수상한 잡화점 삽질 기록: 입력을 4분의 1로 줄였는데 LLM 비용이 그대로였다

LLM API 비용을 줄이려고 프롬프트를 열심히 다이어트했는데 청구액이 거의 그대로였다. 원인을 따라가 보니 돈은 입력이 아니라 출력, 그중에서도 눈에 보이지 않는 사고(thinking) 토큰에서 나가고 있었다.

실측

코드 변경 내용을 읽고 문서를 써 주는 작업이었다. 원문을 통째로 보내는 대신 요약해서 보내는 모드를 만들어 입력을 약 4분의 1로 줄였다. 결과는 문서 한 건당 비용이 4% 남짓 줄어든 것이 전부였다.

사용량을 뜯어보니 이랬다.

비용의 약 80%가 출력 쪽이었다. 출력 토큰의 단가는 입력보다 몇 배 비싸다.
그 출력의 절반가량이 사고 토큰이었다. 모델이 답을 쓰기 전에 속으로 추론하는 데 쓰는 토큰인데, 응답 본문에는 보이지 않지만 출력 단가로 과금된다.

입력을 줄이는 최적화는 비용 구조의 20% 안에서만 움직인 셈이다. 그 요약 모드는 결국 비용이 아니라 "외부로 나가는 원문을 줄인다"는 다른 목적으로만 의미가 있었다.

사고 토큰은 다른 필드에 있다. 어떤 API 는 응답의 사용량 정보에서 답변 토큰과 사고 토큰을 따로 준다. 답변 토큰만 더하면 비용이 크게 과소 계산된다. 짧은 답 하나에 사고 119 토큰, 답 5 토큰이 나온 적도 있다. 스무 배가 넘는 차이다.
단가표에 없는 모델을 0원으로 치면 안 된다. 직접 만든 사용량 집계에 모델별 단가표를 넣어 뒀는데, 새 모델로 바꾸면서 표를 갱신하지 않았다. 집계는 그 모델의 비용을 0으로 계산했고, 걸어 둔 일일 예산 상한은 아무 경고 없이 뚫렸다. 지금은 표에 없는 모델을 가장 비싼 단가로 계산하고 로그에 추정치 표시를 붙인다. 모르는 값은 안전한 쪽으로 틀려야 한다.
구독과 API 는 지갑이 다르다. 채팅 앱이나 코딩 도구의 월 구독은 API 사용료를 포함하지 않는다. 구독 중이니 API 도 되겠지 하고 붙였다가 잔액 부족 오류를 만난다.

먼저 잰다. 호출마다 입력·출력·사고 토큰을 따로 기록한다. 어디가 큰지 모르고 줄이는 것은 운에 맡기는 일이다.
사고를 조절한다. 분류, 번역, 한 줄 요약처럼 추론이 필요 없는 작업은 사고를 끄거나 예산을 낮춘다. 내 경우 가벼운 모델이 짧은 답 하나에 천 토큰 넘게 생각하고 있었고, 끄자 속도와 비용이 함께 떨어졌다.
출력 길이를 설계한다. "자세히 설명해 줘"는 비싼 요청이다. 필요한 필드만 구조화해서 받으면 출력이 줄고 뒤처리도 쉬워진다.
자주 도는 호출부터 본다. 하루 한 번 도는 긴 작업보다 5분마다 도는 사소한 작업이 총액을 지배하는 경우가 많다. 그런 호출은 가벼운 모델로 내리고 결과를 캐시한다.
입력 최적화는 마지막에. 반복되는 긴 지시문이 있다면 프롬프트 캐싱이 효과적이지만, 위의 것들을 먼저 한 뒤의 이야기다.

LLM 비용은 직관과 다르게 움직인다. "보내는 글이 길어서 비싸다"는 느낌은 대개 틀렸고, 보이지 않는 사고 토큰과 자주 도는 호출이 진짜 범인이었다. 줄이기 전에 재고, 모르는 단가는 비싸게 잡는다.