AI 코드 샌드박스, 격리라는 약속의 실제 무게

AI 에이전트가 코드를 짜는 시대보다 더 불편한 장면은, 그 에이전트가 코드를 직접 실행하는 순간이다. 리뷰어가 놓친 버그는 나중에 고치면 되지만, 샌드박스가 놓친 경계는 이미 호스트 커널 앞까지 도달해 있을 수 있다.

최근 공개된 논문 AI Code Sandboxes: A Comparative Security Study는 이 불편함을 꽤 건조하게 파고든다. arrakis, e2b, microsandbox, gVisor, daytona를 놓고 microVM, userspace kernel, OCI container 계열의 격리 특성을 비교했다. 흥미로운 점은 논문이 최종 승자를 뽑지 않는다는 것이다. 대신 이런 질문을 던진다. 당신이 믿는 샌드박스는 정확히 무엇을 막고 있으며, 무엇은 그냥 운에 맡기고 있는가.

샌드박스라는 단어의 인플레이션

개발자 커뮤니티에서 샌드박스는 너무 쉽게 쓰인다. 컨테이너 안에서 실행하면 샌드박스, 임시 VM이면 샌드박스, 웹 UI에서 터미널을 띄워도 샌드박스다. 하지만 공격자 관점에서 중요한 것은 이름이 아니라 경로다.

게스트 코드가 호스트 커널에 닿기까지 어떤 런타임을 통과하는가. 어떤 syscall이 살아 있는가. /dev 아래 장치가 얼마나 노출되는가. seccomp가 실제로 모든 중요한 스레드에 걸려 있는가. upstream 엔진은 빨리 패치되더라도 제품이 그 버전을 언제 끌어오는가.

논문은 이 문제를 여섯 축으로 나눈다.

이 목록은 화려하지 않다. 그러나 샌드박스 보안에서 진짜 중요한 질문은 대개 이런 지루한 표 안에 있다.

microVM이면 안전하다는 착각

많은 사람이 microVM을 컨테이너보다 더 안전한 선택지로 받아들인다. 대체로 맞는 직감이다. 별도 커널과 가상화 경계를 두는 설계는 OCI 컨테이너보다 격리 논리가 선명하다.

하지만 논문이 보여주는 그림은 조금 더 복잡하다. 같은 microVM 계열이라도 제품별 차이가 꽤 크다. Firecracker 기반 e2b, Cloud Hypervisor 기반 arrakis, libkrun 기반 microsandbox는 모두 같은 문패를 달고 있지만 노출 표면, seccomp 적용 방식, 장치 접근성, 패치 핀ning 정책이 다르다.

특히 운영자 입장에서 무서운 부분은 upstream의 성실함과 제품의 성실함이 다를 수 있다는 점이다. 엔진 쪽 패치는 빠르게 나왔더라도, 제품이 특정 버전을 오래 붙잡고 있으면 실제 위험은 그대로 남는다. 논문은 downstream lag가 0일 수도, 수백 일일 수도, 아예 불투명할 수도 있다고 적는다.

보안에서 오래된 버전은 숫자가 아니라 태도다. 무엇을 언제 따라갈지 정하지 않은 시스템은, 결국 우연히 안전한 날과 우연히 취약한 날을 번갈아 산다.

컨테이너가 나쁘다는 결론은 너무 쉽다

OCI 컨테이너는 호스트 커널을 공유한다. 그래서 커널 LPE나 컨테이너 escape 계열 취약점 앞에서 구조적으로 불리하다. 이 말은 맞지만, 여기서 논의를 끝내면 실무 감각이 부족하다.

컨테이너는 관찰과 운영이 쉽다. 패치 파이프라인이 성숙한 조직에서는 runc와 containerd, 커널 업데이트를 잘 밀어 넣는다. 반대로 microVM 제품이라도 기본 이미지가 느슨하고, 장치 노출이 넓고, 패치 핀ning이 오래 묶여 있으면 기대만큼 단단하지 않을 수 있다.

결국 샌드박스 선택은 종교가 아니라 위협 모델의 문제다.

내가 막으려는 것은 무엇인가?
- 단순한 파일 시스템 오염인가
- 호스트 커널 escape인가
- 다른 tenant와의 격리인가
- 에이전트가 훔칠 수 있는 secret인가
- 패치 지연으로 생기는 known-bad window인가

이 질문에 답하지 않고 microVM, gVisor, container 중 하나를 고르는 것은 엔진 이름으로 리스크를 대체하는 일에 가깝다.

가장 흥미로운 문장: unmeasured is not safe

이 연구에서 가장 마음에 남는 태도는 단순하다. 측정되지 않은 것은 안전하다는 뜻이 아니다.

공개 CVE가 적은 제품은 정말 안전할 수도 있다. 반대로 연구자와 공격자가 충분히 들여다보지 않았기 때문에 조용할 수도 있다. upstream 퍼징이 활발한 프로젝트는 취약점이 더 자주 발견되어 시끄러워 보일 수 있지만, 그 시끄러움 자체가 방어 능력일 때도 있다.

보안 제품을 고를 때 우리는 종종 조용한 대상을 좋아한다. CVE가 적고, 이슈가 적고, 릴리스 노트가 짧으면 안정적으로 느껴진다. 하지만 AI 에이전트 실행 환경에서는 그 침묵이 검증의 부재일 수 있다.

논문이 지적한 빈칸도 의미심장하다. microVM과 지속적 공개 퍼징을 동시에 강하게 만족하는 조합이 아직 비어 있다는 관찰이다. 이는 microVM 접근이 틀렸다는 뜻이 아니다. 오히려 앞으로 AI 코드 실행 인프라가 어디에 투자해야 하는지 알려주는 지도에 가깝다.

AI 보안의 다음 병목은 모델이 아닐 수 있다

AI 보안 논의는 자주 프롬프트 인젝션, 데이터 유출, 모델 정렬로 빨려 들어간다. 물론 중요하다. 하지만 코드 에이전트가 보편화될수록 병목은 더 낮은 층으로 내려간다. 모델이 나쁜 명령을 만들었을 때, 그 명령이 어디까지 실행될 수 있는가. 에이전트가 패키지를 설치하고 테스트를 돌리고 파일을 읽는 동안, 어떤 경계가 마지막 방어선인가.

이 지점에서 샌드박스는 UX 기능이 아니라 보안 제품이 된다. 빠른 실행, 넉넉한 권한, 편한 네트워크, 쉬운 파일 마운트는 개발 경험을 좋게 만들지만 동시에 격리의 의미를 갉아먹는다.

운영자가 확인해야 할 질문은 의외로 실무적이다.

• 샌드박스 엔진 버전은 어디에 고정되어 있는가
• upstream 보안 패치가 제품 릴리스까지 오는 평균 시간은 얼마인가
• 기본 설정에서 네트워크와 secret 접근은 어떻게 제한되는가
• seccomp, AppArmor, cgroup 제한은 실제 실행 경로에 적용되는가
• 실패했을 때 로그는 충분히 남지만 민감정보는 남기지 않는가

이 질문들에 답하지 못하는 AI 실행 환경은, 격리라는 단어를 빌려 쓰고 있을 뿐일 수 있다.

결론

AI 코드 샌드박스의 경쟁은 더 빠른 터미널을 만드는 싸움처럼 보이지만, 실제로는 신뢰 경계를 어디에 그을 것인지의 싸움이다. 이번 연구가 흥미로운 이유는 특정 제품을 승자로 세우지 않아서다. 대신 격리를 평가하는 언어를 제공한다.

앞으로 코딩 에이전트는 더 많은 코드를 만들고, 더 많은 코드를 실행하고, 더 많은 실패를 자동으로 반복할 것이다. 그때 중요한 질문은 에이전트가 얼마나 똑똑한가만이 아니다. 에이전트가 틀렸을 때, 우리가 어디까지 피해를 제한할 수 있는가다.