macOS 27에서 Time Capsule 백업을 SMB로 옮긴 기록

4세대 AirPort Time Capsule을 같은 네트워크의 Mac들이 Time Machine 자동 백업 대상으로 쓰고 있었어요. macOS 27.0으로 올린 뒤 이 백업이 되지 않았어요. Apple의 지원 문서는 AFP 기반의 Time Capsule 백업을 macOS 27 이상에서 지원하지 않는다고 밝혀요. 이 문서의 게시일은 2026년 10월 4일에 다시 확인했을 때 2026년 9월 14일이었어요.

기기를 버리지 않고 쓰는 방법으로 TimeCapsuleSMB를 골랐어요. 기기 안에서 Samba 4를 실행해서 SMB3로 백업하게 해 주는 비공식 도구예요. 2026년 9월 14일에 macOS 27의 Mac mini에서 첫 Time Machine 백업이 끝나는 것까지 확인했어요. 아래에는 직접 실행한 것과 문서로만 읽은 것을 구분해서 적었어요.

없어진 것은 AFP 클라이언트예요

Time Capsule의 순정 서버는 AFP와 SMB1을 제공해요. TimeCapsuleSMB의 README와 The Eclectic Light Company의 글이 이렇게 설명해요. macOS 27.0에서는 AFP 클라이언트가 빠졌고, mount_smbfs는 남아 있어요.

예고는 있었어요. macOS Sequoia 15.5의 기업용 릴리스 노트가 앞으로 AFP 클라이언트를 없앤다고 알렸어요. 지원 문서는 AFP NAS로의 백업을 권장하지 않고 macOS 27 이상에서 지원하지 않는다고 적었으며, AirPort Extreme과 Time Capsule에도 같은 조건을 적용했어요. 그 전의 macOS Sequoia 15 릴리스 노트에는 Time Capsule이나 AFP 서버에 새 암호화 백업을 만들지 못하던 문제를 고쳤다는 기록이 있어요.

원인을 TLS 1.2로 설명한 MacRumors의 기사도 있는데, 이것은 다른 이야기예요. macOS 27 Golden Gate 릴리스 노트의 최소 TLS 요건이 적용되는 범위는 기기 관리, 자동 기기 등록, 구성 프로파일과 앱 설치, 소프트웨어 업데이트와 관련된 일부 프로세스이고, Time Machine은 들어 있지 않아요. 같은 릴리스 노트에 AFP 제거 항목도 없어요. 그래서 AFP가 빠졌다는 판단은 지원 문서와 macOS 27.0에 파일이 없다는 사실에 근거했어요.

macOS 27.0에서 AFP 마운트를 시도한 결과예요. 존재하지 않는 주소를 썼고, 디렉터리 경로만 <dir>로 바꿨어요.

$ mount -t afp //example.invalid/share <dir>
mount: exec /Library/Filesystems/afp.fs/Contents/Resources/mount_afp for <dir>: No such file or directory
mount: <dir> failed with 72

이름을 해석하기도 전에 헬퍼 파일이 없어서 끝나요. /sbin/mount_afp가 없고, /System/Library/Filesystems에 AFP 번들이 없고, 네트워크 파일시스템 플러그인에도 AFP 항목이 없어요. 반면 man tmutil의 setdestination 설명에는 AFP와 SMB 공유라는 문구가 남아 있어요. 매뉴얼의 문구는 AFP가 동작한다는 증거가 되지 않아요.

AirPort Utility도 달라졌어요. macOS 27을 새로 설치하면 들어 있지 않고, 업그레이드한 경우에는 기존 앱이 남을 수 있지만 27 이후의 동작은 보장되지 않아요. 제 Mac은 macOS 26.6.2에서 업데이트했고 AirPort Utility 6.3.9가 남아 있었어요.

고를 수 있는 길

Apple이 제시하는 대체 저장소는 외장 저장장치, Time Machine을 지원하는 NAS, 다른 Mac의 공유 폴더예요.

직접 연결하는 외장 저장장치: Apple이 흔하게 드는 구성이에요. 네트워크가 끊겨도 상관없지만, 노트북은 꽂아 둔 동안에만 백업이 돌아요.
SMB를 지원하는 NAS: Mac 여러 대를 한곳에 받을 수 있어요. 장비 값이 들어요.
다른 Mac의 공유 폴더: 집에 있는 Mac을 그대로 써요. Apple의 권장 조건은 두 Mac 모두 macOS 11 이상이에요.
macOS 26에 남기: AFP는 한동안 그대로 쓸 수 있어요. 보안 업데이트가 끊기면 유지하기 어려워요.
TimeCapsuleSMB: 쓰던 기기를 살리고, 예전 백업을 넘겨받을 여지도 있어요. 비공식 도구가 기기에서 root로 도는 것은 감수해야 해요.

저는 마지막 길을 골랐어요. 기본 설정으로 설치한 뒤에 바이너리와 이슈를 조사했고, 그 결과에 따라 설정을 바꿔 다시 배포했어요. 아래의 보안 절은 설치한 뒤에 알게 된 내용이지만, 설치하기 전에 읽어야 할 내용이라서 앞에 뒀어요.

SMB로 Time Machine을 받으려면

Time Machine이 SMB 공유를 백업 대상으로 쓰려면 서버가 Apple 전용 기능을 지원해야 해요. Samba에서는 vfs_fruit 모듈이 이 일을 맡아요.

Samba의 공개 테스트 설정에 있는 공유 정의예요. 설치하면서 직접 편집하는 파일이 아니고, 어떤 옵션이 필요한지 보여 주는 발췌예요.

[vfs_fruit_timemachine]
	vfs objects = fruit streams_xattr acl_xattr xattr_tdb
	fruit:time machine = yes

fruit:time machine = yes가 켜진 공유는 Bonjour의 _adisk._tcp로 광고돼요. 광고를 등록하는 부분은 Samba의 Avahi 등록 구현에 있어요. vfs_fruit는 SMB2의 AAPL 확장을 협상해서 Finder의 메타데이터를 처리해요. 이 확장은 SMB2 이상이 필요하므로 순정 서버의 SMB1로는 조건을 채울 수 없어요.

TimeCapsuleSMB가 기기에서 하는 일

제가 설치한 v2.2.9는 Samba 4.24.3을 실행하고 SMB3로 접속을 받아요. 별도의 mDNS 헬퍼가 _smb._tcp와 _adisk._tcp를 광고해요. 기본 설정에서는 SMB2와 SMB3만 허용하고, Allow Any SMB Protocol을 켜면 이 제한이 풀려요.

설치물은 저장 영역 두 군데로 갈라져요. /mnt/Flash는 용량이 작지만 재부팅해도 남는 영역이라서 부팅 스크립트와 설정, 크기가 작은 mDNS 헬퍼를 여기에 둬요. 덩치가 큰 Samba 본체의 자리는 하드디스크 안의 .samba4예요. 기기가 켜질 때마다 본체를 램디스크인 /mnt/Memory로 옮겨서 거기서 돌려요. Apple 펌웨어가 한가한 하드디스크를 꺼 버리는 탓에 디스크 위에서 바로 실행하지 못하기 때문이에요.

설치할 때에는 앱이 먼저 기기의 SSH를 켜고, 그 통로로 파일을 보내요. 원래 디스크에 들어 있던 데이터는 건드리지 않아요. 제거 기능은 하드디스크 쪽 설치물과 /mnt/Flash에 있는 로더를 없애요. 설치 파일 삭제와 부트 훅 복원은 서로 다른 작업이라는 점은 알아 둬야 해요. 펌웨어를 순정으로 되돌리는 명령은 flash --restore예요.

바이너리는 세대에 따라 달라요. 5세대는 NetBSD 6이고 1~4세대는 NetBSD 4예요. 제 4세대 기기에는 NetBSD 4.0 little-endian용이 설치됐어요.

설치하기 전에 알아야 할 보안 조건

가장 먼저 알아야 할 것은 heartbeat예요. v2.2.9의 nbns-advertiser에는 heartbeat 기능이 들어 있어요. HTTP로 heartbeat4le와 서명 파일을 받아서 검증한 뒤 실행해요. 바이너리의 문자열에서 찾은 주소는 http://timecapsulesmb.jamesyc.com/downloads/bin/heartbeat4le예요. 이 기능의 소스는 v2.2.9 태그에 없어요.

이슈 299는 이 기능이 12시간 간격으로 root 권한으로 실행되고 기기 정보를 전송한다고 보고해요. 관리자는 이것이 텔레메트리이고 설정으로 끌 수 있으며 v3.0.0에서 구조를 바꿨다고 답했어요. 제가 설치한 2026년 9월 14일에는 v3.0.0이 나오지 않았어요. 릴리스 목록을 2026년 10월 4일에 다시 보니 v3.0.0은 9월 15일(UTC)에 게시됐고, 가장 최근 릴리스는 v3.2.0이에요. v3 계열은 설치해 보지 않았으므로, 이 글의 설치와 텔레메트리 내용은 v2.2.9 기준이에요. 서명 검증은 아무 파일이나 실행되는 것을 막아 주지만, 무엇이 실행되는지는 관리자의 서버와 서명 키에 달려 있어요.

텔레메트리 설정이 닿는 범위도 확인했어요. 앱과 CLI는 Mac의 .bootstrap에 TELEMETRY=false를 적고, 이것은 Mac에서 보내는 사용 이벤트를 멈춰요. 그런데 v2.2.9의 배포 코드와 바이너리 문자열을 보면 이 값이 기기의 설정으로 전달되지 않아요. 이슈 299에서 말한 설정이 어느 항목인지는 분명하지 않아요.

기기의 heartbeat를 멈추는 방법은 NBNS를 끄는 것이에요. nbns-advertiser는 항상 하드디스크의 .samba4에 놓이지만, NBNS_ENABLED=1일 때에만 램디스크로 복사돼서 실행돼요. 앱에서는 Enable NBNS를 끄고 Install/Update를 다시 실행하면 NBNS_ENABLED=0으로 배포돼요. CLI에서는 deploy --no-nbns예요. 이 판단의 근거는 부팅 코드와 바이너리의 문자열이에요. 네트워크 요청이 실제로 사라졌는지 패킷으로 검증하지는 않았어요.

NBNS를 끄면 NetBIOS 이름 응답이 멈춰서 Windows의 탐색에서 빠질 수 있어요. Mac은 Bonjour로 찾으므로 NBNS가 꼭 필요하지는 않고, 제 기기도 다시 배포한 뒤에 정상이었어요.

나머지 조건은 이래요.

Bind SMB to LAN Only는 기본값이 꺼짐이에요. 꺼져 있으면 WAN을 포함한 모든 인터페이스에 바인딩될 수 있고, 켜면 LAN으로 한정돼요. 기기가 공유기를 겸한다면 켜는 것이 안전해요.
SMB 인증은 사용자 이름을 가리지 않고 Time Capsule의 기기 비밀번호를 써요. 게스트는 막혀 있고, 인증된 사용자는 root로 매핑돼요.
README는 LAN에서만 쓰고 인터넷으로 포트를 열지 말라고 해요. FAQ는 가정의 네트워크에서는 쓸 수 있다고 하면서, 보안에 민감한 환경에서는 쓰지 말라고 해요.
앱을 처음 열 때 Gatekeeper 경고를 직접 허용해야 해요. 이슈 284에는 외부 공유 링크로 공개되지 않은 빌드를 제공한 사례가 있어요. 공식 릴리스에서 받는 것이 좋아요.

앱으로 설치한 순서

저는 CLI가 아니라 앱으로 설치했어요. 순서는 이래요.

앱은 GitHub 릴리스에서 내려받아요. 압축을 풀어 열면 Gatekeeper가 막는데, 직접 허용해야 실행돼요.
앱에 로컬 네트워크 권한을 줘요. 위치는 시스템 설정의 «개인정보 보호 및 보안»이고, 권한을 준 다음 앱을 껐다가 다시 열어요.
Add Device에서 기기를 고르고 기기 비밀번호를 입력해 Save Device로 저장해요. 그러면 앱이 SSH를 켜는데, 끝나기를 기다려요.
설정 세 가지를 바꿔요. Mac 텔레메트리는 끔, Enable NBNS는 끔, Bind SMB to LAN Only는 켬이에요.
Install/Update를 눌러요. NBNS와 LAN 설정은 이 단계에서 기기에 들어가요.
1~4세대라면 부트 훅을 써요.
Checkup은 5~10분 지난 뒤에 돌려요.

4세대 기기에서 배포는 약 6분 걸렸어요. 기기가 다시 부팅되고 런타임이 활성화되는 검증이 성공했고, Checkup은 실패 0건, 경고 0건이었어요.

README는 실패했을 때의 대응도 적어 뒀어요. SSH 단계에서 막히면 앱을 껐다 켜고 기기 등록을 새로 하거나, 기기 자체를 재부팅해요. 배포 단계에서 막히면 앱에 저장된 기기 항목을 삭제하고, 새로 등록해서 배포를 한 번 더 돌려요. 한 번의 배포로 파일이 다 넘어가지 않아서 여러 차례 반복해야 하는 경우도 있어요.

1~4세대의 부트 훅

1~4세대의 NetBSD 4 펌웨어는 부팅 훅을 유지하지 못해요. 패치하지 않으면 재부팅할 때마다 tcapsule activate를 실행해야 해요. 앱에서는 Persistent NetBSD4 Boot Hook 메뉴에서 Back Up and Inspect, Plan Patch, Write Patch를 차례로 실행해요.

제 기기의 펌웨어는 7.8.1이에요. 두 뱅크를 모두 Mac에 백업했고, Apple 카탈로그의 7.8.1을 바탕으로 만든 이미지를 primary 뱅크에만 썼어요. secondary 뱅크는 원본 그대로예요. 쓴 뒤에 다시 읽어서 일치하는지 확인하는 검증도 통과했어요. 패치 모드에서는 재부팅 명령을 쓸 수 없어서 전원 코드를 뽑았다가 다시 꽂았고, 그 뒤로는 activate 없이 Samba가 시작됐어요.

플래시 쓰기에는 위험이 있어요. v2.2.9의 FAQ는 쓰는 도중에 전원이 끊기면 기기를 못 쓰게 될 수 있다고 경고해요. v2.2.9의 README에 따르면 tcapsule flash --restore로 고른 뱅크를 순정으로 되돌릴 수 있는데, 저는 복원을 시험하지 않았어요. 5세대는 README와 FAQ에 따르면 부트 훅이 필요 없고, 재부팅 뒤에 Samba가 자동으로 시작되며, 배포 중에 한 번 재부팅해요. 5세대도 시험하지 않았어요.

CLI로 설치하는 경우

CLI는 실행하지 않았어요. README의 순서에 NBNS를 끄는 옵션을 더하면 아래와 같아요.

./tcapsule bootstrap
.venv/bin/tcapsule configure
.venv/bin/tcapsule deploy --no-nbns
.venv/bin/tcapsule doctor

bootstrap은 저장소 안에 Python 가상환경을 만들고, configure는 주소와 비밀번호를 설정 파일에 적어요. deploy --no-nbns는 NBNS를 끈 채로 배포하고, doctor는 상태를 검사해요. 1~4세대는 deploy 뒤에 flash로 백업하고 flash --patch로 부트 훅을 써요.

문서에 적힌 요구 환경은 macOS 14 이상, Python 3.9 이상, Homebrew, smbclient예요. NetBSD 4 기기가 대상이면 sshpass도 필요해요.

기존 백업을 이어 쓰는 방법

이 절은 main의 FAQ를 정리한 것이에요. 기준은 2026년 9월 14일의 커밋 34c075f이고, 제가 직접 옮겨 본 것이 아니에요. 설치는 디스크와 기존 .sparsebundle을 지우지 않아요.

먼저 SMB 접속이 되는지부터 봐요.
SMB 공유의 최상위에 .sparsebundle을 가져다 놓아요. 기본 내부 디스크 설정에서는 ShareRoot 폴더가 그 위치예요. 사용자 폴더 안쪽에 있던 묶음도 같은 자리로 꺼내요.
Time Machine의 백업 대상을 SMB 공유로 새로 지정해요.
예전 백업을 이어서 쓰자는 제안이 뜨면 받아들여요.

예전 묶음이 보이지 않거나 재사용에 실패하면 Time Machine은 묶음을 새로 만들어 버릴 수 있어요. 옮긴 뒤에도 macOS가 기존 백업을 찾지 못할 때 FAQ가 권하는 조치는 재부팅이에요. 백업을 마운트하지 않은 상태에서 Time Capsule부터 재부팅하고, 이어서 Mac을 재부팅해요.

확인한 범위

확인한 환경은 이래요. 설치에 쓴 Mac은 macOS 27.0이고, 백업한 Mac은 macOS 27의 Mac mini예요. 기기는 4세대 AirPort Time Capsule, 펌웨어 7.8.1, NetBSD 4.0이에요. 앱은 2.2.9, Samba는 4.24.3이고, 날짜는 2026년 9월 14일이에요. Mac mini에서 SMB 공유를 백업 대상으로 지정했고 첫 Time Machine 백업이 끝났어요.

상태를 볼 때 쓸 수 있는 명령이 몇 가지 있어요. Bonjour에서 SMB 서비스를 광고하는 기기를 찾는 명령이에요.

dns-sd -B _smb._tcp local.

Time Machine 백업 서비스를 광고하는 기기를 찾는 명령이에요. 두 명령은 따로 실행하고, 출력이 계속 이어지므로 Control-C로 끝내요.

dns-sd -B _adisk._tcp local.

지금 Mac에 등록된 백업 대상을 보는 명령이에요.

tmutil destinationinfo

첫 명령에는 SMB 기기 이름이, 둘째 명령에는 백업 디스크의 기기 이름이 나와요. 광고가 보인다고 해서 인증과 쓰기가 된다는 뜻은 아니에요. 문서에 따르면 doctor는 Samba 프로세스, 445 포트, Bonjour 광고, 인증된 공유 목록, 공유 안의 파일 작업을 검사해요.

계속 쓰면서 볼 것

설치가 끝난 뒤에도 앱이나 CLI 폴더는 보관해 두는 것이 좋아요. Checkup을 돌릴 때도, 다시 배포할 때도, activate나 제거를 할 때도 그 도구가 있어야 해요. FAQ는 CLI 폴더를 지워도 되지만 유지보수를 하려면 보관하거나 다시 받아야 한다고 설명해요. 새 버전으로 올릴 때에는 제거부터 하지 않고, 설치돼 있는 상태에서 배포를 한 번 더 해요. 그런 다음 NBNS 설정, LAN 설정, 텔레메트리 구조가 그대로인지 보고 Checkup으로 마무리해요. 부트 훅을 쓰지 않은 1~4세대는 재부팅 뒤에 activate를 실행해 줘야 해요.

OS 쪽의 변화도 봐야 해요. FAQ에는 macOS 26.4.x와 15.7.5~15.7.7에서 Time Machine 네트워크 백업이 퇴행했다는 기록이 있어요. OS를 올린 뒤에는 첫 백업이 끝나는지 확인하는 것이 좋아요.

이슈에 올라온 사례도 있어요. 이슈 294는 백업 중에 SMB가 멈추는 문제이고, 내장 Wi-Fi보다 유선이나 최신 외부 AP가 안정적이었다고 하지만 원인은 확정되지 않았어요. 이슈 271에서 관리자는 Samba와 네트워크의 불안정으로 판단했어요. 이슈 177은 첫 배포 중에 기기가 공장 초기화된 사례예요. 디스크의 데이터는 남지만 네트워크는 AirPort Utility로 다시 설정해야 하는데, macOS 27에서는 그 앱이 동작한다는 보장이 없어요. 그래서 설치하기 전에 기기의 설정을 기록해 둬요.

설치할 때에는 아직 출시 전이던 main도 읽어 봤어요. 2026년 9월 14일의 커밋 34c075f와 네이티브 헬퍼의 README에서는 heartbeat가 telemetry 헬퍼로 분리됐고, 서버의 지시에 따라 서명된 debug 실행물을 받아 실행해요. 출시 전의 코드이고 동작을 확인하지 않았으므로, 업데이트하기 전에 릴리스 노트와 FAQ를 다시 읽어야 해요.

Apple의 지원이 끝난 장비에 비공식 프로젝트를 얹은 구성이에요. 중요한 백업은 외장 저장장치나 SMB NAS에 하나 더 두는 것이 좋아요.

직접 확인하지 않은 것은 CLI 설치, 순정 펌웨어 복원, 기존 백업의 이전이에요. 5세대 기기, AirPort Extreme, 기기에 연결한 외장 디스크도 시험하지 않았어요. macOS 27에서 순정 SMB1으로 파일에 접속하는 것도 시험하지 않았어요. 이 글이 다룬 것은 Time Machine 문제예요. heartbeat가 멈췄다는 것도 패킷으로 확인하지 않았어요.