칼럼 및 연구자료

소프트웨어 라이선스 사용 한도를 우회하는 프로그램, 저작권 침해가 될 수 있을까?

동시사용(concurrent) 방식으로 판매되는 소프트웨어의 라이선스 한도를 기술적으로 우회하여 약정한 최대 동시사용자 수보다 많이 사용하도록 하는 경우, 저작권법상 ‘일시적 복제권’ 침해가 문제될 수 있습니다. 대법원은 동시사용 방식의 소프트웨어에서 라이선스 한도를 우회하는 보조 프로그램으로 인해 최대 동시사용자 수를 넘어서는 복제가 이루어진 사안에서, 해당 일시적 복제에 독립한 경제적 가치가 있다고 보아 저작권 침해를 인정했습니다. 오늘은 서울중앙지방법원 2011가합125231 판결, 서울고등법원 2014나27205 판결을 거쳐 대법원 2016다20916 판결로 확정된 사건을 중심으로 소프트웨어 라이선스와 일시적 복제의 관계, 그리고 소프트웨어 라이선스 거래에서 유의할 점을 살펴보겠습니다.   어떤 사건이었나요? 이 사건에서는 사용하지 않는 소프트웨어를 종료하지 않은 채 비활성화하고, 해당 프로그램에 할당된 라이선스만 서버에 반환시키는 방식이 문제되었습니다. 설계용 소프트웨어인 카티아(CATIA)는 ‘동시사용(concurrent)’ 방식으로 라이선스가 부여됩니다. 라이선스 서버가 접속 순서대로 라이선스를 할당하고, 구매한 수량이 모두 소진되면 누군가 라이선스를 반납할 때까지 다른 사용자는 기다려야 하는 구조입니다. 그런데 한 판매대리점이 “라이선스를 추가로 확보해 준다”는 보조 소프트웨어를 개발하여 판매했습니다. 이 프로그램은 실제로 사용되지 않고 있는 카티아를 종료시키지 않고 비활성화만 한 채 라이선스를 서버에 반환시키고, 그렇게 반환된 라이선스를 다른 사용자가 새로 할당받도록 했습니다. 문제는 비활성화된 카티아가 완전히 종료된 것이 아니라 RAM에 그대로 남아 있었다는 점입니다. 즉, 프로그램은 RAM에 계속 적재된 상태로 남아 있지만 라이선스 서버에는 해당 라이선스가 반환되고, 반환된 라이선스를 다른 사용자가 다시 할당받는 구조​였습니다. 이에 따라 약정한 최대 동시사용자 수를 넘어서는 복제가 이루어질 수 있었습니다. 판매대리점은 이를 “약 20%의 라이선스를 더 구매한 것과 같은 효과”라고 홍보하기도 했습니다.   RAM에 프로그램이 남아 있는 것도 저작권법상 복제일까요? 프로그램을 실행하는 과정에서 RAM에 프로그램이 적재되는 경우에도 저작권법상 ‘일시적 복제’에 해당할 수 있습니다. 저작권법 제2조 제22호는 ‘복제’의 개념에 일시적 복제를 포함하고 있습니다. 따라서 프로그램을 영구적으로 저장하거나 별도의 파일로 복사하는 경우뿐 아니라 프로그램을 구동하면서 RAM에 일시적으로 적재하는 경우에도 복제가 문제될 수 있습니다. 다만 일시적 복제가 모두 저작권 침해에 해당하는 것은 아닙니다. 저작권법 제35조의2는 컴퓨터에서 저작물을 이용하는 과정에서 원활하고 효율적인 정보처리를 위하여 필요하다고 인정되는 범위에서는 일시적 복제를 허용하고 있습니다. 결국 이 사건에서는 비활성화된 카티아가 종료되지 않은 채 RAM에 남아 있는 것이 단순히 프로그램의 정보처리를 위해 필요한 복제인지, 아니면 그 범위를 넘어서는 복제인지가 중요한 쟁점이 되었습니다.   쟁점이 된 소프트웨어 라이선스 조항 일시적 복제가 허용되는 범위와 함께, 소프트웨어 라이선스에서 어떠한 범위까지 이용을 허락했는지도 중요한 쟁점이 되었습니다. 이 사건의 라이선스 계약에는 다음과 같은 내용이 포함되어 있었습니다. “본 계약에 명시된 경우를 제외하고, 명시적이거나 묵시적인 어떠한 권리나 라이선스도 최종 사용자에게 허용되지 아니한다.” ►   계약서에 명시되지 않은 이용, 즉 최대 수량을 초과하는 복제는 이용허락의 범위 밖이라는 근거가 되는 조항입니다. 이용허락의 범위에는 단순한 ‘사용(use)’뿐 아니라 ‘액세스(access)’​도 포함되어 있었습니다. 프로그램을 구동하여 액세스하면 RAM에 일시적 복제가 이루어지고, 이러한 복제 역시 약정한 최대 수량의 범위에서 허용되는지가 쟁점이 되었습니다. ► 해당 조항과 관련된 법률로는 복제의 개념에 일시적 복제를 포함시킨 저작권법 제2조 제22호와, 일시적 복제를 일정한 범위에서 면책하는 같은 법 제35조의2가 문제 되었습니다.   왜 단순한 라이선스 관리가 아니라 저작권 침해가 문제됐을까요? 핵심은 라이선스를 반환하는 기능 자체보다, 그 결과 약정한 최대 동시사용자 수를 넘어서는 프로그램의 복제가 가능해졌다는 점입니다. 항소심은 비활성화된 카티아를 종료하지 않고 RAM에 남겨 두는 복제가 이용자의 단순한 편의를 위한 것일 뿐, 원활하고 효율적인 정보처리를 위해 불가피한 것은 아니라고 보았습니다. 특히 보조 프로그램을 사용하면 기존 프로그램은 RAM에 그대로 남아 있으면서 해당 라이선스만 반환되고, 반환된 라이선스를 다른 사용자가 새롭게 할당받을 수 있었습니다. 그 결과 하나의 라이선스를 반환한 이후에도 기존 프로그램의 복제 상태가 유지되면서 다른 프로그램이 새롭게 실행될 수 있었고, 사실상 약정한 최대 라이선스 사용 한도보다 많은 프로그램을 사용할 수 있는 효과가 발생했습니다. 대법원은 이러한 구조에서 “일시적 복제 자체가 독립한 경제적 가치를 가지는 경우”는 저작권법 제35조의2에 따른 면책 범위에서 제외되어야 한다고 판단했습니다.   법원의 판단과 결론 대법원은 동시사용 라이선스에서 최대 라이선스 사용 한도가 유상 거래의 핵심이라는 점을 고려하여, 이 사건의 일시적 복제가 독립한 경제적 가치를 가진다고 판단했습니다. 동시사용 방식에서는 구매한 라이선스 사용 한도에 따라 동시에 프로그램을 사용할 수 있는 범위가 정해집니다. 그런데 이 사건의 보조 프로그램을 이용하면 추가 라이선스를 구매하지 않고도 기존보다 많은 프로그램을 이용할 수 있는 효과가 발생했습니다. 이는 라이선스 판매량에도 영향을 줄 수 있는 구조였습니다. 이에 대법원은 해당 일시적 복제가 단순한 정보처리를 위해 필요한 범위를 넘어 독립한 경제적 가치를 가진다고 보았고, 저작권법 제35조의2에 따라 면책되는 일시적 복제에 해당하지 않는다고 판단했습니다. 결국 이러한 행위는 저작권자의 일시적 복제권을 침해하는 행위로 판단되었고, 이 결론은 1심부터 항소심, 대법원까지 유지되었습니다. 또한 이러한 이용을 가능하게 하는 보조 소프트웨어를 개발하여 판매한 판매대리점에 대해서는 최종 사용자의 저작권 침해를 방조한 책임이 인정되었습니다.   소프트웨어를 공급하거나 사용하는 기업은 무엇을 확인해야 할까요? 이 판결은 소프트웨어 라이선스의 한도를 기술적으로 우회하는 도구가 저작권, 특히 일시적 복제권 침해로 이어질 수 있음을 보여주는 대표적인 사례입니다. 라이선스를 제공하는 벤더로서는 이용허락의 범위에 ‘사용(use)’과 ‘액세스(access)’​를 함께 규정하고, 명시되지 않은 권리는 허용되지 않는다는 내용과 최대 라이선스 사용 한도를 소프트웨어 라이선스에 명확하게 정해 둘 필요가 있습니다. 반대로 라이선스를 이용하는 기업이나 개발사도 소프트웨어의 이용 효율을 높이기 위한 프로그램이라 하더라도 실제 작동 방식이 라이선스 통제를 우회하여 약정한 최대 사용량을 넘어서는 결과를 만드는지 살펴봐야 합니다. 정품 소프트웨어를 구매했다는 사실만으로 이용허락의 범위를 넘어서는 모든 복제가 허용되는 것은 아닙니다. 해당 복제가 원활하고 효율적인 정보처리를 위해 필요한 것인지, 아니면 단순한 편의를 넘어 별도의 경제적 가치를 갖는 이용인지에 따라 저작권 침해 여부가 달라질 수 있습니다. 특히 이 사건처럼 프로그램이 종료되는지, 비활성화된 이후 RAM에 어떠한 상태로 남아 있는지, 라이선스 서버가 언제 라이선스를 반환하고 다른 사용자에게 다시 할당하는지 등 소프트웨어의 실제 기술적 작동방식이 법률 판단과 직접 연결될 수 있습니다. 소프트웨어 라이선스 분쟁은 계약서의 문언만으로 판단하기 어려운 경우가 있습니다. 소프트웨어가 실제로 어떠한 방식으로 실행되고 라이선스가 관리되는지를 파악한 뒤, 이를 계약상 이용허락의 범위와 저작권법상 복제의 문제로 함께 검토하는 것이 중요합니다.  법무법인 비트는 소프트웨어 라이선스(EULA)의 설계와 검토, 그리고 저작권 침해와 라이선스 초과사용을 둘러싼 분쟁을 다수 자문해 온 전문성​을 갖추고 있습니다. 라이선스 정책을 설계하는 단계부터 침해가 발생했을 때의 대응과 방어 소송까지, 소프트웨어의 기술적 이용구조와 법률상 이용허락 범위를 함께 검토하여 자문을 제공합니다.   관련 법령 및 판례 -「저작권법」 제2조 제22호, 제35조의2 - 서울중앙지방법원 2011가합125231 판결 - 서울고등법원 2014나27205 판결 - 대법원 2016다20916 판결  

금융자산 토큰화와 토큰증권 제도의 변화

최근 금융시장에서는 주식, 채권, 펀드 등 다양한 금융자산을 디지털 형태로 발행·거래하는 ‘토큰화(Tokenization)’에 대한 논의가 확대되고 있습니다. 과거에는 미술품이나 부동산 등 특정 자산을 여러 투자자가 나누어 투자하는 조각투자를 중심으로 토큰화가 논의되었다면, 최근에는 기존 금융상품의 발행과 거래 구조에도 분산원장 기술을 적용하려는 움직임이 본격화되고 있습니다. 금융위원회는 2026년 9월 「토큰증권 정책방향」을 발표하고, 조각투자뿐만 아니라 주식·채권·펀드 등 기존 증권의 토큰화를 단계적으로 추진한다는 방향을 제시하였습니다. 토큰화와 토큰증권 토큰화는 자산이나 권리를 디지털 토큰의 형태로 구현하고, 그 발행·거래 및 권리관계에 관한 정보를 디지털 방식으로 관리하는 것을 의미합니다. 이 과정에서는 블록체인이나 분산원장 기술이 활용될 수 있습니다. 다만 토큰화가 이루어졌다는 사실만으로 해당 자산의 법적 성격이 달라지는 것은 아닙니다. 토큰이 어떠한 자산이나 권리를 나타내는지, 보유자에게 어떠한 권리가 부여되는지에 따라 적용되는 법률과 규제도 달라질 수 있습니다. 특히 토큰증권(Security Token)은 새로운 종류의 증권이라기보다 분산원장을 이용하여 발행·유통되는 증권의 형태​로 이해할 수 있습니다. 금융위원회 역시 토큰증권을 주식·채권·수익증권 등 증권의 ‘내용’에 따른 구분이 아니라, 실물증권이나 기존 전자증권과 구별되는 ‘형태’에 따른 개념으로 설명하고 있습니다. 조각투자에서 기존 금융상품의 토큰화로 국내 토큰증권 시장은 기존의 조각투자 중심 구조에서 전통적인 금융상품까지 범위를 확대하는 방향으로 전환되고 있습니다. 2027년 2월 4일 개정 「전자증권법」 시행에 맞춰 초기 단계에서는 기관투자자 전용 사모 MMF와 사모사채의 토큰화를 추진하고, 비상장주식의 경우 신탁방식을 활용한 토큰화가 추진될 예정입니다. 공모 조각투자증권 역시 초기 단계부터 토큰증권 형태의 발행이 허용될 계획입니다. 이후 운영 과정에서 안정성, 효율성 및 시장 수요 등을 점검하면서 공모증권 등으로 적용 범위를 확대하는 단계적 방안이 제시되어 있습니다. 상장주식의 경우 즉시 토큰증권으로 전환되는 것은 아닙니다. 금융위원회는 해외 주요 거래소의 사례 등을 참고하여 한국거래소를 중심으로 상장주식 토큰화에 관한 모델 검증과 시범사업을 병행한다는 계획을 밝히고 있습니다. 토큰화가 가져올 금융시장 구조의 변화 토큰화는 단순히 기존 금융상품을 디지털 형태로 바꾸는 것에 그치지 않고, 증권의 발행·거래·청산·결제 및 권리관리 방식 전반과 연결되는 변화입니다. 향후 토큰증권 시장이 확대되면 분산원장을 기반으로 증권의 발행 및 거래 정보를 관리하고, 기존 전자증권 시스템과 새로운 토큰증권 인프라를 연계하는 구조가 점차 구체화될 것으로 보입니다. 금융위원회도 단계적으로 인프라를 확대하고 장기적으로는 디지털 결제수단과 연계한 온체인 결제 구조까지 검토한다는 방향을 제시하고 있습니다. 이에 따라 금융회사와 관련 사업자 입장에서는 단순히 블록체인 기술의 활용 여부만을 살펴보기보다, 토큰화하려는 자산의 법적 성격과 증권 해당 여부, 발행·유통 구조 및 적용되는 자본시장 규제 등을 함께 검토하는 것이 중요합니다. ※ 참고: 금융위원회, 「토큰증권 정책방향」(2026. 9. 4.) 자주 묻는 질문 Q. (질문을 입력하세요) A. (답변을 입력하세요)

[IT 분쟁] 소프트웨어 개발 중 추가 요청사항에 따른 과업변경 및 추가대금 분쟁 법률자문

소프트웨어 개발 과정에서는 계약 체결 당시 예상하지 못한 기능이 추가되거나, 이미 합의한 업무 범위가 변경되는 경우가 많습니다. 이때 발주사는 기존 개발 범위에 포함된 업무라고 생각하는 반면, 개발사는 별도의 추가개발이므로 추가대금과 개발기간 연장이 인정되어야 한다고 판단할 수 있습니다. 계약 이후 요청된 업무라고 해서 모두 추가개발에 해당하는 것은 아닙니다. 추가대금 청구 가능 여부를 판단하려면 개발계약서, 제안서, 요구사항정의서, 기능명세서 및 화면설계서 등을 통해 당초 합의한 소프트웨어 개발 범위를 먼저 확인해야 합니다. 이후 요청된 작업이 기존 기능을 구체화하거나 보완하기 위한 것인지, 당초 예정하지 않았던 기능을 새롭게 구현하는 과업변경인지 살펴보아야 합니다. 요청사항에 사용된 명칭보다 실제 작업의 내용과 영향이 중요합니다. ‘추가 기능’이라고 표현되었더라도 기존 과업을 완성하기 위한 작업일 수 있으며, 단순한 ‘수정’으로 기재되었더라도 시스템 구조나 다른 기능에 상당한 영향을 미친다면 별도의 추가개발로 평가될 수 있습니다. 추가비용과 일정 변경에 관하여 당사자 사이에 어떠한 협의가 이루어졌는지도 함께 검토해야 합니다. 분쟁을 예방하려면 개발계약에 최초 과업범위와 과업변경 절차를 구체적으로 정해두는 것이 중요합니다. 변경 요청과 승인 방식, 추가대금의 산정 및 지급 방법, 개발 일정의 조정 기준 등을 정하고, 실제 개발 과정에서 이루어진 요청과 협의 결과도 이메일, 협업툴 또는 회의록 등으로 관리하는 것이 바람직합니다. 추가대금 분쟁이 발생한 경우에는 계약서 문구만을 기준으로 판단하기보다 계약 체결부터 개발 진행에 이르기까지의 전체 과정을 살펴야 합니다. 특히 작은 변경이 반복되었다면 개별 요청뿐 아니라 변경사항이 누적되면서 전체 업무 범위와 개발 일정에 미친 영향도 함께 검토할 수 있습니다. 법무법인 비트는 IT 및 이공계 전공 변호사들이 소프트웨어의 기술 구조와 실제 개발 경과를 구체적으로 파악하여, 과업범위와 추가개발의 구분부터 추가대금 및 일정 지연에 관한 책임까지 프로젝트의 실질에 맞게 검토합니다. [IT 분쟁] 소프트웨어 개발 중 추가 요구사.. : 네이버블로그 자주 묻는 질문 Q. 계약 체결 후 추가 요청 받은 기능을 개발했다면 추가대금을 청구할 수 있나요? A. 계약 이후에 추가적으로 요청된 작업이라는 이유만으로 당연히 추가대금을 청구할 수 있는 것은 아닙니다. 당초 개발 범위에 포함된 업무인지, 별도의 추가개발에 해당하는지 및 비용·일정 변경에 관한 합의가 있었는지를 계약문서와 실제 개발 과정을 바탕으로 종합적으로 검토해야 합니다.

소프트웨어 개발 지연·미완성 시 계약 해제와 손해배상 범위는?

소프트웨어나 애플리케이션 개발을 맡겼는데 약정한 납기가 지나도록 결과물이 완성되지 않거나, 계약에서 요구한 핵심 기능이 제대로 구현되지 않는 경우가 있습니다. 이때 발주사는 개발계약을 해제하고 이미 지급한 개발비를 어디까지 돌려받을 수 있을까요? 반대로 개발이 제대로 진행되지 않은 데 발주사 자신의 책임도 있다면 개발사에게 채무불이행 책임을 물을 수 있을까요? IT 개발 분쟁에서는 단순히 프로그램이 완성되지 않았다는 사실만으로 책임이 결정되지 않습니다. 개발 지연이나 미완성의 원인이 누구에게 있는지, 계약 해제와 손해배상의 요건이 충족되는지를 구체적으로 살펴봐야 합니다. 서울중앙지방법원 2013가합557245 판결과 서울중앙지방법원 2017가단5082174 판결은 이러한 문제를 잘 보여줍니다.   1. 개발사가 납기를 8개월 넘기고 프로그램을 완성하지 못한 사건 첫 번째 사건(서울중앙지방법원 2013가합557245 판결, 반소 2014가합569474)에서는, 개발사가 위탁료 9,000만 원에 프로그램 개발계약을 맺고도 약정한 기한을 8개월 넘게 넘기도록 개발을 마치지 못했습니다. 외부 분석 결과 안드로이드 앱의 완성도는 약 22.10%에 그쳤고, 아이폰 앱은 감정조차 불가능한 상태였습니다. 개발사가 “추가 대금을 주지 않으면 더 진행할 수 없다”며 소스코드 제공까지 거부하자, 발주사는 계약을 해제하고 지체상금, 서버 유지비, 인건비, 사무실 임차료, 광고계약 해지에 따른 손해, 분석비용 등의 배상을 반소로 청구했습니다.   2. 발주사가 개발에 필요한 자료를 충분히 제공하지 못한 사건 두 번째 사건(서울중앙지방법원 2017가단5082174 판결)은 멕시코 수출용 차량번호 인식 소프트웨어의 공급계약이 문제 된 사건입니다. 이 계약에서는 개발에 필요한 멕시코 차량번호판 사진 등의 자료를 소프트웨어를 공급받는 발주사 측이 제공하기로 되어 있었는데, 발주사 측이 이를 충분히 제공하지 못하면서 개발이 제대로 진행되지 못했습니다. 그런데도 발주 측은 개발사의 채무불이행을 주장하며 계약금의 반환과 손해배상을 청구했습니다.   3. 소프트웨어 개발계약에서 어떤 조항이 쟁점이 되었을까요? - 계약 해제 시 소스코드 제공의무와 지체상금  “(해제 시) 그동안 제작한 프로그램, 기술자료 및 소스코드를 발주사에 제공한다.” — 2013가합557245 사건의 2차 계약 제26조 제3항 또한 이 계약에서는 지체일수 1일당 위탁료의 1,000분의 5를 지체상금으로 정하고 있었습니다. 계약이 해제되더라도 그때까지의 산출물과 소스코드를 발주사에 넘겨주어야 한다는 의무와, 납기를 넘길 경우에 대비하여 손해배상액을 미리 정해 둔 지체상금 조항입니다. - 발주사의 개발자료 제공의무 “이 사건 소프트웨어 제작에 필요한 자료를 (발주 측인) 원고가 제공하기로 하였다.” — 이후 발주 측이 보낸 이메일: “자료를 구하기가 여의치 않네요” 개발의 전제가 되는 발주 측의 협력의무, 즉 자료 제공 의무를 정한 부분으로, 채무불이행 책임이 누구에게 있는지를 가르는 결정적인 사실이 되었습니다.   4. 법원은 개발비 반환과 손해배상 범위를 어떻게 판단했을까요? 첫 번째 사건에서 법원은, 추가 대금에 관한 약정이 없었는데도 그 지급을 요구하며 작업을 중단한 개발사의 태도를 ‘이행거절’​로 평가하여 발주사의 계약 해제가 적법하다고 보았습니다. 그에 따라 개발사는 원상회복으로 이미 지급받은 용역대금 157,700,000원을 반환​하게 되었습니다. 그러나 발주사가 함께 청구한 손해배상 항목은 대부분 받아들여지지 않았습니다. 계약에는 지체일수 1일당 위탁료의 1,000분의 5에 해당하는 지체상금 조항이 있었지만, 법원은 당사자 사이에 개발 기간을 묵시적으로 연장한 것으로 인정하여 지체상금 청구를 받아들이지 않았습니다. 광고계약 해지에 따른 손해는 민법 제393조 제2항의 특별손해로서 개발사가 이를 예견할 수 있었다고 보기 어렵다는 이유로 인정되지 않았고,  서버 유지비와 인건비, 사무실 임차료 역시 개발사의 채무불이행과의 인과관계가 인정되지 않는다는 이유로 청구가 받아들여지지 않았습니다. 즉, 개발사의 계약 위반과 계약 해제가 인정된다고 해서 발주사가 주장하는 모든 비용이 손해배상의 대상이 되는 것은 아닙니다. 이미 지급한 대금의 반환이라는 원상회복과 별도로, 추가 손해에 대해서는 각 손해와 채무불이행 사이의 인과관계 및 특별손해의 예견가능성 등이 문제될 수 있습니다. 한편 두 번째 사건에서 법원은 개발이 이루어지지 못한 원인이 발주사 측이 약속한 자료를 제공하지 않은 데 있다고 보았습니다. 이에 따라 개발사에게 채무불이행 책임이 없다고 판단하고 발주 측의 계약금 반환 및 손해배상 청구를 전부 기각했습니다. 채권자인 발주 측이 자신의 협력의무를 다하지 않았다면 개발사에게 책임을 묻기 어려울 수 있다는 점을 보여 주는 사례입니다. 두 사건을 함께 보면, IT 개발 분쟁에서 이미 지급한 대금을 돌려받는 원상회복은 비교적 인정되기 쉬운 반면, 서버 비용이나 인건비, 광고 손해처럼 계약 바깥으로 번진 손해는 예견가능성과 인과관계라는 높은 입증의 벽을 넘어야 한다는 점을 알 수 있습니다. IT 개발 분쟁에서 발주사가 유의해야 할 점 발주사로서는 회수하고 싶은 손해가 있다면 지체상금이나 손해배상액 예정 조항을 구체적으로 설계해 두는 것이 중요합니다. 또한 자료 제공과 같은 자신의 협력의무를 제대로 이행해야만 상대방에게 책임을 물을 수 있다는 점도 기억해야 합니다. IT 개발 분쟁에서 개발사가 유의해야 할 점 개발사로서는 추가 대금을 받기 전에는 작업을 중단하겠다는 대응이 이행거절로 평가될 수 있으므로 신중해야 합니다. 또한 계약이 해제될 경우 소스코드와 산출물을 넘겨주어야 하는 의무가 계약상 정해져 있는지도 확인해야 합니다. 반대로 발주사 측의 자료 제공이나 의사결정이 늦어지는 사정은 반드시 문서로 남겨 두어야 나중에 방어의 근거로 삼을 수 있습니다.   ► IT 개발 분쟁에서는 계약서와 개발 과정의 기록을 함께 살펴야 합니다 IT 개발 분쟁이 발생하면 계약서뿐 아니라 개발 과정에서 오간 이메일·메신저, 일정 변경 내역, 자료 제공 기록, 검수 결과, 소스코드 및 산출물 등 실제 프로젝트 진행 자료를 함께 확인할 필요가 있습니다. 특히 계약 체결 단계에서 개발 범위와 검수 기준, 일정 변경 절차, 지체상금과 손해배상, 발주사의 협력의무, 계약 해제 시 소스코드와 산출물의 처리​를 구체적으로 정해 두면 분쟁이 발생했을 때 책임 범위와 대응 방향을 보다 명확하게 판단할 수 있습니다. 법무법인 비트는 IT 개발 분쟁에서 이행거절과 계약 해제, 원상회복은 물론 지체상금·특별손해 등 손해배상 범위가 쟁점이 된 사건을 다수 다루어 온 전문성을 갖추고 있습니다. 계약서의 손해배상·검수·협력의무 조항 설계부터 분쟁 대응까지 처음부터 함께 준비해 드립니다. 한편 계약이 해제되었다고 해서 이미 지급한 개발비가 항상 전액 반환되는 것은 아닙니다. 개발 결과물이 상당 부분 완성되어 실제 사용할 수 있는 상태라면 개발사가 완성한 부분에 대한 기성고를 청구할 수 있는지가 별도로 문제될 수 있습니다. 관련 판례 해설 > 소프트웨어 개발 완료 전 계약 해지하면 기성고·개발비는 반환받을 수 있을까? 판례 3건 분석   [자주 묻는 질문] Q1. 개발사가 납기를 넘기면 지체상금을 받을 수 있나요? A1. 반드시 그렇지는 않습니다. 2013가합557245 사건에서는 당사자 사이에 개발 기간을 묵시적으로 연장한 것으로 인정되어 지체상금 청구가 받아들여지지 않았습니다. Q2. 프로그램이 완성되지 않았다면 이미 지급한 개발비를 돌려받을 수 있나요? A2. 계약 해제가 적법하게 인정되는 경우에는 이미 지급한 용역대금의 반환이라는 원상회복이 문제될 수 있습니다. 첫 번째 사건에서는 개발사가 지급받은 용역대금 157,700,000원의 반환이 인정되었습니다. Q3. 서버비·인건비·광고 손해도 청구할 수 있나요? 발주사가 자료를 제공하지 않은 경우는 어떻게 되나요? A3. 추가 손해는 개발사의 채무불이행과의 인과관계나 특별손해의 예견가능성이 문제될 수 있습니다. 첫 번째 사건에서는 서버 유지비·인건비·임차료와 광고계약 해지에 따른 손해가 인정되지 않았습니다. 또한 두 번째 사건에서는 발주 측이 약속한 자료를 제공하지 않은 것이 개발이 제대로 이루어지지 못한 원인으로 인정되어 개발사의 채무불이행 책임이 부정되었습니다.

소프트웨어 개발 완료 전 계약 해지하면 기성고·개발비는 반환받을 수 있을까? 판례 3건 분석

개발이 끝나기 전에 계약이 깨졌다면, 그동안 만든 만큼의 대금은 받을 수 있을까요? 또는 발주사는 이미 지급한 개발비를  돌려받을 수 있을까요? 소프트웨어 개발계약이 완성 전에 종료되었다고 해서 개발사가 항상 보수를 받을 수 없는 것은 아닙니다. 결과물이 상당 부분 완성되어 약간의 수정·보완만으로 실제 사용할 수 있는 상태라면 개발사는 완성한 부분에 대한 기성고 보수를 청구할 수 있습니다. 반대로 일부 기능만 구현된 프로토타입 수준으로 사실상 미완성 상태라면 기성고가 인정되지 않고, 이미 지급받은 개발비를 전액 반환해야 할 수도 있습니다. 이하에서는 대법원 1996. 7. 30. 선고 95다7932 판결과 그 하급심, 서울중앙지방법원 2021가단5018224 판결, 서울북부지방법원 2023가단149881 판결을 살펴보고, 세 사건의 결론이 달라진 이유와 실제 소프트웨어 개발계약에서 유의할 점을 정리해 보겠습니다.   1. 어떤 사건이었나요? 완성도 87.87%였던 첫 번째 사건 첫 번째 사건은 서울민사지방법원 93가합40374 판결, 서울고등법원 94나16740 판결을 거쳐 대법원 95다7932 판결로 확정된 사건입니다. 개발사는 발주사의 업무처리 프로그램을 개발·공급하고 시험가동까지 마쳤습니다. 그런데 발주사는 수주번호가 입력되지 않는 등 결함이 있다는 이유로 개발사의 수정·보완 제의를 거부하였고, 개발사로부터 계약상 지위를 넘겨받은 회사에 대해서는 “계약 당사자가 아니므로 상대하지 않겠다”며 계약 해제를 통보했습니다. 당시 프로그램의 완성도는 87.87%로 평가되었습니다.   완성도 81.9%였던 두 번째 사건 두 번째 사건은 서울중앙지방법원 2021가단5018224 판결입니다. 개발사는 개발비 4,500만 원(부가가치세 별도)에 소프트웨어를 개발하기로 하고 수정·보완을 거쳐 APK 파일과 배포 일정까지 통지했습니다. 그런데 발주사가 돌연 계약 해제를 통지했고, 당시 결과물의 완성도는 81.9%였습니다.   프로토타입 수준에 그친 세 번째 사건 세 번째 사건은 서울북부지방법원 2023가단149881 판결입니다. 발주사는 eSIM 판매용 소프트웨어 3건의 개발을 맡기면서 검수도 하기 전에 대금 합계 229,970,000원​을 모두 미리 지급했습니다. 그러나 개발사가 보내온 결과물은 일부 기능만 구현된 프로토타입 수준이었고, 키오스크 프로그램은 아예 구현되지 않았습니다.   2. 소프트웨어 개발이 끝나지 않았다면 기성고를 받을 수 없을까? 세 사건에서는 소프트웨어 개발계약이 완성 전에 종료된 경우 개발사가 그때까지 완성한 부분에 대한 보수를 청구할 수 있는지가 문제되었습니다. 대법원 95다7932 사건에서는 프로그램의 미완성 부분과 전체적인 완성도가 구체적인 수치로 확인되었습니다. “시험운용단계 5.32%, 교육시스템 검수 및 인계단계 5.04%, 시스템운용단계 1.51%, 프로그램 수정단계 0.26%의 미완성 부분이 있어 전체적으로 87.87%의 완성도를 보이고 있었다.” 이 사건에서는 이러한 87.87%의 완성도가 기성 보수를 산정하는 기준이 되었습니다. 서울중앙지방법원 2021가단5018224 판결에서는 다음과 같이 판단했습니다. “소프트웨어가 거의 완성되어 약간의 보완을 가하면 업무에 사용할 수 있는 정도인데도 도급인이 … 수정·보완 제의를 거부하는 것과 같은 특별한 사정이 없는 한, 완성하지 못한 수급인은 기성 부분의 보수를 청구할 수 없다.” 따라서 결과물이 거의 완성되어 약간의 보완으로 사용할 수 있고, 발주사가 개발사의 수정·보완 제의를 거부하는 것과 같은 특별한 사정이 있다면 개발사가 완성한 부분에 대한 보수를 청구할 수 있는지가 문제될 수 있습니다.   3. 법원은 세 사건을 어떻게 판단했을까? 첫 번째 사건에서 법원은 프로그램의 완성도가 87.87%에 이르렀고 발주사가 보완 제의를 거부하여 신뢰관계가 끊어진 점을 들어 기성 보수를 인정했습니다. 소프트웨어 대금 66,539,000원에 완성도를 적용한 금액에서 이미 지급된 17,424,000원을 뺀 41,043,819원​이 인정되었습니다. 발주사는 이행보증보험증권을 받지 못했다거나 손해를 상계한다는 항변도 하였으나 받아들여지지 않았고, 발주사 측의 협조의무 위반이 지적되었습니다. 두 번째 사건에서도 법원은 결과물의 완성도가 81.9%이고 약간의 보완만 거치면 사용할 수 있는 상태였다는 점을 들어 기성고를 인정했습니다. 용역대금 총액 49,500,000원(부가가치세 포함)에 완성도를 적용한 40,540,500원에서 개발사가 이미 지급받은 34,650,000원을 제외한 5,890,500원​이 인정되었습니다. 반면 발주사가 반소로 청구한 개발비 환불, 즉 원상회복 청구는 이행을 최고하는 등 적법한 해제 요건을 갖추지 못했다는 이유로 기각되었습니다. 세 번째 사건의 결론은 달랐습니다. 결과물이 일부 기능만 구현된 프로토타입 수준의 사실상 미완성 상태였고 키오스크 프로그램은 아예 구현되지 않았습니다. 법원은 기성 부분을 인정하지 않고 개발사의 채무불이행을 이유로 한 계약 해제와 원상회복을 인정하였고, 개발사는 발주사가 미리 지급한 229,970,000원 전액을 반환​하게 되었습니다.   4. 세 판례 비교: 무엇이 결론을 갈랐을까? 세 사건을 한눈에 비교하면 다음과 같습니다. 판례 결과물 상태 주요 사정 법원의 판단 대법원 95다7932 판결 및 하급심 완성도 87.87% 발주사가 수정·보완 제의를 거부 기성고 인정 서울중앙지방법원 2021가단5018224 판결 완성도 81.9%, 약간의 보완으로 사용 가능 발주사의 적법한 계약 해제 요건도 문제됨 기성고 인정, 개발비 반환 청구 기각 서울북부지방법원 2023가단149881 판결 일부 기능만 구현된 프로토타입 수준, 키오스크 프로그램 미구현 사실상 미완성 상태 기성고 불인정, 개발비 전액 반환   결국 승패를 가른 것은 결과물의 완성도와 실제 사용 가능성이었습니다. 다만 위 판례를 두고 ‘80% 이상 개발되면 기성고가 인정된다’고 볼 수는 없습니다. 결과물이 실제 사용할 수 있는 수준인지, 남은 작업이 어느 정도인지, 개발사가 수정·보완할 수 있었는지, 발주사가 이를 거부했는지 등 구체적인 사정을 함께 고려해야 합니다.   5. 발주사가 개발계약을 종료할 때 주의할 점은 무엇일까? 발주사로서는 단계별 검수 기준과 산출물의 정의를 계약서에 분명히 정해 두고, 검수 전의 선지급은 가능한 한 줄이는 것이 바람직합니다. 특히 개발대금을 먼저 지급한 상태에서 결과물이 계약상 요구된 수준에 미치지 못한다면 이미 지급한 개발비를 반환받기 위한 별도의 분쟁이 발생할 수 있습니다. 또한 계약을 해제할 때에는 이행 최고 등 적법한 절차를 갖추어야 합니다. 앞서 본 두 번째 사건처럼 적법한 해제 요건을 갖추지 못하면 이미 지급한 개발비의 반환 청구가 받아들여지지 않을 수 있습니다. 따라서 계약을 종료하기 전에 현재 개발 상태와 수정·보완 가능성, 계약서상 검수 기준과 해제 요건을 먼저 확인할 필요가 있습니다. 6. 개발사가 기성고를 청구하려면 무엇을 준비해야 할까? 개발사로서는 완성도와 기성고를 객관적으로 입증할 수 있는 소스코드와 산출물, 감정에 대비한 자료​를 확보해 두는 것이 중요합니다. 실제 소프트웨어 개발분쟁에서는 개발사가 어느 부분까지 완성했는지, 남아 있는 작업이 무엇인지, 수정·보완을 통해 사용할 수 있는 상태가 될 수 있었는지가 중요한 쟁점이 될 수 있습니다. 또한 검수와 지급을 연동한 분할 지급 구조를 계약에 반영하여 위험을 나누어 두는 것이 좋습니다.   7. 결론 : 개발 완성률보다 결과물의 실제 상태를 살펴봐야 합니다 소프트웨어 개발계약이 완성 전에 종료되었다고 해서 개발사가 항상 기성고를 받을 수 없는 것도 아니고, 발주사가 이미 지급한 개발비를 항상 전액 돌려받을 수 있는 것도 아닙니다. 앞서 살펴본 사건에서는 87.87%와 81.9%까지 완성되어 약간의 보완으로 사용할 수 있는 결과물에 대해서는 기성고가 인정된 반면, 일부 기능만 구현된 프로토타입 수준의 사실상 미완성 결과물에 대해서는 기성고가 인정되지 않고 개발비 전액 반환이 인정되었습니다. 따라서 소프트웨어 개발계약이 중도에 종료되었다면 단순한 개발 진행률만 볼 것이 아니라 결과물의 완성도와 실제 사용 가능성, 수정·보완 가능성, 계약 종료 경위와 적법한 해제 절차​를 함께 살펴봐야 합니다. 법무법인 비트는 소프트웨어 개발계약의 검수·기성·해제 조항 설계와 계약이 중도에 끝난 뒤의 기성고 정산 및 대금반환 분쟁을 다수 수행해 온 전문성을 갖추고 있습니다. 완성도 감정 대응부터 권리행사와 소송 전략까지 처음부터 함께 준비해 드립니다.   [자주 묻는 질문] 소프트웨어 개발이 80% 정도 완료되면 개발비의 80%를 받을 수 있나요? 반드시 그렇지는 않습니다. 판례에서는 완성도 87.87%와 81.9%인 소프트웨어에 대해 기성고가 인정된 사례가 있지만, 특정 완성률 자체가 절대적인 기준은 아닙니다. 결과물이 약간의 수정·보완만으로 실제 사용할 수 있는 상태인지, 핵심 기능이 구현되어 있는지, 남은 작업이 어느 정도인지, 발주사가 개발사의 수정·보완 제의를 거부했는지 등을 함께 살펴봐야 합니다. 발주사가 소프트웨어 개발계약을 해제하면 이미 지급한 개발비를 전액 돌려받을 수 있나요? 계약이 종료되었다는 이유만으로 개발비 전액 반환이 당연히 인정되는 것은 아닙니다. 결과물이 상당 부분 완성되어 기성고가 인정된다면 해당 부분의 보수는 개발사에게 귀속될 수 있습니다. 반면 결과물이 일부 기능만 구현된 프로토타입 수준의 사실상 미완성 상태이고 적법한 계약 해제가 인정된다면 이미 지급한 개발비 전액의 반환이 인정될 수도 있습니다. 개발 결과물에 문제가 있으면 발주사가 바로 계약을 해제할 수 있나요? 항상 그런 것은 아닙니다. 계약 내용과 구체적인 사실관계에 따라 이행 최고 등 적법한 계약 해제 요건과 절차를 갖춰야 할 수 있습니다. 실제 서울중앙지방법원 2021가단5018224 사건에서는 발주사가 적법한 해제 요건을 갖추지 못했다는 이유로 이미 지급한 개발비의 반환 청구가 받아들여지지 않았습니다. 따라서 계약 해제를 통보하기 전 현재 개발 상태와 수정·보완 가능성, 계약서상 해제 요건을 함께 확인할 필요가 있습니다.