중단된 프로젝트를 이어받을 때 가장 먼저 코드를 수정하면 안 됩니다. 현재 운영 버전이 어떤 코드에서 배포됐는지, 데이터와 도메인을 누가 관리하는지 모르는 상태에서는 작은 변경도 장애나 데이터 손실로 이어질 수 있습니다. 인수의 첫 목표는 개선이 아니라 현재 상태를 재현하고 통제권을 확보하는 것입니다.

계정과 소유권부터 확인합니다

담당자가 바뀌어도 회사가 계속 관리할 수 있도록 다음 계정의 관리자 권한과 결제 주체를 확인합니다.

코드 저장소와 조직 계정
호스팅, 서버와 배포 서비스
도메인 등록 기관과 DNS
데이터베이스, 파일 저장소와 백업
이메일, 문자, 푸시 알림과 결제 서비스
분석, 오류 추적과 모니터링 도구
App Store와 Google Play 계정

개인 계정으로 운영 중이라면 바로 삭제하거나 이전하지 말고, 현재 연결 관계와 복구 수단을 기록한 뒤 회사 계정으로 전환합니다. 접근할 수 없는 계정은 인수 범위와 위험 항목에 명시해야 합니다.

운영 중인 버전을 보존합니다

현재 서비스가 실행된다는 사실과 새로 빌드할 수 있다는 사실은 다릅니다. 운영 환경의 주소, 배포 식별 정보, 주요 설정과 데이터 백업을 먼저 확보합니다. 그다음 저장소의 기본 브랜치와 배포 버전이 일치하는지 확인합니다.

재현 과정에서는 다음을 기록합니다.

필요한 실행 환경과 패키지 관리자
설치, 빌드, 테스트와 배포 명령
필요한 환경 변수의 이름과 관리 위치
외부 API와 테스트 계정
현재 실패하는 단계와 정확한 오류 메시지

비밀값을 문서에 그대로 복사하지 않고, 보관 위치와 권한 주체만 남기는 것이 안전합니다.

위험을 영향도에 따라 분류합니다

모든 문제를 한꺼번에 고치기보다 순서를 정해야 합니다. 일반적으로 데이터 손실과 보안, 결제, 로그인, 핵심 사용자 흐름, 운영 효율 순서로 영향도를 검토합니다.

예를 들어 스타일 오류와 결제 중복 요청이 함께 있다면 결제 흐름을 먼저 확인합니다. 오래된 의존성이 있다고 해서 즉시 전체 업그레이드를 시작하기보다 실제 취약점, 빌드 차단과 운영 영향을 구분해야 합니다.

데이터와 외부 연동을 별도로 점검합니다

코드 저장소만 받아서는 프로젝트를 운영할 수 없습니다. 데이터 구조, 백업과 복구 방법, 개인정보 접근 주체를 확인해야 합니다. 외부 API는 계약과 허용 도메인, 호출 제한, 웹훅 주소가 기존 개발사 환경에 묶여 있는지도 점검합니다.

데이터 이전이 필요하다면 원본 보존, 변환 규칙, 검증 방법과 되돌리는 절차를 먼저 합의합니다. 운영 중에 쓰기가 계속 발생하는 서비스는 최종 전환 시점의 변경분을 어떻게 반영할지도 결정해야 합니다.

복구와 리뉴얼을 분리합니다

인수 직후에는 현재 기능을 재현하고 주요 오류를 통제하는 복구 작업에 집중합니다. 화면 개편, 프레임워크 업그레이드와 데이터 구조 변경은 별도의 리뉴얼 범위로 나누는 편이 안전합니다.

이렇게 분리하면 어떤 변경이 장애를 만들었는지 추적하기 쉽고, 서비스 운영을 유지하면서 영향이 낮은 작업부터 적용할 수 있습니다. HD 뉴스레터 리뉴얼 사례에서도 라우팅, 데이터 흐름, 상태와 스타일 책임을 나눠 기존 구조를 단계적으로 정리했습니다.

운영 인계의 완료 기준

인수는 새 담당자가 배포하고 복구할 수 있을 때 완료됩니다. 다음 항목을 확인하세요.

회사 소유 계정으로 주요 서비스에 접근할 수 있다.
새 환경에서 설치, 빌드와 배포를 재현할 수 있다.
데이터 백업과 복구 방법을 확인했다.
주요 사용자 흐름과 오류 상황의 검수 결과가 있다.
알려진 제한 사항과 미완료 작업이 기록되어 있다.
비용, 모니터링, 장애 알림의 담당자가 정해져 있다.

다음 단계

리뉴얼·운영 서비스에서 진단, 복구, 이전과 운영 전환 범위를 확인할 수 있습니다. 새 개발사와 계약하기 전에는 개발 외주 계약 체크리스트를 사용해 코드, 계정과 데이터의 인계 기준을 문서에 반영하세요. 처음부터 새 범위를 산정해야 한다면 MVP 외주 견적 체크리스트도 함께 참고할 수 있습니다.