App Store Connect 앱 이전 2026: 인수인계 전후 어떻게 검수할까?

앱스토어 이전은 완료됐지만 구독 검증이나 로그인만 끊겼다면, 상점 소유권만 넘기고 운영 자산을 넘기지 않은 상태입니다.

가장 빠른 해결책은 이전을 누르기 전에 자격과 고위험 변경을 확인하고, 상점 자료·코드·핵심 서비스·권한을 별도 항목으로 인수인계한 뒤 새 계정에서 실제 이용과 배포를 회귀 검수하는 것입니다.

이 글은 이미 출시된 앱을 매각하거나 인수하는 해외 사업 책임자, 운영 담당자, 프로젝트 관리자에게 적합합니다. 계정의 소유자와 기술 담당자가 다른 조직에 속한 경우에도 사용할 수 있는 검수 기준을 제공합니다.

상점 소유권과 사업 자산을 분리해서 판단하기

App Store Connect 앱 이전은 앱의 상점 기록과 배포 주체를 바꾸는 절차입니다. 코드 저장소, 서버, 도메인, 고객센터, 광고 계정, 분석 도구가 함께 이동한다는 뜻은 아닙니다. Apple도 앱 이전 후 처리되는 항목과 별도로 조치해야 하는 서비스를 구분해 안내합니다. Apple의 앱 이전 개요를 기준으로 계약 범위를 먼저 나눠야 합니다.

매각자와 인수자는 다음처럼 책임을 분리하는 편이 안전합니다.

• 계정 소유자: 이전 자격 확인, 이전 시작, 계약과 권한 승인
• 운영 담당자: 상점 설명, 현지화 자료, 가격과 판매 지역 기록
• 기술 담당자: 저장소, 서버, 인증서, 푸시, 구독 검증
• 재무 담당자: 판매 보고서, 지급 정보, 계약상 정산 기준
• 프로젝트 관리자: 파일 위치, 확인자, 차단 조건, 완료 기록 관리

앱이 상점에서 계속 제공된다는 사실도 서비스 연속성을 보장하지 않습니다. 이전 중에도 다운로드가 가능할 수 있지만, 서버 키와 사용자 식별자 매핑이 새 조직에 맞지 않으면 로그인이나 구독 복원이 중단될 수 있습니다.

계약서에는 “상점 이전 완료”와 “전체 사업 인수인계 완료”를 별도 완료 조건으로 적는 것이 좋습니다. 후자를 확인하기 전에는 저장소, 서버, 고객센터와 외부 서비스의 접근 권한을 일괄 회수하지 않아야 합니다.

이전 자격 확인과 고위험 변경 동결

이전 조건이 맞지 않을 때 반복 제출하지 않기

App Store Connect 앱 이전을 시작하기 전에는 양쪽 계정의 계약 상태, 앱 상태, 사전 주문, 심사 진행 여부, 인앱 구입 항목과 연결 설정을 확인해야 합니다. 세부 조건은 계정 유형과 앱의 현재 상태에 따라 달라질 수 있으므로 Apple 공식 이전 조건을 기준으로 판정합니다.

조건이 맞지 않는 상황은 두 종류로 나눠 기록합니다.

• 현재 상태만 정리하면 다시 검토할 수 있는 일시적 미충족
• 계정 유형이나 연결 구성 때문에 현재 이전할 수 없는 구조적 제한

운영 담당자가 같은 요청을 반복 제출하면 해결 원인을 찾기 어렵습니다. 조건 화면, 계약 상태, 차단 문구는 계정 이름·팀 식별자·이메일을 가린 뒤 저장합니다. 이 기록은 거래 당사자가 “누가 무엇을 확인했는가”를 판단하는 증거가 됩니다.

이전 요청 직전에는 다음 변경을 동결합니다.

• 앱의 기본 식별자와 배포 설정 변경
• 구독 상품과 가격 정책의 대규모 수정
• 로그인 제공자와 사용자 매핑 구조 변경
• 서버 키, 푸시 설정, 도메인 연결 변경
• 심사 제출과 새 버전 배포

동결 기간은 Apple이 정한 공식 기한으로 단정하지 말고, 계약상 변경 금지 시점으로 정의해야 합니다. 플랫폼의 처리 상태나 제한은 이전 시작 절차에서 최신 내용을 다시 확인합니다.

자격 확인을 명령형 기록으로 남기기

아래 형식은 실제 명령어가 아니라 프로젝트 폴더에서 확인 항목을 빠뜨리지 않기 위한 기록 템플릿입니다.

transfer-check/
├── account-owner/
├── agreement-status/
├── app-status/
├── in-app-purchase/
├── store-assets/
├── service-keys/
└── rollback-plan.txt

각 폴더에는 원본 계정 정보가 아니라 탈취 위험을 줄인 화면 캡처와 확인 날짜, 담당자, 판정 결과만 저장합니다.

[ ] 양쪽 계정 소유자 확인
[ ] 계약 및 약정 상태 확인
[ ] 앱 상태와 심사 상태 확인
[ ] 사전 주문 및 인앱 구입 확인
[ ] 차단 조건과 예외 사항 기록
[ ] 동결할 변경 항목 합의

상점 자료와 재무 기록의 인수인계

소유권 이전 뒤에도 매각자와 인수자가 같은 과거 자료를 같은 범위로 보게 된다고 가정하면 안 됩니다. 따라서 이전을 시작하기 전에 상점 운영 자료를 별도 보관합니다.

보관 대상은 다음과 같습니다.

• 앱 이름, 설명, 키워드, 현지화 문구
• 아이콘, 스크린샷, 미리보기 영상과 원본 파일
• 가격, 판매 지역, 세금 및 판매 설정 기록
• 과거 판매·다운로드 보고서와 정산 자료
• 심사 메시지, 거절 이력, 출시 버전 기록
• 지원 웹사이트, 마케팅 웹사이트, 개인정보 처리방침
• 고객 문의 채널과 장애 대응 연락처

인수자는 지원 주소와 연락처를 미리 준비해야 합니다. 이전 수락 화면에서 자료를 급히 수정하면 담당자 확인이 늦어지거나, 기존 고객이 잘못된 문의 채널로 연결될 수 있습니다.

파일 이름은 다음처럼 통일하면 책임 소재가 분명해집니다.

2026-07-store-metadata-ownerA-final
2026-07-review-history-ownerA-export
2026-07-support-links-ownerB-ready
2026-07-asset-handover-approval

날짜와 파일명은 실제 저장 시점에 맞춰 바꿉니다. 중요한 것은 동일한 자료를 여러 위치에 흩어 놓지 않는 것입니다. 각 파일에는 보관 위치, 기준 시점, 열람 가능자, 확인 상태를 함께 기록합니다.

상점의 평점과 리뷰, 앱의 식별 정보가 이전 후 어떻게 유지되는지는 앱의 이전 조건과 Apple의 처리 범위를 따로 확인해야 합니다. 인수자는 수락 직후 제품 페이지와 기존 사용자에게 보이는 정보를 직접 확인하고, 매각자는 원래 계정에서 앱이 제거됐는지 확인해야 합니다. Apple의 이전 수락 안내를 근거 자료로 남기는 것이 좋습니다.

구독과 로그인은 별도 서비스로 검수하기

자동 갱신 구독이 있는 앱의 준비

자동 갱신 구독이 사용 중인 앱은 상점 이전만 확인해서는 부족합니다. 상품 목록, 영수증 또는 거래 검증 서버, 사용자 계정 연결, 복원 흐름을 각각 나눠 점검해야 합니다.

인수 전 기술 담당자는 다음 증거를 제출해야 합니다.

• 현재 판매 중인 구독 상품 목록
• 서버가 거래 상태를 확인하는 방식
• 사용자 계정과 구독 상태의 연결 규칙
• 테스트 계정의 구독 복원 결과
• 이전 실패 시 되돌릴 서버 설정

앱 이전 후 구독 처리가 어떻게 달라지는지는 앱의 구현 방식과 Apple의 현재 문서를 기준으로 확인해야 합니다. 문서에 없는 처리 기간이나 성공률을 경험칙으로 확정해서는 안 됩니다.

Sign in with Apple 사용자의 로그인 연속성

Sign in with Apple을 사용하는 앱은 팀이 바뀐 뒤 사용자 식별자가 그대로 유지된다고 가정하면 안 됩니다. 사용자 이전 작업, 서버의 식별자 변환, 이메일 중계 주소 처리 여부를 기술 담당자가 함께 검수해야 합니다. Apple의 공식 사용자 이전 문서에서 현재 요구되는 작업을 확인합니다.

로그인이 실패할 때는 다음 순서로 원인을 좁힙니다.

• 새 팀에서 발급한 설정과 서버 설정의 일치 여부 확인
• 기존 사용자와 새 사용자 식별자 매핑 여부 확인
• 이메일 중계 주소로 발송되는 인증 메일 확인
• 신규 사용자 로그인과 기존 사용자 로그인을 분리 테스트
• 변환하지 못한 계정의 고객센터 처리 절차 확인

TestFlight도 상점 이전과 같은 방식으로 자동 승계된다고 보지 말고, 인수자 팀에서 초대·설치·업데이트가 가능한지 확인합니다. 외부 테스터에게 안내한 링크와 테스트 계정의 접근 상태도 운영 자료에 포함해야 합니다.

권한, 인증서와 원격 협업을 분리하기

Apple Developer Program 계정의 역할은 모든 담당자에게 동일하게 부여하지 않습니다. 계정 소유자는 이전과 계약 상태를 책임지고, 운영 담당자는 상점 자료를 관리하며, 기술 담당자는 필요한 배포와 서비스 설정만 맡는 식으로 최소 권한을 설계합니다. Apple 계정 역할 안내를 근거로 역할을 배정합니다.

Apple Account 비밀번호나 인증 코드를 공유하는 방식은 피해야 합니다. 원격 Mac을 사용하더라도 플랫폼의 본인 확인은 각 계정 소유자가 직접 수행해야 합니다. 원격 환경은 권한을 우회하거나 이전을 빠르게 만드는 수단이 아닙니다.

원격 협업 환경에는 다음 원칙을 적용합니다.

• 매각자와 인수자에게 독립된 macOS 사용자를 할당합니다.
• 브라우저 세션과 저장된 암호를 공유하지 않습니다.
• 화면 캡처에는 이메일, 팀 식별자, 인증서와 비밀 키를 표시하지 않습니다.
• 계정 소유자가 필요한 승인만 직접 수행하게 합니다.
• 회의록에 접속자, 확인 항목, 미해결 문제를 기록합니다.
• 거래가 끝나면 사용자, 기기, 저장소와 외부 서비스 권한을 순서대로 회수합니다.

서로 다른 지역에서 교대 작업을 해야 한다면 원격 Mac의 사용자 권한과 전달 방식을 먼저 검토할 수 있습니다. 단, 이 환경은 자료 확인과 회귀 검수에 쓰는 작업 공간일 뿐이며 Apple의 공식 계정 권한을 대신하지 않습니다.

이전 완료 후 배포와 사용자 흐름 회귀

인수자는 이전 수락 직후 다음 순서로 확인합니다.

1. 새 계정에서 앱 정보와 상점 노출 상태를 확인합니다.
2. 운영 담당자의 접근 범위와 기술 담당자의 접근 범위를 다시 검토합니다.
3. 인증서, 프로비저닝 프로파일과 후속 빌드 배포 권한을 확인합니다.
4. 제품 설명, 현지화 문구, 지원 링크와 개인정보 링크를 엽니다.
5. 기존 버전의 다운로드와 업데이트 흐름을 확인합니다.
6. 신규 사용자와 기존 사용자의 로그인을 각각 시험합니다.
7. 구독 구매, 복원, 서버 검증 결과를 확인합니다.
8. 푸시 알림과 고객센터 링크를 확인합니다.
9. TestFlight 초대와 빌드 설치를 확인합니다.
10. 문제가 없을 때만 매각자의 접근 권한과 외부 서비스 연결을 회수합니다.

이 과정에서 “페이지가 보인다”와 “업무가 계속된다”를 구분해야 합니다. 상점 페이지가 정상이어도 배포 인증서가 없으면 다음 버전을 내지 못할 수 있습니다. 로그인 화면이 열려도 기존 사용자의 계정 매핑이 없으면 실제 서비스 이용은 실패합니다.

검수 판정은 다음 조건으로 나눌 수 있습니다.

• 모든 핵심 사용자 흐름이 통과하고 증거가 있으면: 인수인계를 승인합니다.
• 상점 자료는 정상이나 구독·로그인·배포 중 하나에 문제가 있으면: 수정 기한과 담당자를 정한 뒤 조건부 승인합니다.
• 이전 자격, 계정 소유자, 사용자 데이터 또는 배포 권한이 확인되지 않으면: 인수인계를 중지하고 원인을 해결합니다.
• 비밀 키가 노출됐거나 회수할 수 없으면: 권한 회수보다 키 교체와 접근 차단을 먼저 진행합니다.

교차 지역 인수인계를 위한 환경 선택

물리 Mac을 공동으로 전달하는 방식은 배송, 초기 설정, 계정 분리와 회수 시점에서 부담이 생깁니다. 일반 클라우드 환경은 macOS 특유의 브라우저와 배포 검수를 동일하게 재현하지 못할 수 있습니다. 반면 원격 Mac은 독립된 작업 공간을 만들 수 있지만, 계정 권한과 서비스 연속성을 자동으로 해결하지는 않습니다.

원격 Mac이 필요하다면 해외 업무용 Mac 환경의 전달 방식을 확인한 뒤 프로젝트별 사용자와 파일 보관 정책을 먼저 정합니다. 장기 운영 장비가 필요한 조직은 임시 대여보다 자체 장비의 접근 통제가 더 적합할 수 있습니다.

현재 방식이 개인 Mac 하나에 계정, 저장소, 인증서, 고객센터 로그를 함께 두는 구조라면 잔여 세션이 남고 책임 추적이 어렵습니다. 여러 지역의 담당자가 같은 화면을 번갈아 사용하면 인증 코드 전달과 권한 회수도 불명확해집니다. 일반 원격 서버만으로 진행하면 Safari와 배포 환경의 확인 범위가 줄어드는 문제도 있습니다.

따라서 단기간의 거래 검수나 지역 간 교대 작업에는 SFTPMAC의 원격 Mac을 별도 프로젝트 환경으로 임대하는 편이 더 깔끔할 수 있습니다. 다만 장기 고정 부하, 물리 인터페이스가 필요한 작업, 조직 내부 보안 정책상 장비 반출이 불가능한 경우에는 자체 Mac이 더 맞습니다. 필요한 것은 이전 성공을 보장하는 장비가 아니라, 각 계정 소유자가 공식 절차를 수행하면서 자료와 결과를 분리해 남길 수 있는 환경입니다. 자세한 조건은 Mac 원격 대여 방식과 가격 안내에서 확인할 수 있습니다.

인수인계의 합격 기준은 버튼을 눌렀는지가 아닙니다. 상점 소유권, 운영 자료, 사용자 서비스, 후속 배포, 접근 권한이 각각 증거로 확인되어야 다음 단계로 넘어갈 수 있습니다. 팀 간 거리가 멀거나 공용 장비가 없는 경우에는 먼저 격리된 macOS 작업 환경을 마련하고, 그 위에서 확인과 권한 회수를 진행하는 방식이 안전합니다.