App Store Connect App Transfer 후 어떻게 패키징하나요? 2026 인계 체크리스트

빌드는 성공했지만 새 팀에서 푸시가 오지 않거나 TestFlight 업로드가 거절되고 있습니까?

가장 빠른 해법은 기존 팀의 서명과 배포 비밀값을 바로 복사하지 않는 것입니다. 인수자가 Bundle ID와 기능 권한을 먼저 확인한 뒤 새 서명, 푸시, 업로드 경로를 원격 맥에 만들고, 실제 Archive와 TestFlight 업로드까지 통과시켜야 합니다. 이전 환경은 새 환경이 검증될 때까지 짧은 기간 이중으로 유지하는 편이 안전합니다.

App을 판매하거나 양도하는 개발자는 소스 코드만 넘기지 않고 빌드 자산과 복구 자료까지 정리해야 합니다.
App을 인수하는 독립 개발자는 새 팀에서 서명, 푸시, 배포 권한을 다시 세워야 합니다.
원격 맥이나 자동 빌드 환경을 관리하는 소규모 팀은 이전 머신의 중단 조건과 새 머신의 인수 조건을 분리해야 합니다.

App Store Connect의 App 기록, App ID, Bundle ID, 인증서, 개인 키, Provisioning Profile은 서로 다른 자산입니다. 소스 저장소와 Archive 파일도 별도 인계 대상입니다. App Transfer는 App의 소유 관계를 바꾸지만, 원래 팀의 사용자 폴더와 키체인, CI 비밀값, 원격 맥의 파일까지 자동으로 넘기지는 않습니다.

Apple은 App Transfer 이후 Bundle ID를 유지하고 연결된 App ID가 인수 팀으로 이동한다고 안내합니다. 그러나 Apple Pay Merchant ID는 App과 함께 이동하지 않습니다. 따라서 일반적인 iOS App의 인계 절차를 Apple Pay, iCloud, Sign in with Apple, Game Center, Mac Catalyst가 포함된 프로젝트에 그대로 적용하면 안 됩니다. Apple의 App Transfer 개요를 기준으로 기능별 확인표를 따로 만들어야 합니다.

주의: 커뮤니티에서 “모든 인증서가 자동으로 이동한다”는 식의 설명을 볼 수 있지만, 이를 확정된 규칙으로 사용하면 안 됩니다. 인증서와 프로필의 현재 상태는 양도 조건과 새 팀의 권한을 기준으로 다시 확인해야 합니다.

양도자는 양도 신청 전에 다음 자료를 읽을 수 있는 형태로 정리해야 합니다.

• 저장소 주소와 특정 출시 버전을 재현할 수 있는 커밋
• Xcode 프로젝트의 서명 설정, 기능 권한 목록, 환경 변수 이름
• Bundle ID와 연결된 기능 목록
• Archive, IPA, dSYM, 변경 기록과 마지막 정상 빌드 로그
• APNs 서버 인증 방식과 서버 쪽 키 교체 절차
• App Store Connect API Key, Webhook, 자동화 계정의 담당자와 폐기 절차
• 테스트 계정, 복구 순서, 문제가 생겼을 때 되돌릴 이전 산출물

개인 키와 API 비밀값을 문서나 채팅에 평문으로 넣어 전달해서는 안 됩니다. 원래 팀의 키체인 전체를 복사하는 방식도 피해야 합니다. Apple은 양도자가 코드와 빌드 자산을 직접 인계해야 한다고 안내하며, 양도 조건과 제한 사항은 공식 App Transfer 조건에서 확인할 수 있습니다.

양도 신청 전에는 계정 상태, 계약 수락 여부, 심사 중인 버전, 판매 중인 버전과 관련된 조건을 확인해야 합니다. 양도자가 해야 할 일은 “앱을 넘겼다”고 선언하는 것이 아니라, 인수자가 새 팀에서 다시 빌드할 수 있는 증거를 남기는 것입니다. 실제 신청 절차는 App Transfer 시작 안내에 맞춰 진행합니다.

인수자는 App Store Connect에 로그인한 뒤 App 기록, 과거 빌드, Bundle ID, 사용자 역할이 보이는지 확인해야 합니다. App 기록이 보인다는 사실만으로 새 팀의 서명과 온라인 기능이 준비된 것은 아닙니다.

다음 항목은 화면에서 직접 대조해야 합니다.

• Bundle ID가 소스의 실제 식별자와 같은지
• 필요한 기능 권한이 새 팀의 App ID에서 활성화되어 있는지
• 과거 빌드와 출시 버전의 기록을 확인할 수 있는지
• 인수자에게 빌드 업로드와 TestFlight 관리 권한이 있는지
• APNs, Associated Domains, Keychain Sharing, iCloud 컨테이너가 필요한지
• Sign in with Apple 사용자 이전 절차가 필요한지
• Apple Pay Merchant ID와 서버 연동을 별도로 준비했는지
• Webhook 수신 주소와 API Key를 새 팀 기준으로 교체할 수 있는지

Sign in with Apple을 사용한다면 사용자 식별자 이전을 별도 작업으로 다뤄야 합니다. Apple은 App 양도와 관련된 사용자 이전 절차를 Sign in with Apple 기술 안내에서 설명합니다. 로그인 기능이 정상적으로 표시되는 것만 확인하고 기존 계정 연결까지 검증하지 않으면, 출시 뒤 사용자 계정이 분리될 수 있습니다.

App Transfer 후 Apple Distribution 인증서와 Provisioning Profile은 “기존 파일을 그대로 복사”하는 항목이 아닙니다. 이전 인증서가 유효 기간 안에 계속 작동할 가능성은 있지만, 이후 배포를 위해 인수 팀이 사용할 새 인증서와 프로필을 준비해야 합니다. 특히 서버 업로드와 자동 빌드가 있다면 새 팀의 키와 권한으로 인증 경로를 교체해야 합니다.

인수자는 다음 순서로 진행하는 것이 좋습니다.

첫째, 새 팀에서 필요한 배포 인증서를 만들고 원격 맥의 보안 저장 영역에 제한적으로 설치합니다.
둘째, 새 Bundle ID와 기능 권한에 맞는 Provisioning Profile을 생성합니다. Provisioning Profile 생성 절차는 프로필 생성에 필요한 App ID와 인증서의 관계를 확인하는 기준으로 사용할 수 있습니다.
셋째, Xcode의 서명 팀, 프로필, entitlements를 새 팀 기준으로 맞춥니다.
넷째, Associated Domains, Keychain Sharing, iCloud 같은 기능이 Archive의 entitlements에 실제로 들어갔는지 확인합니다.
다섯째, 이전 인증서를 즉시 폐기하지 않고 새 인증서로 만든 Archive를 별도 경로에서 검증합니다.

경험: 이전 인증서를 먼저 폐기하면 실패 원인이 서명 교체인지 기능 권한 변경인지 구분하기 어려워집니다. 새 Archive와 업로드가 확인된 뒤에만 이전 Runner와 키를 단계적으로 중지하는 편이 복구에 유리합니다.

App Transfer 이후 APNs도 서버 설정을 다시 점검해야 합니다. 기존 푸시 인증서가 유효 기간 안에 계속 동작할 수 있지만, 인수 팀은 이후 운영을 위해 새 인증서나 키를 준비하고 서버의 팀 식별자, 키 식별자, 환경 설정을 교체해야 합니다. TLS 인증서를 쓰는 경우에는 APNs TLS 인증서 공식 안내를 기준으로 새 팀의 설정을 확인합니다.

원격 맥에서는 사용자 계정 전체를 넘기지 말고, 재현 가능한 구성만 새로 만듭니다.

• Xcode와 프로젝트 의존성의 고정 버전
• 저장소 체크아웃 경로
• 서명 파일을 주입하는 방식
• API Key와 푸시 키의 보안 저장 위치
• GUI Archive와 SSH 또는 CI Archive의 실행 명령
• IPA 출력 경로와 로그 보관 위치
• 업로드 계정과 App Store Connect 연결 상태

모든 예시의 팀 식별자, Bundle ID, 키 식별자, 경로와 로그는 문서에서 가린 값으로 관리해야 합니다. 실제 값은 공유 문서가 아니라 권한이 제한된 비밀 저장소에 넣어야 합니다.

일반적으로 첫 Archive와 TestFlight 처리가 끝나지 않았다면 이중 트랙을 선택합니다. 반대로 새 환경에서 업로드, 설치, 핵심 기능과 복구 로그까지 확인했다면 이전 Runner와 Webhook, API Key, 서명 접근 권한을 차례로 줄일 수 있습니다. Apple의 업로드 흐름은 빌드 업로드 안내와 빌드 상태 설명을 함께 확인해야 합니다.

인수자는 “Xcode에서 Archive가 성공했다”는 결과만으로 완료 처리하면 안 됩니다. 다음 결과를 각각 별도로 기록해야 합니다.

• [ ] 새 팀의 Bundle ID와 기능 권한을 확인했습니다.
• [ ] 새 인증서와 Provisioning Profile로 Archive를 만들었습니다.
• [ ] IPA를 의도한 방식으로 내보냈습니다.
• [ ] 인수자 권한으로 App Store Connect에 업로드했습니다.
• [ ] 업로드 후 처리 상태가 정상으로 바뀌었습니다.
• [ ] TestFlight에서 설치 가능한 빌드를 확인했습니다.
• [ ] 푸시, 로그인, 내장 결제와 클라우드 기능을 실제 환경에서 확인했습니다.
• [ ] Archive, IPA, 로그와 설정 변경 기록을 보관했습니다.
• [ ] 실패 시 이전 빌드 또는 이전 환경으로 돌아가는 조건을 정했습니다.

첫 출시가 검증되기 전에는 원래 팀의 모든 권한을 제거하지 않습니다. 다만 장기간 개인 키를 공동으로 보관하는 것도 피해야 합니다. 새 팀이 실제 배포에 성공한 뒤에는 이전 팀의 Runner, Webhook, API Key와 키체인 접근을 순서대로 폐기하고, 인계 증거만 남기는 방식이 적절합니다.

이번 주에는 양도자가 먼저 기능 목록, Archive, IPA, dSYM, 자동화 설정과 복구 기록을 묶어야 합니다. 인수자는 App Store Connect와 Bundle ID를 확인한 뒤 새 서명과 APNs 경로를 준비해야 합니다. 원격 맥 관리자는 GUI Archive, SSH 또는 CI Archive, IPA 내보내기와 업로드를 각각 실행하고 로그를 남겨야 합니다.

기존 로컬 맥이나 단순 공유 빌드 머신은 사용자 계정과 키체인이 뒤섞이고, 권한 회수가 늦어지며, 새 팀의 서명 실패를 추적하기 어렵다는 단점이 있습니다. 직접 장비를 사면 남는 하드웨어와 유지 관리 부담이 생기고, 일시적인 양도 작업에도 계속 비용이 발생합니다. 이런 상황에서 JEXCLOUD의 원격 맥 환경은 새 팀의 독립된 빌드 공간과 완전한 권한이 필요한 기간에 임시 또는 상시 환경으로 검토할 수 있습니다.

특히 상시 빌드가 필요하지 않고, 양도 직후의 Archive·IPA·TestFlight 검증만 수행해야 한다면 맥을 직접 구매하는 것보다 원격 맥을 기간제로 구성하는 편이 운영 범위를 줄일 수 있습니다. 반대로 장기간 고정 부하가 발생하거나 물리 장치 연결이 필수라면 자체 장비가 더 적합할 수 있습니다. 환경을 선택하기 전에는 원격 맥 배포 방식을 확인하고, 실제 프로젝트의 서명과 업로드 절차를 기준으로 인수 테스트를 설계해야 합니다.