1. 소스코드는 서비스 자산의 일부입니다.
웹이나 앱을 다시 실행하려면 코드뿐 아니라 데이터베이스, 환경설정, 파일 저장소, 외부 API, 서버 구성 등이 필요할 수 있습니다. 화면을 수정하려면 디자인 원본과 디자인 시스템이 필요하고, 운영업무를 이해하려면 관리자 기능이나 데이터 구조에 대한 설명도 필요합니다.
인수인계의 기준은 “파일을 몇 개 받았는가?”가 아니라 “다른 담당자가 서비스를 재현하고 계속 운영할 수 있는가?”입니다.
2. 디자인은 이미지보다 ‘편집 가능한 원본’을 확인하세요.
| 항목 | 확인할 내용 | 왜 필요한가? |
|---|---|---|
| 디자인 원본 | Figma 등 실제 작업에 사용한 편집 가능한 파일·프로젝트 접근권한 | 후속 화면 수정과 신규 기능 디자인 |
| 디자인 시스템 | 색상, 폰트, 버튼, 입력폼 등 공통 컴포넌트 | 서비스 UI의 일관성 유지 |
| 이미지·아이콘 | 원본 파일과 사용 라이선스 | 재사용·수정 가능 여부 확인 |
| 폰트 | 사용 폰트와 라이선스 조건 | 웹·앱·홍보물 사용조건 확인 |
단, 디자인 도구의 원본 파일이나 유료 에셋에 대한 권리·이전 가능 여부는 계약과 해당 서비스의 라이선스 조건에 따라 달라질 수 있으므로 미리 확인해야 합니다.
3. DB는 데이터 파일 하나만 받는 것으로 끝나지 않습니다.
구조DB 구조
테이블·컬럼·관계·인덱스 등 서비스를 구성하는 데이터 구조
데이터운영 데이터
서비스에 축적된 실제 데이터와 필요한 이전 범위
변경 이력변경 이력
스키마를 재현하기 위한 migration·DDL 등 프로젝트 방식에 맞는 정보
백업백업·복구
백업 위치, 주기, 복구 절차와 실제 복구 가능 여부
접근 권한접근권한
운영·개발 DB 계정과 역할별 접근방식
보안민감정보
개인정보·인증정보의 안전한 이전 및 접근통제
4. 소스·디자인·DB 외에도 함께 확인하세요.
| 자산 | 예시 | 인수 시 확인 |
|---|---|---|
| 사용자 업로드 파일 | 첨부파일·이미지·문서 | 저장 위치, 접근권한, 백업 |
| API 문서 | 내부 API·외부 연동 명세 | 인증방식, 호출 규칙, 테스트 정보 |
| 배포 정보 | 빌드·배포 절차, CI/CD | 다른 담당자가 재배포 가능한지 |
| 외부서비스 | 결제·문자·메일·지도·분석 | 계정, 계약주체, API 설정, 비용 |
| 운영 문서 | 관리자 사용법·장애 대응 | 실제 운영자가 활용 가능한 수준인지 |
| 미해결 항목 | 잔여 버그·추가개발·기술부채 | 현재 상태와 후속 조치가 기록됐는지 |
5. 인계받은 뒤 ‘새 환경에서 재현’해보는 것이 가장 좋습니다.
목록에 체크했다고 인수가 끝난 것은 아닙니다. 가능하다면 새로운 담당자 또는 후속 개발업체가 인계 자료만 보고 프로젝트를 실행해보는 방식으로 검증하세요.
01소스 확보
저장소 접근과 최신 버전 확인
02환경 구성
DB·설정·외부서비스 연결
03빌드·배포
문서만으로 실행·배포 가능한지 확인
04운영 확인
주요 기능·데이터·관리자 정상 여부 확인
6. 개발 완료 전 인수 체크리스트
최신 소스코드와 Git 저장소 접근권한을 확보했다.
편집 가능한 디자인 원본과 필요한 디자인 자산을 확인했다.
DB 구조와 필요한 데이터·백업·복구 방법을 확인했다.
사용자 업로드 파일과 저장소의 위치·권한을 확인했다.
외부 API와 결제·문자·메일 등 서비스 계정을 확인했다.
빌드·배포 및 운영에 필요한 문서를 확보했다.
미해결 버그·추가개발·기술 이슈 목록을 인계받았다.
새 담당자가 인계 자료만으로 서비스를 실행·배포할 수 있는지 확인했다.
데이터 인계 주의: 운영 DB에는 개인정보, 인증정보, 결제 관련 정보 등 보호가 필요한 데이터가 포함될 수 있습니다. 실제 데이터 이전은 관련 법령·계약·보안정책과 각 서비스의 접근통제 절차를 확인하고 필요한 범위에서 안전하게 진행해야 합니다.
한 줄 원칙
인수인계는 소스코드를 받는 일이 아니라, 서비스를 이어서 운영할 수 있는 자산을 넘겨받는 일입니다.
소스 + 디자인 + DB + 파일 + 계정 + 배포정보 + 문서가 함께 연결되어야 개발업체가 바뀌어도 서비스의 연속성을 유지할 수 있습니다.