아닙니다. 외주 개발비를 모두 지급하고 프로그램과 소스코드를 납품받았다는 사실만으로 저작재산권까지 자동으로 넘어왔다고 단정할 수는 없습니다. 외주 개발자는 보통 발주자의 업무에 종사하는 직원과 같은 지위가 아니므로, 업무상저작물이라는 이유만으로 발주자가 곧바로 저작자가 되는 것도 아닙니다. 계약에서 어떤 프로그램의 어떤 권리를 넘기는지 분명히 정해야 합니다.
계약서에 ‘모든 산출물은 발주자 소유’라고 적혀 있어도 안심하기는 이릅니다. 파일이나 저장매체의 소유, 소스코드의 인도, 저작재산권의 양도는 서로 다른 문제입니다. 수정·재판매·후속 개발까지 계획한다면 대상 프로그램, 양도 또는 이용허락의 범위, 기존 모듈과 외부 구성요소를 나누어 확인해야 합니다.
대금 지급은 계약 이행의 중요한 사실이지만, 그 자체가 저작재산권 양도 조항을 대신하지는 않습니다. 먼저 ‘무엇을 받았는가’와 ‘어떤 권리를 받았는가’를 따로 적어보는 것이 출발점입니다.
‘돈을 냈다’와 ‘권리를 샀다’는 같은 문장이 아닙니다
저작권법은 저작권이 저작물을 창작한 때부터 발생한다고 정합니다. 또 업무상저작물은 법인이나 단체 등의 기획 아래 그 업무에 종사하는 사람이 업무상 작성한 저작물을 전제로 합니다. 프로그램은 법인 등의 명의로 공표될 필요가 없다는 예외가 있지만, 그렇다고 외부 개발업체가 자동으로 발주자의 종업원이 되는 것은 아닙니다.
따라서 외주 계약에서는 발주자가 아이디어와 요구사항을 제시하고 개발비를 부담했다는 사정만으로 결론을 내리기 어렵습니다. 실제 계약 문구, 누가 창작했는지, 개발자가 발주자의 업무에 종사하는 관계였는지, 개발 과정의 지휘 방식이 어떠했는지를 함께 살펴야 합니다.
‘산출물은 발주자 소유’에서 빠지기 쉬운 세 가지
1. 소유와 저작재산권 양도
납품된 서버, 저장장치 또는 파일을 보유하는 것과 프로그램의 저작재산권을 가지는 것은 구분됩니다. ‘산출물 소유’라는 표현만 있으면 소스코드와 문서의 인도를 뜻하는지, 복제·배포·공중송신·수정에 관한 권리까지 넘긴다는 뜻인지 해석 다툼이 생길 수 있습니다.
발주자가 사업을 직접 운영하는 데 필요한 사용권만 원하는지, 제3자에게 판매하거나 다른 개발사에 맡겨 개작할 권리까지 필요한지부터 정해야 합니다. 저작권법상 저작재산권은 전부 또는 일부 양도할 수 있고, 이용허락을 택하면 허락된 방법과 조건의 범위에서만 이용할 수 있기 때문입니다.
2. 소스코드 인도와 수정 권한
소스코드를 받았더라도 수정·배포할 법적 권한이 별도로 정리되지 않았다면, 보유한 파일로 무엇까지 할 수 있는지가 남습니다. 반대로 저작재산권 양도 조항이 있더라도 저장소 접근권, 빌드 방법, 배포 키, 관리자 계정이 인도되지 않으면 실제 유지보수가 막힐 수 있습니다.
계약에는 저장소와 기준 버전, 전체 이력의 인도 여부, 빌드·배포 문서, 관리자 권한, 비밀정보 처리, 인수인계 완료 기준을 적는 편이 좋습니다. 권리 조항과 기술 인도 조항은 서로 대신할 수 없습니다.
3. 새로 만든 코드와 원래 있던 자산
외주사가 계약 전부터 보유한 공통 모듈, 오픈소스 소프트웨어, 유료 라이브러리, 폰트·이미지·음원 같은 제3자 자료는 이번에 새로 만든 코드와 권리 조건이 다를 수 있습니다. 완성된 프로그램의 권리를 양도받기로 했다고 해서 외부 구성요소의 이용조건까지 사라지는 것은 아닙니다.
따라서 기존 자산과 제3자 구성요소를 목록으로 분리하고, 각 항목의 라이선스, 사용 범위, 후속 개발사가 접근할 수 있는지, 교체가 필요한지를 확인해야 합니다. 외주사가 다시 맡긴 개발자나 업체가 있다면 그 참여자의 권리처리도 함께 점검해야 합니다.
프로그램의 ‘전부 양도’ 규정을 오해하지 마세요
저작권법 제45조는 저작재산권 전부를 양도하는 경우를 규정합니다. 일반 저작물은 특약이 없으면 2차적저작물작성권이 양도에 포함되지 않은 것으로 추정하지만, 프로그램은 특약이 없으면 그 권리도 함께 양도된 것으로 추정합니다.
중요한 점은 이 규정이 전부 양도가 성립한 뒤 그 범위를 정하는 규칙이라는 사실입니다. 개발비 지급이나 납품만으로 전부 양도가 있었다고 만들어주는 규정은 아닙니다. 계약서에서 양도인지 이용허락인지가 불분명하다면 이 예외만으로 수정권한까지 확보했다고 단정해서는 안 됩니다.
서명 전에는 이 표 대신 여섯 줄을 확인하세요
- 대상물 — 프로그램명, 저장소, 기준 커밋, 문서, 화면 디자인, 데이터베이스 구조 등 무엇을 계약 대상으로 삼는지 적습니다.
- 권리 방식 — 저작재산권 양도인지 이용허락인지, 전부인지 일부인지 구분합니다.
- 사업 범위 — 수정, 복제, 배포, 서비스 제공, 재판매, 제3자 유지보수와 재위탁이 허용되는지 정합니다.
- 기술 인도 — 소스코드, 전체 이력, 빌드 환경, 배포 문서, 관리자 계정과 인도 시점을 정합니다.
- 예외 목록 — 외주사의 기존 모듈과 오픈소스·유료 라이브러리 등 제3자 구성요소의 명칭과 조건을 붙입니다.
- 후속 처리 — 검수, 하자보수, 기능 추가, 계약 종료 뒤 자료 반환과 계정 이전 기준을 정합니다.
한국저작권위원회는 저작재산권 전부·일부 양도 계약서와 독점적·비독점적 이용허락 계약서를 각각 제공합니다. 표준계약서는 출발점으로 활용하되, 실제 개발 구조와 사업 방식에 맞게 대상물과 예외를 구체화해야 합니다.
이미 계약이 끝났다면 자료부터 한곳에 모으세요
- 서명한 계약서, 제안서, 견적서와 과업범위서
- 기능 변경요청, 회의록, 검수확인과 대금 지급 기록
- 소스 저장소의 전체 이력, 릴리스 파일과 배포 기록
- 서버·도메인·클라우드·앱마켓 관리자 계정의 인수인계 기록
- 기존 모듈, 오픈소스, 폰트·이미지 등 외부 구성요소와 라이선스 목록
- 참여 개발자와 재하도급 업체, 권리 양도 또는 이용허락 자료
문구가 모호하다면 저장소 이력을 지우거나 계정을 일방적으로 바꾸기 전에 현재 상태를 내보내 보존하고, 대상물과 권리 범위를 명확히 하는 보충합의를 검토할 수 있습니다. 이미 운영 중단이나 권리 주장이 시작됐다면 계약서 한 줄만 보지 말고 개발 지휘관계와 실제 인도 내역을 함께 검토받는 것이 좋습니다.
이 글은 공개된 법률정보를 바탕으로 한 일반 안내입니다. 같은 ‘외주 개발’이라도 계약 문구, 실제 업무관계, 참여자, 기존 코드와 외부 라이선스에 따라 결론이 달라질 수 있습니다.