회사가 입사 전에 작성한 개인 프로젝트까지 회사 소유로 한다는 계약서를 제시하면 서명해야 할까?

About this offer

TL;DR 결론부터 말하면, 입사 전에 독자적으로 만든 개인 프로젝트까지 회사 소유로 한다는 조항에 별다른 검토 없이 그대로 서명할 필요는 없습니다. 입사 전 프로젝트와 입사 후 업무상 만들어지는 결과물은 출발점부터 다릅니다. 특히 프로그램 저작권은 기존 권리가 누구에게 있었는지와 계약을 통해 그 권리를 실제로 회사에 넘기기로 했는지를 따로 봐야 합니다. 따라서 가장 현실적인 방법은 입사 전 프로젝트를 Background IP 또는 Prior Inventions 로 별도 목록화하고, 해당 프로젝트와 기존 소스코드에 관한 권리는 개발자에게 유보된다는 예외조항을 두는 것입니다. 핵심은 간단합니다. 회사에서 일하면서 만든 것과 회사에 들어오기 전에 이미 가지고 있던 것을 같은 디렉터리에 넣으면 안 됩니다. 1. 문제 정의: Problem Statement 개발자 A가 새로운 회사에 입사하면서 근로계약서와 비밀유지계약서, 지식재산권 약정서를 함께 받았다고 가정해보겠습니다. 계약서에 이런 취지의 내용이 들어 있습니다. 근로자가 보유하거나 개발한 프로그램, 소스코드, 아이디어, 발명 및 기타 지식재산권은 회사에 귀속한다. 문장을 조금 더 자세히 읽어보니 입사 후 회사 업무로 개발한 프로그램만 말하는 것이 아닙니다. 입사 전부터 GitHub에서 운영하던 개인 프로젝트나 개인적으로 개발하던 라이브러리까지 회사가 권리를 취득할 수 있는 것처럼 작성되어 있습니다. 이런 경우 개발자가 생각해야 할 질문은 단순히 하나가 아닙니다. 이 계약서가 유효한가? 보다 먼저 다음과 같이 문제를 나누어야 합니다. 1. 프로젝트는 언제 만들어졌는가? 2. 누가 만들었는가? 3. 현재 권리자는 누구인가? 4. 회사의 업무와 관련이 있는가? 5. 회사가 원하는 것은 소유권인가, 사용권인가? 6. 계약서는 기존 권리까지 양도하도록 작성되어 있는가? 7. 입사 후 기존 프로젝트를 계속 개발한다면 그 부분은 어떻게 처리되는가? 개발자식으로 표현하면 이것은 하나의 boolean 문제가 아닙니다. 여러 개의 조건을 확인해야 하는 권리 귀속 로직입니다. 2. 법적 구조 설명: System Architecture 관점 먼저 프로그램은 일반적인 물건과 조금 다릅니다. 노트북을 샀다면 노트북의 소유자는 비교적 쉽게 확인할 수 있습니다. 하지만 프로그램에는 소스코드에 관한 저작권이 존재합니다. 누가 코드를 작성했는지, 회사가 기획하여 업무로 작성된 것인지, 기존 코드가 있었는지, 계약으로 권리를 양도했는지에 따라 결과가 달라집니다. 기본값은 무엇일까? 저작권의 기본 구조에서는 실제로 창작한 사람이 출발점이 됩니다. 다만 회사가 기획하고 회사 업무에 종사하는 사람이 업무상 프로그램을 작성한 경우에는 일정한 요건 아래 회사가 프로그램의 저작자가 될 수 있습니다. 프로그램은 일반적인 업무상저작물과 달리 외부에 공개되었을 것까지 요구되지는 않습니다. 즉, 회사 기획 + 회사 업무 수행 + 업무상 프로그램 작성 = 회사에 권리가 귀속될 가능성이 높은 영역 이라는 구조입니다. 반대로 입사하기 2년 전 개인 노트북으로 혼자 만든 프로그램이라면 이야기가 달라집니다. 회사가 존재하기도 전에 작성했거나, 적어도 그 개발자가 회사에 입사하기 전에 독립적으로 만들어 가지고 있던 프로그램을 두고 단순히 나중에 그 회사에 입사했다는 이유만으로 회사가 처음부터 저작자가 되는 것은 아닙니다. 서버에 입사했다고 해서 과거 커밋의 author가 바뀌는 것은 아닙니다. 그런데 계약서에 서명하면 이야기가 달라질 수 있습니다 여기서 두 번째 레이어가 등장합니다. 저작재산권은 계약을 통해 전부 또는 일부를 다른 사람에게 양도할 수 있습니다. 현행 저작권 제도 역시 저작재산권의 전부 또는 일부 양도를 인정하고 있습니다. 따라서 이런 주장은 위험합니다. “어차피 입사 전에 제가 만든 거니까 계약서에 뭐라고 쓰여 있어도 무조건 제 겁니다.” 항상 그렇지는 않습니다. 원래 개발자에게 있던 권리라고 하더라도 개발자가 이후 계약을 통해 그 권리를 회사에 양도하는 것은 별개의 문제이기 때문입니다. 그래서 계약서를 볼 때는 반드시 두 단계를 나누어야 합니다. Step 1. 현재 이 프로젝트의 권리자는 누구인가? Step 2. 이번 계약을 체결하면서 그 권리를 회사에 넘기는가? 대법원도 프로그램 저작권의 양도 여부가 분명하지 않은 사안에서는 계약 내용과 거래 경위 등을 살펴 권리가 기존 권리자에게 유보되었는지를 판단해 왔습니다. 결국 계약 문구가 중요합니다. 3. 흔히 발생하는 오해: Common Misconceptions 오해 1. 회사 컴퓨터로 만들지 않았으면 무조건 개인 소유다 그렇게 단순하지 않습니다. 장비는 여러 판단 요소 중 하나일 뿐입니다. 회사에서 지급한 맥북을 사용했는지만 가지고 권리 귀속이 결정되는 것은 아닙니다. 누가 개발을 기획했는지, 어떤 업무를 수행하면서 만든 것인지, 근무시간에 개발했는지, 회사의 구체적인 지시가 있었는지 등을 함께 살펴야 합니다. 오해 2. 퇴근 후 집에서 만들었으면 무조건 개인 프로젝트다 이것도 항상 그렇지는 않습니다. 가령 회사가 개발자에게 특정 기능 개발을 맡겼는데 개발자가 집에서 저녁에 코딩했다고 가정해보겠습니다. 저장장소가 개인 PC라는 이유만으로 회사 업무가 개인 프로젝트로 변환되는 것은 아닙니다. location == home 이 곧 personal_project == true 를 의미하지는 않습니다. 오해 3. 입사 전 프로젝트라면 계약서에 서명해도 아무 문제 없다 오히려 이 부분을 가장 조심해야 합니다. 입사 전 프로젝트가 원래 개발자의 것이었다는 것과 그 권리를 계약으로 회사에 넘겼는지는 별개의 문제입니다. 특히 계약서에 다음과 같은 표현이 있다면 범위를 확인할 필요가 있습니다. 과거 및 현재 개발한 모든 프로그램 근로자가 보유하는 일체의 지식재산권 회사 업무와 관련될 수 있는 모든 아이디어 근로기간 전후 개발한 모든 소프트웨어 기존 프로그램 및 그 개량물 일체 범위가 지나치게 넓다면 입사 전 프로젝트까지 포함되는지 반드시 확인해야 합니다. 오해 4. 발명도 프로그램 저작권과 똑같이 보면 된다 그렇지 않습니다. 특허 등이 문제되는 직무발명 은 별도의 구조가 존재합니다. 현행 제도는 회사 업무 범위에 속하고 직원의 현재 또는 과거 직무에 해당하는 발명을 직무발명으로 다루면서, 직무발명에 대해서는 회사가 일정한 절차와 규정에 따라 권리를 승계할 수 있도록 하고 있습니다. 반대로 직무발명이 아닌 발명까지 앞으로 만들어지는 순간 무조건 회사가 가져간다는 식의 사전 포괄승계 조항은 제한됩니다. 대법원도 직무발명 이외의 발명에 대한 사전 승계 부분은 효력이 없다는 취지로 판단하고 있습니다. 다만 이것을 근거로 프로그램 저작권까지 무조건 같은 결론이라고 생각해서는 안 됩니다. 특허·발명 모듈 과 프로그램 저작권 모듈 은 서로 다른 규칙으로 돌아갑니다. 4. 케이스 분기: if / else로 보면 의외로 단순합니다 대략적인 구조를 의사코드로 정리해보겠습니다. if 프로젝트가 입사 전에 이미 완성되어 있었다: 기존 권리자가 누구인지 확인 공동개발자 존재 여부 확인 오픈소스 및 제3자 권리 확인 if 계약서가 기존 프로젝트의 권리까지 회사에 양도한다고 명확히 규정: 수정 또는 제외조항 협의 필요 else: 기존 권리 유지 가능성 검토 else if 입사 후 새롭게 개발했다: if 회사가 기획했고 + 담당업무로 작성했다: 회사 권리 영역인지 검토 else if 완전히 개인적인 프로젝트이고 회사 업무와 무관하고 회사 자원도 사용하지 않았다: 개인 권리 영역인지 검토 else: 경계영역 계약서 + 실제 개발과정 + 업무관련성 함께 검토 문제는 현실의 프로젝트가 이렇게 깔끔하게 분리되지 않는다는 점입니다. 가장 골치 아픈 경우가 있습니다. 입사 전 개인 프로젝트 ↓ 입사 ↓ 기존 코드를 조금 수정 ↓ 회사 프로젝트에서 활용 ↓ 회사 요구사항을 추가 구현 ↓ 개인 프로젝트에도 다시 반영 이렇게 되면 Git history가 갑자기 법적 증거목록처럼 보이기 시작합니다. 어디까지가 기존 코드이고 어디부터가 입사 후 개발된 부분인지가 중요해지기 때문입니다. 5. 특히 위험한 케이스: 개인 라이브러리를 회사 제품에 넣는 경우 개발자들에게 실제로 자주 발생할 수 있는 문제입니다. 개발자 B가 입사하기 전부터 개인적으로 만든 라이브러리 awesome-utils 를 가지고 있다고 가정해보겠습니다. 회사에서도 비슷한 기능이 필요합니다. B는 이렇게 생각합니다. “제가 이미 만들어둔 게 있으니까 그냥 가져다 쓰면 되겠네요.” 개발 효율성 측면에서는 맞습니다. 권리관계 측면에서는 갑자기 dependency가 하나 늘어납니다. 이때는 적어도 다음을 정리해야 합니다. 기존 awesome-utils의 저작권 → 개발자 회사가 사용할 수 있는 범위 → 별도 라이선스 회사 요구로 새로 작성한 코드 → 계약에 따라 판단 기존 프로젝트에 다시 반영할 수 있는지 → 별도 확인 회사 입장에서도 기존 프로젝트 전체를 굳이 소유할 필요가 없는 경우가 많습니다. 회사가 필요한 것은 해당 라이브러리를 자사 제품에서 안정적으로 사용할 권리일 수 있습니다. 그렇다면 소유권 이전보다 사용허락 으로 해결하는 것이 시스템 구조상 훨씬 깔끔합니다. 6. 오픈소스가 섞여 있다면 더 복잡해집니다 개인 프로젝트라고 해서 모든 코드가 개발자 자신의 것은 아닙니다. 오픈소스 라이브러리가 포함될 수도 있고 다른 개발자와 공동으로 작성했을 수도 있습니다. 따라서 계약서에 “해당 프로젝트에 관한 모든 권리를 회사에 양도한다.” 라고 적어 놓는다고 해서 실제로 존재하지 않는 권리까지 회사에 넘길 수 있는 것은 아닙니다. 개발자가 가지고 있는 권리의 범위부터 확인해야 합니다. 내가 작성한 코드 + 공동개발자가 작성한 코드 + 오픈소스 코드 + 외부 API + 상용 SDK 가 하나의 repository에 들어 있다고 해서 모든 권리가 하나의 객체로 합쳐지는 것은 아닙니다. 라이선스 구조를 무시하고 SELECT * FROM intellectual_property 를 실행할 수는 없습니다. 7. 현실적인 대응 전략: Practical Strategy 그렇다면 입사 전에 회사가 이런 계약서를 제시했을 때 어떻게 대응하는 것이 좋을까요. 가장 먼저 계약을 거절할 것인지부터 고민할 필요는 없습니다. 먼저 권리 범위를 정상적으로 설계하면 됩니다. 1단계. 입사 전 프로젝트 목록을 만든다 GitHub repository, 개인 앱, 라이브러리, SaaS, 플러그인, 알고리즘 등 계속 유지할 프로젝트가 있다면 목록을 작성해 두는 것이 좋습니다. 예를 들면 다음과 같습니다. 프로젝트명: ABC Library 최초 개발일: 2024년 Repository: github.com/... 주요 기능: 이미지 처리 라이브러리 권리자: 본인 현재 상태: 개인 프로젝트로 계속 개발 중 이를 계약서 별지에 넣을 수 있습니다. 실무에서는 이런 기존 지식재산을 Background IP , Prior IP , Prior Inventions 등으로 구분하기도 합니다. 2단계. 기존 프로젝트 제외조항을 둔다 계약서는 다음 구조가 훨씬 안전합니다. 입사 전에 독자적으로 개발하거나 보유하고 있던 프로그램, 소스코드 및 기타 지식재산권은 회사에 이전되지 않는다. 해당 기존 지식재산의 목록은 별지와 같다. 그리고 회사에서 기존 프로젝트를 사용할 필요가 있다면 다음 단계를 별도로 설계합니다. Ownership → 개발자에게 유지 License → 필요한 범위에서 회사에 부여 굳이 database ownership까지 migration할 필요 없이 API access만 주면 되는 상황도 있습니다. 3단계. 입사 시점의 상태를 남겨둔다 이것은 개발자에게 특히 쉬운 방법입니다. 입사 전에 다음 자료를 보존해두는 것이 좋습니다. Git commit history repository 생성일 release history package 배포 기록 앱스토어 또는 서비스 출시 기록 개발 관련 문서 기존 소스코드 백업 나중에 분쟁이 생기면 결국 문제가 되는 것은 “이 코드는 언제부터 존재했는가?” 이기 때문입니다. 개발자에게 Git은 버전관리도구이지만, 분쟁이 생기면 훌륭한 타임라인 자료가 되기도 합니다. 4단계. 관련된 모든 것 이라는 문구를 조심한다 계약서에서 가장 위험한 것은 넓고 추상적인 단어입니다. 관련된 파생된 응용된 참고한 활용한 유사한 회사의 사업과 관계있는 예를 들어 회사가 AI 서비스를 한다고 해서 직원이 과거에 개인적으로 만든 모든 AI 프로젝트까지 회사 권리가 된다고 단정할 수는 없습니다. 회사 사업 분야와 비슷하다 와 회사 업무로 개발했다 는 전혀 다른 조건입니다. Boolean 하나 차이 같지만 결과는 상당히 큽니다. 5단계. 입사 후 개인 프로젝트를 계속할 예정이라면 그 부분까지 정한다 입사 전 프로젝트를 제외하는 것만으로 끝나지 않는 경우도 있습니다. 입사 후에도 계속 업데이트할 계획이라면 다음 문제를 미리 정해두는 것이 좋습니다. 개인 시간에 개발 가능 여부 회사 장비 사용 가능 여부 회사 소스코드 사용 금지 회사 영업비밀 사용 금지 회사 프로젝트와 기능이 겹칠 경우 처리방법 기존 프로젝트의 개선물 권리 귀속 처음에는 귀찮아 보입니다. 하지만 장애가 발생한 다음 production에서 hotfix하는 것보다 처음 architecture를 정리하는 것이 훨씬 저렴합니다. 법적 분쟁도 비슷합니다. 8. 그래서 서명해야 할까? 입사 전 개인 프로젝트까지 아무런 구분 없이 회사 소유로 한다는 계약이라면, 일단 그대로 서명하기보다는 어떤 프로젝트와 어떤 권리까지 이전되는지를 먼저 확인하는 것이 좋습니다. 특히 개발자가 계속 운영할 프로젝트가 있다면 계약 단계에서 제외해두는 것이 가장 깔끔합니다. 이미 만들어놓은 프로젝트를 숨길 필요도 없고, 회사와 싸울 필요도 없습니다. 아주 단순하게 말하면 됩니다. 이 프로젝트는 입사 전에 제가 독자적으로 개발한 기존 프로젝트입니다. 회사 업무로 새롭게 작성하는 결과물과는 별도로 기존 프로젝트에 관한 권리는 제게 유보되는 것으로 계약서에 명확히 기재하고 싶습니다. 정상적인 지식재산권 관리라면 이것은 이상한 요구가 아닙니다. 오히려 회사 입장에서도 어떤 코드가 회사 자산이고 어떤 코드가 외부 자산인지 명확해지는 장점이 있습니다. Takeaway 이 문제를 복잡하게 생각할 필요는 없습니다. 권리관계를 세 개의 저장소로 나누면 됩니다. Repository A 입사 전부터 가지고 있던 개인 프로젝트 → 기존 권리 Repository B 회사 기획 + 회사 업무로 새롭게 작성한 결과물 → 회사 권리 여부 검토 Repository C 입사 전 프로젝트를 회사 업무에서 사용하거나 입사 후 계속 수정한 경계영역 → 계약과 라이선스 구조를 별도로 설계 가장 위험한 방식은 이 세 가지를 하나의 폴더에 넣고 계약서에는 모든 지식재산권은 회사 소유 라고 한 줄만 써두는 것입니다. 분쟁이 발생하면 그때부터 사람들은 과거의 commit을 하나씩 열어보기 시작합니다. 좋은 계약서는 분쟁에서 이기기 위한 문서이기 전에, 애초에 어디서 conflict가 발생하는지 미리 정의해놓은 문서입니다. 계약서에 git conflict 표시가 보이기 전에 권리관계부터 merge해두는 편이 낫습니다. 지세훈 변호사 법률상담 안내