HN이 파고든 Opus 4.7 토큰 문제: 입력은 평균 38% 더 무거웠다

커뮤니티가 본 것은 모델 성능보다 청구 단위였다

Hacker News의 관심은 단순히 "Opus 4.7이 비싸졌다"는 불평에 머물지 않았다. 링크된 Tokenomics 페이지는 사용자가 넣은 같은 transcript를 Opus 4.6과 Opus 4.7의 request token 기준으로 비교한다. 이 사이트는 prompt 본문을 저장하지 않고 익명 submission ID와 집계값만 남긴다고 설명하며, 현재 공개 집계는 541건의 submission에서 Opus 4.6 평균 349 request tokens, Opus 4.7 평균 466 request tokens를 가리켰다. 평균 request token 변화는 +38.1%로 표시됐다.

이 숫자가 HN에서 빠르게 퍼진 이유는 Claude 사용자들이 이미 체감하던 문제와 맞닿아 있었기 때문이다. 여러 댓글은 Opus 4.7에서 5시간 사용 한도나 daily/weekly limit가 이전보다 빨리 닳는 느낌을 이야기했다. 특히 coding agent나 IDE 안에서 긴 파일, 로그, 이전 대화가 함께 들어가는 워크플로에서는 tokenizer 차이가 곧 체감 비용으로 바뀐다. 모델의 답변이 더 짧아지거나 reasoning token이 줄어드는 경우까지 합산하면 전체 비용이 달라질 수 있지만, request 쪽 변화만 따로 떼어 본 데이터라는 점이 토론의 출발점이었다.

상위 댓글들은 그래서 신중했다. 한쪽은 Opus 4.7이 output token을 덜 쓰고 reasoning 비용도 줄 수 있으니 total cost를 봐야 한다고 지적했다. 다른 쪽은 token-counting API로 입력 tokenizer 변화만 격리해 본 실험이라, "왜 한도가 이렇게 빨리 줄지"를 설명하는 데는 충분히 유용하다고 봤다. 이 긴장은 LLM 제품에서 점점 자주 나타나는 문제다. 사용자가 느끼는 성능은 latency, context 처리, agent 반복 횟수, output 길이, subscription limit가 섞인 결과인데, 제공되는 설명은 보통 모델명 하나로 압축된다.

이번 HN 스레드가 남긴 핵심은 Opus 4.7의 좋고 나쁨을 단정하는 것이 아니다. 커뮤니티는 모델 교체가 tokenizer, billing meter, IDE quota, agent loop에 미치는 영향을 직접 계측하려고 했다. LLM이 일상적인 개발 도구가 될수록, "같은 작업"이 실제로 같은 단위로 계산되는지 확인하는 문화가 더 중요해지고 있다.

Source: Tokenomics leaderboard and Hacker News discussion.