2M 토큰 함정: ‘Context Stuffing’이 추론을 망치는 이유

Source: Dev.to

왜 더 많은 컨텍스트가 종종 LLM의 성능을 떨어뜨리는가—그리고 대신 해야 할 일

1. Introduction

The Context‑Window Arms Race

The expansion of context windows has been staggering:

• Early 2023 – GPT‑4 launches with 32 K tokens
• Nov 2023 – GPT‑4 Turbo extends to 128 K
• Mar 2024 – Claude 3 reaches 200 K
• Feb 2024 – Gemini 1.5 hits 1 M (later 2 M)

In just two years, capacity grew from 32 K to 2 M tokens—a 62× increase.
The developer intuition was immediate and seemingly logical:

“If everything fits, just put everything in.”

The Paradox: More Context, Worse Results

Practitioners are discovering a counter‑intuitive pattern:

The more context you provide, the worse the model performs.

Typical symptoms:

• Supplying an entire codebase → misunderstood design intent
• Including exhaustive logs → critical errors overlooked
• Providing comprehensive documentation → unfocused responses

This phenomenon appears in the research literature as “Lost in the Middle” (Liu et al., 2023). Information placed in the middle of long contexts is systematically neglected.

The uncomfortable truth is:

A context window is not just storage capacity; it is cognitive load.

This article explores why Context Stuffing fails, what Anthropic’s Claude Code reveals about effective context management, and how to shift from Prompt Engineering to Context Engineering—the discipline of architectural curation for AI systems.

2. “More Context”가 “Better Understanding”을 의미하지 않는 이유

Capacity vs. Capability

• Capacity – 메모리에 들어갈 수 있는 데이터 양 (예: 200 K, 2 M 토큰)
• Capability – 그 데이터를 우선순위화하고, 연결하며, 추론하는 능력

2 M 토큰을 받아들일 수 있는 모델이라 하더라도 모든 토큰에 동일한 주의를 기울이는 것은 아니다.
LLM에 2 M‑토큰 컨텍스트를 제공하는 것은 신입 개발자에게 첫날에 10 000 페이지의 문서를 건네주고 5분 안에 버그를 고치게 하려는 것과 같으며, 그들은 금방 압도당한다.

Attention Dilution and “Lost in the Middle”

이 제한은 self‑attention 메커니즘에서 비롯된다. 토큰 수가 증가하면 어텐션 분포가 평탄해지고, 신호‑대‑잡음 비율이 낮아지며, 관련 정보가 묻힌다. Liu et al. (2023)은 긴 컨텍스트의 중간에 있는 정보가 체계적으로 무시된다는 것을 보여주었으며, 이는 명시적으로 관련이 있더라도 마찬가지이고, 시작과 끝에 있는 내용은 과도하게 주목받는다.

컨텍스트 확장은 접근 가능한 양을 늘릴 뿐, 이해 가능한 양을 늘리지는 않는다.

Real‑World Symptoms

• 전체 코드베이스 → 아키텍처 오해
• 방대한 로그 → 핵심 신호가 묻힘
• 포괄적인 문서 → 답변이 주제에서 벗어남

이것은 모델 지능의 실패가 아니라 정보 구조와 우선순위 지정의 실패이며, 컨텍스트 용량을 아무리 늘려도 해결할 수 없는 문제이다.

3. 75 % 규칙: Claude Code에서 얻은 교훈

문제 – 장시간 세션에서 품질 저하

Claude Code는 Anthropic의 터미널 기반 코딩 에이전트로, 200 K 컨텍스트 윈도우를 가지고 있으며 다음과 같은 현상이 나타났습니다:

• 장시간 세션에서 코드 품질 저하
• 이전 설계 결정이 기억되지 않음
• 자동 압축 실패로 무한 루프 발생

당시 Claude Code는 사용 가능한 컨텍스트의 **> 90 %**를 일상적으로 사용했습니다.

해결책 – 75 %에서 자동 압축

2024년 9월, Anthropic은 직관에 반하는 해결책을 도입했습니다:

컨텍스트 사용량이 75 %에 도달하면 자동 압축을 트리거합니다.

결과:

• 저장을 위해 약 150 K 토큰 사용
• 의도적으로 약 50 K 토큰을 비워 둠

낭비처럼 보였던 것이 극적인 품질 향상의 핵심으로 밝혀졌습니다.

왜 효과가 있는가 – 추론 공간

가설:

1. 컨텍스트 압축 – 낮은 관련성의 정보가 제거됩니다
2. 정보 재구성 – 요약이 흩어진 데이터를 재정리합니다
3. 추론을 위한 공간 확보 – 빈 공간이 생성을 가능하게 합니다

“그 자유로운 컨텍스트 공간은 낭비되는 것이 아니라, 추론이 일어나는 곳입니다.” – 개발자

이는 컴퓨터 메모리 동작을 닮았습니다: RAM을 95 % 사용한다고 해서 남은 5 %가 유휴 상태인 것은 아니며, 시스템 오버헤드가 차지합니다. 100 %까지 밀어붙이면 모든 것이 멈춥니다.

요약

• 컨텍스트를 가득 채우면 출력 품질이 저하됩니다.
• 효과적인 컨텍스트 관리에는 여유 공간이 필요합니다—단순 검색이 아니라 추론을 위해 예약된 공간.

4. 컨텍스트 엔지니어링의 세 가지 원칙

프롬프트 문구 조정 시대는 끝나가고 있습니다. Hamel Husain이 말했듯이:

“AI Engineering is Context Engineering.”

핵심 기술은 이제 모델에 무엇을 말하느냐가 아니라 무엇을 앞에 두느냐이며, 의도적으로 무엇을 빼놓는가입니다.

원칙 1: 격리

모놀리스를 한 번에 내보내지 마세요.
Domain‑Driven Design의 Bounded Contexts를 차용하세요. 작업에 가장 작은 효과적인 컨텍스트를 제공하세요.

예시 – OAuth2 인증 추가

질문: 이 문제를 해결하는 데 필요한 최소 컨텍스트는 무엇인가요?

원칙 2: 체이닝

히스토리가 아니라 아티팩트를 전달하세요.
워크플로를 단계로 나누세요:

1. 계획 → 간결한 계획을 생성 (수백 토큰 수준)
2. 실행 → 1단계에서 생성된 아티팩트만 사용해 계획을 실행
3. 반성 → 결과를 요약하고 정제된 뷰를 다음 반복에 피드백

각 단계는 전체 대화 기록이 아니라 이전 단계의 출력만 받습니다.

원칙 3: 예약

모델이 생각할 여지를 남겨두세요.

• 컨텍스트 창의 약 25 %를 “생각 공간”으로 예약하세요.
• 이 공간을 스크래치패드 추론, 중간 계산, 혹은 실시간 요약에 사용하세요.

모델이 여유 공간을 다 쓰게 되면, 잘라내거나 압축해야 하며, 이는 종종 중요한 추론 단계가 손실되는 결과를 초래합니다.

5. 모두 합치기

1. Audit 현재 프롬프트를 점검하세요: 단일 덤프를 식별합니다.
2. Segment 문제를 경계가 있는 컨텍스트로 분할합니다.
3. Chain 워크플로를 연결하고, 필요한 아티팩트만 앞으로 전달합니다.
4. Reserve 컨텍스트 창의 약 25 %를 추론에 할당합니다.
5. Iterate: 각 사이클 후, 다음 단계 전에 컨텍스트를 압축(요약, 정리)합니다.

컨텍스트를 자유로운 저장소가 아닌 디자인 리소스로 다루면 다음을 기대할 수 있습니다:

• 설계 의도에 대한 높은 충실도
• 올바른 솔루션에 대한 더 빠른 수렴
• 보다 예측 가능하고 유지보수하기 쉬운 AI‑지원 워크플로

TL;DR

• 더 큰 컨텍스트 창이 반드시 더 나은 이해를 의미하지는 않는다.
• “Lost in the Middle”은 중간 토큰에 대한 어텐션이 감소한다는 것을 보여준다.
• Claude Code의 75 % 자동 압축 규칙은 여유 공간이 중요함을 증명한다.
• Isolation, Chaining, and Reservation을 채택하여 효과적인 컨텍스트를 설계하세요.

행복한 컨텍스트 엔지니어링! 🚀

원칙 3: 여유 공간

모델을 100 % 용량으로 절대 실행하지 마세요.
75 % 규칙을 채택하세요.

토큰 제한은 일반적으로 입력 + 출력을 포함합니다. 200 K 윈도우에 195 K 토큰을 채우면 추론을 위한 여유 공간이 거의 남지 않습니다.

묻기:

• 이것을 전사본 대신 요약을 전달하는 단계로 분해할 수 있나요?
• 모델이 단순히 응답하는 것이 아니라 생각할 수 있도록 충분한 여유를 남겼나요?

컨텍스트 윈도우를 무한한 저장소가 아니라 제한된 인지 자원으로 취급하세요.

5. 왜 200 K가 최적점인가

인지 규모

150 K 토큰(≈ 200 K의 75 %)은 대략 한 권의 기술 서적에 해당합니다—인간과 LLM이 관리할 수 있는 가장 큰 일관된 “프로젝트 상태”입니다. 이를 초과하면 챕터, 요약, 그리고 아키텍처가 필요합니다.

비용 및 지연 시간

어텐션은 O(n²) 형태로 확장됩니다.
컨텍스트를 두 배로 늘리면 비용이 네 배가 됩니다.
200 K는 성능, 지연 시간, 비용의 균형을 맞춥니다.

방법론적 규율

200 K는 큐레이션을 강제합니다.
이를 초과하는 것은 코드 냄새와 같습니다: 경계가 불분명하거나, 과도하게 큰 작업, 혹은 구조화 대신 내용을 억지로 채우는 경우.

Anthropic은 1 M 토큰을 제공하지만—프리미엄 티어 뒤에 있습니다.
암묵적인 메시지: 1 M은 특수한 경우에만 사용됩니다. 200 K가 기본값인 이유가 있습니다.

이 제약은 제한이 아니라—그것이 설계 원칙입니다.

6. 결론: 프롬프트 엔지니어링에서 컨텍스트 엔지니어링으로

컨텍스트‑윈도우 경쟁은 용량을 62배 증가시켰지만, 용량은 결코 병목이 아니었다.
병목은—그리고 항상 그랬던—큐레이션이다.

모든 작업 전에 스스로 물어야 할 세 가지 질문

1. 나는 단지 할 수 있기 때문에 컨텍스트를 채우고 있는가?
   관련성이 포괄성보다 우선한다.

2. 이 컨텍스트가 실제 문제에만 국한되어 있는가?
   경계를 명시할 수 없다면, 아직 찾지 못한 것이다.

3. 모델이 생각할 여지를 남겼는가?
   출력 품질은 입력 억제에 달려 있다.

프롬프트 엔지니어링 시대는 영리한 표현을 보상했다.
컨텍스트 엔지니어링 시대는 구조적 판단을 보상한다.

질문은 더 이상: 모델에게 무엇을 말해야 할까?
질문은: 모델이 어떤 세계를 보아야 하는가?

7. 참고문헌

연구 논문

• Liu 외, Lost in the Middle: How Language Models Use Long Contexts (2023)

도구 및 방법론

• planstack.ai –

실증 연구

• Greg Kamradt, Needle in a Haystack

기사 및 분석

• (필요에 따라 항목 추가)