2026 원격 Mac CI 2단계 배포: S3 호환 스테이징과 rsync/SFTP 원자성·권한 매트릭스

통증 분해: 성공 로그 뒤에도 읽기 측이 깨지는 이유

통증 1: 제자리 덮어쓰기 가시성 창. 테스트 러너가 정합되지 않은 디렉터리를 스캔하면 iOS 같은 강한 의존에서 재현하기 어려운 서명·리소스 오류로 보입니다.

통증 2: 동일 경로에 대한 재시도. CI는 공격적으로 재시도합니다. 버전 키가 없으면 어떤 시도의 바이트인지 설명할 수 없습니다.

통증 3: WAN RTT가 대역으로 보이는 착시. 단일 스트림 SFTP/rsync는 왕복 지연에 취약합니다. 리전 버킷과 멀티파트로 병렬성을 앞당기고 Mac은 짧은 거리 페치에 집중합니다.

통증 4: POSIX 의미는 키만으로 부족. 확장 속성·번들 내부 심볼릭 링크는 APFS 실디렉터리가 필요합니다. 두 번째 단계는 그 번역층입니다.

통증 5: 비용·운영 인력. 라이프사이클·IAM 담당이 없으면 양만 큰 복잡도가 됩니다. 먼저 staging+검증+심볼릭 규율을 고정하세요.

위협 모델과 경계

객체층은 누가 언제 불변 스냅샷을 냈는지를 증명하고 디렉터리층은 어떤 스냅샷이 현행인지를 원자적으로 바꿉니다. 내부 실수가 주 위협이면 staging으로 충분하지만 악의적 치환이 걱정이면 manifest 서명을 추가하고 코드사인 배포 맥락과 맞춥니다.

SSH 멀티플렉싱과 병행할 때 데이터·제어 계정을 분리해 긴 다운로드가 관리 작업을 막지 않게 합니다. Sequoia 무인 rsync는 PATH·ssh-agent 이슈가 다시 등장합니다. Sequoia 가이드를 함께 읽으세요.

측정 지표

PUT/GET 바이트, 멀티파트 실패율, manifest 검증 시간, current 전환 성공, 롤백 횟수를 주간 차트로 남깁니다. 단일 산출물이 약 2GB를 넘고 RTT가 약 180ms를 넘으면 멀티파트가 유리하고, 약 200MB 미만이며 동일 광역이면 staging+전환이 TCO에 유리하기 쉽습니다. inode·스냅샷 여유도 추적하고 DerivedData 동기와 I/O 경쟁을 피해 스케줄을 분리합니다.

비용과 운영 인력을 함께 적는 이유

퍼블릭 클라우드 객체 저장소는 요청 단가와 LIST 호출 패턴에 민감합니다. manifest를 잘게 쪼개면 검증은 쉬워지지만 HEAD/LIST 폭주로 청구서가 커질 수 있으니, 메타데이터를 단일 파일로 묶고 접두사 규칙을 엄격히 유지하세요. 자체 MinIO를 같은 데이터홀에 두면 egress를 줄일 수 있지만 패치·백업·디스크 용량 책임이 이동합니다. 어느 쪽이든 담당자 이름과 점검 주기를 런북에 적어야 TCO 비교가 성립합니다. 장애 훈련에서 checksum 실패·자격 증명 중간 폐기·디스크 90% 채움을 시뮬레이션하고 MTTR을 기록하면 설계의 빈틈이 드러납니다.

7단계 절차

1. 네임스페이스·자격 증명 분리.
2. manifest에 SHA-256·파이프라인 ID·커밋 SHA.
3. 멀티파트로 객체 업로드.
4. Mac inbox로 제한 읽기 계정 수신.
5. 검증 실패 시 전환 중단.
6. releases/BUILD_ID로 이동 후 current 갱신.
7. 텔레메트리·보존 정책.

sha256sum -c manifest.sha256
ln -nfs "/srv/artifacts/releases/$BUILD_ID" /srv/artifacts/current

사람용 SFTP는 upload/만 허용하고 chroot로 폭발 반경을 줄입니다.

관련 읽기

Git 내부·외부 경합은 LFS 글을 먼저 보세요. 2단계는 은탄환이 아니라 격리와 증거를 삽니다. 대역·디렉터리 계약이 계속 병목이면 관리형 원격 Mac으로 가변 요소를 제품화하는 편이 TCO에 유리할 수 있습니다.