Developer ID 인증서 만료, Mac CI는 어떻게 이전할까? 2026

배포는 통과했는데 기존 인증서가 새 Sub-CA에서 발급됐는지 알 수 없어 Mac CI 전환을 미루고 있나요?

빠른 결론: Apple 개발자 계정과 인증서 체인에서 Developer ID Application 및 Developer ID Installer의 발급 기관을 먼저 확인하세요. 영향을 받는 인증서에는 G2 대체 인증서를 준비하고, 격리된 Mac CI에서 앱과 설치 패키지를 각각 검증한 뒤 생산 작업을 나누어 전환해야 합니다. Apple은 기존 Sub-CA가 2027년 2월 1일에 만료되며, 해당 인증서로 서명한 pkg는 그날 이후 설치할 수 없다고 안내했습니다. 반면 보안 타임스탬프가 있고 이미 공증된 기존 Mac 소프트웨어는 계속 작동합니다. Apple 공지

이 글은 macOS 앱이나 설치 패키지의 서명과 배포를 맡은 엔지니어링 책임자, Mac CI 기반 시설을 관리하는 IT·플랫폼 담당자, Apple Developer 팀의 인증서와 개인 키를 관리하는 계정 책임자를 위한 안내입니다. 현재 사용하는 인증서와 작업의 영향 범위를 확인하고, 검증 증거를 남기면서 교체하려는 경우에 적합합니다.

마지막 확인: 2026년 10월 4일. Apple 개발자 공지와 Developer ID 인증서 교체 안내를 기준으로 정리했습니다. 전환 전에는 Apple의 최신 안내를 다시 확인하세요.

첫 단계: 인증서와 서명 작업의 연결 관계를 기록합니다

인증서 이름이나 만료일만 보고 영향을 판단하면 안 됩니다. 어느 Mac CI 노드가 어떤 인증서를 어떤 작업에 쓰는지부터 목록으로 만드세요. 계정에서 확인한 인증서 정보와 실제 키체인 및 빌드 설정을 대조해야 합니다.

Apple은 Developer ID Application과 Developer ID Installer를 서로 다른 용도의 인증서로 구분합니다. Application은 배포할 앱 서명에, Installer는 설치 패키지 서명에 사용됩니다. 인증서 종류와 용도는 Apple의 인증서 유형 안내에서 확인하고, 계정의 실제 인증서 정보와 함께 기록하세요.

Developer ID 인증서에 연결된 개인 키는 서명에 필요한 자격 증명입니다. 인증서 파일만 복사해 두고 키 접근 권한이나 CI 서비스 계정의 키체인 설정을 확인하지 않으면, 전환 당일 서명 단계에서 실패할 수 있습니다. 팀의 기존 비밀 정보 관리 절차에 따라 접근 주체와 사용 범위를 문서화하고, 로그에 비밀 정보가 출력되지 않는지도 확인하세요.

둘째 단계: 발급 기관으로 기존 Sub-CA 영향을 판별합니다

영향 여부는 인증서의 표시 이름이나 만료일만으로 결정하지 말고, Apple 개발자 계정에 표시되는 정보와 인증서의 발급 기관 정보를 확인해야 합니다. Apple은 기존 Developer ID Sub-CA가 2027년 2월 1일 만료된다고 공지했습니다. 해당 인증서로 서명된 pkg는 그 날짜 이후 설치할 수 없으므로, 패키지 배포 작업은 우선 영향을 확인해야 합니다. 기존 Sub-CA 만료와 영향에 관한 Apple 공지

기존에 공증한 앱은 다시 서명해야 하나요?

Apple 안내에 따르면, 보안 타임스탬프가 포함되고 이미 공증된 기존 Mac 소프트웨어는 계속 작동합니다. 따라서 기존 배포 앱을 일괄 재서명하는 것으로 계획을 시작할 필요는 없습니다. 다만 다음 앱 업데이트의 서명과 공증은 대체 인증서 및 보안 타임스탬프 적용 여부를 확인해야 합니다. macOS 소프트웨어 공증 준비 안내

영향을 받는 인증서로 서명한 pkg는 어떻게 처리하나요?

Apple은 기존 Sub-CA에서 발급된 인증서로 서명한 pkg가 만료일 이후 설치되지 않는다고 안내합니다. 이미 배포한 패키지와 아직 배포하지 않은 패키지를 구별해 기록하고, 새 Developer ID Installer로 서명한 산출물을 설치 단계까지 검증하세요. 앱 서명이 정상이어도 pkg 서명과 설치가 정상이라는 뜻은 아닙니다.

셋째 단계: G2 대체 인증서를 발급하고 CI 접근을 준비합니다

영향받는 인증서가 확인되면 Apple의 교체 안내에 따라 해당 용도의 대체 인증서를 준비합니다. 신청 과정에서는 Developer ID Application인지 Developer ID Installer인지 정확히 선택하고, 발급되는 인증서의 기관 정보가 G2 Sub-CA를 가리키는지 확인하세요. 절차와 계정 조건은 바뀔 수 있으므로 Apple의 Developer ID 인증서 교체 안내를 기준으로 진행합니다.

교체 전에 다음 사항을 확인하세요.

• [ ] 작업별로 필요한 인증서 유형을 구분했습니다.
• [ ] 새 인증서와 연결된 개인 키가 CI 서명 환경에서 사용 가능하도록 준비했습니다.
• [ ] 키체인 접근 권한을 실제 서명 작업을 실행하는 서비스 계정 기준으로 확인했습니다.
• [ ] 인증서 발급 기관과 계정 귀속 정보를 기록했습니다.
• [ ] 개인 키 배포와 보관은 팀의 기존 자격 증명 관리 절차를 따르도록 정했습니다.
• [ ] Apple 계정의 역할, 인증서 생성 도구 및 발급 제한은 교체 실행 시점에 공식 안내로 재확인하도록 담당자를 지정했습니다.

계정에서 인증서를 만들 수 있는 역할이나 도구 조건을 기억에 의존해 적용하지 마세요. 설정이 달라졌다면 발급 단계에서 막히거나, 개인 키가 없는 인증서만 CI에 배포되는 문제가 생길 수 있습니다. 이 단계에서 필요한 사실을 확인할 수 없다면 생산 인증서를 바꾸기 전에 계정 책임자에게 확인을 요청하세요.

격리된 Mac CI에서 앱과 pkg를 따로 검증합니다

기존 생산 작업을 수정하기 전에, 운영 배포와 분리된 Mac CI 노드나 별도 시험 작업에서 새 인증서를 검증합니다. 시험은 개발자 개인 계정이 아니라 실제 CI 서비스 계정으로 실행해야 키체인 권한 문제를 찾아낼 수 있습니다.

새 인증서로 앱 서명과 macOS 공증을 확인하려면 어떻게 하나요?

앱 빌드 후 새 Developer ID Application으로 서명하고, 서명 검증과 공증 제출·결과 확인을 이어서 수행합니다. 산출물이 의도한 인증서로 서명됐는지, 공증이 끝난 뒤 배포에 필요한 티켓 처리까지 정상인지 확인하세요. 공증 오류가 발생하면 인증서 교체 문제라고 단정하지 말고 로그를 보존한 뒤 Apple의 공증 문제 해결 안내를 참고합니다.

CI에서 Developer ID 인증서 교체를 어떻게 병행 검증하나요?

기존 생산 작업의 인증서 설정은 유지한 채, 시험 작업에 새 인증서와 키체인 설정을 별도로 연결합니다. Developer ID Installer로 pkg를 서명한 다음 서명 검증과 실제 설치 동작을 확인합니다. 앱 작업과 pkg 작업은 서로 다른 결과물과 검증 기준을 가지므로 한 작업의 성공 기록을 다른 작업의 승인 근거로 재사용하지 마세요.

각 시험에서 다음 증거를 남깁니다.

• 빌드와 서명을 실행한 작업 및 CI 서비스 계정
• 사용한 인증서 유형과 발급 기관 확인 결과
• 앱 서명, 공증 결과 또는 pkg 서명 검증 로그
• 설치 시험 결과와 최종 배포 산출물의 식별 정보
• 실패 시 재현 가능한 오류 기록과 담당자

한 번 성공한 것으로 운영 승인을 내리지 마세요. 재실행 가능한 로그가 남고, 실제 배포 흐름에 필요한 서명·공증·설치 단계가 모두 확인되어야 합니다.

마지막 단계: 조건을 충족할 때만 생산 작업을 나누어 전환합니다

전환은 모든 Mac CI 작업을 한 번에 바꾸기보다, 영향을 받는 작업과 산출물을 기준으로 범위를 나눠 진행합니다. 먼저 책임자와 변경 대상 설정을 정하고, 시험 결과를 생산 작업의 승인 자료로 연결하세요. 실패 시에는 새 인증서를 사용하는 시험 또는 제한된 작업으로 되돌아갈 수 있도록 하되, 만료되는 인증서가 계속 서명할 것이라는 가정은 롤백 계획에 넣지 않습니다.

전환 조건을 다음과 같이 판단하세요.

• 앱 서명·공증과 패키지 서명·설치가 각각 통과했고 로그가 남았다면 해당 작업 묶음부터 생산 전환을 진행합니다.
• 새 인증서는 준비됐지만 실제 CI 서비스 계정이 개인 키를 읽지 못한다면 권한과 키체인 설정을 수정하고 격리 검증을 반복합니다.
• 발급 기관이나 기존 인증서의 사용 작업을 확인하지 못했다면 전환 범위를 확정하지 말고 목록 작성 단계로 돌아갑니다.
• pkg 설치나 공증 등 필수 검증이 실패했다면 그 작업의 생산 전환을 보류하고 오류 원인을 분리합니다.
• 실패했을 때 만료될 인증서에 의존해야만 복구할 수 있다면 해당 롤백 계획은 승인하지 말고 유효한 대체 서명 경로를 마련합니다.

변경 기록에는 영향을 받는 작업, 교체 인증서, 검증 결과, 승인자, 전환 시점, 복구 조건을 남깁니다. 이 기록이 있어야 인증서 교체가 끝난 뒤에도 어떤 노드와 작업이 새 발급 기관을 사용 중인지 감사할 수 있습니다.

개별 Mac을 직접 구매하면 장기적으로 전용 하드웨어를 통제하기 쉽지만, 초기 구매와 유지 관리 책임이 남습니다. 기존 CI 노드 하나를 계속 공유하면 키체인 권한과 작업 간 의존성이 커질 수 있고, 일반 가상 서버만으로는 macOS 서명 작업을 대신할 수 없습니다. 팀에 임시 검증 노드나 분리된 macOS 릴리스 환경이 필요하다면, 원격 Mac 환경의 제공 범위와 접근 방식을 확인할 때 RUVCLOUD의 한국어 서비스 안내도 살펴볼 수 있습니다. 구체적인 비용과 이용 조건은 RUVCLOUD 요금 안내에서 확인하고, 구매 전에 팀의 서명·격리 요구사항과 맞는지 따져보세요.