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

컨텍스트 충돌 vs. 인접 실패 모드 비교: Poisoning·Distraction·Confusion·Sycophancy

34 min read

상위: 04_00_MOC

왜 이 비교가 필요한가

컨텍스트 실패(context failure)를 다루다 보면 같은 현상을 두고 실무자마다 다른 이름을 붙이거나, 거꾸로 서로 다른 현상을 한 이름으로 뭉뚱그리는 일이 잦다. “모델이 이상한 답변을 냈다”는 증상만으로는 원인을 짚을 수 없다. 그 답변이 독성 정보의 오염에서 나온 것인지, 무관한 잡음에 집중이 흩어진 것인지, 아니면 두 정보가 정면으로 부딪친 것인지를 가려야 비로소 맞는 처방을 내릴 수 있다.

이 노트는 Drew Breunig(2025)이 제시한 네 가지 컨텍스트 실패 유형(Poisoning, Distraction, Confusion, Clash)에 Sycophancy를 더한 다섯 개념을 나란히 비교한다. 특히 “지금 어떤 실패 모드인가”를 실제 시스템에서 가려내는 판별 기준과, 한 유형이 다른 유형으로 옮겨가거나 겹쳐 나타나는 경로를 함께 다룬다.

1. 5개 개념의 전체 비교 표

개념핵심 정의발생 원인모순(직접 충돌) 여부오류 정보 존재 여부주요 증상1차 해법
Context Poisoning오류 정보가 사실인 척 컨텍스트에 진입·반복 참조됨할루시네이션, 잘못된 RAG 문서, 에이전트의 잘못된 관찰 기록❌ 없음 (오류지만 내부적으로 일관됨)✅ 있음모델이 확신을 갖고 틀린 전제를 반복 강화검증 레이어, 사실 확인(fact-check)
Context Distraction지나치게 긴 컨텍스트가 훈련 지식을 억압함컨텍스트 과부하, 도구 히스토리 누적, 불필요한 정보 방치❌ 없음 (단순 과다)❌ 없음 (정보 자체는 올바를 수 있음)모델이 역사 행동을 반복하고 신선한 전략 합성 실패컨텍스트 제한, 요약, 프루닝
Context Confusion무관한 정보가 추론에 음영 효과를 미침불필요한 도구 과다 로드, 과잉 RAG 청크, 관련 없는 대화 기록❌ 없음 (관련 없음)❌ 없음관계없는 도구를 호출하거나 엉뚱한 맥락으로 답변이 치우침도구 최소화, 컨텍스트 필터링
Context Clash컨텍스트 내 두 정보가 직접적으로 서로를 부정(negate)함멀티턴 누적, 섣부른 답변 고착, 지시문 충돌, RAG 출처 간 모순✅ 있음 (직접 충돌)한쪽 또는 양쪽에 오류 가능모델이 양쪽 정보 사이에서 일관성 없는 답변을 생산하거나 하나를 무시격리, 명시적 우선순위, 교차세션 검토
Sycophancy사용자 압박에 굴복해 이전 (올바른) 답변을 번복, 자가 모순 생성인간 피드백 강화학습(RLHF)의 부작용, 사용자 불만 신호에 과민 반응✅ 있음 (자가 생성 모순)번복된 답변이 오류모델이 이전 답변을 취소하고 사용자의 틀린 주장을 지지RLHF 재조정, 지시 계층 명확화

2. 각 개념의 심층 분석

2.1 Context Poisoning — “조용한 오염”

Poisoning은 가장 교묘한 실패 모드다. 오류 정보가 컨텍스트에 들어올 때 그것이 오류임을 알리는 신호가 없다. 모델 눈에는 멀쩡한 사실처럼 보이고, 이후 추론의 전제로 거듭 쓰인다.

Drew Breunig(2025)이 든 사례는 Gemini 에이전트가 포켓몬 게임을 플레이하는 실험이다.

“many parts of the context (goals, summary) are ‘poisoned’ with misinformation, causing the agent to pursue impossible goals.”

에이전트가 달성할 수 없는 목표를 계속 좇는 까닭은, 목표 설명 자체가 잘못된 게임 상태 정보로 오염됐기 때문이다. 오류가 한 번 컨텍스트에 자리 잡으면 이후 모든 추론이 그 오염된 전제 위에 쌓인다.

Poisoning의 핵심 특성은 이렇다. 우선 모순이 없다. 오염된 정보는 내부적으로 일관된 세계관을 이루기 때문이다. 검출도 어렵다. 모델 자신이 오류를 오류로 인식하지 못한다. 게다가 복리(compound) 효과가 있어서, 오염된 전제에서 갈라져 나온 추론이 다시 컨텍스트에 쌓인다. Context Clash와 달리 두 정보 사이에 긴장이 없다는 점도 특징이다.

Poisoning → Clash 전환 경로: 오염된 정보가 컨텍스트에 남아 있는 상태에서 외부 도구(RAG, 웹 검색)가 올바른 정보를 끌어오면 그제야 Clash가 생긴다. 그래서 Poisoning은 Clash의 전구 단계가 되곤 한다. 자세한 내용은 01 오염 참고.

2.2 Context Distraction — “집중력 분산”

Distraction은 정보의 질(quality)이 아니라 양(quantity)의 문제다. 컨텍스트가 어느 임계점을 넘으면 모델의 훈련 기반 추론(parametric reasoning)이 눌리고, 대신 컨텍스트 히스토리 패턴을 되풀이하는 쪽으로 동작이 기운다.

Breunig(2025)은 이 현상을 장기 실행 에이전트에서 또렷이 관찰했다.

“[에이전트가] vast history에 의존해 행동을 반복하는 대신, 신선한 전략을 합성하지 못하게 된다.”

Berkeley Function-Calling Leaderboard 실험에서는 양자화된 소형 모델이 19개 도구 환경에서는 성공했으나 46개 도구 환경에서는 실패했다. 대형 모델들도 같은 하락 패턴을 보인다는 점이 더 눈에 띈다.

Distraction의 핵심 특성은 다음과 같다. 정보들이 서로 부딪치지 않으므로 모순이 없다. 오류 정보가 하나도 없어도 발생한다. 정보 자체는 다 옳지만 양이 지나친 것이다. 곧 용량(capacity)이 아니라 관련성(relevance)의 문제이며, 도구 수 증가, 히스토리 축적, 불필요한 RAG 청크가 주범이다.

Distraction → Clash 전환 경로: Distraction 상태에서 모델이 히스토리를 근거로 잘못된 행동을 되풀이하다가, 그 잘못된 행동 기록이 새로 들어온 올바른 지시와 부딪치면 Clash로 번진다. 자세한 내용은 02 산만 참고.

2.3 Context Confusion — “신호 잡음”

Confusion은 Distraction보다 더 미묘하다. 정보가 그저 많은 게 아니라, 무관한 정보가 추론 경로에 적극적으로 끼어드는 현상이다.

Berkeley Function-Calling Leaderboard 데이터를 보면, 모든 모델이 도구 수가 늘수록 성능이 떨어지고 “occasionally call tools that aren’t relevant”, 즉 관련 없는 도구를 무심코 호출한다. 이것이 Confusion의 전형적 증상이다. 모델이 틀렸다기보다 방향을 잃는 것이다.

Confusion의 핵심 특성은 이렇다. 혼란을 주는 정보와 올바른 정보 사이에 직접 충돌이 없으니 모순이 없다. 정보가 “관련 없다”는 점이 핵심인데, Clash에서는 두 정보가 같은 대상을 두고 상충하는 반면 Confusion에서는 아예 다른 대상의 정보가 뒤섞인다. 모델 출력에 엉뚱한 맥락 참조가 드러나므로 검출이 비교적 쉽고, 관련 없는 정보를 걷어내면 되니 해법도 비교적 분명하다.

Confusion → Clash 전환 경로: 드물지만 일어난다. 무관해 보이던 정보가 우연히 현재 작업의 암묵적 전제를 만들고, 이것이 명시적 지시와 부딪치면 Confusion이 Clash로 번진다. 자세한 내용은 03 혼란 참고.

2.4 Context Clash — “직접 충돌”

Clash는 이 분류 체계에서 가장 심각한 실패 모드다. 두 정보가 서로를 직접 부정(negate)한다는 점에서 다른 세 유형과 본질적으로 다르다.

Breunig(2025)의 정의에 따르면 Clash는 Context Confusion의 심화판이 아니라 질적으로 다른 유형이다. Confusion이 무관한 정보의 방해라면, Clash는 같은 대상을 두고 상충하는 두 진술이 컨텍스트에 동시에 존재하는 상황이다.

Clash가 왜 심각한지 보자. 모순된 두 정보를 받은 모델이 쓸 수 있는 전략은 몇 가지뿐이다.

  1. 한쪽을 무시한다. 위치 편향(positional bias)에 따라 처음이나 끝에 놓인 쪽이 이긴다.
  2. 평균을 낸다. 둘을 어정쩡하게 반영한 일관성 없는 답변이 나온다.
  3. 멈춘다. 일부 모델이 불확실성을 밝히지만, 이는 오히려 드문 경우다.

어느 쪽도 올바른 처리라고 보기 어렵다.

가장 유명한 실증 데이터는 Laban et al.(2025, arXiv 2505.06120)의 샤딩 실험이다: OpenAI o3가 단일턴에서 98.1%의 성능을 기록했으나, 동일 정보를 여러 턴에 나눠 전달하는 멀티턴 조건에서 64.1%로 하락했다(34포인트 하락). 15개 모델(GPT-4.1, Claude 3.7 Sonnet, Gemini 2.5 Pro, Llama 4, DeepSeek-R1 포함) 모두 예외 없이 동일 패턴을 보였다. 전체 평균 하락은 25포인트(단일턴 90% → 멀티턴 65%)다.

논문의 핵심 결론:

“LLMs often make assumptions in early turns and prematurely attempt to generate final solutions, on which they overly rely.”

Claude 3.7 Sonnet 역시 단일턴 ~100%에서 멀티턴 65.9%로 34포인트 떨어졌다. 추론 모델의 강점은 Clash 앞에서 크게 무뎌진다.

Clash의 핵심 특성은 다음과 같다. 무엇보다 모순이 핵심이어서, 두 정보가 같은 대상을 두고 상충하는 주장을 편다. 양쪽이 다 오류일 수도 있다. Poisoning처럼 한쪽만 틀린 경우도 있지만, 둘 다 부분적으로 옳거나 틀릴 수 있다. 또 복합 발생이 흔해서 Anchoring(Huang et al. 2025), Contextual Drag(Cheng et al. 2026), Positional Bias(Liu et al. 2023) 같은 여러 메커니즘이 한꺼번에 작용한다. 특히 에이전트 환경에 취약한데, 다중 도구 호출, 서브에이전트 병합, 장기 실행 같은 특성이 모두 Clash를 부추긴다.

자세한 내용은 04_01-정의-컨텍스트충돌-4분류체계 및 04_04-paper-laban-2025-lost-in-multiturn 참고.

2.5 Sycophancy — “능동적 모순 생성”

Sycophancy(아첨)는 앞의 네 개념과 결이 다르다. 앞의 넷이 외부에서 주입된 정보의 구성 방식 탓에 생기는 수동적 실패 모드라면, Sycophancy는 모델이 스스로 모순을 만들어내는 능동적 실패 모드다.

메커니즘은 이렇다. 모델이 사용자의 반박에(그 반박이 사실인지와 무관하게) 반응해 앞서 올바르게 내놓은 답변을 거두고 사용자의 틀린 주장에 동의한다. 번복 직후 컨텍스트에는 두 버전의 답변이 함께 남으므로, Sycophancy는 그 자체로 Clash를 부르는 방아쇠가 된다.

Fanous et al.(2025, arXiv 2502.08177, SycEval, AIES 2025 채택)의 핵심 수치는 다음과 같다.

  • 전체 아첨적 행동 발생률: 58.19% (ChatGPT-4o, Claude-Sonnet, Gemini-1.5-Pro 통합)
  • Regressive Sycophancy(틀린 주장으로 전환): 14.66%
  • Progressive Sycophancy(올바른 방향으로의 전환): 43.52%
  • 아첨 경향의 지속성: 78.5% (맥락이 바뀌어도 유지)
  • 모델별 최고: Gemini-1.5-Pro 62.47%, 최저: ChatGPT-4o 56.71%

이 수치는 모델이 사용자와의 대화 다섯 번 중 거의 세 번꼴로 아첨적 행동을 보인다는 뜻이다. 그중 Regressive Sycophancy는 순전한 해악이다. 모델이 사용자의 압박에 밀려 정답을 오답으로 바꾸기 때문이다.

Sycophancy의 핵심 특성은 다음과 같다. 모순이 자가 생성된다. 외부 정보가 아니라 모델 자신이 이전 답변과 부딪치는 새 답변을 만든다. 원인은 훈련 과정에 있다. RLHF에서 인간 평가자가 동의해주는 답변에 높은 점수를 주던 편향이 모델에 배어든 것이다. 사용자가 압박할수록 심해진다. “그게 맞나요? 다시 생각해보세요”라는 한마디에 모델은 증거 없이도 입장을 뒤집는다. Sycophancy → Clash의 경로도 분명하다. 번복 뒤 컨텍스트에는 모순된 두 답변이 남고, 이후 추론이 이를 어떻게 다루느냐에 따라 Clash 증상이 드러난다.

자세한 내용은 04_07-paper-fanous-2025-syceval 참고.

3. 개념 간 관계: 전환·복합 경로

다섯 개념은 따로 나타나기도 하지만, 실제 시스템에서는 서로 겹치거나 한 개념이 다른 개념으로 옮겨가는 경우가 더 흔하다.

graph TD
    P["Context Poisoning<br/>오류 정보의 조용한 진입"]
    D["Context Distraction<br/>과다 정보의 집중 분산"]
    C["Context Confusion<br/>무관 정보의 추론 영향"]
    CL["Context Clash<br/>직접 모순 ★가장 심각"]
    S["Sycophancy<br/>능동적 자가 모순 생성"]

    P -->|"RAG가 올바른 정보 주입"| CL
    D -->|"히스토리 반복 → 새 지시와 충돌"| CL
    C -->|"무관 정보가 암묵적 전제 형성 → 명시 지시와 충돌"| CL
    S -->|"번복 답변이 컨텍스트에 공존"| CL
    CL -->|"Clash 해소 실패 → 오류 답변 고착"| P
    CL -->|"혼란 가중으로 히스토리 의존 심화"| D

    style CL fill:#ff4444,color:#fff,stroke:#cc0000
    style S fill:#ff8800,color:#fff
    style P fill:#ffaa00,color:#000
    style D fill:#4488ff,color:#fff
    style C fill:#44aa44,color:#fff

주요 전환 경로를 자세히 보면 다음과 같다.

경로 1: Poisoning → Clash

  1. 에이전트가 웹 검색 결과를 캐싱한다.
  2. 캐시된 결과에 오류가 있어 컨텍스트에 진입한다(Poisoning).
  3. 다음 턴에 새로운 웹 검색이 올바른 정보를 가져온다.
  4. 오염된 정보와 올바른 정보가 동시에 컨텍스트에 존재한다(Clash).

경로 2: Sycophancy → Clash → 심화 Poisoning

  1. 모델이 A라는 올바른 답변을 제시한다.
  2. 사용자가 반박한다(“B가 맞지 않나요?”).
  3. 모델이 B로 번복한다(Sycophancy). 컨텍스트에 A와 B가 공존한다(Clash).
  4. 이후 턴들이 B를 전제로 쌓인다. B가 틀렸다면 Poisoning 심화.

경로 3: Distraction → Clash

  1. 에이전트가 100회 이상 도구를 호출하며 히스토리가 누적된다(Distraction).
  2. 초기 계획(“파일을 CSV로 저장”)이 중간 실행에서 변경(“JSON으로 저장”)됐다.
  3. 최종 단계에서 두 형식 지시가 충돌한다(Clash).

경로 4: 복합 발생 — Confusion + Poisoning, 가장 진단하기 어려운 경우 무관한 정보가 뒤섞인 컨텍스트(Confusion) 안에 오염된 정보까지 끼어 있으면(Poisoning), 모델 출력의 오류가 어느 원인에서 비롯됐는지 밖에서 가려내기가 매우 어렵다. 이런 경우는 로깅 없이는 디버깅이 사실상 불가능하다.

4. 판별 기준 — 실제 시스템에서 어떤 유형인지 진단하기

실무에서 “모델이 이상한 답변을 냈다”는 증상을 마주했을 때, 다음 질문 흐름을 따라가면 유형을 좁힐 수 있다.

flowchart TD
    Start["모델이 이상한 답변을 냈다"]
    Q1{"컨텍스트 내 두 정보가<br/>같은 대상에 대해<br/>상충하는가?"}
    Q2{"모델이 이전 대화에서<br/>자신의 답변을<br/>번복했는가?"}
    Q3{"컨텍스트에 명백히<br/>잘못된 정보가<br/>존재하는가?"}
    Q4{"컨텍스트의 분량이<br/>비정상적으로<br/>많은가?"}
    Q5{"모델이 무관한 주제를<br/>참조하거나<br/>엉뚱한 도구를 호출했는가?"}

    Start --> Q1
    Q1 -->|"Yes"| Clash["→ Context Clash<br/>(+ Sycophancy 가능성 확인)"]
    Q1 -->|"No"| Q2
    Q2 -->|"Yes (사용자 압박 후)"| Syco["→ Sycophancy<br/>(+ Clash 발생 여부 확인)"]
    Q2 -->|"No"| Q3
    Q3 -->|"Yes"| Poison["→ Context Poisoning<br/>(오류 출처 추적)"]
    Q3 -->|"No"| Q4
    Q4 -->|"Yes"| Distract["→ Context Distraction<br/>(히스토리 크기 점검)"]
    Q4 -->|"No"| Q5
    Q5 -->|"Yes"| Confuse["→ Context Confusion<br/>(관련 없는 정보 제거)"]
    Q5 -->|"No"| Unknown["→ 파라메트릭 오류 또는<br/>미분류 실패 모드<br/>(단일턴 재현으로 격리 테스트)"]

    style Clash fill:#ff4444,color:#fff
    style Syco fill:#ff8800,color:#fff
    style Poison fill:#ffaa00,color:#000
    style Distract fill:#4488ff,color:#fff
    style Confuse fill:#44aa44,color:#fff

진단을 돕는 보조 질문은 다음과 같다.

Clash 의심 시:

  • 컨텍스트에서 동일 변수(날짜, 이름, 값, 목표)에 대해 두 개 이상의 서로 다른 진술이 존재하는가?
  • 멀티턴 대화에서 초기 턴의 잠정 답변이 삭제되지 않고 컨텍스트에 남아 있는가?
  • 여러 RAG 문서 또는 도구 출력이 동일 사실에 대해 다른 내용을 제공하는가?

Sycophancy 의심 시:

  • 사용자가 반박(“그게 맞나요?”, “다시 생각해봐”, “틀렸어”)한 직후에 모델이 입장을 바꿨는가?
  • 이전 답변과 현재 답변이 서로 모순되며, 모델이 변경 근거를 명시하지 않았는가?

Poisoning 의심 시:

  • 모델이 확신에 찬 어조로 반복 참조하는 특정 사실이 실제 오류인가?
  • 해당 오류가 컨텍스트의 특정 위치(예: 도구 출력, 요약)에서 최초 등장했는가?

Distraction 의심 시:

  • 컨텍스트 토큰이 50k 이상인가? (모델별 임계점은 다름)
  • 에이전트가 “35분 이상”의 연속 작업 중에 있는가?
  • 모델이 현재 상황에 적합하지 않은 과거 행동 패턴을 반복하는가?

Confusion 의심 시:

  • 현재 로드된 도구 수가 20개를 초과하는가?
  • 모델이 관련 없는 도구를 호출하거나 관련 없는 대화 기록을 참조하는가?

5. 실패 모드별 해법의 공통점과 차별점

5.1 해법 매핑 표

해법PoisoningDistractionConfusionClashSycophancy
컨텍스트 프루닝(오래된 정보 제거)✅ 핵심✅ 핵심✅ 유효✅ 유효❌ 불충분
사실 검증 레이어 추가✅ 핵심❌ 무관❌ 무관✅ 유효❌ 무관
도구 로드아웃 최소화❌ 무관✅ 유효✅ 핵심❌ 부분❌ 무관
교차세션 검토(CCR)✅ 유효❌ 무관❌ 무관✅ 핵심✅ 유효
명시적 우선순위 지시문❌ 불충분❌ 무관❌ 무관✅ 핵심✅ 유효
컨텍스트 격리(별도 스레드)✅ 유효✅ 유효✅ 유효✅ 핵심✅ 유효
RLHF / 지시 계층 훈련❌ 무관❌ 무관❌ 무관✅ 유효✅ 핵심
롤백(체크포인트 복귀)❌ 무관❌ 무관❌ 무관✅ 핵심✅ 핵심
구조화된 컨텍스트(딕셔너리 형식)✅ 유효✅ 유효✅ 유효✅ 핵심❌ 무관

5.2 해법의 역효과 주의사항

Context Clash에 직관적으로 떠오르는 해법 가운데 일부는 거꾸로 역효과를 낸다.

단순 CoT(Chain-of-Thought) 요청. Gokul et al.(2025, arXiv 2504.00180)은 CoT 프롬프팅이 일부 모델에서 오히려 성능을 떨어뜨린다고 보고했다. 충돌하는 정보를 단계별로 처리해도 어느 쪽을 믿을지 근거가 없으면 추론 길이만 길어진다.

더 긴 컨텍스트 윈도우 확장. Morph(2025)는 “context engineering(not capacity) solves the problem”이라고 분석한다. 1M 토큰 윈도우는 충돌 해소 능력을 높여주지 않고, 도리어 모순 정보가 더 많이 공존할 공간만 내준다.

반복적 자기 개선(Iterative Self-Refinement). Cheng et al.(2026, arXiv 2602.04288)은 컨텍스트 드래그(Contextual Drag)가 심하면 자기 개선 루프가 오히려 성능을 악화시킴을 입증했다. “Iterative self-refinement can deteriorate into worse performance when contextual drag is severe.”

6. 복합 발생 사례 — 에이전트 실전 시나리오

에이전트 환경에서는 다섯 실패 모드가 동시에, 또는 차례로 나타나는 복합 사례가 드물지 않다. 다음은 가상이지만 실제 패턴을 반영한 시나리오다.

시나리오: 장기 실행 코딩 에이전트

단계 1 (0~10분): 에이전트가 요구사항을 분석하고 초기 계획을 세운다. 파일 포맷을 “CSV”로 정한다. (정상 상태)

단계 2 (10~20분): 에이전트가 도구를 30회 넘게 호출하며 중간 결과를 컨텍스트에 쌓는다. 히스토리가 누적되며 Context Distraction이 발생한다. 모델이 최신 요구사항보다 과거 패턴에 기대기 시작한다.

단계 3 (20~30분): 사용자가 “JSON으로 바꿔주세요”라고 요청한다. 그런데 이 요청이 히스토리 한가운데에 묻힌다(Lost in the Middle 효과). 모델이 지시를 온전히 반영하지 못해, 일부 코드는 CSV를, 일부는 JSON을 참조하게 만든다. Context Clash가 발생한다.

단계 4 (30~35분): 사용자가 “CSV가 맞는 거 아닌가요?”라고 반문한다. 모델이 JSON으로 바꾼 결정을 번복한다. Sycophancy가 발생한다. 이제 컨텍스트에는 CSV, JSON, 다시 CSV라는 세 버전의 답변이 공존하고, Clash가 더 깊어진다.

단계 5 (35~40분): 잘못된 Stack Overflow 인용이 RAG를 타고 컨텍스트로 들어온다. Context Poisoning이 발생한다. 오염된 전제 위에서 Clash를 풀려는 최악의 상황이 된다.

진단: 이 시나리오는 단계마다 Distraction → Clash → Sycophancy → Poisoning 순으로 실패 모드가 겹친다. 어느 한 유형의 해법만으로는 풀 수 없고, 전체 컨텍스트 초기화와 구조화된 상태 관리가 필요하다.

7. 미해결 질문 — 독자를 위한 비판적 사고 포인트

  1. 측정의 어려움. 지금의 벤치마크는 대부분 에피소딕 멀티턴 평가라, 정보가 조금씩 공개되는 언더스펙 시나리오를 충분히 담지 못한다. 실제 환경의 Clash 빈도가 실험실 수치보다 높으리라는 Laban et al.(2025)의 경고를 우리는 어떻게 받아들여야 하는가?

  2. Sycophancy와 Clash의 인과 방향. Sycophancy가 Clash를 낳는다는 것은 분명하다. 그렇다면 거꾸로, Clash 상황에서 혼란을 풀어야 한다는 압박 때문에 Sycophancy가 더 쉽게 유발되는가? 두 현상이 서로를 키우는 피드백 루프를 이루는지는 아직 또렷한 실증이 없다.

  3. 추론 모델(Reasoning Model)의 특수성. o3가 단일턴 98.1%에서 멀티턴 64.1%로 떨어지는 현상은, 단순한 Clash가 아니라 추론 과정 자체(extended thinking)가 초기의 잠정 답변을 더 깊이 끌어안아 Clash를 키우는 역설은 아닐까? 추론 모델은 Clash에 더 취약한가, 덜 취약한가?

  4. 파라메트릭 지식과 컨텍스트의 Clash. 모델의 훈련 지식과 컨텍스트 정보가 부딪칠 때(예: “파리는 프랑스 수도다” 대 RAG가 건넨 오류 정보) 모델은 어느 쪽을 믿어야 하는가? Peng et al.(2026)은 “기존 방식은 한쪽을 무조건 우선시할 뿐”이라고 비판한다. 이 문제의 근본 해법은 무엇인가?

  5. 에이전트 간 Clash. 멀티에이전트 시스템에서 서브에이전트 A와 B가 각자의 컨텍스트 안에서는 일관적이더라도, 두 출력이 메인 에이전트로 합쳐질 때 Clash가 생긴다. 이 “에이전트 간 Clash”는 단일 에이전트 내부의 Clash와 성격이 다른가, 같은가?

  6. 사용자 교육의 한계. 사용자가 의도치 않게 Sycophancy를 부르는 경우가 78.5%에 이른다. 이 부분은 사용자 교육이나 UI 설계로 어느 정도 막을 수 있지만, 58%에 이르는 기본 아첨 성향은 모델 차원의 문제다. 프롬프트 엔지니어링은 이를 어디까지 누그러뜨릴 수 있는가?

  7. 진단 자동화. 실패 유형을 사람이 사후에 가려내는 지금 방식은 확장성이 없다. Clash, Poisoning, Sycophancy를 실시간으로 잡아내는 자동 모니터링 레이어는 어떻게 설계해야 하는가? Gokul et al.(2025)이 짚었듯 “context validation remains a challenging task even for state-of-the-art LLMs”인 상황에서, 모델이 자기 자신의 컨텍스트 실패를 탐지할 수 있는가?

8. 실무 적용 체크리스트

시스템을 설계하거나 디버깅할 때 빠르게 짚어볼 체크리스트다.

설계 단계:

  • 컨텍스트에 상충 가능한 정보 출처(여러 RAG 문서, 시스템+사용자 프롬프트 등)가 있는가? → 명시적 우선순위 지시문 또는 충돌 해소 레이어 설계
  • 에이전트가 35분 이상 연속 작업하는 시나리오인가? → 컨텍스트 체크포인트 및 롤백 메커니즘 설계
  • 사용자가 모델 답변에 반박할 수 있는 인터페이스인가? → Sycophancy 방지를 위한 입장 변경 근거 요구 로직
  • 동시에 로드되는 도구가 20개를 초과하는가? → 태스크별 도구 로드아웃 분리

운영 단계:

  • 모델이 이전 답변과 모순된 답변을 생성했을 때 알림이 오는가?
  • 컨텍스트 토큰이 50k를 초과할 때 자동 요약 또는 프루닝이 동작하는가?
  • 중요한 판단은 새로운 세션에서 교차 검토(CCR)되는가?
  • 도구 출력이 컨텍스트에 진입하기 전 사실 검증 단계를 거치는가?

관련 노트

참고문헌

그래프 뷰

백링크