라떼군 이야기
애플이 또? macOS 'Tahoe'에서 고장 난 타임머신과 SMB의 악몽
TL;DR macOS의 새로운 버전(Tahoe)에서 SMB 기본 설정 변경으로 인해 시놀로지 NAS로의 타임머신 백업이 조용히 중단되는 문제가 발생했습니다. 이를 해결하기 위해 클라이언트 측 설정 파일(/etc/nsmb.conf)을 수정하거나, 장기적으로는 시놀로지 의존성을 끊고 Docker 기반의 독립적인 Samba 서버를 구축하는 방안이 제시되었습니다.
백업은 공기와 같아서 사라지기 전까지는 그 소중함을 모릅니다. 그런데 믿었던 타임머신(Time Machine) 백업이 OS 업데이트 후 사용자도 모르게 멈춰있었다면 어떨까요? 이 글은 2026년 시점의 macOS ‘Tahoe’ 업데이트가 예고 없이 SMB 프로토콜 기본값을 변경하면서 발생한 백업 대란과, 이를 기술적으로 어떻게 우회하고 더 견고한 시스템으로 나아갈 수 있는지 다루고 있습니다.
핵심 내용
저자는 시놀로지 NAS를 타겟으로 한 타임머신 백업이 아무런 경고 없이 실패하고 있음을 발견했습니다. 원인은 애플이 SMB의 kern_deadtimer 등의 설정을 더 엄격하게 변경했기 때문이며, 이로 인해 일반적인 NAS 설정과는 호환성 문제가 발생했습니다. 당장의 해결책으로 맥의 /etc/nsmb.conf 파일을 수정하여 검사를 완화하거나 NAS의 SMB 설정을 조정하는 방법이 제시되었습니다. 하지만 저자는 애플과 시놀로지 간의 호환성 줄타기에 지쳐, Proxmox와 ZFS 위에 Docker 컨테이너(mbentley/timemachine)를 띄워 직접 Samba를 제어하는 ‘탈(脫) 어플라이언스’ 방식을 선택했습니다.
기술적 인사이트
이 이슈는 단순히 ‘설정을 바꿔라’는 팁을 넘어, 독점적 생태계(Apple)와 표준 프로토콜(SMB) 간의 미묘한 긴장 관계를 보여줍니다. 소프트웨어 엔지니어 관점에서 볼 때, OS 레벨의 기본값 변경이 상위 애플리케이션(백업)의 가용성을 어떻게 해칠 수 있는지 보여주는 좋은 사례입니다. 특히 저자가 선택한 Docker 기반 솔루션은 ‘인프라의 코드화(IaC)’ 관점에서 의미가 큽니다. NAS 제조사의 펌웨어 업데이트나 애플의 변덕에 의존하지 않고, 백업 서비스 데몬을 컨테이너로 격리하여 제어권을 완전히 가져오는 방식은 시스템의 복잡도는 높이지만 장기적인 안정성과 이식성을 보장하는 트레이드오프를 가집니다.
시사점
시스템 관리자나 홈랩(HomeLab) 운영자들은 macOS 업데이트 시 SMB 관련 변경 사항을 면밀히 모니터링해야 합니다. 특히 ‘조용한 실패(Silent Failure)‘를 방지하기 위해 백업 로그를 주기적으로 검증하는 자동화된 절차가 필요합니다. 또한, 기업 환경에서는 상용 NAS의 편리함에만 의존하기보다, 중요 데이터 파이프라인에 대해서는 표준화된 컨테이너 기술을 통해 벤더 종속성을 낮추는 설계를 고려해볼 시점입니다.
애플은 사용자 경험을 중시하지만, 때로는 그들의 ‘용기 있는’ 결정이 파워 유저들의 워크플로우를 파괴하곤 합니다. 당신의 백업 시스템은 벤더의 일방적인 업데이트로부터 안전한가요? 편의성을 위한 완제품 NAS와 통제권을 위한 자체 구축 서버 사이에서, 이제는 후자로 무게중심을 옮겨야 할 때일지도 모릅니다.