LLM API 비용 줄이기 — 10만 건 분류에 $125 쓴 3단 라우팅

LLM으로 분류하는 시스템의 API 비용이 처리량에 비례해서 무섭다면, 더 싼 모델을 찾기 전에 호출을 나눌 곳부터 찾는 게 맞습니다.

제 시스템은 공시와 뉴스 104,659건을 다섯 달 동안 분류하면서 API에 $125.66을 썼습니다. 전부 상용 API로 보냈다면 $786이었을 겁니다.

차이를 만든 것은 더 싼 모델이나 프롬프트 압축이 아니었어요.

호출을 하지 않는 것입니다.

규칙이 먼저 거르고, 남은 것만 로컬 모델이 보고, 그래도 확신이 안 서는 것만 API로 보냅니다.

전체의 84%가 돈을 쓰지 않고 처리됐습니다.

아래는 이 3단 라우팅의 구조, 어떤 항목을 규칙으로 내려도 되는지 정하는 기준, 배포 전후의 숫자, 넉 달 뒤에 찾은 새는 곳, 그리고 규칙이 공짜가 아닌 이유입니다.

3단 라우팅

한국 시장에는 하루에 공시가 수백 건에서 천 건 넘게 올라옵니다. 이 중 주가에 의미가 있는 것은 극소수이고 나머지는 법이 내라고 해서 내는 행정 문서인데, 읽기 전에는 어느 쪽인지 모릅니다. 그래서 처음엔 전부 LLM에 넣었고, 도입 나흘째인 3월 30일에 하루 2,024건에 $6.76이 나왔습니다. 하루 만 원이면 감당 못 할 금액은 아니지만 이 곡선은 오른쪽으로 갈수록 가팔라집니다. 수집 소스를 늘릴수록, 시장이 바쁠수록 비용이 따라 올라가고, 개인이 혼자 굴리는 시스템에서 비용이 트래픽에 비례하면 확장을 스스로 막게 됩니다. 그날 구조를 바꿨습니다.

API 호출 1건당 평균 $0.00751이니, 10만 건 전부를 3단으로 보냈다면 $786입니다.

1단과 2단은 성격이 다릅니다.

2단(로컬 모델)은 하드웨어를 이미 샀기 때문에 공짜입니다. 다만 한계비용이 0에 가까울 뿐 전기와 시간은 쓰고 처리량 한계도 있습니다.

1단(규칙)은 일 자체를 하지 않습니다. 정규식 한 번이면 끝나고 밀리초 단위이며 처리량 한계가 사실상 없습니다.

그래서 어떤 항목을 1단으로 내릴 수 있으면 그건 언제나 이깁니다.

어떤 항목을 규칙으로 내려도 되나?

문제는 “규칙으로 내려도 되는가”를 어떻게 판단하느냐입니다.

제가 세운 기준은 문서 종류가 아니라 판단의 종류였습니다.

“이 서식은 안 중요하다”로는 부족합니다. “이 서식에서 중요한 경우는 텍스트에 반드시 특정 표현이 나타난다” 여야 규칙으로 내릴 수 있습니다.

정기보고서 규칙이 그렇게 생겼습니다.

// 정기보고서 (감사/사업/반기/분기보고서)
if (/감사보고서|사업보고서|반기보고서|분기보고서/.test(title)) {
  // 감사의견에 이상이 있으면 규칙을 포기하고 LLM으로 넘긴다
  if (/의견거절|한정의견|부적정의견|감사의견 거절|한정 의견/.test(text)) {
    return null;          // ← 탈출구
  }
  return { eventTags: ['정기보고서'], confidence: 0.1, ... };  // LLM 스킵
}

return null 한 줄이 이 설계의 전부입니다.

정기보고서는 대부분 아무 일도 아닙니다. 그런데 감사의견 거절이 붙은 정기보고서는 그 회사에서 그 해에 벌어질 수 있는 가장 큰 사건입니다.

규칙이 그것까지 삼켜버리면 비용을 아끼는 대신 시스템의 존재 이유를 버리는 겁니다.

그래서 규칙은 “이 서식은 건너뛴다”로 쓰지 않습니다. “이 서식은, 중요해지는 조건이 없을 때만 건너뛴다” 로 씁니다.

조건은 규칙보다 훨씬 좁고 명시적이어야 하고, 못 쓰겠으면 그 서식은 규칙 대상에서 뺍니다.

같은 양인데 왜 비용이 1/7 이 됐나?

배포 전후 일주일의 숫자입니다. 처리량은 그대로인데 비용이 7분의 1로 떨어졌습니다.

처리량은 그대로입니다. 2,024건에서 1,860건.

그런데 비용은 $6.76에서 $0.97로 떨어졌습니다.

줄인 것은 일의 양이 아니고 비싼 경로로 흘러간 비율입니다. API로 간 건수가 1,874에서 140으로 줄었습니다.

비용을 토큰 단위로 보면 최적화할 게 별로 없어요. 프롬프트를 30% 줄여봐야 30%입니다.

호출 여부 단위로 보면 자릿수가 바뀝니다.

넉 달 뒤에 어디가 새고 있었나?

규칙은 제가 아는 서식에만 붙습니다. 모르는 서식은 계속 2단과 3단으로 흘러갑니다.

그래서 정기적으로 비용을 서식별로 귀속시켜 봅니다.

“얼마 썼나” 대신 “무엇에 썼나”를 묻는 것입니다.

8월에 이 쿼리를 돌렸더니 두 서식이 위에 올라와 있었습니다.

SELECT si.title, COUNT(*), SUM(lr.cost_estimate_usd)
FROM llm_run lr JOIN source_item si ON si.id = lr.source_item_id
WHERE lr.model LIKE 'claude%'
GROUP BY 1 ORDER BY 3 DESC;

$12.78, 누적 분류비용의 10.2%를 이 두 서식이 쓰고 있었습니다.

하도급법상 대금 결제조건 공시와 공정거래법상 대규모내부거래 의결 공시인데, 둘 다 주가와 아무 관계가 없습니다.

더 나쁜 건 이 1,888건 중 97.1%가 3단(상용 API)까지 올라갔다는 것입니다.

가장 지루한 문서가 가장 비싼 경로로 갔습니다.

로컬 모델은 판단이 어려울 때 낮은 confidence를 냅니다. 그런데 정형 행정 문서는 “주가 영향이 없다”가 명백한 것과 다릅니다. 판단할 내용 자체가 없습니다.

모델 입장에서 확신할 근거가 없으니 낮은 점수가 나오고, 그러면 자동으로 비싼 경로로 승격됩니다.

confidence 기반 라우팅은 “어려운 것”과 “내용이 없는 것”을 구분하지 못합니다. 후자는 규칙으로 잡아야 하는 것들입니다.

규칙 2개를 추가해 8월 12일 저녁에 배포했는데, 첫 번째 서식은 반기 종료 후 45일이 마감이라 그해 마감일이 8월 14일이었습니다. 마감일에 850건이 한꺼번에 들어왔고, 배포 전 단가($0.00677/건)로 환산하면 그 하루에만 $5.75로 제 운영 비용 상한 일 $3의 두 배에 가깝습니다. 이틀 차이로 피했습니다. 자랑할 일은 아니고 운이 좋았다고 쓰는 게 맞습니다. 8월 12일에 비용 귀속 쿼리를 돌린 건 계획된 점검이 아니었고, 다른 걸 보다가 눈에 걸린 것이었습니다. 효과를 얼마로 적을지는 단순한 전후 비교 대신 반사실로 셌고, 그 계산은 부록에 있습니다.

규칙은 공짜인가?

규칙 기반 선처리에는 대가가 있습니다.

셋입니다.

정규식은 부서집니다. 공시 서식명이 바뀌면 규칙이 빗나가고, 그 결과는 오류로 나타나지 않고 비용 증가로만 나타납니다. 침묵하는 실패입니다.

오탐은 되돌릴 수 없습니다. 규칙이 잘못 잡으면 그 문서는 LLM을 아예 안 거치고, 놓친 신호는 나중에 세어볼 수도 없습니다. 그래서 규칙을 추가할 때는 배포 전에 누적 수집분 전체 제목과 대조해서 의도한 것만 매칭되는지 확인합니다. 이번 2건은 18만 건 넘는 수집 이력에 정규식을 돌려 매칭된 제목이 의도한 6개 변형뿐임을 확인하고 넣었습니다.

탈출구는 아직 시험받지 않았습니다. 앞서 자랑한 의견거절 탈출구는 규칙 도입 이후 지금까지 사실상 발동한 적이 없습니다. 감사의견 거절은 3월 결산 시즌에 몰리는데, 규칙을 3월 30일에 넣었기 때문입니다. 이 안전장치의 진짜 시험은 2027년 3월이고, 그때까지는 “작동할 것으로 설계했다”까지만 쓸 수 있습니다.

자주 묻는 질문

로컬 모델 없이 규칙만으로도 되나요

1단만으로 59.3%가 처리되니 그것만으로도 큰 절감입니다. 다만 규칙에 안 걸리는 나머지가 전부 유료 경로로 갑니다. 2단은 그 중간을 받는 자리예요.

confidence 임계값은 어떻게 정했나요

이 글에서는 값을 적지 않습니다. 임계값 자체가 공개 경계 밖입니다. 중요한 건 값이 아닌 confidence 기반 라우팅이 “어려운 것”과 “내용이 없는 것”을 구분하지 못한다는 구조입니다.

서식별 비용 귀속은 얼마나 자주 보나요

정해진 주기가 없습니다. 8월 12일에 돌린 것도 계획된 점검이 아니었고 다른 걸 보다가 눈에 걸린 것이었어요. 이틀 뒤가 마감일이라 운이 좋았습니다. 주기를 정해 두는 편이 맞습니다.

규칙이 잘못 잡은 걸 나중에 알 수 있나요

없습니다. 규칙이 잡으면 그 문서는 LLM 을 아예 안 거치고, 놓친 신호는 나중에 세어볼 수도 없어요. 그래서 배포 전에 누적 수집분 전체 제목과 대조합니다.

참고 자료

• 공정거래위원회 — 하도급대금 결제조건 공시 는 비용을 가장 많이 쓰고 있던 서식 하나가 무엇인지의 근거입니다.

남는 것

건당 비용은 도입 초기 $0.00370에서 지금 $0.00141까지 내려왔습니다. 62% 감소인데 이 숫자는 사실 별로 중요하지 않고, 중요한 건 비용이 유입량에 대해 거의 평평해졌다는 것입니다. 8월 14일에 850건이 한꺼번에 와도 $0이 나오고, 이제 소스를 늘리는 결정이 비용 걱정 없이 가능합니다.

모델을 바꾸기 전에 경로를 나누세요. 더 싼 모델을 찾는 건 상수배 개선이고, 호출을 없애는 건 자릿수 개선입니다. 그리고 대부분의 실무 데이터에는 “LLM이 필요 없는 게 명백한” 다수가 있습니다.

비용은 총액이 아니라 귀속으로 보세요. “이번 달 $17 썼다”는 아무 행동도 유발하지 않습니다. “이 서식 하나가 $12.78 썼다”는 즉시 코드 한 줄로 이어집니다. 같은 데이터인데 집계 축만 다릅니다.

아끼는 쪽으로 기울 때 무엇을 놓치는지 명시적으로 적어두세요. 규칙은 본질적으로 “안 읽고 결정하는 것”입니다. 그 판단이 언제 틀리는지 조건을 코드에 적어둘 수 없다면, 그 항목은 아직 규칙으로 내릴 준비가 안 된 겁니다.

부록 1: 효과를 얼마로 적을 것인가

가장 쉬운 방법은 배포 전후 일평균 비용을 비교하는 것입니다.

배포 전 (8/3~8/12 평일)   $1.574 / 일
배포 후 (8/13~8/21 평일)  $0.685 / 일     → −56.5%

이 숫자를 그대로 쓰면 안 됩니다. 같은 시기에 하도급 공시 러시가 끝났기 때문입니다. 마감이 지나면 그 서식은 어차피 사라지므로 이 −56.5%에는 규칙의 효과와 계절성의 종료가 섞여 있습니다. 그래서 반사실(counterfactual)로 다시 셌습니다. 배포 후 규칙이 흡수한 건수 × 배포 전 실측 단가입니다.

1,455건 × $0.00677 = $9.85   (7 영업일)  →  $1.41 / 일

이 값이 관측된 감소분($0.89/일)보다 큽니다. 규칙이 없었다면 배포 후 비용은 $0.685 + $1.41 = $2.09/일이었을 것이고, 이는 배포 전 $1.574/일보다 높습니다. 순진한 전후 비교는 효과를 과대평가하지 않았습니다. 과소평가하고 있었습니다. 마감이 다가오면서 유입량이 늘고 있었기 때문이고, 아래 표가 그 유입입니다. 제 직관은 반대였습니다. 계절성이 효과를 부풀렸을 거라고 예상하고 확인하러 갔다가 부호가 반대인 걸 봤습니다. 전후 비교가 위험한 건 어느 쪽으로 틀렸는지 알 수 없기 때문입니다.

부록 2: 도입 전 사흘

3/26   69건   $0.33
3/27  917건   $5.92
3/30  2,024건 $6.76   ← 하루 만원

이 사이트의 수치는 주 1회 DB와 다시 대조하고, 판단이 바뀌면 지우지 않고 글 안에 덧붙입니다. 갱신은 RSS로 받을 수 있습니다.