Containerization - macOS에서 Linux 컨테이너를 실행할 수 있는 Swift 패키지

(github.com/apple)

5P by GN⁺ 2일전 | ★ favorite | 댓글 1개

Containerization은 macOS에서 Linux 컨테이너를 실행할 수 있게 해주는 Swift 기반 오픈소스 도구
Apple Silicon 기반 Mac에서 작동하며, Virtualization.framework를 활용하여 가벼운 가상 머신 안에 각 컨테이너를 격리 실행함
OCI 이미지 관리, 원격 레지스트리 연동, ext4 파일 시스템 생성, 컨테이너 환경 제어 등 다양한 기능을 포함함
Rosetta 2를 활용해 Apple Silicon에서도 x86_64 프로세스 실행 지원 가능함
초단시간 부팅, 경량 환경 제공, 커널 버전 커스터마이징 등으로 개발자 유연성과 성능을 높임

프로젝트 개요

Containerization은 애플리케이션이 Linux 컨테이너를 사용할 수 있도록 도와주는 Swift 패키지임
Swift 언어로 구현되어 있으며, Apple Silicon 기반의 Mac에서 Virtualization.framework를 활용해 동작함
API를 통해 아래와 같은 기능을 제공함
- OCI 이미지 관리
- 원격 컨테이너 레지스트리 연동
- ext4 파일 시스템 생성 및 배치
- Netlink 소켓 패밀리와의 상호작용
- 빠른 부팅을 위한 최적화된 Linux 커널 제공
- 경량 가상 머신 생성 및 관리
- 가상 머신의 실행 환경 제어
- 컨테이너화된 프로세스 생성 및 제어
- Rosetta 2를 활용한 Apple Silicon에서 x86_64 프로세스 실행
API 문서는 별도의 공식 페이지에서 확인 가능

디자인 및 구조

각 Linux 컨테이너는 독립된 가상 머신 내에서 실행됨
컨테이너별 전용 IP 주소를 할당할 수 있어, 포트 포워딩 없이도 네트워크 관리가 간편함
최적화된 커널 설정과 경량 루트 파일 시스템 덕분에 1초 미만의 컨테이너 부팅이 가능함
vminitd는 Containerization의 서브프로젝트로, 가상 머신 내에서 초기 프로세스로 동작하는 경량 init 시스템임
- GRPC API를 통해 실행 환경을 설정하고, 컨테이너 프로세스 운영 관리를 지원함
- 입출력, 시그널, 이벤트 처리를 호출한 프로세스에 전달함

요구사항

Apple Silicon Mac 기기가 필요함
패키지 빌드를 위해서는
- macOS 15 이상 및 Xcode 26 Beta
- 또는 macOS 26 Beta 1 이상이 필요함
macOS 15에서 사용하는 경우, 아래 기능은 제한됨
- 비격리 컨테이너 네트워킹: 같은 vmnet 네트워크 상의 컨테이너 간 통신 불가

사용 예시

cctl 실행 파일 제공: API의 다양한 기능을 실험해볼 수 있는 playground 형태임
- 주요 명령 예시
  - OCI 이미지 조작
  - 컨테이너 레지스트리 로그인
  - 루트 파일 시스템 블록 생성
  - 간단한 Linux 컨테이너 실행

Linux 커널 구성

컨테이너용 경량 가상 머신 실행을 위해 Linux 커널이 필요함
Containerization에서 제공하는 최적화 커널 설정은 kernel 디렉터리에 위치함
해당 설정은 최소한의 기능만 담아 빠른 부팅과 경량 환경을 제공함
필요에 따라 컨테이너별 커널 설정과 버전을 다르게 지정할 수 있는 API가 마련됨
- 다양한 커널 버전 및 설정을 테스트 가능함
Kata Containers 프로젝트에서 제공하는 vmlinux.container 등 사전 컴파일된 커널 사용 가능
- 단, VIRTIO 드라이버가 커널에 내장(compiled-in)되어 있어야 함

개발 및 테스트 프로세스 요약

Swift, Static Linux SDK 등 환경 준비 필요
소스 코드 빌드 및 테스트 가능 (make all, make test integration 명령어 등)
- 통합 테스트 실행을 위해 커널 이미지 필요
gRPC/Protobuf 관련 특정 버전을 사용하는 의존성 구성 지원
API 문서 자동 생성 및 로컬 미리보기 기능 탑재

오픈소스 기여 및 프로젝트 현황

기여 환영
0.1.0 버전이 첫 공식 릴리스이며, 소스 안정성은 마이너 버전 범위 내에서만 보장됨
향후 마이너 릴리스에서 정책 변경 가능성 존재

요약

Containerization은 macOS에서 개발자들이 최적화된 환경으로 Linux 컨테이너를 관리, 실행, 개발할 수 있게 해주는 혁신적인 Swift 패키지임
각 컨테이너를 가벼운 전용 가상 머신에서 구동함으로써 격리, 성능, 네트워킹, 커널 커스터마이징 장점을 제공함
오픈소스 컨테이너 환경을 macOS 네이티브 경험으로 확장하려는 개발자들에게 적합한 솔루션임

▲

GN⁺ 2일전 [-]

Hacker News 의견

가장 놀랍고 흥미로운 부분이라고 생각하는 내용 공유함

"container" 프로젝트에 기여를 환영하고 장려한다는 메시지 상당히 이례적인 애플의 태도로 느껴짐
WebKit은 KHTML의 적대적 포크였고, Darwin도 마치 벽 너머로 부품을 띄엄띄엄 던져준 느낌이었음
애플이 최근 GitHub에 공개한 이런 프로젝트들에서 사용자·개발자 협업이 활발해지길 바라는 마음
나는 F/OSS(오픈 소스) 성향이지만, 회사 정책 때문에 리눅스를 못 쓰고 어쩔 수 없이 매일 Mac을 쓰는 사람
애플 실리콘 도입 이후 집에서 쓰는 노트북도 Mac으로 바꿨지만, 요즘에는 리눅스에 친화적인 대안들도 점점 가까워지는 추세라 기대감 큼
이런 변화는 긍정적인 신호이고, 나처럼 내적 갈등 있었던 사용자에게는 마음이 놓이는 변화
혹시 이런 오픈소스 협업이 선순환 구조로 이어진다면 애플과 커뮤니티 사이 협업 문화가 더 커질 수 있을 것이라고 생각
나 같은 개발자들이 이런 변화에서 직접적인 혜택과 동시에 애플에 대한 존중까지 얻을 수 있는 분위기라고 상상함
- 애플이 오픈 소스 커뮤니티 참여에 대해 그리 놀라울 필요는 없다는 의견
  Swift 및 그 관련 프레임워크들에도 오픈 소스 커뮤니티의 기여가 많다는 사실 언급
- 이 프로젝트가 리눅스를 다루다 보니, 리눅스의 카피레프트(강한 오픈소스 라이선스) 때문에 애플이 협업 방식을 취할 수밖에 없다는 시각
관련 비디오로 WWDC 2025 발표 영상(https://developer.apple.com/videos/play/wwdc2025/346/) 추천
각 컨테이너가 가벼운 리눅스 VM으로 분리되는 구조임
container 툴 다운로드로 직접 구동 가능(https://github.com/apple/container/releases), macOS 26 필요
- 이번 제출 건은 https://github.com/apple/containerization 이지 container 프로젝트와는 다름
  containerization은 앱이 컨테이너 사이드카와 함께 배포되는 용도라 더 흥미로운 소식
  반면 container는 개발자가 'docker run ...' 같은 환경을 쓰기 위한 목적
  container 관련해서는 별도 HN 스레드(https://news.ycombinator.com/item?id=44229239) 안내
- macOS 15에서도 동작 가능한데, 일부 네트워킹 기능은 제한될 수 있다는 점 참고
보도자료 및 WWDC 세션에서 CLI 툴이 https://github.com/apple/container 에 있다는 점 언급
이런 툴에 관심 많은 입장으로 최신 Xcode Beta에 기본 포함되길 기대했지만, 아직은 안 들어있음
prebuilt 패키지는 현재 준비중이지만, 작업 현황은 공개 이슈(https://github.com/apple/container/issues/54)에서 확인 가능
- 댓글 이후 정확히 1분 뒤에 prebuilt 패키지 출시(https://github.com/apple/container/releases/tag/0.1.0) 소식 공유
- 관련 논의는 별도 HN 스레드(https://news.ycombinator.com/item?id=44229239)에서 진행 중
Docker 입장에선 어떤 기분일지 궁금
Docker for Desktop 사용자 상당수가 Mac을 쓸 것 같다는 상상
- 이번 변화가 오히려 Docker Desktop 개발을 훨씬 수월하게 만들어준다는 의견
  이제는 독자적으로 리눅스 VM을 세팅하지 않아도 되므로 개발난이도 완화
  그래도 많은 사용자가 익숙한 CLI, Docker Compose, 다양한 Docker 독자적 UX 때문에 기존 Docker Desktop을 선호할 것이라는 예측
  컨테이너 런타임을 바꾸는 것은 쉽지 않은 일이라는 설명
- Docker 입장에서는 podman을 대할 때와 비슷한 감정일 것이라는 추측
- Docker Desktop이 닫힌 소스의 상용 소프트웨어이고, 이번 프로젝트는 자유 소프트웨어이기 때문에 사용자 입장에서는 좋은 소식이라는 생각
이 기술이 Linux 컨테이너를 MacOS 앱에 번들링하는 데 쓸 수 있는지 궁금
예시로, 예를 들어 GPT 같은 도구가 루트 CLI 명령어 없이도 Linux 환경에 접근하게 할 때 필요성 존재
- MacOS 26에서만 동작해도 괜찮다면, 바로 원하는 목적에 쓸 수 있다는 안내
  아니면 Virtualization.framework를 직접 사용해서도 가능하지만, 추가 작업이 더 필요하다는 설명
- 바로 이런 목적을 위해 나온 기술이라는 확신
컨테이너마다 각기 분리된 VM으로 실행되어 완전 격리와 독립된 IP 부여 등 흥미로운 구조이지만, 이런 설계가 리눅스나 윈도우에서는 익숙하지 않음
개발팀에서 한 명이라도 맥을 쓰지 않는다면 로컬 개발 모델이 깨져버리는 단점
Docker/Compose를 대체하기는 쉽지 않을 것이라는 결론
주요 데스크톱 OS 세 개 중 두 곳이 이제 공식적으로 리눅스 VM을 구동해서 리눅스 네이티브 애플리케이션을 실행할 수 있게 됨
이 흐름을 보면 리눅스가 사실상 이겼다는 주장 가능
리눅스 시스템콜 API는 이제 거의 모든 곳에서 동작하는 범용 API 위치
- 두 개의 주요 비리눅스 OS 위에서 리눅스 기반 애플리케이션 개발이 정상적으로 이뤄져야 한다는 사실 자체가 "리눅스의 승리"라고 보기엔 어렵다는 반론
  데스크톱 리눅스의 현실이 여전히 불안정하고 추천하기 힘들다는 경험담
  매년 Fedora/Ubuntu를 최신 PC나 랩톱에 설치해 봐도 여전히 사용성과 안정성을 못 느낀다는 솔직한 피드백
- 오히려 다른 두 플랫폼이 리눅스를 떠나지 않고 쓸 수 있는 방식을 제공하면서 데스크톱 시장에서 리눅스 자체의 점유율 증가를 더디게 만든다는 시각
- 그래픽, 오디오, GUI 쪽에는 아직 제대로 된 솔루션이 없다는 단점 부각
- "게임에 참가한 플레이어가 본인밖에 없으면 이긴 것일까"라는 의문 제기
  평범한 Windows, Mac 사용자에게 말해봤자 리눅스가 뭔지조차 모르는 상태라고 농담
- "리눅스와 함께하는 macOS"라는 사실 자체가 임팩트라는 의견
이들이 메모리 관리(필요 이상으로 VM이 메모리를 쓰지 않는 구조)도 최적화했는지 궁금
어떤 과정인지 정확히는 모르겠으나, 빌드 속도가 너무 느린 느낌
-c, -m 옵션으로 CPU/메모리 자원 더 늘려봤지만 효과 체감 미흡
- 어떤 환경과 비교해서 느린지 궁금
  과거 실리콘 Mac + Rancher Desktop 조합에서 x86 이미지를 빌드하는 척 했지만, 실제 x86 하드웨어에서 그 이미지들이 제대로 동작하지 않은 경험 공유
짧은 데모(https://developer.apple.com/videos/play/wwdc2025/346)에서 수백 밀리초 단위로 VM 부팅 가능하다는 점이 인상적
Virtualization.framework로 동작하는데, 이는 Docker desktop/Colima/UTM 등도 선택적으로 사용하던 기술
컨테이너 여러 개를 병렬로 돌릴 때 메모리 오버헤드가 궁금
- 최적화된 리눅스 커널 설정(kernel config, https://github.com/apple/containerization/…)과 최소 루트 파일시스템, 가벼운 init 시스템 덕분에 컨테이너 부팅 속도가 1초 미만으로 줄었다는 설명

답변달기