37.

[사례분석] 블록체인 소프트웨어 개발 분쟁: 추가 요구사항 입증과 기성고 산정 기준

• 공유하기
• 새 탭 열기
• 작성 이력 보기

<핵심 요약>
블록체인 소프트웨어 도급계약에서 수급인이 핵심 기능을 구현하지 못한 경우 이는 목적 달성이 불가능한 중대한 채무불이행에 해당한다. 기능정의서 범위 내에서 진행된 도급인의 세부 조율은 추가 요구사항으로 인정되지 않으므로 이를 일정 지연의 면책 사유로 삼을 수 없다. 따라서 상용 서비스로서의 실질적 효용이 결여된 미완성 결과물에 대한 부당한 기성고 산정과 보수 청구는 법리적으로 배척된다.

자세한 기본 법리는 아래 위키를 참고하십시오.

• SW개발계약 완성 미완성 하자
• [사례분석] 소프트웨어 공급계약 해제의 주요 쟁점: 불완전이행 및 기술지원의무 위반 인정 여부
• [사례분석] 소프트웨어 개발 계약 해제와 채무불이행 손해배상: IT 개발 인력 이탈에 따른 이행불능과 장래수익 산정 법리
   

1. 플랫폼 개발 지연과 요구사항을 둘러싼 분쟁의 전개

도급인은 모바일 및 웹 기반의 블록체인 플랫폼 서비스를 구축하기 위해 외주 개발업체 수급인과 블록체인 소프트웨어 개발 도급계약을 체결하였다. 해당 계약에는 단순한 회원가입과 로그인을 넘어 블록체인 지갑 연동 및 핫월렛 자금 이체 기능 등 다수의 고난도 핵심 로직이 필수적으로 포함되어 있었다.

그러나 프로젝트가 진행되는 과정에서 수급인은 도급인이 기존 계약 범위를 초과하는 무리한 추가 요구사항을 지속적으로 지시하여 일정이 지연되었다고 주장하였다. 반면 도급인은 해당 요청이 초기 기능정의서를 구체화하는 통상적인 조율에 불과하며 오히려 수급인이 약정된 기한 내에 핵심 기술을 구현하지 못했다고 반박하였다.

결국 양측의 이견이 좁혀지지 않으면서 미완성 결과물에 대한 기성고 산정과 지체상금 책임을 묻는 분쟁이 촉발되었다. 해당 갈등은 합의에 이르지 못하고 대한상사중재원 규칙에 따른 본신청 및 반대신청이 제기되는 중재 분쟁으로 확대되었다.

2. 블록체인 소프트웨어 도급계약의 기능 범위와 완성도 다툼
 

• 가. 기능정의서의 구체화 과정과 추가 요구사항의 법적 구별 기준
  
  개발 과정에서 발생하는 도급인의 요청이 당초 확정된 기능정의서 범위 내의 통상적인 협의인지 계약을 벗어난 새로운 기능 추가인지가 중요한 쟁점이 된다. 만약 기존 계약의 테두리 안에서 진행된 세부 조율이라면 수급인은 이를 추가 요구사항으로 간주하여 업무량 증가나 일정 지연의 면책 사유로 주장할 수 없다.
   
• 나. 블록체인 핵심 기능 미구현에 따른 목적물의 실질적 완성도 평가
  
  단순한 화면 인터페이스나 이메일 로그인 기능이 작동한다고 하여 구조적으로 복잡한 블록체인 지갑 연동이나 자금 이체 기능이 완성된 것으로 인정되기는 어렵다. 실제 상용 서비스 수준에서 핵심 로직이 안정적으로 구동되지 않는다면 해당 결과물은 경제적 효용을 제공하지 못하는 미완성 상태로 평가되어 프로젝트 완성을 인정받기 힘들다.
   
• 다. 효용이 결여된 미완성 목적물에 대한 기성고 산정과 보수 청구 가부
  
  도급계약의 성격을 지니는 소프트웨어 개발 계약에서 목적물이 미완성된 경우 기성 부분이 도급인에게 실질적인 이익이 되는지 여부가 보수 청구의 핵심 요건이다. 작동하는 기능이 극히 일부에 불과하여 결과물 자체가 사용 불가능한 상태라면 수급인의 기성고에 따른 보수 청구는 제한되며 오히려 기지급 대금의 반환이나 지체상금 책임이 문제된다.
   

3. 실질적 완성도 부족 입증을 통한 기성고 통제와 법리 적용
 

• 가. 객관적 자료 분석을 통한 추가 요구사항 면책 주장의 배척
  
  중재 절차에서는 도급인의 요청이 기존 기능정의서 범위 내의 조율에 불과하며 수급인이 주장하는 업무량 증가는 객관적 산식이 없다는 점이 지적되었다. 수급인이 계약 변경이나 기한 연장, 대금 조정 요청 없이, 계약 체결 당시 직접 동의한 방식으로 프로젝트를 지속한 사실이 확인됨에 따라 추가 요구사항을 이유로 한 일정 지연의 귀책사유는 수급인 측에 있는 것으로 정리되었다.
   
• 나. Q: 일부 UI가 작동하는 상태에서 블록체인 핵심 로직이 누락되었다면 프로젝트 완성으로 볼 수 있을까?
  
  원칙적으로 완성으로 인정되지 않으며 대법원 1997. 12. 23. 선고 97다44768 판결 등에 따르면 소프트웨어의 미완성과 하자를 구별할 때 예정된 최후 공정의 종료 여부는 계약의 구체적 내용에 비추어 객관적으로 판단해야 한다. 해당 사건에서는 제출된 시연 영상의 한계가 구체적으로 지적되었고 특정 핵심 기능과 지갑 연동 기술이 정상 작동하지 않음이 확인되어 실질적 완성도가 현저히 낮다고 판단되었다.
   
• 다. 기능별 비교 분석을 근거로 한 보수 청구 제한과 화해중재 도출
  
  전체 개발 항목을 세부적으로 구분하여 실제 구현된 기능과 미구현 기능을 대조하는 방식으로 기성고가 극히 낮다는 객관적 사실이 중재부에 명확히 제시되었다. 미완성 소프트웨어가 도급인에게 실질적 효용을 제공하지 못하므로 대금 청구가 제한된다는 도급계약 법리가 적용되었고 결과적으로 수급인이 도급인에게 기지급금 중 일부 금원을 반환하고 양측이 나머지 청구를 상호 포기하는 화해중재판정이 성립되었다.
   

※ 관련 법률 인사이트
관련 사례에 대한 변호사의 실제 사건 수행 전략은 아래 법률 인사이트에서 더 깊이 있게 확인할 수 있습니다.

• [성공 사례] 블록체인 플랫폼 개발 분쟁 화해 방어 - 기능정의서 기반 기성고 산정 전략
   

4. 관련 판례