AI 코드 리뷰 워크플로우: 누가 수정하고 누가 재검토해야 하나

AI가 구현과 리뷰를 모두 맡을 때 중요한 건 에이전트 수보다 발견·수정·합격 판정의 역할을 분리하는 것이다. 같은 리뷰 대화를 이어갈 때와 새 리뷰를 열 때의 기준까지 정리했다.

TL;DR

일반적인 작업의 기본값은 아래 구조다.

구현 AI A
  ↓ 구현·테스트
리뷰 AI B
  ↓ DiffComment로 문제만 기록
구현 AI A
  ↓ GetDiffComments로 읽고 수정·테스트
같은 리뷰 AI B, 같은 대화
  ↓ 자기 댓글이 실제로 해결됐는지 재검증
테스트·CI·사용자
  ↓ 댓글 Resolve 및 최종 머지 판단

• 수정은 구현 AI A에게 맡긴다. 설계 의도와 작업 맥락을 가장 잘 안다.
• 수정의 합격 판정은 리뷰 AI B에게 맡긴다. 작성자의 가정과 사각지대를 분리한다.
• 기존 댓글의 해결 여부를 볼 때는 같은 B의 같은 대화를 이어간다.
• 전체 diff를 처음부터 재감사할 때만 새 리뷰 대화 C를 연다.
• 보안·결제·데이터처럼 고위험 변경은 B 재검증 + C 독립 리뷰를 모두 한다.

왜 A가 수정하고 B가 판정하나

구현 AI에게 최종 판단까지 맡기면 자신이 코드를 쓸 때 사용한 가정과 사각지대를 그대로 유지하기 쉽다. 그렇다고 리뷰 AI가 발견부터 수정, 검증까지 모두 하면 이번에는 리뷰 AI가 자기 수정의 작성자가 된다.

휴먼 개발의 코드 리뷰도 보통 같다. 작성자가 댓글을 반영하고, 처음 댓글을 남긴 리뷰어가 Resolve 여부를 판단한다. AI 워크플로우도 구현 책임과 승인 책임을 나누는 것이 핵심이다.

1. 독립 리뷰 AI B에게 발견만 맡기기

B는 코드를 직접 고치지 않는다. 수정까지 맡기면 발견자와 작성자의 역할이 섞인다.

현재 workspace의 origin/main 대비 전체 diff를 검토해주세요.
요구사항과 저장소 규칙을 기준으로 실제 버그, 회귀,
보안·데이터 손상 위험, 빠진 테스트를 찾아주세요.
각 발견 사항은 재현 조건과 영향을 확인한 뒤 DiffComment로 남겨주세요.
추측성 의견, 스타일 취향, 근거 없는 가능성은 댓글로 남기지 마세요.
코드는 직접 수정하지 말고 발견 사항만 기록해주세요.

2. 구현 AI A에게 리뷰 수정 맡기기

A는 댓글을 무조건 수용해서도, 자기 구현을 무조건 방어해서도 안 된다. 그래서 틀린 댓글이라면 근거를 대라는 문장이 중요하다.

GetDiffComments로 활성 리뷰 댓글을 모두 읽어주세요.
각 댓글이 지적한 문제를 현재 코드에서 직접 확인한 다음,
타당한 댓글은 기존 설계를 유지하며 최소 범위로 수정해주세요.
관련 회귀 테스트를 추가하거나 실행하고 결과를 확인해주세요.
댓글이 잘못됐다고 판단되면 조용히 무시하지 말고,
근거가 되는 코드 경로, 실행 조건, 테스트 결과를 설명해주세요.
마지막에 변경 파일, 테스트 결과,
각 댓글을 어떻게 처리했는지 댓글별로 정리해주세요.

3. 같은 리뷰 AI B에게 재검증시키기

목적이 기존 댓글이 제대로 해결됐는지 확인하는 것이라면 첫 리뷰를 했던 B의 같은 대화를 이어가는 편이 좋다. B가 문제라고 판단한 이유, 재현 조건, 기대 동작을 이미 알고 있기 때문이다.

구현 AI가 리뷰 댓글을 반영해 수정했습니다.
GetDiffComments로 현재 활성 댓글을 읽고,
최신 workspace 코드와 diff를 다시 확인해주세요.
각 기존 댓글이 실제로 해결됐는지 재현 조건 기준으로 검증하고,
수정으로 인해 새 회귀가 생기지 않았는지도 확인해주세요.
코드는 직접 수정하지 마세요.
해결되지 않은 문제나 새로 발견된 문제만 DiffComment로 남기고,
기존 댓글과 중복되는 댓글은 만들지 마세요.
마지막에 각 기존 댓글을 해결됨/미해결로 정리해주세요.

AI가 GetDiffComments로 댓글을 읽을 수만 있고 Resolve 권한은 없다면, B의 판정과 테스트 결과를 확인한 뒤 사용자가 직접 Resolve한다.

언제 새 리뷰 대화 C를 여나

목적이 현재 전체 diff를 처음 보는 사람처럼 다시 검토하는 것이라면 새 대화가 낫다. 기존 리뷰어의 결론과 수정 방향에 끌려가지 않는 독립 감사가 되기 때문이다.

현재 workspace의 origin/main 대비 전체 diff를
처음 보는 독립 리뷰어처럼 검토해주세요.
먼저 GetDiffComments로 기존 활성 댓글을 읽어
동일한 문제를 중복 등록하지 않도록 해주세요.
기존 리뷰의 결론은 그대로 신뢰하지 말고,
현재 코드에서 실제로 재현되거나 증명되는 버그만 DiffComment로 남겨주세요.
코드는 수정하지 마세요.

리뷰 AI가 직접 수정해도 되는 예외

원래 구현 AI가 같은 문제를 이미 잘못 고쳤거나, 설계 자체가 틀렸거나, 리뷰를 근거 없이 반복해서 부정할 때는 B 또는 별도 수정 AI가 고치는 편이 낫다.

단, B가 코드를 고친 순간 B는 독립 리뷰어가 아니라 구현자가 된다. 이때는 새 리뷰 AI C가 B의 수정을 검증해야 한다.

A 구현 → B 리뷰·수정 → 새 리뷰 AI C 검증 → 테스트·CI → 사용자 판단

함정

• A가 수정 후 스스로 댓글을 닫음 → 작성자와 승인자가 같음 → B가 해결 여부를 판정한다.
• B가 직접 고치고 다시 승인함 → 독립성이 사라짐 → 새 리뷰 AI C를 붙인다.
• 매번 새 리뷰를 엶 → 비용과 중복 댓글이 늘어남 → 댓글 검증은 같은 B, 전체 재감사만 C에게 맡긴다.
• 리뷰 댓글을 전부 정답으로 취급함 → 오탐이 구현을 왜곡함 → A가 코드·실행·테스트 근거로 타당성을 먼저 확인한다.
• AI 판정만으로 끝냄 → 실행 환경의 진실을 놓침 → 테스트·CI 결과와 사용자의 머지 판단을 마지막 관문으로 둔다.

배운 것

• 가장 실용적인 기본값은 A가 구현·수정하고, 같은 B가 리뷰·재검증하는 것이다.
• 같은 대화는 기존 댓글을 닫는 데 강하고, 새 대화는 전체 diff의 독립 재감사에 강하다.
• 최종 신뢰는 AI 한 명의 확신이 아니라 역할 분리 + 테스트·CI + 사용자 판단에서 나온다.