IT 용역 하자보수 기간과 범위, 분쟁 없는 공정한 계약 기준 가이드

소프트웨어 개발의 끝은 '완료'가 아닌 '시작'입니다

많은 기업과 프리랜서가 IT 용역(소프트웨어 개발) 계약을 체결할 때, 서비스의 기획과 개발 비용에만 집중하곤 합니다. 하지만 정작 프로젝트가 끝나고 결과물을 인도받은 시점부터 진짜 갈등이 시작되는 경우가 많습니다. 바로 **'IT 용역 하자보수'**에 관한 문제입니다.

개발된 프로그램에 오류가 발생했을 때, 이를 누가 어디까지 책임질 것인가에 대한 기준이 모호하면 발주사(갑)는 "이것도 안 되는데 당연히 고쳐줘야지"라고 주장하고, 개발사(을)는 "이건 추가 요구사항이니 비용을 내야 한다"며 대립하게 됩니다.

오늘은 BeforeUSign에서 IT 용역 계약서 작성 시 반드시 확인해야 할 공정한 하자보수 기간과 범위에 대해 법적 근거를 바탕으로 상세히 정리해 드립니다.

IT 용역에서 '하자'의 법적 정의와 기준

먼저 무엇을 '하자'로 볼 것인지 명확히 해야 합니다. 민법 제667조(수급인의 담보책임)에 따르면, 완성된 목적물에 하자가 있는 때에는 도급인은 수급인에 대하여 상당한 기간을 정하여 그 하자의 보수를 청구할 수 있습니다.

IT 환경에서 하자는 보통 다음과 같은 경우를 의미합니다.

• 과업지시서나 기획안에 명시된 기능이 정상적으로 작동하지 않는 경우
• 프로그램의 논리적 오류로 인해 데이터 수집 및 가공이 잘못되는 경우
• 보안 취약점이 발견되어 서비스 운영에 심각한 차질을 주는 경우
• 사전에 합의된 성능 기준(응답 속도, 동시 접속자 수 등)에 미달하는 경우

하자와 유지보수의 차이점을 아시나요?

많은 분이 '무상 하자보수'와 '유상 유지보수'를 혼동합니다. 이 둘을 명확히 구분하지 않으면 계약 종료 후 불필요한 분쟁에 휘말릴 수 있습니다.

• 하자보수(Warranty): 개발 단계에서 이미 존재했던 오류나 결함을 수정하는 것 (보통 무상)
• 유지보수(Maintenance): 완성된 서비스에 새로운 기능을 추가하거나, 운영 환경의 변화(OS 업데이트 등)에 따라 시스템을 최적화하는 것 (보통 유상)

공정한 하자보수 기간은 얼마일까?

가장 질문이 많은 부분은 "몇 달 동안 무료로 고쳐주는 게 관례인가요?"라는 점입니다.

1. 법적 근거 (민법과 소프트웨어 진흥법)

우리 민법 제670조와 제671조에 따르면 도급계약의 하자담보책임 기간은 목적물을 인도받은 날로부터 1년을 원칙으로 합니다. 또한 과학기술정보통신부에서 고시한 '소프트웨어사업 표준계약서'에서도 하자담보책임 기간을 1년으로 권장하고 있습니다.

2. 업계 관행과 실무적 합의

실무에서는 프로젝트의 규모와 성격에 따라 다음과 같이 협의하는 것이 일반적입니다.

• 단기 프로젝트(3개월 미만): 3개월 ~ 6개월
• 일반적인 솔루션/웹 구축: 1년
• 대규모 시스템(SI): 1년 이상 (검수 완료 후 기간 설정)

하자의 범위, 어디까지 책임져야 할까?

하자보수의 범위를 '소프트웨어 전체'라고 뭉뚱그려 작성하면 위험합니다. 다음과 같은 구체적인 제한 사항을 두는 것이 공정합니다.

3. 무상 하자보수 제외 대상 설정

다음에 해당하는 경우에는 개발사에게 무상 책임을 묻기 어렵다는 점을 계약서에 명시해야 합니다.

• 발주사가 임의로 소스코드를 수정하여 발생한 오류
• 발주사가 제공한 하드웨어, 운영체제(OS), 브라우저의 자체적인 결함
• 천재지변이나 제3자의 해킹 공격으로 인한 데이터 손실
• 개발 당시의 기술 수준으로는 예측할 수 없었던 보안 취약점

4. 하자보수 이행 보증금

발주사 입장에서는 개발사가 하자보수를 차일피일 미루거나 연락이 두절될까 걱정될 수 있습니다. 이때는 '하자보수이행보증금' 제도를 활용할 수 있습니다. 통상 계약 금액의 2~5% 정도를 보증금율로 설정하며, 현금 대신 보증보험 증권으로 대체하는 경우가 많습니다.

분쟁을 예방하는 계약서 작성 팁

실제 법원 판례를 살펴보면, 하자 여부를 판단할 때 가장 중요한 근거는 **'과업지시서'**와 **'수락 검수 문서'**입니다.

1. 상세한 과업지시서 첨부: "로그인 기능을 구현한다"가 아니라 "OAuth 2.0 기반의 구글/카카오 소셜 로그인을 구현하며, 특정 오류 코드 발생 시 사용자에게 알림을 띄운다"와 같이 구체적이어야 합니다. 그래야 하자인지 아닌지를 객관적으로 판별할 수 있습니다.
2. 검수 확인서 작성: 프로젝트가 끝날 때 반드시 '검증' 과정을 거치고 양측이 서명한 검수 확인서를 남기세요. 이 시점에 발견되지 않은 중대한 하자가 나중에 발견되었을 때만 하자보수를 청구하는 식으로 범위를 좁힐 수 있습니다.

하도급법 준수 여부 확인

만약 귀사가 대기업으로부터 용역을 받는 중소기업(수급인)이라면 '하도급거래 공정화에 관한 법률'의 보호를 받습니다. 원사업자가 부당하게 긴 하자담보책임 기간을 강요하거나, 하자보수 범위를 넘어서는 유지관리를 무상으로 강요하는 것은 불공정 거래 행위에 해당할 수 있습니다.

결론: 명확한 기록이 최고의 방어입니다

IT 용역 하자보수 분쟁은 결국 '서로 생각하는 범위가 달랐기 때문'에 발생합니다. 계약 체결 단계에서부터 하자보수의 기간, 범위, 제외 대상을 명확히 정의하고, 이를 문서화하는 것만이 양측의 신뢰를 지키고 비즈니스를 성공으로 이끄는 길입니다.

지금 작성 중인 IT 용역 계약서의 하자보수 조항이 너무 불리하거나 모호하지 않은지 걱정되시나요? 법률 전문가의 시각을 담은 AI가 단 몇 초 만에 독소 조항을 찾아내고 대안을 제시해 드립니다.