컨테이너는 AI 에이전트를 위한 샌드박스가 아니다

Source: Dev.to

컨테이너가 단순함을 멈추는 지점

컨테이너는 해결된 추상화로 판매됩니다. 파일시스템을 패키징하고, 프로세스를 선언하면 세상이 재현 가능해집니다. 그 이야기는 대부분 사실이지만—컨테이너에게 커널 경계를 넘어 새는 일을 시키는 순간은 예외입니다.

그 순간은 보통 우연히 찾아옵니다.

“그냥 의존성을 하나 더 추가한다.”는 식으로 시작합니다. 도구용 브라우저일 수도 있고, 에뮬레이터일 수도 있고, 더 강력한 격리가 필요한 샌드박스일 수도 있습니다. Dockerfile에 몇 줄을 더 추가합니다. 빌드는 여전히 성공하고, 테스트도 통과합니다. 그리고 조용히, 컨테이너가 실제로 약속할 수 있는 한계에 부딪히게 됩니다.

저는 이 한계에 IDE 환경을 컨테이너화하면서 부딪혔습니다—코드 컴파일만 하는 것이 아니라, 전체 그래픽 툴체인과 에뮬레이터를 브라우저에서 접근 가능한 컨테이너 안에서 실행하는 경우였습니다. 겉으로는 여전히 “그냥 Docker”였지만, 실제로는 불편한 진실과 마주하게 되었습니다:

컨테이너는 커널을 가상화하지 않는다; 커널을 빌려쓴다.

이 점을 내면화하면 많은 컨테이너 전설이 무너집니다.

유저랜드는 쉽지만, 커널은 아니다.

첫 번째 문제 카테고리는 겉보기와는 달리 단순합니다. 환경 내부의 동작을 강화하고 싶습니다—특정 프로토콜 핸들러를 차단하고, 사용자가 링크를 클릭했을 때 일어나는 일을 제한하며, 실수로 탈출구가 생기는 것을 방지하고 싶습니다. 이는 전적으로 유저랜드에 해당합니다.

• 패키지를 설치한다.
• 설정 파일을 만든다.
• 기본값을 제어한다.

이것은 진짜 진전이기 때문에 진전처럼 느껴집니다. 정책을 파일로 표현하는 것이며, 컨테이너는 이 부분에 탁월합니다.

그 다음에 등장하는 두 번째 문제 카테고리는 비슷해 보이지만 근본적으로 다릅니다.

• 가속이 필요하다.
• 가상화가 필요하다.
• 네임스페이스보다 강력한 격리가 필요하다.

그래서 QEMU를 설치하고, KVM을 참조하는 설정 파일을 추가하고, 모든 블로그 포스트가 권장하는 주문어를 작성합니다. 이미지 빌드는 정상적으로 끝납니다.

하지만 실제로는 아무것도 바뀌지 않습니다.

왜냐하면 이제는 더 이상 컨테이너를 설정하는 것이 아니라, 호스트 커널을 내부 프로세스에서 설정하려고 시도하고 있기 때문입니다. Dockerfile의 어떤 영리함도 그 경계를 넘을 수 없습니다.

중첩 가상화, 디바이스 접근, 하드웨어 가속 은 이미지의 속성이 아니라 실행 환경의 속성입니다. CPU 플래그, 커널 모듈, 하이퍼바이저 설정, 런타임 권한에 따라 달라집니다. 호스트가 명시적으로 허용할 때만 컨테이너가 이를 활용할 수 있습니다.

이 순간 많은 컨테이너 설계가 조용히 무너집니다—아이디어가 틀린 것이 아니라, 추상화가 과도하게 확장되었기 때문입니다.

동일한 경계가 에이전트 시스템에서도 나타난다

이 문제는 IDE나 에뮬레이터를 넘어선 의미를 가집니다. 현대 AI 시스템은 점점 에이전트에 의존하고 있습니다—단순히 생각만 하는 것이 아니라 행동까지 하는 프로세스입니다. 이들은 도구를 실행하고, 저장소를 복제하고, 의존성을 설치하며, 종종 동시에 사용자 대신 임의 코드를 실행합니다.

첫 눈에 컨테이너는 이 용도에 완벽해 보입니다:

• 에이전트당 하나의 컨테이너.
• 깨끗한 파일시스템.
• cgroup을 통한 자원 제한.
• 작업이 끝나면 즉시 파기.

이는 작동합니다—다음과 같은 사항을 신경 쓰게 될 때까지:

• 신뢰할 수 없는 코드를 실행해야 할 때.
• 측면 이동(lateral movement)을 방지하고 싶을 때.
• 외부 네트워크 동작을 제어하고 싶을 때.
• 엄격한 파일시스템 정책을 강제하고 싶을 때.
• Docker‑in‑Docker와 같은 워크플로를 지원해야 할 때.
• 하드웨어 가속을 안전하게 제공하고 싶을 때.

그 순간 동일한 경계를 다시 마주합니다: 컨테이너는 보안 샌드박스가 아니다; 공유 커널을 가진 프로세스 격리일 뿐입니다.

에이전트가 호스트 수준의 기능—형제 컨테이너 시작, /dev/kvm 접근, 파일시스템 마운트, 네트워크 네임스페이스 조작—에 들어가야 한다면, 다시 권한, 디바이스, 커널 신뢰의 세계로 돌아가야 합니다.

IDE 문제와 에이전트 문제는 다른 옷을 입은 같은 문제입니다.

강력한 격리는 컨테이너 문제만은 아니다

인프라 설계에서 반복되는 실수가 있습니다: 정책 문제를 해결하려고 컨테이너에 모든 것을 맡기는 것… (이하 생략)

Source: …

lems with packaging tools.

Containers are packaging plus lightweight isolation. They are fantastic for reproducibility and deployment, but they are not a complete security boundary.

Once you accept that, architecture decisions become clearer.

• If your agents run trusted code, containers may be enough.
• If your agents run untrusted code, containers are probably insufficient.

That’s when other tools appear:

• MicroVMs (Firecracker, Kata).
• Sandboxed runtimes (gVisor).
• Ephemeral execution environments.
• Strict syscall filters and egress policies.

These systems are slower to spin up and harder to operate, but they draw the boundary in the right place: at the kernel interface, not inside it. What looks like extra complexity is often just honesty about where isolation actually comes from.

The real product is policy

The most important lesson from all of this is subtle:

The hard part is not running code—it’s deciding what that code is allowed to do.

• Opening links.
• Accessing the network.
• Reading from disk.
• Writing artifacts.
• Using hardware acceleration.

Every meaningful system ends up encoding policy, whether explicitly or by accident. Containers make it easy to ship policy as configuration, but they don’t remove the need to reason about it.

Agent orchestration systems that scale will not be defined by clever prompts or clever scheduling. They will be defined by:

• Clear trust boundaries.
• Explicit execution contracts.
• Reproducible but constrained environments.
• Observability that maps actions back to intent.

That’s not an AI problem. That’s an infrastructure problem we’ve been solving for decades—just under different names.

Containers are still the right starting point

None of this is an argument against containers.

Containers are still the best default abstraction we have. They let us experiment cheaply, reason locally, and iterate fast. They are the right place to start—but they are not the place to stop.

Every serious system eventually reaches a point where the kernel boundary must be addressed directly, and the tooling you choose there will determine whether you get security, performance, and operational simplicity in the right mix.

“그냥 Docker에 넣어라”가 답이 아니게 되는 시점

“그냥 Docker에 넣어라”가 답이 아니라 질문이 되는 시점은 다음과 같은 것이 필요할 때이다:

• 커널 기능
• 하드웨어 보장
• 악성 코드 격리

그 순간 아키텍처를 변경해야 합니다.

기대할 점

• 예측 가능한 경계 – 무엇을 찾아야 할지 알면 그 징후를 미리 알 수 있습니다.
• 빠른 해결책 없음 – Dockerfile로 간단히 덮어쓸 수 없습니다.

이 내용이 도움이 되었나요? 저는 AI 인프라, 보안, 그리고 프로덕션 AI 시스템 구축의 엔지니어링 과제에 대해 글을 씁니다. LinkedIn 또는 Twitter/X에서 저와 연결하세요.

제작자: Siddhant Khare.