🤖 AI

LLM within MCP Matters: Measuring Inefficient Resource Utilization Driven by LLMs

이 연구는 거대 언어 모델이 행동적 선호도 때문에 모델 컨텍스트 프로토콜(MCP) 서버 지침에 효율적으로 임베딩된 참조 데이터를 검색 도구보다 우선시하여 무시하는 경우가 많다는 것을 밝히며, 이는 도구 선택보다 지침 컨텍스트를 우선시하도록 하는 명시적인 호스트 수준의 메커니즘이 필요함을 시사한다.

원저자: Minhan Cho, Soyoung Park, Kihyeon Jeong, Byeongkyu Jeon, Daejin Choi, Jinyoung Han

게시일 2026-08-11

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Minhan Cho, Soyoung Park, Kihyeon Jeong, Byeongkyu Jeon, Daejin Choi, Jinyoung Han

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

당신의 스마트 어시스턴트가 단순히 대화만 하는 것이 아니라, 문제를 해결하기 위해 방대한 도구와 데이터베이스를 즉각적으로 불러올 수 있는 초능력을 가진 세상을 상상해 보세요. 이것이 바로 **대규모 언어 모델(LLM)**이 **도구(tools)**와 함께 작동하는 흥미로운 최전선입니다. LLM을 많이 알고 있지만 가끔은 찾아봐야 하는 데는 똑똑하고 호기심 많은 학생이라고 생각해 보세요. 이 학생을 돕기 위해, 우리는 **모델 컨텍스트 프로토콜(Model Context Protocol, MCP)**이라는 새로운 표준을 가지고 있습니다. MCP는 학생의 "호스트"(학생을 실행하는 앱)가 특정 도구, 데이터, 그리고 그것들을 사용하는 방법에 대한 일련의 지침을 전달할 수 있게 해주는 유니버설 리모컨이라고 생각하면 됩니다.

연구자들이 던지는 핵심 질문은 이것입니다: 그 학생이 정말로 지침을 듣고 있는가? 때로는 지침에 "이 페이지에 당신이 필요한 답을 이미 써두었으니, 그냥 읽으세요!"라고 적혀 있기도 합니다. 하지만 또 다른 경우에는 "참고로, 원한다면 누를 수 있는 검색 버튼이 여기 있습니다"라고 적혀 있기도 합니다. 결과적으로, 아무리 똑똑한 학생이라도 눈앞에 놓인 답을 무시하고 반짝이는 검색 버튼에 한눈을 팔 수도 있다는 사실이 밝혀졌습니다. 이 논문은 바로 이 시나리오를 깊이 파고들어, "검색 습관"이 지침을 읽는 능력보다 더 강한지, 만약 그렇다면 어떻게 해결할 수 있는지를 살펴봅니다.

위대한 "메뉴 읽기" vs "웨이터 부르기" 실험

이 연구에서 연구자들은 한국 법률을 찾는 데 도움을 주는 서버인 **렉스링크(LexLink)**라는 디지털 주방을 설정했습니다. 이 서버는 마치 레스토랑의 메뉴판과 같습니다. 보통 특정 요리(법률)를 원한다면, 웨이터(검색 도구)에게 주방으로 가서 레시피를 찾아 가져다 달라고 요청해야 합니다. 이는 시간과 노력이 듭니다.

하지만 레스토랑 주인(서버)은 영리하게 결정했습니다. 테이블 위에 가장 인기 있는 메뉴 20개와 정확한 주문 번호를 포함한 "오늘의 특선 메뉴" 리스트를 인쇄해 둔 것입니다(서버 지침). 규칙은 간단했습니다: 만약 리스트에 있는 요리를 원한다면, 웨이터에게 직접 주문 번호를 말하세요. 주방을 검색하라고 요청하지 마세요! 이는 더 빠르고 저렴한 방식입니다.

연구자들은 그 후 클로드(Claude), 제미나이(Gemini), GPT와 같은 가족 계열의 24가지 서로 다른 AI 학생들을 초대하여 이 메뉴로 주문하게 했습니다. 그들은 AI 학생들이 "오늘의 특선 메뉴" 리스트를 읽고 직접 주문할 것인지, 아니면 리스트를 무시하고 여전히 "검색" 버튼을 누를 것인지를 확인하기 위해 54,000회의 실험을 수행했습니다.

충격적인 발견: 검색 버튼의 유혹이 너무 강하다

결과는 다소 경종을 울리는 것이었습니다. 연구자들이 검색 버튼을 완전히 제거하여 학생들이 테이블 리스트를 반드시 사용하도록 강제했을 때, 24개의 AI 모델 중 23개가 리스트를 읽고 정확하게 주문하며 **98%에서 100%**의 성공률을 보였습니다. 이는 학생들이 지침을 읽을 수 있다는 것을 증명했습니다. 다만 검색 버튼이 있을 때는 그러고 싶어 하지 않았을 뿐입니다.

하지만 검색 버튼이 존재할 때, 이야기는 극적으로 변했습니다. 24개 중 9개의 모델은 성공률이 15% 미만으로 떨어졌습니다. 그들은 답이 바로 테이블 위에 있음에도 불구하고 "오늘의 특선 메뉴" 리스트를 완전히 무시하고 계속해서 검색 버튼을 눌렀습니다. 연구자들은 이를 **"행동적 선호(behavioral preference)"**라고 부릅니다. AI가 지침을 읽기에 너무 멍청해서가 아닙니다. 비효율적인 선택임에도 불구하고 자신이 가장 잘 아는 도구에 손을 뻗는 습관을 가지고 있는 것입니다. 이는 마치 정답이 5페이지에 있다는 것을 알면서도 선생님에게 책 5페이지를 펴달라고 계속 요청하는 아이와 같습니다.

흥ertz하게도, "최신형"이거나 "더 똑똑하다"는 것이 더 나은 행동을 보장하지는 않았습니다. 일부 매우 최신 모델들이 오히려 이전 세대의 형제들보다 이 특정 규칙을 따르는 데 더 서툴렀습니다. 연구는 모델의 최신성이 이런 상황에서 누가 좋은 경청자가 될지를 예측하지 못한다는 것을 발견했습니다.

그들에게 듣는 법을 가르칠 수 있을까? (마법의 공식)

연구자들은 테이블 위의 지침을 변경하여 이 나쁜 습관을 고치려고 시도했습니다. 그들은 세 가지 다른 기술을 테스트했습니다:

강압적인 헤더 (B): "반드시 리스트를 사용해야 합니다! 검색하지 마세요!"라는 크고 굵은 경고 문구.
예시 (C): 올바르게 하는 모습과 잘못하는 모습을 보여주는 그림.
힌트 (D): 검색 버튼의 설명을 "저를 사용하기 전에 리스트를 먼저 확인하세요"라고 변경함.

그들은 가능한 모든 조합으로 이 기술들을 섞어서 테스트했습니다. 결과는 단 하나의 기술만으로는 모두에게 통하지 않는다는 것을 보여주었습니다. 실제로 어떤 AI 모델들에게는 "강압적인 헤더"만 사용하는 것이 오히려 성능을 떨어뜨려 (한 사례에서는 0%까지 하락!) 더 나쁜 결과를 초 thấy했습니다. 이는 큰 소리로 외치는 것이 어떤 학생에게는 공부하게 만드는 자극이 되지만, 어떤 학생은 얼어붙게 만드는 것과 같습니다.

하지만 세 가지 기술을 모두 결합했을 때, 결과는 놀라웠습니다. 24개 중 20개의 모델이 성공률 86% 이상으로 다시 올라갔습니다. 이는 AI에게 단순히 소리를 지른다고 해서 습관을 고칠 수는 없지만, 경고, 예시, 힌트를 결합한 다각적인 접근 방식이 대부분의 모델을 다시 궤도에 올려놓을 수 있음을 시사합니다.

이것이 미래에 의미하는 바

주요 시사점은 AI에게 도구와 지침을 주는 것만으로는 충분하지 않다는 것입니다. AI는 지침을 무시하게 만드는 "검색 반사(search reflex)"를 가질 수 있으며, 이는 시간과 자원의 낭비로 이어집니다. 이 논문은 이러한 AI를 실행하는 앱(호스트)이 개입해야 한다고 주장합니다. AI가 지침을 읽기를 기대하는 대신, 앱이 AI가 도구를 선택하기도 전에 지침을 먼저 확인하도록 강제해야 합니다.

그렇게 될 때까지 개발자들은 주의를 기울여야 합니다. 단순히 하나의 지침을 작성하고 그것이 모든 AI에게 작동할 것이라고 기대해서는 안 됩니다. 지침을 사용할 것으로 예상되는 "가장 약한" 모델을 기준으로 지침을 테스트해야 하며, 단순히 명령을 내리기보다는 예시와 힌트를 혼합하여 사용해야 합니다. 이 연구는 문제가 실재하지만, 적절한 지침의 레시피를 통해 해결 가능하다는 것을 보여줍니다.

기술 요약: LLM의 MCP 관련 이슈: LLM에 의한 비효율적 자원 활용 측정

문제 정의

모델 컨텍스트 프로토콜(Model Context Protocol, MCP)은 서버가 LLM에 데이터와 도구를 노출하는 방식을 표준화한다. 흔히 사용되는 설계 패턴 중 하나는 자주 사용되는 참조 데이터(예: 식별자 조회 테이블)를 클라이언트 LLM에 제공되는 서버 지침(Server Instructions)—즉, 시스템 프롬프트 텍스트—에 직접 포함시키는 것이다. 이론적으로 이는 모델이 알려진 항목에 대해 도구 호출(예: 검색)을 거치지 않고 데이터를 바로 활용하게 함으로써 토큰 사용량과 지연 시간을 줄일 수 있게 한다.

그러나 이 패턴의 효용성은 대규모 환경에서 검증되지 않은 상태이다. 서버가 이러한 지침을 제공하더라도, 클라이언트 LLM은 가용한 도구 스키마 대신 해당 지침을 따를지 여부를 스스로 결정해야 한다. 기존의 증거들은 서버 지침에 대한 준수율이 낮고 지침 계층 구조에서 실패가 발생함을 시사한다. 본 논문은 클라이언트 LLM이 실제로 지침에 내장된 데이터를 소비하는지, 아니면 필요한 데이터가 컨텍스트에 명시적으로 제공되었음에도 불구하고 검색 도구를 호출하려는 행동적 선호도를 보이는지 조사한다.

방법론

저자들은 한국 법률 정보 검색을 위한 프로덕션 MCP 서버인 LexLink를 사용하여 대규모 경험적 연구를 수행하였다.

테스트베드: 서버는 26개의 도구를 노출한다. 가장 빈번하게 요청되는 20개의 법률에 대해, 서버 지침은 법률 명칭과 ID를 매핑하는 테이블을 내장하고 있다. 효율적인 클라이언트는 ID를 먼저 확인하기 위해 eflaw_search를 호출하는 대신, 캐싱된 ID를 사용하여 eflaw_service를 직접 사용해야 한다.
평가 대상 모델: 세 가지 제공업체(Anthropic Claude 9개, Google Gemini 6개, OpenAI GPT 9개)에 걸친 24개의 LLM으로, 다양한 세대와 성능 티어를 포괄한다.
규모: 54,000회의 시행 (24개 모델 × 9개 조건 × 5개 쿼리 × 50회 라운드).
지표: 적중률 ( $\phi$ ): 모델의 첫 번째 도구 호출이 캐싱된 ID를 포함한 올바른 eflaw_service인 비율. 그 외의 다른 첫 번째 호출(검색을 포함하거나 잘못된 ID를 사용하는 경우)은 미스(miss)로 간주한다.
실험 조건:
- 베이스라인(Baseline): 임베디드 테이블과 검색 도구가 모두 포함된 표준 서버 지침.
- 진단용(no_s): 검색 도구를 완전히 제거함. 이를 통해 역량(모델이 테이블을 읽을 수 있는가?)과 선호도(모델이 도구 대신 테이블을 선택하는가?)를 분리하여 측정한다.
- 요인별 개입 ( $2^3$ ): 세 가지 지침 수준의 수정 사항을 개별적으로 또는 조합하여 테스트하였다:
  - B (지시형, Directive): 캐싱된 ID를 직접 사용할 것을 명령하는 "CRITICAL" 헤더 추가.
  - C (퓨샷, Few-shot): 올바른 패턴과 잘못된 패턴을 대조하는 예시 제공.
  - D (도구 힌트, Tool Hint): 사용자가 지침 테이블을 먼저 확인하도록 경고하는 문구를 검색 도구 설명에 추가.

주요 결과

역량 vs. 선호도:
- no_s 조건(검색 도구 제거) 하에서, 24개 모델 중 23개가 98% 이상의 적중률을 달성하였으며, 이는 모델이 지침에 내장된 데이터를 읽고 활용할 수 있는 역량을 갖추고 있음을 입증한다.
- 베이스라인 조건(검색 도구 존재) 하에서는, 9개 모델이 15% 미만으로 급락하였다.
- 결론: 실패의 원인은 지침을 파싱하는 능력의 부족이 아니라, 검색 도구를 호출하려는 행동적 선호도에 의해 발생한다. 검색 도구의 존재 자체가 많은 모델에게 내장된 데이터보다 도구 호출을 우선시하게 만든다.
비단조적 성능(Non-Monotonic Performance):
- 효율성은 모델의 최신성이나 세대와 상관관계를 보이지 않았다. 주목할 만한 퇴보 현상이 관찰되었다:
  - GPT-4.1 (99%) $\to$ GPT-5 (1%).
  - Gemini 2.5-pro (100%) $\to$ Gemini 3-pro (2%).
  - Claude Opus 4.5 (100%) $\to$ Opus 4.6 (63%).
- 이는 에이전트 벤치마크에 대한 사후 학습(post-training)이 의도치 않게 컨텍스트 데이터를 무시하는 도구 호출 정책을 강화할 수 있음을 시사한다.
요인별 개입 분석:
- 개별 개입(B, C 또는 D)은 변동성이 컸으며 오히려 역효과를 낼 수 있었다. 예를 들어, 지시형(B)만 적용했을 때 GPT-5.2의 성능은 5%에서 0%로 떨어졌다.
- 상호작용 효과: 요인들 사이에 강력한 상호작용이 존재한다. 세 가지를 모두 결합(BCD)했을 때, 24개 모델 중 20개 모델에서 성능이 86% 이상으로 회복되었다.
- 단일 요인 설계로는 이러한 결정적인 상호작용과 개입이 성능을 저하시킬 수 있는 가능성을 놓쳤을 것이다.

의의 및 주장

본 논문은 **서버별 프롬프트 엔지니어링은 해결책이라기보다 임시방편(workaround)**이라고 주장한다. 개별 개입이 모델 제품군에 따라 실패하거나 결과를 뒤집을 수 있기 때문에, 지침 튜닝에만 의존하는 것은 취약하다.

저자들은 세 가지 시사점을 제안한다:

공동 역량 평가: MCP 서버의 역량은 독립적으로 평가될 수 없으며, 클라이언트 LLM의 행동에 크게 의존한다.
호스트 측 메커니즘: MCP 호스트 애플리케이션(예: Claude Desktop, Cursor)은 클라이언트 LLM의 숙고 과정에서 서버 지침을 우선순위에 두도록 하는 명시적인 메커니즘을 제공해야 한다(예: 지침을 시스템 우선순위 지시사항으로 사전 주입하거나, 도구 선택 전 "지침 우선 확인" 절차를 강제함).
서버 개발자 가이드라인: 개발자는 퓨샷 예시(모든 모델에서 긍정적이거나 미미한 효과를 보임)를 포함하고, 더 넓은 범위를 커버하기 위해 여러 유형의 개입(B, C, D)을 조합해야 하며, 가장 약한 성능을 보일 것으로 예상되는 클라이언트 모델을 기준으로 검증해야 한다.

본 연구는 단일 서버 도메인(법률 조회)과 단일 턴 상호작용에 국한된다. 네 가지 추가 MCP 서버(지리, 학술, 데이터베이스, 메시징)에 대한 확장 연구가 진행 중이지만, 저자들은 현재 보고된 결과에 대한 근거로서 이들의 예비 결과가 **전망(outlook)**으로서 인용되었음을 명시적으로 밝히고 있다.