웹 외주 계약서에서 실제로 다투게 되는 다섯 줄

개발이 끝난 뒤에 벌어지는 다툼은 대개 코드가 아니라 문장에서 시작합니다. 아래 다섯 줄은 착수 전에 맞추면 몇 분이면 되고, 끝난 뒤에 맞추려면 몇 주가 걸립니다.

① "정상 동작하면 합격"은 검수 조건이 아니다

무엇이 되면 합격인지를 문장으로 정해 두지 않으면 합격 판정 자체가 협상이 됩니다. 테스트 시나리오와 항목별 통과 상태를 착수 때 서면으로 확정하고, 그 문서를 그대로 검수와 하자보수의 기준선으로 씁니다. 이걸 정하는 자리는 개발이 끝난 뒤가 아니라 시작 전입니다.

② 하자보수는 기간보다 기산점이 먼저다

"3개월이냐 12개월이냐"보다 "언제부터 세느냐"가 실무에서 더 자주 갈립니다. 납품일인지, 최종 검수합격일인지, 오픈일인지에 따라 같은 3개월이 전혀 다른 구간이 됩니다. 저희는 최종 검수합격일부터 3개월로 잡고, 그 날짜를 검수 결과 문서에 함께 적습니다.

③ 접근 권한을 주는 것과 소유권이 넘어가는 것은 다른 사건이다

붙여 쓰면 "권한을 줬으니 이전이 끝났다"로 읽힙니다. 저장소 접근은 계약이 확정되는 시점에 열고, 지식재산권 이전은 대금 완납 시점입니다. 두 문장으로 나눠 적어야 나중에 다투지 않습니다. 이전 대상에 소스코드만 적고 문서와 DB 스키마를 빠뜨리는 경우도 흔합니다.

④ 범위 변경은 어떤 형식이어야 효력이 생기는가

일상 소통은 메신저와 통화로 하는 편이 빠릅니다. 다만 범위·일정·금액에 영향을 주는 결정은 서면(이메일 포함)으로만 효력이 생긴다고 적어 두는 편이 양쪽에 안전합니다. 구두로 합의한 기능은 기억은 남아도 기록이 안 남고, 기억은 두 사람이 다르게 합니다.

⑤ 유지보수는 하자보수와 분리한다

상시 모니터링, 야간·주말 장애 대기, 기능 개선은 하자보수가 아닙니다. 계약 범위 안의 결함을 고치는 것이 하자보수이고, 나머지는 대응 시간과 범위를 정한 연 단위 계약입니다. 저희는 구축비의 약 12%를 기준으로 따로 산정합니다. 이걸 나누지 않으면 "무상 기간 안이니 해 달라"는 요청과 "그건 개선이라 별건입니다"라는 답이 계속 부딪힙니다.

이 다섯 줄은 저희 기본값이기도 합니다

비교해 보고 싶으시면 일하는 방식 페이지에 저희 기준을 그대로 적어 뒀습니다. (계약 실무 정리이며 법률 자문이 아닙니다.)