macOS 27에서 hdiutil이 폐기됩니다. 대체 명령은 이미 나와 있습니다.

macOSTahoe ·
macOS 27에서 hdiutil이 폐기됩니다. 대체 명령은 이미 나와 있습니다.

Apple은 macOS 27에서 hdiutil을 폐기하고 diskutil image로 대체합니다. 이 명령어는 이미 여러분의 Mac에 들어 있으며, 지금 자주 쓰는 몇 가지 기능이 빠져 있습니다.

macOS 27 Golden Gate의 man 페이지에는 지금까지 없던 한 줄이 새로 생겼습니다:

In macOS 27.0, hdiutil is deprecated. Use diskutil image instead for all disk image operations.

hdiutil은 Mac OS X 10.0 이후 줄곧 Mac에서 디스크 이미지를 만들고, 마운트하고, 변환하고, 검사하는 방법이었습니다. .dmg를 배포해봤거나, 설치 스크립트를 작성했거나, Mac 앱을 패키징하는 CI 작업을 만들었거나, 뭔가를 비공개로 보관하려고 암호화 컨테이너를 만들어본 적이 있다면, 직접이든 여러분 대신 이를 호출하는 다른 도구를 통해서든 이 명령을 사용해본 것입니다.

여기서 대부분의 보도가 놓친 부분이 있습니다. 대체 명령은 앞으로 나올 예정이 아닙니다. 이미 여러분의 Mac에 들어 있습니다. 지금 당장 macOS 26 Tahoe에서 터미널을 열고 diskutil image를 실행해 보세요. 응답이 돌아옵니다.

핵심 요약

  • diskutil image는 macOS 26에서 이미 동작합니다. macOS 26.5.2 (빌드 25F84)에서 확인했습니다. macOS 27이 출시되기 전인 지금도 스크립트를 마이그레이션하고 테스트할 수 있습니다.
  • 폐기(deprecated)는 제거(removed)가 아닙니다. macOS 27에서도 hdiutil은 여전히 동작합니다. 첫날부터 뭔가 망가지지는 않습니다. 다만 Apple은 7년에 걸쳐 이 도구를 조금씩 정리해 왔고, man 페이지에는 그 과정이 단계별로 기록되어 있습니다.
  • 명령 체계 자체가 훨씬 단순해졌습니다. hdiutil은 23개의 동사(verb)를 제공하지만, diskutil image는 5개의 서브커맨드만 제공합니다.
  • detach가 없습니다. diskutil image로 디스크 이미지를 attach할 수는 있지만 detach할 수는 없습니다. 이 기능은 diskutil eject로 옮겨갔습니다.
  • verify, compact, makehybrid를 비롯해 아직 대체 수단이 전혀 없는 기능도 있습니다. 빌드 스크립트가 이런 기능을 쓰고 있다면, 오늘 시점에서는 마이그레이션 경로가 없는 셈입니다.

먼저: 직접 여러분의 Mac에서 확인하세요

이 글의 어떤 내용도 그냥 믿지 마세요. 명령 하나면 됩니다.

diskutil image

macOS 26.5.2에서는 다음과 같이 출력됩니다.

OVERVIEW: Manipulate disk images (attach, create, etc)

USAGE: diskutil image [--verbose] [--stdinpassphrase] [--plist] <subcommand>

SUBCOMMANDS:
  attach                  Attach a disk image as a device.
  info                    Print info regarding a disk image.
  create                  Create a disk image. Either blank or from an existing
                          source (disk, disk image or folder).
  resize                  Resize a given image to a specified size if
                          applicable.
  chpass                  Change the passphrase of a given encrypted image.

서브커맨드는 5개입니다. 이제 이것을 hdiutil이 제공하는 목록과 비교해 보겠습니다. 이 목록은 hdiutil 자체의 man 페이지에서 그대로 가져왔습니다.

Common verbs include attach, detach, verify, create, convert, and compact.

The rest of the verbs are currently: help, info, burn, checksum, chpass,
erasekeys, imageinfo, isencrypted, mountvol, unmount, plugins, udifrez,
udifderez, resize, segment, makehybrid, and pmap.

즉 23개 동사 대 5개 서브커맨드입니다. 이 비율만 보면 처음엔 당황스럽지만, 사실 이 숫자 자체는 오해를 부릅니다. 동사 대 서브커맨드를 일대일로 단순 비교하면 잘못된 결론에 도달하기 때문입니다. hdiutil의 여러 동사는 다른 이름으로 diskutil image 안에 통합되어 있고, 일부는 이미 수년 전에 폐기되었으며, 중요한 동사 하나는 완전히 다른 명령으로 옮겨갔습니다.

무엇이 어디로 갔는지 정리하는 것이 이번 마이그레이션의 실질적인 작업이므로, 하나씩 제대로 짚어보겠습니다.

이번 폐기는 갑자기 나온 결정이 아닙니다

마이그레이션 표를 보기 전에, 이번 폐기가 그렇게 급작스러운 일이 아니라는 점을 보여주는 맥락을 짚어보겠습니다. hdiutil의 man 페이지에는 Apple이 지난 7년간 이 도구를 조금씩 좁혀온 기록이 호환성 섹션에 그대로 남아 있습니다. 이 내용은 지금 여러분의 Mac에서도 확인할 수 있습니다. man hdiutil을 실행하고 버전별 항목을 찾아보세요.

macOS 10.15

  • ULMO 포맷에 lzma 압축 도입
  • OS 9 스타일의 dual-fork 파일 지원 폐기 (hdiutil flatten/unflatten)
  • 이미 폐기되어 있던 hdiutil internet-enable 명령과 IDME attach 플래그 제거

macOS 11.0

  • DiskCopy42, DART, NDIF 포맷 지원 제거
  • AppleSingle 및 MacBinary 인코딩 지원 제거
  • OS 9 스타일의 dual-fork 파일 지원 제거
  • 새 이미지의 기본 파일 시스템을 APFS로 변경

macOS 12.0

  • UDBZ 포맷(bzip2 압축) 폐기
  • 세그먼트 UDIF 이미지 폐기 (hdiutil segment, -segmentSize)
  • hdiutil udifrez/udifderez(리소스 삽입 및 추출) 폐기

macOS 13.0

  • encrypted-encoding-version 옵션 제거. 이후 새로 만드는 암호화 이미지는 모두 버전 2를 사용

man 페이지는 또한 -passphrase가 안전하지 않다는 점, 세그먼트 이미지가 폐기되었다는 점, UDBZ가 폐기되었다는 점을 본문 곳곳에서 명시하고 있습니다.

이렇게 하나의 흐름으로 읽으면, macOS 27의 폐기는 올여름에 내려진 결정이 아니라 2019년 무렵부터 시작된 과정의 마지막 단계임을 알 수 있습니다. 이 점은 계획을 세우는 데 중요합니다. Apple은 이 도구의 기능을 천천히 걷어내며 매번 man 페이지에 먼저 예고해 왔습니다. macOS 27의 hdiutil은 폐기되었을 뿐 사라진 것이 아니며, 제거 예정일도 아직 공지되지 않았습니다.

마이그레이션 표

이것이 전체 지도입니다. 아래 항목은 모두 macOS 26.5.2에서 직접 테스트했습니다.

하려는 작업hdiutildiskutil image
이미지 마운트hdiutil attach x.dmgdiskutil image attach x.dmg
이미지 언마운트hdiutil detach /dev/diskNdiskutil image에는 없음 — diskutil eject /dev/diskN 사용
빈 이미지 만들기hdiutil create -size 1g -fs APFS x.dmgdiskutil image create blank --size 1g x.dmg
폴더로부터 이미지 만들기hdiutil create -srcfolder ./dir x.dmgdiskutil image create from ./dir x.dmg
포맷 변환hdiutil convert in.dmg -format UDZO -o out.dmgdiskutil image create from in.dmg out.dmg --format UDZO
이미지 검사hdiutil imageinfo x.dmgdiskutil image info x.dmg
암호화 여부 확인hdiutil isencrypted x.dmgdiskutil image info → Is Encrypted:
크기 조정hdiutil resize -size 2g x.dmgdiskutil image resize
암호(passphrase) 변경hdiutil chpass x.dmgdiskutil image chpass x.dmg
체크섬 검증hdiutil verify x.dmg대체 수단 없음
sparse 이미지 압축hdiutil compact x.sparsebundle대체 수단 없음
하이브리드/ISO 이미지 만들기hdiutil makehybrid대체 수단 없음
라이선스 계약 삽입hdiutil udifrez대체 수단 없음 (macOS 12에서 이미 폐기됨)
광학 미디어에 굽기hdiutil burn대체 수단 없음

convert를 둘러싼 오해

초기 논평에서 가장 자주 본 착각은 "convert가 없다"는 것이었습니다. 있습니다. 다만 이름이 다를 뿐입니다.

OVERVIEW: Create a disk image from an existing source (disk, disk image or
folder).

Source and destination disk image can be the same, which will perform the
conversion in place.

diskutil image create from은 소스로 디스크 이미지 자체를 받을 수 있으므로, 사실상 hdiutil convert가 다른 이름을 쓴 것뿐입니다. 게다가 in-place 변환까지 지원하는데, 이는 hdiutil convert가 한 번도 제공한 적 없는 기능입니다. 동사 개수만 세고 도움말 텍스트를 읽지 않으면, 실제로는 기능이 확장됐는데도 기능이 빠졌다고 오판하게 됩니다.

detach 공백은 실재합니다

이건 이름만 바뀐 경우가 아닙니다. diskutil image 안 어디에도 detach는 없습니다.

$ diskutil image detach /dev/disk12
Error: 2 unexpected arguments: 'detach', '/dev/disk12'
Usage: diskutil image [--verbose] [--stdinpassphrase] [--plist] <subcommand>

대체 명령은 최상위 레벨의 diskutil 명령입니다.

$ diskutil eject /dev/disk12
Disk /dev/disk12 ejected

이 자체는 문제없이 동작하지만, 스크립트 입장에서는 무엇이 달라지는지 잘 봐야 합니다. hdiutil attach / hdiutil detach의 깔끔한 대칭 구조가 diskutil image attach / diskutil eject로 바뀌면서, 같은 바이너리 안에서도 서로 다른 서브커맨드 레벨을 오가게 됩니다. attach와 detach를 짝지어 쓰던 래퍼 함수가 있다면, 단순 찾아 바꾸기가 아니라 구조 자체를 다시 짜야 합니다.

디스크 이미지 스크립트 마이그레이션

diskutil image가 더 나은 부분

이 변화를 순수한 손해로만 그리는 건 공정하지 않습니다. 실제로 확실히 개선된 부분이 세 가지 있습니다.

hdiutil은 아예 만들 수 없는 ASIF

diskutil image는 Apple Sparse Image Format을 지원합니다. hdiutil은 이를 지원하지 않습니다. ASIF를 쓰고 싶다면 — 그리고 APFS 위의 가상 머신 디스크라면 Apple이 계속 그 방향으로 유도해 온 포맷이 바로 이것인데 — 이를 만들 수 있는 도구는 diskutil image뿐입니다.

포맷 목록은 알아둘 만한 가치가 있습니다.

create blank --format : RAW, ASIF, UDSB          (default RAW)
create from  --format : ASIF, RAW, UDRO, UDSB,
                        UDZO, ULFO, ULMO         (default ULFO)

HTTP로 attach가 되고, RAM 디스크도 바로 만듭니다

attach 도움말에서 발췌하면 다음과 같습니다.

Supports 'ram://<size>', file paths, http[s].

지금까지 Mac에서 RAM 디스크를 만드는 방법은 hdiutil attach -nomount ram://<sectors>를 실행한 뒤 newfs_hfs나 diskutil eraseVolume을 이어서 실행해야 하는, 다소 번거로운 2단계 과정이었습니다. 이제는 문서화된 플래그 하나에 인자 하나만 넘기면 됩니다.

속도가 눈에 띄게 빠릅니다

Lapcat Software의 Jeff Johnson은 2026년 8월 초 이번 폐기를 조사하면서 두 도구를 벤치마크했고, diskutil image가 create 작업을 4045초 만에 끝내는 반면 hdiutil은 110115초가 걸렸으며, 그 과정에서 이미지 크기도 더 작게 나온다는 것을 측정했습니다. 오차 범위 수준의 차이가 아닙니다. 커밋마다 디스크 이미지를 빌드하는 CI 작업이라면 이는 실질적인 차이입니다.

실제로 여러분의 스크립트가 망가지는 지점

폐기 경고 자체는 빌드를 망가뜨리지 않습니다. 아래 항목들이 망가뜨립니다.

1. -puppetstrings에는 대체 수단이 없습니다

hdiutil의 -puppetstrings 플래그는 기계가 파싱하기 좋은 진행 상황 출력을 내보내는데, 이는 빌드 시스템이 정확히 원하는 형태입니다. Johnson은 이 기능이 사라진 점을 눈에 띄는 공백 중 하나로 지적합니다. diskutil image에는 구조화된 결과를 위한 --plist가 있지만, 진행 상황은 다음처럼 사람이 읽는 형태로만 출력됩니다.

[5% completed] [79% completed] [98% completed] [100% completed]
test.dmg created

hdiutil의 PERCENT: 라인을 파싱하는 도구를 갖고 있다면, 그 파서는 이제 붙잡을 대상이 없습니다.

2. create의 여러 옵션이 그냥 사라졌습니다

Johnson의 글에는 -[no]crossdev, -[no]scrub, -[no]anyowners, -skipunreadable, -[no]atomic, -copyuid가 대응 옵션 없이 사라진 항목으로 정리되어 있습니다. 폴더로부터 이미지를 만들되 소유권이나 포함되는 파일을 정확히 통제해야 하는 경우 — 설치 프로그램, 포렌식 캡처 등 — 이 목록을 꼼꼼히 봐야 합니다. 특히 -skipunreadable과 -copyuid는 일부 패키징 스크립트에서 핵심적인 역할을 합니다.

3. 스크러빙 동작이 조용히 바뀌었습니다

Johnson에 따르면 diskutil image는 휴지통 폴더 같은 임시 파일을 자동으로 제외하는데, 이는 마치 -scrub이 항상 켜져 있는 것처럼 동작합니다. hdiutil은 명시적으로 요청했을 때만 스크러빙을 수행했습니다. 이미지 내용이 원본 디렉터리와 바이트 단위로 동일해야 한다면, 아무런 알림도 없이 다른 결과물이 만들어질 수 있습니다.

4. 권한 처리가 조용히 실패합니다

이 부분은 제가 가장 먼저 테스트해보라고 권하고 싶은 항목입니다. Johnson은 hdiutil이 root 소유 파일을 만났을 때 인증 프롬프트를 띄우는 반면, diskutil image는 프롬프트 없이 그냥 실패한다는 것을 확인했습니다. 예전에는 자격 증명 입력을 기다리며 멈췄던 스크립트가 이제는 불완전한 이미지를 만들어내고, 오류 처리 방식에 따라서는 성공했다고 보고할 수도 있습니다.

내 소유가 아닌 파일이 포함된 디렉터리로부터 이미지를 만든다면, 종료 코드를 믿기보다 결과물을 직접 검증하세요.

5. 로그가 더 빈약합니다

diskutil image의 verbose 출력은 hdiutil만큼 상세하지 않습니다. 새벽 3시에 빌드가 실패했을 때 이 차이를 실감하게 됩니다.

macOS 26 지원을 깨뜨리지 않고 마이그레이션하는 법

대부분은 한동안 두 버전을 동시에 지원해야 합니다. 다행히도, 그리고 이 글 전체에서 가장 실용적인 포인트인데, OS 버전으로 분기할 필요가 없습니다. diskutil image는 macOS 26에도 이미 존재하기 때문입니다.

버전이 아니라 기능 유무로 감지하세요.

#!/bin/bash
# Prefer diskutil image; fall back to hdiutil where unavailable.

if diskutil image --help >/dev/null 2>&1; then
  USE_DISKUTIL=1
else
  USE_DISKUTIL=0
fi

make_image_from_folder() {
  local src="$1" dst="$2"
  if [ "$USE_DISKUTIL" -eq 1 ]; then
    diskutil image create from "$src" "$dst" --format UDZO
  else
    hdiutil create -srcfolder "$src" -format UDZO "$dst"
  fi
}

attach_image() {
  local img="$1"
  if [ "$USE_DISKUTIL" -eq 1 ]; then
    diskutil image attach "$img" --nobrowse
  else
    hdiutil attach "$img" -nobrowse
  fi
}

detach_device() {
  # Note the asymmetry: detach is NOT under `diskutil image`.
  local dev="$1"
  if [ "$USE_DISKUTIL" -eq 1 ]; then
    diskutil eject "$dev"
  else
    hdiutil detach "$dev"
  fi
}

그런 다음 결과물을 검증하세요. 조용히 달라지는 부분이 바로 여기에 숨어 있기 때문입니다.

# Compare what actually landed in the image against the source.
diskutil image attach build.dmg --nobrowse --mountPoint /tmp/verify_mnt
diff -rq ./src /tmp/verify_mnt/src
diskutil eject /tmp/verify_mnt

이 diff -rq 단계는 생략하지 말라고 권하고 싶습니다. 항상 켜져 있는 스크러빙과 조용히 실패하는 권한 처리 사이에서, 빌드가 성공적으로 끝났다는 것과 이미지가 의도한 내용을 담고 있다는 것은 전혀 다른 이야기이기 때문입니다.

Mac 개발 환경을 처음부터 구축하는 중이라면, 저희 Apple silicon 개발 환경 설정 가이드에서 주변 도구들을 다루고 있고, 터미널 마스터하기 가이드에서는 이 스크립트들이 전제하는 셸 기초를 다루고 있습니다.

디스크 이미지 내용 검증하기

처음부터 끝까지, 실제 예제

macOS 26.5.2에서 실제로 실행한 전체 과정을 보여드리겠습니다. 재구성이 아니라 실제 출력 그대로입니다.

폴더로부터 이미지 만들기:

$ mkdir -p src && echo "hello" > src/file.txt
$ diskutil image create from src --format UDZO test.dmg
[5% completed] [79% completed] [98% completed] [99% completed] [100% completed]
test.dmg created

검사하기:

$ diskutil image info test.dmg
Image Format: UDZO
Format Description: UDIF read-only compressed image (zlib)

	Identity Info:
		UUID: 061189CB-7502-4EA6-BFE3-424442C16D10

	Size Info:
		Empty Bytes: 3437056
		Total Bytes: 4233216

	Compression Info:
		Compressed Bytes: 4124
		Compression Type: zlib

	Encryption Info:
		Is Encrypted: 0

	Master Checksum Info:
		Checksum Type: crc32
		Checksum Value: c4 e3 90 4b

info 하나가 예전에 hdiutil imageinfo, isencrypted, 그리고 checksum의 일부가 각각 따로 알려주던 정보를 모두 담고 있다는 점에 주목하세요. 다만 여기서 보여주는 것은 저장된 체크섬 값이지, 그 값을 검증해주는 것은 아닙니다. 이것이 바로 hdiutil verify가 남긴 공백입니다.

attach하기:

$ diskutil image attach test.dmg
/dev/disk12  	GUID_partition_scheme
/dev/disk13s1	Apple_APFS_Volume    	/Volumes/src

detach하기 — 다른 명령을 써서:

$ diskutil eject /dev/disk12
Disk /dev/disk12 ejected

암호화된 이미지

디스크 이미지를 암호화 컨테이너로 사용한다면, 동작 방식 자체는 단순하지만 선택할 수 있는 옵션은 더 좁아졌습니다.

# Create an encrypted blank image
diskutil image create blank --encrypt --size 10g --volumeName Vault vault.dmg

# Provide the passphrase on stdin rather than interactively
printf '%s' "$PASSPHRASE" | diskutil image create blank --encrypt --stdinpassphrase \
  --size 10g --volumeName Vault vault.dmg

# Change the passphrase later
diskutil image chpass vault.dmg

--encrypt는 AES-256으로 문서화되어 있으며 알고리즘을 선택할 여지는 없습니다. 이는 기능이 줄어든 게 아니라 단순해진 것입니다. Apple은 이미 macOS 13에서 예전의 암호화 인코딩 버전을 제거했기 때문입니다.

스크립트에서 써야 할 것은 --stdinpassphrase 플래그입니다. hdiutil 자체의 man 페이지도 -passphrase가 안전하지 않다고 경고하고 있는데, 이유는 단순합니다. 명령줄에 적힌 암호는 그 머신의 모든 사용자에게 프로세스 목록을 통해 그대로 노출되기 때문입니다.

편의보다 프라이버시 목적으로 디스크 이미지를 쓰고 있다면, 암호화된 이미지가 FileVault와 비교해 어떤 위치에 있는지 저희 Mac 보안 및 프라이버시 가이드에서 읽어볼 만합니다. 둘은 서로 다른 문제를 해결하며, 암호화된 .dmg도 마운트되어 있는 동안에는 아무것도 보호하지 못합니다.

디스크 이미지는 여전히 무엇에 쓰이나

이 모든 것이 왜 중요한지 물어볼 가치가 있습니다. "디스크 이미지"라는 말은 유물처럼 들리지만, 그 주변 도구들은 여러 곳에서 조용히 중요한 역할을 하고 있기 때문입니다.

애플리케이션 배포. .dmg는 App Store 밖에서 Mac 앱을 배포하는 표준적인 방법으로 남아 있습니다. 앱 번들과 /Applications로의 심볼릭 링크를 담은, 압축된 읽기 전용 이미지는 사용자에게 익숙한 '드래그해서 설치' 방식입니다. 그 하나하나가 디스크 이미지 도구를 호출하는 스크립트로 만들어집니다.

암호화 컨테이너. 암호화된 .dmg는 볼륨으로 마운트되며 별도 소프트웨어 없이 어떤 Mac에서도 동작하는, 이동 가능한 독립형 금고입니다. 디스크 전체를 저장 상태에서 보호하는 FileVault와 달리, 암호화된 이미지는 특정 파일 묶음을 보호하며 USB 드라이브, 클라우드 스토리지, 동료에게로 자유롭게 옮길 수 있습니다.

가상 머신 디스크. ASIF가 중요해지는 지점이며, Apple의 방향성이 가장 명확하게 드러나는 지점입니다.

네트워크 백업용 sparsebundle. Time Machine이 네트워크 대상으로 백업할 때는 백업 내용을 sparsebundle 안에 저장합니다. 디스크 이미지를 작은 band 파일 여러 개로 나눠서, 변경된 band만 동기화하면 되도록 만든 형태입니다. 이런 이미지를 관리해본 사람이라면 삭제된 band가 차지한 공간을 회수하기 위해 hdiutil compact를 실행해본 적이 있을 것입니다.

포렌식과 아카이빙. 체크섬이 포함된 볼륨의 블록 수준 이미지는 디스크의 정확한 상태를 보존하는 방법입니다. 이후 그 상태를 확인하는 방법이 바로 hdiutil verify입니다.

이 목록을 마이그레이션 표와 겹쳐보면, 빠진 기능들이 무작위가 아니라 특정 사용자 집단과 정확히 맞아떨어진다는 걸 알 수 있습니다. 앱 개발자는 라이선스 계약 삽입 메커니즘과 -puppetstrings를 잃습니다. 백업과 sparsebundle 사용자는 compact를 잃습니다. 아카이빙과 포렌식 사용자는 verify를 잃습니다. create-convert-attach라는 일상적인 작업만 하는 사람들은 아무 문제가 없습니다.

ASIF: 새 도구만 만들 수 있는 포맷

Apple Sparse Image Format은 Apple이 왜 사람들을 hdiutil에서 떠나보내고 싶어하는지 가장 명확하게 보여주는 신호입니다. hdiutil은 애초에 이 포맷을 전혀 만들 수 없기 때문입니다.

sparse 이미지는 실제로 데이터가 들어 있는 블록에 대해서만 디스크 공간을 차지합니다. 파일 10GB를 담은 100GB짜리 sparse 이미지는 디스크에서 대략 10GB만 차지하고, 데이터를 추가할수록 커집니다. 기존의 UDSP sparse 이미지와 UDSB sparsebundle 포맷도 같은 일을 했지만 알려진 문제가 있었습니다. sparsebundle은 수천 개의 band 파일로 조각나기 쉬웠고, 두 포맷 모두 역사적으로 공간 회수 성능이 좋지 않았습니다. hdiutil compact가 존재해야 했던 이유가 바로 그것입니다.

ASIF는 APFS 위에 덧붙인 형태가 아니라 APFS를 염두에 두고 설계되었기 때문에, 이미지 포맷이 sparse 동작을 흉내내는 대신 파일시스템 자체의 sparse 파일 지원이 그 일을 대신하게 됩니다. 실제로 이 효과가 가장 잘 드러나는 곳은 가상화입니다. VM의 가상 디스크는 대부분 비어 있으면서 끊임없이 변하는 큰 파일인데, 이것이 바로 기존 포맷들을 가장 힘들게 했던 경우입니다.

지금 바로 하나 만들어볼 수 있습니다.

# A 100GB ASIF image that occupies only what it uses
diskutil image create blank --format ASIF --size 100g \
  --volumeName VMDisk vmdisk.asif

# Convert an existing image to ASIF
diskutil image create from old.dmg new.asif --format ASIF

포맷은 확장자로부터 추론된다는 점에 유의하세요. create blank는 "이미지 경로가 .asif나 .sparsebundle 확장자를 갖고 있지 않은 한" 기본값으로 RAW를 사용합니다. 파일 이름만 올바르게 지어도 충분하지만, --format을 함께 지정해두면 이중으로 안전합니다.

트레이드오프는 이식성입니다. ASIF는 새로운 포맷이라, 더 오래된 macOS나 Mac이 아닌 다른 환경에서는 열리지 않습니다. VM 디스크나 로컬 작업 볼륨이라면 이는 무관한 문제입니다. 다른 사람에게 전달할 무언가라면 UDZO를 쓰고 호환성을 유지하세요.

배포 파이프라인에서 이 변화가 놓이는 자리

App Store 밖에서 Mac 앱을 배포한다면, 디스크 이미지 단계는 하나의 체인 중간에 위치합니다. 이번 변화가 그중 어디에 해당하는지 살펴볼 가치가 있습니다.

#!/bin/bash
set -euo pipefail

APP="build/MyApp.app"
DMG="dist/MyApp.dmg"
STAGE="$(mktemp -d)"

# 1. Sign the app bundle (unchanged by any of this)
codesign --force --options runtime --timestamp \
  --sign "Developer ID Application: Example Inc (TEAMID123)" \
  "$APP"

# 2. Stage the contents the user will see
cp -R "$APP" "$STAGE/"
ln -s /Applications "$STAGE/Applications"

# 3. Build the image — the step this article is about
diskutil image create from "$STAGE" "$DMG" --format UDZO

# 4. Sign the image itself
codesign --force --timestamp \
  --sign "Developer ID Application: Example Inc (TEAMID123)" \
  "$DMG"

# 5. Notarize and staple
xcrun notarytool submit "$DMG" --keychain-profile "AC_NOTARY" --wait
xcrun stapler staple "$DMG"

rm -rf "$STAGE"

바뀌는 것은 3단계뿐입니다. 서명, 공증(notarization), 스테이플링(stapling)은 영향을 받지 않습니다. 이들은 완성된 이미지를 대상으로 동작할 뿐, 그 이미지를 어떤 도구가 만들었는지는 신경 쓰지 않기 때문입니다.

실제 파이프라인에서 눈여겨봐야 할 것이 두 가지 있습니다. 첫째, 앞서 설명한 조용한 스크러빙과 권한 처리 동작 때문에 스테이징된 내용이 제대로 들어갔는지 확인해야 합니다. $STAGE와 마운트된 결과물 사이의 diff -rq는 비용 대비 확실한 안전장치입니다. 둘째, 현재 스크립트가 hdiutil udifrez로 라이선스 계약을 삽입하고 있다면, 이 단계는 대체 수단이 없고 macOS 12부터 이미 폐기된 상태입니다. 이 기능이 존재하는 동안은 이 단계에 한해 hdiutil을 계속 쓰면서 대안을 계획하세요.

흔한 문제 해결하기

"diskutil image: command not found" 또는 서브커맨드를 인식하지 못함

문제: image 동사가 존재하지 않는, macOS 26보다 이전 버전을 쓰고 있는 경우입니다.

해결책: 짐작하지 말고 위에서 보여준 기능 확인 방식을 사용하세요. diskutil image --help >/dev/null 2>&1은 해당 기능이 없는 시스템에서 0이 아닌 값을 반환하며, 이는 신뢰할 수 있는 분기 조건입니다. sw_vers로 테스트하지 마세요. 여러분이 실제로 신경 써야 할 것은 서브커맨드의 존재 여부입니다.

이미지는 만들어지지만 파일이 빠져 있음

문제: 가능성 있는 원인은 두 가지입니다. diskutil image가 여러분의 사용자 권한으로 읽을 수 없는 파일을 인증 프롬프트 없이 건너뛰었거나, 항상 켜져 있는 스크러빙이 hdiutil이라면 포함시켰을 항목을 제거한 경우입니다.

해결책: 결과물을 마운트한 뒤 소스 디렉터리와 diff -rq로 비교하세요. 소유권 문제로 파일이 빠졌다면, 프롬프트가 뜨기를 기대하기보다 필요한 권한을 갖고 빌드를 실행하세요. 종료 코드만 믿지 마세요.

CI에서 진행 상황 파싱이 깨짐

문제: -puppetstrings에 대응하는 diskutil image 기능이 없어서, hdiutil의 기계 판독용 진행 상황을 파싱하던 스크립트가 읽을 대상을 잃습니다.

해결책: 구조화된 결과에는 --plist를 사용하고, 진행 상황은 이제 얻을 수 없다고 가정하세요. CI에서 특히 진행 상황이 꼭 필요하다면, 그 단계에 한해 hdiutil을 계속 쓰는 것도 정당한 선택입니다. 이 명령은 폐기되었을 뿐 제거되지 않았고, 제거 예정일도 공지되지 않았습니다.

detach가 안 됨 — "resource busy"

문제: 뭔가가 여전히 해당 볼륨을 열어두고 있습니다. 이 동작 방식 자체는 예전과 똑같습니다.

해결책: lsof +D /Volumes/YourVolume로 점유 주체를 찾은 뒤 diskutil eject를 실행하세요. Spotlight 인덱싱과 백신 스캐너가 자주 원인이 됩니다. --nobrowse로 마운트하면 Finder에 볼륨을 노출시키지 않아 이런 문제를 어느 정도 피할 수 있습니다.

라이선스 계약이 포함된 .dmg가 더 이상 빌드되지 않음

문제: 라이선스 계약 메커니즘은 hdiutil udifrez에 의존하는데, Apple은 이미 macOS 12에서 이를 폐기했고 diskutil image에는 대응하는 기능이 없습니다.

해결책: 대체 경로가 없습니다. 이 기능이 존재하는 동안은 해당 단계에 한해 hdiutil을 계속 사용하고, 삽입된 계약에 의존하지 않는 배포 방식을 계획하세요. 이 사실은 이미 4년째 예고되어 있었으므로, 지금에서야 이 사실을 알게 됐다면 참고할 만합니다.

자주 묻는 질문

macOS 27에서도 hdiutil이 계속 동작하나요?

네. 폐기되었을 뿐 제거되지 않았습니다. 폐기는 Apple이 의도를 알리고 시계를 돌리기 시작한 것이지, 기능상의 변화가 아닙니다. 오늘 동작하는 것은 macOS 27을 설치해도 그대로 동작합니다.

hdiutil은 실제로 언제 제거되나요?

Apple은 밝히지 않았습니다. man 페이지 자체의 이력을 보면, Apple이 이 도구에서 보여온 패턴은 어떤 릴리스에서 기능을 폐기한 뒤 하나 이상의 메이저 버전이 지나서야 제거하는 방식입니다. internet-enable과 OS 9 dual-fork 지원 모두 최소 한 사이클 전체가 걸렸습니다. 구체적인 제거 버전을 제시하는 사람이 있다면 그것은 추측일 뿐입니다.

macOS 26 Tahoe에서 diskutil image를 쓸 수 있나요?

네, 이 글에서 가장 쓸모 있는 사실이 바로 이것입니다. macOS 26.5.2 (빌드 25F84)에서 확인했습니다. macOS 27을 기다릴 필요 없이, 지금 쓰고 있는 OS에서 바로 스크립트를 마이그레이션하고 테스트할 수 있습니다.

diskutil image가 hdiutil을 완전히 대체하나요?

아직은 아닙니다. verify, compact, makehybrid, burn은 대응 기능이 없고, 어떤 파일을 정확히 포함시킬지 제어하는 create의 여러 옵션도 빠져 있습니다. create, convert, attach, inspect, resize, encrypt처럼 흔히 쓰는 경로에 대해서는 완전합니다.

Apple은 왜 이런 결정을 했나요?

Apple은 이유를 공개하지 않았습니다. 관찰할 수 있는 사실은, diskutil image가 벤치마크에서 더 빠르고, 더 작은 이미지를 만들며, hdiutil이 만들 수 없는 새로운 ASIF 포맷을 지원하고, 명령 체계가 훨씬 단순하다는 점입니다. 디스크 이미지 처리를 다른 스토리지 관리 기능들과 함께 diskutil로 통합하는 것은 일관된 방향입니다. 이는 증거를 바탕으로 한 해석이며, Apple의 공식 입장은 아닙니다.

hdiutil을 셸에서 호출하는 제 앱이 망가지나요?

macOS 27에서는 아닙니다. 그래도 미리 옮겨갈 계획을 세워두세요. 그리고 기능 확인 방식을 사용하면 하나의 코드 경로로 두 상황 모두를 커버할 수 있는데, 이는 생각보다 훨씬 간단합니다. 새 명령이 macOS 26에 이미 존재하기 때문입니다.

결론

"25년 된 터미널 명령이 은퇴한다"는 헤드라인은 사실이지만 두 방향 모두에서 오해를 부릅니다. 빌드 스크립트에서 verify, compact, makehybrid, 또는 세밀한 create 옵션을 쓰는 사람에게는 이 변화를 과소평가하게 만듭니다. 오늘 시점에서는 그런 기능들에 앞으로 나아갈 경로가 없기 때문입니다. 반대로 그 외 모든 사람에게는 이 변화를 과대평가하게 만듭니다. hdiutil은 macOS 27에서도 여전히 동작하고, Apple은 제거 예정일을 공지하지 않았으며, 이번 폐기는 macOS 10.15부터 도구 자체의 man 페이지에 기록되어온 축소 과정의 마지막 단계일 뿐이기 때문입니다.

정말로 알아둘 만한 사실은, 대체 명령이 미래의 일이 아니라는 것입니다. diskutil image는 지금 당장 여러분의 Mac, 즉 macOS 26에 들어 있고, create, attach, info, resize, chpass가 모두 동작합니다. 지금 갖고 있는 OS에서 어느 화요일 오후에 이 마이그레이션을 끝내고, diff -rq로 검증한 뒤, 더는 신경 쓰지 않아도 됩니다.

다만 detach가 여러분이 예상한 자리에 있지 않다는 것만 기억해 두세요.

관련 읽을거리: macOS 터미널 마스터하기, Apple silicon 개발 환경 설정, 그리고 macOS 28에서 암호화된 HFS+ 볼륨이 폐지됩니다.