AI에게 코드 리뷰를 시키면, 대개 「전체적으로 잘 작성되었습니다. 몇 가지 개선점으로…」라는 균형 잡힌, 무난한 리포트가 돌아옵니다. 우리는 이것을 버렸습니다.

Web 서비스 개발 리포지토리(coelia-system: 이벤트 예약·LINE 연동·가차 등)의 ADR 0082 「모든 리뷰 계열 스킬의 검증 작법을 적대적 검증(Adversarial Verification)으로 통일」에서, 십수 종류에 달하는 리뷰 계열 스킬 모두에 동일한 작법을 강제한 이야기와, 그 후 이 체제가 실제로 잡아낸 버그의 기록입니다.

적대적 검증의 3가지 규칙

리뷰 계열 스킬 전부(아키텍처 리뷰·보안·성능·신뢰성·관리 화면 리뷰 등)에 다음 3가지를 추가했습니다.

회의적인 입장: 작성자의 구현 의도를 전제로 하지 않는다. 「작성자 관점에서 판정하지 않는다」 -
반증 지향·실패 시나리오 필수: 지적은 「어떤 입력·상태에서 무너지는가」로 나타낸다. 시나리오화할 수 없는 우려는 「확인 필요」로 강등 -
좋은 점은 언급하지 않는다: OK 판정은 「반증을 시도했으나 무너뜨리지 못했다」의 기록으로서 작성

세 번째가 가장 논란이 되는 부분입니다만, 이유는 단순합니다. 좋은 점을 나열하는 것은 리뷰의 목적(결함 검출)에 1밀리도 기여하지 않으며, 토큰과 주의력을 분산시킬 뿐이기 때문입니다. 「문제 없음」의 건전성은 칭찬이 아니라 「어떤 관점에서 반증을 시도하여 OK/N/A였는지」를 명기함으로써 전달합니다.

도입 직후부터 커밋 메시지 헤더에 「적대적 검증의 지적(Bug 3건／Spec 2건)을 수정함」과 같은 형태가 늘어나기 시작했습니다. 「순수 리뷰」 시대에는 간과되었던 종류의 로직 결함이, 반증 모드에서는 구체적인 실패 시나리오와 함께 올라옵니다.

「작성자 본인이 다시 읽기」는 더블 체크가 아니다

또 다른 기둥은 체커의 독립성입니다. 운용 규칙의 근간이 되는 문서에 이렇게 적혀 있습니다.

「작성자 본인이 스스로 다시 읽는 것」은 더블 체크가 아니다. 분리의 목적은 효율이 아니라 **「자신의 출력을 스스로 긍정해 버리는 구조를 끊는 것」**이므로 비용 문제로 생략하지 않는다.

구체적으로는, 공개 PR·메모리 업데이트·브랜드와 관련된 성과물은 머지(Merge) 전에 만든 당사자와는 다른 fresh context의 서브 에이전트(대상별로 7종의 체커 정의가 있음)를 거칩니다. 체커가 이용 한도나 장애로 기동할 수 없을 때는 어떻게 할까요? 이전에는 「셀프 리뷰로 전환」이라는 규칙이었으나, 이는 폐지되었습니다. 지금은 기동될 때까지 공개·머지를 중단하거나, 다른 엔진(Claude ⇔ Codex)의 체커로 넘깁니다. 셀프 리뷰로 대체하는 것은 인정하지 않는다는 것이 명문 규칙입니다.

독립 체커가 실질적인 피해를 막은 사례 2가지

사례 1: 반대되는 결론이 근간 문서에 기록되기 직전에 중단됨

서브 에이전트의 모델 해결 우선순위(환경 변수 vs 호출 인자 vs 정의 파일)를 조사한 세션이, CLI 번들에서 함수를 하나만 읽고 「명시적 지정은 환경 변수보다 강하다」라는 결론을 내어, 운용 규칙의 근간인 3개 파일에 쓰기 직전까지 갔습니다. 실제로는 반대(환경 변수가 최우선)였으며, 읽었던 것은 세션 측의 해결 함수였고, 서브 에이전트 경로는 별개의 함수였습니다.

이를 막은 것이 머지 전의 독립 체커입니다. 리뷰 기록에는 이렇게 적혀 있습니다: 「독립 체커가 반증해 주었기에 실질적인 피해는 제로로 끝났다 = 머지 전 더블 체크가 기능한 사례」. 만약 통과되었다면, 이후의 모델 라우팅 설계가 모두 잘못된 전제 위에 쌓였을 것입니다.

사례 2: 다른 엔진의 리뷰가 GA4의 36자 제한을 검출

A/B 테스트 기반 개수 PR을 Claude로 구현 → Codex 측의 자동 리뷰로 체크한 결과, 「GA4의 사용자 속성(User Property) 값은 36자 제한. 여러 실험의 할당을 합친 실험 ID는 기존 2개 실험만으로도 56자 = 잘려 나가며, 주요 판정 지표가 망가진다」라는 결함이 검출되었습니다.

질이 나쁜 점은, 망가지는 것이 유저 스코프(User Scope) 측뿐이라 이벤트 스코프(Event Scope)의 숫자는 살아남기 때문에 실행해 봐도 알아채기 어렵다는 것입니다. 검출 후 재발 방지책도 세트로, 「실험 ID는 33자 이내」가 테스트 코드에 반영되었습니다. 주의력에 의존하지 않고, 상한이 판명되면 테스트로 옮긴다.

지적으로 끝내지 않는다: 학습의 사다리

적대적 검증을 계속 돌리다 보면 지적 로그가 쌓입니다. 이를 방치하지 않고, 4단계의 「사다리」를 통해 운반합니다.

실제로 ③단계까지 올라간 사례: 이전 세션에서 문서의 절(Section) 이름 참조가 끊기는 것을 탐지하는 스크립트를 새로 만들었더니, 다음 세션에서 절을 이동한 순간 7건의 참조 끊김을 즉시 감지. 그중 3건은 무인 루틴의 운영 절차로, 방치했다면 조용히 망가졌을 종류의 문제였습니다. 인간 체크 → AI 체크 → 기계 체크로, 동일한 관점이 점점 더 저렴한 레이어로 내려갑니다.

비용에 관한 이야기

솔직히 말하면, 적대적 검증 (Adversarial Verification)은 공짜가 아닙니다. 운영 문서에도 "토큰을 3~10배 소비할 수 있다"라고 적혀 있으며, 그렇기에 적용 대상을 좁힙니다.

반드시 수행: 머지(Merge)·공개로 향하는 결과물, 근간이 되는 문서의 업데이트, 아키텍처(Arch) 판단
수행하지 않음: 내부의 중간 반복 (매 이터레이션마다 체커를 세우면 비용만 증가)
계층화: 1차 체크는 실행 모델(Execution-tier model), 공개 판정·근간 문서의 통합 등 고스코프(High-scope)의 최종 검수만 사령탑 모델(Command-tier model)

판별 기준 중 마음에 드는 한 문장이 있습니다: "그 공정이 '같은 관점에서 다시 보는 것'이라면 제외한다. '다른 입장·다른 정보원으로 보는 것'이라면 남긴다." 최신 모델은 자기 검증 (Self-verification)을 기본적으로 수행하므로, 같은 관점의 재확인을 지시하는 것은 낭비입니다. 가치가 있는 것은 관점의 독립성뿐입니다.

요약

리뷰의 품질은 리뷰어의 똑똑함보다 구조 (독립성·반증·기계화로의 출구)에 의해 결정된다는 것이 수백 개의 PR을 돌리며 얻은 실감입니다.

커뮤니티 운영과 커리어 설계에 관한 발신은 obata-tomu.jp/articles 에서 확인하실 수 있습니다.

Discussion