"저장소(Repo)를 모델에 그냥 붙여넣으세요"라는 방식은 컨텍스트 윈도우(Context Window)라는 거대한 벽에 부딪힙니다. 너무 많이 붙여넣으면 잘림(Truncation) 오류가 발생하거나, 더 나쁜 경우에는 모델이 초기 파일들을 조용히 누락시키고 불완전한 정보만을 바탕으로 답변하게 됩니다. 해결책은 "들어갈까?"라는 질문을 붙여넣기
_전(before)_에 계산해야 할 숫자로 취급하는 것입니다.

1단계: API를 호출하지 않고 토큰(Token) 추정하기

사용 가능한 추정치를 얻기 위해 네트워크 왕복(Round-trip)이 필요하지는 않습니다. 소스 코드의 경우, 두 가지 신호를 혼합하면 실제 BPE 토크나이저(Tokenizer)의 약 5~10% 오차 범위 내로 맞출 수 있습니다:

• 글자 수 ÷ ~3.6 — 코드는 산문(Prose)보다 토큰화 밀도가 높습니다 (문장 부호와 식별자가 더 많음).
• 단어/기호 연속 횟수(Word/symbol runs) × ~1.15 — 기호가 많은 파일에서 글자 수 추정치를 보정해 주는 두 번째 신호입니다.

이 두 값을 평균 내면 빠르고 오프라인으로 토큰을 추정할 수 있습니다. "들어갈까?"라는 질문에 답하기에 충분합니다.

2단계: 대상 모델과 비교하여 확인하기

컨텍스트 윈도우(Context Window)는 모델마다 차이가 크므로,
특정 모델에 맞춰 예산을 책정해야 합니다:

모델	컨텍스트 (Context)
Claude (Fable 5 / Opus / Sonnet)	200K
...

번들(Bundle)을 대상 윈도우의 백분율로 보고하세요. "48K 토큰 = 200K의 24%"라고 하면 실제 대화를 위한 여유 공간이 있는지 한눈에 알 수 있습니다.

3단계: 예산을 초과한다면, 무작위가 아닌 중요도에 따라 축소하기

저장소(Repo)가 너무 클 때, 단순한 방식(끝부분을 자르기)은 우연히 마지막에 위치한 파일들을 버리게 됩니다. 더 나은 방법은 다음과 같습니다: 가장 큰 파일의 본문(Body)을 먼저 제외하되, 모든 파일 목록은 유지하는 것입니다. 파일 본문이 포함되지 않더라도 모델은 전체 프로젝트 맵을 볼 수 있으므로 (예: payments/refund.ts가 존재한다는 사실을 인지함) 프로젝트의 구조를 파악할 수 있습니다.

ctxpack을 사용하면 이 작업은 플래그 하나로 해결됩니다:

npx github:trongtruong110-ux/ctxpack . --fit 60000 -o context.md

ctxpack: 220 files packed
  tokens: ~59,400
  trimmed: 34 file(s) omitted to fit 60,000 tokens

모든 파일은 여전히 인덱스에 이름이 남아 있으며, 예산에 맞추기 위해 가장 큰 본문들만 제거됩니다.

습관

1. 붙여넣기 전에 추정하기 (Estimate before you paste) — "들어갈까요?"라는 질문은 사전에 답변이 가능합니다.
2. 모델별 예산 설정 (Budget per model) — Gemini에 적합한 번들이라도 Claude의 컨텍스트 윈도우(Context Window)에는 넘칠 수 있습니다.
3. 크기별로 다듬되, 지도는 유지하기 (Trim by size, keep the map) — 무엇이 누락되었는지 숨겨버리는 잘려 나간 번들보다는, 모든 파일 목록을 여전히 포함하고 있는 부분적인 번들이 더 낫습니다.

ctxpack은 MIT 라이선스이며 무료입니다: https://github.com/trongtruong110-ux/ctxpack. 여러분은 저장소(Repo)가 하나의 프롬프트에 담기에는 너무 클 때, 무엇을 포함할지 현재 어떻게 결정하시나요?