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

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

AI Gateway는 여러 모델과 제공업체로 가는 요청을 관리한다.

로컬 LLM Runtime은 내가 가진 하드웨어에서 모델을 실제로 실행한다.

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

AI Gateway는 무엇을 해결하는가

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

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

하나의 API 형식으로 여러 모델 호출

요청 라우팅과 자동 폴백(fallback)

비용 및 사용량 추적

속도 제한과 지출 한도

요청·응답 로그와 성능 모니터링

캐싱, 가드레일, 팀별 접근 제어

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

주요 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로 보내고 싶지 않다.

반복적인 대량 요청의 장기 비용을 통제하고 싶다.

네트워크가 없거나 불안정한 환경에서도 사용해야 한다.

지연시간, 동시성, 모델 버전을 직접 최적화해야 한다.

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

주요 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는 그래픽 인터페이스에서 모델을 검색하고 비교하려는 사용자에게 편리하다. 전자는 배포 유연성, 후자는 탐색 경험에 더 초점이 맞춰져 있다.

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

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

애플리케이션은 하나의 OpenAI 호환 API만 호출한다.

LiteLLM 같은 Gateway가 요청의 성격을 판단한다.

개인정보가 포함된 요청이나 반복 업무는 자체 vLLM 서버로 보낸다.

복잡한 추론이나 최신 기능이 필요한 요청은 클라우드 모델로 보낸다.

로컬 GPU가 포화되거나 장애가 나면 허용된 클라우드 모델로 폴백한다.

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

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

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

데이터가 외부로 나가도 되는가? 규제나 계약상 제한이 있다면 배포 위치와 로그 정책부터 확인한다.

트래픽은 얼마나 예측 가능한가? 간헐적 사용은 API가 유리할 수 있고, 지속적인 고사용량은 자체 호스팅이 유리할 수 있다.

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

누가 운영할 것인가? 셀프호스트의 진짜 비용은 GPU뿐 아니라 사람의 시간이다.

장애 때 어떻게 동작해야 하는가? 폴백할 모델, 허용 가능한 품질 저하, 데이터 전송 범위를 미리 정해야 한다.

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

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

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

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

AI Gateway와 로컬 LLM?

댓글