iOS 앱을 개발하다 보면 어느 순간 애플 개발자 포털(Apple Developer Portal)에 들어가서 Certificates, Identifiers, Profiles, Keys, Services, Devices라는 생소한 메뉴를 마주하게 된다.
서버 개발자 입장에서는 이 구조가 마치 TLS 인증서·API 키·배포 정책이 한데 섞여 있는 듯한 복잡한 시스템처럼 보일 수 있다. 하지만 한 번 제대로 흐름을 이해해두면, iOS의 코드 서명과 배포 체계는 오히려 꽤 논리적이다.
Certificates — “누가” 서명하는가
Certificates(인증서)는 iOS 앱 바이너리에 서명하는 주체의 신원을 증명하는 수단이다.
TLS 인증서가 서버의 신원을 증명하듯, 애플의 인증서는 “이 앱은 애플이 신뢰하는 개발자 계정에서 서명됐다”는 것을 기기에 보장한다.
- Apple Development 인증서 개발 중에 Xcode로 기기에 직접 빌드할 때 사용한다. 팀원이 여러 명이라면 각자의 Mac에서 개인키를 만들어 사용해도 된다.
- Apple Distribution 인증서 TestFlight, App Store 제출, Ad Hoc 배포에 필요하다. 이건 팀 전체에서 공용으로 1~2개만 관리하는 것이 보통이다.
여러 앱을 만든다고 해서 앱마다 인증서를 따로 발급할 필요는 없다.
같은 개발자 계정 아래에서는 하나의 Distribution 인증서로 여러 앱을 배포할 수 있다.
즉, 인증서는 계정 단위로 공용이다.
Identifiers — “무엇을” 서명하는가
Identifiers는 앱 자체의 정체성을 나타낸다. 가장 대표적인 것이 **App ID (번들 ID)**이다.
com.company.appname 같은 형태이며, 앱 하나당 App ID도 하나씩 만들어야 한다.
푸시 알림이나 Apple Pay 같은 특정 기능을 쓰려면, 이 App ID에 해당 기능을 활성화해야 한다.
App ID 외에도 다음과 같은 Identifier들이 있다.
- Services ID: Sign in with Apple 등을 웹/서비스와 연동할 때
- Merchant ID: Apple Pay 결제용 가맹점 식별자
- App Group ID: 여러 앱이나 위젯 간에 데이터를 공유할 때
- iCloud Container ID: CloudKit 저장소 연결 시
Identifier는 대부분 앱 단위로 별도 생성한다.
다만 App Group ID나 Merchant ID처럼 여러 앱에서 공유할 수 있는 Identifier도 있다. 예를 들어 하나의 App Group ID를 만들어 A앱과 B앱이 같은 사용자 데이터를 공유하는 식이다.
Profiles — “어떤 조건에서 설치할 것인가”
Provisioning Profiles는 인증서·App ID·디바이스·권한 정보를 묶어 놓은 설치 정책 묶음이다.
iOS 기기는 앱 설치 시 프로파일을 함께 검증해 “이 앱은 어떤 권한으로, 어떤 기기에, 어떤 환경에서 설치 가능한가”를 확인한다.
- Development 프로파일: 개발용, 등록된 디바이스에만 설치 가능
- Ad Hoc 프로파일: 내부 테스트용, 최대 100대까지
- App Store 프로파일: 앱스토어 제출용, 디바이스 목록 없음
App ID의 설정(예: 푸시 알림)을 바꾸면, 프로파일도 다시 발급해야 한다. 그래야 entitlements(권한 정보)가 앱에 반영된다.
여러 앱을 만들 때는 앱마다 App ID가 다르기 때문에, 각 앱마다 별도의 프로파일이 필요하다. 하지만 같은 개발자 계정이므로 하나의 인증서를 기반으로 여러 프로파일을 만들 수 있다.
Keys — “서버가 애플과 대화할 때”
Keys는 앱 서명과는 별개의 개념으로, 서버와 애플의 백엔드 간 통신을 인증할 때 쓰인다.
대표적인 예가 **APNs Auth Key (.p8)**이다. 이 키 하나로 팀의 모든 앱에 푸시를 보낼 수 있다.
- APNs Auth Key는 Key ID + Team ID + .p8 비밀키로 JWT를 생성해 APNs 인증에 사용한다.
- 한 번만 다운로드 가능하므로 안전하게 보관해야 한다.
- 같은 계정의 여러 앱에 대해 하나의 .p8 키를 공용으로 사용 가능하다.
Sign in with Apple, MapKit, MusicKit 같은 다른 Apple API도 이 영역의 Keys에 포함된다.
Services — “무엇을 쓸 수 있는가”
Services는 앱에서 사용할 수 있는 **애플 기능(capabilities)**의 스위치다.
예:
- Push Notifications
- Background Modes
- iCloud
- App Groups
- Apple Pay
- Associated Domains (유니버설 링크)
- Game Center 등
이 설정은 App ID에 귀속된다. 따라서 앱마다 필요한 기능을 따로 켜야 한다.
여러 앱이 동일한 기능을 사용할 수도 있지만, 각 앱 ID의 Services 설정은 각각 관리된다.
Xcode에서 capability를 켜면 자동으로 포털의 App ID 설정과 프로파일이 갱신된다.
반대로 포털에서 직접 켰다면 프로파일을 다시 만들어 Xcode에 반영해야 런타임에서 기능이 제대로 동작한다.
Devices — “어떤 기기에서 설치 가능한가”
Devices 메뉴에서는 테스트용 기기의 **UDID(고유 식별자)**를 등록한다.
Development와 Ad Hoc 프로파일은 이 등록된 기기만 설치가 가능하다.
TestFlight나 App Store 배포는 UDID 등록이 필요 없다.
여러 앱이 있다고 해서 기기를 앱마다 따로 등록할 필요는 없다.
기기 목록은 계정 단위로 공용이며, 등록한 기기는 모든 Development/Ad Hoc 프로파일에서 선택할 수 있다.
마무리
iOS의 서명과 배포 체계는 처음 보면 복잡해 보이지만, 각 요소의 역할이 명확하다.
- Certificates: 누가 서명했는가
- Identifiers: 무엇을 서명하는가
- Profiles: 어떤 조건에서 설치할 수 있는가
- Keys: 서버와 애플 간 인증
- Services: 어떤 기능을 사용할 수 있는가
- Devices: 어떤 기기에서 설치할 수 있는가
이 구조를 이해해두면, “푸시 콜백이 안 온다”, “빌드가 기기에 설치가 안 된다”, “TestFlight에서는 되는데 로컬에선 안 된다” 같은 문제를 만났을 때, 정확히 어느 레이어를 점검해야 할지 감이 잡히게 된다.
특히 여러 앱을 개발할 때, 어떤 설정은 계정 전체에서 공유할 수 있고, 어떤 것은 앱 단위로 독립적인지 구분해두면 운영이 훨씬 깔끔해진다.