개발업체를 변경해야 하는 상황이라면 새 업체를 먼저 찾는 것보다 현재 프로젝트를 다른 개발자가 재현할 수 있는 상태로 만드는 것이 우선입니다. 소스코드, DB, 서버, 계정, 배포방법, 미완료 기능을 확보해야 전환 비용을 줄일 수 있습니다.
“새 개발자가 기존 업체 도움 없이 실행·분석·배포할 수 있는가?”
이 질문에 답할 수 있다면 업체 변경의 위험이 크게 줄어듭니다.
현재 운영 버전과 Git 이력 확보
서버·도메인·API·관리자 계정
완료·미완료·버그·변경요청 구분
새 환경에서 실행·배포 가능한지 확인
계약 종료보다 자산 확보가 먼저
오래된 ZIP 파일만 받으면 실제 서비스 상태를 재현하기 어렵습니다.
언제 무엇이 변경되었는지 알아야 장애와 기능 흐름을 추적할 수 있습니다.
테이블 구조뿐 아니라 실제 복구 가능한 백업이 있는지 확인합니다.
DB 외부에 저장된 파일이 누락되지 않도록 확인합니다.
업체 계정으로만 접근 가능한 서버라면 먼저 권한을 이전합니다.
특정 개발자의 PC에서만 배포되는 구조는 전환 리스크가 큽니다.
서비스 운영에 필요한 핵심 계정을 하나씩 확인합니다.
API 키 자체뿐 아니라 어디에서 어떤 용도로 쓰이는지 알아야 합니다.
“80% 완료”가 아니라 기능 단위로 완료 여부를 표시합니다.
새 업체가 기존 계약 책임과 신규 작업을 혼동하지 않도록 합니다.
코드만 전달하면 새 업체가 업무를 다시 해석하는 시간이 길어집니다.
문서에 없는 경험 지식도 전환 전 가능한 범위에서 확보합니다.
완료·미완료 기능과 계약상 잔여범위를 정리합니다.
소스·DB·문서·계정 접근권한을 먼저 확보합니다.
자료를 전달하고 인수 가능 여부와 위험을 확인합니다.
로컬·테스트 환경에서 실행·빌드를 재현합니다.
새 업체가 실제 운영환경에 배포할 수 있는지 확인합니다.
전환 완료 후 이전 업체 접근권한을 회수합니다.
변경 이력과 운영 버전을 확인하기 어려워 새 업체 분석 시간이 늘어납니다.
서비스 이전 자체가 별도 프로젝트가 될 수 있으므로 먼저 소유·권한 관계를 확인합니다.
소스가 있어도 외부 연동과 운영환경을 재현하지 못할 수 있습니다.
데이터 이전과 복구 검증에 예상보다 많은 시간이 필요할 수 있습니다.
문서와 자동화가 없으면 인수 후 첫 배포부터 장애 위험이 커집니다.
디자인·폰트·플러그인·상용 솔루션 사용권을 새 업체가 그대로 쓸 수 있는지 확인합니다.
| 영역 | 확인 내용 | 신규 업체가 확인할 질문 | 상태 |
|---|---|---|---|
| 구조 | 프론트·백엔드·DB·외부연동 구성 | 서비스는 어떤 구조로 실행되는가? | □ 확인 |
| 소스 | Git 저장소와 현재 운영 버전 | 어떤 브랜치·커밋이 운영 중인가? | □ 확인 |
| DB | DB 접속·스키마·백업 | 개발/운영 DB는 어떻게 구분되는가? | □ 확인 |
| 배포 | 빌드·배포·롤백 절차 | 운영 반영과 복구는 어떻게 하는가? | □ 확인 |
| 연동 | 외부 API·메일·결제·알림 | 각 연동 계정과 만료·비용 조건은? | □ 확인 |
| 이슈 | 미완료·버그·기술부채 | 현재 가장 위험한 기능은 무엇인가? | □ 확인 |
소스 내려받기, 로컬 실행, DB 연결, 주요 외부연동을 확인합니다.
핵심 사용자 흐름과 관리자 기능을 직접 테스트합니다.
작은 수정사항으로 테스트·운영 배포 절차를 실제 확인합니다.
인수 후 확인된 상태를 기준으로 일정·비용·우선순위를 다시 정합니다.
개발업체가 바뀌더라도 소스·DB·계정·배포방법·현재 상태가 명확하면 서비스는 이어갈 수 있습니다. 반대로 이 정보가 부족하면 새 업체는 개발보다 기존 시스템을 복원하는 데 먼저 비용과 시간을 쓰게 됩니다.