Fastlane Match iOS 서명 | 클라우드 Mac 암호화 Git·읽기 전용 HTTPS

단주기 iOS 팀은 TestFlight 빌드를 몰아치기 위해 금속을 사지 않고 일 단위로 클라우드 Mac Runner를 빌립니다. 그런데 서명 단계에서 현실과 맞닥뜨립니다. 일시 디스크, 병렬 Job, 앱 코드와 분리돼야 할 비밀 저장소가 한데 얽입니다. Fastlane Match는 여전히 실용적인 기본값입니다. 인증서와 프로비저닝 프로파일을 Git 안의 암호화 블롭으로 두고, 실행마다 키체인에 주입하기 때문입니다. 실패 패턴은 낡은 프로파일, 패스프레이즈 드리프트, 동일 브랜치를 두 Job이 동시에 쓰는 경쟁처럼 예측 가능합니다. 읽기와 쓰기를 나누고 동시성을 고정하면 대부분 지루한 공학으로 정리됩니다.

앱 ID 패밀리당 쓰기 가능 Match 레인

HTTPS

읽기 전용 CI 클론에 권장 전송

N+1

N을 넘는 Job은 대기열 또는 샤딩

Match와 암호화 Git: Runner에 실제로 내려오는 것

Match는 전용 비공개 저장소에 암호화된 .p12와 모바일 프로비저닝, 메타데이터를 둡니다. 패스프레이즈는 Git에 없고 CI 비밀 관리자에서 환경 변수로 주입합니다. 일 단위 클라우드 Mac에서는 체크아웃 디렉터리를 버리기 쉬운 것으로 취급하세요. 매번 새로 클론하고 아카이브 레인에서는 읽기 전용 모드로 match를 돌리며, 인증서를 갱신하는 관리 Job에서만 readonly: false를 허용합니다. 이 한 줄 정책이 「CI가 내 저장소를 뒤집었다」류 사고 대부분을 없앱니다.

브랜치와 접근 제어

환경마다 기본 브랜치를 두고(예: 프로덕션 서명 자료는 main), 머지 권한을 제한합니다. CI 읽기 토큰은 저장소 범위로 콘텐츠 읽기만 허용합니다. 사람 관리자는 갱신용 자격 증명 경로를 따로 둡니다. Ad Hoc과 App Store 프로파일을 한 저장소에 섞으면 디렉터리 이름을 명확히 나눠 병렬 실행 때 Match 타입이 서로 덮어쓰지 않게 하세요.

설계 목표

일반 파이프라인은 Git 호스트에 읽기 전용으로만 닿고 패스프레이즈와 Apple API 키가 있으면 완료할 수 있어야 합니다. 푸시가 없고, 기능 브랜치가 서명 브랜치를 강제 체크아웃하지 않습니다.

클라우드 Mac Runner에서 읽기 전용 HTTPS 클론

범위가 좁은 개인 액세스 토큰이나 HTTPS에 매핑된 배포 키는, 임대 머신에 복사한 장수 SSH 키보다 감사하기 쉽습니다. GIT_TERMINAL_PROMPT=0으로 두면 대화형 인증이 멈추지 않고 빨리 실패합니다. Match 저장소는 얕은 클론을 선호해 짧은 세션 요금을 줄이세요. 제공업체가 IP를 재활용하면 Git 호스트 속도 제한에 걸릴 수 있으니 백오프는 Match가 아니라 파이프라인 래퍼에 두는 편이 낫습니다.

CI 친화 Git 환경(발췌)

export GIT_TERMINAL_PROMPT=0
export MATCH_READONLY=true   # archive / test 레인
# 선택: 대용량 LFS 블롭에 저속 타임아웃 상향
export GIT_HTTP_LOW_SPEED_LIMIT=1000
export GIT_HTTP_LOW_SPEED_TIME=120

다중 Job 인증서 충돌 의사결정 매트릭스

둘 이상의 동시 Job이 모두 쓰기로 Match를 호출하거나, 동일 app_identifier에 충돌하는 type을 쓰면 Git 푸시나 키체인 설치에서 경쟁이 납니다. 병렬을 키우기 전에 아래 표로 판단하세요. Runner 풀 크기와 macOS 두 번째 파이프라인을 둘지 여부는 2026년 단주기 버스트 빌드: GitLab CI 셀프 호스팅 macOS Runner를 클라우드 Mac에 붙일 때의 Shell Executor, 캐시 키와 태그 전략——GitHub Actions와 혼용할 때의 의사결정 매트릭스와 실행 가능한 파라미터 FAQ를, CircleCI 관리형 macOS와 일 단위 자체 호스팅을 비교하려면 2026년 단주기 iOS 빌드 대안: CircleCI 클라우드 macOS 실행기 vs 일 단위 자체 호스팅 클라우드 Mac Runner——비공개 의존성·동시 실행 상한·대기열 SLO 의사결정 매트릭스 FAQ를 참고하면 됩니다.

병렬 상황	위험	결정
모든 Job이 `MATCH_READONLY=true`, 동일 브랜치	낮음: 읽기 경합만	Runner 간 병렬 허용
읽기 + 갱신 Job 1개 혼합	중간: 푸시 경쟁, 부분 클론	쓰기는 뮤텍스 라벨로 직렬화, 읽기는 다른 Runner
갱신 Job 2개, 동일 식별자	높음: 이중 인증서 발급, Git 충돌	단일 비행 Job으로 하드 게이트, 브랜치 자동 갱신 비활성화
앱은 다르지만 저장소·패스프레이즈 공유	중간: `app_identifier` 사람 실수	저장소 분리 또는 제품마다 `git_branch` 강제

키체인 위생

공유 풀에서 단일 테넌시를 보장하지 않는다면 Job 후 가져온 신원을 지우세요. 그렇지 않으면 다음 테넌트가 메모리나 디스크 흔적으로 서명 자료를 물려받을 수 있습니다. 청소 스크립트를 과금 가능한 체크리스트에 포함하세요.

실행 체크리스트 FAQ

프로덕션 서명을 켜기 전에 새 클라우드 Mac 이미지나 Runner 라벨마다 아래를 실행하세요.

사전 점검 — Xcode 메이저가 DEVELOPMENT_TEAM 설정과 맞고, Apple 중간 인증서가 있습니다.
비밀 — MATCH_PASSWORD, App Store Connect API 키, Match 저장소 전용 Git HTTPS 토큰.
네트워크 — Apple과 Git 호스트로의 443 이그레스 허용, 비대화형(CI=1 등으로 Fastlane 프롬프트 생략).
동시성 — 기본 파이프라인은 MATCH_READONLY, 갱신 워크플로만 해제.
Job 후 — 공유 풀은 키체인 리셋 또는 로그아웃 스크립트, 산출물 업로드, 임시 디렉터리 삭제.

FAQ 요약

「Codesign이 키체인 접근을 요청합니다」 — CI에서는 로그인 키체인이 아니라 $TMPDIR의 일회용 키체인 파일로 잠금 해제하세요. 스프린트 중 프로파일 만료 — 갱신 레인을 단 한 번 돌리고 프로파일을 올린 뒤 Match 저장소에 커밋한 다음 읽기 전용 Job을 전개하세요. 앱 두 개, 번들 ID 오타 하나 — 컴파일이 아니라 업로드에서 터집니다. 아카이브 전 gym 메타데이터 검사를 넣으세요.

Match 쓰기를 아예 피할 때

엔터프라이즈 내부 빌드만 소비한다면 서명 자산을 비공개 아티팩트 버킷에 미리 구워 Runner에서는 Git 쓰기를 생략할 수도 있습니다. 그래도 App Store 레인은 사람에게 단일 진실이 되도록 Match를 유지하는 편이 안전합니다.