모델 단가표는 분기마다 내려가는데, 정작 매달 결제되는 금액은 그대로이거나 오히려 늘어난 회사가 많습니다. 숫자가 틀린 게 아니라 세는 단위가 틀린 경우입니다.
이 글에서 확인할 것
- 지금 API 단가에서 실제로 벌어지고 있는 일
- 단가가 내려도 청구서가 안 줄어드는 세 가지 구조
- ‘토큰 단가’가 아니라 ‘업무 1건 원가’로 다시 세는 표
단가 경쟁이 어디까지 왔나
2026년 들어 API 가격 경쟁은 성능 경쟁만큼이나 빠르게 진행됐습니다. 저가 모델들이 입력·출력 토큰 단가를 대폭 낮추면서 같은 작업을 예전의 몇 분의 일 비용으로 돌리는 사례가 흔해졌고, 플랫폼 전체 토큰 사용량에서 저가 모델이 차지하는 비중도 크게 늘었습니다.
현장에서 자리 잡은 결론은 “가장 싼 모델 하나로 통일”이 아닙니다. 난도가 높은 작업은 성능이 검증된 모델에, 분류·요약·추출처럼 정형화된 작업은 저렴한 모델에 나눠 보내는 혼합 배치가 표준에 가까워졌습니다. 그래서 단가표 한 줄만 보고 도입 여부를 결정하면 판단이 어긋납니다.
단가가 내려도 비용이 안 줄어드는 세 가지 구조
1. 같은 질문을 여러 번 보냅니다
결과가 마음에 들지 않으면 다시 호출합니다. 사람이 누르는 재시도, 코드가 자동으로 도는 재시도, 실패 후 폴백까지 합치면 한 건을 처리하는 데 호출이 두세 번 들어가는 일이 흔합니다. 단가가 절반이 돼도 호출이 세 배면 비용은 늘어납니다.
2. 문맥이 계속 길어집니다
대화형으로 쓰면 이전 내용이 매번 함께 전송됩니다. 문서를 통째로 붙이는 방식이라면 실제로 필요한 두 문단 때문에 수십 페이지 분량을 매 호출마다 다시 보내게 됩니다. 입력 토큰은 조용히 늘어나는 항목이라 청구서를 열기 전까지 잘 드러나지 않습니다.
3. 사람 손이 그대로 남습니다
가장 큰 비용은 대개 API 요금이 아니라 검수 인건비입니다. 결과를 사람이 다시 읽고 고쳐야 한다면 절감된 것은 작성 시간뿐이고, 확인 시간은 그대로입니다. 도입 효과를 볼 때 이 항목을 빼고 계산하면 실제보다 훨씬 좋아 보입니다.
‘업무 1건 원가’로 다시 세는 표
여기서부터가 실제로 필요한 부분입니다. 백만 토큰당 단가는 협상용 숫자일 뿐이고, 결재를 올릴 때 쓰이는 숫자는 업무 한 건당 원가입니다. 아래 항목을 한 줄로 채우면 도입 여부가 대체로 저절로 정해집니다.
| 항목 | 무엇을 적나 |
|---|---|
| 건당 호출 수 | 재시도·폴백 포함한 실제 평균 호출 횟수 |
| 건당 입력 토큰 | 붙이는 문서·이전 대화까지 포함한 평균 |
| 건당 출력 토큰 | 실제 저장되는 결과물 기준 |
| 검수 시간 | 사람이 읽고 고치는 데 걸리는 분 단위 시간 |
| 실패율 | 사람이 처음부터 다시 하는 비율 |
| 월 처리 건수 | 지난 3개월 실제 처리량 |
이 표를 채우면 대부분의 회사에서 두 가지가 드러납니다. 하나는 비용의 절반 이상이 토큰이 아니라 검수와 실패에서 나온다는 점이고, 다른 하나는 처리 건수가 많은 한두 개 업무가 전체 비용을 지배한다는 점입니다. 모델을 바꾸는 것보다 그 한두 개 업무의 입력을 다듬는 쪽이 훨씬 크게 줄어듭니다.
줄이는 방법도 순서가 있습니다. 첫째는 매번 똑같이 들어가는 지시문과 참고 자료를 분리해 재사용하는 것입니다. 같은 내용을 반복해서 보내지 않는 것만으로 입력 토큰이 눈에 띄게 줄어듭니다. 둘째는 문서 전체를 붙이는 대신 필요한 부분만 찾아 넣는 방식으로 바꾸는 것입니다. 셋째는 결과 형식을 미리 고정해 두는 것입니다. 형식이 정해져 있으면 사람이 다시 손볼 일이 줄고, 재시도 횟수도 함께 내려갑니다.
단가를 낮추는 협상보다, 건당 호출 수를 3회에서 1회로 줄이는 정리가 비용에 더 크게 작동합니다.
도입 전에 정해 둘 순서
먼저 대상 업무를 하나만 고릅니다. 여러 부서에 동시에 얹으면 어디서 비용이 나오는지 끝까지 알 수 없습니다. 처리 건수가 많고 결과 판정이 명확한 업무, 예를 들어 문의 분류나 서류 항목 추출부터 시작하는 편이 낫습니다.
두 번째로 데이터가 어디 있는지 확인합니다. 주문·재고·거래처 정보가 엑셀과 메신저에 흩어져 있으면 AI를 붙이기 전에 옮겨 담는 작업부터 필요합니다. 사내 시스템에 데이터를 모으는 작업이 선행되지 않으면, 모델이 아무리 좋아도 사람이 자료를 복사해 넣는 시간이 그대로 남습니다.
세 번째로 사용자가 결과를 만나는 화면을 정합니다. 내부 직원만 쓴다면 기존 업무 화면에 얹는 것으로 충분하고, 고객이 직접 쓰는 기능이라면 응답 지연과 실패 처리까지 설계해야 합니다. 고객 대상 기능을 앱 개발로 확장할 계획이라면 오프라인 상태와 타임아웃 문구를 처음부터 정해 두는 편이 낫습니다. 웹으로 먼저 검증한 뒤 사내 웹 서비스 개발 범위에서 화면을 붙이는 순서도 흔히 쓰입니다.
분기마다 다시 볼 항목
단가는 계속 바뀝니다. 그래서 도입 시점의 계산서를 그대로 두면 반년 뒤에는 의미가 없어집니다. 분기에 한 번, 위 표에서 ‘건당 호출 수’와 ‘검수 시간’ 두 칸만 다시 재는 것으로 충분합니다. 이 두 칸이 줄었다면 도입이 자리를 잡은 것이고, 그대로라면 모델이 아니라 업무 설계를 손볼 차례입니다.
가격이 내려간다는 소식은 반가운 신호지만, 그 자체로 비용을 줄여 주지는 않습니다. 줄어드는 것은 언제나 세어 본 항목뿐입니다.
