1. 소스 ZIP 파일이 있어도 바로 실행되지 않을 수 있습니다.
프로그램은 소스코드만으로 동작하지 않는 경우가 많습니다. 특정 버전의 실행환경과 라이브러리가 필요하고, DB와 연결되어야 하며, API 키와 환경설정도 맞아야 합니다. 실제 서비스에서는 웹서버, 파일저장소, 외부 API 등 여러 요소가 함께 작동합니다.
2. 소스코드와 함께 있어야 할 것들
현재 운영 중인 버전과 일치하는 전체 소스
언어·프레임워크·런타임과 주요 버전 정보
테이블·인덱스·마이그레이션 등 데이터 구조
개발·테스트·운영 환경의 설정 구조와 관리방법
결제·메일·문자·스토리지 등 연동 구성
프로그램을 만들고 서버에 반영하는 절차
3. 가능하다면 최종 ZIP보다 Git 저장소 자체를 인계받으세요.
최종 소스만 있으면 현재 상태는 볼 수 있지만 어떤 변경이 언제 이루어졌는지 확인하기 어렵습니다. Git 저장소에는 프로젝트에 따라 브랜치, 커밋 이력, 태그 등이 남아 있어 유지보수 과정에서 변경 내용을 추적하는 데 도움이 됩니다.
| 확인 항목 | 왜 필요한가? |
|---|---|
| 저장소 접근권한 | 후속 개발자가 소스를 지속적으로 관리하기 위해 |
| 운영 버전 기준 | 어떤 브랜치·태그·커밋이 현재 운영본인지 알기 위해 |
| 브랜치 구조 | 개발·테스트·운영 변경 흐름을 이해하기 위해 |
| 변경 이력 | 문제 발생 시 이전 변경사항을 추적하기 위해 |
| 저장소 소유권·관리권한 | 기존 업체와 계약이 끝나도 접근을 유지하기 위해 |
4. 가장 확실한 방법은 새로운 환경에서 재현해보는 것입니다.
인수인계 문서가 충분해 보이더라도 실제로 실행해보기 전에는 누락 여부를 알기 어렵습니다. 가능하다면 후속 담당자가 인계자료를 사용해 아래 과정을 직접 수행해보는 것이 좋습니다.
Git에서 운영 기준 소스 확보
필요한 런타임·라이브러리 설치
DB와 필요한 환경설정 구성
주요 기능이 정상 동작하는지 확인
테스트 환경에 직접 배포해 검증
5. 이런 상태라면 인수인계가 아직 끝나지 않았을 수 있습니다.
| 상태 | 위험 |
|---|---|
| 소스 ZIP만 있고 Git 접근이 없다 | 운영본 기준과 변경 이력 확인이 어려울 수 있음 |
| 실행 방법을 기존 개발자만 안다 | 담당자가 바뀌면 환경 구성부터 다시 분석해야 함 |
| DB 구조나 마이그레이션 정보가 없다 | 새 환경 구성과 데이터 변경이 어려워질 수 있음 |
| API 키·외부서비스가 업체 계정에 묶여 있다 | 계약 종료 후 서비스 연결이 끊길 위험 |
| 배포를 업체만 할 수 있다 | 긴급 수정이나 업체 변경 시 운영 통제력이 떨어짐 |
| 운영본과 전달받은 소스가 같은지 모른다 | 수정 후 배포 시 기능이 되돌아가거나 누락될 위험 |
인수인계 문서는 ‘개발 설명서’보다 ‘다음 개발자를 위한 출발점’이어야 합니다.
모든 코드를 상세하게 설명하는 방대한 문서가 반드시 필요한 것은 아닙니다. 후속 담당자가 프로젝트 구조를 파악하고 실행·배포·운영을 시작하는 데 필요한 핵심 정보가 정확하게 정리되어 있는지가 더 중요합니다.
6. 소스코드 인수 체크리스트
소스코드 인수의 완료 기준은 ‘받았다’가 아니라 ‘다른 개발자가 실행하고 배포할 수 있다’입니다.
소스 + 환경 + 데이터 + 설정 + 계정 + 배포방법이 연결되어야 실제로 유지보수 가능한 개발자산이 됩니다.