iOS 서명 인증서 교체: 2026 기업 CI/CD 점검표

Apple의 Cloud-managed certificate는 만료 90일 전 새 인증서가 자동으로 만들어질 수 있으며, 수동 교체는 유효 기간의 절반보다 짧게 남은 시점부터 가능한 경우가 많습니다. (developer.apple.com) 따라서 iOS 서명 인증서 교체는 만료 당일의 긴급 작업이 아니라, 새 인증서와 Provisioning Profile을 먼저 검증하고 기존 인증서를 나중에 철회하는 방식으로 진행해야 합니다. 개인 키 유출이 의심되면 이 순서를 기다리지 말고 즉시 피해 범위를 줄여야 합니다.

이 글은 다음 담당자를 위한 문서입니다.

• Apple Developer 계정과 서명 권한을 관리하는 기업 IT 관리자
• CI/CD, Keychain, Mac 빌드 노드를 운영하는 플랫폼 엔지니어
• 배포 전환, 긴급 철회와 감사 증거를 승인하는 개발 책임자 및 보안 책임자

SECTION 01 이번 주에 정할 마일스톤과 교체 원칙

이번 주에는 인증서 만료일만 확인하지 말고, 다음 네 가지 승인 지점을 먼저 정해야 합니다.

1. 새 인증서 생성 권한을 누가 행사하는지 정합니다.
2. 새 인증서와 개인 키를 어느 격리된 Mac 노드에 설치할지 정합니다.
3. 실제 보관, 서명, 내보내기, 업로드를 어느 검증 노드에서 수행할지 정합니다.
4. 기존 인증서를 언제 철회할지, 실패 시 어느 경로로 되돌릴지 문서화합니다.

정상적인 만료 교체라면 기존 인증서를 잠시 유지한 채 새 인증서와 새 프로파일을 검증해야 합니다. 반대로 개인 키가 외부로 유출되었거나, 접근 로그에서 비정상 사용이 확인되었거나, 빌드 노드가 통제되지 않는 상태라면 중복 운영을 위해 철회를 늦추면 안 됩니다.

Apple은 인증서 종류마다 만료와 철회의 영향이 다르다고 설명합니다. App Store 배포용 iOS 인증서가 만료되거나 철회되어도 기존 App Store 앱은 영향을 받지 않지만, 해당 인증서로 새 앱이나 업데이트를 업로드할 수 없습니다. 사내 배포 앱은 새 인증서로 다시 서명한 버전을 배포해야 할 수 있습니다. (developer.apple.com)

SECTION 02 첫 번째 역할: Apple Developer 관리자는 무엇을 승인해야 하나요?

Apple Developer 계정에서 가장 먼저 분리해야 할 것은 계정 관리 권한과 빌드 실행 권한입니다. Account Holder와 Admin은 배포 인증서를 만들고 철회할 수 있지만, 이 권한을 CI 노드에 직접 넣을 이유는 없습니다. Apple의 역할 문서에서도 배포 인증서 생성과 철회는 Account Holder 또는 Admin 권한으로 구분됩니다. (developer.apple.com)

관리자는 다음 자산표를 만들어야 합니다.

• 인증서 종류와 현재 상태
• 인증서 지문
• 연결된 Team
• 관련 앱 식별자와 Bundle ID
• 사용 중인 Provisioning Profile
• 실제로 사용하는 Mac 빌드 노드
• 담당 팀과 승인자
• 예정된 교체 방식과 기존 인증서 철회 대상

승인 기록에는 신청자, 인증서 지문, Team, 사용 목적, 연결된 앱, 교체 사유, 철회 예정 대상을 남겨야 합니다. 인증서 파일 이름만으로는 충분하지 않습니다. 여러 노드에 같은 이름의 인증서가 설치되어 있을 수 있고, 개인 키가 없는 인증서는 서명에 사용할 수 없기 때문입니다.

Apple은 배포 인증서를 팀 단위 자산으로 설명하며, Account Holder 또는 Admin만 배포 인증서를 만들 수 있다고 안내합니다. 또한 Apple Account와 인증서, 관련 자격 증명은 민감한 자산이므로 조직 외부에 공유하지 말아야 합니다. (developer.apple.com)

Cloud-managed certificate와 로컬 서명 신원의 선택

Cloud-managed certificate는 Apple Developer 멤버십에 연결되어 원격으로 관리됩니다. Xcode 13 이상에서는 Organizer를 사용하는 배포 흐름에서 클라우드 서명을 활용할 수 있고, 추가 권한을 부여하면 Admin이나 Developer가 해당 흐름을 사용할 수 있습니다. (developer.apple.com)

다만 외부 CI 서버나 수동 서명 흐름에서는 로컬 서명 신원이 필요할 수 있습니다. Apple은 로컬 서명을 사용하려면 활성화된 Apple Distribution 인증서를 Keychain에 추가해야 한다고 설명합니다. 따라서 다음 조건이면 로컬 인증서와 개인 키를 CI 환경에 넣어야 합니다.

• Xcode Organizer가 아닌 외부 CI 명령으로 보관 파일을 생성하는 경우
• 수동 Provisioning Profile을 사용하는 경우
• 사내 배포나 별도 내보내기 옵션을 자동화하는 경우
• 여러 Mac 노드에서 동일한 서명 흐름을 재현해야 하는 경우

반대로 로컬 개인 키를 넣지 않아도 되는 흐름이라면, 불필요하게 개인 키를 여러 노드로 복제하지 않는 편이 안전합니다.

SECTION 03 두 번째 역할: CI 플랫폼 팀은 Mac과 Keychain을 어떻게 분리해야 하나요?

새 인증서를 만들었다고 교체가 끝난 것은 아닙니다. 실제 장애는 인증서 자체보다 개인 키 누락, 잠긴 Keychain, 잘못 선택된 서명 신원, 오래된 프로파일, 로그에 노출된 비밀 값에서 발생합니다.

새 서명 신원은 전용 CI Keychain 또는 동등한 접근 통제 환경에만 넣어야 합니다. 공용 로그인 Keychain에 넣으면 개발자 계정, 다른 프로젝트의 인증서, 테스트 자격 증명과 섞일 수 있습니다.

CI 플랫폼 팀이 확인할 항목은 다음과 같습니다.

• 인증서와 개인 키가 같은 서명 신원을 이루는지 확인합니다.
• CI 프로세스가 사용할 Keychain만 잠금 해제합니다.
• Keychain 접근 권한을 필요한 빌드 프로세스로 제한합니다.
• 인증서 파일과 임시 .p12 파일을 빌드 후 삭제합니다.
• 환경 변수와 로그에서 개인 키 비밀번호를 마스킹합니다.
• 프로젝트가 새 서명 신원을 선택하는지 확인합니다.
• Provisioning Profile의 앱 식별자, Team, 권한 항목을 확인합니다.
• 재부팅 후에도 승인된 방식으로 Keychain이 복구되는지 점검합니다.

Xcode 공식 문서는 외부 빌드 시스템을 사용하는 경우 서명 신원을 직접 관리하고, 팀 구성원 사이에서 신원을 안전하게 공유하며, 각 환경의 로컬 신원을 Developer 계정과 동기화해야 한다고 설명합니다. 또한 인증서만 있고 대응하는 개인 키가 없으면 코드 서명에 사용할 수 없습니다. (developer.apple.com)

여러 Mac 노드를 같은 상태로 만들 때의 기준

각 Mac 노드에서 다음 정보를 별도로 수집해야 합니다.

• 새 인증서의 지문
• 대응하는 개인 키의 존재 여부
• 전용 Keychain의 잠금 상태와 접근 권한
• 새 Provisioning Profile의 파일명과 만료 상태
• Xcode가 선택한 Team과 서명 신원
• 보관, 서명, 내보내기 단계의 성공 여부
• 실패 시 이전 신원으로 되돌릴 수 있는지 여부

한 대의 Mac에서 빌드가 성공했다고 해서 전체 CI가 완료된 것은 아닙니다. 노드별 운영체제 상태, Keychain 권한, 파일 경로, 환경 변수와 캐시가 다를 수 있기 때문입니다. 특히 공유 Mac 빌드 서버를 사용하는 경우에는 프로젝트별 Keychain을 분리하고, 서로 다른 팀의 서명 자산이 같은 작업 디렉터리에 남지 않도록 정리해야 합니다.

SECTION 04 세 번째 역할: 배포 책임자는 새 서명 체계를 어떻게 검증해야 하나요?

배포 책임자는 새 인증서가 존재한다는 사실이 아니라, 실제 출시 경로가 끝까지 통과했다는 증거를 받아야 합니다.

검증은 비핵심 브랜치나 독립 검증 노드에서 시작합니다. 새 인증서를 사용해 다음 단계를 순서대로 실행합니다.

1. 프로젝트의 서명 설정과 Team을 확인합니다.
2. Bundle ID와 App ID가 일치하는지 확인합니다.
3. 필요한 Entitlements가 새 Provisioning Profile에 포함되었는지 확인합니다.
4. Xcode에서 보관 파일을 생성합니다.
5. 새 인증서로 서명된 결과물을 내보냅니다.
6. TestFlight 또는 승인된 업로드 경로로 전송합니다.
7. 업로드 결과와 빌드 아카이브를 보관합니다.
8. 기존 인증서를 선택한 이전 경로도 별도로 확인합니다.
9. 새 경로와 이전 경로 중 어느 쪽을 생산 기본값으로 할지 승인합니다.

Apple의 문서에 따르면 Provisioning Profile은 앱 식별자와 배포 인증서를 연결하며, 수동 서명에서는 새 인증서를 선택해 프로파일을 만들고 다운로드해야 합니다. 자동 서명을 사용하면 Xcode가 앱 내보내기 과정에서 프로파일을 갱신할 수 있지만, 기업 CI에서는 그 결과가 모든 노드에 동일하게 반영되었는지 확인해야 합니다. (developer.apple.com)

인증서만 바꾸면 실패하는 이유

인증서와 Provisioning Profile은 별개의 파일이지만 서명 체계에서는 함께 움직입니다. 새 인증서가 기존 프로파일에 포함되지 않았거나, 새 프로파일의 App ID가 프로젝트의 Bundle ID와 다르면 다음 단계에서 실패할 수 있습니다.

특히 다음 항목을 함께 대조해야 합니다.

• Bundle ID
• App ID
• Team ID
• Entitlements
• 배포 방식
• 인증서 지문
• 프로파일 만료 상태
• Xcode의 수동 서명 설정
• CI 스크립트에서 지정한 파일 경로

Apple은 프로파일이 만료되거나 인증서를 철회한 경우 프로파일을 다시 생성해야 한다고 안내합니다. 철회된 인증서를 포함한 프로파일은 유효하지 않으므로, 기존 인증서를 먼저 없애는 작업은 검증이 끝난 뒤에 수행해야 합니다. (developer.apple.com)

SECTION 05 네 번째 역할: 보안 책임자는 언제 기존 인증서를 철회해야 하나요?

보안 책임자는 새 인증서가 만들어졌다는 이유만으로 철회를 승인하면 안 됩니다. 다음 증거가 모여야 합니다.

• 새 인증서의 지문과 개인 키 확인 결과
• 모든 생산 Mac 노드의 설치 상태
• 새 Provisioning Profile 생성 및 배포 결과
• 실제 보관과 업로드 검증 결과
• 기존 인증서를 사용하는 파이프라인 목록
• 실패 시 복구 절차
• 접근 권한 변경 기록
• 철회 후 예상되는 프로파일 무효화 범위

정상적인 만료 교체라면 새 인증서를 먼저 배포하고, 검증 노드와 생산 노드에서 새 흐름이 통과한 뒤 기존 인증서를 철회합니다. 이때 기존 인증서를 포함한 Provisioning Profile이 함께 무효화될 수 있으므로, 관련 프로파일을 다시 생성할 계획이 있어야 합니다. (developer.apple.com)

개인 키 유출이 의심되는 경우는 다릅니다. 외부 저장소에 키가 올라갔거나, 관리되지 않는 장비로 복사되었거나, 접근 로그에 설명할 수 없는 사용이 있으면 정상적인 중복 전환을 기다리지 않습니다. 우선 계정과 빌드 환경의 접근을 차단하고, 영향을 받은 인증서와 프로파일을 식별한 뒤 긴급 철회 범위를 결정해야 합니다.

Apple은 인증서 종류에 따라 철회 권한과 처리 방식이 다르다고 안내합니다. App Store 배포 인증서는 Account Holder 또는 Admin이 철회할 수 있지만, 일부 인증서는 개발자 계정에서 직접 철회하지 못하고 Apple 지원 절차가 필요할 수 있습니다. (developer.apple.com)

SECTION 06 다섯 번째 역할: 인프라 책임자의 Mac 노드 준비 기준

인프라 책임자는 인증서 교체를 계정 작업으로만 보지 말고, 빌드 노드의 복구 가능성까지 확인해야 합니다. 다음 세 가지 운영 방식을 비교해 결정할 수 있습니다.

생산 빌드 노드에서 직접 교체하는 방식

구성이 단순하고 추가 장비가 필요하지 않다는 장점이 있습니다. 그러나 잘못된 Keychain 권한이나 프로파일 변경이 즉시 생산 파이프라인에 영향을 줄 수 있습니다. 출시 일정이 촘촘하거나 여러 팀이 하나의 노드를 공유한다면 위험이 커집니다.

전용 예비 Mac에서 먼저 교체하는 방식

검증과 복구 경로를 분리하기 쉽습니다. 새 인증서, 새 프로파일, Xcode 설정을 독립적으로 확인한 뒤 생산 노드에 적용할 수 있습니다. 다만 예비 Mac이 실제 생산 환경과 다르면 검증 결과가 재현되지 않을 수 있으므로, Xcode 버전, 프로젝트 의존성, Keychain 구조와 스크립트를 가능한 한 동일하게 맞춰야 합니다.

단기간 원격 Mac 노드를 추가하는 방식

출시나 인증서 교체 기간에만 별도 검증 자원을 확보할 수 있습니다. 다만 네트워크 접근, 비밀 저장소 연결, 원격 재부팅, 접근 권한 회수와 작업 종료 후 데이터 삭제를 함께 검토해야 합니다. 단순히 Mac 한 대를 추가하는 것만으로 격리가 완성되는 것은 아닙니다.

VPSNIX의 원격 Mac 운영 안내를 검토할 때도 독립 검증 노드, 완전한 root 권한, 원격 복구와 작업 종료 후 접근 회수 여부를 먼저 확인해야 합니다. 기업 환경에서는 장비 가격보다 인증서가 남는 위치와 누가 접근할 수 있는지가 더 중요한 판단 기준이 됩니다.

SECTION 07 iOS 서명 인증서 교체용 승인 체크리스트

아래 항목은 역할별 인수인계에 사용할 수 있습니다.

Apple Developer 관리자

• [ ] Account Holder 또는 Admin이 새 배포 인증서 생성을 승인했습니다.
• [ ] 인증서 지문과 연결된 Team을 기록했습니다.
• [ ] 관련 App ID와 Bundle ID를 확인했습니다.
• [ ] 생성자와 승인자를 분리해 기록했습니다.
• [ ] 기존 인증서의 예정 철회 대상을 지정했습니다.

CI 플랫폼 팀

• [ ] 새 인증서와 개인 키가 같은 서명 신원으로 확인되었습니다.
• [ ] 전용 CI Keychain에만 자격 증명을 설치했습니다.
• [ ] Keychain 잠금 해제와 접근 제어를 검증했습니다.
• [ ] 임시 인증서 파일과 비밀번호가 빌드 로그에 남지 않습니다.
• [ ] 모든 Mac 노드에서 인증서 지문을 확인했습니다.
• [ ] 모든 노드에서 새 Provisioning Profile을 확인했습니다.
• [ ] 재부팅 후 Keychain 복구 결과를 기록했습니다.

배포 책임자

• [ ] 비핵심 브랜치에서 보관 파일을 생성했습니다.
• [ ] Bundle ID, Entitlements, Team을 대조했습니다.
• [ ] 새 인증서로 내보내기를 완료했습니다.
• [ ] 승인된 업로드 경로를 통과했습니다.
• [ ] 빌드 아카이브와 업로드 결과를 보관했습니다.
• [ ] 실패 시 이전 경로로 되돌리는 절차를 확인했습니다.

보안 및 인프라 책임자

• [ ] 인증서 접근 권한을 최신 상태로 정리했습니다.
• [ ] 개인 키 유출 여부를 확인했습니다.
• [ ] 철회 대상과 영향받는 프로파일을 식별했습니다.
• [ ] 예비 검증 노드 또는 복구 자원을 확인했습니다.
• [ ] 철회 후 프로파일 재생성 담당자를 지정했습니다.
• [ ] 감사 기록에 생성, 설치, 검증, 승인, 철회 상태를 남겼습니다.

SECTION 08 FAQ: 기업 CI/CD에서 자주 놓치는 판단

iOS 배포 인증서가 만료되기 전에 무엇부터 바꿔야 하나요?

먼저 기존 인증서의 지문, 연결된 앱 식별자, 사용 중인 Mac 노드와 담당자를 기록해야 합니다. 그다음 승인된 Account Holder 또는 Admin이 새 서명 인증서를 만들고, 각 CI 노드의 전용 Keychain에 개인 키와 함께 설치합니다. 새 Provisioning Profile을 생성한 뒤 보관용 빌드가 아니라 실제 보관, 서명, 내보내기, 업로드 흐름까지 확인하고 기존 인증서를 철회합니다.

CI/CD에서 새 인증서를 사용하려면 Provisioning Profile도 다시 만들어야 하나요?

수동 서명 환경이라면 보통 새 인증서를 포함하는 Provisioning Profile을 다시 생성하거나 기존 프로파일을 편집해야 합니다. 프로파일은 앱 식별자와 배포 인증서를 함께 연결하므로 인증서만 교체하면 서명 단계가 실패할 수 있습니다. 자동 서명을 사용하는 Xcode 흐름은 내보내기 과정에서 프로파일을 갱신할 수 있지만, 기업 CI에서는 생성된 프로파일과 실제 노드의 상태를 별도로 확인해야 합니다.

여러 대의 Mac 빌드 노드에 새 서명 인증서를 안전하게 배포하려면 어떻게 해야 하나요?

개인 키가 포함된 서명 신원은 채팅 도구나 공용 폴더로 전달하지 말고, 접근이 제한된 비밀 저장소나 전용 Keychain을 통해 배포해야 합니다. 각 Mac에서 인증서 지문, 개인 키 존재 여부, Keychain 잠금 해제, 프로파일 만료 상태를 따로 확인합니다. 한 노드의 성공을 전체 완료로 간주하지 말고 노드별 로그와 검증 결과를 남겨야 합니다.

Apple Distribution 인증서를 철회하면 이미 출시된 앱도 중단되나요?

App Store에 올라간 기존 앱은 Apple Developer Program 멤버십이 유효한 경우 배포 인증서가 만료되거나 철회되어도 영향을 받지 않습니다. 다만 해당 인증서로 새 앱이나 업데이트를 업로드할 수 없게 됩니다. 사내 배포 앱은 별도 영향이 있으므로 같은 기준으로 판단하면 안 됩니다. Apple은 사내 앱이 새 인증서로 다시 서명된 버전을 배포해야 한다고 안내합니다.

SECTION 09 기존 Mac 환경과 원격 Mac 검증 노드의 선택

현재 생산 Mac에서 인증서를 직접 교체하면 장비를 추가하지 않아도 되지만, 검증과 생산이 한 환경에 섞이고 실패 시 복구 지점이 부족합니다. 여러 팀이 같은 Mac을 공유한다면 Keychain과 작업 디렉터리의 경계도 흐려질 수 있습니다.

반대로 별도 Mac 검증 노드를 두면 새 인증서와 프로파일을 생산 흐름과 분리해 확인할 수 있습니다. 필요한 기간에만 검증 자원을 추가하면 예비 장비를 계속 보유하는 방식보다 운영 선택지가 넓어질 수 있지만, 네트워크 접근과 비밀 저장소 연동을 직접 관리해야 합니다. 따라서 장기적으로 고정된 대규모 빌드가 필요하고 물리 장비를 직접 통제해야 한다면 자체 Mac 구매가 더 적합할 수 있습니다. 인증서 교체, 출시 직전 검증, 일시적인 CI 용량 확장이 목적이라면 원격 Mac 임대가 더 현실적인 선택이 될 수 있습니다.

VPSNIX의 Mac 이용 방식과 요금 안내를 확인할 때는 단순한 월 비용보다 전용 검증 노드 사용 기간, root 권한, 원격 재시작, 작업 종료 후 데이터 정리 절차를 함께 비교해야 합니다. 주문 전 환경 확인에서도 현재 CI가 요구하는 Keychain 접근 방식과 네트워크 정책을 먼저 대조하는 편이 안전합니다.

인증서 교체를 위해 필요한 것은 새 파일 하나가 아니라, 역할별 승인과 노드별 검증 증거가 연결된 운영 체계입니다. 만료 교체라면 새 서명 체계를 먼저 검증하고 기존 인증서를 나중에 철회하십시오. 유출이 의심되면 복구 편의를 위해 철회를 미루지 말고 피해 범위 차단을 우선해야 합니다. 이를 실행할 독립 Mac 검증 노드가 없다면, 일정 기간 전용 원격 Mac을 추가해 실제 CI/CD 배포 흐름을 분리하는 방안을 검토할 수 있습니다.

SECTION 10 자주 묻는 질문 FAQ

추가 읽기

• 엑스코드 클라우드와 아이오에스 빌드 서버의 서명 및 배포 환경 비교