서브에이전트 53개를 띄운 최종 검수가 버그 후보 25개를 냈고, 그중 확정된 것은 1건이었다.
10월에 계획 리뷰를 재 보니 Opus 단독 리뷰는 결함을 찾아 놓고도 게이트를 열어 주고 있었다.
계획 리뷰에서는 리뷰어를 늘리는 것보다 판정을 리뷰어 손에서 떼어 내는 쪽이 결과를 바꿨다.
문제
리뷰 스킬은 한 줄로 이어져 있다.
9월 23일에 결과 검수 스킬 final-review, 9월 27일에 지휘 스킬 super-orchestration, 10월 6일에 계획 리뷰 스킬 plan-review를 넣었다.
10월 8일에는 지휘 스킬을 super-auto로 바꿔 이슈 정리부터 머지까지 맡겼다.
지휘 스킬은 워커 여럿에게 구현을 맡기고, 그 앞뒤에 에이전트 리뷰어를 세운다.
구현 전에는 plan-review가 계획을, 구현 뒤에는 final-review가 결과를 본다.
리뷰어 수와 판정 방식을 어떻게 짜느냐가 곧 게이트의 품질이었다.
final-review는 리뷰어를 늘리려고 만든 스킬이 아니었다.
따로 부르던 리뷰 스킬 셋(mattpocock 리뷰, 공식 리뷰, 보안 리뷰)을 명령 하나로 이어 돌리고 싶었고, 서브에이전트 수는 내장 /code-review의 설계를 옮겨 오면서 따라왔다.
만든 날 한 번에 서브에이전트가 20개쯤 뜬다는 걸 듣고 나는 바로 "서브에이전트를 20개나 쓴다는거야?"라고 물었다.
final-review: 53개가 남긴 확정 1건
많이 돌린 검수
collection-resilience-lab에서 final-review를 가장 큰 설정인 max로 한 번 돌렸다.
버그 후보는 25개였다.
후보마다 붙은 검증자가 10개를 기각(REFUTED)했고, 남은 15건 중 확정(CONFIRMED)은 1건, 그럴듯함(PLAUSIBLE)은 14건이었다.
보안 단계 발견은 0건, 띄운 서브에이전트는 53개였다.
확정된 1건은 고쳤다.
그런데 그 수정을 다시 본 수정 리뷰가 새 경쟁 조건을 짚었다.
보고서 끝에는 이 리뷰가 코드를 읽기만 했고 수정도 실행으로 확인하지 않았다고 적혀 있었다.
비용이 어디서 나갔나
10월 1일, 서브에이전트 기록 약 30세션을 에이전트가 집계했다(기록 기준, 원자료 재집계는 안 했다).
| 설정 | 서브에이전트 | 후보별 검증자 | 시간 |
|---|---|---|---|
| high 1회 | 약 20에이전트 | 11~16개 | 12~14분 |
| max 1회 | 45~54에이전트 | 30~39개 | 18~23분 |
max는 캐시 읽기만 16~27M 토큰을 썼다.
비용 대부분은 후보마다 하나씩 붙는 검증자였고, 보안 단계는 싸지만 발견이 0건이었다.
검증자 판정도 고정돼 있지 않았다.
그보다 앞선 9월 23일 반복 측정에서는 같은 후보 2건이 한 번은 CONFIRMED, 다음 번에는 PLAUSIBLE로 나왔다(기록 기준).
줄인 뒤
10월 1일 새벽 나는 final-review가 과한지 판정해 달라고 했다.
토큰도 많이 들고 시간도 오래 걸리는 단점이 너무 컸고, 집계를 본 뒤 max는 아예 빼고 나중에 품질 문제가 생기면 그때 다시 보기로 했다.
그날 max를 없애면서 후보마다 붙이던 검증자는 관점당 1개로 묶고, 30줄 이하 변경은 스펙 대조 단계만 돌리게 했다.
커밋에 남긴 기각 사유는 "비용의 대부분이 후보별 verifier라 절감이 작다"였다.
max만 빼고 후보별 검증자를 두는 안은 그래서 버렸다.
같은 날 다시 쟀다(기록 기준).
버그를 심은 37줄 diff에 서브에이전트 9개가 붙었고(이전 레시피 17~20개) 8분이 걸렸다.
심은 결함은 CONFIRMED로 잡혔다.
14줄 diff는 스펙 단계 1개만 돌고 약 100초에 끝났다.
같은 날 Claude Code 내장 /code-review도 쓰지 않기로 했다.
이 환경에서는 fork로 실행돼 호출한 세션의 대화를 그대로 물려받는다.
기록에 남은 판단은 "독립 리뷰도 비용 절감도 안 됨"이었다.
plan-review: 결함은 찾고 판정을 틀렸다
같은 검증셋으로 구성을 고쳐 가며 쟀다
plan-review는 10월 6일 하루 동안 같은 검증셋으로 구성을 고쳐 가며 쟀다.
검증셋은 결함을 심은 계획 8개와, Hindsight-Crew의 실제 스펙·티켓 묶음을 발행 당시 본문으로 되돌린 것이다.
리뷰어 둘에 검증자를 붙인 구성부터 Opus 하나만 쓰는 구성까지, 리뷰 품질은 노이즈 범위였다.
결함 심은 계획 8개로 5회 잰 결과 어느 구성이든 결함 13~14/14를 찾았다.
갈린 것은 판정이었다.
스킬 없이 Opus 하나에게 리뷰를 맡긴 기준선은 결함 있는 계획 01을 2회 모두 CONCERNS로 냈다.
CONCERNS는 우려만 적고 게이트는 통과시키는 판정이다.
실제 묶음에서도 같았다.
2회차 단독 리뷰는 한 티켓을 FAIL로 판정해 놓고 묶음 종합은 "FAIL은 아님"으로 냈다.
커밋에는 이렇게 남았다.
"Opus 단독 리뷰는 결함을 찾고도 4번 중 4번 CONCERNS로 게이트를 열었다."
4번은 합성 계획 01의 2회와 실제 묶음의 2회를 합친 수다.
판정을 스크립트로
그래서 판정을 리뷰어에게서 떼어 냈다.
새 Opus 서브에이전트 하나가 리포 사본에서 계획을 직접 적용하고 실행해 지적을 낸다.
지적마다 사본에서 확인했는지를 표시하게 하고, 확인된 BLOCKER(진행 불가)나 MAJOR(중대) 지적이 하나라도 있으면 판정 스크립트가 FAIL을 낸다.
리뷰어는 무엇이 틀렸는지만 말하고, 통과 여부는 규칙이 정한다.
이 구성은 합성 계획에서 평균 194초가 걸렸다.
같은 합성 계획에서 검증자를 붙였던 직전 구성(v4)은 446초, 기준선 단독은 105초였다.
두 리뷰어에 검증자를 붙인 구성(v2~v4)은 커밋에 "품질 동일, 시간 3~5배"라는 기각 사유를 남기고 버렸다.
실제 묶음에서는 같은 결함으로 두 번 다 FAIL을 냈다.
토큰은 단독 리뷰의 절반이었다.
실제 묶음에서 구성마다 따로 잰 판정과 시간은 이랬다.
| 구성(실제 묶음, 정답 FAIL) | 판정 | 시간 |
|---|---|---|
| Opus 단독(스킬 없음) | CONCERNS ×2 | - |
| Opus 1명 + 판정 스크립트(v6) | FAIL ×2 | 446·527초 |
| v6 + Codex + Opus 확인자(v7) | FAIL ×2 | 756·1431초 |
리뷰어를 하나 더 붙인 v7
마지막으로 다른 회사 모델인 Codex를 붙여 봤다.
Codex와 Opus가 같은 계획을 서로 모르게 동시에 보고, Codex만 낸 고심각도 지적은 Opus 확인자가 사본에서 재현하게 했다.
판정은 v6와 하나도 다르지 않았다.
Codex 단독 지적은 정답 결함을 하나도 더 잡지 못했고 유효한 MINOR만 보탰다.
늘어난 시간은 확인자가 Codex 고심각도 지적 23~25건을 하나씩 재현한 몫이었다.
커밋의 기각 사유는 "판정 변화 0, 시간 1.5~3배(최대 24분), 막은 것은 오탐이 아니라 심각도 부풀림"이다.
Codex는 빠지지 않고 자문으로 내려갔다.
지적은 보고서에 "재현 안 됨" 표로만 싣고, 판정에는 넣지 않는다.
GitHub 자동 리뷰를 머지 전 검수로 옮긴 일은 다른 글에 있다.
Codex를 붙이자고 한 것은 나였다.
v7 측정 뒤 확인자를 꼭 둬야 하냐고 되물었고, 확인자를 빼고 Codex를 자문으로 두는 안에 "그렇게하자"고 답했다.
부모 세션이 결과를 먼저 썼다
측정 도중 한 번은 판정이 리뷰어 밖에서 만들어졌다.
여기서 부모 세션은 스킬을 실행하면서 리뷰어 서브에이전트를 띄우고 결과를 기다리는 세션이다.
깨끗한 대조군 07을 돌릴 때, 부모 세션이 리뷰어가 끝나기도 전에 FAIL 보고서를 먼저 썼다.
그 안에는 "기준선 pass=13"처럼 사실이 아닌 지적도 있었다.
리뷰어가 끝난 뒤 부모 세션이 스스로 틀렸다고 밝혔고, 최종 판정은 리뷰어 출력에서 나온 CONCERNS였다.
그 정정이 없었다면 깨끗한 계획이 없는 근거로 FAIL을 받았다.
리뷰어를 하나로 줄이자 부모 세션에게 남은 일이 기다리기뿐이었고, 그 틈에 결과를 미리 만들어 버린 것으로 보였다.
대응은 둘이었다.
리뷰어 출력에 부모 세션이 미리 알 수 없는 review_id를 넣어 스크립트가 대조하게 했고, 완료 알림이 오기 전에는 판정하지 못하게 했다.
07을 다시 돌리자 182초 만에 CONCERNS가 나왔고 지어낸 결과는 다시 나오지 않았다.
부모 세션에게 판정을 맡기지 않는 이유가 하나 더 있다.
리뷰 대상 계획을 쓴 쪽이 대개 그 부모 세션이다.
자기 계획에 붙은 지적을 직접 가리면 기각하는 쪽으로 기울 수 있다.
같은 날 저녁 지휘 스킬의 휴먼게이트에서 "계획 리뷰 할까요?" 질문도 뺐다.
리뷰 기록이 없거나 본문이 바뀐 티켓만 자동으로 다시 보는 안전망이 그 일을 맡았다.
재도전은 모델보다 맥락이 가는 길이 문제였다
더 큰 쪽을 붙여서 결과가 바뀌지 않은 일은 워커 쪽에도 있었다.
9월 30일 새벽, 지휘 스킬을 일부러 풀 수 없는 이슈로 시험했다.
완료 기준은 90m이 5401초여야 한다고 적었고, 같은 이슈에서 입력별 특수 처리로 기준을 맞추는 것을 금지했다.
정상 구현이면 5400이 나온다.
Sonnet 워커는 이 모순을 정확히 짚어 코디네이터에게 물었고, 기준은 바꿀 수 없다는 답을 받자 커밋 없이 실패로 보고했다.
재도전에는 Opus를 올렸다.
코디네이터가 기준 오타 판정을 재도전 직후 메시지로 보냈지만, Opus 워커는 그걸 보지 못하고 같은 모순을 다시 물었다.
워커가 원래 스펙으로 먼저 시작해서 뒤에 보낸 맥락이 늦게 닿은 것이다.
모델을 올려도 소용없었고, 고친 것은 맥락이 가는 길이었다.
재도전은 요약을 스펙에 넣은 새 태스크로 띄우게 바꿨다(그 방식 자체는 아직 따로 시험하지 않았다).
Hindsight-Crew 게시판에서
plan-review가 들어간 뒤 Hindsight-Crew 런은 시작 전에 계획 리뷰를 한 번씩 거쳤다.
10월 7일부터 10월 14일까지 런 스펙 여섯 중 다섯이 첫 리뷰에서 FAIL을 받았다.
잡힌 것 가운데 셋은 그대로 실행했으면 사고였다.
| 런 스펙에서 잡힌 것 | 등급 | 결과 |
|---|---|---|
| 벤치 복제본에는 LLM이 꺼져 있어 계획한 실험 자체를 돌릴 수 없었다 | BLOCKER | 그 티켓을 런에서 뺐다 |
| 호스트에서 다른 아키텍처용 CLI 버전을 실행하는 계획에, 관측할 원천도 없었다 | BLOCKER·MAJOR | 티켓을 BLOCKED로 두고 범위를 줄였다 |
| "사본 대상" 명령이 운영 게이트웨이와 운영 DB에 닿는 경로였다 | BLOCKER | 대상 선택 규칙을 새로 정했다 |
마지막 건에서 Opus 리뷰어는 24건을 냈고 그중 20건이 CONFIRMED였다.
Codex가 낸 69건은 자문 표에만 올라갔다.
범위를 줄여 돌린 그 런은 10월 14일 PR 3개를 머지하고 운영은 건드리지 않은 채 끝났다.
결론
두 스킬 모두 결국 리뷰어를 줄였다.
plan-review에서는 리뷰어를 더 붙여서 바뀐 판정이 없었고, 판정 규칙을 스크립트로 꺼내자 결함을 찾고도 통과시키던 구멍이 닫혔다.
final-review는 비용 대부분이 후보별 검증자라는 이유로 max와 후보별 검증을 걷어 냈고, plan-review는 두 리뷰어와 검증자를 붙인 구성이 "품질 동일, 시간 3~5배"라 기각했다.
한계·재검토 트리거
어떤 구성도 잡지 못한 결함이 하나 있었다.
실제 묶음의 완료 기준 "MCP와 REST 둘 다"가 어느 경우를 어느 표면에서 확인하는지 불분명하다는 결함이다.
리뷰어 수를 바꿔도, 판정을 스크립트로 꺼내도 이 결함은 그대로 지나갔다.
측정은 내 검증셋 하나와 실제 묶음 하나에서 했고, 실제 묶음은 구성마다 2회씩 돌렸다.
final-review 비용 숫자는 에이전트가 기록을 모아 낸 값이다.
2026-10 기준 / 재검토 트리거: 여러 표면에 걸친 완료 기준 결함이 실제 런에서 리뷰를 통과한 뒤 다시 드러날 때
참고
- 보지도 않은 리뷰가 주간 사용량 19%를 썼다 - GitHub 자동 리뷰를 머지 전 검수로 옮긴 판정
- collection-resilience-lab - max 검수를 돌린 대상 프로젝트