샌드박싱의 딜레마: 완벽한 격리인가, 끝없는 오버헤드인가

최근 ACM Queue에 흥미로운 제목의 아티클이 하나 올라왔습니다. “Sandboxing: Foolproof Boundaries vs. Unbounded Foolishness” (샌드박싱: 완벽한 경계인가, 끝없는 어리석음인가). 제목부터 제 시선을 확 사로잡더군요. 15년 넘게 인프라와 백엔드 아키텍처를 설계하면서 “이 코드를 안전하게 격리합시다”라는 요구사항이 얼마나 많은 엔지니어링 리소스와 Latency를 갉아먹는지 뼈저리게 경험했기 때문입니다. 안타깝게도 원문 링크는 현재 403 에러를 뱉어내고 있지만, 이 도발적인 제목이 던지는 화두는 우리가 짚고 넘어갈 가치가 충분합니다.

샌드박싱의 환상과 현실

우리는 흔히 Docker 컨테이너나 가상 머신을 도입하면 시스템이 완벽히 격리된다고 믿습니다. 하지만 현실은 그렇게 호락호락하지 않죠. chroot에서 시작해 namespace와 cgroup을 거쳐, 이제는 Firecracker 같은 MicroVM이나 WebAssembly(Wasm), eBPF까지 기술은 발전해왔습니다.

하지만 여기서 딜레마가 발생합니다. 격리 수준(Isolation)을 높일수록 시스템 복잡도와 Overhead는 기하급수적으로 증가합니다.

  • 컨테이너 수준의 격리: 빠르고 가볍지만, 공유 커널을 사용하기 때문에 컨테이너 탈출(Container Breakout) 취약점에 항상 노출되어 있습니다.
  • MicroVM (Firecracker 등): 하드웨어 수준의 격리를 제공해 안전하지만, Cold Start 문제와 네트워크 I/O 병목이라는 새로운 골칫거리를 안겨줍니다.
  • WebAssembly (Wasm): 최근 가장 핫한 샌드박싱 기술이죠. 하지만 호스트 시스템과 상호작용하기 위한 WASI(WebAssembly System Interface) 규격은 여전히 파편화되어 있고, 네이티브 성능을 온전히 뽑아내기엔 아직 한계가 명확합니다.

2019년의 삽질: Seccomp가 만든 Latency 지옥

이 제목을 보니 2019년에 겪었던 장애가 떠오릅니다. 당시 저희 팀은 마이크로서비스 보안을 강화하겠다며 모든 컨테이너에 엄격한 seccomp 프로필을 적용했습니다. 결과는 어땠을까요? 보안팀은 박수를 쳤지만, P99 Latency가 3배 이상 튀어버렸습니다.

시스템 콜을 필터링하는 과정에서 발생하는 Context Switching 비용을 완전히 과소평가했던 겁니다. 결국 우리는 “어느 수준의 격리가 정말 필요한가?”라는 본질적인 질문으로 돌아가야 했습니다. 신뢰할 수 있는 내부 서비스 간의 통신에 외부 Untrusted 코드를 돌릴 때나 필요한 수준의 샌드박싱을 적용하는 것은, 원문 제목이 말하듯 ‘Unbounded Foolishness(끝없는 어리석음)‘에 불과합니다.

Hacker News의 시선

현재 HN 스레드에는 코멘트가 없지만, 평소 이 커뮤니티의 성향을 보면 반응은 안 봐도 비디오입니다. 아마 “Wasm이 미래다”라고 외치는 진영과 “결국 리눅스 커널의 네임스페이스 격리도 제대로 못 쓰면서 새로운 장난감만 찾는다”며 비판하는 시니어 엔지니어들 간의 난상토론이 벌어질 겁니다. 저는 후자의 의견에 조금 더 마음이 갑니다. 도구가 아무리 발전해도 아키텍처의 근본적인 취약점을 샌드박스라는 마법의 상자로 덮을 수는 없으니까요.

결론 (Verdict)

샌드박싱은 모 아니면 도의 문제가 아닙니다. ‘Foolproof Boundaries’를 구축하려다 시스템 전체를 느리고 디버깅하기 불가능한 블랙박스로 만들어버리는 실수를 범하지 마세요.

새로운 샌드박싱 기술(Wasm, eBPF 등)을 프로덕션에 도입하기 전에 반드시 다음을 자문해 보시기 바랍니다. “우리가 격리하려는 대상이 정말로 Untrusted Code인가, 아니면 단순히 아키텍처의 결함을 샌드박스로 가리려는 것인가?”

보안은 중요합니다. 하지만 맹목적인 격리는 엔지니어링의 적입니다.

References