Opus 4.7이 4.6보다 토큰을 45% 더 쓴다? 같은 답인데 비용은 늘어나는 이유

같은 질문, 같은 답, 그런데 청구서는 더 많이 나온다

혹시 AI 코딩 도구를 쓰다가 "어? 저번 달보다 API 비용이 꽤 올랐네?" 하고 느낀 적 있으세요? 모델을 바꾼 것도 아니고 작업량이 크게 늘어난 것도 아닌데 말이죠. 최근 개발자 커뮤니티에서 이 현상을 숫자로 증명한 리더보드 하나가 돌고 있어요. Bill Chambers라는 분이 만든 "Token Inflation Leaderboard"인데요, 여기서 드러난 수치가 꽤 충격적이에요. Claude Opus 4.7이 이전 버전인 4.6에 비해 같은 문제를 푸는 데 약 45% 더 많은 토큰을 소비한다는 거예요.

"토큰 인플레이션"이라는 말이 낯설 수 있는데요, 쉽게 말해서 물가 상승처럼 AI 모델도 같은 일을 하는데 점점 더 많은 "재료(토큰)"를 쓰게 되는 현상을 말해요. 토큰은 AI가 글자를 처리하는 최소 단위이고, API 요금은 토큰 수로 계산되거든요. 그래서 이게 늘어난다는 건 곧 지갑에서 돈이 더 나간다는 뜻이에요.

왜 신모델이 토큰을 더 먹을까?

상식적으로는 모델이 발전하면 더 효율적이 되어야 할 것 같잖아요. 더 똑똑해졌으니 같은 문제를 더 짧게 풀 수 있어야지, 왜 오히려 늘어날까요. 여기에는 몇 가지 이유가 섞여 있어요.

첫 번째는 추론(reasoning) 모드의 확산이에요. 요즘 모델들은 답을 내기 전에 "생각하는 과정"을 길게 펼쳐놓고 그걸 다시 정리해서 답을 주는 방식을 많이 써요. 사람이 어려운 수학 문제를 풀 때 계산을 연습장에 쭉 적어가면서 푸는 것과 비슷해요. 이 연습장에 적히는 글자 하나하나가 다 토큰으로 계산돼요. 최종 답변만 보면 몇 줄 안 되는데, 뒤에서 속으로 생각한 내용이 수천 토큰씩 쌓이는 거죠.

두 번째는 에이전트(agent) 방식의 확산이에요. 예전엔 "질문 하나 → 답변 하나"로 끝났다면, 요즘은 Claude Code나 Cursor 같은 도구에서 모델이 파일을 읽고, 도구를 호출하고, 결과를 보고 다시 판단하는 과정을 반복해요. 이 반복 하나하나가 다 토큰이에요. 리더보드에서도 단순 Q&A가 아니라 실제 코딩 작업 같은 복잡한 태스크를 기준으로 측정했기 때문에 이 차이가 크게 벌어진 거예요.

세 번째는 모델의 "장황함" 그 자체예요. 새 모델이 컨텍스트를 더 신중하게 다루면서 중간에 확인 질문을 하거나, 주석을 더 풍부하게 달거나, 코드 블록 앞뒤로 설명을 길게 붙이는 경향이 생겼다는 지적이 있어요.

업계 맥락 – 인플레이션은 Claude만의 문제가 아니에요

사실 이런 토큰 팽창 현상은 OpenAI의 o 시리즈, Google의 Gemini 2.5 Pro 같은 경쟁 모델에서도 공통적으로 나타나고 있어요. 추론형 모델이 주류가 되면서 "답변 토큰" 외에 "사고(thinking) 토큰"이라는 새로운 과금 항목이 생겼거든요. 어떤 벤더는 이 사고 토큰을 청구하고, 어떤 벤더는 숨기고, 어떤 벤더는 할인해주는 식으로 정책이 다 달라요.

이러다 보니 벤치마크 점수만 보고 모델을 고르면 안 된다는 이야기가 나와요. 점수는 올라갔는데 그 점수를 내기 위해 쓴 토큰이 3배라면, 실제 서비스에서는 훨씬 비싸진 셈이거든요. 그래서 최근엔 "토큰당 성능(performance per token)" 또는 "달러당 정답률" 같은 지표가 중요해지고 있어요. Artificial Analysis 같은 곳에서도 비슷한 경제성 지표를 내놓기 시작했고요.

한국 개발자에게 주는 시사점

당장 실무에 쓰시는 분들께는 몇 가지 행동 지침이 나와요. 일단 사내에서 Claude Code나 Cursor 같은 도구를 정액제가 아니라 API 종량제로 쓰시는 분들은 이번 달 청구서를 한번 열어보셔야 해요. 모델만 최신으로 올렸는데 체감상 비슷한 작업이면서 비용이 꽤 올랐다면, 그게 토큰 인플레이션 때문일 가능성이 높아요.

두 번째로, 모델 선택을 태스크별로 나누는 전략이 실용적이에요. 간단한 리팩터링이나 변수명 바꾸기 같은 작업은 굳이 Opus급을 부를 필요 없이 Haiku나 Sonnet 같은 가벼운 모델로 충분해요. 정말 어려운 아키텍처 설계나 디버깅 같은 곳에만 최상위 모델을 쓰는 식으로 라우팅하면, 품질은 크게 안 떨어지면서 비용은 눈에 띄게 줄어들어요.

세 번째는 사고 토큰 옵션을 끄거나 제한하는 거예요. Anthropic이든 OpenAI든 reasoning effort를 low/medium/high로 조절할 수 있게 해줘요. 대부분의 CRUD 작업은 low로도 충분하거든요. 이것만 바꿔도 토큰 사용량이 절반으로 떨어지는 경우가 많아요.

네 번째, 내부에서 토큰 사용량 로깅과 대시보드를 만들어두는 게 좋아요. 어느 기능이, 어느 팀이, 어느 프롬프트가 토큰을 가장 많이 먹는지 보이면 최적화 포인트가 드러나요. 프롬프트 캐싱을 적극 쓰는 것도 중요한데, 반복되는 시스템 프롬프트나 긴 문서는 캐시에 올려두면 90% 할인된 가격으로 재사용할 수 있거든요.

마무리

핵심은 "모델 성능은 올라갔지만 그 성능을 뽑아내기 위한 원가도 같이 올라갔다"는 거예요. 벤치마크 숫자만 보고 업그레이드했다가는 청구서에서 뒤통수를 맞을 수 있어요. 앞으로 AI 도구를 선택할 때는 "얼마나 똑똑한가"와 "얼마에 똑똑한가"를 같이 봐야 하는 시대가 온 것 같아요.

여러분 팀에서는 AI 코딩 도구의 토큰 비용을 어떻게 관리하고 계세요? 혹시 모델을 태스크별로 나눠 쓰거나 라우팅하는 노하우가 있으시면 공유해주시면 다들 도움이 될 것 같아요.