코드를 만든 AI에게 같은 대화에서 “문제없는지 봐 달라”고 하면 작성 때의 결론과 가정을 그대로 이어받는다. 다른 모델을 불러도 작성자의 요약과 자신감까지 복사해 주면 독립 검토가 되기 어렵다. 역할을 나누려면 대화가 아니라 검토 가능한 산출물을 넘기고, 작성자와 리뷰어가 서로의 판정 권한을 갖지 못하게 해야 한다.
다중 에이전트가 결함 후보를 찾고 검증하는 구조는 이 시리즈의 010번 글에서 다뤘다. 여기서는 한 변경이 작성 세션에서 검토 세션으로 넘어갈 때 필요한 경계와 상태 전이에 집중한다.
1. 작성 대화 대신 검토 패킷을 넘긴다
작성 작업이 끝나면 새 세션을 열고 아래 정보만 리뷰어에게 준다.
- 기준·머리 커밋 SHA와 실제 diff.
- 요구 사항과 사용자의 완료 조건.
- 변경 파일, 통과한 검사와 실패·미실행 항목.
- 금지 영역과 이번 변경의 제외 범위.
- 작성자가 확신하지 못한 가정.
“문제없이 구현했다” 같은 작성자의 판정은 뺀다. 리뷰어는 패킷과 저장소에서 사실을 다시 확인한다. 검토 중 머리 SHA가 바뀌면 결과를 최신 변경에 재사용하지 않고 새 검토로 시작한다.
2. 두 역할의 권한을 교차시키지 않는다
작성 AI는 지정한 파일과 테스트를 수정할 수 있지만 자기 변경을 승인하거나 지적을 닫지 못한다. 리뷰 AI는 기본적으로 읽기와 검사 실행만 하며 제품 코드를 직접 고치지 않는다. 재현 코드가 필요하면 임시 디렉터리나 분리된 작업 공간에 만들고 대상 브랜치는 건드리지 않는다.
리뷰어는 정확성·보안·데이터 손실·경합·호환성처럼 새 결함만 보고한다. 각 결과에는 파일과 줄, 발생 조건, 호출 경로, 영향, 심각도와 재현 증거가 필요하다. 스타일 취향과 기존 결함은 현재 머지 차단 신호에서 분리한다.
3. 결제 웹훅으로 핸드오프를 연습한다
가령 요구 사항이 “같은 결제 이벤트가 두 번 와도 주문은 한 번만 확정한다”라고 하자. 작성 AI는 중복 방지 로직과 단위 테스트를 만들고 검사 결과를 패킷에 적는다. 리뷰 AI에는 작성 과정 대신 요구 사항과 diff를 준다.
리뷰어는 같은 이벤트의 동시 요청, 외부 결제 성공 뒤 응답 유실과 재시도, 중복 키 저장 실패를 각각 재현한다. “중복 결제 가능”이라는 문장만으로는 부족하다. 어떤 순서에서 두 번째 처리로 들어가는지와 실패 테스트가 있어야 CONFIRMED가 된다. 증거가 없으면 NEEDS_EVIDENCE로 남긴다.
4. 지적 상태를 수정과 재검토에 연결한다
새 지적은 OPEN에서 시작한다. 리뷰어는 증거에 따라 CONFIRMED, NEEDS_EVIDENCE, REJECTED, OUT_OF_SCOPE로 분류한다. NEEDS_EVIDENCE에 새 증거가 들어오면 OPEN으로 돌려 다시 판정한다. 범위 밖 피드백은 원래 댓글을 연결한 별도 이슈로 보낸다. GitHub의 권장 흐름은 리뷰 해결 공식 가이드에서 확인할 수 있다.
작성자가 고치면 상태는 완료가 아니라 FIXED_PENDING_REVIEW다. 리뷰어가 최신 머리 SHA에서 원래 재현 절차와 회귀 검사를 다시 실행해 통과를 확인한 뒤에만 VERIFIED_FIXED로 닫는다. 실패하면 REOPENED로 보내고, 재수정 뒤에는 다시 FIXED_PENDING_REVIEW로 돌린다. 재검토에서 발견한 새 회귀는 기존 지적을 재개하지 않고 별도 OPEN으로 만든다.
NOT_RUN은 지적의 상태가 아니라 리뷰 실행 기록이다. 아직 리뷰를 실행하지 않았다면 실행 상태에 NOT_RUN을 남기고, 실제 지적의 생명주기와 섞지 않는다. 작성자와 리뷰어가 각자 바꿀 수 있는 상태를 제한하면 셀프 승인을 막을 수 있다.
5. 사람과 저장소 규칙이 머지를 결정한다
AI 리뷰는 보조 검토다. GitHub도 Copilot이 모든 문제를 찾는다고 보장하지 않으며, 피드백을 확인하고 사람 리뷰로 보완하라고 명시한다. 한계는 Copilot Code Review 공식 안내에서 확인한다.
보안·결제·권한·데이터 경로에는 사람 소유자를 배정한다. GitHub CODEOWNERS는 경로별 개인이나 팀을 지정하고, 보호 규칙과 결합해 코드 소유자의 승인을 머지 조건으로 만들 수 있다. 설정 기준은 CODEOWNERS 공식 문서에서 확인한다.
좋은 역할 분담은 AI 둘이 동의하게 만드는 절차가 아니다. 작성 대화에서 독립된 패킷을 만들고, 권한을 나누며, 재현 증거와 최신 SHA로만 지적을 닫게 만드는 절차다.