2026 멀티 리전 원격 Mac에서의 공증과 App Store 업로드
notarytool, Stapler, Transporter 이그레스 및 재시도 플레이북

약 23분 분량 · MACCOME

릴리스 엔지니어 및 iOS 리드가 아카이브, 공증, Transporter 업로드를 싱가포르, 일본, 한국, 홍콩, 미 동부, 미 서부에 걸친 원격 Mac으로 옮길 때, 실패의 대부분은 “코드 서명 방법”이 아니라 공증 대기열, 키체인 맥락, 이그레스 네트워크, 재시도 정책에서 발생합니다. 본 글은 릴리스 런북의 마찰 여섯 가지, 공증과 업로드를 어디에서 실행할지에 대한 매트릭스, 온콜과 맞출 수 있는 세 가지 지표, 비대화형 notarytool 예와 Stapler 전제 조건, 여섯 단계 런북을 제시합니다. Fastlane·인증서 동기화, 재현 가능한 클린 빌드, 멀티 리전 대여 가이드와 함께 읽으십시오. 앞의 두 편은 서명 일관성을 지키고, 본 글은 Apple 공증 서비스와 App Store Connect 이그레스까지 이어 줍니다.

야간에 공증과 업로드가 “무작위로” 실패하는 여섯 가지 이유

Apple 공증 경로는 툴체인 버전, 사용 가능한 자격 증명, Apple 엔드포인트로의 TLS 품질에 달려 있습니다. 원격 데스크톱에는 화면 잠금 세션, 프록시, 기업 이그레스 정책이 더해집니다. CI 재시도 히스토그램 옆에 아래 여섯 항목을 추적하십시오. 리전 역할을 아직 고정하지 않았다면 먼저 멀티 리전 가이드를 읽으십시오.

  1. 키체인과 세션 맥락: 대화형 로그인과 비대화형 SSH는 동일한 키체인 항목을 보지 못합니다. 명시적 잠금 해제나 파티션 플래그 없는 자동화는 “로컬에서는 되지만 CI에서는 불안정”이라는 시간 낭비를 만듭니다.
  2. 제출 대 폴링 타이밍:notarytool submit 이 ID를 반환한 뒤에는 info 를 폴링해야 합니다. 높은 크로스 리전 RTT에서 과도한 폴링은 속도 제한으로 느껴지기 쉽고, 느린 폴링은 릴리스 창을 늘립니다.
  3. 디스크와 임시 공간: 공증은 아티팩트를 풀고 다시 묶습니다. 루트 볼륨 여유와 임시 디렉터리 위치는 명확한 “디스크 부족” 메시지 전에 읽기 오류로 나타날 수 있으며, 재현 가능 빌드 글의 DerivedData 경합과 같은 계열입니다.
  4. Stapler 전제:.pkg, .dmg, 앱 번들마다 경로가 다릅니다. 단계를 건너뛰면 QA의 Gatekeeper 동작이 프로덕션과 달라집니다.
  5. Transporter 대 API 업로드: GUI는 수동 재시도에 유리하지만 감사는 어렵고, API는 파이프라인에 맞지만 JWT 수명, Issuer ID, 개인 키 경로를 Fastlane 비밀 거버넌스와 맞춰야 합니다.
  6. 크로스 리전 “누가 Ship을 누르는가”: APAC 주간과 미 서부 야간이 겹치고 온콜 타임존이 어긋나면 실패율이 올라갑니다. 기술적 잡음으로 보이는 조직적 문제입니다.

이 여섯 가지를 HTTP 상태 분포, 재시도 횟수, 동일 아티팩트를 다른 호스트에서 통과한 비율과 짝지어 “다시 실행”을 실제 이그레스와 매개변수 변경으로 바꾸십시오.

매트릭스: 어떤 원격 Mac 이그레스가 공증과 업로드를 맡을 것인가

조달 검토에서 사용하는 표입니다. 실패 시 누가 디버깅하기 쉬운지어떤 열이 감사 필드에 대응하는지를 비교하고, 순수 속도만으로 결정하지 마십시오. 해당되는 경우 피크 머신 필드를 예산 거버넌스 글과 맞추십시오.

차원아티팩트 홈 리전의 빌드 호스트업로드와 인적 게이트용 전용 “릴리스 노드”
네트워크 경로Git·레지스트리 가져오기와 공증 이그레스가 맞물려 대양 횡단 이중 전송이 줄어듦짧고 단일 목적 경로. Transporter와 수동 확인에 적합
실패 귀속빌드와 공증 로그가 한 호스트 맥락을 공유아티팩트에서 상류 파이프라인 ID로의 명시적 매핑이 필요
키체인 정책CI 사용자와 데몬 모델에 묶임. 장기 실행에 유리업로드 전용 계정으로 노출을 줄일 수 있음. 서명 호스트와 인증서 뷰를 섞지 말 것
타임존과 사람무인 야간 배치에 강함온콜 시간과 겹치는 리전을 선호해 “데스크톱에 닿지 않음” 블로킹을 줄임
디스크와 1TB·2TBDerivedData, 아카이브, 공증 임시를 보관. 피크 주에 맞게 크기정리 정책이 엄격하면 더 작은 디스크도 가능. 정책 없이는 디스크형 실패가 여전히 흔함
대여 믹스월별 베이스라인에 릴리스 주변 단기 피크(멀티 리전 가이드와 동일)단기 대여로 업로드 스파이크를 흡수하고 장기 유휴 비용을 줄임

런북과 YAML에 올릴 세 가지 지표

내부 대시보드에서 수집하십시오. 아래 수치는 설명용 자리 표시자이며 팀 베이스라인으로 바꿔야 합니다.

  1. 공증 폴링 간격(NPI): 고정 5초 notarytool info 루프 대신 지수 백오프(예: 5초→10초→20초, 상한 60초)를 쓰고 최대 대기를 릴리스 창에 맞춥니다. 크로스 리전 RTT가 약 180ms를 넘으면 서비스가 정상이어도 폴링이 너무 촘촘하면 제한으로 느껴질 수 있습니다.
  2. 업로드 복구 창(URW): 동일 아티팩트·동일 이그레스 IP로 Transporter 또는 API 업로드에 필요한 시도 횟수를 추적합니다. Apple 상태 페이지가 녹색인데 URW가 오르면 재서명 전에 기업 프록시와 MTU를 점검하십시오.
  3. 스테이플 전 디스크 안전 여유(DSM):xcrun stapler staple 을 실행할 볼륨에서는 아카이브 크기의 2.5배 이상의 여유 공간을 임시 파티션 포함해 확보합니다. 그렇지 않으면 재현 가능 빌드 체크리스트에 따라 캐시와 아카이브를 정리한 뒤 재시도합니다.

2025~2026년에도 Apple은 공증과 업로드 도구를 Xcode CLI 경로로 수렴시키고 있습니다. xcode-selectnotarytool 버전을 고정하지 않고 Xcode를 섞으면 고전적인 “CI 대 데스크톱 드리프트”가 재발합니다.

bash
# Non-interactive notary submit (replace TEAM_ID, secrets, and paths; never commit keys)
xcrun notarytool submit ./dist/MyApp.pkg \
  --apple-id "[email protected]" \
  --password "@keychain:AC_NOTARY_PASSWORD" \
  --team-id "XXXXXXXXXX" \
  --wait

# App Store Connect API key profile (preferred alignment with Fastlane issuer)
# xcrun notarytool store-credentials --keychain "notary-profile" ...
# xcrun notarytool submit ./dist/MyApp.pkg --keychain-profile "notary-profile" --wait
info

팁: 원격 데스크톱에서는 키체인 프로파일이나 CI에서 주입하는 읽기 전용 키 경로를 선호하고, 셸 기록에 평문 비밀번호를 남기지 마십시오. 로테이션 주기는 Fastlane 글과 맞춥니다.

서명된 아카이브에서 출하 가능 아티팩트까지 여섯 단계

서명과 아카이브가 이미 성공했다는 전제입니다. 그렇지 않다면 먼저 Fastlane과 재현 가능 빌드 글로 돌아가십시오.

  1. Xcode와 CLI 고정: 대상 원격 Mac에서 xcode-select -pxcrun notarytool --version 을 릴리스 티켓에 기록해 출시일의 예기치 않은 전환을 막습니다.
  2. 이그레스 선택: 매트릭스에 따라 빌드 호스트 또는 릴리스 노드를 고르고 IP, 리전 트리플, 대여 필드를 멀티 리전 템플릿과 같은 행에 둡니다.
  3. 제출과 폴링: 비대화형 플래그를 사용하고 NPI 백오프로 폴링하며 맹목적 재시도 전에 로그를 내려받습니다.
  4. 스테이플과 검증: 필요한 위치에서 stapler staple 을 실행하고 spctl 로 점검합니다. 명령 해시를 티켓에 남깁니다.
  5. Transporter 또는 API 업로드: 한 경로로 일관되게 갑니다. API의 경우 JWT 만료, 개인 키 권한, 재시도 정책을 CI 비밀 표 옆에 문서화합니다.
  6. 사후 분석 필드: 분기마다 URW, NPI 상한 도달, DSM 트리거를 구매 대 임대·예산 글과 함께 기록해 릴리스 주 단기 피크 대여를 판단합니다.

M4 대 M4 Pro: 공증 경로에서 먼저 병목이 되기 쉬운 것은 IO

텔레메트리에 공증 로그 다운로드가 느리다, 임시 디렉터리가 들쭉날쭉하다, 로컬 노트북이 더 빠르다는 징후가 있으면 CPU를 늘려도 종단 간 시간은 잘 줄지 않습니다. 멀티 프로젝트 풀 글의 DSM과 캐시 전략으로 돌아가 M4 Pro로 옮기기 전에 동일 리전 아티팩트 경로, 충분한 디스크 여유, 안정적 이그레스를 우선하십시오. 원격 Mac의 가치는 이 사슬을 계약 리전과 대여 조건으로 바꿀 수 있다는 데 있으며 노트북 일대일 대체가 아닙니다.

“노트북에서 한 번 됐다”가 프로덕션 전략이 될 수 없는 이유

개인 노트북에 공증과 업로드를 의존하면 컴플라이언스 검토, 인수인계, 24시간 릴리스 창 아래에서 숨은 비용이 생깁니다. 키는 개인 키체인에 있고 이그레스는 위치에 따라 달라지며 실패는 CI 티켓에 깔끔히 매핑되지 않습니다. 공증과 업로드를 리전 전략에 맞춘 원격 Mac 풀로 옮기면 이그레스, 디스크, 대여 조건을 감사 가능하게 만들고 같은 리전의 OpenClaw Gateway 같은 장수 자동화와도 잘 맞습니다.

범용 클라우드 데스크톱이나 단명 VM도 CLI는 돌리지만 그래픽 세션, USB, 키체인 의미론이 깨져 릴리스 주에 조정 시간이 듭니다. MACCOMEMac mini M4 및 M4 Pro 물리 노드를 싱가포르, 일본, 한국, 홍콩, 미국 연안에서 제공하며 전용 빌드, 공증, 업로드 이그레스에 맞는 유연한 대여 조건을 갖추고 있습니다. 먼저 공개 요금 페이지를 매트릭스 행과 맞춘 뒤 NPI, URW, DSM을 대시보드에 연결하십시오.

파일럿: 이주 동안 서명은 고정하고 아티팩트 홈 원격 Mac 한 대에서만 이그레스와 재시도 매개변수를 바꿔 보십시오. 대부분의 “미스터리 실패”는 설명 가능한 소수 클래스로 수렴합니다.

FAQ

공증은 Fastlane·인증서 글보다 먼저 실행해야 합니까, 나중에 실행해야 합니까?

먼저 서명과 프로파일을 안정화한 뒤 공증과 업로드를 진행합니다. Fastlane·인증서 동기화 글을 대여 요금과 함께 열어 리전과 기간을 한 행에 맞춥니다.

리전과 이그레스는 어떻게 고릅니까?

멀티 리전 대여 가이드를 읽고 빌드·공증·업로드가 한 호스트를 공유하는지 검토 자료에 기록하십시오.

청구와 접근 안내는 어디에서 확인합니까?

고객 센터에서 온보딩과 대표적인 청구 관련 설명을 확인합니다.