multi-agent peer review를 돌리고 있었다

큰 설계 변경 전에, 여러 AI에게 독립적인 리뷰를 시키고 있다.

대략적인 흐름은 다음과 같다.

• 기술·운영·비용의 3가지 관점에서 peer reviewer를 병렬 실행한다
• finding을 구조화된 JSON으로 출력하게 한다
• 다른 모델 계열의 reviewer를 섞어, 동일 계열 모델이 공유하는 맹점을 찾는다
• CRITICAL / HIGH를 설계에 반영한다
• 새로운 artifact SHA에 대해 재리뷰한다
• plateau(정체기)에 도달하면 구현으로 넘어간다

이 메커니즘을 Claude Opus를 중심으로 한 개발 세션에서 사용해 왔다. 세 명의 현자에 비유하여, 내부에서는 MAGI review라고 부르고 있다.

목적은 단순했다. 모델을 단 하나만 두면, 그 모델이 작성한 설계를 동일한 모델이 "좋다"라고 평가하기 쉽다. 독립된 관점과 다른 모델 계열을 섞으면, 공유된 training bias (학습 편향)를 어느 정도 상쇄할 수 있다.

당초의 암묵적인 전제는 다음과 같았다.

수정을 거듭하면 finding은 줄어들고, 설계가 충분히 굳어지면 reviewer도

GO

를 내보낸다.

리뷰의 정밀도가 높아지면 수렴도 쉬워질 것이다. 막연히 그렇게 생각했다.

그렇게 되지 않았다.

Fable 5가, 고칠 때마다 다른 구멍을 찾아냈다

회사 공유 memory layer의 큰 설계서를 Claude Fable 5에게 리뷰시켰다. 이력에 남아있던 Fable 호출은 27회. campaign 전체로는 round 41까지 진행되었다.

집계 결과는 다음과 같았다.

campaign directory의 첫 lock은 10:28, 최종 review는 15:09였다. Fable 단체로는 첫 call 시작부터 마지막 call 종료까지 약 4시간 38분, 27 call의 실행 시간을 합치면 약 2시간 25분이 된다.

여기서 말하는 round 41은 Fable을 41번 호출했다는 의미가 아니다. 중간의 3가지 관점 review나 수정 round를 포함한 campaign 번호이며, Fable이 담당한 cross-family seat는 27회였다. 최종 exact-SHA로 리뷰된 설계서는 2,970행. 즉, 약 4시간 42분에 걸쳐 round 41까지 돌리며 약 3,000행의 설계서를 만들었다는 뜻이 된다.

이 집계를 처음 봤을 때는 솔직히 "Fable, 정말 엄청나게 일하네"라며 감탄했다. 실제로 지적 내용도 상당히 좋았다. 곤란했던 점은, 그 감탄이 4시간 이상 지속되어도 구현이 시작되지 않았다는 것이다.

과거 finding의 단순한 재진술뿐이라면 무시하고 멈추기 쉽다. 실제 로그는 그렇지 않았다.

후반부만 보더라도, Fable은 다음과 같은 계층을 차례로 횡단하고 있었다.

• 실제 adapter SQL과 설계서의 권한 열거가 일치하는가
• PostgreSQL의 table / column / sequence / schema / function 권한이 전부 갖춰져 있는가
• SECURITY DEFINER의 search_path가 pgvector의 타입·operator를 해결할 수 있는가
• HNSW index의 opclass와 검색 연산자가 일치하는가
• 수정으로 도입한 "함수 owner에 의한 자동 열거"가, owner 설정 누락을 스스로 검출할 수 있는가
• count-only helper라는 설계가, 실제 adapter의 Python 측 prefix match에서 정말로 사용할 수 있는가

모두 repository의 migration이나 구현 단계까지 내려가 확인하고 있었으며, 결함을 찾아내는 질은 진짜였다.

그리고 수정을 하면 다음 round에서 이렇게 된다.

권한 부족을 수정
↓
권한의 자동 열거 규칙을 추가
...

전부 상당히 옳다.

초기 설계에 구멍이 많았던 것은 사실이다. 거기에 더해, 하나를 고칠 때마다 사양이나 검사 규칙이 늘어났다. 그 늘어난 부분을 다음 round가 다시 리뷰한다. Fable은 그 부분을 성실하게 잡아내고 있었다.

GO를 내보내고 있었다

사실 Fable을 단순히 "Fable이 정지 판정을 못 하고 폭주했다"라고 치부해 버리면, 중요한 부분을 놓치게 된다.

로그를 재확인하니, Fable은 campaign round 39에서 한 번 GO를 내보내고 있었다. 이 round는 MED 이상이 0이었고, LOW 2건과 nit 1건뿐이었다.

그런데, 그 LOW/nit를 우리가 수정했다.

artifact의 SHA가 변경되었으므로, exact-SHA review를 다시 실행한다. 그러자 추가한 검사 문구에서 repository reality와의 불일치가 발견되었고, round 40에서 MED가 다시 나타났다. 이를 수정하자 round 41에서 추가로 2건의 MED가 발생했다.

round 41에서도 2 MED + 2 LOW가 남았고, verdict는 GO-WITH-REVISE였다.

여기서 내가 멈췄다.

PLATEAU (정체기)

marker는 남아 있다. 하지만 Fable가 "더 이상 남은 것이 없다"라고 말하며 자연스럽게 정지한 것이 아니다. 남은 것은 나중에 처리할 수 있다고 인간이 선을 그은 것이다. 그 기록이다.

게다가 round 39에서는 한 번 GO가 나왔었다. 거기서 LOW/nit까지 수정하고 SHA를 움직여 리뷰를 재개한 것은 이쪽(인간) 측이다.

"지적이 있다면 전부 수정한다"는 언뜻 성실해 보인다. 하지만 exact-SHA review에서는 단 한 글자만 고쳐도 별개의 artifact가 된다. 강력한 reviewer에게 매번 전면 탐색을 시킨다면, 멈추지 않는 것이 오히려 자연스럽다.

마지막으로 필요했던 것은 Fable보다 똑똑한 reviewer가 아니었다. "남은 것은 backlog(백로그). 이 SHA는 더 이상 움직이지 않는다"라는, 단순한 정지 판단이었다.

GPT-5.6 Sol medium도 Fable와 같은 지점에 도달했다

다음으로 GPT-5.6 Sol medium에게 별도 기능의 설계를 맡겼다.

처음부터 355행으로 scope(범위)를 좁혔던 것이 아니다. artifact의 시각을 다시 확인해보니, 원래의 review campaign은 22:17의 round 1 lock부터 03:02의 round 23 완료까지 4시간 45분 동안 진행되었다. 그 시점에서 설계서는 4,093행에 달해 있었다.

개입 후에도 03:14부터 03:51까지 약 37분간 MVP review가 이어졌다. 첫 lock부터 계산하면 5시간 34분. agent 기동부터라면 6시간 3분이 된다. 그동안 구현은 아직 시작되지 않았다.

새벽 3시에 round 23의 JSON과 4,093행의 Markdown을 보고서야 비로소 기시감의 정체를 알 수 있었다. 이것은 Fable에서 했던 것과 같다.

설계를 정교화할 때마다 다른 blocker(차단 요소)가 발견되고, 그것을 수정하면 사양(specification), 예외(exception), 검증 항목이 더욱 늘어난다. 문서는 점점 탄탄해지고 있다. 하지만 구현 시작점은 계속해서 멀어져만 간다.

reviewer가 약해서 진전이 없다고 생각했지만, 로그를 보니 매번 나름대로 정확했다. 설계만이 성장하고 있었다. Fable campaign과 똑같은 형태였다.

그래서 내가 개입했다. 4,000행의 설계 전체를 완성하려는 시도를 중단시키고, 처음에 만들 hook MVP만을 별도의 artifact로 분리했다.

• reversible(되돌릴 수 있고)하며 disabled(비활성화된) build로만 한정
• activation(활성화)은 별도의 gate로 보냄
• live Stop hook은 변경하지 않음
• 구현 시간을 8 person-hours로 cap(제한)
• broad design review(광범위한 설계 리뷰)를 재개하지 않음
• 과거 finding(발견 사항)의 해소와 수정 regression(회귀)만을 확인

이 scope cut(범위 축소) 이후, 분리된 MVP의 첫 번째 review에서는 세 가지 관점을 병렬로 실행했다.

15건은 중복을 통합하여 7건으로 synthesis(합성)했다. PreToolUse의 효과를 증명하지 못함, 기존 API와 설계가 어긋남, timeout budget이 성립하지 않음, telemetry(원격 측정)로는 fail-open과 정상적인 no-op을 구분할 수 없음 등의 지적이었다.

7건을 반영한 v3는 355행이 되었다. 두 번째 round에서는 해당 exact SHA에 대해 의도적으로 탐색 범위를 좁혔다.

• fresh broad review 금지
• 과거 7건의 해소 확인을 중심으로 수행
• duplicate / regression / new / readiness-gap / scope-expansion을 필수 분류로 지정
• activation 시에만 필요한 사항을 disabled build의 blocker로 격상시키지 않음
• exact current SHA와 repository reality만을 확인

"더 이상 결점 찾기 대회를 재개하지 마라"라고 상당히 강하게 제약을 건 targeted regression review(대상 지정 회귀 리뷰)이다.

결과는 다음과 같았다.

새로운 finding도 가볍지 않았다.

하나의 문제는 allowlist 외 repository의 미저장 코드를 embed backend로 보낼 수 있는 privacy hole(개인정보 유출 허점)이었다. 또 다른 하나는 작은 Edit payload로부터 거대한 기존 파일을 무제한으로 읽고, 합성 및 parse(구문 분석)할 수 있는 resource hole(자원 유출 허점)이었다.

게다가 수정 후의 문서에 남은 timeout writer의 exactly-once race(정확히 한 번 실행 경쟁 상태)와, defer(지연)했을 터인 concurrency semaphore(동시성 세마포어)가 config/test inventory에 남는 모순도 포착했다.

4,093행에서 355행으로 줄이고, fresh broad review(새로운 광범위 리뷰)까지 금지했다. 그럼에도 Sol은 한 번에 멈추지 않았다.

멈추고 싶은 입장에서는 곤란하다. 다만, 나온 privacy hole과 resource hole은 버리기 어렵다. 이 시점에서의 Sol medium에 대한 인상은 "싸고 끈질긴 reviewer(검토자)"가 되었다.

가격 차이를 실제 로그로 계산하기

2026년 7월 19일 기준 일반 API 가격은 다음과 같다.

Fable campaign은 usage log(사용 로그)에 input / cache write / cache read / output 내역이 남아 있었다.

5분 cache write 요금으로 계산하면, 27회의 추정 합계는 약 $87.36, 1회 호출 평균은 약 $3.24였다.

반면, 수중에 있는 Codex log는 input / output 내역을 남기지 않고, 합계 tokens만 표시하고 있었다. 최초 3개 병렬 + targeted review(대상 리뷰)는 합계 279,248 tokens. 이를 모두 Sol의 output 단가로 계산한다는, 현실적으로는 불가능할 정도로 보수적인 상한선을 적용해도 약 $8.38이 된다. 실제로는 input이나 cached input이 많기 때문에 이보다 훨씬 낮다.

총액만 나란히 놓고 승패를 결정하는 것은 무리가 있다.

• Fable는 약 3,000행의 대규모 설계를 27번의 revision(수정)으로 추적했다.
• Sol은 355행의 별도 설계를 최초 3개 관점 + targeted 1회로 보았다.
• prompt(프롬프트), tool call(도구 호출), repository 탐색량도 다르다.

문서 크기도 작업량도 다르다. 여기서 비교하고 있는 것은 benchmark(벤치마크) 결과가 아니다. 실제로 밟은 두 개의 trace(추적)이다.

그럼에도 1회 단위로 보면, Fable 최종 round는 약 $3.23에 4 findings(발견 사항), Sol targeted round는 최대 $2.01에 7 findings였다. 이 두 개만 놓고 보면, actionable finding / dollar(달러당 실행 가능한 발견 사항 수)는 Sol medium 쪽이 더 높다.

"Fable보다 똑똑하다"거나 "Opus의 상위 호환"이라고까지는 말할 수 없다. Fable에는 거대한 artifact(결과물)의 변경 이력을 추적하고, 이전 round의 수정을 매번 repository까지 내려가서 계속 검증하는 강점이 있었다. 반면 Sol은 짧은 시간 안에 boundary omission(경계 누락)을 고밀도로 파고든다.

적어도 "저렴한 결점 찾기 역할"로서의 Sol medium은 상상했던 것보다 훨씬 강력했다.

종료 조건을 쓰지 않았다

이전에는 수렴 판정을 암묵적으로 모델에게 맡기고 있었다.

findings가 줄어든다
↓
reviewer가 GO를 낸다
...

이 모델은 reviewer의 탐색 능력에 천장이 있는 동안에는 작동한다. 큰 구멍을 다 고치고 나면 남은 것을 찾지 못하게 되어 자연스럽게 GO가 나오기 때문이다.

하지만 reviewer가 강해지면 다음 루프로 이어진다.

finding을 수정한다
↓
artifact SHA가 바뀐다
...

여기서 "finding이 계속 나온다"는 리뷰 실패의 증거가 아니다. 오히려 reviewer가 제대로 기능하고 있다는 증거이다.

틀렸던 점은, 올바른 finding이 있다면 지금 바로 고쳐야 한다고 생각했던 것이었다.

그렇다면, 어디서 멈출 것인가

모델의 GO / REVISE / REJECT는 하나의 증거로 남겨둔다. 하지만 최종 정지 판정에는 사용하지 않는다.

대신, 모델의 외부에서 다음을 기계적으로 판정한다.

reopen =
severity in {CRITICAL, HIGH}
AND class in {new, regression, unresolved-duplicate}
...

프로젝트에 따라 MED도 blocker에 포함한다. 어디에 선을 그을지는 안건에 따라 다르다. 다만, 선은 review를 시작하기 전에 결정해 두어야 한다. finding을 보고 나서 움직이면, 또다시 끝나지 않게 된다.

GO

나중에 LOW/nit를 수정하지 않는다.

1. LOW나 nit는 DEFERRED ledger로 보낸다. 현재의 artifact를 변경하지 않는다.

GO-WITH-REVISE

여기서 REVISE는 "지금 즉시 SHA를 변경하라"가 아니라, "다음 revision의 backlog에 남겨라"로 해석한다. 실제 Fable campaign에서는 round 41에서 인간이 이 판단을 내려 중단했다. 만약 round 39의 GO 시점에 동일한 rail이 있었다면, 훨씬 더 빨리 끝낼 수 있었을 것이다.

2. 2회차 이후부터는 fresh broad review를 금지한다

대상은 다음 사항으로만 좁힌다.

• 이전 round의 blocker가 해소되었는가
• 수정 사항이 regression을 발생시켰는가
• frozen scope 내에 구현 불가능하거나 안전상의 새로운 blocker가 있는가

readiness-gap이나 향후 개선 사항은 기록하되, disabled build를 중단시키지는 않는다.

3. finding에 유형을 부여한다

최소한 다음 항목들은 구분해야 한다.

• duplicate: 이전 blocker가 남아 있음
• regression: 수정 사항이 새로운 결함을 생성함
• new: frozen scope 내의 새로운 blocker
• readiness-gap: 활성화(activation) 전에는 필요하지만, 현재의 build blocker는 아님
• scope-expansion: 향후 개선 사항. 지금은 다루지 않음

"좋은 지적이지만 현재의 정지 조건과는 관계없다"를 표현할 수 없는 schema는, 모든 지성을 REVISE로 변환해 버린다.

4. resolution audit를 finding에 포함하지 않는다

Fable는 매 round마다 이전 finding의 해소 여부를 확인하는 것을 LOW finding으로 내놓는 경향이 있었다. 감사 추적(audit trail)으로서는 유용하지만, 결함 수에 섞어버리면 수렴 곡선(convergence curve)을 왜곡시킨다.

resolved_findings와 new_findings는 별도의 필드로 분리해야 한다.

5. plateau(정체기)를 선언하는 것은 gate뿐이다

모델은 자신의 탐색이 완전했음을 증명할 수 없다. "이제 충분한가"는 코드의 문제라기보다 product risk의 판단이기도 하다.

gate에는 더 지루한 작업만을 맡긴다.

• exact SHA가 일치하는가
• 필수 review family가 실제로 실행되었는가
• blocker가 0개인가
• nonblocker는 deferred ledger에 저장되었는가
• review 후에 artifact가 변경되지 않았는가

plateau를 reviewer의 감상으로부터 분리하여, 조건을 만족했을 때만 발생하는 상태 전이(state transition)로 만든다.

"더 강력한 reviewer를 추가한다"는 해결책이 아니다

리뷰가 수렴하지 않으면, 더 많은 별도의 모델을 추가하고 싶어진다.

하지만 reviewer를 추가하면 탐색량도 늘어난다. 지금 곤란한 점은 구멍을 찾지 못하는 것이 아니다. 강력한 reviewer를 추가하면, 멈출 근거보다 수정해야 할 재료가 늘어날 가능성이 높다.

현재로서는 역할을 다음과 같이 나누는 것이 좋아 보인다.

Sol medium
= 저렴하고 집요한 blocker 탐색 및 targeted regression review
Fable / Opus
...

리뷰는 AI에게 맡긴다. 하지만 종료 시점까지 AI에게 전적으로 맡기지는 않는다.

이번부터 바꿀 것

• LOW/nit는 그 자리에서 수정하지 않고 backlog로 보낸다
• 2회차부터는 broad review를 금지하고, 수정 사항과 regression만 확인한다
• resolution audit와 신규 finding을 별도 필드로 분리한다
• model의 verdict가 아니라, exact SHA와 blocker 수를 gate가 판정한다
• Sol medium은 저렴한 결점 찾기 역할로 사용하고, Fable / Opus는 긴 이력을 추적하는 최종 review에 집중시킨다

마치며

multi-agent peer review를 처음 만들었을 당시에는, 서로 다른 계통의 똑똑한 모델들을 섞으면 언젠가는 안전한 설계로 수렴할 것이라고 생각했다.

설계는 확실히 강력해졌다. 구현 전에 발견된 CRITICAL/HIGH 등급의 문제도 많았다. 그 점은 지금도 마음에 든다.

하지만 똑똑한 리뷰어(reviewer)는 종료 조건(termination condition)까지 가져다주지는 않는다. 때로는 보이는 구멍(hole)만 늘어날 뿐이다.

Fable 5는 41라운드(round 41)까지 구멍을 파 내려가다 인간의 개입으로 멈췄고, GPT-5.6 Sol medium 역시 4,093행, 23라운드(round 23)까지 진행되다가 인간에 의해 범위(scope)가 제한되었다. 게다가 355행의 타겟 리뷰(targeted review)를 통해서도 여전히 7건을 반환했을 때야 비로소 문제의 위치가 보였다.

Fable도 Sol도 고장 난 것이 아니었다. 우리가 요청한 대로, 그저 구멍을 계속 찾았을 뿐이다.

멈추지 않았던 원인은 더 사소했다. "언젠가 AI가 만족하겠지"라고 생각하며 종료 조건을 작성하지 않았던 것이다.

Discussion