Claude 4.7 토크나이저 분석 결과가 공개됐다. 결론부터 말하면 불편하다. 동일한 작업을 Claude 4.7로 돌리면 세션당 비용이 20~30% 더 나간다. 토큰 단가는 그대로인데, 토크나이저가 영어·코드 콘텐츠를 평균 1.3~1.45배 더 잘게 쪼개기 때문이다. 80턴 기준 Claude Code 세션 한 번에 4.6은 약 $6.65, 4.7은 $7.86~$8.76이 청구된다. Anthropic 공식 발표 수치(1.0~1.35배)보다 실측값(1.45~1.47배)이 더 높게 나왔다는 점도 눈여겨봐야 한다.
이걸 두고 "모델이 더 좋아졌으니 비용 증가는 감수해야 한다"고 넘기는 팀이 있고, 비용 구조 자체를 다시 설계하는 팀이 있다. 나는 후자가 옳다고 본다. 명령어 준수도 +5%p 향상이 실제로 팀의 재작업을 얼마나 줄이는지 측정하기 전까지는, 비용 상승을 성능 개선으로 상쇄됐다고 단정할 수 없다. Hacker News 커뮤니티 반응도 비슷하게 갈렸다. 누군가는 "Claude로 9명 6개월 프로젝트를 2명 2개월에 끝냈다"고 했고, 또 누군가는 "하루 $200 청구서를 보고 라우팅 최적화가 더 시급하다는 걸 깨달았다"고 했다. 둘 다 틀린 말이 아니다. 생산성 레버리지가 충분히 크면 비용은 부수적 문제가 되고, 그렇지 않으면 비용이 제품 마진을 갉아먹는 주범이 된다.
그렇다면 실제로 비용을 통제하는 팀은 어떻게 다를까. dev.to에 올라온 한 사례가 참고가 된다. Claude 3.5 Sonnet API로 월 $847이 나오던 고객 지원 에이전트를 오픈소스 스택으로 재구축해 $5.23/월로 낮췄다는 사례다. 핵심은 싼 모델을 찾은 게 아니라 작업별로 모델을 분리한 것이다. 복잡한 추론은 OpenRouter의 유료 모델에, 분류·임베딩은 자체 호스팅한 Ollama(Mistral)에, 컨텍스트 재사용은 PostgreSQL 캐시에 맡겼다. 아키텍처 레이어마다 "이 작업에 가장 싼 도구는 무엇인가"를 물은 결과다.
이 접근을 Claude 4.7 비용 문제에 그대로 적용할 수 있다. 모든 작업을 최신 Opus로 돌릴 이유는 없다. Hacker News 스레드에서도 "무조건 최고 모델 쓰는 시대는 끝났다. 작업에 따라 여러 지점을 선택할 수 있는 라우팅 옵션이 필요하다"는 의견이 반복됐다. GitHub Copilot이 Opus 4.7의 모델 배수를 3에서 7.5로 올리자 "우리 조직에선 Opus 4.7은 절대 켜지 말라"는 내부 권고가 나온 것도 같은 맥락이다. 라우팅 설계가 비용 통제의 실질적 레버다.
그런데 팀에 이걸 정착시키는 게 기술보다 더 어렵다. 많은 팀원이 "최신 모델 = 더 나은 결과"라는 직관을 갖고 있다. 매달 새 모델이 나오고 벤치마크 수치가 올라가는 걸 보면 그 직관이 강화된다. dev.to의 마인드셋 아티클은 이 지점을 "호기심 격차(curiosity gap)"로 설명한다. 기술 격차보다 더 크고 근본적인 문제라는 것이다. 팀원들이 "왜 이 모델을 쓰는가