AI Gateway와 로컬 LLM, 무엇을 선택해야 할까?

이 글은 배포 가이드를 따라 서비스를 올린 뒤 AI 제공업체와 API 구조를 정하는 단계에 있는 독자를 위한 심화 가이드입니다. 어떤 모델 API를 직접 호출할지, 게이트웨이를 둘지, 자체 서버에서 모델을 돌릴지 고민이 시작될 때 읽으면 좋습니다.

AI 서비스를 만들기 시작하면 곧 비슷한 이름의 도구들을 만나게 된다. OpenRouter, Cloudflare AI Gateway, LiteLLM, Ollama, vLLM, SGLang…. 모두 여러 대규모 언어 모델(LLM)을 더 쉽게 쓰게 해주는 것처럼 보인다.

그러나 이들을 한 표에 넣고 단순히 1등부터 순위를 매기면 중요한 차이를 놓치기 쉽다. AI Gateway와 로컬 LLM Runtime은 같은 문제를 해결하는 경쟁 제품이 아니기 때문이다.

AI Gateway는 여러 모델과 제공업체로 가는 요청을 관리한다.
로컬 LLM Runtime은 내가 가진 하드웨어에서 모델을 실제로 실행한다.

쉽게 비유하면 Gateway는 교통 관제 센터이고, Runtime은 자동차의 엔진이다. 목적은 다르지만 함께 사용할 때 더 안정적이고 유연한 AI 인프라를 만들 수 있다.

60초 선택 가이드

지금 상황	먼저 검토할 선택
한 제공업체와 한 모델이면 충분하다	Gateway 없이 해당 API를 직접 호출한다
설정을 최소화하고 여러 클라우드 모델을 비교하고 싶다	OpenRouter
이미 Workers나 Pages를 중심으로 서비스하고 있다	Cloudflare AI Gateway
클라우드와 자체 모델을 하나의 통제된 인터페이스로 묶고 싶다	LiteLLM
노트북이나 워크스테이션에서 비공개 실험을 하고 싶다	Ollama 또는 LM Studio
자체 GPU에서 높은 처리량으로 서비스해야 한다	실제 워크로드로 vLLM 또는 SGLang을 시험한다

이 글은 2026-09-02 기준 각 서비스의 공식 문서를 바탕으로 작성했다. 가격과 기능은 계속 바뀌므로 도입 전 반드시 공식 문서에서 다시 확인해야 한다.

초기 제품의 기본 구조는 완성된 서비스보다 단순한 편이 좋다. 프라이버시, 라우팅, 신뢰성, 지속적인 사용량이 추가 운영 부담을 정당화할 때 Gateway나 자체 Runtime을 도입한다.

직접 API 호출로 충분한 경우

Gateway는 만능이 아니다. 다음에 해당한다면 제공업체 API를 직접 호출하는 편이 낫다.

사용하는 모델과 제공업체가 하나뿐이다.
요청량이 적어 비용 추적이나 폴백(fallback)이 필요 없다.
감사 로그나 데이터 거주성 같은 컴플라이언스 요구가 없다.

이 경우 Gateway는 거쳐야 할 추가 서버일 뿐이다. 지연시간과 운영 지점만 늘어날 수 있으므로, "나중에 필요해질 수도 있다"는 이유만으로 미리 도입하지 않는 편이 좋다.

AI Gateway는 무엇을 해결하는가

처음에는 애플리케이션에서 OpenAI나 Anthropic API를 직접 호출해도 충분하다. 하지만 모델이 늘어나면 상황이 복잡해진다. 제공업체마다 인증, 요청 형식, 오류 처리, 사용량 계산 방식이 다르다. 특정 모델이 느려지거나 장애가 발생했을 때 다른 모델로 전환하는 로직도 필요하다.

AI Gateway는 애플리케이션과 여러 모델 제공업체 사이에 하나의 공통 관문을 둔다. 일반적으로 다음 기능을 제공한다.

하나의 API 형식으로 여러 모델 호출
요청 라우팅과 자동 폴백(fallback)
비용 및 사용량 추적
속도 제한과 지출 한도
요청·응답 로그와 성능 모니터링
캐싱, 가드레일, 팀별 접근 제어

덕분에 애플리케이션 코드는 특정 제공업체에 덜 종속된다. 모델을 교체하거나 새 모델을 시험할 때도 전체 코드를 다시 작성할 필요가 줄어든다.

Gateway가 필요해지는 신호

반대로 다음 신호가 여러 개 겹치기 시작하면 Gateway 도입을 검토할 시점이다.

사용하는 제공업처이나 모델이 3개 이상으로 늘었다.
한 모델의 장애나 속도 저하 때 다른 모델로 자동 전환(폴백)해야 한다.
기능별·팀별 비용 귀속이 필요해졌다.
속도 제한과 지출 한도를 코드 밖에서 통제하고 싶다.
감사 로그나 데이터 거주성 같은 컴플라이언스 요구가 생겼다.
프롬프트 캐싱을 제공업체 경계를 넘어 여러 모델에 걸쳐 활용하고 싶다.

주요 AI Gateway는 어떻게 다른가

OpenRouter: 다양한 모델을 빠르게 시험할 때

OpenRouter의 장점은 폭넓은 모델과 제공업체를 하나의 API로 연결한다는 데 있다. 어떤 모델이 내 서비스에 맞는지 아직 정하지 못한 프로토타이핑 단계나, 같은 프롬프트를 여러 모델에서 비교하고 싶을 때 편리하다.

다만 편의성에는 비용 구조가 따른다. 크레딧 구매 수수료와 BYOK(Bring Your Own Key) 조건은 플랜에 따라 달라질 수 있다. 사용량이 커지기 전 공식 가격 정책을 확인하고, 모델 비용뿐 아니라 플랫폼 비용까지 계산해야 한다.

Cloudflare AI Gateway: Cloudflare 기반 서비스에 자연스러운 선택

이미 Workers, Pages, R2 등 Cloudflare 서비스를 사용한다면 AI Gateway를 기존 구조에 자연스럽게 추가할 수 있다. 분석, 캐싱, 속도 제한뿐 아니라 동적 라우팅, 지출 한도, 가드레일과 데이터 유출 방지 기능도 제공한다. 일부 기능은 베타이거나 플랜별 조건이 있으므로 실제 운영 전에 확인이 필요하다.

특히 전 세계 사용자를 대상으로 하는 서비스에서 에지 네트워크와의 통합은 매력적이다. 반면 Cloudflare 생태계를 사용하지 않는 팀이라면 다른 게이트웨이와 운영 복잡도까지 함께 비교해야 한다.

LiteLLM: 직접 통제하고 싶은 팀을 위한 오픈소스 게이트웨이

LiteLLM은 여러 제공업체를 OpenAI 호환 형식으로 연결하는 셀프호스트형 게이트웨이다. 라우팅, 재시도, 폴백, 예산 관리, 가상 키 같은 기능을 제공하며 클라우드 API뿐 아니라 Ollama나 vLLM 같은 자체 모델 서버도 백엔드로 연결할 수 있다.

라이선스 비용이 없다고 운영비까지 0원인 것은 아니다. 배포, 데이터베이스, 모니터링, 업그레이드, 장애 대응을 직접 책임져야 한다. 따라서 “무료인가?”보다 “우리 팀이 이 시스템을 안정적으로 운영할 수 있는가?”를 먼저 물어야 한다.

Portkey와 Kong: 관찰가능성 또는 엔터프라이즈 거버넌스

Portkey는 요청 단위 추적, 프롬프트 관리, 평가와 같은 운영 관찰 기능이 중요한 팀에 적합하다. Kong은 기존 API 관리 체계와 보안·정책·플러그인을 AI 트래픽에도 적용하려는 엔터프라이즈 조직에 강점이 있다.

이 단계에서는 단순한 모델 수보다 감사 로그, 데이터 거주성, 역할 기반 접근 제어, 가드레일, 기존 시스템과의 통합이 더 중요한 선택 기준이 된다.

로컬 LLM Runtime은 무엇을 해결하는가

Gateway가 요청을 어디로 보낼지 결정한다면, Runtime은 모델 파일을 메모리에 올리고 실제 추론을 수행한다. 로컬 또는 자체 호스팅을 선택하는 이유는 대체로 다음과 같다.

민감한 데이터를 외부 API로 보내고 싶지 않다.
반복적인 대량 요청의 장기 비용을 통제하고 싶다.
네트워크가 없거나 불안정한 환경에서도 사용해야 한다.
지연시간, 동시성, 모델 버전을 직접 최적화해야 한다.

다만 데이터가 내 서버 안에 남는다고 해서 자동으로 안전해지는 것은 아니다. 접근 제어, 로그 보관, 암호화, 취약점 패치, 모델 공급망 관리까지 직접 책임져야 한다.

Ollama와 vLLM은 다른 목적의 도구다

둘 다 "로컬에서 LLM을 실행한다"는 점은 같지만 설계 목적이 다르다. Ollama는 개발자의 노트북에서 빠르게 내려받고 실행하는 데 초점이 있고, vLLM은 GPU 서버에서 높은 처리량으로 다수 요청을 동시에 처리하는 프로덕션 서빙에 초점이 있다. Ollama가 프로토타입과 개발 편의성을 위한 도구라면 vLLM은 서비스 운영을 위한 도구다. 둘을 같은 카테고리의 대안처럼 비교하면 "설치가 쉬운 쪽"만 보고 잘못된 선택을 하기 쉽다.

주요 Runtime은 언제 선택할까

Ollama: 가장 간단한 로컬 개발 경험

Ollama는 개발자의 노트북이나 워크스테이션에서 모델을 빠르게 내려받아 실행할 때 좋다. 로컬 AI 기능을 시험하거나, 인터넷 연결 없이 데모하거나, 개인용 도구를 만들기에 진입 장벽이 낮다.

그러나 설치가 쉽다는 것과 다수 사용자를 안정적으로 처리한다는 것은 다른 문제다. 높은 동시성이 필요한 프로덕션 환경이라면 별도의 성능 시험이 필요하다.

vLLM: GPU 기반 프로덕션 서빙

vLLM은 GPU 메모리 활용과 연속 배치 처리에 초점을 맞춘 고성능 모델 서버다. 여러 사용자의 요청을 동시에 처리하는 내부 AI 플랫폼이나 상용 서비스에 적합하다. OpenAI 호환 API를 제공하므로 기존 애플리케이션과 연결하기도 비교적 쉽다.

대신 GPU 인프라, 모델 호환성, 용량 계획, 모니터링을 다룰 운영 역량이 필요하다. 특정 벤치마크 수치를 그대로 믿기보다 자신의 모델, 프롬프트 길이, 동시 사용자 수로 직접 측정해야 한다.

SGLang: 반복되는 문맥이 많은 워크로드

SGLang은 시스템 프롬프트나 긴 문서의 앞부분을 여러 요청에서 반복 사용하는 RAG와 에이전트 워크플로에 특히 관심을 둘 만하다. 접두부(prefix)를 재사용하는 구조에서 효율을 높일 수 있다. 다만 빠르게 발전하는 프로젝트인 만큼 버전 변화와 모델 지원 범위를 운영 계획에 포함해야 한다.

llama.cpp와 LM Studio: 엣지 또는 GUI 중심 사용

llama.cpp는 GGUF 양자화 모델을 CPU, Apple Silicon, 소형 기기 등 폭넓은 환경에서 실행하는 데 강하다. LM Studio는 그래픽 인터페이스에서 모델을 검색하고 비교하려는 사용자에게 편리하다. 전자는 배포 유연성, 후자는 탐색 경험에 더 초점이 맞춰져 있다.

자체 호스팅을 선택하기 전에 확인할 운영 역량

로컬 Runtime을 프로덕션에 두는 것은 소프트웨어 설치가 아니라 인프라 운영의 시작이다. 다음 역량을 팀이 직접 감당할 수 있는지 먼저 확인한다.

GPU 비용 관리와 하드웨어 업그레이드 계획
모델 업데이트와 보안 패치 적용
모니터링과 장애 대응(온콜 포함)
데이터 백업과 복구 절차

이 중 감당할 수 없는 항목이 있다면 자체 호스팅보다 관리형 서비스를 선택하는 편이 전체 비용과 안정성 면에서 유리하다. 특히 개발 인력이 한두 명뿐인 팀은 GPU 비용보다 사람의 시간이 먼저 한계가 되는 경우가 많다.

가장 현실적인 답은 하이브리드다

실제 서비스에서는 클라우드와 로컬 중 하나만 고를 필요가 없다. 다음과 같은 구성이 더 현실적이다.

애플리케이션은 하나의 OpenAI 호환 API만 호출한다.
LiteLLM 같은 Gateway가 요청의 성격을 판단한다.
개인정보가 포함된 요청이나 반복 업무는 자체 vLLM 서버로 보낸다.
복잡한 추론이나 최신 기능이 필요한 요청은 클라우드 모델로 보낸다.
로컬 GPU가 포화되거나 장애가 나면 허용된 클라우드 모델로 폴백한다.

이 구조는 비용, 성능, 프라이버시를 한 번에 완벽하게 해결하지는 않는다. 대신 요청별로 서로 다른 우선순위를 적용할 수 있게 해준다.

클라우드·로컬·하이브리드 빠른 선택

상황	권장 접근
한 제공업체의 한 모델만 사용하고 요청량이 적다	클라우드 API 직접 호출, Gateway 없음
여러 클라우드 모델을 쓰되 인프라 관리는 맡기고 싶다	관리형 Gateway(OpenRouter, Cloudflare AI Gateway)
민감 데이터나 반복 대량 요청이 핵심이다	로컬 Runtime(vLLM, SGLang) + GPU 운영 역량
비용·프라이버시·품질의 우선순위가 요청마다 다르다	하이브리드(LiteLLM + 클라우드 + 로컬)

도구보다 먼저 답해야 할 다섯 가지 질문

AI 인프라 선택은 기능표보다 요구사항에서 시작해야 한다.

데이터가 외부로 나가도 되는가

규제나 계약상 제한이 있다면 배포 위치와 로그 정책부터 확인한다.

트래픽은 얼마나 예측 가능한가

간헐적 사용은 API가 유리할 수 있고, 지속적인 고사용량은 자체 호스팅이 유리할 수 있다.

몇 개의 모델이 필요한가

한 모델만 쓴다면 Gateway가 불필요한 복잡성을 더할 수도 있다.

누가 운영할 것인가

셀프호스트의 진짜 비용은 GPU뿐 아니라 사람의 시간이다.

장애 때 어떻게 동작해야 하는가

폴백할 모델, 허용 가능한 품질 저하, 데이터 전송 범위를 미리 정해야 한다.

자주 묻는 질문

OpenRouter와 LiteLLM 중 무엇부터 도입해야 할까?

관리 부담을 줄이고 싶다면 OpenRouter부터 시작하는 편이 빠르다. 반면 자체 모델을 함께 쓰거나 비용·접근 제어를 내부에서 통제해야 한다면 LiteLLM을 검토한다. 둘은 단계 차이이지 서로 배타적인 선택은 아니다.

Ollama로 만든 프로토타입을 그대로 프로덕션에 써도 될까?

내부 도구나 소수 사용자라면 가능할 수 있다. 그러나 다수 사용자의 동시 요청이 필요한 서비스라면 vLLM이나 SGLang 같은 서빙 전용 Runtime으로 전환하고, 실제 워크로드로 성능을 측정해야 한다.

로컬 LLM의 비용이 정말 0원인가?

라이선스 비용은 없어도 GPU 구매·대여비, 전력, 모니터링, 업그레이드와 장애 대응 인력 비용이 든다. 요청량이 일정 이상으로 꾸준할 때만 총비용 면에서 클라우드 API보다 유리해진다.

Cloudflare를 쓰지 않으면 Cloudflare AI Gateway를 못 쓰는가?

쓸 수는 있다. 다만 Workers, Pages 같은 Cloudflare 서비스와 함께 쓸 때 운영상 이점이 가장 크다. Cloudflare 생태계 밖이라면 제공업체 중립적인 LiteLLM이나 OpenRouter와 함께 복잡도를 비교하는 편이 낫다.

Gateway는 어느 시점에 도입하는 게 좋을까?

제공업처이나 모델이 3개 이상으로 늘고, 폴백이나 기능별 비용 귀속, 지출 한도 같은 요구가 실제로 생겼을 때다. "나중에 필요할 수도 있다"는 추측만으로 초기에 도입하면 복잡성만 커진다.

결론: 최고의 도구보다 맞는 경계를 선택하라

빠른 실험이 목적이라면 OpenRouter나 Ollama로 시작할 수 있다. Cloudflare 기반 서비스를 이미 운영한다면 Cloudflare AI Gateway가 자연스럽다. 여러 제공업체와 자체 모델을 한곳에서 통제하려면 LiteLLM이 유력하다. 로컬 프로덕션 서빙에는 vLLM이나 SGLang을 검토할 수 있다.

중요한 것은 도구의 순위가 아니다. 어디까지 외부 서비스에 맡기고, 어디부터 직접 통제할 것인지 경계를 정하는 일이다. 그 경계가 분명해지면 Gateway와 Runtime은 경쟁자가 아니라 하나의 아키텍처를 완성하는 두 층이 된다.

이 글은 2026년 9월 공개 정보를 기준으로 작성했다. 가격, 지원 모델, 베타 기능은 바뀔 수 있으므로 도입 전 각 서비스의 공식 문서를 확인해야 한다.

참고 자료

다음으로

배포 가이드로 돌아가기
다른 심화 가이드: 현대식 클라우드 데이터베이스 선택 가이드
본편 3편 AI 레고 스택 — AI 기능을 조립하는 기본 스택 이해하기
본편 10편 데모에서 프로덕션으로 — 실제 운영 기준으로 아키텍처 점검하기
본편 11편 위험, 할루시네이션과 책임 있는 AI — 데이터와 로그의 책임 경계 정하기