소프트웨어 소스코드 영업비밀 침해, 가처분으로 막을 수 있나요? 실무 해설

1. 사건의 배경: 공동개발에서 분쟁으로

A사는 산업용 자동화 기기 소프트웨어 개발 및 제조를 목적으로 하는 회사이고, B사는 프랜차이즈 매장 등에 무인 자동화 기기를 설치하고 운영하는 사업을 영위하고 있었습니다.

공동개발계약의 체결 (2018년 12월)

2018년 12월, A사와 B사는 공동개발계약을 체결했습니다. 주요 내용은 다음과 같습니다.

• A사가 무인 자동화 기기 1,500대를 제작하여 B사에 납품
• B사는 개발비 약 6,200만 원(VAT 별도)을 A사에 지급
• 계약서 제3조: “본 계약의 대상이 되는 자동화 기기 단말기는 H/W, S/W 및 사용자가 이용하는 Application 프로그램(이하 ‘AP’라고 한다)으로 구성되며…”
• 계약서 제7조: “B사가 A사에게 개발비를 지급한 이후에는 AP 소유권은 B사에게 귀속한다”

추가 납품계약과 신모델 개발 (2019~2021년)

2019년 4월, A사와 B사는 추가로 자동화 기기 1,500대에 대한 납품계약을 체결했습니다. 이후 A사는 B사의 요청에 따라 기존 모델을 개량한 신모델을 개발하여 납품했습니다. 문제는 이 신모델에 적용된 소프트웨어가 공동개발계약 당시 예정되었던 프로그램인지, 아니면 별도로 개발된 프로그램인지에 있었습니다.

특히 신모델에는 기존에 없던 새로운 하드웨어 모듈이 탑재되었습니다. 결제 모듈이 X사 제품에서 Y사 제품으로 변경되면서, 이를 제어하기 위한 새로운 미들웨어가 필요했습니다. A사는 이 미들웨어를 자체 개발했고, 이것이 이후 분쟁의 핵심 쟁점이 되었습니다.

2. 소스코드 유출의 발견: 무단 복제는 어떻게 밝혀졌나?

2021년 9월부터 A사와 B사는 소스코드 이관 협의를 시작했습니다. 그러나 협의 과정에서 예상치 못한 사실이 드러났습니다.

소스코드 이관 협의 (2021년 9월~2022년 1월)

A사는 2022년 1월, B사에 소스코드를 이관했습니다. 그런데 이관된 소스코드는 2019년경 개발된 초기 버전이었습니다. B사는 이 초기 버전을 기반으로 독자적으로 ver.45를 개발했다고 주장했습니다. 그러나 A사가 확인한 결과, B사가 개발했다는 ver.45에는 A사가 초기 버전 이관 이후에 별도로 개선한 내용들이 그대로 반영되어 있었습니다. 이것은 B사가 A사의 최신 소스코드를 이미 보유하고 있다는 강력한 증거였습니다.

무단 복제 사실의 확인 (2022년 2월)

A사는 경찰에 수사를 의뢰했습니다. 2022년 2월 경찰 수사 과정에서 결정적인 사실이 밝혀졌습니다.

• B사 직원이 A사에 파견 나온 직원이 잠시 자리를 비운 사이, 해당 직원의 노트북에 무단으로 USB를 연결했음
• USB를 통해 A사의 AP 소스코드 일체를 복사해 감
• 수사 당시까지 B사 직원 컴퓨터에서 A사의 AP 소스코드가 명칭이 변경된 채로 저장되어 있음이 확인됨

특히 경찰 수사에서 확인된 바에 따르면, B사 컴퓨터에 저장된 소스코드는 단순히 파일명만 변경된 것이 아니라, 일부 주석이나 변수명이 수정된 상태였습니다. 이는 B사가 A사의 소스코드를 단순 보관한 것이 아니라 적극적으로 활용하려 했음을 시사하는 증거였습니다.

3. 쟁점 프로그램의 기술 구조: 무엇이 침해되었나?

이 사건에서 가장 치열하게 다투어진 쟁점은 “어떤 프로그램이 공동개발계약상 AP에 해당하는가”였습니다. A사가 B사에 납품한 자동화 기기 소프트웨어는 단일 프로그램이 아니라 수십 개의 모듈로 구성된 복합 시스템이었습니다.

소프트웨어 아키텍처

법원이 인정한 사실관계에 따르면, 쟁점 프로그램들은 기능과 계층에 따라 다음과 같이 분류됩니다.

핵심 쟁점: 미들웨어(DevCntl)의 성격

가장 핵심적인 기술 쟁점은 모듈제어엔진 통합 미들웨어인 DevCntl의 성격이었습니다. DevCntl은 DLL(Dynamic Link Library) 파일로 컴파일되어 배포되는 프로그램으로, 다음과 같은 기능을 수행합니다.

• 결제 모듈이 X사 제품이든 Y사 제품이든 상관없이 상위 AP가 동일한 방식으로 작동할 수 있도록 하드웨어 차이를 추상화
• 각 하드웨어 모듈의 상태 정보를 수집하여 상위 AP에 전달
• 상위 AP의 명령을 해석하여 해당 하드웨어 모듈에 적합한 제어 신호로 변환

B사는 “DevCntl도 결국 AP가 작동하기 위해 필요한 프로그램이므로 AP에 포함된다”고 주장했습니다. 그러나 A사는 “DevCntl은 AP가 아니라 AP와 하드웨어 사이에서 동작하는 미들웨어로, 계약 당시 예정되지 않았던 신모델 개발 과정에서 별도로 개발된 것”이라고 반박했습니다.

4. 공동개발계약의 해석: AP 소유권 귀속의 한계

공동개발계약서 제7조의 해석이 이 사건의 승패를 가르는 핵심 쟁점이었습니다. 법원은 계약서 문언과 체결 당시 상황, 이행 경과 등을 종합적으로 고려하여 AP의 범위를 판단했습니다.

법원의 해석 기준

법원은 DevCntl에 대해 다음과 같이 판단했습니다.

첫째, DevCntl의 핵심기능은 결제 모듈이 X사의 것인지 Y사의 것인지를 불문하고 AP가 작동할 수 있도록 해주는 것입니다. 이는 공동개발계약 체결 당시 예정되었던 기능이 아닙니다.

둘째, DevCntl은 공동개발계약이 체결되어 양산되기 시작한 때(2018년 말~2019년 초)로부터 상당 기간이 경과한 후에야 개발된 프로그램입니다. 구체적으로 신모델 개발이 본격화된 2020년경에 개발되었습니다.

셋째, DevCntl은 공동개발계약에 의해 제작·납품하기로 한 기기 1,500대가 거의 전부 납품되었을 무렵에, 별도로 납품계약을 체결한 개량형 모델에 적용된 프로그램입니다.

넷째, DevCntl의 저작권에 대해서는 양 당사자 사이에 별도 협의를 한 적이 없었던 것으로 보이고, 통상 그런 경우 저작권은 제조사에게 있습니다.

프로그램별 판단 결과

법원은 쟁점 프로그램들을 개별적으로 검토하여, 각 프로그램이 공동개발계약상 AP에 해당하는지 여부를 판단했습니다. 그 결과 DevCntl을 비롯한 일부 프로그램에 대해서는 “현재까지 제출된 자료만으로는 B사가 공동개발계약에 의해 위 소스코드에 대한 소유권까지 취득하였다고 단정하기 부족하다”고 판단했습니다.

5. 법원의 판단: 피보전권리와 보전의 필요성

가처분이 인용되려면 피보전권리(영업비밀 침해금지청구권)의 존재와 보전의 필요성이 모두 소명되어야 합니다. 법원은 두 요건을 모두 인정했습니다.

피보전권리의 소명

법원은 피보전권리에 대해 다음과 같이 판단했습니다. “별지1 목록 기재 프로그램들(이하 ‘쟁점 프로그램들’이라고 한다)은 신청인의 영업비밀인 점, 피신청인이 이를 무단으로 복제하여 감으로써 영업비밀을 침해한 점 등이 소명되므로, 특별한 사정이 없는 한, 신청인에게는 피신청인을 상대로 위 프로그램들의 사용·개작 금지 등을 구할 피보전권리가 인정됩니다.”

B사의 항변과 법원의 판단

B사는 크게 두 가지 항변을 제기했습니다.

첫째, 소유권 항변: B사는 “미들웨어 관련 DLL을 제외한 나머지 프로그램들의 소스코드들은 모두 공동개발계약에 따라 소유권이 인정되는 AP에 해당하므로, A사는 영업비밀 침해를 주장할 수 없다”고 항변했습니다. 그러나 법원은 앞서 본 바와 같이 각 프로그램별로 소유권 취득 여부를 검토하여, 일부 프로그램에 대해서는 소유권이 B사에게 귀속되었다고 단정하기 부족하다고 판단했습니다.

둘째, 보전의 필요성 부존재 항변: B사는 “가처분 인용 시 막대한 손해가 발생하므로 보전의 필요성이 없다”고 주장했습니다. 그러나 법원은 이 사건 신청은 기본적으로 B사의 부당한 소스코드 취득이 없었던 상태로 되돌려달라는 것에 불과한 점, 가처분 인용으로 인하여 B사에게 발생하는 손해는 본질적으로 B사가 적법한 절차를 거치지 않은 채 부당한 방법으로 소스코드를 확보함으로써 발생한 것이어서 B사가 자초한 손해에 해당하는 점 등을 이유로 보전의 필요성을 인정했습니다.

보전의 필요성 인정 근거

법원은 보전의 필요성에 대해 구체적으로 다음 사항들을 고려했습니다.

• B사가 A사의 소스코드를 부당하게 취득한 이상 앞으로 이를 이용할 우려가 있음
• B사가 소스코드를 폐기하였다거나 이를 이용할 우려가 없다는 점의 소명이 부족함
• A사와 B사의 분쟁으로 인하여 급격한 매출 감소가 발생하고 있음
• 본안소송이 확정될 때까지 현 상태를 방치하면 A사에게 회복하기 어려운 손해가 발생할 우려가 있음

6. 결정의 내용: 담보금과 금지 범위

법원은 A사의 가처분 신청을 일부 인용하면서, 담보 제공과 금지 범위를 구체적으로 정했습니다.

담보금: 10억 원

법원은 담보금을 10억 원으로 결정했습니다. 담보 제공 방법은 다음 두 가지 중 선택할 수 있습니다.

• 현금 10억 원을 공탁하는 방법
• 같은 금액(10억 원)을 보험금액으로 하는 지급보증위탁계약 체결문서를 제출하는 방법

담보금이 10억 원으로 책정된 것은 가처분으로 인해 B사가 입을 수 있는 손해를 고려한 것입니다. B사는 프랜차이즈 사업을 영위하면서 다수의 자동화 기기를 운영하고 있었고, 가처분 인용으로 인해 해당 프로그램을 사용하지 못하게 되면 상당한 영업 손실이 발생할 수 있었습니다.

A사는 지급보증위탁계약을 통해 적은 비용으로 담보를 제공할 수 있었습니다.

금지 범위

법원은 쟁점 프로그램들에 대해 다음 행위를 금지했습니다.

• 보관 금지: 해당 프로그램을 저장 매체에 보관하는 행위
• 사용 금지: 해당 프로그램을 실행하거나 업무에 활용하는 행위
• 복제 금지: 해당 프로그램을 복사하는 행위
• 배포 금지: 해당 프로그램을 제3자에게 전달하는 행위
• 개작·변형 금지: 해당 프로그램을 수정하거나 파생 프로그램을 만드는 행위

간접강제 신청의 기각

A사는 위반 시 1일당 약 1억 3천만 원의 간접강제도 함께 신청했습니다. 그러나 법원은 이 부분을 받아들이지 않았습니다. 그 이유는 다음과 같습니다.

• B사가 결정을 고지받고도 이에 응하지 않을 우려가 있다는 점에 관한 소명이 부족함
• B사의 의무이행에 집행관 공시가 별도로 필요하다는 점에 관한 소명이 부족함

7. 실무적 시사점: 개발사가 주의해야 할 점

이 사건은 소프트웨어 개발사와 발주사 간의 계약 관계에서 발생할 수 있는 분쟁의 전형적인 유형을 보여줍니다.

계약서 작성 시 유의사항

공동개발계약 체결 시 소유권이 이전되는 프로그램의 범위를 명확히 특정해야 합니다. 이 사건에서 문제가 된 것은 ‘AP’라는 포괄적 용어의 해석이었습니다. 다음 사항들을 계약서에 명시하는 것이 바람직합니다.

• 별지 목록으로 구체적인 프로그램 명칭과 버전을 특정
• 미들웨어, 라이브러리, 테스트 도구 등 부속 프로그램의 소유권 귀속 명시
• 계약 이후 개발되는 프로그램의 소유권 귀속에 대한 별도 조항
• 소스코드 이관 시기, 방법, 범위에 대한 구체적 약정

소스코드 관리 체계 구축

영업비밀로 보호받으려면 비밀관리성 요건을 충족해야 합니다. 다음과 같은 관리 체계가 필요합니다.

• 소스코드 접근 권한을 개발자별로 차등 부여
• 버전 관리 시스템(Git, SVN 등)을 통한 변경 이력 추적
• 개발자 비밀유지서약서 징구
• 외부 반출 시 승인 절차 수립
• 파견 직원 노트북에 대한 보안 정책 수립

침해 발견 시 대응 방법

소스코드 유출이 의심되는 경우 다음 순서로 대응하는 것이 효과적입니다.

• 1단계: 증거 확보 (로그 분석, 파일 복사 이력 확인 등)
• 2단계: 경찰 고소 (컴퓨터 포렌식을 통한 객관적 증거 확보)
• 3단계: 영업비밀침해금지 가처분 신청 (긴급한 침해 중단)
• 4단계: 본안소송 및 손해배상청구 (최종적 권리 확정)

8. FAQ

이 사건은 소프트웨어 개발사와 발주사 간 분쟁에서 계약서 해석과 영업비밀 보호가 얼마나 중요한지를 보여주는 사례입니다. 담당 변호사팀은 복잡한 기술적 쟁점을 분석하고 공동개발계약의 범위를 엄격하게 해석하여 가처분 인용 결정을 이끌어냈습니다.

※ 본 글에서 소개된 법률 정보는 일반적인 안내 목적으로 작성되었으며, 개별 사건의 구체적인 사실관계에 따라 법적 판단이 달라질 수 있습니다. 실제 사건에 대한 대응은 반드시 변호사와 상담하시기 바랍니다.