결론

얼마 전, "오픈 모델은 가격을 타격하는 몽둥이다"라는 글을 썼다. 중국의 오픈 웨이트 (Open Weights) 모델이 폐쇄형 (Closed) 진영의 API 단가를 낮추고 있다는 이야기다. 하지만 마지막에 한 가지 처방을 남겼다——"단가가 낮아지더라도, 토큰 사용 방식이 허술하다면 가격 인하는 탁상공론에 그칠 것이다".

이 글은 그 처방만을 따로 떼어 깊이 파고든다.

주장은 심플하다. 당신의 AI 비용 중 과반은 "어떤 모델을 선택하느냐"가 아니라, "보내고 있다는 사실조차 인지하지 못한 토큰"에 의해 결정된다. 나는 자체 제작한 프록시 (Proxy)로 나의 개발 과정을 1년 치 측정했다. 결과적으로 성과를 전혀 바꾸지 않고도 54.7%의 토큰이 사라졌다. 모델을 바꾸지 않았다. 프롬프트 (Prompt) 내용도 바꾸지 않았다. 그저 "보낼 필요가 없는 것"을 보내는 행위를 멈췄을 뿐이다.

다루고자 하는 것은 "어떤 모델이 저렴한가"가 아니다 (그것은 별도의 글에서 다뤘다). 다루고자 하는 것은 "무엇을 보내지 않을 것인가"라는 설계다.

제1부: 지금 일어나고 있는 "tokenmaxing"

지금의 AI 개발 분위기는 솔직히 말해 tokenmaxing (토큰 최대화) 상태다. 컨텍스트 (Context)는 클수록 좋고, 에이전트 (Agent)는 많을수록 좋으며, 안 되면 다시 던지면 된다——컨텍스트 윈도우 (Context Window)도 병렬 에이전트도 리트라이 (Retry)도, 전부 "가득 채우는" 방향으로 나아가고 있다.

하지만 채워 넣은 양은 성과와 상관관계가 없다. r/ClaudeCode에서 699표를 얻은 게시물이 이 분위기를 한마디로 꿰뚫었다——"tokenmaxing과 successmaxing은 같지 않다" (r/ClaudeCode). 댓글창의 자학적인 반응이 이를 상징한다:

"180억 토큰을 썼는데, 리포지토리 (Repository) 이름은 여전히

untitled-project-final-v2

"

흥미로운 점은 프론티어 (Frontier) 측에서도 반작용이 나타나고 있다는 것이다. 같은 주, OpenAI는 Codex의 투입 컨텍스트를 372k에서 272k로 축소했다 (Hacker News, 259pt). "많을수록 좋다"는 것이 당연하지 않게 되어가고 있다.

채워 넣는 것을 그만둔다는 발상이 여기서 시작된다. 단, "성능을 낮추어 절약하는 것"과는 다르다. 성과를 바꾸지 않고 줄일 수 있는 여지가 사실 대량으로 존재한다. 그것을 가시화하는 것부터 이야기를 시작하고 싶다.

제2부: 왜 "불가시 토큰"이 비용을 결정하는가

세 가지 메커니즘으로 나눈다.

(1) 비용은 "어떤 토큰을 보내는가"의 분포로 결정된다

AI 비용은 거칠게 말하면 "토큰 양 × 단가"다. 모델 선택은 단가 측면을 건드린다. 하지만 많은 사람이 간과하는 것은, 토큰 양 측면은 "무엇을 보내느냐"에 따라 자릿수가 바뀐다는 점이다.

구체적인 예를 들겠다. 에이전트에게 curl로 API를 호출하게 하면, 가공되지 않은 응답 (거대한 JSON, HTML 전문, HTTP 헤더 더미)이 통째로 컨텍스트에 들어간다. ps aux의 전체 프로세스 목록, 빌드 로그 수천 줄, git log의 전체 이력——이 모두 "AI가 필요로 하는 정보"는 극히 일부임에도 불구하고, 노이즈 (Noise)와 함께 전송된다. 단가를 아무리 낮춰도 이 부분이 비대하다면 효과가 없다.

이는 나만의 체감이 아니다. Quesma의 엔지니어가 "토큰 절약법을 연구하다가 가진 토큰을 전부 녹여버렸다"라는 아이러니한 체험기를 통해, 같은 현상을 다른 각도에서 측정했다. 그들의 보고에 따르면, 하네스 (Harness, 토큰을 어떻게 운반하는가)에 따라 최대 66배의 토큰 차이가 발생했다 (Quesma). 66배. 모델의 단가 차이 따위는 오차로 보일 정도의 격차다. 영향을 미치는 것은 모델이 아니라, 토큰을 운반하는 방식이다.

(2) 노이즈는 편재한다

그리고 중요한 것은, 이 낭비가 모든 명령에 균등하게 퍼져 있는 것이 아니라는 점이다. 노이즈는 편재한다.

나의 실측 (후술)에 따르면, curl 계열의 웹 취득은 출력의 99% 이상이 중복적이며, 삭제해도 의미가 변하지 않는다. 반면 소스 코드를 읽는 작업은 이미 정보 밀도가 높아 10% 정도밖에 줄어들지 않는다. 즉, "전부를 압축하는 것"은 효율적이지 않다. 어디에 노이즈가 집중되어 있는지 파악하고, 그 부분만 타격하는 것이 토큰 설계다.

(3) 프리 런치 (Free Lunch)는 실재한다

경제학은 "공짜 점심(Free Lunch)은 없다"라고 말한다. 하지만 (1)과 (2)를 결합하면, AI 비용에는 예외적으로 프리 런치가 존재한다. 모델을 바꾸지 않고, 성과도 바꾸지 않으면서, 비용만 떨어지는 영역이다.

왜 가능할까? 고노이즈 (High-noise) 영역(curl, 로그, ps)은 "의미를 유지한 채" 요약 및 압축할 수 있기 때문이다. API 응답에서 필요한 필드만 추출하거나, 로그의 에러 행만 남기거나, 프로세스 목록을 집계하는 식이다. AI에 전달되는 정보의 질은 변하지 않고 양만 줄어든다. 이것은 "성능과 비용의 트레이드오프 (Trade-off)"가 아니다. 그저 낭비를 제거하는 것뿐이다.

제3부: 개인 개발자는 어떻게 해야 하는가

개념을 재현 가능한 처방으로 바꾼다. 1차 자료로서 자신의 실측치를 제시한다.

처방 1: 고노이즈 출력은 "압축해서" 전달하라

나는 개발 명령어의 토큰을 줄이기 위해, RTK (Rust Token Killer)라는 자체 제작 CLI 프록시 (Proxy)를 상용하고 있다. git status나 curl의 출력을 의미를 유지한 채 압축하여 에이전트 (Agent)에게 전달하는 구조다. 1년 치의 rtk gain (실측치)은 다음과 같다:

Total commands: 7,656
Input tokens: 54.1M
Output tokens: 24.5M
...

누적 29.6M 토큰, 54.7% 절감. 그리고 명령어별 내역은 제2부에서 언급한 "편재 (Skewness)"를 뒷받침한다:

효과를 보고 있는 것은 모델이 아니다. "가공되지 않은 거대한 출력을 요약을 거쳐 전달한다" — 단지 그뿐이다. RTK를 반드시 쓸 필요는 없다. 핵심은 웹 취득, 로그, 프로세스 목록과 같은 "고노이즈·저정보" 출력을 그대로 AI에게 흘려보내지 않는 것이다.

처방 2: 이미 날씬한 것은 건드리지 마라

위 표의 마지막 행이 시사하는 바가 크다. read (파일 읽기)는 671회 실행했음에도 10%밖에 줄지 않았다. 소스 코드나 텍스트는 원래부터 정보 밀도가 높기 때문이다.

여기에 함정이 있다. "토큰을 줄이겠다"고 결심하면 무심코 전부를 압축하고 싶어진다. 하지만 저노이즈 (Low-noise) 영역을 깎아봤자 노력에 걸맞은 절감 효과는 나오지 않을뿐더러, 정보를 누락시켜 성능을 떨어뜨릴 리스크만 커진다. 절약은 편재하므로, 최적화도 편재시켜야 한다. 전체의 몇 %를 차지하는 고노이즈 명령어 군에 집중 투입하는 것이 비용 대비 효과가 가장 높다.

게다가 조잡한 압축은 오히려 역효과를 낼 수 있다. 앞서 언급한 Quesma는 "단순한 컨텍스트 압축 (Context Compression)이 오히려 청구 금액을 배증시킬 수 있다", "캐시 무효화로 인해 숨겨진 재청구가 발생할 수 있다"고 보고했다 (Quesma). 프롬프트 캐시 (Prompt Cache)가 작동하던 부분을 어설프게 압축하면, 캐시가 무효화되어 전체를 다시 전송해야 하는 상황이 발생한다. 따라서 "무조건 짧게 만들기"가 아니라, "고노이즈인 부분만 캐시를 깨뜨리지 않고" 깎아내는 것이 요점이다.

처방 3: 우선 "측정하라". 도구는 주인공이 아니다

마지막으로 가장 중요한 것. 지금까지의 이야기는 전부 측정하고 나서야 알 수 있었다. 어떤 명령어가 낭비원인지 rtk gain과 같은 시각화 도구가 없다면 영원히 보이지 않는다. 보이지 않는 것은 설계할 수 없다.

그리고 공정하게 말하자면, RTK는 만능이 아니다. rtk proxy (원문 그대로 통과시키는 용도)나 폴백 (Fallback) 경로는 **절감률 0%**다. 도구가 마법인 것이 아니라, "측정하고, 편향을 찾아내고, 그 부분만 타격한다"는 습관이 본체이며, RTK는 그 습관을 돌리기 위한 계기판에 불과하다. 프롬프트 캐시든, 컨텍스트 압축이든, 요약 통과든, 시작점은 모두 "우선 측정하기"다.

마무리

모델의 가격표는 눈에 보인다. 그래서 우리는 "어떤 모델이 저렴한가"를 열심히 비교한다. 반면, 자신이 매일 얼마나 많은 불가시 (Invisible) 토큰을 흘려보내고 있는지는 눈에 보이지 않는다. 그래서 최적화는 보이는 쪽 — 모델 선택 — 에 치우치게 된다.

하지만 진짜 변수는 보이지 않는 곳에 있다.

이전 글에서 "오픈 모델 (Open Model)이 단가를 깎아 내려준다"고 썼다. 그 인하된 가격을 자신의 낭비로 상쇄해 버린다면 너무 아까운 일이다. tokenmaxing을 멈추고, successmaxing으로. 우선 측정하자. 깎을 수 있는 것은 대개 당신이 보내고 있다는 사실조차 인지하지 못하는 토큰들이다.

Discussion