AI 에이전트의 기억 붕괴: 멀티턴 대화에서 LLM이 무너지는 이유

심의 시스템⁹을 만들기 시작한 지 90분쯤 지났을 때, 에이전트는 30분 전에 스스로 논의했던 아키텍처를 더 이상 참조하지 않았습니다. 작업 로그를 열어 보니 Claude가 새로운 도구 출력을 넣을 자리를 만들려고 모듈 의존성 그래프를 압축해 버린 상태였습니다. 에이전트는 계속 코드를 썼지만, 그 코드는 첫 한 시간 동안 스스로 세워 둔 모듈 간 계약을 더 이상 반영하지 않았습니다. 테스트는 통과했고, 통합은 실패했습니다. 에이전트가 자기 설계를 잊어버린 것입니다.

그 실패로 하루를 통째로 디버깅에 썼습니다. 왜 그런 일이 벌어졌는지는 이제 연구가 설명해 줍니다.

핵심 요약

Microsoft Research와 Salesforce는 LLM 15종을 20만 건이 넘는 시뮬레이션 대화에 투입해, 단일 턴에서 멀티턴으로 넘어갈 때 성능이 평균 39% 떨어진다는 사실을 확인했습니다.¹ 저하는 단 두 턴 만에도 시작됩니다. 붕괴를 일으키는 메커니즘은 서로 독립적인 세 가지입니다. 컨텍스트 압축이 중요한 상태를 버리고, 토큰 예산이 줄면서 추론의 일관성이 조각나고, 공유된 사실 기준이 없어 에이전트 간 협업이 무너집니다. 컨텍스트 창을 늘려도 이 중 어느 것도 해결되지 않습니다. Ralph 루프 패턴(반복마다 새 컨텍스트 + 파일 시스템 상태)은 압축 손실을 비껴가지만 그 나름의 비용을 안고 옵니다. 아래에서 연구 내용, 세 가지 메커니즘, 오늘 당장 돌려볼 수 있는 탐지 방법, 그리고 멀티턴 내구성을 확보하기 위한 절차를 차례로 다룹니다.

90분의 절벽

제가 쓴 컨텍스트는 곧 아키텍처라는 글⁸에서는 650개 파일에 걸친 7계층 컨텍스트 체계를 정리했습니다. 그런 시스템을 만들려면 긴 코딩 작업이 필요했고, 그동안 에이전트는 모듈 경계, 의존성 사슬, 훅 실행 순서, 파일 간 계약 같은 복잡한 아키텍처 상태를 계속 붙들고 있어야 했습니다.

2026년 1월과 2월에 걸쳐 Ralph 루프 30회 반복에 대해 작업 품질을 측정했습니다.⁷ 데이터에는 일관된 패턴이 나타났습니다.

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분쯤 되자 에이전트는 이 의존성 사슬을 압축해 날려 버리고 순환 import를 작성했습니다. 문법상으로는 멀쩡한 코드였고, 그 순환 import는 런타임 크래시를 냈습니다.

탐지 방법: 에이전트 출력에서 파일 간 참조 비율이 시간에 따라 어떻게 변하는지 추적하세요. 앞서 다뤘던 파일을 더 이상 언급하지 않기 시작했다면, 압축이 해당 컨텍스트를 버렸을 가능성이 큽니다.

# 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 연구는 멀티턴 성능 저하가 두 요소로 나뉜다는 점을 밝혔습니다. 하나는 소폭의 능력 저하이고, 다른 하나는 큰 폭의 불안정성 증가입니다.¹ 능력은 모델이 정답을 만들어낼 수 있는지를 재고, 안정성은 그것을 얼마나 꾸준히 해내는지를 잽니다.

단일 턴 방식에서 모델들은 여섯 가지 생성 과제에 걸쳐 평균 90% 안팎의 성능을 냈습니다. 멀티턴 방식에서는 약 65%로 떨어졌습니다. 절대치로 25포인트 하락입니다. 결정적인 발견은 이것입니다. “LLM은 멀티턴 대화에서 한 번 길을 잘못 들면, 그대로 헤매며 되돌아오지 못한다.”¹

추론 일관성 상실은 에이전트가 스스로 앞서 내린 결정을 뒤집는 형태로 드러납니다. 시스템이 컨텍스트를 압축해 없앴기 때문(메커니즘 1)이 아니라, 모델의 추론 사슬이 턴을 넘나들며 조각났기 때문입니다. 각 턴의 추론은 국소적으로는 타당하지만 전체적으로는 앞뒤가 맞지 않습니다.

Du 연구진의 인지적 의사결정 라우팅 연구는 바로 이 메커니즘을 정면으로 다룹니다.² 카너먼의 이중 처리 이론(빠른 직관적 반응 대 느린 숙고형 추론)에서 출발한 이들의 시스템은 과제가 요구하는 바에 따라 추론의 깊이를 조절합니다. 핵심 통찰은 이렇습니다. 에이전트의 모든 턴이 같은 깊이의 추론을 필요로 하지는 않으며, 깊이를 일률적으로 적용하면 사소한 단계에 예산을 낭비하는 동시에 정작 중요한 결정에는 충분히 투자하지 못합니다.

탐지 방법: 초반 출력과 후반 출력 사이의 모순을 찾으세요. 15분 시점에는 A안을 주장했는데 60분 시점에는 아무런 언급 없이 B안으로 갈아탔다면, 일관성이 무너진 것입니다.

메커니즘 3: 협업 실패

다중 에이전트 시스템에서는 멀티턴 성능 저하 위에 협업 실패가 얹힙니다. 둘 이상의 에이전트가 한 과제를 함께 처리할 때, 각 에이전트의 컨텍스트는 제각기 따로 무너집니다. 공유 제약 조건을 잊어버린 에이전트는 그 제약에 맞춰 움직일 수 없습니다.

Bhardwaj 연구진의 Agent Context Protocols는 에이전트 사이에 구조화된 통신 경로를 세워 이 문제를 다룹니다.³ 이들의 프레임워크는 컨텍스트 공유, 오류 전파, 상태 동기화에 대한 명시적 규약을 정의해 AssistantBench에서 28.3%의 정확도를 달성했습니다. Krishnan의 Unified Agent Communication Protocol은 여기에 에이전트 간 제로 트러스트 보안 경계를 더해 확장했습니다.⁴

저는 10개 에이전트가 참여한 심의에서 협업 실패를 겪었습니다. 리뷰어 세 명이 같은 코드 변경을 평가하는 구조였는데, 네 번째 리뷰 라운드에 이르자 에이전트들이 “코드의 현재 버전”이 어떤 모습인지에 대해 서로 갈라섰습니다. 각 에이전트의 컨텍스트가 저마다 다른 스냅샷을 붙들고 있었던 것입니다. 리뷰가 서로 어긋난 이유는 의견이 달라서가 아니라, 애초에 서로 다른 코드를 보고 있었기 때문입니다.

탐지 방법: 다중 에이전트 작업에서는 각 에이전트가 붙들고 있는 상태 가정을 서로 비교하세요. 같은 산출물의 서로 다른 버전을 참조하고 있다면 협업은 이미 깨진 것입니다.

컨텍스트 창을 넓혀도 해결되지 않는 이유

멀티턴 성능 저하에 대한 직관적인 대응은 “토큰을 더 주자”입니다. MSR/Salesforce 연구는 영리한 실험 설계로 이 직관을 반박합니다.

연구진은 “Concat” 조건을 실험했습니다. 멀티턴 대화 전체를 하나로 이어 붙여 단일 프롬프트로 제시하는 방식입니다. 이 조건은 단일 턴 성능의 95.1%에 도달했습니다.¹ 컨텍스트 길이는 멀티턴 조건과 동일했고, 담긴 정보도 동일했습니다. 차이는 오직 상호작용의 구조, 즉 한 번의 턴이냐 여러 번의 턴이냐뿐이었습니다.

39%의 성능 저하는 컨텍스트 길이 문제가 아닙니다. 컨텍스트 창을 20만에서 40만 토큰으로 두 배 늘려도 저하는 사라지지 않습니다. 저하를 낳는 것은 공간 부족이 아니라 턴 경계 그 자체이기 때문입니다.

Concat 결과는 제 실제 운영 데이터와도 맞아떨어집니다. Claude는 약 20만 토큰의 컨텍스트로 동작합니다. 제가 컨텍스트 창 관리에서 측정한 바로는, 가장 긴 단일 작업(3시간 이상, 도구 사용이 많은 경우)이 압축이 걸리기 전까지 약 18만 토큰을 소모했습니다. 하지만 품질은 창이 다 차기 훨씬 전에 무너집니다. 90분의 절벽은 경계선이 아니라 컨텍스트 사용률 60~70% 근처에서 나타납니다. 그렇게 쌓인 인지 부채는 에이전트가 개발자의 검증 속도보다 빠르게 코드를 뽑아내면서 눈덩이처럼 불어납니다. 규모만 다를 뿐 복리로 쌓이는 컨텍스트와 같은 문제입니다. 매 턴이 앞선 내용과 비선형적으로 얽히는 정보를 더하는 것이죠.

Du 연구진의 인지적 의사결정 라우팅은 문제의 틀 자체를 다시 잡습니다. 관건은 모델이 몇 개의 토큰을 담을 수 있느냐가 아니라, 그 토큰들에 추론 자원을 얼마나 효율적으로 배분하느냐입니다.² 이들의 시스템은 단순한 판단은 빠른 추론으로, 복잡한 판단은 숙고형 추론으로 흘려보내 연산 비용을 34% 줄이면서 일관성은 23% 끌어올렸습니다.

새 컨텍스트로 가는 해법(그리고 그 대가)

Ralph 루프는 메커니즘 1(압축)을 해결하고 메커니즘 2(일관성)를 부분적으로 해결합니다. 둘 중 어느 것도 발현될 만큼 대화를 길게 끌고 가지 않기 때문입니다. 반복할 때마다 20만 토큰의 컨텍스트를 온전히 가진 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 시스템은 성능 저하가 이미 진행 중일 때 무엇을 할 수 있는지를 다룹니다.⁶ 실제 에이전트 실행 궤적 1만 건 이상을 분석한 결과, 명세 이탈, 반복 루프, 도구 호출 실패 같은 오작동이 전체 작업의 약 30%에서 발생했습니다. Wink는 에이전트의 궤적을 관찰하다가 표적 교정을 넣어, 한 번의 개입으로 해결되는 오작동의 90%를 처리했습니다. 탐지는 실시간으로 이뤄집니다. 실패가 코드베이스 전체로 번질 때까지 기다리는 것이 아니라, 저하 패턴이 나타나는 순간에 잡아냅니다.

그 대가

새 컨텍스트로 반복하는 방식은 공짜가 아닙니다. 대가는 세 가지입니다.

1. 상황 파악 부담. 반복할 때마다 직전 반복이 이미 이해하고 있던 상태를 다시 읽는 데 토큰을 씁니다. 제 측정으로는 각 반복 토큰 예산의 15~20%가 상황 파악 단계로 들어갑니다. 상태 파일을 읽고, 최근 git 이력을 훑고, 이어가기에 충분한 만큼 컨텍스트를 다시 세우는 과정입니다. 20만 토큰짜리 반복은 실제로 쓸 수 있는 용량 약 16만~17만 토큰에서 출발하는 셈입니다.

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로 비교하면 됩니다.

멀티턴 내구성을 위한 절차

세 단계로 나뉘며, 각 단계는 서로 다른 메커니즘을 다룹니다. 1단계부터 시작해 필요에 따라 층을 더하세요.

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% 높였습니다.²

자주 묻는 질문

참고 문헌