AI 에이전트 샌드박스 설계: 코드 실행과 파일 접근을 안전하게 여는 법

AI 에이전트가 실제 업무에 들어오면 가장 먼저 부딪히는 문제는 모델 성능이 아니라 실행 환경입니다. 에이전트가 파일을 읽고, 코드를 실행하고, MCP 서버에 연결하고, 외부 API를 호출하려면 샌드박스가 필요합니다. OpenAI Agents API도 환경을 OpenAI 호스팅 샌드박스, 자체 인프라, 파트너 샌드박스 중에서 고를 수 있게 설명합니다. 선택의 핵심은 “어디서 실행할까”가 아니라 “무엇을 절대 못 하게 할까”입니다.

왜 샌드박스가 필요한가

간단한 챗봇은 텍스트만 주고받습니다. 하지만 업무형 에이전트는 다릅니다. 코드베이스를 분석하려면 파일 시스템이 필요하고, 테스트를 돌리려면 명령 실행이 필요하며, 사내 데이터를 보려면 API나 데이터베이스 접근이 필요합니다. 이 순간 에이전트는 단순한 답변기가 아니라 제한된 권한을 가진 작업자 프로세스가 됩니다.

샌드박스 없이 로컬 또는 서버 권한을 그대로 열면 위험합니다. 프롬프트 인젝션으로 엉뚱한 명령을 실행할 수 있고, 실수로 민감 파일을 읽을 수 있으며, 잘못된 스크립트가 데이터를 삭제할 수도 있습니다. 모델이 악의적이지 않아도 도구 사용 오류는 충분히 발생합니다.

따라서 샌드박스의 목표는 에이전트가 일을 못 하게 막는 것이 아닙니다. 해야 할 일에 필요한 최소 권한만 열고, 나머지는 차단하는 것입니다.

샌드박스 선택 기준

실행 환경은 크게 세 가지로 나눌 수 있습니다.

1. 관리형 샌드박스
2. 자체 호스팅 샌드박스
3. 파트너 또는 클라우드 기반 격리 환경

관리형 샌드박스는 시작이 빠릅니다. 인프라를 직접 만들 필요가 적고, 파일 작업과 코드 실행을 빠르게 붙일 수 있습니다. 단점은 네트워크, 비밀값, 데이터 위치에 대한 통제권이 제한될 수 있다는 점입니다.

자체 호스팅은 통제권이 큽니다. VPC 안에서 실행하고, 사내 보안 정책을 적용하고, 로그와 비밀값 관리를 직접 설계할 수 있습니다. 단점은 구현과 운영 부담입니다. 컨테이너 격리, 타임아웃, 리소스 제한, 네트워크 정책, 파일 정리, 감사 로그를 모두 챙겨야 합니다.

파트너 샌드박스는 중간 선택지입니다. E2B, Daytona, Modal, Vercel 같은 환경을 쓰면 특정 워크로드에 맞는 성능과 배포 방식을 고를 수 있습니다. 단, 벤더별 네트워크 정책과 데이터 보존 정책을 반드시 확인해야 합니다.

권한은 작업 유형별로 나눈다

샌드박스 권한은 넓게 열고 나중에 막는 방식보다 좁게 열고 필요한 것만 추가하는 방식이 안전합니다. 작업 유형별 권한을 나누면 운영이 쉬워집니다.

읽기 전용 조사 에이전트는 파일과 문서를 읽을 수 있지만 쓰기 권한은 없습니다. 로그, 이슈, 문서, 코드 일부를 분석하고 리포트만 생성합니다. 이 단계는 비교적 안전하므로 도입 초기에 적합합니다.

구현 에이전트는 제한된 디렉터리에 파일을 쓸 수 있습니다. 테스트 실행은 허용하지만 배포, 데이터베이스 쓰기, 비밀값 조회는 막습니다. 변경 결과는 PR이나 패치 파일로 남기고 사람이 리뷰합니다.

운영 에이전트는 장애 조사나 배치 작업을 도울 수 있지만, 실제 복구 명령은 승인 기반으로 둡니다. 예를 들어 “캐시 서버 재시작 명령 제안”은 가능하지만 “운영 서버 재시작 실행”은 사람 승인을 거칩니다.

이렇게 나누면 한 에이전트가 모든 권한을 갖는 상황을 피할 수 있습니다.

파일 시스템 설계

파일 접근은 샌드박스 보안의 기본입니다. 에이전트에게 전체 홈 디렉터리를 주면 안 됩니다. 작업별 workspace를 만들고, 필요한 파일만 복사하거나 마운트하는 구조가 좋습니다.

권장 패턴은 다음과 같습니다.

• 작업마다 임시 workspace 생성
• 읽기 전용 입력 디렉터리와 쓰기 가능한 출력 디렉터리 분리
• 비밀값 파일, .env, SSH 키, 클라우드 인증 파일은 기본 제외
• 작업 완료 후 산출물만 보존하고 나머지는 삭제 또는 격리
• 파일 크기와 총 디스크 사용량 제한

코드 작업이라면 저장소 전체를 주기보다 필요한 브랜치와 디렉터리를 명확히 지정합니다. 대형 모노레포를 통째로 읽게 하면 컨텍스트도 낭비되고, 불필요한 파일을 건드릴 가능성도 늘어납니다.

네트워크와 비밀값 통제

에이전트에게 네트워크를 열면 외부 API 호출, 패키지 설치, 문서 조회가 가능해집니다. 동시에 데이터 유출 경로도 열립니다. 그래서 네트워크 정책은 allowlist 방식이 안전합니다.

예를 들어 코드 테스트에 npm registry가 필요하다면 해당 도메인만 허용합니다. 사내 API는 읽기 전용 토큰으로 제한하고, 고객 데이터 API는 샘플 또는 staging만 연결합니다. 외부 웹 검색이 필요한 에이전트와 내부 데이터 접근 에이전트를 같은 환경에서 실행하지 않는 것도 좋은 방법입니다.

비밀값은 환경변수로 무작정 주입하지 말고 작업 단위로 최소화해야 합니다. 토큰은 scope를 좁히고, 만료 시간을 짧게 두며, 로그에 노출되지 않게 필터링합니다. 에이전트가 명령 출력을 그대로 대화에 반환할 수 있기 때문에 secret masking은 필수입니다.

리소스 제한과 타임아웃

샌드박스에는 리소스 제한이 필요합니다. 모델이 생성한 코드가 무한 루프를 돌거나, 테스트가 계속 실패하며 재시도하거나, 대량 파일을 생성할 수 있습니다. CPU, 메모리, 디스크, 실행 시간 제한을 걸어야 비용과 장애를 막을 수 있습니다.

기본 제한 예시는 다음과 같습니다.

• 작업 전체 최대 실행 시간: 15~60분
• 단일 명령 타임아웃: 30초~5분
• 최대 파일 생성 크기: 작업 성격에 따라 제한
• 네트워크 요청 수 또는 총 전송량 제한
• 동시 샌드박스 개수 제한

긴 작업이 필요한 경우 제한을 없애기보다 체크포인트를 둡니다. 중간 산출물을 저장하고 다음 세션에서 이어가게 하면 장애 복구가 쉽습니다.

감사 로그와 재현성

업무용 에이전트에서 “무슨 일이 있었는지”를 재현할 수 없으면 운영하기 어렵습니다. 최소한 다음 로그를 남겨야 합니다.

• 세션 ID와 작업 ID
• 사용한 모델과 프롬프트 버전
• 부여된 도구와 권한
• 읽은 주요 파일 목록
• 실행한 명령과 exit code
• 생성·수정한 파일 목록
• 외부 API 호출 요약
• 사람 승인 여부와 승인자

로그는 단순 디버깅용이 아닙니다. 사고가 났을 때 권한 범위를 확인하고, 비용이 튄 원인을 찾고, 같은 작업을 재현하는 데 필요합니다. 특히 코드 수정 에이전트는 최종 diff만이 아니라 어떤 테스트를 실행했는지까지 남겨야 합니다.

실행 체크리스트

• 에이전트 유형을 읽기 전용, 구현, 운영 액션으로 나눕니다.
• 작업별 workspace를 만들고 전체 홈 디렉터리 접근을 막습니다.
• 입력 디렉터리는 읽기 전용, 출력 디렉터리는 쓰기 가능으로 분리합니다.
• .env, SSH 키, 클라우드 인증 파일은 기본 마운트에서 제외합니다.
• 네트워크는 allowlist로 시작하고 필요한 도메인만 엽니다.
• 비밀값은 scope와 만료 시간을 줄이고 로그 마스킹을 적용합니다.
• CPU, 메모리, 디스크, 단일 명령, 전체 작업 타임아웃을 설정합니다.
• 배포, 삭제, 결제, 고객 연락 액션은 사람 승인 없이는 실행하지 않습니다.
• 세션 ID, 명령, diff, 테스트 결과, 승인 기록을 감사 로그로 남깁니다.

AI 에이전트 샌드박스 설계는 생산성과 보안 사이의 타협이 아닙니다. 좋은 샌드박스는 에이전트가 더 안전하게 더 많은 일을 하게 만드는 기반입니다. 파일 접근, 네트워크, 비밀값, 리소스, 로그를 처음부터 설계하면 에이전트는 실험 도구가 아니라 운영 가능한 작업자가 됩니다.