모델 라우팅 비용 계산법: 토큰 단가 대신 완료 작업당 비용으로 LLM 고르기

LLM 비용을 줄이겠다고 토큰 단가표만 비교하면 실제 운영비가 빗나간다. 같은 입력 1,000토큰이라도 모델마다 재시도율, 도구 호출 수, 답변 길이, 검증 필요 여부가 다르다. 싸게 보이는 모델이 세 번 실패하면 비싼 모델 한 번보다 더 비싸다. 반대로 고급 모델을 모든 요청에 쓰면 쉬운 분류, 라우팅, 포맷 변환까지 과하게 지불하게 된다. 이제 실무 기준은 “토큰당 가격”보다 “완료된 작업 하나당 비용”이어야 한다.

최근 모델 업데이트 흐름도 이 방향을 강화한다. 고속 모드, 저비용 소형 모델, 프런티어 모델, 캐시 가격 인하, 의사결정 전용 모델이 동시에 나오고 있다. 선택지가 늘어난 만큼 기본 모델 하나를 정해 끝내기 어렵다. 제품팀은 요청을 난이도별로 나누고, 실패했을 때만 상위 모델로 올리는 라우팅 구조를 만들어야 한다.

왜 토큰 단가만 보면 틀리나

예를 들어 고객 문의 분류 기능을 생각해 보자. 모델 A는 100만 입력 토큰당 1달러이고 정확도 92%다. 모델 B는 3달러지만 정확도 98%다. 단가만 보면 A가 3배 싸다. 하지만 오분류된 8%를 사람이 다시 처리해야 하고, 일부는 고객에게 잘못된 답변을 보낸다면 비용 계산이 달라진다. 사람 검수 비용, SLA 위반, 재처리 호출까지 넣으면 B가 더 싸질 수 있다.

코딩 에이전트도 마찬가지다. 빠른 모델이 패치를 만들었지만 테스트를 자주 깨면, CI 비용과 리뷰 시간이 늘어난다. 고급 모델이 한 번에 통과율을 높이면 토큰비는 비싸도 완료 작업당 총비용은 낮아진다. 그래서 모델 평가표에는 토큰 가격 옆에 성공률, 평균 재시도 수, 사람이 수정한 비율, 작업 소요 시간을 반드시 넣어야 한다.

완료 작업당 비용 공식

가장 단순한 공식은 다음과 같다. 완료 작업당 비용 = 모델 호출 비용 + 도구 실행 비용 + 재시도 비용 + 사람 검수 비용 + 실패 후 복구 비용. 여기서 모델 호출 비용은 입력 토큰, 출력 토큰, 캐시 읽기·쓰기, 배치 할인 여부를 포함한다. 도구 실행 비용은 검색 API, 코드 실행 샌드박스, 벡터DB 조회, 이미지 생성 같은 외부 리소스 비용이다.

재시도 비용은 생각보다 크다. 실패한 요청을 같은 모델에 다시 보내는지, 상위 모델로 승격하는지에 따라 달라진다. 사람 검수 비용은 분당 비용으로 환산하면 된다. 예를 들어 리뷰어가 시간당 6만원이고 요청 하나를 평균 2분 검수한다면 건당 2,000원이다. 모델 비용이 몇십 원이어도 사람 검수가 붙는 순간 의사결정 기준이 바뀐다.

라우팅 구조의 기본 패턴

첫 번째 패턴은 난이도 선분류다. 요청이 단순 분류, 정형 요약, 정책 판단, 코드 수정, 장문 추론 중 어디에 속하는지 작은 모델이나 규칙으로 먼저 판단한다. 쉬운 요청은 저비용 모델로 보내고, 위험도가 높은 요청만 상위 모델로 보낸다. 여기서 중요한 것은 선분류 모델의 오판 비용이다. 어려운 요청을 쉬운 요청으로 잘못 분류하면 품질 사고가 난다. 따라서 위험도가 애매하면 상위 모델로 보내는 보수적 기준이 필요하다.

두 번째 패턴은 단계적 승격이다. 처음에는 저비용 모델로 처리하고, 검증 규칙을 통과하지 못하면 더 강한 모델로 다시 처리한다. 예를 들어 JSON 스키마가 깨지거나, 근거 문서 ID가 없거나, 테스트가 실패하거나, 정책 금지어가 발견되면 승격한다. 이 방식은 전체 평균 비용을 낮추지만 지연시간이 늘 수 있다. 사용자 대면 기능에서는 p95 지연시간을 따로 측정해야 한다.

세 번째 패턴은 역할별 모델 분리다. 생성 모델, 검증 모델, 라우팅 모델을 다르게 둔다. 생성은 창의성과 추론이 좋은 모델을 쓰고, 검증은 작고 빠른 모델 또는 규칙 기반 검사로 처리한다. 모든 단계를 하나의 큰 모델에 맡기면 구현은 쉽지만 비용과 추적성이 나빠진다.

평가셋을 만드는 방법

라우팅은 감으로 만들면 실패한다. 먼저 실제 로그에서 요청 200~500개를 뽑아 난이도와 정답을 붙인다. 고객 문의라면 올바른 카테고리, 필요한 정책 링크, 최종 답변의 허용 범위를 정한다. 코드 작업이라면 테스트 통과 여부, 수정 파일 수, 리뷰어 수정량을 기록한다. 문서 요약이라면 누락하면 안 되는 조항과 잘못 쓰면 안 되는 표현을 표시한다.

그다음 후보 모델을 같은 평가셋에 돌린다. 단순 정확도뿐 아니라 실패 유형을 나눈다. 형식 오류, 근거 오류, 과잉 답변, 보안 정책 위반, 지연시간 초과, 도구 호출 실패를 분리해야 라우팅 조건을 만들 수 있다. “모델 A는 싸지만 형식 오류가 많다”면 JSON 복구 단계를 붙이면 된다. “모델 B는 근거 오류가 많다”면 검색 증강을 강화하거나 사용 범위를 줄여야 한다.

운영 중 봐야 할 지표

배포 후에는 요청당 평균 비용만 보면 안 된다. 난이도 구간별 비용, 승격률, 재시도율, 캐시 적중률, 검수 전환율, 사용자 재질문률을 같이 봐야 한다. 특히 승격률이 계속 오르면 두 가지 가능성이 있다. 첫째, 들어오는 요청이 어려워졌다. 둘째, 1차 모델이나 프롬프트가 퇴화했다. 원인을 구분하지 못하면 무조건 상위 모델을 늘려 비용만 오른다.

캐시도 중요하다. 같은 시스템 프롬프트, 같은 도구 설명, 같은 정책 문서를 반복해서 보내는 제품은 프롬프트 캐시를 적극적으로 써야 한다. 다만 캐시 키가 자주 바뀌면 적중률이 낮다. 정책 문서 버전, 도구 스키마 버전, 시스템 프롬프트 버전을 분리해서 변경 범위를 줄이는 것이 좋다.

마지막으로 예산 한도를 코드에 넣어야 한다. 라우터가 잘못 설정되면 하루 만에 모든 요청이 상위 모델로 승격될 수 있다. 워크스페이스, 고객, 기능 단위로 일일 최대 비용을 두고, 한도를 넘으면 저위험 기능은 축소 모드로 전환한다. 비용 제어는 재무팀 보고용이 아니라 장애 대응 장치다.

실행 체크리스트

• 모델 선택 기준을 토큰 단가가 아니라 완료 작업당 총비용으로 바꾼다.
• 실제 요청 200~500개로 평가셋을 만들고 난이도 라벨을 붙인다.
• 쉬운 요청, 위험 요청, 장문 추론, 코드 작업을 분리해 라우팅한다.
• 실패 시 같은 모델 재시도와 상위 모델 승격 기준을 명확히 둔다.
• 비용 대시보드에 승격률, 재시도율, 사람 검수율, 캐시 적중률을 포함한다.
• p95 지연시간을 비용과 함께 보고 사용자 대면 기능은 단계적 승격을 제한한다.
• 월 1회 이상 실제 로그로 라우팅 기준을 다시 조정한다.