상위: 02_00_MOC
처방 — 컨텍스트 산만 완화 전략과 실무 체크리스트
컨텍스트 산만(Context Distraction)은 진단하고 메커니즘을 이해하는 데서 끝나지 않는다. 현장에서 손에 잡히는 전략으로 옮겨야 비로소 쓸모가 생긴다. 이 노트는 연구 근거에 기댄 완화 전략 여섯 가지를 정리하고, AI 강사와 AX 컨설턴트가 클라이언트 교육이나 시스템 설계 현장에서 바로 꺼내 쓸 수 있도록 체크리스트로 마무리한다.
적용 시나리오는 다음 세 갈래로 나눈다.
- RAG(Retrieval-Augmented Generation): 문서를 검색한 뒤 답변을 생성하는 경우
- 에이전트(Agent): 다단계 자율 추론과 행동 루프를 도는 경우
- 일반 LLM 사용: 단일 프롬프트나 단순한 멀티턴 대화
전략 1 — 중요 정보 위치 설계 (Position Engineering)
근거: “Lost in the Middle” (Liu et al., 2023)
Stanford/Meta 팀은 multi-document QA와 key-value retrieval 과제에서 관련 정보의 위치가 성능을 결정적으로 좌우한다는 것을 보였다(위치 편향 상세). 성능 곡선은 U자 모양을 그린다.
“Performance is 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 of long contexts, even for explicitly long-context models.” — Liu et al., TACL 2024
핵심 수치를 보면, 중간 위치의 정확도는 처음이나 끝에 둘 때보다 약 18~20 퍼센트포인트 떨어진다. “explicitly long-context models”까지 포함한 모든 테스트 모델에서 나타난 현상이다. 긴 컨텍스트를 지원하도록 설계한 모델이라고 예외가 아니다.
실천 원칙: 처음과 끝에 핵심을 배치하라
graph LR A["🔴 시스템 프롬프트<br/>(역할·지침·제약)"] --> B["🟡 보조 컨텍스트<br/>(히스토리·배경)"] B --> C["🟡 RAG 검색 결과<br/>(관련도 순 정렬)"] C --> D["🔴 사용자 질문<br/>(최종 위치 고정)"] style A fill:#ff6b6b,color:#fff style D fill:#ff6b6b,color:#fff style B fill:#ffd93d,color:#333 style C fill:#ffd93d,color:#333
권장 구조 (RAG 시나리오):
- 처음(최우선): 시스템 프롬프트. 모델 역할, 핵심 지침, 절대 제약
- 중간(필요에 따라): RAG 검색 결과. 관련도 높은 청크를 먼저, 낮은 청크를 뒤에
- 끝(최우선): 사용자의 실제 질문. 항상 마지막에 고정
권장 구조 (에이전트 시나리오):
- 처음: 에이전트 목표와 현재 스텝의 목적, 핵심 제약
- 중간: 압축한 히스토리 요약(슬라이딩 윈도우)
- 끝: 현재 관찰(observation)과 다음 결정 요청
흔한 실수 패턴:
| 잘못된 구조 | 문제 |
|---|---|
| 긴 배경 설명 → 시스템 프롬프트 → 질문 | 핵심 지침이 중간에 묻힘 |
| 질문 → RAG 결과 → 추가 지시 | 모델이 RAG 결과를 답변으로 오인 가능 |
| RAG 결과를 관련도 역순으로 배치 | 가장 중요한 근거가 중간에 위치 |
적용 시나리오: RAG 시스템 설계, 긴 시스템 프롬프트 작성, 멀티턴 대화 컨텍스트 구성
전략 2 — 모델별 산만 임계점 이하로 컨텍스트 관리
근거: RULER 벤치마크 + Databricks RAG 연구
산만 임계점(Distraction Ceiling)은 모델마다 다르다. 광고된 컨텍스트 길이와 실제로 에이전트가 다룰 수 있는 길이 사이에는 큰 격차가 있다.
모델별 실용적 상한선 (에이전트·복합 추론 기준):
| 모델 등급 | 실용 상한선 | 광고 컨텍스트 | 근거 |
|---|---|---|---|
| Mixtral-8x7B급 소형 모델 | 4K | 32K | Databricks 2024 |
| DBRX-instruct급 중형 | 8K | 32K | Databricks 2024 |
| Claude-3-sonnet급 | 16K | 200K | Databricks 2024 |
| Llama 3.1 405B급 | 32K | 128K | Databricks 2024 |
| GPT-4-0125-preview급 | 64K | 128K | Databricks 2024 |
| Gemini 2.5 Pro급 (에이전트) | ~100K | 1M | Gemini Tech Report 2025 |
핵심은 이렇다. “1M 토큰 = 1M 토큰을 다 쓸 수 있음”이 아니다. Gemini 2.5 Pro만 해도 광고 컨텍스트 1M 토큰 가운데 에이전트 추론에 실질적으로 안전한 구간은 약 100K, 광고치의 10% 수준이다.
RULER 벤치마크는 이를 좀 더 구체적으로 보여준다.
| 모델 | 4K 성능 | 128K 성능 | 저하 |
|---|---|---|---|
| Gemini-1.5 | 96.7% | 94.4% | −2.3점 |
| GPT-4 | 96.6% | 81.2% | −15.4점 |
| Llama3.1-70B | 96.5% | 66.6% | −29.9점 |
| Mistral-v0.2 | 93.6% | 13.8% | −79.8점 |
시스템 설계 원칙:
flowchart TD A[컨텍스트 누적] --> B{임계점 도달?} B -- "아니오 (<70% 상한)" --> C[정상 진행] B -- "예 (>70% 상한)" --> D[압축/요약 트리거] D --> E{전략 선택} E --> F["슬라이딩 윈도우<br/>최근 N턴 유지"] E --> G["중요 사건 압축<br/>키 포인트만 보존"] E --> H["완전 초기화 후<br/>요약본으로 재시작"]
모니터링 지표 (프로덕션 배포 시):
- 매 요청마다
input_tokens추적 - 상한선의 70%에 닿으면 자동 압축 트리거
- 상한선을 넘은 이후 요청에서 반복·루프 패턴이 잡히면 알람
적용 시나리오: 에이전트 시스템 설계, RAG 파이프라인 토큰 예산 설정, LLM API 비용 최적화
전략 3 — 에이전트 히스토리 주기적 압축/요약 (ACON 프레임워크)
근거: ACON (Kang et al., ICML 2026, microsoft/acon)
ACON(Optimizing Context Compression for Long-horizon LLM Agents)은 장기 실행 에이전트에서 나타나는 무한 컨텍스트 성장(unbounded context growth) 문제를 자연어 최적화 공간에서 푼다. 모델을 파인튜닝하지 않아도 적용할 수 있다.
ACON의 핵심 메커니즘은 다음과 같다.
ACON “iteratively refines compression guidelines based on failure analysis of the agent,” preserving essential state information while reducing context volume. — Kang et al., ICML 2026
flowchart LR subgraph "에이전트 루프" A[관찰] --> B[행동] B --> C[컨텍스트 누적] end subgraph "ACON 압축기" C --> D{압축 트리거?} D -- "예" --> E[실패 분석 기반<br/>압축 가이드라인 정제] E --> F[중요 사건 보존] E --> G[반복 정보 제거] F --> H[압축된 컨텍스트] G --> H end H --> A
핵심 수치는 다음과 같다.
| 지표 | 결과 |
|---|---|
| 피크 토큰 사용량 감소 | 26~54% |
| 소형 모델 성능 개선 | 최대 46% |
| 적용 방식 | 파인튜닝 없음 (추론 시 적용) |
| 공개 코드 | github.com/microsoft/acon |
실무 구현은 세 단계 압축 전략으로 정리한다.
A. 슬라이딩 윈도우 요약 (Sliding Window Summarization)
[설계 원칙]
- 최근 N턴은 원본 보존 (단기 작업 기억)
- N턴 이전은 요약 텍스트로 대체
- 요약 시 보존 항목: 결정사항, 발견한 오류, 현재 목표 달성 진도
- 제거 항목: 중간 탐색 과정, 실패한 시도의 세부 내용, 반복 확인 행동
B. 중요 사건 압축 (Important Event Compression)
[보존 우선순위]
1순위: 목표 변경 사건 (goal shift)
2순위: 치명적 오류 및 복구 (critical error + recovery)
3순위: 환경 상태 변화 (state change)
4순위: 사용자 피드백 및 수정 지시
제거 대상: 단순 탐색, 반복 조회, 확인 완료된 중간 단계
C. 완전 초기화 + 요약 재주입 (Full Reset with Summary Injection)
에이전트가 루프에 빠진 징후(Pokémon 에이전트 사례처럼 같은 행동을 반복하는 경우)가 잡히면 이렇게 처리한다.
- 컨텍스트를 강제로 초기화한다.
- “지금까지 달성한 것, 현재 상태, 다음 목표”를 담은 압축 요약만 다시 주입한다.
- 새 컨텍스트에서 재시작한다.
루프 감지 휴리스틱:
- 마지막 다섯 번의 행동 중 세 번 이상이 같은 행동
- 같은 함수를 같은 인자로 2회 이상 연속 호출
- 출력 텍스트의 n-gram 반복률 30% 초과
적용 시나리오: 에이전트 전용 (장기 실행 에이전트, 코드 작성 에이전트, 게임 플레이 에이전트, RPA 자동화)
전략 4 — 증거 재인용 프롬프트 (Evidence Recitation Prompting)
근거: Du et al., EMNLP 2025 (arXiv:2510.05381)
Du et al.의 연구는 컨텍스트 산만의 원인이 단순한 “정보 노이즈”가 아님을 보였다. 검색 품질을 완벽하게 통제하고 무관한 토큰을 공백으로 바꾸거나 마스킹해도, 컨텍스트 길이 자체만으로 성능이 떨어졌다.
“Even when models can perfectly retrieve all relevant information, their performance still substantially declines as input length increases, with degradation ranging from 13.9% to 85% across tested models.” — Du et al., EMNLP 2025
컨텍스트 산만이 어텐션 아키텍처의 구조적 부담이라는 뜻이다. 이를 가장 단순하게 우회하는 방법이 증거 재인용 프롬프트다.
핵심 원리는 긴 컨텍스트를 짧은 작업으로 쪼개는 것이다. 모델이 먼저 관련 근거를 명시적으로 뽑아 인용한 뒤 추론하게 하면, 정작 추론 단계에서 처리해야 할 유효 컨텍스트 길이가 짧아진다.
효과를 보면, GPT-4o RULER 벤치마크에서 이미 강한 베이스라인 대비 최대 4% 추가 개선이 나타났다.
구체적인 프롬프트 패턴은 세 가지다.
패턴 A. 단계 분리형
[컨텍스트]
{긴 컨텍스트 삽입}
[질문]
{질문}
[지시]
답변하기 전에 먼저 위 컨텍스트에서 이 질문과 직접 관련된 부분을 그대로 인용하세요.
인용 후, 인용한 내용만을 근거로 답변하세요.
형식:
## 관련 근거 인용
> (컨텍스트에서 직접 발췌한 텍스트)
## 답변
(근거 기반 답변)
패턴 B. 체인 프롬프팅형 (2단계 호출)
# 1차 호출: 증거 추출
"다음 컨텍스트에서 [질문]에 답하는 데 필요한 핵심 사실만 추출하세요.
불필요한 내용은 생략하고, 추출된 사실만 나열하세요."
→ 결과: 압축된 근거 목록 (컨텍스트 대폭 단축)
# 2차 호출: 추론
"다음 사실들을 근거로 [질문]에 답하세요:
{1차 결과}"
패턴 C. RAG 파이프라인 통합형
시스템 프롬프트에 추가:
"답변 생성 전, retrieved context에서 답변 근거가 되는 문장을
'근거:' 섹션으로 먼저 제시하세요. 근거에 없는 내용은 답변에 포함하지 마세요."
주의할 점도 있다.
- 4% 개선은 GPT-4o 기준이며, 소형 모델에서는 더 클 수도 작을 수도 있다.
- 2단계 호출은 레이턴시와 비용이 늘어난다. 배치 처리나 캐싱으로 보완한다.
- 재인용 자체가 컨텍스트를 늘릴 수 있으므로, 재인용 섹션 길이에 상한을 두는 편이 좋다.
적용 시나리오: RAG 시스템 (정확도가 중요한 법률·의료·계약 분야), 긴 문서 기반 QA, 컴플라이언스 분석
전략 5 — STRING 위치 인코딩 최적화 (오픈소스 모델 전용)
근거: An et al., 2024 (arXiv:2410.18745)
오픈소스 LLM의 실효 컨텍스트 길이가 훈련 길이의 50%를 넘지 못하는 근본 원인을, An et al.은 상대적 위치의 좌편향 빈도 분포(left-skewed position frequency distribution)로 설명한다.
“The left-skewed frequency distribution of relative positions formed in LLMs pretraining and post-training stages restricts effective information retrieval from distant contexts.” — An et al., 2024
사전훈련과 사후훈련 데이터에는 단거리 위치 쌍이 장거리 쌍보다 압도적으로 많이 등장한다. 그래서 모델은 가까운 토큰 사이의 어텐션에는 능숙하지만, 먼 거리 정보 통합(distant information gathering)에는 체계적으로 취약하다.
STRING의 작동 원리는 이렇다. 추가 훈련(fine-tuning) 없이 추론 시점(inference-time)에 RoPE(Rotary Position Embedding)의 위치 인덱스를 재조정한다. 잘 훈련된(well-trained) 단거리 위치 표현을 장거리 위치에 덮어써서(overwrite), 이미 학습된 어텐션 패턴을 먼 거리에서도 효과적으로 살려낸다.
성능 결과는 다음과 같다.
| 모델 | 적용 전 | 적용 후 | 개선 |
|---|---|---|---|
| Llama 3.1 70B (RULER) | 기준 | +10점 이상 | GPT-4-128K 초과 |
| Qwen2 72B (RULER) | 기준 | +10점 이상 | 대폭 개선 |
| Llama 3.1 70B (InfiniteBench) | 기준 | +10점 이상 | Claude 2, Kimi-chat 초과 |
적용 조건과 제약은 다음과 같다.
- 적용 가능: RoPE 기반 오픈소스 모델(Llama, Qwen, Mistral 등)
- 적용 불가: 클로즈드 API 모델(GPT-4, Claude, Gemini). 위치 인코딩에 접근할 수 없다
- 추가 훈련 불필요: 추론 시 코드 수정만으로 적용
- 주의: 모든 RoPE 변형에 똑같이 효과적이지는 않을 수 있으므로 반드시 테스트한다
실무 적용 시나리오는 이렇다.
- 온프레미스(on-premises) Llama/Qwen 배포 환경
- 비용을 줄이려고 장문 컨텍스트를 소형 오픈소스 모델로 처리해야 할 때
- 데이터 보안 요건 때문에 클로즈드 API를 쓰지 못하는 기업 환경
적용 시나리오: 오픈소스 LLM 사용 환경 전반 (RAG, 에이전트, 일반 사용)
전략 6 — 도구 동적 로딩과 컨텍스트 격리 (Context Quarantine)
근거: Drew Breunig (dbreunig.com, 2025-06-22)
Breunig은 컨텍스트 실패의 해법으로 구조적 접근 두 가지를 제안한다.
“Context distraction is solvable. Key techniques include dynamically loading tools and implementing context quarantines.” — Drew Breunig, 2025
도구 동적 로딩 (Dynamic Tool Loading):
에이전트에 모든 도구 정의(tool definitions)를 처음부터 주입하면, 쓰지도 않는 도구 설명 수천 토큰이 늘 컨텍스트를 차지한다. 동적 로딩은 현재 스텝에서 정말 필요한 도구만 컨텍스트에 담는다.
[정적 로딩 (비추천)]
시스템 프롬프트: [50개 도구 정의 = ~5,000 토큰 항상 차지]
[동적 로딩 (권장)]
현재 스텝 분석 → 관련 도구 3~5개만 선택 → 컨텍스트에 주입
→ 스텝 완료 후 제거, 다음 스텝 도구로 교체
컨텍스트 격리 (Context Quarantine):
장기 실행 에이전트에서 서로 다른 목적의 정보를 분리 관리한다.
graph TD subgraph "격리된 컨텍스트 슬롯" A["슬롯 1: 에이전트 목표<br/>(불변, 항상 존재)"] B["슬롯 2: 단기 작업 기억<br/>(최근 5~10턴)"] C["슬롯 3: 장기 요약 메모리<br/>(압축된 히스토리)"] D["슬롯 4: 현재 도구 + 관찰<br/>(동적 교체)"] end A --> E[프롬프트 조합] B --> E C --> E D --> E
이 격리 구조에서는 각 슬롯의 크기를 따로 제어할 수 있어, 전체 컨텍스트가 임계점을 넘지 않도록 조절하기 쉽다.
적용 시나리오: 에이전트 시스템 아키텍처 설계, 장기 실행 워크플로 자동화
전략 통합 매트릭스
각 전략이 어느 시나리오에서 얼마나 잘 듣는지 정리했다.
| 전략 | RAG | 에이전트 | 일반 LLM | 난이도 | 추가 비용 |
|---|---|---|---|---|---|
| 1. 위치 설계 | ★★★ | ★★★ | ★★★ | 낮음 | 없음 |
| 2. 임계점 관리 | ★★★ | ★★★ | ★★ | 낮음 | 없음 |
| 3. ACON 압축 | ★★ | ★★★ | ★ | 높음 | 추가 LLM 호출 |
| 4. 증거 재인용 | ★★★ | ★★ | ★★ | 낮음 | 약간 |
| 5. STRING | ★★ | ★★★ | ★★ | 중간 | 없음 (OSS 전용) |
| 6. 동적 로딩·격리 | ★ | ★★★ | ★ | 높음 | 없음 |
실무 체크리스트
AI 강사와 AX 컨설턴트가 클라이언트 시스템을 진단하고 설계할 때 쓰는 단계별 체크리스트다.
A. 진단 체크리스트 (시스템 감사)
□ 현재 사용 모델의 실용적 상한선을 확인했는가?
(광고 컨텍스트 × 0.5~0.65 = 실효 상한 추정치)
□ 에이전트 루프에서 컨텍스트 크기를 실시간 모니터링하고 있는가?
□ 중요 정보(시스템 프롬프트, 핵심 지침)가 컨텍스트의 처음 또는 끝에 위치하는가?
□ 도구 정의가 정적으로 전체 로딩되고 있지는 않은가?
□ 에이전트 히스토리를 압축 없이 무한 누적하고 있지는 않은가?
□ RAG 청크가 관련도 역순으로 삽입되고 있지는 않은가?
B. 설계 체크리스트 (신규 시스템 구축)
□ 모델별 산만 임계점을 기준으로 토큰 예산을 배분했는가?
- 시스템 프롬프트: 최대 ___K 토큰
- RAG 결과: 최대 ___K 토큰
- 히스토리: 최대 ___K 토큰 (압축 포함)
- 사용자 입력: 최대 ___K 토큰
합계가 실용 상한선의 70%를 초과하지 않는지 확인
□ 에이전트 루프에 압축 트리거를 구현했는가?
(히스토리 토큰 > 임계점 × 0.7 시 자동 압축)
□ 정확도가 중요한 RAG에서 증거 재인용 프롬프트를 적용했는가?
□ 오픈소스 모델 사용 시 STRING 적용 가능성을 검토했는가?
□ 루프 감지 로직(반복 행동 탐지)을 구현했는가?
C. 클라이언트 교육 핵심 메시지 (3분 버전)
1. "1M 토큰 컨텍스트 = 1M 토큰 안전 사용" — 이 등식은 거짓입니다.
실효 사용 구간은 광고 컨텍스트의 절반 수준입니다.
2. 중요한 정보는 프롬프트의 맨 앞 또는 맨 끝에 두세요.
중간에 묻으면 모델이 놓칩니다.
3. 에이전트가 오래 실행될수록 과거 기록에 갇힙니다.
주기적으로 기억을 압축·요약해 주어야 합니다.
4. 긴 문서에서 답을 찾게 할 때는 먼저 근거를 인용하게 한 뒤 답변하게 하세요.
이 한 가지만으로 정확도가 올라갑니다.
D. 장애 대응 체크리스트 (이미 배포된 시스템)
증상: 에이전트가 같은 행동을 반복하거나 루프에 빠진 경우
→ □ 현재 컨텍스트 토큰 수 확인
→ □ 산만 임계점 초과 여부 판단
→ □ 컨텍스트 강제 초기화 + 압축 요약 재주입
증상: RAG 기반 답변 품질이 문서 수 증가와 함께 저하되는 경우
→ □ RAG 청크 배치 순서 검토 (관련도 높은 것 → 처음 또는 끝)
→ □ 증거 재인용 프롬프트 추가
→ □ 총 컨텍스트 토큰 수 측정 (실용 상한 초과 여부)
증상: 시스템 프롬프트 지침을 모델이 무시하는 경우
→ □ 시스템 프롬프트가 컨텍스트 중간에 위치하고 있는지 확인
→ □ 지침을 컨텍스트 처음 AND 끝에 중복 배치 시도
→ □ 전체 컨텍스트 길이 점검 (임계점 초과 시 지침 무시 빈도 급증)
전략 간 우선순위 가이드
시간과 리소스가 빠듯할 때 어떤 전략부터 손댈지 정리했다.
flowchart TD A[컨텍스트 산만 문제 발생] --> B{에이전트 vs RAG?} B -- "RAG" --> C[1순위: 위치 설계<br/>처음·끝에 핵심 배치] C --> D[2순위: 임계점 관리<br/>토큰 예산 설정] D --> E[3순위: 증거 재인용 프롬프트<br/>정확도 추가 개선] B -- "에이전트" --> F[1순위: 임계점 관리<br/>실용 상한선 파악] F --> G[2순위: 히스토리 압축<br/>슬라이딩 윈도우] G --> H[3순위: 동적 도구 로딩<br/>컨텍스트 격리 설계] H --> I[4순위: ACON 적용<br/>고도화 단계] B -- "오픈소스 모델 + 에이전트" --> J[우선: STRING 적용<br/>추가 훈련 없이 즉시 개선] J --> G
한계 및 주의사항
전략 1~4의 공통 한계: 이 전략들은 컨텍스트 산만을 완화하지만 완전히 제거하지는 않는다. Du et al.(2025)이 보여준 것처럼, 컨텍스트 길이 자체가 구조적 부담이므로 어느 시점에서는 아키텍처 수준의 개선(새로운 어텐션 메커니즘, 메모리 모듈)이 필요하다.
전략 3 (ACON) 주의: 압축 자체에 LLM 호출이 필요하여 추가 레이턴시·비용이 발생한다. 실시간 응답이 중요한 시스템에는 신중하게 적용해야 한다.
전략 5 (STRING) 적용 범위: RoPE 기반 모델에만 적용 가능하다. ALiBi, Sinusoidal 등 다른 위치 인코딩 방식에는 적용할 수 없다.
증거 재인용 수치 해석: Du et al.(2025)의 4% 개선은 GPT-4o, RULER 벤치마크에서의 수치다. 다른 모델·과제에서는 효과가 다를 수 있다.
에이전트 루프 감지 휴리스틱: 본문의 루프 감지 기준(n-gram 반복 30% 등)은 실무 경험적 수치이며, 시스템 특성에 따라 조정이 필요하다.
관련 노트
- 02_01-정의-컨텍스트-산만 — 컨텍스트 산만의 정의와 개요
- 02_02-메커니즘-어텐션-희석 — 어텐션 가중치 희석 메커니즘
- 02_03-메커니즘-위치-편향-u자형 — Lost in the Middle 상세
- 02_04-개념-산만-임계점 — 모델별 산만 임계점 데이터
- 02_06-paper-lost-in-the-middle — Liu et al. 2023 논문 상세
- 01 오염 — 컨텍스트 오염 실패 모드 (산만과 비교)
참고문헌
- Lost in the Middle: How Language Models Use Long Contexts — Nelson F. Liu, Kevin Lin, John Hewitt et al., 2024, TACL
- Context Length Alone Hurts LLM Performance Despite Perfect Retrieval — Yufeng Du, Minyang Tian et al., 2025, EMNLP Findings
- ACON: Optimizing Context Compression for Long-horizon LLM Agents — Minki Kang, Wei-Ning Chen, Dongge Han et al., 2026, ICML
- Why Does the Effective Context Length of LLMs Fall Short? — Chenxin An, Jun Zhang, Ming Zhong et al., 2024, arXiv
- How Contexts Fail and How to Fix Them — Drew Breunig, 2025-06-22, dbreunig.com