소스코드 소유권과 저작권 양도 2026: 외주 계약서 조항과 인수인계 확인 목록

소스코드 소유권은 완성된 코드를 누가 복제하고 수정하고 다시 배포할 수 있는지, 그리고 다른 개발사에 넘겨 이어서 개발하게 할 수 있는지를 정하는 권리 문제예요. 개발비를 전액 지급했다는 사실만으로 이 권리가 발주자에게 자동으로 넘어오지는 않아요. 대금 지급은 용역에 대한 대가이고, 권리 이전은 계약서에 따로 적어야 성립하는 별개의 합의이기 때문이에요. 이 차이를 모른 채 넘어가면 파일은 손에 있는데 마음대로 쓰지 못하는 상태가 됩니다.

이 글은 법률 강의가 아니라 발주자가 계약서와 인수인계 목록을 검토할 때 쓰는 실무 기준이에요. 개별 사안의 결론은 계약서 문언과 사실관계에 따라 달라지니, 서명 전 변호사 검토를 받는 것을 전제로 읽어주세요. 여기서는 검토를 의뢰하기 전에 발주자가 스스로 짚어야 할 항목과, 미팅에서 개발사에게 물어야 할 질문을 다룹니다.

대금을 다 지급하면 권리도 함께 넘어오나요?

저작권은 대금을 지급한 쪽이 아니라 그 코드를 만든 쪽에 먼저 생겨요. 발주자는 계약을 통해 그 권리를 넘겨받거나 쓸 권한을 허락받는 구조입니다. 견적서에 적힌 "소스코드 제공"은 파일을 전달하겠다는 말이지 권리를 넘기겠다는 말이 아니에요. 두 문장은 계약서에서 서로 다른 자리에 있어야 하고, 없으면 그냥 없는 겁니다.

이 문제는 개발이 진행되는 동안에는 잘 드러나지 않아요. 유지보수를 다른 업체로 옮기려 할 때, 투자 실사에서 지식재산 귀속 자료를 요구받을 때, 서비스를 분사하거나 매각할 때 한꺼번에 터집니다. 그 시점에는 이미 개발사와의 협상력이 낮아진 상태예요. 잔금을 다 치른 뒤라서 협상 카드가 남아 있지 않기 때문이에요.

계약서에 권리 관련 문장이 아예 없거나, "본 계약 산출물의 저작권은 을에게 귀속한다"가 그대로 들어 있는 경우가 반복적으로 관찰돼요. 후자는 발주자가 읽고도 그냥 넘기기 쉬운 형태입니다. 문장 자체가 짧고 계약서 뒤쪽 일반 조항 사이에 섞여 있기 때문이에요. 비슷한 유형의 문장을 모아 정리한 IT 외주 개발 계약서 독소조항 분석을 옆에 두고 대조하면 빠르게 걸러낼 수 있어요. 소유권을 안 적는 일이 다른 실패 패턴과 어떻게 맞물리는지는 웹·앱 개발 실패 이유와 예방법에 정리돼 있습니다. 이 글은 권리 조항 자체를 다루고, 그 글은 실패 패턴 전반을 다뤄요.

홈페이지처럼 규모가 작은 웹 제작 건에서도 같은 질문이 나오는데, 그쪽은 소유권 논점을 비용 구조와 함께 봐야 판단이 섭니다. 웹사이트 한 건을 발주하는 상황이라면 홈페이지 제작 비용 가이드의 소유권 항목을 먼저 보세요. 여기서는 규모와 상관없이 계약서에 들어가야 할 권리 조항을 다룹니다.

저작권 양도와 이용허락은 무엇이 다른가요?

양도는 권리자 자체가 바뀌는 방식이고, 이용허락은 권리자는 개발사로 두고 발주자가 쓸 수 있는 범위만 정하는 방식이에요. 둘 다 "소스코드를 쓸 수 있다"는 결과는 같아 보이지만, 사업을 확장하거나 정리할 때 결과가 갈립니다. 특히 다른 업체로 이관하거나 지분 거래를 할 때 차이가 드러나요.

이용허락이 무조건 나쁜 선택은 아니에요. 다만 이용허락으로 갈 거라면 네 가지 조건을 문장에 넣어야 실무에서 쓸 수 있습니다. 기간이 영구인지, 독점인지 비독점인지, 수정과 개작이 허용되는지, 제3자에게 다시 넘길 수 있는지예요. 이 글에서는 이 네 가지를 계속 같은 묶음으로 씁니다. 대가를 무상으로 할지 별도 사용료를 둘지는 이 네 가지와 별개로 정하는 항목이에요. 네 가지가 빠진 이용허락은 다음 개발사에게 코드를 건네는 순간 문제가 됩니다.

표의 판정은 일반적인 방향을 적은 것이고, 실제 결론은 계약서에 적힌 문언과 사실관계에 따라 달라져요. 그래서 표를 읽을 때는 우리 계약서의 해당 문장을 옆에 두고 대조해야 합니다. 선택 기준 자체는 단순해요. 그 코드가 회사의 사업 자체라면 양도로 가고, 업무를 돕는 부속 도구라면 이용허락으로도 운영이 됩니다. 투자 유치나 매각을 염두에 두고 있다면 양도 쪽이 나중에 설명할 일이 적어요.

계약서에 "소스코드를 납품한다"고만 적혀 있으면 무엇이 빠진 건가요?

소스코드를 둘러싼 약속은 세 층으로 나뉘어요. 파일을 건네는 인도, 저장소와 서버에 들어갈 수 있는 접근권, 그리고 저작재산권 자체입니다. 세 층은 서로를 대신하지 못해요. 압축 파일 하나를 받았다고 저장소 이력이 오는 것도 아니고, 저장소 관리자 권한을 받았다고 권리가 넘어오는 것도 아니에요. 여기에 개발사 것이 아닌 제3자 구성요소를 확인하는 항목이 하나 더 붙어서, 계약서에서는 세 층에 한 줄을 더한 네 줄로 읽으면 됩니다.

이 세 층 중 하나만 적혀 있을 때 문제가 드러나는 형태가 반복적으로 관찰돼요. 파일은 받았는데 커밋 이력이 없어 누가 무엇을 언제 만들었는지 확인할 수 없거나, 접근권은 있는데 계정 소유자가 개발사여서 계약이 끝나자 권한이 회수되는 식이에요. 네 줄이 각각 계약서 어디에 있는지 손가락으로 짚어보는 게 검토의 시작입니다.

표의 오른쪽 열은 그대로 쓰는 표준 문안이 아니라 검토를 시작하는 지점이에요. 개발사마다 계약서 틀이 다르니 같은 뜻이 다른 문장으로 이미 들어가 있을 수도 있어요. 중요한 건 문구가 아니라 네 가지가 각각 언급되어 있는지입니다.

접근권 줄에서 특히 볼 것은 시점이에요. "검수 완료 후 며칠 안에 저장소 접근권을 부여한다"처럼 접근을 뒤로 미루는 문장은 독소조항으로 다뤄지는 형태라, 독소조항 분석의 해당 항목과 함께 읽으면 어디가 문제인지 빨리 보입니다. 같은 항목이 견적서 단계에서는 어떤 이름으로 적히는지는 IT 외주 견적서 분석 가이드에 정리돼 있어요. 견적서에서 한 줄로 스쳐 지나간 항목이 계약서에서 네 줄로 벌어지는 자리라고 보면 됩니다.

2차적저작물작성권과 저작인격권은 왜 따로 적나요?

양도 조항을 "저작재산권 일체를 양도한다"로 넓게 써도, 2차적저작물작성권까지 함께 넘어왔는지는 산출물의 성격에 따라 갈려요. 국내 저작권법은 저작재산권 전부를 양도할 때 특약이 없으면 2차적저작물작성권은 포함되지 않은 것으로 추정하되, 프로그램의 경우에는 반대로 특약이 없는 한 함께 양도된 것으로 추정하는 취지의 규정을 두고 있습니다(저작권법 제45조 제2항). 소스코드 자체는 원칙과 반대쪽 추정이 걸리는 영역이라는 뜻이에요.

그런데도 실무 계약서가 "2차적저작물작성권을 포함한다"를 문장 안에 직접 넣는 이유는 두 가지입니다. 하나는 산출물에 프로그램이 아닌 요소, 그러니까 디자인 시안이나 문서, 콘텐츠가 섞여 있으면 그 부분에는 원칙 쪽 추정이 걸릴 수 있다는 점이에요. 다른 하나는 추정은 반증으로 뒤집힐 수 있어서 다툼이 생기면 결국 계약서 문언으로 돌아온다는 점입니다. 조문 해석은 사안마다 갈릴 수 있으니 이 부분은 변호사 확인을 받는 게 맞습니다.

발주자에게 이 권리가 중요한 이유는 개발이 한 번으로 끝나지 않기 때문이에요. 받은 코드를 고쳐 다음 버전을 만들고, 일부를 떼어 다른 서비스에 쓰고, 구조를 바꿔 다시 짜는 일이 전부 여기에 걸립니다. 산출물에 프로그램이 아닌 요소가 섞여 있을 때 이 문구가 없으면, 그 부분은 받은 상태 그대로 쓰는 것만 허용된다는 해석의 여지가 남아요. 화면 디자인과 문서까지 함께 넘겨받는 계약이라면 한 줄로 정리해 두는 편이 낫습니다.

저작인격권은 성질상 양도되지 않는 권리로 다뤄져요. 만든 사람의 이름을 표시할 권리, 내용을 함부로 바꾸지 못하게 할 권리 같은 것들이에요. 그래서 계약서에서는 양도 대신 "저작인격권을 행사하지 아니한다"는 부작위 특약을 넣는 방식이 자주 쓰입니다. 이 문장이 없으면 코드를 크게 리팩터링하거나 화면 문구를 바꿀 때 이의가 제기될 여지가 생겨요.

정리하면 양도 조항 한 줄에 세 가지가 함께 들어가야 해요. 저작재산권 양도, 2차적저작물작성권 포함, 저작인격권 불행사입니다. 셋 중 하나만 빠져도 나중에 확인해야 할 일이 남습니다.

외주로 만들면 업무상저작물이라 자동으로 회사 것 아닌가요?

업무상저작물 법리는 고용 관계를 전제로 하는 개념이에요. 회사 직원이 업무로 만든 결과물과, 도급이나 위탁 형태로 외부 회사에 맡긴 결과물은 같은 방식으로 다뤄지지 않습니다. 외주 개발은 원칙적으로 계약서에 적은 대로 정해진다고 보는 게 안전해요. 그래서 외주에서는 계약서가 권리를 확보하는 사실상 유일한 수단입니다.

프리랜서와 직접 계약할 때도 같아요. 프리랜서 건은 계약서 없이 메신저 합의로 진행되면서 같은 문제가 그대로 남는 경우가 있어요. 금액과 기간만 합의하고 권리 이야기는 아무도 꺼내지 않은 채 개발이 끝나는 식이에요. 금액이 작은 건에서도 같은 문제가 남습니다.

개발사가 일부 작업을 재하청으로 돌리는 경우도 확인해야 해요. 개발사가 발주자에게 권리를 넘기려면 개발사 자신이 먼저 그 권리를 확보하고 있어야 합니다. 프리랜서나 협력사가 만든 부분에 대해 개발사가 권리를 정리하지 않았다면 권리 사슬이 중간에서 끊겨요. 계약서에 "을은 제3자가 참여한 부분을 포함해 산출물에 관한 권리를 확보한 뒤 갑에게 양도한다"는 취지의 문장을 넣어 이 구멍을 막습니다.

개발사가 "공통 모듈은 못 넘긴다"고 하면 어떻게 하나요?

이 요청이 무조건 부당한 건 아니에요. 개발사가 여러 프로젝트에서 쌓아온 인증 모듈, 관리자 화면 골격, 배포 스크립트 같은 자산은 다른 고객사 서비스에도 들어가 있습니다. 그걸 통째로 한 발주자에게 양도하면 개발사는 다른 계약을 이행할 수 없게 돼요. 그래서 협상은 전부 아니면 전무가 아니라 자산을 나누는 방향으로 갑니다.

실무에서는 계약 전에 이미 존재하던 사전보유자산과, 이번 계약으로 새로 만든 산출물을 구분해요. 사전보유자산은 양도 대신 이용허락으로 처리하되, 앞에서 정리한 네 가지 조건을 그대로 겁니다. 기간은 영구, 독점 여부는 비독점, 수정과 개작 허용, 제3자 이전 가능이에요. 대가는 이 네 가지와 별개 항목이라, 용역비에 포함해 추가 사용료가 붙지 않도록 적어두면 나중에 계산이 단순해집니다. 이 조건이 붙으면 다른 개발사에게 유지보수를 맡길 때 그 모듈째로 넘길 수 있어요.

여기서 중요한 건 사전보유자산 목록을 계약 시점에 별지로 확정하는 일이에요. 목록이 없으면 프로젝트가 끝난 뒤에 "그 부분도 우리 사전보유자산"이라는 주장이 뒤늦게 넓어질 수 있습니다. 목록을 요구했을 때 개발사가 곤란해하면 그 자체가 정보예요. 자기 자산과 고객 자산의 경계를 관리하고 있는 회사인지 드러나기 때문입니다.

이 요구가 계약서에서 어떤 문장으로 나타나는지도 함께 보면 좋아요. "개발사는 유사 프로젝트에서 습득한 노하우와 컴포넌트를 자유롭게 재사용할 수 있다" 같은 무제한 재사용 문장은 독소조항 분석에서 별도 항목으로 다뤘습니다. 이 글은 재사용을 어디까지 허용할지 협상하는 기준을 다루고, 그 글은 계약서 문장 자체를 어떻게 고쳐 쓰는지를 다뤄요.

오픈소스와 유료 라이브러리, 폰트는 왜 소유권과 별개인가요?

양도는 개발사가 가진 권리만 넘기는 절차예요. 개발사가 애초에 권리를 갖고 있지 않은 제3자 구성요소는 양도 문장이 아무리 넓어도 넘어오지 않습니다. 오픈소스 패키지, 유료 라이브러리, 상용 서체가 여기에 해당해요. 계약서상 소유권을 확보했는데도 운영 단계에서 별도 비용이나 제약이 튀어나오는 이유가 이것입니다.

오픈소스는 무료로 쓸 수 있지만 라이선스마다 조건이 붙어 있어요. 고지 의무, 동일 조건 배포 요구, 소스 공개 조건이 라이선스별로 다릅니다. 같은 패키지라도 사내 서버에서만 돌릴 때와 앱으로 배포할 때 걸리는 의무가 달라질 수 있어요. 이 점검을 어떤 순서로 하는지는 오픈소스 의존성과 라이선스 인수 체크리스트에 단계별로 정리해 뒀습니다.

상용 서체는 발주자가 놓치기 쉬운 항목이에요. 인쇄용, 웹폰트, 앱 임베딩이 각각 다른 허락 범위로 나뉘어 있는 경우가 있습니다. 디자인 시안을 받을 때 원본 파일만 챙기고 서체 사용 허락 증빙은 안 받는 일이 반복적으로 관찰돼요. 로고와 아이콘의 제작 원본, 사용한 서체 이름과 구매 명의를 함께 요구해야 나중에 교체 작업을 피할 수 있습니다.

유료 라이브러리와 외부 서비스 키가 개발사 명의로 결제되어 있는 상황도 자주 나와요. 계약이 끝나고 개발사가 갱신을 멈추면 그 기능이 어느 날 멈춥니다. 코드는 우리 것인데 코드가 호출하는 대상이 끊기는 형태예요. 계약 단계에서 유료 구성요소는 발주자 명의로 구매하도록 정하고, 이미 개발사 명의로 산 것은 명의 이전이나 재구매 비용을 누가 부담할지 적어둬야 합니다.

소스코드를 소유해도 인앱결제 수수료는 왜 그대로 나가나요?

코드 소유권과 유통 플랫폼 정책은 서로 다른 층이에요. 앱을 스토어에 올리는 순간 그 스토어의 약관이 적용되고, 디지털 재화 결제에는 스토어가 정한 결제 수단과 수수료 구조가 따라옵니다. 소스코드 저작재산권을 전부 양도받아도 이 조건은 달라지지 않아요. 수수료를 줄이려는 판단은 권리 문제가 아니라 상품 설계와 결제 구조 설계의 문제입니다.

그래서 발주자가 먼저 갈라야 할 것은 우리 상품이 스토어 결제를 거쳐야 하는 종류인지예요. 앱 안에서 바로 소비되는 디지털 재화, 그러니까 구독권, 이용권, 아이템, 기능 잠금 해제 같은 것은 스토어 결제 수단을 쓰도록 요구되는 영역입니다. 반면 실물 상품 배송, 오프라인 서비스 예약, 앱 밖에서 제공되는 용역은 다르게 취급돼요. 우리 상품이 어느 쪽인지에 따라 결제 구조 자체가 갈리니, 이 구분을 견적 단계에서 먼저 확정해야 합니다. 두 종류가 한 앱에 섞여 있으면 결제 흐름을 두 갈래로 설계해야 해서 공수도 달라져요.

구체적인 수수료율, 소규모 사업자 대상 프로그램, 외부 결제 허용 범위는 스토어 정책에 따라 다르고 변경되기도 해요. 그래서 이 글에서는 숫자를 적지 않습니다. 대신 각 스토어의 공식 개발자 문서에서 확인할 항목 이름을 적어둘게요. 애플 쪽은 앱스토어 심사 지침의 결제 관련 항목, 인앱 구입 문서, 소규모 개발자 대상 프로그램 안내 페이지입니다. 구글 쪽은 결제 정책 문서와 서비스 수수료 안내 페이지예요. 이 페이지들에서 현재 기준을 직접 확인하고, 그 값을 기준으로 손익을 계산하는 편이 안전합니다.

견적 단계에서 개발사에게 물을 질문은 세 개로 좁혀져요. 우리 상품 구조에서 스토어 결제가 필수인지, 스토어 결제와 웹 결제를 함께 붙이는 설계가 가능한지, 결제 실패와 환불 처리를 어느 쪽 시스템에서 담당하는지입니다. 이 세 답이 견적서의 결제 연동 공수와 직접 연결돼요. 답을 들을 때는 근거로 삼은 스토어 문서의 항목 이름을 함께 물어보면 확인이 가능해집니다.

권리 쪽에서 발주자가 진짜로 챙겨야 할 항목은 따로 있어요. 개발자 계정 명의입니다. 앱이 개발사 명의 계정으로 올라가 있으면 소스코드 권리를 확보했더라도 그 앱의 리스팅, 리뷰, 설치 기반, 구독 이력을 그대로 가져오기 어려워요. 계정 개설 단계에서 정리하지 않으면 나중에는 이전 절차와 심사가 함께 따라옵니다.

그래서 계약서에는 스토어 계정과 정산 정보를 발주자 명의로 둔다는 문장이 필요해요. 개발사에게는 등록과 배포에 필요한 권한만 위임하는 구조입니다. 개인과 법인 가입에서 절차가 갈리는 부분은 애플 개발자 계정 비용과 등록 절차에 정리했고, 출시 단계에서 계약으로 미리 정해둘 항목은 앱 출시와 앱스토어 심사 계약 항목에서 다뤘어요.

계약서 저작권 조항에는 어떤 문장을 넣어야 하나요?

권리 조항은 한 문단으로 몰아 쓰기보다 항목을 나눠 쓰는 편이 검토하기 쉬워요. 아래 표는 발주자가 계약서를 훑을 때 순서대로 짚을 수 있게 만든 점검표입니다. 왼쪽 항목을 찾지 못했다면 그 줄에 적힌 일이 나중에 생길 수 있다는 뜻이에요. 오른쪽 열은 확인해야 할 취지이지 그대로 붙여 쓰는 표준 문안이 아닙니다.

표에 있는 열 줄을 전부 넣자고 요구하면 협상이 길어질 수 있어요. 순서를 정한다면 권리 귀속, 양도 범위, 계정 명의, 제3자 권리 보증이 먼저입니다. 이 네 가지는 나중에 돈으로 해결하기 어려운 항목이기 때문이에요. 나머지는 조건을 조정하거나 별지로 미룰 여지가 있습니다.

같은 조항이 앞뒤 단계에서는 다른 이름으로 나타나요. 견적서 단계에서 이 조항을 어떻게 읽는지는 IT 외주 견적서 분석 가이드에, 업체를 고르는 단계에서 무엇을 물어야 하는지는 앱 개발 업체 선정 체크리스트에 정리돼 있습니다. 조항 문장 자체는 이 글에서 확정하고, 그 앞 단계 판단은 두 글로 넘기면 중복 없이 정리돼요.

권리가 넘어오는 시점은 언제로 잡아야 하나요?

양도 조항이 있어도 언제 넘어오는지가 비어 있으면 다툼이 남아요. 선택지는 보통 세 가지입니다. 창작과 동시에, 마일스톤별로 부분 이전, 대금 완납 시점이에요. 발주자에게 유리한 건 첫 번째지만 개발사가 받아들이기 어려운 경우가 있습니다.

개발사 입장에서 권리는 미수금에 대한 사실상의 담보예요. 그래서 대금 완납을 조건으로 이전하는 방식이 현실적인 타협점으로 자주 쓰입니다. 이때 발주자가 함께 확인할 것은 완납의 정의예요. 검수 완료와 잔금 지급이 같은 날이 아닌 경우가 있어서, 어느 시점을 기준으로 하는지 문장에 적어야 합니다.

중도 해지 상황도 미리 정해두면 좋아요. 이미 지급한 마일스톤에 해당하는 산출물은 그 시점 상태 그대로 이전한다는 취지의 문장입니다. 이 문장이 없으면 프로젝트가 중간에 멈췄을 때 낸 돈에 해당하는 결과물조차 못 가져오는 상황이 생겨요. 지급 구조를 어떻게 나누는지는 마일스톤 결제 구조 설계 가이드에, 교체 상황의 절차는 외주 개발사 교체와 중도 해지 가이드에 정리해 뒀습니다.

검수와 권리 이전을 같은 것으로 보는 오해도 자주 나와요. 검수는 산출물이 합의한 기준을 충족하는지 확인하는 절차이고, 권리 이전은 그와 별개로 계약이 정한 시점에 일어납니다. 검수 절차를 어떻게 설계하는지는 산출물 검수와 사인오프 가이드에서 단계별로 다뤘어요.

인수인계 문서에는 무엇이 들어가야 저작권 양도가 완성되나요?

계약서에 양도 문장이 있어도 실물을 못 받으면 권리는 서류 위에만 남아요. 인수인계 단계에서 권리와 직접 연결된 항목을 따로 뽑아 확인해야 하는 이유입니다. 운영 전반의 인계 목록은 범위가 넓으니 IT 외주 개발 인수인계 가이드를 함께 보고, 여기서는 권리 확인에 필요한 것만 좁혀서 정리할게요.

표의 앞쪽 여섯 줄은 권리를 확인하는 근거이고, 마지막 두 줄은 권리를 받아도 실제로는 못 쓰는 상태인지 가려내는 항목이에요. 판단 축이 다르니 따로 읽는 게 맞습니다. 운영 자산 전체를 어떤 순서로 넘겨받는지는 앞에서 링크한 인수인계 가이드 쪽이 담당해요.

양도 확인서와 산출물 목록에 서명을 받는 절차를 형식적으로 여기기 쉬운데, 이 문서가 있어야 나중에 무엇이 양도 대상이었는지 특정할 수 있어요. 프로젝트가 길어지면 중간에 추가된 기능과 별도 발주분이 섞이기 때문입니다. 인계 회의를 마치기 전에 목록을 함께 읽고 서명을 받아두면 그 자리에서 끝나는 일이에요.

AI 코딩 도구로 만든 코드의 권리는 어떻게 정하나요?

생성형 도구가 만든 코드의 권리 관계는 도구 약관, 사용 방식, 해석에 따라 달라질 수 있는 영역이에요. 지금 시점에서 하나의 결론으로 단정하기는 어렵습니다. 그래서 발주자가 할 일은 답을 정하는 게 아니라 확인할 수 있는 상태를 만들어 두는 쪽이에요. 나중에 문제가 생겼을 때 무엇을 근거로 대응할지 미리 정하는 겁니다.

계약 단계에서 통제할 수 있는 항목은 네 가지예요. 어떤 도구를 쓰는지 고지받기, 산출물이 제3자 권리를 침해하지 않는다는 보증 받기, 우리 코드와 데이터를 외부 학습에 넣지 못하게 하기, 사용 내역을 남기게 하기입니다. 이 네 가지는 생성물의 권리 귀속과 별개로 계약서에 적을 수 있어요. 조항 형태와 협의 방법은 외주 계약서에 넣을 AI 도구 사용 조항에 정리해 뒀습니다.

AI 도구 사용 자체를 금지하는 방향은 실효성이 떨어져요. 확인하기 어렵고, 개발 속도를 이유로 단가 협상에 영향을 줄 수도 있습니다. 금지보다 고지와 보증으로 접근하는 편이 발주자에게 실익이 있어요. 기밀 자료가 외부 도구로 흘러가는 문제는 NDA와 기밀유지 계약 조항 쪽에서 함께 다루면 중복 없이 정리됩니다.

계약이 이미 끝났는데 저작권 조항이 없으면 지금 무엇을 할 수 있나요?

먼저 현재 상태를 사실로 확인해요. 저장소와 클라우드 계정의 소유자가 누구인지, 스토어 계정 명의가 어디로 되어 있는지, 계약서와 발주서에 권리에 관한 문장이 한 줄이라도 있는지 세 가지입니다. 이 확인 없이 협의를 시작하면 상대의 설명에 끌려가기 쉬워요. 계정 소유자는 관리 화면에서 바로 확인할 수 있는 항목입니다. 이 글은 권리와 계정 명의가 서로 다른 층이라는 판단 기준까지만 다루고, 실제로 계정과 인프라를 넘겨받는 절차는 클라우드 인프라 인수인계 7단계 가이드로 넘깁니다.

다음은 사후 양도 합의서를 별도로 체결하는 방법이에요. 이미 대금을 다 지급한 뒤라 협상 카드는 적지만, 유지보수 계약이 이어지고 있다면 그 협의와 묶을 수 있습니다. 개발사 입장에서도 권리 관계가 정리되어 있는 편이 다음 계약에 유리해요. 관계가 유지되고 있을 때 꺼내는 편이 이야기를 시작하기 쉽습니다.

양도가 어렵다면 최소한 이용허락 범위라도 서면으로 받아두세요. 앞에서 정리한 네 가지 조건, 즉 기간, 독점 여부, 수정 허용, 제3자 이전을 그대로 문장에 넣으면 실무에서 필요한 동작은 가능해집니다. 유지보수 계약을 갱신할 때 이 문장을 넣는 방식도 있는데, 계약 구조는 개발 유지보수 계약과 비용 가이드에서 함께 살펴보면 됩니다. 그리고 다음 개발사와의 계약서에는 같은 항목이 반복되지 않도록 이번 경험을 그대로 반영하세요.

계약서에 서명하기 전 마지막으로 무엇을 확인하나요?

아래 표는 서명 직전에 계약서를 열어놓고 순서대로 짚는 용도예요. 각 줄은 예 또는 아니오로 답할 수 있게 만들었습니다. 아니오가 나온 줄만 개발사에게 질문하면 미팅이 짧아져요. 답을 듣는 것보다 문장이 계약서 어디에 있는지 함께 확인하는 게 중요합니다.

여덟 줄을 다 통과했다면 권리 쪽에서 급하게 막을 구멍은 줄어든 상태예요. 남는 작업은 인수인계 시점에 실물을 받아 목록과 대조하는 일입니다. 계약서 검토와 인계 확인은 서로 다른 시점의 작업이라 한쪽만으로는 끝나지 않아요.

포텐랩은 앱과 웹 프로덕트 개발을 맡고, AI 챗봇이나 RAG처럼 AI 자체가 제품인 프로젝트는 트리숲(TreeSoop)이 맡습니다. 어느 쪽이든 권리 귀속과 계정 명의는 계약 첫 검토에서 정리하고 시작하는 편이 서로에게 낫다고 봐요. 발주를 준비하고 있다면 계약서 초안을 열기 전에 이 글의 점검표부터 채워보시길 권합니다.

자주 묻는 질문

개발비를 전액 지급하면 소스코드 소유권이 자동으로 넘어오나요?

아니에요. 저작권은 대금을 지급한 쪽이 아니라 코드를 만든 쪽에 먼저 생기고, 발주자는 계약으로 양도받거나 이용허락을 받는 구조예요. 견적서에 적힌 소스코드 제공은 파일을 전달하겠다는 뜻이지 권리를 넘기겠다는 뜻이 아닙니다. 계약서에 권리 귀속 문장이 따로 들어 있는지 확인해야 해요.

저작권 양도와 이용허락 중 어느 쪽을 요구해야 하나요?

그 코드가 사업 자체라면 양도로 가고, 사내 도구처럼 재사용 계획이 없다면 이용허락으로도 운영이 됩니다. 이용허락으로 갈 경우에는 기간이 영구인지, 독점인지 비독점인지, 수정과 개작이 되는지, 제3자에게 이전할 수 있는지 네 가지를 문장에 넣어야 다음 개발사로 넘길 수 있어요. 대가를 무상으로 할지는 이 네 가지와 별개로 정하는 항목입니다. 다만 표에 적은 판정은 일반적인 방향이고 실제 결론은 계약 문언과 사실관계에 따라 달라져요.

계약서에 2차적저작물작성권을 왜 따로 적어야 하나요?

국내 저작권법은 저작재산권 전부를 양도할 때 특약이 없으면 2차적저작물작성권은 포함되지 않은 것으로 추정하되, 프로그램의 경우에는 반대로 특약이 없는 한 함께 양도된 것으로 추정하는 취지의 규정을 두고 있습니다(저작권법 제45조 제2항). 그래도 실무에서 문장을 직접 넣는 이유는 두 가지예요. 산출물에 디자인이나 문서처럼 프로그램이 아닌 요소가 섞이면 그 부분에는 원칙 쪽 추정이 걸릴 수 있고, 추정은 반증으로 뒤집힐 수 있어 다툼이 생기면 결국 계약서 문언으로 돌아오기 때문입니다. 조문 해석은 사안마다 갈릴 수 있어 변호사 확인을 받는 게 맞아요.

외주로 만들면 업무상저작물이라 자동으로 회사 것 아닌가요?

업무상저작물 법리는 고용 관계를 전제로 하는 개념이라, 도급이나 위탁으로 외부 회사에 맡긴 결과물은 같은 방식으로 다뤄지지 않습니다. 외주 개발은 원칙적으로 계약서에 적은 대로 정해진다고 보는 게 안전해요. 프리랜서와 직접 계약할 때도 마찬가지라, 금액과 기간만 합의하고 권리 이야기를 꺼내지 않으면 같은 문제가 그대로 남습니다.

개발사가 사전에 보유한 공통 모듈도 양도받을 수 있나요?

그 모듈이 다른 고객사 서비스에도 들어가 있으면 양도가 거절될 수 있어요. 이럴 때는 사전보유자산과 이번 계약의 산출물을 나누고, 사전보유자산에는 영구, 비독점, 수정 허용, 제3자 이전 가능이라는 네 가지 조건의 이용허락을 받는 방식이 현실적입니다. 대가는 별개 항목이라 용역비에 포함해 추가 사용료가 붙지 않도록 적어두면 좋아요. 그 목록을 계약 별지로 확정해 두어야 범위 주장이 나중에 넓어지지 않습니다.

계약이 이미 끝났는데 저작권 조항이 없으면 지금 무엇을 할 수 있나요?

먼저 저장소와 클라우드 계정의 소유자, 스토어 계정 명의, 계약서에 권리 문장이 한 줄이라도 있는지 세 가지를 사실로 확인하세요. 그다음 사후 양도 합의서를 별도로 체결하는 방법이 있고, 유지보수 계약이 이어지고 있다면 그 협의와 묶을 수 있습니다. 관계가 유지되고 있을 때 꺼내는 편이 이야기를 시작하기 쉬워요. 양도가 어렵다면 기간, 독점 여부, 수정 허용, 제3자 이전 네 가지를 담은 이용허락이라도 서면으로 받아두세요.

함께 읽으면 좋은 글

• 서버 이전을 외주로 맡길 때 확인할 것
• 소셜 로그인·PG 연동에 드는 비용과 기간
• API 연동 개발의 비용 구조