외주 개발이 끝났는데 개발자가 실행 파일이나 완성된 사이트만 주고 소스코드, 서버 계정, 저장소 접근 권한을 넘기지 않는 경우가 있습니다. 이때 가장 먼저 구분할 것은 소스코드가 계약상 납품물인지, 그리고 저작권이나 운영 권한까지 이전하기로 했는지입니다. 개발비를 모두 지급했다는 사실만으로 모든 자료와 권리가 자동으로 넘어오는 것은 아닙니다.
핵심 정리소스코드 파일의 인도, 저작재산권의 이전, 서버·도메인 계정의 관리 권한은 서로 다른 문제입니다. 계약서와 실제 협의 내용을 기준으로 각각 확인해야 합니다.
계약에서 소스코드가 납품물인지 확인합니다
계약서에 ‘소프트웨어 일체’, ‘개발 결과물’처럼 넓은 표현만 있다면 그 문구 하나로 소스코드 포함 여부를 단정하기 어렵습니다. 견적서, 과업지시서, 요구사항 문서, 메신저 원문, 이메일에서 소스코드·원본 파일·기술문서의 제공을 어떻게 설명했는지 함께 살펴봐야 합니다.
유지보수를 발주자가 직접 하거나 다른 업체에 맡기기로 한 사정, 개발 중 공유 저장소를 사용한 경위, 납품 목록에 빌드 방법이나 데이터베이스 구조가 포함된 사정도 해석 자료가 될 수 있습니다. 반대로 개발자가 계속 유지보수를 맡기로 했고 계약 대상이 운영 서비스 제공에 가까웠다면 판단이 달라질 수 있습니다.
- 납품물
- 소스코드, 실행 파일, 디자인 원본, 데이터베이스 구조, 설치·빌드 문서 등 실제로 건네야 하는 자료를 말합니다.
- 저작재산권
- 프로그램을 복제·수정·배포하는 등 법이 정한 방식으로 이용할 권리입니다. 계약에 따른 이전 또는 이용허락 범위를 따로 확인해야 합니다.
- 운영 권한
- 도메인, 클라우드 서버, 앱 마켓, 코드 저장소, 배포 도구 등에 접속하고 관리하는 권한입니다.
소스코드를 받는 것과 저작권을 넘겨받는 것은 다릅니다
소스코드 사본을 받았다고 해서 저작재산권까지 당연히 이전되는 것은 아닙니다. 반대로 저작재산권 이전 약정이 있더라도 어떤 형식과 시점에 소스코드를 인도할지는 계약 내용을 더 확인해야 할 수 있습니다. 계약에 ‘소유권’, ‘사용권’, ‘저작권 귀속’이 섞여 있다면 각 표현이 무엇을 뜻하는지 전체 문맥으로 해석해야 합니다.
개발자가 기존에 보유하던 공통 모듈이나 제3자의 오픈소스·유료 구성요소는 발주자에게 전부 이전할 수 없는 경우도 있습니다. 사용된 외부 프로그램의 이름, 라이선스 조건, 유료 계정의 계약 주체도 함께 정리해야 향후 수정이나 재배포 과정의 위험을 줄일 수 있습니다.
잔금과 검수 조건도 함께 살펴봐야 합니다
계약에서 소스코드 인도와 검수 완료를 잔금 지급 조건으로 정했다면, 약속된 자료가 빠진 상태인지가 중요합니다. 반면 지급일이 이미 지났거나 핵심 기능을 정상적으로 사용하고 있다면 잔금 전부를 계속 지급하지 않는 데 위험이 생길 수 있습니다. 일부 미완성이나 하자의 정도와 미지급 금액이 지나치게 차이 나는지도 문제될 수 있습니다.
검수 완료 확인서를 작성했더라도 소스코드 인도청구가 언제나 사라지는 것은 아닙니다. 다만 검수 당시 무엇을 받았고 어떤 문제를 유보했는지가 중요한 증거가 됩니다. 결과물을 받은 날짜, 검수 요청을 받은 날짜, 수정 요구를 보낸 날짜와 내용을 시간순으로 남겨두는 것이 좋습니다.
상대방의 미이행이 계약 목적을 달성하기 어려울 정도인지, 보완 기회를 주었는지, 발주자 측 대금도 지급기일이 되었는지에 따라 결론이 달라집니다. 계약의 동시이행 조항과 해제 절차를 먼저 확인해야 합니다.
운영 계정은 파일 인도와 별도로 정리합니다
서비스 운영에는 소스코드 외에도 도메인 등록 계정, 클라우드 관리자 권한, 앱 마켓 계정, 코드 저장소, 데이터베이스 백업, 인증서와 배포 설정이 필요할 수 있습니다. 개발자 개인이나 개발업체 명의 계정을 그대로 양도하는 방식은 서비스 약관이나 보안 정책에 맞지 않을 수 있으므로, 발주자 명의의 새 계정을 만들고 관리자 권한을 초대하거나 데이터를 이전하는 방식도 검토할 수 있습니다.
비밀번호나 인증키를 메신저에 그대로 보내도록 요구하기보다 권한 변경 기록과 인계 목록을 남기는 편이 안전합니다. 이용자 개인정보가 저장되어 있다면 백업본의 전달 방법, 개발자 측 사본의 보관·삭제 범위, 접근 권한 종료 시점도 확인해야 합니다.
요구하기 전에 자료를 이렇게 정리합니다
- 계약 문서를 한곳에 모읍니다
개발계약서, 견적서, 요구사항 문서, 납품 목록과 변경 합의 내용을 서로 대조합니다.
- 이미 받은 자료를 확인합니다
압축 파일뿐 아니라 코드 저장소의 커밋 기록, 서버 관리자 화면, 앱 마켓 권한과 데이터베이스 백업 여부를 확인합니다.
- 미인도 항목을 구체적으로 적습니다
‘자료 일체’라고만 하지 말고 소스코드 버전, 빌드 문서, 관리자 권한 등 필요한 항목과 요청 기한을 나누어 전달합니다.
- 손해 자료를 별도로 보관합니다
서비스 중단 비용, 다른 개발업체의 복구 견적, 추가 서버 비용과 입출금 내역을 보관하되 계약 위반과의 관련성을 구분합니다.
계약 불이행이 확인되면 자료 인도나 보완 이행을 요구하고, 실제로 발생한 추가 비용에 대해 손해배상 가능성을 검토할 수 있습니다. 계약 목적을 이루기 어려운 중대한 미이행이라면 해제 문제도 생길 수 있지만, 상당한 이행 기회를 주어야 하는지와 예외가 있는지는 계약 내용과 경위에 따라 달라집니다.
계약서의 검수·하자 통지 기간은 결과물을 받거나 검수 가능 통지를 받은 때 등 약정한 기준에서 시작할 수 있습니다. 법정 권리행사 기간은 해당 청구권을 행사할 수 있게 된 시점과 계약 유형에 따라 달라지며, 단순한 협의나 메신저 요청만으로 기간 문제가 모두 해결되는 것도 아닙니다. 따라서 최초 납품일, 검수 통지일, 최종 대금 지급일과 인도 거절일을 정확히 정리해 두는 것이 중요합니다.