멀티에이전트 도입의 신뢰성 판정

멀티에이전트 도입 여부는 평균 점수가 아니라 신뢰성으로 판정해야 합니다. 오류가 번지는 경로와 되돌리는 비용을 감당할 설계가 없다면 단일 에이전트에 검증기를 붙이는 쪽이 낫습니다.

에이전트를 여러 개 붙일지는 벤치마크 평균 점수로 정할 문제가 아닙니다. 평균 점수는 도입 이후에 실제로 지불하는 비용을 보여주지 않습니다. 2026년에 나온 신뢰성 연구들은 판정의 축을 다른 곳으로 옮깁니다. 반복 실행의 일관성, 오류가 번지는 경로, 잘못을 되돌리는 비용 세 가지입니다.

따로 움직이는 역량 점수와 신뢰성

성공률 하나로 압축한 평가는 운영 결함을 가립니다. Rabanser 등의 'Towards a Science of AI Agent Reliability'(arXiv:2602.16666, 2026-02)가 이 문제를 다룹니다. 이 연구는 신뢰성을 일관성, 견고성, 예측 가능성, 안전성 네 차원 12개 지표로 분해했습니다. 두 벤치마크에서 모델 15개를 잰 결과, 최근의 역량 향상은 신뢰성에서 작은 개선만 냈습니다.

같은 갈라짐이 장기 과제에서 더 뚜렷합니다. Khanal 등의 'Beyond pass@1'(arXiv:2603.29231, 2026-03)은 모델 10개를 396개 과제, 23,392 에피소드로 측정했습니다. 성능이 완만하게 떨어지는 정도를 재는 GDS(Graceful Degradation Score)는 도메인마다 다르게 움직였습니다. 소프트웨어 엔지니어링은 과제가 길어지면 0.90에서 0.44로 내려앉았고, 문서 처리는 0.74에서 0.71로 거의 평평했습니다.

같은 논문의 나머지 발견이 판정에 더 직접 걸립니다. 역량 순위와 신뢰성 순위가 갈라져 장기 구간에서 순위가 여러 칸 뒤집혔습니다. 프론티어 모델의 붕괴율이 최대 19%로 가장 높았는데, 야심찬 다단계 전략을 시도하다 궤도를 벗어나기 때문입니다. 메모리 스캐폴드는 모델 10개 전부에서 장기 성능을 떨어뜨렸습니다.

측정 인프라 쪽에서도 같은 신호가 나옵니다. Holistic Agent Leaderboard(arXiv:2510.11977, 2025-10)는 모델 9개와 벤치마크 9개에 걸쳐 21,730회를 약 4만 달러에 실행했습니다. 여기서 추론 노력을 올렸을 때 다수의 실행에서 정확도가 오히려 떨어졌습니다. 이 지표들의 정의는 멀티에이전트 시스템 평가와 오케스트레이션 토폴로지에 있습니다.

토폴로지를 타고 번지는 오류

멀티에이전트가 단일 구성과 갈라지는 지점은 오류가 남의 컨텍스트로 들어간다는 데 있습니다. Xie 등의 'From Spark to Fire'(arXiv:2603.04474, 2026-03)는 협업을 방향 의존성 그래프로 놓고 이 전파를 모델링했습니다. 프레임워크 6개를 세 토폴로지로 나눠 재면서 연쇄 증폭, 토폴로지 민감성, 합의 고착 세 가지 취약성을 확인했습니다. 체인에는 LangChain과 MetaGPT, 메시에는 AutoGen과 CAMEL, 스타에는 CrewAI와 LangGraph가 들어갔습니다.

전파의 모양은 토폴로지가 정합니다. 체인 구조에서는 오류가 한 단계씩 앞으로 밀리며 계단 모양으로 늘어납니다. 스타 구조에서는 허브가 오류를 채택하는 순간 모든 작업자에게 한 번에 방송되어 급등합니다.

어디로 들어오느냐가 피해 반경을 가릅니다. 같은 오류 시드를 허브 노드에 심으면 감염률이 100%에 이르렀고, 말단 노드에 심으면 CrewAI가 15.9%, LangGraph가 9.7%에 그쳤습니다. 두 값의 비인 영향 계수는 각각 6.29배와 10.31배입니다. 허브를 어디에 두는지가 성능 문제가 아니라 오염 반경 문제라는 뜻입니다.

개입이 늦을수록 비싸지는 합의 고착

합의 고착은 시간 방향의 비대칭입니다. 거짓 하나를 밀어 넣는 비용은 싸지만, 되돌리는 비용은 작업이 진행될수록 커집니다. 산출물 중심 워크플로에서 중간 결과물이 곧 프로젝트의 상태가 되기 때문입니다. 초기 오류는 출처와 가정, 코드 뼈대, 평가 기준 같은 제약으로 굳어 다음 단계가 그 위에 쌓입니다.

그래서 뒤늦은 정정은 문장 하나와 다투지 않습니다. 내부 정합성을 이미 갖춘 의존 사슬 전체와 부딪힙니다. 같은 논문은 개입 전까지 쌓인 오염 컨텍스트의 양을 오염 라운드로 셌습니다.

두 단계를 늦추면 되돌려야 할 오염이 세 배 가까이 늘어납니다. 토론 구조에서는 이 고착이 다수결과 겹쳐 더 굳습니다. 진행 중인 투표를 실시간으로 공개할 때 생기는 쏠림은 Multi-Agent Debate에서 정리했습니다.

신뢰성의 가격

같은 연구는 메시지 계층에 계보 그래프 기반 거버넌스를 끼워 오류 확산을 억제했습니다. 지표는 BICR(Benign Infection Control Rate)로, 공격 성공률의 여집합이며 최종 산출물이 오염을 피한 비율입니다. 아래 수치는 오류 시드를 일부러 주입한 설정에서 나왔으므로 평상시 환각률로 옮겨 읽으면 안 됩니다.

읽는 방향은 두 갈래입니다. 자기 반성만으로는 0.32에 머물러 방어라 부르기 어렵고, 계보 기반 거버넌스는 0.89 이상으로 올립니다. 대신 0.32에서 0.94로 가는 값이 토큰 4.5배, 지연 2.4배입니다.

절제 실험이 더 중요한 것을 알려줍니다. 탐지는 하되 차단과 롤백을 뺀 변형은 토큰을 34,991개나 쓰고도 BICR이 3.1%에 그쳤습니다. 개입을 아예 하지 않은 설정의 2.2%와 사실상 같습니다. 판정만 내리는 검증기는 비용을 다 지불하고 전파를 막지 못한다는 뜻입니다.

검증기를 먼저 붙일 자리

앞의 근거를 모으면 도입 순서가 나옵니다. Anthropic은 'Building Effective Agents'에서 가장 단순한 해법을 먼저 찾고 필요할 때만 복잡도를 올리라고 권합니다. 같은 글은 자율성이 비용을 올리고 오류를 복리로 키운다고 명시합니다. 단일 에이전트에서 검증 계약이 서지 않으면 에이전트를 늘려도 서지 않는다는 것이 제 판단입니다.

검증기의 조건은 모델 밖에 있는 것입니다. 모델이 완료했다고 말하는 것은 성공의 증거가 아닙니다. 테스트 통과 여부, 스키마 충족, 도구의 실제 응답, 데이터베이스 상태, 사람 승인처럼 독립 신호로 판정해야 합니다. 앞 절의 절제 실험대로 이 검증기는 판정에 더해 격리와 롤백까지 할 수 있어야 값을 합니다.

멀티에이전트로 넘어가면 디버깅 자체가 어려워집니다. Who&When(arXiv:2505.00212, 2025-05)은 멀티에이전트 시스템 127개의 실패 로그로 자동 실패 귀속을 측정했습니다. 최고 방법이 책임 에이전트를 53.5%, 실패 단계를 14.2% 맞혔습니다. 어디서 깨졌는지를 절반쯤만 짚는 상태에서 에이전트를 늘리면 운영 부담이 함께 늘어납니다. 루프와 하네스 쪽 설계는 에이전트 하네스와 루프 엔지니어링에 정리해 두었습니다.

이 주장이 서지 않는 조건

이 판정 기준이 흔들리는 자리가 셋 있습니다. 첫째는 병렬 탐색이 과제의 본질인 경우입니다. 서브태스크가 서로 독립이면 조정 비용을 내고도 남는 이득이 나옵니다. 이 경계의 수치는 같은 평가 글에 있습니다.

둘째는 검증이 결정론적으로 끝나는 도메인입니다. 컴파일러나 정적 분석기, 스키마 검증기가 중간 결과의 진위를 확정하면 오염이 하류로 갈 통로가 좁아집니다. 이때는 오류 연쇄의 위험이 크게 줄어 멀티에이전트의 손익이 다시 계산됩니다.

셋째는 방어 기술의 성숙입니다. HalluProp(arXiv:2607.26836, 2026-07)은 에이전트가 발화하기 전에 실패 위험을 추론합니다. 역할과 질의의 의미 불일치로 내재 위험을 재고 전파 위험과 결합해, 결함 노드 국소화에서 평균 AUROC 84.6%와 사후 방식 대비 65배 이상의 속도를 보고했습니다. 다만 단일 연구의 보고이며 독립 재현은 확인하지 못했습니다.

한계도 분명히 적어 둡니다. 앞의 BICR 수치는 프레임워크 6개와 소수 데이터셋의 적대 설정에서 나온 값입니다. 그리고 이 글이 인용한 신뢰성 연구들은 대체로 단일 에이전트를 잰 것입니다.

2026-09 기준으로 확인한 반복 실행 연구도 마찬가지입니다. ReliabilityBench(arXiv:2601.06112)는 ReAct와 Reflexion 단일 에이전트를 잽니다. 행동 재현성 연구(arXiv:2605.28840)도 단일 도구 호출 에이전트가 대상입니다. 멀티에이전트의 pass^k 곡선을 같은 규모로 잰 공개 연구는 없으므로, 두 축을 잇는 마지막 고리는 추정입니다.

도입 전에 답해야 할 질문

판정은 다섯 질문으로 압축됩니다. 무인으로 반복 실행하는지, 단일 에이전트 기준선이 있는지, 오류가 들어올 자리가 허브인지, 검증기가 격리와 롤백을 하는지, 신뢰성의 값을 지불할 예산이 있는지입니다. 이 중 둘째 질문에 답하지 못하면 나머지는 비교 대상이 없어 무의미합니다.

조건별로 정리하면 다음 표가 됩니다.

표의 마지막 줄이 실무에서 가장 자주 걸립니다. 성능이 모자란 이유가 에이전트 수가 아니라 검증 계약과 컨텍스트인 경우가 많기 때문입니다.

정리

멀티에이전트 도입은 평균 점수가 아니라 신뢰성으로 판정해야 합니다. 역량과 신뢰성이 따로 움직이고, 오류는 허브를 통해 말단의 6배 이상 넓게 번지며, 개입이 두 단계 늦으면 되돌릴 오염이 세 배 가까이 늘기 때문입니다. 신뢰성을 사려면 토큰 4.5배와 지연 2.4배를 지불해야 하는데, 그 값을 내고도 판정만 하는 검증기는 전파를 막지 못합니다.

그래서 기본값은 단일 에이전트에 격리와 롤백이 가능한 검증기를 붙이는 구성이고, 멀티에이전트는 병렬 탐색이 본질이거나 중간 결과를 결정론적으로 확정할 수 있을 때 검토합니다. 도입 전에 단일 에이전트 기준선부터 만드는 것이 판정의 출발점입니다.