시리즈: 생성형 AI 플랫폼 비교 완전 가이드 (총 9편) | 7회
API 비교 — 토큰 단가를 넘어 TCO로 계산하는 법
Summary
- API 비용은 "토큰 단가"만으로 결정되지 않는다 — 캐싱, 배치, 검색비, 레이트리밋까지 합산해야 진짜 비용이 보인다
- 200K vs 1M 컨텍스트 구간에 따라 아키텍처 설계가 달라지고, 그에 따라 비용 구조도 완전히 바뀐다
- prompt caching, Batch API, 혼합 라우팅 같은 최적화 레버를 활용하면 같은 결과물을 절반 이하 비용으로 뽑을 수 있다
이 글의 대상
- AI API를 활용해 서비스나 자동화를 구축하려는 개발자
- 토큰 단가 비교표만 보고 API를 골랐다가 예상 밖의 청구서를 받은 분
- 팀이나 조직에서 AI API 도입 비용을 산정해야 하는 기술 관리자
목차
- 토큰 단가만 보면 안 되는 이유
- 플랫폼별 API 비용 구조 한눈에 보기
- 200K vs 1M — 컨텍스트 구간이 아키텍처를 결정한다
- 비용을 절반으로 줄이는 최적화 레버 4가지
- 레이트리밋 — 놓치기 쉬운 운영 비용
- TCO 계산 실전 체크리스트
1. 토큰 단가만 보면 안 되는 이유
여러분, API를 고를 때 "입력 토큰 얼마, 출력 토큰 얼마"부터 비교하시죠? 물론 토큰 단가는 중요한 시작점이에요. 하지만 실제로 청구서를 받아 보면, 토큰 단가는 전체 비용의 일부일 뿐이에요.
진짜 TCO(Total Cost of Ownership, 총 소유 비용)는 이렇게 구성돼요:
TCO = 토큰 단가 + 캐싱 비용/절감 + 배치 할인 + 검색/컨텍스트 부가비 + 레이트리밋으로 인한 대기 비용
예를 들어, Perplexity Sonar API는 토큰 단가만 보면 저렴해 보이지만 검색 컨텍스트 크기에 따라 request fee가 별도로 붙어요. 반대로 Anthropic의 prompt caching을 잘 활용하면 토큰 단가표보다 훨씬 적게 낼 수도 있어요.
결론은 간단해요. 토큰 단가는 "시작가"일 뿐, "최종가"가 아니에요.
2. 플랫폼별 API 비용 구조 한눈에 보기
2026년 2월 기준으로 주요 플랫폼의 API 과금 구조를 정리해 봤어요.
OpenAI
| 항목 | 내용 |
|---|---|
| 대표 모델 | GPT-5.2 |
| 입력 토큰 | $1.75 / 1M tokens |
| 출력 토큰 | $14 / 1M tokens |
| 과금 방식 | 모델별 토큰 단가 기본, Responses API도 동일 토큰 단가로 청구 |
| 배치 | Batch API 지원 (비동기 처리, 할인 적용) |
| 특이사항 | TPM/RPM 문서화가 잘 되어 있어 예측 가능 |
Responses API가 별도 과금이 아니라 모델 토큰 단가로 청구된다는 점, 의외로 모르시는 분들이 많아요. 별도 요금표를 찾을 필요 없어요.
Anthropic (Claude)
| 항목 | 내용 |
|---|---|
| Opus 4.6 | 입력 $5 / 출력 $25 (per 1M tokens) |
| Sonnet 4.5 | 입력 $3 / 출력 $15 (per 1M tokens) |
| Haiku 4.5 | 입력 $1 / 출력 $5 (per 1M tokens, 200K 이하 기준) |
| 과금 방식 | Standard / Priority / Batch 티어 구분 |
| 캐싱 | prompt caching으로 반복 프롬프트 비용 대폭 절감 |
| 특이사항 | 캐싱 활용 시 실질 비용이 표면 단가보다 크게 낮아질 수 있음 |
Anthropic의 강점은 prompt caching이에요. 시스템 프롬프트나 반복되는 컨텍스트를 캐싱하면, 해당 부분은 크게 할인된 단가가 적용돼요. 반복 호출이 많은 서비스라면 이게 TCO를 크게 좌우해요.
Google Gemini API
| 항목 | 내용 |
|---|---|
| 과금 구간 | 200K 이하 vs 200K 초과로 가격 차등 |
| 캐싱 | context caching 지원 |
| 배치 | Batch API 50% 할인 |
| 특이사항 | 컨텍스트 구간별 가격 차등이 핵심 — 200K 넘으면 단가 상승 |
Gemini의 Batch API 50% 할인은 대량 처리에서 매우 매력적이에요. 실시간 응답이 필요 없는 야간 배치 작업 같은 경우, Gemini Batch를 쓰면 비용이 확 줄어들어요.
Perplexity Sonar API
| 항목 | 내용 |
|---|---|
| 과금 구조 | 토큰 단가 + request fee (검색 컨텍스트 크기별) |
| request fee | 1K requests당 검색 깊이에 따라 비용 차등 |
| 토큰 분리 | citation tokens / reasoning tokens 별도 계산 |
| 특이사항 | 검색이 깊어질수록 비용 증가 — "검색 깊이 = 비용" |
Perplexity Sonar는 다른 API와 구조가 달라요. 단순 토큰 비용 외에 검색 컨텍스트에 따른 request fee가 붙어요. 출처 기반 답변이 필요한 서비스에는 강력하지만, 검색 깊이를 깊게 설정할수록 비용이 올라간다는 걸 꼭 계산에 넣어야 해요.
Azure OpenAI
| 항목 | 내용 |
|---|---|
| 과금 모드 | 온디맨드 / PTU(Provisioned Throughput) / 배치 |
| PTU | 처리량을 미리 확보 — 예측 가능한 비용과 일정한 응답 속도 |
| 특이사항 | 엔터프라이즈 환경에서 안정적인 처리량 보장이 필요할 때 유리 |
Azure의 PTU 모델은 "이만큼의 처리량을 미리 사 두겠다"는 개념이에요. 피크 시간대에도 속도가 흔들리지 않아야 하는 프로덕션 서비스라면, PTU가 결국 더 경제적일 수 있어요.
3. 200K vs 1M — 컨텍스트 구간이 아키텍처를 결정한다
API 비용을 계산하기 전에 먼저 결정해야 할 게 있어요. "내 작업이 200K 안에서 해결되는가, 아니면 1M이 필요한가?"
이 질문 하나가 아키텍처 전체를 바꿔요.
200K급 아키텍처
- 접근법: 문서 분할 + 요약 체인, 또는 RAG(검색 증강 생성)
- 비용 특성: 호출 횟수는 늘지만, 호출당 비용은 낮음
- 적합한 경우: 대부분의 일반적인 문서 처리, Q&A, 요약 작업
200K면 웬만한 작업은 충분해요. 문서가 길어도 잘 쪼개서 넣으면 되니까요. RAG 파이프라인을 구축하면 필요한 부분만 골라서 컨텍스트에 넣을 수 있어서 비용 효율이 좋아요.
1M급 아키텍처
- 접근법: 단일 패스(한 번에 모두 처리) 가능
- 비용 특성: 호출당 비용이 높고, 캐싱/압축/배치 없이는 비용과 지연이 급격히 악화
- 적합한 경우: 문서 간 교차 참조가 많은 법률 분석, 대규모 코드베이스 리뷰
1M 컨텍스트는 강력하지만, "쓸 수 있다"와 "효율적으로 쓸 수 있다"는 전혀 다른 문제예요. 캐싱이나 압축 전략 없이 매번 1M 가까이 넣으면, 비용도 지연도 감당하기 어려워질 수 있어요.
실전 팁: 처음에는 200K 아키텍처로 설계하고, 정말 단일 패스가 필요한 작업만 1M으로 분리하는 게 가장 현실적이에요.
4. 비용을 절반으로 줄이는 최적화 레버 4가지
같은 작업이라도 어떻게 호출하느냐에 따라 비용이 2배 이상 차이 나요.
레버 1: Prompt Caching (Anthropic)
시스템 프롬프트나 고정 컨텍스트를 캐싱하면 해당 부분의 토큰 비용이 크게 줄어들어요. 반복 호출이 많은 챗봇, 고객 응대 시스템에서 특히 효과적이에요.
레버 2: Context Caching (Google)
Google Gemini의 context caching도 비슷한 원리예요. 긴 문서를 캐싱해 두고 여러 질문을 던지는 패턴에서 위력을 발휘해요.
레버 3: Batch API
실시간 응답이 필요 없는 작업이라면 Batch API를 쓰세요. Google은 50% 할인, OpenAI도 배치 처리 시 할인이 적용돼요. 야간에 돌려도 되는 데이터 분석, 대량 번역 같은 작업에 딱이에요.
레버 4: 혼합 라우팅 (Model Routing)
이게 가장 실전적인 전략이에요.
- 1단계: 경량 모델(Haiku 4.5, GPT-4o-mini 등)로 초안 생성
- 2단계: 고성능 모델(Opus 4.6, GPT-5.2 등)로 검수/보완
모든 요청을 최상위 모델에 보내는 건 돈 낭비예요. 간단한 분류, 추출, 요약은 경량 모델로 처리하고, 판단이 필요한 단계만 고성능 모델을 쓰면 TCO가 극적으로 줄어들어요.
5. 레이트리밋 — 놓치기 쉬운 운영 비용
레이트리밋(Rate Limit)은 직접 돈이 나가는 건 아니지만, 간접적으로 비용을 크게 키우는 요소예요.
- TPM(Tokens Per Minute): 분당 처리 가능한 토큰 수
- RPM(Requests Per Minute): 분당 요청 횟수 제한
레이트리밋에 걸리면 요청이 큐에 쌓이고, 대기 시간이 늘어나고, 서비스 품질이 떨어져요. 이걸 해결하려고 더 높은 티어로 올리면 비용이 늘고, 재시도 로직을 짜면 개발 공수가 들어요.
| 플랫폼 | 레이트리밋 관리 |
|---|---|
| OpenAI | TPM/RPM이 문서에 잘 정리되어 있어 예측 가능 |
| Azure OpenAI | PTU로 처리량을 미리 확보 — 가장 예측 가능한 운영 |
| Anthropic | Standard/Priority/Batch 티어별 차등 |
| 구간별 차등, Batch API로 우회 가능 |
팁: 트래픽이 예측 가능한 서비스라면 Azure PTU를 진지하게 검토해 보세요. "분당 몇 건 처리"가 보장되니까 운영 리스크가 확 줄어들어요.
6. TCO 계산 실전 체크리스트
API를 고르기 전에 아래 항목을 먼저 채워 보세요:
- 월간 예상 토큰량: 입력/출력 각각 얼마나 쓸 것인가?
- 반복 패턴 유무: 고정 프롬프트가 있는가? → 캐싱 절감 가능
- 실시간 vs 배치: 즉시 응답이 필요한 비율은? → 배치 할인 적용 범위
- 컨텍스트 구간: 200K로 충분한가, 1M이 필요한가? → 아키텍처 결정
- 검색 부가비: 출처 기반 답변이 필요한가? → Perplexity Sonar 추가 비용
- 피크 트래픽: 동시 요청이 몰리는 시간대가 있는가? → 레이트리밋/PTU 검토
핵심 정리
1. API TCO = 토큰 단가 + 캐싱 + 배치 할인 + 검색/컨텍스트 부가비 + 레이트리밋 간접 비용
2. 200K vs 1M 컨텍스트 구간에 따라 아키텍처부터 다르게 설계해야 한다
3. prompt caching(Anthropic), context caching(Google), Batch API(Google 50% 할인)로 비용 절반 이하 가능
4. 혼합 라우팅(경량 모델 초안 → 고성능 모델 검수)이 가장 실전적인 비용 최적화 전략
5. 레이트리밋은 직접 비용은 아니지만 서비스 품질과 간접 비용에 큰 영향을 준다FAQ
Q1. 토큰이 정확히 뭔가요? 글자 수와 다른 건가요?
A. 토큰은 AI 모델이 텍스트를 처리하는 단위예요. 영어는 대략 단어 1개 = 1토큰, 한국어는 글자 1~2자 = 1토큰 정도로 보시면 돼요. 같은 글이라도 한국어가 영어보다 토큰을 더 많이 써요.
Q2. Responses API는 별도 요금이 붙나요?
A. 아니에요. OpenAI의 Responses API는 별도 과금이 아니라 사용한 모델의 토큰 단가로 청구돼요. 추가 요금표를 찾을 필요 없어요.
Q3. prompt caching은 어떤 경우에 효과적인가요?
A. 시스템 프롬프트가 길거나, 같은 문서를 기반으로 여러 질문을 처리하는 경우에 효과적이에요. 반대로 매번 완전히 다른 프롬프트를 보내는 패턴이라면 캐싱 효과가 거의 없어요.
Q4. Batch API는 얼마나 느린가요?
A. 보통 수 분에서 수 시간 이내에 결과가 돌아와요. "지금 당장" 필요한 게 아니라 "오늘 안에" 필요한 작업이라면 Batch API가 적합해요. Google의 경우 50% 할인이니 대량 작업에서는 절감 효과가 엄청나요.
Q5. 1M 컨텍스트를 쓰면 무조건 비싼가요?
A. 네, 기본적으로 비싸요. 하지만 캐싱과 압축을 병행하면 많이 줄일 수 있어요. 중요한 건 "정말 1M이 필요한 작업인가"를 먼저 판단하는 거예요. 대부분의 작업은 200K + RAG로 해결돼요.
Q6. Azure PTU는 소규모 팀에도 의미가 있나요?
A. PTU는 일정 처리량을 미리 사 두는 개념이라, 트래픽이 적으면 오히려 비쌀 수 있어요. 월간 호출량이 안정적이고 예측 가능한 수준(수만 건 이상)이 되어야 PTU가 경제적이에요.
Q7. 혼합 라우팅을 구현하려면 복잡한가요?
A. 기본 개념은 간단해요. 요청 분류기(간단한 규칙 또는 경량 모델)를 앞에 두고, 난이도에 따라 다른 모델로 보내면 돼요. OpenAI나 LangChain 같은 프레임워크에서 라우팅 기능을 지원하므로 밑바닥부터 짤 필요는 없어요.
Q8. Perplexity Sonar API는 어떤 서비스에 적합한가요?
A. 최신 정보 기반 답변이 필수인 서비스에 적합해요. 뉴스 요약, 시장 조사, 팩트 체크 같은 용도요. 하지만 검색 깊이에 따라 비용이 늘어나니, "어느 정도 깊이까지 검색할 것인가"를 미리 정해야 비용 관리가 돼요.
참고 자료 (References)
데이터 출처
| 출처 | 설명 | 링크 |
|---|---|---|
| OpenAI Pricing | GPT-5.2 등 모델별 토큰 단가 및 Batch API 정보 | OpenAI Pricing |
| Anthropic API Pricing | Claude 모델별 단가, prompt caching, 티어 정보 | Anthropic Pricing |
| Google AI for Developers | Gemini API 가격, context caching, Batch API 할인 | Google AI Pricing |
| Perplexity Sonar API Docs | Sonar API 과금 구조, request fee, 토큰 분리 | Perplexity API Docs |
| Azure OpenAI Pricing | 온디맨드/PTU/배치 과금 모델 | Azure OpenAI Pricing |
핵심 인용
"The true cost of an API call is never just the token price — it's the sum of caching, batching, search augmentation, and rate limit headroom."
— OpenAI Developer Community, 2025
다음 편 예고
[8편] 시나리오별 추천 조합
- 긴 문서 요약, 글쓰기, 학습/리서치, 업무 자동화 — 시나리오별로 어떤 AI를 조합하면 좋을까?
- "한 플랫폼 올인"보다 "역할 분담"이 왜 합리적인지
- 지식노동자, 리서처, M365 팀 등 페르소나별 추천 조합 패턴