“2라운드 들어가면 MVP를 외주로 만들 건데, 결과물은 당연히 제 것 아닌가요?” 모두의 창업 일반·기술 트랙은 2라운드에서 시제품(MVP) 제작비를 최대 2,000만 원 안에서 차등 지원해요(통합 모집공고 2차). 직접 개발하기 어려운 팀이라면 외주 개발사를 찾게 되는데, 이때 권리 문제를 계약서에 담지 않으면 나중에 곤란해질 수 있어요. 개발을 맡기는 순간에는 일정과 금액에 신경이 쏠려서, 권리 이야기는 뒤로 밀리기 쉬워요.
이 글에서는 외주 결과물의 특허와 저작권이 원칙적으로 누구에게 생기는지, 개발사가 발명에 기여하면 어떻게 되는지, 계약서에 무엇을 넣어야 하는지, 아이디어를 보여주기 전에 무엇부터 할지를 차례로 짚어볼게요.
돈을 냈다고 권리가 자동으로 오지는 않아요
특허를 받을 권리는 발명을 한 사람에게 생겨요(특허법 제33조). 비용을 댄 사람이 아니라 실제로 기술적인 해결 방법을 만든 사람이 기준이에요. 코드도 비슷해요. 외주로 만든 프로그램의 저작권은 원칙적으로 실제로 창작한 개발자 쪽에 생기고, 주문자에게 넘어오려면 계약으로 정해야 한다는 게 일반적인 해석이에요(도급계약과 저작권 귀속 해설).
정리하면, 외주 계약서에 권리 조항이 없으면 “돈은 내가 냈는데 코드 저작권과 발명의 권리는 개발사 쪽에 남는” 상황이 생길 수 있어요. 특히 투자 실사에서 핵심 기술의 권리가 회사에 있는지 확인할 때 이 부분이 걸리기 쉬워요.
그렇다고 다툼을 걱정해 외주를 피할 필요는 없어요. 대부분은 계약서에 몇 줄을 더하는 것만으로 미리 정리할 수 있는 문제예요. 다만 “나중에 알아서 정리하자”고 미뤄 두면, 막상 투자나 매각처럼 권리를 증명해야 할 때 개발사의 협조가 필요해지고 그때는 조건이 달라질 수 있어요.
개발사가 구조를 새로 만들었다면 공동 발명이 될 수 있어요
보통은 대표님이 아이디어와 핵심 구조를 정하고, 개발사는 그걸 구현해요. 이 경우 발명자는 구조를 만든 쪽이에요. 그런데 개발 과정에서 개발사가 원래 없던 해결 방법을 새로 제안하고, 그게 제품의 핵심이 되는 경우도 있어요. 그러면 그 부분은 개발사 쪽 사람이 공동 발명자가 될 수 있고, 특허를 받을 권리를 공유하게 될 수 있어요(특허법 제33조).
공유가 되면 출원도 함께 해야 하고(특허법 제44조), 나중에 지분을 정리하거나 다른 곳에 라이선스할 때 서로의 동의가 필요해요(특허법 제99조). 외주 관계가 끝난 뒤에도 이런 제약이 남으면 사업에 두고두고 부담이 돼요. 그래서 개발사가 새로 더한 부분이 있다면, 그 기여를 인정하고 대가를 정한 뒤 권리를 넘겨받는 방식으로 정리하는 경우가 많아요. 기여를 부정하기보다 인정하고 계약으로 정리하는 편이 나중에 다툼이 적어요. 권리를 공유할 때 생기는 제약은 동업자와 함께 모두의 창업에 도전했다면, 특허는 누구 이름으로 내나요?에서 더 자세히 다뤘어요.
계약서에 꼭 넣어야 할 권리 조항
외주 계약서에는 보통 금액, 일정, 검수 조건이 들어가요. 여기에 아래 내용이 빠지지 않았는지 확인해 보세요.
- 결과물 저작권 귀속: 소스코드·디자인 등 결과물의 저작재산권을 주문자에게 넘긴다는 조항. 저작재산권은 계약으로 넘길 수 있어요(저작권법 제45조).
- 특허를 받을 권리 귀속: 개발 과정에서 나온 발명의 특허를 받을 권리를 주문자에게 넘긴다는 조항과, 출원에 협조한다는 약속
- 소스코드 인도: 실행 파일만이 아니라 소스코드와 설계 문서를 넘겨받는다는 조항
- 기존 기술과 오픈소스: 개발사가 원래 갖고 있던 모듈이나 오픈소스를 쓰는 경우 그 범위와 사용 조건
- 비밀유지: 개발하며 알게 된 아이디어를 다른 고객 일에 쓰지 않는다는 약속
저는 이 가운데 특허를 받을 권리 조항이 가장 쉽게 빠진다고 봐요. 코드 저작권은 요즘 계약서 양식에 들어 있는 경우가 많지만, 발명에 대한 권리는 따로 적지 않으면 비어 있기 쉬워요.
검수 때 넘겨받을 산출물 목록도 계약서에 적어 두면 좋아요. 소스코드 저장소 접근 권한, 빌드와 배포 방법 문서, 사용한 외부 서비스 계정 목록, 설계 문서가 대표적이에요. 이게 없으면 나중에 다른 개발사로 바꾸거나 내부 개발자를 뽑았을 때 처음부터 다시 파악해야 해요.
오픈소스는 한 번 더 볼 필요가 있어요. 라이선스에 따라서는 그 코드를 쓴 결과물의 소스코드까지 공개해야 하는 조건이 붙기도 해서, 나중에 서비스를 키우거나 투자 실사를 받을 때 문제가 될 수 있어요. 개발사에게 사용한 오픈소스와 라이선스 목록을 받아 두고, 핵심 기능에 공개 의무가 있는 라이선스가 쓰였는지 확인해 보세요.
로고·화면 디자인도 같은 원리예요
MVP를 만들면서 로고나 앱 화면 디자인까지 외주로 맡기는 경우가 많아요. 이때도 원칙은 비슷해요. 디자인등록을 받을 수 있는 권리는 디자인을 창작한 사람에게 생기고(디자인보호법 제3조), 로고 그림의 저작권도 원칙적으로 그린 사람 쪽에 생겨요.
로고는 특히 조심할 부분이 있어요. 상표는 사업을 하는 쪽이 출원하지만, 로고 그림의 저작권이 디자이너에게 남아 있으면 나중에 그 로고를 쓰는 데 걸림돌이 될 수 있어요. 상표법도 등록상표가 출원 전에 생긴 다른 사람의 저작권과 부딪히면, 그 저작권자의 동의 없이는 그렇게 사용할 수 없다고 정하고 있어요(상표법 제92조). 그래서 로고 외주 계약서에는 저작재산권 양도와 함께, 상표 출원과 사용에 이의를 제기하지 않는다는 문구를 넣어 두는 게 좋아요.
- 로고: 저작재산권 양도와 상표 출원·사용 동의
- 제품 외형·화면 디자인: 디자인등록을 받을 권리 양도
- 원본 파일: 수정할 수 있는 원본 파일 인도
브랜드 이름을 정했다면 같은 이름이 이미 있는지도 먼저 확인해 두세요. 방법은 키프리스로 내 브랜드, 출원 전에 먼저 검색해보기에 정리해 두었어요. 화면 디자인도 요건을 갖추면 디자인등록으로 보호받을 수 있어서, 핵심 화면이 사업의 차별점이라면 함께 검토해 볼 만해요.
아이디어를 보여주기 전에 순서를 정해요
외주 개발사를 고르는 과정에서 여러 곳에 견적을 받게 되는데, 이때 아이디어를 어디까지 설명할지가 문제예요. 비밀유지 약속 없이 여러 사람에게 구조를 자세히 설명하면 공개로 볼 여지가 생기고, 아이디어가 새어 나갈 위험도 커져요.
- 견적 단계에서는 기능과 화면 위주로 설명하고, 핵심 구조는 계약 뒤에 공유해요. 견적에 필요한 건 대개 기능 목록, 화면 수, 연동할 서비스 정도예요.
- 구조를 설명해야 한다면 비밀유지 약속(NDA)을 먼저 받아요.
- 핵심 구조가 정해졌다면 개발을 맡기기 전에 출원이나 임시 명세서로 날짜부터 잡는 걸 검토해요.
여러 개발사에 같은 설명 자료를 돌리게 되는데, 그 자료가 어디까지 퍼질지는 통제하기 어려워요. 자료 첫 장에 비밀유지 안내를 적고, 보낸 곳과 날짜를 기록해 두면 나중에 문제가 생겼을 때 확인하기 쉬워요.
날짜를 먼저 잡아 두면, 개발 중에 개발사가 무엇을 새로 더했는지 구분하기도 쉬워져요. 처음 출원한 내용이 “우리가 원래 가진 것”의 기준선이 되거든요. 임시 명세서 활용법은 모두의 창업 발표 전에, 임시 명세서로 출원일부터 잡을 수 있나요?에 정리해 두었어요.
이미 계약했다면 지금 확인할 것
이미 외주 계약을 맺었다면 계약서를 다시 펼쳐 권리 조항부터 보세요. 조항이 없거나 모호하다면 개발이 끝나기 전에 보완 합의를 하는 편이 쉬워요. 개발이 끝나고 잔금까지 치른 뒤에는 협상할 여지가 줄어들기 때문이에요. 투자나 지원사업 서류에 권리 관계를 적어야 한다는 이유를 설명하면, 보완 합의 이야기도 자연스럽게 꺼낼 수 있어요.
개발사로부터 특허를 받을 권리를 넘겨받아 출원하는 경우라면, 출원 전에 받은 권리는 출원을 해야 제3자에게 주장할 수 있다는 점도 기억해 두세요(특허법 제38조). 권리를 넘겨받기로 합의했다면 출원을 미루지 않는 게 좋아요.
개발 과정의 기록도 챙겨 두세요. 회의록, 요구사항 문서, 개발사와 주고받은 메시지는 나중에 “이 구조를 누가 먼저 제안했는지”를 가릴 때 근거가 돼요. 누가 무엇을 새로 더했는지 분명하면 권리 정리도 훨씬 수월해져요. 기록은 따로 시간을 내기보다, 주간 회의 끝에 결정 사항을 한 줄씩 남기는 습관으로도 충분해요.
공식 근거: 본문에 링크한 국가법령정보센터 특허법·저작권법 조문과 모두의 창업 통합 모집공고 2차. 2026년 9월 25일에 확인했어요.
※ 이 글은 일반 안내예요. 권리 귀속은 계약 내용과 사안에 따라 달라지고, 특허 등록을 보장하지 않아요. 계약서 문구는 변호사, 발명·출원 구조는 변리사 검토 뒤 결정하세요.
