2026원자 배포rsync

2026 원격 Mac 빌드 산출물 원자 배포: in-place SFTP 대비 rsync 스테이징·심볼릭 전환

원격 Mac에 산출물을 올릴 때 운영 트리를 SFTP로 바로 덮어쓰면 전송 창 동안 신·구 파일이 섞여 사용자와 CDN에 불일치가 퍼질 수 있습니다. releases/타임스탬프로 rsync한 뒤 검증하고 ln -sfn으로 current만 바꾸면 스냅샷 일관성과 초단위 롤백을 동시에 얻습니다. 비교표, 다섯 단계 명령, 디스크 여유 2.5배·타임아웃 3배 같은 게이트, 감사 로그 필드, 그리고 자체 장비 대비 SFTPMAC 같은 호스팅 원격 Mac이 주는 운영 이점을 정리합니다. 관련 글: SFTP·rsync GUI 선택, 권한·감사 비교.

원자 배포rsyncCI/CD원격 Mac
1. 세 가지 운영 통증2. in-place가 위험한 이유3. 비교표4. 다섯 단계5. 게이트·감사6. 롤백·SFTPMAC
원격 Mac에서 rsync 스테이징과 심볼릭 전환 개념

2026년에 자주 나타나는 세 가지 통증

1) 읽기·쓰기 교차. 새 HTML과 옛 자산이 동시에 노출될 수 있습니다.

2) 부분 실패 후 모호함. 어떤 트리가 마지막으로 신뢰할 만한지 이름을 붙이기 어렵습니다.

3) 계정·감사. 공유 SFTP 계정은 로그 해상도를 떨어뜨리고 키 순환을 어렵게 합니다.

왜 in-place SFTP는 여전히 고위험인가

핵심은 공개 문서 루트를 계속 변형한다는 점입니다. 새 디렉터리에 완전한 스냅샷을 만든 다음 심볼릭만 전환하면 검증이 끝날 때까지 외부에 보이는 경로는 이전 버전을 가리킵니다.

의사결정 표

항목직접 덮어쓰기releases + current
혼합 노출길다전환 순간에 집중
롤백재업로드 분 단위이전 폴더 유지 시 초 단위
CI 적합성순서 실수 위험동기화·게이트·전환 3단계 표준화

다섯 단계 예시

TS=$(date +%Y%m%d%H%M)
mkdir -p /srv/app/releases/$TS
rsync -av --delete-after --exclude '.git' ./dist/ deploy@remote-mac:/srv/app/releases/$TS/
ssh deploy@remote-mac "test -f /srv/app/releases/$TS/index.html && shasum -a 256 /srv/app/releases/$TS/index.html"
ssh deploy@remote-mac "ln -sfn /srv/app/releases/$TS /srv/app/current && readlink /srv/app/current"

게이트와 감사

최대 릴리스 크기의 2.5배 이상 여유 디스크, CI 타임아웃은 중앙값의 3배, 로그에는 주체·UTC 시각·호스트·$TS·전환 전후 readlink를 남기고 90일 보관을 권장합니다.

롤백과 SFTPMAC 원격 Mac

  • 이전 $TS 디렉터리 무결성 확인
  • ln -sfn으로 current 복구
  • 해시 샘플링과 오류율 모니터링

패턴은 자체 Mac·클라우드·호스팅 노드 모두 동일하고, 차이는 디스크·회선·가용성 운영 부담입니다. 배포 빈도가 높아질수록 디렉터리 격리와 SFTP 접근을 플랫폼에 맡기는 편이 비용 대비 안정적입니다.

SFTPMAC는 격리 경로 안에서 동일한 rsync·심볼릭 운용을 유지하면서 도달성과 권한 기준선을 서비스 측에서 지원합니다. 맺음말로, 자체 노드의 한계는 야간 장애 대응과 키·권한 드리프트에 시간이 소모된다는 점이며, 원격 Mac 임대로 Apple 환경에서의 배포 파이프라인을 더 예측 가능하게 만들 수 있습니다.

원자 배포를 유지하며 운영 노이즈를 줄이려면 SFTPMAC 플랜과 노드 규격을 검토하세요.