AI 에이전트 메모리 성능 저하: 멀티턴 LLM가 붕괴하는 이유

심의 시스템을 구축한 지 90분이 지났을 때, 에이전트가 30분 전에 논의했던 아키텍처를 더 이상 참조하지 않기 시작했어요. 세션 로그를 확인해 보니 Claude가 새로운 도구 출력을 위한 공간을 확보하려고 모듈 의존성 그래프를 압축해서 제거한 것이었어요. 에이전트는 계속 코드를 작성했지만, 그 코드에는 첫 한 시간 동안 수립했던 크로스 모듈 계약이 더 이상 반영되어 있지 않았어요. 테스트는 통과했지만 통합에서 실패했어요. 에이전트가 자기 자신의 설계를 잊어버린 거예요.

그 실패로 디버깅에 꼬박 하루를 날렸어요. 이제 연구를 통해 왜 그런 일이 일어났는지 설명할 수 있게 되었어요.

**AI 에이전트 메모리는 멀티턴 대화에서 39% 성능이 저하돼요.** 세 가지 메커니즘이 원인이에요: 컨텍스트 압축이 이전 상태를 버리고, 추론 일관성이 턴을 거치며 파편화되며, 멀티 에이전트 협업이 공유된 기준 사실 없이 무너져요. 더 긴 컨텍스트 윈도우로는 이 문제가 해결되지 않아요. 파일시스템에 상태를 저장하면서 새로운 컨텍스트로 반복하는 방식이 가장 효과적인 완화 전략이며, 15-20%의 오리엔트 오버헤드가 발생해요.

요약

Microsoft Research와 Salesforce가 15개의 LLM를 대상으로 200,000건 이상의 시뮬레이션 대화를 테스트한 결과, 단일 턴에서 멀티턴으로 전환할 때 평균 39%의 성능 하락을 발견했어요.¹ 성능 저하는 단 두 번의 턴만으로도 시작돼요. 세 가지 독립적인 메커니즘이 붕괴를 유발해요: 컨텍스트 압축이 핵심 상태를 버리고, 추론 일관성이 토큰 예산이 줄어들면서 파편화되며, 에이전트 간 협업이 공유된 기준 사실 없이 무너져요. 더 긴 컨텍스트 윈도우로는 이 중 어떤 것도 해결되지 않아요. Ralph 루프 패턴(파일시스템 상태와 함께 반복마다 새로운 컨텍스트)은 압축 손실을 우회하지만 나름의 비용이 발생해요. 아래에서 연구 내용, 세 가지 메커니즘, 지금 바로 실행할 수 있는 탐지 방법, 그리고 멀티턴 회복력을 위한 프로토콜을 다뤄요.

90분의 절벽

컨텍스트가 아키텍처다 포스트에서 650개 파일에 걸친 7계층 컨텍스트 시스템을 문서화한 바 있어요. 이 시스템을 구축하려면 에이전트가 복잡한 아키텍처 상태를 유지해야 하는 장시간 코딩 세션이 필요했어요: 모듈 경계, 의존성 체인, 훅 실행 순서, 크로스 파일 계약 등이요.

2026년 1월과 2월에 걸쳐 30회의 Ralph 루프 반복에서 세션 품질을 측정했어요. 데이터는 일관된 패턴을 보여줬어요:

Minutes 0-30:   Precise multi-file edits, correct cross-references
Minutes 30-60:  Occasional missed imports, still recoverable
Minutes 60-90:  Single-file tunnel vision, loses architectural context
Minutes 90+:    Repetitive attempts, contradicts earlier decisions

이 품질 절벽은 작업 유형에 관계없이 나타났어요. 장시간 리팩토링 세션, 테스트 스위트 구축, 문서화 작업 모두 같은 곡선을 따라 성능이 저하됐어요. 달라진 것은 심각도뿐이었어요: 크로스 파일 상태가 더 많이 필요한 작업일수록 절벽에 더 빨리 도달했고, 단일 파일 작업은 상대적으로 덜했어요.

처음에는 이 패턴을 컨텍스트 윈도우 압박 때문이라고 판단하고 이를 우회하기 위해 Ralph 루프를 구축했어요. 반복마다 새로운 Claude 인스턴스를 생성하고, 파일시스템에서 상태를 주입하며, 한 번의 반복을 넘어서는 대화 메모리에 의존하지 않는 방식이에요. 이 패턴은 효과가 있어요. 하지만 2025년 5월에 발표된 MSR/Salesforce 연구는 이 문제가 컨텍스트 윈도우 크기만의 문제보다 더 구조적이라는 것을 밝혀냈어요.

멀티턴 붕괴의 세 가지 메커니즘

Laban 등은 멀티턴 성능 저하를 독립적인 메커니즘으로 분해했으며, 이 구분이 중요한 이유는 각각 구조적으로 다른 개입이 필요하기 때문이에요.¹

메커니즘 1: 컨텍스트 압축

모든 AI 대화는 유한한 토큰 예산 내에서 작동해요. 대화가 길어지면 시스템이 새로운 콘텐츠를 위한 공간을 만들기 위해 이전 턴을 압축해요. 이 압축은 손실적이에요. 턴 3에서 문서화된 아키텍처 결정이 턴 15까지 살아남지 못할 수 있어요.

심의 시스템 구축 중에 이것을 직접 목격했어요. 에이전트는 처음 20분 동안 모듈 의존성 그래프를 수립했어요: deliberation_engine.py는 consensus_calculator.py에 의존하고, 이것은 다시 vote_aggregator.py에 의존하는 구조였어요. 75분이 지나자 에이전트는 의존성 체인을 압축해서 제거하고 순환 임포트를 작성했어요. 코드는 문법적으로 유효했지만 순환 임포트가 런타임 크래시를 일으켰어요.

탐지 방법: 시간에 따라 에이전트 출력에서 크로스 파일 참조 비율을 추적하세요. 에이전트가 이전에 논의했던 파일을 더 이상 참조하지 않으면, 압축이 관련 컨텍스트를 제거했을 가능성이 높아요.

# Count unique file references per 30-min window in a session log
# Declining count signals compression loss
git log --since="2 hours ago" --pretty=format:"%s" | \
  grep -oP '[a-z_]+\.(py|js|ts)' | sort -u | wc -l

메커니즘 2: 추론 일관성 손실

MSR/Salesforce 연구는 멀티턴 성능 저하가 두 가지 요소로 분해된다는 것을 발견했어요: 미미한 적성 손실과 상당한 신뢰성 저하.¹ 적성은 모델이 올바른 답변을 생성할 수 있는지를 측정하고, 신뢰성은 그것을 일관되게 수행하는지를 측정해요.

단일 턴 모드에서 모델들은 6개 생성 작업에 걸쳐 약 90%의 평균 성능을 달성했어요. 멀티턴 모드에서는 약 65%로 떨어졌어요: 25포인트의 절대적 하락이에요. 핵심 발견: “LLM가 멀티턴 대화에서 잘못된 방향으로 가면, 길을 잃고 회복하지 못해요.”¹

추론 일관성 손실은 에이전트가 자신의 이전 결정과 모순되는 형태로 나타나요. 시스템이 컨텍스트를 압축해서 제거했기 때문이 아니라(메커니즘 1), 모델의 추론 체인이 턴을 걸쳐 파편화되었기 때문이에요. 각 턴의 추론은 지역적으로는 타당하지만 전역적으로는 불일치해요.

Du 등의 인지적 의사결정 라우팅 연구는 이 메커니즘을 직접 다뤄요.² Kahneman의 이중 처리 이론(빠른 직관적 응답 vs. 느린 숙고적 추론)에서 영감을 받아, 이 시스템은 작업 요구에 따라 추론 깊이를 조절해요. 핵심 통찰: 모든 에이전트 턴이 같은 깊이의 추론을 필요로 하는 것은 아니며, 균일한 깊이를 적용하면 사소한 단계에서 예산을 낭비하면서 중요한 결정에는 충분히 투자하지 못하게 돼요.

탐지 방법: 세션 초반과 후반 출력 사이의 모순을 찾으세요. 에이전트가 15분차에 접근법 A를 지지하다가 60분차에 변경을 인정하지 않고 접근법 B를 지지하면, 일관성이 저하된 거예요.

메커니즘 3: 협업 실패

멀티 에이전트 시스템은 멀티턴 성능 저하에 협업 실패까지 더해져요. 두 개 이상의 에이전트가 작업을 협력할 때, 각 에이전트의 컨텍스트는 독립적으로 저하돼요. 공유된 제약 조건을 잊어버린 에이전트는 그것을 중심으로 협업할 수 없어요.

Bhardwaj 등의 Agent Context Protocols는 에이전트 간 구조화된 통신 채널을 수립하여 이 문제를 해결해요.³ 이 프레임워크는 컨텍스트 공유, 오류 전파, 상태 동기화를 위한 명시적 프로토콜을 정의하여 AssistantBench에서 28.3%의 정확도를 달성했어요. Krishnan의 Unified Agent Communication Protocol은 에이전트 간 제로 트러스트 보안 경계까지 확장해요.⁴

10-에이전트 심의 중에 세 명의 리뷰어가 같은 코드 변경을 평가할 때 협업 실패를 직접 경험했어요. 네 번째 리뷰 라운드에 이르자 에이전트들은 코드의 “현재 버전”이 무엇인지에 대해 의견이 갈렸어요. 각 에이전트의 컨텍스트에는 서로 다른 스냅샷이 있었어요. 리뷰가 서로 모순된 것은 의견이 달라서가 아니라 서로 다른 코드를 리뷰했기 때문이에요.

탐지 방법: 멀티 에이전트 워크플로에서 각 에이전트가 보유한 상태 가정을 비교하세요. 에이전트들이 같은 아티팩트의 다른 버전을 참조하면, 협업이 실패한 거예요.

더 긴 컨텍스트 윈도우로 해결되지 않는 이유

멀티턴 성능 저하에 대한 직관적인 대응은 “모델에게 더 많은 토큰을 줘라”예요. MSR/Salesforce 연구는 교묘한 실험 설계로 이 직관을 반박해요.

“Concat” 조건을 테스트했어요: 전체 멀티턴 대화를 하나의 연결된 프롬프트로 제시하는 방식이에요. Concat 조건은 단일 턴 성능의 95.1%를 달성했어요.¹ 컨텍스트 길이는 멀티턴 조건과 동일했어요. 정보 내용도 동일했어요. 유일한 차이는 상호작용 구조였어요: 한 번의 턴 vs. 여러 번의 턴.

39% 성능 저하는 컨텍스트 길이 문제가 아니에요. 컨텍스트 윈도우를 200K에서 400K 토큰으로 두 배로 늘려도 성능 저하는 사라지지 않아요. 성능 저하는 공간 부족이 아니라 턴 경계 자체에서 비롯되기 때문이에요.

Concat 결과는 프로덕션 데이터와도 일치해요. Claude는 약 200,000 토큰의 컨텍스트로 작동해요. 컨텍스트 윈도우 관리 측정에서 가장 긴 단일 세션(3시간 이상, 도구 집중 사용)이 컴팩션이 발동되기 전에 약 180,000 토큰을 소비한다는 것을 확인했어요. 하지만 품질은 윈도우가 가득 차기 훨씬 전에 저하돼요. 90분의 절벽은 컨텍스트 활용률이 약 60-70%일 때 발생하지, 한계점에서 발생하는 게 아니에요. 결과적으로 발생하는 인지적 부채는 에이전트가 개발자가 검증할 수 있는 속도보다 빠르게 코드를 생성하면서 복리로 축적돼요. 이것은 다른 규모에서 나타나는 같은 복합 컨텍스트 문제예요: 각 턴이 이전 내용과 비선형적으로 상호작용하는 정보를 추가해요.

Du 등의 인지적 의사결정 라우팅은 문제를 재정의해요: 문제는 모델이 얼마나 많은 토큰을 보유할 수 있는가가 아니라, 모델이 그 토큰들에 걸쳐 추론 자원을 얼마나 효율적으로 배분하는가예요.² 이 시스템은 간단한 결정은 빠른 추론으로, 복잡한 결정은 숙고적 추론으로 라우팅하여 계산 비용 34% 절감과 일관성 23% 향상을 달성했어요.

새로운 컨텍스트 솔루션 (그리고 그 비용)

Ralph 루프는 메커니즘 1(압축)을 해결하고 메커니즘 2(일관성)를 부분적으로 해결해요. 어느 쪽이든 나타날 만큼 대화를 오래 진행하지 않기 때문이에요. 각 반복은 전체 200K 토큰 컨텍스트를 가진 새로운 Claude 인스턴스를 생성해요. 상태는 대화 메모리가 아닌 파일시스템을 통해 유지돼요.

# Simplified Ralph loop iteration (from jiro-artisan.sh)
while [ "$stories_remaining" -gt 0 ]; do
  # Orient: inject current state from filesystem
  state=$(cat jiro.state.json)
  progress=$(cat jiro.progress.json)
  git_state=$(git diff --stat HEAD)

  # Spawn fresh context with injected state
  claude --print \
    "State: $state" \
    "Progress: $progress" \
    "Git: $git_state" \
    "Task: implement next story from prd.json"

  # Update filesystem state from agent output
  update_state_from_output
done

각 반복은 전체 컨텍스트 예산을 받아요. 이전 턴에서 온 압축 아티팩트가 없어요. 이전 추론 체인에서 온 일관성 파편도 없어요. 파일시스템이 에이전트의 외부 메모리 역할을 해요: jiro.state.json은 현재 스토리를 추적하고, jiro.progress.json은 반복 간 완료된 작업을 기록하며, git diff는 실제로 무엇이 변경되었는지에 대한 기준 사실을 제공해요.

Zhang, Kraska, Khattab의 Recursive Language Models는 보완적인 접근법을 취해요: 새로운 인스턴스를 생성하는 대신, 모델이 컨텍스트를 Python REPL 환경으로 오프로드하고 토큰 공간이 아닌 코드 내에서 컨텍스트를 추론해요.⁵ RLM-Qwen3-8B는 긴 프롬프트를 내부 메모리가 아닌 외부 데이터 구조로 취급하여 장문 컨텍스트 작업에서 기준 대비 28.3% 우수한 성능을 보였어요. Ralph 루프가 상태를 파일로 외부화하는 반면, RLM은 상태를 코드로 외부화해요. 두 패턴 모두 다른 메커니즘을 통해 같은 압축 문제를 해결해요.

Nanda 등의 Wink 시스템은 성능 저하가 이미 진행 중일 때 어떻게 대처하는지를 다뤄요.⁶ 10,000건 이상의 실제 에이전트 궤적을 분석한 결과, 오동작(사양 이탈, 반복 루프, 도구 호출 실패)이 전체 세션의 약 30%에서 발생한다는 것을 발견했어요. Wink는 에이전트의 궤적을 관찰하고 표적화된 경로 수정을 제공하여 단일 개입 오동작의 90%를 해결해요. 탐지는 실시간으로 이루어져요: Wink는 실패가 코드베이스 전체로 전파되기를 기다리지 않고 성능 저하 패턴이 나타나는 즉시 식별해요.

비용

새로운 컨텍스트 반복은 무료가 아니에요. 세 가지 비용이 있어요:

1. 오리엔트 오버헤드. 매 반복마다 이전 반복에서 이미 이해한 상태를 다시 읽는 데 토큰을 소비해요. 측정 결과 각 반복의 토큰 예산 중 15-20%가 오리엔트 단계에 사용돼요: 상태 파일 읽기, 최근 git 이력 스캔, 계속 진행하기에 충분한 컨텍스트 재구축 등이요. 200K 토큰 반복은 약 160-170K 토큰의 실질적 용량으로 시작해요.

2. 암묵적 지식 손실. 대화 컨텍스트는 파일시스템 상태로 포착할 수 없는 암묵적 지식을 담고 있어요: 설계 선택의 이유, 고려하고 기각한 대안들, 접근법 A를 B 대신 선택한 미묘한 이유 등이요. 오리엔트 단계는 사실(무엇이 변했는지, 다음은 무엇인지)을 주입해요. 추론(왜)은 반복 사이에 사라져요.

3. 협업 비용. 여러 Ralph 루프가 동시에 실행되면(병렬 스토리 구현), 각 루프는 독립적인 상태를 유지해요. 루프 간 협업은 단일 장시간 세션이 암묵적으로 처리하는 것을 명시적 병합 로직과 충돌 해결로 대체해야 해요.

비용-편익 계산은 명확해요: 60분 미만의 세션에서는 단일 대화가 더 효율적이에요. 90분을 넘어서면 오리엔트 오버헤드에도 불구하고 새로운 컨텍스트 패턴이 더 높은 품질의 출력을 생산해요. 교차점은 작업 복잡도에 따라 달라요: 크로스 파일 상태가 많으면 교차점이 앞당겨지고, 단일 파일 작업이면 뒤로 밀려요.

성능 저하를 사전에 측정하는 방법

프로덕션 장애가 발생할 때까지 기다릴 필요 없이 멀티턴 성능 저하를 탐지할 수 있어요. 가장 간단한 것부터 가장 철저한 것까지 세 가지 방법이 있어요:

방법 1: 컨텍스트 압력 모니터링

컨텍스트 활용률을 실시간으로 추적하세요. context-pressure.sh 훅은 모든 도구 호출 후에 실행되며 활용률이 60%를 초과하면 경고해요:

# Simplified context pressure check
context_used=$(wc -c < "$CONVERSATION_LOG" | awk '{print int($1/4)}')
context_max=200000
utilization=$(( context_used * 100 / context_max ))

if [ "$utilization" -gt 60 ]; then
  echo "[WARN] Context at ${utilization}% — quality degradation likely"
fi

if [ "$utilization" -gt 80 ]; then
  echo "[CRITICAL] Context at ${utilization}% — start new session"
fi

방법 2: 교차 참조 추적

에이전트가 출력당 참조하는 고유 파일 수를 모니터링하세요. 감소 추세는 압축 손실 신호예요:

# Track file reference diversity in recent commits
for commit in $(git log --oneline -5 --format="%H"); do
  files=$(git diff-tree --no-commit-id --name-only -r "$commit" | wc -l)
  echo "$commit: $files files touched"
done

방법 3: 모순 탐지

시간에 따른 에이전트의 아키텍처 진술을 비교하세요. 에이전트가 20분차에 “모듈 A는 모듈 B에 의존합니다”라고 말하고 70분차에 “모듈 A는 외부 의존성이 없습니다”라고 말하면, 일관성이 저하된 거예요. 자동화 버전: 세션 초반과 후반 출력 사이에서 에이전트의 EXPLAIN 문(또는 설계 코멘트)을 diff 하세요.

컨텍스트 성능 저하 모델: 단일 장시간 세션에서 품질은 컨텍스트 활용률 60% 이후 대략 선형적으로 저하돼요. 새로운 컨텍스트 반복에서는 매 주기마다 품질이 초기화되지만 오리엔트 오버헤드로 15-20%가 손실돼요. 새로운 컨텍스트가 단일 세션을 능가하는 교차점은 작업 복잡도에 따라 60분에서 90분 사이에 발생해요.

멀티턴 회복력을 위한 프로토콜

세 가지 티어가 있으며, 각각 다른 메커니즘을 다뤄요. 티어 1부터 시작하고 필요에 따라 계층을 추가하세요.

티어	해결하는 메커니즘	개입 방법	구현 비용
1	압축	30분마다 파일시스템에 상태 체크포인트	낮음: 5분 설정
2	일관성	60-90분 후 새로운 컨텍스트 반복	중간: 상태 직렬화 필요
3	협업	에이전트 간 명시적 상태 동기화	높음: 프로토콜 설계 필요

티어 1: 상태 체크포인팅

30분마다 에이전트의 현재 아키텍처 이해를 파일로 직렬화하세요. 전체 대화가 아니라 구조적 상태예요: 어떤 모듈이 존재하는지, 어떻게 연결되는지, 어떤 제약 조건이 적용되는지.

# Pre-compaction checkpoint (runs before Claude compresses context)
mkdir -p .claude/checkpoints
cat > ".claude/checkpoints/$(date +%s).md" << 'CHECKPOINT'
## Architectural State
- Module graph: [current understanding]
- Active constraints: [list]
- Design decisions made this session: [list with reasoning]
CHECKPOINT

에이전트의 동작이 저하되면, 저하된 컨텍스트를 계속 사용하는 대신 체크포인트에서 복원하세요.

티어 2: 새로운 컨텍스트 반복

60분을 초과하는 세션에서는 Ralph 루프 패턴으로 전환하세요. 핵심은 오리엔트 단계예요: 새로운 컨텍스트가 전체 대화 이력을 다시 읽지 않고도 생산적으로 계속할 수 있을 만큼 충분한 상태를 주입하는 거예요.

오리엔트 단계에 필요한 상태: 1. 현재 작업과 인수 기준 2. 이전 반복에서 수정된 파일 (git diff에서) 3. 아키텍처 결정과 그 근거 4. 알려진 제약 조건과 실패 모드

티어 3: 에이전트 협업 프로토콜

멀티 에이전트 워크플로에서는 모든 에이전트가 읽고 쓰는 공유 상태 문서를 수립하세요. 이 문서는 기준 사실 역할을 하여, 심의 리뷰 중에 경험한 분기 현상을 방지해요.

{
  "version": 7,
  "last_updated": "2026-02-22T14:30:00Z",
  "active_files": ["engine.py", "calculator.py", "aggregator.py"],
  "constraints": [
    "No circular imports between modules",
    "All public functions require type annotations"
  ],
  "decisions": [
    {"decision": "Use RRF for vote aggregation", "reasoning": "Handles rank-only data", "turn": 3}
  ]
}

모든 에이전트는 자신의 턴 시작 시 이 문서를 읽고 종료 시 업데이트해요. 충돌이 발생하면 조용히 분기되는 대신 협업 일시 중지가 발동돼요. 최고의 에이전트는 이렇게 눈에 보이지 않게 작동해요 — 보이지 않는 에이전트에서 다뤘듯이, 목표는 개발자가 의식하지 않아도 작동하는 인프라예요.

핵심 요약

멀티턴 성능 저하는 구조적 문제이지, 컨텍스트 길이 문제가 아니에요. MSR/Salesforce 연구는 컨텍스트 길이가 동일한 상태에서도 39%의 성능 저하를 보여줬어요. 토큰 한계가 아니라 턴 경계가 붕괴를 유발해요.¹
세 가지 독립적인 메커니즘에는 세 가지 다른 개입이 필요해요. 압축 손실에는 상태 체크포인팅이, 일관성 손실에는 새로운 컨텍스트 반복이, 협업 실패에는 공유 상태 프로토콜이 필요해요.
90분의 절벽은 실재하며 측정 가능해요. 컨텍스트 활용률, 교차 참조 다양성, 아키텍처 모순을 추적하면 프로덕션 장애가 표면화되기 전에 성능 저하를 탐지할 수 있어요.
새로운 컨텍스트 반복은 효과적이지만 15-20%의 오버헤드가 발생해요. Ralph 루프 패턴은 오리엔트 오버헤드와 반복당 전체 컨텍스트 예산을 교환해요. 60-90분을 넘어서면 새로운 컨텍스트가 유리해요.
적응적 추론 배분이 균일한 깊이보다 우수해요. Du 등의 인지적 의사결정 라우팅은 추론 깊이를 작업 요구에 맞춤으로써 비용 34% 절감과 일관성 23% 향상을 달성했어요.²

FAQ

LLM는 왜 멀티턴 대화에서 성능이 저하되나요?

LLM는 세 가지 독립적인 메커니즘을 통해 멀티턴 대화에서 성능이 저하돼요. 컨텍스트 압축이 토큰 예산 내에 새로운 콘텐츠를 넣기 위해 이전 정보를 버려요. 추론 일관성이 모델의 사고 체인이 여러 턴에 걸치면서 파편화되어, 지역적으로는 타당하지만 전역적으로는 불일치한 출력을 만들어요. 여러 에이전트 간 협업이 각 에이전트의 컨텍스트가 독립적으로 저하되면서 실패해요. Microsoft Research와 Salesforce는 15개의 LLM와 200,000건 이상의 대화를 대상으로 평균 39%의 성능 하락을 문서화했으며, 성능 저하는 단 두 번의 턴에서부터 시작돼요.

더 긴 컨텍스트 윈도우로 멀티턴 성능 저하가 해결되나요?

더 긴 컨텍스트 윈도우로는 멀티턴 성능 저하가 해결되지 않아요. MSR/Salesforce 연구에서 전체 대화를 하나의 프롬프트로 제시하는 "Concat" 조건을 테스트했는데, 단일 턴 성능의 95.1%를 달성했어요. 같은 내용을 여러 턴으로 분할하면 약 65%로 떨어졌어요. 성능 저하는 컨텍스트 길이 제한이 아니라 턴 경계 자체에서 비롯돼요. 컨텍스트 윈도우를 두 배로 늘려도 39%의 성능 격차는 사라지지 않아요.

AI 에이전트를 위한 새로운 컨텍스트 반복 패턴이란 무엇인가요?

새로운 컨텍스트 반복은 하나의 긴 대화를 계속하는 대신 각 작업 주기마다 새로운 AI 인스턴스를 생성하는 방식이에요. 상태는 대화 메모리가 아닌 외부 저장소(파일시스템, 데이터베이스)를 통해 유지돼요. 각 반복은 현재 상태를 읽고, 작업을 수행하고, 업데이트된 상태를 다시 기록해요. 이 패턴은 압축 아티팩트와 일관성 파편화를 제거하지만, 새로운 인스턴스가 외부 상태를 읽고 처리하는 "오리엔트" 단계에 15-20%의 오버헤드가 발생해요. 프로덕션 데이터에 따르면 60-90분을 초과하는 작업에서 이 패턴이 단일 세션 접근법을 능가해요.

멀티턴 성능 저하를 장애 발생 전에 어떻게 탐지할 수 있나요?

실무에서 세 가지 탐지 방법이 효과적이에요. 컨텍스트 압력 모니터링은 토큰 활용률을 추적하고 60%를 초과하면(품질 저하 가능성) 또는 80%를 초과하면(새 세션 시작) 경고해요. 교차 참조 추적은 에이전트가 출력당 참조하는 고유 파일 수를 모니터링해요. 감소 추세는 압축 손실 신호예요. 모순 탐지는 시간에 따른 에이전트의 아키텍처 주장을 비교해요. 명시적인 결정 없이 모듈 의존성에 대한 에이전트의 이해가 세션 초반과 후반 출력 사이에서 변하면, 일관성이 저하된 거예요.

LLM 성능이 저하되기까지 몇 턴이 걸리나요?

MSR/Salesforce가 15개의 LLM를 대상으로 200,000건 이상의 대화를 연구한 결과, 성능 저하는 단 두 번의 턴에서부터 시작돼요. 대화가 길어질수록 심각도가 증가하며, 실질적 측정에서 약 60-90분의 연속적 에이전트 상호작용 시점에서 일관된 품질 절벽이 나타나요. 크로스 파일 아키텍처 상태가 필요한 작업은 단일 파일 작업보다 빠르게 저하돼요. 핵심 발견은 LLM가 멀티턴 대화에서 한 번 "잘못된 방향으로 가면" 스스로 수정하지 못하며 — 오류가 후속 턴을 통해 복리로 누적된다는 거예요.

참고문헌

Laban, Philippe, et al., “LLMs Get Lost In Multi-Turn Conversation,” arXiv:2505.06120, May 2025. arxiv.org. Microsoft Research and Salesforce Research. Tested 15 LLMs across 8 model families on 200,000+ simulated conversations. ↩↩↩↩↩↩
Du, Y., et al., “Cognitive Decision Routing in Large Language Models: When to Think Fast, When to Think Slow,” arXiv:2508.16636, August 2025. arxiv.org. Achieved 34% reduction in computational costs with 23% improvement in consistency. ↩↩↩
Bhardwaj, et al., “Agent Context Protocols Enhance Collective Inference,” arXiv:2505.14569, May 2025. arxiv.org. Introduces structured communication protocols for multi-agent coordination, achieving 28.3% accuracy on AssistantBench. ↩
Krishnan, “Beyond Context Sharing: A Unified Agent Communication Protocol,” arXiv:2602.15055, February 2026. arxiv.org. Proposes standardized agent-to-agent orchestration with zero-trust security boundaries. ↩
Zhang, Alex L., Tim Kraska, and Omar Khattab, “Recursive Language Models,” arXiv:2512.24601, December 2025. arxiv.org. MIT CSAIL. RLM-Qwen3-8B outperforms baseline by 28.3% on long-context tasks by offloading context to a Python REPL environment. ↩
Nanda, Rahul, et al., “Wink: Recovering from Misbehaviors in Coding Agents,” arXiv:2602.17037, February 2026. arxiv.org. Misbehaviors occur in approximately 30% of all agent trajectories; Wink resolves 90% of single-intervention cases. ↩
Author’s session quality measurements across 30 Ralph loop iterations, January-February 2026. Data collected from jiro.progress.json session logs and git diff --stat output per iteration. Orient overhead measured by token count of state injection vs. total iteration budget. ↩
Author’s context-is-architecture system. Seven-layer hierarchy across 650 files documented in Context Engineering Is Architecture. ↩
Author’s multi-agent deliberation system. 10-agent consensus with 3-reviewer autonomous code review documented in The Deliberation System. ↩