멀티에이전트의 본업은 교차검증입니다

AI 에이전트가 하나보다 셋이면 더 믿을 만할까요. 겉으로는 그럴듯합니다. 한 모델이 답하고, 다른 모델이 검토하고, 세 번째 모델이 합의를 내면 사람보다 꼼꼼해 보입니다. 화면에는 "3개 모델 중 2개 동의" 같은 문장이 뜹니다. 검증을 통과한 것처럼 읽힙니다.

문제는 그 숫자가 생각보다 자주 검증보다 연출에 가깝다는 데 있습니다. 여러 에이전트가 모였다고 해서 서로 독립된 증거가 생기는 것은 아닙니다. 같은 학습 데이터에서 같은 함정에 빠질 수 있고, 한 모델의 그럴듯한 오답이 다음 모델의 출발점이 될 수도 있습니다. 결과를 한 문단으로 합쳐 버리면 어느 쪽이 왜 틀렸는지 되짚기도 어렵습니다.

저는 멀티에이전트를 협업 시스템보다 먼저 감사 시스템으로 봅니다. 일을 나눠 맡기는 장치보다, 한 결과를 다른 경로에서 공격하고 확인하는 장치에 가깝습니다. 두 번째 에이전트의 가치는 일을 더 빨리 끝내는 데서 나오지 않습니다. 첫 번째 에이전트가 놓친 오류를 다른 방식으로 드러낼 때 생깁니다.

자동 협업이 자주 평균이 되는 이유

멀티에이전트라는 말은 협업을 떠올리게 합니다. 여러 사람이 회의하듯 모델들이 의견을 내고, 마지막 모델이 종합하면 더 나은 판단이 나올 것 같습니다. 실제로는 다른 장면이 자주 나옵니다.

첫 번째 실패는 절충입니다. 한 모델이 맞고 다른 모델이 틀렸을 때, 종합 모델은 둘 사이의 중간 문장을 만들 수 있습니다. 중간은 합의처럼 보이지만 정답이 아닙니다. 법률과 세무처럼 결론이 갈리는 도메인에서는 절충이 가장 위험한 답이 됩니다. 보안이나 마이그레이션도 마찬가지입니다.

두 번째 실패는 공유 오류입니다. 모델이 셋이어도 같은 공개 자료와 같은 관용적 설명을 배웠다면, 같은 곳에서 함께 틀릴 수 있습니다. "다수가 동의했다"는 말은 독립 검증을 뜻하지 않습니다. 서로 다른 출처와 다른 절차를 거쳤을 때만 다수 의견에 무게가 생깁니다.

세 번째 실패는 디버깅 불가입니다. 누가 어떤 입력을 받았고, 어떤 근거로 어떤 결론을 냈는지 남지 않으면 실패를 고칠 수 없습니다. 최종 답변 한 문단만 보면 회의록이 없는 회의를 본 것과 같습니다. 틀린 결론은 남고, 틀린 경로는 사라집니다.

교차검증은 불편해야 작동합니다

좋은 멀티에이전트 설계는 일부러 마찰을 남깁니다. 자동으로 최적 모델을 고르고 자동으로 위임하는 흐름은 편합니다. 다만 위험한 전제를 깔고 있습니다. 모델이 자기 한계를 정확히 안다는 전제입니다. 실제로 모델은 자기가 언제 틀릴지 잘 모릅니다. 자동 라우팅은 필요한 순간을 놓치거나, 필요 없는 순간에 비용을 태우기 쉽습니다.

교차검증은 반대로 갑니다. 호출 타이밍을 사람이 정합니다. "이 변경은 인증을 건드리니 다른 모델에게 설계 검토를 맡긴다"처럼 검증 지점을 명시합니다. "이 계산은 조문 적용이 까다로우니 별도 adversary에게 공격시킨다"도 검증 지점으로 남깁니다. 불편함 자체가 안전장치로 작동합니다. 검증은 비용이 드는 행동이어야 남발되지 않고, 중요한 곳에 쓰입니다.

또 하나의 원칙은 실패 허용. 두 번째 에이전트가 늦거나 실패해도 메인 작업이 멈추면 안 됩니다. 검증자는 주 실행자가 아닙니다. 주 실행자는 작업을 끝까지 밀고, 검증자는 위험한 가정과 빠진 근거를 찾아냅니다. 결과가 늦게 오면 늦게 온 검토로 반영하면 됩니다. 교차검증은 병목보다 감사 로그에 가깝습니다.

합의는 산문 전에 계산되어야 합니다

여러 에이전트의 의견을 모을 때 가장 피해야 할 방식은 최종 LLM에게 "종합해줘"라고 던지는 것입니다. 종합은 설명처럼 보이지만, 그 안에서 표가 사라지고 숫자가 사라집니다. 강하게 말한 한 모델이 전체 결론을 끌고 갈 수도 있습니다.

합의는 먼저 구조화되어야 합니다. 각 에이전트는 결론과 근거를 정해진 필드에 씁니다. 확신도와 실패 여부도 따로 남깁니다. 그다음 결정론적 집계기가 bullish, bearish, neutral 같은 표를 계산하듯 결론 분포를 냅니다. 표가 갈리면 갈렸다고 남깁니다. near-zero나 split-panel이면 HOLD처럼 보수적 결론으로 보내는 규칙도 코드에 있어야 합니다.

LLM이 할 일은 그다음입니다. 계산된 합의를 사람이 읽을 말로 설명합니다. 투표 수를 만들거나, 반대 의견을 슬쩍 지우거나, 중간 문장을 발명하지 않습니다. 판단은 코드가 하고, 모델은 설명합니다. 지난 글에서 말한 하네스 원칙과 같은 자리입니다.

두 번째 모델은 작업자보다 반대편 감사자일 때 강합니다

멀티에이전트가 빛나는 순간은 모두가 같은 방향으로 달릴 때가 아닙니다. 한 모델이 낸 결론을 다른 모델이 반대편에서 공격할 때입니다. 세무와 규제처럼 그럴듯한 답이 사고를 내는 영역에서는 adversary가 필요합니다. 보안 리뷰도 같은 축에 놓입니다.

예를 들어 세무 판단에서 reasoner가 결론을 냅니다. 그다음 adversary는 반대 입장에 섭니다. 빠진 사실관계가 있는지, 결정적 조문이 다른 결론을 요구하지 않는지, 판례 하나가 방향을 뒤집지 않는지 공격합니다. 마지막 synthesis는 이 공격을 통과한 결론만 정리합니다. 여기서 두 번째 모델은 동료 작업자가 아니라 감사자입니다.

이 구조가 중요한 이유는 self-eval의 천장 때문입니다. 같은 모델이 자기 답을 검토하면 말투만 조심스러워질 뿐, 잘못 잡은 전제를 그대로 유지하는 경우가 많습니다. 검증자는 다른 프롬프트와 다른 역할, 가능하면 다른 모델과 다른 근거 경로를 가져야 합니다. 그래야 첫 번째 답의 사각지대를 찌를 가능성이 생깁니다.

비용은 줄이기 전에 설계해야 합니다

물론 교차검증은 비쌉니다. 모델을 하나 더 부르면 토큰이 늘고, 대기 시간이 늘고, 중간 산출물이 쌓입니다. 멀티에이전트 시스템에서 컨텍스트가 누적되면 비용은 생각보다 빨리 커집니다. "항상 여러 모델"은 좋은 기본값이 아닙니다.

대신 검증 지점을 고릅니다. 인증과 결제처럼 틀렸을 때 손실이 큰 곳입니다. 데이터 삭제, 법령 적용, 대규모 마이그레이션도 여기에 들어갑니다. 그리고 검증 입력을 작게 만듭니다. 전체 대화를 넘기지 않고, 주장과 근거와 diff만 넘깁니다. 검증자가 봐야 할 것은 모든 맥락보다 위험한 결정의 핵심입니다.

이렇게 보면 마찰은 단점만이 아닙니다. 사람이 검증 버튼을 누르는 행위는 "여기는 위험하다"는 표시입니다. 자동 위임을 포기하면 조금 느려집니다. 대신 왜 두 번째 모델을 불렀는지 기록이 남습니다. 협업의 환상보다 이 기록이 더 쓸모 있습니다.

먼저 감사 시스템으로 보세요

멀티에이전트는 매력적인 단어입니다. 여러 모델이 알아서 역할을 나누고, 서로 토론하고, 최종 답을 고르는 그림은 멋집니다. 실무에서 먼저 필요한 것은 그 그림이 아닙니다. 누가 무엇을 주장했는지. 어떤 근거가 독립적으로 확인됐는지. 어느 leg가 실패했는지. 합의가 코드로 계산됐는지. 이 네 가지입니다.

두 번째 에이전트를 붙이고 싶다면 질문을 바꿔보세요. "이 에이전트가 어떤 일을 대신 해줄까"보다 "이 에이전트가 어떤 오류를 잡아줄까"가 먼저입니다. 그 질문에 답이 없으면 아직 멀티에이전트를 쓸 때가 아닙니다.

멀티에이전트는 협업 시스템이기 전에 교차검증 시스템입니다. 그 순서를 지킬 때만 모델을 둘 이상 붙이는 비용이 신뢰로 바뀝니다.