Developer ID G1 만료, Mac 설치 패키지 서명은 어떻게 이전할까? 2026

Developer ID G1 만료에 대응하려면 먼저 서명 체인이 실제로 G1에서 발급됐는지 확인하고, 산출물 종류에 따라 조치해야 합니다. 대상 인증서로 서명한 설치 패키지는 기한 전에 G2 인증서로 다시 서명해 설치까지 검증하되, 보안 타임스탬프가 있는 기존 공증 앱까지 같은 방식으로 처리하지는 않습니다.

macOS 앱 출시 책임자라면 현재 서명 자산이 영향을 받는지 확인할 수 있습니다.
CI/CD 플랫폼 엔지니어라면 인증서와 키체인, 산출물 검사 단계를 점검할 수 있습니다.
기업 IT 담당자라면 운영 배포와 분리된 맥 빌드 환경에서 변경 사항을 검증할 수 있습니다.

인증서 만료일과 발급 체인 비교

Apple은 2026년 10월 1일 공지에서 기존 Developer ID Certification Authority인 G1이 2027년 2월 1일 만료된다고 밝혔습니다. 다만 인증서 이름이나 만료일만 보고 영향 여부를 단정하면 안 됩니다. 같은 이름의 Developer ID 인증서가 서로 다른 중간 인증 기관에서 발급될 수 있으므로 발급자 정보를 확인해야 합니다. Apple의 G1 만료 공지와 이전 Sub-CA 발급 인증서 식별 안내를 기준으로 확인하세요.

다음처럼 인증서와 결과물을 나눠 점검합니다.

키체인 접근에서 해당 인증서의 발급자 이름을 펼쳐 조직 단위를 확인합니다. Apple 안내에 따르면 조직 단위가 Apple Certification Authority이면 이전 Sub-CA 발급이며, G2이면 현재 기관 발급입니다. 만료일만 보고 발급 체인 확인을 건너뛰지 마세요. pkgutil --check-signature로 PKG 서명 정보를 검사하고, 앱은 codesign -dvv로 서명 정보와 타임스탬프를 점검할 수 있습니다. 인증서 종류와 교체 절차는 Apple의 Developer ID 인증서 문서에서 확인할 수 있습니다.

PKG와 공증 앱에 미치는 영향 비교

이 변경에서 배포 차질을 직접 확인해야 하는 대상은 영향을 받는 인증서로 서명한 설치 패키지입니다. Apple은 2027년 2월 1일부터 해당 PKG가 설치되지 않는다고 명시했습니다. 반면 보안 타임스탬프가 포함된 기존 공증 맥 소프트웨어는 계속 작동하며, 이후 업데이트는 새 인증서로 서명하고 공증에 필요한 타임스탬프를 포함해야 합니다. 이 규칙을 모든 앱, DMG, ZIP에 동일하게 적용되는 것으로 확대 해석해서는 안 됩니다. 산출물별 안내는 Apple의 G1 만료 공지에서 확인하세요.

실제 점검에서는 설치 실패 메시지, 패키지에 표시된 서명자, 인증서 체인을 함께 기록합니다. 예를 들어 CI가 빌드 성공을 반환해도 릴리스 폴더에 남아 있는 PKG가 예전 Developer ID Installer 인증서로 서명되어 있을 수 있습니다. 빌드 성공, 새 서명 확인, 대상 맥에서의 설치 성공은 서로 다른 통과 조건으로 관리하는 편이 안전합니다.

G2 선택과 도구 체인 점검

대체 인증서를 만들 때는 인증서 종류뿐 아니라 발급 중간 기관도 확인해야 합니다. PKG용 인증서는 Developer ID Installer, 앱 코드용 인증서는 Developer ID Application입니다. 두 인증서는 서로 대체할 수 없으며, 둘 다 필요하다면 각각 준비해야 합니다. 인증서 생성 과정에서 Developer ID Certificate Intermediary를 선택하라는 안내가 나오면 G2 Sub-CA를 선택합니다. 다른 항목을 선택하면 만료 예정인 기관에서 인증서가 발급될 수 있다고 Apple은 안내합니다.

기존의 오래된 Xcode를 유지해야 한다면 인증서 발급 전에 Apple의 지원 버전 안내를 확인하세요. Apple은 Xcode 11.4 이하 사용 팀에 업데이트를 안내하고 있으며, G2 선택 옵션은 Xcode 11.4.1 이상 기준으로 안내됩니다. 이 버전 정보와 교체 지침은 Apple의 G1 만료 공지에 정리되어 있습니다.

G2는 중간 인증 기관 이름이지, 발급받은 개별 인증서의 유효 기간이 항상 길다는 뜻은 아닙니다. Apple 공지 기준으로 G2 기관은 2031년까지 유효하지만, 여기서 발급되는 개별 인증서는 매년 갱신해야 합니다. 갱신 책임자와 만료 알림을 CI 운영 절차에 포함하세요.

맥 CI 서명 전환과 설치 검증

다음 절차는 CI가 새 인증서로 실제 서명하고 배포 가능한 PKG를 만드는지 확인하는 데 초점을 둡니다.

• 인증서 목록 작성: 배포 중인 앱과 PKG별 서명 인증서, 발급자, 키체인 위치, 담당자를 기록합니다. 인증서 표시 이름만 같고 발급 체인이 다른 경우를 구분합니다.
• 대체 인증서 생성: 필요한 인증서 유형을 각각 준비하고, 발급 과정에서 G2 Sub-CA가 선택됐는지 확인합니다. 기존 인증서는 테스트가 끝나기 전에 삭제하거나 폐기하지 않습니다.
• CI 노드의 서명 자산 확인: 빌드 작업이 사용하는 키체인에 인증서와 대응 개인 키가 있는지 검사합니다. 서명 단계가 로컬 개발자의 키체인에 기대고 있지는 않은지도 점검합니다.
• 시험 빌드 서명: 실제 출시 흐름을 대표하는 앱과 PKG를 만들고, 앱에는 요구되는 공증 절차를 적용합니다. 공증을 위한 서명에는 보안 타임스탬프가 필요합니다. 자세한 내용은 Apple의 공증 전 서명 안내에서 확인할 수 있습니다.
• 산출물 체인 검사: 앱과 PKG의 서명 정보를 각각 기록합니다. 빌드 로그의 성공 문구만으로 인증서 전환을 승인하지 않습니다.
• 대상 맥 설치 확인: 배포 대상과 유사한 맥에서 새 PKG 설치를 시험하고, 설치 결과와 오류 메시지를 보관합니다. 공증 처리와 PKG 설치 검증은 별도 결과로 남깁니다.
• 출시 승인과 비밀 정보 보호: 검증한 인증서 식별 정보와 산출물 해시, 검사 결과를 릴리스 기록에 연결합니다. 개인 키와 인증서 비밀 정보가 빌드 로그에 출력되지 않도록 마스킹과 접근 권한을 점검합니다.

macOS CI 서명에서 자주 생기는 관리상 함정은 “CI가 성공했으니 새 인증서 적용도 끝났다”고 판단하는 것입니다. 새 인증서를 등록했더라도 파이프라인 변수나 키체인 검색 순서가 이전 신원을 선택할 수 있습니다. 그러므로 대표 빌드마다 서명자와 발급자, PKG 설치 결과를 함께 확인해야 합니다. 기존 인증서로 계속 서명하는 동안 관련 중간 인증서를 유지해야 하는 조건은 Apple의 중간 인증서 지원 안내를 참고하세요.

격리 검증 환경과 운영 전환

운영 배포를 바로 바꾸기보다 대표 프로젝트를 복제한 검증용 맥 환경에서 새 인증서 체인과 설치 절차를 시험하는 편이 위험을 줄입니다. 검증 환경과 운영 환경의 Xcode 버전, 키체인 구성, 네트워크 접근, 공증 인증 정보가 다르면 결과가 달라질 수 있으므로 차이를 기록하세요. 인증서와 개인 키는 접근 권한이 제한된 방식으로 전달하고, 로그나 예제에 비밀 값을 남기지 않습니다.

이 글에서는 실제 xcodeops 맥 구성, 제공 방식, 서명 이관 테스트 기록과 산출물 검증 결과가 제공되지 않았으므로 특정 환경의 성능이나 설치 성공을 실측 사례로 제시하지 않습니다. 검증 설계를 시작할 때는 가이드 모음과 데이터 보호 안내을 먼저 살펴보세요.

현재 방식과 원격 맥 환경의 선택

개발자별 실기기를 늘리는 방식은 장비 구매와 유지 관리가 필요하고, 기존 공용 빌드 노드만 쓰는 방식은 테스트 변경을 운영 배포와 분리하기 어려울 수 있습니다. 가상 환경만으로 실제 맥의 서명·설치 동작을 대체하려는 경우에도 대상 환경과의 차이를 검증해야 합니다. 반대로 안정적인 장기 고부하 작업이나 물리 인터페이스가 필요한 팀에는 장비를 직접 운영하는 편이 더 적합할 수 있습니다.

출시 전 별도 맥 환경이 필요한 팀은 원격 맥을 시험 선택지로 검토할 수 있습니다. xcodeops 환경이 요구하는 격리 수준과 인증서 전달 방식에 맞는지는 실제 도입 전에 확인해야 합니다. 검증용 환경이 꼭 필요한 경우에만 원격 맥 환경 문의에서 제공 방식과 시험 조건을 확인하세요.

마지막 업데이트: 2026년 10월 26일. 날짜와 인증서 범위는 Apple의 2026년 10월 1일 공지, 인증서 교체 안내, 중간 인증서 지원 문서를 대조해 확인했습니다.