컨텍스트 엔지니어링 실패모드 위키

깊이읽기 — 컨텍스트 혼란, 왜 도구를 많이 주면 멍청해지는가

21 min read

볼트 홈: README

깊이읽기 — 컨텍스트 혼란, 왜 도구를 많이 주면 멍청해지는가

한 줄 정의

컨텍스트 혼란(Context Confusion)은 모델이 약해서가 아니라 컨텍스트에 쓸모없는 정보, 특히 과도한 도구 정의를 너무 많이 넣어서 응답 품질이 떨어지는 실패모드다. 직관은 한 줄로 충분하다. “넣으면 모델은 본다.”

왜 중요한가

2025~2026년의 에이전트 붐은 MCP(Model Context Protocol)를 타고 왔다. “에이전트에 도구 수백 개를 연결할 수 있다”는 약속은 매혹적이다. 그런데 막상 도구를 50개, 100개, 150개 붙여 보면 이상한 일이 벌어진다. 모델이 더 똑똑해지기는커녕 더 멍청해진다. 엉뚱한 도구를 부르고, 있지도 않은 도구를 지어내고, 분명히 줬던 지시를 까먹는다.

이게 컨텍스트 혼란이다. 게다가 이 실패는 조용하다. 100% 실패하는 게 아니라 때로는 되고 때로는 망하는 패턴으로 온다(03_02-툴-과부하-MCP-실태). 그래서 모니터링으로 잡기 어렵고, 데모에서는 멀쩡하다가 프로덕션에서 무너진다. AI 강사와 AX 컨설턴트가 현장에서 가장 자주 마주치는 함정이 바로 이것이다.

1. 직관 잡기 — 망치를 못 찾는 목수

당신이 목수다. 책상 위에 망치 하나만 있으면, 못을 박으라는 주문이 들어왔을 때 0.5초 만에 망치를 집는다. 그런데 누가 “도구가 많을수록 좋겠지” 하며 책상 위에 드라이버, 줄자, 대패, 톱, 사포, 끌, 컴퍼스까지 200개를 늘어놓았다고 하자. 이제 못을 박으려면 그 200개 더미를 스캔해서 망치를 찾아내야 한다. 망치는 분명 거기 있다. 하지만 찾는 데 시간이 걸리고, 가끔은 줄자를 집어 들고 못을 두드린다.

이게 컨텍스트 혼란의 본질이다. 도구가 없어서 실패하는 게 아니라, 도구가 너무 많아서 정작 맞는 도구를 못 고르는 것이다.

여기서 가장 자주 깨지는 직관 하나를 못 박아 두자. 트랜스포머의 어텐션은 “쓸 정보만 골라 보는” 선택적 시선이 아니다. 컨텍스트에 들어간 모든 토큰은 어텐션 계산에 참여한다. 그러니까 컨텍스트는 모델이 볼 수 있는 공간이 아니라 반드시 봐야 하는 공간이다(03_01-정의와-메커니즘). 책상 위 200개 도구를 목수가 안 보고 넘길 수 없는 것과 같다. 일단 거기 있으면 시야에 들어오고, 시야를 차지하는 만큼 망치에 쏠릴 집중이 희석된다. 이것이 어텐션 희석(attention dilution)이다.

흔한 오해 ① "관련 있으면 넣어도 되잖아?"

가장 비싼 오해다. 관련성(Relevance) ≠ 필요성(Necessity). 어떤 도구가 이 도메인과 관련 있다는 것과, 지금 이 요청을 처리하는 데 필요하다는 것은 전혀 다르다. 줄자는 목공과 관련 있지만 못 박기에는 필요 없다. 컨텍스트에 넣을지 말지는 관련성이 아니라 지금 이 태스크에 필요한가로 판단해야 한다.

2. 서사 — 혼란이 자라나는 과정

시작: 한 개의 MCP 서버

처음엔 좋다. Playwright MCP 하나를 붙인다. 웹 자동화가 된다. 만족스럽다. 그런데 이 단일 서버 하나가 이미 Claude Sonnet 4의 200K 컨텍스트 중 22.2%를 차지한다(03_02-툴-과부하-MCP-실태). 작업을 시작하기도 전에 컨텍스트의 5분의 1이 도구 설명서로 채워진 것이다.

악화: 서버를 더 붙인다

GitHub MCP를 붙인다. IDE MCP를 붙인다. 혹시 모르니까 DB MCP도. 5개 서버 × 30개 도구 = 150개 도구 ≈ 30,000~60,000 토큰, 200K의 25~30%를 잡아먹는다. 여기서 결정적인 구조적 함정이 작동한다. LLM은 상태가 없다(stateless). 매 요청마다 전체 도구 목록을 처음부터 다시 받아야 한다. 지금은 안 쓸 도구를 옆으로 치워두기가 구조적으로 불가능하다(03_02-툴-과부하-MCP-실태). 목수가 매번 작업을 시작할 때마다 책상 위 200개를 처음부터 다시 훑어야 하는 상황이다.

발현: 에이전트가 무너지는 실제 모습

이쯤 되면 어텐션 희석이 임계점을 넘는다. 에이전트는 다음과 같이 행동한다(03_01-정의와-메커니즘):

  • 잘못된 도구 선택 — 비슷한 이름의 다른 도구를 부른다.
  • 도구 환각(tool hallucination) — 존재하지 않는 도구를 지어낸다.
  • 잘못된 파라미터·체이닝 — 맞는 도구를 골라도 인자를 틀린다.
  • 툴 바이패스(tool bypass) — 가장 위험하다. 도구를 실제로 호출하지 않고 결과를 시뮬레이션해 버린다. 보안·감사 통제를 통째로 우회하므로 프로덕션에서 치명적이다.
  • 지시 망각 — 시스템 프롬프트에 줬던 규칙을 흘려보낸다.

Anthropic도 같은 진단을 내놓는다. “우리가 보는 가장 흔한 실패모드 중 하나는 너무 많은 기능을 덮으려는 비대한 도구 세트, 혹은 어떤 도구를 써야 할지 모호한 결정 지점이다.” 에이전트를 망치는 건 종종 모델이 약해서가 아니라 컨텍스트를 너무 많이, 너무 무질서하게 채워서다(03_01-정의와-메커니즘).

flowchart TD
    A[사용자 요청] --> B{도구 로딩 방식}
    B -->|전체 로드| C["150개 도구 정의<br/>≈ 30K-60K 토큰<br/>컨텍스트의 25-30% 점유"]
    B -->|동적 선택| D["관련 3-7개만 로드<br/>≈ 2K 토큰"]
    C --> E[어텐션 희석]
    E --> F[잘못된 도구 선택]
    E --> G[도구 환각]
    E --> H[지시 망각]
    F & G & H --> I[태스크 실패 · 비용 폭증]
    D --> J[정확한 도구 선택]
    J --> K[고품질 응답 + 비용 절감]

3. 대표 발현이 왜 하필 ‘MCP 도구 과부하’인가

혼란은 원리상 어떤 무관한 정보든(문서 덤프, 불필요한 예시) 일으킬 수 있다. 그런데 2025~2026년 현장에서 대표 사례가 하필 도구 과부하인 데는 세 가지 이유가 있다.

먼저 도구 정의는 매 요청마다 전량 반복된다. 한 번 들어가고 마는 첨부 문서와 달리, 도구 목록은 stateless 구조 때문에 호출마다 처음부터 다시 실린다. 쌓인 만큼 점유가 계속 불어난다.

게다가 도구 설명은 서로 닮았다. search_files와 find_documents처럼 의미가 겹치는 설명이 늘어나면, 모델이 어떤 걸 써야 할지 모호한 결정 지점이 폭증한다. 닮은 정보끼리는 더 강한 어텐션 경합(attention competition)을 일으킨다. Chroma Research가 보인 반직관적 결과처럼, 논리적으로 잘 정돈된 컨텍스트가 무작위로 섞인 것보다 오히려 성능이 낮을 수 있다(03_01-정의와-메커니즘). 망치 두 자루가 거의 똑같이 생겨 책상에 나란히 놓이면, 한 자루만 있을 때보다 오히려 고르기가 더 어려워지는 셈이다. 도구를 늘릴수록 늘어나는 것은 선택지가 아니라 혼동의 짝이다.

마지막으로 돈이 즉시 샌다. 5개 서버 150개 도구 = 6만 토큰 오버헤드를 하루 1만 회 호출하면, 도구 정의값만 하루 $1,800이 나간다(03_02-툴-과부하-MCP-실태). 동적 선택으로 절반을 줄이면 하루 $900, 연 약 $328,500을 절약한다. 혼란은 품질만 갉아먹는 게 아니라 청구서를 부풀린다.

흔한 오해 ② "컨텍스트 윈도우가 1M인데 6만 토큰쯤이야?"

윈도우 용량과 혼란은 별개 문제다. 핵심 실증이 이를 보여준다. 양자화 Llama 3.1 8B는 윈도우 용량은 충분한데도 도구 46개에서 실패하고 19개로 줄이자 성공했다(03_03-소형모델-취약성). 실패 원인은 공간 부족이 아니라 도구 선택 혼란 그 자체였다. 윈도우를 늘려도 혼란은 줄지 않는다. 오히려 더 많은 잡동사니가 들어갈 공간만 생긴다.

4. 소형 모델은 왜 더 빨리 무너지는가

이 대목이 AX 컨설팅에서 특히 중요하다. 비용 절감하겠다고 소형 모델을 에이전트로 깔면, 도구 관리를 훨씬 더 엄격하게 해야 한다.

Drew Breunig이 인용한 GeoEngine 실험이 결정적이다(03_03-소형모델-취약성):

도구 수결과
46개(전체)태스크 실패 (윈도우 용량 내인데도)
19개(제한)태스크 성공 (동일 윈도우)

같은 모델, 같은 윈도우. 차이는 오직 도구 수다. 대형 추론 모델은 불필요한 컨텍스트를 걸러 내는 능력이 조금씩 나아지고 있지만, 소형 모델은 그렇지 못해 같은 도구 수에서도 훨씬 빠르게 무너진다. 중형 모델(Claude Sonnet 4.6)조차 도구를 5개로 제한했을 때 93.1%, 전체 세트에서 87.1%로 떨어지며, 특히 중간 난이도 쿼리에서 격차가 76.8% 대 60.9%로 더 크게 벌어진다(03_03-소형모델-취약성).

숫자 주의

“19개”는 단일 모델, 단일 태스크의 관찰치다. 절대 임계값으로 일반화하지 말 것. 직관은 “소형일수록 도구를 가혹하게 줄여라”이지 “19가 마법의 숫자”가 아니다. 모델 규모별 실용 가이드(소형 10~20개, 중형 30~50개, 대형 동적 선택)도 참고선일 뿐이다.

graph LR
    subgraph SM["소형 8B 양자화"]
        A1["19개 이하<br/>성공"]
        A2["46개<br/>실패"]
    end
    subgraph MM["중형 Sonnet"]
        C1["5개<br/>93.1%"]
        C2["전체<br/>87.1%"]
    end
    subgraph LM["대형"]
        E1["동적 선택<br/>권장"]
    end
    style A2 fill:#e74c3c,color:#fff
    style C2 fill:#f39c12,color:#fff
    style A1 fill:#2ecc71,color:#fff
    style C1 fill:#2ecc71,color:#fff

5. 처방 — Less is More

혼란의 해법은 직관적이다. 덜 넣어라. 단, 막연한 “줄여라”가 아니라 구체적 기법이 있다(03_08-해결전략-less-is-more).

핵심은 동적 도구 선택(RAG-MCP)이다. 전체 도구를 매번 다 싣는 대신, 요청마다 관련 도구 3~7개만 검색해서 로드한다. 효과는 극적이어서 정확도가 13.62%에서 43.13%로, 약 3.17배 뛰고 토큰은 50% 이상 줄어든다(03 혼란). 책상 위에 200개를 늘어놓는 대신, 주문이 들어오면 그때 필요한 도구만 꺼내 주는 것이다.

보조 처방은 다음과 같다.

  • 컨텍스트 트리밍(프루닝+요약) — 완료율 +20.6%p, 토큰 63% 절감(Lodha et al. 2026, 03 혼란).
  • 서브에이전트 격리 — 각 에이전트가 자기 전문 도구만 보유한다. 충돌 표면도 함께 줄어든다.
  • 컨설팅 룰오브섬 — 총 컨텍스트 사용량을 40% 미만으로 유지한다. MCP 서버를 추가하기 전에 현재 점유율을 먼저 측정하고, 현재 태스크와 직접 관련 없는 서버는 비활성화한다(03_02-툴-과부하-MCP-실태).

흔한 오해 ③ "그래도 혹시 모르니 다 켜 두자"

“junk drawer(잡동사니 서랍)” 사고방식이다. 혹시 몰라 켜 둔 도구는 혹시 쓰이는 게 아니라 항상 어텐션을 갉아먹고 항상 청구서에 찍힌다. 혼란의 세계에서 보험은 비용이지 안전망이 아니다.

6. 2026 연구가 더해준 것

2025년의 “도구 많으면 멍청해진다”는 GeoEngine 일화나 Chroma 실험에 기댄 주장에 가까웠다. 2026년은 이걸 대규모 벤치마크로 정량화하면서 혼란을 측정 가능한 현상으로 끌어올렸다.

MCPAgentBench(arXiv:2512.24565)는 결정적 장치를 넣었다. 바로 디스트랙터(distractor)를 섞은 동적 샌드박스다. 정답 도구 옆에 일부러 닮은 함정 도구를 깔아 두고, 모델이 그 더미에서 맞는 것을 골라내는 변별력을 잰다. 3절에서 말한 닮은 도구끼리의 어텐션 경합을 이제 통제된 실험으로 켜고 끌 수 있게 된 것이다. 책상 위에 진짜 망치와 가짜 망치를 섞어 두고 목수의 정확도를 측정하는 셈이다(03_01-정의와-메커니즘).

규모도 커졌다. MCP-Atlas(arXiv:2602.00933)는 실제 MCP 서버의 대규모 스냅샷으로 툴 사용 역량을 평가한다. 둘 다 같은 곳을 가리킨다. 도구가 많아질수록, 특히 닮은 도구가 섞일수록 선택 성능이 떨어진다는 것이 더 이상 한 모델, 한 태스크의 일화(4절의 “19개” 주의 문구를 기억하라)가 아니라 여러 모델과 실서버에서 재현되는 경향임을 보여준다. 동시에 이 벤치마크들은 5절 처방을 평가하는 잣대가 된다. 동적 도구 선택(RAG-MCP)이 정말 변별력을 높이는지를 이제 디스트랙터가 깔린 무대 위에서 확인할 수 있다(03_03-소형모델-취약성, 03_08-해결전략-less-is-more).

한 줄로 요약하면, 2026년은 “도구가 많을수록 혼란”이라는 직관을 디스트랙터를 심은 MCP 벤치마크로 정량화해 일화에서 측정값으로 바꿔 놓았다.

한 문단 요약

컨텍스트 혼란은 “넣으면 모델은 본다”는 한 문장에서 출발한다. 컨텍스트는 모델이 골라 보는 공간이 아니라 반드시 봐야 하는 공간이라, 무관한 도구 정의가 쌓이면 어텐션이 희석되어 잘못된 도구 선택, 도구 환각, 지시 망각이 조용히 발생한다. MCP 도구 과부하가 대표 발현인 이유는 도구 정의가 매 요청마다 전량 반복되고, 서로 닮아 경합을 키우며, 즉시 돈이 새기 때문이다. 윈도우 용량이 아니라 도구 수 자체가 원인이므로 윈도우 확장은 해법이 아니고, 소형 모델일수록 더 빨리 무너진다. 처방은 동적 선택(RAG-MCP, 13.62%→43.13%), 트리밍, 서브에이전트 격리, 40% 룰이며 한마디로 Less is More다.

기억할 핵심 직관 한 줄. 관련성은 입장권이 아니다. 지금 이 태스크에 필요한 것만 넣어라.

요약·체크리스트

  • “관련 있다”가 아니라 “지금 필요하다”로 넣을지 판단한다(관련성 ≠ 필요성).
  • MCP 서버 추가 전에 현재 컨텍스트 점유율을 측정하고 40% 미만을 유지한다.
  • 현재 태스크와 무관한 MCP 서버와 도구는 비활성화한다.
  • 가능하면 동적 도구 선택(RAG-MCP)으로 요청당 3~7개만 로드한다.
  • 소형 모델일수록 도구를 더 가혹하게 줄인다(윈도우 용량과 무관한 문제임을 명심).
  • 툴 바이패스(실제 호출 없이 결과 시뮬레이션) 발생 여부를 감사 로그로 점검한다.
  • 다른 모드와 혼동하지 말 것. 혼란은 모순이 없다. 모순이 있으면 09_01-감별진단-5대모드-종합비교에서 충돌과 감별하라.

관련 노트: 03 혼란 · 03_01-정의와-메커니즘 · 03_02-툴-과부하-MCP-실태 · 03_03-소형모델-취약성 · 03_08-해결전략-less-is-more · 09_01-감별진단-5대모드-종합비교

그래프 뷰

백링크