안녕하세요. 저는 보안 분야에서 10년 넘은 경력을 가지고 최근 Atlassian Forge 기반으로 Flexible Space Navigation, Flexible Table을 개발하고 운영하고 있는 개발자입니다.
“AI 기능을 여러 서비스에 붙이고 있는데, 이걸 어떻게 관리해야 하나요?””
최근 고객사와 지인들에게 비슷한 질문을 자주 받습니다.
처음엔 API 키 하나로 시작했던 게, 서비스가 늘고 모델 공급자가 늘면서 어느새 감당하기 어려워졌다는 이야기입니다. 어떤 팀이 얼마나 쓰는지 파악이 안 되고, 특정 공급자에 장애가 나면 서비스 전체가 중단되기도 하고요.그 중에서도 가장 많이 받는 질문은 “이 프롬프트가 어디로 나가는지”, “누가 이 모델에 접근할 수 있나요? 였습니다.
그래서 이 문제를 정리해보고자, AI Gateway와 그 검토 포인트를 글로 남겨봅니다.
AI Gateway는 애플리케이션과 여러 AI 모델 API 사이에 위치하는 중간 계층입니다. 애플리케이션은 하나의 엔드포인트만 호출하고, 실제 요청은 게이트웨이가 적절한 모델 공급자로 전달합니다.
이 과정에서 인증, 권한, 사용량 제한, 라우팅, 로깅, 비용·토큰 관리, 장애 시 폴백 같은 공통 기능을 중앙에서 처리할 수 있습니다. 공급자마다 다른 API 형식이나 인증 방식도 게이트웨이가 흡수합니다.
중요한 점은 하나 있습니다. AI Gateway가 답변 품질이나 보안을 자동으로 보장해주지는 않습니다. 민감정보 처리, 접근 권한, 로그 정책 등은 별도로 설계해야 합니다.
개인적으로는 이 부분이 가장 중요하다고 봅니다. 실무에서 게이트웨이를 도입하는 팀들을 보면, “게이트웨이만 넣으면 보안이 해결된다”고 오해하는 경우가 의외로 많습니다. 게이트웨이는 통로를 하나로 만들어줄 뿐, 그 통로를 지키는 건 여전히 우리 몫입니다.
AI Gateway는 단순히 “편하게 호출하기 위한 프록시”가 아니라 운영을 위한 계층에 가깝습니다. 실제로는 다음과 같은 이유로 필요해집니다.
| 항목 | 설명 |
|---|---|
| 멀티 모델 환경 대응 | 여러 모델을 조합해 사용하는 순간, 공급자별 API와 인증을 서비스마다 관리하기 어려워집니다. |
| 벤더 종속 리스크 완화 | 특정 공급자에 강하게 결합되면 가격, 성능, 장애 이슈 발생 시 대응 비용이 커집니다. |
| 장애 대응과 폴백 | 단일 공급자에 의존하면 해당 장애가 곧 서비스 장애로 이어집니다. 게이트웨이에서 우회 전략을 구성할 수 있습니다. |
| 비용 통제 | 여러 팀이 각자 API를 호출하면 비용 가시성이 떨어집니다. 중앙 로그가 있어야 예산 관리가 가능합니다. |
| 거버넌스와 보안 | 누가 어떤 모델을 어떤 데이터로 사용하는지 조직 단위에서 통제해야 합니다. |
| 실험과 A/B 테스트 | 애플리케이션 코드를 수정하지 않고도 모델별 성능과 비용을 비교할 수 있습니다. |
이 6가지 중에서 저는 개인적으로 거버넌스와 보안을 가장 우선순위가 높다고 생각합니다. 비용이나 장애는 눈에 보이는 순간 바로 대응할 수 있지만, “누가 어떤 데이터로 어떤 모델을 썼는지” 모르는 상태는 사고가 나기 전까지 드러나지 않거든요.
AI Gateway를 실제로 어떻게 구현할지 정해야 하는데, 선택지는 크게 두 갈래로 나뉩니다.
하나는 Portkey, OpenRouter 같은 상용 SaaS를 구독해서 바로 쓰는 방법입니다. 설정이 빠르고 운영 부담이 없지만, 프롬프트 데이터가 외부 서버를 거치고 매달 사용료가 나갑니다.
다른 하나는 오픈소스를 직접 설치해 운영하는 방법입니다. 데이터가 회사 인프라 밖으로 나가지 않고 라이선스 비용도 없지만, 서버를 띄우고 관리하는 몫은 우리 팀이 떠안게 됩니다.
데이터를 외부로 보내고 싶지 않거나, 트래픽이 많아 SaaS 사용료가 부담스러운 팀이라면 오픈소스 쪽으로 기웁니다.이 오픈소스 진영을 이야기할 때 빠지지 않는 이름이 LiteLLM입니다.
LiteLLM은 다양한 모델 공급자를 OpenAI 호환 API 형태로 사용할 수 있게 해주는 오픈소스입니다 (github.com/BerriAI/litellm). Python 라이브러리로 붙일 수도 있고, 프록시 서버로 배포해 공용 게이트웨이처럼 사용할 수도 있습니다.
오픈소스만으로도 다음과 같은 게이트웨이 운영 기능을 바로 사용할 수 있습니다.
반면 SSO, 조직 단위 권한 관리, 고급 감사 로그 같은 기능은 별도 라이선스(Enterprise) 영역입니다.
LiteLLM 프록시에 요청 하나가 들어오면 내부적으로 몇 단계를 거칩니다.
한 가지 눈에 띄는 설계 포인트가 있습니다. 로깅, 사용량 집계, 콜백 실행이 응답 반환 후 비동기로 처리된다는 점입니다. 요청·응답 경로에는 DB 쓰기가 끼어들지 않아, 로깅 때문에 응답이 느려지는 일이 없어보입니다.
규모가 커지면 이 구조를 하나의 프록시로 묶어서 운영하는 대신, 라우팅,인증, rate limit을 담당하는 게이트웨이(데이터 플레인), 키 관리·예산 추적·DB를 담당하는 백엔드(컨트롤 플레인), 관리 대시보드인 UI로 나눠서 각각 독립적으로 확장 가능하다고 합니다..
여러 서비스가 LiteLLM 하나를 거쳐 다양한 모델 공급자와 통신한다면, 이 지점이 곧 조직 전체의 민감 데이터가 오가는 핵심 관문이 됩니다. 그래서 가장 먼저 확인해야 할 질문은 두 가지입니다.
이 두 질문은 성격이 다르기 때문에 나눠서 봐야 합니다.
프롬프트와 응답 내용을 보호하는 영역은 오픈소스로도 충분히 시작할 수 있습니다.
LiteLLM은 Presidio 기반 PII 마스킹을 지원해 개인정보를 탐지하고 마스킹할 수 있습니다. 또한 Lakera, CrowdStrike AIDR, IBM FMS Guardrails 같은 외부 솔루션과 연동해 프롬프트 인젝션 탐지도 보강할 수 있습니다.
즉, 데이터 자체를 보호하는 문제는 비교적 빠르게 대응이 가능합니다.
반면 “누가 어떤 권한으로 요청했는가”를 통제하는 영역은 다릅니다.
오픈소스에서도 가상 키와 예산 관리 정도는 가능하지만, 사내 SSO 연동, OIDC/JWT 기반 인증, 부서·팀 단위 권한 관리 같은 기능은 Enterprise 영역에서 제공됩니다.
그래서 보안 요구사항은 아래처럼 나눠서 보는 것이 현실적입니다.
| 보안 요구사항 | 가능 여부 |
|---|---|
| 민감정보 마스킹 | 오픈소스로 가능 |
| 프롬프트 인젝션 대응 | 외부 솔루션 연동으로 가능 |
| 가상 키·비용 관리 | 오픈소스로 가능 |
| SSO 및 조직 인증 | Enterprise 필요 |
| 팀 단위 권한 관리 | Enterprise 필요 |
이 표를 보면서 제가 느낀 건, 오픈소스가 “콘텐츠 보안”까지는 커버해주지만 “이 요청을 누가 보냈는가”는 결국 조직이 스스로 답해야 하는 질문이라는 점입니다. 10년 넘게 보안 쪽 일을 해오면서 느낀 건, 사고의 8할은 기술 결함이 아니라 “접근 권한이 누구에게 있는지조차 불분명한 상태”에서 시작된다는 겁니다. 그래서 Enterprise 비용을 아까워하기보다, 이 부분만큼은 신경 써서 설계하시길 권합니다.
AI Gateway는 단순 프록시가 아니라 운영 계층입니다. 비용, 장애 대응, 모델 라우팅, 보안 정책을 한곳에서 다루기 위한 구조입니다.
LiteLLM은 이 구조를 가볍게 검증해보기 좋은 출발점입니다. 라우팅, 폴백, 비용 관리, 로깅, 콘텐츠 보안까지 기본적인 흐름을 빠르게 확인할 수 있습니다.
다만 보안은 두 가지로 나눠서 접근하는 것이 중요합니다. 데이터 자체를 보호하는 문제는 오픈소스로 시작할 수 있지만, 조직의 접근 권한을 통제하는 문제는 Enterprise까지 고려해야 합니다.
이 기준만 명확히 잡아도 도입 범위, 예산, 일정이 훨씬 현실적으로 정리됩니다.
