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

올해 들어 주요 LLM 제공사의 토큰 가격이 여러 차례 인하됐다. 처음에는 뉴스로 보고 “좋은 소식이네” 하고 넘겼는데, 어느 시점부터는 우리가 짜둔 비용 계산식 자체를 다시 짜야 하는 상황이 생겼다.

비용 계산식을 짜둔 이유

LLM 을 서비스에 붙일 때 항상 고민하는 것이 “호출 당 비용이 얼마인가”다. 프롬프트 길이, 출력 길이, 캐싱 여부를 조합하면 단건 비용을 추정할 수 있고, 예상 호출 수를 곱하면 월 예산이 나온다.

우리는 이 계산식을 스프레드시트로 관리하고 있었다. 서비스별로 평균 입력/출력 토큰 수를 측정하고, 현재 단가를 곱해서 월별 비용을 시뮬레이션하는 방식이었다.

단가 인하가 설계를 바꾼 지점

문제는 단가가 내려가면서 “비용 때문에 제한했던 것”을 다시 검토해야 했다는 점이다. 예를 들어 컨텍스트 길이를 제한하거나, 특정 기능에서 더 저렴한 모델로 강제 라우팅하던 로직이 있었다. 단가가 낮아지면 이 로직이 오히려 품질을 희생하는 쪽이 된다.

# 기존: 비용 제한으로 짧은 컨텍스트 강제
max_tokens = 2000  # 비용 절감 목적

# 개정: 단가 인하 후 품질 우선
max_tokens = 8000  # 비용 증가분이 허용 범위 내

또 하나는 ‘모델 티어링’ 기준이다. 이전에는 “간단한 요청은 저렴한 모델, 복잡한 요청은 비싼 모델”이라는 규칙을 명시적으로 코드에 넣었다. 단가 격차가 줄어드니 이 분기가 설계를 복잡하게 만드는 비용 대비 이점이 줄었다.

지금 우리의 접근

가격 변동에 흔들리지 않으려면 비용보다 ‘품질 대비 비용’ 기준으로 생각해야 한다는 걸 이번에 다시 확인했다. 단가가 낮아졌다고 해서 무작정 더 비싼 모델을 쓰는 것도 아니고, 비싸다고 무조건 줄이는 것도 아니다.

우리가 지금 쓰는 원칙은 단순하다: 실제 응답 품질을 측정하고, 그것이 기준에 못 미치면 더 좋은 모델을 쓰고, 충분하면 더 저렴한 쪽을 유지한다. 가격표가 바뀔 때마다 이 측정값을 다시 확인하는 주기를 분기에 한 번으로 잡고 있다.

— by slecs