Don't trust large context windows

Garrit의 블로그에서 읽은 글. LLM 코딩 에이전트 사용 시 컨텍스트 윈도우의 '스마트 존'과 '덤브 존'을 구분해야 한다는 주장. HN에서 240점, 178개 댓글로 활발한 토론.

1. 원문 핵심 내용

컨텍스트 윈도우의 '스마트 존'과 '덤브 존'

저자는 LLM의 컨텍스트 윈도우를 두 영역으로 나눈다. 스마트 존은 모델이 날카롭게 작동하는 영역이고, 덤브 존은 어텐션(집중력)이 떨어져 모델이 이전에 알려준 정보를 잊기 시작하는 영역이다. 경계선은 대략 10만 토큰 부근이라고 한다.

컨텍스트 윈도우란 LLM이 한 번에 고려할 수 있는 텍스트의 최대 길이다. OpenAI GPT-4는 12만8천 토큰, Claude는 20만 토큰, 일부 모델은 100만 토큰까지 광고한다. 하지만 저자는 이 숫자가 마케팅용이라고 지적한다. 실제 유용하게 쓰이는 범위는 광고된 것의 일부에 불과하다는 뜻이다.

왜 중요한가: 코딩 에이전트는 컨텍스트를 빠르게 소모한다

현대 코딩 에이전트는 토큰을 빠르게 소모한다. 파일 몇 개를 읽고, 디버깅 세션을 돌리고, 테스트 결과를 확인하는 것만으로도 점심시간 전에 10만 토큰을 넘긴다. 벤더들은 20만, 100만, 200만 토큰 컨텍스트를 자랑하지만, 연구(RULER, Chroma의 컨텍스트 로트 보고서)에 따르면 실제 유효 컨텍스트는 광고된 숫자의 일부일 뿐이고, 윈도우가 채워질수록 성능이 서서히 저하된다.

어텐션 메커니즘의 한계

대규모 컨텍스트 윈도우를 가능하게 하는 아키텍처는 작동하지만, 근본적인 어텐션 메커니즘의 문제를 완전히 해결하지는 못한다. 컨텍스트가 길어질수록 모델은 모든 토큰에 고르게 주의를 기울이기 어렵고, 중요한 정보가 묻혀버린다.

자동 컴팩션(auto-compaction)의 한계

Claude Code 같은 도구는 세션이 길어지면 히스토리를 요약하고 새 세션을 시작하는 자동 컴팩션을 제공한다. 하지만 자동 컴팩션은 이미 덤브 존에 진입한 후에 작동하며, 요약 자체도 이미 성능이 저하된 모델이 만든 것이다. 저자는 '그나마 낫다'지만 근본 해결책은 아니라고 평가한다.

저자의 해결책: 수동 스펙과 아티팩트

저자의 방법은 새 세션을 열고 자신이 직접 쓴 스펙(명세서)을 전달하는 것이다. 자동 요약보다 훨씬 높은 신호 대 잡음비를 가진 인계(handoff)가 가능하다고 주장한다. 왜냐하면 무엇이 중요한지는 사용자가 결정할 수 있기 때문이다.

이것은 저자가 이전에 소개한 'breadcrumbs(나뭇가지)' 접근법을 에이전트에 적용한 것이다. 다음 세션이나 다른 사람이 깔끔하게 이어받을 수 있는 산출물(artifact)을 남긴다는 개념이다.

더 나아가: 구조화된 워크플로우

obra/superpowers, mattpocock/skills 같은 프로젝트는 PRD(제품 요구사항 문서), 계획, 스킬, 서브 에이전트 인계 등 작고 이름 붙은 아티팩트 전체를 구조화한다. 각각은 라이브 세션에서 정보를 빼내어 다음 세션이 읽을 수 있는 형태로 만드는 방식이다.

핵심 메시지: 컨텍스트를 예산처럼 다루라

저자는 컨텍스트 윈도우를 예산처럼 취급한다. 초기 부분만 실제로 자신에게 일해준다고 가정하고, 라이브 세션 밖으로 꺼내어 문서화할 수 있는 것은 모두 문서로 만든다. 그러면 어텐션이 경쟁해야 할 대상이 줄어든다.

2. 커뮤니티 반응

HN에서 240점, 178개 댓글. 반응은 크게 경험 차이 논란, 기술적 해석, 워크플로우 대안, 글 자체에 대한 비판으로 나뉜다.

2.1 경험 차이: "나는 그런 경험 없다" (가장 큰 논쟁)

댓글 중 상당수가 저자의 주장에 동의하지 않았다. 본인들의 경험에서는 100만 토큰 컨텍스트를 사용해도 '덤브 존' 현상을 겪지 않았다는 것이다.

• daishi55: Opus 1M 컨텍스트를 매일 업무에서 사용하지만 컨텍스트 윈도우를 생각할 정도가 아니며, 자동 컴팩션을 맡겨도 문제없다고 함
• monster_truck: 본인의 경험과 맞지 않으며, 이 현상을 테스트하는 방법론도 유용하지 않다고 주장
• danielbln: 60k 토큰은 컨텍스트를 barely seed(시드)한 단계일 뿐이고, 600-700k 토큰에서야 컨텍스트 관련 성능 저하가 보인다고 함
• arcanemachiner: Opus 4.6은 200k 이후에 '약물 영향'처럼 작동했고, 4.8은 350k까지 잘 작동했으며, Fable은 400k 이상에서도 훌륭했다고 버전별 경험을 공유
• asd88: Fable에서 컨텍스트 70% 이상 사용해도 날카롭고 메모리 문제 없음

반대편에서도 실제 경험을 제시했다:

• Bolwin: Opus 모델이 <100k 토큰에서 이미 기본 기억 실수를 한다고 하며, <60k를 스마트 존으로 간주한다고 함. Opus 4.7/4.8은 더 세분화된 토크나이저 때문에 더 나쁘다고 지적
• csomar: Rust 프로젝트에서 GLM은 120k, Opus는 200-300k 이후에 기본 빌드 명령으로 회귀한다고 보고

핵심 쟁점: '컨텍스트 로트'가 실제로 존재하는 현상인지, 아니면 사용 패턴이나 모델 버전에 따라 크게 달라지는 것인지에 대한 경험 기반 논쟁이다.

2.2 '컨텍스트 로트'의 측정 문제

• cubefox: '컨텍스트 로트'의 존재와 심각도가 순전히 일화적(anecdotal)이며, 체계적으로 측정한 사람이 없다고 주장. 'needle in a haystack'(바늘 찾기) 테스트는 특정 정보를 기억하는 능력을 측정할 뿐, 모델이 전반적으로 '더 바보가 된다'는 주장은 별개라고 지적. 실제로 측정하면 간단할 텐데 왜 안 하는지 의문
• fullstackchris: 글에서 어떤 모델을 구체적으로 언급하지 않았으며, '점심시간까지 100k'라는 주장도 본인의 경험과 맞지 않는다고 비판

2.3 기술적 해석: 진짜 원인은 무엇인가

• carterschonwald: 컨텍스트 윈도우 크기 자체가 문제가 아니라, 어텐션 질량(attention mass)이 너무 넓게 퍼져 모든 것이 일종의 '전역 평균' 영역으로 수렴하면서 slop(저질 출력)이 나온다고 설명. 모델 레이어나 harness 레이어에서 이를 완화하는 흥미로운 방법들이 있지만, AI 연구소들이 우선순위를 두지 않는다고 지적
• Der_Einzige: 롱 컨텍스트 생성은 샘플링 문제라고 주장. min_p나 더 새로운 샘플러를 사용하면 롱 컨텍스트에서 모델이 더 잘 작동한다고 함

2.4 워크플로우 대안

• schipperai: 매우 흥미로운 경험 공유. 200k 컨텍스트 시대에는 작업을 좁게 스코프해야 했기에 복잡도를 줄이려 노력했고 자연스럽게 원자적 작업이 나왔다. 1M 컨텍스트와 '최신 모델은 롱런 작업에 더 좋다'는 약속이 작업을 넓게 잡게 만들었고 품질이 나빠졌다. 다시 세션 당 하나의 좁은 작업, 400k 이하로 제한하는 방식으로 돌아갔다고 함. 세션이 길어지면 본인이 너무 야심찬 작업을 잡았다는 신호라고 해석
• OutOfHere: 코드보다 정교한 스펙을 우선시하며, 여러 채팅에 걸쳐 스펙을 다듬은 후 실행 단계에 들어가면 각 단계는 100k 토큰 내에 쉽게 처리된다고 함
• tmp10423288442: Codex의 자동 컴팩션이 잘 작동한다고 평가. 세션이 빗나가기 시작하면 새 세션에서 이전 세션을 AGENTS.md로 요약하게 하고 거기서 시작한다고 함
• kristianc: 자체 프레임워크를 소개 — 문제 진술, 영향받는 사용자, 사용자 스토리, 비즈니스 케이스, 범위 정의, '가장 얇은 슬라이스'(최소 기능), 기술 노트, 의존성, 스키마 변경, 리스크, 최종 추천(진행/불진행) 등. Claude.md에 '이 프레임워크 없이 새 기능 도입 금지'라고 명시

2.5 비유와 평가

• jsemrau: "큰 차고가 있다고 해서 차를 쉽게 주차할 수 있는 것은 아니다" — 컨텍스트 윈도우 크기와 실제 유용성은 다르다는 점을 잘 표현
• cyanydeez: "โป๊กเกอร์ 테이블에 앉았는데 누가 마크(속임의 대상)인지 모르겠다면, 네가 마크인 것이다" — 큰 컨텍스트를 자랑하는 벤더들이 실제로는 고객을 속이고 있다는 해석
• hypfer: 많은 추론을 소비하는 것은 낭비적이라고 지적

3. 새로운 시각

3.1 '컨텍스트 예산' 개념은 소프트웨어 아키텍처의 '메모리 예산'과 유사하다

저자가 제안하는 '컨텍스트를 예산처럼 다루자'는 접근은 전통적인 소프트웨어 엔지니어링에서 메모리나 CPU를 예산으로 관리하는 철학과 본질적으로 동일하다. RAM이 64GB라 해서 모든 데이터를 메모리에 올리는 개발자는 없다. 마찬가지로 컨텍스트 윈도우가 100만 토큰이라 해서 모든 것을 세션에 넣는 것은 잘못된 설계다. 이것은 LLM 시대의 새로운 인사이트라기보다, 기존 공학적 사고를 새로운 도메인에 적용한 것이다.

3.2 '스마트 존'의 실제 경계는 모델·태스크·사용자 패턴의 3원소 함수다

HN 댓글에서 가장 큰 논쟁은 '100k가 맞느냐, 60k가 맞느냐, 600k까지 괜찮다'였다. 이것은 스마트 존의 경계가 고정된 숫자가 아니라 모델 버전(4.6→4.8→Fable로 개선 중), 태스크 유형(코드 생성 vs 문서 요약 vs 논리적 추론), 그리고 사용자 패턴(정교한 프롬프트 vs 즉흥적 대화)에 따라 달라진다는 것을 시사한다. 따라서 '100k'라는 단일 숫자를 믿기보다, 자신의 워크플로우에서 실험적으로 경계를 찾는 것이 더 실용적이다.

3.3 자동 컴팩션의 근본 문제는 '재귀적 품질 저하'다

저자가 지적한 자동 컴팩션의 문제는 재귀적이다. 성능이 저하된 모델이 요약을 만들고, 그 요약으로 새 세션이 시작되며, 새 세션도 결국 저하된다. 이는 '노이즈가 누적되는 피드백 루프'와 유사하다. schipperai의 경험처럼 자동 컴팩션에 의존하면 작업 스코프가 넓어지고 품질이 저하되는 현상은 이 재귀적 저하의 실제 증거일 수 있다. 수동 스펙이 더 나은 이유는 인간이 노이즈를 필터링하기 때문이다.

4. 자녀/미래 영향

아인, 석현, 은한에게

이 글은 아이들이 AI 도구를 사용할 시대에 필요한 '디지털 리터러시'의 한 형태다.

구체적 조언:

1. 도구의 마케팅 숫자를 맹신하지 말라 — 컨텍스트 윈도우 크기가 100만 토큰이라고 해서 100만 토큰만큼 유용하게 쓰는 것은 아니다. 스마트폰 RAM 16GB가 4GB보다 항상 낫다는 뜻은 아니다. 도구의 실제 성능은 사용 방법에 달려있다.

1. 작은 단위로 나누어 생각하라 — schipperai의 교훈처럼, 큰 컨텍스트가 가능하다고 해서 큰 작업을 한 번에 처리하려는 유혹에 빠지지 말라. 작업을 작은 단위로 나누고, 각 단위를 명확한 스펙으로 정의한 후 실행하는 습관이 AI 시대의 핵심 생산력이다.

1. 문서화하는 습관을 기르라 — 저자의 'breadcrumbs' 접근법은 단순히 AI 에이전트에게 유용한 것이 아니라, 자신의 생각과 작업을 기록하는 일반적인 습관으로도 적용된다. 좋은 노트는 다음 세션의 자신뿐만 아니라 다른 사람도 이어받을 수 있다.

1. 도구는 예산처럼 관리하라 — 컨텍스트 윈도우뿐만 아니라, 시간, 주의력, 에너지도 모두 예산이다. 무한한 것처럼 보이는 자원을 무한히 사용하는 것은 항상 낭비로 끝난다.

SAVED_NOTE: /home/ybman/Documents/vault/wikis/notes/raw/notes/2026-06-15_dont-trust-large-context-windows.md SLUG: 2026-06-15_dont-trust-large-context-windows TG_SUMMARY: LLM 컨텍스트 윈도우는 광고된 크기보다 훨씬 작은 범위만 실제로 유용하게 작동한다. 저자는 10만 토큰 부근을 '스마트 존'과 '덤브 존'의 경계로 보고, 세션을 짧게 유지하고 수동 스펙으로 인계하는 워크플로우를 제안한다. HN 커뮤니티는 경험 차이로 크게 갈렸으며, 일부는 100만 토큰에서도 문제없다고 반박했다.