AI 에이전트 샌드박스 통합, 두 가지 아키텍처 패턴과 선택 기준
목차
개요
AI 에이전트가 코드를 실행할 때 보안을 위해 샌드박스는 필수적이다. 그러나 에이전트와 샌드박스를 연결하는 방식에 따라 성능, 보안, 유지보수성이 크게 달라진다. LangChain 블로그에서 공개한 이 글은 AI 에이전트와 샌드박스를 통합하는 두 가지 핵심 아키텍처 패턴을 분석하고, 각각의 장단점과 선택 기준을 제시한다.
패턴 1: 에이전트가 샌드박스 안에서 실행
Docker나 VM 이미지에 에이전트 프레임워크를 설치하고, 샌드박스 내부에서 에이전트를 구동한 후 외부와 네트워크로 통신하는 방식이다.
장점
- 로컬 개발 환경을 그대로 미러링할 수 있다.
- 에이전트가 파일시스템에 직접 접근할 수 있다.
- 환경 수정이 자유롭다.
단점
- API 키가 샌드박스 내부에 존재하면서 보안 리스크가 증가한다.
- 프롬프트 인젝션 공격으로 인증 정보가 유출될 가능성이 있다.
- 에이전트 업데이트 시 컨테이너를 재빌드하고 재배포해야 하므로 개발 반복 주기가 느려진다.
- 웹 검색 등 높은 권한이 필요한 도구를 안전하게 분리하기 어렵다.
패턴 2: 샌드박스를 도구로 사용
에이전트를 로컬 또는 서버에서 실행하고, 코드 실행이 필요할 때만 원격 샌드박스를 API로 호출하는 방식이다.
장점
- 에이전트 코드를 즉시 업데이트할 수 있어 개발 속도가 빠르다.
- API 키는 샌드박스 외부에 안전하게 보관된다.
- 에이전트 상태와 샌드박스 실행이 명확하게 분리된다.
- 여러 샌드박스를 병렬로 실행할 수 있다.
- 코드 실행 시에만 비용이 발생한다.
- 향후 GPU 머신 활용에 유리하다.
단점
- 네트워크 레이턴시가 발생한다.
- 많은 소규모 실행이 필요할 경우 지연이 누적된다.
- 다만, 상태 유지 세션을 통해 변수, 파일, 설치 패키지를 유지하는 방식으로 완화할 수 있다.
두 패턴 비교
| 항목 | 패턴 1 (에이전트 내부 실행) | 패턴 2 (샌드박스를 도구로) |
|---|---|---|
| 보안 | API 키가 샌드박스 내부에 노출 | API 키를 외부에서 안전하게 관리 |
| 개발 속도 | 컨테이너 재빌드 필요 | 즉시 업데이트 가능 |
| 파일 접근 | 직접 접근 가능 | API를 통한 간접 접근 |
| 병렬 실행 | 제한적 | 여러 샌드박스 병렬 실행 가능 |
| 비용 | 상시 실행 비용 | 실행 시에만 비용 발생 |
선택 기준
패턴 1이 적합한 경우
- 에이전트와 실행 환경이 긴밀하게 결합되어 있을 때
- 프로덕션 환경이 로컬 개발과 최대한 유사해야 할 때
- 샌드박스 제공업체의 SDK가 통신을 처리할 때
패턴 2가 적합한 경우
- 에이전트 로직을 빠르게 반복 개발해야 할 때
- API 키를 샌드박스 밖에 보관하고 싶을 때
- 에이전트 상태와 실행 환경을 명확히 분리하고 싶을 때
LangChain의 오픈소스 프레임워크 deepagents에서 두 패턴 모두 지원한다. 패턴 2의 경우 E2B, Daytona, Runloop, Modal 등의 샌드박스 백엔드를 사용할 수 있다.
결론
아키텍처 선택은 보안, 개발 속도, 유지보수성, 비용에 직접 영향을 미치는 중요한 결정이다. 프롬프트 인젝션이나 샌드박스 취약점 같은 보안 위협이 현실화되는 상황에서, 각 패턴의 공격 표면이 크게 달라질 수 있다. 프로젝트의 특성과 보안 요구사항을 고려하여 적절한 패턴을 선택하는 것이 중요하다.