AI API 요금은 물통과 같다. 여러 구멍으로 동시에 새고, 작은 구멍부터 막으면 헛수고다. 요금을 절반, 때로는 10분의 1로 줄이는 사람과 그러지 못하는 사람의 차이는 요령의 개수가 아니라 순서다. 절감 효과가 큰 구멍부터 막는다. 아래는 그 순서다. 참고로 구체 수치는 Claude API 요금을 기준으로 들었다(모델·요금은 바뀌므로 실제 적용 전 최신 공시 확인 권장).
구멍 1: 모델 과잉 — 가장 크고, 가장 흔한 누수
대부분의 요금 낭비는 여기서 시작된다. 쉬운 일에 비싼 모델을 쓰는 것. 분류, 추출, 요약, 간단한 포맷팅 같은 일에 최상위 모델을 붙이는 건, 못 하나 박는 데 굴착기를 부르는 격이다.
Claude 기준으로 입력·출력 100만 토큰당 요금은 대략 Haiku 4.5가 $1/$5, Sonnet 4.6이 $3/$15, Opus 4.8이 $5/$25다. 즉 같은 작업을 최상위 모델 대신 하위 모델로 돌리면 토큰당 단가 자체가 몇 배 차이 난다. 실제로 작업 난이도에 따라 Haiku와 Sonnet 사이를 라우팅하는 것만으로 전체 청구액을 60~80% 줄일 수 있다는 분석도 있다.
막는 법: 작업을 난이도로 계층화하라. 쉬운 대량 작업은 가장 싼 모델로, 정말 어려운 추론만 최상위로 올린다. 최상위 모델은 “더 나은 첫 답이 프리미엄만큼의 값어치를 하는” 순간에만 아껴 쓴다.
구멍 2: 반복되는 컨텍스트 — 캐싱으로 막는다
같은 시스템 프롬프트, 같은 문서, 같은 예시를 매 요청마다 다시 보내고 있다면, 매번 그 입력 토큰 값을 새로 지불하는 것이다. RAG 시스템이나 코드 어시스턴트처럼 고정된 큰 맥락을 반복 전송하는 워크로드에서 이 누수는 특히 크다.
프롬프트 캐싱이 이 구멍을 막는다. 안정적인 앞부분(시스템 프롬프트, 지식 베이스, 긴 문서)을 서버에 캐시해두면, 캐시된 입력의 재사용 단가가 기본 입력의 0.1배까지 내려간다. 캐시 쓰기가 처음 한 번 1.25배(단기) 정도 더 들지만, 한두 번만 재사용해도 곧 손익분기를 넘긴다. 반복 맥락이 많은 앱에서는 캐싱만으로 비용을 88~95% 줄일 수 있다.
막는 법: 프롬프트에서 잘 안 바뀌는 부분(지시·문서·예시)을 앞쪽에 고정 배치하고 캐싱을 건다. 요청마다 바뀌는 부분만 뒤에 붙인다. 캐시는 순서에 민감하므로 ‘안정적인 것 → 가변적인 것’ 순으로 구성하는 게 핵심이다.
구멍 3: 비대한 입력 — 컨텍스트 다이어트
세 번째 누수는 “일단 다 넣고 보자”는 습관이다. 파일 전체, 대화 히스토리 전부, 문서 통째로를 매번 밀어넣으면 입력 토큰이 폭증한다. 특히 요청 입력이 20만 토큰을 넘어가면 긴 컨텍스트 프리미엄 요금이 붙어, 부담이 한 번 더 커진다.
막는 법: 모델에게 필요한 것만 골라 준다. 문서 전체 대신 검색으로 관련 조각만 넣고(RAG), 긴 대화는 오래된 부분을 요약해 압축하거나 슬라이딩 윈도로 잘라낸다. 지시문에서 중복되고 장황한 문장을 걷어내는 것도 누적되면 무시 못 할 절감이 된다. 입력에서 가장 저렴한 토큰은 애초에 보내지 않은 토큰이다.
구멍 4: 실시간 강박 — 배치로 절반
네 번째. 모든 요청을 실시간으로 처리할 필요는 없는데, 습관적으로 동기 호출을 쓴다. 야간 리포트 생성, 대량 분류, 콘텐츠 정제, 예약된 데이터 추출처럼 당장 응답이 필요 없는 작업이 여기 해당한다.
배치 API가 이 구멍을 막는다. 요청을 비동기로 모아 보내면 보통 24시간 안(대개 훨씬 빨리)에 결과가 오고, 입력·출력 토큰이 모두 50% 할인된다. 같은 모델이 같은 추론을 돌리므로 품질 차이는 없고, 단지 여유 시간대에 스케줄될 뿐이다. 게다가 배치는 캐싱과 겹쳐 쓸 수 있어, 반복 맥락 작업이라면 입력 기준 최대 95% 수준까지 결합 절감이 가능하다.
막는 법: 워크로드를 ‘실시간이 꼭 필요한 것’과 ‘아닌 것’으로 가른다. 후자는 전부 배치 큐로 보낸다. 이것만으로 해당 작업의 요금이 곧장 반으로 준다.
구멍 5: 긴 출력 — 출력은 입력의 5배다
마지막 구멍은 자주 간과된다. 모든 Claude 모델에서 출력 토큰은 입력 토큰의 5배다. 즉 코드·기사·리포트처럼 긴 출력을 만드는 작업은 청구액의 무게중심이 출력 쪽에 쏠린다. 모델에게 장황하게 답하라고 방치하면, 가장 비싼 토큰을 낭비하는 셈이다.
막는 법: 출력 상한(max_tokens)을 현실적으로 잡고, “간결하게”, “핵심만”, “표로” 같은 지시로 형식을 제약한다. 구조화된 출력(JSON 등)과 정지 시퀀스를 써서 불필요한 사족을 잘라낸다. 추론형 모델을 쓴다면 사고(thinking) 토큰 예산과 노력 수준을 작업 난이도에 맞게 조절해, 쉬운 일에 과한 사고를 태우지 않도록 한다. 출력이 무거운 작업일수록, 모델 계층 선택(구멍 1)과 출력 통제(구멍 5)를 함께 조이는 것이 효과가 크다.
구멍을 다 막기 전에: 어디서 새는지부터 재라
순서대로 막았다면 마지막 원칙 하나가 남는다. 측정 없이는 최적화도 없다. 요청별 입력·출력·캐시 토큰을 로깅해서, 청구액의 대부분을 잡아먹는 상위 작업이 무엇인지부터 찾아라. 어떤 워크로드는 입력이 지배적이고(그럼 캐싱·컨텍스트 다이어트가 답), 어떤 워크로드는 출력이 지배적이다(그럼 모델 다운사이징·출력 통제가 답). 지배적인 쪽을 알아야, 다섯 구멍 중 어디에 힘을 줄지가 정해진다.
정리하면 이렇다. 큰 것부터 — 모델을 라이트사이징하고, 반복 맥락을 캐싱하고, 입력을 다이어트하고, 비실시간 작업을 배치로 넘기고, 출력을 통제한다. 이 다섯을 순서대로 막으면, 같은 결과물을 내면서 요금은 전혀 다른 자릿수가 된다.
⚠️ 이 글의 요금·할인율·모델명은 2026년 8월 기준이며, LLM 요금 체계는 자주 바뀐다. 실제 적용 전에는 사용하는 API 제공사의 공식 가격 페이지에서 최신 수치를 반드시 확인할 것.
자주 묻는 질문
어떤 구멍부터 막아야 하나요?
모델 과잉입니다. 분류, 추출, 요약, 간단한 포맷팅 같은 일에 최상위 모델을 붙이는 것이 가장 흔하고 가장 큰 낭비입니다.
프롬프트 캐싱은 언제 효과가 큰가요?
같은 시스템 프롬프트나 문서를 매 요청마다 다시 보내는 경우입니다. RAG 시스템이나 코드 어시스턴트처럼 고정된 큰 맥락을 반복 전송하는 워크로드에서 특히 큽니다.
출력 토큰이 왜 중요한가요?
모든 Claude 모델에서 출력 토큰은 입력 토큰의 5배 요금입니다. 코드나 기사, 리포트처럼 긴 출력을 만드는 작업은 청구액의 무게중심이 출력 쪽에 쏠립니다.
배치 API는 언제 쓰나요?
야간 리포트 생성, 대량 분류, 콘텐츠 정제, 예약된 데이터 추출처럼 당장 응답이 필요 없는 작업입니다.
Leave a Reply