Developer ID G2 인증서 이전 방법? 2026 Mac 서명 검수

구형 인증서로 서명한 설치 패키지가 있습니다. G2로 바꿔야 하는지 판단하기 어렵습니다.

가장 빠른 해법은 인증서의 발급 기관을 확인한 뒤 앱과 .pkg를 따로 처리하는 것입니다. Apple은 구형 Developer ID Certification Authority가 2027년 2월 1일에 만료된다고 발표했습니다. 영향을 받는 설치 패키지는 그 전에 대체 인증서로 다시 서명하고, 안전한 타임스탬프가 있고 공증된 기존 앱은 일괄 재서명 대상으로 보지 않습니다. Apple의 만료 공지를 기준으로 전환 계획을 세우세요.

이 글은 Developer ID로 Mac App Store 밖에 앱을 배포하는 독립 개발자, .pkg를 출시하는 Mac 소프트웨어 배포팀, macOS CI 서명 작업을 관리하는 엔지니어를 위한 안내입니다.

마지막 업데이트: 2026년 10월 28일. 날짜와 영향 범위는 Apple의 만료 공지, 인증서 교체 안내와 Developer ID 문서를 대조해 확인했습니다.

인증서 이름보다 발급 기관과 배포물을 먼저 확인합니다

Developer ID G2 인증서 이전 여부는 인증서 이름이나 만료일만 보고 정하면 안 됩니다. 개발자 계정의 인증서 목록과 Mac의 키체인에서 인증서 세부 정보를 열어 발급 기관을 확인해야 합니다. Apple은 Developer ID 인증서 교체 안내에서 교체 절차와 영향을 설명합니다.

먼저 배포물을 분류하세요.

앱은 보통 Developer ID Application 인증서로 서명합니다.
설치 패키지인 .pkg는 Developer ID Installer 인증서로 서명합니다.

둘은 용도가 다릅니다. Apple의 Developer ID 인증서 유형 설명에서도 앱 서명과 설치 패키지 서명에 쓰이는 인증서를 구분합니다.

구형 Sub-CA에서 발급된 인증서인지 어떻게 확인합니까?
개발자 계정에서 인증서 항목을 확인한 뒤, macOS 키체인에서 해당 인증서의 발급자 정보를 살펴보세요. 이름에 “G2”가 있는지, 만료일이 언제인지만으로는 발급 기관을 확정할 수 없습니다. 교체 판단은 Apple이 안내하는 인증서 세부 정보와 발급 기관을 기준으로 해야 합니다.

G2와 구형 인증서는 무엇이 다릅니까?
판단 기준은 표시 이름보다 인증서가 어느 중간 인증 기관에서 발급됐는지입니다. 구형 기관에서 발급된 인증서는 공지된 만료일 이후 서명에 사용할 수 없으므로, 영향을 받는 배포물에 맞는 대체 인증서를 준비해야 합니다. Apple의 중간 인증서 안내에서 관련 기관 정보를 대조할 수 있습니다.

앱과 설치 패키지의 영향은 같지 않습니다. 안전한 타임스탬프가 있고 공증된 기존 앱까지 모두 다시 서명해야 한다고 단정하지 마세요. 반면 영향을 받는 인증서로 서명한 .pkg는 새 인증서로 재서명하는 계획을 세워야 합니다.

독립 개발자는 보유 인증서와 실제 앱 서명을 대조합니다

독립 개발자는 개발자 계정에 인증서가 있다는 사실만 확인해서는 부족합니다. 출시 중인 앱이 실제로 어느 인증서로 서명됐는지, 안전한 타임스탬프와 공증 상태가 확인되는지를 함께 점검해야 합니다.

인증서를 바꾸면 Mac 앱도 모두 다시 서명해야 합니까?
아닙니다. Apple 공지에서 안내한 조건에 맞는, 안전한 타임스탬프가 있고 공증된 기존 앱은 구형 기관 만료만을 이유로 모두 다시 서명해야 하는 것은 아닙니다. 신규 버전이나 다른 조건의 배포물까지 같은 결론을 확대하지 말고, 해당 앱의 서명과 공증 상태를 확인하세요. 서명 및 타임스탬프 관련 내용은 Apple의 코드 서명 인증서 기술 문서를 참고할 수 있습니다.

앱을 다시 출시할 때는 대체 인증서로 시험 서명한 결과를 확인하고, 배포용 앱을 실제 설치 환경에서 검증하세요. 공증 상태나 서명 확인에서 문제가 생기면 임의로 단계를 생략하기보다 Apple의 공증 문제 해결 문서에서 해당 오류의 원인을 확인하는 편이 안전합니다.

배포팀은 .pkg를 앱과 별도 경로로 검수합니다

설치 패키지는 앱 자체의 서명과 별개의 배포물입니다. 앱이 기존 조건에 따라 계속 유효하더라도, 그 앱을 담은 .pkg가 구형 Developer ID Installer 인증서로 서명됐다면 설치 패키지 측의 교체와 재서명이 필요할 수 있습니다.

2027년 2월 1일 이후에도 구형 서명 .pkg를 설치할 수 있습니까?
영향을 받는 구형 인증서로 서명한 패키지가 그 날짜 이후에도 정상 설치될 것이라고 전제하지 마세요. Apple 공지에 맞춰 기한 전에 대체 인증서로 재서명하고, 새 패키지의 설치 결과까지 확인해야 합니다. 날짜와 영향 범위는 Apple의 공식 만료 공지를 기준으로 하세요.

검수는 프로젝트에서 실제로 배포하는 파일을 기준으로 진행합니다.

대체 Developer ID Installer 인증서를 준비합니다.
출시 대상 .pkg를 새 인증서로 서명합니다.
배포 방식에 따라 공증이 필요한지 확인하고, 해당 절차를 진행합니다. Apple의 macOS 소프트웨어 공증 안내를 따르세요.
새로 만든 패키지를 사용자 관점에서 설치하고, 앱 실행과 설치 후 동작을 확인합니다.
배포 파일과 검수 결과를 기록하고, 문제 발생 시 이전 출시 절차로 돌아갈 조건을 정합니다.

인증서 교체만으로 설치 검수가 끝나는 것은 아닙니다. 다운로드한 패키지의 서명, 공증 처리, 설치 결과가 각각 기대한 상태인지 확인해야 합니다.

macOS CI는 격리된 작업에서 새 서명 경로를 먼저 검증합니다

CI 담당자는 빌드 작업이 여전히 구형 인증서, 개인 키, 키체인 항목 또는 서명 설정을 참조하는지 조사해야 합니다. 설정을 한꺼번에 바꾸면 인증서 문제와 빌드 설정 문제를 구분하기 어려워집니다.

macOS CI 서명 작업은 어떤 순서로 옮겨야 합니까?

빌드 작업과 배포 설정에서 사용 중인 Developer ID Application 및 Developer ID Installer 인증서를 식별합니다.
새 인증서와 대응하는 개인 키가 빌드 환경에서 사용 가능한지 확인합니다. 비밀 정보의 저장과 접근은 Apple이 안내하는 보안 절차를 따릅니다.
정식 배포와 분리된 시험 작업을 만들어 새 인증서로 앱 또는 .pkg를 서명합니다.
생성된 산출물의 서명과 필요한 공증 상태를 검증하고, 실제 설치까지 시험합니다.
시험 결과가 승인된 뒤 정식 작업의 인증서 참조를 바꾸고, 이전 설정으로 되돌릴 조건과 담당자를 기록합니다.

인증서 가져오기나 공증 작업의 세부 구현은 빌드 환경과 배포 방식에 따라 달라집니다. 명령과 자격 증명 취급을 검증 없이 일반 규칙처럼 복사하지 말고, Apple의 공증 작업 흐름 설명과 공식 서명 문서를 기준으로 확인하세요.

전환안을 고르는 기준과 실행 체크리스트

구매·운영 관점에서 보면, 현재 영향 범위를 확인하지 않은 채 모든 앱을 재서명하는 방식은 검수 범위를 불필요하게 넓힐 수 있습니다. 반대로 .pkg를 앱과 같은 대상으로 취급해 점검을 미루면 기한 전에 설치 검증을 마칠 여유가 줄어듭니다.

기존 앱의 서명과 공증 상태를 확인한 뒤 필요한 앱만 처리: 적합도 높음. Apple이 안내한 조건에 맞는 기존 앱까지 일괄 재서명하지 않습니다.
영향받는 .pkg를 새 인증서로 서명하고 설치까지 검수: 적합도 높음. 실제 납품물이 설치되는지 확인할 수 있습니다.
정식 CI 설정을 한 번에 바꾸고 출시 직전에 확인: 적합도 낮음. 실패 원인과 되돌릴 지점을 분리하기 어렵습니다.

팀 책임자는 다음 항목을 담당자와 함께 확인하세요.

[ ] 개발자 계정과 키체인에서 인증서 발급 기관을 확인했습니다.
[ ] 앱과 .pkg의 서명 인증서를 구분해 목록으로 만들었습니다.
[ ] 영향을 받는 설치 패키지에 대체 인증서를 연결했습니다.
[ ] 격리된 CI 작업에서 새 인증서로 산출물을 만들었습니다.
[ ] 앱과 설치 패키지를 실제 배포 방식에 맞춰 설치 검수했습니다.
[ ] 정식 전환 담당자와 실패 시 되돌릴 조건을 기록했습니다.
[ ] G2 인증서도 만료일을 확인하고, 해당 유효 기간에 맞춰 갱신할 계획을 세웠습니다.

원격 Mac을 쓸지 판단할 때는 서명 환경의 빈틈부터 봅니다

Windows나 Linux 중심의 빌드 환경은 macOS 전용 서명과 설치 검수를 그대로 대신할 수 없습니다. macOS 빌드 장비가 없다면 인증서·키체인 설정을 시험하기 어렵고, 실제 Mac에서 .pkg가 설치되는지도 확인하기 어렵습니다. 반대로 이미 macOS 빌드 환경을 안정적으로 운영하고 있거나 물리 장비 연결이 꼭 필요하다면 원격 환경 임대가 적합하지 않을 수 있습니다.

전환 전에 인증서 발급 기관과 실제 배포물을 먼저 목록화하고, 앱과 .pkg의 검수 항목을 나눠 책임자를 정하세요. macOS CI에서 시험 서명과 사용자 설치 검수를 할 환경이 부족한 팀이라면 ArmMacs의 Mac 지원 안내와 이용 계획을 살펴 원격 Mac이 해당 작업에 맞는지 비교할 수 있습니다. 임시 검증이나 마이그레이션 기간에 쓸 Mac 환경은 구매 전에 부담을 줄일 수 있지만, 지속적인 고부하 작업이나 물리 연결이 필요한 경우에는 보유 장비와 다른 운영 방식을 함께 검토하는 것이 낫습니다.