바로 답변
계약서에 양도 조항이 없으면 발주사의 것이 되지 않습니다. 저작권은 창작한 때 발생하고 별도 절차가 필요 없으며(저작권법 제10조제2항), 업무상저작물 규정은 법인등의 업무에 종사하는 자를 전제로 하므로 외부 개발사가 도급으로 만든 산출물에 그대로 적용된다고 보기 어렵습니다. 그래서 저작재산권 양도 조항이 필요하고, 프로그램은 전부 양도 시 2차적저작물작성권까지 양도된 것으로 추정되지만 화면 디자인이나 문서 같은 비프로그램 산출물은 반대로 추정되므로 따로 적어야 합니다. 계약 전에 양도 범위, 인도 목록, 제3자 구성요소 세 가지를 문서로 확정해 두시기 바랍니다.
핵심 요약
- 저작권은 창작한 때 발생하므로 대금 지급 사실만으로 저작재산권이 이전되지는 않습니다(제10조제2항).
- 업무상저작물 규정은 법인등의 업무에 종사하는 자를 전제로 하므로(제2조제31호, 제9조), 외주 계약에는 양도 또는 이용허락 조항이 따로 필요합니다.
- 프로그램은 전부 양도 시 2차적저작물작성권도 양도된 것으로 추정되지만, 디자인·기획 문서 등은 포함되지 않은 것으로 추정됩니다(제45조제2항).
- 저작인격권은 저작자 일신에 전속하므로 양도 대상이 아니며(제14조제1항), 불행사 합의로 정리하는 것이 일반적입니다.
- 개발사 폐업 등에 대비하려면 원시코드와 기술정보를 한국저작권위원회에 임치하는 방법이 있습니다(제101조의7, 시행령 제39조의2).

대금을 다 내면 소스코드는 우리 것이 되나요?
계약서에 적지 않으면 그렇지 않습니다. 저작권은 저작물을 창작한 때부터 발생하고 어떠한 절차나 형식도 필요하지 않습니다(저작권법 제10조제2항). 대금 지급은 저작재산권을 옮기는 행위가 아니라 계약상 의무를 이행한 것이어서, 권리 이전은 별도의 양도 조항으로 정해야 합니다.
회사 직원이 만든 결과물과 같다고 생각하기 쉽지만 근거 조문이 다릅니다. 저작권법 제9조는 법인등의 명의로 공표되는 업무상저작물의 저작자를 그 법인등으로 보는데, 업무상저작물은 법인등의 기획하에 법인등의 업무에 종사하는 자가 업무상 작성한 저작물을 말합니다(제2조제31호). 외부 개발사에 도급을 준 경우에는 이 요건을 그대로 충족한다고 보기 어렵기 때문에, 발주사가 권리를 갖는 근거는 계약서가 됩니다.
계약서에서 무엇을 확인해야 하나요?
아래 네 항목은 문구 한 줄 차이로 나중에 기능을 추가할 수 있는지, 다른 개발사에 넘길 수 있는지가 갈립니다.
| 확인할 조항 | 이런 문구면 생기는 일 | 요청할 문안의 방향 |
|---|---|---|
| 저작재산권 귀속 | "산출물의 저작권은 을에게 있고 갑은 사용권을 갖는다" — 기능 추가나 업체 교체 때마다 동의가 필요합니다 | 대금 완납 시 산출물의 저작재산권 전부를 발주사에 양도한다는 취지로 명시 |
| 2차적저작물작성권 | "저작재산권을 양도한다"만 있으면 프로그램이 아닌 산출물은 개작 권리가 빠진 것으로 추정됩니다 | 2차적저작물작성권을 포함한다는 문구를 양도 조항에 함께 기재 |
| 저작인격권 | 크레딧 표기나 변경을 두고 다툼이 생길 수 있습니다 | 저작인격권을 행사하지 않는다는 합의를 별도 항으로 기재 |
| 제3자 구성요소 | 오픈소스와 상용 SDK는 양도 대상이 아닌데 목록이 없으면 출시 직전에 발견됩니다 | 사용한 오픈소스 라이선스 목록과 상용 라이선스의 계약 명의를 산출물에 포함 |
두 번째 행이 특히 자주 놓치는 지점입니다. 저작권법 제45조제2항은 저작재산권 전부를 양도해도 특약이 없으면 2차적저작물작성권은 포함되지 않은 것으로 추정하되, 프로그램의 경우에는 특약이 없으면 함께 양도된 것으로 추정한다고 정합니다. 소스코드는 프로그램이어서 비교적 안전하지만, 화면 디자인과 기획 문서, 일러스트와 촬영물은 프로그램이 아니므로 반대 추정이 적용됩니다. 디자인을 손봐서 다음 버전을 만들 계획이라면 조항에 한 줄을 더해야 합니다.
네 번째 행은 출시 직전에 문제를 만듭니다. 오픈소스는 라이선스에 따라 고지 의무나 소스 공개 의무가 붙을 수 있고, 상용 SDK가 개발사 계정으로 구매돼 있으면 계약이 끝난 뒤 사용 권한이 끊깁니다. 산출물 목록에 라이선스 목록을 포함시키고, 상용 라이선스는 발주사 명의로 구매하거나 이전이 가능한지 착수 전에 확인하시기 바랍니다.
'납품'과 '인도'는 같은 말이 아닙니다
앱이 스토어에 올라가고 웹이 열렸다고 해서 넘겨받아야 할 것을 다 받은 상태는 아닙니다. 검수 기준에 인도 목록을 적어 두시기 바랍니다.
- 원시코드 전체와 형상관리 저장소 이전(계정 이관 또는 소유자 변경)
- 빌드와 배포 절차 문서, 빌드 스크립트, 환경변수 목록
- 데이터베이스 스키마와 초기 데이터, 마이그레이션 이력
- 외부 서비스 연동 키의 발급 주체와 재발급 방법
- 오픈소스 라이선스 목록과 고지 문구 반영 위치
계정 명의도 인도 목록과 함께 정리해야 합니다. 클라우드, 도메인, 앱 마켓 개발자 계정이 개발사 명의로 되어 있으면 권리를 양도받아도 서비스를 이어받지 못합니다. 착수 전에 발주사 명의로 계정을 만들고 개발사를 구성원으로 초대하는 방식이 가장 단순합니다.
인도는 마지막에 한 번에 받기보다 중간에 나눠 확인하는 편이 안전합니다. 첫 배포 시점에 형상관리 저장소 접근 권한을 받아 커밋이 실제로 쌓이는지 확인해 두면, 검수 때 압축 파일 하나만 도착하거나 이력이 통째로 비어 있는 상황을 피할 수 있습니다.
개발사가 문을 닫으면 어떻게 하나요?
원시코드와 기술정보를 제3자에게 맡겨 두는 임치 제도가 있습니다. 저작권법 제101조의7은 프로그램의 저작재산권자와 이용허락을 받은 자가 합의해 원시코드와 기술정보를 수치인에게 임치할 수 있고, 합의에서 정한 사유가 발생하면 제공을 요구할 수 있다고 정합니다. 시행령 제39조의2는 이 수치인을 한국저작권위원회로 정하고 있습니다.
모든 프로젝트에 필요한 장치는 아닙니다. 소스코드를 직접 넘겨받고 저장소를 우리 계정으로 옮겨 두었다면 임치의 실익은 크지 않습니다. 유지보수만 맡기고 코드는 개발사가 보유하는 구조이거나, 발주사에 코드를 관리할 인력이 없을 때 검토할 선택지입니다.
계약 전에 정리해 보낼 한 가지
위 표의 네 항목을 계약서 초안에서 찾아 표시하고, 해당 문구가 없으면 없다고 적어 개발사에 회신해 보시기 바랍니다. 이 단계에서 정리하면 조항을 고치는 일이지만, 출시 후에 꺼내면 추가 협상이 됩니다. MVP 범위를 줄이는 기준이 함께 필요하다면 기능 목록과 계약서 초안을 같이 보내 주시면 검토해 드립니다.
주의할 점 — 이런 경우엔 다르게 판단하세요
이 글은 법률 자문이 아닙니다. 권리 귀속은 계약 문언과 실제 작업 형태에 따라 달라질 수 있으므로 계약 체결 전에 변호사 등 전문가의 검토를 받으시기 바랍니다. 조문은 2026년 9월 28일 국가법령정보센터에서 확인한 저작권법(시행 2026-08-11)과 저작권법 시행령을 기준으로 정리했습니다. 본문의 계약 문구는 확인 지점을 설명하기 위한 편집 예시이며 특정 계약서의 표준 문안이 아닙니다. 하도급거래에 해당하는 경우에는 하도급거래 공정화에 관한 법률과 표준하도급계약서가 별도로 적용될 수 있습니다. 이 글에서는 다루지 않았습니다.
출처와 작성 정보
참고 자료
- 국가법령정보센터 — 저작권법 (시행 2026-08-11) ↗ (기준일 2026-09-28)
- 국가법령정보센터 — 저작권법 시행령 (제39조의2 프로그램의 임치) ↗ (기준일 2026-09-28)
함께 보면 좋은 콘텐츠
- 가이드MVP 개발 비용과 기간은 어떻게 결정될까? 기능 범위를 줄이는 7가지 기준 →MVP 개발 비용은 화면 수보다 검증할 가설, 사용자 유형, 외부 연동, 관리자 기능, 데이터·보안 요건에 더 크게 좌우됩니다. 개발을 시작하기 전에 반드시 포함할 기능과 출시 이후로 미룰 기능을 구분하는 방법을 정리했습니다.
- 가이드투자 IR과 정부 실증사업에 낼 MVP는 어디까지 만들어야 하나요? →같은 MVP라도 투자 심사와 정부 실증과제가 확인하려는 지점은 다릅니다. 제출처별로 무엇을 만들고 무엇을 미뤄도 되는지 판단 기준과 역산 일정을 정리했습니다.