발표자: Abhishek Bhardwaj — OpenAI RL & Agent Infrastructure 팀
핵심 키워드: microVM, 샌드박스 보안, 스냅샷 영속성, 대규모 오케스트레이션
1부: 왜 샌드박스가 필요한가 (동기와 배경)
1.1 코드 실행 능력이 AI 모델의 핵심 언락(unlock)이 된 이유
- ChatGPT는 "딸기에 몇 시간이 있냐?"같은 질문에 답을 못 함
- 인터넷에 "3+3=6"은 수없이 등장하지만, 특정 검증 가능한 질문은 데이터 부족
- 핵심 돌파구: 모델에게 코드 실행 도구(Tool Calling)를 주면 검증 가능한 문제를 정확히 풀 수 있음
훈련 루프(Training Loop) 구조
질문/태스크 → 모델이 코드 생성 → 하네스(Harness)가 실행
→ 그레이더(Grader)가 정답 여부 판정 → 역전파(Backprop) → 가중치 업데이트
- 모델이 두 가지를 학습: (1) 어떤 클래스의 문제에서 코드 실행을 호출할 것인지, (2) 실행한 코드가 실제 문제를 풀도록 코드를 잘 짤 것인지
- 결과: 2026년 현재 이 방식이 대규모로 적용되어 AI가 코드·수학에서 강력해짐
1.2 프로덕트 측면 — 어디에서 코드를 실행하는가?
- 훈련 루프와 동일한 구조, 단 훈련 루프 없음
- 코드 실행 위치: 사용자 노트북(Codex CLI, Claude Code 등) 또는 클라우드 노드(Codex Web, ChatGPT)
- 보안 위협:
- 의도적/비의도적 공격 모두 존재
- 모델이 "과잉도움" 시도로 루트 권한 획득 시도 가능
- 다른 사용자의 샌드박스 데이터 탈취 위험
- 결론: 신뢰할 수 없는 코드를 안전하게 실행할 샌드박스 필수
1.3 연구(Research) vs 프로덕트(Product) 요구사항 비교
| 요구사항 | 연구 | 프로덕트 |
|---|---|---|
| 처리량(Throughput) | 매우 중요 (rollout 병렬 실행) | 중요 |
| 지연시간(Latency) | 덜 중요 | 매우 중요 (유저 이탈 직결) |
| 신뢰성(Reliability) | 중요 (GPU 낭비 방지) | 중요 (이탈 방지) |
| 보안(Security) | 중요 (모델이 OpenAI 인프라 공격 가능) | 중요 (유저 데이터 탈취 방지) |
Rollout: 하나의 태스크에 대한 하나의 시도. "3+3" 질문에 5개의 다른 답변 = 5 rollouts
2부: 런타임 보안 — Fork에서 MicroVM까지
2.1 Linux 보안의 기초: 링 구조(Ring Architecture)
- CPU 실행 링:
- Ring 0 (커널 모드): 최고 권한, 모든 시스템 자원 접근 가능
- Ring 3 (유저 모드): 일반 프로세스 실행
- 시스템 콜(System Call): 유저 공간 → 커널 권한 자원 접근 시 CPU 컨텍스트 전환
Linux 시스템의 두 가지 공격 벡터
- Root 획득: Ring 3에서 실행하지만 시스템 최고 권한 유저 = SSH 키, 암호화 데이터 등 모두 접근 가능
- 커널 모드 익스플로잇: Ring 0 실행 = 프로세스 메모리 덤프 등 최악의 시나리오. "뉴욕타임스 기사감"
2.2 방법 1: Fork/Exec (가장 단순, 가장 위험)
- API 서버가 각 도구 호출마다 프로세스를 fork하고 exec
- 장점: 가장 빠름 (네이티브 성능)
- 단점:
- 포크된 프로세스가 커널과 직접 통신 → 루트 획득 또는 커널 익스플로잇 가능
- 악의적
while(fork())루프 → 노이지 네이버(Noisy Neighbor) 문제 → 전체 노드 다운
- 결론: 성능 외 모든 것이 나쁨
2.3 방법 2: 컨테이너 (Linux Namespaces + cgroups)
Namespaces (리소스 격리)
- 컨테이너 내부에서는 PID 1, 2, 3처럼 보이지만 외부에서는 다른 PID
- Mount Namespace: 컨테이너 내부에서 다른 파일 시스템 마운트 가능, 외부에는 원본 마운트 유지
- PID, Network, Mount 등 다양한 네임스페이스 존재
cgroups (리소스 제어)
- 컨테이너가 소비할 수 있는 CPU와 메모리 제어
while(fork())루프가 노드 전체를 다운시키는 것을 방지
Seccomp (시스템 콜 필터링)
- 컨테이너가 호출 가능한 시스템 콜 수 및 인수 제한 → 커널 공격 표면 감소
- 문제: 어떤 시스템 콜이 필요할지 사전에 모름 → 사용자 요청 차단 → 피드백 루프 최악
- AI 에이전트는 "마법 같은 경험"이 필요한데 seccomp이 이를 제한
컨테이너의 근본적 한계
- 동일한 호스트 커널 공유: 리소스가 격리되어도 커널 익스플로잇은 여전히 가능
- 루트 획득 후 다른 사용자 데이터 탈취 가능
2.4 방법 3: gVisor (유저 스페이스 커널)
- 핵심 아이디어: 보안 경계 = 커널 API → 커널 API를 유저 공간에서 구현
- Sentry: Go로 작성된 유저 스페이스 커널. Linux API(프로세스 관리, 워크로드 관리) 구현
- Gopher: 파일 시스템 접근 담당 데몬
- 모든 시스템 콜이 인터셉트되어 Sentry가 서비스 → Ring 3에서만 실행
- 커널 익스플로잇이 커널이 아닌 유저 공간에 머묾
gVisor의 한계
- Sentry와 Gopher가 여전히 호스트 커널 위에서 실행
- 2단계 체인 익스플로잇: Sentry/Gopher 취약점 → 호스트 커널 공격
- 현대 AI 모델이 버그 리포트를 분석하고 체인 익스플로잇을 시도할 수 있음
- 2-step이라 어렵지만 불가능하지 않음
세 방법 모두의 공통 문제
"Fork, 컨테이너, gVisor 모두 결국 호스트 커널에 도달 가능"
2.5 방법 4: MicroVM (하드웨어 레벨 격리) ⭐
가상화의 핵심 원리
- VMX Non-root: 게스트 커널이 Ring 0에서 실행되지만 별도 프로세서 컨텍스트
- VMX Root: 호스트 커널과 하이퍼바이저가 Ring 0 VMX Root 모드에서 실행
- 게스트가 Ring 0을 완전히 제어하지만 호스트는 보호됨
- 성능 페널티: CPU가 게스트↔호스트 컨텍스트 전환 시 무거운 연산
VMM (Virtual Machine Monitor) 구조
- VMM(= QEMU 등)이
/dev/kvm(Linux 커널의 하이퍼바이저 API)에 직접 통신 - 게스트가 블록/네트 디바이스 접근 시 → 호스트 컨텍스트로 exit → VMM 프로세스가 서비스
Para-virtualization (virtio)
- 게스트 드라이버가 "나는 VM 안에서 돌고 있다"는 것을 인식하고 효율적인 virtio 프로토콜로 호스트와 통신
- PCI 디바이스에 접근 → 호스트로 exit → 효율적 처리
- "Linux 마법사들이 20년 전에 만든 놀라운 작품"
Rust 기반 VMM의 등장 (2023년 세이스믹 시프트)
| VMM | 언어 | 특징 |
|---|---|---|
| QEMU | C | 많은 아키텍처 지원, 다양한 디바이스, 메모리 안전성 취약 |
| CrossVM | Rust | Google이 개발 (Chromebook Linux VM 지원), 최초 Rust VMM |
| Firecracker | Rust | CrossVM 포크, AWS Lambda·서버리스에 사용 |
| Cloud Hypervisor | Rust | 범용 VMM, 많은 기업이 기여 |
"MicroVM"이란?
- 내부에서 실행되는 것과 무관, VMM 자체의 특성:
- 더 적은 메모리 풋프린트 (적은 디바이스 지원)
- 더 빠른 부트 (불필요한 코드 제거)
- Rust의 메모리 안전성 + 디바이스 jail(각 디바이스가 자신의 리소스만 접근)
MicroVM의 실제 실행 방법
하네스 → Cloud Hypervisor 바이너리 fork
→ 프로세스가 Unix Domain Socket으로 API 노출
→ create API 호출 (rootFS, 커널, CPU, 메모리 지정)
→ start 호출 → /dev/kvm 직접 호출 → 게스트 MicroVM 시작
→ 게스트 내부 PID 1이 API 서버 노출 (VSOCK 또는 IP 스택으로 통신)
MicroVM 트레이드오프
| 장점 | 단점 |
|---|---|
| 하드웨어 레벨 격리 | 성능 오버헤드 (컨텍스트 전환) |
| 호스트 공격 매우 어려움 | 메모리 공유 어려움 (balloon driver 필요) |
| 디바이스별 jail 가능 | GPU 공유 어려움 (VFIO는 단일 샌드박스만) |
발표자의 조언
"보안 트릭은 성능 문제를 숨길 수 있지만, 보안 침해는 숨길 수 없다. 신뢰는 한 번 잃으면 회복하기 매우 어렵다."
"샌드박싱의 7단계 슬픔": 모든 스타트업이 결국 container → gVisor → v8s를 거쳐 VM이 필요하다는 결론에 도달. 처음부터 MicroVM을 쓰라.
3부: 영속성 (Persistence) — 디스크 스토리지
3.1 왜 영속성이 중요한가
- 현재 클라우드 에이전트들은 디스크 없는 컴퓨터처럼 동작: 세션 종료 시 모든 작업 소멸
- 사용자가 발표 자료, GitHub 저장소를 만들다가 노드가 죽으면 → 작업 전체 손실
- GPU 토큰 낭비 + 사용자 경험 최악
- 핵심: 컴퓨트(compute)가 첫 번째 언락이었다면, 디스크(disk)는 다음 언락
3.2 영속성이 가능하게 하는 세 가지 사용 사례
사용 사례 1: 신뢰성 및 스케일
- 작업 중간에 주기적으로 체크포인트 저장
- 노드/클러스터 장애 시 다른 노드에 정확한 상태로 복구
- 의도적 마이그레이션 (클러스터 업그레이드, AB 테스트)
- "영속성은 신뢰성이다"
사용 사례 2: 장기 실행 태스크 지원
- Codex의 "Gold Mode" — 현재 기록: 3일간 연속 실행
- 태스크가 길어질수록 체크포인팅 필수
- 에이전트가 체크포인트 저장 → 다른 노드에서 복구 → 계속 진행
사용 사례 3: Monte Carlo 탐색 ⭐ (가장 흥미로운 케이스)
- 하네스가 여러 솔루션/샘플 공간을 탐색하고 싶을 때
- 샌드박스 상태를 체크포인트 → Monte Carlo 방식으로 여러 경로 탐색 → 역추적(backtrack) → 다시 체크포인트
- 수 일에 걸쳐 롤아웃 수행 → 최적 솔루션 발견
- 발표자의 희망: 이 인프라가 잘 되면 신약 개발 등 어려운 문제 해결 가능
3.3 스냅샷 솔루션의 요구사항
- 증분 스냅샷(Incremental Snapshotting): 스냅샷 간 diff만 저장 (전체 저장 시 회사 파산 수준 비용)
- 빠른 스냅샷 API: 모델/하네스가 자주 스냅샷 호출 가능해야 함
- 빠른 복구: 프로덕트 경험에서 복구 속도 = 생성 속도와 같이 중요
- 두 가지 패러다임:
- Always-on persistence: 하네스가 명시적 save API 불필요
- Explicit persistence: 하네스가 명시적으로 save API 호출
3.4 Linux 스토리지 기초
유저 공간 파일
↓
파일시스템 (inode: 파일 오프셋 → 논리적 블록 번호)
↓
블록 디바이스 (논리적 블록 0~N)
↓
디스크 펌웨어 (논리적 블록 → 물리 섹터/페이지)
MicroVM 내 스토리지 접근 방식
| 방식 | 특징 | 성능 |
|---|---|---|
| 폴더 공유 (9P/virtiofs) | 파일시스템 연산마다 exit | 비효율적 |
| 블록 디바이스 전달 | 게스트 내 캐시 활용, 실제 접근 시만 exit | 효율적 ✓ |
3.5 명시적 영속성 구현: Copy-on-Write + fiemap
베이스 이미지 (ChatGPT/Codex 베이스)
↓ (zero-copy, 즉시)
쓰기 가능 레이어 (XFS CoW)
↓ (파일 변경 시에만 블록 페널티 발생)
snapshot() 호출:
→ fiemap으로 변경된 블록 위치와 범위 파악
→ 변경 블록 zip으로 압축
→ 클라우드 업로드 (백그라운드, 즉시 snapshot ID 반환)
→ artifact + snapshot lineage 저장
복구 시:
snapshot ID 제공
→ lineage(스냅샷 계보) 파악
→ 레이어 순서대로 다운로드 및 적용
→ 블록 수준에서 정확히 동일한 상태의 MicroVM 복구
3.6 Always-on 영속성 구현: NBD + 계층 캐시
MicroVM 내부 → NBD(Network Block Device) 블록 디바이스처럼 보임
↓
계층 캐시 (tiered cache)
- L1: 인클러스터 캐시 (빠름)
- L2: 클라우드 오브젝트 스토리지 (GCS/S3)
- NFS는 성능이 떨어지고 POSIX 비호환
- AI 모델은 POSIX 표준 환경에서 잘 동작
- 블록 레벨 캐싱으로 글로벌 계층 아키텍처 구현
핵심 메시지: "스토리지는 다음 언락이다. 샌드박스를 만들고 있다면 무엇을 빠르게 스냅샷하고 복구할 수 있는지 생각하라."
4부: 오케스트레이션 — 대규모 플릿 운영
4.1 클러스터 토폴로지
글로벌 컨트롤 플레인 (리전, 부하 등으로 클러스터 선택)
↓
클러스터 (노드 그룹)
↓
스케줄러 (노드 선택: 부하, 장애 여부 등 고려)
↓
개별 노드 (MicroVM 실행)
- 핵심 북스타: 낮은 지연시간 + 신뢰성
- 하네스와 가까운 클러스터 선택으로 빠른 접근 보장
4.2 저지연 샌드박스 생성 전략
전략 1: 사전 워밍 (Pre-warming)
- 샌드박스를 미리 생성해두고 요청 시 즉시 제공
- 단점: 유휴 상태에서 CPU/메모리 낭비
전략 2: 메모리 스냅샷 JIT 복구
- MicroVM 메모리 스냅샷을 저장해두고
- 요청이 오는 순간 밀리초 단위로 복구 시작
- 장점: 유휴 자원 낭비 없음
전략 3: 하이브리드 (권장)
- 웜 풀(Warm Pool) 유지하되, 풀 성장 시 메모리 스냅샷에서 확장
- 두 방법의 장점 결합
4.3 스냅샷 인식 스케줄링
- 스냅샷 복구 시 레이어 계보(lineage)가 여러 개일 수 있음
- 스케줄러가 이미 해당 레이어를 보유한 노드에 높은 점수 부여
- 결과: 다운로드 최소화 → 더 빠른 생성 + 더 안정적인 오케스트레이션
스냅샷 lineage: Layer A → Layer B → Layer C → Layer D
노드 A: Layer A, B 보유
노드 B: Layer A, B, C, D 모두 보유 ← 스케줄러 선택
노드 C: Layer C, D 보유
핵심 인사이트 요약
| 레이어 | 기술 | 핵심 가치 |
|---|---|---|
| 보안 기반 | MicroVM (Firecracker/Cloud Hypervisor) | 하드웨어 레벨 게스트/호스트 격리 |
| 언어 안전성 | Rust 기반 VMM | 메모리 안전, 디바이스 jail |
| 영속성 | CoW + fiemap 증분 스냅샷 | 빠른 저장·복구, Monte Carlo 탐색 |
| Always-on | NBD + 계층 캐시 | 실시간 블록 레벨 영속성 |
| 오케스트레이션 | 스냅샷 인식 스케줄링 | 최소 다운로드, 고속 생성 |
발표자의 3대 결론
- 처음부터 MicroVM을 쓰라 — "샌드박싱의 7단계 슬픔"을 건너뛰어라
- 스토리지는 다음 언락 — 디스크 영속성이 에이전트를 진정한 지식 노동자로 만든다
- Monte Carlo 탐색 — 체크포인팅 인프라가 완성되면 며칠에 걸친 탐색으로 신약 개발 같은 어려운 문제를 풀 수 있다
노트 생성: 2026-07-14 | 영상 완전 커버 (100%)