기업 iOS CI 인증서는 종류와 Apple Developer 계정의 현재 상태를 먼저 확인한 뒤 교체해야 합니다. 연결된 Provisioning Profile을 갱신하고 격리된 Mac CI 노드에서 서명과 전달 경로를 검증한 다음 생산 작업을 전환하세요. 개인 키 유출이 의심되면 정상 교체 절차보다 긴급 대응과 인증서 폐기를 우선합니다.
Apple Developer 계정과 서명 자산을 관리하는 IT 담당자: 인증서 종류, 변경 권한, 폐기 영향을 확인해야 합니다.
iOS CI/CD를 맡은 플랫폼 팀: 프로파일 갱신과 노드 검증, 생산 전환 기준을 정해야 합니다.
배포 및 보안 책임자: 계획된 교체와 키 유출 사고를 구분해야 합니다.
[ SECTION_01 ] 기업 iOS CI 인증서 교체는 자산 확인부터 시작합니다
인증서, 개인 키, Provisioning Profile, Apple Developer 계정 권한, CI 노드 권한은 서로 다른 자산입니다. 하나만 바꿔도 다른 자산이 자동으로 맞춰진다고 가정하면 안 됩니다.
Apple은 개발용, 배포용, Developer ID, 클라우드 관리 인증서를 구분합니다. 각 인증서는 용도와 생성 및 사용 경로가 다르므로, 인증서 이름만 보고 같은 방식으로 교체하지 마세요. 현재 유형과 사용 목적은 Apple의 인증서 유형 및 용도 안내에서 대조할 수 있습니다.
특히 팀 배포, App Store 제출, Mac 앱 배포는 인증서 폐기나 만료의 영향이 같지 않을 수 있습니다. Apple은 인증서를 폐기하면 연결된 프로파일이 영향을 받을 수 있다고 안내합니다. 따라서 먼저 실제 앱과 프로파일의 연결 관계를 확인해야 합니다. 인증서 폐기 시 영향을 확인하는 Apple 안내를 변경 검토에 포함하세요.
Apple Distribution 인증서를 바꾸면 프로파일도 다시 만들어야 하나요?
서명 방식과 프로파일에 포함된 인증서에 따라 다릅니다. 수동 서명이라면 새 인증서가 프로파일의 허용 자산과 일치하는지 확인하고, 필요하면 프로파일을 다시 생성하거나 갱신해야 합니다. Xcode 관리 방식도 새 인증서가 실제 빌드에 적용됐는지 확인해야 합니다. 프로파일이 어떤 인증서와 앱 ID를 참조하는지는 App Store 배포 프로파일 생성 안내에서 확인하세요.
교체 방식은 현재 계정 상태에도 좌우됩니다. 인증서를 새로 만들 수 있는 권한이 있는지, 해당 유형에 기존 인증서와 새 인증서를 함께 사용할 수 있는 조건이 있는지를 먼저 확인하세요. 모든 유형에서 병행 검증이나 무중단 전환이 가능하다고 전제하지 마세요. Apple Developer Program 역할별 권한으로 작업 담당자의 권한도 대조해야 합니다.
[ SECTION_02 ] 전환 전에 현재 배포 경로를 기록합니다
변경 전 기준선이 없으면 새 서명 오류와 기존 파이프라인 문제를 구분하기 어렵습니다. 자산 목록에는 앱 식별자, 배포 방식, 대상 파이프라인, 사용하는 인증서, 개인 키의 보관 위치, 프로파일 연결 관계를 기록하세요.
현재 정상 동작하는 빌드와 배포 경로도 남깁니다. 최근 성공 기록, 빌드 로그, 아카이브 및 전달 결과를 확보하면 전환 뒤 무엇이 달라졌는지 비교할 수 있습니다. 개인 키는 인증서와 별도로 취급하고, 접근 가능한 사람과 자동화 계정을 확인하세요. 계정 권한, 키체인 접근 권한, CI 노드 로그인 권한을 하나의 권한으로 뭉뚱그리지 않는 것이 중요합니다.
변경 승인에는 작업 책임자, 적용 대상, 유지보수 시간, 중단 기준과 되돌림 조건을 명시합니다. 변경 대상 앱이 여러 개라면 릴리스 우선순위와 팀 배포 영향도 함께 기록하세요. 현황은 추정치가 아니라 Apple 계정 기록과 최근 성공한 파이프라인 증거를 기준으로 작성합니다.
[ SECTION_03 ] 첫 단계: 계정 규칙에 맞는 새 서명 자산을 준비합니다
인증서 종류를 확인한 뒤 해당 유형에 맞는 생성, 교체 또는 활성화 경로를 선택하세요. 클라우드 관리 인증서는 일반 인증서와 같은 절차라고 가정할 수 없습니다. Apple이 안내하는 사용 및 교체 조건을 확인하고, 실제 계정에서 가능한 경로인지 검증해야 합니다. 클라우드 관리 인증서 안내를 해당 인증서를 쓰는 경우에만 적용하세요.
개인 키 생성과 전달도 승인된 절차로 수행해야 합니다. 키를 빌드 노드에 배포하기 전에 저장 위치, 접근 주체, 회수 방법을 정하고 변경 기록을 남기세요. 계정 역할이 허용하지 않거나 병행 검증이 불가능하면, 동시 사용을 약속하지 말고 통제된 유지보수 창에서 전환하도록 계획을 바꾸세요.
[ SECTION_04 ] 다음 단계: 프로파일과 서명 설정을 함께 갱신합니다
인증서만 키체인에 추가하고 기존 설정을 그대로 두면, CI가 계속 이전 프로파일이나 이전 서명 자산을 참조할 수 있습니다. 각 프로파일의 앱 ID, 연결된 인증서와 허용 기능이 새 배포 방식에 맞는지 검토하세요.
수동 서명 환경에서는 새 인증서가 들어간 프로파일을 생성하거나 필요한 항목을 갱신하고, 그 결과를 빌드 노드에 배포합니다. Xcode 관리 프로파일을 사용하는 환경은 Xcode가 새 자산을 선택하는지, 실제 아카이브의 서명 결과가 기대한 팀과 인증서에 연결되는지 검사하세요. 프로파일 편집과 재다운로드, 삭제 절차는 Apple의 프로파일 관리 안내를 기준으로 확인할 수 있습니다. 프로파일 갱신이 필요한 조건은 프로파일 업데이트 설명에서도 대조하세요.
만료된 서명 인증서 때문에 배포가 멈춘 경우에는 어떻게 복구하나요?
먼저 실패한 작업이 요구하는 인증서 종류와 프로파일 상태를 확인합니다. 새 인증서만 추가하지 말고, 서명 설정과 프로파일이 함께 새 자산을 참조하는지 검사한 뒤 격리 노드에서 아카이브와 전달을 검증하세요. 만료나 폐기로 기존 프로파일까지 쓸 수 없다면 유효한 프로파일을 준비해야 합니다. 운영 계정의 실제 권한과 Apple의 해당 인증서 규칙을 확인하기 전에는 복구 완료를 선언하지 마세요.
[ SECTION_05 ] 격리된 Mac CI 노드에서 전체 서명 경로를 검증합니다
검증은 정식 생산 작업을 덮어쓰지 않는 별도 작업이나 격리된 Mac CI 노드에서 진행합니다. 대표 앱과 실제 배포 방식으로 빌드하고, 인증서 식별부터 서명, 아카이브, 내보내기, 최종 전달까지 연결해서 확인하세요.
정식 배포에 영향을 주지 않고 새 인증서를 검증하려면 어떻게 해야 하나요?
생산 파이프라인의 인증서나 프로파일을 먼저 교체하지 마세요. 분리된 작업에서 새 자산을 명시적으로 지정하고, 결과 로그와 서명 정보를 검토합니다. 성공 결과가 기존 생산 작업의 설정 변경에 의존하지 않는지도 확인해야 합니다.
검증 중에는 빌드 로그와 결과물의 서명 정보에 이전 인증서나 프로파일이 남아 있지 않은지 살펴보세요. 필요한 권한과 배포 자격 증명이 일치하는지도 확인합니다. Mac CI 서명은 키체인 안의 인증서 유무만으로 완료 판정을 내릴 수 없습니다. 작업 실행 계정이 키에 접근할 수 있는지, 프로파일과 앱의 식별 정보가 맞는지, 최종 전달 경로가 정상인지 함께 봐야 합니다.
전환 전에 다음 항목을 모두 확인합니다.
- [ ] 변경 대상 앱, 파이프라인, 인증서와 프로파일을 목록으로 만들었습니다.
- [ ] 새 자산을 만들거나 활성화할 계정 권한을 확인했습니다.
- [ ] 개인 키의 생성, 보관, 전달, 회수 절차를 승인 기록에 남겼습니다.
- [ ] 수동 또는 Xcode 관리 서명 방식에 맞춰 프로파일을 갱신했습니다.
- [ ] 격리된 Mac CI 작업에서 서명과 아카이브 결과를 확인했습니다.
- [ ] 로그와 결과물에 이전 자산이 남아 있지 않은지 검사했습니다.
- [ ] 생산 중지 기준과 되돌림 조건을 담당자와 합의했습니다.
[ SECTION_06 ] 생산 작업은 나눠 전환하고 구 자산을 정리합니다
격리 검증이 끝나면 앱 또는 파이프라인 단위로 생산 작업을 전환합니다. 전환 직후 첫 배포 결과와 로그를 확인하고, 사전에 정한 실패 조건이 나타나면 다음 작업으로 확대하지 말고 중단 기준에 따라 되돌리세요. 결과가 확인되지 않은 상태에서 구 인증서나 캐시된 프로파일을 일괄 삭제하지 마세요.
새 인증서가 적용된 뒤 기존 인증서는 언제 폐기해야 하나요?
새 자산의 생산 사용이 확인된 뒤에도 구 인증서의 용도와 계정 상태를 검토해야 합니다. 즉시 폐기가 적절한 유형도 있고, 연결된 프로파일에 미치는 영향을 먼저 확인해야 하는 경우도 있습니다. 실제 인증서 규칙과 프로파일 영향에 따라 결정하고, 폐기 권한도 별도로 확인하세요. Apple은 인증서 폐기 권한을 역할별 권한 안내에서 설명합니다.
프로파일이 더 이상 유효하지 않은 상황은 어떻게 확인하나요?
CI 로그의 프로파일 선택 및 서명 오류를 확인하고, 프로파일에 설정된 앱 ID와 인증서가 현재 빌드 자산과 맞는지 대조합니다. 프로파일 파일이 노드에 남아 있다는 사실만으로 유효하다고 볼 수 없습니다. 필요하면 Apple 계정에서 새 프로파일을 생성하거나 내려받고, 격리 작업에서 다시 검증하세요.
개인 키 유출이 의심된다면 계획된 교체와 분리해 보안 사고로 다뤄야 합니다. 파이프라인 전환이 끝날 때까지 기다리지 말고, 계정에서 해당 인증서를 폐기할 권한과 영향을 확인해 긴급 대응을 시작하세요. Apple은 인증서 폐기 절차와 영향을 안내하며, 연결된 프로파일은 별도 점검과 복구가 필요할 수 있습니다. 영향을 받은 키를 사용하던 노드와 자동화 작업도 조사하고, 새 개인 키가 같은 경로로 노출되지 않도록 접근 권한을 재검토해야 합니다.
[ SECTION_07 ] 변경 방식은 검증 가능성과 되돌림 조건으로 판정합니다
- 격리 노드에서 먼저 검증 — 적합: 생산 설정을 보존하면서 새 인증서, 프로파일, 전달 경로를 확인할 수 있습니다. 테스트 결과와 기록이 승인되면 생산 전환으로 진행합니다.
- 생산 노드에서 바로 교체 — 조건부: 격리 검증이 불가능하고 계정 규칙상 병행이 보장되지 않는 경우에만 통제된 변경 창을 검토합니다. 중단 기준과 복구 담당자가 정해지지 않았다면 진행하지 않습니다.
- 유출 의심 키를 그대로 유지 — 부적합: 정상 교체 일정이나 무중단 목표를 이유로 폐기를 미루지 않습니다. 영향 확인과 긴급 폐기, 연결된 프로파일 복구를 사고 대응 절차로 처리합니다.
평가는 속도보다 증거의 완전성으로 내립니다. 자산 목록, 계정 권한 확인, 프로파일 변경 기록, 격리 빌드 결과, 생산 전환 승인, 구 인증서 처리 내역을 한 변경 기록에 모으세요. 이 자료가 이어지지 않으면 전환 완료로 판정하지 않는 편이 안전합니다.
고정된 사내 Mac만 사용하면 장비 구매와 유지 관리, 노드별 키 보관을 직접 책임져야 합니다. 일반 CI 환경에만 의존하면 실제 Mac 기반 서명과 배포 경로를 별도로 검증하기 어려울 수 있습니다. 시험 노드를 잠시 확보하려는 경우에는 Mac mini 대여 비용과 운영 조건을 검토하고, 원격 Mac 환경에서 격리 검증과 접근 권한 설계를 먼저 시험할 수 있습니다. 장기적으로 상시 사용하는 고정 부하나 물리 장치 연결이 필요한 작업은 직접 장비를 운영하는 편이 더 적합할 수 있습니다. 반대로 교체 리허설이나 한정된 시험 환경이 필요한 팀은 NOVAKVM의 Mac 대여를 비교해 보되, 실제 운영 요건과 보안 승인을 충족하는지 확인한 뒤 선택하세요. 자세한 환경 선택은 NOVAKVM의 원격 Mac 안내에서 확인할 수 있습니다.