AI 에이전트가 영구 저장소가 필요한 이유

Source: Dev.to

문제 개요

AI 에이전트를 2년 동안 구축하면서 가장 큰 문제는 LLM이 아니라 샌드박스라는 것을 깨달았습니다. 대부분의 AI 에이전트 샌드박스(E2B, Modal 등)는 **무상태(stateless)**입니다. 세션이 리셋될 때마다 메모리가 사라져 에이전트가 학습하거나 기억하거나 진화할 수 없습니다.

컴퓨터를 재시작할 때마다 모든 것을 잊어버리는 것을 상상해 보세요—현재 AI 에이전트의 상황이 바로 그것입니다.

현재 샌드박스 문제점

• 지속적인 상태가 없음 – 에이전트가 실수에서 학습할 수 없습니다.
• 샌드박스 내부에 비밀이 존재 – API 키가 손상된 샌드박스에 노출됩니다.
• 접근 제어 부재 – 에이전트가 전체 권한으로 실행됩니다.

최근 연구(beam.ai, 2026)에 따르면 **88 %**의 조직이 AI 에이전트 보안 사고를 경험했습니다. 주요 원인은 손상될 수 있는 샌드박스에 비밀이 저장된 것이었습니다.

Sandbox0 솔루션

저는 다음과 같은 기능을 갖춘 Sandbox0을 만들었습니다:

• 세션 간 메모리 공유
• 스냅샷/복원 에이전트 상태
• 포킹: 메모리를 그대로 유지한 채 에이전트 복제
• 인프라 수준에서 주입되는 API 키
• 선언형 egress 인증 규칙
• HTTP 헤더, gRPC 메타데이터, TLS 인증서 지원
• 제로 트러스트 보안: 샌드박스가 손상돼도 비밀은 안전하게 보호
• 어디서든 실행 가능(로컬, 클라우드, 하이브리드)
• 수평 확장 지원
• 엔터프라이즈 수준

작동 방식

egressAuth:
  - destination: "api.openai.com"
    authRef: "openai-api-key"
    # Key is injected at infrastructure level
    # Sandbox never sees the actual key

에이전트는 OpenAI API를 호출할 수 있지만, 비밀 키는 절대 샌드박스로 들어가지 않습니다.

사용 사례: 고객 지원 에이전트

지속적인 저장소가 없으면 매일이 Day 1로 초기화됩니다.

지속적인 저장소가 중요한 이유

AI 에이전트는 인프라가 되고 있습니다. 필요합니다:

• 메모리 – 학습하고 개선하기 위해
• 감사 – 보안 및 규정 준수를 위해
• 확장성 – 프로덕션 워크로드를 위해

무상태 샌드박스는 이러한 요구를 충족시킬 수 없습니다.

오픈소스 및 제공 예정

Sandbox0은 오픈소스와 클라우드 서비스(곧 출시) 형태로 제공될 예정입니다:

github.com/sandbox0-ai/sandbox0

AI 에이전트 샌드박스를 사용해 본 경험이 있나요? 무상태 장벽에 부딪힌 적이 있나요?