상위: 04_00_MOC
컨텍스트 충돌 완화 전략 처방 및 실무 체크리스트
컨텍스트 충돌(Context Clash)은 LLM 실패 모드 가운데 가장 심각한 유형이다. Breunig(2025)의 4분류 체계에서 충돌은 단순한 노이즈가 아니라 두 정보가 서로를 직접 부정(negate)하는 구조적 모순으로 정의된다. 이 노트는 완화 전략 아홉 가지를 처방 수준으로 상세히 기술하고, 역효과를 낼 수 있는 전략에 대한 경고를 덧붙인 뒤, 실무자가 곧바로 적용할 체크리스트로 마무리한다.
관련 노트: 04 충돌 — 충돌의 정의, 분류, 메커니즘 전반
1. 왜 완화 전략이 필요한가 — 충돌의 파괴력 재확인
완화 전략을 논하기 전에 충돌이 얼마나 치명적인지 숫자로 다시 짚어 두자. o3는 단일턴 98.1%에서 멀티턴 64.1%로 34포인트 하락한다(Laban et al. 2025). 가장 강력한 추론 모델조차 대화 안에서 정보가 충돌하면 무력해진다.
graph TD A["단일턴 완전 명세<br/>평균 90%"] -->|"정보를 여러 턴에 분산"| B["멀티턴 분산 명세<br/>평균 65%"] B -->|"섣부른 답변 누적"| C["앵커링 편향<br/>(Shallow-layer activation)"] B -->|"오류 시도 잔존"| D["컨텍스트 드래그<br/>10~20% 추가 하락"] B -->|"사용자 반박 → 번복"| E["자가 생성 충돌<br/>Regressive Sycophancy 14.66%"] C --> F["복합 충돌 상태<br/>해소 없으면 누적"] D --> F E --> F
이 하락은 특정 모델만의 문제가 아니다. Laban et al.(2025)의 실험에서 GPT-4.1, Claude 3.7 Sonnet, Gemini 2.5 Pro, DeepSeek-R1, Llama 4 등 15개 모델 전부가 같은 패턴을 보였다. Morph(2025)의 18개 모델 전수 조사도 같은 결론에 이른다. “All 18 models degrade with length—including GPT-4.1, Claude Opus 4, and Gemini 2.5 Pro.”
에이전트 환경에서는 도구 호출 누적, 서브에이전트 병합, 장시간 반복 실행이 충돌 기회를 기하급수적으로 늘린다. Morph(2025): “every AI agent’s success rate decreases after 35 minutes of human-equivalent task time — failure rates quadruple when task duration doubles.”
2. 완화 전략 9가지 — 상세 처방
전략 1: 컨텍스트 격리 (Context Quarantine)
핵심 원리는 분리다. 서로 충돌할 수 있는 정보나 독립적으로 처리해야 할 서브태스크를 별도 스레드·세션·에이전트로 나눈다. 단일 컨텍스트에 모든 것을 욱여넣는 것이 충돌의 구조적 원인이므로, 분리 자체가 예방이 된다.
Drew Breunig(2025, dbreunig.com)은 “isolate conflicting information by breaking tasks into separate threads”라고 말하면서 실증 사례를 함께 든다. Anthropic의 멀티에이전트 리서치 시스템이 단일 에이전트 Claude Opus 4보다 90.2% 높은 성능을 낸 까닭은 역할과 컨텍스트를 분리한 데 있다.
실무 적용:
- 태스크를 원자 단위(atomic unit)로 분해하고 각 단위에 독립 세션을 할당
- 서브에이전트 출력을 메인 컨텍스트에 원문 그대로 병합하지 말고 구조화된 요약 형태로 전달
- 장시간 실행 에이전트는 중간 체크포인트에서 컨텍스트를 리셋하고 요약만 유지
주의할 점도 있다. 격리가 지나치게 엄격하면 에이전트 사이의 정보 공유가 막혀 중복 작업이나 불일치 결과가 생긴다. 격리의 경계는 태스크 의존성(task dependency)을 기준으로 설계해야 한다.
전략 2: Cross-Context Review (CCR)
핵심 원리는 검토 세션을 갈아 끼우는 것이다. 출력물을 만든 세션의 히스토리를 전혀 모르는 신선한(fresh) 세션에서 같은 출력물을 다시 검토하게 한다. 생산 세션의 잘못된 가정이나 앵커링, 중간에 나온 오류 답변이 검토 품질을 흐리지 않도록 컨텍스트를 완전히 떼어 놓는 방식이다.
Song(2026, arXiv 2603.12123)의 정량 결과는 다음과 같다.
| 검토 방식 | F1 스코어 | 비고 |
|---|---|---|
| Cross-Context Review (CCR) | 28.6% | 신선한 세션에서 검토 |
| Same-session Review (SR) | 24.6% | 동일 세션에서 1회 검토 |
| Same-session Review 2회 (SR2) | 21.7% | 동일 세션에서 2회 검토 |
핵심은 SR2가 SR보다 오히려 낮다는 점이다. 단순 반복은 도움이 되지 않고 오히려 결과를 악화시킨다. 이점의 원천이 컨텍스트 분리 그 자체임을 보여주는 결과다(p=0.008, 효과 크기 d=0.52).
“The benefit comes from context separation itself. CCR works with any model, needs no infrastructure, and costs only one extra session.” — Song (2026, arXiv 2603.12123)
실무 적용:
- 중요한 코드 리뷰, 문서 검토, 계획 검증 시 생산 세션과 별개의 검토 세션 운영
- 검토 세션에는 원본 출력물과 검토 기준만 전달하고, 생산 과정의 대화 히스토리는 제외
- 비용: API 호출 1회 추가. 인프라 변경 불필요
연계: 06 해결전략 — 멀티에이전트 아키텍처에서 CCR은 검증 에이전트를 별도로 스폰해 구현한다.
전략 3: 컨텍스트 프루닝 (Context Pruning)
핵심 원리는 능동적 제거다. 새 정보가 들어오거나 태스크가 바뀔 때, 더는 유효하지 않거나 모순되는 이전 정보를 적극적으로 걷어낸다. 컨텍스트를 정적으로 쌓이는 구조가 아니라 동적으로 관리할 대상으로 다루는 것이다.
Breunig(2025)이 든 실증 사례를 보자. Provence 도구(1.75GB 모델)로 Wikipedia 문서를 특정 질문 기준에 맞춰 95% 압축하면서도 그 질문에 필요한 핵심 정보는 그대로 남겼다. 방대한 컨텍스트에서 관련 정보를 찾아내려 애쓰는 것보다 불필요한 정보를 덜어내는 편이 더 효과적임을 보여주는 사례다.
graph LR A["원본 컨텍스트<br/>100% 토큰"] -->|"Provence 프루닝"| B["압축 컨텍스트<br/>5% 토큰"] B -->|"핵심 정보 보존"| C["동등 또는 향상된<br/>답변 품질"] A -->|"프루닝 없이 그대로"| D["Lost in the Middle<br/>중간 정보 활용 저하"]
실무 적용:
- 대화 히스토리에서 이미 해소된 오류 답변, 번복된 계획, 구버전 명세를 명시적으로 제거
- 에이전트 파이프라인에서 각 단계 완료 후 해당 단계의 중간 결과는 요약으로 교체
- Provence 같은 전문 프루닝 도구를 RAG 파이프라인 전처리 단계에 통합
주의할 점은 대상 선택을 잘못하면 필요한 컨텍스트까지 지워 버린다는 것이다. 자동 프루닝을 쓸 때는 태스크 관련성을 판단하는 기준을 분명히 잡아야 한다.
전략 4: 구조화된 컨텍스트 (Structured Context)
핵심 원리는 형식이다. 자유 텍스트(free-form text) 대신 딕셔너리(dictionary)·폼(form)·스키마 형식으로 컨텍스트를 관리한다. 키-값 구조에서는 충돌하는 정보를 찾아내고 갈아 끼우기가 자유 텍스트보다 훨씬 수월하다.
자유 텍스트에서 충돌을 탐지하기 어렵다는 점은 Gokul et al.(2025, arXiv 2504.00180)이 실증했다. “context validation remains a challenging task even for state-of-the-art LLMs.” 모델이 자유 텍스트 안의 모순을 스스로 감지하고 해소하는 능력은 지금 기준으로도 불안정하다.
예시 비교:
자유 텍스트 방식(충돌 탐지 어려움):
사용자는 예산이 500만원이라고 했다. ... (50턴 후) ...
사용자가 예산을 700만원으로 수정했다.
구조화 방식(충돌 탐지 용이):
{
"budget": 7000000,
"budget_last_updated": "turn_52",
"previous_budget": 5000000
}실무 적용:
- 에이전트의 상태(state)를 자유 텍스트 대신 JSON/YAML 구조체로 관리
- 사용자 요구사항, 제약 조건, 결정 사항을 명명된 필드로 관리하고 업데이트 시 덮어쓰기
- 시스템 프롬프트에 “정보가 충돌하면 [필드명] 값을 최신 값으로 갱신하라”는 메타 규칙 포함
전략 5: 도구 로드아웃 최소화 (Tool Loadout Minimization)
핵심 원리는 도구 정의의 수를 태스크에 실제로 필요한 만큼으로만 제한하는 것이다. 쓰지 않는 도구 정의는 지시문 충돌(Instruction Clash)의 잠재적 원천이고, 모델의 선택 공간을 복잡하게 만든다.
Breunig(2025)이 인용한 Berkeley Function-Calling Leaderboard 데이터는 다음과 같다.
- DeepSeek-v3: 도구 100개 이상에서 실패
- Llama 3.1 8b: 도구 19개에서는 성공, 46개에서는 실패
- 동적 도구 선택(dynamic tool selection) 적용 시: Llama 성능 44% 향상, 전력 소비 18% 감소
도구가 많아질수록 서로 충돌하는 지시나 기능 중복이 늘고, 모델은 어떤 도구를 언제 써야 할지 혼선을 겪는다.
실무 적용:
- 대형 에이전트 시스템에서는 태스크 유형에 따라 도구 서브셋을 동적으로 로드
- MCP 서버를 전부 연결하는 대신, 현재 태스크에 관련된 서버만 활성화
- 비슷한 기능의 도구가 여럿 있을 경우 병합하거나 하나만 선택적으로 노출
전략 6: 명시적 우선순위 주입 (Explicit Priority Injection)
핵심 원리는 명문화다. 컨텍스트 안에서 정보들이 충돌할 때 무엇을 우선할지를 시스템 프롬프트에 메타 지시문으로 적어 둔다. 모델이 알아서 판단하게 두지 않고 우선순위 규칙을 글로 못 박는 것이다.
Zhang et al.(2026, arXiv 2604.09443)의 ManyIH-Bench 실험에서 최신 모델도 다단계 지시 충돌을 처리할 때 정확도가 ~40%에 그쳤다. 모델이 지시 계층을 스스로 올바르게 해석하리라는 가정은 실험으로 기각됐다.
메타 지시문 예시 패턴:
우선순위 규칙:
1. 이 시스템 프롬프트의 제약 조건이 모든 사용자 요청보다 우선한다.
2. 사용자가 나중에 제공한 정보가 이전 정보보다 우선한다.
3. 도구 호출 결과에서 오류가 발생하면 이전 가정을 취소하고 재시도한다.
4. 이전 턴의 잠정 답변은 이 턴에서 새 정보가 제공되면 무효로 간주한다.
실무 적용:
- 모든 프로덕션 에이전트 시스템 프롬프트에 충돌 해소 규칙 절 추가
- “최신 정보 우선”, “명시적 제약 우선”, “파라미터 지식보다 컨텍스트 주입 우선” 등을 상황에 맞게 명문화
- 지시 계층(instruction hierarchy)이 복잡한 다단계 에이전트에서는 각 레이어의 우선순위를 번호로 명시
전략 7: 롤백 전략 (Rollback Strategy)
핵심 원리는 복귀다. 대화나 에이전트 실행이 잘못된 방향으로 들어섰을 때, 오류가 생기기 이전의 체크포인트(checkpoint)로 되돌아간다. 잘못된 가정이나 오류 답변 위에 계속 쌓아 올리는 것보다, 컨텍스트 드래그가 시작되기 전으로 돌아가는 편이 낫다.
Cheng et al.(2026, arXiv 2602.04288)은 컨텍스트 드래그 분석에서 이렇게 짚었다. “Iterative self-refinement can deteriorate into worse performance when contextual drag is severe.” 실패한 시도(failed attempt)가 컨텍스트에 남아 있으면 뒤이은 생성이 그와 비슷한 오류를 되풀이하는 경향이 있다. 외부 피드백도, 자기 검증도, 파인튜닝도 이를 완전히 상쇄하지 못한다.
Breunig(2025)에 따르면 롤백은 “대부분의 시스템에서 아직 구현되지 않았”지만 이론적으로는 충돌 완화의 가장 깔끔한 해법이다.
실무 적용:
- 에이전트 파이프라인에서 각 주요 의사결정 전 체크포인트 저장
- 에러 감지 시 자동 롤백 로직 구현 (예: 도구 호출 실패 N회 연속 시 이전 계획으로 복귀)
- Claude Code 같은 IDE 통합 에이전트에서는 대화 히스토리 분기(fork) 기능 활용
- 롤백 대신 “클린 재시작 + 이전 결과 요약 전달” 패턴도 실용적 대안
전략 8: 지시 계층 강화학습 훈련 (Instruction Hierarchy RL Training)
핵심 원리는 학습이다. 지시 충돌 해소를 독립된 추론 과제로 재정의하고, 강화학습(RL)으로 모델이 이를 익히게 한다. 응답을 만들기 전에 먼저 지시들 사이의 관계를 추론하도록 훈련하는 것이다.
Zheng et al.(2025, arXiv 2511.04694)의 VerIH 접근법은 다음과 같다.
- 데이터셋: 약 7,000개의 aligned/conflicting 시스템-사용자 지시 쌍 (검증 가능한 정답 포함)
- 방법: 경량 RL로 “사용자 프롬프트와 상위 우선순위 시스템 지시 간의 관계를 먼저 사고(think)한 후 응답 생성” 훈련
- 결과:
| 지표 | 개선 수치 |
|---|---|
| IHEval 충돌 설정 성능 | ~20% 향상 |
| 프롬프트 인젝션 공격 성공률(ASR) | 최대 20% 감소 |
| 안전 임계 설정 일반화 | 훈련 분포 밖으로 일반화 확인 |
“the model must first ‘think’ about the relationship between a given user prompt and higher-priority (system) instructions before generating a response.” — Zheng et al. (2025, arXiv 2511.04694)
한계도 분명하다. RL 훈련이 전제이므로 곧바로 쓸 수는 없고, 모델 제공자나 파인튜닝 파이프라인을 갖춘 조직만 직접 구현할 수 있다. 실무자는 이 원리를 시스템 프롬프트의 “think before act” 지시문으로 프롬프트 수준에서 흉내 낼 수 있다.
연계: 07 거버넌스 — 지시 계층 위반, 룰 침범, 재정의 문제와 직접 연결된다.
전략 9: 다중 에이전트 지식 충돌 해소 (MACR)
핵심 원리는 능동적 해소다. 파라메트릭 지식(모델 내부 지식)과 컨텍스트 주입 정보(RAG 등)가 충돌할 때, 한쪽을 무작정 우선시하는 방식을 버리고 세 개의 전문 에이전트가 충돌을 명시적으로 분석하고 풀어낸다.
Peng et al.(2026, arXiv 2606.20245)의 MACR(Multi-Agent Conflict Resolution) 프레임워크는 다음과 같다.
graph TD A["파라메트릭 지식<br/>(모델 내부)"] --> D["수정된 시맨틱 엔트로피로<br/>신뢰도 측정"] B["컨텍스트 주입 정보<br/>(RAG/MCP)"] --> D D -->|"충돌 감지"| E["Agent 1:<br/>명시적 규칙 도출"] E --> F["Agent 2:<br/>충돌 분석"] F --> G["Agent 3:<br/>불일치 해소 및 최종 답변"] G --> H["해석 가능한<br/>충돌 해소 결과"]
“existing methods avoid conflicts by privileging one source over the other, rather than actively resolving inconsistencies.” — Peng et al. (2026, arXiv 2606.20245)
이 비판의 핵심은 양쪽 모두 오류를 품을 수 있다는 현실을 기존 RAG 시스템이 외면해 왔다는 데 있다. 파라메트릭 지식이 구식(outdated)일 수도 있고, 검색된 컨텍스트에 잘못된 문서가 섞일 수도 있다.
실무 적용:
- 고신뢰도 RAG 파이프라인 설계 시 단순 “컨텍스트 우선” 또는 “모델 지식 우선” 방식 대신 불확실성 기반 충돌 감지 레이어 추가
- 멀티에이전트 시스템에서 검증 에이전트에게 “두 출처가 모순될 경우 양쪽의 오류 가능성을 모두 검토하라”는 명시적 역할 부여
- 시맨틱 엔트로피(semantic entropy)를 충돌 감지의 신호로 활용
연계: 05 부패 — 구식 파라메트릭 지식이 충돌을 일으키는 패턴과 연결된다.
3. 역효과 가능성 있는 전략 — 경고 섹션
다음 전략들은 직관적으로는 매력적이지만, 실증 연구에서 컨텍스트 충돌 상황에서는 효과가 없거나 오히려 역효과를 낼 수 있다고 보고됐다.
경고 1: 단순 CoT 요청 (Chain-of-Thought Prompting)
CoT는 여러 추론 태스크에서 효과적이지만, 모순 탐지(contradiction detection) 맥락에서는 사정이 다르다.
Gokul et al.(2025, arXiv 2504.00180)의 RAG 컨텍스트 검증 연구를 보면, CoT 프롬프팅이 일부 모델에서는 오히려 모순 탐지 성능을 떨어뜨렸다. CoT가 잘못된 추론 경로를 더 길고 자신감 있게 펼치게 만들 수 있기 때문으로 풀이된다.
처방은 단순 요청을 피하는 것이다. “생각해봐”라고만 던지지 말고, 전략 6(명시적 우선순위 주입)과 묶어 “먼저 두 정보의 출처와 신뢰도를 비교하고, 충돌 지점을 빠짐없이 나열한 뒤, 그다음 답변을 만들라”는 식으로 구조화된 CoT를 써야 한다.
경고 2: 컨텍스트 윈도우 확장
1M 토큰 컨텍스트 윈도우가 충돌 문제를 풀어 줄 것이라는 기대에는 근거가 없다. Breunig(2025)의 말처럼 “context engineering(not capacity) solves the problem.”
윈도우가 커지면 충돌할 수 있는 정보가 함께 놓일 기회만 더 늘어난다. Gemini 2.5 Pro 분석에서는 컨텍스트가 100k 토큰을 넘어서자 에이전트가 새 전략을 짜내는 대신 과거 히스토리를 되풀이하는 현상이 나타났다. 윈도우 확장은 처리 용량을 비용 효율적으로 키워 줄 뿐, 충돌을 근원에서 해소하지는 못한다.
경고 3: 반복적 자기 개선 (Iterative Self-Refinement)
자기 개선 루프는 컨텍스트 드래그가 심한 상황에서 성능을 떨어뜨릴 수 있다.
Cheng et al.(2026, arXiv 2602.04288)은 “Iterative self-refinement can deteriorate into worse performance when contextual drag is severe”라고 했다. 실패한 시도가 컨텍스트에 남은 상태에서 모델에게 “다시 시도해봐”를 거듭 시키면, 모델은 이전 오류와 구조가 비슷한 오류를 되풀이하는 경향을 보인다. 트리 편집 거리(tree edit distance) 분석으로 11개 모델 × 8개 태스크에서 이 현상이 확인됐다.
처방은 단독 사용을 피하는 것이다. 자기 개선 루프를 쓴다면 전략 7(롤백)이나 전략 2(CCR)와 반드시 묶어야 한다. 이전 시도를 컨텍스트에서 걷어내거나 신선한 세션에서 다시 시작하는 편이 같은 컨텍스트에서 반복하는 것보다 낫다.
경고 4: 더 많은 정보 주입
컨텍스트가 부족해 보인다고 문서와 도구 설명, 예시를 더 들이부으면 Context Confusion이 심해지고, 충돌 정보가 끼어 있을 경우 충돌 강도까지 올라간다. 전략 3(프루닝)을 거꾸로 한 셈이다.
4. 전략 비교 매트릭스
| 전략 | 적용 시점 | 구현 난이도 | 즉시 적용 가능 | 에이전트 적합성 | 근거 출처 |
|---|---|---|---|---|---|
| 컨텍스트 격리 | 설계 단계 | 중 | 가능(아키텍처 변경 필요) | 높음 | Breunig 2025 |
| Cross-Context Review | 검토 단계 | 낮음 | 가능(즉시) | 중 (검증 에이전트로) | Song 2026 |
| 컨텍스트 프루닝 | 실행 중 | 중~고 | 도구 필요 | 높음 | Breunig 2025 (Provence) |
| 구조화된 컨텍스트 | 설계 단계 | 중 | 가능(프롬프트 변경) | 높음 | Gokul et al. 2025 |
| 도구 로드아웃 최소화 | 설계 단계 | 낮음 | 가능(즉시) | 높음 | Berkeley FCL |
| 명시적 우선순위 주입 | 시스템 프롬프트 | 낮음 | 가능(즉시) | 높음 | Zhang et al. 2026 |
| 롤백 전략 | 실행 중 | 고 | 어려움(미구현 다수) | 높음 | Breunig 2025, Cheng et al. 2026 |
| 지시 계층 RL 훈련 | 모델 훈련 단계 | 매우 높음 | 불가(훈련 필요) | 높음 | Zheng et al. 2025 |
| MACR | 추론 파이프라인 | 고 | 어려움 | 높음 | Peng et al. 2026 |
5. 실무 체크리스트 — 5항목
이 체크리스트는 프로덕션 에이전트나 LLM 파이프라인을 설계·운영할 때 컨텍스트 충돌을 미리 막거나 사후에 진단하기 위한 점검 기준이다.
✅ 체크 1: 컨텍스트 독립성 — “각 태스크는 독립적으로 실행되는가?”
- 서브태스크들이 하나의 공유 컨텍스트에 모두 누적되고 있지는 않은가?
- 서로 다른 도메인/단계의 작업이 동일 세션에서 순차 실행되고 있지 않은가?
- 서브에이전트 출력이 원문 그대로 메인 컨텍스트에 병합되고 있지는 않은가?
기준: 독립적으로 처리 가능한 태스크는 독립 세션에서 실행한다. 출력물 전달 시 구조화된 요약으로 변환한다.
✅ 체크 2: 충돌 정보 관리 — “오래된 또는 번복된 정보가 컨텍스트에 잔존하지 않는가?”
- 이전 턴에서 잘못된 것으로 판명된 답변이 컨텍스트에 그대로 남아 있지 않은가?
- 사용자가 요구사항을 변경했을 때 이전 요구사항 텍스트가 제거 또는 명시적으로 무효화되었는가?
- 아첨(sycophancy)으로 인해 이전 답변과 새 답변이 모두 컨텍스트에 공존하지 않는가?
기준: 번복된 정보는 삭제하거나 [무효화됨] 표기를 추가한다. 구조화 컨텍스트(전략 4) 사용 시 필드 업데이트로 자동 처리.
✅ 체크 3: 검토 세션 분리 — “중요한 출력물은 신선한 세션에서 재검토하는가?”
- 중요한 코드, 문서, 계획의 품질 검토를 생산 세션과 동일한 컨텍스트에서만 수행하고 있지 않은가?
- CCR(Cross-Context Review) 패턴이 배포 전 품질 관문(quality gate)으로 구현되어 있는가?
- 검토 에이전트/세션에 생산 세션의 대화 히스토리가 전달되지 않음을 확인했는가?
기준: 고위험 출력물(코드 배포, 중요 문서, 에이전트 계획)은 반드시 독립 세션에서 1회 추가 검토.
✅ 체크 4: 우선순위 명문화 — “충돌 발생 시 어느 정보를 우선하는지 명시되어 있는가?”
- 시스템 프롬프트에 정보 우선순위 규칙이 명시되어 있는가?
- “최신 정보 우선”, “시스템 지시 우선”, “명시적 제약 우선” 등의 메타 규칙이 있는가?
- 파라메트릭 지식과 RAG 컨텍스트가 충돌할 경우의 처리 방침이 설계에 포함되어 있는가?
기준: 모든 프로덕션 에이전트 시스템 프롬프트에 “우선순위 규칙” 절을 포함한다.
✅ 체크 5: 롤백 및 에스컬레이션 — “충돌 감지 시 복구 경로가 있는가?”
- 에이전트가 자체적으로 모순을 감지했을 때 인간 또는 상위 에이전트에게 에스컬레이션하는 로직이 있는가?
- 도구 호출 오류가 반복될 때 이전 체크포인트로 롤백하는 메커니즘이 있는가?
- “반복 자기 개선”이 충돌을 해소하지 못할 경우 클린 재시작 옵션이 있는가?
기준: 오류 N회 반복 → 롤백 또는 에스컬레이션을 자동화한다. 단순 재시도 루프는 컨텍스트 드래그를 악화시킨다.
6. 전략 선택 의사결정 트리
flowchart TD A["컨텍스트 충돌 징후 감지"] --> B{충돌 유형?} B -->|"시간적 충돌<br/>(이전 답변 vs 새 정보)"| C{컨텍스트 히스토리<br/>접근 가능?} C -->|"Yes"| D["전략 3: 프루닝<br/>+ 전략 7: 롤백"] C -->|"No"| E["전략 6: 우선순위 주입<br/>(시스템 프롬프트 메타 규칙)"] B -->|"출처 간 충돌<br/>(RAG vs 파라메트릭)"| F["전략 9: MACR<br/>또는 시맨틱 엔트로피 기반 감지"] B -->|"지시문 충돌<br/>(시스템 vs 사용자)"| G["전략 6: 우선순위 주입<br/>+ 전략 8: RL 훈련(장기)"] B -->|"자가 생성 충돌<br/>(아첨으로 번복)"| H["전략 2: CCR<br/>+ 전략 7: 롤백"] B -->|"설계 단계 예방"| I["전략 1: 격리<br/>+ 전략 4: 구조화<br/>+ 전략 5: 도구 최소화"]
7. 한계 및 미해결 과제
현재 완화 전략들이 해결하지 못하는 근본적 문제들이 있다.
자동 충돌 탐지의 불안정성. Gokul et al.(2025)이 지적했듯, 자유 텍스트 컨텍스트에서 모순을 자동으로 잡아내는 일은 최신 모델에게도 못 미더운 수준이다. 구조화된 컨텍스트(전략 4)가 부분적인 해법이긴 하나, 모든 형태의 충돌을 구조화할 수는 없다.
CCR의 비용 현실. Cross-Context Review는 구현은 단순하지만 API 호출이 두 배로 든다. 호출이 잦은 에이전트 파이프라인에서는 이 비용이 부담이 된다.
지시 계층의 규모 한계. Zheng et al.(2025)의 RL 훈련은 ~20% 개선을 이뤄냈지만, Zhang et al.(2026, ManyIH-Bench)의 12단계 계층 실험에서는 여전히 정확도가 ~40%에 머물렀다. 계층이 깊어질수록 어떤 접근도 흡족한 수준에 닿지 못한다.
컨텍스트 드래그의 불완전한 해소. Cheng et al.(2026)이 “외부 피드백, 자기 검증, 파인튜닝, 컨텍스트 노이즈 제거 어느 것도 완전히 상쇄하지 못한다”고 결론 내린 대로, 지금은 어떤 단일 전략도 컨텍스트 드래그를 근원에서 풀어내지 못한다.
연계: 06 해결전략 — 멀티에이전트 아키텍처가 이런 한계를 구조적으로 어떻게 우회하는지 다룬다.
참고문헌
- Cross-Context Review: Improving LLM Output Quality by Separating Production and Review Sessions — Tae-Eun Song, 2026, arXiv
- How to Fix Your Context — Drew Breunig, 2025, dbreunig.com
- Reasoning Up the Instruction Ladder for Controllable Language Models — Zheng et al. (Zishuo Zheng, Vidhisha Balachandran, Chan Young Park, Faeze Brahman, Sachin Kumar), 2025, arXiv
- Navigating Unreliable Parametric and Contextual Knowledge: Explicit Knowledge Conflict Resolution for LLM Inference — Peng et al. (Huang Peng, Jiuyang Tang, Weixin Zeng, Hao Xu, Xiang Zhao), 2026, arXiv
- Contradiction Detection in RAG Systems: Evaluating LLMs as Context Validators for Improved Information Consistency — Gokul et al., 2025, arXiv