월 $7,000을 $350으로 줄이고 배운 것

문제는 월 57,000번의 호출이었다

천기문은 한 번의 유료 풀이를 만들 때 LLM을 5~9회 호출한다. 월 요청은 57,000건을 넘었고 API 비용은 $7,000까지 올라갔다. 응답을 줄이거나 모델을 낮추면 사주 해석의 톤과 품질이 흔들릴 수 있었다.

먼저 반복을 찾았다. 긴 시스템 프롬프트와 비슷한 입력이 계속 들어오고 있었다. 같은 내용을 매번 새로 읽히는 대신, Anthropic Prompt Caching으로 긴 컨텍스트를 캐시했다.

캐싱보다 중요한 건 캐시를 살려두는 일

캐시를 켜는 것만으로는 부족했다. 트래픽이 고르지 않으면 TTL이 끝나고, 다음 요청은 다시 전체 비용을 낸다. 1시간마다 캐시를 미리 데우는 작업을 붙였다. 캐시를 기능이 아니라 운영 시스템으로 본 것이다.

세 가지를 배웠다

1. 상품의 핵심은 건드리지 않는다

   품질이 곧 상품이면 모델을 바꾸기 전에 호출 방식과 인프라부터 본다.

2. 캐시는 설정이 아니라 운영이다

   TTL, 실제 트래픽, 워밍 주기를 함께 설계해야 비용이 안정적으로 줄어든다.

3. 측정값이 다음 결정을 만든다

   히트율과 요청 패턴을 보지 않았다면 워밍이 필요한 이유도 찾지 못했을 것이다.

이 수치가 모든 서비스에 그대로 재현된다는 뜻은 아니다. 반복되는 긴 컨텍스트가 있었고, 캐시를 유지할 만큼 호출이 꾸준했던 서비스에서 얻은 결과다. 중요한 건 캐싱이라는 정답이 아니라, 품질을 보존한 채 가장 큰 비용 구간을 찾는 순서다.

최적화는 싼 모델을 찾는 일이 아니라, 같은 품질을 더 적은 낭비로 전달하는 일이다.