--- title: "애플 컨테이너에 ‘맥 안의 지속형 리눅스 머신’이 들어옴" published: 2026-06-10T00:29:01.000Z canonical: https://jeff.news/article/3950 --- # 애플 컨테이너에 ‘맥 안의 지속형 리눅스 머신’이 들어옴 애플의 container 도구에 컨테이너 머신이라는 개념이 추가돼, 맥에서 지속형 리눅스 환경을 빠르게 띄우고 쓸 수 있게 됨. 일반 컨테이너가 앱 단위라면, 컨테이너 머신은 init 시스템과 서비스, 홈 디렉터리 공유까지 포함한 리눅스 개발 환경에 가까움. - 애플의 container 도구가 ‘컨테이너 머신’이라는 리눅스 개발 환경 모델을 제공함 - 일반 컨테이너가 앱 하나를 실행하는 데 초점이 있다면, 컨테이너 머신은 리눅스 환경 자체를 띄우는 쪽임 - 빠르고 가볍고 지속형이며, 표준 OCI 이미지로 만들고 공유할 수 있음 - 이미지의 init 시스템을 실행할 수 있어서 장기 실행 서비스나 프로세스 슈퍼바이저 기반 테스트도 가능함 - 맥에서 편집하고, 리눅스 안에서 빌드하는 흐름을 노골적으로 겨냥함 - 맥의 `$HOME`에 있는 저장소가 컨테이너 머신 안에서는 `/Users/` 또는 리눅스 홈 경로로 마운트됨 - 맥의 에디터나 IDE로 코드를 고치고, 빌드와 실행은 리눅스 환경 안에서 돌리는 식임 - 빌드 산출물을 다시 복사하지 않아도 맥 네이티브 프로파일러, 브라우저, 스크린샷 도구, GUI 디버거가 같은 파일을 볼 수 있음 - 사용자 계정 매핑도 개발자 친화적으로 잡혀 있음 - `container machine run -n dev whoami`를 실행하면 root가 아니라 호스트의 사용자명이 나옴 - 컨테이너 머신을 실행하면 맥 계정과 같은 사용자로 셸에 들어가고, 홈 디렉터리와 dotfile도 공유됨 - ‘컨테이너 안이라 권한 꼬임’ 같은 로컬 개발 특유의 귀찮음을 줄이려는 설계로 보임 - 배포판별 리눅스 테스트 환경을 여러 개 만들 수 있음 - `container machine create alpine:latest --name dev`처럼 Alpine 기반 환경을 만들 수 있음 - Ubuntu, Debian 같은 타깃 배포판마다 컨테이너 머신을 따로 만들고 같은 홈 디렉터리와 설정 파일을 공유할 수 있음 - 특정 배포판에서만 깨지는 빌드나 패키지 의존성 문제를 로컬에서 바로 확인하기 좋아짐 - 실행 명령은 꽤 단순함 - `container machine run -n dev`는 대화형 셸을 열고, 컨테이너 머신이 꺼져 있으면 먼저 부팅함 - `container machine run -n dev uname -a`처럼 단일 명령만 실행하고 빠져나올 수도 있음 - 기본 머신을 `container machine set-default dev`로 지정하면 `-n` 플래그 없이 `container machine run`, `container machine ls`, `container machine inspect dev` 같은 명령을 쓸 수 있음 - `container machine`은 `m` 별칭도 있어서 `m ls`, `m run`처럼 짧게 호출 가능함 > [!TIP] > 맥에서 코드 편집 도구를 그대로 쓰면서 실행 환경만 리눅스로 맞추고 싶다면 이 모델이 꽤 잘 맞음. 특히 배포 타깃이 리눅스인데 개발 장비는 맥인 팀에 실용적임. - 리눅스 서비스 테스트도 현실적인 수준까지 들어옴 - systemd가 설치된 이미지라면 `systemctl start postgresql` 같은 명령으로 데이터베이스나 필요한 서비스를 띄울 수 있음 - 컨테이너 하나에 프로세스 하나만 넣는 전통적인 앱 컨테이너 감각과는 조금 다름 - 로컬에서 ‘작은 리눅스 개발 머신’을 켜놓고 테스트하는 방식에 가까움 - 리소스와 마운트 설정도 바꿀 수 있음 - `container machine set -n dev cpus=4 memory=8G`처럼 CPU와 메모리를 조정할 수 있음 - 변경 사항은 디스크 설정에 저장되고, 다음 stop/start 이후 적용됨 - 메모리 기본값은 호스트 메모리의 절반이고, 홈 마운트는 기본 읽기쓰기(`rw`), 읽기전용(`ro`), 없음(`none`) 중 고를 수 있음 - 커스텀 이미지 조건은 `/sbin/init`이 있는 리눅스 이미지임 - 문서 예시는 Ubuntu 24.04 기반 이미지에 `dbus`, `systemd`, `openssh-server`, 네트워크 도구, `curl`, `wget`, `vim-tiny`, `man`, `sudo` 등을 설치함 - `systemctl set-default multi-user.target`로 기본 타깃을 잡고, 컨테이너 환경에서 불필요하거나 문제될 수 있는 일부 systemd 유닛을 마스킹하거나 비활성화함 - 빌드는 `container build -t local/ubuntu-machine:latest .`, 생성은 `container machine create local/ubuntu-machine:latest --name ubuntu` 흐름임 - 첫 부팅 때 사용자 프로비저닝도 자동화돼 있음 - 기본적으로 container가 내장 setup script를 실행해 호스트와 맞는 사용자를 만들어줌 - 직접 제어하고 싶으면 이미지에 `/etc/machine/create-user.sh` 실행 파일을 넣으면 됨 - 이 스크립트는 최초 부팅 때 root로 한 번 실행되고, `CONTAINER_UID`, `CONTAINER_GID`, `CONTAINER_HOME`, `CONTAINER_USER`, `CONTAINER_MACHINE_ID` 같은 변수를 받음 --- ## 기술 맥락 - 여기서 애플이 고른 방향은 ‘앱 컨테이너’가 아니라 ‘개발용 리눅스 머신’이에요. 맥에서 코드를 편집하는 경험은 유지하되, 실제 빌드와 실행은 리눅스에 붙이고 싶다는 문제가 있었기 때문이에요. - 홈 디렉터리와 사용자명을 자동 매핑하는 것도 꽤 중요한 선택이에요. 로컬 개발에서 권한, 경로, dotfile이 엇갈리면 생산성이 바로 떨어지거든요. 같은 파일을 맥 도구와 리눅스 환경이 동시에 보게 만들면 복사 단계가 사라져요. - systemd를 허용하는 건 단순 컨테이너보다 한 단계 더 무거운 대신, 테스트 현실성이 올라가요. 데이터베이스나 백그라운드 서비스를 실제 배포 환경과 비슷하게 띄워야 하는 스택에서는 프로세스 하나만 실행하는 모델이 답답할 수 있거든요. - OCI 이미지를 기반으로 한 것도 실용적인 선택이에요. 완전히 새로운 이미지 포맷을 만들면 생태계와 멀어지는데, 기존 컨테이너 빌드 흐름을 유지하면 팀이 이미 가진 Dockerfile이나 배포판 기반 이미지를 활용하기 쉬워요. ## 핵심 포인트 - 컨테이너 머신은 앱이 아니라 리눅스 환경 자체를 모델링함 - 맥의 사용자명과 홈 디렉터리가 리눅스 환경에 자동 매핑됨 - systemd가 들어간 이미지라면 PostgreSQL 같은 장기 실행 서비스를 테스트할 수 있음 - Alpine, Ubuntu, Debian 등 배포판별 개발 환경을 따로 만들 수 있음 - CPU, 메모리, 홈 마운트 권한 같은 설정을 디스크에 저장하고 재시작 후 적용할 수 있음 ## 인사이트 이건 Docker Desktop 대체 한 줄 요약으로 끝낼 물건이 아니라, 맥 개발자의 ‘로컬은 맥, 실행은 리눅스’ 루틴을 애플식으로 정리하려는 시도에 가까움. 홈 디렉터리 공유와 systemd 지원이 같이 들어가면, 단순 빌드 컨테이너보다 훨씬 실제 개발 머신처럼 굴릴 수 있음.