개발자용 MCP 오류 문구가 최신 에이전트를 멈춘다: 복구율 45%→84%, MCP 오류 메시지 실험 리뷰

원문 정보

Xiaonan Xu, Wenjing Wu, "MCP Error Messages Written for Developers Hurt the Most Capable Agents Most", arXiv:2609.35381 [cs.SE; cs.AI], 2026-09-28 제출(v1)·09-29 개정(v2, 인용 부호만 수정 — 수치 동일), 15쪽·표 6, Journal of Systems and Software 투고. 소속: 조지아공대 컴퓨팅대학(교신저자)·콜로라도대 볼더 컴퓨터과학과. 원문 전문은 2026-10-10 arXiv HTML(v1·v2)로 대조했습니다.

학술지 심사 중인 프리프린트입니다. 연구비 표기는 없고, 저자는 이해상충이 없다고 밝혔습니다. 시나리오·오류 문구·조사 데이터·모델 출력·코드를 GitHub(WenJing95/tool-error-text)에 공개해 재현이 가능합니다. 다만 실험한 다섯 모델이 모두 OpenAI 모델이라 다른 회사 모델에서도 같은 결과가 나오는지는 확인되지 않았습니다.

연구 개요

MCP 서버의 상당수는 사람 개발자를 위해 만든 웹 API를 감싼 것입니다(선행 연구 기준 공식 서버 116개 중 88.6%가 REST 기반). 그래서 오류 메시지도 "터미널에서 이 명령을 실행하세요", "설정을 바꾸세요", "잠시 기다렸다 다시 시도하세요"처럼 사람이 할 수 있는 행동을 권합니다. 그런데 이 문구를 읽는 쪽이 채팅 앱의 MCP 커넥터처럼 도구 호출밖에 할 수 없는 에이전트라면 어떻게 될까요. 논문은 세 단계로 답합니다.

먼저 GitHub 별 수 상위 MCP 서버 150개(공식 SDK 사용·최근 1년 내 갱신, 별 426~186,635개)의 소스에서 오류 메시지 3,001건을 찾아 분류했습니다(분류는 공개 코드북을 따른 OpenAI Codex 에이전트가 수행). 다음으로 BFCL V4 다중 턴 과제에서 7가지 실패 유형 × 24개, 모두 168개 시나리오를 만들고 오류 문구 6종을 바꿔 가며 GPT-5.5·GPT-5.6 Sol·GPT-6 Sol·GPT-6 Astra·GPT-6 Luna 다섯 모델로 15,120회 시행했습니다(추론 강도 high, 도구 호출 최대 8회, 2026-09-24·25·27 접속). 마지막으로 두 해법 — 서버 개발자가 문구를 "서버 도구 호출"로 고쳐 쓰기, 에이전트 개발자가 한 문장 프롬프트로 지시문을 지우기 — 을 시험했습니다(필터 시험 추가 1,440회).

핵심 결과

조사 결과부터 보면, 3,001건 중 949건이 "다음에 할 일"을 적었고 그중 477건은 서버가 알 수 없는 호출자 조건(도구·로그인·권한)에 따라 맞기도 틀리기도 하는 지시였습니다. 인증·권한·호출 한도 오류 209건에서는 지시 128건 중 99건이 호출자 의존이었고, 그중 93건이 MCP 도구만 쓰는 에이전트는 수행할 수 없는 일이었습니다. 인증 오류 지시 67건 중 62건이 설정·웹 페이지·터미널을 요구했고, 호출 한도 지시 30건 중 20건은 "기다렸다 재시도"라고만 했을 뿐 다시 부를 호출을 적은 것은 하나도 없었습니다.

실험에서 에이전트는 문구가 시키는 대로 했습니다. 로그인이 만료된 상황에서 원인만 알려 주면 평균 82%가 스스로 로그인 도구를 불러 복구했지만, 같은 문구에 "Please run: reddit-mcp-buddy --auth" 한 문장을 붙이자 45%로 떨어지고 55%의 시행이 복구 없이 끝났습니다. 지시를 "Call ticket_login first."처럼 서버 도구 호출로 고치면 84%, 한 문장 프롬프트(GPT-6 Luna로 실행)로 지시만 지우면 82%로 돌아왔습니다.

하락폭은 모델이 최신·대형일수록 컸습니다. GPT-5.5는 18%p, GPT-5.6 Sol 35%p, GPT-6 Sol 39%p, 가장 큰 GPT-6 Astra는 69%p(소형 GPT-6 Luna는 26%p)였고, Astra와 GPT-5.5의 차이 51%p는 95% 구간 29~72로 0을 넘습니다. Astra는 이 조건에서 시행당 도구 호출이 0.60회에 그쳤고, 복구 없이 끝난 68회 중 48회는 로그인 도구를 갖고 있으면서도 "다시 연결해 달라"며 사용자에게 수리를 넘겼습니다.

호출 한도 오류는 더 극적입니다. GitHub식 "Wait before retrying."에서는 평균 복구율이 6%였고 시행의 89~99%가 그대로 끝났습니다. 다시 부를 호출을 명시하자 88%로 올라 82%p(구간 75~88) 개선됐고, 비용은 도구 호출 0.37→1.42회, 토큰 3,098→5,409개로 호출 한 번 정도 늘었습니다.

실패가 에이전트 자신의 호출에 드러나는 유형(단위·형식 오류, 필수 필드 누락, 잘못된 도구, 없는 리소스)에서는 어떤 문구든 일반 안내 대비 4%p 안쪽 차이였습니다(원문 Table 6). 문구가 결정적인 것은 세션 만료·권한 부족·호출 한도처럼 오류 문구로만 원인이 보이는 실패였고, 권한 부족에서는 원인만 주면 0%, 로그인 도구를 명시하면 53%였습니다.

신뢰도 평가

믿을 근거: 같은 저장 상태에서 문구만 바꾸는 시나리오 내 비교라 다른 변수가 섞이지 않고, 복구 판정을 LLM 심판이 아닌 BFCL의 상태 검사로 해 채점 주관이 없습니다. 구간은 실패 유형 안에서 시나리오를 1만 번 재표집한 부트스트랩이고, 데이터와 코드가 전부 공개돼 있습니다. 조사 대상 오류 문구도 실제 서버에서 가져와 실험 문구에 그대로 썼습니다.

감안할 점: ① 다섯 모델 모두 OpenAI 모델이며 Claude·Gemini 등은 없습니다. ② "최신 모델일수록 문구를 더 문자 그대로 따른다"는 해석은 OpenAI·Anthropic의 프롬프트 가이드 서술과 일관된다는 정도이고 인과적으로 검증한 것은 아닙니다. ③ 조사 라벨은 사람이 아닌 Codex 에이전트가 붙였고 사람 검수 일치도는 보고되지 않았습니다. ④ BFCL 환경에서는 호출 한도 재시도가 즉시 성공하도록 설정돼 있어(실제 대기 없음), 실제 서비스에서 "다시 호출"이 같은 효과를 내는지는 별개 문제입니다.

관련 연구: 같은 방향을 가리키는 MCP 생태계 연구

• Mastouri et al.(2025). From REST to MCP: An Empirical Study of API Wrapping and Automated Server Generation for LLM Agents — 이번 논문의 전제를 제공한 선행 연구. 공식 MCP 서버 116개 중 88.6%가 REST 기반이고 92%가 API를 그대로 감싼 도구라는 수치가 여기서 나왔습니다. "개발자용 문구가 에이전트에게 그대로 흘러간다"는 문제의 구조적 원인입니다.
• Hasan et al.(2026). Model Context Protocol (MCP) Tool Descriptions Are Smelly! — 같은 렌즈를 도구 설명문에 댄 연구. 이번 논문은 그 시선을 오류 문구로 옮겨, 설명문뿐 아니라 실패 응답도 에이전트 성능을 좌우하는 인터페이스임을 보였습니다.
• Liu et al.(2026). When the Manual Lies: A Realistic Benchmark to Evaluate MCP Poisoning Attacks — 독립적인 같은 방향의 증거. 가장 능력 있는 모델이 도구 설명에 심긴 지시를 가장 충실히 따랐습니다. 악의적 지시(공격)와 선의의 지시(이번 논문)라는 차이만 있을 뿐, "최신 모델일수록 도구가 돌려준 문장을 지시로 받아들인다"는 결론이 겹칩니다.

선행 연구가 "도구 설명이 부실하다", "MCP 서버는 대부분 API 래퍼다", "강한 모델이 심긴 지시를 잘 따른다"를 각각 따로 보였다면, 이번 논문은 이 셋이 만나는 지점 — 래퍼가 상속한 개발자용 오류 문구를 강한 모델이 지시로 받아 멈춘다 — 을 통제 실험으로 측정했습니다.

리뷰어 판단

첫째, 이 논문의 가장 중요한 수치는 69%p가 아니라 "원인만"의 82%라고 판단합니다. 에이전트는 원래 고칠 수 있었습니다. 실패의 원인은 모델 능력이 아니라 도움이 되려고 덧붙인 한 문장이었고, 이는 프롬프트·도구 설계에서 "더 많은 안내 = 더 좋은 결과"라는 직관이 틀릴 수 있음을 보여 줍니다.

둘째, 모델을 올리면 같은 서버 문구가 더 큰 비용을 낸다는 점은 운영상 무겁습니다. 지금 잘 돌아가는 에이전트가 모델 버전 업그레이드만으로 인증 만료 복구율이 급락할 수 있다는 뜻이므로, 모델 교체 회귀 테스트에 "오류 경로" 시나리오를 반드시 넣어야 합니다. 성공 경로만 보는 평가 세트로는 이 회귀가 보이지 않습니다.

셋째, 두 해법의 위치가 다르다는 점을 실무에서 구분해야 합니다. 서버를 직접 운영하면 문구를 "서버 도구 호출"로 고치는 것이 가장 확실하고(인증 84%, 호출 한도 88%), 남의 서버를 연결하는 쪽이라면 지시 삭제 필터가 싸고(949건 전체 처리 비용 0.09달러) 효과도 있습니다. 다만 권한 부족·호출 한도에서는 원인만으로 복구가 거의 안 되므로(0%·5%) 필터를 일괄 적용하면 오히려 정답 지시까지 지웁니다 — 저자도 필터를 인증 오류에 한정하라고 권합니다.

넷째, 이 결과는 의미 계층 논의와도 연결됩니다. 에이전트에게 무엇을 할 수 있는지(도구 목록)와 실패했을 때 무엇을 하라는지(오류 문구)가 같은 어휘로 정렬돼 있어야 한다는 점에서, 오류 문구는 도구 온톨로지의 일부로 설계해야 할 대상이라고 봅니다.

실무 적용

• 오류 문구에 서버 도구 이름을 쓴다 — "재인증하세요" 대신 "auth_login을 먼저 호출하세요", "기다렸다 재시도" 대신 "몇 초 후 place_order를 다시 호출하세요". 사람 개발자에게도 그대로 통하는 유일한 형태입니다.
• 사람용 안내는 별도 필드로 분리 — 터미널 명령·설정 경로·웹 링크는 사람 운영자에게 보여 줄 필드로 빼고, 모델이 읽는 본문에는 원인과 도구 호출만 남깁니다(RFC 9457의 기계 판독용 problem details와 같은 발상).
• 제3자 MCP 서버에는 인증 오류 한정 필터 — 도구 응답이 인증 오류일 때만 "다음 할 일" 문장을 지우는 한 문장 프롬프트를 끼웁니다. 권한·호출 한도 오류에는 적용하지 않습니다.
• 모델 업그레이드 회귀 세트에 오류 경로 추가 — 세션 만료·권한 부족·호출 한도 시나리오를 실패 유형별로 두고 "복구 없이 끝난 비율"과 "사용자에게 수리를 넘긴 비율"을 지표로 봅니다.
• 연결 전 오류 문구 감사 — 새 MCP 서버를 붙이기 전에 소스나 응답 샘플에서 터미널·설정·웹 지시가 있는지 확인합니다. 이 연구의 조사 기준으로는 인증 오류 지시의 93%(67건 중 62건)가 해당했습니다.

결론

이 논문은 MCP 에이전트의 실패 원인이 모델이 아니라 서버가 돌려준 한 문장일 수 있음을, 그리고 그 비용이 최신 모델일수록 커질 수 있음을 공개 데이터로 보였습니다. OpenAI 모델에 한정된 결과이고 모델 성향에 대한 해석은 아직 가설이지만, 해법이 단순하고 측정된 효과가 커서 서버 개발자와 에이전트 개발자 모두 바로 적용할 수 있습니다.

에이전트가 연결하는 MCP 서버와 의미 계층이 늘어날 때 운영팀이 무엇을 점검해야 하는지는 같은 날 블로그 글 구글 Gemini 에이전트, 모든 MCP 서버와 지식 카탈로그 연결에서 이어집니다.

참고 링크

• MCP Error Messages Written for Developers Hurt the Most Capable Agents Most — arXiv 초록(원문)
• 같은 논문 HTML 전문(v2) — Table 1·4·5·6 수치 대조에 사용
• 저자 공개 데이터·코드(GitHub)
• From REST to MCP(arXiv:2507.16044)
• MCP Tool Descriptions Are Smelly!(arXiv:2602.14878)
• When the Manual Lies: MCP Poisoning Benchmark(arXiv:2605.24069)
• 구글 Gemini 에이전트, 모든 MCP 서버와 지식 카탈로그 연결 — sunny34.com 블로그