개발 외주 계약서의 소스코드 인도 조항에는 무엇을 적어야 합니까?

「산출물 일체」 한 줄이 부족한 이유

개발 외주 계약서의 인도 조항은 「개발 산출물 일체를 인도한다」 한 줄로 끝나는 경우가 많습니다. 문제는 「일체」의 범위를 두 당사자가 다르게 읽는다는 점입니다. 개발사는 최종 소스 파일 묶음을 떠올리고, 발주사는 시스템을 다시 세우는 데 필요한 모든 것을 떠올립니다. 그 차이는 프로젝트가 순조로울 때는 드러나지 않다가 유지보수 업체를 바꾸거나 개발사와 연락이 끊긴 시점에 한꺼번에 드러납니다.

인도 조항은 다섯 요소로 나눠 적으면 해석의 여지가 크게 줄어듭니다.

1. 목록무엇을 받는지 항목별로 적습니다
2. 형식어떤 형태로, 어디로 받는지 정합니다
3. 시점단계마다 받는지, 완료 후 한 번에 받는지 정합니다
4. 검증받은 자료로 다시 세울 수 있는지 확인하는 방법을 정합니다
5. 권리양도인지 이용 허락인지, 범위가 어디까지인지 적습니다

과학기술정보통신부가 2020년 말부터 배포하고 있는 SW 분야 표준계약서 6종(정보시스템 개발구축 사업 표준계약서 등)을 초안 옆에 놓고 대조하면, 빠진 조항을 찾는 데 도움이 됩니다.

인도 목록 — 다시 세울 수 있는 단위로 적습니다

목록의 기준은 하나입니다. 다른 개발팀이 인도받은 자료만으로 같은 시스템을 다시 빌드하고 배포할 수 있는가입니다. 소스 파일만으로는 이 기준을 채우지 못합니다.

비밀번호나 API 키 같은 비밀값은 문서나 저장소에 값으로 적지 않습니다. 목록에는 항목 이름만 두고, 값은 비밀값 관리 서비스나 별도 전달 경로로 받는다고 적어 두는 편이 안전합니다.

목록은 계약서 본문보다 별첨으로 두는 편이 관리하기 쉽습니다. 개발 도중 외부 서비스가 추가되거나 구조가 바뀌면 별첨만 갱신하면 되고, 인수 단계에서는 그 별첨을 점검표로 그대로 쓸 수 있습니다. 제안 단계에서 개발사가 이 목록을 구체적으로 채워 오는지도 업체를 비교하는 단서가 됩니다.

형식과 시점 — 끝나고 받기보다 처음부터 갖고 있기

코드 저장소와 클라우드 계정을 발주사 명의로 만들고 개발사에 권한을 부여하는 방식은 인도를 둘러싼 다툼의 여지를 구조적으로 줄입니다. 계약이 끝나면 권한만 회수하면 되기 때문입니다. 이 방식이 어렵다면 최소한 「중간 검수마다 그 시점의 저장소 사본을 인도한다」는 문장을 넣어 두십시오.

권리 조항 — 양도인지, 이용 허락인지

소스를 받는 것과 그 소스를 고쳐 써도 되는 권리는 별개입니다. 저작권법 제45조 제2항은 저작재산권 전부를 양도할 때 특약이 없으면 2차적저작물작성권(원래 프로그램을 고쳐 새로 만들어 이용할 권리)은 포함되지 않은 것으로 추정하되, 프로그램은 예외로 특약이 없으면 그 권리도 함께 양도된 것으로 추정합니다. 다만 이것은 전부 양도의 경우에 대한 추정일 뿐이므로, 계약서에 다음을 분명히 적어 두는 편이 안전합니다.

• 저작재산권을 전부 양도하는지, 이용 허락만 하는지
• 양도라면 2차적저작물작성권까지 포함하는지
• 개발사가 이전부터 갖고 있던 공통 모듈과 오픈소스처럼 양도 대상이 아닌 부분의 목록, 그리고 그 부분의 이용 허락 범위(기간, 수정 가능 여부, 다른 업체의 유지보수 허용 여부)

마지막 항목은 빠지기 쉽습니다. 개발사의 공통 모듈은 다른 고객 프로젝트에도 쓰이므로 양도받기 어렵고, 오픈소스는 개발사에게 애초에 양도할 권리가 없습니다. 이 부분을 이용 허락으로 정리해 두지 않으면 다른 업체에 유지보수를 맡길 때 권리 범위가 불분명해집니다.

개발사의 담당 개발자가 퇴사하더라도 권리를 그 개인에게서 따로 받을 필요는 대개 없습니다. 저작권법 제9조는 법인 등의 기획하에 그 업무에 종사하는 사람이 업무상 작성한 저작물(업무상저작물)이 법인 등의 명의로 공표되면 계약이나 근무규칙에 다른 정함이 없는 한 그 법인 등을 저작자로 보고, 프로그램은 공표되지 않아도 같다고 정하기 때문입니다. 그래서 권리 조항의 상대방은 원칙적으로 개발사라는 법인입니다. 다만 개발사가 일부를 프리랜서나 하청 업체에 맡겼다면, 그 부분의 권리가 개발사에 정리돼 있는지를 함께 확인해야 합니다.

금액이 크거나 권리 관계가 복잡하다면 이 항목들을 추린 뒤 법률 자문을 받으시는 편이 효율적입니다.

인도를 「검증」하는 방법

목록이 있어도 실제로 다시 세울 수 있는지는 해 봐야 압니다. 인수 조건에 확인 절차를 넣어 두십시오.

시연은 개발사가 아닌 사람의 손으로, 개발사 계정이 아닌 환경에서 하는 것이 핵심입니다. 이 과정에서 문서에 없던 설정값이나 담당자 개인 PC에만 있던 스크립트가 드러납니다. 시연에서 막힌 항목은 하자가 아니라 인도 미완료로 다룬다고 정해 두면, 잔금 지급과 인도 완료의 순서가 뒤바뀌지 않습니다.

개발사가 소스 공개를 꺼릴 때 — 프로그램 임치

패키지 솔루션처럼 개발사가 소스를 넘기기 어려운 경우에는 프로그램 임치를 검토할 수 있습니다. 저작권법 제101조의7은 저작재산권자와 이용 허락을 받은 자가 합의해 원시코드와 기술정보를 대통령령으로 정하는 수치인에게 맡길 수 있게 하고, 합의에서 정한 사유가 생기면 이용 허락을 받은 자가 그 제공을 요구할 수 있도록 정하고 있습니다. 임치를 택한다면 어떤 사유가 생기면 받는지(예: 폐업, 유지보수 중단)와 임치물을 얼마나 자주 최신본으로 바꾸는지를 함께 적어야 실효가 있습니다.

빌드업웍스는 만든 코드와 데이터를 고객 소유로 두며, 기존 시스템을 이어받을 수 있는지 확인할 때도 같은 항목을 순서대로 대조합니다.

참고 자료

• 저작권법 제45조(저작재산권의 양도) — 국가법령정보센터
• 저작권법 제9조(업무상저작물의 저작자) — 국가법령정보센터
• 저작권법 제101조의7(프로그램의 임치) — 국가법령정보센터
• 과학기술정보통신부 — 소프트웨어(SW)분야 표준계약서(6종) 활용 안내