기능만 적으면 '완료'가 달라진다

외주 계약서에는 보통 '로그인 기능', '결제 모듈', '디자인 시안' 같은 기능 목록이 길게 적혀 있다. 사업자 입장에서는 그 목록을 모두 구현하면 '납품했다'고 생각한다. 그런데 고객은 '기능은 있는데 버그가 많다', '속도가 느리다', 'UI가 마음에 안 든다'며 추가 수정을 요청한다.

문제는 '완료'의 정의가 계약서에 없다는 것이다. '기능을 다 만들었다'와 '버그 없이 완벽하게 작동한다'는 전혀 다른 의미이지만, 계약서에 이 차이가 담겨 있지 않으면 양쪽 입장이 계속 충돌한다. 한쪽은 기능 체크리스트를 마쳤으니 완료라고 주장하고, 다른 한쪽은 자신의 기준에 맞을 때까지 수정해야 한다고 본다.

'완료의 기준'은 기능 목록과 분리해서 적어야 한다

계약서에 기능과 완료 기준을 함께 섞어 쓰면 나중에 해석이 엇갈린다. 별도 항목으로 구분하면 혼동을 줄일 수 있다.

예를 들어, 앱 개발 프로젝트라면 이렇게 나눈다: • 기능 목록: '회원가입', '로그인', '상품 검색', '장바구니' • 완료 기준: '기능 단위로 기획서 대로 작동하며, 협의된 브라우저에서 오류 없이 로드되고, 테스트 케이스 10개를 모두 통과하며, 합의된 성능 기준(페이지 로드 2초 이내)을 만족할 때'

완료 기준은 객관적인 지표들로 이루어져야 한다. '예쁜 디자인', '좋은 사용성' 같은 주관적 표현은 피하고, '픽셀 완벽성 ±2px 범위', '색상 코드 일치', '폰트 크기 지정 대로' 같이 측정 가능한 것들을 넣는다.

계약서에 명시해야 할 구체적 항목들

기능과 완료 기준 외에, 계약서에 꼭 들어가야 할 항목들이 있다.

첫째, '수정 범위'다. "계약 기능 내에서 발견되는 버그 수정은 포함하고, 기획 변경이나 새 기능 추가는 별도 비용 청구"라는 식으로 명확히 한다. 고객이 프로젝트 도중 요구사항을 자주 바꾸는 경우, '기능 변경은 월 1회, 2회차부터 비용 추가' 같이 횟수도 정할 수 있다.

둘째, '인수 기준'이다. '사업자가 납품물을 제출한 후, 고객이 검수 기간 7일 내에 수정 요청을 하지 않으면 인수 완료로 간주한다'는 조항을 넣으면, 무한정의 재작업 요청을 차단할 수 있다. 기술 관련 계약에서는 보통 5~10일의 검수 기간을 명시한다.

셋째, '테스트 환경과 최종 환경의 차이'다. '사업자는 협의된 테스트 환경에서만 동작 보장하고, 고객 서버에 올렸을 때 문제가 생기면 고객의 서버 설정 검토 후 추가 비용 청구'라고 적어 두면, 나중에 서버 환경 문제로 인한 분쟁을 줄일 수 있다.

'납품'과 '검수'를 구분해서 일정을 잡는다

일정 관리도 같은 원리다. 계약서에 '개발 완료 예정일'과 '검수 완료 예정일'을 따로 적는다. 많은 계약서가 이 둘을 구분하지 않아서 문제가 생긴다.

개발 완료 후 고객의 검수 기간을 따로 두어야 한다. 예를 들어 "6월 30일 개발 완료, 7월 7일까지 검수 기간, 7월 15일까지 수정 사항 반영, 7월 20일 최종 인수"라고 명시하면, 둘 다 언제까지 움직여야 하는지 알 수 있다. 검수 기간 동안 고객의 피드백이 없으면 그 항목은 승인된 것으로 간주한다는 조항도 넣으면 일정 슬립을 줄일 수 있다.

계약서 작성할 때 확인할 체크리스트

계약서를 다시 검토할 때 이 항목들이 빠져 있지는 않은지 확인해 보자.

□ 기능 목록은 명세서로 분리되어 있는가? □ 완료 기준이 객관적이고 측정 가능한가? (예: '버그 없음'이 아니라 '테스트 케이스 100개 통과', '성능 2초 이내' 같은 구체적 지표) □ 수정 범위와 추가 비용 기준이 명확한가? □ 검수 기간과 최종 인수일이 구분되어 있는가? □ 검수 기간 동안 고객 피드백이 없으면 자동 인수된다는 조항이 있는가? □ 테스트 환경과 고객 환경의 차이에 대한 책임이 구분되어 있는가? □ 납품 후 발견되는 버그의 정의와 책임 한계가 있는가? (예: '납품 1개월 이내 버그는 무상 수정, 그 이후는 유상')

이 항목들을 계약서에 넣는 것만으로도 나중의 분쟁 가능성이 크게 줄어든다. 사업자 입장에서는 무한정의 재작업을 막을 수 있고, 고객 입장에서는 자신의 기준이 어디까지 보장되는지 명확히 알 수 있다.

계약서 작성이 시간을 아낀다

처음에는 계약서를 디테일하게 작성하는 것이 번거워 보일 수 있다. 하지만 나중에 생기는 분쟁과 재작업에 드는 시간과 비용을 생각하면, 계약 단계에서의 투자가 훨씬 효율적이다.

특히 외주 사업에서는 고객과의 기대 차이가 그대로 손실로 이어진다. '완료의 기준'이 애매하면 고객의 무한 수정 요청에 응하느라 새로운 프로젝트를 받을 시간을 잃는다. 반대로 명확한 기준이 있으면 고객도 "이게 맞다"고 신뢰하고, 사업자도 "여기까지가 책임"이라는 선을 그을 수 있다.

다음 계약부터, 기능 목록 다음에 '이것을 완료된 상태라고 부르는 구체적인 조건'을 한 문단 더 추가해 보자. 그것이 나중의 재작업 시간을 큰 폭으로 줄이는 가장 간단한 방법이다.