1. 먼저 ‘돈을 냈다’와 ‘권리를 가진다’를 구분하세요.
외주개발 결과물에는 소스코드뿐 아니라 화면 디자인, 문서, 데이터베이스 구조, 오픈소스 라이브러리, 상용 솔루션, 외부 API 등이 함께 사용될 수 있습니다. 따라서 하나의 문장으로 “전부 발주자 소유”라고 생각하면 실제 인수 과정에서 해석 차이가 생길 수 있습니다.
개발된 소스 파일과 저장소를 실제로 넘겨받을 수 있는가?
결과물을 복제·수정·배포·유지보수하는 데 필요한 권리가 어떻게 정해져 있는가?
오픈소스·상용 라이브러리·외부 솔루션은 어떤 라이선스를 따르는가?
다른 개발업체가 넘겨받아 수정하고 운영할 수 있는 상태인가?
2. 소스코드는 ‘준다’보다 어떻게 인계하는지가 중요합니다.
| 확인 항목 | 확인해야 할 내용 |
|---|---|
| 전체 소스 | 프론트엔드·백엔드·관리자·배치 등 실제 운영에 필요한 코드가 모두 포함되는지 |
| Git 저장소 | 최종 ZIP 파일만 받는지, Git 이력과 저장소 접근·이전까지 가능한지 |
| 빌드·배포 | 소스만으로 다른 개발자가 빌드하고 운영환경에 배포할 수 있는지 |
| 설정 정보 | 환경변수, 외부서비스 연결정보 등 운영에 필요한 설정을 안전하게 인계하는지 |
| 문서 | 설치·배포·DB·API 등 후속 유지보수에 필요한 설명이 제공되는지 |
3. 개발업체가 만든 코드가 아닌 부분도 있습니다.
실제 서비스는 처음부터 모든 코드를 새로 작성하지 않습니다. 오픈소스 라이브러리, 프레임워크, 상용 컴포넌트, 클라우드 서비스 등을 사용할 수 있습니다. 이런 구성요소는 각각의 라이선스와 이용조건이 적용될 수 있습니다.
이번 프로젝트를 위해 새로 작성된 부분
각 오픈소스 라이선스 조건 확인
구매·구독·사용권 이전 가능성 확인
API·클라우드 등 계정과 계약관계 확인
따라서 계약서에는 결과물의 권리만 적기보다 제3자 라이선스나 기존 보유 기술이 포함될 경우 어떻게 처리하는지도 확인하는 것이 좋습니다.
4. 계약 단계에서 최소한 이 항목은 구분해서 확인하세요.
| 계약 항목 | 확인 질문 |
|---|---|
| 결과물 범위 | 소스코드 외에 디자인 원본·DB·문서 등 무엇을 납품하나요? |
| 권리 귀속 | 이번 프로젝트에서 새로 제작된 결과물의 권리는 어떻게 정하나요? |
| 이용·수정 | 발주자가 직접 또는 제3자를 통해 수정·유지보수할 수 있나요? |
| 기존 기술 | 개발업체가 기존부터 보유한 공통 모듈이 포함된다면 이용조건은 무엇인가요? |
| 제3자 라이선스 | 오픈소스·상용 솔루션 사용 여부와 적용 조건을 확인할 수 있나요? |
| 인계 시점 | 소스와 계정은 최종대금 지급 후에만 받는지, 개발 중에도 저장소 접근이 가능한가요? |
5. 계약서에 권리가 있어도 실제 인수가 안 되면 운영이 어렵습니다.
계약 문구만큼 중요한 것이 실제 인수 상태입니다. 최종적으로 다른 개발자가 기존 업체의 도움 없이 프로젝트를 실행·분석·배포할 수 있어야 업체 변경이나 자체 유지보수가 가능합니다.
6. 계약 전에 확인할 체크리스트
개발비를 지급하는 것과 소스코드·권리를 확보하는 것은 별도로 확인하세요.
계약할 때 무엇을 받는지, 어떤 권리를 가지는지, 다른 개발자가 이어서 수정할 수 있는지까지 정해두어야 개발 완료 후의 분쟁과 운영 리스크를 줄일 수 있습니다.