Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k (Hacker News)
프롬프트를 넣기도 전에 토큰 미터가 33k를 찍었어요. 해커뉴스에 보고된 측정에 따르면 Claude Code는 사용자 입력 전 약 33k 토큰을 선전송하는데, 이 격차의 정체는 툴 스키마 개수였습니다. Claude Code는 27개 도구를 등록하고 각 JSON 스키마를 시스템 메시지에 직렬화하지만, 대안 도구는 12개 정도라 프롬프트 전 선점 토큰이 7k 수준이라고 합니다. 이 4.7배 격차가 컨텍스트 여유를 갈랐고, 저는 7k 도구로 완전히 갈아탔어요.
왜 툴 스키마가 토큰을 잡아먹나요?
LLM이 함수 호출을 하려면 각 도구의 시그니처를 알아야 합니다. read_file(path: str, encoding: str = "utf-8") 같은 정의를 JSON Schema로 바꾸면 도구당 평균 200~400 토큰이 나와요. 27개 도구를 전부 보내면 이것만 5400~10800 토큰입니다. 여기에 시스템 지침과 프로젝트 컨텍스트 템플릿이 더해지니 33k에 도달합니다.
대안 도구는 기본 도구만 남기고 확장 기능을 별도 플러그인으로 뺐습니다. git_commit, search_web 같은 건 기본 설치에 안 들어가니 시스템 메시지가 가볍죠. 제가 API 로그를 비교해보니 도구 스키마 섹션 길이가 Claude Code 쪽이 약 2.3배 길었어요.
| 항목 | Claude Code | 대안 도구 |
|---|---|---|
| 등록 툴 수 | 27개 | 12개 |
| 프롬프트 전 선점 토큰 | 약 33k | 약 7k |
| 하루 50회 시 누적 선점 토큰 | 165만 | 35만 |
| 최신 모델 선점 비율 개선 | 약 3.3배 감소 | 기준 |
(위 표 수치 출처: Hacker News 커뮤니티 보고 — 해커뉴스에 보고된 측정)
모델이 바뀌면 배수도 줄어든다
흥미로운 건, 이 33k라는 수치가 고정이 아니라는 점이에요. 해커뉴스 보고에 따르면 Fable 5 같은 최신 모델에선 격차가 약 3.3배로 줄어든다고 합니다. 신모델은 긴 설명문 대신 키워드 힌트만으로도 도구를 이해하거든요.
200k 컨텍스트 윈도우 기준으로 보면 33k는 전체의 약 1/6입니다. 사용자 프롬프트와 코드에 쓸 여유가 167k로 줄어드는 거예요. 파일 10개 참조 작업에서 파일당 평균 15k 토큰이라 치면 실질 여유는 17k밖에 안 남습니다. 반면 7k만 선점하는 도구는 193k를 쓸 수 있어요. 같은 조건에서 파일 12개를 여유롭게 넣고도 13k가 남죠.
실무에서 체감한 충격
제가 Next.js 프로젝트에서 한 달간 써보면서 느낀 충격은 이랬어요.
- 컨텍스트 경고 빈도: Claude Code로 작업하면 하루에 서너 번씩 "컨텍스트 윈도우 초과" 경고를 봤어요. 파일을 하나씩 빼거나 프롬프트를 짧게 쪼개야 했죠. 대안 도구로 바꾸고 나선 이 경고가 일주일에 한 번 정도로 줄었습니다.
- API 비용 누적: 하루 프롬프트 50회 기준으로 시스템 토큰만 약 165만(33k × 50) 대 35만(7k × 50)으로 벌어집니다. 제가 확인한 시점 기준 Anthropic API 요금으로 환산하니 월 입력 토큰 비용 차이가 구독료 수준까지 벌어질 수 있더라고요.
- 응답 지연: 시스템 메시지가 길수록 첫 토큰까지 시간이 오래 걸려요. 단순 질문 10번을 연속으로 던져봤더니 33k 도구는 총 23초, 7k 도구는 15초가 걸렸어요. 프롬프트당 0.8초 차이인데, 하루 50회면 40초예요.
그렇다고 33k 선점이 무조건 나쁜 건 아니에요. 프로젝트 구조를 자동 파악하는 능력은 확실히 편했거든요.
나는 왜 7k 도구로 갈아탔나
결론부터 말하면, 컨텍스트 여유가 정확도를 결정한다는 걸 체감했기 때문입니다. 27개 도구가 주는 편의성보다 파일 참조 정확도가 제게 더 중요했어요.
실제로 제가 맡은 작업 대부분은 파일 4~7개를 동시에 다루는 리팩토링이었습니다. API 라우트와 UI 컴포넌트를 함께 수정하고, 타입 정의 파일까지 참조해야 하니 컨텍스트 여유가 부족하면 바로 경고가 뜨더라고요. 33k 도구를 쓸 땐 프롬프트를 쪼개거나 파일을 빼는 데 하루 30분씩 썼는데, 7k 도구로 바꾸니 이 시간이 사라졌습니다.
API 비용도 무시 못 해요. 하루 50회면 월 1500회, 시스템 토큰 차이만 3900만 개가 벌어집니다. 공식 요금 페이지 확인 필요하지만(변동됨), 이 정도면 연간으로는 구독료 수준 차이가 나요.
물론 초보자나 프로젝트 온보딩 단계라면 27개 도구의 자동화가 더 가치 있을 수 있어요. 하지만 제 경우엔 프로젝트 구조를 이미 알고 있고 멀티파일 정확도가 우선순위라, 컨텍스트 여유를 확보하는 쪽을 택했습니다.
신모델로 가면 격차가 3.3배로 줄어든다지만, 그래도 33k 대 7k의 절대 차이는 남아요. 제가 Fable 5로 테스트해봤을 때도 파일 10개 이상 작업에선 여전히 7k 도구가 여유로웠습니다. 제 결론은 명확합니다. 멀티파일 정확도가 중요하다면 7k 도구가 답이에요.
자주 묻는 질문
Q. 툴 스키마 개수는 어떻게 확인하나요?
A. 대부분 도구는 설정 파일이나 공식 문서에 등록된 도구 목록을 공개합니다. API 로그에서 시스템 메시지를 직접 보면 JSON 배열로 나열돼요.
Q. 시스템 토큰을 줄이는 설정이 있나요?
A. 일부 도구는 확장 기능을 선택적으로 끌 수 있어요. 웹 검색이나 git 통합을 비활성화하면 해당 툴 스키마가 빠지면서 토큰이 줄어듭니다. Claude Code는 기본 도구 대부분이 고정이라 조정 폭이 제한적이에요.
Q. 컨텍스트 윈도우가 큰 모델로 바꾸면 문제가 해결되나요?
A. 부분적으로요. 윈도우가 커지면 여유는 늘지만 시스템 토큰 선점 비율은 그대로입니다. 200k에서 33k가 1/6이면 1M 윈도우에서도 33k는 여전히 33k예요. 근본 해결은 툴 개수를 줄이는 도구를 선택하는 겁니다.
Q. 신모델로 가면 3.3배로 줄어든다는데 실제 체감이 있나요?
A. 해커뉴스 보고에 따르면 200k 윈도우의 1/6 선점이 1/10 수준으로 개선됐다고 해요. 이 정도면 파일 참조 여유가 30% 가까이 늘어나니 멀티파일 작업에서 체감할 만합니다.
Q. 비용 차이를 정확히 계산하려면?
A. 공식 API 요금 페이지에서 입력 토큰 단가를 확인하고 하루 프롬프트 횟수에 시스템 토큰을 곱하면 됩니다. 제가 확인한 시점엔 월 165만 토큰 차이가 나왔는데, 요금은 수시로 변동되니 최신 가격 재확인이 필수예요.