UTM 딥다이브
— 실행 버튼 뒤에 숨은 작은 컴퓨터의 설계

1프로젝트 한줄 요약

UTM은 Apple 기기에서 가상 컴퓨터를 만들고 관리하는 네이티브 앱입니다. 가상 컴퓨터의 CPU·메모리·디스크·네트워크를 설정하고, Windows나 Linux 같은 운영체제를 부팅한 뒤 화면과 입력 장치를 연결합니다. 실행 엔진으로 QEMU를 사용하며, macOS에서는 Apple의 Virtualization.framework를 사용하는 경로도 제공합니다.

UTM에서 배울 핵심은 가상 CPU를 직접 만드는 법보다, 복잡한 실행 엔진을 사용자가 다룰 수 있는 앱으로 연결하는 법입니다. 버튼 하나를 처리하려면 설정 해석, 파일 접근, 프로세스 시작, 화면 연결, 오류 복구가 함께 맞물려야 합니다.

사용자가 하는 일과 코드가 하는 일

여기서 VM은 가상 머신의 줄임말입니다. 단순한 앱 창보다 수명이 긴 객체입니다. 창을 표시하는 일, 게스트 CPU를 실행하는 일, 디스크에 설정을 저장하는 일은 서로 다른 책임으로 읽어야 합니다.

2왜 주목받는가

UTM은 2026-10-23 분석 기준 GitHub Trending Swift Weekly #3에 선정됐으며, GitHub 스타는 36,485개입니다. 최신 릴리스 v5.0.8의 날짜는 2026-10-17, 최근 push는 2026-10-20입니다. 릴리스와 관심이 같은 시기에 있었다는 사실만으로 특정 기능이 순위 상승을 일으켰다고 결론 내릴 수는 없습니다.

UTM은 Apple Silicon의 ARM64 환경에서 ARM64 게스트를 실행하거나, x86·PowerPC 같은 다른 아키텍처의 소프트웨어를 보존하는 데 활용할 수 있습니다. README.md는 QEMU 기반 에뮬레이션과 macOS의 하드웨어 가상화를 소개합니다. 이는 기능을 바탕으로 본 활용 가능성이며, 트렌딩 유입 경로에 대한 통계는 아닙니다. UTM 공식 소개에서 제품 정보를 더 볼 수 있습니다.

비슷한 선택지와 비교하면 보이는 장점

QEMU의 개념은 공식 시스템 소개에서 더 볼 수 있습니다. iSH의 실행 범위는 UTM의 README.md·Related 항목을 기준으로 요약했으며, iSH 공식 사이트도 참고할 수 있습니다. 속도나 제품 우열을 측정한 비교표는 아닙니다.

이 저장소의 학습 가치는 쉬운 화면과 까다로운 운영체제 제약 사이의 연결이 실제 코드로 드러난다는 데 있습니다. macOS와 iOS가 같은 시작 버튼을 보여줘도, 내부에서는 프로세스 생성과 JIT 권한의 차이를 처리해야 합니다.

README의 범위와 실제 구현을 함께 읽기

README.md는 QEMU 기반 시스템 에뮬레이션과 30종 이상의 프로세서를 소개합니다. 하지만 모든 배포판이 그 구성을 똑같이 포함하지는 않습니다. scripts/build_dependencies.sh의 ARM64 *-tci 분기에는 아래 일곱 타깃이 명시됩니다.

# scripts/build_dependencies.sh — ARM64 TCI 빌드의 target-list
aarch64-softmmu, i386-softmmu, ppc-softmmu, ppc64-softmmu,
riscv64-softmmu, x86_64-softmmu, m68k-softmmu

README의 SE 요약은 ARM·PPC·RISC-V·x86 계열과 32/64비트 변형을 언급하지만, 이 빌드 목록에는 m68k가 추가되고 arm-softmmu와 riscv32-softmmu는 없습니다. Configuration/QEMUConstant.swift의 WITH_QEMU_TCI 아래 isHidden도 같은 일곱 항목을 노출합니다. 배포판별 지원 범위를 판단할 때는 소개 문구보다 빌드 타깃과 UI 필터를 함께 확인해야 합니다.

3기술 스택 전체 지도

이 프로젝트의 백엔드는 웹 서버를 뜻하지 않습니다. 같은 앱 안팎에서 VM을 관리하는 서비스 계층입니다. 주 빌드 정의는 UTM.xcodeproj/project.pbxproj이며, 앱 버전은 Build.xcconfig에서 정합니다. Node.js·Rust·Python 서버 프로젝트에서 찾는 package.json·Cargo.toml·pyproject.toml 대신 Xcode 설정과 SwiftPM 잠금 파일을 읽습니다.

프론트엔드: SwiftUI에 플랫폼별 화면 구현을 결합

UTM.xcodeproj/project.pbxproj의 여러 타깃은 SWIFT_VERSION = 5.0을 사용합니다. 이는 Swift 언어 모드 설정이며, 설치된 컴파일러가 반드시 Swift 5.0이라는 뜻은 아닙니다. 현대적인 any·async/await가 보인다는 이유만으로 Swift 6 엄격 동시성 검사가 활성화됐다고 판단해서도 안 됩니다.

백엔드: 두 엔진과 여러 연결 부품

SwiftPM 잠금 파일에서 직접 읽는 버전

근거 파일은 UTM.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved입니다. 버전 번호가 있는 항목과 브랜치 커밋으로 고정된 항목을 구분해야 같은 의존성을 재현할 수 있습니다.

인프라·빌드: 네이티브 의존성을 준비한 뒤 앱을 만든다

scripts/build_dependencies.sh는 patches/sources의 소스를 사용해 의존성을 빌드하고, 타깃별 sysroot-*에 배치합니다. autoconf·Meson·CMake 계열 결과물을 Xcode에서 사용할 프레임워크로 정리하는 과정입니다. 그다음 scripts/build_utm.sh로 앱 아카이브를 만들고, 패키징 스크립트가 서명·배포 형식을 처리합니다.

# .github/workflows/build.yml — 책임별 흐름 요약
configuration → build-sysroot
                  ├→ build-utm → package-ios / submit-ios
                  └→ build-sysroot-universal → build-universal
                                              → package-mac / submit-mac

# 캐시를 구분하는 주요 입력
플랫폼 + CPU 아키텍처
scripts/build_dependencies.sh + scripts/fixup.sh + patches/**
Universal 구성: scripts/pack_dependencies.sh도 포함
캐시 저장 키: 위 입력에 커밋 SHA도 포함

CI의 macOS 러너 기본 이미지는 macos-26이며, 저장소 설정에 따라 자체 macOS 러너를 선택합니다. actions/checkout@v3, actions/cache/restore@v4, actions/upload-artifact@v4가 실제 워크플로에 등장합니다. 앱 매트릭스에는 macOS ARM64·x86_64와 iOS·visionOS의 일반·SE·Remote 구성이 있습니다.

화면 코드만으로 완성되는 앱처럼 보여도, 재현 가능한 빌드에는 Swift 패키지와 네이티브 의존성의 고정 지점이 모두 필요합니다. Build.xcconfig는 제품 버전 5.0.8, 빌드 번호 129를 선언합니다.

4아키텍처 심화 분석

전체 구조: 제어와 화면 출력을 나눠서 보기

이 그림의 위쪽은 VM을 제어하는 흐름입니다. 아래의 SPICE 연결은 QEMU의 화면·입력을 옮기는 흐름입니다. QMP는 QEMU에 정지·재개 같은 명령을 보내는 관리 프로토콜이므로, SPICE와 역할을 바꿔 이해하면 안 됩니다. Apple 백엔드는 QEMU나 SPICE를 거치지 않고 OS의 Virtualization API로 실행됩니다.

설계 패턴 1: 공통 프로토콜과 화면용 어댑터

Services/UTMVirtualMachine.swift는 두 엔진이 공통으로 제공할 동작을 선언합니다. Configuration과 Capabilities는 연관 타입입니다. 각 구현은 자신의 설정 타입과 기능 집합을 유지하면서, 시작·정지 같은 공통 요청을 받을 수 있습니다.

// Services/UTMVirtualMachine.swift — 선언 일부 발췌
protocol UTMVirtualMachine: AnyObject, Identifiable {
    associatedtype Capabilities: UTMVirtualMachineCapabilities
    associatedtype Configuration: UTMConfiguration

    var config: Configuration { get }
    var state: UTMVirtualMachineState { get }
    func start(options: UTMVirtualMachineStartOptions) async throws
    func stop(usingMethod method: UTMVirtualMachineStopMethod) async throws
}

이를 전략 패턴 관점에서 읽으면, 시작이라는 요청은 유지하고 실행 전략을 교체하는 구조입니다. 다만 모든 분기가 사라지지는 않습니다. Platform/macOS/UTMDataExtension.swift의 run(vm:options:startImmediately:)는 Apple VM인지 QEMU VM인지에 따라 적절한 창 컨트롤러를 만듭니다. 엔진별 화면 기능까지 완전히 같지는 않기 때문입니다.

Platform/VMData.swift는 @MainActor의 ObservableObject입니다. 내부의 wrapped: (any UTMVirtualMachine)?에 실제 VM을 담고, 화면에 필요한 상태를 @Published로 노출합니다. load(from:)는 설정 타입을 보고 구체적인 VM 구현을 고릅니다.

subscribeToChildren()는 하위 객체의 변경을 관찰하며, onStateChange 콜백에서 Task { @MainActor in ... }을 통해 상태와 스크린샷을 화면 모델에 반영합니다. 이 부분이 엔진의 알림을 SwiftUI가 관찰할 값으로 바꾸는 어댑터 역할입니다.

설계 패턴 2: 상태 머신과 실패 시 정리

시작 버튼을 두 번 눌렀을 때 두 번 부팅하면 안 됩니다. UTMVirtualMachineState는 stopped·starting·started·pausing· paused·resuming·saving·restoring·stopping을 구분합니다. 전환 중인 상태가 있기 때문에 UI도 진행 중인 작업을 표현할 수 있습니다.

Services/UTMQemuVirtualMachine.swift의 start(options:)는 먼저 state == .stopped를 검사하고, 다른 상태이면 invalidVmState 오류를 던집니다. 이어 상태를 .starting으로 바꾼 뒤 _start(options:)를 기다립니다.

// start(options:)의 핵심 흐름을 줄인 설명용 코드
guard state == .stopped else {
    throw UTMQemuVirtualMachineError.invalidVmState
}
state = .starting
do {
    // 실제 코드는 startTask를 저장하고 defer로 해제한다.
    try await _start(options: options)
    state = .started
} catch {
    await registryEntry.setIsSuspended(false)
    await qemuVM.kill()
    state = .stopped
    throw error
}

_start(options:)에는 자원 캐시 준비, TPM 시작, 인자 생성, SPICE 서비스 시작, QEMU 시작이 이어집니다. 중간마다 Task.checkCancellation()을 호출합니다. async를 붙여도 작업 취소와 자원 정리가 자동으로 끝나지는 않습니다. 작업이 취소 신호를 확인하고 이미 만든 자원을 정리해야 한다는 사례입니다.

비동기 기능을 설계할 때는 성공 결과만큼, 중간 상태와 실패 후 되돌아갈 상태를 구체적으로 정해야 합니다. 여기서는 시작 실패 시 실행 엔진을 종료하고 공통 상태를 .stopped로 복구합니다. 이것을 모든 파일 변경까지 되돌리는 데이터베이스 트랜잭션으로 해석해서는 안 됩니다.

설계 패턴 3: 저장 형식이 되는 설정 모델

Configuration/UTMQemuConfiguration.swift와 Configuration/UTMAppleConfiguration.swift는 서로 다른 설정 트리를 가집니다. 공통 인터페이스인 UTMConfiguration은 Codable을 사용합니다. 화면의 설정은 잠깐 쓰는 폼 값에 그치지 않고, 다음 실행과 버전에서도 읽어야 할 저장 형식입니다.

Configuration/UTMConfiguration.swift의 load(from:)는 config.plist에서 먼저 UTMConfigurationStub을 읽고 Backend로 분기합니다. QEMU이면 QEMU 설정을, Apple이면 macOS에서 Apple 설정을 디코딩합니다. Backend 키가 없거나 값이 Unknown인 예전 형식은 Configuration/Legacy/ 모델을 통해 마이그레이션을 시도합니다.

// Configuration/UTMConfiguration.swift — 실제 상수
static var oldestVersion: Int { 4 }
static var currentVersion: Int { 4 }
static var dataDirectoryName: String { "Data" }

// 저장 단계 요약: save(to:)
prepareSave(for:) → 번들·Data 디렉터리 준비 → saveData(to:)
→ 참조하지 않는 Data 파일 정리 → XML PropertyListEncoder → config.plist

여기서 설정 형식 버전 4는 제품 버전 5.0.8과 별개입니다. QEMU 설정의 디코더는 허용 범위보다 낮거나 높은 버전을 오류로 처리합니다. 버전 검사를 읽으면 “새 앱에서 저장한 파일을 이전 앱이 읽을 수 있는가”라는 호환성 문제를 구체적으로 이해할 수 있습니다.

registryEntry에는 호스트별·단기적인 정보가 따로 있습니다. 프로토콜의 설명은 화면 크기와 이동식 드라이브 북마크 등을 예로 듭니다. 휴대할 VM 설정과 특정 Mac의 접근 권한을 구분하는 설계이며, .utm을 옮겼다고 원래 호스트의 권한까지 자동 이전되지는 않습니다.

설계 패턴 4: 인자 빌더가 파일 자원까지 운반한다

Configuration/UTMQemuConfiguration+Arguments.swift는 설정을 QEMU 인자로 번역합니다. allArguments는 자동 생성 인자와 사용자 인자를 합칩니다. generatedArguments는 CPU·장치·네트워크·디스크 등의 인자 묶음을 순서대로 조합합니다.

Configuration/QEMUArgumentBuilder.swift는 Swift의 @resultBuilder입니다. buildExpression이 문자열·정수·URL을 조각으로 바꾸고, buildEither·buildOptional·buildArray가 조건문과 반복문을 지원합니다. buildBlock은 조각을 병합하고 buildFinalResult는 최종 인자 배열을 만듭니다.

// Configuration/QEMUArgument.swift — 값이 함께 다니는 구조
struct QEMUArgument: Hashable, Identifiable, Codable {
    var string: String
    var fileUrls: [URL]?
    // 나머지 선언 생략
}

// UTMQemuVirtualMachine._start(options:) — 실제 추출식
let arguments = allArguments.map({ $0.string })
let resources = allArguments.compactMap({ $0.fileUrls }).flatMap({ $0 })

문자열과 URL 목록을 함께 유지하는 이유가 중요합니다. 디스크 경로를 명령행 문자열에 넣어도, 별도의 샌드박스 프로세스가 그 파일을 읽을 권한을 얻는 것은 아닙니다. URL 정보를 보존해야 시작 직전에 자원 접근 절차를 수행할 수 있습니다.

QEMUArgumentFragment.merge(_:)는 기존 문자열에 URL 조각을 붙일 때 URL의 쉼표를 ,,로 이스케이프합니다. QEMU의 쉼표 구분 옵션 문법과 파일 이름이 충돌하지 않도록 처리하는 것입니다. 이는 HTML 이스케이프나 셸 인용과 다른 규칙입니다. 어떤 문법의 경계를 넘는지 먼저 구분해야 합니다.

Services/UTMQemuSystem.m의 startQemuWithCompletion:은 자원마다 북마크를 준비해 전달합니다. Services/UTMProcess.m의 accessDataWithBookmark:securityScoped:completion:은 XPC 연결이 있으면 Helper에 요청하고, 없으면 현재 프로세스에서 처리합니다.

QEMUHelper/QEMUHelper.m의 같은 접근 메서드는 북마크를 URL로 해석하고 필요하면 갱신합니다. startQemuTask:standardOutput:standardError:libraryPath:argv:completion:는 NSTask로 QEMULauncher를 시작합니다. 권한 전달과 프로세스 수명이 얽히는 지점이므로 “파일 경로가 맞으면 열린다”는 가정으로 읽으면 놓치는 부분이 많습니다.

플랫폼 경계에서 알아둘 예외

Documentation/Architecture.md는 iOS에서 QEMU를 pthread로 실행하고 한 프로세스에서 재실행이 제약된다고 설명합니다. VM 실행 경로의 UTMProcess.startDylibThread:completion:에서도 dlopen과 pthread_create를 확인할 수 있습니다. macOS의 XPC 실행 구조를 iOS에 그대로 적용하면 안 되는 이유입니다.

5디렉토리 구조 해부

예를 들어 RAM 입력값이 실제 QEMU 옵션으로 바뀌는 과정을 보려면 Platform/에서 화면을 찾고, Configuration/UTMQemuConfigurationSystem.swift의 memorySize를 거쳐, Configuration/UTMQemuConfiguration+Arguments.swift의 architectureArguments를 읽습니다. 엔진 시작 실패를 이해하려면 Services/로 이동합니다.

실제 코드 규모와 집계 해석

커밋 1c5e215의 파일을 확장자별로 나누고 줄바꿈 문자를 센 값입니다. 빈 줄·주석·라이선스 머리말을 포함하며, .git은 제외했습니다. SwiftPM이 외부에서 가져오는 QEMUKit·CocoaSpice 소스나 빌드 시 내려받는 QEMU 전체 코드는 포함하지 않습니다.

Swift에는 Configuration/QEMUConstantGenerated.swift 10,088줄과 Scripting/UTMScripting.swift 323줄이 포함됩니다. 이 두 생성 파일을 빼면 Swift는 51,346줄입니다. 큰 숫자 때문에 모든 줄을 순서대로 읽으려 하지 말고, 기능 하나를 관통하는 경로부터 선택하세요.

생성 파일의 상수를 하나씩 외우는 것보다 scripts/const-gen.py가 필요한 이유를 이해하는 편이 좋습니다. 장치와 CPU 목록이 많을수록 수작업보다 생성 규칙을 유지하는 편이 일관성을 지키기 쉽습니다.

6학습 포인트 (기술별)

SwiftUI·Combine: 화면의 원본 데이터 찾기

Platform/UTMData.swift는 VM 목록·선택·작업 중 표시 등을 관리하고, Platform/VMData.swift는 개별 VM의 화면 상태를 감쌉니다. 화면에 보이는 값이 엔진에서 온 것인지, 앱이 잠깐 관리하는 값인지 구분해 보세요. 같은 “실행 중” 표시라도 그 원본은 서비스의 상태이고, 화면 모델은 이를 전달받아 표시합니다.

Swift 동시성: 기다림과 실행 위치를 구분하기

Services/UTMAppleVirtualMachine.swift의 _start(options:guestProvisioning:)는 withCheckedThrowingContinuation으로 콜백 API를 async 흐름에 연결합니다. 실제 apple.start 호출은 vmQueue.async 안에 있습니다. 기다림을 표현하는 장치와, API를 어느 큐에서 호출하는지를 나누어 읽어야 합니다.

// Apple 백엔드의 일반 시작 분기 — 제어 구조를 줄인 예시
try await withCheckedThrowingContinuation {
    (continuation: CheckedContinuation<Void, Error>) in
    vmQueue.async {
        // 실제 코드는 apple 존재 여부와 OS별 시작 옵션도 검사한다.
        apple.start { result in
            continuation.resume(with: result)
        }
    }
}

continuation은 기다리는 작업에 결과를 한 번 전달해야 합니다. 전달하지 않으면 대기가 끝나지 않고, 두 번 전달하면 계약을 어기게 됩니다. 실제 코드의 guard let apple 실패 경로가 오류를 전달한 뒤 return하는 이유도 이 관점에서 읽어 보세요. async만 보고 “백그라운드 스레드에서 실행된다”고 해석하지 않는 습관이 중요합니다.

Codable·버전 호환성: 데이터가 오래 사는 앱 설계

UTMQemuConfiguration.init(from:)는 단순히 필드를 채우지 않습니다. 백엔드와 형식 버전을 검증하고 하위 모델을 디코딩합니다. UTMQemuConfigurationSystem.init(from:)는 알 수 없는 CPU 값에 대해 invalidConfigurationValue를 잡고 기본 CPU로 되돌리는 처리도 포함합니다.

실습으로 “없는 키”, “알 수 없는 CPU”, “미래 형식 버전”의 세 입력을 가정하고, 각각 기본값 적용·복구·거부 중 어떤 처리가 나오는지 표로 정리하세요. 모든 디코딩 실패를 같은 오류로 취급하지 않는 법을 배울 수 있습니다.

DSL·타입 설계: 문자열에 잃어버린 의미를 되찾기

QEMUArgumentBuilder의 입력은 모두 문자열로 취급되지 않습니다. URL은 fileUrls를 남기고, 숫자는 문자열로 바뀌며, 최종 인자 경계는 isFinal로 표현됩니다. “문자열을 합친다”는 작업 안에도 자료의 의미와 문법 경계를 보존하는 설계가 있습니다.

경계를 넘기는 데이터에는 값만 담을지, 권한·수명·해석 규칙까지 함께 담을지 판단해야 합니다. 이 질문은 파일 업로드, 데이터베이스 연결, 외부 도구 실행에도 그대로 적용할 수 있습니다.

스냅샷: 실제 상태와 관리용 메타데이터 분리

Services/UTMSnapshotService.swift는 VM 상태와 별도로 스냅샷 목록·제목·계보를 다룹니다. Services/UTMSnapshotBackend.swift는 실제 상태를 저장하고 복원하는 공통 계약을 정의합니다. create(suspendIdentifier:)·restore(_:)·delete(identifier:)가 대표적입니다.

UTMSnapshotBackendEntry.isComplete는 해당 스냅샷이 필요한 모든 이미지를 포함하는지 나타냅니다. 디스크를 추가하기 전의 스냅샷을 복원하면 여러 디스크의 시점이 어긋날 수 있다는 문제를 코드 주석이 설명합니다. 목록에 보이는 항목과 실제 복원 가능한 데이터가 항상 같지는 않다는 점을 배워 보세요.

실습으로 createSnapshot(title:on:)와 restoreSnapshot(_:on:)에서 백엔드 호출과 UTMSnapshotManifest 갱신을 다른 색으로 분류해 보세요. 메타데이터와 실제 디스크 상태가 어긋났을 때 어느 쪽을 조사해야 할지 설명하는 것이 목표입니다.

기능의 이름과 지원 조건도 나누어 봐야 합니다. 이 상위 서비스의 isSupported(for:)는 Apple VM에 대해 macOS 27 이상을 검사합니다. Apple Silicon에서 Apple VM의 중단 상태를 저장·복원하는 경로의 macOS 14 조건과는 다른 범위입니다. 관련 코드가 존재한다는 사실만으로 모든 지원 OS에서 같은 스냅샷 관리 기능을 쓸 수 있다고 결론 내리지 마세요.

CLI·앱 자동화: 같은 기능을 여러 입구로 제공

utmctl/UTMCtl.swift는 ArgumentParser로 명령을 정의하고 ScriptingBridge의 SBApplication으로 UTM 앱에 연결합니다. 별도 HTTP 서버에 요청하는 CLI라고 생각하면 실제 구조를 놓칩니다. Scripting/UTM.sdef가 자동화 인터페이스의 어휘를 정의합니다.

# 이미 설치된 앱을 사용하는 환경에서의 읽기 전용 명령 예시
utmctl list
utmctl status "학습용 Linux"
utmctl snapshot list "학습용 Linux" --json

위 명령은 사용 예시이며 소스 읽기 실습에 실행이 필요하지는 않습니다. 코드에서는 UTMAPICommand.run()과 virtualMachine(forIdentifier:in:)를 따라가며, 이름이나 UUID가 어떤 앱 객체로 연결되는지 확인하세요.

7하드웨어 / 시스템 요구사항

근거는 UTM.xcodeproj/project.pbxproj, scripts/build_dependencies.sh, .github/workflows/build.yml, Documentation/MacDevelopment.md와 Documentation/iOSDevelopment.md입니다. OS 버전 숫자 하나로 전체 기능의 요구사항을 설명하기 어려운 프로젝트입니다.

CPU: ARM64 Linux와 x86 Windows의 비용은 다르다

Configuration/QEMUConstant.swift의 hasHypervisorSupport는 먼저 기기의 기능을 검사하고, 호스트가 ARM64이면 .aarch64, x86_64이면 .x86_64만 허용합니다. 인자 생성의 machineArguments는 조건에 따라 -accel hvf 또는 -accel tcg를 만듭니다.

호스트와 다른 CPU를 실행할 수 있다는 사실은, 같은 CPU를 가상화할 때와 비슷한 속도가 나온다는 뜻이 아닙니다. 학습용 Linux를 고를 때도 호스트와 같은 아키텍처의 이미지를 먼저 고려하면 부팅·실습 대기 시간을 줄이기 쉽습니다. 이 문서에는 기기별 속도 측정이나 벤치마크 결과를 포함하지 않습니다.

메모리와 저장 공간: 기본값은 권장 사양이 아니다

UTMQemuConfigurationSystem의 구조체 초기값은 memorySize = 512MiB, cpuCount = 0, jitCacheSize = 0입니다. CPU 수 0은 직접 지정하지 않고 자동 선택한다는 의미입니다. 실제 emulatedCpuCount는 호스트의 성능 코어와 게스트 아키텍처를 고려하고, 조합에 따라 단일 코어를 선택하기도 합니다. 메모리 512MiB는 모델의 기본값일 뿐 Windows나 데스크톱 Linux의 권장 메모리라는 뜻이 아닙니다. 마법사나 게스트별 설정은 이 값을 바꿀 수 있습니다.

# 용량을 계획할 때의 항목 — 공식 최소 사양 수치가 아니다
필요한 호스트 RAM ≈ 호스트 OS·앱 사용량 + 게스트 RAM + 엔진·장치·코드 캐시
디스크 여유     = 게스트 이미지 + 설치 매체 + 스냅샷 + 임시·변환 공간

machineArguments는 TCG를 사용할 때 지정된 JIT 캐시가 없으면 memorySize / 4로 tb-size 값을 만듭니다. 이 계산식이 곧 실제 상주 메모리 총량은 아닙니다. iOS에서는 메모리 한도도 제약이므로 기기 전체 RAM을 게스트에 모두 배정하지 않는 것이 좋습니다.

그래픽·권한·빌드 의존성의 조건

소스에는 Vulkan·DirectX 드라이버를 선택하는 경로가 있습니다. vulkanDriver·directXDriver는 OS 버전·렌더러 선택·Rosetta 가용성을 검사합니다. 이 선택 코드만으로 모든 게스트·드라이버·게임 조합의 호환성을 보장할 수는 없습니다. 제품의 그래픽 기능 안내는 UTM 공식 사이트에서 볼 수 있습니다.

배포본을 사용하는 것과 개발 빌드를 만드는 조건도 다릅니다. 개발 문서는 미리 빌드된 Sysroot-* 아티팩트를 받는 경로를 안내합니다. 저장소만 열어도 QEMU·SPICE가 자동으로 준비되는 구조는 아닙니다. 서명 여부에 따라 USB·브리지 네트워크 등 일부 기능이 달라질 수 있다고 macOS 개발 문서가 설명합니다.

일반 iOS UTM의 JIT 조건은 OS·설치 방식에 따라 달라집니다. SE는 JIT 우회 없이 인터프리터로 실행하는 경로입니다. 설치 방법은 공식 iOS 설치 문서에서 해당 기기와 버전에 맞춰 확인하세요.

8직접 해볼 수 있는 실습 과제

처음부터 UTM 전체를 빌드하면 서명과 네이티브 의존성 준비가 학습을 가릴 수 있습니다. 아래 과제는 소스를 읽고 작은 모델로 재구성하는 방식입니다. 실습용 구현이 필요하면 원본 저장소와 분리한 작은 프로젝트에서 작성하고, 실제 디스크 이미지나 Helper 프로세스에 연결하지 않아도 됩니다.

실습의 완료 기준은 VM이 한 번 켜졌다는 사실보다, 값과 상태가 어느 경로로 전달되는지 설명할 수 있는가입니다. 소스 탐색을 도울 때는 저장소 루트에서 아래처럼 읽기 전용 검색을 사용할 수 있습니다.

# 소스 탐색 예시: 프로그램을 빌드하거나 실행하지 않는다.
rg -n 'memorySize|architectureArguments' Configuration
rg -n 'func start|state =|invalidVmState' Services/UTMQemuVirtualMachine.swift
rg -n 'fileUrls|func merge' Configuration/QEMUArgument.swift
rg -n 'withCheckedThrowingContinuation|vmQueue.async' Services/UTMAppleVirtualMachine.swift

9관련 기술 심화 학습 로드맵

첫 주에는 운영체제 이론 전체를 끝내려 하지 않아도 됩니다. “게스트의 명령을 누가 실행하는가”와 “장치를 누가 흉내 내는가”에 답할 수 있으면 충분합니다. 둘째 주부터는 타입·상태·파일이라는 눈에 보이는 단위로 나누어 공부합니다.

여섯 주 뒤에 선택할 세 갈래

• 앱 개발: 관찰 가능한 상태, 오류 표시, 입력·창 수명, UI와 서비스 계층의 경계를 더 공부합니다.
• 시스템 개발: QMP의 요청·응답, TCG의 명령 변환, VirtIO의 장치 모델, 파일 디스크립터 전달로 확장합니다.
• 개발 인프라: 크로스 컴파일, 의존성 고정, 빌드 캐시, 코드 서명·공증을 공부하고 CI의 각 단계와 연결합니다.

어느 갈래를 택하더라도 “내가 읽은 함수의 입력·출력·실패 조건은 무엇인가”라는 질문을 유지하세요. 한 번에 이해할 파일 수를 줄이고, 관찰한 근거를 경로와 함수명으로 남기는 방식이 긴 저장소를 읽는 데 도움이 됩니다.

10핵심 키워드 사전

11참고 링크

공식 저장소·문서

• UTM 공식 저장소 · 소개, 이슈, 전체 코드
• 분석 기준 커밋의 파일 트리 · 본문에서 인용한 경로의 기준
• UTM 공식 사이트 · 배포판과 제품 기능
• UTM 공식 사용자 문서 · 설치·게스트 구성 안내
• v5.0.8 릴리스 · 분석일 기준 최신 릴리스
• 아키텍처 문서 · QEMU·XPC·표시 계층의 배경
• macOS 개발 문서 · sysroot·빌드·서명 조건
• iOS 개발 문서 · 타깃 구성과 Helper 확장

핵심 소스와 관련 기술

• UTMVirtualMachine.swift · 프로토콜·상태·공통 동작
• UTMQemuVirtualMachine.swift · 시작과 오류 정리
• UTMQemuConfiguration+Arguments.swift · 설정을 실행 인자로 변환
• 네이티브 의존성 목록 · QEMU·SPICE 등의 버전과 커밋
• CI 워크플로 · 타깃 매트릭스와 배포 단계
• QEMUKit · 외부 패키지에 속하는 엔진 연결 코드
• CocoaSpice · SPICE 연결과 Apple 화면 통합
• QEMU 시스템 에뮬레이션 소개 · 엔진·가속기·옵션의 관계
• QEMU QMP 문서 · 관리 명령과 이벤트
• Apple Virtualization 문서 · 네이티브 VM 구성 API
• Swift 동시성 안내 · 비동기 호출·액터의 기초
• iSH 공식 사이트 · 사용자 모드 에뮬레이션과의 비교

온라인 기술 문서는 계속 바뀔 수 있습니다. 특히 QEMU의 master 문서는 UTM이 고정한 10.0.12-utm과 버전이 다를 수 있으므로 개념을 익히는 데 사용하고, 특정 옵션의 가용성은 해당 포크·버전과 함께 확인하세요.

현재 상태 (2026-10-23 확인)