109개의 에이전트를 활용한 코드 감사 워크플로우에서 얻은 교훈

여러분은 그러지 않아도 되도록, 제가 109개의 에이전트를 활용한 코드 감사에 930만 토큰을 사용해 보았습니다

요약하자면: 저는 약 5,000라인 규모의 코드베이스(codebase)에 AI 에이전트 군단을 투입하여 수정할 가치가 있는 것들을 찾아내도록 했습니다. 파이프라인은 병렬 서브시스템 매퍼(subsystem mappers) → 8개의 "탐색(finder)" 렌즈 → 중복 제거(dedup) → 모든 발견 사항에 대한 적대적 검증(adversarial verification) → 순위 산정 패널(ranking panel) → 종합(synthesis) 순으로 구성되었습니다.

결과는 성공적이었습니다. 32개의 검증된 발견 사항, 깔끔한 상위 10개 항목, 출력 결과에 대한 불만은 없었습니다. 하지만 약 930만 토큰(API 비용으로 약 46달러)이 소모되었으며, 그중 3분의 2 이상은 제가 돈을 허공에 날린 것이나 다름없었습니다. 여기 그 사후 분석(autopsy) 결과가 있습니다.

토큰이 실제로 어디에 쓰였는가

단계	에이전트 수	무엇이 잘못되었나
검증 (Verify)	109개 중 86개 (79%!)	34개의 발견 사항 중 단 2개만 폐기함 — 6%의 적중률을 위해 코드를 86번 다시 읽는 전체 비용을 지불함
...

결정적인 문제는 캐시 읽기(cache reads)가 전체 토큰의 77%를 차지했다는 점입니다. 모든 에이전트는 새로운 컨텍스트(context)와 함께 생성되어 동일한 파일을 처음부터 다시 읽습니다. 이는 광범위하게 확장(fan out)할 때 발생하는 비용이며, 즉 이득이 되는 곳에만 확장해야 한다는 것을 의미합니다.

가장 중요했던 단 하나의 실수

저는 순위를 매기기 전에 모든 것을 검증했습니다. 적대적 검증(Adversarial verification)은 단위 가치당 가장 비용이 많이 드는 단계이며, 대부분의 발견 사항은 최종 단계에 도달조차 하지 못합니다. 즉, 저는 편집 과정에서 버려질 운명인 발견 사항들을 사실 확인하기 위해 프리미엄 가격을 지불하고 있었던 것입니다.

순서를 바꾸십시오:

탐색(find) → 중복 제거(dedup) → 순위 산정(RANK) → 상위 약 12~15개만 검증(verify) → 종합(synthesize)

결과는 동일합니다. 에이전트 수는 약 70% 줄어듭니다. 이것이 진정한 교훈이며, 나머지는 각주에 불과합니다.

각주 (비용을 절감해 주는 실제 규칙들, 절감 효과가 큰 순서대로)

1. 먼저 순위를 매기고, 나중에 검증하라 (Rank first, verify after). 실제 결과물에 포함될 발견 사항(findings)에 대해서만 적대적 검증 (adversarial verification) 비용을 지불하세요.
2. 리스크 수준에 맞춰 편집증(paranoia)의 강도를 조절하라. 내부 감사에서 잘못된 발견 사항이 발생하면 누군가의 읽기 시간 몇 분을 낭비할 뿐이며, 이 경우 하나의 반박자 (refuter)만으로도 충분합니다. 전체 3단계 패널 (코드 진위 (code-truth) / 영향도 (impact) / 접근 방식 (approach))은 최종 후보군이나 실제 조치를 유발하는 주장(claims)을 위해서만 아껴두세요.
3. 파일 단위로 검증을 배치(Batch) 처리하라. 34개의 발견 사항이 약 10개의 파일에 걸쳐 있었습니다. 하나의 검증자가 동일한 파일에 대해 모든 발견 사항을 확인하면, 파일을 10번 읽는 대신 한 번만 읽으면 됩니다. 발견 사항마다 렌즈별로 팬아웃 (fan-out)을 수행하지 마세요. 그것은 이 교훈을 배우기에 너무 비싼 방식입니다.
4. 작은 리포지토리(<10k LOC)에서는 매퍼 (mappers)를 건너뛰라. 에이전트 하나가 전체를 다 삼킬 수 있고, 발견자 (finders)들이 어차피 다시 읽기 때문에, 맵 (map) 단계는 두 번의 오버헤드(overhead)를 발생시킵니다. 한 번은 맵을 구축할 때, 또 한 번은 모든 발견자 프롬프트에 이를 첨부할 때입니다.
5. 발견자 렌즈는 최대 6개로 제한하라 —

• **검증 단계에서의 코드 진실 거부권 (The code-truth veto in verification)**은 제 역할을 다했습니다. 최종 보고서에서 저를 당황하게 만들었을 법한, 그럴듯하지만 틀린 2개의 발견 사항을 잡아냈습니다. 적대적 검증 (Adversarial checking)은 랭킹을 통과한 항목들에 대해서라면 모든 토큰을 쓸 가치가 있습니다.
• 모든 에이전트에 구조화된 출력 스키마 (Structured output schemas) 적용: 109개 에이전트 전체에서 파싱 실패가 단 한 건도 발생하지 않았습니다. 지루하지만, 신뢰할 수 있고, 훌륭합니다.
• 발견자 출력에 대한 엄격한 제한 (각각 최대 6개): 깔때기 (Funnel)가 급격히 팽창하는 것을 방지했습니다.
• 캐시된 결과를 활용한 재개 가능한 실행 (Resumable runs with cached results): 실행 중간에 중단했다가 나중에 거의 비용 부담 없이 다시 시작할 수 있었습니다.

요약 (TL;DR)

*찾기 (Find)*를 위해 확산(Fan out)하세요. *검증 (Verify)*하기 전에 수렴(Converge)하세요. 넓게 펼치는 것은 발견을 위한 것이고, 엄격함은 살아남은 것들을 위한 것입니다. 이 과정을 거꾸로 하면, 저처럼 에이전트의 79%가 인간은 절대 읽지 않을 것들을 성실하게 감사하는 상황에 처하게 될 것입니다.