AI가 만든 코드, 위험과 검증 결과로 리뷰하기
목차 · 원하는 부분으로 이동
AI가 코드를 빨리 만들수록 검토할 변경도 쌓인다. Claude Code 팀은 최근 공개한 개발 글에서 변경의 위험에 따라 사람의 검토를 배분하는 방식을 설명했다. 작은 팀에서도 PR 하나에 위험, 실행한 검사, 되돌리는 방법을 붙이는 것부터 시작할 수 있다.
완료했다는 설명을 읽고 끝내지 말고, 무엇이 잘못될 수 있는지와 그것을 확인한 근거를 함께 보자.
TL;DR
- 문구 수정과 결제·권한 수정을 같은 깊이로 검토하지 않는다.
- 테스트 이름과 실제 실행 결과를 남긴다. 실행하지 못한 항목도 적는다.
- 지적을 반영한 뒤에는 새 변경을 중심으로 다시 확인한다.
- 병합 뒤 문제가 생기면 누가 무엇을 되돌릴지 미리 정한다.
사람의 시간을 줄이는 데는 전제가 있다
Claude Code 팀은 자동 리뷰와 보안 검사, CI를 여러 단계로 쌓고, 변경 위험에 따라 사람의 승인을 달리한다. 낮은 위험의 일부 변경에는 자동 검사만으로 진행하는 경로도 있지만 신뢰된 작성자와 지정된 경로라는 조건이 붙는다. 모든 저장소에서 사람 검토를 없애라는 조언으로 옮기면 안 된다. Anthropic 개발 글
이 방식은 검사와 되돌리기가 갖춰져 있을 때 의미가 있다. 자동 테스트가 거의 없거나 운영 장애를 뒤늦게 아는 팀이라면 승인 인원부터 줄일 이유가 없다. 기존 검토를 유지한 채 자주 놓치는 오류를 검사로 옮기는 데서 출발하자.
아래는 프랜디어가 작은 웹 서비스 팀을 가정해 만든 적용 예시다. Anthropic의 내부 정책이나 실제 측정 결과를 그대로 재현한 것은 아니다.
첫 질문은 변경 줄 수보다 영향 범위
예를 들어 다운로드 버튼의 안내 문구를 고치는 일과 파일 다운로드 권한을 바꾸는 일은 모두 몇 줄로 끝날 수 있다. 하지만 후자는 다른 사용자의 파일이 열릴 가능성을 확인해야 한다. 수정량만 세면 이 차이가 잘 보이지 않는다.
PR을 열 때 “이 변경이 틀렸다면 누가 어떤 피해를 받는가?”를 한 문장으로 적어 보자.
| 변경 예시 | 먼저 볼 근거 | 사람에게 남길 판단 |
|---|---|---|
| 안내 문구 수정 | 모바일 화면·링크 목적지 | 의미가 정확한가 |
| 파일 내보내기 변경 | 경계 입력·기존 파일 호환 검사 | 실패해도 원본을 보존하는가 |
| 인증·결제 변경 | 권한별 테스트·실패 처리 | 접근 범위와 금액이 의도대로인가 |
이 표는 자체 분류 예시다. 문구 하나가 결제 조건을 바꾸거나 법적 고지를 건드린다면 단순 수정으로 묶지 않는다. 변경이 닿는 대상과 실패했을 때의 결과로 판단한다.
PR에는 결과와 빈칸을 같이 남긴다
“테스트 통과”만으로는 무엇을 확인했는지 알기 어렵다. 실행 명령, 확인한 조건, 나온 결과를 같이 남겨야 다시 검토할 수 있다. 화면을 바꿨다면 해당 화면도 확인한다.
다음은 CSV 내보내기 기능을 고친 가상의 PR 기록이다.
이 기록에서 “미확인”은 실패를 숨기는 칸이 아니다. 검토자가 남은 확인을 맡을지, 변경 범위를 줄일지 결정할 근거다. 테스트를 실행하지 못했다면 통과로 적지 말고 막힌 환경과 필요한 조건을 남긴다.
반복 지적은 짧은 리뷰 지침으로 옮긴다
공식 글은 프로젝트 공통 맥락을 적는 CLAUDE.md와 코드 소유자가 검토 기준을 적는 REVIEW.md를 구분한다. 지적에는 파일과 위치 같은 근거를 요구하고, 반복되는 문제는 지침이나 자동 검사에 반영한다. 원문: 검토 기준을 관리하는 방법
작은 팀이라면 내보내기 모듈의 리뷰 지침을 이렇게 시작할 수 있다.
반복해서 같은 오류가 나온다면 문서에만 쌓지 말고 회귀 테스트나 린트로 옮길 수 있는지 본다. 팀이 실제로 겪은 문제부터 넣으면 지침이 길어지는 것도 막을 수 있다.
리뷰가 끝없이 돌면 접근을 다시 본다
작성 AI와 검토 AI가 서로 수정을 요구하다 보면 변경이 계속 커질 수 있다. 공식 글은 리뷰 반복 횟수에 상한을 두고, 몇 차례 뒤에는 새 diff를 중심으로 재검토하는 방법을 소개한다. AI의 승인을 필수 사람 승인으로 세지 않는다는 경계도 명시한다. Anthropic 개발 글
팀에 맞는 중단 기준을 정하자. 예를 들어 같은 유형의 지적이 다시 나오면 관련 사례 전체를 한 번에 확인하고, 새 요구사항이 생기면 별도 작업으로 뺀다. “한 번 더 리뷰”를 자동으로 되풀이하기 전에 무엇이 새로 바뀌었는지부터 묻는다.
실전 활용 팁: 다음 PR 한 개로 시험하기
새 제품을 도입하거나 승인 규칙을 바꾸기 전에, 다음 작은 변경 하나에 아래 세 칸을 추가해 보자.
- 위험: 틀렸을 때 영향을 받는 사용자와 데이터.
- 검증: 실행한 검사·실제 결과·확인하지 못한 조건.
- 복구: 되돌릴 변경·남는 데이터 영향·담당자.
병합 후에는 검토 대기 시간만 보지 말고 수정 요청과 되돌림, 운영 문제도 같이 남긴다. 리뷰 시간이 줄어도 장애 대응이 늘었다면 일이 다른 곳으로 이동했을 수 있다. 서로 다른 PR 몇 개의 숫자만으로 자동화가 품질을 높였다고 단정하지 않는다.
다음 리뷰에서는 코드를 읽기 전에 변경의 위험 한 문장과 검증 결과부터 확인해 보자. 근거가 모자라면 필요한 검사를 추가하고, 영향이 크면 담당자의 판단을 받는다. 작은 팀이 먼저 얻을 것은 무엇을 확인하고 병합했는지 다시 설명할 수 있는 기록이다. 지금 검토 중인 PR에는 위험과 검증, 복구 방법이 남아 있는가?
참고 자료
- GeekNews, 「Claude Code 팀의 코드 리뷰 방식」 · 관련 읽을거리
- Anthropic 개발진, How the Claude Code team does code review · 원문 표기 2026-10-15
2026-10-17 확인. 이 글의 CSV 예시와 소규모 팀 적용 절차는 프랜디어의 제안이며, 특정 도구 도입이나 검토 인원 축소의 효과를 보장하지 않는다.