상위: 05_00_MOC
한줄 요지
컨텍스트 부패는 아키텍처 수준의 구조적 한계에서 비롯되므로 완전히 제거할 수는 없다. 다만 컨텍스트 최소화 → 위치 설계 → 디스트랙터 제거 → 검색-추론 분리 → 증거 암송으로 이어지는 다섯 층위의 전략을 조합하면 실무 수준에서는 의미 있게 완화할 수 있다.
0. 처방의 전제: 부패는 증상 완화 가능, 근본 제거는 불가
Du et al.(2025, Findings of EMNLP 2025, arXiv:2510.05381)의 완전 마스킹 실험은 이 점을 분명히 보여준다.
“비관련 토큰을 완전히 마스킹해 모델이 관련 토큰에만 어텐션하도록 강제해도 성능 저하는 지속된다.”
곧 컨텍스트 부패는 “비관련 내용이 모델을 혼란시키는” 문제가 아니라, 입력 길이 증가 자체가 트랜스포머 어텐션 아키텍처에 구조적 병목을 만드는 문제다. 그래서 처방의 목표는 근본 해소가 아니라 실무적 완화(mitigation)에 놓인다.
graph TD A[컨텍스트 부패 대응 전략 5층위] A --> B["Layer 1: 컨텍스트 최소화<br/>(애초에 짧게 유지)"] A --> C["Layer 2: 위치 설계<br/>(핵심 정보를 앞/뒤에)"] A --> D["Layer 3: 디스트랙터 제거<br/>(유사 비관련 정보 배제)"] A --> E["Layer 4: 검색-추론 분리<br/>(Focused Input / 멀티에이전트)"] A --> F["Layer 5: 증거 암송<br/>(Evidence Recitation)"] B --> G["가장 효과 큼<br/>(Chroma 2025: 18모델 전체)"] C --> H["위치 편향 경로 차단<br/>(Liu et al. 2023)"] D --> I["디스트랙터 효과 억제<br/>(NoLiMa 2025)"] E --> J["이중 과제 병목 해소<br/>(멀티에이전트 패턴)"] F --> K["최대 +4% 개선<br/>(Du et al. 2025, GPT-4o 기준)"]
처방 1: 컨텍스트 최소화 (Focused Input 원칙)
근거
Chroma Research(2025)의 LongMemEval 실험은 Focused 입력(~300 토큰, 관련 정보만 추출)과 Full 입력(~113,000 토큰, 전체 대화 이력)을 비교했다. 결과는 18개 모델 전부에서 예외 없이 Focused가 Full을 앞섰다.
Anthropic Engineering(2025)의 권고도 같은 방향이다.
“Find the smallest set of high-signal tokens that maximize the likelihood of some desired outcome.”
이는 비용 효율이 아니라 정확도의 문제다.
실행 체크리스트
- 무관한 이전 대화 턴을 컨텍스트에서 제거했는가?
- RAG 파이프라인에서 관련도 낮은 청크를 상위 N개로 제한했는가?
- 시스템 프롬프트에서 현재 과제와 무관한 지시를 삭제했는가?
- 긴 문서 전체를 넣는 대신 관련 섹션만 추출했는가?
- 전체 이력 대신 요약본(summary)을 사용하는 옵션을 검토했는가?
한계
완벽한 Focused Input은 이미 “어느 부분이 관련 있는지”를 안다는 것을 전제한다. 결국 검색(retrieval) 품질이 이 처방의 효과를 좌우한다. 검색이 어긋나면 관련 정보가 통째로 빠질 수도 있다.
처방 2: 위치 설계 (Position Engineering)
근거
Liu et al.(2023, “Lost in the Middle”, TACL 2024, arXiv:2307.03172)는 관련 정보가 컨텍스트 시작부나 끝부분에 있을 때 성능이 가장 높고, 중간으로 갈수록 급격히 떨어지는 U자형 곡선을 보고했다.
“Performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle.”
실행 체크리스트
- 시스템 프롬프트(규칙·역할·제약)를 컨텍스트 앞부분에 배치했는가?
- RAG 검색 결과를 사용자 질문 직전, 즉 끝부분에 배치했는가?
- 핵심 지시나 핵심 사실이 긴 컨텍스트 중간에 묻혀 있지는 않은가?
- 멀티문서 입력 시 가장 관련성 높은 문서를 처음이나 마지막에 두었는가?
한계
Du et al.(2025)은 관련 증거를 질문 직전, 즉 끝에 배치해도 성능 저하가 남는다는 점을 확인했다. 위치 설계는 부패의 위치 편향 경로를 차단할 뿐, 어텐션 희석이나 길이 병목 경로는 여전히 살아 있다. 그러므로 위치 설계만으로는 부족하고 다른 처방과 함께 써야 한다.
처방 3: 디스트랙터 의식적 제거 (Distractor Filtering)
근거
Chroma Research(2025)의 디스트랙터 실험에서는 디스트랙터를 1개만 추가해도 성능이 유의미하게 떨어졌고, 4개로 늘리면 더 나빠졌다.
NoLiMa(Modarressi et al., ICML 2025)의 디스트랙터 실험에서는 GPT-4o의 effective length가 디스트랙터 없이 8K였다가, 어휘가 겹치는 무관 문장 1개를 끼워 넣자 1K로 급락했다(87.5% 감소).
Shi et al.(2023, ICML, arXiv:2302.00093)의 GSM-IC 연구도 같은 맥락이다. 의미상 비슷하지만 실제 답과는 무관한 정보가 끼어들면 LLM의 수학 추론 성능이 크게 무너졌다.
실행 체크리스트
- RAG 파이프라인의 목표를 recall 최대화가 아니라 precision 최대화에 두고 있는가?
- 검색된 청크 중 주제는 비슷하나 정확하지 않은 문서를 재랭킹으로 하위로 내렸는가?
- 디스트랙터가 되기 쉬운 어휘 중복형 비관련 문서를 먼저 걸러 냈는가?
- 청크 크기를 줄여 무관한 내용이 청크에 섞이지 않도록 했는가?
한계
“주제는 비슷하지만 정확하지 않은 정보”를 자동으로 완벽히 걸러 내기란 쉽지 않다. 리랭킹 모델 자체가 이런 미묘한 구별에 약할 수 있기 때문이다. 게다가 필터링이 지나치게 엄격하면 정작 필요한 정보까지 빠질 위험이 있다(recall-precision 트레이드오프).
처방 4: 검색-추론 분리 (Retrieval-Reasoning Separation)
근거
Chroma Research(2025) LongMemEval 실험에서 Focused 입력(추론만 수행)과 Full 입력(검색과 추론을 동시 수행)의 성능 차이는 이중 과제 병목 가설을 강하게 뒷받침한다. 긴 컨텍스트는 모델에 “무엇이 관련 있는지 찾기”라는 과제를 하나 더 얹어, 정작 목표인 추론에 쓸 처리 능력을 깎아먹는다.
패턴 A: RAG 파이프라인 분리 (단일 에이전트)
[전통적 방식]
긴 문서 전체 → LLM 단일 호출 → 검색 + 추론 동시
[분리 방식]
1단계: 검색 모델 / 임베딩 검색 → 관련 청크만 추출
2단계: 짧은 Focused 컨텍스트 → LLM 추론 전용 호출
패턴 B: 멀티에이전트 분리 (복잡 에이전트 시스템)
검색 에이전트 (Retrieval Agent)
↓ Focused 컨텍스트 전달
추론 에이전트 (Reasoning Agent)
↓ 결과
답변 생성
→ 05_08-에이전트-시사점 참조
실행 체크리스트
- 단일 LLM 호출에 “문서 전체 탐색 + 추론”을 동시에 요청하고 있지는 않은가?
- 검색 단계와 추론 단계를 별도 API 호출로 나눴는가?
- 멀티에이전트 설계에서 각 에이전트가 받는 컨텍스트를 최소화했는가?
- 대화 이력이 길어지면 자동으로 Focused 요약본으로 갈아 끼우는 로직이 있는가?
한계
검색-추론 분리는 그만큼 검색 품질에 대한 의존도를 높인다. 관련 정보가 검색 단계에서 빠지면 추론 단계에서는 되살릴 수 없다. 멀티에이전트 패턴은 지연(latency)과 비용도 함께 늘린다.
처방 5: 증거 암송 프롬프팅 (Evidence Recitation)
근거
Du et al.(2025, Findings of EMNLP 2025, arXiv:2510.05381):
검색이 완벽한 조건에서도 컨텍스트 길이 자체 때문에 성능이 떨어지는 상황에서, 모델이 관련 증거를 먼저 명시적으로 암송한 뒤 문제를 풀게 하는 프롬프팅 기법이 효과를 보였다.
결과: RULER 벤치마크에서 GPT-4o 기준 최대 4% 향상
프롬프트 구조
Step 1 프롬프트:
"다음 문서에서 이 질문에 직접 관련된 문장이나 구절을 모두 찾아
그대로 인용하세요: [질문]"
Step 2 프롬프트:
"위에서 인용한 증거를 바탕으로 다음 질문에 답하세요: [질문]"
또는 단일 프롬프트:
"다음 단계로 답하세요:
1. 이 질문에 관련된 문서 내 증거를 먼저 그대로 인용하세요
2. 인용한 증거를 바탕으로 답을 도출하세요
질문: [질문]"
실행 체크리스트
- 장문 RAG 시나리오에서 “답하기 전에 관련 근거를 먼저 인용하라”는 지시를 넣었는가?
- 다중 문서 QA에서 CoT(Chain-of-Thought)로 추론 과정을 드러내게 했는가?
- Two-hop 추론이 필요한 경우, CoT가 특히 효과적이라는 점을 활용하고 있는가? (NoLiMa 기준 Two-hop에서 CoT +32%p 개선)
한계
- 4%는 부패를 “해소”하지 못한다. 통계적으로 유의미할 뿐 실무에서 충분한 수준은 아니다.
- 출력 토큰이 늘어난다. 증거 암송 자체가 추가 출력 토큰을 소모해 비용과 지연을 키운다.
- 짧은 컨텍스트에서는 오히려 역효과다. 굳이 암송할 필요가 없는 상황에서 출력만 과해진다.
처방 효과 비교표
| 처방 | 효과 크기 | 비용 변화 | 구현 난이도 | 근거 |
|---|---|---|---|---|
| 컨텍스트 최소화 | 가장 큼 | 절감 | 낮음 (RAG 품질 의존) | Chroma 2025: 18모델 전체 |
| 위치 설계 | 중간 | 없음 | 낮음 | Liu et al. 2023 |
| 디스트랙터 제거 | 중간 | 소폭 증가 | 중간 (리랭킹 필요) | Chroma 2025, NoLiMa 2025 |
| 검색-추론 분리 | 큼 | 증가 | 높음 (아키텍처 변경) | Chroma 2025 LongMemEval |
| 증거 암송 | 소 (최대 +4%) | 증가 | 낮음 (프롬프트만) | Du et al. 2025 |
통합 처방 흐름도
flowchart TD START["장문 컨텍스트 LLM 호출 계획"] --> Q1{"컨텍스트를<br/>줄일 수 있는가?"} Q1 -- "YES" --> A1["처방 1: 컨텍스트 최소화<br/>관련 정보만 추출·Focused Input"] Q1 -- "NO" --> Q2{"핵심 정보 위치를<br/>제어할 수 있는가?"} A1 --> Q2 Q2 -- "YES" --> A2["처방 2: 위치 설계<br/>핵심 정보 → 앞/뒤 배치"] Q2 -- "NO/PARTIAL" --> Q3{"유사 비관련 정보<br/>(디스트랙터)가 있는가?"} A2 --> Q3 Q3 -- "YES" --> A3["처방 3: 디스트랙터 제거<br/>RAG precision 강화·리랭킹"] Q3 -- "NO" --> Q4{"검색과 추론을<br/>분리할 수 있는가?"} A3 --> Q4 Q4 -- "YES" --> A4["처방 4: 검색-추론 분리<br/>멀티에이전트 or 2단계 호출"] Q4 -- "NO" --> A5["처방 5: 증거 암송<br/>프롬프트에 암송 지시 추가"] A4 --> END["완화된 컨텍스트 부패"] A5 --> END
미해결 논쟁점
-
RAG는 처방인가, 딜레마인가? 검색 품질이 낮으면 디스트랙터를 더 많이 끌어오고, 그 결과 부패가 오히려 심해진다. 무엇을 “좋은 RAG”로 볼지부터 정의가 필요하다.
-
Thinking Mode(확장 추론)는 이 처방들을 대체하는가? LongMemEval에서 thinking 모드는 Focused와 Full 양쪽을 모두 끌어올렸지만 둘 사이의 격차는 그대로 남았다. NoLiMa에서는 GPT-o1조차 32K에서 31.1%에 그친다. 처방과 thinking mode를 어떻게 조합해야 최적인지는 아직 정해지지 않았다.
-
컨텍스트 압축(context compression) 기술의 실제 효과 — LLMLingua, AutoCompressor 같은 압축 기술이 부패를 얼마나 완화하는지에 대한 체계적 비교 연구가 아직 부족하다.
-
증거 암송의 도메인 적합성 — 법률·의학처럼 정밀성이 중요한 도메인에서 암송 오류(partial quote, paraphrase)가 나면 신뢰성이 흔들린다. 암송의 충실도를 어떻게 검증할 것인가.
관련 노트
- 05_00_MOC — 챕터 05 전체 맵
- 05_03-메커니즘-왜-발생하는가 — 처방의 이론적 근거인 메커니즘 분석
- 05_08-에이전트-시사점 — 에이전트 시스템에서의 검색-추론 분리 패턴
- 05_04-paper-context-rot-chroma — Chroma 실험 상세 (처방의 핵심 근거)
- 06 해결전략 — 멀티에이전트 아키텍처 전략
참고문헌
- Context Rot: How Increasing Input Tokens Impacts LLM Performance — Kelly Hong, Anton Troynikov, Jeff Huber, Chroma Research, 2025
- Context Length Alone Hurts LLM Performance Despite Perfect Retrieval — Du et al., Findings of EMNLP 2025
- Lost in the Middle: How Language Models Use Long Contexts — Liu et al., TACL 2024
- NoLiMa: Long-Context Evaluation Beyond Literal Matching — Modarressi et al., ICML 2025
- Large Language Models Can Be Easily Distracted by Irrelevant Context — Shi et al., ICML 2023
- RULER: What’s the Real Context Size of Your Long-Context Language Models? — Hsieh et al., COLM 2024