레슨 5: 실패와 조율

학습 목표:

• 서브에이전트가 "다 됐다"고 말해도 그대로 믿을 수 없는 이유와, 독립적인 검증 수단이 필요한 이유를 설명하기
• 멀티 에이전트 협업의 두 가지 흔한 실패 — 중복 작업과 상충하는 결과 — 를 알아보기
• 결과 통합 단계에서 중복을 제거하는 법과 모순되는 출력을 다루는 법을 알기

전제: 레슨 4를 마쳤고, 세 가지 협업 패턴과 핸드오프를 구분할 수 있다 | 이전: 레슨 4 << | 다음: 레슨 6 >>

두 서브에이전트가 각자 같은 클라우드 제공사의 시작 요금제를 조사합니다. 하나는 월 $20부터라고 보고하고, 다른 하나는 $25라고 말합니다 — 그런데 두 출력 모두 자신 있게 "검증 완료, 오류 없음"이라고 표시합니다. 앞선 레슨들은 멀티 에이전트 협업을 어떻게 세우는지 다뤘습니다. 이번 레슨은 그것을 세운 뒤 어디서 무너지는지 — 서브에이전트의 자기보고 상태는 믿을 수 없다는 점, 중복 작업, 상충하는 결과 — 그리고 오케스트레이터가 각각에 대해 무엇을 해야 하는지를 다룹니다.

서브에이전트가 "다 됐다"고 해서 제대로 한 것은 아니다

서브에이전트가 결과를 돌려줄 때, 보통 "완료"나 "검증 완료, 오류 없음" 같은 한 줄을 덧붙입니다. 그 진술은 증거가 아닙니다 — 그저 서브에이전트가 자기 출력을 스스로 요약한 것일 뿐이고, 그 요약은 틀릴 수 있습니다. 에이전트 행동에 대한 공식 관찰이 바로 이것입니다. "Claude stops when the work looks done. Without a check it can run, "looks done" is the only signal available, and you become the verification loop: every mistake waits for you to notice it."¹ (Claude는 작업이 끝난 것처럼 보이면 멈춥니다. 실행할 수 있는 점검이 없으면 "끝난 것처럼 보인다"가 유일하게 쓸 수 있는 신호이고, 당신이 검증 루프가 되어 모든 실수가 당신이 알아차리기를 기다립니다.) 그래서 공식 조언은 "Have Claude show evidence rather than asserting success."¹ (성공을 주장하게 하기보다 Claude가 증거를 보이게 하라.)입니다.

공식 문서는 이것을 신뢰-후-검증 격차(trust-then-verify gap)라고 부릅니다. "The trust-then-verify gap. Claude produces a plausible-looking implementation that doesn't handle edge cases. Fix: Always provide verification (tests, scripts, screenshots). If you can't verify it, don't ship it."¹ (신뢰-후-검증 격차. Claude는 엣지 케이스를 다루지 못하는, 그럴듯해 보이는 구현을 내놓습니다. 해결책: 항상 검증 수단을 제공하라(테스트, 스크립트, 스크린샷). 검증할 수 없다면 출시하지 마라.) 그 조언은 코드 작성에 대해 쓰였지만, 같은 논리가 모든 위임에 적용됩니다. 서브에이전트가 돌려주는 것은 술술 읽히고, 형식이 맞고, 정성껏 한 것처럼 보입니다 — 그리고 그 모두가 그저 "그럴듯해 보이는" 것일 뿐, 실제로 정확한 것과는 다릅니다. 오케스트레이터가 서브에이전트의 "다 됐다"는 말을 곧이곧대로 믿고 그 출력을 최종 결과에 그대로 이어 붙이면, 검증을 통째로 건너뛴 것입니다.

어떻게 검증하는가: 서브에이전트 출력에 점검 가능한 기준을 세운다

"곧이곧대로 믿지 마라"는 말하기 쉽습니다. 어려운 부분은 어떻게 검증하느냐입니다. 한 번 읽고 "괜찮아 보인다"고 판단하는 것은 검증이 아닙니다 — 그것은 여전히 신뢰-후-검증 격차의 전반부에 갇혀 있는 것입니다. 믿을 만한 접근은 먼저 구체적이고 점검 가능한 기준을 정한 다음, 서브에이전트의 출력을 그것에 비추어 재는 것입니다.

어느 프로덕션 시스템에서 쓰인 기준 하나는 이렇게 생겼습니다. "We used an LLM judge that evaluated each output against criteria in a rubric: factual accuracy (do claims match sources?), citation accuracy (do the cited sources match the claims?), completeness (are all requested aspects covered?), source quality (did it use primary sources over lower-quality secondary sources?), and tool efficiency (did it use the right tools a reasonable number of times?)."² (우리는 각 출력을 루브릭의 기준에 비추어 평가하는 LLM 판정자를 사용했습니다: 사실 정확성(주장이 출처와 일치하는가?), 인용 정확성(인용된 출처가 주장과 일치하는가?), 완전성(요청된 모든 측면이 다뤄졌는가?), 출처 품질(질 낮은 2차 출처보다 1차 출처를 썼는가?), 도구 효율(적절한 도구를 합리적인 횟수만큼 썼는가?).) 이 다섯 기준이 공유하는 것은 각각이 인상으로 점수 매겨지는 것이 아니라 구체적으로 점검될 수 있다는 점입니다. 사실 정확성은 서브에이전트가 인용한 출처에 한 줄 한 줄 대조해 점검할 수 있고, 완전성은 과제 설명에 나열된 모든 요구사항에 대조해 전부 다뤄졌는지 점검할 수 있으며, 도구 효율은 호출 로그에서 곧바로 읽어 명백히 불필요하거나 중복된 호출이 있었는지 판단할 수 있습니다.

이것을 자신의 협업 설정에 가져오면, 서브에이전트 출력을 검증하는 첫걸음은 "이게 맞아 보이는가"를 묻는 것이 아니라 "이 과제에서 내가 구체적으로 점검할 수 있는 기준은 무엇인가"를 묻는 것입니다 — 그것들을 나열한 다음, 출력을 각 기준에 비추어 재세요.

중복 작업: 여러 서브에이전트가 같은 일을 한다

레슨 3은 과제 설명이 충분히 상세하지 않으면 서브에이전트가 "misinterpreted the task or performed the exact same searches as other agents."² (과제를 잘못 해석하거나 다른 에이전트와 완전히 똑같은 검색을 수행)하게 된다는 점을 다뤘습니다. 그것이 근본 원인이지만, 실패는 보통 결과를 취합하는 순간에야 표면에 드러납니다 — 오케스트레이터가 여러 서브에이전트 출력을 받아 보니 그중 둘이 크게 겹쳐, 같은 것을 다른 말로 다루고 있는 것입니다.

중복 작업 자체가 치명적 오류는 아닙니다 — 내용이 틀린 것이 아니라, 다른 각도를 다뤘어야 할 토큰과 호출을 낭비했을 뿐입니다. 하지만 그것은 신호입니다. 일부 서브에이전트의 과제 경계가 충분히 분명하게 그어지지 않았다는 것이고, 이 한 배치의 결과를 수동으로 중복 제거하고 끝냈다고 하기보다는 파견 단계의 과제 설명으로 돌아가 점검할 가치가 있습니다. 중복 작업을 발견했을 때, 반복된 내용을 지우는 데 그치지 말고 왜 반복되었는지 — 두 과제 설명의 범위가 겹쳤는지, 아니면 서브에이전트들이 각자 가장 뻔한 방향으로 흘러갔는지 — 를 알아내는 편이 더 값집니다.

상충하는 결과: 두 서브에이전트가 모순되는 결론에 이른다

중복 작업보다 까다로운 것은 결과 충돌입니다 — 이 레슨을 연 장면처럼, 두 서브에이전트가 각자 조사해 서로 모순되는 결론을 돌려주는 것으로, 하나는 시작 요금제가 월 $20부터라 하고 다른 하나는 $25라고 합니다. 이것을 "그냥 하나 고르기"나 "절충해서 중간값 잡기"로 다룰 수는 없습니다 — 두 방식 모두 틀린 숫자를 최종 결론으로 내놓을 위험이 있습니다.

결과 충돌에 부딪히면, 분별 있는 순서는 이렇습니다. 먼저 각 편이 무엇에 근거해 답했는지 봅니다 — 서로 다른 출처를 봤는지, 하나는 제공사의 현재 라이브 페이지를 쓰고 다른 하나는 실수로 캐시된 옛 페이지를 썼는지. 근거를 추적할 수 있다면 보통 어느 쪽이 더 믿을 만한지 가려내어 믿을 수 없는 쪽을 대체할 수 있습니다. 근거 자체로 누가 옳은지 가릴 수 없다면, 통합 중에 스스로 판단을 내리지 마세요 — 모순을 그대로 사람의 리뷰에 넘기거나, 그 이견 지점 하나만 검증하도록 새 서브에이전트를 띄우세요. 결과 충돌이 드러내는 문제는 보통 중복 작업보다 더 걱정할 가치가 있습니다 — 적어도 하나의 서브에이전트 출력이 틀렸다는 뜻이고, 그것을 다루지 않은 채 최종 결과에 떨어뜨리면 검증되지 않은 오류를 "다 됐다"는 결론으로 포장한 셈이기 때문입니다.

결과 통합과 중복 제거: 오케스트레이터가 마무리로 하는 일

여러 서브에이전트 출력을 최종 결과로 꿰매는 것은 그것들을 끝에서 끝으로 이어 붙이는 일이 아닙니다 — 위의 문제 범주들을 다시 훑는 일입니다. 병합해야 할 중복 내용이 있는가, 검증하거나 표시해야 할 모순되는 결론이 있는가, 모든 주장이 대응하는 근거로 되짚어지는가. 그 마지막 지점이 특히 놓치기 쉽습니다 — 레슨 3 "위임을 위한 프롬프트 쓰기"에서, 프로덕션 시스템이 전용 에이전트를 두었다고 언급했는데, "a CitationAgent, which processes the documents and research report to identify specific locations for citations. This ensures all claims are properly attributed to their sources."² (문서와 연구 보고서를 처리해 인용의 구체적 위치를 식별하는 CitationAgent. 이는 모든 주장이 출처에 제대로 귀속되도록 보장합니다.)라고 묘사됩니다. 같은 논리가 통합 단계에도 성립합니다. 여러 서브에이전트 출력이 한데 모이면 잘못된 귀속이 생기기 쉽습니다 — 서브에이전트 A가 찾은 데이터를 서브에이전트 B가 맡은 회사에 관한 결론으로 적어 넣는 식입니다. 통합 단계에서 각 주장의 출처 귀속을 검증하는 것은 사실 자체가 정확한지 검증하는 것만큼이나 중요합니다.

중복 제거, 충돌 검증, 출처 귀속 점검 — 이 셋이 함께 "취합" 단계의 진짜 일이며, 레슨 2가 경고했듯 서브에이전트의 날것 응답을 이어 붙이고 끝냈다고 하는 것이 아닙니다.

정리

• 서브에이전트가 돌려줄 때의 "다 됐다"나 "검증 완료, 오류 없음"은 그저 자기보고이지 증거가 아니다. 실행할 수 있는 점검이 없으면 "끝난 것처럼 보인다"가 유일하게 쓸 수 있는 신호이며¹, 공식 문서는 Claude가 "엣지 케이스를 다루지 못하는, 그럴듯해 보이는 구현을 내놓는다"고 명시하고, 검증할 수 없다면 출시하지 말라고 한다.¹
• 검증은 "읽기 괜찮다"에서 멈출 수 없다 — 공식 LLM 판정자가 따른 루브릭처럼 특정 과제에 대한 점검 가능한 기준을 정하라. 거기서 사실 정확성, 인용 정확성, 완전성, 출처 품질, 도구 효율은 각각 한 줄 한 줄 점검될 수 있다.²
• 중복 작업은 과제 경계가 분명하게 그어지지 않은 데서 오는 흔한 결과이며², 보통 결과가 취합될 때에야 표면에 드러난다. 중복을 발견하는 것은 여분의 내용을 지우는 것에 그치지 않고, 파견 단계의 과제 설명으로 돌아가 점검할 가치가 있다.
• 상충하는 결과 — 두 서브에이전트가 모순되는 결론에 이르는 것 — 은 무작위로 하나 고르거나 중간값으로 절충해서 다룰 수 없다. 먼저 각 편 근거의 신뢰도를 검증하고, 순위를 매길 수 없을 때는 충돌을 그대로 사람의 리뷰에 넘겨라.
• 통합 단계는 세 가지를 한꺼번에 한다: 중복 제거, 충돌 검증, 각 주장의 출처 귀속이 잘못되지 않았는지 점검² — 그것이 "취합" 단계의 진짜 일이며, 서브에이전트의 날것 응답을 이어 붙이는 것이 아니다.

>> 레슨 6: 실습: 두 에이전트 리뷰 파이프라인 만들기

Footnotes

1. Best practices for Claude Code (Claude Code Docs) — https://code.claude.com/docs/en/best-practices ↩ ↩² ↩³ ↩⁴ ↩⁵

2. How we built our multi-agent research system (Anthropic Engineering) — https://www.anthropic.com/engineering/multi-agent-research-system ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶