LLM 토큰 가격이 또 떨어졌다 — 우리 인프라 계산식이 바뀐 지점

뉴스로 읽을 때와 인프라를 짤 때는 다른 이야기다

LLM 단가 인하 소식은 올해만 벌써 여러 차례 나왔다. GPT-4o 입력 토큰이 2024년 초 대비 절반 이하로 내려갔고, Claude 3.5 Haiku·Sonnet 계열은 출시 때부터 전 세대 대비 60~80% 낮은 가격으로 진입했다. Gemini 1.5 Flash는 특정 구간에서 입력 토큰을 사실상 무료에 가깝게 제공하기도 했다. "좋은 소식이네" 하고 넘기면 그게 전부지만, 우리처럼 LLM을 결제·정산·자동화 워크플로에 직접 연결해서 운영하는 팀에게는 이 뉴스가 스프레드시트를 다시 열어야 하는 트리거가 된다.

결제와 정산은 호출 건수가 많다. 세금계산서 한 장 파싱, 입금 내역 한 줄 매칭, 이상 거래 한 건 플래그 — 이 작업들이 하루에 수천 건 이상 쌓인다. 단가가 10% 내려가면 월 비용이 10% 줄어드는 게 아니라, 우리가 비용 때문에 포기했던 설계 선택지가 다시 테이블 위로 올라온다는 뜻이다. 그 선택지 중 일부는 처음부터 품질 문제였지 비용 문제가 아니었다.

우리가 비용 계산식을 '공식 문서'처럼 관리하는 이유

HEDVION은 LLM 호출 비용을 스프레드시트 한 장으로 관리한다. 워크플로별로 평균 입력 토큰 수, 평균 출력 토큰 수, 프롬프트 캐시 적중률, 월 예상 호출 건수를 기록하고, 현재 단가를 곱해서 월별 비용을 시뮬레이션한다. 단순해 보이지만 이 시트가 없으면 "다음 달 LLM 비용이 얼마나 나올지"를 아무도 모른다는 상태가 된다. 정산 팀이 예산을 잡을 때 근거가 없어지고, 새 기능을 붙일 때 비용 영향을 추산할 방법도 없어진다.

구체적으로 우리 시트에는 다음 항목이 들어간다. 세금계산서 OCR 후 구조화 워크플로: 평균 입력 4,200토큰, 출력 380토큰, 캐시 적중률 약 65%, 월 12,000건. 입금 내역 자동 매칭 워크플로: 평균 입력 1,800토큰, 출력 120토큰, 캐시 적중률 약 40%, 월 35,000건. 이 두 워크플로만 합쳐도 Claude Sonnet 기준으로 월 비용이 단가 변동에 따라 수십만 원에서 수백만 원 단위로 출렁인다. 계산식이 없으면 가격표가 바뀔 때 어디서 얼마가 바뀌는지 파악하는 데만 며칠이 걸린다.

단가 인하가 실제로 설계 결정을 뒤집은 세 가지 지점

컨텍스트 길이 상한선. 정산 워크플로에서 우리는 한동안 입력 컨텍스트를 2,500토큰으로 강제 제한했다. 세금계산서 원문이 길어도 앞부분만 잘라서 넘기는 방식이었다. 이유는 단순했다. 입력 토큰이 비쌌고, 4,000토큰 이상 보내면 월 비용이 약 38% 증가했다. 그런데 컨텍스트를 자르면 품목이 많은 계산서에서 후반부 항목이 누락되는 오류가 생겼고, 그 오류를 사람이 검수하는 시간이 호출 비용보다 더 비쌌다. 단가가 내려가면서 4,200토큰으로 늘렸을 때 월 추가 비용은 약 9만 원, 줄어든 검수 공수는 월 16시간이었다. 트레이드오프가 명확히 뒤집혔다.

모델 티어링 분기 로직. 코드베이스에 "단순 요청은 Haiku, 복잡한 요청은 Sonnet"이라는 라우팅 로직이 있었다. 입력 토큰 수 1,000 이하면 Haiku, 이상이면 Sonnet으로 분기하는 방식이었다. 2024년 중반까지는 이 분기가 월 약 22% 비용 절감을 만들어냈다. 그런데 Haiku 3.5와 Sonnet 3.5의 단가 격차가 좁아지면서(입력 기준 약 4배 → 약 2.2배), 이 분기 로직이 만들어내는 코드 복잡도와 테스트 부담이 절감액을 넘어서기 시작했다. 지금은 95%의 호출을 Sonnet 단일 모델로 처리하고, 극단적으로 단순한 분류 작업만 Haiku에 남겨뒀다. 코드 분기가 줄어드니 프롬프트 품질을 한 곳에 집중해서 올릴 수 있게 됐다.

캐싱 설계의 재검토. 프롬프트 캐싱은 단가 인하와 독립적으로 작동하지만, 단가가 내려가면 캐시 구현에 쓰는 엔지니어링 비용 대비 절감 효과 비율이 달라진다. 캐시 적중률 65%일 때 캐싱 구현이 월 X만큼 절감한다면, 단가가 40% 떨어지면 같은 캐시가 0.6X만 절감한다. 캐싱을 정교하게 유지하는 엔지니어링 시간이 상대적으로 비싸진다는 뜻이다. 우리는 이걸 이유로 캐싱을 줄인 게 아니라, 캐싱에 공들이는 우선순위를 재조정했다. 이미 구현된 캐시는 유지하되, 새 워크플로에서 정교한 캐시 전략에 시간을 많이 쓰지 않는 방향으로 바꿨다.

'단가 격차 좁아짐'이 모델 선택에 미치는 실제 영향

모델 티어링을 설계할 때 흔히 간과하는 것이 있다. 단가 격차만 보는 게 아니라, 그 분기 로직이 틀렸을 때 드는 비용을 함께 봐야 한다. "단순한 요청"이라고 판단해서 Haiku로 보냈는데 결과가 엉터리면, 그 호출은 Sonnet으로 재시도하거나 사람이 수정해야 한다. 재시도 비용과 검수 비용이 단가 절감분을 먹는다.

우리가 직접 측정한 수치를 보면, 자동 매칭 워크플로에서 Haiku로 처리한 요청의 오류율이 Sonnet 대비 약 3.4배 높았다(입력 복잡도가 비슷한 구간 기준). 오류 건당 평균 수정 비용을 환산하면, Haiku의 단가 이점이 오류율 차이에 의해 완전히 상쇄됐다. 이 수치는 단가 격차가 클 때는 Haiku 쪽이 그래도 유리했지만, 격차가 2배 초반대로 좁아진 시점부터 Sonnet 단일 운영이 전체 비용 기준으로 저렴해졌다. 이 계산을 해보지 않으면 단가표만 보고 "Haiku가 싸니까 Haiku 써야지"라는 결론에 머물게 된다.

HEDVION이 지금 쓰는 방식: 품질 측정 루프를 중심으로

단가가 바뀔 때마다 흔들리지 않으려면 비용 절대값이 아니라 '품질 대비 비용(quality-per-cost)' 기준이 있어야 한다. 우리는 각 워크플로별로 세 가지 지표를 정기적으로 측정한다. 정확도(기대 출력 대비 실제 출력 일치율), 오류 처리 비용(오류 건당 평균 수정·재처리 비용), 호출당 순비용(LLM 비용 + 오류 비용 합산). 이 세 수치가 있으면 단가가 바뀌었을 때 "어떤 설정을 바꿔야 하는가"를 데이터로 판단할 수 있다.

분기 검토 주기는 분기에 1회로 고정했다. 매달 하면 노이즈가 많고, 반기나 연 단위로 하면 설계가 이미 낡아 있다. 분기 검토 때 확인하는 항목은 세 가지다. 단가 변동이 있었는지, 있었다면 어떤 워크플로의 비용 구조가 의미 있게 바뀌었는지, 바뀐 비용 구조가 현재 설계(컨텍스트 제한, 모델 선택, 캐시 전략)를 재검토할 임계값을 넘었는지. 이 세 질문에 "아니오"가 두 개 이상이면 현행 유지, 그렇지 않으면 변경 검토를 시작한다.

지금 바로 써먹을 수 있는 시사점

단가가 또 내려갔다는 소식을 봤을 때 할 수 있는 구체적인 행동을 정리한다.

1. 비용 계산식 시트를 만들지 않았다면 지금 만든다. 워크플로별로 평균 입력/출력 토큰 수, 월 호출 건수, 캐시 적중률 네 항목만 있으면 된다. 단가가 바뀔 때마다 셀 하나만 고치면 영향이 보인다.

2. 비용 때문에 걸어둔 제한을 목록화한다. 컨텍스트 상한선, 모델 강제 라우팅, 호출 빈도 제한 등 "비용 때문에"라고 주석이 달린 코드를 찾아서 리스트로 뽑는다. 단가 인하 이후에도 그 제한이 여전히 타당한지 하나씩 확인한다.

3. 모델 티어링이 있다면 오류율까지 같이 측정한다. 단가 절감액만 보지 말고, 하위 모델의 오류율 차이가 절감액을 얼마나 먹는지 계산한다. 단가 격차가 좁아질수록 이 계산의 결론이 바뀐다.

4. 품질 측정 없이 모델을 바꾸지 않는다. 단가가 내려갔다고 무조건 비싼 모델로 올리거나, 비싸다고 무조건 내리는 것 모두 데이터 없이 하는 결정이다. 변경 전후 정확도와 오류 비용을 비교하는 A/B 기준을 먼저 만든다.

5. 검토 주기를 캘린더에 박아 둔다. "나중에 해야지"는 결국 가격표가 두세 차례 더 바뀐 뒤에도 예전 설계 그대로 돌아가는 상태가 된다. 분기 1회, 30분이면 충분하다. 단가 변동 확인 → 계산식 업데이트 → 제한 목록 재검토 순서로 루틴화한다.

단가 인하는 비용 절감 뉴스가 아니라 설계 재검토 신호다. 받아들이는 방식에 따라 품질 개선 기회가 되기도 하고, 낡은 로직을 계속 유지하는 이유가 되기도 한다.