소프트웨어 결함으로 매출 손실, 손해배상 받을 수 있을까

얼마 전 이런 사연이 있었습니다. 서울에서 온라인 패션 쇼핑몰을 운영하는 C씨(38세, 여성)는 주문 관리 효율화를 위해 IT 개발사 D사와 5,200만 원 규모의 재고관리 소프트웨어 개발 계약을 체결했습니다. 납품 후 약 두 달이 지날 무렵, 시스템에 치명적 결함이 발견되었습니다. 재고 수량이 실제보다 과다 표시되면서, 이미 품절된 상품에 대한 주문이 수백 건 접수된 것입니다.

C씨는 급히 수작업으로 전환했지만, 이미 고객 클레임이 쏟아졌고 환불 처리와 배송 지연으로 약 3,800만 원의 매출 손실이 발생했습니다. C씨는 D사에 하자 보수와 손해배상을 요구했으나, D사 측은 "소프트웨어는 완벽할 수 없고, 운영 환경에 따른 오류일 수 있다"며 책임을 부인했습니다.

"개발비 5,200만 원에 매출 손실 3,800만 원, 소프트웨어 결함에 대해 법적으로 배상을 받을 수 있는 걸까요?"

이 사안을 통해 소프트웨어 결함 손해배상의 핵심 법적 쟁점 세 가지를 살펴보겠습니다.

소프트웨어 결함이 민법상 '하자'에 해당하는지

소프트웨어 개발 계약은 일반적으로 민법상 도급계약(민법 제664조)으로 분류됩니다. 도급계약에서 수급인(개발사)은 완성된 일의 결과에 대해 담보책임을 부담하며, 일의 목적물에 하자가 있을 경우 도급인(발주자)은 하자보수 청구권 또는 손해배상 청구권을 행사할 수 있습니다(민법 제667조).

핵심은 '하자'의 판단 기준입니다. 실무에서는 다음 두 가지를 중심으로 살펴봅니다.

계약서상 요구사항 명세(SRS)와의 합치 여부 - 개발 계약 시 합의한 기능 명세서에 "재고 수량 실시간 정합성 보장"이 포함되어 있었다면, 그 기능의 오작동은 명확한 하자에 해당합니다.

통상적으로 기대되는 품질 수준 충족 여부 - 명세서에 구체적 기재가 없더라도, 재고관리 시스템이 재고 수량을 정확히 반영하는 것은 사회통념상 당연히 갖춰야 할 기능으로 볼 수 있습니다.

C씨의 경우, 계약서 별첨의 기능 요구사항에 "실시간 재고 동기화"가 명시되어 있었고, 결함 로그를 통해 소프트웨어 자체의 데이터베이스 동기화 오류임이 확인되었습니다. 따라서 민법상 하자에 해당할 가능성이 높습니다.

확대 손해(매출 손실)까지 배상받을 수 있는지

소프트웨어 하자 자체의 보수나 개발비 반환은 비교적 인정받기 수월합니다. 문제는 C씨가 입은 3,800만 원의 매출 손실, 즉 확대 손해까지 배상받을 수 있는지 여부입니다.

민법 제667조 제2항은 하자로 인한 손해배상을 규정하고 있으며, 이때의 손해배상 범위는 민법 제393조(손해배상의 범위)에 따라 판단됩니다. 정리하면 다음과 같습니다.

통상손해: 소프트웨어 결함으로 인해 통상적으로 발생하는 손해. 하자보수 비용, 대체 시스템 도입 비용 등이 이에 해당합니다.

특별손해: 매출 손실, 고객 이탈에 따른 영업 손실 등은 특별한 사정으로 인한 손해에 해당하며, 채무자(개발사)가 이를 알았거나 알 수 있었을 때에만 배상 범위에 포함됩니다.

C씨의 사안에서는 D사가 계약 체결 시 "온라인 쇼핑몰의 주문 처리 시스템"이라는 사용 목적을 명확히 인지하고 있었습니다. 재고 오류가 곧바로 잘못된 주문 접수와 매출 손실로 이어진다는 점은 충분히 예견 가능한 사정이므로, 특별손해 배상이 인정될 여지가 있습니다.

다만 실무에서 가장 어려운 부분은 손해액의 입증입니다. C씨가 주장하는 3,800만 원 중 어디까지가 소프트웨어 결함과 인과관계 있는 손해인지를 구체적으로 증명해야 합니다. 이를 위해 필요한 자료는 아래와 같습니다.

결함 발생 전후 매출 비교 데이터 (최소 직전 3개월 대비)

오류 주문 건별 환불 처리 내역 및 고객 클레임 기록

시스템 장애 로그, 결함 원인 분석 보고서

수작업 전환으로 인한 추가 인건비 지출 증빙

개발사의 면책 주장에 대한 검토

D사는 두 가지 반론을 제기했습니다. 실무에서도 소프트웨어 분쟁에서 개발사 측이 자주 사용하는 논리이므로 각각 살펴볼 필요가 있습니다.

첫째, "소프트웨어는 본질적으로 완벽할 수 없다"는 주장입니다. 소프트웨어에 일정 수준의 버그가 존재할 수 있다는 점 자체는 업계에서 통용되는 사실입니다. 그러나 이는 사소한 UI 오류나 비핵심 기능의 미비에 해당하는 경우에 한합니다. 재고관리 시스템의 핵심 기능인 수량 정합성에 중대한 결함이 있다면, 이를 소프트웨어의 본질적 한계로 돌리기는 어렵습니다.

둘째, "운영 환경 문제"라는 주장입니다. 개발사가 결함의 원인을 발주사의 서버 환경이나 데이터 입력 오류로 돌리는 경우가 실무에서 빈번합니다. 이 경우 기술적 원인 규명이 쟁점이 되며, 제3자 전문가의 감정(소프트웨어 감리)이 필요할 수 있습니다. C씨의 경우, 결함 로그 분석 결과 소프트웨어 내부의 동기화 모듈 오류로 확인되었기 때문에 이 반론은 설득력이 낮습니다.

한편, 계약서에 면책조항이나 손해배상 한도 조항이 포함되어 있는 경우도 많습니다. 예컨대 "간접 손해에 대해서는 배상하지 않는다" 또는 "배상 총액은 계약 금액을 초과하지 않는다"는 조항이 대표적입니다. 이러한 조항이 있다면 배상 범위에 상당한 영향을 미칠 수 있으나, 고의 또는 중대한 과실에 의한 하자의 경우에는 면책조항의 효력이 제한될 수 있다는 점도 함께 고려해야 합니다.

실무적 조언

C씨처럼 소프트웨어 결함으로 인한 손해배상을 청구하려는 경우, 다음 사항을 유의하시기 바랍니다.

결함 발견 즉시 서면(이메일 포함)으로 개발사에 통보하고, 하자보수를 요청하십시오. 구두 통보만으로는 추후 통보 시점을 증명하기 어렵습니다. 도급인의 하자보수 청구권은 목적물 인도일로부터 1년 이내에 행사해야 합니다(민법 제670조).

시스템 로그, 오류 스크린샷, 매출 데이터 등 증거를 즉각 확보하십시오. 시간이 지나면 서버 로그가 덮어쓰기 되거나 삭제되는 경우가 많습니다. 데이터베이스 백업을 결함 발생 시점 기준으로 별도 보존해 두는 것이 중요합니다.

계약서상 하자보수 의무, 손해배상 한도, 면책조항을 면밀히 검토하십시오. 분쟁의 방향이 이 조항들에 의해 크게 좌우됩니다. 계약 체결 단계에서부터 핵심 기능 장애 시 개발사 책임 범위를 명확히 규정해 두는 것이 최선의 예방책입니다.

손해액 산정에 객관적 근거를 확보하십시오. 동종 업종 평균 매출 대비, 결함 기간 매출 감소분, 직접 지출한 복구 비용 등을 기초로 산정하되, 필요시 회계사의 손해액 감정 의견서를 준비하는 것이 유리합니다.

소프트웨어 결함 손해배상 분쟁은 법률적 쟁점과 기술적 쟁점이 복합적으로 얽혀 있는 사안입니다. 계약서 분석, 결함의 기술적 원인 규명, 손해액 입증이 모두 충분히 뒷받침되어야 실질적인 배상을 받을 수 있습니다.

👤

이우덕 변호사의 코멘트

소프트웨어 분쟁을 다루면서 느낀 점은, 결함 자체보다 계약서와 증거 확보 상태가 결과를 좌우하는 경우가 대부분이라는 것입니다. 특히 시스템 로그는 시간이 지나면 복구 불가능한 경우가 많으므로 결함 인지 즉시 데이터를 보전해야 합니다. 복합적 쟁점이 얽힌 사안인 만큼 가능한 초기 단계에서 전문가의 검토를 받으시길 권합니다.

이 글의 변호사