이 블로그는 GS리테일과 AWS의 협업으로 작성되었습니다. 이 글은 GS리테일의 전사 AI Gateway 구축 사례 1부: 인증·라우팅·계정 자동화 설계에 이어지는 두 번째 글입니다. 1부를 아직 보지 않으셨다면 먼저 읽어보시길 권해드립니다. 1부에서는 GS리테일 클라우드인프라팀이 사내 AI 도구 수요를 조직 차원에서 안전하게 받아내기 위해, 모든 AI 호출을 하나의 관문으로 모으는 전사 AI Gateway를 구축한 과정을 다뤘습니다. Claude on […] ||
이 블로그는 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의 차별점: 실사용을 견디는 운영 체계
사용자 온보딩을 자동화한 Install Center
예산 소진에 따른 자동 모델 라우팅
자체 가드레일 적용
OTEL 기반 자체 관측 파이프라인
운영 현황을 한눈에 확인하는 Leader Lounge
감사 로그: Amazon S3 + Amazon DynamoDB 분리 저장
기본 제공하지 않는 기능(Web Search)은 어떻게 확장할 것인가
마무리
GS리테일 AI Gateway의 차별점: 실사용을 견디는 운영 체계
AI Gateway를 구축한 이후 GS리테일의 다음 과제는 AI Gateway 자체를 운영 가능한 플랫폼으로 만드는 것이었습니다.
AI Gateway가 모든 AI 요청을 중계하더라도, 실제 운영에서는 새로운 요구사항이 계속 발생합니다.
예를 들어 새로운 사용자가 AI 서비스를 이용하려면 어떻게 권한을 부여할 것인지, 조직별 예산은 어떻게 관리할 것인지, 허용되지 않은 모델 사용은 어떻게 차단할 것인지와 같은 문제는 단순한 API Proxy만으로는 해결하기 어렵습니다.
그림 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 설치기 및 프로세스 모니터