상위: 04_00_MOC


한줄 요지

멀티턴 대화에서 LLM 성능은 단일턴 대비 평균 39% 하락한다. 원인은 능력(aptitude)의 저하가 아니라 불안정성(unreliability)의 폭증이다. 추론 모델인 o3와 DeepSeek-R1까지 포함해 15개 최첨단 모델이 예외 없이 같은 패턴을 보였다.


1. 문제의식 — 왜 이 연구가 필요했는가

1.1 현실과 평가 방식의 괴리

AI 제품 개발 현장에서 실제 사용자는 한 번에 완전한 명세(single, fully-specified instruction)로 요청하지 않는다. 자기가 원하는 바를 차차 발견해 나가면서, 대화 도중 요구사항을 조각조각 흘린다. 이것이 사람의 자연스러운 소통 방식이다.

그러나 2025년까지도 LLM 성능 평가의 주류는 단일턴(single-turn) 벤치마크였다. 사용자가 모든 정보를 한 번에 정확히 전달한다고 암묵적으로 가정하는 이 방식은 실제 사용 환경과 근본부터 다르다.

Laban et al.(2025)은 이 간극을 실증하기 위해 대규모 시뮬레이션 실험을 설계했다. 질문 자체는 단순하다. 같은 정보를 단일턴으로 한 번에 전달할 때와 멀티턴으로 나눠 전달할 때, LLM 성능은 얼마나 차이가 나는가?

1.2 언더스펙 문제 (Underspecification Problem)

현실 대화에서는 사용자 지시의 상당수가 불완전하다(underspecified). 모델은 빠진 정보를 스스로 추론하거나 명확화(clarification)를 요청해야 한다. 하지만 기존 연구는 이 상황을 체계적으로 다루지 않았다.

이 논문은 언더스펙 멀티턴 대화를 “사용자가 완전한 정보를 쥐고 있으면서도 여러 턴에 걸쳐 조금씩 내놓는” 시나리오로 정의한다. 특수한 최악의 경우가 아니라 일상적인 사용 패턴이다.


2. 저자 소개

저자소속
Philippe LabanMicrosoft Research
Hiroaki HayashiSalesforce Research
Yingbo ZhouSalesforce Research
Jennifer NevilleMicrosoft Research

Microsoft Research와 Salesforce Research의 공동 연구다. 두 기관 모두 LLM 제품을 직접 배포해 본 산업 연구소라는 점에서, 이 연구의 실용적 동기가 잘 드러난다.


3. 방법론 — 샤딩 실험 설계 (Sharding Experiment)

3.1 핵심 아이디어: 샤딩(Sharding)

방법론의 핵심은 샤딩(sharding)이다. 완전히 명세된 단일 지시문을 개별 정보 단위인 여러 개의 “샤드(shard)“로 쪼갠 뒤, 각 샤드를 별도의 대화 턴으로 하나씩 전달하는 방식이다.

예를 들어 “파이썬으로 피보나치 수열을 재귀 방식으로 출력하되, 최대 20개 항목만 출력하고 오류 처리를 포함하라”라는 단일 지시가 있다고 하자. 이를 샤딩하면 다음과 같다.

  • 턴 1: “파이썬으로 피보나치 수열을 출력하는 코드를 작성해 줘”
  • 턴 2: “재귀 방식으로 구현해 줘”
  • 턴 3: “최대 20개 항목만 출력하도록 해 줘”
  • 턴 4: “오류 처리도 추가해 줘”

최종적으로 전달되는 정보는 같지만 전달 방식이 다르다.

3.2 5가지 시뮬레이션 조건

논문은 다섯 가지 실험 조건을 비교한다.

조건설명역할
Full단일턴, 완전 명세 지시기준선(baseline)
Concat단일턴, 샤드를 재조합한 지시포맷 효과 격리
Sharded멀티턴, 샤드를 순서대로 전달핵심 실험 조건
Recap샤딩 + 마지막 턴에 전체 요약재요약 완화 효과 측정
Snowball매 턴마다 누적 요약점진적 재요약 효과 측정

3.3 실험 규모

  • 태스크 6종: 코드 생성(Code), 데이터베이스 쿼리(Database), 액션 시퀀스(Actions), 수학 풀이(Math), 데이터-텍스트 변환(Data-to-text), 문서 요약(Summary)
  • 모델 15개: OpenAI o3, GPT-4.1, GPT-4o, GPT-4o-mini, Claude 3.7 Sonnet, Claude 3 Haiku, Gemini 2.5 Pro, Gemini 2.5 Flash, DeepSeek-R1, Llama 4, Llama 3.3-70B, Llama 3.1-8B 등
  • 지시문: 태스크당 100개, 총 600개
  • 반복 시뮬레이션: 조건마다 N=10회
  • 총 대화 수: 200,000건 이상

소규모 프로빙이 아니라 통계적으로 신뢰할 수 있는 규모의 실증이다.

3.4 성능 분해: 적성 vs. 불안정성 (Aptitude vs. Unreliability)

논문은 전체 성능을 두 구성 요소로 분해한다.

  • A⁹⁰ (적성, Aptitude): 10회 반복 실행 중 상위 90% 성능. 모델이 “가장 잘 풀리는 날”에 낼 수 있는 실력.
  • U (불안정성, Unreliability): 최고 성능과 평균 성능의 차이, 곧 성능의 변동폭.

이 분해에서 논문의 핵심 통찰이 나온다.

graph TD
    A[전체 성능 = Aptitude - Unreliability] --> B[Aptitude A90]
    A --> C[Unreliability U]
    B --> D["단일턴→멀티턴 평균 하락: ~16%<br>(소폭 저하)"]
    C --> E["단일턴→멀티턴 평균 증가: 112%<br>(두 배 이상 폭증)"]
    E --> F["핵심 결론:<br>성능 하락의 주범은<br>능력 손실이 아닌<br>불안정성 폭증"]

4. 핵심 수치 및 결과

4.1 전체 요약

조건평균 성능
Full (단일턴, 완전 명세)90%
Sharded (멀티턴, 분산 명세)65%
하락폭-25포인트 (상대 하락 -39%)

4.2 모델별 상세 성능표

모델Full (단일턴)Sharded (멀티턴)하락 (pp)하락 (%)
o386.6%50.3%-36.3pp-42%
GPT-4.193.4%58.2%-35.2pp-38%
GPT-4o89.0%52.8%-36.2pp-41%
GPT-4o-mini82.5%53.0%-29.5pp-36%
Claude 3.7 Sonnet87.6%51.8%-35.8pp-41%
Claude 3 Haiku64.6%36.5%-28.1pp-43%
Gemini 2.5 Pro94.9%53.1%-41.8pp-44%
Gemini 2.5 Flash91.0%54.2%-36.8pp-40%
DeepSeek-R189.7%51.9%-37.8pp-42%
Llama 3.3-70B80.6%50.4%-30.2pp-37%
Llama 3.1-8B47.4%28.6%-18.8pp-39%

주목할 점: 단일턴 성능이 높은 모델일수록 절대 하락폭(pp)이 크다. Gemini 2.5 Pro는 단일턴 94.9%에서 멀티턴 53.1%로 41.8pp 떨어져 낙폭이 가장 컸다. 더 뛰어난 모델이라고 해서 안전하지는 않다는 뜻이다.

4.3 재요약(Recap/Snowball) 완화 효과

Recap 조건(마지막 턴에 전체 요약을 덧붙임)과 Snowball 조건(매 턴마다 누적 요약)은 성능을 일부 회복시키지만 Full 수준까지는 끌어올리지 못한다. 한번 만들어진 잘못된 답변의 영향은, 나중에 주입되는 정보만으로는 상쇄되지 않는다는 의미다.


5. 직접 인용

“Large-scale simulation experiments comparing single- and multi-turn performance reveal all tested top open- and closed-weight LLMs exhibit significantly lower multi-turn performance, with an average 39% drop across six generation tasks.”

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

“When LLMs take a wrong turn in a conversation, they get lost and do not recover.”

“In single-turn settings, models with higher aptitude tend to be more reliable. The sharded setting paints a different picture…all models we test exhibit very high unreliability.”

“Because of the overly simplified conditions of simulation, we believe the degradation observed in experiments is most likely an underestimate.”


6. 실패 메커니즘 — 왜 LLM은 길을 잃는가

논문은 멀티턴 성능 하락을 일으키는 네 가지 구체적 실패 패턴을 짚는다.

flowchart TD
    S[사용자가 샤드1 전달] --> A

    A["모델이 불완전한 정보로<br>최종 답변 시도(Premature Answer)"]
    A --> B["잠정 답변이 컨텍스트에 정착"]
    B --> C[사용자가 샤드2, 3... 전달]
    C --> D{"모델이 초기 답변에<br>과잉 의존(Overly Rely)"}
    D --> E["답변 비대화(Answer Bloat):<br>초기 오답 + 새 정보의<br>억지 결합"]
    D --> F["중간 턴 정보 무시<br>(Loss-of-Middle Turns)"]
    D --> G["추론 모델의 장황한 사고<br>(Verbosity): 더 많은 가정 생성"]

    E --> H[최종 결과물: 오류 증폭]
    F --> H
    G --> H

6.1 조기 답변 시도 (Premature Answer Attempts)

모델은 정보가 불완전한 상황에서도 완성된 최종 답변을 내놓으려 한다. 이때 사용자가 아직 전달하지 않은 부분에 대해 근거 없는 가정(unfounded assumptions)을 끼워 넣는다. 그렇게 만들어진 초기 답변이 이후 대화 전체의 앵커(anchor)로 굳어 버린다.

6.2 답변 비대화 (Answer Bloat)

처음의 잠정 오답에 새 정보를 억지로 끼워 맞추려는 시도가 반복되면서 답변이 점점 길고 복잡해진다. 길이가 늘어날수록 오류 밀도도 함께 높아진다.

6.3 중간 턴 정보 손실 (Loss-of-Middle Turns)

02 산만에서 다루는 “Lost in the Middle” 현상과 비슷하게, 모델은 대화의 첫 턴과 마지막 턴에 유독 많은 주의를 쏟는다. 그 사이 중간에 전달된 핵심 정보는 묻혀 버리는 구조적 취약점이다.

6.4 추론 모델의 장황성 (Verbosity)

o3나 DeepSeek-R1 같은 추론 강화 모델(reasoning model)은 멀티턴 환경에서 평균 33% 더 긴 응답을 낸다. 더 많이 생각할수록 더 많은 가정을 만들고, 가정이 늘어날수록 잠재적 오류 앵커도 늘어난다. 추론 능력을 강화하는 것이 오히려 멀티턴 불안정성을 키울 수 있다는 역설이다.


7. 완화 시도와 한계

논문은 여러 완화 전략을 실험하고 그 효과를 측정했다.

완화 전략효과결론
온도(temperature) 낮추기거의 없음”ineffective in improving system reliability”
Recap (마지막 턴 전체 요약)부분적Full 수준 회복 불가
Snowball (매 턴 누적 요약)부분적Full 수준 회복 불가
에이전트 프레임워크 적용미미함근본 문제 미해결

핵심은 분명하다. 표준적인 완화 전략으로는 멀티턴 불안정성을 근본적으로 해결할 수 없다. 이는 프롬프트 엔지니어링 차원이 아니라 모델 훈련 방향성 자체의 문제다.


8. 논문의 한계

저자들이 직접 밝힌 한계는 다음과 같다.

  1. 자동화 시뮬레이션 의존: 실제 사용자가 아니라 LLM 기반 시뮬레이션을 사용했다. 실제 사용자의 언어 패턴이나 모호성, 감정적 요소는 반영되지 않았다.

  2. 단순화된 대화 구조: 실험에서는 모든 샤드가 전달되면 최종 정보가 반드시 충족된다. 현실에서는 사용자가 무엇이 필요한지조차 모르는 경우가 많다.

  3. 정형화된 샤드 순서: 실험에서 샤드는 구조화된 순서로 전달된다. 실제 대화는 훨씬 더 비선형적이고 반복적이다.

  4. 분석 태스크 편향: 여섯 태스크가 모두 분석과 생성 위주다. 창의적 글쓰기나 감성적 대화는 다루지 않았다.

  5. 영어 텍스트 한정: 다국어나 멀티모달 능력은 평가 범위 밖이다.

  6. 실제 하락폭은 더 클 가능성: 저자들이 직접 인정하는 대목이다.

“Because of the overly simplified conditions of simulation, we believe the degradation observed in experiments is most likely an underestimate.”

실험에서 측정된 39% 하락은 하한선인 셈이다.


9. 타 챕터 개념과의 연결

graph LR
    P["[[01_00_MOC|01 오염]]<br>할루시네이션이<br>컨텍스트에 진입"] --> CLASH["Context Clash<br>(이 논문의 핵심 현상)"]
    M["멀티턴 누적<br>Laban et al. 2025"] --> CLASH
    A["앵커링 편향<br>Huang et al. 2025<br>arXiv 2505.15392"] --> CLASH
    D["[[02_00_MOC|02 산만]]<br>Lost-in-Middle<br>위치 편향"] --> CLASH
    S["아첨(Sycophancy)<br>Fanous et al. 2025<br>SycEval"] --> CLASH
    CLASH --> E["에이전트 실패<br>성능 폭락<br>불안정성 폭증"]
    CLASH --> F["[[06_00_MOC|06 해결전략]]<br>컨텍스트 격리 필요"]

이 논문이 측정한 현상은 04 충돌 챕터의 Temporal Clash(시간적 충돌) 메커니즘을 가장 직접적으로 보여 주는 사례다. 멀티턴으로 분산된 명세가 컨텍스트 안에서 초기의 잘못된 답변(오염된 정보)과 뒤이은 올바른 정보 사이의 충돌을 빚어 내는데, 이 구조적 패턴을 200,000건이 넘는 대화로 확인했다.


10. 우리 주제(실패모드)에의 시사점

10.1 Context Clash의 핵심 증거

이 논문은 04 충돌 챕터 전체를 떠받치는 핵심 실증 논문이다. 컨텍스트 충돌이 막연한 이론적 우려가 아니라 정량적으로 측정 가능하고 보편적으로 나타나는 현상임을 보여 준다.

10.2 추론 모델도 면역 없음

“추론 모델(reasoning model)을 쓰면 더 안전하다”는 통념을 정면으로 반박한다. o3는 단일턴 86.6%에서 멀티턴 50.3%로 42% 떨어졌고, DeepSeek-R1은 89.7%에서 51.9%로 떨어졌다. 추론 능력을 강화하면 단일턴 성능은 올라가지만 멀티턴 불안정성은 그대로다. 오히려 가정을 더 많이 만들어 내는 장황성(verbosity)이 상황을 악화시키기도 한다.

10.3 AI 전문강사·AX 컨설턴트를 위한 실무 함의

강의 설계 관점: “모델만 업그레이드하면 해결된다”는 고객의 기대를 바로잡을 명확한 수치를 준다. o3 같은 최상위 모델조차 멀티턴에서 42% 떨어진다는 사실은 교육 현장에서 강력한 앵커가 된다.

컨설팅 관점: 기업이 LLM을 고객 응대 챗봇이나 내부 보조 도구로 배포할 때, 단일턴 벤치마크 성능을 실제 사용 성능으로 곧장 기대하지 말라고 경고하는 근거가 된다. 실제 성능은 벤치마크의 65% 수준에 그칠 공산이 크다.

시스템 설계 관점: 멀티턴 대화가 필수인 애플리케이션이라면 컨텍스트 관리 전략이 반드시 따라와야 한다.

  • 초기 불완전 답변의 앵커링 효과를 억제하는 명시적 지시
  • Recap/Snowball보다 더 근본적인 컨텍스트 구조화
  • 에이전트 단계마다 명시적 상태 검증

10.4 1M 토큰 컨텍스트 윈도우 확장의 역설

컨텍스트 윈도우가 커지면 멀티턴 대화를 더 많이 담을 수 있다. 그러나 이 논문이 가리키는 방향은 정반대다. 컨텍스트가 길어질수록 초기 오답 앵커가 늘고, 그만큼 충돌 기회도 많아진다. 용량을 늘린다고 문제가 풀리지는 않는다.


11. 에이전트 환경에서의 특수성

이 논문이 다루는 “사용자가 정보를 멀티턴으로 나눠 전달하는” 시나리오는 에이전트(agent) 환경에서 구조적으로 훨씬 자주 일어난다.

  • 에이전트는 도구(tool)를 반복 호출하며 결과를 순차적으로 컨텍스트에 누적한다
  • 각 도구 호출 결과는 “하나의 샤드”처럼 작용한다
  • 중간 단계 결과가 틀렸을 때, 후속 도구 호출 결과는 충돌 정보가 된다
  • 장기 실행(long-horizon) 태스크에서 초기 계획이 현실과 달라질 때, 이 논문의 메커니즘이 그대로 발동된다

따라서 멀티턴 성능 하락은 단순한 “챗봇 UX 품질” 문제가 아니라 에이전트 아키텍처의 근본적인 신뢰성 문제다. Laban et al.의 실험 결과는 에이전트가 장시간 실행 태스크에서 왜 실패율이 급등하는지를 메커니즘 차원에서 설명해 준다.


참고문헌


관련 노트