클로드 토큰과 컨텍스트 윈도우, 프롬프트 캐싱 완벽 정리

클로드 컨텍스트 윈도우가 1M으로 풀렸다는 소식을 듣고 막연히 “이제 토큰 걱정 없겠지” 생각하셨다면 이 글이 필요합니다. 실제로는 정반대로 비용 위험이 더 커집니다.

이 글은 토큰 절약 명령어 수준을 넘어서 그 아래 작동 원리까지 파고드는 글입니다. 토크나이저가 왜 한국어를 다섯 배 비싸게 매기는지, 컨텍스트가 길어질수록 왜 답변이 멍청해지는지, 프롬프트 캐싱은 정확히 어디서 어떻게 비용을 깎는지를 한 번에 정리했습니다.

토큰 기초 글과 실전 7가지 절약법을 먼저 읽고 오시면 흐름이 자연스럽습니다.

토크나이저, 한국어가 비싼 진짜 이유

먼저 토큰이 어떻게 만들어지는지부터 정리합니다. 사람이 보기엔 글자지만 AI 모델은 숫자 시퀀스를 처리합니다. 그 변환을 맡는 게 토크나이저입니다.

클로드가 쓰는 BPE(Byte Pair Encoding) 계열 토크나이저는 자주 등장하는 글자 묶음을 하나의 토큰으로 합칩니다. 영어로 학습된 코퍼스가 압도적이다 보니 ‘Hello’는 통째로 1 토큰이 됩니다. 반면 한국어 코퍼스 비중이 작아서 ‘안녕하세요’는 자모 단위로 쪼개져 약 5 토큰이 잡힙니다.

이게 왜 중요하냐면 같은 의미를 전달하는 데 한국어가 입력 비용 4~5배, 출력 비용도 비례해서 늘어난다는 뜻이기 때문입니다. 실용적인 함의가 두 가지 있습니다.

시스템 프롬프트와 메모리 파일은 영어로 쓰는 편이 토큰 효율이 좋습니다. 협업 규칙처럼 사용자가 내용을 직접 읽지 않는 영역이라면 영어로 적는 게 비용 면에서 유리합니다.
답변을 한국어로 받으면 같은 정보량이라도 출력 토큰이 훨씬 더 들어갑니다. “출력은 영어로, 마지막 요약만 한국어로” 같은 분리 전략이 의외로 효과적입니다.

컨텍스트 윈도우 1M, 그릇이 커진다고 비용이 줄지 않습니다

클로드 모델 기본 컨텍스트 윈도우는 20만 토큰입니다. 베타로 1M(100만) 토큰까지 풀렸습니다. 책 한 권이 200K 정도라면 1M은 책 다섯 권을 한꺼번에 보여줄 수 있는 그릇입니다.

문제는 그릇 크기와 비용은 별개라는 점입니다. 컨텍스트는 매 메시지마다 입력 토큰으로 다시 계산됩니다. 100만 토큰 중 80만 토큰을 쓰고 있다면 매 답변마다 80만 토큰을 입력으로 청구한다는 뜻입니다.

여기에 어텐션 희석 문제가 겹칩니다. 컨텍스트가 길어질수록 모델이 핵심 정보에 집중하기 어려워집니다. 짐코딩이 정리한 컨텍스트 로트(Context Rot)의 네 가지 원인이 정확합니다.

어텐션 희석: 정보가 너무 많아 핵심에 가중치가 덜 실립니다.
명령 충돌: 앞뒤로 다른 지시가 쌓이면 모델이 어느 쪽을 따를지 흔들립니다.
토큰 예산 압박: 출력 가능 영역이 줄어 답변이 잘립니다.
관련성 미스 매치: 무관한 정보까지 다 읽어 노이즈가 됩니다.

결론적으로 1M 컨텍스트는 “특정 작업에 한해 신중하게 쓰는 도구”입니다. 큰 코드베이스를 한 번에 분석할 때나 의미가 있고, 일반 코딩 세션에서는 200K도 절반만 차도 품질이 떨어지기 시작합니다.

실무 기준은 두 가지로 압축됩니다. 컨텍스트 사용량이 75%를 넘으면 정리하시고 한 파일이 2,000~3,000 토큰을 넘으면 분리를 고민하시면 됩니다.

프롬프트 캐싱, 비용을 10분의 1로 깎는 메커니즘

토큰 절약 명령어 위에 한 단계 더 강력한 장치가 있습니다. 프롬프트 캐싱입니다. 클로드 코드가 반복되는 시스템 프롬프트와 메모리 파일을 캐시에 저장해두고 다음 호출 때 비용을 10분의 1로 깎아주는 기능입니다.

핵심은 작동 조건입니다. 캐시는 무조건 켜진다고 들어맞는 게 아니라 다음을 만족해야 효과가 납니다.

앞쪽 토큰이 동일해야 합니다. 시스템 프롬프트와 메모리 파일이 한 글자라도 바뀌면 캐시가 깨집니다.
세션이 너무 자주 끊기면 안 됩니다. 캐시 TTL이 만료되면 다시 풀 가격으로 시작합니다.
세션 내 일관성이 유지돼야 합니다. 도중에 메모리 파일을 수정하면 그 시점부터 캐시가 깨집니다.

이걸 운영 관점으로 옮기면 두 가지 원칙이 나옵니다. 자주 바뀌는 정보는 claude.md에 두지 마시고 별도 파일로 빼두시는 게 안전합니다. 그리고 한 작업 안에서는 가능한 한 메모리 파일을 건드리지 않고 끝까지 가는 게 캐시 효율이 좋습니다.

캐시가 잘 작동하는지 확인하려면 공식 마켓플레이스의 Session Report 플러그인을 쓰시면 됩니다. 대시보드에서 캐시 히트율이 직접 표시됩니다. 히트율이 낮게 찍히면 세션 운영 패턴부터 점검해야 한다는 뜻입니다.

모델별 비용 구조 정밀 비교

100만 토큰 기준 가격을 다시 한 번 정리합니다.

모델	입력	출력	캐시 적용 시 입력	권장 용도
Haiku	$1	$5	약 $0.1	단순 분류, 학습 실습, 보조 에이전트
Sonnet 4.5	$3	$15	약 $0.3	일반 코딩 80% 커버
Opus 4.5	소넷의 4~5배	소넷의 4~5배	캐시 효과 동일 비율	설계와 깊은 추론

표에서 가장 중요한 칼럼은 캐시 적용 시 입력입니다. 캐싱이 잘 깔린 환경에서는 입력 비용이 사실상 10분의 1이 됩니다. 출력은 그대로지만 입력이 출력보다 보통 5배 이상 많기 때문에 전체 비용이 절반 가까이 빠집니다.

여기서 흥미로운 의사결정 포인트가 나옵니다. 오퍼스가 비싸지만 캐시가 잘 깔리면 의외로 합리적인 선택이 됩니다. 복잡한 작업을 한 번에 끝내서 토큰 누적을 줄이면 결과적으로 소넷보다 적게 쓸 수도 있다는 뜻입니다.

반대로 캐시 효과가 잘 안 나는 환경(자주 끊기는 세션, 자주 바뀌는 메모리)에서는 오퍼스를 쓰면 비용이 그대로 4~5배가 됩니다.

Sonnet과 Opus 의사결정 트리

작업이 들어왔을 때 어떤 모델을 골라야 할지 판단하는 흐름을 정리합니다.

먼저 작업 성격을 분류합니다.

분석과 설계가 80% 이상인 작업 → Opus 또는 opus-plan 모드. 잘못 짠 설계를 나중에 뒤엎으면 토큰이 가장 크게 빠집니다.
요구사항이 명확하고 구현 위주인 작업 → Sonnet. 80% 코딩 작업은 여기서 끝납니다.
반복적이고 단순한 변환 → Haiku. 변수명 일괄 변경, 로그 파일 정리, 간단한 텍스트 처리는 굳이 비싼 모델을 쓸 이유가 없습니다.

여기서 한 단계 더 들어가면 두 변수를 추가로 봐야 합니다.

컨텍스트가 무거우면 Opus 가산점입니다. 큰 코드베이스를 한 번에 이해해야 하는 작업이라면 컨텍스트 추적 능력이 좋은 모델이 결과적으로 토큰을 적게 씁니다. 소넷이 같은 작업을 두세 번 시도하다가 결국 더 비싸지는 경우가 종종 있습니다.

캐시가 안정적이면 Opus 가산점입니다. 한 세션에서 길게 작업할 거라 캐시 히트율이 높을 것 같다면 오퍼스 단가 부담이 실제로는 크게 줄어듭니다.

이 두 변수가 모두 낮은 환경(짧은 세션, 단순 작업)이라면 무조건 소넷이나 하이쿠가 정답입니다.

실제 사용 시나리오로 옮기면 결정이 더 쉬워집니다. 스타트업 1인 개발자라면 보통 짧은 세션을 자주 끊어 쓰기 때문에 캐시 효과가 약합니다. 소넷 고정에 오퍼스는 설계 단계에서만 잠깐 쓰는 패턴이 합리적입니다. 사내 코딩 컨벤션이 빡빡한 팀이라면 메모리 파일이 안정적이라 캐시가 잘 깔립니다. opus-plan 모드를 기본값으로 두고 구현은 소넷으로 자동 전환되게 잡으시면 됩니다. 대형 코드베이스를 다루는 시니어 개발자라면 1M 컨텍스트와 오퍼스 조합이 결과적으로 가장 싸지는 케이스도 있습니다. 같은 작업을 소넷이 두세 번 시도하다 실패하는 비용보다 한 번에 끝내는 게 토큰 측면에서도 유리합니다.

컨텍스트 엔지니어링이라는 새 직무

지금까지의 이야기를 한 단어로 묶으면 컨텍스트 엔지니어링입니다. AI 모델 자체를 튜닝하는 게 아니라 모델에게 무엇을 어떻게 보여줄지 설계하는 일을 가리킵니다.

미첼 해시모터가 제안한 하네스 엔지니어링도 같은 맥락에 있습니다. AI가 실수를 했을 때 AI를 탓하는 대신 환경을 고치자는 접근입니다. 같은 실수가 세 번 이상 나오면 훅(Hook)을 추가해서 발동 조건을 정의해두는 식입니다.

실무에서 이 접근이 작동하는 모습은 이렇습니다.

메모리 파일을 의식적으로 다이어트합니다. 안 쓰는 규칙은 정기적으로 제거하고 자주 바뀌는 정보는 별도 파일로 분리합니다. 캐시 히트율을 높이는 가장 직접적인 행동입니다.
자주 하는 작업을 패턴으로 굳혀둡니다. 폴더 구조 잡는 법, 에러 처리 라이브러리 같은 반복 패턴을 인스팅트(Instinct)로 학습시키고 누적되면 스킬(Skill)로 승격시킵니다. 회사 코딩 컨벤션을 클로드에게 영구 기억시키는 셈입니다.
품질 게이트를 자동화합니다. task_completed 훅으로 결과물 품질을 자동 검증하고 미달이면 다시 시키는 구조를 만들어둡니다. 매번 사용자가 채점하느라 토큰을 태우는 비용이 사라집니다.

세레나(Serena) MCP 같은 의미 기반 코드 탐색 도구도 이 흐름의 일부입니다. 단순 글자 검색이 1만 토큰을 쓰는 작업을 의미 단위로 좁혀서 수십 분의 1로 줄여줍니다. 리팩토링 작업이 잦은 팀이나 30개 이상 파일의 변수명을 일괄 변경해야 하는 시니어 개발자라면 가장 체감이 큽니다. uv라는 파이썬 패키지 매니저가 필요하긴 하지만 큰 프로젝트를 다루는 분이라면 설치 시간이 아깝지 않습니다.

마무리: 토큰을 보는 시야가 한 단계 올라가면

처음에는 /clear 한 번 치는 게 토큰 절약의 전부처럼 느껴집니다. 그 단계를 넘어서면 토크나이저, 컨텍스트 윈도우, 프롬프트 캐싱이 함께 돌아가는 구조가 보이기 시작합니다.

이 시야가 생기면 의사결정이 달라집니다. “오퍼스를 쓸까 소넷을 쓸까”가 아니라 “이 세션의 캐시 히트율이 어느 정도일 때 어느 모델이 합리적인가”를 따지게 됩니다. “메모리 파일이 너무 길어서 줄이고 싶다”가 아니라 “캐시가 깨지지 않게 자주 바뀌는 부분을 어디로 빼야 할까”를 고민하게 됩니다.

클로드 코드를 본격적으로 쓰는 분이라면 이 시점부터 비용 관리가 진짜 시작됩니다. 명령어 몇 개 외우는 단계를 졸업하고 환경을 설계하는 단계로 올라서는 셈입니다. 결국 클로드 컨텍스트 윈도우를 잘 다룬다는 건 그릇 크기를 자랑하는 일이 아니라 그릇 안에 무엇을 어떤 순서로 담을지 매번 결정하는 일에 가깝습니다.

세 편을 읽어주신 분께 마지막으로 한 가지만 권합니다. Session Report 플러그인을 일주일 정도 깔아두고 본인의 캐시 히트율과 모델별 사용 비중을 직접 보시는 게 좋습니다. 어디서 토큰이 새는지 본인 환경에서 확인되면 이 글의 추상적인 원리들이 구체적인 행동으로 바뀝니다.