앱 개발 외주 인수인계 체크리스트

1 출시 버전과 연결되는 소스코드를 확인합니다

스토어에 배포된 앱 버전과 대응하는 저장소, 브랜치, 커밋 또는 태그를 기록합니다. 작업 중인 브랜치와 출시된 코드가 다르면 어느 시점부터 다음 작업을 시작할지 불명확해질 수 있습니다.

• 앱과 서버 및 관리자 웹 등 계약 범위에 포함된 저장소 목록
• 출시 버전 번호와 대응하는 커밋 또는 태그
• 의존성 파일과 프로젝트에서 사용하는 잠금 파일
• 미반영 변경사항과 알려진 오류 및 지원하지 않는 기능
• 의뢰 조직이 저장소와 백업을 관리할 방법

완료 기준의 예시는 새 담당자가 지정한 출시 코드에 접근하고, 각 저장소가 어떤 기능을 담당하는지 설명할 수 있는 상태입니다. 단순히 압축파일 이름에 최종이라고 적혀 있는지는 충분한 확인 기준이 아닙니다.

2 별도 작업 환경에서 실행과 빌드를 재현합니다

Flutter와 Dart, Xcode와 Android 도구 등 실제 사용하는 개발 환경의 버전과 설치 순서를 기록합니다. 프로젝트에 환경별 설정이 있다면 테스트와 운영의 차이, 설정값을 주입하는 위치, 빌드 명령과 출력 파일도 구분합니다.

• 필요한 도구와 버전 및 설치 안내
• 패키지 설치와 코드 생성 등 실행 전 작업
• 테스트와 운영 환경을 선택하는 방법
• Android와 iOS의 빌드 및 내부 테스트 절차
• 실패한 빌드의 로그를 확인할 위치

다음 담당자가 안내문만으로 준비된 테스트 환경에서 앱을 실행하고 빌드를 만드는지 확인하세요. 이때 실제 운영 데이터나 공개 배포를 건드리지 않는 검수 범위를 정하고, 재현 결과와 남은 장애를 기록합니다.

3 스토어 권한 변경과 앱 이전을 구분합니다

Play Console과 App Store Connect에서 누가 앱을 보유하고 누가 출시 작업을 수행하는지 확인합니다. 의뢰 조직의 계정에 개발자가 참여한 경우와 개발사 계정에 앱이 등록된 경우는 인수인계 방식이 다를 수 있습니다. 담당자 변경이 곧 앱의 계정 간 이전을 의미하지는 않습니다.

다른 개발자 계정이나 조직으로 앱을 옮겨야 한다면 정식 이전 조건을 먼저 검토합니다. Apple은 이전 가능한 앱인지 확인하고 정보를 백업한 뒤, 양쪽 Account Holder가 시작과 수락을 진행하도록 안내합니다. 결제와 로그인 및 알림 등 사용하는 기능에 따라 추가 점검이 있습니다. Apple 앱 이전 개요를 기준으로 프로젝트에 해당하는 항목을 확인하세요.

Google Play도 원래 계정과 대상 계정의 준비 상태, 서명 방식, 결제와 연동 서비스 확인을 별도로 안내합니다. 계정 비밀번호 공유로 절차를 대신하지 마세요. Google Play 앱 이전 안내에서 현재 조건을 확인할 수 있습니다.

완료 기준은 다음 담당자가 합의한 계정 구조에서 해당 앱을 확인하고 필요한 출시 작업을 수행할 권한을 확보한 상태입니다. 실제 공개 제출은 별도 승인 절차로 구분합니다.

4 서버와 외부 서비스 및 결제 담당자를 기록합니다

Firebase와 데이터베이스, 서버와 관리자 페이지, 도메인과 DNS, 알림과 문자 및 메일, 분석과 오류 모니터링처럼 앱과 연결된 서비스를 목록화합니다. 서비스별 프로젝트 식별자, 관리 화면, 운영 담당자, 결제 담당자와 사용량 확인 위치를 남깁니다. 개발 비용과 반복되는 외부 이용료도 구분합니다.

앱 이전은 모든 외부 서비스의 이전을 대신하지 않습니다. Google Play 공식 안내도 Firebase 연결, 분석 권한, 광고 SDK 등 연동 서비스에 대한 별도 조치를 설명합니다. 앱 이전과 서버 프로젝트 접근 권한, 청구 관리가 각각 완료됐는지 확인하세요. 연동 서비스 확인 항목을 참고할 수 있습니다.

Firebase는 프로젝트 구성원에게 역할을 부여해 권한을 관리합니다. 새 담당자에게 필요한 작업 권한을 확인하되, 편의를 위해 모든 담당자에게 광범위한 권한을 주는 방식은 피하세요. Firebase IAM 안내는 역할과 필요한 권한만 부여하는 원칙을 설명합니다.

5 서명 자산과 인증 정보는 안전한 접근 경로로 전달합니다

앱 서명과 업로드에 필요한 자산, 서버와 외부 API 인증 정보는 일반 운영 문서와 분리해서 관리합니다. 문서에는 원문 비밀값이 아니라 보관 장소, 관리 책임자, 접근 권한을 받는 절차, 만료와 교체 및 복구 방법을 적습니다.

• Android의 Play App Signing 사용 여부와 업로드 키 관리 방식
• iOS의 서명과 배포 설정 및 알림 인증 정보 관리 방식
• 서버에서 사용하는 비밀값의 이름과 주입 위치 및 담당자
• 자동 배포가 사용하는 계정과 실제 필요한 권한
• 인수 완료 후 기존 담당자 접근을 정리하는 순서

Google Play는 앱 이전 시 업로드 키와 앱 서명 키의 보안을 각각 검토하도록 안내합니다. 두 키를 같은 것으로 취급하거나 모든 앱에서 개인 서명 키를 파일로 받아야 한다고 단정하지 마세요. Play App Signing 관련 이전 항목을 확인할 수 있습니다.

키 교체나 권한 회수 전에는 새 접근 경로와 영향 범위를 확인합니다. 새 담당자의 작업 가능 여부를 검증한 뒤 불필요한 접근을 정리하는 순서를 합의하세요.

6 운영 문서와 디자인 자료 및 검수 결과를 남깁니다

관리자 사용법, 화면과 기능 명세, API 문서, 디자인 원본, 스토어 소개와 이미지, 정책과 고객지원 주소를 정리합니다. 외부 폰트와 이미지 및 라이브러리를 사용했다면 출처와 적용되는 이용 조건, 관리해야 할 자료를 기록하세요. 전달 범위와 사용할 권한은 계약과 실제 구성에 맞춰 확인합니다.

검수 문서에는 테스트 환경과 계정, 정상 동작 기준, 알려진 오류와 재현 방법, 다음 버전 후보를 구분합니다. 실패한 테스트를 완료된 항목으로 처리하지 말고 담당자와 처리 계획을 남깁니다. 운영 사용자 개인정보나 비밀값이 들어간 화면을 공유 자료로 사용하지 않도록 확인하세요.

7 다음 업데이트와 장애 대응을 위한 검수를 진행합니다

최종 검수는 파일 수가 아니라 합의한 작업을 수행할 수 있는지로 확인합니다. 다음 담당자가 테스트 환경에서 실행과 빌드를 하고, 필요한 콘솔에 자신의 계정으로 접근하고, 제출 준비와 되돌리기 절차를 설명하도록 검수안을 구성할 수 있습니다.

• 지정한 버전에서 앱을 실행하고 테스트 빌드를 만듭니다
• 합의한 핵심 사용자 흐름을 테스트 환경에서 확인합니다
• 스토어와 서버 및 관리 도구의 작업 권한을 확인합니다
• 장애 기록과 백업 및 복구 절차를 확인합니다
• 미해결 항목과 담당자 및 인수 완료 조건을 기록합니다

오류 수정, 기능 추가, 운영체제 대응, 외부 서비스 정책 변경에 대한 작업 범위와 지원 기간 및 연락 경로를 구분하세요. 실제 배포와 권한 회수 및 인증 정보 교체는 각 작업의 담당자와 승인 조건을 정한 뒤 진행합니다.

현재 전달받은 자료로 먼저 점검합니다

이미 인수인계가 끝났다면 저장소 주소, 스토어 주소, 전달받은 문서 목록과 현재 막힌 단계를 먼저 정리하세요. 키플에 점검을 문의할 때는 이 정보부터 공유하면 필요한 확인 범위를 구분할 수 있습니다. 처음 문의에 계정 비밀번호와 인증키 또는 실제 고객 데이터를 첨부할 필요는 없습니다.

업데이트를 준비 중이라면 Flutter 앱 유지보수 비용과 범위, 출시 단계에서 막혔다면 앱스토어와 구글 플레이 심사 대응도 함께 읽어보세요.

이 글은 기술 인수인계를 위한 점검안이며 모든 프로젝트의 이전 가능성이나 작업 비용을 보장하지 않습니다. 필요한 전달 항목과 권리 및 지원 범위는 계약과 실제 운영 구조, 각 서비스의 현재 조건에 맞춰 확인해야 합니다.