정보의 위치
0%
컨텍스트 시작
예상 정확도
90%
또렷하게 찾음
LLM은 컨텍스트의 시작과 끝에 있는 정보는 잘 찾지만, 중간에 있는 정보는 정확도가 30%+ 하락합니다. 모든 주요 LLM에서 동일한 U자형 패턴이 관찰됩니다.
X축은 "전체 컨텍스트 윈도우의 몇 %"가 아니라, "내가 지금 실제로 입력한 토큰 안에서의 상대 순번"입니다. 1,000 토큰을 넣었으면 그 1,000 토큰이 0%~100%이고, 800k를 넣었으면 그 800k가 0%~100%로 펼쳐집니다.
이 U자형 곡선은 윈도우가 꽉 찼을 때(밀도가 높을 때)의 양상입니다. 1M 윈도우에 1,000 토큰만 넣었다면 사실상 모두 "앞쪽"에 몰려 있어 중간 유실은 거의 없습니다. 반대로 800k~1M를 채우면 "중간"의 범위가 길어져 정보가 급격히 흐려집니다.
출처: AI Hero
밀도(%) 대신 절대 토큰 수로 보는 관점도 있습니다. 모델이 "또렷하게" 다루는 영역을 Smart Zone, 그 뒤로 어텐션이 흐려지며 정보가 묻히는 영역을 Dumb Zone이라 부릅니다.
[1m] 접미사를 붙여 1M 컨텍스트를 켤 수 있고(예: claude-opus-4-8[1m]), 2026년 6월 출시된 Claude Fable 5(claude-fable-5)는 1M 컨텍스트가 기본값입니다. 하지만 "쓸 수 있다(혹은 기본으로 켜져 있다) ≠ 항상 가득 채워야 한다"입니다. 윈도우가 1M이 돼도 Smart Zone은 그대로 ~80k~100k에 머물러 있고, 늘어난 건 Dumb Zone입니다. 자세한 전환 전략은 Q5 참고.
입력 밀도에 따라 모델의 안정성이 달라집니다. 1M 윈도우 기준 100k는 10%로 매우 안전한 영역입니다. 같은 질문에 대해 모델마다 견해가 조금씩 다르므로, 세 견해를 나란히 두고 비교하시면 좋습니다.
| 점유율 | 상태 | 권장 전략 |
|---|---|---|
| 0 ~ 20% | 안전 | 집중력 최상. 중요한 지시·로직을 자유롭게 배치해도 됩니다. |
| 20 ~ 60% | 주의 | 중간 정보가 희석되기 시작. 핵심은 앞과 뒤에 배치하세요. |
| 60 ~ 90% | 위험 | 중간 유실이 본격적으로 시작. 불필요한 로그·과거 대화를 정리하세요. |
| 90% 이상 | 한계 | 성능 급락. /clear로 세션을 리셋하거나 RAG로 핵심 청크만 추려 넣으세요. |
| 점유율 | 상태 | 권장 전략 |
|---|---|---|
| 0 ~ 30% | 안전 | 멀티 파일 편집·long-range 참조 모두 안정. 복잡한 plan도 무리 없음. |
| 30 ~ 50% | 양호 | 단일 작업은 OK. 멀티 스텝 추론에서 초반에 준 지시가 살짝 흐려지기 시작. |
| 50 ~ 75% | 주의 | 도구 호출 결과·파일 읽기가 누적되며 중간 구간 형성. 오래된 파일은 다시 읽어야 정확합니다. |
| 75% 이상 | 위험 | auto-compact 직전. /clear 또는 핵심 결정을 CLAUDE.md·plan에 옮기고 새 세션을 여세요. |
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으로 추출 후 잊기. |
| 트리거 | 신호 | 대응 |
|---|---|---|
| 약함 | 같은 파일을 3회 이상 read | 해당 파일 요약을 plan에 적어두기. |
| 중간 | 도구 호출 결과만 30% 초과 | 로그·grep 결과 핵심만 남기고 폐기. 다음 호출은 더 좁게. |
| 강함 | 같은 버그를 두 번째 재시도 | 중간 정보 유실 가능성 높음. /clear 후 결론만 옮겨 재개. |
| 치명 | 모델이 초반 지시를 무시 | 이미 U자 중앙으로 밀려난 상태. 즉시 새 세션. |
/clear합니다. 이때 그냥 비우지 않고, 현재 상태를 HANDOFF.md 파일에 적어두는 게 핵심입니다. 작업 목표, 지금까지 한 일, 다음 할 일, 건드린 핵심 파일과 결정 사항을 짧게 정리해 저장하면(에이전트에게 "지금까지 진행 상황을 HANDOFF.md에 정리해줘"라고 시키면 됩니다), 다음 세션에서는 전체 대화 히스토리 없이 이 HANDOFF.md 하나만 다시 읽고도 이어서 작업할 수 있습니다. 컨텍스트를 모델의 윈도우가 아니라 파일에 보관하는 셈입니다. "여유가 곧 정확도"라는 관점입니다.
Claude Code Max 사용자에게도 1M 컨텍스트가 열리면서 자주 받는 질문입니다. 결론부터: "5배 더 넣을 수 있다"가 아니라 "작업 방식 자체를 재설계해야 한다"가 맞습니다. 윈도우가 커졌다고 컨텍스트 관리가 덜 중요해진 게 아니라, 더 정교한 관리가 가능해진 것이기 때문입니다.
200K 시절에는 70% 지점에서 선제적으로 /compact하는 게 정석이었습니다. 1M에서도 75% 부근에서 능동 관리해야 한다는 관찰은 동일합니다(90%까지 밀어붙이면 출력량은 늘지만 품질이 떨어진다는 보고). 달라지는 건 "전체 요약"이 아니라 "부분 요약"으로 옮겨가야 한다는 점입니다.
Esc+Esc(rewind)로 특정 지점까지 되감아 대화를 정리하는 partial compaction이 1M에서 실질 가치가 큽니다. 특히 rewind는 grep·ls 같은 별로 중요하지 않은 출력이나 긴 로그가 컨텍스트를 잔뜩 채웠을 때 유용합니다. 그 호출 직전 지점으로 되감으면 불필요한 토큰 덩어리를 한 번에 걷어낼 수 있기 때문입니다.
200K 시절 subagent는 컨텍스트 절약의 핵심 도구였습니다. 1M에서는 역할이 병렬화와 관심사 분리로 옮겨갑니다.
/clear하거나 끊기 전에 작업 목표·진행 상황·다음 할 일·핵심 파일을 적어두는 인계 파일. 다음 세션에서 이 파일만 다시 읽으면 전체 히스토리 없이 이어서 작업 가능(위 현장 경험칙 참고).| 상황 | 권장 모드 | 이유 |
|---|---|---|
| 일상적인 기능 개발·버그 수정 | 표준 200K + 온디맨드 탐색 | 대부분 작업은 Smart Zone 안에서 끝남. 비용·품질 모두 유리. |
| 도메인 모델 리팩터링·모듈 경계 재설계 | opus-4-8[1m]로 전환 → SPEC.md에 결과 기록 → 새 세션에서 실행 |
플랜 단계만 1M 활용. 실행은 다시 표준 모드로 돌아옴. |
| 코드 리뷰·보안 감사·cross-cutting 분석 | 1M으로 전체 모듈 로딩 | 한 번에 봐야 패턴이 보이는 작업. 토큰을 많이 써도 그만큼 고가치라 1M 비용이 정당화됨. |
| 작업 완료 후 | /compact 또는 /clear → SPEC.md로 재개 |
1M을 "항상 켜놓지" 말 것. 다음 세션은 다시 표준으로. |
/clear로 새 세션을 열어 리셋