iOS 개발 인증서 이전: 2026년 맥 교체 검수표

📋 목차

증상: 인증서를 가져왔는데도 새 맥의 Xcode가 개인 키가 없다고 표시합니다.
가장 빠른 해결: 인증서 파일만 복사하지 말고 개인 키가 포함된 서명 신원을 내보내거나, 새 맥에서 인증서를 다시 만든 뒤 Provisioning Profile과 앱 권한을 함께 확인합니다.

이 글은 기존 맥에서 원격 맥으로 빌드 환경을 옮기는 독립 개발자, 상시 실행되는 iOS 빌드 서버를 관리하는 작은 팀을 위한 실행 문서입니다. 기존 맥이 고장 난 경우에 무엇을 복구할 수 있고 무엇을 새로 발급해야 하는지도 구분합니다.

이전 전에 확인할 서명 자산

iOS 개발 인증서 이전에서 먼저 분리해야 할 항목은 인증서, 개인 키, 서명 신원, Provisioning Profile, 업로드 자격 증명입니다. 이 다섯 가지를 하나의 파일처럼 취급하면 실패 원인을 찾기 어려워집니다.

Apple의 코드 서명 구조에서 실제 서명에는 개인 키가 사용됩니다. 인증서는 공개 키와 소유자 정보를 확인하는 역할을 하므로 .cer 파일만 가져와서는 기존 서명 능력을 복원할 수 없습니다. 인증서와 연결된 개인 키가 함께 있어야 하나의 서명 신원으로 작동합니다. Apple의 서명 및 검증 설명에서 이 구조를 확인할 수 있습니다.

이전 전에 다음 항목을 문서로 남겨 두십시오.

Team ID와 앱의 Bundle ID
Apple Distribution 또는 개발용 인증서의 종류
각 인증서에 대응하는 개인 키의 존재 여부
앱, 위젯, 알림 확장 기능에 필요한 권한
Provisioning Profile의 이름과 적용 대상
App Store Connect 업로드 방식과 별도 API 키
자동 빌드에서 사용하는 환경 변수와 비밀 저장소

Xcode 자동 서명은 프로필과 인증서를 자동으로 관리할 수 있습니다. 그러나 수동 서명이나 무인 빌드에서는 프로젝트 설정과 자격 증명을 직접 관리해야 합니다. 따라서 Xcode에서 팀 계정이 보이는 것과 서버에서 반복 빌드가 되는 것은 서로 다른 성공 조건입니다.

기존 맥에서 안전하게 내보내기

Keychain Access에서 확인할 항목

기존 맥의 Keychain Access에서 인증서 이름 왼쪽의 펼침 표시를 확인하십시오. 인증서 아래에 대응하는 개인 키가 함께 보여야 합니다. 인증서만 있고 개인 키가 없다면 해당 항목은 새 맥에서 배포 서명을 수행할 수 있는 완전한 서명 신원이 아닙니다.

내보내기 대상은 보호된 신원 파일이어야 합니다. 내보낸 파일에는 개인 키가 포함될 수 있으므로 암호를 설정하고, 코드 저장소나 팀 메신저에 올리지 마십시오. Apple의 인증서 서명 요청 절차를 기준으로 키체인에 저장된 인증서와 개인 키의 관계를 확인하십시오.

Provisioning Profile은 별도 파일로 보관합니다. 프로젝트의 Signing & Capabilities, 빌드 설정, 자동화 스크립트도 함께 백업하되 개인 키와 암호는 포함하지 마십시오.

인증서 파일만 옮겼을 때

인증서 파일만 새 맥으로 가져오면 Xcode가 팀과 인증서 이름은 인식할 수 있습니다. 그러나 서명 단계에서 개인 키를 찾지 못해 개인 키가 없다는 오류가 발생할 수 있습니다.

이때 프로필을 무작정 다시 만드는 것보다 먼저 키체인에 개인 키가 있는지 확인해야 합니다. 개인 키가 기존 맥에 남아 있다면 보호된 신원을 다시 내보내는 편이 빠릅니다. 개인 키가 사라졌다면 공개 인증서에서 역으로 복구할 수 없으므로 새 인증서를 만들고 관련 프로필을 갱신해야 합니다.

기존 맥을 사용할 수 없을 때의 복구 경로

기존 맥이 고장 났고 개인 키 백업도 없다면 복구와 재발급을 나누어 판단해야 합니다.

개발자 계정에 등록된 인증서는 새로 만들 수 있습니다.
기존 인증서의 개인 키는 공개 인증서만으로 되살릴 수 없습니다.
새 인증서를 만들면 해당 인증서를 포함하는 Provisioning Profile도 갱신해야 합니다.
기존 인증서를 바로 폐기하면 그 인증서를 포함한 프로필이 무효가 될 수 있습니다.
App Store Connect API 키와 APNs 키는 코드 서명 인증서와 별도의 자격 증명입니다.

Apple은 폐기된 인증서를 포함한 Provisioning Profile이 무효가 될 수 있다고 안내합니다. 따라서 새 인증서가 실제 빌드에서 작동하기 전에는 기존 인증서를 먼저 폐기하지 않는 편이 안전합니다. Apple의 인증서 폐기 안내와 프로필 수정 및 재생성 절차를 함께 확인하십시오.

APNs나 App Store Connect API를 자동화에 사용한다면 키 파일도 별도로 확인해야 합니다. 서비스용 개인 키는 다시 내려받을 수 없는 경우가 있으므로 생성 직후 안전한 장소에 보관하고, 코드 서명용 인증서와 같은 항목으로 취급하지 마십시오.

새 맥에서 복원하는 작업 순서

새 맥에서는 다음 순서로 진행하면 원인을 좁히기 쉽습니다.

Xcode와 프로젝트 의존성을 설치합니다. 먼저 기존 빌드 환경과 버전을 맞추고, 새 버전으로 바꾸는 작업은 이전 검수가 끝난 뒤 진행합니다.
보호된 신원 파일을 목표 키체인으로 가져옵니다. 인증서와 개인 키가 함께 보이는지 확인합니다.
Xcode에 올바른 팀으로 로그인합니다. 다른 팀의 계정이 남아 있으면 자동 서명이 잘못된 Bundle ID를 선택할 수 있습니다.
Signing & Capabilities에서 Team, Bundle ID, 권한을 확인합니다. 푸시 알림, 키체인 공유, 앱 그룹과 같은 권한은 프로필과 함께 검토해야 합니다.
Provisioning Profile을 설치하거나 Xcode가 올바른 프로필을 다시 생성하도록 합니다. 인증서가 바뀌었다면 기존 프로필을 그대로 사용할 수 있는지 먼저 확인합니다.
무인 빌드 사용자로 키체인 접근을 시험합니다. 로그인 세션에서는 되지만 재부팅 뒤 실패하는 구성이 있으므로 작업 재시작 후에도 확인해야 합니다.
비밀 값을 로그에 출력하지 않습니다. 키 파일 경로, 암호, API 키 값은 모두 자리표시자로 문서화합니다.

Provisioning Profile은 서명 주체, 허용된 앱, 실행 대상, 권한을 묶어 검증하는 자산입니다. 프로필 파일만 복사하고 Bundle ID나 권한을 확인하지 않는 방식은 충분하지 않습니다. Provisioning Profile 내부 구조 설명을 기준으로 확인하십시오.

이전 완료를 판단하는 조건 목록

아래 항목을 순서대로 확인하십시오. 체크하지 못한 항목이 있으면 기존 맥을 바로 내리지 마십시오.

[ ] 인증서 아래에 대응하는 개인 키가 보입니다.
[ ] 새 맥의 Keychain Access에서 인증서와 개인 키가 함께 인식됩니다.
[ ] Xcode의 Team과 Bundle ID가 기존 프로젝트와 일치합니다.
[ ] Signing & Capabilities의 앱 권한이 기존 앱과 일치합니다.
[ ] 올바른 Provisioning Profile이 설치되었거나 새 프로필이 생성되었습니다.
[ ] 실제 프로젝트로 Release Archive가 생성됩니다.
[ ] 보관 파일의 서명 신원과 Team ID를 확인했습니다.
[ ] 내보낸 결과물의 서명이 검증됩니다.
[ ] App Store Connect가 업로드한 빌드를 받아 처리했습니다.
[ ] 재부팅 또는 작업 재시작 뒤에도 무인 빌드가 다시 실행됩니다.
[ ] 로그에서 개인 키, 암호, API 키가 노출되지 않습니다.

조건별 판단은 다음과 같이 나누십시오.

인증서와 개인 키가 모두 있고 Archive와 업로드까지 성공하면 새 맥으로 전환할 수 있습니다.
인증서는 있지만 개인 키가 없으면 새 인증서를 만들고 Provisioning Profile을 갱신한 뒤 다시 검수합니다.
기존 맥을 사용할 수 없고 개인 키 백업도 없으면 인증서 재발급과 관련 프로필 교체를 진행합니다.
Archive만 성공하고 서명 검증 또는 App Store Connect 처리가 실패하면 이전을 완료한 것으로 보지 않습니다.
무인 빌드가 재부팅 뒤 실패하면 키체인 접근 방식을 다시 설계합니다. 보안을 낮춰 자동화를 통과시키는 방식은 선택하지 않습니다.

실제 보관 파일과 업로드 검수

iOS 개발 인증서 이전의 완료 여부는 컴파일 성공만으로 판단하면 안 됩니다. 다음 네 단계를 각각 통과해야 합니다.

컴파일 성공: 소스와 의존성이 정상적으로 빌드됩니다.
Archive 성공: 실제 배포 설정으로 보관 파일이 생성됩니다.
서명 검증 성공: 서명 신원, Team ID, Bundle ID, entitlements가 예상값과 일치합니다.
업로드 및 처리 성공: App Store Connect가 빌드를 받아 처리하고, 해당 빌드를 선택할 수 있습니다.

실제 프로젝트에서 깨끗한 Release Archive를 생성하십시오. 그 뒤 보관 파일의 서명 정보와 포함된 프로필을 확인하고, 업로드 처리까지 진행합니다. 로컬에서 IPA가 만들어졌다는 사실만으로는 업로드 성공을 보장하지 않습니다.

App Store Connect의 빌드 업로드 절차와 업로드한 빌드 선택 방법을 기준으로 마지막 검수를 진행하십시오.

검수 로그에는 다음 항목만 남기고 비밀 값은 제거합니다.

실행 시각과 빌드 식별자
사용한 Team ID와 Bundle ID
인증서 종류와 만료 상태
프로필 이름과 권한 검수 결과
Archive, 서명, 업로드 처리 결과
실패한 경우의 오류 코드와 해결 조치

기존 맥을 내리는 시점

새 환경에서 실제 프로젝트의 Archive, 서명 검증, 업로드 처리가 모두 끝난 뒤에만 기존 맥을 하차시키십시오. 가능하면 동일한 빌드 명령을 무인 실행으로 한 번 더 수행하고, 작업 재시작 뒤에도 인증서와 업로드 자격 증명이 정상적으로 읽히는지 확인합니다.

자체 맥을 계속 운영하는 경우에는 맥 미니 렌탈 요금 안내와 물리 맥과 가상 맥 비교 안내를 함께 검토하면 상시 빌드 환경에 필요한 보존 기간과 운영 방식을 정하기 쉽습니다. 민감한 키를 보관하는 환경은 접근 권한과 복구 절차를 먼저 설계해야 합니다.

기존 방식 그대로 새 맥만 바꾸면 인증서와 개인 키가 분리되고, 프로필이 오래된 권한을 가리키며, 업로드 키가 다른 위치에 남는 문제가 생깁니다. 개인용 맥은 재부팅과 로그인 상태에 의존하기 쉽고, 새 장비를 매번 준비하면 검수 과정도 반복됩니다.

이런 조건이라면 짧은 기간의 MacDate 원격 맥으로 서명 이전과 실제 배포를 먼저 재현해 보는 편이 안전합니다. Archive와 업로드가 반복해서 성공한 뒤 발행 빈도에 맞춰 상시 빌드 환경으로 유지할지 결정하면 됩니다. MacDate 한국어 안내에서 원격 맥 운영 조건을 확인할 수 있습니다.