에이블리코퍼레이션(ABLY Corp, 이하 에이블리)은 “셀러와 유저가 상생하는 스타일 생태계”를 목표로 스타일 커머스 플랫폼 에이블리를 운영하는 기업입니다. 자체 개발한 AI 개인화 추천 기술을 기반으로 이용자 취향에 맞는 쇼핑 경험을 제공하고 있으며, 국내를 넘어 글로벌 시장으로도 사업을 확장하고 있습니다. 에이블리 앱의 월간 활성 사용자(MAU)는 1,000만 명을 돌파했으며, 누적 다운로드는 6,000만 회, 누적 리뷰는 1억 개를 넘어섰습니다.
에이블리는 사내 구성원이 자연어로 업무용 웹 애플리케이션을 만드는 AI Builder도 운영합니다. 구성원이 요청하면 에이전트가 프로젝트 파일을 고치고 패키지를 설치하며, 구성원은 프리뷰로 결과를 확인한 뒤 다음 작업을 요청합니다. 그래서 프로젝트마다 파일과 실행 도구를 갖춘 작업환경이 필요합니다. 문제는 이 환경을 언제 만들고 언제 회수하느냐였습니다. 작업은 대화가 끝난 뒤에도 이어질 수 있지만, 사용하지 않는 환경을 계속 켜 둘 이유는 없습니다.
에이블리는 Amazon Elastic Kubernetes Service(Amazon EKS)에서 작업환경의 수명 주기(lifecycle) 관리를 Agent Sandbox에 맡깁니다. 노드의 공급과 회수는 Karpenter에 연결했습니다. 1부는 Agent Sandbox와 gVisor로 격리 계층을 구성했고, 2부는 NetworkPolicy, Warm Pool, 격리 비용, 수명 주기를 다뤘습니다. 3부는 실제 서비스에서 작업환경을 언제 만들고 언제 회수하는지를 에이블리 사례로 살펴봅니다.
시리즈 블로그 보기
AWS에서 AI 에이전트 실행 환경 격리하기 1부: Amazon EKS와 Agent Sandbox, 개념과 구성
AWS에서 AI 에이전트 실행 환경 격리하기 2부: Amazon EKS와 Agent Sandbox, 개념과 구성
AWS에서 AI 에이전트 실행 환경 격리하기 3부: 에이블리의 Amazon EKS 기반 Agent Sandbox 운영 사례
1. Agent Sandbox를 선택한 이유
에이블리에 필요한 것은 프로젝트별 작업공간은 남기고, 사용하지 않을 때는 실행 자원을 회수했다가 다시 준비하는 수명 주기였습니다. 먼저 Kubernetes 기본 워크로드로 구현하는 방법을 검토했습니다.
방식
원래 용도
작업환경에 적용할 때 남는 과제
Deployment
정해진 수의 Pod 유지, 배포와 갱신
중단, 재개, 만료 규칙을 따로 만들어야 함
Job
작업의 완료 관리
실행 한 번이 끝나도 환경은 남아야 하므로 작업 완료와 환경 수명 주기를 분리해야 함
Pod 직접 생성
단일 Pod
생성, 중단, 재생성, 만료를 애플리케이션이 모두 관리해야 함
Agent Sandbox
작업환경 하나를 Sandbox 커스텀 리소스로 표현
실행 스펙, 실행 상태, 만료를 한 리소스에 선언
표 1. 에이블리가 검토한 작업환경 관리 방식
세 가지 기본 워크로드로도 구현은 가능합니다. 다만 수명 주기를 애플리케이션이 모두 책임져야 합니다. 에이블리는 이 역할을 컨트롤러에 맡기는 편이 낫다고 판단했고, 작업환경 단위의 리소스를 제공하는 Agent Sandbox를 선택했습니다.
2. Sandbox 리소스로 작업환경 관리하기
AI Builder 애플리케이션은 프로젝트마다 Sandbox를 하나 만듭니다. Agent Sandbox 컨트롤러는 이 스펙(Spec)대로 작업 Pod를 만들고, Pod는 전용 Karpenter NodePool의 노드에 배치됩니다. 언제 멈출지는 애플리케이션이 정하고, Pod와 노드의 실제 상태는 각 컨트롤러가 맞춥니다.
그림 1. 작업환경과 노드의 수명 주기를 연결한 에이블리 구성 (Is