애플 실리콘 맥에서 아이폰을 '켠다'는 발상은 오래도록 개발자들의 상상 속에만 있었다. 시뮬레이터는 iOS의 UI 계층만 흉내 낼 뿐 실제 커널이나 시스템 서비스를 돌리지 않고, 물리 기기 없이 진짜 iOS를 부팅하는 경로는 사실상 막혀 있었다. Lakr233가 공개한 오픈소스 프로젝트 vphone-cli는 이 벽에 대한 흥미로운 접근을 보여준다. 애플이 자사 인프라 검증을 위해 마련해 둔 PCC(Private Cloud Compute) 리서치 VM 인프라를 활용해, macOS의 Virtualization.framework 위에서 가상 아이폰을 부팅하는 커맨드라인 도구다.
한 줄 명령으로 도는 전체 파이프라인
이 도구의 핵심은 자동화된 파이프라인이다. vphone-cli vm create 한 번이면 펌웨어 다운로드, 바이너리 패치, DFU 모드 복원, 커스텀 펌웨어(CFW) 설치, 첫 부팅까지 처음부터 끝까지 이어진다. 각 단계는 개별 명령으로도 노출되어 있어, 특정 스테이지만 다시 돌리거나 수동으로 제어할 수도 있다. 더 새로운 iOS 버전으로 올리려면 fw prepare 명령에 IPSW 파일 경로를 --iphone-source와 --cloudos-source 인자로 넘기면 된다. 도구가 생성하는 모든 산출물은 저장소나 앱 번들 바깥의 ~/.vphone/ 아래에 격리되며, $VPHONE_ROOT 환경변수로 이 트리 전체의 위치를 옮길 수 있다. 서명된 번들이 이식성을 유지하도록 캐시(ipsws, tools, debs)를 바깥에 두는 설계다.
부팅을 실제로 성사시키는 관건은 패치다. vphone-cli는 보안 우회 강도가 단계적으로 높아지는 다섯 가지 패치 변형(variant)을 제공하며, --variant 인자로 선택한다. 각 컴포넌트별로 무엇이 어떻게 바뀌는지는 저장소의 research/0_binary_patch_comparison.md에 정리되어 있다. 여기서 알 수 있는 것은, 이 프로젝트가 단순한 실행 스크립트가 아니라 iOS 부팅 체인의 보안 검증 지점을 어디까지 완화해야 게스트가 뜨는지를 조합적으로 연구한 결과물이라는 점이다.
맥 자체의 보안 장벽부터 넘어야 한다
역설적이게도 가장 먼저 부딪히는 벽은 아이폰이 아니라 호스트 맥의 보안 정책이다. 도구를 실행하려면 AMFI(Apple Mobile File Integrity)의 서명 검증 제약을 풀어야 한다. 문서는 두 가지 경로를 제시한다. 옵션 A는 복구 모드 터미널에서 SIP를 완전히 끄고, macOS로 재부팅한 뒤 amfi_get_out_of_my_way=1 부트 인자를 설정하는 가장 관대한 방식이다. 옵션 B는 SIP를 디버그 완화 상태로 켜 둔 채 amfidont로 해당 바이너리만 허용 목록에 넣는, 상대적으로 시스템 전반의 영향을 줄이는 방식이다. 이 제약을 풀지 않으면 실행 즉시 zsh: killed로 프로세스가 죽는다.
또 하나 결정적인 전제는 하드웨어다. "Virtualization is not available on this hardware"라는 오류는 맥 자체가 이미 VM일 때 나타난다. PV=3 게스트 부팅은 중첩 가상화가 불가능하므로, 비중첩 환경의 macOS 15 이상 호스트가 반드시 필요하다. 결국 이 도구는 실물 애플 실리콘 맥을 직접 손에 쥔 사람만 온전히 쓸 수 있다.
실무자가 마주치는 함정들
문서가 나열하는 트러블슈팅 목록은 이 프로젝트가 아직 연구 단계임을 솔직하게 드러낸다. 부팅 후 "Press home to continue"에서 멈추면 VNC로 접속해 두 손가락 클릭(우클릭)으로 홈 버튼을 흉내 내야 한다. iOS 초기 설정에서 지역으로 일본이나 EU를 고르면 VM이 충족할 수 없는 추가 규제 검증 때문에 시스템 앱이 설치되지 않으므로 미국 등을 골라야 한다. 앱이 EXC_GUARD / GUARD_TYPE_MACH_PORT로 죽으면 --force-exc-guard 옵션으로 다시 패치해야 하며, 이 옵션은 iOS 18 기반에서는 항상 켜진다.
특히 눈에 띄는 항목은 CFW 설치 중 시스템 바이너리를 재서명할 때 ldid-procursus가 메모리를 무한정 먹으며 멈추는 버그다. 홈브루 안정판(2.1.5-procursus7까지)에 포함된 bytes(uint64_t)가 값이 0인 경우를 막지 않은 채 __builtin_clzll(0)을 호출해 정의되지 않은 동작에 빠지고, 부호 없는 루프 카운터가 언더플로해 종료하지 못한 채 버퍼에 1바이트씩 쓰며 폭주한다. 정확히 정수값 0을 담은 엔타이틀먼트 plist가 방아쇠가 되는데, 일부 실제 애플 시스템 바이너리가 이런 값을 갖고 있다. 업스트림에는 고쳐졌으나 아직 태그된 릴리스에 반영되지 않아, brew install --HEAD ldid-procursus로 소스에서 다시 빌드하는 것이 현재의 해법이다. 이런 서술의 구체성은, 이 도구를 실제로 굴려 보려면 iOS 내부와 코드사이닝 툴체인에 대한 상당한 이해가 필요함을 보여준다.
자동화 테스트 관점의 가능성
단순한 호기심용 장난감으로만 보기 어려운 지점은 호스트 제어 소켓이다. vphone-cli는 번들 안에 vphone.sock을 노출해 스크린샷, 터치, 스와이프, 하드웨어 키, 클립보드 같은 동작을 프로그래밍 방식으로 제어하게 하고, 각 동작은 인라인 스크린샷을 함께 돌려준다. AI가 화면을 보고 다음 행동을 결정하는 E2E 테스트 루프를 염두에 둔 설계다. 이 소켓을 MCP 서버로 감싼 vphone-mcp도 함께 언급된다. 물리 기기 팜이나 클라우드 디바이스 서비스에 의존하던 iOS 자동화 테스트를, 맥 한 대 위에서 재현 가능한 형태로 돌릴 여지를 시사한다.
다만 냉정하게 볼 한계도 분명하다. 이 프로젝트는 애플이 공식 지원하는 경로가 아니라 리서치 VM 인프라와 보안 우회 패치에 기대고 있어, SIP를 끄고 AMFI를 무력화해야 겨우 동작한다. iOS 버전이 바뀔 때마다 패치 변형이 다시 맞아떨어질지도 불확실하고, 지역 규제 검증처럼 VM이 넘지 못하는 경계가 남아 있다. 프로덕션 CI에 곧바로 얹을 만한 안정성보다는, iOS 내부 구조와 가상화의 접점을 탐구하려는 보안·플랫폼 엔지니어에게 실험 재료로서의 가치가 크다. 애플이 아이폰을 얼마나 촘촘한 신뢰 사슬로 묶어 두었는지, 그리고 그 사슬의 어느 고리를 풀어야 부팅이 성립하는지를 역으로 드러낸다는 점에서 읽어 둘 가치가 있는 작업이다.