AI 하나에 올인한 팀이 먼저 맞는 청구서

단일 AI 의존이 먼저 터뜨리는 건 전략이 아니라 비용이다

사티아 나델라가 7월 말 꺼낸 경고의 핵심은 단순하다. 프롬프트와 모델 사이에 추상화 레이어 — AI 게이트웨이 — 를 두지 않은 회사는 위험하다. 단일 AI에 전부를 맡긴 기업은 살아남지 못할 수 있다.

대기업 CTO 얘기로 들린다면 맞다, 보통은 그렇다. 그런데 작은 팀에게 이 경고가 현실로 오는 경로가 다르다. 전략 실패가 아니라 다음 달 청구서로 온다. 벤더 교체 고민보다 훨씬 빠르게.

Claude Haiku와 Sonnet의 output 토큰 단가 차이는 약 3~4배다. GPT-4o mini와 GPT-4o 사이는 더 벌어진다. 단순 콘텐츠 생성을 Sonnet으로만 돌리면 Haiku 대비 비용이 세 배 넘게 나온다. 모델을 한 곳에 고정해두면 최적화 여지가 아예 없다.

단, 여기에 함정이 있다. "그냥 싼 모델 써라"가 아니다. 어떤 작업에 어떤 모델을 쓸지 설계 없이 무조건 싸게 가면 품질이 무너진다. 이 균형점을 잡는 게 진짜 핵심이다.

AI 게이트웨이를 대기업 말 빼고 설명하면

나델라가 언급한 AI 게이트웨이는 구조적으로 이렇다. LLM API를 코드에서 직접 호출하지 않고, 중간에 라우터 레이어 하나를 둔다. 그 레이어가 태스크 유형·복잡도·현재 비용에 따라 어느 모델로 요청을 보낼지 결정한다.

엔터프라이즈 제품이라면 여기에 캐싱, 프롬프트 로깅, 멀티벤더 폴백, 비용 알림이 다 붙는다. LiteLLM, Portkey, Kong AI Gateway 같은 솔루션이 이 공간을 노린다. 월 수십만 원짜리 SaaS도 있고, 셀프호스팅 오픈소스도 있다.

작은 팀이 당장 이걸 도입해야 하느냐고 물으면 — 꼭 그렇지 않다. 추상화가 얼마나 두꺼워야 하는지는 팀 규모와 봇·서비스 수에 달려 있다. 단 한 가지만은 분명하다. 모델 호출을 코드에 직접 박아둔 팀은 가격이 오르거나 모델이 바뀌는 순간 전체 코드를 뒤집어야 한다.

실제 수치: 봇 12개 팀에서 차이가 이렇다

우리 팀 규모로 대략 계산해보면 이렇다. 봇 12개, 하루 평균 봇당 13건, 글 한 편 생성에 output 토큰 약 2,0003,000개. 시스템 프롬프트·예시·컨텍스트를 합한 input이 output의 3~4배 수준이다.

하루 output 기준 40,00080,000 토큰이 나온다. Haiku 단가로 계산하면 월 토큰 비용이 510만 원대다. 같은 볼륨을 Sonnet으로만 돌렸다면 15~30만 원이 된다. 검수·판단 작업(리뷰 루프, 품질 판정, 복잡한 분류)만 Sonnet으로 올리고 초안 생성은 Haiku로 내리면, 품질 판단은 좋은 모델이 맡으면서 비용은 절반 이하로 유지된다.

이게 모델 계층화(model tiering)다. 나델라 식으로 말하면 AI 게이트웨이의 핵심 기능이고, 실용적으로 말하면 "무서운 건 Sonnet이 하고, 양산은 Haiku가 해라"다.

처음엔 어차피 모델 하나 쓰면 된다고 생각했다. 봇 수가 다섯을 넘어가면서, 같은 비용 구조를 유지하면 안 된다는 게 실감됐다.

우리 팀이 이미 절반은 해두었던 것

모든 봇에서 claude_cli라는 공통 헬퍼를 쓴다. anthropic SDK를 코드에서 직접 호출하지 않고, 이 헬퍼 하나를 통해 모든 LLM 요청이 지나간다. 덕분에 Haiku 3에서 Haiku 4.5로 이관할 때 코드 수정이 모델명 상수 변경 한 줄이었다.

이게 나델라가 말한 "프롬프트와 모델 사이의 레이어"와 본질적으로 같다. 완성된 게이트웨이는 아니지만, 벤더를 바꾸거나 모델을 교체할 때 전체 코드를 건드리지 않아도 된다는 것 하나만으로도 상당한 보험이 된다.

다음 단계로 고민하는 건 태스크 타입 기반 자동 모델 선택이다. 생성(초안 작성, 요약)은 Haiku, 검수·판단은 Sonnet, 멀티홉 추론이 필요한 작업은 더 강한 모델로 — 이걸 봇 코드가 아니라 헬퍼 레이어에서 결정하게 하는 것. 호출 쪽은 태스크 타입만 넘기고 어떤 모델을 쓸지는 헬퍼가 고른다. 한 벤더가 가격을 올리거나 장애가 나도 폴백 경로가 생기는 건 그다음 이야기다.

AI 인프라 레이어를 아는 사람이 드문 이유

AI 개발자 취업을 준비하는 입장이라면 이 시점에 이 개념이 중요하다. LLM API를 직접 호출하는 코드를 짜는 것과, 게이트웨이 레이어를 설계하고 모델 비용 구조를 이해하며 태스크별 라우팅을 구현해본 것은 시장에서 레벨이 다르게 읽힌다.

클라우드 전환기에 VPC 설계, IAM 정책, 비용 최적화를 아는 DevOps 엔지니어가 단순 인스턴스 관리자보다 압도적으로 가치가 높았던 것처럼, 지금 AI 인프라에서 같은 전환이 일어나고 있다. 모든 회사가 "LLM 붙이기"를 하고 있고, 그다음인 "어떻게 비용 효율적으로 운영하느냐"를 실제로 해본 사람이 드물다. OpenAI API 붙인 토이 프로젝트보다, LiteLLM을 운영하면서 모델별 비용과 품질을 직접 트레이드오프해본 경험이 포트폴리오에서 차별화된다.

지금 바로 실행할 수 있는 것들

모델 호출을 코드에 직접 박지 마라. 헬퍼 함수 하나, 클래스 하나라도 중간에 두는 게 첫 번째다. 모델명을 상수 하나로 관리하고 있다면 그게 최소한의 레이어다. 안 되어 있다면 리팩토링 한 시간이면 끝난다.

태스크를 두 등급으로 나눠라. 생성 계열(초안, 요약, 번역)은 저렴한 모델로 내리고, 판단 계열(품질 검수, 복잡한 분류, 의사결정 지원)은 좋은 모델에 집중한다. 이것만 해도 동일 품질에 비용이 40~60% 줄어드는 경우가 많다.

실제 토큰 사용량을 지금 찍어라. Anthropic 콘솔이든 LiteLLM 셀프호스트든, 봇별 사용 로그 하나만 있으면 최적화 포인트가 눈에 들어온다. 직접 찍어보기 전까지는 어느 작업이 얼마나 먹는지 감이 없다.

마지막으로, Anthropic API만 쓰고 있다면 GPT-4o mini든 Gemini Flash든 폴백 선택지를 코드에 열어둬라. 장애 대비보다 가격 협상력이 목적이다. 선택지가 있는 팀이 없는 팀보다 유리하다. 단일 AI에 올인한 팀이 살아남지 못할 수 있다는 말은 결국 이걸 가리킨다.

원문: AI News & Artificial Intelligence | TechCrunch