2편 · 현상 (Consequence)
Lost in the Middle: 위치 기반 정확도 곡선
Lost in the Middle('중간 손실')은 대화가 길어질수록 LLM이 처음에 준 지시를 잊는 현상입니다. 그 이유를 위치별 정확도 곡선으로 알아봅니다.
해설 전문 텍스트로 보기
Lost in the Middle은 우리말로 ‘중간 손실’이라 번역되는 현상입니다. LLM은 컨텍스트의 시작과 끝에 있는 정보는 잘 찾지만, 중간에 있는 정보는 정확도가 30% 이상하락합니다. 모든 주요 LLM에서 동일한 U자형 패턴이 관찰됩니다(출처: Chroma Research · Liu et al. 2023 “Lost in the Middle”).
| 구간 | 위치 | 정확도 | 설명 |
|---|---|---|---|
| 시작 | 0~20% | ~90% | 시스템 프롬프트, 초반 지시사항에 해당. 모델이 또렷하게 기억함 |
| 중간 | 40~60% | ~55% | 30%+ 하락. 긴 대화의 중간, 중간 문서 섹션은 놓칠 가능성 큼 |
| 끝 | 80~100% | ~88% | 최근 메시지, 마지막 질문. 모델이 가장 주목하는 영역 |
Q1. X축이 정확히 뭘 뜻하나요?
X축은 “전체 컨텍스트 윈도우의 몇 %”가 아니라 “내가 지금 실제로 입력한 토큰 안에서의 상대 순번”입니다. 1,000 토큰을 넣었으면 그 1,000 토큰이 0%~100%이고, 800k를 넣었으면 그 800k가 0%~100%로 펼쳐집니다.
- Capacity(컨텍스트 윈도우, 용량): 모델이 한 번에 받아들일 수 있는 최대 토큰 수. 예: 200k, 1M. 책장의 크기에 해당
- Position(토큰 위치, 순번): 실제로 넣은 입력 안에서 토큰의 상대적 자리. 모델이 어디에 주의를 더 주는지 결정. 책장 안에서 책이 꽂힌 위치
핵심: “1M짜리 책장이 커졌다”는 건 더 많이 넣을 수 있다는 뜻이지, 어디든 다 똑같이 잘 본다는 뜻이 아닙니다. 어텐션 가중치는 여전히 입력의 앞과 뒤로 쏠립니다.
Q2. 이 곡선은 언제 강하게 나타나나요?
이 U자형 곡선은 윈도우가 꽉 찼을 때(밀도가 높을 때)의 양상입니다. 1M 윈도우에 1,000 토큰만 넣었다면 사실상 모두 “앞쪽”에 몰려 있어 중간 유실은 거의 없습니다. 반대로 800k~1M를 채우면 “중간”의 범위가 길어져 정보가 급격히 흐려집니다.
밀도의 법칙: 컨텍스트 윈도우가 1M으로 커져도 U자 패턴은 사라지지 않고, 오히려 중간 구간의 폭이 더 넓어집니다. 단순 검색은 잘 되지만, 여러 정보를 조합하는 복합 추론은 중간에서 성능이 급락합니다.
Q3. Smart Zone / Dumb Zone: 절대 토큰 기준의 또 다른 관점
밀도(%) 대신 절대 토큰 수로 보는 관점도 있습니다(출처: AI Hero). 모델이 “또렷하게” 다루는 영역을 Smart Zone, 그 뒤로 어텐션이 흐려지며 정보가 묻히는 영역을 Dumb Zone이라 부릅니다.
- Smart Zone(~80,000–100,000 토큰): 컨텍스트 윈도우 크기와 거의 무관하게 일정. 어텐션이 또렷하게 작동하는 절대 토큰 범위. 200k 윈도우 기준 대략 전체의 40% 안쪽이 ‘스마트’하게 사용되는 한도
- Dumb Zone(Smart Zone 이후 전부): 윈도우가 커지면 늘어나는 건 사실상 이 영역. 정보는 들어가 있지만 모델이 또렷하게 인지하지 못함. “넣을 수는 있다 ≠ 잘 본다”의 핵심
1M 윈도우의 함정: 200k → 1M으로 윈도우가 5배 커져도 Smart Zone은 거의 그대로입니다. 1M 모델에서 100k 정도 채웠을 때(약 10% 점유)가 여전히 Smart Zone 안쪽, 즉 “여유 있는 1M”이 아니라 “Smart Zone 외엔 Dumb Zone이 길어진 1M”입니다.
실용 환산: 200k 컨텍스트 윈도우라면 Smart Zone ≈ 40%, 1M 컨텍스트 윈도우라면 Smart Zone ≈ 8~10%. 헷갈리기 쉬운 지점은 여기입니다. 1M 윈도우를 10%만 채우면 “아직 90%나 남았네”라며 여유롭게 느껴지지만, 그 10%는 이미 약 100k 토큰, 즉 Smart Zone의 끝자락입니다. 윈도우가 클수록 같은 점유율이라도 담기는 절대 토큰 수가 훨씬 많기 때문에, 퍼센트로는 비어 보여도 또렷하게 보는 한계는 이미 넘었을 수 있다는 뜻입니다.
최근 변화: Opus 4.8에서는 모델명 뒤에 [1m] 접미사를 붙여 1M 컨텍스트를 켤 수 있고(예: claude-opus-4-8[1m]), 2026년 6월 출시된 Claude Fable 5(claude-fable-5)는 1M 컨텍스트가 기본값입니다. 하지만 “쓸 수 있다(혹은 기본으로 켜져 있다) ≠ 항상 가득 채워야 한다”입니다. 윈도우가 1M이 돼도 Smart Zone은 그대로 ~80k~100k에 머물러 있고, 늘어난 건 Dumb Zone입니다.
현실 데이터: 넣을 수 있다 ≠ 넣어야 한다
Gene Kim과 Steve Yegge는 『Vibe Coding』에서 전 세계 Git 저장소의 약 80%가 50만(500K) 토큰 컨텍스트 윈도우 안에 통째로 들어간다고 추정합니다. GitIngest, Repomix, files-to-prompt 같은 도구를 쓰면 실제로 저장소 전체를 텍스트 하나로 이어 붙여 그대로 넣을 수 있습니다. 하지만 저자들이 이 통계 바로 뒤에 덧붙인 경고가 이 페이지의 결론과 같습니다. “할 수 있다고 항상 해야 하는 건 아니다.” 500K를 채우는 순간 위 Q3에서 본 Smart Zone(~80k~100k)의 다섯 배를 넘어서고, 저장소의 대부분은 Dumb Zone에 묻힙니다.
출처: Gene Kim·Steve Yegge, 『Vibe Coding』(IT Revolution, 2025) 113쪽, Chapter 10 “Managing Your Cutting Board: AI Context and Conversations”. 원문은 “approximately 80% of Git repositories worldwide can fit within a 500,000 token context window”. 외부 논문이 아니라 저자들의 자체 분석(“based on our analysis”)이며 113쪽 하단 각주에 분석 과정을 담은 ChatGPT 공유 링크가 달려 있습니다.
Q4. 그럼 윈도우를 몇 %까지 채우는 게 좋나요?
입력 밀도에 따라 모델의 안정성이 달라집니다. 1M 윈도우 기준 100k는 10%로 매우 안전한 영역입니다. 같은 질문에 대해 모델마다 견해가 조금씩 다르므로 세 견해를 나란히 두고 비교하면 좋습니다.
Gemini 견해: “밀도의 법칙”, 일반 질의응답·문서 처리 관점
| 점유율 | 상태 | 권장 전략 |
|---|---|---|
| 0 ~ 20% | 안전 | 집중력 최상. 중요한 지시·로직을 자유롭게 배치해도 됩니다. |
| 20 ~ 60% | 주의 | 중간 정보가 희석되기 시작. 핵심은 앞과 뒤에 배치하세요. |
| 60 ~ 90% | 위험 | 중간 유실이 본격적으로 시작. 불필요한 로그·과거 대화를 정리하세요. |
| 90% 이상 | 한계 | 성능 급락. /clear로 세션을 리셋하거나 RAG로 핵심 청크만 추려 넣으세요. |
Gemini의 경험칙: 윈도우 대비 30~40% 밀도에서 가장 안정적인 판단을 내립니다. “꽉 채워야 똑똑하다”가 아니라 “빈 공간이 많을수록 똑똑하다”.
Claude 견해: 에이전트·코딩 작업 관점(멀티 홉 추론 + 도구 호출 결과 누적 환경)
| 점유율 | 상태 | 권장 전략 |
|---|---|---|
| 0 ~ 30% | 안전 | 멀티 파일 편집·long-range 참조 모두 안정. 복잡한 plan도 무리 없음. |
| 30 ~ 50% | 양호 | 단일 작업은 OK. 멀티 스텝 추론에서 초반에 준 지시가 살짝 흐려지기 시작. |
| 50 ~ 75% | 주의 | 도구 호출 결과·파일 읽기가 누적되며 중간 구간 형성. 오래된 파일은 다시 읽어야 정확합니다. |
| 75% 이상 | 위험 | auto-compact 직전. /clear 또는 핵심 결정을 CLAUDE.md·plan에 옮기고 새 세션을 여세요. |
Claude의 경험칙: 일반 Q&A보다 에이전트 작업의 안전 구간이 더 좁습니다. 도구 호출 결과가 중간 구간에 누적되기 때문에, 동일 30%여도 “꽉 찬 30%”가 “여유 있는 30%”보다 훨씬 더 흐립니다.
Codex 견해: 대형 코드베이스·리팩터링·도구 호출 루프 관점
Codex는 컨텍스트를 “무엇이 차지하느냐”로 나누어 봅니다. 같은 점유율이어도 구성 요소에 따라 위험도가 다르고, 코드 작업은 단순 Q&A보다 멀티 홉 추론 비중이 커서 임계치가 더 낮습니다.
① 점유율별 코드 작업 안정성
| 점유율 | 상태 | 코드 작업 권장 |
|---|---|---|
| 0 ~ 25% | 최상 | 대규모 리팩터링·신규 모듈 설계 등 복합 작업 전부 허용. |
| 25 ~ 45% | 안정 | 단일 기능 구현·버그 수정 안정. 멀티 파일 리팩터링은 분할 권장. |
| 45 ~ 70% | 경고 | 초반 plan·CLAUDE.md 지시가 중간 구간으로 밀려남. 재확인 필요. |
| 70% 이상 | 압축 | auto-compact 임박. 새 세션으로 옮기는 게 거의 항상 더 빠릅니다. |
② 컨텍스트 구성 요소별 권장 상한
| 비중 상한 | 구성 요소 | 이유 |
|---|---|---|
| ~5% | 시스템·CLAUDE.md·plan | 항상 “앞쪽”에 두면 어텐션 가중치 안정. 비대해지면 본 작업에 손해. |
| ~25% | 읽은 파일·코드 스니펫 | 리팩터링 대상 코드는 정확히 봐야 함. 한도 넘으면 관련 청크만 다시 read. |
| ~15% | 도구 호출 결과(ls/grep/test 로그) | 가장 빠르게 누적되는 항목. 중간 구간을 채우는 주범. 요약하거나 폐기. |
| ~10% | 대화 히스토리 | 오래된 사용자 발화는 묻혀도 무방. 핵심 결정은 plan으로 추출 후 잊기. |
합산 ~55% 이내가 Codex가 보는 “지속 가능한 작업 영역”. 나머지는 모델 사고용 여백입니다.
③ 세션 리셋·압축 트리거 신호
| 트리거 | 신호 | 대응 |
|---|---|---|
| 약함 | 같은 파일을 3회 이상 read | 해당 파일 요약을 plan에 적어두기. |
| 중간 | 도구 호출 결과만 30% 초과 | 로그·grep 결과 핵심만 남기고 폐기. 다음 호출은 더 좁게. |
| 강함 | 같은 버그를 두 번째 재시도 | 중간 정보 유실 가능성 높음. /clear 후 결론만 옮겨 재개. |
| 치명 | 모델이 초반 지시를 무시 | 이미 U자 중앙으로 밀려난 상태. 즉시 새 세션. |
Codex의 경험칙: 점유율 숫자보다 “무엇이 컨텍스트를 채우고 있는가”가 더 중요합니다. 도구 호출 결과 30%는 코드 30%보다 훨씬 위험합니다. 똑같이 중간을 채우지만 가치 밀도가 다르기 때문입니다.
현장 경험칙(모던웹연구소 + 일부 엔지니어): 위 세 견해와 별개로, 실전에서는 20%를 절대 넘기지 않는 것을 원칙으로 둡니다. 중요한 작업일수록 컨텍스트를 의도적으로 비워두고, 20% 임계치가 보이면 plan·메모로 옮기고 /clear합니다. 이때 그냥 비우지 않고, 현재 상태를 HANDOFF.md 파일에 적어두는 게 핵심입니다. 작업 목표, 지금까지 한 일, 다음 할 일, 건드린 핵심 파일과 결정 사항을 짧게 정리해 저장하면(에이전트에게 “지금까지 진행 상황을 HANDOFF.md에 정리해줘”라고 시키면 됩니다), 다음 세션에서는 전체 대화 히스토리 없이 이 HANDOFF.md 하나만 다시 읽고도 이어서 작업할 수 있습니다. 컨텍스트를 모델의 윈도우가 아니라 파일에 보관하는 셈입니다. “여유가 곧 정확도”라는 관점입니다.
비용 관점: 과거 베타에서는 200K를 넘는 프롬프트에 입력 2배·출력 1.5배의 장문 프리미엄이 붙었지만, 2026년 3월 1M 컨텍스트가 GA로 전환되면서 이 프리미엄은 폐지됐습니다. 지금은 1M 전 구간이 표준 요금으로, 90만 토큰 요청도 9천 토큰 요청과 토큰당 단가가 같습니다. 그래도 “윈도우가 커졌으니까 다 넣자”는 여전히 손해입니다. 프리미엄 배수는 사라졌어도 토큰을 많이 넣을수록 비용은 그대로 비례해 늘고, 무엇보다 context rot로 품질이 떨어지기 때문입니다. 평소 작업은 200K 안에서, 아키텍처 리뷰·대규모 리팩터링처럼 cross-file 의존성을 한눈에 봐야 할 때만 의도적으로 1M을 켜는 패턴을 권장합니다.
Q5. 200K에 적응했는데 1M으로 바뀌면 작업 방식을 어떻게 조정해야 하나요?
Claude Code Max 사용자에게도 1M 컨텍스트가 열리면서 자주 받는 질문입니다. 결론부터 말하면 “5배 더 넣을 수 있다”가 아니라 “작업 방식 자체를 재설계해야 한다”가 맞습니다. 윈도우가 커졌다고 컨텍스트 관리가 덜 중요해진 게 아니라, 더 정교한 관리가 가능해진 것이기 때문입니다.
① Compaction 전략: 타이밍이 아니라 granularity
200K 시절에는 70% 지점에서 선제적으로 /compact하는 게 정석이었습니다. 1M에서도 75% 부근에서 능동 관리해야 한다는 관찰은 동일합니다(90%까지 밀어붙이면 출력량은 늘지만 품질이 떨어진다는 보고). 달라지는 건 “전체 요약”이 아니라 “부분 요약”으로 옮겨가야 한다는 점입니다.
실전 팁: 오래된 도구 호출 결과만 선택적으로 정리하거나, Esc+Esc(rewind)로 특정 지점까지 되감아 대화를 정리하는 partial compaction이 1M에서 실질 가치가 큽니다. 특히 rewind는 grep·ls 같은 별로 중요하지 않은 출력이나 긴 로그가 컨텍스트를 잔뜩 채웠을 때 유용합니다. 그 호출 직전 지점으로 되감으면 불필요한 토큰 덩어리를 한 번에 걷어낼 수 있기 때문입니다.
② “전체 로딩” vs “온디맨드 탐색”
- 전체 로딩이 유리(아키텍처 리뷰·대규모 리팩터링): cross-file 의존성을 한눈에 봐야 할 때. 도메인 경계 재정의, 모듈 분리 같은 작업에 1M을 의도적으로 켭니다.
- 온디맨드가 유리(단일 파일 버그·기능 추가): 기본 작업은 여전히 검색 도구로 그때그때 읽는 방식이 더 효율적·유연. Anthropic 공식 입장도 동일.
주의: 1M이 있다고 모든 코드베이스를 밀어넣는 건 비효율입니다. Dumb Zone에 묻혀 모델이 못 보고, 표준 요금이라 해도 토큰을 많이 넣을수록 비용은 그만큼 선형으로 늘기 때문입니다.
③ Subagent의 역할 전환: “절약”에서 “관심사 분리”로
200K 시절 subagent는 컨텍스트 절약의 핵심 도구였습니다. 1M에서는 역할이 병렬화와 관심사 분리로 옮겨갑니다. 메인 세션은 전체 아키텍처를 올려놓고 오케스트레이션하고, subagent A는 인증 모듈 조사, subagent B는 테스트 커버리지 분석을 맡아 각각 요약 리포트를 돌려주면 메인이 두 리포트를 종합하여 구현합니다. 여유가 있어도 subagent를 쓰는 이유는 서로 다른 관심사의 탐색 결과가 메인 컨텍스트를 오염시키는 것을 막기 위해서입니다.
④ CLAUDE.md·외부 상태 파일의 역할 재정의
- CLAUDE.md: 매 세션 로드되므로 여전히 간결하게. “어떤 파일을 언제 읽을지” 포인터 역할에 집중.
- TODO.md / SPEC.md: Plan Mode와 함께 태스크 상태를 외부 파일로 유지하면 compaction을 거쳐도 보존됨.
- HANDOFF.md: 세션을
/clear하거나 끊기 전에 작업 목표·진행 상황·다음 할 일·핵심 파일을 적어두는 인계 파일. 다음 세션에서 이 파일만 다시 읽으면 전체 히스토리 없이 이어서 작업 가능(위 현장 경험칙 참고). - 커스텀 지시: “compaction 시 수정된 파일 목록과 테스트 명령은 보존하라”를 CLAUDE.md에 적어두면 핵심 컨텍스트가 살아남음.
⑤ 비용·전환 가드레일
| 상황 | 권장 모드 | 이유 |
|---|---|---|
| 일상적인 기능 개발·버그 수정 | 표준 200K + 온디맨드 탐색 | 대부분 작업은 Smart Zone 안에서 끝남. 비용·품질 모두 유리. |
| 도메인 모델 리팩터링·모듈 경계 재설계 | opus-4-8[1m]로 전환 → SPEC.md에 결과 기록 → 새 세션에서 실행 | 플랜 단계만 1M 활용. 실행은 다시 표준 모드로 돌아옴. |
| 코드 리뷰·보안 감사·cross-cutting 분석 | 1M으로 전체 모듈 로딩 | 한 번에 봐야 패턴이 보이는 작업. 토큰을 많이 써도 그만큼 고가치라 1M 비용이 정당화됨. |
| 작업 완료 후 | /compact 또는 /clear → SPEC.md로 재개 | 1M을 “항상 켜놓지” 말 것. 다음 세션은 다시 표준으로. |
한 줄 요약: 1M은 “항상 켜놓는 상시 모드”가 아니라 “필요할 때 전략적으로 확장하는 도구”입니다. 평소엔 200K로 경제적으로, 고가치 작업에만 1M을 의도적으로 활성화하세요.
이 사실이 의미하는 것: 실무 적용
모든 LLM에서 관찰되는 U자형 정확도 곡선. 프롬프트를 설계할 때 위치 배치 자체가 정확도에 영향을 미친다는 뜻입니다.
- 긴 문서는 프롬프트 상단(시작)에 배치하고, 질문은 맨 끝에 배치 → Anthropic 공식 Long Context Tips 기준 최대 30% 성능 향상
- 중요한 컨텍스트를 중간에 끼워 넣지 마세요. “있으니까 됐다”가 아니라 “있어도 모델이 못 볼 수 있다”
- 긴 대화가 쌓이면 초기에 준 중요 지시사항이 중간 구간으로 밀려나 무시당하기 시작.
/clear로 새 세션을 열어 리셋
핵심 교훈
“컨텍스트 길이만 문제가 아니라 위치도 문제다.” 중요한 건 시작과 끝에 두세요.