MS BUILD 2026에서 containment, container, WSLC라는 표현을 나와서 찾아본 내용입니다.
겉으로는 모두 “격리된 환경에서 실행한다”는 비슷한 이야기처럼 들리지만, 실제로는 초점이 다르다.
container는 containment를 구현하는 방법 중 하나일 수 있지만, containment 자체는 container보다 더 넓은 개념이다.
먼저 용어를 구분해보자
| 용어 | 핵심 의미 | 답하는 질문 | 예시 |
|---|---|---|---|
| Containment | 접근 권한과 실행 범위를 제한하는 보안 개념 | “이 코드나 agent가 어디까지 접근해도 되는가?” | 파일 접근 제한, 네트워크 차단, 권한 정책, MXC |
| Container | 앱과 의존성을 이미지 기반으로 묶어 격리 실행하는 단위 | “이 앱을 같은 환경에서 어떻게 실행할까?” | Docker container, OCI container |
| WSLC / WSL Containers | Windows/WSL에서 Linux container를 실행하기 위한 방식 | “Windows에서 Linux container를 더 자연스럽게 실행하려면?” | wslc.exe, WSL Containers API |
Container는 실행 단위다
우리가 흔히 말하는 container는 Docker나 OCI container 같은 것을 의미한다.
컨테이너는 애플리케이션과 그 의존성을 이미지로 패키징하고, 실행 시에는 격리된 프로세스 환경을 제공한다. Linux에서는 namespaces, cgroups, SELinux 같은 기능을 활용해 프로세스, 파일시스템, 네트워크, 리소스를 분리한다.
이 덕분에 컨테이너는 개발과 배포에서 매우 유용하다.
예를 들어 다음과 같은 상황에서는 container가 적합하다.
- 개발용 PostgreSQL, Redis, MySQL 실행
- 테스트 환경 재현
- CI/CD에서 동일한 빌드 환경 구성
- 앱과 의존성을 묶어 배포
- 로컬과 서버 환경 차이 줄이기
하지만 중요한 점이 있다.
Container는 격리된 실행 환경이지만, 그 자체가 완전한 보안 경계는 아니다.
많은 컨테이너는 호스트 커널을 공유한다. 설정이 잘못되었거나 과도한 권한이 주어지면, 컨테이너 안의 프로세스가 예상보다 많은 권한을 가질 수 있다.
따라서 “컨테이너 안에서 실행했으니 안전하다”는 생각은 위험할 수 있다.
Containment는 보안 경계다
Containment는 container보다 더 넓은 개념이다.
Containment의 핵심 질문은 이것이다.
이 코드, 프로세스, AI agent가 무엇을 할 수 있고, 무엇을 절대 하면 안 되는가?
특히 AI agent 시대에는 이 질문이 훨씬 중요해졌다.
예전의 프로그램은 비교적 예측 가능한 입력과 출력 안에서 동작했다. 하지만 AI agent는 다르다. Agent는 다음과 같은 일을 할 수 있다.
- 터미널 명령 실행
- 파일 읽기와 쓰기
- Git repository 수정
- 네트워크 요청
- 외부 도구 호출
- 브라우저나 UI 조작
- API key나 credential에 접근
이런 환경에서는 단순히 “container 안에서 돌린다”만으로 충분하지 않다.
필요한 것은 더 명시적인 정책이다.
예를 들어 다음과 같은 질문에 답할 수 있어야 한다.
- 이 agent가 읽을 수 있는 폴더는 어디까지인가?
- 이 agent가 쓸 수 있는 파일은 무엇인가?
- 인터넷 접속을 허용할 것인가?
- 특정 도메인에만 접근하게 할 것인가?
- 사용자의 홈 디렉터리에 접근할 수 있는가?
- SSH key나 API key를 볼 수 있는가?
- UI 자동화나 clipboard 접근을 허용할 것인가?
- 실행 시간과 CPU, 메모리는 얼마나 제한할 것인가?
이런 제한을 정의하고 강제하는 것이 containment의 영역이다.
즉, container는 실행 환경의 문제이고, containment는 권한과 신뢰의 문제다.
왜 이 용어의 사용을 구분했을까?
Scott Hanselman이 말하려는 핵심은 다음에 가깝다.
Container에 넣었다고 해서 충분한 containment가 생기는 것은 아니다.
이 구분은 특히 AI agent, coding agent, automation agent를 다룰 때 중요하다.
예를 들어 AI coding agent에게 “이 repository를 고쳐줘”라고 요청한다고 해보자. Agent는 코드를 읽고, 수정하고, 테스트를 실행할 것이다. 여기까지는 정상이다.
하지만 agent가 다음까지 할 수 있다면 어떨까?
- 홈 디렉터리 전체 읽기
.ssh폴더 접근.env파일 읽기- 외부 서버로 데이터 전송
- shell script를 통해 임의 명령 실행
- Docker socket 접근
- host filesystem mount
이 경우 “컨테이너 안에서 실행 중”이라는 사실만으로는 안심하기 어렵다.
진짜 필요한 것은 “이 agent는 이 repository 안에서만 읽고 쓸 수 있다”, “네트워크는 차단한다”, “credential은 볼 수 없다” 같은 명시적인 containment policy다.
WSLC / WSL Containers는 어디에 들어가나?
WSLC 또는 WSL Containers는 container와 containment 중에서는 container 실행 방식에 더 가깝다.
Microsoft는 Build 2026 전후로 Windows에서 Linux container를 더 네이티브하게 실행하기 위한 WSL Containers를 소개했다. 여기서 언급되는 wslc.exe는 Docker와 비슷한 CLI 경험을 제공하는 도구로 설명된다.
예를 들면 이런 식의 명령이 언급된다.
wslc run
wslc pull
wslc exec
wslc logs다만 이 영역은 아직 프리뷰 성격이 강하므로, 명령어와 구조는 바뀔 수 있다.
핵심은 이것이다.
WSLC는 Windows에서 Linux container를 실행하는 경로이고, containment 자체를 대체하는 개념은 아니다.
즉, WSLC는 “Windows에서 container를 어떻게 더 잘 실행할까?”에 대한 답에 가깝다. 반면 containment는 “그 container나 agent가 어디까지 접근해도 되는가?”에 대한 답이다.
MXC와의 관계
Microsoft는 AI agent 시대의 안전한 실행 환경을 위해 MXC, Microsoft Execution Containers라는 개념도 함께 소개하고 있다.
MXC는 단순히 container 하나를 실행하는 도구라기보다는, agent나 untrusted code를 실행할 때 필요한 containment policy를 정의하고 강제하는 계층에 가깝다.
개념적으로 보면 다음과 같이 나눌 수 있다.
AI Agent / Tool Execution
↓
Containment Policy
↓
MXC 같은 정책/실행 계층
↓
Backend isolation
↓
Process isolation, Windows Sandbox, Linux container, micro-VM, WSLC 등즉, MXC는 “어떤 정책으로 실행을 제한할 것인가?”에 집중하고, WSLC는 그 아래에서 사용할 수 있는 실행 백엔드 중 하나로 볼 수 있다.
Container와 containment를 혼동하면 생기는 문제
Container와 containment를 같은 것으로 생각하면 보안 모델이 느슨해질 수 있다.
예를 들어 다음과 같은 착각이 생긴다.
“Docker 안에서 실행하니까 안전하겠지.”
하지만 실제로는 다음을 따져봐야 한다.
- container가 privileged mode로 실행되는가?
- host directory가 mount되어 있는가?
- Docker socket이 mount되어 있는가?
- network access가 열려 있는가?
- secret이나 credential이 환경변수로 들어가 있는가?
- container 내부 사용자가 root인가?
- seccomp, AppArmor, SELinux 같은 제한이 적용되어 있는가?
- 파일 쓰기 범위가 제한되어 있는가?
이 질문들에 답하지 않으면 container는 편리한 실행 단위일 뿐, 충분한 containment라고 보기 어렵다.
AI agent 시대에는 containment가 먼저다
개발자가 직접 실행하는 container와 AI agent가 실행하는 container는 성격이 다르다.
개발자는 보통 자신이 어떤 명령을 실행하는지 알고 있다. 하지만 AI agent는 모델의 추론 결과에 따라 동적으로 명령을 만들고 실행한다. 그리고 그 결과는 항상 예측 가능하지 않다.
따라서 AI agent 실행 환경에서는 다음 원칙이 중요하다.
1. 최소 권한
필요한 파일과 도구만 접근 가능해야 한다.
2. 명시적 정책
네트워크, 파일, 프로세스, credential 접근 범위를 선언해야 한다.
3. 격리된 실행
agent 실행 환경은 host와 분리되어야 한다.
4. 재현 가능성
같은 작업을 같은 환경에서 다시 실행할 수 있어야 한다.
5. 감사 가능성
agent가 어떤 명령을 실행했고 어떤 파일에 접근했는지 추적 가능해야 한다.
이런 관점에서 보면 containment는 AI agent runtime의 핵심 구성 요소가 된다.
실무적으로 어떻게 구분하면 좋을까?
간단히 말하면 다음처럼 판단할 수 있다.
Container가 중요한 경우
다음이 목적이라면 container를 먼저 생각하면 된다.
- 개발 환경 통일
- 테스트 환경 구성
- 앱 배포
- dependency 격리
- 로컬 서비스 실행
- CI 환경 재현
예:
docker run postgres
docker compose up
docker build .Containment가 중요한 경우
다음이 목적이라면 containment를 먼저 생각해야 한다.
- AI agent 실행
- untrusted code 실행
- 외부 사용자가 제출한 코드 실행
- 자동화 스크립트 실행
- 플러그인 실행
- 민감한 파일이나 credential 보호
- 네트워크 접근 제한
이 경우에는 단순히 container를 쓰는지보다, 어떤 정책으로 접근을 제한하는지가 더 중요하다.
WSLC가 중요한 경우
다음이 목적이라면 WSLC나 WSL Containers를 살펴볼 만하다.
- Windows에서 Linux container를 더 네이티브하게 실행
- WSL 기반 개발 환경과 container 통합
- Windows 앱 또는 도구에서 Linux container를 직접 활용
- Docker Desktop 외의 Windows-native container 실행 경로 검토
다만 WSLC는 아직 변화 가능성이 있는 영역이므로, 현재 시점에서는 Docker Desktop, WSL 2 backend, Hyper-V isolation, Enhanced Container Isolation 같은 기존 옵션과 함께 비교해야 한다.
참고 자료
- Scott Hanselman, Hanselminutes #1033: Run your AI Agent in a Sandbox with Docker President Mark Cavage
- Microsoft Windows Developer Blog: Build 2026: Furthering Windows as the trusted platform for development
- Microsoft Developer: Windows development updates on WSL Containers and MXC
- Microsoft GitHub:
microsoft/mxc - Docker Docs: Docker Desktop WSL 2 backend and isolation options
- Red Hat Docs: Linux container isolation, namespaces, cgroups, SELinux
- Hayden Barnes: WSLC: A native Linux container runtime for Windows
0 댓글