Token Reduction Is Not Cost Reduction
이 논문은 코딩 에이전트 컨텍스트에서 토큰 수를 줄이는 것이 프롬프트 캐시 트래픽의 지배력과 작업 실패 위험으로 인해 청구 비용을 안정적으로 낮추지 못한다는 점을 입증하며, 대신 토큰 감소 자체보다는 성공률을 반영한 조정 청구 비용을 기준으로 비용 효율성을 평가해야 한다고 주장한다.
원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
당신이 고도의 기술을 갖춘 탐정 사무소를 운영하고 있다고 상상해 보세요. 당신의 초지능형 AI 탐정들(이하 "코딩 에이전트")은 파일을 읽고, 명령어를 실행하며, 당신과 대화하며 미스터리를 해결합니다. 그들이 파일을 읽거나 명령어를 실행할 때마다 당신은 클라우드 제공업체로부터 청구서를 받게 됩니다.
오랫동안 모든 이들은 돈을 아끼는 가장 좋은 방법이 탐정들이 읽는 텍스트를 줄이는 것이라고 생각했습니다. 논리는 간단했습니다. "파일을 압축하면 읽는 단어 수가 줄어드니, 청구 금액도 내려갈 거야!" 이것은 마치 여행 가방 속의 공기를 짜내어 부피를 줄이는 것처럼 완벽한 계획처럼 보였습니다.
하지만 **"토큰 감소는 비용 감소가 아니다(Token Reduction Is Not Cost Reduction)"**라는 제목의 이 논문은, 그 가방 비유가 함정이라고 말하기 위해 여기 등장했습니다. 저자들은 무엇이 실제로 청구 금액에 영향을 미치는지 확인하기 위해 7개의 서로 다른 코드베이스와 3개의 서로 다른 AI 모델을 대상으로 2,908회 이상의 방대한 실험을 수행했습니다.
여기 반전이 있습니다. 텍스트를 줄이는 것이 항상 청구 금액을 줄여주는 것은 아니라는 것입니다. 사실, 텍스트를 줄이면 청구 금액이 오히려 올라가는 경우도 있습니다.
"캐시 메모리"의 놀라운 사실
가장 충격적인 점은 돈이 실제로 어디로 흘러가는가 하는 것이었습니다. 저자들은 청구 내역을 분석하여 재구성된 비용의 87%(그리고 실제 청구액의 약 80%)가 "프롬프트 캐시 트래픽(prompt-cache traffic)"에서 발생한다는 것을 발견했습니다.
AI의 메모리를 매우 빠르고 마법 같은 화이트보드라고 생각해 보세요.
- 화이트보드에 쓰기 (캐시 생성): 비용이 들지만, 일회성 비용입니다.
- 화이트보드에서 읽기 (캐시 읽기): 할인 쿠폰을 받는 것처럼 매우 저렴합니다.
- 새로운 텍스트 (비캐시 입력): 이것이 비싼 부분이지만, 실제로는 전체 파이에서 아주 작은 조각(약 1.3%)에 불과합니다!
하지만 화이트보드가 명확하게 보여주지 않는 숨겨진 비용이 있습니다. 저자들은 표준적인 분석으로는 설명할 수 없는 청구서 내의 **8.7% "미분류 잔여물(unattributed residual)"**을 발견했습니다. 이 남겨진 덩어리는 무작위가 아닙니다. 이는 AI가 얼마나 열심히 '생각'하느냐에 따라 직접적으로 규모가 커집니다. Haiku 4.5 모델의 경우, "사고 노력(thinking effort)"을 높게 설정할수록 이 신비로운 청구 금액도 커집니다. 이는 텍스트가 작아 보이더라도, AI가 토큰 수에는 나타나지 않는 값비싼 정신적 작업을 수행하고 있을 수 있음을 시사합니다.
문제는 텍스트를 압축할 때, 단순히 "새로운 텍스트" 부분만 아끼는 것이 아니라는 점입니다. 당신은 "화이트보드에서 읽는" 부분을 망가뜨릴 수 있습니다. 만약 파일을 너무 과하게 압축하면, AI가 혼란에 빠져 자신이 무엇을 하고 있었는지 잊어버리고, 상황을 파악하기 위해 대화의 전체 기록을 다시 읽어야 할 수도 있습니다.
AI가 그 기록을 다시 읽어야 할 때마다, 그것을 화이트보드에 다시 써야 합니다. 그리고 쓰는 작업은 비쌉니다! 따라서 설령 몇 단어를 아꼈다 하더라도, 당신은 AI에게 그 "쓰기 비용"을 반복해서 지불하게 만든 셈입니다.
더 많은 비용을 초래한 "38%의 삭감"
저자들은 RTK-ML이라 불리는 정교한 압축 시스템을 테스트했습니다. 이 시스템은 원본 도구 출력 텍스트를 38.4% 성공적으로 줄였습니다. 당연히 엄청난 돈을 아낄 것이라고 생각했겠죠?
틀렸습니다.
대조 테스트 결과, 이 시스템은 오히려 비용을 6.8% 증가시켰습니다 (95% 신뢰 구간 [+2.8, +11.3]).
왜일까요? 압축이 너무 공격적이었기 때문에 AI가 문제를 해결하기 위해 추가적인 단계를 밟아야 했기 때문입니다. AI는 추가적인 진단 턴을 실행하고, 파일을 다시 읽고, 더 많은 질문을 던져야 했습니다. 이러한 각 단계는 대화 기록 전체를 다시 전송해야 함을 의미했고, 이는 텍스트 압축으로 얻은 절약분을 모두 상쇄해 버렸습니다.
이 논문은 "토큰이 적으면 비용이 낮아진다"는 아이디어를 명시적으로 부정합니다. 저자들은 텍스트를 얼마나 많이 제거하느냐와 비용을 얼마나 아끼느냐 사이의 관계가 거의 존재하지 않는다는 것을 발견했습니다. 상관관계는 0.15로 매우 낮았는데, 이는 거의 0에 가까워 사실상 동전 던지기와 다름없는 수준이었습니다.
"깨진 닻(Broken Anchor)"의 재앙
압축이 역효사를 불러올 수 있는 또 다른 방법은 AI가 업무를 수행하는 데 필요한 단서를 망가뜨리는 것입니다.
저자들은 Go 프로그래밍 작업에 대한 특별 테스트를 진행했습니다. 그들은 텍스트를 압축했을 때, AI가 버그를 수정하기 위해 복사하여 붙여넣어야 하는 정확한, 바이트 단위의 코드 라인인 "버전별 편집 앵커(verbatim edit anchors)"를 놓치는 경우가 있다는 것을 발견했습니다.
파이프의 누수를 고치려고 하는데, 읽고 있는 지침이 너무 쥐어짜져서서 잘라내야 할 특정 부분이 흐릿한 얼룩처럼 변해버린 상황을 상상해 보세요. AI는 패치(수정 사항)를 적용하려고 노력하지만, 지침이 손상되었기 때문에 "패치"가 제대로 맞지 않습니다.
- 압축 없음: AI가 40개의 패치 중 27개를 성공적으로 적용했습니다.
- 압축 있음: AI는 40개 중 15개만을 성공했습니다.
이 특정 테스트에서, 압축된 버전은 성공적인 수정당 비용이 더 낮아 보였을지 모르지만, 실제로는 성공할 때까지 드는 "성공당 비용"이 두 배(0.248)였습니다. 왜냐하면 실패율이 너무 높았기 때문입니다.
"블랙박스" 프록시
그들은 또한 메시지를 AI에 전달하기 전에 재작성하는 중간 매개체 역할을 하는 Headroom이라는 다른 도구도 테스트했습니다. 이 도구는 지갑에 완전한 재앙이었습니다. 아무것도 하지 않았을 때보다 비용을 48.4% 더 높게 만들었으며(95% CI [+42.3, +55.0]), 성공률의 개선도 전혀 없었습니다.
결론
논문의 결론은 다음과 같습니다. AI 코딩 에이전트에 들어가는 비용을 아끼고 싶다면, 단순히 "토큰 카운터"만 보고 승리했다고 확신해서는 안 됩니다.
- 증명된 사실: 이 구체적인 실제 테스트에서, 텍스트를 줄이는 것이 비용을 안정적으로 낮춰주지 않았습니다. 사실, RTK-ML 시스템의 경우 오히려 더 비싸게 만들었습니다. Headroom의 경우 훨씬 더 비싸게 만들었습니다.
- 측정된 내용: 그들은 단순히 추측한 것이 아니라, 메인 캠페인에 대해서만 약 $175.92에 달하는 실제 청구 금액과, 표준 토큰 수로는 설명할 수 없으며 사고 노력에 따라 변하는 **8.7%**의 추가 비용을 포함하여 2,908회의 실제 실행을 추적했습니다.
- 제언: 압축 도구가 효과가 있는지 알 수 있는 유일한 방법은 제거된 단어 수가 아니라, 성공적인 작업당 최종 청구 금액을 측정하는 것입니다.
그러므로 다음에 누군가 당신에게 "데이터를 50% 압축해서 비용을 아꼈습니다!"라고 말한다면, 당신은 미소를 지으며 이렇게 말할 수 있습니다. "좋네요, 그런데 그 때문에 AI가 책 전체를 다시 읽어야 했던 건 아닌지 확인해 보셨나요?" 왜냐하면 AI 에이전트의 세계에서는 때때로 가장 짧은 경로가 가장 비싼 경로가 될 수 있기 때문입니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.