GS리테일의 전사 AI Gateway 구축 사례 – 1부: 인증·라우팅·계정 자동화 설계

이 블로그는 GS리테일과 AWS의 협업으로 작성되었습니다.

다양한 AI 서비스를 안전하게 활용하기 위한 단일 운영 플랫폼 구축

수백 개 팀 계정의 AI 호출을 하나의 관문에서 인증·비용·쿼터 단위로 통제할 수 있을까요?

생성형 AI는 이제 기업의 업무 환경에 빠르게 자리 잡고 있습니다. 개발자는 코드 작성을 위해 AI를 활용하고, 기획자는 문서 작성과 아이디어 발굴에 AI를 사용하며, 데이터 분석가는 AI를 통해 인사이트를 도출합니다. 최근에는 AI Agent를 활용해 업무를 자동화하려는 시도도 빠르게 확산되고 있습니다.

하지만 기업이 여러 AI 서비스를 동시에 도입하기 시작하면 새로운 과제가 나타납니다. 조직 구성원들은 Claude Code, Claude Cowork, Codex 등 다양한 도구를 사용하고 싶어하고, 조직은 비용 추적과 보안 통제, 감사 로깅을 확보하고자 합니다. 도구가 하나 늘어날 때마다 별도의 관리 체계를 만드는 방식으로는 이 속도를 따라잡기 어렵습니다. 또한 동일한 AI 모델을 사용하더라도 조직마다 다른 API Key를 관리하거나, 사용량을 추적할 수 없는 환경에서는 운영과 거버넌스를 유지하기 어렵습니다.

특히 대규모 조직에서는 이러한 문제가 더욱 두드러집니다. AI 서비스를 빠르게 도입하는 것만큼이나 누가, 어떤 모델을, 어떤 목적으로 사용하고 있는지 관리할 수 있는 체계가 필요합니다. 생성형 AI의 활용이 조직 전반으로 확대될수록 AI를 안전하고 지속 가능하게 운영하기 위한 플랫폼의 중요성도 함께 커지고 있습니다.

그림 1. GS리테일 전사 AI Gateway의 주요 기능과 운영 구성 요소

GS리테일 클라우드인프라팀 역시 이러한 과제를 해결하기 위해 전사 AI 활용 환경을 재검토했습니다. 단순히 하나의 AI 서비스를 도입하는 것이 아니라, 다양한 AI 애플리케이션과 AI Agent가 공통으로 사용할 수 있는 전사 AI Gateway를 구축해 AI 호출을 하나의 관문으로 통합하고, 보안과 비용, 운영 정책을 일관되게 관리하는 구조를 설계했습니다.

이 사례의 특징은 Gateway 구축과 함께 실사용을 위한 운영 체계를 마련했다는 점입니다. 비개발 직군을 위한 설치 자동화, 예산 소진 시 자동 모델 다운그레이드, 조직도 동기화, 자체 가드레일과 관측 파이프라인, 리더를 위한 관리자 대시보드까지, 실제 사용자가 늘어나면서 필요해진 기능을 추가해가며 운영 성숙도를 높였습니다.

이 글에서는 그 구축 배경과 아키텍처, 주요 설계 원칙, 실제 운영 과정에서 확보한 AI 거버넌스 경험을 포함해 Gateway를 AI 활용 공통 인프라로 확장해나가는 여정을 소개합니다.

GS리테일 클라우드인프라팀과 AI Gateway 도입 배경

GS리테일은 편의점 GS25, 슈퍼마켓 GS THE FRESH, O4O 플랫폼 우리동네GS, 홈쇼핑·이커머스 GS SHOP을 운영하는 대한민국 대표 유통기업입니다. 매일 수천만 명이 이용하는 이 서비스가 끊김 없이 돌아가는 뒤에는 클라우드인프라팀이 있습니다. 24/7 모니터링과 장애 대응을 넘어, 전사 클라우드 아키텍처 표준과 보안·비용 거버넌스, 계정·네트워크 설계까지 각 사업 조직이 안정적으로 서비스를 운영할 수 있는 공통 플랫폼을 책임지는 조직입니다. 또한 새로운 기술이 등장할 때마다 이를 먼저 검토하고 전사가 쓸 수 있는 표준으로 다듬는 것은 클라우드인프라팀의 일이며 생성형 AI도 그 연장선상에 있었습니다.

최근 GS리테일은 전사적으로 다양한 AX(AI Transformation) 과제를 추진해 왔습니다. 상품·마케팅·점포운영·고객상담 등 여러 도메인에서 AI를 적용하는 프로젝트가 동시다발적으로 진행되었고, 그 과정에서 사내 AI 활용이 빠르게 확대되었습니다. 개발 조직은 코드 작성·리뷰·분석에 AI를 상시 활용하기 시작했고, 현업 부서에서도 문서 작성·데이터 분석 같은 일상 업무에 AI를 쓰려는 움직임이 확산되었습니다. Claude Code, Claude Cowork 같은 AI 어시스턴트를 쓰고 싶다는 요구가 곳곳에서 쏟아졌습니다.

AI 활용이 늘면서 개별 과제별 대응만으로는 한계가 생겼고, 공통 플랫폼이 필요해졌습니다. 어떤 모델을 누가 어디까지 쓸 수 있는지, 사내 데이터가 어떻게 다뤄지는지, 비용이 어느 조직에 얼마나 발생하는지 요구가 들어올 때마다 개별로 답할 수 있는 질문이 아니었습니다. 조직 차원의 답이 필요했고, 그 답을 설계하는 일은 클라우드인프라팀의 몫이었습니다. GS리테일은 생성형 AI를 특정 조직의 PoC로 끝낼 생각이 없었고, 여러 조직이 공통으로 쓸 수 있는 환경을 처음부터 목표로 했습니다.

그림 2. 전사 AI 활용 확대 과정에서 나타난 인증·비용·보안 과제

그러나 여러 AI 서비스를 동시에 활용하는 환경에서는 예상보다 빠르게 운영상의 문제가 발생했습니다.

1. AI 서비스와 인증의 분산

조직과 프로젝트마다 서로 다른 AI 서비스를 개별적으로 도입하면 동일한 목적의 AI 모델이라도 서로 다른 인증 방식과 API Key를 사용하게 됩니다. 시간이 지날수록 어떤 서비스가 사용되고 있는지, 누가 어떤 모델을 사용하는지 파악하기 어려워지고, 운영 복잡성도 함께 증가합니다.

2. 비용과 사용량의 가시성 부족

생성형 AI는 호출 횟수뿐 아니라 입력·출력 토큰 수에 따라 비용이 달라집니다. 조직별 사용량과 모델별 비용을 실시간으로 파악하지 못하면 예산을 계획하거나 이상 사용 패턴을 조기에 발견하기 어렵습니다. 또한 팀별/개인별 예산 한도를 설정하여 초과 시 사용을 차단하는 등의 비용 통제가 필요했습니다.

3. 보안과 거버넌스

기업에서는 조직별 접근 권한, 모델 사용 정책, 감사 로그와 같은 운영 기준을 일관되게 적용해야 합니다. 그러나 AI 서비스마다 인증 체계와 관리 방식이 다르면 이러한 정책을 통합적으로 운영하기 어렵습니다. 또한 개인 계정을 기반으로 외부 AI 도구들을 활용하게 되면 민감 정보 입력에 따른 데이터 유출 위험을 사전에 탐지하기 어렵습니다.

이러한 문제는 특정 AI 서비스의 기능만으로 해결하기 어렵습니다. 새로운 AI 모델이 추가되더라도 기존 운영 체계를 그대로 유지할 수 있는 구조, 즉 AI 모델과 애플리케이션 사이에서 공통 정책을 적용하는 플랫폼 계층이 필요했습니다.

GS리테일은 이러한 요구사항을 바탕으로 모든 AI 요청이 하나의 관문을 통과하도록 설계했습니다. 애플리케이션은 AI 모델을 직접 호출하지 않고 AI Gateway를 통해 요청을 전달하며, Gateway는 인증, 권한 관리, 비용 추적, 감사 로그, 운영 정책을 공통으로 적용한 뒤 적절한 AI 모델로 요청을 전달합니다.

이 구조를 통해 AI 모델이 변경되거나 새로운 서비스가 추가되더라도 애플리케이션은 동일한 인터페이스를 유지할 수 있으며, 운영 정책 역시 중앙에서 일관되게 관리할 수 있도록 설계했습니다.

Claude on Amazon Bedrock + AI Gateway 구조를 선택한 이유

GS리테일 전사 AI Gateway를 설계하면서 가장 먼저 결정해야 했던 것은 개발 환경의 표준 AI 서비스였습니다.

GS리테일은 개발자를 위한 AI 코딩 환경으로 Claude Code on Amazon Bedrock을, 현업 사용자들을 위한 표준 AI 활용 환경으로 Claude Cowork on Bedrock을 선택했습니다. Claude Code는 뛰어난 코드 생성과 리팩터링, 코드 이해 능력을 제공하며 Claude Cowork는 비개발자들에게도 친숙한 클라이언트 기반 사용 환경을 제공하기 때문이고, 둘 모두 Amazon Bedrock을 통해 사용할 경우 기업 환경에서 요구되는 보안과 운영 요구사항을 함께 충족할 수 있기 때문입니다.

특히 GS리테일은 다음과 같은 기준을 중요하게 고려했습니다.

특히 GS리테일에게 결정적이었던 것은 데이터가 통제된 경계 안에 머무는 것이었습니다. Amazon Bedrock은 입력·출력 데이터를 모델 제공자나 제3자와 공유하지 않으며, 선택한 AWS 리전 밖으로 데이터를 이동·복제하지 않습니다. 또한 GS리테일의 사내 보안 기준을 충족하기 위해서는 퍼블릭 인터넷 망을 경유하지 않으면서도 VPC/PrivateLink를 통한 네트워크 격리가 가능해야 했는데, 이 구조로 두 요건을 함께 충족할 수 있었습니다.

비용 측면에서도 Pay-as-you-go가 합리적이었습니다. 700개 팀, 수천 명 규모에서 일부 개발자는 매일 활발히 사용하지만, 많은 직원은 주 1-2회 사용하거나 거의 사용하지 않습니다. 이러한 불균등한 사용 패턴에서는 시트당 고정 비용보다 실제 사용한 토큰만큼만 과금되는 방식이 전체 비용을 크게 낮출 수 있었습니다.

한편, Claude Enterprise 또는 Claude Platform on AWS에서만 네이티브로 제공되는 고유 기능(Web Search, Files, Memory 등)은 Amazon Bedrock 연결을 통해서는 기본적으로 사용할 수 없습니다. GS리테일은 이 중 가장 필요했던 Web Search를 AI Gateway 레벨에서 서버사이드로 자체 구현하여 보완했습니다. 이 내용은 뒤에서 자세히 다룹니다.

하지만 Claude on Amazon Bedrock을 선택했다고 해서 운영 문제가 모두 해결되는 것은 아니었습니다. 여러 AI 모델을 함께 사용하고, 조직별 정책을 적용하며, 비용과 사용량을 중앙에서 관리하기 위해서는 Bedrock 앞단에서 동작하는 별도의 운영 계층이 필요했습니다.

이 요구사항은 기업 환경에서 생성형 AI를 지속적으로 운영하기 위한 기반이었습니다.

GS리테일은 이 운영 계층으로 LiteLLM 기반 AI Gateway를 구축했습니다.

AI Gateway 아키텍처

AI Gateway란 무엇인가

AI Gateway, 통칭 LLM Gateway는 Claude Code, Cowork와 같은 AI 어시스턴트 클라이언트와 Amazon Bedrock 사이에 위치하여, 사내 SSO 연동·비용 추적·사용량 제한·감사 로깅을 수행하는 중간 계층입니다. 클라이언트 입장에서는 접속 대상 엔드포인트만 사내 Gateway로 바꾸면 됩니다. Claude Code는 ANTHROPIC_BASE_URL을 사내 Gateway로 지정하고(Codex 등 OpenAI 계열 도구는 OpenAI 호환 엔드포인트로 연결), 나머지 인증·라우팅·비용 귀속은 모두 Gateway가 처리합니다.

<참고> Claude Code를 Amazon Bedrock과 함께 사용하는 기본적인 방법에 대해서는 Amazon Bedrock과 함께 Claude Code 사용하기 포스트를, Gateway 연동 방법은 Connect Claude Code to an LLM gateway 문서를 참고하시기 바랍니다. 이 글에서는 그 위에 전사 거버넌스와 운영 체계를 얹어 실제 수천 명 규모로 운영한 GS리테일의 사례를 다룹니다.

AI Gateway가 수행하는 4가지 핵심 역할

앞서 살펴본 것처럼 GS리테일이 해결하고자 했던 과제는 특정 AI 모델을 선택하는 것이 아니라, 여러 AI 서비스를 하나의 운영 체계로 관리하는 것이었습니다.

이를 위해 GS리테일은 AI 도구를 통한 모델 호출이 이루어지는 사용자 PC/애플리케이션(Client)과 AI 모델 사이에 AI Gateway를 배치했습니다.

아래 다이어그램은 AI Gateway를 도입한 엔터프라이즈 환경의 전형적인 구조입니다.

그림 3. Client, Gateway, Model Layer로 구성한 AI Gateway 아키텍처

AI Gateway는 크게 세 개의 계층으로 구성됩니다.

• Client Layer: Claude Code, 사내 AI 애플리케이션, AI Agent 등 다양한 클라이언트
• Gateway Layer: LiteLLM 기반 공통 운영 계층
• Model Layer: Amazon Bedrock을 비롯한 다양한 LLM Provider

이 구조를 통해 모든 AI 호출은 동일한 인터페이스를 사용하며, 운영 정책 역시 Gateway에서 일관되게 적용됩니다. 또한 이 구조에서 핵심은 개발자 PC와 Bedrock 사이에 인터넷을 경유하는 구간이 없다는 점입니다. 회사 네트워크에서 Direct Connect를 통해 VPC로 진입하고, VPC 내의 LLM Gateway를 거쳐 PrivateLink로 Bedrock에 도달합니다.

GS리테일은 오픈소스 LiteLLM을 Gateway 엔진으로 선택했습니다. LiteLLM은 100개 이상의 LLM 제공자를 OpenAI 호환 API 하나로 통합하는 Proxy입니다.

LiteLLM을 운영 계층의 기반 소스로 선택한 이유

전사 AI Gateway를 구현하기 위한 다양한 오픈소스가 존재하지만, GS리테일은 LiteLLM을 운영 계층의 소스로 선택했습니다.

선정 기준은 단순히 다양한 모델을 지원하는 것이 아니었습니다. 기업 환경에서는 모델 호출보다 운영 기능이 더 중요했기 때문입니다.

GS리테일은 운영 계층이 다음과 같은 요구사항을 충족해야 한다고 판단했습니다.

• OpenAI 호환 API 제공
• 다양한 LLM Provider 지원
• 중앙 집중형 인증과 권한 관리
• 모델별 라우팅 정책
• 사용량 및 비용 추적
• 확장 가능한 Proxy 구조

LiteLLM은 이러한 요구사항을 기본적으로 충족하면서도 Amazon Bedrock과 자연스럽게 통합할 수 있었고, Claude Code를 비롯한 OpenAI API 기반 애플리케이션을 큰 수정 없이 환경 변수 설정만으로도 대부분 연결할 수 있다는 장점이 있었습니다.

GS리테일은 LiteLLM을 단순한 Proxy로 사용하는 대신, 풍부한 커스터마이징을 통해 AI Gateway의 핵심 운영 계층으로 확장했습니다.

Amazon Bedrock을 업스트림으로 활용한 이유

AI Gateway의 가장 큰 특징은 애플리케이션이 특정 AI 모델을 직접 인식하지 않는다는 점입니다.

예를 들어 Claude Code에서 서로 다른 모델 프로바이더의 AI 모델을 사용하더라도, 실제 요청은 LiteLLM Gateway를 거쳐 Amazon Bedrock에서 지원하는 모델로 전달되어 처리됩니다. 향후 Amazon Bedrock에서 지원하는 다른 신규 모델을 추가하더라도 애플리케이션은 동일한 인터페이스를 그대로 사용할 수 있습니다.

이러한 구조는 AI 모델 교체 비용을 줄이고, 새로운 모델을 점진적으로 도입할 수 있는 기반을 제공합니다.

또한 Gateway는 요청마다 모델 선택 정책을 적용할 수 있으므로, 조직이나 프로젝트 특성에 따라 서로 다른 모델을 사용하는 것도 가능합니다.

AI 모델은 계속 변화하지만, 애플리케이션은 변하지 않는 구조를 만드는 것이 AI Gateway의 중요한 설계 원칙이었습니다.

GS리테일은 LiteLLM 뒤에 Amazon Bedrock을 모델 Provider로 배치했습니다. Claude on Amazon Bedrock 방식은 멀티 모델 지원으로 벤더 Lock-in을 해소하고, 기존 통제 체계(VPC, IAM, CloudTrail, Direct Connect)를 그대로 재사용할 수 있습니다.

Amazon Bedrock은 여러 공급자의 다양한 파운데이션 모델을 서비스 형태로 제공합니다. Cross-Region Inference를 통해 피크 시간 트래픽을 분산하면서도 네트워크 경로를 AWS 내부에 유지할 수 있습니다. 또한 Prompt Caching 기능을 통해 반복되는 코드베이스 컨텍스트를 여러 API 호출에 걸쳐 캐싱함으로써 지원하는 모델들에 대해 응답 지연 시간을 최대 85%까지 줄이고 비용을 최대 90%까지 절감할 수 있어, 장시간 코딩 세션에서 응답 속도와 비용 효율성을 모두 높일 수 있습니다.

Amazon Bedrock이 엔터프라이즈에 제공하는 핵심 보안 기능

Amazon Bedrock을 업스트림으로 두면, AI Gateway는 아래 기능을 별도 개발 없이 활용할 수 있습니다.

데이터 프라이버시: Bedrock은 고객의 프롬프트와 응답을 모델 학습에 사용하지 않으며, Anthropic을 포함한 모델 Provider들도 데이터에 접근할 수 없습니다. 기본적으로 프롬프트와 응답을 저장하지 않으며, 로깅을 활성화한 경우에만 고객의 S3나 CloudWatch에 저장됩니다.

Bedrock Guardrails: Guardrails enforcement 기능을 통해, Bedrock 모델 호출 시 Guardrails가 Account Level 또는 Organization Level로 강제 적용되도록 설정할 수 있습니다.

Private Network: AWS PrivateLink를 통해 모든 LLM 호출이 인터넷을 경유하지 않고 AWS 백본 네트워크만 통과하도록 구성할 수 있습니다. 전체 경로가 회사 네트워크 → VPC → VPC Endpoint → PrivateLink → Bedrock으로 이루어지며 어느 단계에서도 공개 인터넷을 경유하지 않습니다.

CloudTrail 감사: Amazon Bedrock API 호출에 대한 감사 정보를 기록합니다. 호출 주체(IAM identity), 소스 IP, 요청 시간, 호출한 API 및 모델 ID 등의 정보를 확인할 수 있으며, 오류가 발생한 경우 오류 정보도 기록됩니다.

Model Invocation Logging: 별도로 활성화하면 모델 호출에 대한 상세 로그를 수집할 수 있습니다. 호출한 모델, 호출 주체, 입력·출력 토큰 수와 함께 ​모델에 전달된 요청 및 모델의 응답 내용을 CloudWatch Logs 또는 Amazon S3에 기록할 수 있습니다. 큰 요청·응답 데이터는 S3에 별도 객체로 저장될 수 있습니다.

GS리테일의 AI Gateway는 이러한 Bedrock의 기본 보안 기능 위에, Virtual Key 기반의 추가 거버넌스 계층과 자체 운영 체계를 올린 구조입니다.

Virtual Key 기반 중앙 인증 구조

Gateway의 설계 중심에 놓이는 것은 모델이 아니라 Virtual Key입니다. 사용자든 백엔드 서버든 Agent든, Gateway를 통과하는 모든 주체를 Virtual Key 하나로 추상화하면 인증·사용량 한도·비용 귀속이 주체마다 따로 설계되지 않고 동일한 메커니즘을 타게 됩니다.

기업에서는 AI API Key를 개별 사용자나 애플리케이션이 직접 관리하는 방식에 여러 한계가 있습니다.

API Key가 사용자 환경에 분산되면 교체와 폐기, 권한 변경을 중앙에서 통제하기 어렵고, 누가 어떤 모델을 얼마나 사용했는지 추적하기도 쉽지 않습니다.

Virtual Key는 실제 Amazon Bedrock 자격 증명을 외부에 노출하지 않으면서, Gateway에서 사용자를 식별하고 권한을 적용하기 위한 논리적 인증 키입니다.

Gateway는 Virtual Key를 통해 다음과 같은 정보를 함께 관리합니다.

• 사용자
• 조직
• 프로젝트
• 사용 가능한 모델
• 사용량 정책
• 비용 정책
• 감사 로그

이를 통해 애플리케이션은 동일한 방식으로 Gateway를 호출하면서도, 사용자마다 서로 다른 권한과 정책을 적용할 수 있습니다.

무엇보다 중요한 점은 운영 정책이 애플리케이션이 아니라 Gateway에 집중된다는 것입니다.

새로운 애플리케이션이 추가되더라도 별도의 인증 체계를 다시 구축할 필요 없이, Virtual Key만 발급하면 동일한 거버넌스 체계 안에서 운영할 수 있습니다.

그림 4. Virtual Key 기반 중앙 인증과 정책 적용 흐름

사용자는 먼저 사내 SSO로 AI Gateway 포털에 로그인하여 신원을 확인한 뒤, 자신의 Virtual Key를 발급받습니다. 이후 Claude Code, Cowork 등 AI 클라이언트는 매 요청마다 Virtual Key를 Authorization: Bearer 헤더로 전달합니다. AI Gateway는 키의 SHA-256 해시를 조회해 사용자의 신원을 복원하고, 권한·모델 정책·비용·감사 정책을 적용한 후 Amazon Bedrock으로 요청을 전달합니다. 이를 통해 AWS 자격 증명을 사용자 환경에 배포하지 않으면서도 인증과 권한, 비용, 감사 정책을 중앙에서 일관되게 관리할 수 있습니다.

이 과정에는 몇 가지 보안 원칙이 함께 적용됩니다. Virtual Key는 표준 난수 기반의 불투명 토큰으로, AI Gateway는 키 원문을 저장하지 않고 SHA-256 해시만 저장하며 식별용으로 접두 일부만 별도로 남깁니다. 신원의 신뢰 원천은 요청 본문이 아니라 SSO이며, 발급 시 신원 저장소를 재조회해 이를 확정하고 조회 실패나 비활성 계정이면 키를 만들지 않고 거부합니다(fail-closed). 키 발급은 감사 기록이 선행되어, 감사에 남지 않은 키는 존재할 수 없습니다. Amazon Bedrock 호출에 필요한 AWS 자격증명은 AI Gateway가 AWS STS로 받아 프로세스 메모리에서 요청 서명에만 사용하므로, 사용자 환경에는 AI Gateway 전용 토큰만 남고 키 폐기 한 번으로 접근을 즉시 차단할 수 있습니다.

Virtual Key는 발급보다 수명 관리가 더 중요하다

Virtual Key를 한 번 발급하는 것만으로는 기업 환경에서 안전한 운영을 보장할 수 없습니다. 사용자가 사용하는 AI 클라이언트마다 인증 정보를 저장하고 갱신하는 방식이 다르기 때문입니다.

예를 들어 Claude Code처럼 백그라운드에서 토큰을 자동으로 갱신할 수 있는 도구도 있지만, 일부 애플리케이션은 사용자가 설정 화면이나 환경 변수에 키 값을 직접 저장합니다. 두 유형에 동일한 정책을 적용하면 보안은 강화할 수 있어도 사용성이 크게 떨어질 수 있습니다.

그래서 AI Gateway는 클라이언트의 특성에 따라 두 가지 방식으로 Virtual Key의 수명을 관리합니다.

자동 갱신 계열은 짧은 수명의 호출 키와 Refresh Token 체인을 사용합니다. 호출 키가 만료되면 클라이언트가 자동으로 새로운 키를 발급받기 때문에 사용자는 별도의 설정 변경 없이 계속 사용할 수 있습니다. 이때 최초 발급 시 결정된 정책 기간을 기준으로 만료 시간을 연장하며, 체인 최초 발급 시점을 기준으로 절대 만료 시점을 두어 무한정 연장되는 것을 방지합니다.

반대로 고정 키 계열은 키 값이 변경되면 사용자가 다시 설정해야 하는 특성이 있습니다. 따라서 키 원문은 유지한 채 만료 시점만 연장하는 방식을 사용합니다. 사용자는 만료 전에 포털에서 연장을 요청할 수 있으며, 기존 설정을 변경하지 않고 계속 사용할 수 있습니다.

그림 5. 클라이언트 특성에 따른 Virtual Key 수명 관리 방식

또한 Virtual Key는 단순히 만료 시간을 늘리지 않습니다. 최근 일정 기간 동안 실제 호출이 확인된 활성 Key Chain만 연장 대상으로 인정하며, 사용 이력을 확인할 수 없거나 조회 과정에서 오류가 발생하면 연장을 수행하지 않는 Fail-Closed 원칙을 적용합니다. 이미 만료된 키는 연장이 아닌 재발급 절차를 통해 새로운 Virtual Key를 발급하여 오래된 자격증명이 계속 사용되는 상황을 방지합니다.

크로스 계정 라우팅: 비용도 쿼터도 팀 단위로 가른다

AI Gateway에서는 수백 개 이상의 AWS 계정에 있는 Amazon Bedrock을 호출하고 있습니다. AWS 계정은 팀/프로젝트별로 하나씩 별도로 구분하여 생성 및 관리하고 있습니다.

GS리테일에서 팀마다 Bedrock을 호출하는 AWS 계정을 나눈 이유는 두 가지입니다.

첫째는 비용 귀속입니다. 중앙 계정에서 모든 모델 비용을 처리하면 포털에서 조직별 비용을 계산할 수는 있어도, AWS 청구 계정과 실제 소유 조직이 달라집니다. AWS에서 계정은 청구와 격리의 정확한 단위이므로, 팀 계정으로 호출하면 태깅 전략에 기대지 않고도 Cost Explorer의 계정 축 하나로 비용이 갈립니다.

둘째는 쿼터 분산입니다. Bedrock의 모델 호출 한도(Service Quotas)는 계정·리전·모델 단위로 적용됩니다. 전사 트래픽을 한 계정에 몰면 그 계정의 쿼터가 곧 전사 상한이 될 수 있고, 한 팀의 대량 배치가 다른 팀의 스로틀링으로 나타나는 경우가 발생할 수 있습니다. 계정을 나누면 한 팀의 사용량 급증이 다른 팀으로 전이되지 않고, 증설이 필요한 조직만 그 계정의 쿼터를 올리면 됩니다.

그래서 팀과 AWS 계정의 매핑을 조회하고, 요청 시 STS AssumeRole로 해당 팀 계정의 Bedrock을 호출하는 크로스 계정 라우팅을 구현했습니다.

그림 6. 팀별 비용·쿼터 분리를 위한 크로스 계정 라우팅

처음 몇 개는 콘솔에서 손으로 만들면 됩니다. 그런데 본부·부문·팀 단위로 요청이 쌓이면 계정 하나를 여는 일은 클릭 몇 번이 아니라 OU 배치 → 초기 SSO 권한 할당 → Bedrock 모델 액세스 요청 → 위키 기록 → 담당자 통보로 이어지는 반복 절차가 됩니다. 사람이 매번 밟으면 반드시 어딘가에서 빠뜨립니다.

그래서 계정 개설을 두 개의 서버리스 파이프라인으로 옮겼습니다.

전체 흐름은 두 개의 독립 파이프라인으로 나뉩니다. 하나는 계정을 만드는 팩토리, 다른 하나는 계정이 만들어진 뒤 온보딩을 마무리하는 후속 파이프라인입니다. 둘을 느슨하게 분리한 덕분에 각각을 따로 배포하고 따로 장애 격리할 수 있습니다.

그림 7. Account Factory와 Account Onboarding 자동화 파이프라인

Account Factory (대량 계정 생성)

운영자가 계정 정보가 담긴 CSV를 업로드하면 Amazon EventBridge가 이를 감지해 AWS Step Functions를 실행합니다. 상태 머신은 CSV를 검증한 뒤 계정별로 중복 여부 확인 → Control Tower Account Factory를 통한 계정 생성 → 생성 완료 확인 → IAM Identity Center 권한 할당을 순차적으로 수행합니다. 모든 진행 상태는 Amazon DynamoDB에 기록되며, 동일한 CSV를 다시 실행해도 성공한 계정은 건너뛰고 실패한 계정만 재처리하는 멱등성(Idempotency)을 보장합니다.

Account Onboarding (자동 온보딩)

계정 생성이 완료되면 AWS CloudTrail 이벤트를 Amazon EventBridge가 수신하여 두 번째 AWS Step Functions 파이프라인을 시작합니다. 대상 OU를 확인한 뒤 Amazon Bedrock 모델 액세스를 자동으로 요청·구독하고, 완료 결과를 Amazon SES 메일, Microsoft Teams, Confluence 위키에 자동으로 반영합니다. 이를 통해 신규 계정은 별도의 운영자 개입 없이 사용할 준비가 완료되며, 생성 이력과 온보딩 결과도 함께 관리됩니다.

위와 같이 계정 준비가 자동화된 덕분에, 앞서 교차 계정 라우팅에서 이야기했던 전제, 팀 계정이 있고 그 계정에서 모델 구독이 끝나 있어야 한다는 조건을 수작업 없이 충족할 수 있습니다. 계정을 늘리는 일이 병목에서 빠지고 나서야 팀 단위로 쿼터와 비용을 나누는 구조가 실제로 굴러갔습니다.

결론

이번 1부에서 가장 크게 달라진 것은 여러 팀이 제각각 사용하던 AI 모델 호출을 하나의 통제된 경로로 통합했다는 점입니다. 단순히 Gateway를 하나 추가한 것이 아니라, 인증부터 모델 라우팅, 계정 관리까지 반복되던 작업을 자동화하면서 개발자가 기존 도구를 그대로 사용할 수 있는 구조를 만들었습니다.

1. 인증 경로를 하나로 통합했습니다.

• 과거에는 팀과 도구별로 각기 다른 인증 방식과 자격 증명을 관리해야 했지만, 현재는 모든 모델 호출이 LiteLLM 기반 AI Gateway를 거치도록 구성했습니다. 사용자는 기존 도구를 그대로 사용하면서 AI Gateway에서 중앙화된 인증과 정책의 적용을 받을 수 있게 되었습니다.

2. 크로스 계정 모델 라우팅을 표준화했습니다.
   • 과거에는 팀별 AWS 계정과 모델 접근 방식이 분산되어 있었지만, 현재는 AI Gateway가 AWS STS를 통해 각 팀 계정의 역할을 위임받아 Amazon Bedrock으로 요청을 전달하도록 구성했습니다. AI Gateway가 팀별 장기 자격 증명을 직접 보관하지 않으면서도 계정별 모델 접근을 중앙에서 통제할 수 있게 되었습니다.
3. 계정 생성과 반복 작업을 자동화했습니다.
   • 과거에는 신규 사용자나 팀이 추가될 때 계정 생성과 설정을 수작업으로 처리해야 했지만, 현재는 설치와 계정 생성 과정을 자동화하고 작업 상태를 추적할 수 있도록 구성했습니다. 실패한 작업만 다시 처리할 수 있게 되면서 운영 과정에서 반복되는 수작업도 줄일 수 있었습니다.

사용자는 기존 개발 도구를 그대로 사용하면서도, 뒤에서는 인증·라우팅·거버넌스가 중앙에서 관리되는 구조를 만들 수 있었습니다. 개발 경험을 과도하게 제한하면 우회 경로가 생길 수 있으므로, 기존 사용성을 유지하는 것을 중요한 설계 원칙으로 삼았습니다.

실제 만들어 보며 느낀 점

AI Gateway를 만드는 입장에서 가장 도움이 된 것은 두 가지였습니다. LiteLLM이 OpenAI 호환 인터페이스를 제공하니 기존 클라이언트 도구를 개조하지 않고도 AI Gateway를 연결할 수 있었고, 우리 환경에 필요한 사용량 집계나 감사 기록은 훅 지점에 붙여 Proxy 본체를 크게 수정하지 않고 구현할 수 있었습니다.

Amazon Bedrock 쪽에서는 AWS IAM과 AWS STS를 활용해 팀 계정으로 안전하게 권한을 위임할 수 있다는 점이 컸습니다. 덕분에 AI Gateway가 팀별 장기 자격 증명을 직접 보관하지 않고도 교차 계정 라우팅을 구현할 수 있었습니다.

운영하면서는 기록을 남기는 방식과 반복 작업의 자동화가 운영 부담을 크게 좌우한다는 것도 확인했습니다. 감사 로그를 어떻게 저장하고 조회할 것인지, 계정 생성과 같은 반복 작업을 어떻게 안정적으로 자동화할 것인지는 실제 운영 단계에서 특히 중요했습니다. 이러한 로그 저장 구조와 운영 자동화 방식은 2부에서 구체적으로 다뤄보겠습니다.

다음 이야기

AI Gateway가 자리를 잡자 다음 요구가 올라왔습니다. 모델을 호출하는 데서 멈추지 않고, 업무를 실제로 처리하는 AI Agent를 쓰려는 움직임이 조직 곳곳에서 나타났습니다. 늘어나는 Agent도 같은 AI Gateway를 거쳐 동작하게 만드는 것이 클라우드인프라팀의 다음 과제가 되었습니다. 그런데 Agent는 1부에서 답한 질문을 다른 모습으로 다시 가져왔습니다. 사내 메일·파일·일정에 접근할 때 누구의 권한으로 읽는지, 최신 정보가 필요한 작업에서 막아 둔 인터넷 접근을 어떤 경계 안에서 허용하는지입니다.

두 질문 모두 클라이언트 도구가 기대하는 기능과 모델 서비스가 제공하는 기능이 어긋나는 지점에서 드러났습니다. Claude Code와 Cowork가 웹 검색을 위해 보내는 web_search 서버 툴을 Amazon Bedrock은 지원하지 않는 툴 타입으로 판단해 되돌려보냈고, M365 같은 사내 시스템 연동은 아예 AI Gateway 바깥에서 이루어지려 했습니다. 그 간극을 메워 모든 에이전트를 같은 통제 안으로 들여놓는 일이 다시 AI Gateway의 몫으로 남았습니다.

이 지점이 2부의 출발점이며, 그 두 가지를 실제 Amazon Bedrock AgentCore 기반으로 구현한 사례를 구체적인 구성 내용과 함께 다뤄볼 예정입니다.