AI Agent가 짠 코드, 7단계 검증 파이프라인으로 해결하기

요즘 이 주제가 가장 뜨겁다. Agent가 하루에 수백 개 커밋을 쏟아내는데 그걸 누가 다 리뷰하느냐는 거다.

오픈클로 개발자 Peter의 하루 커밋은 3,000회가 넘는 날도 있다. 인간의 범위를 아득히 넘은 양이다. 이제 인간만으로는 진행할 수 없는 일이 되어버렸다.

처음엔 방법이 없다고 생각했다. Ryan Carson의 “Code Factory”를 읽고 나서 윤곽이 잡혔다. 사람이 읽는 걸 포기하는 대신 기계가 검증할 수 있는 구조를 세우는 것이다.

Merge 규칙을 JSON 하나로 잡아둔다

어떤 경로가 위험하고 어떤 체크를 통과해야 하는지 파일 하나에 다 적어둔다. 핵심은 문서와 스크립트가 따로 노는 걸 원천 차단한다는 점이다.

• 고위험 경로는 Review Agent + 브라우저 증거까지 필요
• 저위험 경로는 policy gate와 CI만 통과하면 Merge 가능

CI 돌리기 전에 자격 검사부터 한다

리뷰도 안 끝난 PR에 빌드를 돌리면 돈만 날아간다. risk-policy-gate를 CI fanout 앞에 세워두는 구조다. 이것만으로도 불필요한 CI 비용이 꽤 줄어든다.

• policy gate → Review Agent 확인 → CI fanout 순서 고정
• 자격 미달 PR은 test/build에 진입조차 못 함

낡은 커밋 기준 “통과”는 믿으면 안 된다

Carson이 가장 크게 강조한 부분이다. 예전 커밋에서 받은 “통과”가 남아 있으면 최신 코드가 검증 없이 Merge된다. Push할 때마다 리뷰를 다시 돌리고, 안 맞으면 gate가 막아야 한다.

• Review Check Run이 headSha와 매칭될 때만 유효
• synchronize 이벤트마다 Rerun 강제

Rerun 요청은 딱 한 곳에서만 보낸다

여러 워크플로가 Rerun을 요청하면 코멘트가 중복으로 달리고 Race Condition이 생긴다. 별거 아닌 것 같지만 이걸 안 잡으면 파이프라인 전체가 흔들린다.

• Marker + sha:headSha로 중복 방지
• 이미 요청한 SHA면 그냥 넘어감

수정까지 Agent가 알아서 한다

Review Agent가 문제를 찾으면 Coding Agent가 패치해서 같은 브랜치에 Push하는 구조다. 가장 날카로운 포인트는 모델 버전을 고정하라는 부분이다. 안 그러면 매번 다른 결과가 나와서 재현이 안 된다.

• Codex Action이 수정 → Push → Rerun Trigger
• 모델 버전 고정으로 재현성 확보

봇끼리 한 대화만 자동으로 닫는다

사람이 참여한 스레드는 절대 건드리지 않는다. 이 구분이 없으면 리뷰어가 남긴 의견이 묻혀버린다.

• clean current-head Rerun 이후에만 auto-resolve
• 사람이 쓴 스레드는 무조건 열어둠

눈에 보이는 증거를 남겨야 한다

UI를 바꿨으면 스크린샷 말고 CI에서 검증 가능한 증거를 요구한다. 프로덕션에서 터진 문제는 테스트 케이스로 바꿔서 같은 사고가 반복되지 않게 만든다.

• regression → harness gap issue → 테스트 케이스 추가 → SLA 추적

Carson이 선택한 도구

참고로 Carson이 선택한 도구 구성이다. 코드 리뷰 에이전트로는 Greptile, 수정 에이전트로는 Codex Action을 선택했으며, 세 가지 워크플로 파일이 핵심 역할을 담당한다 greptile-rerun.yml은 표준 Rerun, greptile-auto-resolve-threads.yml은 오래된 스레드 정리, risk-policy-gate.yml은 사전 검증 정책을 처리한다.

정합성을 넘어서: 시각적 검증

여기까지가 “코드가 맞는지 틀리는지”를 잡는 구조다. 그런데 실무에서 한 발 더 나가면 결과물이 눈에 어떻게 보이는지까지 검증해야 한다.

두 가지 접근 방식이 눈에 띈다.

Nico Bailon의 visual-explainer는 터미널 Diff를 ASCII 대신 HTML 페이지로 렌더링해서 변경 내역을 한눈에 파악할 수 있게 해준다.

Chris Tate의 agent-browser는 방향이 다르다. 실제 브라우저 화면을 픽셀로 비교해서 CSS나 레이아웃 깨짐을 잡아낸다. bisect와 결합하면 어떤 커밋에서 깨졌는지까지 특정할 수 있다.

나도 codexBridge를 만들면서 이 부분을 고민하고 있다. 어떤 Agent가 어떤 코드를 만들었는지 추적하려면 세션 로그를 남기는 것만으로는 부족하고, 쉽게 꺼내 쓸 수 있는 검색 구조가 필요하다.

결론

“Agent가 짠 코드를 누가 검증하냐”는 질문에 대한 답은 사람이 아니다. 기계가 남긴 증거를 기계가 판단하는 구조. 그게 답이다.