이 글의 순서
- 01앱개발업체 변경은 소스코드 파일을 받는 것으로 끝나지 않습니다
- 02먼저 현재 서비스의 운영 구조를 한 장으로 정리합니다
- 03소스코드는 실제 운영 버전을 다시 빌드할 수 있어야 합니다
- 04서버·데이터베이스·도메인의 명의와 접근 권한을 확인합니다
- 05앱스토어와 플레이스토어는 비밀번호보다 소유권을 확인합니다
- 06결제·문자·지도 같은 외부 서비스도 별도 계정입니다
- 07데이터는 백업뿐 아니라 구조와 이전 책임을 함께 확인합니다
- 08운영 기록과 남은 문제를 함께 인수합니다
- 09기존 업체와 새 업체의 책임이 바뀌는 날짜를 정합니다
- 10새 앱개발업체에 전달할 인수 자료 8가지
- 11업체 변경 전에 확인할 질문 7가지
- 12새 기능 견적보다 인수 가능 범위를 먼저 확인하세요
앱개발업체 변경은 소스코드 파일을 받는 것으로 끝나지 않습니다
운영 중인 앱의 개발업체를 바꿀 때 가장 먼저 떠올리는 자료는 소스코드입니다. 하지만 압축된 소스코드 파일만 전달받아도 새 업체가 바로 수정하고 배포할 수 있는 것은 아닙니다.
현재 앱이 어떤 저장소의 어느 버전으로 배포됐는지, 빌드에 필요한 설정과 외부 라이브러리는 무엇인지, 서버와 데이터베이스는 어느 계정에서 실행되는지, 앱스토어와 플레이스토어의 소유권은 누구에게 있는지 함께 확인해야 합니다. 결제·문자·지도·본인인증처럼 앱 밖에서 사용하는 서비스도 빠질 수 없습니다.
앱개발업체 변경은 크게 아래 여섯 영역을 인수하는 작업입니다.
이 여섯 영역 중 하나라도 기존 업체나 담당자의 개인 계정에만 남아 있으면 새 업체가 코드를 이해해도 운영과 배포를 이어가기 어렵습니다.
확인해보세요
- 소스코드와 실제 빌드 환경
- 서버·데이터베이스·파일과 백업
- 도메인·DNS와 배포 환경
- Apple·Google 앱과 배포 권한
- 결제·문자·지도 등 외부 서비스 계정
- 운영 기록·장애 확인·남은 작업
먼저 현재 서비스의 운영 구조를 한 장으로 정리합니다
새로운 앱개발업체에 리뉴얼 견적을 요청하기 전에 현재 서비스가 어떻게 연결돼 있는지부터 확인하세요.
구성 요소마다 현재 명의, 접근 가능한 사람, 결제 주체, 갱신일, 새 업체에 필요한 권한을 함께 적으면 누락된 영역을 찾기 쉽습니다.
계정 비밀번호 자체를 여러 사람에게 전달하는 방식은 피하는 것이 좋습니다. 서비스가 지원한다면 고객사 소유 계정에서 새 담당자를 사용자로 초대하고 필요한 역할만 부여하세요. 계정 소유자와 실무 접근 권한을 구분하면 업체가 바뀔 때 개인 계정 전체를 공유하거나 비밀번호를 반복해서 바꾸는 문제를 줄일 수 있습니다.

확인해보세요
- 고객이 사용하는 iOS·Android 앱과 웹
- 운영자·파트너가 사용하는 관리자 화면
- 앱과 관리자의 요청을 처리하는 서버
- 회원·주문·예약·콘텐츠를 저장하는 데이터베이스
- 사진·문서·영상이 저장되는 파일 공간
- 도메인, DNS와 보안 인증서
- Apple App Store와 Google Play 등록 계정
- 결제·문자·지도·로그인·분석 등 외부 서비스
- 오류 기록, 모니터링, 백업과 정기 실행 작업
소스코드는 실제 운영 버전을 다시 빌드할 수 있어야 합니다
소스코드를 전달받았다는 사실과 현재 운영 중인 앱을 같은 결과로 빌드할 수 있다는 사실은 다릅니다. 새 업체가 확인할 기본 항목은 다음과 같습니다.
환경 변수나 API 키의 이름과 용도는 문서화해야 하지만 실제 비밀값을 일반 문서나 메신저에 그대로 복사해서 전달해서는 안 됩니다. 새 업체가 사용할 별도 계정과 비밀값을 발급하거나 권한이 통제되는 안전한 전달 방식을 정하고, 인수가 끝나면 기존 업체의 불필요한 접근 권한을 회수합니다.
새 업체는 첫 기능을 수정하기 전에 기존 소스로 개발 환경을 실행하고 테스트 빌드를 만들어보는 것이 좋습니다. 이 과정에서 빠진 파일, 종료된 외부 라이브러리, 특정 개발자 컴퓨터에만 있는 인증서와 자동화 설정을 찾을 수 있습니다.
확인해보세요
- 고객 앱·관리자·서버의 전체 저장소 주소
- 현재 운영에 배포된 버전과 연결되는 브랜치·태그·커밋
- 사용하는 언어·프레임워크·도구의 버전
- 의존성 설치와 개발 환경 실행 방법
- 개발·테스트·운영 환경을 구분하는 설정 항목 목록
- iOS·Android 빌드와 서명에 필요한 절차
- 서버 배포·되돌리기와 데이터 변경 순서
- 유료 라이브러리·폰트·이미지와 사용 권한
- 자동 배포, 테스트와 코드 품질 확인 설정
서버·데이터베이스·도메인의 명의와 접근 권한을 확인합니다
앱 화면을 수정할 수 있어도 서버와 데이터에 접근하지 못하면 회원·주문·예약 정보를 확인하거나 오류를 고치기 어렵습니다.
접근 권한을 받기 전에 데이터베이스와 파일의 최신 백업을 만들고, 백업 파일이 있다는 사실뿐 아니라 실제 복구에 필요한 정보가 있는지도 확인합니다. 데이터베이스 구조만 있고 사진 파일이나 외부 저장소가 빠지는 경우도 있으므로 데이터 종류별 보관 위치를 나눠 봐야 합니다.
서버를 새 계정으로 옮길 때는 데이터 이전, 도메인 전환, 외부 서비스 주소 변경, 앱의 서버 주소 변경과 새 버전 배포가 서로 연결될 수 있습니다. 기존 환경을 바로 종료하지 말고 새 환경에서 기능과 데이터를 확인한 뒤 전환 시점을 잡으세요.
확인해보세요
- 클라우드·호스팅 계정의 명의와 결제 주체
- 운영·테스트 서버와 데이터베이스 목록
- 파일 저장 공간, 이메일과 메시지 발송 환경
- 도메인 등록 업체, DNS와 보안 인증서 관리 주체
- 백업 주기, 보관 위치와 복구 절차
- 서버 로그, 오류 알림과 모니터링 접근 권한
- 예약 발송, 정산, 데이터 정리처럼 자동으로 실행되는 작업
- 방화벽·접근 허용 목록과 관리자 접속 방식
앱스토어와 플레이스토어는 비밀번호보다 소유권을 확인합니다
개발업체만 바뀌고 앱을 소유한 회사는 그대로라면 스토어 계정 전체를 이전할 필요 없이 고객사 계정에 새 업체 담당자를 초대하고 기존 업체의 접근 권한을 정리할 수 있습니다.
반대로 기존 앱이 개발업체나 다른 사업자의 개발자 계정에 등록되어 있다면 단순 로그인 정보 공유가 아니라 공식 앱 이전 절차가 필요할 수 있습니다.
Apple의 앱 이전에서는 기존 리뷰와 평점, Bundle ID를 유지할 수 있지만 구독, Apple Pay, Sign in with Apple, 푸시 알림, iCloud 같은 기능을 사용한다면 이전 뒤 인증서·키·서비스 연결을 다시 확인해야 합니다. 실제 소스코드와 빌드 자료는 Apple이 대신 전달하지 않으므로 기존 업체와 새 업체가 별도로 인수해야 합니다.
Google Play의 앱 이전에서도 사용자, 다운로드 통계, 평점·리뷰와 스토어 등록 정보는 대상 계정으로 이전되지만 일부 내보내기·지급·수익 보고서는 이전되지 않을 수 있으므로 필요한 자료를 먼저 내려받아야 합니다.
따라서 스토어 인수 전에는 아래 항목을 확인하세요.
실제 이전 시점에는 Apple의 앱 이전 안내와 Google Play의 앱 이전 체크리스트를 다시 확인해야 합니다.
확인해보세요
- 앱이 등록된 계정과 법인·사업자 명의
- 계정 소유자와 새 업체에 부여할 역할
- iOS Bundle ID와 Android 패키지 이름
- 앱 서명·배포 인증서와 갱신 방법
- 푸시 알림, 로그인, 결제와 구독 연결
- 스토어 설명·이미지·개인정보 표시와 심사 이력
- 이전 전에 내려받아야 할 판매·지급·분석 자료
- 진행 중인 심사·테스트·예약 출시 여부
결제·문자·지도 같은 외부 서비스도 별도 계정입니다
앱과 서버 계정을 모두 인수해도 외부 서비스 연결이 기존 업체 계정에 남아 있으면 알림, 결제나 로그인이 중단될 수 있습니다.
각 항목에는 계정 명의, 계약 주체, 사용 중인 상품, 월 또는 사용량 비용, 운영·테스트 키, 허용된 도메인과 서버 주소, 담당자 연락처를 기록합니다. 기존 키를 그대로 넘겨받기보다 고객사 계정에서 새 키를 발급하고 새 설정을 먼저 시험한 뒤 기존 키 폐기 시점을 정하는 편이 안전합니다.
확인해보세요
- 결제대행사와 정산 계정
- 문자·카카오 알림·이메일 발송 계정
- 지도·주소 검색과 위치 서비스
- 소셜 로그인과 본인인증
- 앱 푸시 알림과 기기 토큰 관리
- 분석·광고·고객 문의와 오류 수집 도구
- AI·OCR·번역·파일 변환 서비스
- 외부 ERP·관제·공공데이터·파트너 API
데이터는 백업뿐 아니라 구조와 이전 책임을 함께 확인합니다
데이터 인수에서 중요한 것은 데이터베이스 파일 하나가 아닙니다.
실제 개인정보를 개발자의 로컬 컴퓨터나 테스트 환경에 그대로 복제하지 않도록 이전 방식과 접근 권한을 정해야 합니다. 테스트가 필요하다면 식별 정보를 가리거나 별도 샘플 데이터를 사용하는 방법을 검토합니다.
확인해보세요
- 회원·주문·예약·결제·상담 등 주요 데이터 종류
- 사진·문서·영상 같은 별도 파일
- 데이터베이스 구조와 각 상태값의 의미
- 관리자 화면에서 수정되는 값과 서버가 자동 계산하는 값
- 보관·삭제·탈퇴와 접근 권한 규칙
- 외부 서비스에만 남아 있는 거래·발송·분석 기록
- 현재 데이터 용량과 이전에 필요한 시간
- 백업 생성·전달·복구 검증과 폐기 책임
운영 기록과 남은 문제를 함께 인수합니다
소스와 계정이 모두 있어도 운영 중 반복되던 문제와 해결 방법을 모르면 새 업체가 같은 원인을 처음부터 다시 찾게 됩니다.
가능하다면 기존 업체, 고객 운영 담당자와 새 업체가 함께 현재 구조와 남은 문제를 확인하고 질문과 답을 문서에 남기세요.
확인해보세요
- 현재 배포 버전과 최근 변경 내용
- 알려진 오류와 임시 대응 방법
- 서버 장애·성능 저하·외부 서비스 실패 이력
- 사용량이 늘 때 먼저 확인할 서버와 비용 항목
- 매일·매주·매월 운영자가 처리하는 업무
- 자동 실행 작업과 실패 시 확인 방법
- 아직 완료하지 않은 기능과 우선순위
- 앱 마켓·외부 서비스의 보완 요청과 예정된 정책 변경
- 고객 문의가 반복되는 화면과 운영 규칙
기존 업체와 새 업체의 책임이 바뀌는 날짜를 정합니다
권한을 넘기기 시작한 날과 새 업체가 모든 운영 책임을 맡는 날은 같지 않을 수 있습니다. 안전한 전환은 다음 순서로 진행할 수 있습니다.
전환 중 문제가 생기면 어느 환경과 버전으로 되돌릴지, 긴급 장애는 누가 먼저 확인할지도 정합니다. 기존 서버나 계정을 너무 빨리 종료하면 데이터를 비교하거나 이전 버전으로 돌아갈 수 없으므로 안정화가 끝난 뒤 정리하세요.

확인해보세요
- 현재 서비스·계정·문서와 남은 문제를 조사합니다.
- 코드·데이터·설정과 필요한 보고서를 백업합니다.
- 새 업체에 제한된 확인 권한을 먼저 부여합니다.
- 기존 소스로 개발 환경과 테스트 빌드를 재현합니다.
- 서버·외부 서비스와 앱의 핵심 기능을 확인합니다.
- 작은 수정이나 테스트 배포로 실제 배포 절차를 검증합니다.
- 운영 책임 전환일과 장애 연락 체계를 확정합니다.
- 안정화 후 기존 업체의 불필요한 권한과 키를 정리합니다.
새 앱개발업체에 전달할 인수 자료 8가지
자료가 모두 없더라도 업체 변경을 시작할 수는 있습니다. 다만 새 업체가 먼저 조사하고 복구해야 하는 범위가 커질 수 있으므로 현재 보유, 기존 업체에 요청, 새 업체가 조사 세 상태로 나눠 누락을 표시하세요.
확인해보세요
- **서비스 구조도** — 고객 앱·관리자·서버·데이터와 외부 서비스 연결
- **저장소와 빌드 안내** — 운영 버전, 실행·빌드·배포 방법과 필요한 도구
- **서버·도메인 목록** — 계정 명의, 환경, 결제·갱신과 접근 방식
- **데이터·백업 안내** — 데이터 종류, 용량, 백업 위치와 복구 방법
- **스토어·배포 정보** — 앱 소유 계정, 앱 식별자, 서명과 심사 상태
- **외부 서비스 목록** — 결제·알림·로그인·지도·분석의 계정과 담당자
- **운영·장애 기록** — 반복 업무, 모니터링, 알려진 오류와 대응 이력
- **남은 작업 목록** — 수정·개선·신규 기능과 우선순위, 완료 기준
업체 변경 전에 확인할 질문 7가지
계약 전에 결과물과 계정의 소유 관계를 확인하는 기준은 앱 외주 계약 전에 확인할 소스코드·서버·계정에서, 새 업체를 비교하는 기준은 앱개발업체를 선택하기 전에 확인할 7가지에서 이어서 확인할 수 있습니다.
확인해보세요
- 현재 운영 앱과 같은 버전을 소스코드로 다시 빌드할 수 있나요?
- 서버·데이터베이스·도메인·스토어와 외부 서비스의 소유 계정은 누구 명의인가요?
- 최신 데이터와 파일을 백업하고 복구 결과를 확인할 수 있나요?
- 앱 서명·푸시·로그인·결제처럼 이전 뒤 다시 설정할 기능은 무엇인가요?
- 기존 서비스의 알려진 오류와 완료되지 않은 작업은 무엇인가요?
- 기존 업체와 새 업체의 운영 책임은 언제 바뀌며 장애가 나면 누가 먼저 대응하나요?
- 안정화가 끝난 뒤 회수할 접근 권한·키·개인정보 사본은 무엇인가요?
새 기능 견적보다 인수 가능 범위를 먼저 확인하세요
운영 중인 앱의 개발업체를 바꿀 때는 원하는 개선 기능만 설명하기보다 현재 서비스를 어디까지 안전하게 인수할 수 있는지 먼저 확인해야 합니다. 코드와 계정, 데이터, 배포 방법과 운영 기록이 연결돼야 새 업체도 기존 기능을 유지하면서 개선 범위와 일정을 현실적으로 판단할 수 있습니다.
기존 서비스를 이어받아 개선한 사례와 신규 서비스를 처음부터 구축한 사례는 데브크래프트 개발 사례에서 비교할 수 있습니다. 현재 보유한 소스코드와 계정, 개선하고 싶은 기능을 알려주시면 기존 앱 인수·개선 범위 30분 무료 상담에서 먼저 확인할 자료와 다음 진행 순서를 함께 정리해드립니다.


