모델을 부르는 곳이 서른 개 넘는 팀이라면, 게이트웨이보다 등급 계약부터

이 글을 도입 검토 자료로 읽으려는 팀이 먼저 답해야 할 질문은 "어느 게이트웨이를 쓸까"가 아닙니다. "우리 서비스가 부르는 모델을 등급 셋으로 줄일 수 있나"예요. 인프랩 사례에서 옮겨 갈 수 있는 부분은 Envoy AI Gateway 라는 제품이 아니라, 서비스 코드에는 low·medium·high 만 남기고 그 아래 실제 모델은 플랫폼이 바꾼다는 계약이거든요. 이 계약을 못 세우는 팀은 게이트웨이를 들여와도 모델 이름이 코드에 그대로 남고, 그러면 게이트웨이는 비싼 프록시로 끝납니다.

은퇴 주기 3개월짜리 의존성을 서른 곳에 박아둔 상태

인프랩이 출발한 지점은 저도 여러 팀에서 봤던 모습이에요. 자막 번역, 강의 상세 생성, 학습 에이전트, 커뮤니티 답변까지 서른 곳 넘는 사용처가 각자 제공 업체 키를 받아 직접 호출하고 있었고, 2026년 6월에는 LLM API 비용이 AWS 비용의 23% 까지 올라와 있었습니다. 문제는 비용 자체보다 모델의 수명이죠. 한 업체 안에서도 길어야 3개월 주기로 새 버전이 나오고 오래된 모델은 은퇴합니다. 서비스 코드에 gemini-2.5-flash 가 박혀 있으면 은퇴 통보가 올 때마다 서른 팀이 각자 검증하고 각자 배포해야 하는데, 바쁘면 밀리고, 밀리면 은퇴 시점에 그대로 장애가 되죠.

이걸 "키 관리 문제"로 부르면 시크릿 매니저 도입으로 끝나고, "비용 문제"로 부르면 싼 모델 찾기로 끝나요. 인프랩이 잘한 건 문제를 "선택을 바꾸는 비용"으로 이름 붙인 겁니다. 최적의 모델을 유지하는 게 아니라 모델을 바꾸는 데 드는 시간을 줄이는 쪽으로 방향을 잡았고, 그러면 답이 게이트웨이와 등급으로 자연스럽게 모이거든요.

등급은 품질 약속이 아니라 가격 상한 계약이다

인프랩의 등급표를 보면 high 는 100만 입력 토큰당 최대 $2, medium 은 $1, low 는 $0.3 입니다. 각 등급 뒤에 어떤 모델이 붙는지는 시간이 지나면 바뀌지만 상한선은 고정이에요. 그래서 기능 담당자는 "한 달 1억 토큰이면 low 로 $30" 식으로 입력 비용을 먼저 추정할 수 있고요.

계약의 성격을 정확히 읽어야 하는 지점이 이 표입니다. 등급이 약속하는 건 가격 상한이지 품질이 아니에요. medium 뒤의 모델이 바뀌면 그 모델에 맞춰 다듬어 둔 프롬프트가 깨질 수 있는데, 그 비용은 플랫폼이 아니라 기능 담당자가 집니다. 인프랩도 이 지점을 "좀 답답하지 않나요?" 라는 한 단락으로 인정하고 넘어가요. 특정 시점의 최적화보다 조직 전체의 반응 속도를 샀다는 설명인데, 저는 이 거래 자체에는 동의해요. 다만 이 거래가 공정해지려면 등급별 품질 테스트 세트가 먼저 있어야 하는데, 그건 등급별 테스트 세트를 더 촘촘하게 만들어 교체 판단을 자동화하겠다는 미래 과제로 적혀 있습니다. 즉 8월에 이뤄진 등급 라우팅 전환은 촘촘한 품질 게이트 없이 이뤄졌고, 비용은 측정됐지만 품질 회귀는 측정되지 않았어요.

공정하게 말하면 절차 자체는 있습니다. 등급별로 최소 품질 기준을 자동 검증하는 테스트 세트를 두고, 상한 비용 안에서 가성비가 더 좋아 보이는 모델이 나오면 후보로 올리고, 기존 모델과 후보에 같은 테스트를 돌려 하나라도 실패하면 탈락시키고, 통과하면 개발 파트 전체에 변경 예정일을 공지한 뒤 변경 후 집중 확인과 테스트 세트 추가로 닫는 다섯 단계예요. 순서는 맞아요. 문제는 이 절차의 강도가 테스트 세트의 밀도와 정확히 같다는 점이고, 그 밀도를 높이는 일이 아직 계획 단계라는 겁니다. 테스트 세트가 얇으면 "하나라도 실패하면 탈락"은 거의 아무것도 걸러내지 못하거든요. 등급 계약을 도입하려는 팀이 인프랩보다 먼저 해야 할 일이 있다면 이 세트를 등급마다 스무 개라도 먼저 채우는 거라고 봅니다.

라우팅 구성은 그 자체로 배울 만합니다. medium 요청은 할인 경로인 OpenRouter 의 openai/gpt-5.6-luna 를 priority 0 으로 먼저 때리고, 429 나 커넥션 실패가 나면 OpenAI 직접 경로의 gpt-5.6-luna 로 넘어가요. 같은 모델을 더 싸게 파는 경로가 생기면 그쪽을 1순위로 올리고, 한도에 걸릴 때만 정가로 가는 판단이 서비스 코드가 아니라 게이트웨이 설정에 있다는 게 핵심이죠.

78% 는 게이트웨이의 숫자가 아니라 가시화의 숫자다

비용이 가장 높았던 6월과 등급 라우팅을 적용한 뒤 첫 온전한 달인 8월을 비교하면 전체 LLM 비용이 약 78% 줄었습니다. 인상적인 숫자지만 분모와 분자 사이에 게이트웨이 말고도 변수가 최소 셋 들어 있어요.

하나는 인프랩이 직접 꼽은 두 요인이에요. 등급 라우팅으로 medium 의 실제 혼합 단가가 100만 토큰당 $0.18, 상한 $1 의 5분의 1로 내려갔고, 캐시 히트율이 80% 를 넘긴 것도 단가를 끌어내렸습니다. 다른 하나는 사용량이 보이기 시작한 것. 서비스와 기능 두 축으로 쪼개 놓고 나니 예상보다 훨씬 많이 쓰던 기능, 굳이 비싼 모델일 필요가 없던 기능이 드러났고, "라우팅을 바꾸지 않아도 보이는 것만으로 고쳐지는 몫" 이 있었어요. 마지막 하나는 글의 전제 자체입니다. 거의 매주 더 싸고 좋은 모델이 나온다는 시장에서 6월과 8월의 단가는 게이트웨이가 없었어도 같지 않았을 겁니다.

그래서 저는 78% 를 게이트웨이의 성과가 아니라 가시화의 성과로 읽습니다. 그리고 그건 이 글을 낮춰 보는 게 아니라 정확히 보는 겁니다. 초기 스타트업에서 비용 대시보드를 처음 열어본 팀은 알아요. 어느 기능이 얼마를 쓰는지 보이는 순간 절반은 라우팅 없이도 고쳐진다는 걸요. 인프랩이 LiteLLM Proxy 를 탈락시킨 이유가 바로 이 지점이었다는 게 일관성 있는 대목이고요. 사용량을 자체 UI 안에서만 볼 수 있어서 기존 Prometheus·OpenTelemetry 대시보드에 합칠 수 없었고, 사내 대시보드 한 곳에서 보는 게 목표였으니 그대로 탈락이었죠.

게이트웨이가 서는 조건과 그 아래 깔린 것

구성도만 보면 단순합니다. 게이트웨이 하나가 진입 경로 세 가지를 받아 제공 업체 다섯 곳으로 보내고, 호출하는 쪽은 OpenAI 라이브러리 하나로 Claude 와 Gemini 와 Qwen 을 다 부르죠. 그런데 이 단순함 아래에 깔린 걸 세어 보면 도입 조건이 나와요. Envoy AI Gateway 는 Envoy Gateway 위에서 도는 확장이라 인프랩은 쓰지 않던 Envoy Gateway 를 같이 들여왔고, 라우팅과 인증 정책은 쿠버네티스 커스텀 리소스로 선언해 GitOps 로 관리합니다. 관측성은 이미 돌고 있던 Prometheus·OpenTelemetry 스택에 붙였고요. 새 제공 업체를 붙이는 일이 콘솔 클릭이 아니라 코드 리뷰 붙는 PR 한 건으로 끝난다는 성과는, 이 스택이 이미 있는 팀에서만 성립합니다.

제품 선택의 논리도 같은 결에 있어요. 2025년 11월에 LiteLLM Proxy, Portkey AI Gateway, Envoy AI Gateway 를 비교하고 2026년 9월에 다시 확인한 표에서, 예산·rate limit, 비용 트래킹, 가드레일 칸에 "유료 전용"이 안 붙은 열은 Envoy 뿐입니다. 프롬프트 관리는 아예 없지만 돈을 안 내서 막힌 기능이 없죠. 인프랩이 이걸 결정적이라고 본 이유가 정확해요. 게이트웨이를 두는 목적이 예산 정책, rate limit, 사용량 추적 같은 통제 장치를 한곳에 모으는 건데, 하필 그 통제 장치들이 상용 플랜의 판매 포인트거든요. 무료 플랜으로 시작하면 사용처가 늘어 정책을 조여야 하는 가장 바쁜 시점에 기능마다 플랜 협상을 하게 됩니다. 구매 결정을 최악의 타이밍으로 미루는 셈이라, CNCF 프로젝트라는 점을 기능 표보다 위에 둔 판단에 저는 동의해요.

인증 설계는 이 글에서 제가 제일 좋아하는 결정이에요. 서비스를 구분하려고 게이트웨이용 키를 새로 발급하려다가, 없애려던 키가 다시 늘어나는 게 걸려서 방향을 틀었습니다. 배포 애플리케이션 이름을 API 키 자리에 넣으면 게이트웨이가 허용된 형식인지 검증해 서비스 식별 헤더로 옮기고, X-Service-Feature 헤더로 기능 이름을 하나 더 받아요. 관리할 대상을 늘리지 않고 푸는 방법이 있는지 먼저 찾는다는 원칙이 실제 결정에서 지켜진 드문 사례라 기억해 둘 만합니다.

서른 곳이면 게이트웨이, 세 곳이면 라이브러리

제 판단은 이렇습니다. 쿠버네티스와 GitOps 와 메트릭 스택을 이미 운영하는 DevOps 팀이 있고 LLM 을 부르는 곳이 서른 개를 넘는다면, 인프랩 구성은 그대로 가져가도 됩니다. 등급 계약과 관측성 통합이 같은 값이고, 모델 은퇴가 장애로 이어지는 리스크를 한곳에서 막을 수 있으니까요. 단 첫 교체 전에 등급별 테스트 세트부터 만드세요. 인프랩이 미래 과제로 남긴 그 일이 이 구조의 진짜 시험입니다.

호출하는 곳이 서너 개고 쿠버네티스가 없는 팀이라면 게이트웨이는 오버헤드예요. 그 팀에 필요한 건 공용 클라이언트 라이브러리에 low·medium·high 등급 enum 을 두고, 등급과 모델의 매핑을 설정 파일 하나로 빼는 것까지입니다. 그것만으로 모델 이름을 코드에서 지우는 효과의 대부분을 얻고, 사용처가 늘어 라이브러리 배포가 병목이 되는 시점에 게이트웨이로 옮기면 돼요. 어느 쪽이든 순서는 같습니다. 제품을 고르기 전에 등급 계약부터, 라우팅을 바꾸기 전에 사용량이 보이게.