지난 분기 인프라 청구서를 열어보고 거의 숨이 막힐 뻔했습니다. 우리는 헤지펀드가 Series A 투자금을 소진하듯 — 아무도 제대로 추적하지 않는 상태에서 무심하게 AI 토큰을 태워 없애고 있었습니다. 저는 작은 스타트업의 CTO입니다. 이는 제가 코드를 작성하고, 모델을 선택하고, 청구서에 서명하며, 왜 우리의 매출 총이익률(Gross Margin)이 스위스 치즈처럼 구멍이 숭숭 뚫려 있는지 이사회에 설명해야 하는 사람이라는 뜻이기도 합니다.

이것은 제가 6개월만 더 일찍 누군가로부터 건네받았더라면 좋았을 플레이북(Playbook)입니다. 아래의 모든 숫자는 실제이며, 모든 코드 라인은 프로덕션(Production) 환경에서 실행 중입니다. 만약 여러분이 이 글을 읽고 있는 스타트업 창업자나 엔지니어링 리드(Eng Lead)라면, 제가 겪었던 값비싼 시행착오를 건너뛰기를 바랍니다.

모든 일의 시작이었던 14,000달러의 실수

우리의 초기 AI 스택은 2024년의 다른 모든 기업들과 비슷했습니다. 모든 것에 GPT-4o를 사용했죠. 고객 지원(Customer Support)? GPT-4o. 내부 요약(Internal Summarization)? GPT-4o. 문서 분류(Document Classification)? 짐작하신 대로 — GPT-4o였습니다. 우리는 제품-시장 적합성(Product-Market Fit)을 찾은 뒤에 "나중에 최적화하자"라고 스스로에게 말했습니다.

두 달이 지나자, 청구 금액은 14,000달러에 달했습니다. 제품-시장 적합성은 여전히 소문 단계에 불과했습니다. 그때 저는 사용 로그(Usage Logs)를 살펴보며 우리가 시장에서 가장 비싼 모델을 통해 수천 개의 사소한 요청을 처리하고 있다는 사실을 깨달았습니다. 그것은 마치 식료품을 사러 가는데 Lamborghini를 사용하는 것과 같았습니다.

해결책은 거창한 머신러닝(ML) 엔지니어링이 아니었습니다. 그것은 아키텍처(Architecture)였습니다. 그리고 투자 대비 효과(ROI)는 즉각적이었습니다. 3주 이내에 동일한 제품 서비스 범위에서 월 청구 금액이 700달러 미만으로 떨어졌습니다. 이것이 제가 계속 언급할 95%라는 숫자입니다. 실제 스택을 하나씩 살펴보겠습니다.

싸울 대상을 선택하라: 모델 선택이 가장 큰 레버리지다

제가 창업자들에게 "모델 선택이 단일 비용 측면에서 가장 큰 레버리지(Lever)입니다"라고 말하면, 그들은 정중하게 고개를 끄덕인 뒤 여전히 모든 것에 GPT-4o를 계속 사용합니다. 이해합니다. 편리함이라는 요소는 실재하니까요. 하지만 규모가 커지면 "편리함"은 "파산"이 됩니다.

제가 우리 시스템을 위해 구축한 정확한 로드맵은 다음과 같습니다. 이것은 이론적인 비교가 아닙니다. 몇 주간의 벤치마킹 (Benchmarking) 끝에 제가 확정한 실제 운영 (Production) 할당 내역입니다:

작업 유형	기존 사용 모델	현재 사용 모델	절감액
단순 채팅	GPT-4o ($10/M)	DeepSeek V4 Flash ($0.25/M)	97.5%
...

패턴은 명확합니다. 여기서의 모든 "스마트한" 선택은 편리한 기본값보다 30~1000배 더 저렴합니다. 수백만 개의 토큰 (Tokens)을 처리할 때, 이러한 비율은 실제 현금으로 복리 효과를 일으킵니다.

한 가지 짚고 넘어가고 싶은 점은 이것이 단지 비용에 관한 것만이 아니라는 점입니다. 벤더 종속 (Vendor lock-in)은 실질적인 위험입니다. 만약 제가 모든 것을 GPT-4o API를 중심으로 구축했다면, 가격 정책 한 번의 변경만으로도 마진 위기에 처했을 것입니다. 추론 (Inference)을 여러 제공업체에 분산시키는 것 — 코드는 DeepSeek, 번역은 Qwen, 그리고 프리미엄 모델을 예비로 두는 방식 — 은 우리에게 협상력과 회복 탄력성 (Resilience)을 제공합니다. 한 제공업체가 가격을 올리거나 서비스 중단 (Outage)이 발생하더라도, 우리는 몇 주가 아닌 몇 시간 내에 경로를 재설정할 수 있습니다.

계층형 라우팅 (Tiered Routing): 모든 것을 바꾼 85/15/5 분할

모든 요청에 동일한 지능이 필요하지 않다는 점을 받아들이고 나면, 다음 아키텍처 (Architecture) 결정 사항은 라우팅 (Routing)입니다. 저희는 곧 코드와 함께 보여드릴 3단계 시스템으로 결정했습니다. 우선 그 철학부터 설명하겠습니다:

• Tier 1: 쉬운 쿼리 (Queries)의 롱테일 (Long tail)을 처리합니다. 트래픽의 약 80%를 차지합니다.
• Tier 2: 중간 난이도의 작업을 처리합니다. 트래픽의 약 15% 정도입니다.
• Tier 3: 진정으로 어려운 상위 5%를 위해 예약되어 있습니다.

저는 이를 OpenAI 호환 API (OpenAI-compatible API)를 감싸는 래퍼 (Wrapper) 형태로 구축했습니다. 저희는 Global API를 라우팅 계층으로 사용하는데, 이는 여러 모델에 대해 하나의 엔드포인트 (Endpoint)를 제공하기 때문입니다. 즉, 벤더 종속이 줄어들고, 청구서는 하나로 통합되며, 모니터링할 곳도 한 곳이 됩니다. 다음은 저희의 운영 라우팅을 구동하는 실제 코드입니다:

import httpx
import hashlib
import json
...

실제 결과는 다음과 같습니다. 저희 고객 지원 챗봇의 비용이 월 420달러에서 28달러로 줄었습니다. 제품도 같고, 사용자도 같으며, 답변 품질도 동일합니다 (블라인드 평가 (Blind evals)를 실시했습니다). 이는 제가 곧 보여드릴 다른 어떤 것을 적용하기 전, 오직 라우팅만으로 달성한 93%의 감소율입니다.

캐싱 (Caching): 아무도 이용하지 않는 공짜 점심

캐싱 (Caching)은 모든 시니어 엔지니어가 해야 한다는 것을 알고 있지만, 왠지 모르게 실제로 대규모로 구현하는 사람은 거의 없는 것 중 하나입니다. 그 이유는 게으름 때문입니다. 이 프롬프트를 이미 본 적이 있는지 고민하는 것보다 또 다른 API 호출을 날리는 것이 더 쉽기 때문입니다. 하지만 대규모 환경에서 게으름은 비용이 많이 듭니다.

우리의 설정은 의도적으로 단순합니다. 프롬프트(Prompt)와 모델(Model)의 조합을 해싱(Hash)하고 응답을 저장합니다. TTL(Time To Live) 창 내에서 동일한 해시가 발견되면, 비용 제로로 캐싱된 응답을 반환합니다. 다음은 프로덕션 버전입니다:

import hashlib
import json
import time
...

우리에게 있어 이 방식은 엄청난 승리였습니다. 고객 지원 문의는 반복되기 때문입니다. "비밀번호를 어떻게 재설정하나요?"라는 질문은 수천 번씩 들어옵니다. "환불 정책이 어떻게 되나요?"도 마찬가지입니다. 일반적인 문의를 캐싱하자, 서비스 영역에 따라 50%에서 80% 사이의 캐시 적중률(Cache rate)을 기록했습니다. 이는 모델 라우팅(Model routing)을 통해 절감한 비용에 더해, API 지출을 사실상 다시 절반으로 줄인 것입니다.

주의할 점이 있습니다. 캐싱은 예측 가능하고 반복적인 트래픽이 있을 때만 작동합니다. 만약 모든 프롬프트가 고유하다면(창의적인 생성, 개인화된 추천 등), 이 방식은 도움이 되지 않습니다. 하지만 FAQ 형태, 문서 Q&A, 또는 분류(Classification) 작업이 많은 경우에는 즉시 프로덕션에 적용 가능하며 기본적으로 비용이 들지 않습니다.

프롬프트 압축 (Prompt Compression): 숨겨진 토큰 세금

입력 토큰(Input tokens)은 소리 없는 살인자입니다. 대부분의 팀은 명확성과 완전성을 위해 프롬프트를 최적화하며, 이는 품질 측면에서는 올바른 결정이지만, 해당 프롬프트가 수백만 번 전송될 때는 비용 측면에서 파괴적입니다.

비결은 이것입니다: 비싼 모델로 보내기 전에 저렴한 모델을 사용하여 긴 컨텍스트(Context)를 압축하는 것입니다. 우리는 100만 토큰당 0.01달러인 Qwen3-8B를 사용하여 긴 문서를 요약한 다음, 요약본을 실제 작업을 수행할 모델로 보냅니다. 다음은 해당 함수입니다:

def compress_prompt(text, target_ratio=0.5):
    if len(text) < 500:
        return text  # 이미 짧음 — 호출을 낭비하지 마세요
...

제가 확신을 갖게 된 계산법을 보여드리겠습니다. 저희는 모든 요청 앞에 2,000-토큰 (token) 규모의 시스템 프롬프트 (system prompt)를 붙여서 사용하고 있었습니다. 압축 후에는 이것이 400-토큰이 되었습니다. $0.25/M (DeepSeek V4 Flash 요금 기준)를 적용하면, 요청당 $0.024를 절약하게 됩니다. 금액 자체는 작아 보일 수 있지만, 곱해 보면 이야기가 달라집니다. 하루 10,000-요청 = 하루 $240 = 연간 $87,600입니다.

연간 8만 7천 달러입니다. 단 하나의 프롬프트(prompt)만으로 말이죠. 그 순간 저는 입력 토큰 (input tokens)을 "공짜"로 취급하는 것을 멈추고, 우리 AI 청구서에서 가장 큰 항목으로 다루기 시작했습니다.

배치 (Batching): 수익으로 직결되는 엔지니어링 본능

마지막 레버 (lever)는 제가 전통적인 시스템 엔지니어링 (systems engineering)에서 빌려온 것입니다. 하나로 충분할 때 세 번의 API 호출 (API calls)을 하지 마세요. 모든 API 호출에는 요청 설정 (request setup), 응답 파싱 (response parsing), 네트워크 지연 시간 (network latency)과 같은 고정된 오버헤드 (overhead)가 발생합니다. 유사한 프롬프트 목록을 보낼 때, 이를 하나의 호출로 배치 (batching)하면 토큰을 절약할 뿐만 아니라 오버헤드도 줄일 수 있습니다.

대조는 명확합니다:

# ❌ 이전 — 세 번의 호출, 세 번의 오버헤드
for question in user_questions:
    response = call_model(
...

저희는 배치 (batched) 워크로드 (workloads)에서 10-20%의 비용 절감을 확인했으며, 순차적인 네트워크 호출을 기다릴 필요가 없기 때문에 처리량 (throughput) 개선 효과는 훨씬 더 큽니다. 저희의 야간 데이터 처리 작업 (nightly data processing jobs)의 경우, 실제 소요 시간 (wall-clock time)을 절반으로 줄였습니다. 공짜로 얻은 속도입니다.

내가 가졌더라면 좋았을 프로덕션 준비 체크리스트 (Production-Ready Checklist)

스타트업에서 AI 인프라 (AI infrastructure)를 구축하는 모든 분을 위해 제가 배운 내용을 체크리스트로 정리해 보겠습니다:

1. 모델 단위가 아닌 기능(feature) 단위로 비용을 측정(Instrument)하세요. 어떤 제품 인터페이스에서 $X만큼의 비용을 쓰고 있는지 알 수 없다면, 최적화할 수 없습니다.
2. 기본값은 저렴한 모델로 설정하세요. 품질 평가(evals)를 통해 필요함이 증명될 때만 상위 모델로 격상하세요. "더 안전해 보이니까 비싼 모델을 선택했다"라는 결정의 비용은 규모가 커질수록 엄청나게 불어납니다.
3. 하드코딩된 모델 호출이 아닌 라우팅 계층(routing layer)을 구축하세요. 모든 AI 기능은 어떤 모델을 사용할지 결정하는 함수를 거쳐야 합니다. 이것이 미래의 유연성을 보장합니다.
4. 공격적으로 캐싱(Cache)하고, 신중하게 만료(expire)시키세요. 일반적인 쿼리에 대해 1시간의 TTL(Time To Live)을 설정하는 것은 당연한 선택입니다. 더 긴 TTL은 데이터의 최신성(freshness) 보장이 필요합니다.
5. 전송하기 전에 압축하세요. 긴 컨텍스트(long context)에 대해 저렴한 요약기(summarizer)를 실행하세요. 여기서 얻는 절감액은 압축 호출에 드는 비용을 압도합니다.
6. 배치(Batch) 처리가 가능한 모든 것은 배치로 처리하세요. 모델 호출을 순차적인 루프(sequential loops)로 돌리는 것은 대개 코드 스멜(code smell)입니다.
7. 벤더 종속(vendor lock-in)을 피하세요. OpenAI 호환 애그리게이터(aggregator, 저희는 Global API를 사용합니다)를 사용하여 몇 주가 아닌 몇 시간 만에 제공업체를 교체할 수 있도록 하세요. 이 단 하나의 결정이 지난달 주요 제공업체의 장애 상황에서 저희를 구했습니다.
8. 비용뿐만 아니라 품질을 측정하세요. 모델을 교체할 때마다 블라인드 평가(blind eval)를 실시하세요. 사용자 경험을 망가뜨리는 95%의 비용 절감은 승리가 아닙니다.

이것이 실제로 달러로 환산하면 어떤 모습인가

모든 내용을 종합해 보겠습니다. 최적화 전 저희의 월간 AI 지출액은 약 $14,000였습니다. 다섯 가지 레버를 모두 적용한 후에는 약 $650가 되었습니다. 특히 고객 지원 챗봇은 $420에서 $28로 줄었습니다. 문서 요약(Document summarization)은 92% 감소했고, 코드 리뷰 도구(Code review tooling)는 96% 감소했습니다.

총 월간 절감액은 약 $13,350입니다. 연간으로 환산하면 $160,200입니다. 4명 규모의 스타트업에게 이것은 다음 엔지니어를 채용할 수 있느냐 없느냐의 차이입니다.

그리고 청구서에는 나타나지 않는 부분이 있습니다. 바로 저희가 더 빠르게 제품을 출시(ship)한다는 점입니다. 제가 팀원들에게 "먼저 저렴한 모델을 사용하세요"라고 말하면, 그들은 매 테스트 실행마다 실제 돈이 나가는 것에 대해 불안해하지 않기 때문에 더 빠르게 반복(iterate)합니다. 비용 효율성(Cost-effectiveness)과 속도(velocity)는 대립하는 개념이 아니라 같은 맥락의 대화입니다.

나의 마무리 제언

만약 이 현장 보고서에서 단 한 가지만 얻어가야 한다면, 이것을 가져가십시오. 대부분의 AI API 비용은 모델 가격이 아니라 아키텍처 선택(architectural choices)의 결과물입니다. 모델 가격은 매 분기마다 저렴해지고 있습니다. 여러분이 오늘 통제할 수 있는 것은 바로 여러분의 아키텍처 선택입니다.

만약 10개의 서로 다른 제공업체(provider)와 관계를 맺지 않고도 이러한 아이디어들을 빠르게 테스트하고 싶다면, Global API를 살펴보십시오. global-apis.com/v1에 있는 그들의 엔드포인트(endpoint)는 OpenAI 프로토콜을 따르기 때문에, 위에서 보여드린 코드는 코드 변경 없이 대부분의 기존 스택(stack)에 즉시 적용됩니다. 지난 분기 동안 우리는 이를 라우터(router)로 사용해 왔으며, 이를 통해 개발자 편의성(developer ergonomics)을 희생하지 않으면서도 선택의 폭을 넓게 유지할 수 있었습니다.

AI 비용 최적화의 가장 좋은 점은 절감액 그 자체가 아니라, 바로 자유(freedom)입니다. 각 쿼리(query) 비용이 1센트의 아주 작은 부분 수준으로 낮아지면, 실험을 아껴가며 할 필요가 없어집니다. 여러분은 비로소 실제로 만들고 싶었던 제품을 만들기 시작하게 됩니다. 그것이 진정한 ROI(투자 대비 수익)이며, 제가 이야기를 들어주는 모든 창업자에게 이 내용을 계속해서 설파하는 이유입니다.

이제 가서 그 client.chat.completions.create 호출 코드를 다시 작성하십시오. 미래의 여러분과 여러분의 CFO(최고재무책임자)가 고마워할 것입니다.