애플 컨테이너에 ‘맥 안의 지속형 리눅스 머신’이 들어옴

• 애플의 container 도구가 ‘컨테이너 머신’이라는 리눅스 개발 환경 모델을 제공함

  • 일반 컨테이너가 앱 하나를 실행하는 데 초점이 있다면, 컨테이너 머신은 리눅스 환경 자체를 띄우는 쪽임
  • 빠르고 가볍고 지속형이며, 표준 OCI 이미지로 만들고 공유할 수 있음
  • 이미지의 init 시스템을 실행할 수 있어서 장기 실행 서비스나 프로세스 슈퍼바이저 기반 테스트도 가능함

• 맥에서 편집하고, 리눅스 안에서 빌드하는 흐름을 노골적으로 겨냥함

  • 맥의 $HOME에 있는 저장소가 컨테이너 머신 안에서는 /Users/<username> 또는 리눅스 홈 경로로 마운트됨
  • 맥의 에디터나 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처럼 짧게 호출 가능함

• 리눅스 서비스 테스트도 현실적인 수준까지 들어옴

  • 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이나 배포판 기반 이미지를 활용하기 쉬워요.