Encore, Apple Silicon에서 Firecracker 호환 microVM API 'crackling' 구축
- Encore는 Linux의 Firecracker와 macOS의 Apple 하이퍼바이저를 하나의 microVM API로 감싼 crackling을 만들어, 프로덕션 Firecracker를 유지하면서 맥에서도 같은 빌드 이미지를 부팅함
- Firecracker는 KVM과
/dev/kvm이 필요한 Linux 전용 구조라 macOS를 지원하지 않으며, Firecracker 유지보수진도 Virtualization.framework 기반 동작 시연을 거절하고 가까운 시일 내 macOS 지원 계획이 없다고 밝힘 - Encore 개발자는 4년간 Tailscale로 연결한 공유 원격 빌드 머신에서 사용자별 이미지와 바이너리를 관리했고, 변경 사항은 SSH·rsync·교차 컴파일로 배포했음
- Docker 레이어를 Firecracker가 부팅할 블록 이미지로 바꿀 도구가 없어 squash_layers를 직접 작성했으며, 레이어 재추출, whiteout 삭제,
/etc/resolv.conf작성, Docker 환경 변수 추출 뒤mksquashfs를 실행함 - Docker 컨테이너 안에서 Firecracker를 실행하려고
--privileged,/dev/kvm,/dev/net/tun을 넘기고, 컨테이너 내부에docker0브리지를 만드는 시작 스크립트를 작성함
Hacker News opinions
VZ.framework은 많이 제한적이고, KVM에 대응하는 건 Hypervisor.framework 쪽이라고 봄.
VZ.framework이 자기 목적에 비해 특별히 제한적인 건 아님. 리눅스에서 Firecracker처럼 고수준 API를 쓰니 macOS에서도 같은 선택이 자연스럽고, Firecracker에 Hypervisor.framework 백엔드를 넣어도 AWS가 받을지는 의문임.
개발자 대부분이 맥을 쓴다는 전제부터 잘못 잡은 문제 아닌가.
현실적인 선택임. 리눅스 쪽에는 쓸 만한 MDM이 없고, 2026년에 절전과 복귀가 제대로 되는 소비자용 장비를 쉽게 사기도 어려움.
어젯밤 com.apple.private.virtualization entitlement에 막혀서 VZVirtualMachine의 비공개 AccessorEndpoint API를 보려 했음. 애플 비공개 API 안에 쓸 만한 게 꽤 많더라.
로컬 백엔드를 만들기 전까지 4년이나 공유 원격 머신을 쓴 건, 개발 도구에 언제 투자해야 하는지 보여주는 사례 같음.
Firefox에서 트랙패드는 되는데 화살표나 PageUp/PageDown으로 스크롤하면 첫 화면 뒤가 빈 페이지가 됨. 블로그 렌더러가 너무 이상함.
나만 그런 줄 알았는데 Safari에서도 같은 현상 남.
글 본문을 클릭하면 내부 스크롤바가 활성화돼서 키보드 스크롤이 되더라. 스크롤바를 둘로 만들면 유지보수할 게 늘어나는데 왜 이렇게 만드는지 모르겠음.
M 시리즈 맥에서 Firecracker를 제대로 돌리는 건 꽤 큰 작업이라 Encore 선택이 이해됨. 우리는 Bazel 등으로 맥과 리눅스에서 예측 가능한 빌드를 만들고, macOS에서는 vfkit -> QEMU -> Kind + Firecracker VM 중첩 가상화를 택했음.
M1과 M2에는 중첩 가상화 하드웨어 지원이 없다는 점은 알아둬야 함.
M3 이후 macOS 15의 리눅스 VM에서는 /dev/kvm을 받아 Firecracker를 수정 없이 돌릴 수 있다는데, 아직 M1이나 M2를 쓰는 개발자가 많은 게 의아함.
대부분 회사에서 노트북 교체는 2년이 아니라 실제로 4년 가까이 감. M1은 아직 충분히 빠르고, 2년마다 새 맥을 사줄 생산성 근거도 약함.
기술은 흥미로운데 글이 너무 빽빽하고 읽기 힘듦. 첫 문장부터 AI가 쓴 글처럼 느껴져서 내용을 따라가기 싫어짐.
AI로 초안을 썼다면 사람 손으로 훨씬 많이 고쳐야 했음. 이 글은 읽기보다 LLM에 붙여 넣어 요약해야 할 것 같은 문체임.