macOS 27 베타가 가상 머신에 설치되지 않나요? 해결 가이드

macOSTahoe ·
macOS 27 베타가 가상 머신에 설치되지 않나요? 해결 가이드

macOS 27 Golden Gate 베타가 UTM, Parallels, VMware Fusion에서 설치 실패 오류와 함께 설치되지 않는 이유와 해결 방법을 안내합니다.

신중한 방법을 그대로 따랐습니다. 매일 사용하는 Mac에 갓 나온 macOS 27 "Golden Gate" 베타를 바로 설치하는 대신, 책임감 있는 개발자나 파워 유저라면 응당 그래야 하듯 먼저 가상 머신 안에서 테스트해 보기로 했습니다. 복원 이미지를 다운로드하고 UTM이나 Parallels, VMware Fusion을 그 이미지로 가리킨 다음 VM 생성을 클릭하고, 진행 표시줄이 몇 분 동안 천천히 나아가는 것을 지켜봅니다. 그러다 갑자기 멈추더니 짧은 대화 상자가 뜹니다. "설치 중 오류가 발생했습니다. 설치하지 못했습니다." 읽어볼 만한 로그도 없고, 검색할 코드도 없고, 무엇이 잘못됐는지에 대한 힌트도 없습니다. 다시 시도합니다. 결과는 같습니다. UTM에서 VirtualBuddy로, 다시 Tart로 앱을 바꿔봐도 모두 같은 지점에서 같은 무의미한 메시지와 함께 실패합니다. macOS 27 베타가 Mac의 가상 머신에 설치되지 않는다면, 여러분이 설정을 잘못한 것도 아니고 다운로드가 손상된 것도 아닙니다. Apple이 인정한 알려진 버그에 부딪힌 것이며, 설정에서 특정 한 가지를 바꾸기 전까지는 아무리 재시도해도 고쳐지지 않습니다.

이 문제가 새 macOS 베타를 일찍 써보려는 사람들을 유독 좌절시키는 이유는, 제대로 된 방법을 따른 사람들에게 벌을 주기 때문입니다. VM을 쓰는 이유 자체가 위험을 피하기 위해서인데, 여기서는 오히려 그 안전한 경로가 깨져버립니다. 게다가 막연한 "설치 실패" 오류는 마치 로컬에서 뭔가 실수한 것처럼 보이게 만듭니다 — IPSW가 잘못됐거나, 디스크 공간이 부족하거나, VM 설정이 틀렸거나 하는 식으로 말이죠. 그래서 사람들은 애초에 해결될 리 없는 문제를 붙잡고 몇 시간씩 헛수고를 하게 됩니다. 근본 원인이 화면 이쪽에 있는 게 전혀 아니기 때문입니다. 원인은 현재 Mac이 실행 중인 macOS 버전과 게스트에 설치하려는 macOS 버전 사이의 상호작용에 있습니다.

이 가이드에서는 오류가 정확히 어떤 모습으로 나타나는지, 누가 이 문제를 겪고 누가 겪지 않는지, 그리고 애초에 VM에서 베타를 테스트할 가치가 있는 이유를 설명합니다. 그런 다음 핵심으로 들어가겠습니다. 진짜 근본 원인은 Apple Virtualization framework에서 macOS 26.6 호스트와 macOS 27 설치 프로그램 사이의 호환성 문제이며, 모든 VM 앱이 왜 똑같은 방식으로 실패하는지 정확히 이해할 수 있도록 설명합니다. 이어서 실제로 통하는 세 가지 해결 방법과 UTM, VirtualBuddy, Tart, Parallels, VMware Fusion 각 앱별 참고 사항, 그리고 고려해 볼 만한 더 안전한 대안을 살펴봅니다. 이는 계속 변화하는 베타 상황이므로, 무엇이 확실하고 무엇이 다음 빌드에서 바뀔 수 있는지 시종일관 솔직하게 다루겠습니다.

핵심 요약

  • "설치 중 오류가 발생했습니다. 설치하지 못했습니다." 메시지는 여러분 쪽의 실수가 아니라 Apple이 인정한 알려진 버그입니다 — UTM, VirtualBuddy, Tart, Parallels, VMware Fusion 전부에서 동일하게 실패하는데, 이는 이들 모두가 동일한 설치 프로그램 경로를 공유하기 때문입니다.
  • 근본 원인은 Apple Virtualization framework의 호환성 문제입니다 — 구체적으로는 VZMacOSInstaller API로, macOS Tahoe 26.6을 실행 중인 Mac이 macOS 27 Golden Gate 복원 이미지를 게스트에 설치하려 할 때 발생합니다. 호스트 OS가 더 새로운 설치 프로그램을 구동하기에는 버전이 너무 낮습니다.
  • 해결 방법 1: 이미 macOS 27을 실행 중인 Mac에서 macOS 27 VM을 만들거나 설치하면 호스트-게스트 불일치 자체가 사라집니다.
  • 해결 방법 2: 먼저 macOS Tahoe VM을 만든 다음, IPSW에서 27을 바로 새로 설치하는 대신 게스트 내부에서 Software Update(Apple Beta 등록)를 통해 그 VM을 macOS 27 베타로 업그레이드합니다.
  • 해결 방법 3: API 불일치를 해결한 업데이트된 베타 빌드나 업데이트된 VM 앱을 그냥 기다립니다 — 베타이다 보니 영향을 받는 빌드는 릴리스마다 바뀔 수 있습니다.
  • Apple 실리콘에서는 이 모든 앱이 동일한 Apple 프레임워크를 감싸고 있고, macOS 게스트는 역사적으로 Apple 라이선스에 따라 호스트당 VM 2개로 제한되어 왔으며, 게스트는 일부 DRM 및 iCloud 연동 서비스에 로그인할 수 없습니다 — VM에 시간을 투자하기 전에 알아두면 좋은 사실들입니다.

"설치 실패" 오류가 어떻게 나타나고 누가 겪는가

어떤 앱을 쓰든 실패 양상이 거의 동일하다는 점이 문제가 앱에 있지 않다는 첫 번째 큰 단서입니다. 새 macOS 가상 머신을 만드는 일반적인 절차를 시작합니다. 새 macOS 게스트를 설치하기로 선택하고, macOS 27 복원 이미지(IPSW 파일)를 앱에 넘기거나 앱이 알아서 가져오게 하고, CPU 코어와 메모리, 디스크를 할당한 다음 시작합니다. 초반 단계는 완전히 정상으로 보입니다. 앱은 복원 이미지의 압축을 풀고, 임시 설치 환경을 띄우고, 30초에서 몇 분 정도 그럴듯하게 앞으로 나아가는 진행 표시줄을 보여줍니다. 그러다 중간쯤에서 전체 과정이 멈추고 "설치 중 오류가 발생했습니다. 설치하지 못했습니다."와 비슷한 짧은 대화 상자를 보게 됩니다. 어떤 앱은 이를 네이티브 macOS 알림으로 보여주고, 다른 앱은 자체 UI에 표시하거나 로그에 짧은 한 줄을 남깁니다. 문구가 일부러 두루뭉술한 이유는, 실제 작업을 수행하는 프레임워크로부터 앱 자체가 상세한 이유를 전달받지 못하는 경우가 많기 때문입니다.

메시지가 너무 빈약하다 보니 사람들은 자연스레 자신이 뭔가 잘못했다고 생각하고, 애초에 문제였던 적이 없는 원인을 쫓느라 시간을 낭비합니다. IPSW가 손상됐을까 봐 다시 다운로드합니다. 체크섬을 검증합니다. VM에 디스크, RAM, 코어를 더 할당합니다. VM을 삭제하고 처음부터 다시 만듭니다. 찾을 수 있는 모든 설정을 이리저리 바꿔봅니다. 어느 것도 결과를 바꾸지 못하는데, 이 중 어느 것도 실제로 실패의 원인이 아니기 때문입니다. 설치는 다운로드가 멀쩡하고 할당량이 충분하다는 것을 증명할 만큼은 진행됩니다 — 바이트가 누락됐거나 디스크가 비좁아서 멈추는 게 아닙니다 — 그러고 나서 설치 메커니즘 자체에 내장된, 어떤 VM 쪽 설정으로도 옮길 수 없는 벽에 부딪힙니다.

앱마다 정확히 어떻게 나타나는가

이 버그를 알아보기 쉽게 만드는 것은 그 일관성입니다. UTM에서는 VM 생성 마법사가 설치 단계에 도달한 다음 실패를 던지는 것을 보게 됩니다. 바로 이런 종류의 테스트를 위해 Apple의 가상화 스택을 중심으로 만들어진 VirtualBuddy에서도 안내형 설치 프로그램이 같은 단계에서 실패합니다. CI와 자동화 환경에서 선호되는 명령줄 중심 도구인 Tart는 사용 가능한 이미지를 만들어내는 대신 설치 오류를 반환합니다. 두 대형 상용 하이퍼바이저인 Parallels Desktop과 VMware Fusion도 영향을 받는 호스트에서 macOS 27 복원 이미지를 넘기면 둘 다 실패합니다. 만약 로컬 설정 오류였다면 앱마다 다른 단계에서, 다른 메시지로, 다른 특유의 방식으로 실패했을 것입니다. 각 앱이 프레임워크를 서로 다르게 감싸고 있기 때문입니다. 모두가 같은 지점에서 같은 일반적인 오류로 죽는다는 사실은, 다섯 가지 별개의 우연이 아니라 공유된 상위 원인의 특징입니다.

누가 영향을 받고 누가 받지 않는가

경계선은 어떤 VM 앱을 골랐는지가 아니라 호스트 Mac이 무엇을 실행 중인지입니다. 여러분의 Mac이 현재 macOS Tahoe 26.6(그 베타를 포함)을 실행 중이고 표준 Virtualization framework 설치 경로로 macOS 27 게스트를 설치하려 한다면 영향을 받는 그룹에 속합니다. 만약 여러분의 Mac이 이미 macOS 27 자체를 실행 중이고 27 게스트를 만든다면, 호스트와 게스트가 맞아떨어지므로 일반적으로 영향을 받지 않습니다. 그래서 온라인에서 어떤 사람들은 베타가 VM에 "잘" 설치된다고 하고, 다른 사람들은 아무리 해도 오류를 넘지 못한다고 하는 것입니다 — 단지 서로 다른 호스트 운영체제를 쓰고 있을 뿐입니다. 또한 이 문제가 시점과 이렇게 밀접하게 연결된 이유이기도 합니다. 현재 Tahoe 트랙에 있는 사람들이 막 출시된 27 베타를 돌려보려 하면서 정확히 이 시점에 나타났고, 호스트들이 27로 넘어가거나 Apple이 불일치를 해결하는 빌드를 출시하면 사라질 것입니다. 이는 베타이기 때문에 계속 움직이는 대상이라는 점을 기억하세요. 경계선 양쪽의 정확한 빌드는 바뀔 수 있으므로, 여기 나온 버전 번호는 영구적인 규칙이 아니라 작성 시점의 상황으로 받아들이시기 바랍니다.

애초에 왜 macOS 27을 가상 머신에서 테스트하는가

해결 방법으로 들어가기 전에, 왜 이렇게 많은 사람이 이런 수고를 감수하는지 짚어볼 가치가 있습니다. 이 버그가 왜 이렇게 성가신 것인지 설명해 주기 때문입니다. 매일 의존하는 Mac에서 갓 나온 첫 해의 macOS 베타를 실행하는 것은 실제로 위험합니다. 초기 베타는 커널 익스텐션을 망가뜨리거나, 다운그레이드 시 데이터를 손상시키거나, 배터리 수명을 갉아먹거나, 서드파티 앱을 못 쓰게 만들 수 있습니다. macOS 27은 이번 주기에 특히 무게가 실려 있는데, 최초의 Apple 실리콘 전용 릴리스이자 Rosetta 2를 지원하는 마지막 버전이며 Intel Mac 시대의 종막이기 때문입니다 — 한꺼번에 많은 변화가 몰려듭니다. 가상 머신은 이 모든 것을 Apple 스스로도 미완성이라 밝힌 베타에 실제 작업 환경을 걸지 않고도 찔러볼 수 있는 방법을 제공합니다. 이번 릴리스에서 무엇이 바뀌는지 더 폭넓게 보고 싶다면, WWDC 2026에서 발표된 기능, 호환성, 출시 일정에 대한 개요를 참고하세요. 이 릴리스가 유독 많은 테스터를 끌어들이는 이유를 알 수 있습니다.

스냅샷과 즉시 롤백

VM에서 테스트하는 가장 큰 이유는 스냅샷입니다. 위험한 업데이트를 설치하기 전, 새로운 API를 찔러보기 전, 신뢰하지 않는 소프트웨어를 실행하기 전에 스냅샷 — 전체 머신 상태를 얼려놓은 사본 — 을 찍어두면 무언가 잘못되더라도 몇 초 만에 그 시점으로 되돌아갈 수 있습니다. 재설치도 없고, 백업 복원도 없고, 날려버린 오후도 없습니다. 버튼 하나만 누르면 VM은 망가뜨리기 전 상태 그대로 돌아옵니다. 베타 테스트에서 이는 혁신적입니다. 베타를 설치하고, 망가지는 것을 지켜보고, 되돌리고, 뭔가를 조정하고, 다시 시도하는 것을 실제 하드웨어에서 macOS를 한 번 재설치하는 데 걸리는 시간 동안 열 몇 번 반복할 수 있습니다. 실제 장비는 이런 반복 속도를 도저히 따라갈 수 없기 때문에, 버그를 안정적으로 재현해야 하는 개발자들이 가장 먼저 VM을 찾는 것입니다.

실제 데이터와 환경으로부터의 격리

VM은 또한 밀폐된 상자이기도 합니다. 베타가 무엇을 하든 — 이상한 백그라운드 프로세스를 띄우든, 환경설정을 망가뜨리든, 계정에서 이상 동작을 하든 — 그것은 게스트 안에서 일어나지, 실제 디스크에서 일어나지 않습니다. 실제 사진, 문서, 키체인, 앱 라이선스는 호스트에 손대지 않은 채 안전하게 남아 있습니다. 바로 이 격리 때문에 "설치 실패" 버그가 더 아프게 다가옵니다. VM의 존재 가치 전체가 신중한 사람들이 무서운 소프트웨어를 안전하게 테스트할 수 있게 해주는 것인데, 이 버그는 신중한 경로의 문을 닫아버리면서 무모하게 "그냥 메인 Mac에 설치해버리자"는 경로는 활짝 열어둡니다. VM과 씨름하고 싶지 않아서 실제 하드웨어에서 베타를 고려하고 있다면, macOS 27 개발자 베타를 설치해야 할지와 알려진 문제들에 대한 솔직한 의견을 결정하기 전에 읽어보세요. VM의 안전망은 가볍게 포기할 만한 것이 아니기 때문입니다.

근본 원인: Virtualization Framework의 호스트-게스트 불일치

여기가 실제로 모든 것을 설명해 주는 부분입니다. macOS 27 베타가 Tahoe 호스트의 가상 머신에 설치되지 않는 이유는 Apple 자체의 Virtualization framework — 이 앱들 모두가 Apple 실리콘에서 macOS 게스트를 만들고 설치하는 데 의존하는 저수준 시스템 구성 요소 — 내부의 호환성 문제 때문입니다. 구체적으로는 그 프레임워크의 설치 프로그램 부분, 즉 macOS 복원 이미지를 부팅 가능한 게스트로 변환하는 역할을 맡은 API가 macOS 26.6 호스트에서 실행될 때 macOS 27 복원 이미지를 제대로 처리하지 못하는 것입니다. Apple은 개발자 포럼에서 이를 알려진 문제로 인정했습니다. 간단히 말하면, Tahoe 26.6을 실행 중인 Mac은 Apple 가상화 설치 경로로 macOS 27 복원 이미지를 앉힐 수 없으며, 호스트가 업그레이드되거나 Apple이 프레임워크를 패치하기 전까지는 그 경로가 막혀 있습니다.

Apple 실리콘 Mac에서 실행 중인 macOS 가상 머신 창

Apple 실리콘 가상화의 실제 작동 방식

왜 이런 일이 벌어지는지 알려면 Apple 실리콘에서 가상 머신이 어떻게 작동하는지 이해해야 합니다. Intel 시대와는 상당히 다르기 때문입니다. Apple 실리콘 Mac에서는 서드파티 앱이 macOS 게스트를 실행하기 위한 자체 저수준 하이퍼바이저를 내장하지 않습니다. 대신 Apple이 macOS의 일부로 Virtualization framework(Virtualization.framework)를 제공하며, 이 프레임워크가 실질적인 작업을 도맡습니다. 가상 하드웨어를 정의하고, 게스트를 부팅하고 — 여기서 결정적으로 — 복원 이미지로부터 새 게스트에 macOS를 설치합니다. UTM, VirtualBuddy, Tart, Parallels, VMware Fusion 같은 앱들은 macOS 게스트의 경우 사실상 이 공유된 Apple 프레임워크를 감싼 정교한 프론트엔드이자 관리 계층에 불과합니다. Apple은 심지어 같은 근본 호출을 보여주는 최소한의 기준 도구 macosvm도 함께 제공합니다. 이 설계는 우아하며, 평상시 Apple 실리콘에서 macOS 위의 macOS 가상화가 그토록 깔끔하게 작동하는 이유이기도 합니다 — 하지만 동시에 모든 앱이 동일한 엔진을 구동하고 있으므로 프레임워크의 버그도 그대로 물려받는다는 뜻입니다. 이 아키텍처를 더 깊이 이해하고 싶다면 저희의 보다 폭넓은 macOS 가상화 완전 가이드를 참고하세요.

VZMacOSInstaller 경로가 깨지는 지점

이 프레임워크 안에서 새 macOS 게스트를 설치하는 구성 요소는 복원 이미지를 받아서 작동하는 시스템을 만들어내는 부분입니다. VM 앱에 macOS 27 IPSW를 건네고 새 게스트를 만들라고 하면, 앱은 이 설치 프로그램 API를 호출해서 복원 이미지를 읽고, 검증하고, 게스트의 가상 스토리지를 설정한 다음 macOS 27을 그 안에 씁니다. 문제는 macOS 26.6 호스트에 내장된 설치 프로그램 코드가 사실상 자신이 처리하도록 요청받은 macOS 27 복원 이미지보다 더 오래된 버전이라는 점입니다. 27 이미지는 26.6 호스트의 프레임워크가 아직 제공하지 않는 설치 프로그램 동작을 기대하며, 이 불일치가 설치 도중 드러나면 프레임워크는 중단됩니다. 위쪽의 앱은 상세한 설명 없이 실패를 전달받고 일반적인 "설치 실패" 상자를 보여줍니다. 이는 버전 불일치 문제입니다. 설치를 수행하는 쪽이 설치되는 대상보다 한 걸음 뒤처져 있어서, 둘이 중간에서 만날 수 없는 것입니다.

왜 모든 VM 앱이 똑같이 실패하는가

설치 프로그램이 앱이 아니라 Apple의 프레임워크 안에 있다는 것을 이해하고 나면, 동일한 실패들은 더 이상 미스터리가 아닙니다. UTM, VirtualBuddy, Tart, Parallels, VMware Fusion 모두 결국 신규 macOS 게스트 설치를 동일한 Apple 설치 프로그램 API를 통해 처리합니다. 따라서 그 API가 26.6 호스트에서 27 이미지를 처리하지 못하면, 어떤 잘 다듬어진 인터페이스를 거쳐 갔든 관계없이 모두 같은 고장 난 문 앞에 다다릅니다. 이것이 바로 앱 쪽에서 아무리 문제를 해결하려 해도 도움이 되지 않고, VM 앱만 업데이트한다고 고쳐질 수도 안 고쳐질 수도 있는 이유입니다. 해결책은 호스트 운영체제 쪽에서 오거나(27 이미지를 이해하는 프레임워크를 가진 버전으로 이동), Apple이 호스트 업데이트로 프레임워크를 패치하거나, 현재 프레임워크가 처리할 수 있는 이미지를 가진 이후 27 베타에서 나와야 합니다. 이 현실이 바로 아래 세 가지 해결 방법의 근거입니다.

앱별 참고 사항: UTM, VirtualBuddy, Tart, Parallels, VMware Fusion

근본 원인은 공유되지만, 각 앱은 문제를 드러내는 방식과 어떤 해결 방법이 가장 잘 맞는지에 있어 저마다의 특징이 있습니다. 각 앱에서 무엇을 예상해야 하는지 살펴보겠습니다.

UTM

UTM은 인기 있는 무료 오픈소스 가상화 도구로, 비용이 들지 않고 Apple 가상화 기반 macOS 게스트와 QEMU 기반의 다른 시스템 게스트를 모두 다루기 때문에 많은 사람의 첫 선택지입니다. Apple 실리콘에서 macOS 27 게스트를 만들 때는 Apple Virtualization 백엔드를 사용하므로, 설치 프로그램 버그를 그대로 물려받습니다. UTM에서는 IPSW를 선택한 뒤 안내형 macOS 설치 도중 실패가 나타나는 것이 일반적입니다. 영향을 받는 호스트에서는 VM을 다시 만들거나, IPSW를 바꾸거나, 리소스 설정을 조정해도 이를 넘어갈 수 없습니다. 다만 UTM은 해결 방법 2에 적합한 좋은 선택지입니다. 먼저 UTM에서 macOS Tahoe 게스트를 만들고(Tahoe 호스트에서는 문제없이 설치됩니다) 내부에서 27 베타로 업그레이드하면 됩니다.

VirtualBuddy

VirtualBuddy는 macOS 게스트를 다운로드, 설치, 실행하기 위해 Apple의 Virtualization framework를 중심으로 만들어진 무료 전용 도구이며, 프레임워크의 기능을 쉽게 다룰 수 있게 해주기 때문에 바로 이런 종류의 베타 테스트에 애용됩니다. 그만큼 긴밀히 결합되어 있다는 것은 설치 프로그램 버그에도 직접 노출된다는 뜻입니다. 설치 흐름 전체가 곧 프레임워크의 설치 흐름이기 때문입니다. VirtualBuddy는 복원 이미지를 편리하게 가져오고 스냅샷을 관리하는 데 뛰어나므로, 버그를 우회한 뒤에는 여전히 강력한 선택지로 남습니다. Tahoe 게스트를 만들고 스냅샷을 찍은 다음 그 자리에서 업그레이드하는 데 쓰세요. 프레임워크와 이만큼 밀접한 도구는 새로운 베타의 특이 사항을 빠르게 반영하는 경우가 많으니 릴리스를 주시하세요.

Tart

Tart는 자동화와 지속적 통합(CI)을 겨냥한 명령줄 가상화 도구로, macOS VM을 프로그래밍 방식으로 생성, 사용, 폐기하는 데 쓰입니다. 이 역시 Apple의 Virtualization framework 위에 놓여 있으므로, 26.6 호스트에서 macOS 27 이미지를 가져오는 tart create는 사용 가능한 이미지를 만들어내는 대신 동일한 설치 실패를 겪습니다. CI 파이프라인에서는 무인·반복 가능한 빌드가 전체의 요점이기 때문에 이 버그가 특히 지장을 줍니다. Tart 사용자에게 가장 깔끔한 해법은 해결 방법 1입니다 — 이미 macOS 27인 러너에서 이미지 빌드 단계를 실행하거나, 다른 곳에서 27 게스트를 미리 빌드한 뒤 완성된 이미지를 러너들에 배포하는 것이지, 영향을 받는 각 호스트에서 새로 설치하는 것이 아닙니다.

Parallels Desktop

Parallels Desktop은 Mac에서 Windows를 실행하는 것으로 가장 잘 알려진 잘 다듬어진 상용 하이퍼바이저이지만, Apple 실리콘에서는 Apple의 프레임워크를 통해 macOS 게스트도 만들며, 그 macOS 게스트는 Tahoe 호스트에서 동일한 설치 프로그램 벽에 부딪힙니다. Parallels는 새 macOS 릴리스가 나올 때마다 신속하게 업데이트를 내놓는 편이니 앱 업데이트를 확인할 가치는 있습니다 — 다만 결함이 호스트 프레임워크에 있다면 호스트 자체가 앞으로 나아가기 전까지는 Parallels 업데이트만으로는 해결되지 않을 수 있다는 점을 기억하세요. Parallels는 스냅샷과 게스트 관리 도구가 성숙해 있어 "Tahoe 설치 후 업그레이드" 경로를 수월하게 만들어주므로 해결 방법 2에 편안한 환경입니다.

VMware Fusion

이제 개인용으로는 무료인 VMware Fusion도 마찬가지로 Apple 실리콘의 macOS 게스트에 Apple의 Virtualization framework를 사용하며, 영향을 받는 호스트에서 macOS 27 복원 이미지를 넘기면 동일한 방식으로 실패합니다. Parallels와 마찬가지로 Fusion 업데이트를 지켜보되, 앱 업데이트만으로 호스트 프레임워크의 한계가 뒤집히리라 기대하지는 마세요. Fusion은 Tahoe 우선 업그레이드 경로에서 잘 작동하며, 목표가 신규 설치 경험 자체를 테스트하는 것이 아니라 그저 작동하는 macOS 27 샌드박스를 확보하는 것이라면 이 경로만으로 아무것도 기다릴 필요 없이 목표에 도달할 수 있습니다.

이 다섯 가지 모두를 관통하는 공통점은 같습니다. 어떤 앱을 고르든 인터페이스와 편의 기능이 바뀔 뿐, 근본 원인은 바뀌지 않습니다. 스냅샷과 관리 도구가 가장 마음에 드는 앱을 고른 다음, 아래 해결 방법 중 하나를 적용하세요.

해결 방법 1: 이미 macOS 27을 실행 중인 Mac에서 VM 만들기

가장 직접적인 해결책은 불일치 자체를 없애는 것입니다. 이미 macOS 27을 실행 중인 Mac을 호스트로 삼아 macOS 27 게스트를 설치하세요. 이 버그는 근본적으로 게스트 이미지보다 한 걸음 뒤처진 호스트 프레임워크에 관한 문제이므로, 호스트를 게스트와 같은 세대에 두면 설치 프로그램 API가 27 복원 이미지를 올바르게 처리할 수 있고 VM은 정상적으로 만들어집니다. 이미 27 베타를 실행 중인 두 번째 Mac이나 여분의 파티션, 외장 부팅 디스크가 있다면 거기서 27 게스트를 만들면 "설치 실패" 오류는 아예 발생하지 않습니다.

명백한 함정은 순환적이라는 점입니다. 많은 사람이 VM을 원하는 이유가 바로 실제 Mac에서 27을 실행하지 않기 위해서인데, 이 해결 방법은 VM을 만들기 위해 실제 Mac에서 27을 실행하라고 요구합니다. 이는 타당한 반론이며, Mac이 한 대뿐이고 그것을 베타로 옮기고 싶지 않다면 이 방법은 맞지 않으니 해결 방법 2로 건너뛰세요. 하지만 딱 맞아떨어지는 상황도 있습니다. 베타에 올려도 괜찮은 오래된 보조 Apple 실리콘 Mac을 갖고 있다면, 그 기기를 "VM 제조소"로 전용하는 것은 깔끔한 방법입니다. 그 기기를 27로 올리고, 라이선스가 허용하는 만큼 27 게스트를 만들고 스냅샷을 찍으면, 그 게스트 이미지는 휴대 가능하고 재사용할 수 있습니다. CI를 운영하는 팀도 같은 아이디어를 적용해서 27에 상주하는 빌드 러너를 지정하고, 그곳에서 다른 모든 사람이 소비할 게스트 이미지를 생성하면 됩니다.

이 경로를 택한다면 즉흥적으로 메인 머신을 업그레이드하기보다는 신중하게 진행하세요. macOS 27 퍼블릭 베타를 안전하게 설치하는 방법 가이드는 적절한 백업과 탈출구를 갖추고 실제 Mac을 베타로 옮기는 방법을 다루며, 이는 일회용으로 취급하는 기기라 해도 중요합니다. 그리고 나중에 그 호스트를 안정 버전 macOS로 되돌리고 싶다면 미리 탈출 경로를 알아두세요. 데이터 손실 없이 macOS 27 베타에서 Tahoe로 다운그레이드하는 방법 안내가 바로 그럴 때를 위해 존재합니다.

해결 방법 2: 먼저 Tahoe VM을 만든 다음 Software Update로 업그레이드하기

이는 Mac이 한 대뿐인 대부분의 사용자가 실제로 원할 만한 해결 방법입니다. 이미 갖고 있는 Tahoe Mac 외에는 아무것도 필요하지 않기 때문입니다. 핵심은 이 버그가 프레임워크의 설치 프로그램을 통해 복원 이미지로부터 macOS 27을 새로 설치하는 경우에만 영향을 미친다는 점입니다. 이미 설치된 macOS 게스트를 실행하는 데는 영향을 주지 않고, 실행 중인 게스트 내부의 일반적인 인플레이스 소프트웨어 업데이트 메커니즘에도 영향을 주지 않습니다. 그러니 27을 직접 설치하려 하는 대신, 먼저 macOS Tahoe 게스트를 설치하고 — 호스트와 게스트가 일치하므로 Tahoe 호스트에서 완벽하게 작동합니다 — 그런 다음 그 게스트 내부에서 실제 Mac을 업그레이드하듯 Software Update로 27 베타로 업그레이드합니다.

Software Update를 통해 macOS VM을 베타로 업그레이드하기

단계별 안내

원하는 VM 앱에서 일반적인 macOS Tahoe 가상 머신을 만드는 것부터 시작하세요. Tahoe 복원 이미지를 지정하고(또는 앱이 가져오게 하고) 설치하게 둡니다. 호스트와 게스트가 같은 세대이므로 오류 없이 완료됩니다. 새 Tahoe 게스트를 부팅하고, 초기 설정을 진행해서 작동하는 데스크톱까지 도달하세요. 다른 무엇을 하기 전에 스냅샷을 찍으세요 — 이 깨끗한 Tahoe 상태는 보존할 가치가 있으며, 업그레이드가 잘못될 경우 즉시 되돌릴 수 있는 지점이 됩니다.

이제 실제 Mac에서 하듯 게스트를 베타에 등록하세요. 시스템 설정을 열고 일반, 그다음 소프트웨어 업데이트로 이동한 다음 베타 업데이트 제어를 사용해 게스트를 macOS 27을 제공하는 Apple Beta 프로그램 트랙에 등록하세요. 등록이 완료되면 소프트웨어 업데이트가 macOS 27 베타를 사용 가능한 업그레이드로 제시합니다. 다운로드를 시작하기 직전에 스냅샷을 한 번 더 찍은 다음 다운로드하고 설치하게 두세요. 이는 새로운 프레임워크 설치가 아니라 게스트 자체의 소프트웨어 업데이트 메커니즘이 실행하는 인플레이스 업데이트이므로, 고장 난 설치 프로그램 경로를 완전히 우회하며 게스트는 macOS 27을 실행하는 상태로 올라옵니다.

이 방법이 버그를 우회하는 이유

이 방법이 통하는 이유는 명확히 짚어볼 가치가 있습니다. 프레임워크의 VZMacOSInstaller 경로는 호스트가 복원 이미지로부터 새 게스트를 만들 때만 호출됩니다. 이미 실행 중인 게스트를 새 macOS 버전으로 업그레이드하는 것은 게스트 내부에서 작동하는 macOS의 일반적인 업데이트 시스템이 처리하며, 이는 호스트 프레임워크가 27 복원 이미지를 처리할 수 있는지에 의존하지 않는 별개의 코드 경로입니다. 사실상 호스트에게 빈 상자에 27을 설치하라고 요구하는 대신, 어느 Mac이나 그렇듯 게스트 스스로 업그레이드하게 하는 셈입니다. 직접 설치보다 시간이 더 걸리고 디스크도 조금 더 소모하지만, 오늘 당장 Tahoe 호스트에서 작동하는 macOS 27 VM을 얻을 수 있으며, 두 번째 Mac도 패치를 기다릴 필요도 없이 신뢰성 있게 확보할 수 있습니다.

해결 방법 3: 업데이트된 베타 빌드나 VM 앱을 기다리기

때로는 아직 아무것도 하지 않는 것이 옳은 선택입니다. 이 결함은 호스트 프레임워크와 게스트 복원 이미지 사이의 상호작용에 있으므로, 베타 시즌의 통상적인 변화 속에서 해결될 만한 딱 그런 종류의 문제입니다. 저절로 해결될 수 있는 경로는 세 가지입니다. 첫째, Apple이 27 복원 이미지를 이해하는 Virtualization framework를 갖춘 호스트 업데이트 — 이후의 Tahoe 26.6 빌드나 정식 릴리스 — 를 출시하면, 그 호스트에서 신규 설치가 작동하기 시작합니다. 둘째, Apple이 현재 프레임워크가 처리할 수 있는 복원 이미지를 가진 수정된 macOS 27 베타를 출시할 수 있습니다. 셋째, VM 앱들 스스로가 자신들이 영향을 미칠 수 있는 부분에서는 업데이트를 통해 이 특이 사항에 맞춰 적응할 수 있습니다. 이 중 어느 하나라도 직접 설치 경로를 다시 켜줍니다.

그래서 베타 주기를 계속 따라가는 것이 중요합니다. Apple은 이번 주기에 빠르게 반복해 왔습니다 — 개발자 베타 3 빌드가 나온 지 일주일 만에 수정된 개발자 베타 3와 첫 퍼블릭 베타가 뒤따랐습니다 — 그리고 2주 된 격차를 메우는 수정판이 흔합니다. 급하지 않다면 다음 베타가 나온 후 다시 확인해 보는 것은 상당히 합리적인 전략이며 비용도 들지 않습니다. 기다리는 것은 또한 그저 베타를 테스트하기 위해 메인 Mac에 무언가 과감한 조치를 취하고 싶은 유혹이 들 때 취할 수 있는 정직한 조언이기도 합니다. 이 버그는 베타 특유의 결함일 뿐 영구적인 상태가 아니며, 베타는 원래 이런 거친 부분이 있기 마련입니다.

다만 그 절충안은 현실적으로 봐야 합니다. 목표가 가벼운 탐색이라면 "기다리기"는 훌륭하지만, 진짜 마감이 있다면 — 재현해야 할 버그, 새 릴리스에 맞춰 검증해야 할 앱, 이번 주 안에 답을 줘야 할 클라이언트가 있다면 — 형편없는 전략입니다. 그런 경우에는 해결 방법 2를 사용해 지금 당장 작동하는 27 게스트를 확보하고, 앞으로 있을지 모를 프레임워크 수정은 덤으로 여기세요. 그리고 상황이 유동적이므로 특정 빌드 하나에 지나치게 몰두하지 않도록 주의하세요. 오늘 실패한 것이 다음 주에는 깔끔하게 설치될 수도 있고, 다음 주에 설치되는 것이 그다음에는 또 다르게 동작할 수도 있습니다. 한 번 본 동작이 고쳐졌다고 가정하기보다는 알려진 문제 목록을 계속 추적하세요. macOS 27 개발자 베타의 알려진 문제를 정리한 저희 목록은 또 다른 저녁 시간을 쏟기 전에 VM 설치 문제가 해결됐다고 표시됐는지 확인하기 좋은 곳입니다.

IPSW를 구하고 검증하는 방법

복원 이미지 자체가 버그의 원인은 아니지만, 해결 방법 1과 나중에 시도할 직접 설치를 위해서는 올바른 이미지가 필요하므로 이 부분을 제대로 해두는 것은 가치가 있습니다. Apple 실리콘에서 macOS는 가상화 및 복원용으로 일반 업그레이드에 쓰이는 "Install macOS" 앱이 아니라 서명되고 자체 완결된 복원 이미지인 IPSW 파일로 배포됩니다. 가장 안전한 출처는 베타 이미지를 위한 Apple 자체 개발자 채널과 VM 앱이 대신 가져와 주는 복원 이미지입니다. 특히 VirtualBuddy와 상용 앱의 안내형 설치 프로그램을 비롯한 여러 도구가 적절한 복원 이미지를 직접 다운로드할 수 있어서, 파일을 직접 찾아다니는 수고를 덜어주고 잘못된 빌드를 받을 가능성을 줄여줍니다.

빌드 일치와 무결성 확인

IPSW를 수동으로 구했다면, 그것이 정말로 테스트하려는 macOS 27 베타 빌드인지, 라벨이 잘못됐거나 오래된 파일은 아닌지 확인하세요. 출처가 빌드 식별자를 명시하는 경우 이를 기록해 두고 어떤 빌드로 작업 중인지 계속 추적하세요. 베타 빌드는 자주 바뀌고 빌드마다 동작이 다를 수 있기 때문입니다. 다운로드 후에는 파일이 온전한지 확인하세요. 출처에 명시된 크기와 일치하는지 확인하고, 체크섬이 공개되어 있다면 이미지를 사용하기 전에 검증하세요. 잘리거나 손상된 다운로드는 나름의 방식으로 실패하는데 — 보통 더 일찍, 다른 증상으로 실패합니다 — 그러니 먼저 무결성을 검증해 두면 "파일이 나쁜" 문제와 이 가이드에서 다루는 호스트 프레임워크 문제를 깔끔하게 구분할 수 있습니다. 진행 표시줄이 한동안 그럴듯하게 나아간 후에야 설치가 실패하고 메시지가 일반적인 "설치 실패"라면, 특히 체크섬으로 검증된 이미지가 동일하게 실패한다면 거의 확실히 프레임워크 버그를 보고 있는 것이지 나쁜 IPSW가 아닙니다.

검증된 IPSW는 재사용할 수 있는 곳에 보관하세요. 테스트하는 동안 같은 게스트를 여러 번 만들게 될 가능성이 높고, 매번 몇 기가바이트짜리 복원 이미지를 다시 다운로드하는 것은 낭비이기 때문입니다. 검증되고 올바르게 라벨이 붙은 하나의 이미지를 여러 시도에 걸쳐 재사용하면 문제 해결 과정도 깔끔해집니다. 같은 정상 작동이 확인된 파일이 Tahoe 호스트에서는 실패하고 27 호스트에서는 성공한다면, 스스로 진단을 확인한 셈이 됩니다.

스냅샷과 롤백: VM의 존재 이유

어떤 해결 방법으로 작동하는 macOS 27 게스트를 얻었든, VM 테스트를 할 가치 있게 만드는 그 한 가지 기능을 낭비하지 마세요. 스냅샷을 아낌없이, 그리고 의도적으로 찍으세요. 스냅샷은 특정 순간의 게스트 전체 상태 — 디스크, 메모리, 설정, 모든 것 — 를 담아내므로, 클릭 한 번으로 정확히 그 순간으로 돌아갈 수 있습니다. 베타 테스트에서 이는 여러분의 안전벨트입니다. 아무것도 설정하기 전에 깨끗한 설치 상태를 스냅샷하세요. 베타에 등록하기 전, 주요 업데이트 전, 실험적인 무언가를 실행하기 전에도 다시 스냅샷하세요. 테스트가 게스트를 손상시키거나 베타 업그레이드가 잘못되면, 처음부터 다시 만드는 대신 몇 초 만에 되돌릴 수 있습니다. 신규 설치가 막힌 호스트에서는 그렇지 않으면 다시 Tahoe-후-업그레이드 과정을 처음부터 반복해야 할 것입니다.

여기에 작은 습관을 들이세요. 각 스냅샷이 무엇을 나타내는지 알 수 있도록 이름을 붙이세요 — "깨끗한 Tahoe", "베타 등록, 업그레이드 전", "27 설치됨, 테스트 전" — 서로 구분할 수 없는 라벨 없는 복원 지점 더미를 쌓아두지 마세요. 더 이상 필요 없는 오래된 스냅샷은 정리하세요. 각각이 디스크 공간을 소모하기 때문입니다. 다만 핵심 이정표는 유지하세요. 일치하는 Tahoe 기준 스냅샷과 작동하는 27 스냅샷의 조합은 안정적인 환경과 베타 환경 사이를 거의 즉시 전환할 수 있다는 뜻이며, 이것이 바로 이런 작업에서 VM이 실제 장비보다 우월하게 만드는 유연성입니다. 스냅샷을 부차적인 것이 아니라 산출물 그 자체로 여기세요. 실행 중인 27 게스트가 가치 있는 이유는 바로 언제든 정상 작동이 확인된 버전으로 돌아갈 수 있기 때문입니다.

더 안전한 대안: 별도의 APFS 볼륨 또는 외장 디스크

VM만이 베타를 신중하게 테스트하는 유일한 방법은 아니며, 목표에 따라서는 최선의 방법이 아닐 수도 있습니다. 특히 현재의 설치 버그를 고려하면 하드웨어에 가까운 두 가지 접근 방식을 고려할 만합니다. 첫째는 Mac의 내장 드라이브에 있는 별도의 APFS 볼륨입니다. APFS는 여러 볼륨이 같은 물리적 공간을 공유할 수 있게 해주므로, 기존 컨테이너에 새 볼륨을 추가하고 그 볼륨에 macOS 27을 설치한 다음 테스트하고 싶을 때 그 볼륨으로 부팅할 수 있습니다. 실제 데이터가 담긴 메인 볼륨은 완전히 분리된 채로 남습니다. 부팅할 볼륨을 직접 선택할 수 있고, 베타는 자신만의 공간에서 살아갑니다. 이는 실제 하드웨어에서 전체 속도로 실행되므로 VM이 충실히 재현할 수 없는 성능이나 GPU에 민감한 작업에 중요하며, 가상화 설치가 아니라 일반적인 실제 장비 설치이므로 프레임워크 설치 프로그램 버그를 완전히 피해 갑니다.

두 번째 옵션은 외장 디스크입니다. 베타를 빠른 외장 SSD에 설치하고 그곳에서 Mac을 부팅하면 내장 드라이브를 전혀 건드리지 않는 완전히 격리된 테스트 환경을 얻게 됩니다. 외장을 뽑으면 Mac은 손대지 않은 안정 버전 시스템으로 곧장 부팅됩니다. 별도 볼륨 방식과 마찬가지로 이 역시 실제 실리콘에서 실행되고 가상화 설치 프로그램 경로를 건너뛰므로 "설치 실패" 버그가 적용되지 않습니다.

이를 VM과 정직하게 비교해 보세요. 절충안은 별도 볼륨이든 외장 디스크든 VM만큼 빠르게 반복할 수 있게 해주는 즉각적인 스냅샷-롤백 루프를 제공하지 않는다는 점입니다. 실제 설치를 되돌리려면 버튼 클릭이 아니라 재설치나 복원이 필요하고, 환경을 전환하려면 창을 넘나드는 것이 아니라 재부팅이 필요합니다. 하지만 이들은 네이티브 속도로 실행되고 실제 하드웨어 동작을 정확히 재현하며, 지금 이 순간 VM 설치를 막고 있는 바로 그 버그로부터 자유롭습니다. 테스트하는 목적이 소프트웨어를 빠르게 반복하는 것이 아니라 실제 성능, 드라이버 동작, 하드웨어 기능을 평가하는 것이라면, 별도 볼륨이나 외장 디스크가 실제로 더 똑똑한 도구일 수 있으며, 메인 시스템을 건드리지 않고 유지하는 진정으로 안전한 방법입니다.

알아두어야 할 Apple 실리콘 가상화 제약

작동하는 macOS 27 게스트를 확보한 후에도, Apple이 macOS 가상화에 두는 경계를 이해해 두면 도움이 됩니다. 이는 VM 안에서 현실적으로 무엇을 할 수 있는지를 결정하며, 그렇지 않으면 버그처럼 보일 수 있는 몇 가지 동작을 설명해 줍니다.

VM 2개 라이선스 규칙

역사적으로 Apple의 소프트웨어 라이선스 조건은 한 호스트에서 실행할 수 있는 macOS 가상 머신 수를 제한해 왔습니다 — 일반적으로 호스트 자체 외에 Mac 한 대당 최대 두 개의 macOS 게스트로 이해됩니다. 이는 기술적 장벽이라기보다 라이선스 제약이지만 실재하며, 병렬 테스트를 위해 한 기기에서 macOS 27 게스트 전체 함대를 띄울 계획이었다면 중요한 문제입니다. 더 많이 필요하다면 더 많은 호스트가 필요합니다. 대부분의 개인 개발자와 파워 유저에게는 게스트 두 개면 충분합니다 — 깨끗한 기준선 하나와 활성 테스트 환경 하나 — 하지만 CI 매트릭스를 구축하는 팀은 하나의 강력한 Mac이 무제한의 macOS 게스트를 호스팅할 수 있다고 가정하기보다 호스트당 제한을 용량 계획에 반영해야 합니다.

게스트 내 DRM 부재 및 일부 iCloud 서비스 제한

Apple 실리콘의 Apple Virtualization framework에서 실행되는 macOS 게스트는 특정 보호된 서비스에 접근할 수 없습니다. 실제로는 일부 DRM으로 보호된 콘텐츠와 여러 iCloud 및 계정 연동 서비스가 게스트 안에서는 로그인되지 않거나 완전히 작동하지 않는다는 뜻입니다. 가상 머신은 실제 Mac과 같은 하드웨어 아이덴티티와 보안 증명을 제공하지 않으며, Apple은 특정 서비스를 이에 근거해 제한합니다. 그러니 테스트 계획의 일부가 기기 수준 DRM이나 특정 iCloud 자격에 의존하는 서비스에 로그인하는 것이라면, VM 안에서는 마찰이나 아예 거부를 예상하세요. 이는 여러분의 설정 오류가 아니라 의도된 설계이며, 특정 종류의 테스트에서는 별도 볼륨이나 외장 디스크가 실제 하드웨어에서 더 나은 환경인 또 다른 이유이기도 합니다. 이를 미리 알아두면 베타가 고장 났다고 결론짓는 대신 가상화 경계가 제 역할을 하고 있을 뿐임을 이해할 수 있습니다.

이러한 제약은 설치 버그를 우회하는 데 장애물이 되는 것은 아니지만, 기대치를 설정해 줍니다. VM은 OS, API, 대부분의 앱을 다루는 데 탁월하며, 하드웨어에 종속되거나 계정에 종속된 몇 가지 기능에는 의도적으로 접근이 차단되어 있습니다. 이에 맞춰 테스트를 계획하고, 그런 경계에 부딪히는 작업에는 실제 하드웨어 설치를 활용하세요.

문제 해결

문제: VM을 아무리 다시 만들거나 어떤 앱을 써도 macOS 27 설치가 같은 지점에서 실패합니다.

해결책: 이는 로컬 설정 오류가 아니라 호스트 프레임워크 버그의 특징입니다. VM을 다시 만들어도 도움이 되지 않는 이유는 실패가 앱이나 설정이 아니라 공유된 Apple 설치 프로그램 경로에 있기 때문입니다. 재시도를 멈추고 전략을 바꾸세요. 해결 방법 2를 사용해 Tahoe 게스트를 만들고 내부에서 27로 업그레이드하거나, 이미 27을 실행 중인 Mac에서 게스트를 만드세요.

문제: VM 앱을 최신 버전으로 업데이트했는데도 설치가 여전히 실패합니다.

해결책: 앱 업데이트만으로는 호스트 운영체제의 Virtualization framework에 있는 결함을 고치지 못할 수 있습니다. 앱들은 Apple의 설치 프로그램 API를 감싸고 있을 뿐이므로, 그 API가 26.6 호스트에서 27 이미지를 처리하지 못하면 더 새로운 앱 빌드라도 같은 벽에 부딪힙니다. 호스트를 macOS 27로 옮기거나, Tahoe-후-업그레이드 경로를 사용하거나, 불일치를 해결하는 호스트 또는 베타 업데이트를 기다리세요.

문제: 실패가 손상된 IPSW 때문인지 알려진 버그 때문인지 확신할 수 없습니다.

해결책: 먼저 복원 이미지를 검증하세요 — 파일 크기가 출처와 일치하는지 확인하고 공개된 체크섬이 있다면 확인하세요. 손상된 파일은 보통 더 일찍, 다른 방식으로 실패합니다. 체크섬으로 검증된 이미지가 진행 표시줄이 1~2분 나아간 후에도 여전히 실패하고 일반적인 "설치 실패" 메시지로 끝나며, 앱마다 동일하게 실패한다면 나쁜 다운로드가 아니라 프레임워크 버그를 보고 있는 것입니다.

문제: Tahoe VM은 문제없이 설치되지만 게스트 내부의 소프트웨어 업데이트에서 macOS 27 베타가 보이지 않습니다.

해결책: 실제 Mac과 마찬가지로 게스트도 먼저 올바른 베타 트랙에 등록되어야 합니다. 게스트에서 시스템 설정을 열고 일반, 그다음 소프트웨어 업데이트로 이동한 다음 베타 업데이트 제어를 사용해 macOS 27을 제공하는 Apple Beta 프로그램 트랙에 등록하세요. 등록 후에는 27 베타가 사용 가능한 업그레이드로 나타나야 합니다. 되돌릴 수 있도록 다운로드를 시작하기 전에 스냅샷을 찍으세요.

문제: 일부 iCloud나 미디어 서비스가 macOS 27 게스트 안에서 로그인되지 않거나 작동하지 않습니다.

해결책: 이는 예상된 동작입니다. Apple 실리콘의 macOS 게스트는 VM이 실제 Mac과 같은 하드웨어 아이덴티티를 제공하지 않기 때문에 특정 DRM으로 보호된 서비스와 계정 연동 서비스에 접근할 수 없습니다. 이는 베타 버그가 아니라 의도된 가상화 경계입니다. 그런 특정 서비스를 반드시 테스트해야 한다면 VM 대신 실제 하드웨어의 별도 APFS 볼륨이나 외장 디스크에 베타를 설치하세요.

FAQ

"설치 실패" 오류는 제 VM 앱의 버그인가요, 아니면 macOS의 버그인가요?

이는 macOS 자체의 버그입니다 — 구체적으로는 macOS 26.6 호스트가 macOS 27 복원 이미지를 처리하는 Virtualization framework의 설치 프로그램 경로에 있습니다. Apple은 이를 알려진 문제로 인정했습니다. UTM, VirtualBuddy, Tart, Parallels, VMware Fusion 모두 동일한 근본 Apple 설치 프로그램을 공유하기 때문에 똑같이 실패하는 것이지, 특정 앱 하나에 잘못이 있는 것이 아닙니다.

VM 앱을 재설치하거나 IPSW를 다시 다운로드하면 고쳐질까요?

아니요. 결함이 앱이나 파일이 아니라 호스트의 Virtualization framework에 있으므로, 앱을 재설치하거나 검증된 복원 이미지를 다시 다운로드해도 아무것도 바뀌지 않습니다. 두 가지 모두 여기서 흔한 시간 낭비입니다. 진짜 해결책은 호스트를 macOS 27로 옮기거나, 내부에서 Software Update로 Tahoe 게스트를 업그레이드하거나, 수정 업데이트를 기다리는 것뿐입니다.

두 번째 Mac 없이 VM에 macOS 27을 설치할 수 있나요?

가능합니다. 해결 방법 2를 사용하세요. 기존 Tahoe 호스트에서 macOS Tahoe 가상 머신을 만들고, 부팅한 다음, 소프트웨어 업데이트에서 Apple Beta 프로그램에 등록하고, 그 게스트를 그 자리에서 macOS 27로 업그레이드하세요. 게스트 내부 업데이트 경로는 고장 난 프레임워크 설치 프로그램을 피해 가므로, Mac 한 대만으로도 작동하는 macOS 27 게스트를 얻을 수 있습니다.

별도 APFS 볼륨에서 테스트하는 것이 VM보다 안전한가요?

데이터 측면에서는 더 안전하다고 볼 수 있으며, 가상화 설치가 아니라 실제 하드웨어 설치이므로 이 특정 버그를 피할 수 있습니다. 절충안은 즉각적인 스냅샷 롤백을 잃고 환경을 전환하려면 재부팅해야 한다는 점입니다. 실제 성능이나 하드웨어 동작을 평가하는 데는 훌륭하지만, 빠른 소프트웨어 반복에는 실행할 수만 있다면 VM의 스냅샷이 여전히 우세합니다.

한 대의 Mac에서 macOS 27 VM을 몇 개까지 실행할 수 있나요?

Apple의 라이선스 조건은 역사적으로 호스트 자체 외에 macOS 게스트를 호스트당 두 개로 제한해 왔습니다. 이는 기술적 차단이 아니라 라이선스 규칙이지만 실재하며, 병렬 테스트를 계획하는 사람에게는 중요합니다. 동시에 실행할 macOS 게스트가 더 필요하다면, 하나에 몰아넣기보다 추가 호스트 머신이 필요합니다.

그냥 Apple이 고칠 때까지 기다려야 할까요?

가볍게 탐색 중이고 마감이 없다면 기다리는 것이 합리적입니다. 이후 베타 빌드, 호스트 업데이트, 업데이트된 프레임워크가 직접 설치를 되살릴 수 있고, 베타는 빠르게 반복됩니다. macOS 27 샌드박스에 의존하는 실제 작업이 있다면 기다리지 마세요. Tahoe-후-업그레이드 경로를 사용해 오늘 작동하는 게스트를 확보하고, 앞으로 있을지 모를 수정은 덤으로 여기세요.

결론

macOS 27 베타가 가상 머신에 설치되지 않으려 드는 문제는 개인적인 실수처럼 느껴지지만 전혀 그렇지 않은 부류의 문제입니다. 일반적인 "설치 실패" 메시지는 구체적이고 Apple이 인정한 원인을 감추고 있습니다. macOS Tahoe 26.6 호스트는 Virtualization framework의 설치 프로그램을 구동해 더 새로운 macOS 27 복원 이미지를 앉힐 수 없으며, 그래서 그 공유된 프레임워크 위에 만들어진 모든 앱 — UTM, VirtualBuddy, Tart, Parallels, VMware Fusion — 이 같은 지점에서 실패합니다. 설치 프로그램이 앱이 아니라 Apple의 프레임워크 안에 있다는 것을 이해하고 나면 동일한 실패들이 이해가 되고, 헛된 재시도가 멈추며, 앞으로 나아갈 길이 분명해집니다. VM 설정에서 무엇을 바꾸든 호스트에 내장된 벽을 움직일 수는 없습니다.

좋은 소식은 세 가지 진짜 우회 방법과 진정으로 안전한 대안 하나가 있다는 것입니다. 여분의 Mac이 있다면 이미 macOS 27을 실행 중인 Mac에서 게스트를 만드세요. Mac이 한 대뿐이라면 Tahoe 게스트를 설치하고 내부에서 Software Update로 베타로 업그레이드하면 고장 난 설치 프로그램을 깔끔하게 우회할 수 있습니다. 아니면 그저 격차를 메우는 베타 빌드, 호스트 업데이트, 앱 업데이트를 기다리세요. 이는 계속 변화하는 베타 상황이며 영향을 받는 빌드는 바뀔 수 있기 때문입니다. 그리고 스냅샷 속도의 반복이 필요하지 않다면, 별도의 APFS 볼륨이나 외장 부팅 디스크가 이 버그로부터 자유로우면서도 메인 시스템을 건드리지 않는 완전한 속도의 실제 하드웨어 테스트 환경을 제공합니다. 어떤 경로를 택하든 스냅샷을 일찍, 자주 찍고, VM 2개 라이선스 제한과 게스트 내부의 DRM 및 iCloud 경계를 유념하며, 검증된 IPSW를 손 닿는 곳에 보관하세요.

베타 여정을 얼마나 멀리 갈지 아직 정하는 중이라면, 먼저 더 넓은 맥락 속에서 계획을 세우세요. macOS 27이 무엇을 바꾸고 언제 출시되는지를 읽고, Rosetta 2 종료와 Intel 앱 전환에 맞춰 여러분의 앱을 점검하고, 최종 Intel Mac 호환성 목록에서 여러분의 하드웨어가 어디에 속하는지 확인하세요. 스마트하게 테스트하고, 탈출구를 준비해 두고, VM이 가장 잘하는 일을 하게 하세요. 위험을 대신 감수해서 실제 Mac이 그럴 필요가 없게 만드는 것 말이죠.