자, 이런 일이 있었습니다: 하나의 API 키로 184개의 AI 모델을 실행하는 방법 — 백엔드 이야기

6개월 전, 저는 Series A 단계의 핀테크 기업을 위해 LLM (Large Language Model) 기반 기능을 출시했습니다. 지난주에는 Fortune 500 기업의 조달 팀이 첫 AI 계약을 협상하는 것을 도왔습니다. 같은 주에 말이죠. 이 두 대화는 이보다 더 다를 수 없을 만큼 판이했으며, 이를 통해 저는 시중에 나와 있는 대부분의 "AI API 비교" 기사들이 하나의 프로필이 모두에게 적합한 것처럼 가장하기 때문에 기본적으로 쓸모가 없다는 사실을 깨달았습니다.

그래서 이 글은 제가 예전에 가졌더라면 좋았을 글입니다. 여러분이 누구인지, 그리고 무엇을 최적화하려 하는지에 따라 LLM API 제공업체를 선택할 때 실제로 무엇이 중요한지 나누어 살펴보겠습니다. 마케팅용 미사여구나 "상황에 따라 다릅니다"와 같은 회피성 답변은 없습니다. 제가 실제 인보이스(invoice)에서 확인한 수치와 함께, 프로덕션(production) 환경에서 마주치는 트레이드오프 (tradeoffs)만을 다룹니다.

참고로, 저는 백엔드 엔지니어입니다. 저는 보도 자료가 아니라 레이턴시 백분위수 (latency percentiles)에 관심이 있습니다.

"그냥 OpenAI를 직접 호출하세요"가 나쁜 조언인 이유

제가 멘토링한 모든 주니어 개발자들은 어느 시점에 항상 똑같은 말을 했습니다: "왜 그냥 OpenAI API를 직접 호출하지 않나요?" 이론적으로는 합리적으로 들립니다. 중간 단계를 생략하고, 가장 최신의 모델을 사용할 수 있으며, 깔끔한 OpenAI 클라이언트 호출을 작성하여 배포하면 되니까요.

하지만 현실이 닥칩니다.

3개월 후, 여러분은 선택한 모델이 지원 중단 (deprecated)되고 있다는 사실을 발견합니다. OpenAI에 장애가 발생했을 때를 대비한 폴백 (fallback)이 필요합니다 (장애는 반드시 발생합니다. 참고로, 지난 18개월 동안 모든 주요 제공업체가 수 시간 동안 지속된 장애를 겪었습니다). CFO는 왜 청구 금액이 400달러에서 4,000달러로 늘어났는지 알고 싶어 합니다. 그리고 팀원 중 누군가는 DeepSeek-V3가 여러분의 워크로드(workload)에 대해 60배 더 저렴하다는 사실을 발견했지만, 가입하려면 중국 전화번호와 WeChat Pay가 필요하다는 것을 알게 됩니다.

그때가 바로 밤 11시에 "AI API aggregator (aggregator)"를 구글링하기 시작하는 시점입니다.

아무도 미리 말해주지 않는 사실은 이렇습니다. 직접적인 제공업체(provider) 경로(path)는 MSA(Master Service Agreement, 주 서비스 계약) 서류에 서명할 수 있는 기업(enterprise)에 최적화되어 있지, 금요일에 프로토타입(prototype)을 출시하고 싶은 팀을 위해 만들어진 것이 아닙니다. 그리고 기업이라 할지라도, 직접 연결한다는 것은 사용하려는 모든 모델 벤더(vendor)와 각각의 이용 약관(ToS), 결제 주기(billing cycle), 속도 제한 정책(rate limit policy)을 가지고 개별적으로 협상해야 함을 의미합니다.

제 개인적인 의견으로는, "직접 연결하라"는 조언은 Medium 포스트에서는 맞는 말처럼 들리지만, 이를 실제로 운영(operationalize)하려고 시도하는 순간 무너지는 것들 중 하나입니다. RFC 7231이 여기에는 적용되지 않지만, 그 정신은 유효합니다. 즉, 중개자(intermediaries)가 존재하는 데에는 이유가 있다는 것입니다.

실제로 제가 목격하는 두 가지 프로필

"스타트업(startup)"과 "기업(enterprise)"은 모호한 용어이므로, 제가 무엇을 비교하고 있는지 구체적으로 말씀드리겠습니다.

스타트업 프로필 (Series A–B 단계의 핀테크 사례):

• 엔지니어 3명 (그중 한 명은 CTO)
• 월간 AI 지출: $200–$2,000
• 프로덕션(production) 환경에서 3개의 모델 사용 (빠른 모델, 똑똑한 모델, 임베딩(embeddings)용 저렴한 모델)
• 전담 DevOps 없음, Stripe + Vercel 수준 이상의 보안 검토(security review) 없음
• API를 선택하는 엔지니어가 새벽 3시에 호출(paging)을 받는 바로 그 사람임

기업 프로필 (Fortune 500 구매 팀):

• 50명 이상의 엔지니어, 전담 플랫폼 팀 존재
• 월간 AI 지출 목표: 2분기 내 $50,000 이상
• 구매 부서에서 SOC2, DPA, 그리고 법무팀에 제출할 수 있는 실제 SLA(Service Level Agreement, 서비스 수준 협약)를 요구함
• 고객 데이터에 닿는 모든 것은 정보 보안(InfoSec) 팀의 검토를 거쳐야 함
• API를 선택하는 엔지니어는 80개의 질문이 담긴 벤더 리스크 평가(vendor risk assessment) 양식을 작성해야 함

이들은 같은 고객이 아닙니다. 같은 고객인 척하는 것을 그만두십시오.

스타트업이 실제로 최적화하는 것

스타트업 프로필의 경우, 병목 현상(bottleneck)은 SLA 협상이 아니라 반복 속도(iteration speed)입니다. 인증(auth)을 다시 설정하지 않고도 모델들을 A/B 테스트하고 싶어 합니다. 런웨이(runway)가 연장되더라도 만료되지 않는 크레딧(credits)을 원합니다. 결제 수단이 "중국 은행 계좌 개설" 같은 것이 아니기를 바랍니다.

제가 핀테크 팀에게 설명했던 비용 계산 방식은 다음과 같습니다. 동일한 워크로드(workload), 동일한 프롬프트(prompt), 단지 모델 선택만 다릅니다. 이해하기 쉽도록 모든 기획 문서에서 사용하는 것과 동일하게 5M(500만) 토큰 수치를 사용하겠습니다.

모든 단계에서 동일한 비율의 비용 절감이 발생하며, 이것이 핵심입니다. 스타트업에게 던져야 할 질문은 "비싼 모델을 사용해야 하는가?"가 아니라, "저렴한 모델이 쿼리(query)의 95%를 정확하게 처리한다면, 왜 굳이 비싼 모델을 사용해야 하는가?"입니다.

내부적으로 볼 때, 이러한 단계 사이에서 변하는 것은 수학적 계산이 아니라 실패 모드(failure modes)입니다. MVP 단계에서는 최선(best-effort)의 가동 시간(uptime)만으로도 충분합니다. 하지만 성장(Growth) 단계에서는 페일오버(failover)가 필요합니다. 따라서 MVP 단계에서 무엇을 선택하든, 코드 재작성 없이 성장 단계를 감당할 수 있는 수준으로 확장 가능해야 합니다.

다음은 실제 통합 코드입니다. 표준 OpenAI SDK를 사용하고 있다는 점에 주목하세요. 새로 배워야 할 특별한 라이브러리나 독점적인 클라이언트(proprietary client)는 없습니다. base_url만 변경될 뿐입니다.

from openai import OpenAI

client = OpenAI(
...

제가 스타트업들에게 여기서 애그리게이터(aggregator)를 권장하는 이유는 모델 교체(model-swap) 시나리오 때문입니다. OpenAI에 직접 연결되어 있다면, 비용 문제로 Qwen3-32B로 전환할 때 새로운 SDK, 새로운 인증(auth), 새로운 결제 관계가 필요합니다. 하지만 Global API를 사용하면 문자열 하나만 바꾸면 됩니다. 저는 팀들이 첫날부터 이러한 옵션을 열어둠으로써 일주일 분량의 엔지니어링 시간을 절약하는 것을 직접 목격해 왔습니다.

엔터프라이즈(Enterprise) 단계로 넘어가면 무엇이 변하는가

월 비용이 약 $5,000를 넘어서고 구매(procurement) 팀이 생기면 계산법이 뒤집힙니다. 저렴한 모델을 쓸 것인가의 문제는 더 이상 중요하지 않습니다. 질문은 다음과 같이 변합니다:

• 서비스가 중단되었을 때 누가 책임을 지는가?
• 데이터가 어디에서 처리되며, 이를 증명할 수 있는가?
• 회계 팀의 항의를 피하기 위해 Net-30 결제(Net-30 billing)가 가능한가?
• 법무 팀이 출시를 막기 전에 맞춤형 데이터 처리 합의서(DPA)를 받을 수 있는가?

이 지점이 바로 Global API의 Pro Channel이 제 역할을 다하는 곳이며, 직접 제공업체(direct-provider)와의 관계가 실제로 고통스러워지는 지점입니다. OpenAI는 연간 지출액이 100만 달러 미만인 고객에게는 맞춤형 데이터 처리 합의서(DPA)를 제공하지 않습니다. Anthropic도 비슷합니다. 중국 제공업체들은 SOC2를 언급하는 그 어떤 문서에도 서명하지 않을 것입니다.

Pro Channel은 기업 수준의 보증이 필요하지만, 단일 벤더와 7자리 수(백만 달러 단위)의 연간 계약을 맺고 싶지는 않은 중견 기업(mid-market enterprise)을 위한 해답입니다. 서비스 수준 협약(SLA) 항목 하나만 보더라도 — 99.9% 보장된 업타임(uptime) — "AI 기능이 2시간 동안 중단되었습니다"라는 상황이 단순한 사과로 끝날지, 아니면 SLA 크레딧(SLA credit) 지급 대상이 될지를 결정짓는 차이를 만듭니다.

동일한 OpenAI SDK, 다른 API 키 접두사(prefix), 다른 계층의 백엔드:

# Pro Channel — 동일한 클라이언트, 전용 백엔드
from openai import OpenAI

...

접두사(prefix)를 사용하는 트릭은 깔끔합니다. SDK는 이를 알지도 못하고 신경 쓰지도 않습니다 — 당신은 여전히 동일한 방식으로 .create()를 호출할 뿐입니다. 하지만 모델 식별자(model identifier)인 Pro/deepseek-ai/DeepSeek-V3.2는 라우터(router)에게 이 요청을 우선순위 큐잉(priority queueing)이 적용된 전용 인스턴스로 보내라고 지시합니다. 개인적으로 모든 벤더가 이렇게 하기를 바랍니다. 두 개의 별도 클라이언트 객체를 유지 관리하는 것보다 훨씬 더 깔끔한 추상화(abstraction)이기 때문입니다.

제가 실제로 배포하는 하이브리드 패턴

여기서 "하나의 크기로 모두 해결한다(one size fits all)"라는 프레임워크가 무너집니다. 제가 함께 일했던 대부분의 팀은 결국 하이브리드 방식을 채택하게 됩니다. 이는 결정을 내리지 못해서가 아니라, 서로 다른 워크로드(workload)가 실제로 서로 다른 요구사항을 가지고 있기 때문입니다.

                    ┌─────────────────────────────┐
                    │      Your Application       │
                    └──────────────┬──────────────┘
...

저렴한 계층(cheap tier)은 트래픽의 80%(요약, 분류, 추출)를 처리합니다. 저렴한 모델이 낮은 신뢰도 점수(low-confidence score)를 반환하면 폴백(fallback)이 작동합니다. 프리미엄 계층(premium tier)은 실제로 추론(reasoning)이 필요한 쿼리, 즉 컴플라이언스 분석, 계약서 검토, 그리고 정말로 똑똑한 모델이 필요한 새벽 2시의 디버깅 세션 등을 위해 예약됩니다.

이것은 제가 더 많은 블로그 포스트에서 실제로 추천하기를 바라는 아키텍처입니다. "모든 것에 그냥 GPT-4를 사용하라"는 부류는 비용 효율성을 놓치고 있으며, "그냥 Llama를 로컬에서 사용하라"는 부류는 지연 시간 (Latency)을 놓치고 있습니다.

백엔드 엔지니어 체크리스트

제가 AI 통합 PR (Pull Request)을 검토할 때 실제로 확인하는 사항은 다음과 같습니다. 여러분이 백엔드 엔지니어라면, 이 리스트가 새벽 3시에 호출되는 상황을 방지해 줄 것입니다.

1. 타임아웃 (Timeout) 설정. 클라이언트에 명시적인 timeout=을 설정하세요. OpenAI 클라이언트의 기본 타임아웃은 10분입니다. 응답이 멈춘 요청이 10분 동안 워커 (Worker)를 차단하는 상황을 원치 않을 것입니다.
2. 지터 (Jitter)를 포함한 재시도. 지수 백오프 (Exponential backoff) + 지터 (Jitter). 400번대 에러에 대해서는 재시도하지 마세요. 429 및 503 에러에 대해서는 재시도하세요.
3. 서킷 브레이커 (Circuit breaker). 만약 모델이 M초 동안 N번 실패한다면, 해당 모델로 트래픽을 보내는 것을 중단하세요. Pro Channel 티어는 이 부분에서 도움이 됩니다. 왜냐하면 페일오버 (Failover)가 사용자의 문제가 아닌 제공자 (Provider) 수준에서 이루어지기 때문입니다.
4. 토큰 예산 (Token budgeting). 요청당 토큰 사용량을 추적하세요. 사용자가 50페이지 분량의 문서를 붙여넣는다고 해서 여러분의 청구서가 조용히 10배로 늘어나서는 안 됩니다.
5. 로그 내 모델 버전 관리. 6개월 후에 model="..."를 교체할 때, 어떤 호출이 어떤 모델에 도달했는지 알아야 합니다. 이를 로그에 남기세요.
6. 멱등성 (Idempotent) 프롬프트에 대한 캐시된 응답. 두 명의 사용자가 "환불 정책이 무엇인가요?"라고 묻는다면, API가 아니라 캐시 (Cache)를 호출해야 합니다.

이것들은 AI 전용 패턴이 아닙니다. 제가 어떤 외부 의존성 (External dependency)에 대해서도 사용하는 것과 동일한 패턴입니다. 바로 그것이 핵심입니다. LLM은 그저 독특한 장애 모드 (Failure modes)를 가진 또 다른 서비스일 뿐입니다.

직접 제공자(Direct-provider) 문제 요약

결론을 맺자면, 제가 직접 제공자에게 가는 것을 추천하지 않는 이유는 이념적인 것이 아닙니다. 운영적인 이유 때문입니다.

마지막 행이 바로 엔터프라이즈 계약을 성사시키는 부분입니다. 아무도 12개의 별도 DPA (Data Processing Agreement)를 협상하고 싶어 하지 않습니다.

마무리하며

여기까지 읽으셨다면, 제가 고객들에게 제안하는 방식 그대로 나눈 저의 실제 권장 사항은 다음과 같습니다:

• 스타트업 (월 지출 약 $5K 미만): Global API standard 티어를 사용하세요. 하나의 키로 184개의 모델을 사용할 수 있으며, PayPal 결제가 가능하고 계약이 필요 없습니다. 빠르게 움직이세요.
• 엔터프라이즈 (월 지출 약 $5K 이상 또는 컴플라이언스 요구사항이 있는 경우): Global API Pro 채널을 사용하세요. 전용 용량 (Dedicated capacity), 99.9% SLA, 맞춤형 DPA, Net-30 결제 조건이 제공됩니다. 안심하고 업무에 집중하세요.

두 가지 경로 모두 대규모 사용 시 직접 제공업체와 계약하는 것보다 비용을 절감할 수 있으며, 직접 액세스 방식에서는 불가능한 모델 교체 유연성 (model-swap flexibility)을 제공합니다. 제가 두 경우 모두 고려하고 있는 가격 티어는 global-apis.com에서 제공되는 것과 동일합니다. 참고로, 가격 페이지는 제가 예상하는 것보다 더 자주 업데이트되므로 북마크해 두는 것이 좋습니다.

만약 당신이 선택한다면