tart 딥다이브
— 가상 Mac 한 대를 복제하고 배포하는 Swift 시스템 설계

1프로젝트 한줄 요약

tart는 Mac에서 가상머신의 생성·복제·실행·배포를 자동화하는 Swift 프로그램입니다. 주된 사용 환경은 Apple Silicon Mac이며, 게스트 운영체제로 macOS와 Linux를 다룹니다. 한 번 준비한 가상 컴퓨터를 이미지로 보관하고, 작업마다 복제해 같은 환경에서 시작하게 합니다.

예를 들어 Xcode와 빌드 도구가 설치된 VM을 준비해 두면, CI 작업마다 그 VM을 복제해 앱을 빌드할 수 있습니다. 다른 작업이 설치한 패키지나 남긴 파일 때문에 다음 빌드가 달라지는 문제를 줄이는 방식입니다. 작업 후 복제본을 정리하는 절차는 CI 스크립트나 외부 관리 도구가 구성해야 합니다.

명령 세 줄에 담긴 역할

다음은 README의 빠른 시작 예입니다. 이미지 다운로드 규모는 README 기준 약 25 GB입니다. 명령을 읽을 때는 설치 → 원격 이미지 확보와 로컬 복제 → VM 실행을 나누어 보세요.

# Homebrew로 배포된 실행 파일 설치
brew install openai/tools/tart

# 원격 VM 이미지를 가져와 tahoe-base라는 로컬 VM 생성
tart clone ghcr.io/cirruslabs/macos-tahoe-base:latest tahoe-base

# 로컬 VM 실행
tart run tahoe-base

clone은 원격 이미지를 필요할 때 먼저 가져옵니다. run은 저장된 VM 설정을 Apple의 VZVirtualMachineConfiguration으로 조립합니다. 이 연결을 이해하면 가상화 도구를 처음 접해도 소스를 따라갈 출발점이 생깁니다.

코드 출발점: Sources/tart/Root.swift, Sources/tart/Commands/Clone.swift, Sources/tart/VM.swift. VM 구현은 Sources/tart/에 모여 있습니다.

2왜 주목받는가

2-1. 개발 환경도 배포 대상이 됩니다

2026-10-23 GitHub Trending Swift Monthly #1이라는 순위는 관심이 모였다는 신호입니다. 순위만으로 유입 원인이나 특정 사건의 효과를 확정할 수는 없습니다. 기술적으로 주목할 지점은 macOS 개발 환경을 반복해서 공급하는 작업을 명령과 이미지 배포로 다룬다는 데 있습니다.

Xcode 버전, 운영체제 버전, 설치된 도구가 달라지면 CI 결과도 달라질 수 있습니다. VM 기준본을 만들고 복제하면 이러한 차이를 줄일 수 있습니다. docs/quick-start.md에는 macOS 버전별 이미지와 Xcode 이미지, Linux 이미지가 구분되어 있습니다.

tart의 강점은 가상머신을 실행하는 기능과 이미 준비된 환경을 팀에 배포하는 기능을 한 흐름으로 연결한 데 있습니다.

2-2. 기존 레지스트리를 VM 배포 창구로 씁니다

README는 OCI 호환 레지스트리로 VM을 push/pull할 수 있다고 설명합니다. 실제 Sources/tart/VMDirectory+OCI.swift의 pushToRegistry()는 VM 설정, 디스크 청크, NVRAM을 올린 뒤 이들을 가리키는 manifest를 발행합니다. VM을 나눠 주기 위해 별도의 대용량 파일 다운로드 체계를 처음부터 만들 필요를 줄입니다.

2-3. 무엇과 비교하면 성격이 분명해질까?

Anka 비교는 docs/faq.md의 설명 기준입니다. 이 문서는 Anka 3.0과 같은 기반 기술을 쓴다고 설명하므로, tart가 무조건 더 빠르다는 결론은 근거가 없습니다. 제품별 최신 기능·가격을 비교한 표로 읽기보다 배포와 운영 방식의 차이를 보는 표로 읽으세요.

2-4. 성능 주장과 측정 조건을 함께 읽습니다

README의 “네이티브에 가까운 성능”은 프로젝트의 주장입니다. benchmark/README.md에는 실제 호스트·게스트 비교 기록도 있지만, 모든 작업을 대표하지는 않습니다. 2024-03-27 기록의 M2 Pro·32 GB RAM·macOS 14.4.1 조건에서는 1 MB 무작위 쓰기가 호스트 2.6 GB/s, VM 2.5 GB/s인 반면, 1,000 MB 항목은 호스트 1.7 GB/s, VM 1.1 GB/s로 차이가 더 큽니다.

학습 근거: 저장소 FAQ, 조건이 명시된 벤치마크 기록, Apple의 macOS VM 예제.

3기술 스택 전체 지도

3-1. 백엔드 역할: Swift로 작성한 로컬 실행·관리 계층

여기서 백엔드는 웹 서버가 아니라 VM의 상태와 자원을 관리하는 로컬 프로그램입니다. Package.swift는 tart 실행 파일 하나와 TartTests 테스트 타깃을 정의합니다. 패키지 도구 선언은 swift-tools-version:5.10, 배포 대상은 .macOS(.v13)입니다.

도구 버전 선언을 현재 소스 전체의 빌드 가능 최소 컴파일러와 혼동하면 안 됩니다. 예를 들어 Sources/tart/Root.swift에는 nonisolated(unsafe)가 있고, CI의 실행 환경 이름은 xcode-27입니다. “Swift 5.10만 설치하면 현재 HEAD가 반드시 빌드된다”고 단정할 수 없습니다.

VM 구현 파일은 Sources/tart/ 아래에 있으며, 표의 경로는 저장소 루트 기준입니다. 위 Apple 프레임워크는 운영체제 SDK에 포함되며, 개별 SwiftPM 버전 번호를 가진 외부 패키지와 구분해야 합니다.

3-2. 의존성의 요구 범위와 실제 고정값

Package.swift는 허용하는 버전 범위를, Package.resolved는 선택된 버전과 커밋을 기록합니다. 의존성을 설명할 때는 최소 요구 버전과 실제 고정 버전을 함께 확인해야 재현 가능한 지식이 됩니다.

브랜치를 지정한 의존성도 있습니다. Dynamic은 master의 772883073d04, TextTable은 master의 e03289289155, opentelemetry-swift는 main의 ed37be952508에 고정되어 있습니다. 게스트 에이전트 gRPC 패키지는 main의 4935078c2fe2입니다. 브랜치 이름은 움직이므로 고정 커밋도 함께 보는 습관이 필요합니다.

전이 의존성으로는 swift-nio 2.93.0, swift-protobuf 1.33.3, swift-system 1.4.2가 기록되어 있습니다. 실행 타깃의 직접 의존성과 잠금 파일에 등장하는 모든 패키지는 같은 목록이 아닙니다.

3-3. 프론트엔드 역할: SwiftUI와 AppKit

VM 화면은 웹 UI가 아닙니다. Sources/tart/Commands/Run.swift의 MainApp이 SwiftUI 창을 만들고, VMView: NSViewRepresentable이 AppKit 기반 VZVirtualMachineView를 감쌉니다. updateNSView()는 실제 vm.virtualMachine을 화면에 연결합니다.

즉 SwiftUI가 창과 메뉴를 맡고, 가상 화면 표시와 입력 처리는 Apple의 VM 뷰가 맡습니다. 같은 명령 파일 안에 CLI 옵션 해석과 화면 코드가 함께 있어, 초보자는 “명령부”와 “화면부”로 나눠 읽는 편이 좋습니다. 문서 사이트는 별도로 mkdocs.yml과 docs/가 관리합니다.

3-4. 인프라·빌드·테스트 지도

.goreleaser.yml의 version: 2는 설정 형식 버전이며 tart의 릴리스 버전이 아닙니다. arm64와 x86_64 Swift 실행 파일을 먼저 만들고 범용 바이너리로 묶습니다. 따라서 GoReleaser를 쓴다는 사실만으로 본체가 Go 프로그램이라고 판단하면 안 됩니다.

integration-tests/go.mod는 go 1.25, testify 1.11.1, otel 1.38.0, protobuf 1.36.11을 요구합니다. benchmark/go.mod는 go 1.23.0과 toolchain go1.24.1을 따로 선언합니다. Python integration-tests/requirements.txt의 pytest·testcontainers·paramiko 등은 버전이 고정되어 있지 않습니다.

버전 근거: Package.swift, Package.resolved, GitHub CI, Cirrus CI.

4아키텍처 심화 분석

VMDirectory는 파일의 위치와 배치를 알고, VM은 실행 중인 가상머신 객체를 다룹니다. “디스크에 저장된 VM”과 “지금 돌아가는 VM”의 역할이 구분된다는 점부터 잡으면 구조가 단순해집니다.

4-1. 패턴 ① 명령 분기와 메인 이벤트 루프 소유권

Sources/tart/Root.swift의 Root는 AsyncParsableCommand를 따릅니다. 그런데 진입점 main()은 의도적으로 동기 함수입니다. 먼저 parseAsRoot()로 명령을 해석한 뒤, MainThreadCommand인지 검사합니다.

// Root.main()의 핵심 분기 발췌
if let mainThreadCommand = command as? MainThreadCommand {
  MainActor.assumeIsolated {
    runOnMainThread(mainThreadCommand)
  }
} else {
  let task = Task.detached {
    await runInBackground(command)
  }
  // 원본에는 Ctrl+C를 task.cancel()로 연결하는 처리도 있음
  dispatchMain()
}

Sources/tart/Commands/Run.swift는 extension Run: MainThreadCommand {}로 이 경로에 참여합니다. 일반 명령은 비동기 실행 경로로 보내고, run은 메인 스레드 최상위에서 AppKit·SwiftUI의 이벤트 루프를 구동합니다. Sources/tart/Root.swift 주석은 Swift 6.4 이후 실행기와 중첩된 UI 루프 사이에서 VM 부팅이 멈추는 문제를 피하기 위한 설계라고 설명합니다.

이 설명은 해당 소스 주석에 기록된 배경입니다. 모든 Swift 프로그램에서 동기 진입점을 써야 한다는 일반 규칙은 아닙니다. MainActor.assumeIsolated 역시 실행을 다른 스레드로 보내는 명령이 아니라, 현재 격리 조건이 맞다는 전제 아래 실행합니다.

4-2. 패턴 ② 전략 객체를 조합하는 VM 구성

Sources/tart/Platform/Platform.swift는 OS마다 달라지는 부품을 프로토콜로 정의합니다. Darwin은 macOS용 부트로더·하드웨어 모델·화면을, Linux는 EFI 부트로더와 VirtIO 화면을 제공합니다. VM.craftConfiguration()은 그 결과를 모아 최종 설정을 만듭니다.

// VM.craftConfiguration()에서 발췌
configuration.bootLoader = try vmConfig.platform.bootLoader(nvramURL: nvramURL)
configuration.cpuCount = vmConfig.cpuCount
configuration.memorySize = vmConfig.memorySize
configuration.platform = try vmConfig.platform.platform(
  nvramURL: nvramURL, needsNestedVirtualization: nested)
configuration.graphicsDevices = [vmConfig.platform.graphicsDevice(vmConfig: vmConfig)]
// 원본은 오디오·입력·네트워크·디스크·공유 폴더도 구성
try configuration.validate()

전략 패턴은 “같은 작업을 다른 방식으로 수행하는 부품을 바꿔 끼우는 설계”입니다. 여기서는 OS별 분기문을 모든 장치 생성 위치에 흩뿌리는 대신, Platform 구현에 차이를 모읍니다. 최종 검증은 Apple 프레임워크의 validate()에 맡깁니다.

네트워크도 같은 발상입니다. Network 프로토콜은 attachments(), run(), stop()을 요구합니다. 기본 NetworkShared는 NAT 장치를 반환하고, NetworkBridged는 선택된 인터페이스에 연결합니다. Run.validate()는 bridged·Softnet·host·외부 FD 방식의 중복 선택을 차단합니다.

Sources/tart/GuestAgentChannel.swift의 withGuestAgentChannel()은 gRPC 채널을 열고 성공·실패 양쪽에서 닫습니다. ControlSocket.handleClient()는 그 데이터를 기본 포트 8080의 게스트 VirtIO 소켓으로 중계합니다. 이 제어 경로는 macOS 14 이상의 호스트와 실행 중인 게스트 에이전트가 필요하며, 포트 8080은 게스트 VirtIO 소켓의 포트입니다.

4-3. 패턴 ③ 동시성을 제한한 대용량 전송 파이프라인

Sources/tart/OCI/Layerizer/DiskV2.swift의 push()는 디스크를 압축 전 최대 512 MiB 단위로 자르고 각 조각을 LZ4로 압축합니다. bufferSizeBytes와 holeGranularityBytes는 각각 4 * 1024 * 1024입니다. 이 크기들은 HTTP 업로드의 --chunk-size와 다른 계층의 설정입니다.

// DiskV2.push()의 작업 수 제한 부분 발췌
for (index, data) in mappedDisk.chunks(ofCount: layerLimitBytes).enumerated() {
  if index >= concurrency {
    if let (index, pushedLayer) = try await group.next() {
      pushedLayers.append((index, pushedLayer))
    }
  }
  // 원본은 이어서 group.addTask로 압축·업로드 작업 추가
}

한도에 도달하면 group.next()로 기존 작업 하나가 끝나기를 기다린 뒤 새 작업을 추가합니다. “512 MiB 조각이 천 개니까 작업도 천 개를 한꺼번에 실행”하는 식으로 메모리 사용량을 키우지 않습니다. Push와 Clone의 기본 concurrency는 4입니다.

전송 완료 순서는 원래 디스크 순서와 다를 수 있습니다. 그래서 push()는 각 결과에 원래 index를 붙이고 마지막에 정렬합니다. pull()은 각 청크의 쓰기 오프셋을 미리 정해, 완료 순서가 달라도 제자리로 복원합니다.

비동기 전송에서는 완료 순서와 데이터 순서를 분리하고, 동시에 진행할 작업 수를 제한하는 것이 핵심입니다.

• 이미 있는 blob 재사용: 압축 결과의 digest로 Registry.blobExists()를 확인합니다.
• 일시적 네트워크 실패: URLError에 대해 maxAttempts: 5로 재시도합니다. 모든 오류를 무조건 재시도하지 않습니다.
• 중단된 pull 재개: 기존 디스크 구간의 해시가 비압축 청크 digest와 같으면 그 구간을 건너뜁니다.
• 전송 중 재연결: 받은 바이트 수인 rangeStart를 유지해 다음 요청에 사용합니다.
• 빈 공간 처리: zeroSkippingWrite()가 0으로 채워진 구간의 불필요한 쓰기를 줄입니다.

압축 blob의 digest와 복원된 데이터의 digest도 구분합니다. 전자는 전송 객체를, 후자는 압축을 풀었을 때의 내용을 식별합니다. OCI의 descriptor가 종류·digest·크기를 함께 담는다는 원칙은 공식 OCI 명세에서 이어서 볼 수 있습니다.

4-4. 패턴 ④ 임시 저장·잠금·내용 주소로 안전하게 발행하기

Clone.run()은 목적지 이름을 검사하고 임시 VM 디렉토리에 파일을 준비한 뒤, VMStorageLocal.move()로 로컬 이름 아래에 배치합니다. 잠금은 다른 프로세스의 생성·실행·정리 작업과 충돌하지 않게 하는 장치입니다.

FileLock은 flock으로 파일·디렉토리 작업을 직렬화하고, PIDLock은 fcntl 잠금으로 실행 중인 프로세스를 추적합니다. VMDirectory.state()는 실행 잠금이 있으면 running, 저장 상태 파일이 있으면 suspended, 그 외에는 stopped로 판단합니다.

기본 복제는 VMDirectory.clone(to:generateMAC:)의 파일 복사로 이루어집니다. APFS에서는 쓰기 시 복사 덕분에 물리 공간을 즉시 전부 복제하지 않을 수 있습니다. MAC 주소는 같은 주소의 로컬 VM이 있고 원본이 일시 중단 상태가 아닐 때 새로 만듭니다. Linux 가상 하드웨어의 machine identifier도 원본이 일시 중단 상태가 아닐 때 재생성합니다.

적층 디스크는 한 단계 더 나갑니다. ContentStore는 복원된 전체 파일의 SHA-256을 이름으로 사용하고, install()에서 실제 해시를 검증한 뒤 저장합니다. 공유 기준 디스크와 발행된 읽기 전용 계층은 재사용하고, VM마다 쓰기 가능한 overlay.asif를 따로 둡니다.

다만 이 적층 경로는 DiskImageStack.requireSupport()가 검사하는 canImport(DiskImageKit)과 macOS 27 조건을 만족해야 합니다. clone --stacked로 새 적층 기준을 만드는 경로는 원격 macOS 이미지만 허용합니다. 기본 APFS 복제, ASIF 파일 형식, 적층 디스크는 서로 다른 기능입니다.

관련 소스: Sources/tart/OCI/Layerizer/DiskV2.swift, Sources/tart/VMDirectory.swift, Sources/tart/ContentStore.swift, Sources/tart/DiskImageStack.swift.

5디렉토리 구조 해부

이는 주요 경로를 추린 트리입니다. Sources/tart/VMDirectory+OCI.swift처럼 이름에 +가 붙은 파일은 같은 타입의 기능을 Swift extension으로 나눈 예입니다. 경로가 다르다고 별개의 VM 모델이 생기는 것은 아닙니다.

코드 규모: 줄 수를 읽는 기준도 함께 기록합니다

커밋 95a0dac의 파일을 확장자별로 집계한 값이며 빈 줄과 주석을 포함합니다. 마지막에 개행이 없는 줄도 한 줄로 셉니다. .git 내부는 제외했습니다. 실행 타깃에서 생성 코드를 빼면 Swift 13,094줄입니다. 테스트 4,486줄은 전체 Swift의 약 23.8%이지만, 이 비율은 실행 커버리지나 품질 점수가 아닙니다.

처음 읽는 순서

1. Sources/tart/Root.swift: 사용할 수 있는 명령과 실행 경로를 확인합니다.
2. Sources/tart/Commands/Clone.swift: 입력 검증부터 저장까지 한 사용 사례를 따라갑니다.
3. Sources/tart/VMDirectory.swift, Sources/tart/VMConfig.swift: 무엇을 저장하는지 이해합니다.
4. Sources/tart/VM.swift, Sources/tart/Platform/: 저장한 값이 가상 하드웨어가 되는 지점을 봅니다.
5. Sources/tart/OCI/Layerizer/DiskV2.swift: 마지막으로 전송 최적화와 동시성을 읽습니다.

테스트를 먼저 곁들이고 싶다면 Tests/TartTests/VMDirectoryLayoutTests.swift가 좋습니다. 필요한 파일 조합을 작은 사례로 만들고, 어떤 배치가 실행 가능한지 단언하므로 모델의 규칙이 드러납니다.

6학습 포인트 (기술별)

6-1. Swift CLI: 입력도 타입으로 모델링합니다

Sources/tart/Commands/Create.swift의 @Argument, @Option, @Flag를 비교해 보세요. VM 이름은 위치 인자, 디스크 크기는 값이 있는 옵션, Linux 선택은 참·거짓 플래그입니다. 명령을 구조체로 표현하면 옵션 선언·도움말·검증·실행을 한 단위로 읽을 수 있습니다.

미니 실습: Push.validate()에서 concurrency가 0일 때와 chunkSize가 음수일 때를 찾아 입력·오류 표를 만드세요. 정상 경로를 읽기 전에 실패 입력을 정리하면 명령의 계약이 먼저 보입니다.

6-2. Codable: 오래된 설정을 계속 읽는 법

VMConfig.init(from:)는 빠진 os를 .darwin, 빠진 arch를 .arm64, 빠진 diskFormat을 raw로 읽습니다. 새 필드가 생겼어도 기존 설정 파일을 처리하려는 호환성 설계입니다. 반대로 잘못된 MAC 주소처럼 해석할 수 없는 값에는 디코딩 오류를 반환합니다.

미니 실습: “필드 누락”, “형식 오류”, “지원하지 않는 호스트”를 구분해 보세요. 어떤 입력을 기본값으로 보완하고 어떤 입력을 거절해야 하는지 근거를 붙이면, 설정 파일 설계 연습이 됩니다.

6-3. Swift 동시성: 작업 수·상태 격리·취소는 다른 문제입니다

DiskV2의 task group은 작업의 생명주기와 동시 진행 수를 다룹니다. Sources/tart/OCI/AuthenticationKeeper.swift의 actor는 인증 상태 접근을 보호합니다. Clone.run()의 withTaskCancellationHandler는 취소 시 임시 결과 정리를 시도합니다. 이 셋을 모두 “비동기라서 안전하다”로 뭉뚱그리면 설계 이유가 사라집니다.

미니 실습: 청크 A·B·C·D와 동시성 2를 놓고 B가 먼저 끝나는 일정을 종이에 그려 보세요. 작업 제출 순서, 완료 순서, manifest에 들어갈 최종 순서를 서로 다른 줄로 기록하세요.

6-4. 파일 시스템: 논리 크기와 실제 사용량을 구분합니다

VM 안에서 보이는 디스크 용량과 호스트에서 실제로 할당된 저장 공간은 다를 수 있습니다. Clone.run()은 두 크기의 차이를 계산해 공간 확보를 시도합니다. --prune-limit 기본값 100은 최대 100 GiB까지 공간 확보를 시도하도록 하는 계산 한도이며 VM 디스크 자체의 최대 크기가 아닙니다.

미니 실습: 기본 VM, 적층 로컬 VM, 적층 OCI 캐시에 대해 “파일이 존재한다”와 “지금 실행 가능하다”를 따로 표기하세요. VMDirectory.Layout의 세 경우와 isRunnable이 답의 근거입니다.

6-5. 네트워크·인증: 추상화 뒤에도 서로 다른 전제가 남습니다

IP.resolveIP()는 DHCP·ARP·agent 전략을 나눕니다. 기본 DHCP 경로는 호스트의 예약·임대 정보를 읽고, ARP 경로는 이웃 주소 정보를 이용하며, agent 경로는 게스트 에이전트가 있어야 동작합니다. 네트워크 모드를 바꾸면 IP를 알아내는 방법도 점검해야 합니다.

Sources/tart/OCI/Registry.swift의 기본 자격증명 공급자 순서는 환경변수 → Docker 설정 → Keychain입니다. HTTP 401을 받으면 WWW-Authenticate를 해석하고 인증을 거쳐 요청을 다시 시도합니다. “비밀번호를 어디서 가져오는가”와 “서버가 어떤 인증 방식을 요구하는가”가 분리되어 있습니다.

미니 실습: Run.userSpecifiedNetwork()의 findBridgedInterface()를 읽어 보세요. 커밋 95a0dac은 일치하지 않은 인터페이스 이름을 오류에 포함합니다. 같은 실패라도 입력값과 가능한 선택지를 함께 보여 주면 사용자가 문제를 해결하기 쉬워집니다.

6-6. 관측 가능성과 테스트: 정상 작동의 증거를 설계합니다

OTel.initializeTracing()은 TRACEPARENT가 있을 때만 추적을 초기화합니다. OTEL_EXPORTER_OTLP_TRACES_ENDPOINT가 있으면 해당 주소를 exporter에 사용합니다. Root.startCommandSpan()은 명령 이름과 명령행 인자를 span에 넣고, Sources/tart/VMDirectory+OCI.swift는 압축 디스크 바이트 수를 기록합니다.

테스트에서는 “통과했다”의 범위를 봐야 합니다. LayerizerTests.testDiskV2()는 1 GiB 무작위 데이터를 push/pull한 뒤 해시를 비교합니다. 하지만 레지스트리를 준비할 수 없으면 XCTSkip으로 건너뜁니다. .github/workflows/ci.yml도 VM을 부팅하는 Python 테스트는 실행하지 않는다고 명시합니다.

좋은 테스트를 읽을 때는 무엇을 검증하는지와 어떤 조건에서 실행되지 않는지를 함께 확인해야 합니다.

미니 실습: CommandBehaviorTests.testClonePreservesIncompleteDestination()를 읽고 불완전한 목적지 디렉토리라도 자동 덮어쓰면 안 되는 이유를 설명하세요. “VM으로 인식되지 않는다”와 “지워도 되는 데이터다”는 같은 뜻이 아닙니다.

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

“Linux VM 지원”은 Linux 호스트에서 tart 실행 파일을 돌린다는 뜻이 아닙니다. 이 패키지의 호스트 대상은 macOS입니다. 문서가 언급하는 Linux 호스트용 Vetu는 별도 프로젝트입니다.

기능마다 올라가는 OS 문턱

중첩 가상화는 VZGenericPlatformConfiguration.isNestedVirtualizationSupported를 검사합니다. 소스 오류 문구는 M3 이상을 안내하고, 저장소 FAQ는 M3·M4와 Linux 게스트를 명시합니다. 최종 가능 여부는 실제 호스트의 프레임워크 지원으로 판단해야 합니다.

운영 환경에서는 서명 권한과 Keychain도 요구사항의 일부입니다. Resources/tart-dev.entitlements에는 가상화 권한이, 배포용 파일에는 추가 네트워크 권한이 있습니다. 헤드리스 Mac의 Keychain 조건은 docs/faq.md의 설명을 함께 확인하세요.

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

tart clone ghcr.io/cirruslabs/macos-tahoe-base:latest study-base
tart clone study-base study-work
tart get study-work
tart set study-work --cpu 4 --memory 4096
tart run study-work

# 손으로 먼저 풀어 볼 입력 표
config + nvram + disk                    : standalone
config + nvram + manifest + overlay      : stackedLocal
config + nvram + manifest                : stackedOCIRecord
config + nvram + disk + manifest + overlay : 유효하지 않음

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

Swift를 처음 접한다면 문법을 완벽히 끝낸 뒤 읽겠다고 미루기보다, 작게 이해할 수 있는 타입부터 시작하세요. 매주 소스 한 부분을 읽고, 그 동작을 작은 표나 연습 코드로 다시 표현하면 이해를 확인할 수 있습니다.

단계별로 던질 질문

• 타입 단계: 이 값은 저장되는 설정인가, 실행 중인 객체인가?
• 호출 단계: 이 함수의 실패는 사용자가 고칠 입력 문제인가, 외부 시스템 문제인가?
• 동시성 단계: 같은 상태를 다른 작업이나 다른 프로세스가 만질 수 있는가?
• 운영 단계: 중간에 꺼져도 다시 시작할 수 있는가? 어떤 파일을 신뢰하는가?

그다음 확장은 관심에 따라 나누면 됩니다. 화면 개발이 궁금하면 VMView와 SwiftUI·AppKit 연결을, 인프라가 궁금하면 OCI 배포와 Orchard 문서를, 시스템 프로그래밍이 궁금하면 파일 잠금·희소 파일·VirtIO 소켓을 더 읽으세요. ANTLR 생성 코드는 손으로 전부 따라 읽기보다 Sources/tart/OCI/Reference/Reference.g4의 14줄 문법에서 시작하는 편이 효과적입니다.

10핵심 키워드 사전

11참고 링크

공식 저장소와 사용 문서

• openai/tart 공식 저장소 — README·이슈·릴리스의 출발점.
• tart 공식 문서 — 사용법과 통합 안내.
• 분석 커밋의 빠른 시작 문서 — 이미지 종류와 설정 예제.
• 분석 커밋의 FAQ — 네트워크·Keychain·디스크·Anka 비교.
• 릴리스 2.41.1 — 배포판 정보. HEAD 소스와 구분해서 확인.
• Orchard 아키텍처 문서 — 여러 Mac을 관리하는 상위 계층.
• 기여 안내 — 개발 참여 전 읽을 규칙.

소스 분석에 직접 연결되는 링크

• Sources/tart/Root.swift와 Sources/tart/Commands/Run.swift — 명령 실행과 메인 루프.
• Sources/tart/VM.swift와 Sources/tart/Platform/Platform.swift — 가상 하드웨어 조립.
• Sources/tart/OCI/Manifest.swift와 Sources/tart/OCI/Layerizer/DiskV2.swift — 배포 형식과 전송.
• Tests/TartTests/VMDirectoryLayoutTests.swift와 Tests/TartTests/CommandBehaviorTests.swift — 상태와 데이터 보존 규칙.
• 배포 설정와 서명·공증 스크립트 — 실행 파일 이후의 제품화.

관련 기술의 공식 자료

• Apple Virtualization 문서 — 가상머신 API의 범위.
• Apple Silicon에서 macOS VM 실행하기 — 기반 API를 직접 보는 예제.
• AsyncParsableCommand 문서 — 비동기 CLI 명령의 인터페이스.
• OCI manifest 명세와 descriptor 명세 — 목록과 내용 식별의 표준 구조.
• SwiftNIO — 제어 소켓과 스트림 처리의 기반.
• OpenTelemetry Swift — 명령과 전송의 추적.

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

커밋 시각은 한국 표준시 기준입니다. 같은 순간이 커미터의 -07:00 시간대에서는 2026-10-22로 보입니다. 날짜만 비교하기보다 시간대까지 확인해야 합니다.

소스에서 보이는 기능, 릴리스에 포함된 기능, 내 컴퓨터에서 사용할 수 있는 기능은 각각 확인해야 합니다.