안전하고 확장 가능한 에이전트 샌드박스 인프라를 구축한 방법

Browser Use는 수백만 개 웹 에이전트를 운영하며, 처음에는 AWS Lambda에서 브라우저 전용 에이전트를 돌렸다. 이후 Python 실행과 shell 명령까지 더했지만, 에이전트 루프와 REST API가 같은 백엔드를 공유하면서 재배포 때 실행 중인 에이전트가 끊기고 메모리 집약적 작업이 API를 흔드는 문제가 생겼다.

해법은 위험한 도구만 분리하는 Pattern 1이 아니라, 에이전트 전체를 비밀 없는 샌드박스에 넣는 Pattern 2였다. 샌드박스는 외부와 직접 통신하지 않고, 모든 요청을 control plane이 대신 처리한다.

운영에서는 같은 이미지가 Unikraft micro-VM으로, 개발과 eval에서는 Docker 컨테이너로 실행된다. sandbox_mode: 'docker' | 'ukc' 하나로 경로를 바꾸며, 프로덕션에서는 Unikraft Cloud REST API로 AWS의 dedicated bare metal machines 위에 프로비저닝한다. Unikraft는 scale-to-zero를 기본 제공해 유휴 상태에서는 VM이 suspend되고 다음 요청에 즉시 resume되며, 샌드박스는 여러 Unikraft metro로 분산된다. 샌드박스에는 SESSION_TOKEN, CONTROL_PLANE_URL, SESSION_ID만 들어가고, VM은 private VPC에서 control plane 외에는 권한이 없다.

보안 강화도 단계적으로 넣었다.

• Python 소스는 빌드 시 .pyc로 컴파일한 뒤 .py를 삭제한다.
• 엔트리포인트는 root로 시작하지만 곧바로 setuid/setgid로 sandbox 사용자로 권한을 낮춘다.
• 환경 변수는 읽은 뒤 os.environ에서 지워 노출을 줄인다.

control plane은 FastAPI 기반의 stateless proxy로, LLM 호출과 S3 파일 저장, billing을 모두 중계한다. 각 요청은 Bearer session_token으로 세션을 검증한 뒤 실제 자격 증명으로 실행되고, 전체 대화 히스토리는 DB에 보관된다. 샌드박스의 /workspace 변경은 session-scoped presigned URL로 S3에 동기화돼 AWS 자격 증명이 샌드박스에 남지 않으며, 내부에는 ControlPlaneGateway와 DirectGateway를 둬 프로덕션과 개발 경로를 같은 인터페이스로 맞췄다.

결국 ECS Fargate 위의 control plane은 private subnets behind an ALB에서 CPU 기준으로 오토스케일하고, Unikraft 샌드박스와 백엔드도 각자 병목에 맞춰 독립적으로 스케일한다. 대가로 모든 작업에 네트워크 홉이 하나 더 생기고 서비스 수는 늘었지만, LLM 응답 시간에 비하면 지연은 거의 의미 없다고 봤다. 핵심 원칙은 단순하다. 에이전트가 훔칠 만한 것도, 보존할 만한 것도 없게 만드는 것이다.