Claude Code 팀이 코드 리뷰를 하는 방식 (번역)

2026. 10. 17. · Sam

원문: https://simonwillison.net/2026/Oct/16/code-review/

claude.dev 블로그에 실린 원문 전문의 번역이다.

Claude가 Claude Code 자체 코드의 약 90퍼센트를 작성한다고 우리는 말해 왔다. 그렇다면 이 정도 물량을 어떻게 리뷰하는가. 지금도 누군가 코드를 읽고 있는가. 뭔가 깨졌을 때 누가 잡아내는가.

이 글은 Claude Code 팀의 코드 리뷰 흐름과 그 변천을 다룬다. 6월부터 9월 사이에 Claude Code 코드베이스로 머지된 풀 리퀘스트는 두 배 이상 늘었고, 되돌려야 했던 비중은 40퍼센트 이상 줄었다.

리뷰를 없애지는 않았다. 대신 읽는 일 대부분을 기계로 옮기고, 사람의 시간과 주의에 맞춰 최적화했으며, 실수를 빠르고 쉽게 되돌릴 수 있도록 크게 투자했다.

코드 리뷰의 목적을 다시 생각하다

에이전트가 코드를 쓰면 변경 건수가 빠르게 늘어난다. Anthropic 모노레포에는 하루에 반영되는 변경이 올해 5월의 약 2,500건에서 9월에는 30,000건을 넘었다.

Claude Code는 모노레포와 별개의 저장소에 있지만 이곳도 압박이 크다. 이 속도로 출시하면 사람이 줄마다 코드 리뷰를 하는 일은 어렵기는커녕 거의 불가능하다.

코드 리뷰에는 두 가지 역할이 있다.

출시 전에 문제를 찾아 고친다
팀 전체에 코드베이스 이해와 공유 맥락을 쌓는다

이 글은 주로 첫 번째를 다루고, 두 번째는 끝에서 다시 돌아온다.

우리는 “사람이 코드를 읽었는가”라는 질문이 “이 변경에서 무엇이 잘못될 수 있고, 자동 검사와 사람 검토 중 어느 쪽이 그것을 잡기에 맞는가”라는 질문에 대한 부정확한 대리 지표라고 본다.

이 질문은 리뷰가 언제 일어나는지도 바꿨다. 전에는 리뷰가 길 끝의 관문이었다. 코드를 쓰고, PR을 열고, 동료를 기다린다.

이제 리뷰는 글을 쓰는 동안의 맞춤법 검사처럼 상시 돌아간다. 사람에게 검토를 부탁하기 전에 대부분의 변경은 이미 Claude에게 한 번 이상 리뷰되고 고쳐진 상태다. 이렇게 해서 루틴한 실수 대부분을 걷어내고, 팀의 주의를 더 높은 수준의 질문과 검증에 쓸 수 있게 남겨둔다.

희소한 자원: 사람의 시간과 주의

사람만 해결할 수 있는 문제를 위해 사람의 시간과 주의를 아끼고, 나머지는 자동 검사가 잡도록 만든다. 현재의 변경 속도에서도 사람이 할 일은 여전히 많고, 팀은 거의 매일 새로운 난제를 만난다.

사람의 시간은 리뷰 비용의 양쪽을 덮는다. 리뷰에 쓰는 시간과, 나쁜 코드가 깨뜨린 것을 고치는 시간이다. 앞쪽만 줄이고 그 시간이 뒷쪽으로 이동한다면 소용이 없다.

목표는 Claude Code 저장소들(CLI, 데스크톱·웹 앱, 모바일 앱)의 대부분 PR이 사람 최대 한 명, 그 한 명이 작성자일 수도 있는 구성으로 머지되면서 되돌림과 장애가 늘지 않는 것이다. 사람의 시간을 측정하기 위해 PR당 사람 승인 수(중앙값과 95백분위), 사람이 남긴 코멘트 수, PR이 사람을 기다린 시간을 추적한다. 되돌림률과 장애율은 가드레일이다. 이 숫자가 오르면 사람의 시간을 아낀 것이 아니라 옮긴 것뿐이다.

하나의 변경이 지나가는 길

작성자의 노트북, 혹은 Slack의 Claude 세션에서 시작한 변경은 여러 겹의 코드 리뷰를 통과한다.

FIG A. 대부분의 경로는 자동화되어 있고, 사람의 주의는 위험이 있는 곳으로 간다.

PR이 열리기 전: 작업을 검증한다. Claude가 테스트, 빌드, linter를 돌리고, 두 번째 에이전트가 새로운 컨텍스트에서 diff를 리뷰한다.
모든 PR에서: 필수 CI. 플랫폼별 lint, 타입, 테스트, 빌드와 패키징. 빨간불은 머지를 막는다. Claude 코드 리뷰. 에이전트들이 병렬로 버그를 찾고, 검증자들이 지적마다 투표하고, 살아남은 것은 심각도 순으로 정렬된다. 보안 리뷰는 별도 패스다. 어느 쪽 지적이든 열려 있으면 머지를 막는다. 위험 기반 승인. 분류기가 티어를 정한다. 사람 없음, 한 명, 또는 두 명. 일부 경로는 항상 사람이 필요하다.
머지에서: 머지 큐가 변경을 적용한 최신 main 기준으로 검사를 다시 돌린다.
머지 후: 플래그 뒤에서 내부 사용이 먼저다. Anthropic 직원이 전체 공개 전에 써본다. 점진 출시. latest 채널이 먼저고 stable 채널이 뒤따른다. 감시하고, 앞으로 고치거나 되돌린다. 작성자와 온콜이 지켜보고, 플래그는 빨리 꺼지고, 깨진 빌드는 되돌려진다.

층층이

관문 하나가 아니라 층이다. 여섯 겹의 검사가 쌓이고 그 아래에 빠른 롤백이 있다. 각 층은 어떤 문제는 잡고 어떤 문제는 놓친다. 전부를 뚫는 문제는 드물고, 나머지는 롤백이 처리한다.

1. 다른 누군가 보기 전에 작업을 검증한다

리뷰 대부분은 PR이 존재하기 전에 일어난다. Claude에게 실행할 수 있는 무언가, 예컨대 테스트, 빌드, 디자인과 비교할 스크린샷을 주고, 완료라고 말하는 대신 출력을 보이라고 한다. 그다음 서브에이전트가 새로운 컨텍스트에서 diff를 리뷰한다. 두 습관 모두 베스트 프랙티스 가이드에서 나온 것이다.

PR을 열기 전에 여러 내부 스킬을 돌리기도 한다. 하나는 버그를 찾고, 하나는 diff를 단순화하고, 하나는 동작을 끝까지 확인한다. UI 변경은 디자인 가이드라인과 대조해 검사한다.

Claude Code를 만든 Boris Cherny는 Claude에게 작업을 검증할 방법을 주는 것이 좋은 결과를 얻는 데 아마 가장 중요한 일이라고 말했다. 최종 결과를 두세 배 좋게 만든다는 추정이고, 이렇게 썼다. “검증의 모습은 도메인마다 다르다. bash 명령 하나를 돌리는 것일 수도 있고, 테스트 스위트를 돌리는 것일 수도 있고, 브라우저나 폰 시뮬레이터에서 앱을 테스트하는 것일 수도 있다.”

자동 리뷰어가 같은 것을 계속 지적하면 원인을 고친다. 스킬에서 고치거나, lint 규칙을 만들거나, 다음과 같은 안내 파일을 고친다.

CLAUDE.md는 프로젝트가 무엇인지 Claude에게 알려준다. 스택, 관례, 목표와 목표가 아닌 것. 모든 리뷰가 이 파일을 읽으므로 큰 코드베이스에서는 짧게 유지하고 여기서 다른 문서를 가리킨다. 리뷰어는 이 파일의 관례를 깨는 코드와, 이 파일의 한 줄을 낡게 만드는 변경도 지적한다.
REVIEW.md는 코드 오너가 쓰고, 리뷰어에게 자기 구역에서 무엇이 중요한지 알려준다. 리뷰어가 실제로 이 파일을 따르는지 따로 검사한다. 좋은 REVIEW.md는 짧다. 그 저장소에서 실패가 어떤 모습인지 말하고(문서라면 “거짓말을 한다”, 설정이라면 “잘못된 곳으로 라우팅한다”), 잔소리성 지적에는 상한을 두고, 건너뛸 경로를 나열하고, 이름을 근거로 한 추측 대신 파일과 줄을 증거로 요구한다. 요약은 개수로 시작하게 하고, 고칠 것이 없으면 그렇게 분명히 말하라고 요청한다.

2. 모든 풀 리퀘스트에 AI 리뷰

모든 PR은 사람이 보기 전에 Claude 리뷰를 받는다. 리뷰어는 diff를 저장소 전체와 PR이 밝힌 의도와 대조해 읽고 묻는다. 이 변경이 문제를 해결하는가, 시스템에 맞는가, 다른 것을 깨뜨리는가.

버그 수정이라면 근본 원인을 찾는다. 공개 버전인 Code Review for Claude Code가 Team·Enterprise 플랜에서 일반 제공 중이고, /code-review는 로컬에서 가벼운 버전을 돌린다.

리서치 프리뷰를 출시했을 때 실질적인 리뷰 코멘트를 받은 내부 PR 비중이 16퍼센트에서 54퍼센트로 올라갔다. 1,000줄이 넘는 PR은 대부분 지적이 나오고, 작은 PR은 대부분 깨끗하게 끝난다. 관리자가 저장소마다 Quick, Standard, Deep을 고른다. 놓친 버그 하나가 추가 리뷰 시간보다 비싼 곳에서는 Deep이 값지다.

사람이 리뷰하기 전에 다른 에이전트들이 지적을 검증한다. 여러 에이전트가 동시에 버그를 찾는다. 그다음 별도 그룹이 지적 하나하나에 투표하고, 충분한 수가 진짜라고 동의해야 게시된다. 스타일, 진단, 정리에 불과한 지적은 버린다. 이 필터들은 우리 PR에서 A/B 테스트로 확인하고 남겼다. 남은 것은 심각도 순으로 정렬된 인라인 코멘트로 나타난다. 각각 Important, Nit, Pre-existing 태그가 붙어서, PR이 만들지 않은 버그가 작성자 탓처럼 보이지 않는다.

모든 지적에는 응답이 필요하다. 고치거나, 이유를 붙여 스레드를 resolve한다. 종종 에이전트가 밤사이 수정을 가져와서, 작성자는 이미 한 번 더 리뷰를 통과한 PR로 돌아온다.

3. 막을 수 있는 보안 리뷰

보안에도 자동 리뷰가 따로 돌아간다. 버그 리뷰나 보안 리뷰의 지적이 열려 있는 동안 PR은 머지할 수 없다. 고치거나, 짧은 이유로 스레드를 닫는다. 오탐을 지우는 방법이 그것이다.

이후 커밋이 문제를 고치면 지적은 저절로 해제된다. 오픈소스 보안 리뷰 GitHub Action이나 /security-review 명령으로 같은 구성을 만들 수 있다.

4. 막는 자동 검사

익숙한 것들이다. lint, 타입 검사, 모든 플랫폼의 테스트, 빌드. (이 물량에 맞춰 CI를 확장한 이야기는 별도 글에 썼다.) CLI PR 하나가 사람이 보기 전에 수십 개의 검사를 통과할 수 있다. PR 템플릿은 변경을 어떻게 테스트했는지, 어떻게 되돌리는지 묻는다. Claude가 채울 수 있지만, 변경을 요청한 사람이 서명한다.

5. 위험에 비례한 사람 승인

문서 수정과 자동 업데이터 변경은 위험이 다르고, 리뷰도 다르게 받는다.

위험	예	사람 승인
낮음	문서, 카피, 내부 전용 기능, 플래그 뒤의 추가 변경	자동 리뷰와 보안 검사가 모두 통과되면 불필요
중간	일반 제품 변경, 캐싱·자동 업데이터·시스템 프롬프트 같은 민감 영역의 변경	한 사람
높음	가장 위험한 코드, 항상 두 사람이 필요한 소수의 경로	두 사람

티어를 정하는 것은 변경이고 작성자가 아니다. 분류기가 변경을 읽고 위험 티어를 고른다. 두 번째 분류기는 티어 기준으로는 사람이 필요 없더라도 이 특정 변경에 사람이 하나 더 필요한지 묻는다. 일부 경로는 항상 사람이 필요하다. 오너가 민감하다고 표시한 것과 모든 CI 워크플로 파일이 그렇다.

가벼운 경로는 신뢰된 작성자에게만 열린다. 저장소 신뢰 목록에 있는 작성자, 대체로 그 저장소를 소유한 팀만 가벼운 경로를 쓴다. 그 외에는 두 번째 승인자가 필요하다. 에이전트의 승인은 사람의 승인을 대신할 수 없다. 자동 리뷰는 저위험 변경을 통과시킬 수 있지만, 사람을 요구하는 자리를 채울 수는 없다.

변경을 지시한 사람이 책임을 진다. 에이전트가 쓴 PR에서 에이전트를 지시한 사람이 필수 리뷰어 한 자리를 차지한다. 코드를 직접 타이핑했을 때와 마찬가지다.

승인은 특정 커밋 하나를 덮는다. 시스템이 보증할 수 없는 새 커밋이 들어오면, 에이전트의 푸시나 누군가 손으로 해결한 머지 같은 것이라면 승인을 다시 받아야 한다.

일곱 겹의 검사를 통과한 변경이 머지 큐와 플래그, 점진 출시로 나아가는 모습

6. 머지 큐, 플래그, 점진 출시

머지 큐는 변경을 적용한 최신 main 기준으로 모든 검사를 다시 돌린다. 따로 통과한 두 PR이 합쳐져 main을 깨뜨리는 일을 막는다. 새 동작은 보통 플래그 뒤에서 Anthropic 직원에게 먼저 열린다. 내부의 무거운 사용이 사용자보다 먼저 회귀를 드러낸다. 공개 릴리스는 latest 채널이 먼저고 stable 채널이 뒤따른다.

7. 빠른 감지, 빠른 롤백

그래도 일부 실수는 통과한다. 마지막 층은 그것을 빨리 잡는 일이다. 플래그는 배포 없이 꺼진다. Claude Code에는 주 단위 온콜 로테이션이 있고, 장애 회고에서는 어느 층이 이 문제를 잡았어야 했는지 묻는다.

나쁜 머지를 알아차리는 일은 여전히 작성자와 온콜, 그리고 되돌림·장애 대시보드에 기댄다. 이 숫자가 움직일 때 승인 기준을 강화하는 서킷 브레이커는 아직 없다. 더 많은 코드가 무인 머지로 가기 전에 엔지니어들은 그것을 원한다.

한 동료가 이렇게 말했다. 느리게 하면 오류율이 내려가긴 하지만, 대체로 모든 일을 덜 하기 때문이다. 우리는 문제를 알아차리고 고치는 속도를 올리는 쪽을 택했다.

리뷰어를 더 좋게 만드는 방법

코드 리뷰 프로세스는 끊임없는 루프로 개선된다.

장애는 이제 전부 eval이 된다. 팀은 장애를 일으킨 과거 PR들을 fix-forward와 되돌림과 함께 모으고, 그 코드를 아는 엔지니어에게 각 버그와 그 위치를 확인하게 했다. 리뷰어는 매일 그 세트를 상대로 돌아간다.

이 eval은 장애가 생길 때마다 커지고, 리뷰어의 프롬프트·도구·모델을 바꿀 때마다 전체 세트로 점수를 매긴다. 점수가 올랐으면 유지하고, 아니면 버린다.

노이즈는 코멘트에 대한 사람의 반응을 보며 측정한다. 비버그를 찍는 것을 신경 쓰지 않는다면 버그를 더 많이 잡는 일은 쉽다. 그래서 방어가 필요하다. 리뷰어가 남긴 모든 코멘트를 PR 담당자의 반응으로 분류한다. 고쳤는지, 틀렸다고 했는지, 의도된 동작이라고 했는지, 중요하지 않다고 판단했는지. 깨끗하다고 알려진 PR에도 리뷰어를 돌려서, 누군가를 해로운 변경으로 이끌 만한 보고를 얼마나 하는지 센다. 우선순위는 문서로 적어 둔다. 진짜 버그를 잡는 게 첫째, 리뷰 라운드를 줄이는 게 둘째.

노이즈 비용은 작성자가 에이전트일 때 더 크다. 사람은 nit를 몇 초 만에 움직여 넘긴다. 에이전트는 고친다. 즉 커밋이 하나 더 쌓이고 리뷰 라운드가 하나 더 돈다.

리뷰는 수렴해야 한다. 에이전트 작성자와 에이전트 리뷰어는 서로를 무한히 바쁘게 할 수 있다. CLI PR 하나가 작성자가 멈추기 전까지 밤사이 50라운드를 넘게 리뷰와 수정을 반복한 적이 있다.

리뷰어가 계속 지적한 것에 git blame을 돌리니 약 59퍼센트가 리뷰어의 첫 패스 때부터 있던 코드였다. 리뷰어는 새 버그를 찾기보다 매 라운드 낡은 버그를 조금씩 더 찾고 있었다.

우리 스스로 이것을 악화시켰다. 기본으로 여러 라운드를 돌리는 데 익숙해져 있었다. 패스마다 뭔가 새로 잡히기 때문이다. 위험한 변경에서는 값질 수 있지만 모든 PR에서 그런 것은 아니다. 팀은 이제 recall과 함께 rounds-to-pass를 추적하고, 재리뷰 방식을 바꿨다.

라운드 상한. 세 라운드가 지나면 리뷰어가 작성자에게 한 걸음 물러나 접근을 다시 생각하라고 요청한다.
처음 몇 패스 이후에는 diff만 다시 리뷰한다.
버그의 유형을 지적해서 작성자가 한 줄이 아니라 모든 사례를 고치게 한다.
이미 게시된 지적을 반복하지 않는다.

리뷰 에이전트는 밤마다 기존 코드 위에서도 돈다. 낡은 버그가 다른 곳에 나타나기 전에 잡는 데 도움이 된다.

수렴 변경 이후 내부 PR에서 한 번의 리뷰·수정 라운드로 통과하는 비중은 65퍼센트에서 78퍼센트로 올랐고, 다섯 라운드 이상이 필요한 비중은 8.9퍼센트에서 1.5퍼센트로 내렸으며, 통과까지 평균 리뷰 수는 2.08에서 1.32로 줄었다.

사람이 루프에 남는 곳

시니어 엔지니어를 깊은 작업에서 끌어내 루틴한 실수를 잡게 하는 일은 자동 리뷰보다 훨씬 비싸다. Anthropic에서 우리의 일은 모든 diff를 읽는 것에서 기계가 못 하는 결정으로 옮겨졌다.

이것을 애초에 만들어야 하는가. 방향, 취향, 범위. 리뷰 병목이 해결됐다고 선언한 팀조차 팀 밖에서 온 변경에는 사람 리뷰를 유지해서 누군가 “이걸 해야 하긴 하는가”를 묻게 했다.
청구(billing), 자동 업데이터, CI 워크플로 같은 위험한 코드.
다른 사람들이 따라 복사할 패턴을 정하는 아키텍처.
증거 읽기. 테스트 출력, 돌아간 명령과 반환값, 스크린샷, 리뷰어의 지적. 검사가 무엇을 놓칠지 말할 수 없다면 빠른 승인 대신 진짜 리뷰를 요청한다.
결과의 소유. 누가 타이핑했든 출시되는 모든 변경에는 책임지는 사람이 있다.

팀 전체에 맥락을 나누다

코드 리뷰의 두 번째 역할은 언제나 코드베이스 이해를 퍼뜨리는 것이었다. 동료의 diff를 읽는 것이 무엇이 바뀌었고 조각들이 어떻게 맞물리는지 배우는 길이다. 기계가 대부분의 읽기를 한다면 누가 코드를 배우는가.

이를 위한 정식 프로세스는 없다. 팀에 Claude Code의 완전한 멘탈 모델을 머리에 넣고 다니는 사람은 없고, 필요하지도 않다고 본다. 누군가 코드베이스의 한 부분을 이해하고 싶으면 Claude에게 정확히 그 슬라이스에 대한 설명문(explainer)을 쓰게 한다. 몇 분 걸리고 오늘 현재의 코드를 반영한다.

한 걸음 더 나아가 Claude에게 그 부분을 시각화하고 자기가 좋아하는 방식으로 가르쳐 주는 작은 아티팩트를 만들게 하는 사람들도 있다.

목표가 사람의 주의를 잘 쓰는 것이라면 이 방법이 사소한 diff를 줄마다 읽는 것보다 낫다. 한 줄 카피 변경에서 배울 것은 거의 없다. 이제 막 바꾸려는 모듈의 설명문에서 배울 것은 많다. 열린 Slack 채널에서 일하는 기본 문화도 도움이 된다. 다른 사람들이 만드는 것을 만드는 동안 볼 수 있기 때문이다.

“네가 머지하면 네가 책임진다”

작거나 중간 규모의 변경을 머지하고 그래도 문제가 생기면 보통 본인이 고치는 것이 팀 규범이다. 이것이 나쁘게 흘러가지 않는 이유는 몇 가지다.

변경이 작다. 리뷰하고 디버그하고 되돌리기 쉽다.
모든 것이 되돌릴 수 있다. 플래그, 되돌림, 단계적 출시가 대부분의 실수를 몇 분 안에 되돌린다.
영향 범위가 기준이다. 비싼 코드에는 더 많은 사람과 검사가 붙는다.
회귀는 텔레메트리와 내부 사용으로 빨리 드러난다.
이것은 비난이 아니다. 수정을 소유한다는 것은 맥락을 가장 많이 가진 사람이 고친다는 뜻이고, 장애 회고는 시스템을 본다.

소유권은 나눠 갖기도 한다. 팀의 상당수가 열린 채널에서 일한다. 누구나 다른 사람이 만드는 것을 보고, 스레드를 잇고, Claude를 빈틈에 붙일 수 있다. 피드백은 코드 소유자가 아닌 사람에게서도 온다. 모든 줄에 관문을 두지 않고 품질을 높게 유지하는 데 이 열림이 큰 몫을 한다.

방향을 바꿀 때

에이전트는 시작을 싸게 만들기 때문에 어떤 작업은 머지되지 말아야 한다. 보통 채널의 누군가가 왜인지 묻고, 이전 결정을 가리키거나 더 단순한 길을 제안하면 작성자가 PR을 닫거나 다시 잡는다.

코드가 빨리 쓰였기 때문에 PR을 닫는 일이 손해처럼 느껴지지 않는다. 요령은 완성된 PR에 막는 코멘트로 달지 않고, 스레드에서 일찍 다른 방향을 꺼내는 것이다.

이 프로세스를 도입하는 방법

필요한 조각들은 대부분 오늘 존재한다.

풀 리퀘스트 전

에이전트에게 실행할 수 있는 검사를 준다. 짧은 CLAUDE.md에 목록을 두고, 포매터와 linter를 돌리는 훅을 붙인다.
/code-review와 /security-review를 로컬에서 돌리거나, 새 컨텍스트의 서브에이전트 리뷰를 돌린다.
REVIEW.md를 만들고 반복되는 리뷰 코멘트를 그 안으로 옮긴다.

모든 풀 리퀘스트에서

CI를 필수로 하고 PR 템플릿에 Testing, Risk, How to revert를 넣는다.
한 저장소에 AI 리뷰어(Code Review for Claude Code 또는 Claude Code GitHub Action)를 붙이고, REVIEW.md를 몇 주 다듬은 뒤 범위를 넓힌다.
자동 보안 리뷰를 추가하고, 모든 리뷰 스레드의 해결을 머지 조건으로 둔다.
리뷰 강도를 위험에 맞춘다. 루틴한 변경은 빠른 패스, 놓친 버그가 비싼 곳은 깊은 패스(Code Review의 Quick, Standard, Deep).
리뷰 라운드에 상한을 두고, 처음 몇 패스 이후에는 새 diff만 재리뷰한다.

승인

위험 티어를 문서로 적고, 작성자가 아니라 변경에서 티어를 정한다. 엄격하게 시작하고 근거가 쌓이면 느슨하게 한다.
가벼운 승인 경로는 신뢰하는 작성자에게만 남긴다.
CODEOWNERS와 브랜치 보호를 써서 인증, 청구, CI와 릴리스 워크플로, 인스톨러에는 항상 사람이 필요하도록 한다.
봇의 승인이 필수 사람 승인을 대신하게 하지 않는다. 새 커밋에서는 승인을 해제한다.

머지와 그 이후

머지 큐, 피처 플래그, 내부 사용 우선, 단계적 릴리스, 한 번에 롤백을 쓴다.
장애와 되돌림을 eval 세트로 만들고, 리뷰어의 프롬프트·도구·모델이 바뀔 때마다 다시 점수를 매긴다.
사람의 시간을 측정한다. 되돌림률과 장애율이 가드레일이다.

앞으로의 방향

Code Review 발표는 PR 승인이 여전히 사람의 판단이라고 밝혔다. 제품은 승인이 아니라 지적을 게시한다. 우리 자체 저장소는 더 나아가 오너가 어떤 저위험 변경을 자동 검사만으로 머지할지 정하게 하고, 그 선은 계속 움직인다.

리뷰가 무언가를 놓쳤을 때 우리는 모델 앞에 무엇이 없었는지 묻고, 그 해결을 CLAUDE.md나 스킬, 새 검사에 넣는다. 목표는 변하지 않았다. 변경당 사람의 시간을 줄이고, 되돌림을 늘리지 않는 것.

팀이 에이전트에게 PR을 열게 한다면 어떤 검사를 자동화했는지, 무엇이 아직 사람을 필요로 하는지, 우리가 뭘 잘못 알고 있다고 생각하는지 듣고 싶다.

Emma Webb, Michael Segner, Amie Rotherham의 리뷰에 감사한다.

모든 에세이 · home