다른 업체가 만든 앱을 이어받을 때는 소스코드 파일보다 계정과 키를 먼저 챙겨야 합니다. 앱스토어와 구글 플레이 계정, 앱 서명 키, 서버와 도메인, 푸시나 결제 같은 외부 서비스 계정이 누구 명의인지 확인하고, 받은 소스코드로 실제 빌드가 되는지 직접 해 봐야 인수인계가 끝났다고 말할 수 있습니다. 앱스토어와 구글 플레이는 계정 사이에 앱을 옮기는 공식 절차가 따로 있어서, 조건을 미리 맞춰 두면 사용자와 리뷰를 그대로 둔 채 넘겨받을 수 있습니다. 아래에 항목별로 확인할 것과 저희가 쓰는 순서를 적었습니다.

앱을 넘겨받을 때 무엇부터 받아야 하나요

인수인계 자리에서 가장 흔한 장면은 압축 파일 하나를 받고 끝나는 것입니다. 그런데 앱을 계속 운영하려면 코드 말고도 필요한 것이 많습니다. 저희는 넘겨받을 것을 크게 다섯 묶음으로 나눠 목록을 만듭니다.

넘겨받을 다섯 묶음

• 앱, 서버, 관리자 페이지 소스코드
• Apple, Google 스토어 계정
• iOS 인증서와 Android 업로드 키
• 서버, 도메인, 클라우드 계정
• 푸시, 지도, 결제, 분석 서비스 계정

• 소스코드: 앱(iOS, Android 또는 크로스플랫폼), 서버, 관리자 페이지 코드와 저장소 접근 권한
• 스토어 계정: Apple Developer 계정과 App Store Connect, Google Play Console
• 서명 관련 자료: iOS 인증서와 프로비저닝 프로필, Android 업로드 키와 비밀번호
• 운영 인프라: 서버, 데이터베이스, 도메인, 클라우드 계정
• 외부 서비스: 푸시, 지도, 결제, 본인인증, 분석, 오류 수집 도구 계정

이 중 하나라도 이전 업체 직원 개인 계정에 묶여 있으면 나중에 연락이 끊겼을 때 손을 쓰기 어렵습니다. 처음 계약할 때 계정을 발주사 명의로 만드는 이야기는 외주 계약서 글에서 다뤘으니, 여기서는 이미 만들어진 앱을 옮겨 오는 쪽에 집중하겠습니다.

소스코드는 받았다는 것보다 빌드가 되는지가 중요합니다

소스코드를 받으면 가장 먼저 해 보는 일이 빌드입니다. 받은 코드로 앱을 새로 만들어 기기에 설치하고, 지금 스토어에 올라가 있는 버전과 같은 화면과 동작이 나오는지 비교합니다. 이걸 미루면 몇 달 뒤 급한 수정이 생겼을 때 그제야 빌드가 안 된다는 걸 알게 됩니다.

빌드가 막히는 이유는 대개 비슷합니다. 저장소에 최신 코드가 올라가 있지 않고 이전 담당자 컴퓨터에만 있었던 경우, 설정 파일이나 키 파일이 저장소에서 빠져 있는 경우, 오래된 라이브러리 버전이 지금 개발 도구와 맞지 않는 경우입니다. 앱이 한동안 업데이트되지 않았다면 Xcode, Android Gradle Plugin, Flutter나 React Native 같은 프레임워크 버전을 한꺼번에 올려야 하고, 외부 SDK도 함께 바꿔야 합니다.

그래서 코드를 받을 때는 저장소 주소와 권한만 받지 말고, 스토어에 올라간 마지막 버전이 어느 커밋(저장 시점)에서 만들어졌는지도 같이 물어보세요. 버전 번호와 커밋이 짝지어져 있으면 지금 운영 중인 앱과 받은 코드가 같은지 확인하기 쉽습니다. 현재 스토어 요건과의 차이는 API 36 대응 글과 iOS 26 SDK 글을 보시면 얼마나 손봐야 할지 감이 옵니다.

앱스토어 계정은 누구 명의인지부터 봅니다

iOS 앱은 Apple Developer 계정에 묶여 있습니다. 이 계정에는 계정 소유자(Account Holder)가 있는데, Apple 역할 안내에 따르면 연간 멤버십 갱신, 약관 동의, 관리자 추가, 정산 계좌 변경 승인을 이 사람이 맡습니다. 앱이 이전 개발사 계정에 올라가 있다면 운영사 계정으로 앱을 옮기는 이전(App Transfer)을 해야 합니다.

Apple의 앱 이전 안내를 보면 보내는 쪽 계정 소유자가 이전을 시작하고, 받는 쪽 계정 소유자가 수락합니다. 이전 중에도 앱은 스토어에 남아 있고 리뷰와 평점이 유지되며, 사용자도 계속 업데이트를 받습니다. 다만 이전 조건 문서에 걸리는 것이 몇 가지 있습니다. 양쪽 모두 최신 유료·무료 앱 약관에 동의되어 있어야 하고, 앱이 최소 한 번은 출시된 상태여야 하며, 심사 대기나 심사 중 같은 상태에서는 이전할 수 없습니다. TestFlight 베타 테스트도 미리 꺼 두어야 합니다.

이전 뒤에 따로 챙길 것도 있습니다. 같은 문서에 따르면 Apple Pay 가맹점 ID는 함께 넘어가지 않고, 푸시는 넘겨받은 쪽이 자기 팀에서 새 인증서나 키를 만들어 서버에 반영해야 합니다. 키체인 공유를 쓰는 앱은 다음 업데이트 후 사용자가 한 번 다시 로그인해야 한다고 안내되어 있어서, 공지 문구까지 미리 준비해 두는 편이 좋습니다.

구글 플레이 앱은 계정 간 이전으로 옮깁니다

안드로이드 앱도 Play Console 계정 사이에 옮길 수 있습니다. Google Play 앱 이전 도움말에 따르면 두 계정이 모두 등록되어 활성 상태여야 하고, 원래 계정 소유자가 요청하면 받는 계정 소유자가 승인한 뒤 Google 지원팀이 검토합니다. 요청할 때 양쪽 계정의 등록 거래 ID가 필요한데, 오래전에 만든 계정이면 이 번호를 찾는 데 시간이 걸리기도 합니다.

이전하면 사용자, 다운로드 통계, 평점과 리뷰, 스토어 등록 정보가 함께 넘어갑니다. 반대로 이전 전 주문 내역과 수익 보고서, 비공개 테스트 그룹은 넘어가지 않으니 필요한 보고서는 미리 내려받고 테스트 그룹은 새로 만들어야 합니다. 유료 앱이나 인앱 상품이 있다면 받는 계정에 결제 프로필이 있어야 합니다. Firebase 연결이나 Google Cloud 프로젝트 소유자 같은 연동 서비스 권한도 자동으로 옮겨지지 않아 직접 다시 설정해야 한다고 적혀 있습니다.

서명 키를 잃어버리면 어떻게 되나요

앱은 서명이라는 일종의 도장을 찍어 배포합니다. 같은 도장이 찍혀 있어야 기존 앱 위에 업데이트로 설치됩니다.

플랫폼별 서명 키 관리

Android

• 앱 서명 키는 구글이 보관
• 업로드 키는 재설정 요청 가능
• 직접 관리한 키는 재설정 불가

iOS

• 인증서는 계정에서 재발급
• 계정 확보가 먼저
• 푸시 인증서 만료일 확인

안드로이드는 Play 앱 서명을 쓰는지 먼저 확인합니다. Play 앱 서명 도움말에 따르면 이 방식에서는 사용자에게 배포되는 앱에 찍히는 앱 서명 키를 구글이 보관하고, 개발자는 업로드할 때 쓰는 업로드 키만 가집니다. 업로드 키를 잃어버리거나 유출이 의심되면 Play Console에서 재설정을 요청할 수 있습니다. 문제는 Play 앱 서명을 쓰지 않던 오래된 앱입니다. 개발자가 직접 관리하던 앱 서명 키를 잃어버리면 재설정할 수 없다고 문서에 나와 있습니다. 이전 업체에게 키 파일(keystore)과 비밀번호, 별칭을 반드시 함께 받아 두세요.

iOS는 사정이 조금 다릅니다. 배포 인증서와 프로비저닝 프로필은 Apple Developer 계정에서 다시 만들 수 있어서, 계정만 확보되면 크게 막히지 않습니다. 대신 인증서마다 만료일이 있고, 서버가 예전 푸시 인증서를 쓰고 있다면 만료 시점에 푸시가 끊깁니다. 넘겨받을 때 푸시를 인증서 방식으로 보내는지 키 방식으로 보내는지, 만료일은 언제인지 적어 두는 것이 좋습니다.

서버, 도메인, 외부 서비스 계정은 누구 명의인가요

앱 화면은 멀쩡한데 뒤에서 데이터를 주고받는 서버가 이전 업체 클라우드 계정에 있는 경우가 생각보다 많습니다. 이전 업체가 결제를 멈추는 순간 앱이 함께 멈춥니다. 외부 서비스도 마찬가지라서, 저희는 아래처럼 표를 만들어 하나씩 명의와 접근 권한을 확인합니다.

계약 주체가 이전 업체로 되어 있는 결제나 본인인증 서비스는 명의 변경에 서류가 필요하고 기간도 걸립니다. 앱 이전보다 이쪽이 더 오래 걸리는 경우가 많으니 가장 먼저 문의를 넣어 두는 편이 낫습니다.

관리자 페이지와 문서는 어디까지 받아야 하나요

운영사가 매일 쓰는 것은 앱보다 관리자 페이지입니다. 관리자 페이지 주소와 최고 관리자 계정, 그리고 이 페이지의 소스코드가 따로 있는지 확인합니다. 앱 코드는 받았는데 관리자 페이지는 이전 업체 솔루션을 빌려 쓰고 있었다는 사실을 나중에 아는 경우도 있습니다.

문서가 꼼꼼하지 않아도 괜찮습니다. 최소한 서버 구성도, API 목록, 환경별(개발·운영) 주소와 설정값, 배포 방법, 외부 서비스 목록이 있으면 이어받는 쪽이 길을 잃지 않습니다. 문서가 없다면 인수인계 기간 중에 이전 업체와 화면 공유로 배포를 한 번 같이 해 보는 것만으로도 빠진 정보가 많이 드러납니다.

저희가 쓰는 인수인계 순서

순서는 대체로 이렇습니다. 계정 명의 목록을 먼저 만들고, 코드와 키를 받아 빌드를 해 본 다음, 스토어 이전과 외부 서비스 명의 변경을 진행합니다. 마지막으로 작은 수정 하나를 실제로 배포해 봅니다.

인수인계 진행 순서

1. 명의 목록 작성계정과 서비스의 현재 명의 기록
2. 코드와 키 받기소스코드, 키 파일, 문서 수령
3. 직접 빌드iOS와 Android 빌드 후 비교
4. 스토어 이전이전 조건 맞춘 뒤 요청
5. 외부 서비스 이전서버, 도메인, 푸시, 결제 명의 변경
6. 시험 배포작은 수정으로 실제 배포 확인

1. 넘겨받을 계정과 서비스 목록을 만들고 현재 명의를 적습니다.
2. 소스코드, 키 파일과 비밀번호, 문서를 받습니다.
3. 받은 코드로 iOS와 Android를 각각 빌드해 스토어 버전과 비교합니다.
4. 앱스토어와 구글 플레이 이전 조건을 맞춘 뒤 이전을 요청합니다.
5. 서버, 도메인, 푸시, 결제 등 외부 서비스 명의와 권한을 옮깁니다.
6. 작은 수정을 넣은 업데이트를 테스트 트랙과 TestFlight를 거쳐 배포합니다.

6번까지 끝나야 이전 업체 도움 없이 앱을 고쳐서 내보낼 수 있다는 것이 확인됩니다. 그래서 이전 업체와의 계약이 끝나기 전에 이 단계까지 마치는 것을 목표로 일정을 잡습니다.

자주 묻는 질문

이전 업체와 연락이 되지 않으면 어떻게 하나요?

스토어 계정이 운영사 명의라면 앱 자체는 계속 업데이트할 수 있습니다. 소스코드가 없다면 새로 만들어야 할 수도 있고, 안드로이드는 Play 앱 서명 사용 여부에 따라 업로드 키 재설정으로 업데이트를 이어 갈 수 있습니다. 계정까지 이전 업체 명의라면 스토어 고객 지원에 문의해야 해서 시간이 오래 걸립니다.

앱을 옮기면 기존 사용자는 앱을 다시 설치해야 하나요?

Apple과 Google의 공식 이전 절차를 쓰면 다시 설치할 필요가 없습니다. 앱이 그대로 유지되고 리뷰와 평점도 넘어갑니다. 다만 iOS에서 키체인 공유를 쓰던 앱은 업데이트 후 한 번 다시 로그인해야 할 수 있습니다.

인수인계 기간은 얼마나 잡아야 하나요?

앱 규모와 문서 상태에 따라 차이가 큽니다. 스토어 이전 자체는 조건만 맞으면 오래 걸리지 않지만, 결제나 본인인증 같은 외부 서비스 명의 변경은 서류 절차가 있어 더 걸립니다. 이전 업체 계약 종료일에서 거꾸로 일정을 잡으시길 권합니다.

이어받은 코드가 너무 오래됐으면 새로 만드는 게 낫나요?

빌드를 해 보기 전에는 판단하기 어렵습니다. 라이브러리 버전만 올리면 되는 경우가 많고, 구조 자체가 지금 스토어 요건을 맞추기 어려운 경우도 있습니다. 빌드와 코드 점검 결과를 보고 고쳐 쓸지 새로 만들지 정하는 것이 순서입니다.

모바일파트너스는 다른 업체가 만든 앱을 넘겨받아 빌드 점검부터 계정 이전, 이후 유지보수까지 맡고 있습니다. 넘겨받을 앱이 있다면 상담 페이지로 현재 상황을 알려 주세요. 저희가 다루는 개발 범위는 개발 역량 페이지에서 보실 수 있습니다.