앱 외주개발 저작재산권: 양도와 이용허락을 계약 전에 나누는 법
앱 외주 계약에서 “소스코드를 받는다”는 말만으로 이후의 수정·배포·다른 개발사 투입까지 정리되지는 않습니다. 계약 전에는 완성물의 저작재산권을 양도받을지, 정해진 범위에서 이용허락을 받을지, 그리고 누가 어떤 범위에서 고칠 수 있는지를 따로 결정해야 합니다. 납품 파일을 받는 일과 권리·이용 범위를 정하는 일은 같은 질문이 아닙니다.
공식 원문 확인일: 2026년 9월 15일 · 작성: 유인어스(UINUS)
먼저 답: ‘파일 인도’와 ‘권리·이용 범위’를 한 조항으로 뭉치지 않습니다
외주 개발사는 저장소 접근권한을 넘기고 소스코드를 압축 파일로 전달할 수 있습니다. 그러나 그 사실만으로 발주사가 앱을 수정·복제·배포하거나 다음 개발사에 맡길 수 있는 범위가 문서상 분명해지는 것은 아닙니다. 개발 결과에는 직접 작성한 코드 외에도 디자인 시안, 문서, 폰트, 이미지, 외부 라이브러리, 클라우드 설정처럼 출처와 조건이 다른 요소가 섞일 수 있기 때문입니다.
그래서 계약서에는 “모든 권리를 발주사에 준다”처럼 넓은 문장 하나를 넣기보다, 결과물을 목록으로 나누고 각 항목에 양도인지 이용허락인지 표시하는 편이 좋습니다. 저작권법 제45조는 저작재산권의 전부 또는 일부 양도를 정하고, 프로그램의 경우 특약이 없으면 2차적저작물작성권도 함께 양도된 것으로 추정한다고 규정합니다(C001). 제46조는 이용허락을 받은 사람이 허락된 이용 방법과 조건의 범위에서 이용할 수 있다고 정합니다(C002). 실제 계약 문구와 프로젝트 구조에 따라 판단이 달라질 수 있으므로, 이 글은 계약·저작권 법률자문을 대신하지 않습니다.
계약 전에 먼저 고를 두 가지: 양도와 이용허락
양도는 계약으로 정한 저작재산권을 상대방에게 이전하는 방식입니다. 서비스 운영자가 기능을 계속 고치고, 다른 개발사에게 유지보수를 맡기고, 새로운 채널이나 국가에 맞게 개편할 계획이라면 어떤 결과물과 범위를 양도 대상으로 적을지 검토하게 됩니다. 반대로 이용허락은 권리 자체를 옮기기보다, 허용한 방법·기간·지역·매체·재허락 가능 여부 안에서 쓰도록 하는 방식입니다.
둘 중 하나가 항상 유리하다고 단정할 수는 없습니다. 핵심은 사업 계획과 운영 책임에 맞게 표현을 구체화하는 것입니다. 예를 들어 MVP를 한 서비스에서만 운영할 예정이라면 이용 범위를 명확히 한 허락이 검토 대상이 될 수 있고, 투자·인수·다른 개발사 교체까지 염두에 둔 서비스라면 수정·이전·재위탁 가능 범위가 계약에 빠지지 않았는지 확인할 필요가 있습니다. ‘영구 사용 가능’이라는 표현은 기간만 말할 뿐, 수정·재허락·소스 공개 범위를 답하지 못할 수 있습니다.
계약 전에 묻는 질문 | 양도 중심으로 적을 때 확인할 것 | 이용허락 중심으로 적을 때 확인할 것 |
|---|---|---|
대상 결과물 | 화면, 코드, 문서, 디자인 중 무엇을 포함하는가 | 어떤 결과물을 어떤 서비스에 쓰는가 |
변경 | 발주사 또는 후속 개발사가 수정할 수 있는가 | 수정·개작·연동이 허용되는가 |
운영 이전 | 다른 개발사·계열사·인수자에게 넘길 수 있는가 | 재허락·양도·승계가 가능한가 |
기간과 지역 | 권리 이전의 시점과 조건이 무엇인가 | 기간, 지역, 채널, 이용 횟수 제한이 있는가 |
제외 항목 | 사전 보유 도구·범용 모듈은 무엇인가 | 제외 항목을 서비스에서 어떻게 사용할 수 있는가 |
표는 정답 서식이 아닙니다. 계약 상대방, 개발 방식, 사전 보유 자산, 납품 대가와 개별 조항에 따라 필요한 문구가 달라집니다. 다만 선택지를 표로 분리하면 회의에서 ‘소스코드 받았나요?’라는 질문을 ‘누가 어디까지 고치고 넘길 수 있나요?’로 바꿀 수 있습니다.
‘외주사가 원래 갖고 있던 것’과 ‘이번 프로젝트 결과물’을 분리합니다
개발사는 여러 프로젝트에 공통으로 쓰는 내부 프레임워크, 자동화 도구, 범용 코드 조각을 보유할 수 있습니다. 발주사가 이번 프로젝트를 위해 만든 화면·기능·문서라고 생각한 항목 안에도 그런 사전 보유 요소가 포함될 수 있습니다. 이를 확인하지 않으면 계약이 끝난 뒤 어느 파일이 납품 대상인지, 어떤 부분을 다른 개발사가 손댈 수 있는지 대화가 꼬일 수 있습니다.
실무에서는 결과물 목록을 ‘이번 프로젝트에서 새로 만든 것’, ‘기존 보유·범용 요소’, ‘제3자 제공물’로 나눠 보세요. 각 항목에 저장소 위치, 버전, 담당자, 권리·이용 조건, 대체 가능 여부를 적으면 좋습니다. 단, 목록에 API 키·고객 개인정보·운영 비밀번호를 넣어 공유하면 안 됩니다. 권한 인수인계는 별도 보안 절차로 다루고, 비밀값은 안전한 방식으로 전달·교체해야 합니다.
앱 개발 종료 뒤 저장소·도메인·클라우드 계정의 운영 권한을 확인하는 순서는 앱 외주개발 인수인계 체크리스트에서 이어서 볼 수 있습니다. 그 글이 운영 계정의 실제 통제권을 다룬다면, 이 글은 개발 결과물의 권리와 이용 범위를 계약 단계에서 나누는 데 초점을 둡니다.
외부 라이브러리와 디자인 자산은 ‘포함’만 적지 말고 조건을 남깁니다
오픈소스 라이브러리, 유료 폰트, 스톡 이미지, 지도·결제·분석 SDK는 서비스에 포함될 수 있어도 외주사가 임의로 권리를 넘길 수 있는 자산이라고 단정할 수 없습니다. 따라서 납품 목록에는 외부 구성요소의 이름·버전·출처·적용 기능·라이선스 또는 사용 조건 확인 위치를 남기는 것이 좋습니다. 이것은 특정 라이선스의 의무를 단정하기 위한 목록이 아니라, 다음 담당자가 확인해야 할 출발점을 남기는 방식입니다.
특히 외주사가 “상용 사용 가능하다”고 말한 것만으로 서비스의 사용 조건을 확정하지 마세요. 서비스 출시 전에는 해당 제공자의 최신 약관·라이선스 원문과 계약서의 역할 분담을 함께 검토해야 합니다. 외부 요소의 조건은 바뀔 수 있고, 프로젝트의 배포 방식이나 수정 범위에 따라 적용 검토가 달라질 수 있습니다.
계약 체결 전, 담당자가 함께 확인할 7가지
이번 계약의 결과물을 코드·디자인·문서·콘텐츠·설정으로 나눠 적었는가?
각 결과물의 권리 처리를 양도와 이용허락 중 무엇으로 할지 정했는가?
발주사, 후속 개발사, 인수자에게 허용할 수정·이전·재위탁 범위를 적었는가?
개발사의 사전 보유 모듈과 이번 프로젝트 신규 결과물을 구분했는가?
외부 라이브러리·폰트·이미지·SDK의 출처와 조건 확인 위치를 남겼는가?
납품 시점에 저장소, 빌드 방법, 버전 정보, 문서를 어떤 형식으로 넘길지 정했는가?
계약서의 권리 조항, 실제 납품물 목록, 운영 인수인계 계획이 서로 충돌하지 않는가?
이 목록은 계약 결과나 권리 귀속을 보장하지 않습니다. 공동 작업 여부, 고용관계, 사전 보유 자산, 제3자 이용 조건, 계약 문구 등 사실관계에 따라 검토가 달라질 수 있습니다. 중요한 거래나 서비스 인수·투자 단계라면 최신 계약서와 사실관계를 바탕으로 전문가에게 검토받으세요.
앱 개발 범위와 사업 준비 항목을 현재 단계에 맞춰 정리하려면 유인어스 준비 항목을 확인할 수 있습니다.
자주 묻는 질문
소스코드를 받으면 저작재산권도 자동으로 받나요?
파일 전달과 권리 처리 범위는 같은 질문이 아닙니다. 계약서와 실제 결과물 목록에서 어떤 권리를 누구에게 어떤 조건으로 정했는지 확인해야 합니다. 저작권법 제45조·제46조의 적용은 구체적 사실관계와 약정에 따라 검토해야 합니다.
‘권리 일체 양도’라고만 적으면 충분한가요?
결과물 범위, 기존 보유 요소, 제3자 제공물, 변경·재위탁·승계 범위를 함께 확인하는 편이 좋습니다. 포괄 문구만으로 각 파일과 사용 조건이 분명해지는 것은 아닐 수 있습니다.
다른 개발사에게 유지보수를 맡겨도 되나요?
누가 수정·이용·재허락 또는 이전할 수 있는지는 계약에서 정한 권리와 이용 범위에 따라 달라질 수 있습니다. 계약 전에 후속 개발사 투입 가능성을 공유하고 관련 범위를 문서화하세요.
오픈소스나 유료 폰트도 외주 계약으로 모두 넘겨받을 수 있나요?
각 구성요소의 제공자 조건과 계약 구조를 확인해야 합니다. 외부 요소는 이름·버전·출처·조건 확인 위치를 납품 목록에 남기고, 출시·변경 전 최신 원문을 다시 확인하세요.
앱 개발 계약과 사업 준비 단계에서 빠진 항목을 정리하려면 우리 팀의 준비 항목을 확인해 보세요.