원문 정보
Antonio Ken Iannillo, Joshua Segun Owotogbe, Roberto Natella, Francesco Avallone, Kristina Kudryavtseva, Indika Kumara, "Tool-Calling LLM Agents Under Realistic MCP Faults: Scale Does Not Purchase Fault Tolerance", arXiv:2610.32555 [cs.SE, cs.AI], 2026-10-23 제출. 소속: 룩셈부르크대(SnT)·틸부르흐대·그란사소 과학연구소·나폴리 페데리코2세대. 원문 전문은 GitHub Actions가 2026-10-26T22:07:58Z에 수집한 스냅숏(HTML 전문 사본)으로 대조했습니다 — 이번 실행이 세션 egress 전면 차단(무관 대조군 example.com 포함 403)을 10분 간격 3회 재확인한 뒤의 공식 폴백입니다.
동료심사를 거치지 않은 arXiv 프리프린트입니다. cs.SE(소프트웨어공학)·cs.AI 분류의 실증 평가 논문으로, 저자 6인 전원이 대학·연구소(룩셈부르크대·틸부르흐대·그란사소과학연구소·나폴리 페데리코2세대) 소속입니다. 자금 고지는 네덜란드 SURF의 전산 자원 지원(할당 EINF-16024) 하나뿐이며, 저자들은 "경쟁 이해관계 없음"을 본문에 명시했습니다.
연구 개요
연구 질문은 두 가지입니다 — ① MCP(Model Context Protocol)로 도구를 호출하는 LLM 에이전트가 실제 운영 환경에서 벌어지는 도구 장애를 만났을 때 얼마나 버티는가, ② 모델을 더 크게 키우면 그 내성도 함께 커지는가. 기존 툴콜링 벤치마크는 도구가 항상 정상 응답한다고 가정해 이 질문에 답하지 못한다는 문제의식에서 출발합니다.
저자들은 MCP 호출 경로에 끼워 넣는 프록시형 중간계층 MCP-Injector를 만들고, 공개 MCP 서버 저장소 1,774개의 이슈·PR 스레드 57,240건을 LLM(gpt-4o-2024-08-06)으로 분류해 실제 장애 유형(지연 응답·무응답·오류 반환·오출력·무효 출력·경미한 오류)과 지속성(영구·간헐·일시) 분포를 추출, 이를 그대로 주입 프로파일로 삼았습니다. 분류 신뢰도는 독립 검수자 두 명이 117건을 표본 검수해 Cohen's κ=0.93(장애 유형)·0.80(지속성)으로 확인했습니다. 이 분포는 영구 장애가 91.3%로 압도적인데, GitHub 이슈가 재현 가능한 영구 장애를 과대표집하는 경향을 반영한 것이라 저자들도 이를 "스트레스 프로파일"로 못박습니다.
실험은 2개 백본(gpt-oss-20B·120B) × 3개 에이전트 스택(MCPBench 자체 플랜·실행 루프, OpenAI Agents SDK, LangChain create_agent) × 3개 조건(프록시 꺼짐, 무장애 통과 OP0, 장애 주입 OPP) × 25개 과제 × 3시드로 1,350칸을 구성한 완전요인설계입니다. 평가는 MCP-Bench 과제셋에 LLM-as-judge(gpt-4o-mini, 평가 5회 중앙값 집계)로 9개 지표를 매겼습니다.
핵심 결과
장애를 주입하자(OPP) 작업완성 점수가 무장애(OP0) 8.08점에서 3.23점으로 60% 떨어졌습니다(쌍대 차이 −4.85점, 95% CI [−5.22, −4.48]). 9개 지표 전부가 54~68% 떨어졌고(벤저민-호크버그 보정 Wilcoxon p<0.001), 양쪽 조건 모두에서 완료된 셀만 따로 봐도 57% 하락이 유지됩니다 — 완료 실패가 아니라 완료된 작업 자체의 품질 저하가 주된 원인입니다.
| 지표 | OP0(무장애) | OPP(장애 주입) | 변화 | 하락률 |
|---|---|---|---|---|
| 작업완성(Task completion) | 8.08 | 3.23 | −4.85 | −60% |
| 도구 선택(Tool selection) | 8.10 | 3.36 | −4.74 | −59% |
| 계획 효과성(Planning eff.) | 7.51 | 2.49 | −5.02 | −67% |
| 작업 충족(Task fulfillment) | 8.07 | 3.37 | −4.70 | −58% |
| 근거 있는 충족† | 7.70 | 2.83 | −4.87 | −63% |
| 근거성(Grounding) | 8.09 | 3.10 | −5.00 | −62% |
| 도구 적합성 | 8.21 | 3.81 | −4.40 | −54% |
| 파라미터 정확성 | 8.00 | 2.91 | −5.08 | −64% |
| 의존성 인지 | 7.94 | 2.75 | −5.19 | −65% |
† 도구 적합성이 2점 이상일 때만 작업 충족을 인정한 지표입니다. 완료된 작업 중 27개 셀(6.0%)은 도구를 제대로 안 쓰고도 그럴듯한 답을 내 높은 점수를 받는 "도구 우회(tool bypass)"였고, 이 중 17개는 애초에 도구를 한 번도 부르지 않아 장애 자체가 적용될 길이 없던 셀이었습니다. 이런 셀을 빼면 작업완성 하락률은 60%에서 67%로 더 벌어집니다 — 보고된 60%는 오히려 과소 추정 쪽이라는 뜻입니다.
두 번째 핵심은 모델 크기입니다. 장애 주입(OPP) 조건의 완성률은 20B 95.6%[92.0, 97.6] 대 120B 91.1%[86.7, 94.2]로, 더 큰 모델이 오히려 낮았습니다(차이 4.4%p, 95% CI [−0.2, 9.3], Fisher 정확검정 p=0.088 — "0과 다르다"고 확정하기엔 애매한 구간입니다). 무장애 기준 완성률도 이미 120B가 더 낮고(96.9% 대 99.1%), 장애로 인한 순수 하락분은 120B −5.8점[−10.4, −1.4] 대 20B −3.6점[−7.2, −0.5]으로 구간이 넓게 겹칩니다. 저자들은 이를 "스케일 효과"로 단정하지 않고 서술적 관찰로만 다룹니다.
세 번째는 에이전트 하네스(스택) 차이입니다. 완성률(OPP)은 LangChain 95~97%, MCPBench 91~95%, OpenAI 88~95% 순이었고, 혼합효과모형에서 MCPBench는 LangChain보다 0.93점 더 손실(95% CI [−1.86, −0.01], p=0.048), OpenAI는 0.84점 더 손실(p=0.074, 경계적)이었습니다. 저자들은 다중비교 보정을 하지 않았고 신뢰구간이 0에 가까워 "암시적" 수준이라고 선을 긋습니다. 장애에 노출된 450개 OPP 셀 중 가장 흔한 결과는 완전 실패가 아니라 부분 저하였습니다(56%, 스택·모델별로는 44~71%).
신뢰도 평가
동료심사를 거치지 않은 arXiv 프리프린트입니다(2026-10-23 제출). 저자 6인 전원이 대학·연구소 소속이고, 자금 고지는 SURF 전산 자원 지원 하나뿐이며 저자들은 경쟁 이해관계가 없다고 명시했습니다. 평가 대상 모델(gpt-oss 계열)이나 세 에이전트 프레임워크 중 어느 쪽도 저자 소속과 연결되지 않아, 자사 제품을 자사가 평가하는 유형의 이해상충은 보이지 않습니다.
믿을 근거는 셋입니다. 첫째, 장애 프로파일이 임의 가정이 아니라 57,240건의 실제 MCP 이슈·PR 스레드에서 추출한 경험적 분포이고, 분류 신뢰도를 독립 검수(κ=0.93·0.80)로 확인했습니다. 둘째, 장애 미적용(OP0)·프록시 꺼짐 두 통제 조건을 모두 둬서 중간계층 자체가 성능을 깎아먹는지(비개입성)를 별도로 검증했습니다. 셋째, 모든 발견에 효과크기와 95% 신뢰구간을 병기하고 다중검정에는 보정(벤저민-호크버그)을 적용했습니다.
감안할 점도 뚜렷합니다. 저자들이 '한계' 절에서 직접 밝혔듯, 이 장애 프로파일은 2025년 9월 기준 오픈소스 MCP 생태계의 이슈 보고 편향을 그대로 물려받은 분포이며, 비적대적 위협모델(의도적 공격이 아닌 운영 장애만 다룸)을 전제합니다. 두 백본이 같은 모델 계열(gpt-oss)·같은 서빙 환경(Apple Mac Studio, 16K 컨텍스트)이라 스케일 효과를 일반화하기엔 이르고, 스택 간 차이(p=0.048·0.074)도 다중비교 보정 없이 나온 '암시적' 수준입니다. 상반된 증거로는, 가장 가까운 선행 연구인 ReliabilityBench(관련 연구 참고)가 레이트리밋 장애를 가장 치명적이라고 지목한 반면 이 논문은 영구 오류(explicit_error) 단독이 65.6%를 차지하는 전혀 다른 분포를 썼다는 점에서, '어떤 장애가 가장 위험한가'에 대한 결론은 아직 수렴하지 않았습니다.
관련 연구
- Gupta(2026). ReliabilityBench: Evaluating LLM Agent Reliability Under Production-Like Stress Conditions — 이번 논문이 "가장 가까운 선행 연구"로 직접 인용한 벤치마크입니다(prior). 2개 모델·2개 아키텍처·4개 도메인·1,280 에피소드 규모로 타임아웃·레이트리밋·부분 응답·스키마 변형을 주입해, 레이트리밋 장애가 가장 치명적이고 ReAct가 Reflexion보다 안정적이라고 보고합니다(WebSearch로 독립 확인 — 이번 논문이 재현한 수치는 아님). 이번 논문은 장애 분포를 임의 설계가 아니라 57,240건의 실제 이슈·PR에서 경험적으로 추출했다는 점, 모델 스케일보다 에이전트 하네스 차이가 더 크게 나타난다는 결론에서 갈립니다.
- (2026). Real Faults in Model Context Protocol (MCP) Software: a Comprehensive Taxonomy — 실무자 설문으로 검증한 MCP 장애 분류 체계로, 이번 논문의 장애 유형 추출과 같은 "실제 장애를 먼저 보고 분류한다"는 접근을 공유합니다(prior). 도구 탐색·등록 실패와 서버 플랫폼 비호환을 가장 심각한 범주로 꼽는데(WebSearch로 독립 확인), 이번 논문의 6개 연산자(지연·무응답·오류반환·오출력·무효출력·경미오류)는 이미 도구가 연결된 "호출 이후" 단계만 다뤄 범위가 더 좁습니다 — 두 분류를 합치면 MCP 장애의 전체 수명주기를 더 촘촘히 덮을 수 있습니다.
- Shinn 외(2023). Reflexion: Language Agents with Verbal Reinforcement Learning — 이번 논문이 관련 연구에서 직접 언급한 자가 교정 기법입니다(contradiction에 가까움). 에이전트가 실패를 언어로 반성해 다음 시도에 반영하는 방식으로 HumanEval 등에서 성능을 끌어올렸다고 보고합니다(WebSearch로 독립 확인). 그러나 이번 논문의 사례 분석은 에이전트들이 "장애를 한결같이 일시적인 것으로 취급하며 사소한 파라미터만 바꿔 재시도한다"는 패턴을 반복적으로 보였다고 지적합니다 — 반성 능력이 있어도 장애가 영구적이라는 진단 자체를 못 하면 Reflexion류 자가교정의 전제(도구는 결국 믿을 만하다)가 깨진다는 뜻입니다.
이번 리뷰가 다룬 수치(완성률·점수 하락률)는 모두 MCP-Injector 논문 자체가 재현한 것이고, 위 세 편의 구체 수치는 WebSearch로 독립 확인했을 뿐 이번 논문이 직접 재현하거나 같은 벤치마크로 비교한 것은 아닙니다.
리뷰어 판단
첫째, 이 논문에서 가장 주목할 결과는 "60% 하락"이라는 헤드라인이 아니라, 도구를 아예 호출하지 않고도 그럴듯한 답을 내는 '도구 우회' 패턴이 완료 셀의 6%를 차지했고 이를 빼면 하락률이 60%에서 67%로 더 벌어진다는 점이라고 판단합니다. 현재의 LLM-as-judge 채점 방식은 "도구를 못 써서 모른다고 답한 정직한 실패"와 "모르면서 아는 척한 답"을 구분하지 못하는데, 운영 환경에서 더 위험한 쪽은 후자입니다.
둘째, 모델 크기가 장애 내성을 사지 못한다는 결론을 "모델 스케일은 신뢰성과 무관하다"로 일반화하는 것은 과도하다고 봅니다. 이 실험은 같은 모델 계열(gpt-oss) 두 크기만 비교했고, 신뢰구간이 0을 가로지르는(p=0.088) 수준이라 "120B가 더 나쁘다"와 "차이가 없다" 둘 다 데이터와 양립합니다. 실무에서는 "큰 모델을 쓰면 장애 대응도 자동으로 좋아질 것"이라는 가정을 버리고 하네스 수준의 오류 처리에 투자하는 쪽이, 이 논문이 실제로 뒷받침하는 결론이라고 판단합니다.
실무 적용
- 모델 교체보다 하네스 점검 먼저 — 큰 모델로 바꾼다고 장애 내성이 따라오지 않습니다. 재시도·도구 전환·폴백 로직이 있는 하네스와 없는 하네스의 완성률 차이(최대 약 9%p)가 모델 크기 차이보다 더 크게 나타났습니다.
- 영구 장애를 1순위로 대응 — 실제 MCP 생태계 장애의 91.3%가 영구형이고 그중 65.6%가 explicit_error 단독입니다. 재시도 상한을 늘리는 대신, 영구 오류를 빠르게 식별해 다른 도구로 전환하는 로직을 우선 구축합니다.
- 도구 우회를 별도로 계측 — 응답 품질 점수만으로는 "도구 없이 아는 척한 답"을 걸러내지 못합니다. 도구 호출 여부·적합성을 작업 완성도와 별개 지표로 로깅해 거짓 양성을 가려냅니다.
- 미들웨어 비개입성 먼저 검증 — 장애 주입·관찰 미들웨어를 도입하기 전에 꺼진 상태와 정상 통과 조건의 점수 차이를 먼저 측정해, 테스트 장치 자체가 성능을 깎지 않는지 확인합니다.
- 하네스별 장애 대응 프로파일을 알고 선택 — 플랜-실행형(MCPBench류)은 도구 전환 위주, 메시지 루프형(OpenAI SDK·LangChain)은 포기·답변 위주로 반응이 갈립니다. 운영 중 장애 발생 시 원하는 행동에 맞춰 하네스를 고릅니다.
결론
이 논문의 기여는 MCP 툴콜링 에이전트의 장애 내성을 임의의 가상 장애가 아니라 실제 생태계에서 관측된 장애 분포로 측정하는 재현 가능한 도구(MCP-Injector)를 내놓은 것과, "모델을 키우면 알아서 안전해진다"는 통념을 1,350칸 실험으로 반박한 것입니다. 작업완성 점수가 60% 떨어지고, 그 하락의 상당 부분이 도구 없이 아는 척하는 '우회' 패턴에서 나온다는 점은 실무 배포 전 반드시 점검해야 할 실패 양상입니다. 다만 두 백본이 같은 모델 계열이라는 점, 스택 간 차이가 다중비교 보정 없는 암시적 수준이라는 점은 그대로 남는 한계입니다. 도구 호출 실패를 작게 쪼개 복구하는 설계 원칙은 멀티 툴콜 부분 실패 복구 설계에서 다루는 운영 체크리스트와도 통합니다.
참고 링크
- Tool-Calling LLM Agents Under Realistic MCP Faults: Scale Does Not Purchase Fault Tolerance — arXiv 초록(원문)
- 같은 논문 HTML 전문 — 표·수치 대조에 사용
- 멀티 툴콜 부분 실패 복구 설계 — sunny34.com 블로그
이 리뷰에 대해 AI와 대화하기
AI가 이 리뷰와 검증된 수치를 읽은 상태로 답합니다. 무엇이든 물어보세요 — 글에 없는 내용이면 없다고 먼저 알려줍니다.
대화창을 불러오는 중…