컨텍스트 엔지니어링,
빈 대화가 이미 3만 토큰을 씁니다

30초 요약: 용량이 아니라 예산의 문제입니다

Anthropic은 컨텍스트를 “한정된 자원(finite resource)”이라고 부릅니다. 창이 커진 것과 모델이 그 안의 내용을 잘 쓰는 것은 다른 문제라는 뜻입니다. 아래는 그 주장을 제 환경에서 숫자로 확인해 본 과정입니다.

컨텍스트 엔지니어링은 프롬프트 엔지니어링의 다음 단계입니다

용어부터 정리하겠습니다. Anthropic 엔지니어링 블로그의 2025년 9월 29일 글 “Effective context engineering for AI agents”가 둘을 이렇게 구분합니다.

핵심은 마지막 줄입니다. 원문은 “프롬프트를 쓰는 단발성 작업과 달리, 컨텍스트 엔지니어링은 반복적이며 선별 단계가 모델에 무엇을 넘길지 정할 때마다 매번 일어난다”고 적습니다. 그래서 이 일은 프롬프트 파일을 잘 써 두는 것으로 끝나지 않고, 세션이 굴러가는 내내 관리 대상이 됩니다.

그리고 목표는 분명합니다. 같은 글은 좋은 컨텍스트 엔지니어링을 “원하는 결과가 나올 확률을 최대로 만드는, 신호가 높은 토큰의 가능한 가장 작은 집합을 찾는 것”이라고 정의합니다. 많이 넣는 게 아니라 적게 넣는 쪽이 목표라는 말입니다.

왜 적게 넣어야 하나: 컨텍스트 로트와 어텐션 예산

같은 글이 근거로 드는 개념이 컨텍스트 로트(context rot)입니다. 원문 표현으로는 “컨텍스트 창의 토큰 수가 늘어날수록 모델이 그 안의 정보를 정확히 회상하는 능력은 떨어진다”이고, “모델마다 저하 정도는 다르지만 이 특성은 모든 모델에서 나타난다”고 덧붙입니다.

이유는 구조에 있습니다. 트랜스포머는 모든 토큰이 다른 모든 토큰을 참조할 수 있게 만들어져 있어서, 토큰 n개면 n²개의 쌍 관계가 생깁니다. 컨텍스트가 길어지면 그 관계를 붙잡는 능력이 얇게 펴지고, 글의 표현대로 “컨텍스트 크기와 주의 집중 사이에 자연스러운 긴장”이 생깁니다. Anthropic은 이걸 사람의 작업기억에 빗대 “어텐션 예산(attention budget)”이라고 부르고, 토큰 하나가 들어올 때마다 그 예산이 조금씩 깎인다고 설명합니다.

여기까지가 문서의 주장입니다. 그럼 내 환경에서 그 예산이 실제로 얼마나 남아 있는지 세어 보겠습니다.

규칙 네 줄짜리 빈 프로젝트에서 /context를 돌렸습니다

측정 환경부터 밝힙니다. 임시 폴더에 index.js 한 줄과 아래 CLAUDE.md만 두고, 개인 설정이 섞이지 않도록 CLAUDE_CONFIG_DIR을 그 폴더 안의 빈 디렉터리로 지정했습니다. 그래야 제가 평소 쓰는 스킬과 서브에이전트가 빠지고 기본값만 남습니다.

CLAUDE.md는 딱 네 줄이었습니다. 제목 한 줄, 커밋 규칙 한 줄, 테스트 명령 한 줄. 결과는 이렇습니다.

표를 처음 봤을 때 숫자가 안 맞아 보였습니다. 항목을 다 더하면 32k인데 상단 표시는 16.5k였으니까요. 답은 deferred에 있습니다. 지연 등록된 도구 15.6k는 이름만 올라가 있고 스키마 본문은 필요할 때 불러옵니다. 실제로 지금 차 있는 건 3k + 11.6k + 27 + 1.8k = 약 16.4k이고, 표시값과 맞습니다. Haiku로 바꿔 계산해도 6.8k + 20.3k + 20 + 1.4k = 28.5k로 정확히 떨어졌습니다.

이 구조는 공식 문서의 설명과도 맞습니다. Claude Code 문서의 “Explore the context window” 페이지는 세션 시작 직후 무엇이 자동으로 올라가는지를 시뮬레이션으로 보여 주는데, MCP 도구를 “deferred”로 표시하고 “기본적으로 전체 스키마는 지연 상태로 두고 작업에 필요할 때 도구 검색으로 불러온다”고 적어 둡니다.

문서 쪽 예시는 200k 창 기준에 자동 메모리와 전역 CLAUDE.md까지 포함해 7.8k입니다. 제 측정이 더 큰 이유는 도구 목록이 실제 설치본 기준으로 잡히고, 기본 제공 스킬 12개의 설명문이 함께 올라가기 때문입니다. 요점은 값의 크기가 아니라 “입력하기 전에 이미 차 있다”는 구조입니다.

모델만 바꿔도 고정비가 거의 두 배 차이 납니다

여기서 예상 밖의 결과가 나왔습니다. 프로젝트도 도구도 그대로 두고 --model만 바꿔 네 번 측정했습니다.

같은 빈 프로젝트에서 Sonnet 5는 Opus 5의 약 1.9배를 쓰고 시작합니다. 시스템 프롬프트가 3k 대 9.1k로 세 배, 도구 정의가 11.6k 대 19.8k입니다. 모델마다 붙는 기본 지시문과 도구 설명의 분량이 다르다는 뜻입니다.

실무에서 더 중요한 건 마지막 줄입니다. Haiku는 절대값(28.5k)이 Sonnet보다 작은데도 창이 200k라서 시작하자마자 14%가 사라집니다. “싼 모델로 돌리면 되겠지”라고 생각하고 Haiku에 큰 파일 탐색을 맡기면, 남은 171.5k가 생각보다 빨리 바닥납니다. 1M 창 모델에서 같은 작업이 2%만 먹고 시작하는 것과는 체감이 다릅니다.

CLAUDE.md 242줄을 넣자 27토큰이 5.7k가 됐습니다

공식 문서는 CLAUDE.md를 “200줄 아래로 유지하고, 참고성 내용은 스킬이나 경로 한정 규칙으로 옮겨 필요할 때만 로드되게 하라”고 권합니다. 그 권고가 토큰으로 얼마인지 궁금해서, 같은 프로젝트의 CLAUDE.md를 규칙 240줄짜리로 바꿔 다시 측정했습니다.

5.7k라는 값 자체는 100만 창에서 0.6%라 대단해 보이지 않습니다. 문제는 성격입니다. 이건 매 요청마다 다시 실리는 고정비이고, 압축이 일어난 뒤에도 디스크에서 그대로 재주입됩니다. 대화가 길어질수록 절약되는 게 아니라 계속 따라붙습니다. 게다가 문서는 분량이 길어지면 “지시 준수율이 떨어진다”고도 적어 둡니다. 토큰보다 이쪽이 더 아픈 대가입니다.

반대로 스킬은 설계가 다릅니다. 제 측정에서 기본 제공 스킬 12개가 차지한 건 1.8k인데, 이건 각 스킬의 설명 한 줄씩입니다. 본문은 Claude가 그 스킬을 실제로 쓸 때만 올라옵니다. 그래서 “가끔 필요한 긴 절차”는 CLAUDE.md가 아니라 스킬에 두라는 권고가 나옵니다.

창을 좁히면 압축 버퍼가 3분의 1을 먹습니다

측정표에 계속 등장하는 Autocompact buffer 33k가 무엇인지 확인해 봤습니다. 공식 문서는 1M 창을 쓰는 모델이 “창이 다 차기 전, 기본값으로 약 967K 토큰에서 압축한다”고 적습니다. 100만에서 967k를 빼면 33k입니다. 제가 본 33k가 바로 그 여유분이었습니다.

그럼 창을 좁히면 어떻게 될까요. --autocompact 100000으로 100k를 지정하고 같은 측정을 했습니다.

버퍼는 33k로 그대로입니다. 창만 10분의 1로 줄었으니 비율이 3.3%에서 33%로 뛰었습니다. 여기에 고정비 16.5k를 더하면, 실제로 대화와 파일 읽기에 쓸 수 있는 공간은 50.5k. 절반입니다. “압축을 자주 시켜 요약을 깔끔하게 유지하자”는 의도로 창을 좁히면, 압축이 잦아지는 대신 한 번에 다룰 수 있는 양이 생각보다 훨씬 작아집니다. 문서가 허용하는 값은 100K에서 1M 사이이고, /autocompact auto로 모델 기본값으로 되돌릴 수 있습니다.

도구를 줄이는 쪽도 재 봤습니다. --restricted는 Bash·코드 실행·WebFetch 같은 도구를 빼는 모드인데, 결과는 16.5k에서 13.6k로 2.9k 감소였습니다. 다만 이 모드는 사용자·프로젝트·로컬 설정 파일을 무시해서 측정표에서 Memory files 줄 자체가 사라졌습니다. CLAUDE.md도 안 읽힌다는 뜻이라, 토큰 절약 목적으로 쓸 만한 옵션은 아닙니다.

압축에서 살아남는 것과 사라지는 것

컨텍스트가 차면 Claude Code는 대화를 요약해 압축합니다. 이때 무엇이 남는지는 “어떻게 올라왔는가”에 따라 갈립니다. 공식 문서가 표로 정리해 둔 부분입니다.

실무에서 걸리기 쉬운 지점만 추리면 이렇습니다.

그래서 무엇부터 하면 되나

측정한 것들을 비용 대비 효과 순으로 놓으면 이렇습니다.

반대로 권하지 않는 것도 분명해졌습니다. 창을 좁히는 것(버퍼 비율이 급등), --restricted로 도구를 빼는 것(CLAUDE.md까지 무시됨), 스킬을 통째로 끄는 것(1.8k 아끼려다 /context를 포함한 슬래시 명령 전체가 사라짐). 셋 다 아끼는 양에 비해 잃는 게 큽니다.

자주 묻는 질문

컨텍스트 창이 100만이면 그냥 다 넣으면 되지 않나요?
공식 문서 기준으로도 아닙니다. Anthropic은 토큰 수가 늘수록 회상 정확도가 떨어지는 현상을 컨텍스트 로트로 부르고 “모든 모델에서 나타난다”고 적습니다. 창 크기는 담을 수 있는 한도이고, 잘 쓰는 능력은 별개입니다.

측정한 16.5k는 제 환경에서도 같나요?
다를 겁니다. 설치한 MCP 서버, 개인 스킬과 서브에이전트, 전역 CLAUDE.md가 모두 더해집니다. 이 글의 숫자는 개인 설정을 격리한 빈 프로젝트 기준이라 사실상 하한선에 가깝습니다. 본인 값은 /context로 직접 확인하세요.

deferred 항목은 결국 비용인가요 아닌가요?
지금은 아니고 나중에 될 수 있습니다. 이름만 올라가 있다가 작업에 필요해지면 스키마가 로드됩니다. MCP 서버를 많이 붙여 뒀다면 평소엔 안 보이다가 특정 작업에서 갑자기 컨텍스트가 뛰는 이유가 여기 있습니다.

Sonnet 5가 Opus 5보다 고정비가 크면 손해인가요?
그 항목만 보면 그렇지만 14k 차이는 1M 창에서 1.4%입니다. 모델 선택은 성능·속도·요금으로 정하는 게 맞고, 고정비 차이는 200k 창처럼 여유가 빠듯할 때만 실제로 체감됩니다.

이 측정에 한계는 없나요?
있습니다. /context가 내놓는 값은 문서 표기대로 “추정치(Estimated usage)”이고, 저는 세션을 시작한 직후 상태만 쟀습니다. 파일을 읽고 대화가 쌓인 뒤의 변화, 실제 압축이 일어나는 순간의 동작까지는 이번에 확인하지 않았습니다.