Claude Code 팀이 코드 리뷰를 수행하는 방법

저희는 이전에 Claude가 Claude Code 자체 코드의 약 90 퍼센트를 작성한다고 말한 바 있습니다. 그렇다면 이렇게 많은 양의 코드를 어떻게 리뷰할 수 있을까요? 이제는 아무도 코드를 읽지 않는 걸까요? 그리고 무언가가 고장 났을 때 누가 그것을 잡아낼까요?

이 글에서는 Claude Code 팀의 코드 리뷰 흐름과 그 진화 과정을 다룹니다. 6월부터 9월까지 Claude Code 코드베이스에 병합된 pull request는 두 배 이상 증가했고, 그중 revert되어야 했던 비율은 40 퍼센트 이상 감소했습니다.

저희는 리뷰를 없애지 않았습니다. 대신 대부분의 읽기 작업을 기계로 옮기고, 인간의 시간과 주의력을 최적화했으며, 실수를 빠르고 쉽게 되돌릴 수 있도록 많은 투자를 했습니다.

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

에이전트가 코드를 작성하면 변경 사항의 수가 빠르게 늘어납니다. Anthropic의 모노레포에서는 하루에 반영되는 변경 사항이 약 5월의 2,500건에서 올해 9월에는 30,000건 이상으로 증가했습니다.

Claude Code는 모노레포와 별도의 자체 저장소에 있지만, 역시 상당한 압박을 받고 있습니다. 이렇게 빠르게 출시하는 상황에서는 수동의 한 줄씩 확인하는 코드 리뷰가 어려울 뿐만 아니라 사실상 불가능합니다.

코드 리뷰는 두 가지 역할을 합니다:

1. 출시 전에 문제를 찾아 수정하기
2. 팀 전체에 공유된 맥락과 코드베이스 이해를 구축하기

이 글은 주로 문제를 찾고 수정하는 일에 초점을 맞추지만, 글 말미에서 두 번째 역할로 다시 돌아올 것입니다.

저희는 "인간이 코드를 읽었는가?"라는 질문이 "이 변경으로 무엇이 잘못될 수 있고, 자동화 검사든 인간 검토든 어떤 확인이 그것을 잡아내기에 적절한가?"라는 질문에 대한 부정확한 대리 지표라고 생각합니다.

이 질문을 던지는 것은 리뷰가 언제 이루어지는지도 바꾸었습니다. 이전에는 리뷰가 길의 끝에 있는 관문이었습니다. 코드를 작성하고, PR을 열고, 동료를 기다리는 방식이었습니다.

이제는 리뷰가 지속적으로 실행됩니다. 글을 쓰는 동안의 맞춤법 검사기처럼요. 대부분의 변경 사항은 인간에게 검토를 요청하기 전에 최소 한 번은 Claude에 의해 검토되고 수정됩니다. 이를 통해 대부분의 일상적인 실수를 잡아내고, 팀의 주의력은 더 높은 수준의 질문과 검토에 쓸 수 있게 됩니다.

희소한 자원: 인간의 시간과 주의력

저희는 인간만이 해결할 수 있는 문제를 위해 인간의 시간과 주의력을 아끼고, 나머지는 자동화 검사가 잡아내도록 하고자 합니다. 현재의 변경 속도에서도 인간이 해야 할 놀라울 정도로 많은 작업이 남아 있으며, 저희 팀은 거의 매일 새롭고 색다른 과제에 부딪힙니다.

인간의 시간은 리뷰 비용의 양쪽을 모두 포함합니다. 사람들이 리뷰에 쓰는 시간과 나쁜 코드가 깨뜨린 것을 수정하는 데 쓰는 시간입니다. 첫 번째를 줄였다고 해서 그 시간이 두 번째로 넘어간다면 아무 도움이 되지 않습니다.

따라서 목표는 Claude Code 저장소들(CLI, 데스크톱 및 웹 앱, 모바일 앱)의 대부분 pull request가 인간 한 명(작성자일 수 있음)의 개입으로 병합되면서 revert나 장애가 증가하지 않도록 하는 것입니다. 인간의 시간을 측정하기 위해 저희는 PR당 인간 승인 수(중앙값 및 95 백분위수), 인간 코멘트 수, PR이 사람을 기다리는 시간을 추적합니다. Revert율과 장애율은 가드레일입니다. 이 수치가 상승하면 인간의 시간을 절약한 것이 아니라 옮긴 것에 불과합니다.

변경 사항의 생애

엔지니어의 노트북(또는 Slack의 Claude 세션)에서 시작된 전형적인 변경 사항은 여러 계층의 코드 리뷰를 거칩니다.

계층별로 살펴보기

1. 다른 누군가가 보기 전에 작업이 검증된다

이제 대부분의 리뷰는 PR이 존재하기 전에 이루어집니다. 우리는 Claude에게 실행 가능한 것—테스트, 빌드, 또는 디자인과 비교할 스크린샷—을 제공하고, 완료되었다고 말하는 대신 결과물을 보여달라고 요청합니다. 그런 다음 서브에이전트가 새로운 컨텍스트로 diff를 리뷰합니다. 이 두 가지 습관은 모두 저희의 모범 사례 가이드.

PR을 열기 전에 우리 중 상당수는 몇 가지 내부 스킬도 실행합니다. 하나는 버그를 찾고, 하나는 diff를 단순화하고, 하나는 동작을 엔드 투 엔드로 확인합니다. UI 변경 사항은 또한 우리의 디자인 가이드라인에 따라 검토됩니다.

Claude Code를 만든 Boris Cherny는 Claude에게 자신의 작업을 검증할 방법을 주는 것을 언급한 바 있습니다. 아마도 가장 중요한 것일 겁니다 좋은 결과를 얻기 위한 방법입니다. 그는 이것이 최종 결과를 두세 배 더 좋게 만든다고 추정하며, "검증은 도메인마다 다르게 이루어집니다. bash 명령을 실행하거나, 테스트 스위트를 실행하거나, 브라우저나 폰 시뮬레이터에서 앱을 테스트하는 것만큼 간단할 수 있습니다."라고 썼습니다.

자동 검토기가 같은 문제를 계속 지적할 때, 우리는 그 원인에서 해결합니다: 스킬 자체 내에서, 린트(lint) 규칙을 통해서, 또는 다음과 같은 안내 파일의 업데이트를 통해:

• CLAUDE.md 프로젝트가 무엇인지 Claude에게 알려줍니다: 스택, 컨벤션, 목표와 목표가 아닌 것들. 모든 리뷰가 이 파일을 로드하기 때문에, 규모가 큰 코드베이스에서는 짧게 유지하고 여기서 다른 문서들을 가리키도록 합니다. 리뷰어는 또한 이 파일의 컨벤션을 깨는 코드와 이 파일의 내용을 낡게 만드는 변경사항도 표시합니다.
• REVIEW.md코드 오너들이 작성하는 이 문서는 리뷰어에게 자신들이 담당하는 코드 부분에서 무엇이 중요한지 알려줍니다. 리뷰어가 실제로 이 문서를 따르는지는 별도로 확인합니다. 좋은 문서들은 짧습니다. 그 리포지토리에서 실패가 어떤 모습인지 말해주고(문서라면 "거짓말을 하는 것", 설정이라면 "잘못된 경로로 라우팅하는 것"), 사소한 지적(nit)의 수를 제한하고, 건너뛸 경로를 나열하며, 이름만 보고 추측하는 대신 파일과 라인을 근거로 요구합니다. 또한 개수로 시작하는 요약을 요구하고, 수정할 것이 없을 때는 그렇게 명확히 말하도록 합니다.

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

모든 풀 리퀘스트는 사람이 보기 전에 Claude 리뷰를 받습니다. Claude는 diff를 리포지토리 전체 및 PR에 명시된 의도와 대조하여 읽고 다음을 묻습니다: 이 변경사항이 문제를 해결하는가, 시스템에 부합하는가, 아니면 다른 무언가를 깨뜨리는가?

버그 수정의 경우, 근본 원인을 찾습니다. 공개 버전인 Code Review for Claude Code가 Team 및 Enterprise 플랜에서 정식 출시(generally available)되었으며, /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을 머지할 수 없습니다. 수정하거나 짧은 이유와 함께 스레드를 닫아야 하며, 이것이 오탐(false positive)을 해소하는 방법입니다.

이후 커밋이 문제를 수정하면, 지적 사항은 자동으로 해제됩니다. 오픈소스 보안 리뷰 GitHub Action이나 /security-review 커맨드로 동일한 것을 설정할 수 있습니다. 설정 방법은 automated security reviews in Claude Code.

4. 차단하는 자동 검사

일반적인 것들입니다: 린트, 타입 검사, 모든 플랫폼에서의 테스트, 그리고 빌드. (이 규모에 맞춘 CI 확장에 대해 저희가 여기에 작성한 글이 있습니다.) 전형적인 CLI 풀 리퀘스트는 아무도 보기 전에 수십 개의 검사를 실행할 수 있습니다. PR 템플릿은 변경사항이 어떻게 테스트되었는지와 어떻게 되돌릴 수 있는지를 묻습니다. Claude가 이를 작성할 수 있지만, 변경사항을 요청한 사람이 이를 승인합니다.

5. 위험도에 따라 조정되는 사람의 승인

문서 수정과 자동 업데이터 변경은 위험도가 다르므로, 서로 다른 리뷰를 받습니다.

변경사항이 등급을 정하는 것이지, 작성자가 정하는 것이 아닙니다. 분류기가 변경사항을 읽고 위험 등급을 정합니다. 두 번째 분류기는 등급이 사람이 필요 없다고 판단하더라도 이 특정 변경사항에 다른 사람이 필요한지를 묻습니다. 어떤 경로는 항상 사람을 필요로 합니다. 소유자가 민감하다고 지정한 모든 것과 CI 워크플로우 파일이 그렇습니다.

신뢰할 수 있는 작성자만 더 가벼운 경로를 얻습니다. 저장소의 신뢰 목록에 있는 작성자, 주로 해당 저장소를 소유한 팀만 더 가벼운 경로를 이용할 수 있습니다. 다른 모든 사람은 두 번째 사람의 승인이 필요합니다. 에이전트의 승인 역시 사람의 승인으로 간주되지 않습니다. 자동화된 검토가 저위험 변경사항을 통과시킬 수는 있지만, 사람을 요구하는 자리를 대신할 수는 없습니다.

변경을 지시한 사람이 그 변경사항에 대한 책임을 집니다. 에이전트가 작성한 PR의 경우, 에이전트를 지시한 사람이 요구되는 검토자 중 한 명으로 간주됩니다. 그들이 직접 코드를 작성했을 때와 마찬가지입니다.

승인은 하나의 특정 커밋에 대해서만 유효합니다. 시스템이 보증할 수 없는 새 커밋이 올라오면, 예를 들어 에이전트의 푸시나 누군가 수작업으로 해결한 병합이 있으면, 승인을 다시 받아야 합니다.

6. 머지 큐, 플래그, 그리고 점진적 릴리스

머지 큐는 변경 사항이 적용된 상태로 모든 검사를 main에 대해 다시 실행하므로, 각각 따로 통과한 두 PR이 합쳐져서 깨진 main을 만들 수 없습니다. 새로운 동작은 보통 플래그 뒤에 숨겨진 채 먼저 Anthropic 직원들에게 배포되며, 우리의 많은 사용이 사용자보다 먼저 회귀를 드러내는 경우가 많습니다. 공개 릴리스는 먼저 latest 채널로 나갑니다. 그 stable 채널이 그 뒤를 따릅니다.

7. 빠른 감지, 빠른 롤백

일부 실수는 여전히 통과할 수 있으므로, 마지막 계층은 이를 빠르게 잡는 것입니다. 플래그는 배포 없이 끌 수 있습니다. Claude Code에는 주간 온콜 로테이션이 있으며, 인시던트 리뷰에서는 어떤 계층이 이 문제를 잡았어야 했는지 묻습니다.

나쁜 머지를 알아차리는 것은 여전히 작성자와 온콜, 그리고 revert 및 인시던트 대시보드에 의존합니다. 이러한 수치가 움직일 때 승인 기준을 강화하는 서킷 브레이커는 아직 없으며, 여기 엔지니어들은 더 많은 코드가 무인 머지로 넘어가기 전에 그것을 원하고 있습니다.

한 동료는 속도를 늦추면 오류율이 낮아지긴 하지만, 대체로 모든 작업을 덜 하기 때문이라고 말했습니다. 우리는 문제를 알아차리고 수정하는 데 더 빨라지는 것을 선호합니다.

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

우리의 코드 리뷰 프로세스는 루프를 돌며 끊임없이 개선되고 있습니다.

발생한 인시던트는 모두 이제 eval이 됩니다. 팀은 인시던트를 일으킨 과거 PR들을 fix-forwards 및 revert와 함께 수집하고, 해당 코드를 아는 엔지니어들에게 각 버그와 그 위치를 확인하도록 했습니다. 리뷰어는 매일 그 집합을 대상으로 실행됩니다.

우리는 사람들이 코멘트를 어떻게 다루는지 지켜봄으로써 노이즈를 측정합니다. 많은 비버그를 지적하는 것을 신경 쓰지 않으면 더 많은 버그를 잡기 쉽기 때문에, 이에 대한 검증이 필요합니다. 우리는 리뷰어가 남기는 모든 코멘트를 PR 담당자의 반응 방식에 따라 분류합니다: 수정했거나, 잘못됐다고 했거나, 그 동작이 의도적이라고 했거나, 중요하지 않다고 판단했거나. 또한 깨끗하다고 알려진 PR에 리뷰어를 실행하여 유해한 변경을 유도할 만한 것을 보고하는 빈도를 셉니다. 우리의 우선순위는 문서화된 대로, 진짜 버그를 잡는 것이 첫째이고 리뷰 라운드를 줄이는 것이 둘째입니다.

노이즈는 작성자가 에이전트일 때 더 큰 비용을 초래합니다. 사람은 사소한 지적을 몇 초 만에 무시할 수 있습니다. 에이전트는 그것을 수정하는데, 이는 또 다른 커밋과 또 다른 리뷰 라운드를 의미합니다.

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

리뷰어가 계속 지적한 것에 git blame을 실행했을 때, 약 59%가 리뷰어의 첫 번째 검토 때부터 있었던 코드였습니다. 리뷰어는 새로운 버그를 찾는 경우가 드물었고, 라운드마다 몇 개 더 오래된 버그를 찾고 있었습니다.

우리 스스로 이를 악화시켰습니다. 우리는 각 검토가 무언가 새로운 것을 잡기 때문에 기본으로 여러 라운드를 실행하는 데 익숙해져 있었습니다. 이는 위험한 변경에는 가치가 있을 수 있지만 모든 PR에 그럴 필요는 없습니다. 팀은 이제 리콜과 함께 통과까지 필요한 라운드 수를 추적하며, 재검토 방식을 변경했습니다:

• 라운드 상한. 세 라운드가 지나면 리뷰어는 작성자에게 한 걸음 물러나 접근 방식을 다시 고려하라고 요청합니다.
• diff 전용 재검토 첫 몇 번의 검토 이후에는.
• 버그 클래스 지적, 작성자가 한 줄이 아니라 모든 인스턴스를 수정하도록.
• 반복 없음 이미 게시된 지적 사항은.

리뷰 에이전트는 또한 매일 밤 기존 코드를 대상으로 실행되어, 오래된 버그가 다른 곳에서 나타나기 전에 잡는 데 도움을 줍니다.

HUMANS STAY IN THE LOOP

시니어 엔지니어를 깊은 작업에서 불러내어 사소한 실수를 잡게 하는 것은 자동화된 리뷰보다 훨씬 큰 비용이 듭니다. Anthropic에서 우리의 업무는 모든 diff를 읽는 것에서 기계가 잘 못하는 결정들로 옮겨갔습니다:

• Should we build this at all? 방향, 취향, 범위. 리뷰 병목이 해결되었다고 선언한 한 팀도 여전히 팀 외부에서 오는 변경에는 사람의 리뷰를 유지했는데, 그래서 누군가는 "should we even do this?"라고 묻게 됩니다.
• 위험한 코드 예를 들어 청구(billing), 자동 업데이터, CI 워크플로우 등입니다.
• 아키텍처 다른 사람들이 따라 하게 될 패턴을 만드는 것.
• 증거 읽기. 테스트 출력, 실행된 명령어와 그 반환 결과, 스크린샷, 리뷰어의 소견. 검사가 무엇을 놓칠 수 있는지 말할 수 없다면, 대충 승인받기보다 진짜 리뷰를 요청하세요.
• 결과에 대한 책임. 누가 코드를 타이핑했든, 출시되는 모든 변경에는 한 사람이 책임을 집니다.

SHARING CONTEXT ACROSS THE TEAM

코드 리뷰의 두 번째 역할은 항상 코드베이스에 대한 이해를 널리 퍼뜨리는 것이었습니다. 팀원의 diff를 읽는 것이 변경된 내용과 각 부분이 어떻게 맞물리는지 배우는 방법입니다. 만약 기계가 대부분의 읽기를 담당한다면, 사람들은 어떻게 코드를 배울 수 있을까요?

이를 위한 공식적인 프로세스는 없습니다. 팀 누구도 Claude Code에 대한 완전한 멘탈 모델을 머릿속에 간직하지 않으며, 그럴 필요가 있다고 생각하지도 않습니다. 누군가 코드베이스의 특정 부분을 이해하고 싶을 때, 바로 그 부분에 대한 설명서를 Claude에게 작성해 달라고 요청합니다. 몇 분이면 완료되며 오늘 날짜 기준의 실제 코드를 반영합니다.

우리 중 일부는 한 걸음 더 나아가, Claude가 코드의 해당 부분을 시각화하는 작은 아티팩트를 만들게 하여 그 사람이 선호하는 학습 방식으로 배우도록 합니다.

목표가 인간의 주의력을 잘 쓰는 것이라면, 이는 사소한 diff를 한 줄씩 읽는 것보다 낫습니다. 한 줄짜리 복사 변경은 거의 아무것도 가르쳐 주지 않습니다. 곧 수정하려는 모듈에 대한 설명 자료는 많은 것을 가르쳐 줍니다. 기본으로 열려 있는 Slack 채널에서 작업하는 저희 문화도 도움이 됩니다. 다른 사람들이 무엇을 만들고 있는지 만드는 동안 그대로 볼 수 있기 때문입니다.

"당신이 착륙하면, 그것은 당신의 것입니다"

작거나 중간 규모의 변경을 적용한 후에도 문제가 발생하면, 보통 그것을 직접 수정하는 것이 팀의 관례입니다. 이것이 나쁘게 흘러가지 않도록 유지해 주는 몇 가지 요소가 있습니다:

• 변경 사항은 작으며, 검토, 디버그 및 되돌리기가 쉽도록 하기 위해서입니다.
• 모든 것은 되돌릴 수 있습니다. 플래그, 되돌리기 및 단계적 릴리스는 대부분의 실수를 몇 분 안에 되돌려 줍니다.
• 폭발 반경이 기준을 정한다. 비용이 많이 드는 코드에는 더 많은 사람과 더 많은 검토가 투입된다.
• 회귀 오류는 빠르게 드러납니다 텔레메트리와 내부 사용을 통해 이루어집니다.
• 그것은 비난이 아닙니다. 수정 사항을 소유하고 있다는 것은 가장 많은 맥락을 갖고 있다는 뜻이며, 장애 검토는 시스템을 살펴봅니다.

소유권 또한 공유됩니다. 팀의 상당수 구성원은 다음에서 근무합니다. 개방 채널 누구나 다른 사람들이 만들고 있는 것을 볼 수 있고, 흐름을 이어받거나 Claude를 비어 있는 부분에 투입할 수 있으며, 코드를 소유하지 않은 사람들로부터도 피드백이 옵니다. 이러한 개방성이 모든 줄마다 관문을 두지 않고도 품질을 높게 유지하는 큰 부분을 차지합니다.

우리가 방향을 바꿀 때

에이전트는 무언가를 시작하는 비용을 낮추기 때문에, 일부 작업은 받아들여지지 않아야 합니다. 보통 채널의 누군가가 그 이유를 묻고, 이전 결정을 지목하거나 더 간단한 방법을 제안하면, 작성자가 PR을 닫거나 다듬습니다.

코드를 빠르게 작성했기 때문에 PR을 닫는 것이 손해처럼 느껴지지 않습니다. 요령은 완성된 PR에 차단 코멘트로 남기는 것이 아니라, 스레드에서 다른 방향을 일찍 제시하는 것입니다.

이 과정을 어떻게 도입할 수 있는가

이를 팀과 함께 수행하는 데 필요한 대부분의 요소들은 오늘날 이미 존재합니다.

풀 리퀘스트 전에

• 에이전트가 실행할 수 있는 점검 항목을 짧은 CLAUDE.md, 그리고 포매터와 린터를 실행하는 훅도 포함됩니다.
• 실행 /code-review 그리고 /security-review 로컬에서 검토하거나, 새로운 컨텍스트를 가진 하위 에이전트(subagent)의 검토를 받는 것입니다.
• 추가 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와 브랜치 보호를 사용하여 auth, billing, CI 및 release 워크플로우, 그리고 인스톨러에는 항상 사람의 확인이 필요하도록 하세요.
• 봇의 승인이 필수 인간의 승인을 대체하게 하지 말고, 새 커밋이 있으면 승인을 취소하세요.

병합 이후

• 병합 큐, 피처 플래그, 내부 우선 사용, 단계적 릴리스, 원스텝 롤백을 활용하세요.
• 장애(incident)와 되돌리기(revert)를 평가 셋으로 만들고, 리뷰어의 프롬프트, 도구 또는 모델이 변경될 때마다 다시 채점하세요.
• 사람의 시간을 측정하되, 되돌리기율과 장애 발생률을 안전선(guardrail)으로 삼으세요.

이 기술의 향방

Code Review의 발표 에 따르면 풀 리퀘스트 승인은 여전히 사람의 판단 사항이며, 이 제품은 승인이 아닌 지적 사항을 게시합니다. 우리 자신의 저장소에서는 더 나아가 소유자가 자동화된 검사만으로 어떤 저위험 변경을 병합할지 결정하도록 하고 있으며, 그 기준선은 계속 움직이고 있습니다.

리뷰에서 무언가 놓쳤을 때, 우리는 모델이 앞에 두지 못했던 것이 무엇인지 물어보고 그 수정책을 CLAUDE.md이나 스킬 또는 새로운 검사에 반영합니다. 목표는 변하지 않았습니다. 변경당 사람의 시간을 줄이고, 되돌리기 횟수는 이전보다 늘리지 않는 것입니다.

여러분 팀이 에이전트가 풀 리퀘스트를 열도록 허용한다면, 어떤 검사를 자동화했는지, 어떤 검사가 여전히 사람을 필요로 하는지, 그리고 우리가 잘못 이해하고 있다고 생각하는 것이 무엇인지 알려주시면 감사하겠습니다.

리뷰해 준 Emma Webb, Michael Segner, Amie Rotherham에게 감사를 전합니다.