엔터프라이즈 애플리케이션과 대규모 언어 모델 (LLM) 사이의 보안이 유지되고, 관찰 가능하며, 벤더 중립적인(vendor-agnostic) 플랫폼을 구축하는 방법

우리가 처음 출시한 AI 기능은 일주일도 채 걸리지 않았습니다. 제품 팀이 유스케이스(use case)를 식별하고, 대규모 언어 모델 (LLM)을 선택하고, 백엔드에 API 호출을 추가한 뒤 사용자에게 응답을 반환했습니다.

6개월 후, 상황은 매우 달라졌습니다. 5개의 별도 팀이 AI를 통합하고 있었는데, 각 팀은 자신만의 모델 제공업체, 자체적인 재시도 로직 (retry logic), 그리고 다른 팀들과 조용히 차이가 벌어진 자신들만의 프롬프트 템플릿 (prompt template) 사본을 가지고 있었습니다. 아무도 왜 한 애플리케이션의 월간 비용이 유사해 보이는 워크로드(workload)를 가진 다른 애플리케이션보다 3배나 더 높은지 확신을 가지고 말할 수 없었습니다.

우리는 LLM 문제가 있었던 것이 아닙니다. 플랫폼 문제가 있었던 것입니다.

"모델을 호출하는 것"과 "조직 전체에서 AI를 안정적으로 실행하는 것" 사이의 그 간극이 바로 이 글에서 다루고자 하는 내용입니다.

대부분의 엔터프라이즈 AI 애플리케이션은 놀라울 정도로 단순한 아키텍처로 시작합니다.

제품 팀이 유스케이스를 식별하고, 대규모 언어 모델 (LLM)을 선택하고, 백엔드에 API 호출을 추가한 뒤 사용자에게 응답을 반환합니다. 초기 프로토타입(prototype) 단계에서는 이 접근 방식이 빠르고 효과적입니다.

Application
     │
     ▼
...

이러한 단순함은 생성형 AI (generative AI) 도입이 매우 빠르게 진행된 이유 중 하나입니다. 소규모 엔지니어링 팀은 전체 머신러닝 (machine-learning) 플랫폼을 먼저 구축하지 않고도 요약 도구, 콘텐츠 어시스턴트, 지원 코파일럿 (support copilot) 또는 문서 분석기를 구축할 수 있습니다.

문제는 프로토타입이 성공했을 때 나타납니다.

다른 팀들이 자신들만의 AI 기능을 구축하기 시작합니다. 고객 지원 애플리케이션은 한 모델 제공업체를 호출하고, 마케팅 플랫폼은 다른 곳을 호출하며, 내부 엔지니어링 어시스턴트는 세 번째 통합 방식을 사용합니다. 각 애플리케이션은 자체적인 인증 (authentication), 재시도 로직 (retry logic), 프롬프트 템플릿 (prompt templates), 타임아웃 처리 (timeout handling), 토큰 추적 (token tracking) 및 안전 점검 (safety checks)을 구현하기 시작합니다.

조직은 여러 개의 독립적인 AI 애플리케이션을 만들었다고 믿을 수도 있습니다. 하지만 실제로는 동일한 인프라의 약간씩 다른 버전들을 여러 개 만든 것에 불과합니다.

이 지점이 바로 기존의 직접 통합 (direct-integration) 모델이 무너지기 시작하는 곳입니다.

직접적인 모델 통합이 작동하지 않는 시점

세 개의 AI 기반 제품을 운영하는 조직을 가정해 보겠습니다.

고객 지원 (customer-support) 플랫폼은 LLM을 사용하여 사례를 요약하고 답변 초안을 작성합니다. 마케팅 애플리케이션은 캠페인 카피를 생성합니다. 엔지니어링 어시스턴트는 기술 문서를 분석하고 내부 질문에 답변합니다.

초기에는 각 팀이 외부 모델 제공업체 (model provider)에 직접 연결합니다.

고객 지원 ─────────► 모델 제공업체 A

마케팅 플랫폼 ───────► 모델 제공업체 A
...

각 팀은 자체적인 통합 방식을 소유하며 독립적으로 움직일 수 있습니다. 이러한 유연성은 처음에는 유용해 보이지만, 중복 (duplication)을 초래하기도 합니다.

지원 팀은 제공업체가 일시적인 오류를 반환할 때 재시도 (retries) 로직을 구현합니다. 마케팅 팀은 서로 다른 제한 사항을 가진 별도의 재시도 로직을 만듭니다. 엔지니어링 팀은 자체적인 타임아웃 (timeout) 정책을 추가합니다.

한 팀은 애플리케이션 코드에 프롬프트 (prompts)를 저장합니다. 다른 팀은 구성 파일 (configuration files)에 저장합니다. 세 번째 팀은 데이터베이스에 프롬프트 템플릿 (prompt templates)을 유지 관리합니다.

한 팀은 토큰 사용량 (token usage)을 기록합니다. 다른 팀은 요청 지연 시간 (request latency)만 기록합니다. 세 번째 팀은 모델 수준의 관측성 (observability)이 전혀 없습니다.

이러한 차이점들은 개발 단계에서는 명확히 드러나지 않을 수 있는 운영상의 문제들을 야기합니다.

만약 조직이 제공업체의 자격 증명 (credential)을 교체해야 한다면, 여러 서비스를 수정해야 합니다. 특정 모델을 사용할 수 없게 되면, 모든 애플리케이션이 각자 자체적인 폴백 (fallback) 로직을 구현해야 합니다. 보안 팀이 개인 식별 정보 (personally identifiable information)에 대한 새로운 규칙을 도입하면, 동일한 보호 조치를 모든 통합 지점에 개별적으로 추가해야 합니다.

더 많은 애플리케이션이 AI를 채택할수록, 이러한 중복 비용은 더욱 커집니다.

단일 API 호출 뒤에 숨겨진 문제들

LLM (Large Language Model)을 호출하는 것은 단 한 번의 네트워크 요청처럼 보이지만, 프로덕션 품질 (production-quality)의 AI 요청에는 수많은 결정 사항이 포함됩니다.

모델이 호출되기 전에 시스템은 애플리케이션을 인증하고, 입력을 검증하며, 민감한 정보를 식별하고, 승인된 프롬프트 (prompt)를 검색하고, 비즈니스 컨텍스트 (business context)를 추가하고, 토큰 사용량을 추정하고, 할당량 (quota)을 확인하며, 적절한 모델을 선택해야 할 수도 있습니다.

모델이 응답한 후에는 시스템이 출력을 검증하고, 안전 규칙 (safety rules)을 적용하며, 토큰 소비를 기록하고, 비용을 계산하고, 제공자별 응답을 정규화 (normalize)하며, 디버깅을 위한 충분한 메타데이터 (metadata)를 저장해야 할 수도 있습니다.

더 현실적인 요청 라이프사이클 (request lifecycle)은 다음과 같습니다:

Application Request
        │
        ▼
...

만약 모든 애플리케이션이 이 라이프사이클을 독립적으로 구현한다면, 조직은 결국 시스템 전체에 걸쳐 일관되지 않은 동작, 중복된 코드, 그리고 특정 제공자에 종속된 의존성 (provider-specific dependencies)을 쌓아가게 됩니다.

이제 문제는 모델을 어떻게 호출하느냐가 아닙니다.

문제는 여러 애플리케이션과 팀에 걸쳐 AI에 대한 신뢰할 수 있는 접근을 어떻게 제공하느냐입니다.

AI 게이트웨이 (AI Gateway) 소개

AI 게이트웨이 (AI Gateway)는 엔터프라이즈 애플리케이션과 모델 제공자 (model providers) 사이에 위치하는 중앙 집중식 플랫폼입니다.

애플리케이션은 더 이상 Amazon Bedrock, Anthropic, OpenAI 또는 다른 모델 플랫폼을 직접 호출하지 않습니다. 대신, 게이트웨이에 구조화된 요청을 보냅니다.

                        Enterprise Applications

          ┌────────────────┬────────────────┬────────────────┐
...

AWS 중심의 스택에서 이는 단순히 개념적인 상자가 아닙니다. 게이트웨이는 일반적으로 네트워크 에지(network-edge) 관련 사항(TLS, 스로틀링 (throttling), API 키)을 처리하기 위해 Amazon API Gateway 뒤에 위치하며, 부하 형태에 따라 ECS 또는 Lambda에서 자체 로직을 실행합니다. 시맨틱 캐시 (semantic cache)와 속도 제한 카운터 (rate-limit counters)는 Redis (ElastiCache)에 유지하고, 프롬프트 버전과 라우팅 정책은 DynamoDB에 영구 저장하며, 관찰된 모든 데이터를 CloudWatch로 전송합니다. Amazon Bedrock은 Anthropic 또는 OpenAI와의 직접적인 통합과 함께 게이트웨이 뒤에 있는 여러 모델 제공자 중 하나가 됩니다. 이러한 인프라가 AI 게이트웨이를 구축하는 데 반드시 필요한 것은 아닙니다. 이 패턴은 제공자 중립적 (provider-agnostic)입니다. 하지만 이는 AWS에서 게이트웨이를 구축하는 흔하고 검증된 방식입니다.

팀들이 자주 논의하는 설계 결정 중 하나는 게이트웨이 자체를 서버리스 함수 (serverless functions)로 실행할 것인지, 아니면 장기 실행 서비스 (long-running service)로 실행할 것인지 여부입니다. 가벼운 오케스트레이션 (orchestration)이 필요한 간헐적인 워크로드의 경우, Lambda는 운영 오버헤드를 줄일 수 있습니다. 관리할 플릿 (fleet)이 없고, 요청 사이의 비용이 0으로 스케일 다운됩니다. 복잡한 라우팅을 수행하거나, 지속적인 캐시를 유지하거나, 여러 다운스트림 서비스 (downstream services)를 조정해야 하는 게이트웨이의 경우, ECS 또는 Kubernetes 기반의 컨테이너 배포가 더 예측 가능한 성능과 운영 유연성을 제공하는 경우가 많습니다. 이는 Redis 및 내부 상태(internal state)에 대한 연결을 매번 콜드 스타트 (cold start) 시마다 다시 설정할 필요가 없기 때문입니다. 여기에 보편적인 정답은 없습니다. 올바른 선택은 AI 모델 자체가 아니라 워크로드의 특성에 달려 있습니다.

게이트웨이는 애플리케이션 팀으로부터 제공자별 세부 사항을 숨기면서 안정적인 내부 API를 제공합니다.

마케팅 애플리케이션은 어떤 정확한 모델이 카피를 생성했는지 알 필요가 없어야 합니다. 애플리케이션은 작업, 컨텍스트 (context), 그리고 예상되는 출력을 설명하는 요청을 보내야 합니다. 게이트웨이는 어떤 모델을 호출할지, 최종 프롬프트를 어떻게 구성할지, 그리고 선호하는 제공자를 사용할 수 없는 경우 어떤 폴백 (fallback)을 사용할지를 결정해야 합니다.

예를 들어, 애플리케이션은 다음과 같은 요청을 보낼 수 있습니다:

{
  "task": "generate_marketing_copy",
  "context": {
...

애플리케이션은 인프라를 선택하는 것이 아니라 비즈니스 의도 (business intent)를 표현하고 있는 것입니다.

그러면 게이트웨이는 승인된 프롬프트 버전 (prompt version)을 검색하고, 품질 및 지연 시간 (latency) 요구 사항에 따라 모델을 선택하며, 보안 제어 (security controls)를 적용하고, 제공업체 (provider)를 호출한 다음, 정규화된 응답 (normalized response)을 반환할 수 있습니다.

이러한 분리가 AI 게이트웨이 (AI Gateway)의 핵심 가치입니다.

애플리케이션 팀은 제품의 동작에 집중합니다. 플랫폼 팀은 AI를 안전하고 신뢰성 있게 운영하는 데 필요한 엔지니어링 관련 사항들을 담당합니다.

AI 게이트웨이는 API 게이트웨이 그 이상입니다

기존의 API 게이트웨이 (API Gateway)가 이미 이 문제를 해결할 수 있는지에 대한 합리적인 의문이 생길 수 있습니다.

전통적인 API 게이트웨이는 인증 (authentication), 라우팅 (routing), 스로틀링 (throttling), 그리고 요청 정책 (request policies)을 관리하는 데 탁월합니다. 이러한 기능들은 여전히 유용하지만, AI 트래픽은 기존 게이트웨이가 원래 관리하도록 설계되지 않은 추가적인 고려 사항들을 도입합니다.

전통적인 게이트웨이는 주로 엔드포인트 (endpoints)와 네트워크 정책을 기반으로 요청을 라우팅합니다. 반면 AI 게이트웨이는 작업 (task), 프롬프트 버전 (prompt version), 고객 등급 (customer tier), 토큰 예산 (token budget), 지연 시간 목표 (latency target), 모델 가용성 (model availability), 또는 데이터 민감도 (data-sensitivity) 요구 사항을 기반으로 요청을 라우팅할 수 있습니다.

전통적인 게이트웨이는 요청 횟수와 응답 시간을 측정합니다. AI 게이트웨이는 또한 토큰 사용량 (token usage), 프롬프트 버전 (prompt versions), 모델별 오류 (model-specific errors), 제공업체 비용 (provider costs), 캐시 효율성 (cache effectiveness), 그리고 출력 품질 신호 (output-quality signals)를 이해해야 합니다.

전통적인 게이트웨이는 일반적으로 요청 본문 (request body)을 애플리케이션 데이터로 취급합니다. AI 게이트웨이는 프롬프트 인젝션 (prompt injection), 민감 정보 (sensitive information), 지원되지 않는 지침 (unsupported instructions), 과도한 컨텍스트 (excessive context), 또는 콘텐츠 정책 위반 (content-policy violations) 여부를 확인하기 위해 해당 본문을 검사해야 할 수도 있습니다.

AI 게이트웨이는 전통적인 API 게이트웨이를 대체하는 것이 아닙니다. 많은 아키텍처에서 두 가지 모두 사용됩니다.

API 게이트웨이는 네트워크 경계에서 서비스를 보호하고 노출합니다. AI 게이트웨이는 그 뒤에서 AI 요청의 특화된 라이프사이클 (lifecycle)을 관리합니다.

AWS에서의 구체적인 배포 사례를 통해 이를 더 쉽게 그려볼 수 있습니다:

Users
  │
  ▼
...

두 게이트웨이는 서로 다른 계층에서 서로 다른 작업을 수행하며, 이것이 바로 조직이 하나를 선택하기보다 두 가지를 모두 운영하는 경향이 있는 정확한 이유입니다.

설계 목표 (The design goal)

AI 게이트웨이의 목표는 모든 AI 의사결정을 소유하는 또 다른 거대한 중앙 집중식 서비스를 만드는 것이 아닙니다.

그 목적은 일관된 기반을 제공하는 데 있습니다.

잘 설계된 게이트웨이는 모든 애플리케이션 팀이 통합 방식을 재구축하도록 강요하지 않으면서도, 모델을 변경하고, 새로운 제공업체 (Provider)를 도입하며, 조직 전체의 정책을 집행하고, 비용을 모니터링하며, 신뢰성을 개선하는 것을 더 쉽게 만들어야 합니다.

또한 병목 현상 (Bottleneck)이 되는 것도 피해야 합니다.

이는 게이트웨이가 명확한 인터페이스를 노출하고, 독립적인 확장 (Scaling)을 지원하며, 가능한 한 비즈니스 특화 동작을 핵심 플랫폼 외부로 유지해야 함을 의미합니다.

가장 강력한 AI 게이트웨이 설계는 쉽게 충돌할 수 있는 두 가지 목표 사이에서 균형을 잡습니다. 즉, 조직 전체에서 일관되어야 하는 관심사들은 중앙 집중화하는 동시에, 개별 제품이 독립적으로 진화할 수 있는 충분한 유연성을 보존하는 것입니다.

이러한 원칙을 바탕으로, 다음 질문은 실제 요청이 도착했을 때 게이트웨이 내부에서 실제로 어떤 일이 일어나는가 하는 점입니다. 이는 하나의 요청을 처음부터 끝까지 추적함으로써 가장 쉽게 이해할 수 있습니다.

게이트웨이를 통한 요청 추적 (Following a request through the gateway)

AI 게이트웨이는 애플리케이션과 언어 모델 (Language Model) 사이에 위치하는 프록시 (Proxy) 그 이상입니다.

진정한 가치는 모델 호출 (Model invocation) 전후에 발생하는 모든 과정에서 나옵니다.

그 이유를 이해하기 위해, 시스템을 통과하는 단일 요청을 따라가 보겠습니다.

제품 관리자(Product Manager)가 내부 마케팅 애플리케이션을 열고 **"제품 설명 생성 (Generate Product Description)"**을 클릭한다고 가정해 봅시다.

프론트엔드 (Frontend)는 요청을 Spring Boot 백엔드로 보내고, 백엔드는 이를 AI 게이트웨이로 전달합니다.

게이트웨이는 즉시 LLM을 호출하는 대신, 일련의 검증 및 오케스트레이션 (Orchestration) 단계를 시작합니다.

Application
      │
      ▼
...

애플리케이션은 단일 요청과 단일 응답을 보지만, 게이트웨이는 배후에서 상당한 양의 작업을 수행합니다.

각 단계를 살펴보겠습니다.

1단계: 인증 (Authentication) 및 인가 (Authorization)

게이트웨이의 첫 번째 책임은 신뢰를 구축하는 것입니다.

모든 애플리케이션은 외부 모델 제공업체(model providers)를 위한 자격 증명(credentials)을 직접 저장하는 대신, 게이트웨이를 통해 인증을 수행해야 합니다.

이는 다음과 같은 여러 가지 이점을 제공합니다.

API 키가 수십 개의 마이크로서비스(microservices)에 분산되는 대신 중앙에서 관리됩니다.

액세스 정책(Access policies)을 일관되게 적용할 수 있습니다.

개별 애플리케이션의 비즈니스 요구 사항에 따라 서로 다른 사용량 제한(usage limits)을 할당할 수 있습니다.

예를 들어, 내부 엔지니어링 어시스턴트(engineering assistant)는 프리미엄 추론 모델(reasoning models)에 접근할 수 있도록 허용되는 반면, 고객 대상 챗봇(chatbot)은 저비용 모델로 제한될 수 있습니다.

애플리케이션의 관점에서는 아무것도 변하지 않습니다.

애플리케이션은 조직의 기존 ID 메커니즘(identity mechanism)을 사용하여 게이트웨이와 인증할 뿐입니다.

게이트웨이가 외부 제공업체와 안전하게 통신하는 책임을 맡게 됩니다.

2단계: 입력 검증 (Input Validation)

인증에 성공하면 요청 자체를 검증해야 합니다.

전통적인 API와 달리, AI 시스템은 대체로 비정형화된(unstructured) 입력을 수용합니다.

이러한 유연성은 리스크를 유발합니다.

프로덕션 게이트웨이는 다음 사항을 확인해야 합니다:

• 필수 필드(required fields)가 존재하는지
• 프롬프트(prompt) 크기가 허용 가능한 범위 내에 있는지
• 지원되지 않는 요청 유형(request types)이 거부되는지
• 잘못된 형식의 요청(malformed requests)이 모델에 도달하지 않는지