Developer ID 인증서 2027 만료 시 대처법? 2026 이전 점검표

Apple은 2026년 10월 1일, 기존 Developer ID 하위 인증 기관이 2027년 2월 1일 만료된다고 안내했습니다. 따라서 Developer ID 인증서의 발급 체인을 먼저 확인하고, 영향받는 인증서로 서명한 .pkg는 기한 전에 새 인증서로 다시 서명해야 합니다. 이미 서명·공증을 마치고 안전 타임스탬프가 있는 맥 앱은 이번 만료만으로 다시 서명할 필요가 없습니다. Apple의 만료 공지와 실제 계정 기록으로 판단하세요.

이 글은 맥 앱을 배포하며 기존 서명 신원의 영향을 확인하려는 독립 개발자를 위한 안내입니다.
설치 패키지 유지 담당자는 재서명과 설치 검수를, 원격 맥 빌드 환경을 운영하는 팀은 인증서와 개인 키 전환 여부를 확인할 수 있습니다.

최종 업데이트: 2026년 10월 2일. Apple의 만료 공지, 인증서 생성 안내, 인증서 영향 설명을 대조했습니다. 2026년 11월에 다시 확인할 예정입니다.

발급 체인 확인: 인증서 이름보다 발급 기관을 대조합니다

영향 여부는 인증서의 종류만으로 결정되지 않습니다. 개발자 계정의 인증서 기록에서 발급 기관과 유효 기간을 확인하고, Apple의 Developer ID 하위 인증 기관 안내와 대조해야 합니다. Apple은 기존 Developer ID 하위 인증 기관이 2027년 2월 1일 만료되며, 해당 기관이 발급한 인증서는 그때부터 작동하지 않는다고 밝혔습니다. 공지의 날짜와 적용 범위는 실제 인증서 기록과 함께 확인하세요.

인증서 역할도 구분해야 합니다. Developer ID Application은 맥 앱 서명에 사용하고, Developer ID Installer는 .pkg 설치 패키지 서명에 사용합니다. 한쪽 인증서가 영향을 받는다고 다른 유형까지 자동으로 같은 상태라고 단정할 수는 없습니다.

개발자 계정에서 다음 항목을 확인하고, 인증서 이름과 발급 기관을 기록합니다.

• 인증서 유형과 만료일
• 발급 기관 및 중간 인증서
• 인증서와 짝을 이루는 개인 키의 보유 여부
• 해당 서명 신원을 사용하는 빌드 작업과 배포 파일

배포 산출물 영향: 앱과 설치 패키지를 따로 판정합니다

기존 맥 앱과 설치 패키지는 만료 이후의 영향이 다릅니다. Apple은 이미 서명과 공증을 마쳤으며 안전 타임스탬프가 포함된 기존 맥 소프트웨어는 계속 작동한다고 설명합니다. 후속 업데이트에는 새 인증서를 사용해야 합니다. 이 안내는 모든 과거 앱을 지금 다시 서명하라는 뜻이 아닙니다. Developer ID 인증서 영향 설명을 기준으로 실제 배포본을 확인하세요.

반면 영향을 받는 인증서로 서명된 .pkg는 공지된 만료일 이후 설치할 수 없습니다. 기존 배포 위치에 설치 파일이 남아 있다면 새 인증서로 다시 서명한 파일을 준비하고, 사용자가 받는 실제 경로에서 설치까지 검수해야 합니다. 확인하지 않은 사용자 환경의 동작을 미리 단정하지 말고, 재현 결과를 기록하세요.

앱의 공증 여부와 안전 타임스탬프는 별도 항목입니다. 인증서를 교체했다는 이유만으로 기존 앱을 다시 공증해야 한다고 가정하지 말고, 새로 배포할 산출물에 필요한 절차를 Apple의 Developer ID 서명 안내와 공증 기록으로 확인하세요.

서명 자산 확인: 인증서만 옮기지 말고 개인 키까지 검증합니다

인증서는 개인 키 없이 완전한 서명 신원이 되지 않습니다. 새 인증서를 만든 뒤에는 실제 빌드 계정의 키체인에서 대응하는 개인 키와 서명 신원이 보이는지 확인해야 합니다. 원격 맥과 로컬 맥이 서로 다른 계정이나 키체인을 사용한다면 각 환경에서 따로 검증합니다.

Apple의 Developer ID 인증서 생성 안내에 따라 새 인증서가 현재 Developer ID Certification Authority(G2)에서 발급되는지 확인하세요. 생성 과정에서 선택하는 중간 인증서와 구형 Xcode의 호환성은 프로젝트 환경에 따라 달라질 수 있으므로, 사용 중인 Xcode와 Apple의 공식 안내를 함께 대조해야 합니다. 일괄 적용되는 설정으로 취급하지 않는 편이 안전합니다.

빌드 계정에서 서명 신원 목록을 확인하는 예시는 다음과 같습니다.

security find-identity -v -p codesigning

출력에는 사용할 Developer ID 서명 신원이 표시되어야 합니다. 개인 키나 재사용 가능한 인증 정보를 로그, 문서, 화면 캡처에 노출하지 마세요. 공개할 수 있는 기록은 인증서 종류, 검사 결과, 빌드 식별자처럼 민감 정보가 제거된 항목으로 제한합니다.

배포 검수: 실제 산출물의 서명과 설치 결과를 남깁니다

인증서를 새로 만들었다는 사실만으로 이전이 끝난 것은 아닙니다. 앱 업데이트와 설치 패키지를 각각 실제 배포 조건으로 확인하세요. Apple의 코드 서명 인증서 기술 안내도 서명 인증서를 검토할 때 참고할 수 있습니다.

확인 절차는 다음 순서로 진행합니다.

• 개발자 계정의 인증서 기록에서 발급 기관과 만료일을 확인합니다.
• 빌드 계정의 키체인에서 새 인증서와 대응 개인 키가 함께 사용 가능한지 확인합니다.
• 앱에는 예상한 Developer ID Application 신원이 적용됐는지 검사합니다.
• 설치 패키지에는 예상한 Developer ID Installer 신원이 적용됐는지 검사합니다.
• 배포 예정 파일을 대상으로 공증 기록과 서명 결과를 확인합니다.
• 실제 배포 경로에서 앱 업데이트와 .pkg 설치를 각각 검수하고 결과를 기록합니다.

앱 번들은 다음처럼 확인할 수 있습니다.

codesign -dv --verbose=4 "/경로/앱 이름.app" 2>&1

설치 패키지는 다음 명령으로 서명 정보를 확인합니다.

pkgutil --check-signature "/경로/설치 파일.pkg"

아래는 출력 형식을 설명하기 위한 예시입니다. 실제 결과에서는 프로젝트에 맞는 인증서 정보와 검증 상태를 확인해야 합니다.

앱: 예상한 Developer ID Application 서명 신원
패키지: 예상한 Developer ID Installer 서명 신원
검수: 서명 확인 및 실제 설치 결과 기록

자주 묻는 영향 범위: 기존 앱과 패키지의 조건을 구분합니다

오래된 중간 인증서로 서명한 맥 앱은 모두 다시 서명해야 하나요?

아닙니다. 이미 서명과 공증을 마쳤고 안전 타임스탬프가 포함된 기존 맥 소프트웨어는 계속 작동한다는 것이 Apple의 안내입니다. 다만 후속 업데이트는 새 인증서로 서명해야 합니다. 실제 배포 앱의 서명 정보와 공증 기록을 확인해 예외 조건을 추측으로 처리하지 마세요.

Developer ID Installer로 서명한 패키지 설치 파일은 언제 다시 서명해야 하나요?

영향을 받는 인증서로 서명한 .pkg는 Apple이 공지한 만료일 이후 설치할 수 없으므로, 그 전에 새 인증서로 서명하고 실제 설치를 검수해야 합니다. 보관 중인 파일뿐 아니라 다운로드 페이지나 자동 업데이트 경로에 게시된 파일도 목록에 넣으세요.

공증과 안전 타임스탬프가 있는 앱도 지금 다시 서명해야 하나요?

이번 만료만을 이유로 기존 앱을 즉시 다시 서명할 필요는 없습니다. 기존 앱의 조건과 다음 업데이트의 서명 요구사항을 나눠 판단하세요. 새 빌드를 배포할 때는 새 인증서로 서명하고 해당 배포본의 공증 및 서명 결과를 확인합니다.

인증서가 만료 예정인 하위 기관에서 발급됐는지 어떻게 확인하나요?

개발자 계정의 인증서 기록에서 발급 기관과 유효 기간을 보고, Apple의 하위 인증서 안내와 비교합니다. 인증서 표시 이름만 보고 영향 여부를 결정하지 마세요. 빌드 환경에서 실제 사용하는 서명 신원도 함께 확인해야 합니다.

선택 기준: 산출물 유형과 검수 증거로 조치를 정합니다

새 인증서는 Apple의 현재 생성 안내에 따라 확인하고, 구형 Xcode 호환성이나 중간 인증서 선택은 해당 개발 환경에서 별도로 검증합니다. 이때 공증 문제 해결 문서는 공증 오류가 실제로 발생했을 때 참고할 자료이지, 인증서 교체가 곧 공증 재실행을 뜻한다는 근거는 아닙니다.

개발 환경을 직접 관리하는 방식은 키체인 접근과 배포 경로를 통제하기 쉽지만, 전용 맥의 유지 관리와 저장 공간 확보, 상시 실행 환경 관리가 부담이 될 수 있습니다. 기존 맥을 계속 쓸 수 있다면 굳이 임대할 필요는 없습니다. 다만 인증서 이전 기간에 분리된 빌드 환경이 필요하거나 로컬 장비의 자원을 다른 작업과 나눠 써야 한다면, SFTPMAC의 맥 미니 요금 안내에서 사용 조건을 먼저 비교할 수 있습니다. 원격 맥은 물리 장비에 직접 접근해야 하거나 장기간 고정된 환경을 상시 운영하는 경우에 반드시 적합한 선택은 아닙니다. 임시 이전 검수나 별도 배포 환경이 목적이라면 SFTPMAC 서비스 환경을 살펴보고, 필요한 인증서·개인 키 관리 방식과 접속 조건이 현재 출시 절차에 맞는지 확인하세요.