LLM으로 서비스 만들 때 토큰 비용이 실제로 새는 곳
비용이 큰 쪽은 대개 모델 선택이 아니라, 같은 요청을 두 번 부르는 구조입니다.
LLM을 쓰는 서비스를 만들면 비용 이야기가 반드시 나옵니다. 그런데 처음 논의되는 건 대개 "어느 모델을 쓸 것인가"입니다. 실제로 청구서를 뜯어 보면 모델 선택보다 구조에서 새는 양이 더 큰 경우가 많습니다.
1. 같은 요청을 두 번 부르는 것
가장 흔하고 가장 조용한 낭비입니다. 사용자가 버튼을 두 번 누르거나, 결과가 안 나온다고 새로고침하거나, 네트워크가 끊겨서 재시도하는 상황입니다. 서버 입장에서는 정상 요청이라 로그에도 이상하게 보이지 않습니다.
막는 방법은 간단합니다. 요청 내용을 해시해서 키로 삼고, 같은 키가 이미 처리됐으면 저장된 결과를 돌려주는 것입니다.
- 키: 도구 이름 + 정규화한 입력값의 해시
- 저장 시점: 결과를 쓸 때 같은 트랜잭션으로
- 유효 기간: 한 시간 정도면 충분
이 사이트도 같은 방식으로 처리합니다. 결과 저장과 멱등 키 기록을 한 트랜잭션으로 묶어서, 둘 중 하나만 남는 상태가 생기지 않게 했습니다. 구현은 몇십 줄인데 막아 주는 비용은 그보다 훨씬 큽니다.
2. 매 요청마다 프롬프트 앞쪽이 조금씩 달라지는 것
프롬프트 캐싱은 앞에서부터 정확히 일치하는 구간만 재사용됩니다. 그래서 시스템 프롬프트 안에 현재 시각이나 요청 ID를 넣으면 그 뒤 전체가 캐시에서 빠집니다. 한 글자만 달라져도 그렇습니다.
자주 걸리는 것들이 정해져 있습니다.
- 시스템 프롬프트에 넣은 오늘 날짜
- 매번 순서가 달라지는 JSON 직렬화
- 조건에 따라 도구 목록을 다르게 구성하는 코드
고치는 방향도 단순합니다. 고정된 것을 앞에, 매번 바뀌는 것을 뒤에 둡니다. 캐시가 실제로 먹고 있는지는 응답의 캐시 읽기 토큰 수를 보면 바로 알 수 있습니다. 반복 호출인데 계속 0이면 어딘가에서 앞쪽이 흔들리고 있는 것입니다.
3. 출력 길이를 제한하지 않는 것
입력보다 출력이 몇 배 비쌉니다. 그런데 프롬프트에 "자세히 설명해 주세요"라고 써 두면 모델은 성실하게 길게 씁니다. 사용자는 그 절반도 안 읽습니다.
길이는 토큰 상한으로 자르는 것보다 형식으로 통제하는 편이 낫습니다. 상한으로 자르면 문장 중간에서 끊겨서 재시도가 발생하고, 결국 두 번 부르는 셈이 됩니다. 대신 "표로 정리", "3문장 이내", "항목 5개" 같은 형식 지시를 주면 모델이 알아서 그 안에서 끝냅니다. 읽기도 더 낫습니다.
4. 결과 페이지를 매번 다시 만드는 것
이건 토큰이 아니라 인프라 쪽이지만 같은 성격의 낭비입니다. 한 번 만들어진 결과는 바뀌지 않는데, 그 결과 링크를 여러 사람이 열 때마다 서버가 매번 조회하고 렌더한다면 불필요한 일을 반복하는 것입니다.
결과가 불변이라면 캐시 헤더를 길게 주면 됩니다. 공유 링크가 널리 퍼지는 서비스라면 이 차이가 꽤 큽니다. 링크 하나가 만 번 열려도 실제 서버 처리는 사실상 한 번으로 끝납니다.
5. 어려운 작업에만 필요한 설정을 전부에 적용하는 것
요즘 모델들은 사고 깊이를 조절할 수 있습니다. 그런데 이걸 서비스 전체에 한 값으로 고정해 두는 경우가 많습니다. 분류나 짧은 변환처럼 단순한 작업까지 높은 설정으로 돌아가면 품질 차이는 거의 없는데 비용만 올라갑니다.
경로별로 나누는 게 맞습니다. 판단이 필요한 곳은 높게, 형식 변환에 가까운 곳은 낮게 둡니다. 다만 순서가 중요합니다. 캐싱과 중복 호출 차단 같은 공짜 개선을 먼저 하고, 그다음에 품질을 거래하는 조정을 합니다. 반대로 하면 품질만 깎이고 비용은 별로 안 줄어듭니다.
정리
정리하면 우선순위는 이렇습니다.
- 같은 요청 두 번 부르지 않기 (멱등 키)
- 프롬프트 앞쪽 고정해서 캐시 살리기
- 출력 길이를 형식으로 통제하기
- 불변 결과는 캐시하기
- 경로별로 사고 깊이 조정하기
1번부터 4번까지는 품질을 전혀 깎지 않습니다. 대부분의 경우 여기까지만 해도 비용 이야기가 한동안 나오지 않습니다. 모델을 낮추는 건 그다음에 고민해도 늦지 않습니다.