macOS Tahoe 26.4로 Time Machine SMB 백업이 중단됨: 26.5까지의 nsmb.conf 수정 방법
macOS 26.4의 강화된 SMB 서명이 Synology, QNAP, UGREEN NAS의 Time Machine을 중단시켰습니다. 단계별 nsmb.conf 해결 방법, 벤더 현황, 26.5 수정 일정을 안내합니다.
2026년 3월 말에 macOS Tahoe 26.4를 설치한 후 Synology, QNAP, UGREEN, TrueNAS 또는 Asustor NAS로의 Time Machine 백업이 갑자기 중단되었다면, 여러분만의 문제가 아닙니다. Apple의 26.4 릴리스는 운영 체제의 SMB 서명 기본값을 조용히 강화했으며, 이 변경으로 인해 시장의 거의 모든 서드파티 네트워크 연결 스토리지 장치에 대한 Time Machine 연결이 중단되었습니다. 4월 9일에 출시된 26.4.1 패치는 여러 버그를 수정했지만 Time Machine SMB 회귀 문제는 다루지 않았습니다.
좋은 소식은 오늘 밤에도 적용할 수 있는 알려진 해결 방법이 있다는 것입니다. Apple은 이미 macOS 26.5 베타 4(빌드 25F5068a, 2026년 4월 27일 시드)에서 해당 동작을 수정했습니다. 나쁜 소식은 공개 버전 26.5가 2026년 6월 8일 WWDC 2026 직전인 5월 말에 출시될 예정이라는 것입니다. 수동으로 조치를 취하지 않으면 대부분의 NAS 소유자는 몇 주 동안 백업이 중단된 상태로 있어야 합니다.
이 가이드는 내부적으로 무엇이 변경되었는지 정확히 설명하고, 붙여넣을 정확한 텍스트와 함께 /etc/nsmb.conf 해결 방법을 안내하며, 주요 NAS 벤더별 현황을 요약하고, 가정 또는 사무실 LAN에서 SMB 서명을 완화하는 보안 트레이드오프를 평가하며, 기다리는 동안 실행할 수 있는 더 안전한 임시 백업 전략을 설명합니다. 마지막에는 다시 백업이 작동하도록 하고, 포기한 것이 무엇인지 명확히 이해하며, macOS 26.5가 출시되는 즉시 변경 사항을 되돌리는 방법을 알 수 있게 됩니다.
핵심 요약
- 중단된 것: macOS Tahoe 26.4는 Time Machine 연결에서 SMB 서명을 기본값으로 필수화했습니다. 대부분의 서드파티 NAS는 macOS 26.4가 수락하는 방식으로 SMB 서명을 알리지 않아 Time Machine이 스파스번들을 마운트하기 전에 SMB 세션이 거부됩니다.
- 영향받는 벤더: Synology DSM 7.2 이하, QNAP QTS 5.1.x, UGREEN UGOS 1.x, Asustor ADM 4.x, TrueNAS SCALE 24.x(기본 설정), 기타 다수의 서드파티 SMB 대상. macOS 간 SMB를 통한 Time Machine은 여전히 작동합니다.
- 증상: "Time Machine이 백업을 완료할 수 없었습니다", "작업이 허용되지 않습니다", 반복되는 자격 증명 프롬프트, 마운트되지만 읽을 수 없는 스파스번들, 몇 초 이내에 중단되는 전체 재백업 시도.
- 수정 방법: NAS 펌웨어가 업데이트되거나 macOS 26.5가 출시될 때까지
signing_required=no및protocol_vers_map=7이 포함된/etc/nsmb.conf를 만듭니다. - 위험: SMB 서명을 비활성화하면 로컬 네트워크에서 SMB 세션이 MITM 변조에 노출됩니다. 신뢰할 수 있는 가정 LAN에서는 허용 가능하지만, 공유 사무실 Wi-Fi 또는 코워킹 네트워크에서는 덜 허용됩니다.
- 수정 일정: macOS 26.5 베타 4가 회귀 문제를 해결했다고 보고되고 있습니다. 공개 버전 26.5는 WWDC를 앞두고 2026년 5월 말에 예정되어 있습니다.
무엇이 언제 중단되었나
Apple은 2026년 3월 말에 macOS Tahoe 26.4를 Tahoe 사이클의 두 번째 기능 업데이트로 출시했습니다. 릴리스 노트에서는 Apple Intelligence 개선, 캘린더 앱 새로고침, 긴 보안 수정 목록이 강조되었습니다. 그 보안 목록 안에 macOS에 내장된 SMB 클라이언트에 대한 변경 사항이 포함되어 있었으며, 커널이 SMB 세션을 협상하는 방식을 강화했습니다. Apple은 헤드라인 릴리스 노트에서 이를 강조하지 않았지만, Time Machine 대상이 서드파티 NAS인 사람에게는 즉각적인 영향이 있었습니다.
26.4 출시 48시간 이내에, Apple Community 스레드 256221835가 동일한 증상을 설명하는 Synology 및 QNAP 소유자의 보고를 수집하기 시작했습니다. Hacker News 항목 46848699에서는 모든 종류의 소비자 및 프로슈머 NAS를 사용하는 사용자로부터 수백 개의 응답이 모였습니다. 패턴은 명확했습니다: 몇 년 동안 매일 밤 실행되던 백업이 26.4 업데이트 후 첫 번째 시도에서 갑자기 초기화를 거부했습니다.
Apple은 2026년 4월 9일에 26.4.1을 출시하여 Wi-Fi 로밍 문제와 메일 렌더링 버그를 포함한 몇 가지 무관한 회귀 문제를 처리했습니다. Time Machine SMB 문제는 26.4.1 패치 노트에 없었으며, 테스트를 통해 회귀 문제가 포인트 릴리스에서 살아남았음이 확인되었습니다. 26.4.1이 조용히 이전 동작을 복원해줄 것을 기대했던 사용자들은 실망했으며, Apple Community 스레드의 분위기는 "이게 나만의 문제인가"에서 "Apple이 이것을 인정해야 한다"로 바뀌었습니다.
26.4 릴리스 사이클과 알아야 할 기타 회귀 문제에 대한 자세한 내용은 macOS Tahoe 26.4 및 26.4.1 완전 업데이트 가이드를 참조하십시오.
증상 갤러리
Time Machine SMB 회귀는 NAS 벤더, 펌웨어 버전 및 업그레이드 전 Time Machine 구성 방법에 따라 여러 가지 방식으로 나타납니다. 가장 일반적인 증상은 사용자 보고서에 나타나는 대략적인 순서로 아래에 나열되어 있습니다.
26.4 이후 첫 번째 예약된 백업에서 Time Machine이 초기화에 실패합니다. Time Machine 메뉴 바 아이콘이 몇 초 동안 회전한 후 "Time Machine이 [공유 이름]에 백업을 완료할 수 없었습니다"를 표시합니다. 시스템 설정에서 Time Machine을 열면 대상이 여전히 구성되어 있지만 다음 백업 시도도 동일하게 실패합니다.
반복되는 자격 증명 프롬프트. macOS가 SMB 공유 사용자 이름과 비밀번호를 요청하고, 자격 증명을 수락한 후 즉시 다시 요청합니다. Keychain에 자격 증명을 저장해도 도움이 되지 않습니다. SMB 세션 자체가 인증보다 낮은 레이어에서 거부되기 때문입니다.
"작업이 허용되지 않습니다" 또는 POSIX 오류 1. 이것은 기본 로그에서 가장 일반적인 오류 문자열입니다. NAS의 스파스번들은 기술적으로 도달 가능하지만, macOS 26.4가 이제 요구하는 서명 속성 없이 SMB 세션이 협상되거나 다운그레이드되었기 때문에 macOS가 마운트를 거부하여 발생합니다.
마운트되지만 읽을 수 없다고 보고되는 스파스번들. 일부 사용자는 백업 볼륨이 Finder에 마운트되지만 Time Machine이 볼륨을 사용할 수 없다고 보고합니다. 이는 일반적으로 공유가 폴백으로 서명되지 않은 SMB1 또는 SMB2 세션을 협상하고 macOS가 그것에 쓰기를 거부할 때 발생합니다.
몇 초 이내에 중단되는 전체 재백업 시도. 일부 사용자는 대상을 제거하고 다시 추가하여 문제를 "수정"하려고 했으며, 새로운 백업이 작동하기를 바랐습니다. 대신 재백업은 동일한 손상된 SMB 세션을 협상하고 거의 즉시 중단되어 경우에 따라 NAS에 빈 자리 표시자 스파스번들을 남깁니다.
smbfs, signature mismatch 또는 STATUS_ACCESS_DENIED를 참조하는 콘솔 로그 항목. 실패가 발생하는 동안 Console.app을 열고 smb로 필터링하면 서명 협상에 관한 커널 메시지가 표시됩니다. 이것이 서명 변경의 확실한 증거입니다.
이 중 여러 가지가 동시에 발생하고 있다면, NAS 하드웨어 결함, 네트워크 문제 또는 손상된 스파스번들보다 26.4 SMB 서명 회귀를 거의 확실하게 겪고 있는 것입니다. SMB 레이어와 관계없이 적용되는 더 광범위한 Time Machine 진단에 대해서는 완전한 Time Machine 문제 해결 가이드에서 나머지 영역을 다루고 있습니다.
중단된 이유: Apple의 SMB 서명 변경 설명
해결 방법이 왜 작동하는지 이해하려면 SMB 서명이 실제로 무엇인지, 그리고 Apple이 26.4에서 기본값을 바꾸기로 결정한 이유를 아는 것이 도움이 됩니다.
SMB 서명은 macOS가 Windows 공유, Samba 서버 또는 NAS에 연결할 때 사용하는 파일 공유 프로토콜인 Server Message Block 프로토콜의 기능입니다. SMB 서명이 활성화되면 클라이언트가 서버에 보내는 모든 패킷에는 세션 키에서 파생된 암호화 서명이 포함됩니다. 서버는 각 패킷의 서명을 확인하고 응답에도 동일한 방식으로 서명합니다. 결과적으로 같은 네트워크의 공격자는 서명이 실패하고 연결이 종료되지 않으면서 전송 중인 파일 내용을 변조할 수 없습니다.
SMB 서명은 SMB1부터 존재했으며 많은 Windows 워크로드에서 기본적으로 SMB3에서 필수입니다. 클라이언트와 서버 간의 프로토콜 협상에 따라 서명이 "사용되지 않음", "활성화되지만 선택적" 또는 "필수" 중 하나로 결정됩니다. macOS 26.4 이전에는 macOS SMB 클라이언트가 서버가 서명을 요구하지 않으면 서명되지 않은 세션을 협상하는 것을 수락했으며, 이는 성능상의 이유로 대부분의 소비자 NAS 장치가 취하던 방식이었습니다.
26.4에서 Apple은 명시적으로 지시받지 않는 한 클라이언트가 세션에서 서명을 요구하도록 macOS 기본값을 변경했습니다. 클라이언트가 서명을 사용 가능하지만 필수는 아니라고 알리는 NAS에 연결하면, macOS는 서명되지 않은 모드로의 폴백을 거부합니다. 세션 협상이 오류로 완료되고, SMB 마운트가 실패하며, Time Machine에는 쓸 대상이 없어집니다.
Apple은 왜 이렇게 했을까요? 이 변경은 SMB를 강화하기 위한 다년간의 업계 노력과 일치합니다. Microsoft는 Windows 11 24H2에서 기본적으로 서명을 필수화했고, SMB 커뮤니티는 필수 서명이 있는 SMB 3.1.1로 마이그레이션하고 있으며, Apple의 기업 고객도 동일한 것을 요청해 왔습니다. 랜섬웨어 위협 모델에는 침해된 엔드포인트에서 파일 공유로 이동하여 전송 중인 백업 파일을 변조하는 공격자가 포함되며, SMB 서명이 가장 깔끔한 완화책 중 하나입니다.
문제는 NAS 벤더들에게 명확한 지원 중단 예고가 주어지지 않았다는 것입니다. Synology, QNAP, UGREEN 장치는 이전 Windows 클라이언트와 임베디드 장치가 여전히 연결할 수 있도록 서명을 사용 가능하지만 필수는 아니라고 출시합니다. macOS 26.4는 사실상 이러한 벤더들이 자신들의 기본값을 변경하도록 요구하는데, 이는 동일한 네트워크의 다른 클라이언트를 중단시킬 수 있기 때문에 대부분의 플랫폼에서 단 한 번의 펌웨어 업데이트로 수정할 수 없습니다.
macOS Tahoe의 SMB 스택과 SMB 연결이 실패할 수 있는 다른 방법에 대한 자세한 내용은 완전한 SMB 및 NAS 문제 해결 가이드에서 Time Machine 이외의 연결 문제를 다루고 있습니다.
nsmb.conf 수정, 단계별 안내
가장 깔끔한 해결 방법은 신뢰하는 연결에 대해 서명 없는 SMB 세션을 수락할 의향이 있음을 macOS에 알리는 것입니다. macOS는 모든 SMB 세션 설정 시 /etc/nsmb.conf의 구성 파일을 읽으며, 거기에 26.4 이전 동작을 복원하는 전역 플래그를 설정할 수 있습니다.
시작하기 전에 두 가지 경고가 있습니다. 첫째, 이 변경은 Time Machine뿐만 아니라 Mac이 만드는 모든 SMB 연결에 적용되므로, 이 기사의 후반부에 설명된 보안 트레이드오프에 대해 편안한지 확인하십시오. 둘째, /etc/nsmb.conf에 대한 편집은 관리자 권한이 필요하며, 형식이 잘못된 파일은 SMB 연결이 다른 방식으로 실패하게 하므로 신중하게 진행해야 합니다.
빠른 수정: 원라이너
자기 전에 백업이 작동하기를 원하고 Terminal에 익숙하다면, 다음 명령으로 필요한 설정이 포함된 파일을 한 번에 만들 수 있습니다. 응용 프로그램 → 유틸리티에서 Terminal을 열고 명령을 정확히 붙여넣습니다. 관리자 암호를 입력하라는 메시지가 표시됩니다.
sudo tee /etc/nsmb.conf >/dev/null <<'EOF'
[default]
signing_required=no
protocol_vers_map=7
EOFsigning_required=no 줄은 SMB 서명이 필수가 아니라 선택 사항임을 macOS SMB 클라이언트에 알립니다. protocol_vers_map=7 줄은 SMB 1, SMB 2, SMB 3 협상을 허용하는 비트마스크로, 이는 레거시 기본값입니다. 최신 NAS 장치 대부분에서는 실제로 SMB 2와 SMB 3만 사용되지만, 맵에 SMB 1을 포함시키면 협상이 프로토콜 없이 완전히 실패하는 엣지 케이스를 방지합니다.
명령을 실행한 후, 현재 마운트된 SMB 공유를 Finder에서 꺼내고 10초를 기다린 후 이름으로 공유에 다시 연결합니다. 다음 Time Machine 백업 시도가 진행될 것입니다.
영구적인 수정: /etc/nsmb.conf 직접 편집
커밋하기 전에 파일을 보고 싶거나 나중에 서버별 재정의를 추가하려면, sudo로 텍스트 편집기에서 파일을 만들거나 편집합니다. 원하는 편집기를 사용하십시오. nano는 macOS에 포함되어 있으며 Terminal을 가끔 사용하는 사용자에게 가장 친숙한 옵션입니다.
sudo nano /etc/nsmb.conf다음 내용을 붙여넣고, Control-O와 Return으로 저장하고, Control-X로 종료합니다.
[default]
signing_required=no
protocol_vers_map=7
# Optional: target a specific NAS by hostname.
# Replace synology.local with your NAS hostname.
[synology.local]
signing_required=no[default] 섹션은 모든 SMB 연결에 적용됩니다. 선택적인 두 번째 섹션은 단일 호스트 이름에 대한 기본값을 재정의합니다. NAS에 대해서만 서명을 완화하고 기업 파일 서버 연결에는 엄격함을 유지하려는 경우에 유용합니다.
더 세밀한 제어가 필요한 사용자를 위해, /Library/Preferences/com.apple.NetworkAuthorization.plist의 속성 목록이나 덜 알려진 serverMarkers.plist 메커니즘을 사용하여 특정 서버를 "레거시"로 표시하고 새 서명 로직을 우회하는 대안적인 접근법이 있습니다. plist 접근법은 더 침습적이며 nsmb.conf보다 문서가 적으므로, 특정 NAS 펌웨어 조합에서 nsmb.conf가 문제를 해결하지 못하는 경우에만 권장합니다.
수정이 작동했는지 확인
파일을 저장한 후, Mac이 협상하는 다음 SMB 세션은 새 기본값을 따릅니다. 파일이 올바르게 읽히고 있는지 확인하려면 Terminal에서 다음 원라이너를 실행합니다.
cat /etc/nsmb.conf작성한 내용과 정확히 일치하는 것이 표시되어야 합니다. 파일이 비어 있거나 다른 [default] 블록이 표시되면 이전 해결 방법 시도에서 오래된 복사본이 있을 수 있습니다.
실시간으로 SMB 협상이 일어나는 것을 보려면 Console.app을 열고 검색 필드에 smb를 입력한 다음 Time Machine 백업을 시작하거나 공유를 수동으로 마운트합니다. 공유 이름으로의 트리 연결이 이어지는 성공적인 세션 설정이 표시되어야 합니다. 수정 전 실패는 같은 스트림에 서명 또는 서명 오류를 기록했으며, 수정 적용 후 해당 오류가 없으면 해결 방법이 적용되었다는 명확한 지표입니다.
협상된 SMB 프로토콜 버전을 확인하려면 Activity Monitor를 열고 네트워크 탭으로 전환하면 smbd 연결이 표시됩니다. Terminal에서 smbutil statshares -a를 실행할 수도 있으며, 모든 활성 SMB 공유와 협상된 SMB 다이얼렉트가 나열됩니다. SMB_VERSION SMB_3_0_2 이상에 SIGNING_SUPPORTED TRUE라는 줄이 있으면 서명이 더 이상 필수가 아니더라도 기회주의적으로 사용되고 있음을 의미하며, 이것이 최선의 상태입니다.
Time Machine이 첫 번째 백업을 성공적으로 완료하면 macOS 26.5가 출시될 때까지 구성을 그대로 둘 수 있습니다. 롤백하려면 /etc/nsmb.conf를 삭제하거나 signing_required=no를 signing_required=yes로 변경하고 공유를 다시 연결합니다.
NAS 벤더별 현황
회귀의 심각도와 벤더 측 수정의 가용성은 NAS 플랫폼에 따라 다릅니다. 2026년 5월 초 현재 상황은 다음과 같습니다.
Synology DSM. Synology는 2026년 4월 중순에 DSM 7.2.2 업데이트 4를 출시하여 서버 측에서 SMB 서명을 요구하는 구성 토글을 추가했습니다. 제어판의 파일 서비스 → SMB → 고급 설정에서 토글을 활성화하면 Mac의 nsmb.conf 해결 방법 없이 Time Machine 기능이 복원됩니다. 이전 DSM 7.1 및 DSM 6.2 시스템에는 토글이 없으며 클라이언트 측 해결 방법이 필요합니다. Synology는 커뮤니티 게시물에서 DSM 7.2.3이 새 설치에서 서명 필수를 기본값으로 만들 것이라고 확인했습니다.
QNAP QTS. QTS 5.1.7은 제어판 → 네트워크 및 파일 서비스 → Win/Mac/NFS/WebDAV → SMB 고급 옵션에 유사한 설정을 추가했습니다. 토글은 "SMB 서명 적용"으로 레이블이 지정되어 있습니다. 활성화하면 대부분의 사용자에게 작동하지만, 일부는 공유 자체를 다시 만든 후에야 QTS SMB 스택이 올바르게 협상한다고 보고했습니다. QTS 5.2.0 베타가 테스트 중이며 서명 필수를 기본값으로 만들 예정입니다.
UGREEN UGOS. UGREEN은 반응이 느렸습니다. 2026년 4월 말 현재 UGOS 1.4는 서명 필수로 SMB 3.1.1을 활성화하는 베타 펌웨어를 추가했지만, 펌웨어는 아직 GA가 아니며 베타 채널을 통해 옵트인 방식입니다. 안정적인 UGOS 펌웨어의 UGREEN 소유자는 앞으로 몇 주 동안 nsmb.conf 해결 방법을 사용할 계획을 세워야 합니다.
TrueNAS. TrueNAS SCALE 24.10은 Samba 4.20과 함께 출시되며, 기본적으로 서명 필수를 지원합니다. SMB 서비스 보조 매개변수를 편집하고 server signing = mandatory를 추가하여 설정을 활성화할 수 있습니다. 변경 사항을 적용한 후 SMB 서비스를 다시 시작합니다. 이전 Samba 버전의 TrueNAS CORE 사용자는 서버 측 수정을 사용하기 전에 업데이트가 필요할 수 있습니다.
Asustor ADM. ADM 4.3.1은 서비스 → Win/Mac/NFS에 "SMB 서명 적용" 토글을 추가했지만, 저가형 CPU가 있는 이전 Asustor 장치에서 활성화하면 패킷별 서명 오버헤드로 인해 SMB 처리량이 20~30% 감소한다고 보고되었습니다. 이 트레이드오프로 인해 Asustor 사용자는 Mac의 클라이언트 측 해결 방법을 선택할 수 있습니다.
기타 벤더. Drobo, WD My Cloud Pro 및 몇몇 소규모 벤더는 아직 펌웨어 업데이트를 출시하지 않았습니다. nsmb.conf 해결 방법은 모든 경우에 적용됩니다. NAS가 최신 Samba(4.18 이상)를 실행하는 경우, 장치의 smb.conf에서 server signing = mandatory를 활성화하는 것도 작동할 수 있지만, 자체 Samba 구성을 유지하는 것에 익숙한 경우에만 시도하십시오.
단일 취약 지점에 의존하지 않는 장기적인 백업 전략을 고려하는 사용자를 위해, 2026년 최고의 Mac 백업 전략에서 Time Machine과 iCloud 및 로컬 클론을 결합하여 복원력을 높이는 방법을 안내합니다.
SMB 서명 완화의 보안 트레이드오프
nsmb.conf에서 signing_required를 비활성화하는 것은 외형적인 토글이 아니라 보안 태세에 대한 실질적인 변경입니다. 무엇을 교환하고 있는지에 대해 솔직하게 평가할 가치가 있습니다.
SMB 서명이 필수인 경우, 로컬 네트워크에서 중간자로 자리 잡은 공격자는 전송 중인 SMB 트래픽을 변조할 수 없습니다. 서명이 없으면 같은 레이어 2 네트워크의 충분한 동기가 있는 공격자가 SMB 패킷을 가로채고 NAS에 기록되는 파일 내용을 변경할 수 있습니다. 공격자는 유선 LAN, Wi-Fi 네트워크 또는 같은 브로드캐스트 도메인을 공유하는 VPN에 있어야 합니다. 또한 SMB MITM 도구를 실행할 수 있는 기술적 정교함도 필요하며, 이는 사소하지 않지만 드물지도 않습니다.
자신이 관리하는 단일 Wi-Fi 네트워크, 신뢰하는 라우터, LAN에 신뢰할 수 없는 장치가 없는 일반적인 가정 환경에서는 SMB MITM 공격의 실질적인 위험이 매우 낮습니다. 가정 LAN에서 가장 일반적인 공격자는 소유한 다른 장치에서 실행 중인 악성 소프트웨어이며, 이 시나리오는 대부분 SMB 서명 범위를 벗어납니다. 악성 소프트웨어는 자체 자격 증명을 보유하여 Mac에 대한 중간자 공격이 필요하지 않기 때문입니다.
사무실 환경, 코워킹 공간 또는 신뢰할 수 없는 장치가 정기적으로 네트워크에 참여하는 설정에서는 계산이 다릅니다. Raspberry Pi를 연결한 동료, 악성 소프트웨어가 있는 게스트 장치 또는 침해된 IoT 카메라 모두 서명되지 않은 SMB 트래픽에 대한 공격을 수행할 수 있습니다. 그러한 환경에서 올바른 답은 Mac의 서명을 완화하는 것이 아니라 NAS 펌웨어를 업데이트하여 서명이 엔드투엔드로 필수로 유지되도록 하는 것입니다.
합리적인 중간 방법은 nsmb.conf의 서버별 섹션을 사용하여 Time Machine이 대상으로 하는 NAS 호스트 이름에 대해서만 서명을 완화하고 전역 기본값은 signing_required=yes로 유지하는 것입니다. 이렇게 하면 다른 SMB 연결은 보호된 상태로 유지되고 완화는 LAN에서 신뢰하는 호스트에만 적용됩니다.
또한 서버가 SMB 암호화(서명과는 별도 기능)를 명시적으로 활성화하지 않는 한 macOS의 모든 SMB 트래픽은 기본적으로 암호화되지 않는다는 점도 주목할 가치가 있습니다. 네트워크를 통한 백업 콘텐츠의 기밀성이 걱정된다면, NAS 측에서 SMB 암호화를 활성화하는 것이 서명보다 더 효과적이며 26.4 회귀와 상호 작용하지 않습니다.
기다리는 동안의 대안
시스템 구성 파일 편집이 편안한 주말의 생각이 아니거나 보안 트레이드오프에 불편함이 있는 경우, NAS 기반 Time Machine과 병렬로 또는 대신 실행할 수 있는 여러 대안적인 백업 전략이 있습니다. 그 중 두 가지를 결합하면 문제가 해결될 때까지 이중화가 확보됩니다.
외부 SSD를 통한 Time Machine. USB-C 직결 SSD는 단일 NAS 드라이브 베이와 거의 같은 비용으로 SMB 레이어 없이 네이티브로 서명된 Time Machine 백업을 제공합니다. 2TB Samsung T7 또는 Crucial X9 Pro는 대부분의 사용자의 수개월 분량의 증분 백업을 보유할 수 있습니다. 매일 밤 연결하고 Time Machine을 완료한 후 랜섬웨어 복원력을 위해 오프사이트에 보관합니다. 단점은 수동 처리이며, 대부분의 사람들이 2주 내에 중단합니다.
Carbon Copy Cloner. Bombich Software의 Carbon Copy Cloner(CCC)는 SMB 공유를 포함한 모든 대상에 Mac의 부팅 가능 또는 부팅 불가능한 클론을 만듭니다. CCC는 Time Machine과 독립적으로 SMB 세션 설정을 처리하며 26.4 회귀에 대해 Time Machine 자체보다 더 탄력적인 자체 재시도 로직이 포함되어 있습니다. 라이선스는 일회성이며 체험판이 넉넉합니다. CCC는 Apple이 Time Machine을 수정할 때까지 기다리는 동안 실제 백업 도구가 필요한 사용자들에게 가장 인기 있는 선택입니다.
SuperDuper. Shirt Pocket Software의 SuperDuper는 macOS용 또 다른 오래된 클론 도구입니다. CCC보다 단순하고 기능이 적지만, 가격도 더 저렴하며 "어딘가에 최근 디스크 사본을 유지한다"는 목표만 있는 사용자에게는 충분하고도 남습니다. SuperDuper는 SMB 공유보다 로컬 대상에 더 신뢰성 있게 쓰기 때문에 외부 SSD 접근 방식과 잘 결합됩니다.
Arq 클라우드 스토리지 백업. Arq는 Backblaze B2, Wasabi, AWS S3 및 자체 SFTP 서버를 포함한 클라우드 대상을 지향하는 버전 관리 백업 도구입니다. 오프사이트 백업을 위해 설계되었으며, 업로드 전에 클라이언트 측에서 데이터를 암호화하고 macOS SMB 스택에 대한 의존성이 없습니다. Arq는 완전한 대체가 아닌 로컬 백업의 강력한 보완재입니다. 대규모 데이터 세트의 클라우드 복원은 느리기 때문입니다.
Time Machine 대상으로 두 번째 Mac 사용. 오래된 Mac이 있는 경우 거기서 파일 공유를 활성화하고 기본 Mac의 Time Machine을 보조 Mac의 폴더로 향하게 할 수 있습니다. macOS 간 SMB 연결은 26.4에서도 여전히 작동합니다. 양쪽이 같은 다이얼렉트를 사용하기 때문입니다. 이것은 틈새 옵션이지만 하드웨어가 있으면 무료입니다.
수정을 기다리는 동안 많은 사용자들이 정착하는 조합은 NAS로의 Carbon Copy Cloner 작업과 주 1회 외부 SSD 교체입니다. CCC는 일일 증분 작업을 처리하고 26.4에서 신뢰성이 있으며, 외부 SSD는 NAS 드라이브 장애부터 네트워크 공유를 암호화하는 랜섬웨어까지 모든 것으로부터 보호하는 에어갭 폴백을 제공합니다.
macOS 26.5는 실제로 언제 이것을 수정하나?
Apple은 2026년 4월 27일에 빌드 번호 25F5068a의 macOS 26.5 베타 4를 개발자에게 시드했습니다. 베타 릴리스 노트는 여전히 NDA 하에 있지만, 베타 테스터의 보고에 따르면 SMB 서명 기본값이 조정되어 수동 개입 없이 일반적인 NAS 구성에 대한 Time Machine 연결이 성공합니다.
수정의 정확한 메커니즘은 공식적으로 문서화되지 않았습니다. SMB 협상 로그에서 관찰된 변경 사항에서 가장 좋은 추측은 Apple이 서버가 서명을 지원되지만 필수는 아니라고 알리는 SMB 세션에 대한 폴백 경로를 재도입했으며, 폴백을 Time Machine 스파스번들 액세스로 제한했다는 것입니다. 이렇게 하면 영향받는 NAS 집단의 백업 기능이 복원되는 동시에 일반 SMB 사용에 대한 보안 개선이 유지됩니다.
26.5의 공개 릴리스 일정은 미확인이지만 예측 가능한 패턴을 따릅니다. Apple은 일반적으로 macOS의 주요 버전의 최종 WWDC 이전 포인트 릴리스를 5월 말에 목표로 하며, WWDC 2026은 6월 8일 월요일에 시작할 예정입니다. 4월 말의 베타 4, 5월 초의 베타 5, 5월 중순의 릴리스 후보는 공개 릴리스를 5월 19일에서 5월 26일 창에 몇 일의 오차 내에 놓습니다.
26.5 사이클에 포함된 다른 내용(새 Apple Intelligence 기능, 재설계된 알림, 오래 기다려 온 Mail 재작성 등)에 대한 자세한 내용은 macOS Tahoe 26.5 베타 1 완전 가이드를 참조하십시오.
26.5가 출시되고 해결 방법 없이 Time Machine이 작동하는지 확인한 후, 모든 네트워크 연결에서 SMB 서명 기본값이 복원되도록 /etc/nsmb.conf를 제거하거나 복원하는 것을 잊지 마십시오.
문제 해결 체크리스트
nsmb.conf 해결 방법이 첫 번째 시도에서 Time Machine을 수정하지 못하면, 문제가 더 특이하다고 가정하기 전에 이 체크리스트를 확인하십시오.
공유를 꺼내고 다시 마운트합니다. macOS는 공유가 완전히 꺼낼 때까지 공유의 협상된 SMB 세션을 캐시합니다. Finder를 사용하여 NAS 공유를 꺼내고, 10초를 기다린 후 공유 경로를 수동으로 입력하여 Finder에서 다시 연결합니다. 그런 다음에만 Time Machine 백업을 시작합니다.
Mac을 다시 시작합니다. 일부 사용자는 SMB 클라이언트가 다음 부팅까지 새 nsmb.conf를 가져오지 않는다고 보고했습니다. 재시작은 문제를 더 추적하는 것보다 빠릅니다.
NAS 펌웨어를 업데이트합니다. NAS에 Tahoe 특정 수정이 없더라도, 최근 펌웨어 업데이트가 macOS 변경과 상호 작용하는 방식으로 SMB 협상을 개선했을 수 있습니다. Synology DSM 7.2.2u4, QNAP QTS 5.1.7, TrueNAS SCALE 24.10이 최소 권장 버전입니다.
공유 권한을 확인합니다. NAS에서 Time Machine이 사용하는 사용자 계정이 Time Machine 공유에 대한 읽기 및 쓰기 권한이 있는지 확인합니다. 일부 NAS 펌웨어 업데이트는 업데이트 프로세스 중에 권한을 재설정합니다.
스파스번들 무결성을 확인합니다. 이전 백업 시도가 부분적인 스파스번들을 남긴 경우, 수동으로 마운트하여 hdiutil verify를 실행합니다. 손상된 스파스번들은 SMB 레이어가 수정된 후에도 Time Machine을 실패하게 합니다. 심각한 경우에는 스파스번들을 삭제하고 처음부터 시작하는 것이 가장 깔끔한 방법입니다.
Time Machine 대상이 인식되는지 확인합니다. 시스템 설정 → 일반 → Time Machine을 열고 대상이 목록에 여전히 표시되는지 확인합니다. 빠진 경우 SMB 레이어가 작동한 후 다시 추가합니다.
네트워크 연결을 확인합니다. Terminal에서 NAS를 ping하여 Mac이 NAS에 도달할 수 있는지 확인합니다. SMB는 IP 레벨 연결과 SMB 포트(일반적으로 445) 모두 도달 가능해야 합니다.
커널 로그를 확인합니다. 백업이 실패한 후 log show --last 5m --predicate 'process == "kernel"' | grep smb를 실행합니다. 커널 레벨 SMB 오류는 실패가 서명 협상, 인증, 트리 연결 또는 파일 작업 레이어 중 어느 곳에 있는지 밝혀줍니다.
이 모든 것 후에도 백업이 실패하면, 특정 NAS 펌웨어 조합이 serverMarkers.plist 접근 방법 또는 NAS 측 smb.conf 변경이 필요한 이상치일 수 있습니다. NAS 모델, 펌웨어 버전 및 정확한 커널 로그 줄을 관련 벤더 포럼에 게시하는 것이 일반적으로 작동하는 수정에 가장 빠른 방법입니다.
자주 묻는 질문
Q: nsmb.conf 해결 방법이 Windows PC로의 SMB 연결에 영향을 미칩니까?
A: 예. [default] 섹션의 변경은 Mac이 만드는 모든 SMB 연결에 적용됩니다. Windows 연결을 엄격하게 유지하려면 NAS 호스트 이름을 섹션 이름으로 사용하여 변경 사항을 서버별 섹션으로 범위를 좁히십시오.
Q: 수정을 적용한 후 Time Machine 백업을 전체적으로 다시 해야 합니까? A: 아니요. SMB 세션이 올바르게 설정되면 Time Machine은 중단한 지점부터 재개하여 다음 증분 백업을 씁니다. 스파스번들 자체가 이전 실패한 시도로 손상된 경우에만 전체 재백업이 필요합니다.
Q: 수정을 시도했지만 Time Machine이 여전히 실패합니다. 이제 어떻게 해야 합니까? A: 위의 문제 해결 체크리스트를 검토하고 커널 로그 줄에 특히 주의를 기울이십시오. 가장 일반적인 후속 원인은 남은 SMB 문제가 아니라 이전 실패한 시도로 인한 손상된 스파스번들입니다.
Q: 코워킹 공간에 가져가는 Mac에 수정을 적용하는 것이 안전합니까?
A: 코워킹 네트워크에서 가정 NAS로 서명되지 않은 SMB를 실행하는 것보다 안전하지만, 가장 깔끔한 답은 NAS 펌웨어를 업데이트하여 서버 측 서명이 필수가 되도록 하거나 nsmb.conf 예외를 가정 NAS 호스트 이름에만 범위를 좁히는 것입니다.
Q: 매 macOS 업데이트 후 수정을 반복해야 합니까?
A: /etc/nsmb.conf 파일은 업데이트에 걸쳐 유지됩니다. 업데이트가 특히 시스템 구성 파일을 재설정하지 않는 한 다시 적용할 필요가 없으며, 이는 드문 경우입니다.
Q: 수정이 iCloud 백업, AirDrop 또는 다른 Apple 서비스를 중단시킵니까?
A: 아니요. 이러한 서비스는 SMB를 사용하지 않으므로 nsmb.conf 변경의 영향을 받지 않습니다.
Q: macOS Sequoia 또는 Sonoma에서 동일한 수정을 사용할 수 있습니까? A: 파일 형식은 동일하며 동일한 줄이 작동하지만, SMB 서명 변경이 Tahoe 26.4에만 해당되므로 Sequoia 또는 Sonoma에서는 필요하지 않을 것입니다. 이전 macOS 버전에 수정을 적용해도 해롭지 않지만 불필요합니다.
Q: NAS 벤더가 이것을 수정하는 펌웨어 업데이트가 있다고 말합니다. 그래도 nsmb.conf를 유지해야 합니까?
A: 펌웨어 업데이트가 적용되고 해결 방법 없이 Time Machine이 작동하는 것을 확인한 후 nsmb.conf를 제거하십시오. 완화를 계속 유지하는 것은 불필요하며 보안 기준을 낮춥니다.
Q: nsmb.conf를 편집하는 GUI 도구가 있습니까?
A: Apple의 공식 도구는 없습니다. GitHub에 몇 가지 서드파티 도구가 있지만, 두 줄짜리 파일의 경우 Terminal 접근 방법이 새 유틸리티를 설치하는 것보다 더 빠르고 위험이 낮습니다.
Q: 26.5가 출시되면 Apple이 수정을 26.4에 백포트합니까? A: Apple은 SMB 회귀를 다루는 26.4.2 패치에 약속하지 않았습니다. 역사적으로 Apple은 특히 비보안 회귀의 경우 백포트보다 다음 주요 포인트 릴리스에 수정을 포함시키는 것을 선호합니다. 26.5를 해결책으로 계획하십시오.
결론
macOS Tahoe 26.4 SMB 서명 변경은 보안 관점에서 올바른 결정이었지만, 벤더 조율 부재로 인해 NAS 기반 Time Machine 백업이 몇 주 동안 어려운 상황에 놓였습니다. /etc/nsmb.conf 해결 방법은 짧고, 되돌릴 수 있으며, 즉각적인 필요를 해결합니다. 더 지속적인 답은 NAS 펌웨어를 최신 상태로 유지하여 서버 측에서 서명이 필수가 되도록 하여 연결 전체에 걸쳐 엄격한 서명이 복원되도록 하는 것입니다.
2026년 5월 말 이후에 이것을 읽고 있다면, 해결 방법을 적용하기 전에 macOS 26.5가 출시되었는지 확인하십시오. 26.5가 사용 가능하다면 설치하면 시스템 파일 변경 없이 Time Machine 백업이 재개될 것입니다. 해결 방법을 적용했고 26.5가 설치된 경우, 5분을 내서 nsmb.conf를 롤백하고 엄격한 서명이 복원된 상태에서도 백업이 작동하는지 확인하십시오.
백업은 무언가가 중단될 때만 생각하는 인프라의 종류이며, 26.4 회귀는 단일 백업 대상에 의존하는 것이 위험하다는 유용한 알림입니다. 이번 주에 어떤 수정 경로를 택하든, 다음 macOS 업데이트가 도착하기 전에 두 번째 독립적인 백업 대상을 추가하는 것을 고려하십시오.