IT 외주는 분쟁이 가장 많은 영역입니다. 결과물의 "완성"이 모호하고, 클라이언트가 도중에 요구사항을 바꾸고, 운영 중 발견된 버그를 무한히 책임지라고 하기 때문입니다.
이 글은 한국 개발자·SI 프리랜서가 실제로 자주 분쟁에 휘말리는 5가지 계약 조항과, 민법·하도급법 근거의 협상 문구를 정리합니다.
1. 납품(완성) 정의의 모호성
가장 흔한 분쟁입니다. "정상 작동하는 프로그램을 납품한다" 같은 추상적 문구만 적혀 있고, 무엇이 "정상 작동"인지 정의가 없습니다.
실제 사례
개발자 A는 쇼핑몰 사이트를 6개월에 걸쳐 개발하고 납품했습니다. 그런데 클라이언트가 "결제 모듈에 가끔 오류가 난다"며 잔금 지급을 거부했습니다. 계약서에는 "정상 작동"이라고만 적혀 있었고, 어떤 부하 조건에서 어떤 응답시간을 만족해야 하는지 명시가 없었습니다.
협상 문구
"본 계약의 납품(완성)은 다음 기준을 모두 충족한 시점으로 한다.
① 요구사항 정의서(별첨 1)의 기능 100% 구현
② 단위 테스트 통과율 OO% 이상
③ 클라이언트의 검수 환경에서 주요 시나리오 OO개가 정상 처리됨
④ 별첨 2의 성능 기준(응답시간·동시접속자) 충족
위 기준을 충족하는 시점에 자동으로 납품 완료된 것으로 간주한다."
핵심: 요구사항 정의서를 별첨으로 첨부하고 거기에 모든 기능을 명시. 추가 기능은 별도 변경 계약(Change Request).
2. 인수 검수 무기한 — 검수 deemed 조항 부재
납품 후 클라이언트가 검수를 무한히 지연시키는 패턴입니다. 검수 안 끝나면 잔금도 못 받습니다.
실제 사례
개발자 B는 앱을 납품했는데, 클라이언트가 4개월간 검수를 미뤘습니다. 그동안 추가 기능 요청이 들어왔고, B는 "이미 납품 완료했다"고 주장했지만 계약서에 검수 기한이 없어 결국 추가 작업을 무료로 해야 했습니다.
협상 문구 — 검수 간주(Deemed Acceptance)
"도급인은 수급인의 납품 통지일로부터 영업일 기준 14일 이내에 검수 결과를 서면(이메일 포함)으로 통지한다. 위 기간 내 통지가 없는 경우 본 계약 결과물은 검수에 합격한 것으로 간주되며, 잔금이 자동으로 지급기일에 도래한다.
검수에서 발견된 결함은 다음과 같이 처리한다.
① 본 계약 요구사항 정의서에 명시된 기능의 미구현·오작동: 무상 수정
② 요구사항 정의서에 없는 추가 기능 요청: 별도 견적 후 진행"
3. 무한 유지보수 / 하자담보 무기한
납품 후 1년, 2년이 지나도 "버그 났으니 고쳐달라"는 요청이 무료로 들어오는 경우입니다.
법적 기준
민법 제670조(수급인의 담보책임)에 따라 도급인은 일의 목적물에 하자가 있는 때에 그 하자의 보수 또는 손해배상을 청구할 수 있습니다. 그러나 하자담보책임의 존속기간은 인도일로부터 1년(제671조 제1항)이 원칙이며, 토지·건물 등은 5년·10년(제2항).
소프트웨어는 명시적 규정이 없어 일반 도급에 준하며, 특약이 없으면 1년이 합리적입니다. 그런데 계약서에 "납품 후 영구 무상 유지보수"가 들어가 있다면 1년이 무한이 됩니다.
협상 문구
"수급인의 무상 하자보수 의무는 다음과 같다.
① 인도일로부터 90일 이내 발견된 결함: 무상 수정 (단, 도급인 또는 제3자의 변경·운영 환경 변화로 인한 것은 제외)
② 위 기간 이후 발생한 결함 또는 추가 기능 요청: 별도 유지보수 계약(월 OO원) 또는 시간당 OO원의 기술지원 요금
③ 본 계약 종료 후 운영·유지보수에 따른 모든 책임은 도급인에게 귀속된다."
4. 소스코드 전부 양도 + 라이브러리 권리 침해
클라이언트가 "소스코드 일체와 모든 권리를 양도"라고 적었는데, 개발자가 일반적으로 보유한 범용 라이브러리·내부 프레임워크까지 묶이는 패턴입니다.
왜 문제인가
대부분의 개발자는 자신만의 인증 모듈·UI 컴포넌트·유틸리티 라이브러리를 가지고 다음 프로젝트에 재사용합니다. 그런데 "소스코드 일체 양도"라고 하면 이 자산을 다른 곳에서 쓸 수 없게 됩니다.
또한 오픈소스 라이브러리(MIT·Apache·GPL 등) 사용 시, 라이선스 의무를 클라이언트가 인지하지 못하면 추후 분쟁의 원인이 됩니다.
협상 문구
"본 계약에서 도급인에게 양도되는 권리의 범위는 다음으로 한정한다.
① 본 프로젝트를 위해 신규 작성된 비즈니스 로직 및 UI 코드의 저작재산권
② 제외 대상:
ㄱ. 수급인이 본 계약 이전부터 보유하던 범용 라이브러리·내부 프레임워크·유틸리티 (별첨 3 목록 참고)
ㄴ. 오픈소스 라이브러리 (각 라이브러리의 원 라이선스 적용)
ㄷ. 외부 SaaS·API의 사용권
③ 수급인은 ②ㄱ에 대해 도급인에게 비독점 영구 사용권을 부여한다.
④ 도급인은 ②ㄴ의 오픈소스 라이선스 의무(고지·공개 등)를 준수할 의무가 있다."
5. 손해배상 무제한 — 책임 캡(Cap) 부재
IT 외주에서 가장 위험한 조항입니다. 시스템 장애·데이터 유출·서비스 중단 등은 클라이언트의 매출에 직접 영향을 미치며, "장애 시간 동안의 매출 손실"이 청구되면 프리랜서 인생이 끝날 수 있습니다.
실제 사례
개발자 C는 이커머스 사이트를 ₩3,000만원에 개발했습니다. 출시 1년 후 결제 모듈에서 버그가 발견되어 6시간 서비스 중단. 클라이언트는 "그 6시간 매출 손실 ₩2억"을 청구했습니다. 계약서에는 "수급인은 일체의 손해를 배상한다"고만 적혀 있었습니다.
협상 문구
"수급인의 책임 범위는 다음과 같이 한정한다.
① 책임 사유: 고의 또는 중과실로 인한 직접적·통상적 손해에 한정
② 책임 한도(Cap): 사유를 불문하고 본 계약 총 금액(또는 사유 발생 직전 12개월간 지급된 금액 중 적은 것)을 초과하지 아니한다
③ 제외 대상: 간접손해, 일실이익, 매출 손실, 영업권 손실, 데이터 손실, 평판 손해 등 부수적·특별 손해
④ 위 한도는 다음의 경우 적용되지 않는다: (가) 수급인의 고의·중대한 과실로 인한 비밀유지 위반, (나) 제3자의 지적재산권 침해 (단, 도급인 제공 자료에 기인한 것은 제외)"
이 조항만 잘 챙겨도 최악의 시나리오를 방지할 수 있습니다. 책임 한도를 계약 금액 이내로 캡 하는 것이 글로벌 IT 계약의 표준이기도 합니다.
요약 — 개발 용역 5대 체크리스트
- 납품 정의 명확화. 요구사항 정의서를 별첨.
- 검수 기한 + 간주 합격. 14~21일 내 통지 없으면 자동 합격.
- 하자담보 기간 한정. 90일~1년 + 그 이후는 별도 유지보수 계약.
- 소스코드 양도 범위 한정. 범용 자산·오픈소스는 제외.
- 손해배상 캡. 계약 금액 이내, 간접손해 제외.
분쟁이 이미 시작되었다면
본 글은 사인 전 단계 가이드입니다. 이미 계약을 사인했고 분쟁이 시작되었다면, 즉시 변호사·하도급분쟁조정협의회·중소기업중앙회 분쟁조정 등에 상담하세요.
사인 전이라면 redline에서 한국법 기준으로 본인 계약서를 1분에 확인할 수 있습니다. 위험 조항은 빨간줄, 협상에 그대로 쓸 수 있는 수정 문구도 함께 받을 수 있습니다.