AI를 컨테이너에 넣었다고 끝이 아니다: 에이전트 샌드박스의 진짜 경계

 

AI 에이전트 샌드박스, 왜 지금 실행 환경을 다시 설계해야 할까

AI 에이전트 샌드박스는 모델이 생성한 코드와 명령을 제한된 실행 환경에서 처리하도록 만드는 장치다. 그러나 컨테이너를 하나 띄웠다는 사실만으로 데이터 유출과 권한 오남용까지 해결되지는 않는다. 파일 접근, 네트워크 연결, 자격증명 사용, 실행 시간과 자원 소비를 각각 통제해야 실제 업무에 투입할 수 있다. 이 글은 그 경계를 나누고, gVisor와 가상머신 기반 격리의 차이부터 운영 검증까지 살펴본다.

 

챗봇은 틀린 문장을 만들 수 있다. 코드를 실행하는 에이전트는 그 문장을 실제 파일 변경이나 외부 요청으로 바꾼다. 검색 결과를 읽다가 잘못된 지시를 받아들였을 때, 답변 품질의 문제가 실행 권한의 문제로 이어지는 이유다. 모델을 더 신중하게 만드는 작업과 실행 환경에서 가능한 행동을 제한하는 작업은 함께 필요하다.

 

여기서 자극적인 결론은 단순하다. 샌드박스를 탈출하지 않아도 사고는 일어날 수 있다. 작업 공간에 고객 원본 자료가 있고 외부 업로드 API가 허용되어 있다면, 프로그램은 부여받은 권한만으로 자료를 전송할 수 있다. 이 경우 런타임 격리는 정상적으로 작동했어도 서비스의 보안 목표는 실패한다. 따라서 제품 이름보다 먼저 확인할 것은 에이전트가 읽고 쓸 수 있는 대상이다.

 

이 글은 2026년 10월 30일 확인한 Anthropic과 gVisor 공식 문서, AWS 한국 기술 블로그와 Sionic 기술 블로그를 바탕으로 작성했다. 직접 수행한 성능 실험이나 침투 테스트 결과를 제시하는 글은 아니다. 아래 업무 시나리오는 설계 원리를 설명하기 위한 가상 사례이며, 특정 업체의 현재 내부 구현을 추정하지 않는다.

샌드박스란 무엇인가: 안전한 방보다 중요한 것은 출입 규칙이다

샌드박스는 신뢰하기 어려운 프로그램이 접근할 수 있는 자원을 제한하는 실행 환경이다. 프로세스가 어떤 파일을 읽는지, 어떤 시스템 기능을 호출하는지, 어느 서버에 연결하는지를 기술적으로 제한한다. 같은 단어라도 운영체제 수준의 제한, 컨테이너, 사용자 공간 커널, 가상머신 등 구현 방법은 다를 수 있다. 이름이 같다고 보장하는 범위가 같지는 않다.

 

보안 목표를 문장으로 먼저 적으면 선택이 쉬워진다. 예를 들어 “업로드된 표 파일을 분석하되 다른 사용자의 자료를 읽지 못하고, 인터넷에 원본을 전송하지 못하며, 정해진 비용 안에서 종료한다”는 목표를 세울 수 있다. 이 문장은 파일 격리, 사용자 간 격리, 네트워크 정책, 자원 제한이라는 별도의 요구사항으로 분해된다. 런타임 하나를 선정하는 것만으로 완료할 수 없는 이유다.

 

반대로 “안전한 AI 실행”처럼 추상적인 목표는 검증하기 어렵다. 무엇이 금지되어 있는지 없으면, 차단된 명령 하나를 보고 성공했다고 판단하기 쉽다. 운영자는 허용해야 하는 정상 작업과 반드시 거부해야 하는 작업을 함께 정의해야 한다. 차단이 너무 넓으면 서비스가 멈추고, 허용이 너무 넓으면 격리 환경이 단지 실행 장소만 바꾼 셈이 된다.

 

프롬프트에도 경계 설명을 넣을 수 있다. 다만 “민감한 정보를 전송하지 마라”는 문장은 정책 안내이며 실행 통제 자체는 아니다. 모델이 안내를 오해하거나 외부 문서를 지시로 받아들이더라도, 환경이 금지된 접근을 거부하도록 만들어야 한다. 모델의 판단과 운영체제의 권한 검사가 서로 다른 층에서 작동하도록 설계하는 것이 핵심이다.

일반 컨테이너와 gVisor, 가상머신은 무엇이 다른가

일반적인 리눅스 컨테이너는 네임스페이스와 자원 제어 등을 이용해 실행 환경을 구분하면서 호스트 커널을 공유한다. 가볍고 배포 생태계가 풍부하다는 장점이 있다. 그러나 생성 코드를 신뢰하기 어렵다면 호스트 커널과 만나는 공격 표면, 부여된 권한, 마운트된 경로를 더 엄격하게 검토해야 한다. 컨테이너 이미지를 사용한다는 사실은 독립된 커널을 가진다는 뜻이 아니다.

 

gVisor는 Sentry라는 사용자 공간 구성요소가 애플리케이션의 시스템 인터페이스를 구현하는 방식으로 추가 경계를 제공한다. 애플리케이션이 호스트 커널의 넓은 인터페이스를 직접 사용하는 경로를 줄이는 것이 중요한 목적이다. 가상 하드웨어 위에 완전한 게스트 운영체제를 올리는 전통적인 가상머신과 구조가 다르며, 호환성과 성능 특성도 동일하게 취급할 수 없다.

 

Kata Containers처럼 가상머신 기반의 경계를 사용하는 접근은 별도의 게스트 커널을 활용한다. 이때도 가상화 계층, 장치 연결, 공유 파일 시스템, 관리 서비스가 설계 범위에 들어온다. “가상머신이니까 모든 위험이 사라진다”는 결론은 성립하지 않는다. 네트워크와 API 권한은 여전히 별도의 문제이며, 게스트가 사용할 수 있도록 전달한 자료는 게스트 안의 프로그램도 이용할 수 있다.

 

선택 기준은 기술의 서열보다 작업의 특성이다. 지원해야 하는 라이브러리, 파일 처리량, 시스템 호출 빈도, GPU 사용 방식, 시작 지연, 세션 밀도, 운영팀의 대응 능력을 함께 봐야 한다. 작은 예제의 실행 성공만으로 실제 업무 호환성을 판단하면 안 된다. 패키지 설치와 대용량 결과물 생성까지 포함한 대표 작업을 준비하는 편이 현실적이다.

 

gVisor 공식 보안 모델은 샌드박스가 안전한 아키텍처를 대신하지 않는다고 설명한다. 허용된 파일과 네트워크는 샌드박스 내부에서도 사용할 수 있다. 따라서 이 글에서 gVisor는 호스트 접근을 줄이는 실행 경계로 설명하며, 자동으로 인터넷을 차단하거나 비밀 정보를 보호해 주는 완성품으로 설명하지 않는다.

파일 시스템 경계: 작업 폴더가 곧 데이터 권한이다

문서 분석 에이전트에 저장소 전체를 마운트하는 것은 편리하다. 필요한 파일을 알아서 찾을 수 있기 때문이다. 그러나 그 편리함은 모델이 접할 수 있는 자료의 범위를 넓힌다. 작업에 필요한 입력만 별도 공간으로 복사하고 결과물 경로를 분리하면, 잘못된 파일 탐색이 일어나더라도 영향을 줄일 수 있다. 데이터 최소화는 모델 호출 이전의 실행 환경 설계에서 시작한다.

 

읽기 전용 루트 파일 시스템은 기본 프로그램과 설정이 임의로 변경되는 범위를 줄이는 데 도움이 된다. 그렇다고 모든 파일 쓰기가 없어지는 것은 아니다. 분석 결과와 임시 파일을 만들 경로는 별도로 필요하다. 쓰기 가능한 경로가 어디인지, 용량 제한이 있는지, 다른 세션과 공유되는지, 종료 후 보관되는지를 명시해야 한다. 허용된 쓰기 경로에 비밀 파일을 넣어두지 않는 것도 중요하다.

 

사용자 A와 사용자 B의 작업 공간은 논리적인 이름만 달라서는 부족하다. 실제 스토리지 권한과 경로 매핑이 분리되어야 한다. 재사용하는 실행 환경에 이전 사용자의 캐시, 다운로드 파일, 환경 변수, 프로세스가 남아 있으면 경계가 무너질 수 있다. 빈 디렉터리처럼 보이는지만 확인하지 말고 세션 종료와 다음 배정 사이의 정리 과정을 검증해야 한다.

결과물 회수도 별도 단계로 다루는 편이 좋다. 에이전트가 만든 파일의 위치와 크기, 허용한 형식, 전달 대상을 검사한 뒤 사용자에게 제공한다. 임시 디렉터리 전체를 그대로 내보내면 중간 생성물이나 입력 원본이 함께 나갈 수 있다. 저장 기간과 삭제 책임까지 정해 두어야 실행이 끝난 뒤에도 데이터 통제가 이어진다.

네트워크 경계: HTTPS 허용은 목적지 검증과 다르다

네트워크 정책에서 자주 생기는 착각은 암호화된 연결을 안전한 연결로 보는 것이다. HTTPS는 전송 내용을 보호하는 데 쓰이지만, 누구에게 어떤 자료를 보낼 수 있는지를 대신 판단하지 않는다. 외부의 모든 443번 포트 연결을 허용하는 정책과 승인된 업무 API만 허용하는 정책은 다르다. 허용 범위를 설명할 때 포트와 목적지를 구분해야 한다.

 

에이전트가 패키지를 내려받고 검색 API를 사용해야 한다면 무조건적인 인터넷 차단만으로는 업무를 수행하기 어렵다. 필요한 통신을 나열하고, 가능한 경우 실행 환경 밖의 프록시나 게이트웨이에서 목적지와 요청을 검사하는 구조를 고려할 수 있다. 다만 프록시를 만들었다고 우회 경로가 자동으로 사라지지는 않는다. 직접 연결이 차단되는지 실제 트래픽으로 확인해야 한다.

 

도메인 허용 목록에도 한계가 있다. 같은 서비스 안에서 문서 조회와 파일 업로드, 개인 공간과 조직 공간이 함께 제공될 수 있다. 특정 도메인을 허용했다는 사실만으로 어떤 계정과 어떤 자원에 접근하는지까지 제한되지는 않는다. 중요한 작업은 요청 경로, 메서드, 대상 자원, 사용자 소유권 같은 업무 의미를 권한 검사에 포함해야 한다.

 

DNS와 리디렉션, 내부 주소 접근도 정책 설계에 들어간다. DNS 조회를 허용하는 것과 모든 이름에 대한 정보 전달을 허용하는 것은 운영상 다른 문제다. 최초 목적지를 검사한 뒤 다른 주소로 이동하는 요청을 어떻게 처리할지도 정해야 한다. 이 글은 공격 방법을 소개하려는 것이 아니라, 단일한 도메인 검사만으로 충분하다고 판단하지 말아야 한다는 점을 강조한다.

 

Kubernetes에서는 NetworkPolicy 객체가 존재하는지보다 사용하는 네트워크 구성요소가 그 정책을 실제로 집행하는지가 중요하다. AWS의 EKS 사례도 CNI 설정과 정책 적용 시점을 확인해야 한다고 설명한다. 문서에 선언된 차단 규칙과 실행 중 관측한 차단 결과를 연결해야 한다. 허용 목록에 없는 외부 테스트 서버로의 연결이 거부되는지 안전한 검증 환경에서 확인할 수 있다.

자격증명 경계: 비밀을 넣지 않는 설계가 먼저다

샌드박스에 장기 관리자 키를 넣은 뒤 외부로 나가지 못하게 막는 방식은 관리 부담이 크다. 네트워크 정책이 바뀌거나 허용된 API가 넓어질 때 위험이 다시 커지기 때문이다. 가능하다면 실제 비밀은 실행 환경 밖의 신뢰할 수 있는 서비스에 보관하고, 에이전트에는 작업에 필요한 최소한의 능력만 제공하는 구성을 검토해야 한다.

 

Anthropic의 Claude Code 샌드박싱 설명에는 파일 시스템과 네트워크 격리를 함께 적용하는 접근이 나온다. 웹 실행 환경의 Git 연동 사례에서는 실제 자격증명을 프록시 쪽에 두고, 요청의 대상과 허용된 동작을 확인한 뒤 사용한다. 여기서 참고할 원칙은 특정 제품을 그대로 복제하는 것이 아니라, 비밀 보관과 비신뢰 코드 실행의 책임을 나누는 것이다.

단기 토큰을 쓴다고 모든 문제가 해결되는 것도 아니다. 만료 전에는 사용할 수 있고, 그 시간 안에 허용된 범위의 동작을 수행할 수 있다. 토큰의 수명뿐 아니라 대상 저장소, 조직, 경로, 읽기와 쓰기 권한, 취소 방법을 함께 정해야 한다. “유효 시간이 짧다”와 “피해 범위가 작다”는 서로 관련이 있지만 동일한 조건은 아니다.

 

클러스터 환경에서는 서비스 계정과 클라우드 권한도 점검해야 한다. 워크로드가 Kubernetes API를 호출할 이유가 없다면 해당 자격증명을 자동 전달할 필요가 있는지부터 확인한다. 런타임이 강하게 격리되어도 정당하게 전달된 관리자 권한을 사용하면 서비스 전체가 영향을 받을 수 있다. 이 문제는 컨테이너 탈출 여부와 별개로 다뤄야 한다.

에이전트 제어부와 실행부를 분리하는 현실적인 구조

가상의 사내 보고서 분석 서비스를 생각해 보자. 사용자는 매출 표를 올리고 요약과 차트를 요청한다. 제어부는 사용자 인증, 작업 권한, 모델 호출, 도구 선택을 관리한다. 실행부는 제한된 작업 공간에서 분석 코드를 실행한다. 결과 검증부는 생성 파일을 확인하고 원래 요청한 사용자에게 전달한다. 이 구분은 책임을 분명하게 하기 위한 개념적 구조다.

 

중요한 점은 실행부가 제어부의 모든 기능을 사용할 수 없게 하는 것이다. 분석 프로그램이 샌드박스 생성 API나 다른 사용자의 세션 조회 API까지 호출할 수 있다면, 계산 공간을 격리해도 관리 경계가 넓게 열려 있다. 제어용 라우터와 관리 엔드포인트의 인증, 대상 세션 소유권, 권한 검사는 별도로 필요하다.

 

도구 인터페이스도 좁히는 편이 좋다. “아무 URL로 요청”하는 도구보다 “현재 사용자가 접근 가능한 문서의 지정 필드를 조회”하는 도구가 권한을 표현하기 쉽다. 물론 도구가 좁아도 구현이 권한을 검사하지 않으면 안전하지 않다. 모델이 전달한 사용자 식별자만 믿지 말고 서버가 인증된 주체와 자원 소유권을 연결해야 한다.

 

실행 환경에 오류가 생겼을 때 제어부가 더 넓은 권한으로 재시도하는 자동 복구도 주의해야 한다. 정책 때문에 막힌 작업을 일반 실행기로 넘기는 동작은 격리를 무력화할 수 있다. 재시도는 같은 경계를 유지하는지 확인하고, 필요한 권한이 달라지는 경우에는 별도의 승인 흐름이나 명시적인 실패 결과로 처리하는 편이 타당하다.

세션 수명주기와 웜 풀: 빠르게 시작하는 만큼 정리도 중요하다

에이전트 실행은 짧은 요청 하나로 끝나지 않을 수 있다. 파일을 다운로드하고 분석한 뒤 추가 질문을 받아 같은 상태를 이어갈 수 있다. 따라서 생성, 배정, 실행, 중지, 만료, 결과 회수, 삭제의 수명주기를 설계해야 한다. 단순히 프로세스를 시작하는 API만 있으면 남은 자원과 데이터의 책임이 불분명해진다.

 

AWS 한국 기술 블로그의 Agent Sandbox 사례는 Kubernetes에서 이런 수명주기를 선언적으로 관리하는 접근을 다룬다. Sandbox와 템플릿, 사전 준비된 풀, 요청을 연결하는 구조가 소개된다. 여기서 Agent Sandbox라는 관리 프로젝트와 gVisor나 Kata 같은 실제 실행 격리 기술을 구분해야 한다. 관리 리소스가 생겼다는 사실만으로 강한 런타임 경계가 자동으로 생기지는 않는다.

웜 풀은 미리 준비한 실행 환경으로 시작 지연을 줄이려는 방식이다. 대신 유휴 자원 비용과 이미지 갱신, 배정 전 상태 확인, 사용자 간 잔여 데이터 제거가 운영 과제가 된다. 사전에 준비한 환경이 오래된 정책이나 패키지를 계속 사용하는지도 확인해야 한다. 빠른 응답 하나만 측정하면 이 비용과 위험이 드러나지 않는다.

 

동시에 여러 작업이 몰릴 때의 동작도 필요하다. 풀이 비었을 때 대기할지 새 환경을 만들지, 최대 몇 개까지 허용할지, 오래된 세션을 언제 종료할지를 정한다. 특히 실패한 작업을 무제한으로 재생성하면 실행 비용이 늘고 다른 사용자의 요청을 밀어낼 수 있다. 격리의 품질은 정상 경로만큼 장애와 정리 경로에서도 드러난다.

자원 제한이 없으면 안전한 실행도 서비스 장애가 된다

악의적인 코드가 아니어도 생성된 프로그램은 큰 메모리를 사용하거나 끝나지 않는 계산을 만들 수 있다. 잘못된 반복문, 예상보다 큰 압축 파일, 너무 많은 중간 결과물은 흔한 실패 요인이다. CPU와 메모리뿐 아니라 프로세스 수, 디스크 용량, 출력 크기, 실행 시간과 동시 실행 수를 업무에 맞게 제한해야 한다.

 

타임아웃은 모델 응답과 실제 실행을 구분해서 설계한다. 프런트엔드가 기다리기를 멈췄다고 서버의 계산이 종료되는 것은 아니다. 사용자가 취소했을 때 자식 프로세스와 외부 작업까지 정리되는지 확인해야 한다. 연결이 끊어진 작업이 뒤에서 계속 과금되거나 다음 요청과 파일을 공유하지 않도록 세션 상태를 관리한다.

 

결과 로그도 자원이다. 프로그램이 무제한 출력을 만들면 로그 저장 비용과 관측 시스템에 부담을 줄 수 있다. 출력 길이를 제한하고 초과 사실을 남기되, 로그에 원본 문서나 토큰이 그대로 기록되지 않도록 해야 한다. 디버깅을 위해 모든 입력과 출력을 저장하는 관행은 데이터 보관 범위를 불필요하게 넓힐 수 있다.

 

gVisor 공식 문서도 자원 고갈 방어에서 호스트의 자원 제어를 함께 고려한다. 샌드박스는 한 번의 설치로 끝나는 보안 스위치가 아니다. 런타임, 오케스트레이터, 네트워크 계층, 저장소와 관측 시스템이 각자 맡는 제한을 연결해야 전체 서비스의 가용성과 비용을 관리할 수 있다.

성능 비교에서 빠지기 쉬운 조건과 잘못된 결론

샌드박스 기술을 비교할 때 “몇 밀리초에 시작한다”는 숫자는 눈에 잘 들어온다. 그러나 이미지가 이미 내려받아져 있는지, 실행 환경을 새로 만드는지, 웜 풀을 쓰는지, 노드가 같은지에 따라 결과가 달라진다. 시작 지연과 코드 실행 시간, 파일 입출력, 결과 회수 시간을 분리해 봐야 사용자 체감 속도를 설명할 수 있다.

 

AWS 사례의 특정 실행 수치나 다른 블로그의 마이크로벤치마크를 우리 서비스의 평균 성능으로 가져오면 안 된다. 실험 조건과 표본 수가 충분히 설명되어 있는지 먼저 확인해야 한다. 이 글은 gVisor가 항상 빠르다거나 가상머신이 항상 느리다는 결론을 내리지 않는다. 필요한 호환성과 격리 경계를 충족한 후보를 같은 작업으로 비교하는 것이 합리적이다.

 

대표 작업은 작은 계산뿐 아니라 실제 사용하는 패키지 로딩, 여러 파일 읽기, 큰 결과 파일 쓰기, 허용된 API 호출을 포함해야 한다. 성공한 작업만 평균 내면 실패율과 재시도 비용이 숨는다. 전체 성공률, 상위 지연 구간, 종료 실패, 환경 정리 시간, 작업당 비용을 함께 기록하면 도입 판단에 도움이 된다.

Sionic 기술 블로그는 런타임 비교와 네트워크, RBAC를 한 흐름에서 다뤄 국내 운영자가 문제를 이해하기 쉬운 구성을 보여준다. 다만 다른 글에 제시된 세부 지원 범위와 성능 수치는 버전과 조건에 따라 달라질 수 있다. 본문에서는 그 숫자를 재인용해 일반화하기보다 공식 보안 모델로 경계를 확인하고 운영 체크 항목을 도출했다.

운영 전 검증: 차단 로그보다 중요한 것은 실제 결과다

검증은 정상 작업이 되는지와 금지 작업이 거부되는지를 짝으로 구성하면 좋다. 예를 들어 지정한 입력 파일은 읽을 수 있어야 하고 다른 세션의 입력은 읽을 수 없어야 한다. 결과 폴더에는 쓸 수 있어야 하고 운영 설정 경로에는 쓸 수 없어야 한다. 모든 테스트에는 기대 결과와 확인 방법을 적어 두면 정책 변경 후에도 회귀 검증을 할 수 있다.

 

네트워크는 허용된 업무 API와 허용하지 않은 검증용 목적지를 나눠 확인한다. 요청 실패만 보고 정책 차단이라고 판단하면 안 된다. DNS 오류나 서비스 중단 때문에 실패했을 수 있기 때문이다. 정책 집행 계층의 기록과 실행 결과를 연결해 어떤 규칙이 적용되었는지 확인해야 한다. 민감한 실제 데이터 대신 가짜 표식 데이터를 쓰는 것이 좋다.

 

파일과 네트워크뿐 아니라 세션 경계도 검증한다. A 세션을 종료한 후 B 세션에서 A의 표식이 보이지 않는지, 만료된 토큰으로 요청이 거부되는지, 취소된 작업의 프로세스가 남지 않는지를 확인한다. 이런 검증은 고급 공격을 재현하지 않아도 설계 결함을 찾는 데 도움이 된다. 반복 가능한 작은 테스트가 문서상의 자신감보다 실용적이다.

 

환경 내부에 표시되는 커널 버전이나 보안 상태 필드 하나만으로 격리 수준을 판정하지 않는다. 런타임이 호환성을 위해 다른 값을 보여줄 수 있고, 네트워크 접근 방식에 따라 관리 도구의 동작도 달라질 수 있다. 포트 포워딩 실패를 강한 격리의 증거로 해석하는 것도 위험하다. 무엇을 측정한 결과인지부터 분명히 해야 한다.

 

마지막으로 정책을 완화했을 때의 영향도 검토한다. 새 패키지 저장소를 허용하거나 공유 볼륨을 추가하면 기존 검증 결과가 그대로 유지된다고 볼 수 없다. 변경된 권한 범위를 기록하고 관련 테스트를 다시 실행한다. 보안 검토는 최초 출시 시점의 통과 표시가 아니라, 실행 환경이 바뀔 때마다 유지해야 하는 운영 기준이다.

처음 도입한다면 업무 범위부터 작게 잡자

첫 도입 대상으로는 입력과 출력이 명확하고 외부 쓰기 권한이 적은 작업이 적합하다. 예를 들어 익명화한 표 파일에서 통계와 차트를 만드는 업무를 선택할 수 있다. 처음부터 고객 시스템 수정과 배포, 메일 발송을 한 실행 환경에 묶으면 무엇이 필요한 권한인지 구분하기 어렵다. 계산 기능을 검증한 뒤 필요한 연결을 단계적으로 추가하는 편이 좋다.

 

담당자도 나눠야 한다. 애플리케이션 팀은 업무 권한과 결과 검증을, 플랫폼 팀은 런타임과 수명주기를, 보안 담당자는 네트워크와 비밀 관리 정책을 함께 검토할 수 있다. 조직마다 역할은 다르지만 경계별 소유자가 없으면 문제가 생겼을 때 “컨테이너는 정상”이라는 말만 남는다. 실제 책임은 서비스가 달성해야 하는 보호 목표를 기준으로 정한다.

운영 문서에는 허용된 데이터, 통신 목적지, 자격증명 발급 주체, 최대 자원, 세션 보관 기간, 긴급 중지 방법을 남긴다. 장애 시 누구에게 연락하는지와 어떤 권한을 즉시 취소할 수 있는지도 필요하다. 사용자는 내부 런타임 이름보다 자신의 자료가 어디에 쓰이고 작업이 언제 끝나는지를 이해할 수 있어야 한다.

 

샌드박스의 가치는 에이전트가 절대로 실수하지 않는다고 약속하는 데 있지 않다. 실수가 일어났을 때 접근할 수 있는 대상과 지속 시간을 제한하고, 그 결과를 확인하고 복구할 수 있게 만드는 데 있다. 프롬프트 엔지니어링이 행동의 방향을 정한다면, 실행 환경 설계는 그 행동이 현실에서 미칠 수 있는 범위를 정한다.

AI 에이전트 샌드박스 자주 묻는 질문

Q. Docker 컨테이너만 사용하면 AI 에이전트가 안전해지나?

컨테이너는 실행 환경을 나누는 중요한 도구지만, 일반적인 구성은 호스트 커널을 공유한다. 마운트, 권한, 네트워크, 비밀 관리에 따라 접근 범위가 달라진다. 임의 코드를 실행하는 서비스라면 추가 격리 계층의 필요성과 업무 권한을 함께 평가해야 한다.

Q. gVisor를 쓰면 외부 데이터 전송도 자동 차단되나?

그렇지 않다. gVisor의 실행 경계와 네트워크 허용 정책은 별도의 설계 요소다. 프로그램에 허용된 연결은 사용할 수 있으므로 목적지 제한과 API 권한 검사를 함께 적용해야 한다. 허용된 서비스 안에서 어떤 자원에 접근할 수 있는지도 확인해야 한다.

Q. 샌드박스를 쓰면 프롬프트 인젝션 방어는 필요 없나?

외부 콘텐츠를 지시로 받아들이는 문제는 여전히 남는다. 샌드박스는 잘못된 행동이 영향을 미칠 수 있는 범위를 줄이는 역할을 한다. 입력의 신뢰 구분, 도구 권한 검사, 중요한 변경의 승인과 결과 검증을 함께 설계해야 한다.

Q. 보안과 속도 중 무엇을 먼저 선택해야 하나?

먼저 보호해야 하는 자원과 금지할 행동을 정의하고 그 조건을 만족하는 후보를 고른다. 그다음 실제 업무로 시작 지연과 처리량, 실패율과 비용을 비교한다. 격리 조건을 빼고 얻은 빠른 속도는 같은 요구사항 아래의 성능 비교가 아니다.

공식 문서와 국내 기술 블로그 출처

Anthropic, Beyond permission prompts: making Claude Code more secure and autonomous, 2025년 10월 20일. 파일 시스템과 네트워크 경계를 함께 적용하는 이유, 실행 환경 밖에서 자격증명을 다루는 구조를 참고했다. 특정 제품의 효과 수치를 일반적인 보안 성능으로 확대하지 않았다. 원문: https://www.anthropic.com/engineering/claude-code-sandboxing

Making Claude Code safer with sandboxing

 

gVisor, Security Model. Sentry의 역할, 호스트 커널 접근 표면 축소, 허용된 자원과 서비스 API에 대한 한계, 자원 제한의 책임 범위를 확인했다. 문서의 핵심은 샌드박스가 전체 보안 아키텍처를 대신하지 않는다는 점이다. 원문: https://gvisor.dev/docs/architecture_guide/security/

AWS 한국 기술 블로그, AWS에서 AI 에이전트 실행 환경 격리하기 1부: Amazon EKS와 Agent Sandbox, 개념과 구성, 2026년 10월 18일. 실행 수명주기와 RuntimeClass, 네트워크 정책 집행, 관리 경로를 함께 다루는 운영 관점을 참고했다. 원문: https://aws.amazon.com/ko/blogs/tech/aws-ai-agent-sandbox-eks-isolation-part-1/

 

Sionic Tech Blog, 에이전트 시대에 꼭 필요한 컨테이너 샌드박싱 전략, 2026년 3월 18일. 국내 기술 블로그의 문제 제기와 런타임 비교, 네트워크와 RBAC를 이어 설명하는 구성을 참고했다. 세부 성능 수치와 개별 업체의 내부 구현은 독립적으로 검증하지 않아 본문에서 일반화하지 않았다. 원문: https://www.sionic.ai/blog/agent-sandboxing-strategy

에이전트 시대에 꼭 필요한 컨테이너 샌드박싱 전략

 

자료 확인일: 2026년 10월 30일. 제품의 지원 기능과 기본 정책은 버전에 따라 바뀔 수 있다. 실제 도입 시에는 사용하는 런타임과 CNI, 클라우드 환경의 현재 공식 문서를 확인하고 자체 워크로드로 허용과 차단 결과를 검증해야 한다.