LiteLLM보다 44배 가볍다는 Go 기반 AI 게이트웨이, GoModel

AI 게이트웨이가 대체 뭐길래

요즘 AI 앱을 만들다 보면 이런 고민이 생깁니다. OpenAI도 쓰고 싶고, Claude도 쓰고 싶고, 로컬에 띄운 Llama도 붙이고 싶은데, 각자 API 형식이 다 달라서 코드가 지저분해진다는 거예요. 그래서 나온 개념이 AI 게이트웨이예요. 이게 뭐냐면, 모든 LLM API를 하나의 통일된 인터페이스로 감싸주고, 요청을 적절한 모델로 라우팅해주고, 로깅·요금 관리·속도 제한까지 해주는 일종의 중간 관리자 서버입니다.

이 분야에서 지금까지 가장 유명했던 건 LiteLLM이에요. Python으로 짜여 있고, 100개가 넘는 LLM 제공자를 OpenAI 호환 API로 감싸주는 기능 때문에 많은 팀이 쓰고 있었죠. 그런데 이번에 GoModel이라는 새로운 대안이 오픈소스로 공개됐습니다. 이름에서 눈치채셨겠지만 Go로 작성됐고, 무엇보다 LiteLLM보다 44배 가볍다는 성능 주장을 들고 나왔어요.

왜 Go로 다시 만들었을까

LiteLLM의 약점은 명확해요. Python 기반이라 동시 요청이 많아지면 GIL(Global Interpreter Lock, 파이썬이 한 번에 한 스레드만 실행하게 막는 제약)에 부딪히고, 메모리 사용량도 꽤 큽니다. 수많은 의존성 패키지를 깔아야 해서 Docker 이미지도 수백 MB 단위로 부풀어요. 프록시 하나에 이 정도 리소스가 필요한 건 좀 과하다는 불만이 있었죠.

GoModel은 이 지점을 공략합니다. Go 언어 자체가 가벼운 고루틴으로 수만 개 동시 연결을 저렴하게 다룰 수 있고, 바이너리 하나로 배포되니까 컨테이너 이미지도 작아요. 44배 가볍다는 수치는 메모리 풋프린트와 이미지 크기 기준인 것으로 보이고, 실제로 Go로 짠 유사한 프록시들(예: Traefik, Caddy)이 Python/Node.js 대비 보여주는 수치와 비슷한 범위예요.

핵심 기능과 구조

GoModel이 제공하는 기능은 일반적인 AI 게이트웨이가 갖춰야 할 것들을 그대로 담고 있어요. OpenAI 호환 엔드포인트 하나로 여러 제공자를 호출할 수 있게 해주고, API 키를 여러 개 돌려가며 쓰는 키 로테이션이 되고, 요청별로 어떤 모델에 보낼지 정하는 라우팅 규칙을 설정할 수 있습니다. 실패 시 다른 모델로 넘기는 폴백, 사용량 기반 속도 제한, 비용 추적 같은 운영에 꼭 필요한 기능들도 있어요.

구조적으로는 상당히 심플해 보이는데, 설정 파일 하나에 제공자 목록과 라우팅 규칙을 정의하고 바이너리를 띄우면 끝이에요. 쿠버네티스 사이드카로 붙이기도 좋고, 엣지에서 돌리기도 부담이 적습니다.

경쟁자들과 비교하면

이 영역엔 이미 여러 선수가 있어요. LiteLLM은 생태계와 기능이 가장 풍부하지만 무겁고, Portkey는 상용 서비스로 잘 만들어졌지만 셀프호스팅 옵션이 제한적이에요. OpenRouter는 호스팅 서비스라 직접 운영이 필요 없는 대신 외부 의존성이 생기고요. Cloudflare AI Gateway는 엣지에서 돌지만 Cloudflare 생태계에 묶입니다.

GoModel의 포지션은 "가볍게 셀프호스팅하고 싶은 팀"을 정확히 노리는 느낌이에요. 아직 초창기 프로젝트라 생태계는 부족하지만, 커뮤니티가 기여만 잘 붙으면 LiteLLM의 Go 버전 같은 위치를 노려볼 만해 보입니다.

한국 개발자에게 어떤 의미일까

국내에서도 AI 서비스를 만드는 팀이 폭발적으로 늘면서, 여러 LLM을 섞어 쓰는 구조가 점점 일반적이 되고 있어요. GPT-4는 품질이 좋지만 비싸고, Claude는 긴 컨텍스트가 강점이고, 한국어는 의외로 Solar나 HyperCLOVA X가 좋은 경우도 있거든요. 이런 멀티 모델 환경에서 게이트웨이는 선택이 아니라 필수에 가깝습니다.

Go로 짜인 가벼운 바이너리는 특히 온프레미스 환경이나 비용 민감한 스타트업에 유리해요. 금융·공공처럼 외부 SaaS를 못 쓰는 곳, 또는 작은 팀이 Lambda나 Cloud Run에 붙여 쓰기에 딱이죠. 다만 아직 안정성이 검증되지 않았으니, 프로덕션 도입 전엔 직접 부하 테스트와 장애 시나리오 검증이 필요합니다. 사이드 프로젝트나 내부 도구부터 시험해보는 게 안전한 길이에요.