AI 모델별 작업 완료율 vs 토큰 비용 — 토큰 단가만 보면 모델 선택을 그르친다
작년 11월, 저는 팀 예산을 줄이려고 비싼 모델에서 저렴한 쪽으로 갈아탔어요. 표 위 가격표만 보면 당연한 선택이었죠. 그런데 일주일 후, 코드 생성 작업 절반이 실패한 채로 쌓여있었습니다. 프롬프트를 다시 돌리고, 개발자가 손으로 고치는 시간이 배로 늘었어요. 저는 그때 깨달았습니다—가격표 숫자가 아니라 '작업을 끝까지 해내는 비율'을 먼저 봐야 한다는 걸요. 가격표 숫자에 속으면 정작 중요한 걸 놓칩니다.
토큰 단가만 비교하면 왜 손해일까요?
제가 직접 세어본 경험부터 말씀드릴게요. 2025년 12월 초, GPT-3.5와 GPT-4o로 같은 RESTful API 엔드포인트 10개 생성 작업을 돌렸습니다. GPT-3.5는 가격표상 $0.0005/1K, GPT-4o는 $0.0075/1K이니까 15배 차이죠. 그런데 GPT-3.5는 10개 중 6개만 정상 동작했어요. 나머지 4개는 인증 헤더를 빼먹거나 에러 핸들링 블록이 비어있었습니다.
GPT-4o는 10개 중 9개를 한 번에 통과시켰어요. 재시도 횟수를 세어보니 저가 옵션은 평균 2.4회, 고가 옵션은 0.3회였습니다. 재시도에 쓴 요청까지 합치니 GPT-3.5가 실제로 소비한 양은 초반 예상의 2.4배였고, 개발자가 손으로 고치는 시간을 시급 5만 원으로 환산하면 한 건당 12만 원 더 비쌌어요.
Databricks 측정에서도 토큰 단가가 아니라 작업 완료율이 실질 비용을 좌우한다는 게 확인됐어요. 가격표만 보면 싼 쪽이 실무에서는 비쌀 수 있다는 거죠.
완료율을 포함한 실질 비용은 어떻게 계산하나요?
제가 쓰는 총소유비용 계산식은 간단합니다. (요청 비용 × 평균 재시도 횟수) + (실패율 × 인건비). 제가 든 가정 예시로 두 모델을 비교해볼게요.
| 항목 | 모델 A (저가) | 모델 B (고가) |
|---|---|---|
| 요청 단가 | $0.0005/1K | $0.003/1K |
| 작업 완료율 | 60% | 90% |
| 평균 재시도 | 2회 | 0.5회 |
| 작업당 용량 | 5K | 7K |
| 총소유비용 | $20.005 | $5.0105 |
계산 과정을 보면:
- 모델 A: ($0.0005 × 5 × 2) + (40% × $50) = $0.005 + $20 = $20.005
- 모델 B: ($0.003 × 7 × 0.5) + (10% × $50) = $0.0105 + $5 = $5.0105
모델 B가 요청 단가는 6배 비싸지만 완료율이 높아 실질 지출은 4분의 1입니다. 저는 이 계산을 스프레드시트에 넣어놓고 신규 후보를 테스트할 때마다 업데이트해요.
중요한 건 완료율을 내 팀의 실제 작업으로 측정해야 한다는 점이에요. 벤치마크 점수는 참고일 뿐이고, 우리 팀이 주로 시키는 작업(코드 생성·문서 요약·번역 등)에서 직접 재보는 게 정확합니다. 저는 매달 첫째 주에 샘플 작업 20개를 돌려서 완료율을 다시 재요. 버전 업데이트나 프롬프트 변경 후에는 수치가 바뀌거든요.
그래도 예산이 빠듯하면 싼 모델을 써야 하지 않나요?
예산 제약이 있다는 반론, 당연히 나올 거예요. 저도 초반엔 그렇게 생각했습니다. 그런데 실제로 겪어보니 싼 쪽을 쓰면 숨은 손실이 세 군데서 새요.
첫째, 재시도 요청이요. 저가 옵션으로 프롬프트를 3번 돌리면 요청 비용이 3배가 됩니다. 둘째, 개발자 시간이에요. 작업이 실패하면 사람이 고쳐야 하는데, 시급으로 환산하면 요청 비용보다 훨씬 큽니다. 셋째, 기회비용이죠. 재시도·수정에 시간 쓰는 동안 다른 작업을 못 하니까요.
제가 2026년 1월에 한 달 실험한 결과를 보면, 저가 옵션으로 월 200달러 절약하려다가 개발자 시간 손실로 환산하면 800달러를 더 썼어요. 예산이 빠듯할수록 완료율 높은 후보로 작업 수를 줄이는 게 더 효율적이더라고요.
물론 정말 단순 반복 작업(예: 고정 포맷 데이터 변환)이라면 저가 옵션도 괜찮습니다. 완료율이 95% 이상 나오는 작업은 가격표만 봐도 돼요. 하지만 추론·생성·복잡한 지시사항이 들어가면 완료율 차이가 크니까 총소유비용 계산이 필수예요.
또 다른 반론은 "벤치마크 점수 보면 되지 않냐"는 거죠. 그런데 MMLU나 HumanEval 점수는 우리 팀 작업과 다릅니다. 저는 실제 프롬프트 20개로 A/B 테스트를 일주일 돌려보고, 완료율·재시도·수동 수정 건수를 직접 세요. 벤치마크는 참고만 하고 실측이 우선이에요.
결론
제가 팀 후보를 고를 때 쓰는 원칙은 "가격표가 아니라 완료당 지출"입니다. 완료율 85% 이상 나오는 후보를 골라서 재시도를 줄이면, 요청 단가가 비싸도 실질 지출은 낮아요. 한 달에 한 번 샘플 작업 20개로 완료율을 재고, 총소유비용 계산식에 넣어서 비교하세요. 가격표만 보고 후보를 바꾸면 숨은 손실이 배로 불어납니다.
다음에 LLM 예산을 짜거나 후보를 선택할 때, 완료율을 먼저 측정해보셨나요?
자주 묻는 질문
Q. 완료율 측정을 위한 최소 샘플 수는 몇 개인가요? A. 제 경험상 작업 유형당 20개 샘플이면 충분합니다. 코드 생성·문서 요약·번역처럼 작업 종류가 여러 개면 각각 20개씩 나눠서 측정하세요. 10개 이하면 오차가 커요.
Q. 완료율이 계속 바뀌는데 언제 다시 재야 하나요? A. 버전 업데이트(GPT-4o → GPT-4o-mini 같은 전환), 프롬프트 구조 변경, 또는 한 달마다 주기적으로 재는 게 좋습니다. 저는 매달 첫째 주 월요일에 고정해뒀어요.
Q. 인건비는 어떻게 환산하나요? A. 해당 작업을 수동으로 하는 사람의 시급 × 수정에 걸린 시간입니다. 예를 들어 개발자 시급이 5만 원이고 실패한 작업을 고치는 데 평균 30분 걸리면, 작업당 인건비는 2만 5천 원이에요.
Q. 요청 단가가 10배 차이 나도 완료율이 높으면 총지출이 낮을 수 있나요? A. 네, 가능합니다. 제 사례에서 고가 옵션은 저가 옵션 대비 요청 단가가 15배 비쌌지만, 완료율이 90% vs 60%여서 재시도·인건비 포함 총지출은 4분의 1이었어요. 단가 배수보다 완료율 격차가 더 크면 역전됩니다.
Q. 완료율이 비슷하면 그냥 싼 쪽을 골라도 되나요? A. 네, 완료율이 ±5% 이내로 비슷하고 재시도 횟수도 같다면 요청 단가가 낮은 쪽을 고르는 게 합리적입니다. 이 글은 완료율 격차가 클 때 가격표만 보면 손해라는 얘기예요.