IT 용역 하자보수 기간과 범위 가이드: 공정한 계약을 위한 법률 체크리스트

IT 용역 계약의 완성은 '인수'가 아닌 '하자보수'입니다

소프트웨어(SW) 개발 프로젝트에서 가장 빈번하게 발생하는 분쟁은 무엇일까요? 바로 **'하자보수'**에 관한 견해 차이입니다. 발주사(갑)는 "계약한 대로 작동하지 않으니 무상으로 고쳐달라"고 요구하고, 개발사(을)는 "그것은 하자가 아니라 추가 요구사항이니 비용을 지불하라"고 맞섭니다.

IT 용역은 무형의 결과물을 만들어내는 과정이기에, 일반적인 제조물보다 '하자'의 경계가 모호합니다. 하지만 법적 기준과 공정한 계약 관행을 미리 알고 있다면 이러한 감정 소모와 법적 리스크를 획기적으로 줄일 수 있습니다. 오늘은 IT 용역 하자보수의 올바른 기간과 범위, 그리고 독소 조항을 피하는 법을 법률적 관점에서 살펴보겠습니다.

1. 법이 정한 소프트웨어 하자보수의 근거

IT 개발 계약은 법적으로 '도급' 계약의 성격을 가집니다. 우리 민법은 도급 계약에서 완성된 결과물에 하자가 있을 경우 수급인(개발사)이 책임을 지도록 규정하고 있습니다.

민법 제667조 (하자담보책임)

민법에 따르면 완성된 목적물에 하자가 있는 때에는 주문자는 수급인에 대하여 상당한 기간을 정하여 그 하자의 보수를 청구할 수 있습니다. 또한, 하자보수와 함께 또는 하자보수에 갈음하여 손해배상을 청구할 수도 있습니다.

소프트웨어 진흥법 제54조

공공 소프트웨어 사업의 경우, '소프트웨어 진흥법'이 보다 구체적인 기준을 제시합니다. 해당 법률에 따르면 국가기관등이 발주한 SW 사업의 하자담보책임 기간은 준공검사를 마친 날로부터 1년 이내로 제한됩니다. 비록 민간 계약에서는 당사자 간 합의가 우선하지만, 이 1년이라는 기준은 IT 업계에서 가장 보편적이고 공정한 표준으로 통용됩니다.

2. 하자보수 기간, 언제부터 언제까지가 적당할까?

가장 흔한 실수는 하자보수 기간의 '기점'을 명확히 하지 않는 것입니다.

시작점: 검수 완료일 vs 잔금 지급일

일반적으로 하자보수 기간은 **'검수 완료일(검사 합격일)'**로부터 시작됩니다. 잔금 지급일이나 실제 서비스 오픈일을 기점으로 삼기도 하지만, 법적 분쟁을 예방하기 위해서는 검수 확인서에 양측이 서명한 날을 기준으로 명시하는 것이 가장 깔끔합니다.

적정 기간: 6개월에서 1년

• 일반적인 솔루션/웹사이트: 6개월 ~ 1년
• 복잡한 시스템 통합(SI): 1년
• 단순 유지보수 또는 운영: 별도의 '유지관리(Maintenance)' 계약 체결 권장

간혹 발주사가 '영구적인 하자보수'나 '5년 이상의 장기 보수'를 요구하는 경우가 있습니다. 이는 개발사에게 지나치게 가혹한 조건이며, 소프트웨어의 기술적 수명과 환경 변화(OS 업데이트, 브라우저 버전업 등)를 고려할 때 현실적으로 불가능합니다. 특수한 목적이 없다면 1년을 초과하는 무상 하자보수 조항은 신중하게 검토해야 합니다.

3. '하자'와 '유지보수'를 구분하는 명확한 기준

많은 계약서가 '하자보수'와 '유지관리(유지보수)'를 혼용해서 사용하지만, 법률적으로 이 둘은 엄연히 다릅니다.

하자보수 (Warranty)

• 정의: 계약 시 약정했던 기능이 구현되지 않거나, 설계 오류로 인해 발생하는 오류를 바로잡는 것.
• 비용: 원칙적으로 무상.
• 예시: 로그인 버튼을 눌렀는데 에러가 발생하는 경우, DB 데이터가 유실되는 로직 결함 등.

유지관리 (Maintenance)

• 정의: 검수 완료 당시에는 없었던 새로운 기능을 추가하거나, 외부 환경 변화에 맞춰 시스템을 최적화하는 것.
• 비용: 원칙적으로 유상.
• 예시: 새로운 결제 수단 추가, 디자인 레이아웃 변경, 사용자 요구에 따른 데이터 통계 화면 신설 등.

4. 분쟁을 예방하는 체크리스트 3가지

공정한 IT 용역 계약을 위해 계약서 검토 시 다음 세 가지를 반드시 확인하세요.

1) '하자'의 범위를 명시했는가?

사용자의 조작 미숙, 발주사가 제공한 서버의 결함, 오픈 소스 라이브러리 자체의 결함 등은 개발사의 책임 범위에서 제외해야 합니다. "을은 본 사업과 관련하여 발생하는 모든 장애에 책임을 진다"와 같은 포괄적인 문구는 위험합니다.

2) 대응 시간(SLA)이 현실적인가?

하자 발생 시 "즉시 수리해야 한다"는 표현보다는 "장애 접수 후 24시간 이내에 원인 파악 및 조치 계획을 공유한다"와 같이 구체적인 프로세스를 정하는 것이 실무적으로 적절합니다.

3) 하드웨어 및 외부 환경 변화에 대한 면책 조항이 있는가?

OS(Android, iOS) 업데이트나 크롬 브라우저의 정책 변경으로 인해 발생하는 문제는 '하자'가 아닙니다. 이는 변화된 환경에 맞추는 '업데이트' 영역이므로 무상 보수 범위에서 제외하는 것이 공정합니다.

5. 마치며: 계약서 한 줄이 수천만 원을 결정합니다

IT 용역 하자보수 분쟁은 결국 '문구의 모호함'에서 시작됩니다. "성실히 협의하여 결정한다"는 식의 표현은 분쟁 상황에서 아무런 힘이 되지 못합니다. 법적 근거에 기반하여 기간과 범위를 명확히 설정하는 것이 갑과 을 모두가 상생하는 길입니다.

지금 검토 중인 IT 계약서에 우리 회사에 불리한 독소 조항이 있지는 않나요? 혹은 너무 막연한 표현으로 나중에 발목을 잡힐까 걱정되시나요?

전문적인 법률 지식 없이도 AI를 통해 계약서의 위험 요소를 즉시 파악할 수 있습니다. 복잡한 하자보수 조항, 이제 BeforeUSign으로 명쾌하게 검토해 보세요.