코딩 에이전트 검수 체계: 자체 검수, 기계 검사, 별도 검수자 나누기

🤔 에이전트가 늘어나자 검수가 병목이 될 때

코딩 에이전트를 여러 개 돌리기 시작하면 만드는 속도는 빨라지는데 확인하는 속도가 따라가지 못합니다. 하루에 변경 요청이 열 건씩 올라오니 사람이 전부 한 줄씩 읽을 수는 없고, 그렇다고 "테스트 통과했습니다"라는 보고만 믿고 합치면 며칠 뒤에 다른 곳이 깨집니다. 확인 단계가 한 사람에게 몰려 있으면 에이전트를 늘릴수록 병목이 심해집니다.

이 병목은 검수를 한 단계가 아니라 여러 단계로 나눠 풀 수 있습니다. 싸고 빠른 검사로 먼저 거르고, 판단이 필요한 것만 다음 단계로 넘기는 구조입니다. 자기 결과물을 후하게 평가하는 이유와 평가 용어는 에이전트 검수와 평가에서 다뤘고, 이 편에서는 실제로 검수 단계를 어떤 순서로 짜고 각 단계에 무엇을 맡길지를 다룹니다.

🔑 코딩 에이전트 검수 체계의 정의

코딩 에이전트 검수 체계는 에이전트가 만든 변경을 작성자 자체 확인, 기계 검사, 별도 검수자, 사람의 최종 확인 순서로 거르도록 역할을 나눠 둔 구조입니다.

공항 보안 검색에 비유하면 이해가 쉽습니다. 모든 가방은 예외 없이 X선 장비를 지나고, 장비가 이상을 표시한 가방만 사람이 열어 봅니다. 장비는 싸고 빠르고 늘 같은 기준으로 판정하며, 사람은 장비가 걸러 낸 것에만 시간을 씁니다. 검수 체계도 같은 원리로 단계를 쌓습니다.

🪜 네 단계가 맡는 일

1단계는 비용이 거의 들지 않지만 믿을 만하지 않습니다. 작성자는 자기 결과를 좋게 보는 경향이 있고, 테스트를 고쳐 통과시킨 경우도 스스로는 문제로 여기지 않을 수 있습니다. 그래서 1단계의 역할은 판정이 아니라 증거 수집입니다. 작업 명세에 적은 명령을 돌리고 출력과 바꾼 파일 목록을 보고하게 합니다.

2단계가 체계의 중심입니다. 클로드 코드 모범 사례 문서는 테스트나 빌드, 화면 캡처처럼 에이전트가 돌려 볼 수 있는 확인 수단이 없으면 끝나 보인다는 인상만 남는다고 설명합니다. 기계 검사는 같은 입력에 늘 같은 판정을 내리므로, 규칙으로 적을 수 있는 것은 모두 이 단계로 옮기는 편이 낫습니다. 어떤 검사가 반드시 돌아야 한다면 에이전트의 판단에 맡기지 않고 훅이나 CI처럼 정해진 시점에 강제로 돌게 합니다.

3단계는 규칙으로 적기 어려운 것을 봅니다. 명세의 의도와 구현이 맞는지, 소유 범위 밖의 파일을 건드리지 않았는지, 테스트나 명세 문서가 함께 바뀌지 않았는지입니다.

4단계는 되돌리기 어려운 것만 봅니다. 배포, 데이터 삭제, 권한 변경, 구조를 바꾸는 결정입니다. 앞의 세 단계가 걸러 낸 목록이 있으면 사람은 전체를 다시 읽지 않고 그 목록부터 봅니다.

🔍 별도 검수자에게 줄 것과 주지 않을 것

검수자를 따로 두는 이유는 새 눈으로 보게 하려는 것입니다. 클로드 코드 모범 사례 문서는 새 컨텍스트가 코드 리뷰를 개선한다며, 방금 쓴 코드에 치우치지 않기 때문이라고 설명합니다. 검수자 서브에이전트는 변경 내역과 사람이 준 기준만 보고 그 변경을 만든 추론 과정은 보지 않는다는 점을 장점으로 들었습니다.

같은 문서에 검수자를 둘 때의 함정도 적혀 있습니다. 문제를 찾으라고 지시받은 검수자는 작업이 멀쩡해도 대개 무언가를 보고한다는 것입니다. 그래서 정확성이나 요구사항에 영향을 주는 문제만 짚으라고 범위를 좁혀 지시합니다. 그렇지 않으면 사소한 취향 지적이 쌓여 사람이 볼 목록이 오히려 길어집니다.

검수자에게 파일을 고칠 권한을 주지 않는 것도 중요합니다. 검수자가 직접 고치면 누가 무엇을 바꿨는지 추적하기 어려워지고, 고친 부분은 다시 검수를 받지 않은 채 남습니다. 검수자는 목록만 내고, 고치는 일은 작성자에게 되돌려 보냅니다.

🧪 전용 리뷰 도구가 보여 준 구조와 수치

범용 에이전트에게 말로 리뷰를 맡기는 방식의 약점을 구조로 푼 사례가 있습니다. 알리바바가 사내에서 쓰다 2026년 5월 공개한 Open Code Review는 어떤 파일을 봐야 하는지, 관련 파일을 어떻게 묶는지, 어느 규칙을 붙이는지는 코드로 고정하고, 상황에 따라 달라지는 판단만 모델에 맡깁니다. 지적한 위치가 맞는지도 별도 모듈이 다시 확인합니다. 체계의 2단계와 3단계를 한 도구 안에 나눠 넣은 셈입니다.

알리바바가 공개한 자체 벤치마크 수치는 전용 도구와 범용 에이전트의 성격 차이를 보여 줍니다. 같은 모델을 쓴 조합의 결과입니다.

정밀도는 지적한 항목 가운데 실제 결함의 비율이고, 재현율은 실제 결함 가운데 찾아낸 비율입니다. 전용 도구는 지적의 적중률이 높고 빠르지만, 범용 에이전트는 결함을 더 많이 찾습니다. 두 조합 모두 F1이 30%를 넘지 않았다는 점이 더 중요합니다. 자동 검수는 사람이 볼 양을 줄이는 단계이지 사람의 검토를 대신하는 단계가 아닙니다. 이 수치는 도구를 만든 쪽이 측정한 값이고 제3자의 재현 결과는 아직 공개되지 않았습니다. 도구의 세부는 Open Code Review 사용법에 있습니다.

🧭 검수 체계를 짜는 순서

1. 완료 증거 명령부터 정합니다: 작성자가 돌리고 검수자가 다시 돌릴 명령이 같아야 결과를 비교할 수 있습니다
2. 규칙으로 적을 수 있는 것을 기계 검사로 옮깁니다: 코드 스타일, 타입, 금지 표현, 파일 크기처럼 판정이 분명한 것은 검사 스크립트로 만듭니다
3. 검수자의 기준 문서를 씁니다: 명세와 함께 이 프로젝트에서 특히 조심할 점을 적어 둡니다. 같은 실수가 두 번 나오면 한 줄씩 늘립니다
4. 사람이 볼 곳을 정합니다: 되돌리기 어려운 변경의 종류를 적어 두고, 그 종류만 사람의 승인을 거치게 합니다

검수 단계를 넣으면 토큰과 시간이 더 듭니다. 클로드 코드 비용 문서는 서브에이전트의 요청도 사용량에서 빠진다고 적고 있어서, 검수자 한 명을 붙일 때마다 그만큼 사용량이 늘어납니다. 잘못된 변경을 합친 뒤 되돌리는 비용과 비교해 검수의 깊이를 정합니다.

⚠️ 검수 체계를 운영할 때 자주 하는 실수

• 검수자에게 대화를 통째로 넘깁니다: 작성자의 가정을 그대로 물려받아 같은 잘못을 놓칩니다
• 검수자가 직접 고치게 둡니다: 고친 부분이 다시 검수를 받지 않고 남습니다
• 규칙으로 판정할 수 있는 것을 모델에게 묻습니다: 테스트 한 번이면 끝날 확인을 검수자에게 맡기면 비싸고 판정도 매번 달라질 수 있습니다
• 모든 변경을 사람이 봅니다: 사람이 병목이 됩니다. 사람은 되돌리기 어려운 변경과 앞 단계가 걸러 낸 목록에 집중합니다

❓ 자주 묻는 질문

검수자는 같은 모델이어도 되나요?

새 컨텍스트로 분리하기만 해도 작성 과정의 가정이 끼어드는 것을 막는 효과가 있습니다. 다만 모델이 같으면 자기 문장을 익숙하게 여기는 성질은 남으므로, 되돌리기 어려운 변경이라면 다른 모델로 한 번 더 대조하는 편이 낫습니다.

검수자를 여러 명 두면 더 좋은가요?

관점이 다른 검수자를 둘 두는 것은 도움이 되지만, 같은 지시를 받은 검수자를 여럿 두면 비슷한 지적이 반복되고 비용만 늘어납니다. 하나는 요구사항과의 일치, 하나는 보안처럼 기준을 나눠 주는 편이 쓸모가 있습니다.

작은 수정에도 네 단계를 다 거쳐야 하나요?

기계 검사는 늘 돌리고, 별도 검수자와 사람의 확인은 변경의 위험도에 따라 붙입니다. 문구 하나를 고친 변경과 인증 로직을 바꾼 변경을 같은 깊이로 검수하면 정작 위험한 쪽에 쓸 시간이 줄어듭니다.

📋 3줄 요약

1. 코딩 에이전트 검수 체계는 에이전트가 만든 변경을 작성자 자체 확인과 기계 검사, 별도 검수자, 사람의 최종 확인 순서로 거르도록 역할을 나눠 둔 구조입니다.

2. 테스트와 린터처럼 싸고 판정이 일정한 기계 검사를 앞에 두고, 새 컨텍스트의 검수자에게는 변경 내역과 판정 기준만 주어 정확성과 요구사항에 영향을 주는 문제만 짚게 합니다.

3. 알리바바가 공개한 전용 리뷰 도구도 자체 벤치마크 F1이 25.10%에 그쳤으므로 자동 검수는 사람이 볼 양을 줄이는 단계로 두고 되돌리기 어려운 변경은 사람이 최종 승인합니다.

📚 참고 자료

• 클로드 코드 문서, Best practices: https://code.claude.com/docs/en/best-practices
• 클로드 코드 문서, Manage costs: https://code.claude.com/docs/en/costs
• 알리바바, Open Code Review 저장소: https://github.com/alibaba/open-code-review
• 앤트로픽, Demystifying evals for AI agents: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents