GS리테일의 전사 AI Gateway 구축 사례 – 2부: 실사용을 견디는 운영과 거버넌스

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

이 글은 GS리테일의 전사 AI Gateway 구축 사례 1부: 인증·라우팅·계정 자동화 설계에 이어지는 두 번째 글입니다. 1부를 아직 보지 않으셨다면 먼저 읽어보시길 권해드립니다.

1부에서는 GS리테일 클라우드인프라팀이 사내 AI 도구 수요를 조직 차원에서 안전하게 받아내기 위해, 모든 AI 호출을 하나의 관문으로 모으는 전사 AI Gateway를 구축한 과정을 다뤘습니다. Claude on Amazon Bedrock과 LiteLLM을 기반으로 한 아키텍처, Virtual Key 중앙 인증, 그리고 팀 계정별 크로스 계정 라우팅이 핵심이었습니다.

이번 글은 그 이후의 이야기입니다. AI Gateway를 세우는 것과 그것을 수천 명이 매일 쓰는 플랫폼으로 운영하는 것은 다른 일이었습니다. 사용자 온보딩 자동화, 예산 기반 자동 모델 라우팅, 자체 가드레일과 관측 파이프라인, 그리고 AI Agent로의 확장까지, 실사용이 만들어낸 요구를 Gateway 위에 하나씩 얹은 과정을 다룹니다.

GS리테일 AI Gateway의 차별점: 실사용을 견디는 운영 체계

AI Gateway를 구축한 이후 GS리테일의 다음 과제는 AI Gateway 자체를 운영 가능한 플랫폼으로 만드는 것이었습니다.

AI Gateway가 모든 AI 요청을 중계하더라도, 실제 운영에서는 새로운 요구사항이 계속 발생합니다.

예를 들어 새로운 사용자가 AI 서비스를 이용하려면 어떻게 권한을 부여할 것인지, 조직별 예산은 어떻게 관리할 것인지, 허용되지 않은 모델 사용은 어떻게 차단할 것인지와 같은 문제는 단순한 API Proxy만으로는 해결하기 어렵습니다.

Install Center, 예산 라우팅, 가드레일, 관측과 리더 대시보드로 구성한 AI Gateway 운영 체계

그림 1. 실사용을 지원하는 AI Gateway 운영 기능

GS리테일은 이러한 운영 요구사항들을 AI Gateway 위에 직접 커스터마이징하여 구현한 운영 계층으로 해결했습니다. 이 운영 성숙도가 곧 “구축한 AI Gateway”와 “전사가 실제로 사용하는 Gateway”를 가르는 차이입니다.

사용자 온보딩을 자동화한 Install Center

전사 확산에서 가장 먼저 부딪힌 벽은 기술이 아니라 현업 사용자의 환경이었습니다. AI 도구의 전사 확산에서 진짜 병목은 모델이 아니라 “현업 PC(Windows)에 어떻게 무리 없이 설치되게 하느냐”입니다.

현업 부서의 Windows 사용자들이 PowerShell과 CMD를 다루기 어려워하는 경우가 많았습니다.
Cowork를 Windows에서 실행하려면 Windows 가상 머신 플랫폼(Virtual Machine Platform) 기능 활성화가 필요한데, 이를 일반 사용자가 직접 설정하기는 어려웠습니다.

클라우드인프라팀은 이 문제를 .NET 기반의 설치 번들 파일(.exe)을 직접 제작해 해결했습니다. AI Gateway 웹 화면의 설치 센터(Install Center) 탭에서 이 설치기를 가이드와 함께 배포하고, 설치 과정을 돕는 챗봇과 Windows 설치기 및 프로세스 모니터링까지 제공했습니다. 덕분에 IDE나 터미널에 익숙하지 않은 비개발 직군도 큰 어려움 없이 AI 도구를 설치하고, 사용할 수 있게 되었습니다.

Install Center는 사용자가 직접 AI 사용을 신청하고 필요한 환경을 자동으로 구성하는 셀프서비스(Self-service) 화면입니다. Install Center는 사용자의 OS와 선택 도구에 맞는 설치 경로를 제공하고 다음 과정을 표준화합니다.

포털 SSO 로그인과 사용자·조직 확인
필요한 Virtual Key 또는 부트스트랩 자격증명 발급
Claude Code·Cowork·Codex 등 도구별 설정 생성
Windows 원클릭 설치기와 macOS 관리 프로필 제공
설치 단계별 진단 정보와 복구 안내

운영체제와 사용 목적에 따라 AI 도구 설치 경로를 안내하는 Install Center 화면

그림 2. 운영체제와 사용 목적에 맞는 설치 경로를 제공하는 Install Center

Windows 설치기의 구성 요소 준비 화면과 사내 계정 2단계 인증 화면

그림 3. 원클릭 설치기의 구성 요소 준비와 사내 계정 인증 과정

단계	수행 과정
1	설치기 실행
2	설치할 도구 선택 (Claude Code · Cowork · Codex)
3	PC 상태 점검 · 필요한 구성 요소와 Windows 기능 준비
4	사내 계정 로그인 + 2단계 인증(MFA)
5	사용자 신원 확인 후 자격증명 발급 (조직·정책 정보 포함)
6	도구별 설정 파일에 엔드포인트와 자격증명 자동 기록
7	연결 확인 호출로 실제 동작 검증

설치 자동화에서 가장 중요한 부분은 자격증명을 사람이 옮기지 않게 만드는 것입니다. 사용자가 포털에서 키를 발급해 복사하고, 터미널이나 설정 파일에 붙여넣는 방식은 실패 지점이 많습니다. 값이 잘리거나 공백이 섞이고, 도구별로 어느 항목에 넣어야 하는지도 다릅니다. 그래서 설치기는 실행 중에 자체 로그인 창을 띄워 사내 계정으로 인증합니다. 사용자는 포털에서 안내받은 계정으로 로그인하고 2단계 인증(문자 또는 인증 앱)을 완료합니다. 인증이 끝나면 설치기가 사용자 대신 AI Gateway에서 자격증명을 받아 도구 설정에 직접 기록합니다.

AI 서비스가 조직 전체로 확대될수록 이러한 자동화는 운영 효율성뿐 아니라 보안 정책을 일관되게 유지하는 기반이 되었습니다.

예산 소진에 따른 자동 모델 라우팅

생성형 AI 운영에서 가장 어려운 부분 가운데 하나는 비용 관리입니다. 생성형 AI 비용은 대부분 쓰고 난 뒤에 확인됩니다. 그런데 코딩 Agent 하나가 하루에 소비하는 비용은 예측 범위를 쉽게 벗어나 급격히 증가할 수 있습니다.

GS리테일은 사용량 모니터링에 더해 예산 기반 운영 정책을 AI Gateway에 적용했습니다. 본부별 비용 한도를 설정하고 사용량에 따라 모델을 비용 효율적인 모델로 자동 라우팅하는 방식으로 해당 정책을 구현했습니다.

조직별 예산 소진율에 따라 모델 유지, 다운그레이드와 차단 정책을 적용하는 흐름

그림 4. 예산 임계값에 따른 자동 모델 라우팅 정책

운영자는 조직별 또는 프로젝트별 예산을 설정할 수 있으며, AI Gateway는 사용량을 지속적으로 추적합니다. 예산이 특정 임계값에 도달하면 운영 정책이 자동으로 적용됩니다.

예를 들어 고성능 고비용 모델을 계속 사용하는 대신 상대적으로 비용이 낮은 모델로 자동 전환하도록 정책을 구성할 수 있습니다.

이 방식은 사용을 완전히 차단하지 않으면서도 비용 폭주를 방지합니다. 사용자는 한도 내에서 최고 성능 모델을 쓸 수 있고, 한도에 가까워지면 자연스럽게 경량 모델로 전환되어 업무 연속성이 유지됩니다. 리더는 관리자 대시보드에서 본부별로 한도를 직접 설정할 수 있습니다.

사용량 관리

개인은 일일·월간 토큰 사용량과 비용, 월 예산 대비 소진율을 확인할 수 있습니다.

프롬프트 캐싱 영역에서는 캐시 히트율, Write:Read 비율과 캐시로 절감한 금액을 제공합니다.

또한 ‘내 캐시 패턴 진단’을 통해 사용 패턴의 개선점을 확인할 수 있도록 했습니다.

개인의 토큰 사용량, 비용, 예산 소진율과 프롬프트 캐싱 지표를 보여주는 대시보드

그림 5. 개인별 사용량·비용·프롬프트 캐싱 대시보드

예산은 개인별로 할당하지만, 관리 단위는 팀 예산 풀입니다. 개인 한도는 해당 풀 내에서 분배한 몫이고, 합계는 팀 총액을 넘지 않습니다.

이와 같이 설정한 이유는 실제 사용 분포가 고르지 않기 때문입니다. 한 팀 안에서도 매일 코딩 Agent를 돌리는 사람과 한 달에 몇 번 쓰는 사람이 섞여 있습니다. 1인당 균등 배분으로 시작하면 한쪽은 월 중에 한도를 모두 소진하여 강등되는 반면, 다른 쪽은 90%가 남은 채로 월이 끝납니다. 팀 전체로는 예산이 남는데 헤비 유저의 사용이 막히는 상태입니다.

그래서 미사용 인원의 예산을 헤비 유저에게 이관하는 권한을 리더에게 부여했습니다. 담당자가 개별 요청을 받아 처리하는 게 아니라, 누가 얼마나 쓰는지 아는 조직원이 본 화면에서 직접 예산을 조정합니다.

리더가 팀원별 예산과 사용량을 확인하고 예산을 조정하는 화면

그림 6. 팀 예산 풀과 구성원별 예산 조정 화면

자체 가드레일 적용

Amazon Bedrock Guardrails를 쓰면 프롬프트 필터링을 손쉽게 붙일 수 있지만, 호출마다 별도 비용이 발생합니다. 약 700개 팀·수천 명 규모에서 모든 호출에 적용하면 전체 비용이 빠르게 증가합니다.
비용만이 이유는 아니었습니다. 전 호출에 동일한 외부 정책을 일괄 적용하는 방식으로는 조직마다 다른 요구를 담기 어려웠습니다. 어떤 부문은 고객 식별정보를 아예 막아야 하고, 어떤 팀은 마스킹만으로 충분하며, 특정 프로젝트는 경고만 남기고 통과시켜야 합니다.
그래서 AI Gateway는 가드레일을 Gateway 레벨에 직접 구현했습니다. 덕분에 관리형 Guardrails의 호출 과금 없이 요구사항에 맞추어 민감 정보 필터링을 전 호출에 적용하고 있습니다.

LiteLLM Proxy는 CustomLogger를 상속한 커스텀 callback을 등록하면 요청 처리 과정의 특정 hook을 호출할 수 있습니다. 자체 가드레일 구현에서는 Proxy 전용 async_pre_call_hook, async_post_call_success_hook을 활용해 LLM 호출 전과 후에 요청을 검사·변경하고, async_log_success_event를 활용해 호출 결과를 로깅할 수 있습니다.

LiteLLM Proxy 코드에서는 아래와 같이 설정하는 방식으로 구현할 수 있습니다.

class GuardrailCallback(CustomLogger):
    # Input Guard: 모델 호출 전 요청 검사
    async def async_pre_call_hook(
        self, user_api_key_dict, cache, data, call_type
    ): ...

    # Output Guard: 모델 응답 생성 후 검사
    async def async_post_call_success_hook(
        self, data, user_api_key_dict, response
    ): ...

    # 감사 기록: 호출 결과를 비동기로 기록
    async def async_log_success_event(
        self, kwargs, response_obj, start_time, end_time
    ): ...

구분	Input Guard	Output Guard
LiteLLM Hook	`async_pre_call_hook`	`async_post_call_success_hook`
검사 시점	모델 호출 전	모델 응답 생성 후
검사 대상	사용자 프롬프트 / 요청	모델 응답
주요 기능	PII 탐지, 금칙어, Prompt Injection, 주제 제한 등 정책 검사	PII 탐지, 금칙어, 민감정보 유출 검사
정책 위반 시	모델 호출 전에 차단 가능	검사 후 위반 사실을 감사 기록 (사후 탐지)
토큰 비용	발생하지 않음 (모델 미호출 시)	이미 발생 (모델 응답 생성 후)
운영 목적	불필요한 모델 호출 방지 및 비용 절감	생성된 응답의 정보 유출 방지

인증 이후 Input Guard를 적용하고 모델 응답 이후 Output Guard를 적용하는 처리 흐름

그림 7. AI Gateway의 Input Guard와 Output Guard 처리 흐름

AI Gateway의 가드레일은 인증(Authentication) 이후, 모델 라우팅(Routing) 이전에 동작합니다. 먼저 Input Guard가 사용자의 조직 정보와 정책을 조회하여 프롬프트를 검사합니다. 정책 위반 시에는 모델을 호출하지 않고 즉시 차단(BLOCK)하므로 토큰 비용이 발생하지 않습니다. 반면 REDACT는 민감정보를 마스킹한 뒤 모델로 전달하고, WARN은 요청은 그대로 통과시키되 위반 사실만 기록합니다.

Input Guard를 통과한 요청만 예산 및 모델 제한(Budget / Model Restriction)을 거쳐 실제 LLM으로 전달됩니다.

모델 응답이 생성된 이후에는 Output Guard가 응답 내용을 검사합니다. 다만 사내 트래픽은 코딩 에이전트 비중이 높아 대부분 스트리밍으로 동작하는데, 스트리밍 응답을 되돌리려면 응답 전체를 모아 검사한 뒤 한 번에 내보내야 하므로 첫 토큰까지의 대기 시간이 전체 생성 시간으로 늘어납니다. 도구 사용성을 크게 훼손하는 방식이라, 차단은 입력 경계에 집중시키고 출력 경계는 응답을 검사해 위반 사실을 감사 원장에 남기는 사후 탐지 역할을 맡도록 설계했습니다. 정리하면 입력은 사전 차단, 출력은 사후 탐지이며, 민감 패턴 감지 시 스트림을 중단하는 부분 차단은 개선 항목으로 검토 중입니다.

모든 정책 위반 내역은 응답 처리와 분리된 비동기(Fire-and-Forget) 방식으로 감사 로그에 기록됩니다. 저장 구조는 뒤의 감사 로그 섹션에서 다룹니다.

정책은 조직 계층별로 적용할 수도 있으며, 하나의 정책은 여러 Scope를 동시에 가질 수 있고 우선순위를 함께 지정할 수도 있습니다. 이 조직 문맥 기반 정책 적용이 Gateway 자체 구현의 가장 큰 이유입니다.

오탐(False Positive) 대응 시에는 형식만 맞는 숫자를 개인정보로 세지 않도록 탐지 단계에 검증을 넣었습니다. 체크섬·Luhn 검증, 주변 문맥 라벨 확인(업무 승인번호·주문번호·우편번호 등은 제외하되 전화 라벨이 함께 있으면 유지), 형식상 존재할 수 없는 번호 배제, 공개 대표번호·문서용 더미 번호 블록리스트를 적용합니다. 또한 위반을 건수가 아니라 고유 값 기준으로 집계합니다. 에이전트 계열 클라이언트가 대화 히스토리를 매 요청 재전송해 같은 값이 반복 집계되기 때문입니다. 이 조치로 실제보다 과장된 개인정보 축 위반 탐지 건수를 대폭 줄일 수 있었고, 남은 실제 건수에 대해 검토를 진행하고 있습니다. 운영 정책에 따라 실제 탐지 분포를 관찰하고 있으며, 위반 방향은 입력이 96.8%, 출력이 3.2%로 입력 경계에 크게 치우치는 경향이 있습니다.

목적별로 분리한 자체 관측 체계

요청이 성공했는지 확인하는 것만으로는 운영 관점에서 충분하지 않습니다. 누가 어떤 모델을 호출했고, 응답이 얼마나 걸렸고, 어느 조직에서 비용이 늘고 있는지를 상시로 볼 수 있어야 합니다.

관측은 목적에 따라 세 계층으로 분리해 운영합니다.

① 감사·정산 원장은 요청·응답 전문을 Amazon S3에, 검색·집계용 메타데이터를 Amazon DynamoDB에 나눠 저장하며, 샘플링 없이 전량 기록하고 보존 기간은 항목 TTL로 관리합니다.
② 운영 로그와 지표는 Amazon CloudWatch Logs에 남기고, 오류 유형은 메트릭 필터로 지표화해 임계 감시에 활용합니다.
③ 실시간 성능 계측은 게이트웨이가 최근 구간의 지연과 성공률을 자체 계측해 화면에 제공합니다.

상용 APM 하나로 감사와 실시간 관제를 함께 맞추려 하면 비용이 빠르게 커지고, LLM 특유의 지표(입력·출력 토큰, 캐시 생성·읽기, 모델별 원가)는 활용 중인 APM 솔루션의 기본 스키마에 들어 있지 않아 이렇게 나눴습니다. 개인정보는 마스킹 규칙으로 거르는 방식이 아니라 저장 구조로 분리했습니다. 감사 메타데이터에는 프롬프트·응답 본문이 포함되지 않고, 전문은 권한을 분리한 별도 저장소에 두며, 인증 키는 원문 없이 해시만 남깁니다. 세 계층이 각각 다른 저장소와 조회 경로를 갖고 있어, 수집 규격을 OpenTelemetry(OTEL)로 통일하는 작업을 다음 단계로 진행하고 있습니다.

수집한 메타데이터에는 다음과 같은 항목이 포함됩니다.

사용자·팀·Agent 식별자와 클라이언트 유형
모델, 성공·실패 상태, 응답 시간
입력·출력·캐시 생성·캐시 읽기 토큰
실제 호출에 사용한 AWS 계정 식별자
요청 형태와 자동 라우팅 결과
Amazon S3의 전문 객체를 가리키는 key

운영 현황을 한눈에 확인하는 Leader Lounge

GS리테일은 LiteLLM의 기본 운영자를 위한 Admin UI를 넘어, 경영진과 관리자가 전체 AI 활용 현황을 확인할 수 있는 Leader Lounge를 구축했습니다.

조직별 AI 사용량, 비용과 보안 점검 현황을 보여주는 Leader Lounge 화면

그림 8. 조직 리더를 위한 AI 사용 현황 대시보드

Leader Lounge에서는 다음과 같은 정보를 확인할 수 있습니다.

조직별 AI 사용 현황 리포트
모델별 사용량과 비용 리포트
사용자 증가 추이 및 조직별 정책 관리

이를 통해 운영자는 시스템 상태를 관리하고, 조직 리더는 AI 도입 현황과 비용을 함께 확인할 수 있는 공통의 운영 지표를 확보했습니다.

700개 팀, 수천 명 규모의 사용자를 수동으로 관리하는 것은 불가능합니다. GS리테일은 사내 조직도를 매일 아침 1회 자동 동기화하여, 신규 입사·부서 이동·퇴사가 Gateway의 사용자/팀 구조에 자동으로 반영되도록 했습니다.

특히 리더 라운지는 단순 사용량 통계가 아니라 “각 조직이 AI를 어떻게 활용하고 있는지”를 LLM이 요약해 리더에게 전달한다는 점에서, AI Gateway를 거버넌스 도구에서 경영 인사이트 도구로 확장한 기능입니다.

감사 로그: Amazon S3 + Amazon DynamoDB 분리 저장

감사 로그에는 성격이 전혀 다른 두 종류의 데이터가 섞여 있습니다.

프롬프트와 응답 전문은 한 건이 수십 KB에서 수백 KB에 이르고, 코딩 Agent처럼 프로젝트 컨텍스트를 통째로 실어 보내면 한 요청이 1MB를 넘기기도 합니다. 크기는 이렇게 크지만 실제로 열어 보는 일은 드물어서, 보안 조사나 특정 요청 추적처럼 주로 사후에 지목해서 봅니다. 또한 프롬프트나 응답 전문에는 소스 코드, 개인정보, 영업 비밀 등이 포함될 수 있기 때문에 암호화 및 접근 통제, 보존/삭제 정책 설정이 필요합니다.
다른 하나는 메타데이터입니다. 누가, 언제, 어떤 모델을, 토큰 몇 개, 응답 시간 몇 ms, 상태 코드 몇 번으로 호출했는지 같은 정보가 여기에 해당합니다. 건당 1KB도 안 되는 작은 데이터지만, 대시보드·사용량 집계·비용 정산·이상 탐지가 상시로 이 데이터를 훑고 지나갑니다.

이 둘을 한 저장소에 넣으면 어느 쪽으로 맞춰도 손해를 봅니다. Amazon DynamoDB에 전문까지 넣으면 아이템 400KB 제한에 걸리고, 걸리지 않더라도 대시보드 쿼리가 매번 본문 바이트를 함께 읽어 옵니다. 반대로 전부 Amazon S3에 넣으면 “이번 달 팀별 비용”을 뽑기 위해 수백만 개 객체를 스캔해야 합니다.

그래서 역할 기반으로 분리했습니다. 전문은 Amazon S3에, 메타데이터는 Amazon DynamoDB에 저장하는데 여기서 Amazon DynamoDB를 선택한 이유는 다음과 같습니다.

Append-only에 가까운 쓰기 패턴: 감사 로그와 같이 요청마다 한 건씩 쌓이고 수정되지 않아, 조인·트랜잭션·스키마 변경이 거의 없는 워크로드에 유리
코드로 관리하지 않는 보존 기간: TTL만 넣으면 백그라운드에서 만료/삭제를 Amazon DynamoDB가 처리해, 정리 배치나 파티션 드롭이 불필요
한 테이블에서 소화하는 여러 이벤트 종류: 스키마가 고정되지 않아 다양한 이벤트 타입이 한 테이블에 들어가고, GSI로 종류별 조회가 가능(api_request, guardrail_violation, claude_agent_lifecycle)
적은 운영 부담: 백업·암호화·가용성이 설정값 수준으로 처리되어, 소수 인원 운영 환경에서 실질적인 결정 요인

요청과 응답 전문은 Amazon S3에 저장하고 검색용 메타데이터는 Amazon DynamoDB에 저장하는 감사 로그 구조

그림 9. Amazon S3와 Amazon DynamoDB를 분리한 감사 로그 저장 구조

두 저장소를 잇는 것은 s3Key 한 필드입니다. 상세 조회는 DynamoDB에서 메타데이터를 찾고, 그 안의 s3Key로 전문을 가져오는 방식입니다. 여기서 의도적으로 한 가지를 지켰는데, 키를 규칙으로 재조립하지 않고, 실제 사용한 키를 그대로 저장한다는 점입니다. 경로 규칙을 나중에 바꾸더라도 과거 로그 조회가 깨지지 않습니다.

감사 데이터는 저장 시 암호화(AWS KMS)하고 시점 복구(PITR)를 활성화했습니다. 요청·응답 전문은 별도 Amazon S3 버킷에 저장하고 공개 접근을 차단하며, 조회는 관리자 권한으로 제한합니다. 위반 원문 조회처럼 민감한 조회는 그 조회 행위 자체가 감사에 기록됩니다. 감사 메타데이터에는 프롬프트 본문이 포함되지 않고, 인증 키는 원문 없이 해시만 남습니다.

조회 축은 일자 단위 파티션 위에 사용자별·이벤트 종류별 보조 인덱스(GSI)를 두어 분리했습니다. “이 사람이 최근에 뭘 했나”는 사용자 인덱스로, “가드레일 위반만 모아 보자”는 이벤트 종류 인덱스로 조회합니다. 감사 테이블에는 모델 호출·정책 위반 등 여러 이벤트 종류가 함께 담기는데, 종류별 인덱스 하나로 조회가 되다 보니 새 이벤트가 추가돼도 테이블이나 인덱스를 늘릴 필요가 없었습니다. 한편 일자 단위 파티션은 하루치 쓰기가 한 파티션에 모이는 구조여서 용량 한도를 함께 봐야 합니다. 현재 트래픽 밀도는 단일 파티션 한도 대비 여유가 크고, 규모가 커지면 파티션 키에 분산 접미사를 더해 확장할 수 있습니다. 조회 축은 이미 보조 인덱스로 분리돼 있어 파티션 키 변경이 조회 경로에 영향을 주지 않습니다.

기본 제공하지 않는 기능(Web Search)은 어떻게 확장할 것인가

AI Gateway를 운영하면서 또 하나의 과제가 나타났습니다.

생성형 AI 서비스는 빠르게 발전하고 있지만, 기업이 실제 업무에 쓰려면 부가 기능이 더 필요한 경우가 많습니다. 대표적인 예가 Web Search입니다. 최신 정보를 다뤄야 하는 AI Agent는 웹 검색 결과를 함께 활용해야 할 때가 많은데, 이 기능을 지원하는 방식은 모델이나 서비스마다 제각각입니다.

Claude Code와 Cowork는 웹 검색이 필요하면 web_search 서버 툴을 요청에 담아 보냅니다. 문제는 Gateway가 이를 그대로 Amazon Bedrock에 전달할 때 생깁니다. Amazon Bedrock이 지원하지 않는 툴 타입으로 판단해 HTTP 400을 돌려주는데, 이는 버그가 아니라 플랫폼 기능상의 경계에서 비롯된 현상입니다.

Amazon Bedrock은 고객 데이터가 외부로 나가지 않는 보안 환경에서 모델을 서빙하지만, Anthropic이 자사 플랫폼(1P)에서 제공하는 web search 같은 서버 툴까지는 기본 모델 호출로 지원하지 않습니다. 보안 제약이라기보다는 지원 범위의 문제에 가깝습니다. GS리테일은 이 공백을 Gateway 레벨에서, 데이터가 AWS를 벗어나지 않는 Amazon Bedrock AgentCore Web Search로 메웠습니다.

GS리테일 클라우드인프라팀은 이를 위해 두 가지 방식을 비교 검토했습니다.

방식	구조	장점	단점
Client Side MCP	클라이언트 → LLM GW(모델 호출) + AgentCore Gateway(검색 직접)	구성 간단, AgentCore에서 web search 활성화 후 MCP 등록만으로 가능	클라이언트가 두 개 백엔드에 각각 접속, 개별 환경에 MCP 추가 설정 필요
Server Side	클라이언트 → LLM GW(모델 호출 + `tool_use` 가로채기 → AgentCore 검색)	클라이언트 설정 변경 없음, 상세 사용량 추적 가능	GW 내부 추가 개발 필요

LiteLLM 훅이 web_search 요청을 가로채 Amazon Bedrock AgentCore Web Search를 호출하고 결과를 모델에 전달하는 흐름

그림 10. Server Side 방식의 Web Search 실행 흐름

여기서 GS리테일은 Server Side 방식을 선택했습니다. LiteLLM의 async_pre_call_hook에서 web search tool을 감지하면 요청을 가로채고, Gateway 내부에서 Amazon Bedrock AgentCore의 Web Search 커넥터(SigV4 인증)를 호출해 결과를 tool_result로 모델에 주입합니다. 클라이언트는 기존과 동일하게 요청을 보내고 동일한 형태의 응답을 받습니다.

LiteLLM Proxy 훅에서 요청을 가로채, Gateway 안에서 검색 루프를 완결하고 클라이언트에는 평소와 똑같은 응답 형태로 돌려주는 것입니다.

요청 도착 (web_search 서버 툴 포함)
native web_search → 커스텀 함수 툴 web_search(query) 로 치환
모델 호출 (stream=false)
모델이 tool_use(web_search, query=”…”) 를 내면
→ AgentCore Web Search 호출 (SigV4)
→ 결과를 tool_result 로 주입 → 3으로 되돌아감
내지 않으면 → 종료
최종 답변을 클라이언트 규격 SSE로 유사 스트리밍(fake streaming)

Server Side 방식의 핵심 장점은 사용량 추적의 완결성입니다.

모델 토큰: 두 방식 모두 Gateway를 경유하므로 동일하게 잡힙니다.
검색 횟수·쿼리·검색비: Client Side는 검색 실행(tools/call)이 클라이언트 안에서 일어나 Gateway를 우회하기 때문에, Gateway는 검색이 몇 번 일어났는지조차 알 수 없습니다. 반면 Server Side는 검색까지 Gateway를 통과하므로 Virtual Key 단위로 검색 비용까지 하나로 집계됩니다.
연산 그룹핑: Client Side는 대화 1건이 Gateway 입장에서 서로 무관한 N개 독립 요청으로 흩어져 “이 대화의 총비용”을 묶어낼 수 없습니다. 대신 Server Side는 하나의 요청 안에서 전 과정이 처리되므로 자연스럽게 한 덩어리로 집계됩니다.

보안 경계 측면의 이점도 있습니다. AgentCore Web Search는 검색 쿼리가 서드 파티 검색 엔진으로 전송되지 않고 AWS 인프라 내부에서 처리됩니다. 따라서 검색 쿼리가 외부 검색 API로 전달되는 데이터 유출 경로를 제거할 수 있습니다. 데이터 egress 심사 부담이 큰 조직에서는 이 점이 결정적일 수 있습니다. 필요하면 도메인 include/exclude 필터로 검색 범위를 추가로 제한할 수도 있습니다.

M365 연동을 위한 AgentCore Gateway + MCP 활용

M365 연동에서 가장 빠른 길은 Claude가 제공하는 M365 커넥터로, 사용자가 설정에서 켜고 Microsoft 로그인만 하면 됩니다. 다만 이 방식에는 두 가지 문제가 있었습니다.

트래픽이 회사 Gateway를 우회: 커넥터를 켜면 Claude 관리형 인프라가 사내 메일·파일·일정에 직접 접근하므로, Gateway에 붙여둔 도구 허용 목록과 감사 로그, 가드레일, 사용량 집계가 적용되지 않습니다. 모델 호출은 AI Gateway를 지나는데 사내 데이터 접근은 지나지 않는, 경계가 반쪽인 상태가 됩니다.
거버넌스 커스터마이징의 어려움: 어떤 도구를 허용할지, 어떤 조직에 열지, 무엇을 감사에 남길지가 모두 커넥터 쪽에 달려있는데 이 경우 회사 계정 권한을 서드파티 관리형 인프라에 위임하는 셈입니다.

그래서 M365 도구를 사내 MCP로 직접 정의하기로 하고, 그 MCP 서버를 자체 서버로 띄울지 AgentCore Gateway에 올릴지를 비교했습니다.

항목	자체 MCP 서버	AgentCore Gateway
도구 정의	코드를 직접 구현	OpenAPI 스펙 등록만으로 Tool 노출
사용자 토큰	전 직원 Refresh Token을 직접 저장·관리	Gateway가 OBO(On-Behalf-Of) 토큰 교환 수행
운영	서버, 스케일링, 가용성을 직접 운영	AWS 관리형 서비스
로깅	직접 구축	Vended Logs 제공
세밀한 제어	완전한 커스터마이징 가능	OpenAPI 스펙 및 설정 범위 내에서 제어

결정을 가른 것은 사용자 토큰이었습니다. M365 도구는 각 사용자가 자신의 메일과 파일에만 접근해야 하므로 앱 권한으로 테넌트 전체를 읽는 방식은 검토 대상이 아니었고, 그렇다면 사용자 위임 토큰(delegated token)이 필요한데 자체 서버로 구현하면 전 직원의 refresh token을 직접 보관·갱신·폐기해야 합니다. MCP 서버 하나를 운영하는 일이 사내 자격증명 관리 시스템을 구축하는 일로 확장되는 지점이었습니다.

AgentCore Gateway를 선택한 이유가 여기 있습니다. TOKEN_EXCHANGE(OBO) 를 사용하면 인바운드 사용자 토큰을 사용자의 delegated identity를 유지한 채 Microsoft Graph용 access token으로 교환하여, 사용자의 권한으로 Graph를 호출할 수 있습니다. 이를 통해 애플리케이션이 사용자별 refresh token을 직접 장기 보관·관리하는 구조를 피할 수 있습니다. 다만 OBO를 쓰더라도 인바운드 사용자 토큰과 교환된 액세스 토큰의 캐시·폐기, 그리고 호출 감사에 대한 책임은 여전히 남으므로, 토큰 수명과 감사 로깅은 AI Gateway에서 별도로 관리합니다.

사용자
  ↓
Entra 로그인
  ↓
인바운드 사용자 토큰
  ↓
Gateway의 OBO Token Exchange
  ↓
Microsoft Graph용 delegated access token
  ↓
사용자 권한으로 Graph 호출

또한 이 구조에서는 Microsoft Entra의 Conditional Access 정책과 연계할 수 있어, 기존에 회사에서 적용하고 있는 MFA 등의 인증 정책을 AI 도구의 Graph 접근 경로에도 적용할 수 있습니다. 단, downstream 리소스에 Conditional Access가 적용된 경우에는 추가 인증을 위한 claims challenge 처리가 필요할 수 있습니다.

마무리

이번 프로젝트를 통해 GS리테일은 AI 운영을 위한 공통 플랫폼을 마련했습니다. 지금까지의 여정을 정리하면 다음과 같습니다.

Shadow IT 리스크를 최소화하면서 AI 도구를 도입했습니다.
LiteLLM 기반 AI Gateway로 모든 호출을 단일 관문으로 모았습니다.
실사용을 견디는 운영 체계를 Gateway 위에 얹었습니다.
플랫폼 기능의 경계를 AI Gateway가 흡수하도록 커스터마이징했습니다.

운영을 시작한 뒤에는 설계 단계에서 예상하지 못한 요구가 이어졌습니다. 예산은 1인당 균등 배분으로 시작할 수 없었고, 감사 로그는 한 저장소에 담을 수 없었으며, 클라이언트가 기대하는 기능과 모델 서비스가 제공하는 기능도 늘 일치하지 않았습니다. GS리테일은 이러한 요구를 AI Gateway에 반영하며 현재의 운영 플랫폼으로 확장했습니다.

생성형 AI는 이제 특정 조직의 실험적인 기술이 아니라 기업 전반의 업무를 지원하는 핵심 플랫폼으로 자리 잡고 있습니다.

기업이 AI를 지속적으로 활용하기 위해서는 새로운 모델을 빠르게 도입하는 것뿐 아니라, 보안과 비용, 운영 정책을 일관되게 적용할 수 있는 체계가 함께 마련되어야 합니다.

같은 고민을 하는 조직이라면 세 가지를 먼저 정하시길 권합니다.

통제 지점을 하나로 둘 것: 도구는 계속 늘어나므로 도구마다 별도의 관리 체계를 만드는 방식은 지속하기 어렵습니다.
사용을 막지 않고 통제할 것: 예산 한도에 도달했을 때 사용을 차단하는 대신 모델을 전환하면 업무 연속성을 유지할 수 있습니다.
통제 범위를 모델 호출에 한정하지 않을 것: 모델 호출뿐 아니라 데이터 접근 경로에도 동일한 거버넌스 정책을 적용해야 합니다.

앞으로 AI 모델과 AI Agent는 계속 진화할 것이고, 이를 안정적으로 운영하기 위한 기반이 더욱 중요해질 것입니다.

GS리테일의 전사 AI Gateway는 이러한 변화에 대응하기 위한 하나의 사례로, AI를 도입하는 것을 넘어 AI를 운영하는 플랫폼을 구축하는 방법을 보여주었습니다.

AI 모델과 도구가 바뀌더라도 운영 플랫폼은 계속 활용할 수 있습니다. 새로운 도구가 등장하면 허용 여부만 검토하는 대신 AI Gateway에 연결하는 방식도 함께 검토합니다. GS리테일은 이 플랫폼을 기반으로 다음 AI 활용 과제를 준비하고 있습니다.

AWS 기술 블로그