팀 iOS CI 인증서 교체는 어떻게 할까요? Fastlane Match 2026

CI 빌드는 성공하는데 배포 서명에 쓰는 인증서와 개인 키가 어떤 Mac에 있는지 확신하기 어렵습니까?
이번 주에는 자산과 의존 작업부터 기록하고, Fastlane Match로 새 서명 자산을 단계별 동기화한 뒤, 실제 Mac CI에서 빌드와 아카이브를 검증하세요. 성공을 확인하기 전에는 기존 자산을 폐기하지 마세요.

기업 IT 책임자는 승인, 책임자 지정, 복구 기준을 정해야 합니다.
플랫폼 엔지니어는 CI가 기존 서명 자산만 안전하게 읽도록 구성해야 합니다.
iOS 릴리스 엔지니어는 새 자산으로 실제 아카이브와 배포 경로가 작동하는지 확인해야 합니다.

시작 시점: 교체 범위와 출시 영향을 먼저 가릅니다

팀 iOS CI 인증서 교체는 인증서 파일을 바꾸는 작업만으로 끝나지 않습니다. 개인 키, iOS provisioning profile, 앱 식별자, CI Secret, Keychain 접근 권한이 함께 맞아야 빌드 결과물에 올바른 서명이 적용됩니다.

개발, 배포, 내부 테스트에 쓰는 자산을 나누고, 각 자산의 소유자와 사용 중인 앱 및 파이프라인을 기록합니다. Apple은 인증서 종류와 관리 방식을 구분해 안내하므로 Apple의 인증서 유형과 관리 안내를 기준으로 용도를 대조하세요.
Apple Developer 계정에 표시되는 자산과 Mac의 Keychain, CI 설정, 최근 빌드 로그를 서로 확인합니다. 인증서 파일이 존재해도 대응하는 개인 키가 없거나 빌드 계정이 Keychain에 접근하지 못하면 서명에 실패할 수 있습니다.
생성과 관리 권한도 확인합니다. 계정 역할에 따라 가능한 작업이 다르므로 Apple Developer Program 역할 안내에 맞춰 담당자를 정하고, 개인 계정이나 공유 계정에 작업이 묶이지 않게 합니다.

전환 전 기준선: 현재 동작을 재현 가능한 상태로 남깁니다

새 인증서를 만들기 전에 현재 Mac CI가 어떤 서명 자산으로 어떤 작업을 완료하는지 기록합니다. 기준선이 없으면 교체 후 오류가 새 자산 때문인지 기존 환경 차이 때문인지 구분하기 어렵습니다.

Xcode 버전, 서명 식별자, 프로비저닝 프로파일, 대상 앱, 빌드·아카이브·배포 작업을 기록합니다. 대표 작업의 로그와 아카이브 결과도 보관해 전환 후 비교할 수 있게 합니다.
인증서와 개인 키가 실제로 짝을 이루는지 확인하고, CI 작업 계정이 필요한 Keychain 항목만 사용할 수 있는지 점검합니다. Xcode에서 팀 서명 인증서를 공유하는 방식은 Apple의 팀 서명 인증서 안내와 대조할 수 있습니다.
작업별 자산의 출처와 복구 담당자를 표시합니다. 서명 실패 때 어느 계정, 저장소, Mac 노드를 확인해야 하는지 불명확하다면 교체를 시작하기보다 소유권부터 정리하세요.

Apple Distribution 인증서가 만료되기 전에 무엇을 준비해야 합니까?
만료일만 보고 즉시 폐기하지 말고, 해당 인증서를 쓰는 앱과 파이프라인, 개인 키, 프로파일을 먼저 연결해 목록화합니다. 새 자산을 준비할 담당자와 승인자를 정하고, 기존 빌드 기준선 및 복구 가능한 서명 자료가 있는지 확인하세요. Apple은 인증서와 프로파일을 별도 자산으로 안내하므로 프로비저닝 프로파일 관리 절차도 함께 확인해야 합니다.

새 자산 준비: 인증서와 프로파일을 함께 점검합니다

새 인증서의 생성·관리는 팀이 쓰는 서명 방식에 맞춰 진행합니다. Xcode, Apple Developer 계정 또는 기존 Fastlane Match 운영 절차 중 무엇을 기준으로 삼는지 먼저 합의하고, 작업을 수행할 계정에 필요한 권한이 있는지 확인하세요.

인증서 변경 뒤에는 연결된 앱 식별자와 프로비저닝 프로파일이 새 서명 자산에 맞는지 확인합니다. 필요한 경우 프로파일을 다시 생성하거나 내려받아 CI에서 사용하는 파일과 일치시킵니다.
인증서, 개인 키, 프로파일을 각각 기록합니다. 인증서는 서명 신원을 나타내고 개인 키는 서명에 필요한 비밀 자료이며, 프로파일은 앱과 허용 조건을 연결합니다. CI Secret은 저장소 접근용 비밀값일 수 있지만, 그 자체가 인증서나 Mac의 호스트 권한을 대체하지는 않습니다.
기존 인증서를 언제 폐기해도 됩니까? 모든 실제 작업이 새 자산으로 통과하고, 백업 노드와 복구 절차까지 확인한 뒤 조직의 승인에 따라 결정합니다. Apple은 인증서를 폐기하면 그 인증서를 포함한 프로비저닝 프로파일이 유효하지 않게 된다고 설명합니다. 따라서 Apple의 인증서 폐기 안내를 확인하고, 폐기를 일반적인 첫 단계로 삼지 마세요.

CI 동기화: Fastlane Match를 읽기 전용으로 운영합니다

Fastlane Match는 팀의 인증서와 프로비저닝 프로파일을 동기화하는 데 쓸 수 있습니다. 다만 Match 설정만으로 기업의 승인 절차가 자동화되거나 Mac 호스트가 다른 작업과 격리되는 것은 아닙니다.

우선 분리된 Mac 빌드 환경에서 대상 앱과 서명 유형에 맞는 동기화 결과를 확인합니다. 운영 CI는 새 자산이 승인된 저장소에서 내려오는지 확인한 뒤 적용합니다.
정식 빌드 작업은 새 자산을 임의로 만들거나 저장소 내용을 바꾸지 않도록 읽기 전용 모드로 구성합니다. Fastlane 문서의 Match 읽기 전용 설정과 동작 설명을 확인하고, 실제 lane과 환경 변수에 설정이 반영됐는지 점검하세요.
암호화된 인증서 저장소, 복호화 암호, CI Secret 각각의 접근자를 정합니다. Secret이 노출될 수 있는 로그와 작업 환경을 제한하고, CI Secret 관리 안내 및 손상된 runner의 위험 설명에 맞춰 실행 환경과 권한을 검토합니다.

Fastlane Match가 CI에서 기존 인증서와 프로파일만 읽게 하려면 어떻게 합니까?
Match의 읽기 전용 옵션을 운영 lane에 지정하고, 해당 작업이 자산을 생성하거나 수정하지 않는지 검증합니다. 복호화에 필요한 Secret의 노출 범위도 제한해야 합니다. Secret 접근을 제어하는 것과 Mac 호스트 자체를 격리하는 것은 별개의 통제입니다.

Mac CI 검증: 녹색 빌드만으로 완료 처리하지 않습니다

전환은 실제 결과물의 서명까지 확인해야 끝납니다. 동일한 프로젝트와 작업을 새 자산으로 실행하고, 기존 기준선과 로그 및 결과물을 비교하세요. Apple의 프로비저닝 프로파일과 서명 로그 기술 안내를 참고하면 서명 실패 원인을 좁히는 데 도움이 됩니다.

대표 프로젝트로 빌드와 아카이브를 수행하고, 팀에서 사용하는 테스트 배포 또는 정식 배포 경로도 확인합니다.
결과물에 들어간 서명 식별자와 프로파일이 의도한 새 자산인지 검사합니다. 파이프라인이 성공 표시를 반환했다는 사실만으로 실제 아카이브의 서명이 맞다고 판단하지 마세요.
인증서 업데이트 후 Mac CI가 새 자산을 쓰는지 어떻게 확인합니까? 빌드 로그의 서명 설정, Keychain의 인증서와 개인 키, 아카이브에 포함된 프로파일을 서로 대조합니다. 하나라도 불일치하거나 핵심 작업이 실패하면 확대 적용을 멈추고, 기록해 둔 기준선에 따라 복구합니다.

퇴역 판단: 증거와 승인 뒤에 기존 자산을 정리합니다

기존 자산의 처분은 일정에 맞춰 일괄 수행하기보다 의존 관계가 끊겼음을 확인한 뒤 결정해야 합니다. 정식 CI뿐 아니라 예비 Mac 노드와 관련 앱도 새 서명 자산으로 검증됐는지 살펴보세요.

새 자산이 확인되면 기존 인증서를 바로 폐기해도 됩니까? 아닙니다. 생산 파이프라인, 예비 노드, 필요한 배포 경로의 검증 결과와 복구 가능성을 확인한 뒤 승인 절차를 밟습니다. 폐기 시 프로파일에 미치는 영향도 다시 검토합니다.
자산 소유자, 변경 승인, 전환 시점, 검증 결과, 복구 조건, 최종 처분을 기록합니다. 유일하게 복구 가능한 서명 자료를 지우거나, 사용 여부가 확인되지 않은 인증서를 폐기하지 마세요.
CI 환경을 바꾸는 과정에 배포 보호 규칙이 있다면 승인 조건과 접근 범위도 함께 검토합니다. 환경 및 배포 보호 규칙 문서에 설명된 기능은 CI 설정에 따라 적용 여부가 다르므로 실제 저장소 구성을 기준으로 판단하세요.

환경 선택: 기존 장비와 원격 Mac의 책임을 나눕니다

팀이 이미 관리하는 Mac은 물리 인터페이스나 내부 네트워크 연결이 필요한 작업에 적합할 수 있습니다. 반면 장비를 새로 구매하면 조달, 유지보수, 교체 주기를 함께 관리해야 하고, 공유 장비는 접근 권한과 Keychain 사용 범위를 따로 통제해야 합니다. 원격 Mac을 이용하더라도 인증서 승인, Secret 보호, 사용자 권한 검토는 팀의 책임으로 남습니다.

아래 조건을 확인해 다음 환경을 선택하세요.

[ ] 물리 인터페이스나 내부 네트워크 연결이 필수라면 팀이 직접 관리하는 Mac을 선택합니다. 원격 환경에서 이 요건을 충족하지 못하면 원격 Mac을 정식 빌드 노드로 전환하지 않습니다.
[ ] 분리된 Mac에서 새 자산으로 빌드와 서명을 확인할 수 있다면 제한된 검증 환경부터 시작한 뒤 운영 CI로 확대합니다. 검증 환경이 없다면 기존 인증서를 유지하고 전환을 보류합니다.
[ ] 운영 CI가 기존 자산을 읽기만 해야 한다면 Fastlane Match를 읽기 전용으로 구성하고 CI Secret 접근 범위를 제한합니다. 자산 생성 권한이 필요하다면 별도 승인 작업과 책임자를 정한 뒤 부여합니다.
[ ] 정식 빌드, 아카이브, 배포 경로와 예비 노드가 새 자산으로 통과했다면 승인 후 기존 자산의 보존 또는 폐기를 결정합니다. 검증되지 않은 작업이 하나라도 있으면 기존 자산을 유지하고 실패 원인을 해결한 뒤 다시 확인합니다.

기존 장비에 필요한 macOS·Xcode 환경과 승인된 네트워크가 갖춰져 있으면 현재 노드를 기준으로 검증하고, 자산 변경만 단계적으로 진행합니다. 사용량이 일시적으로 늘거나 팀원이 같은 물리 장비를 쓰기 어려워 원격 빌드 환경을 검토한다면, 실제 서명 작업에 필요한 접근 방식과 환경 요건을 먼저 정리합니다. 인증서와 개인 키를 원격 Mac에 배포하는 정책은 별도로 승인해야 합니다.

물리 장비가 필수이거나 장기간 고정 부하가 예상되면 직접 관리하는 Mac이 더 알맞을 수 있습니다. 반대로 임시 검증 노드가 필요하다면 VMSPIN 요금 안내에서 조건을 확인하고, 서명 운영 권한을 어떻게 관리할지 정한 뒤 한국 이용 안내를 살펴보세요. 원격 Mac은 구매·유지보수 부담을 줄이는 선택지가 될 수 있지만, 팀의 서명 자산 통제나 호스트 격리를 대신하지는 않습니다.