클라우드 Mac mini 임대 종료 전 데이터 백업과 개발 환경 이전

금요일 오후, 팀에서 배포를 담당하는 동료가 채팅방에 한마디 물었다. "우리 월 단위로 임대한 Mac mini, 다음 주 수요일에 만료되는데 그 안에 있는 인증서, 시뮬레이터 데이터, Homebrew 캐시는 어떻게 하지?" 아무도 즉시 완전한 목록을 대답하지 못했다 — 이것이야말로 전형적인 이전 실패의 전조다. 클라우드 Mac mini는 쓰기 편하지만, 많은 상태값은 "쓰는 동안에는 어디 있는지 잊어버리는" 것들이라, 정작 마무리할 날이 되어야 십여 개의 디렉터리에 흩어져 있다는 걸 깨닫게 된다.

임대 종료 전 이전 작업은 왜 자주 실패할까

대부분의 사람들이 이해하는 "이전"은 "프로젝트 폴더를 로컬로 복사하는 것"에 머물러 있지만, 실제로 빌드를 막는 것은 대개 숨겨진 설정이다. ~/.ssh에 발급된 배포 키, Keychain 안의 배포 인증서, ~/Library/Developer/Xcode/DerivedData의 증분 빌드 인덱스, 그리고 각종 도구가 사용자 디렉터리 아래에 조용히 써 넣는 캐시 경로들. 이런 것들은 평소에는 눈에 띄지 않지만, 기기가 만료되어 반납되고 나면 다시는 되찾을 수 없다.

이전은 "파일을 백업하는 것"이 아니라 "즉시 작동하는 기기를 재현하는 것"이다. 판단 기준은 "파일을 다 복사했는가"가 아니라 "새 기기에서 빌드를 한 번 돌렸을 때 결과물이 기존 기기와 동일한가"이다.

이전 전 자산 목록: 무엇을 반드시 가져가야 하나

먼저 가져갈 것들을 두 부류로 나눈다. 분류 자체만으로도 누락을 줄일 수 있다.

개발 환경 설정

셸 설정(.zshrc/.zprofile), SSH 키와 known_hosts, Git 전역 설정과 자격 증명, Xcode 서명 인증서와 프로비저닝 프로파일, 그리고 security 명령으로 내보낸 Keychain 항목이 포함된다. 이런 파일들은 용량은 작지만 하나라도 빠지면 안 되므로, 별도로 하나의 아카이브로 묶어두는 것을 권장한다.

프로젝트와 의존성 캐시

코드 저장소(이론상 전부 원격에 있어야 하지만, 로컬에서 아직 push하지 않은 브랜치는 별도로 확인해야 한다), CocoaPods와 SwiftPM의 로컬 캐시, Homebrew로 설치한 패키지 목록(brew bundle dump로 Brewfile을 내보내는 것이 /opt/homebrew 전체를 복사하는 것보다 훨씬 효율적이다), 그리고 Podfile.lock, .xcode-version 같은 잠금 파일들이 포함된다.

3계층 백업 전략: rsync 증분 + tar 아카이브 + 스냅샷 다운로드

한 가지 수단으로 모든 상황을 커버할 수 있으리라 기대하지 말자. 3계층을 조합해야 비로소 안정적이다.

rsync로 증분 동기화하기

로컬에서 시작해서, Mac mini 상의 핵심 디렉터리를 로컬 머신이나 오브젝트 스토리지 마운트 지점으로 동기화한다.

rsync -avz --delete \
  --exclude 'DerivedData' \
  --exclude 'node_modules' \
  dev@hk1.oncemini.com:~/projects/ \
  ~/backup/mac-mini-hk1/projects/

DerivedData, node_modules처럼 재생성 가능한 디렉터리를 제외하면 동기화 시간을 수십 분에서 몇 분으로 줄일 수 있다. 만료 일주일 전부터 매일 한 번씩 실행하는 것을 권장하며, 마지막 날 처음으로 동기화를 시작하는 것은 피해야 한다 — 첫 전체 동기화에 걸리는 시간은 흔히 과소평가되곤 한다.

불변 아카이브 패키징하기

인증서, 키처럼 자주 바뀌지 않지만 절대 잃어버려서는 안 되는 데이터는 별도로 패키징하고 암호화한다.

tar czf keychain-backup.tar.gz \
  ~/Library/Keychains \
  ~/.ssh
gpg -c keychain-backup.tar.gz

암호화한 아카이브는 이후 rsync로 전송하거나 직접 다운로드하여, 평문 키가 전송 경로상에 남는 것을 피할 수 있다.

플랫폼 스냅샷 다운로드를 최후 안전망으로

앞 두 계층이 네트워크 문제로 완료되지 못했다면, 콘솔의 전체 머신 스냅샷 다운로드를 최후의 안전망으로 사용할 수 있다. 다만 사전에 용량을 계산해둬야 한다 — 512GB짜리 시스템 디스크를 가정용 대역폭으로 다운로드하면 몇 시간이 걸릴 수 있으므로, 반드시 여유 시간을 확보해두고 만료 몇 시간 전에 가서야 시작하는 일은 없어야 한다.

흔한 실수와 체크리스트

• brew bundle dump로 Brewfile 내보내는 것을 잊어버려, 새 기기에서 소프트웨어 설치를 전부 기억에 의존하게 되고 버전 번호가 맞지 않는다.
• 프로젝트 코드만 백업하고 .env 안의 로컬 환경 변수를 백업하지 않아, 새 기기에서 빌드할 때 설정 누락으로 오류가 난다.
• 일반 사용자 권한으로 rsync를 실행해서 시스템 수준 인증서 파일의 읽기 권한을 놓치고, 아카이브가 불완전한데도 오류 알림이 뜨지 않는다.
• 만료 몇 시간 전에야 스냅샷 다운로드를 시작해서, 대역폭 변동을 만나면 바로 시간이 부족해진다.
• 이전 후 기존 기기의 키와 토큰을 정리하지 않으면, 임대 종료 후에도 이 자격 증명들이 이론상 여전히 유효한 상태로 남아 보안 위험이 되므로, 마지막 로그인 시점에 능동적으로 폐기해야 한다.

이전 후 새 기기의 콜드 스타트 검증

이전을 마쳤다고 끝난 게 아니다. 새 환경에서 완전한 검증을 한 번 돌려야 비로소 마무리된다.

brew bundle install --file=Brewfile
pod install --repo-update
xcodebuild -workspace App.xcworkspace \
  -scheme App -configuration Release \
  clean build
shasum -a 256 build/App.app/App

신구 두 번의 빌드에서 나온 shasum 출력을 비교해서, 일치해야 비로소 이전이 진짜로 완료된 것이다. 이 단계는 흔히 생략되곤 하지만, "환경에서 아무것도 빠지지 않았다"는 것을 증명할 수 있는 유일하고 객관적인 증거이며, "그럭저럭 돌아가는 것 같다"보다 훨씬 믿을 만하다.

자주 묻는 질문