기술유출/영업비밀분쟁 민형사소송실무

- 공격과 방어 전방위 실무경험 바탕으로 실무적 포인트 및 해결방안

디자인 등록을 하지 않았더라도 타인이 자사 디자인을 카피하면 법적 책임을 물을 수 있습니다. 물론 디자인 등록을 한 경우와 비교해 볼 때 권리행사가 어렵고 이러 저러한 제약이 많습니다. 그러나 자사 디자인의 독창성이 강하고 타사 제품에서 그 와 같은 독창적 디자인 특징을 사용하고 있다면 비록 디자인 등록을 하지 않았다고 하여도 상대방 제품의 생산 판매를 막을 수 있습니다.

1. 법률적 쟁점 및 관련 규정 

제품의 디자인 등록이 없더라도 카피 행위는 금지됩니다. 부정경쟁방지법 제 2 조 제 1 호 (자)목에서는 “타인이 제작한 상품의 형태를 모방한 상품을 양도, 대여, 전시, 수입, 수출하는 행위”를 부정경쟁행위로 규정하고 있고, 이와 같은 부정경쟁행위의 금지 및 손해배상 책임을 규정하고 있습니다. 즉 부정경쟁방지법에서 등록여부에 상관없이 새로운 상품의 모방행위를 부정경쟁행위로서 금지하고 있습니다.

여기서 가장 중요한 사항은 “모방”의 범위를 어떻게 해석할 것인가 문제입니다. 대법원에서는 형식적으로 동일한 경우 뿐만 아니라 실질적으로 동일한 경우까지 모방이라고 해석하고 있습니다.

실무적으로 매우 중요한 내용이므로 판결문의 해당 부분을 인용합니다. “모방이라 함은 타인의 상품의 형태에 의거하여 이와 실질적으로 동일한 형태의 상품을 만들어 내는 것을 말하며, 형태에 변경이 있는 경우 실질적으로 동일한 형태의 상품에 해당하는지 여부는 당해 변경의 내용, 정도, 그 착상의 난이도, 변경에 의한 형태적 효과 등을 종합적으로 고려하여 판단하여야 한다.” (대법원 2012. 3. 29. 선고 2010다20044 판결) 

통상 후발 제품은 선발 제품과 완전 동일하지 않고 차이가 있습니다. 이와 같은 차이점이 있는 제품이 부정경쟁행위로서의 모방에 해당하는지 여부가 핵심 쟁점입니다. 위 설명한 기준에 따라 실질적으로 판단해 보아야 합니다. 

2. 서울중앙지방법원의 모방 여부에 관한 판단

법원은 양 제품의 디자인상의 동일 유사점과 차이점을 구체적으로 찾아낸 후 상세하 게 비교하였습니다. 그 결과, 두 제품 사이에 “유사하다고 인정되는 부분은 그 독자 적인 형태상 특징이 드러나는 사항들로서 보는 자의 주의를 끄는 부분이라고 판단된 다. 반면, 차이점은 사소한 변경에 불과하여 후행 제품에 별도의 비용, 시간, 노력을 들여 독자적인 특징을 추가하였다고 보기 어렵고, 그 차이점으로 인해 특별한 형태 상 특징이 나타난다고 보기도 어렵다”는 이유로 실질적으로 동일한 형태의 상품이라 고 보아야 한다고 판결하였습니다. 문제가 된 디자인의 가장 특징적인 부분에서 유 사하고 차이점으로 지적된 부분은 디자인상 별로 중요하지 않다는 의미입니다. 

3. 모방자의 법적 책임 

디자인 모방에 해당하는 후행 제품을 “판매, 양도, 대여. 전시, 수입, 수출해서는 안된다”라는 금지명령과 보관 중인 제품의 반출을 금지한다는 명령을 하였습니다.

나아가, 선행 디자인 권리자는 상대방을 대상으로 손해배상 청구를 할 수 있습니다. 권리자는 손해배상으로 상대방이 판매한 제품 숫자를 파악할 수 있다면 그 숫자에 제품당 본인의 이익액을 곱한 금액, 또는 상대방이 판매로 얻은 수익액, 또는 통상의 로열티 금액 중 본인에게 가장 유리한 것을 선택하여 청구할 수 있습니다. 액수도 중요하지만 입증이 가장 쉬운 것을 선택하는 방안도 바람직합니다. 참고로, 다른 유 형의 부정경쟁행위와 달리 상품 모방 행위에 대해서는 민사책임을 물을 수 있을 뿐 형사 책임은 물을 수 없다는 특징이 있습니다.

4. 디자인 카피에 대한 소송 전략

가처분 신청 소송은 4개월 정도면 결과를 얻을 수 있는 신속한 재판입니다. 특히 시즌 상품인 경우에는 긴급한 보호의 필요성이 인정되므로 더 신속한 재판을 요청할 수 있습니다. 판매중지 등 가처분 결정은 나오는 즉시 집행할 수 있습니다. 패소한 상대방이 불복하여 항고하더라도 일단 판매중지는 즉시 집행되어야 합니다. 만약, 불복하는 중이라는 이유로 판매를 중지하지 않는 경우 1일당 수백만원에 해당하는 간접강제금을 부과할 수 있습니다. 이와 같은 사항은 판결이 확정된 후에야 집행할 수 있는 본안소송과는 상당히 다릅니다. 손해배상 청구는 가처분 소송이 아니라 본안소송만이 가능합니다. 따라서, 판매금지 가처분 소송에서 좋은 결과를 얻고 난 후 순차적으로 제기하는 것이 소송전략상 바람직합니다.

[​질문 또는 상담신청 입력하기]

Faiveley v. WABTEC (S.D. New York 2008) 분쟁 사례

1.     Licensor - Faiveley : 전동차용 브레이크 기술 보유

2.     Licensee - WABTEC : 제조 판매

3.     양사는 Faiveley의 영업비밀 정보를 이용하여 브레이크 제조 판매에 관한 장기간의 license 관계 유지

4.     Faiveley 회사 합병으로 ownership 변경 후 계약 종료

5.     WABTEC - 브레이크 시스템 독자 개발 추진

6.     독자 개발 성공 후 기존 거래처 등 Faiveley의 경쟁 거래처 납품

라이선스 계약위반 및 영업비밀 침해주장 소송제기

WABTEC 방어 논리 : 독립적 reverse engineering으로 제품 개발한 것

비밀유지약정 위반 및 영업비밀 침해가 아니라고 주장

WABTEC 개발 경과에 관한 주장 :

1.     영업비밀에 접근한 적이 없었던 내부 직원으로 개발팀 구성

2.     외부업체 리버스 엔지니어링 전문회사에 개발 의뢰

3.     리버스 엔지니어링 작업으로 개발 진행함

4.     소위 Clean Room Approach 전략으로 진행하였음

미국 1심 및 2심 법원 판결

입증책임 - 영업비밀 침해사건에 있어 침해자가 독자 개발을 주장하는 경우 입증책임이 전환되어 침해자가 독자개발사실을 입증해야 함

Discovery 결과

1.     엔지니어와 다른 리버스 엔지니어링 담당자들이 주고 받은 이메일 증거

2.     Faiveley 기술 도입에 관여한 엔지니어가 리버스 엔지니어링 프로젝트에도 관여한 사실

3.     수년간 Faiveley의 기술 제공에 기초하여 제조된 제품의 생산에 관여하면서 위 영업비밀의 내용을 지득한 1인의 엔지니어가 리버스 엔지니어링 작업 전반에 관여한 사실

4.     엔지니어가 리버스 엔지니어링 단계에서 고려되지 않은 부품의 기능에 대한 이해를 기초로 하여 리버스 엔지니어링을 통해 제작된 새 도면상 치수 및 공차 등에 대해 수정을 가했다는 점이 드러남

5.     "이 부품의 표면 처리와 직경은 제품에 적합하지 않음”

6.     “bushing hole의 공차가 지나치게 큼” 등 기존 Faiveley 기술에 대한 이해가 없으면 할 수 없는 표현 포착

Faiveley 영업비밀 및 판결   

Faiveley가 WABTEC에 제공하였던 도면에 포함된 정보인 도면상 치수, 공차, 표면처리방법, 재료의 선택 및 처리방법, 윤활특성, 생산-테스트-조립시 유의사항 등

WABTEC 제품의 특성(치수, 공차 등) – Faiveley 비밀정보 도면과 거의 일치

결론: WABTEC의 계약위반 및 영업비밀 침해인정

Clean Room Defense 성공 사례 - NEC v. Intel (N.D. Cal. 1989) 사건

NEC가 Intel의 8086 프로세서 코드를 복제하여 프로세서를 개발

NEC 대응 - 양사의 프로세서상 코드에 대한 사전 지식이 없는 엔지니어들로 구성된 외주업체에게 개발 의뢰

필요 스펙만 제공하고 코드를 독자 개발하도록 요청

독자개발 인정 – 저작권 침해 부인

Clean Room Defense 성공 사례 - NCI v. M&S (N.D. Ill. 2008) 사례

1.     licensee - M&S, licensor – NCI, 소프트웨어 라이선스

2.     licensee - M&S 유사한 소프트웨어 독자 개발 및 판매 개시

3.     licensor NCI 소송 제기: M&S의 프로그램은 저작권 침해 주장

M&S 개발 전략 - 완벽하게 인적으로 분리된 2개 팀 조직

1 팀 :  

1.     라이선스에 의해 허용되는 범위 내에서 최대한 기존 제품에 대한 기능적 분석 수행 (Dirty Room)

2.     제품 개발에 필요한 기초자료가 되는 기술정보를 수집, 정리

2 팀 :

1.     기능적 분석으로부터 도출된 정보만을 토대로 완전히 새로운 코드를 작성하여 제품을 개발함 (Clean Room)

2.     독자적인 개발을 진행한 개발팀

각 팀은 인적 완전히 분리 및 교류 차단

Clean Room 환경에서 개발되었음을 효과적으로 입증함

결론 : 독자 개발 인정 저작권 침해 부정 

[질문 또는 상담신청 입력하기]

1. 영업비밀 성립인정, 침해인정 but 침해금지기간 도과 여부 다툼

치과용 3차원 광학 스캐너 데이터 처리 프로그램 개발팀장으로 근무하다 퇴사하면서 위 프로그램 소스코드 파일을 유출한 사건입니다. 소스코드 파일은 비밀성, 경제적 가치, 비밀관리 요건을 모두 충족한 것으로 영업비밀로 인정되었고, 그 무단유출은 영업비밀 침해행위로서 형사처벌뿐만 아니라 민법상 손해배상 책임도 인정되는 상황입니다.

본 사건에서 문제된 쟁점은 영업비밀침해금지기간이 어느 시점부터 어느 시점까지 얼마나 지속되는지 여부입니다. 달리 얘기하면, 영업비밀 보호기간에 관한 다툼입니다.

2. 영업비밀 침해금지기간 및 기산점

"영업비밀 침해행위를 금지시키는 것은 침해행위자가 침해행위에 의하여 공정한 경쟁자보다 유리한 출발 내지 시간절약이라는 우월한 위치에서 부당한 이익을 취하지 못하도록 하고, 영업비밀 보유자로 하여금 그러한 침해가 없었더라면 원래 있었을 위치로 되돌아갈 수 있게 하는 데에 그 목적이 있으므로, 영업비밀 침해행위의 금지는 공정하고 자유로운 경쟁의 보장 및 인적 신뢰관계의 보호 등의 목적을 달성함에 필요한 시간적 범위 내로 제한되어야 하고, 그 범위를 정함에 있어서는 영업비밀인 기술정보의 내용과 난이도, 영업비밀 보유자의 그 정보취득에 소요된 기간과 비용, 영업비밀의 유지에 기울인 노력과 방법, 침해자들이나 다른 공정한 경쟁자가 독자적인 개발이나 역설계와 같은 합법적인 방법에 의하여 그 기술정보를 취득하는 데 필요한 시간, 침해자가 종업원인 경우에는 사용자와의 관계에서 그에 종속하여 근무하였던 기간, 담당업무나 직책, 영업비밀에의 접근 정도, 영업비밀보호에 관한 내규나 약정, 종업원이었던 자의 생계 활동 및 직업선택의 자유와 영업활동의 자유, 지식재산권의 일종으로서 존속기간이 정해져 있는 특허권 등의 보호기간과의 비교, 그 밖에 심문에 나타난 당사자의 인적 ∙ 물적 시설 등을 고려하여 합리적으로 결정함으로써, 기업활동에 있어서의 공정한 경쟁의 보장과 개인의 영업의 자유가 적절히 조화되도록 하여야 할 것이다.

또한, 영업비밀침해금지의무를 부과함에 있어서 영업비밀의 해당 여부 및 영업비밀의 존속기간은 영업비밀을 취급한 근로자가 지득한 영업비밀을 기준으로 평가하여야 하는데, 부정경쟁방지법 제10조에서 영업비밀 침해행위의 금지 또는 예방을 위한 조치를 취할 수 있다고 규정하고 있으므로 근로자가 회사에서 퇴직하지는 않았지만 전직을 준비하고 있는 등으로 영업비밀을 침해할 우려가 있어서 이를 방지하기 위한 예방적 조치로서 미리 영업비밀침해금지를 구하는 경우에는 근로자가 그 영업비밀을 취급하던 업무에서 실제로 이탈한 시점을 기준으로 영업비밀침해금지기간을 산정할 수 있을 것이며, 영업비밀이 존속하는 기간 동안에는 영업비밀의 침해금지를 구할 수 있는 것이므로, 근로자가 퇴직한 이후에 영업비밀침해금지를 구하는 경우에도 근로자가 영업비밀 취급업무에서 이탈한 시점을 기준으로 영업비밀침해금지기간을 산정함이 타당하다(대법원 1998. 2. 13. 선고 97다24528 판결, 2003. 7. 16.자 2002마4380 결정 참조)."

3. 구체적 사안에 적용

"위 법리에 기초하여 살피건대, 기록에 의하여 소명되는 사정(독자적 개발기간이 2~6개월 정도 단축되었을 것이라는 개발자 의견, 9개월 이내 독자 개발할 수 있다는 교수 2명의 의견서, 개발자 1명 내지 2명이 1년 이내에 개발한 실제 사례 소개자료, 전직금지약정기간이 2년으로 설정된 사정, 퇴직자가 개발팀장으로서 퇴직 후 독자개발에 상당한 시간이 걸리지 않을 것으로 보이는 점) 등을 종합하여 보면, 이 사건 각 파일에 대한 영업비밀침해금지기간은 이 사건 각 파일을 유출한 채무자 C이 채권자 회사의 3차원 스캐너 프로그램 연구개발업무에서 이탈한 시점인 2011. 8. 5.경으로부터 6개월 내지 2년 정도라고 볼 여지가 있다."

법원은 구체적으로 확정할 수는 없지만 그 영업비밀침해금지기간을 문제된 프로그램 연구개발업무에서 이탈한 시점부터 최장 2년까지로 판단하였습니다.

4. 영업비밀침해금지기간 도과한 경우 영업비밀사용금지청구 기각

"비록 영업비밀에 해당되고, 영업비밀 침해행위에 해당한다고 하더라도, 이 사건 결정일 현재 이 사건 각 파일에 대한 영업비밀침해금지기간은 이미 경과하였다고 볼 수 있다. 따라서 채권자 회사가 채무자들을 상대로 손해배상을 구하는 것은 별론으로 하고, 그 영업비밀 침해행위의 금지를 구할 수는 없다."

영업비밀침해금지기간 2년이 경과한 후에는 과거에 범한 영업비밀침해행위로 인한 손해배상을 청구할 수 있을 뿐, 그 기간 경과 후 영업비밀의 사용행위 또는 그것을 활용한 제품의 제조, 판매금지 등을 청구할 수는 없다고 판결한 것입니다.

[질문 또는 상담신청 입력하기]

영업비밀 침해행위를 금지시키는 것은 침해행위자가 그러한 침해행위에 의하여 공정한 경쟁자보다 우월한 위치에서 부당하게 이익을 취하지 못하도록 하고 영업비밀 보유자로 하여금 그러한 침해가 없었더라면 원래 있었을 위치로 되돌아갈 수 있게 하는 데에 그 목적이 있다.

영업비밀 침해행위의 금지는 이러한 목적을 달성하기 위해 영업비밀 보호기간의 범위 내에서 이루어져야 한다.

영업비밀 보호기간은 영업비밀인 기술정보의 내용과 난이도, 침해행위자나 다른 공정한 경쟁자가 독자적인 개발이나 역설계와 같은 합법적인 방법으로 영업비밀을 취득할 수 있었는지 여부, 영업비밀 보유자의 기술정보 취득에 걸린 시간, 관련 기술의 발전 속도, 침해행위자의 인적․물적 시설, 종업원이었던 자의 직업선택의 자유와 영업활동의 자유 등을 종합적으로 고려하여 정해야 한다(대법원 1996. 12. 23. 선고 96다16605 판결, 대법원 1998. 2. 13. 선고 97다24528 판결 등 참조).

사실심의 심리결과 영업비밀 보호기간이 남아 있으면 남은 기간 동안 침해금지청구권이 인정되고, 이미 영업비밀 보호기간이 지나면 침해금지청구권은 소멸한다.

다만, 침해행위자나 다른 공정한 경쟁자가 독자적인 개발이나 역설계와 같은 합법적인 방법으로 영업비밀을 취득하거나 영업비밀과 동일한 기술을 개발할 가능성이 인정되지 않는 등으로 영업비밀 보호기간의 종기를 확정할 수 없는 경우에는 침해행위 금지의 기간을 정하지 않을 수 있다. 이처럼 금지기간을 정하지 않는다고 해서 영구히 금지하는 것은 아니고, 금지명령을 받은 당사자는 나중에 영업비밀 보호기간이 지났다는 사정을 주장․증명하여 가처분 이의나 취소, 청구이의의 소 등을 통해 다툴 수 있다.

[질문 또는 상담신청 입력하기]

위젯 개발사간의 영업비밀침해 분쟁 사례인 서울중앙지방법원 2013. 11. 14. 선고 2010가합53704 사건에 대한 글입니다. 사안 가운데 “예외처리 소스코드”의 영업비밀성에 대한 법원의 판단 부분을 살펴봅니다.

1. 배경사실

배경사실을 간단히 다시 보면, 원고 X회사는 컨텐츠 및 서비스 딜리버리 플랫폼 개발업체로서, KT등 업체로부터 위젯서비스 플랫폼 개발 용역을 수주한 바 있습니다. 한편 피고 B 등은 X회사 및 그 외주업체에서 영업 및 개발직으로 근무하다가 퇴사하면서 Java로 작성된 예외처리 소스코드 등 기술정보를 가지고 나와 Y회사를 창업하였습니다. 이후 Y회사는 KT로부터 위젯서비스 플랫폼 개발 용역을 수주하고 개발을 진행하였습니다.

그런데 X회사에서 사용하였던 예외처리 소스코드는 인터넷에 공개된 코드를 정리한 것이었고, 이에 피고측은 소송에서 위 소스코드가 이미 공지된 코드에 불과하여 영업비밀이 될 수 없다고 주장하였습니다.

2. 법원의 판단

법원은,

가. 비록 이 사건 예외처리 소스코드가 공개된 인터넷 사이트에서 소개하고 있는 코드를 이용한 것이기는 하나, 이를 그대로 이용한 것이 아니라 단순화 및 정리하는 과정에서 변형이 되었다는 점(법원은 X, Y사의 예외처리 소스코드에 나타나는 getBrief 함수는 공개된 코드중에는 없다는 점을 예로 들고 있습니다)

나. 감정한 저작권위원회도 양 코드의 구성 및 구현에 차이가 있다고 판단하였다는 점

다. 공개된 소스코드를 이용목적에 맞게 수정, 조합하여 시스템에 맞게 구현하는 것이 기술력의 중요한 부분이라는 점

등을 고려하면, 이 사건 소스코드는 위젯 서비스 플랫폼 개발업계에 공연히 알려져 있지 않고, 그 취득을 위해서는 적지않은 비용이나 노력이 필요하다고 볼 수 있다고 판시하였습니다. 이에 따라 법원은 위 소스코드에 비공지성 및 경제적 유용성이 있어 영업비밀이 될 수 있다고 본 것입니다.

3. 검토

공지된 오픈소스를 개작한 프로그램도 전체로서 영업비밀의 요건을 갖추면 영업비밀로 인정할 수 있다는 판결은 여러 차례 있었습니다. 오픈소스 커뮤니티에서 화제가 되었던 ETUND 판결(서울중앙지방법원 2006. 11. 1. 선고 2005노3002 판결) 및 반도체 제조장비 구동 소프트웨어에 대한 영업비밀 침해사건에 대한 서울중앙지방법원 2013. 12. 6. 선고 2011가합45458 판결 등에서 같은 취지의 판시를 찾아볼 수 있습니다.

특히 위 반도체 제조장비 구동 소프트웨어에 관한 판결은 이 사건 판결과 마찬가지로 “공개된 소스코드를 수정, 조합하여 이용목적에 맞게 구현하는 것도 기술력의 중요한 부분”이라는 판시를 하고 있는데, 이에 비추어 수정, 조합을 누구나 매우 쉽게 할 수 있는 것이라는 점을 보인다면 그 기술정보의 경제적 가치가 부정되거나 또는 낮게 인정되도록 할 가능성도 열려있다고 생각됩니다.

한편 법원이 예로 든 getBrief() 메소드는 오류의 내용이 무엇인지 그 요약 정보를 가져오는 기능을 하는 것에 불과하며, 이를 통해 무언가 중요하고 가치있는 다른 서비스를 구현할 수 있는 것이 아닙니다. 실질적으로 없어도 그만인 (또한 아무나 할 수 있는) 코드의 부가였을 가능성이 높습니다. 이에 이를 예로 든 것은 부적절한 것 같습니다.

반도체, 통신, 제약 등 대부분의 기술사건과 마찬가지로 소프트웨어 관련 소송은 소프트웨어를 이해할 수 있고 관련 경험이 풍부한 법률가의 도움을 받아 수행하는 것이 바람직합니다. 프로그래밍에 익숙하지 않은 재판부를 적절한 공격과 방어를 통해 설득하기 위해서는 코드를 하나하나 뜯어보고 분석하는 작업이 요구됩니다. 이러한 분석작업을 거쳐 정밀한 주장을 하는 경우 소송에서 보다 바람직한 결과를 얻어낼 수도 있을 것입니다.

[질문 또는 상담신청 입력하기]

1. 배경사실

원고 X회사는 컨텐츠 및 서비스 딜리버리 플랫폼 개발업체입니다. 피고 B 등은 X회사 및 그 외주업체에서 영업 및 개발직으로 근무하다가 퇴사 후 피고 Y회사를 설립하거나 Y회사로 전직한 사람들입니다.

컨텐츠 및 서비스 딜리버리 플랫폼 개발업체인 원고 X회사는, 2008. 4.에 KT로부터 위젯서비스 서버시스템 구축 용역을 수주, 수억원을 받고 “SoIP 위젯서비스 플랫폼” 및 “SoIP 위젯 컨텐츠 및 CP 연동기능” 개발 계약을 체결한 뒤 개발 및 기술지원 등의 용역을 제공하였습니다. 이 과정에서 X회사는 KT와, 개발계약에 따라 생성된 결과물의 소유권은 KT에 귀속한다는 약정을 하였습니다.

그런데 피고 B 등은 X회사에서 영업 및 개발직으로 근무하다가 퇴사하면서, X회사가 KT에 사업제안을 할 때 사용한 자료인 “DCD Architecture 정의서” 및 예외처리 소스코드 등 기술정보를 가지고 나왔고, 이후 Y회사를 설립한 뒤 2009. 7. KT로부터 “SoIP 스마트그린 위젯 개발” 용역을 수주, 수억원을 받고 위젯개발 용역 계약을 체결하였습니다. 용역 수주 및 개발과정에서 B 등은 X회사에서 가지고 나온 위 기술정보를 사용하였습니다.

그러자 X회사가 Y회사 및 B 등을 상대로 형사고소 및 민사소송을 제기하였고, 형사재판 1심에서는 B 등의 영업비밀 침해혐의를 인정하여 유죄가 선고되었습니다. 이하에서는 민사소송 1심 판결 가운데 위 아키텍처 정의서의 영업비밀성에 관한 법원의 판단을 살펴봅니다.  

2. 법원의 판단

먼저 피고 B등은 아키텍처 정의서가 위 계약상 “결과물”에 속하여 그 소유권은 KT가 갖게 되므로 X회의 영업비밀이 될 수 없다고 주장하였습니다. 그러나 법원은, 아키텍처 정의서는 X회사가 KT에 개발계약 체결을 제안하는 문서로서, 개발계약의 이행에 착수하기 전에 X회사 스스로 작성한 것이고, 이를 위젯 서비스 플랫폼과 같이 개발계약에 의해 생성된 “결과물”로 보기는 어렵다는 점 등을 들어 아키텍처 정의서에 대한 소유권은 KT가 아니라 X회사가 갖는 것이라 판시하였습니다.

나아가 B 등은 정의서가 대외적으로 기술을 설명하기 위해 작성된 것으로 비밀정보가 아니어서 영업비밀성이 없다고 주장하였습니다. 그러나 법원은, (1) 정의서는 플랫폼 개발에 필요한 설계도면의 성격을 가지며 X회사가 위젯 플랫폼 개발과정에서 시행착오를 거쳐 얻은 성과와 노하우가 포함되어 있고, (2) 위젯서비스 플랫폼을 개발하는데 필요한 각각의 기술이 공지되었거나 상용화되어 있다 하더라도, 각각의 기술을 포함하여 효율성이 높은 위젯서비스 플랫폼을 개발할 수 있는 X회사의 구체적 기술정보까지 공지되었다고 볼 수는 없다는 이유를 들어 영업비밀성을 인정하였습니다.

3. 실무적 포인트

가. 아키텍처 정의서와 같은 전자문서에 “소유권”을 논하는 것이 과연 적절한지에 대해서는 학계의 견해가 나뉘어 있고 판례도 없는 상황입니다. 다만 개발 결과물의 소유권은 일방에 귀속한다는 위 약정의 취지를 실무적으로 살펴보면, 개발과정에서 작성된 문서 및 완성 또는 미완성 상태의 프로그램을 발주자가 아닌 타 업체에 납품하는 등 목적으로 사용하지 않을 의무를 수주 업체에 부과하는 것으로 볼 수 있습니다.

따라서 발주자와 수주자간의 계약이 최종적으로 체결되지 않은 경우와 달리, 계약이 체결되어 개발용역이 진행되었다면, 사업제안서(아키텍처 정의서 포함) 및 그 연장선상에 있는 기획서 등의 개발문서가 모두 발주자인 KT의 “소유”가 된다는 것이 당사자의 의사가 아니었을까 하는 생각이 듭니다.

나. 한편, 영업비밀로 보호되는 비밀정보는 전자문서인 아키텍처 정의서의 일부분입니다. 참고로 아키텍처 정의서가 발주자에게 전달되는 상황을 보면, IT 업계에서는 발주자가 방대한 양의 사업제안요청서를 통해 과업내용, 요구사항, 계약조건, 평가요소 및 방법 등 사항을 미리 공개하는 것이 일반적이며, 사업을 통해 구축하고자 하는 목표시스템의 개략적인 HW/SW 등의 구성도 또한 사업제안요청서에 포함하여 제시합니다.

이에 따라 사업을 수주하고자 하는 업체는 사업제안요청서에 규정된 사항에 맞추어 시스템 아키텍처 정의서 등을 포함한 사업제안서를 제출하는데, 이때 타사와 차별화된 아키텍처 및 그 효용을 어필하여 사업 수주를 도모하게 됩니다. 그런데 그 차별 포인트는, 일반적으로 알려져 있으며 흔히 사용되는 플랫폼 아키텍처의 일부분을 수정한 것이었을 가능성이 높습니다. 따라서 아키텍처 정의서 가운데서도 핵심이 되는 그 일부분이 어느 부분인지에 대한 특정이 필요할 것입니다. 사안에서는 재판부가 이러한 특정을 요구하지는 않은 것으로 보이고, 피고의 소송대리인도 이 부분을 다투지는 않은 것 같습니다. 하지만 일반적으로 재판실무에 있어서는 영업비밀의 특정여부가 중요한 방어 포인트라는 점을 유의해야 합니다.

다. 물론 공개된 정보만 조합한 자료도 영업비밀이 될 수는 있습니다. 그러나 이 경우 그 경제적 가치가 상대적으로 더 낮게 평가될 수 있고 재판부의 재량에 의한 배상액 산정에도 영향을 줄 수 있으므로, 침해자 입장에서는 영업비밀이라 주장된 자료를 최대한 자세하게 분석하여 자료의 각 부분이 공개된 것임을 보여야 합니다. 또한 나아가 공개된 자료의 조합도 업계 종사자에게 매우 쉬운 일이라는 점을 부각하여야 할 것입니다. 

[질문 또는 상담신청 입력하기]

저작권은 아이디어가 아닌 표현만을 보호하므로 소프트웨어의 경우에는 소스코드를 보호하지만 해당 소스코드의 기능을 보호하지는 않습니다. 원칙적으로 기능에 관한 아이디어는 영업비밀 또는 특허로 보호할 수 있습니다.

저작권 침해는 저작권자의 동의 없이 소스코드 등 저작물을 무단으로 사용하는 경우에 발생합니다. 프로그램저작권 침해소송에서는 문언적 복제(literal copying)가 인정되는 경우는 많지 않고 대부분 비문언적 복제(non-literal copying) 여부가 쟁점입니다.

저작권의 보호를 받는 표현이란 소스코드와 같은 문언 요소(literal elements)와 프로그램 아키텍처, 구조, 시퀀스 및 구성, 동작 모듈, 컴퓨터 사용자 인터페이스와 같은 비문언 요소(non-literal elements)를 포함됩니다. 그래서 소프트웨어 저작 권 침해는 단순히 코드를 똑같이 복제하는 문언적 침해(literal infringement)의 경우에만 문제가 되는 것이 아니라 비문언적 침해(non-literal infringement)가 중요한 침해 행위가 될 수 있습니다.

문언적 복제는 창작성이 있는 타인의 소스코드의 상당한 분량을 그대로 복제할 경 우에 발생합니다. 저작권 성립을 위한 창작성은 예술작품과 같은 높은 수준을 요구하지 않으므로, 통상 소스코드는 창작성이 인정됩니다. 한편, 동일하게 복제하지 않고 아래 사례와 같이 주석을 변경하고 삭제하거나 변수 및 함수의 이름을 변경하는 정도의 피상적인 변경을 가하더라도 문언적 복제로 인정될 수 있습니다.

그런데 타사의 소스코드를 확보하고 저작권 침해를 피하기 위하여 소스코드를 그대로 복제하여 사용하기보다는 함수 및 변수 이름을 변경하고 함수 내부의 명령의 순서도 변경하여, 타인의 코드를 복제한 것이 아니라 독자적으로 개발하였다고 볼 수 있을 정도로 변경작업을 한 경우가 많습니다.

위와 같이 의도적 변경을 하더라도 타인의 코드에 있던 주석 등을 처리하지 못하여 현재 코드에는 없고 타인의 코드에 있던 변수, 함수 등의 설명이 남아 있는 경우라면 이는 타인의 코드를 보고 복제하였다는 유력한 증거가 될 수 있습니다. 또한 구조체와 함수의 이름을 변경하고 for loop, print 구문 등을 이용하여 코드를 일부 수정하였지만, 구조체와 함수의 변경전 명칭을 그대로 둔 경우 이 또한 복제의 유력한 증거가 될 수 있습니다.

​

위와 같은 문언적 복제를 피하기 위하여 소스코드를 새로 코딩하는 경우에도 타인의 소프트웨어가 가지고 있던 코드의 구조(structure), 시퀀스(sequence), 조직(organization)의 SSO는 그대로 사용하는 경우가 많습니다. 이러한 SSO의 복제는 비문언적 복제로 저작권 침해에 해당합니다. 다만, SSO는 실제 소스코드에 대한 것으로 한정되고, 기능상에 대한 부분까지 확대되지는 않습니다. 아래 그림은 Video Stack을 추가하였더라도 유사한 SSO를 가진 것으로 비문언적 복제로 판단 받을 수 있습니다.

위와 같이 소프트웨어 업체가 경쟁업체 또는 동종업체에서 소프트웨어 엔지니어를 영입하는 경우나 타사 제품에 대한 경쟁제품을 개발하기 위하여 타사 제품의 리버스엔지니어링을 통하여 분석하는 경우, 문언적 복제 이외에도 비문언적 복제 행위로 판단될 소지가 있다는 점을 유념해야 할 것입니다.

[질문 또는 상담신청 입력하기]

소프트웨어 프로그램은 통상 2진파일(binary file) 포맷인 실행파일 형태로 배포되어 소스코드를 확인할 수 없기에 저작권 침해 여부를 확인하는 것이 매우 어렵습니다. 소스코드의 확보할 목적으로 침해혐의자를 고소하여 형사절차를 통해 압수, 수색을 시도하기도 합니다.

소프트웨어 프로그램 저작권 침해 사건은 소스코드의 유출이 발단이 되는 경우가 많습니다. 이때 소스코드를 유출한 직원은 경쟁업체를 설립하고 유출된 소스코드를 기반으로 개발하여 배포, 판매로 나아가게 되므로, 결국 소송에서는 프로그램 저작권 침해뿐만 아니라 경업 및 전직금지, 영업비밀 침해 등 쟁점으로 대두됩니다. 수사절차는 대부분 피해자가 저작권 침해죄, 영업비밀 침해죄 혐의 등으로 침해 혐의자를 고소하는 것에서 시작됩니다. 여기서 영업비밀유출, 저작권침해 등에 관한 범죄혐의가 어느 정도 소명되어야 압수수색을 시도해 볼 수 있습니다. 소명은 증명에는 이르지 못한 정도이지만 적어도 그럴 개연성이 있다는 점을 보여주는 것입니다. 소스코드 없이도 어떻게 침해하였을 개연성을 보일 수 있는지 어려운 과제입니다.

1. 저작권 침해요건

저작권침해는 원칙적으로 (1) 침해자가 피해자의 저작물을 보고 베낀 사실(의거성)과 (2) 침해자의 결과물이 피해자의 저작물과 실질적으로 유사한 사실(실질적 유사성)이 인정되어야 합니다. 소프트웨어 프로그램의 경우도 침해자가 피해자의 컴퓨터프로그램의 소스코드에 접근하였다는 사실과 침해자의 컴퓨터프로그램이 피해자의 것과 유사하다는 사실을 보여야만 합니다. 실제 소송에서 주로 쟁점이 되는 것은 실질적 유사성의 문제입니다.

2. 실질적 유사성 판단   

통상 비교대상 소프트웨어 프로그램들의 기능을 추상화하여 그 유사성을 살피고, 다음으로 컴퓨터프로그램을 둘러싼 주변 요소들 중 사상의 영역과 표현을 위해 사용되는 수단적 요소들을 제거하여 여과한 다음, 남는 부분들을 비교, 검토하여 유사성 여부를 가리는 과정을 거쳐 판단합니다.

또한 추상화와 여과 과정을 거친 후에 남는 구체적 표현(소스코드 혹은 목적코드)을 개별적으로 비교하는 외에도, 명령과 입력에 따라 개별 파일을 호출하는 방식의 유사도, 모듈 사이의 기능적 분배의 유사도, 분석 결과를 수행하기 위한 논리적 구조 계통 역시 검토하게 되고, 그와 같은 구조와 개별 파일들의 상관관계에 따른 전체적인 저작물 제작에 어느 정도의 노력과 시간, 그리고 비용이 투입되는지 여부도 함께 고려됩니다. 다만 이와 같은 검토 과정은 사안에 따라 유동적으로 사용됩니다.

3. 소스코드를 확보할 수 없는 경우의 유사성 소명 방법

소스코드를 확보할 수 없는 사건 초기에 실질적 유사성을 소명하기 위해서는 상대방의 제품에서 이진파일 상태인 목적코드, DLL, 실행파일 등을 추출하여 비교할 수 밖에 없습니다. 이 경우에는 역어셈블 또는 역컴파일을 통해서 어셈블리어 수준 또는 소스코드 수준에서 비교를 해야 합니다만, 디버깅 정보가 모두 제거된 상태이므로 어셈블리 수준에서는 변수와 함수 명칭 등이 모두 메모리상의 주소(숫자)로 변환되어 있고, 소스코드 수준으로 변환하여도 위 명칭 등이 모두 임의로 변경되어 있어 비교가 쉽지 않습니다.

이에 전체 구조의 유사성을 살피기 위해서는 함수 호출관계 차트를 그려서 이를 분석, 피해자의 소스코드와 비교하여 함수 간의 관계를 살피는 작업을 거치게 됩니다. 이것을 기준으로 유사한 함수 내의 기능과 내부 코드를 비교하여 유사도를 확인합니다. 여기서 먼저 분석할 함수로는 전체 컴퓨터프로그램에서 중요한 기능을 차지하고 새롭게 창작한 부분에 포함되는 것들을 선택하여야 할 것입니다.

이렇게 어느 정도 유사도가 확인되면, 이를 소명 자료로 만들어 법원 또는 검찰에 제출하여, 압수수색을 도모하거나 감정신청으로 나아갈 수 있게 됩니다. 소프트웨어 저작권 침해 또는 영업비밀 침해 사건에서 피해를 입은 회사 또는 개발자 등은 위와 같이 침해 사실의 소명이 필요하다는 점을 유념해야 합니다.

[질문 또는 상담신청 입력하기]