외주 개발에서 가장 큰 트러블이 발생하는 지점은 기술이 아니라 계약서입니다. 대부분의 분쟁은 "그건 그때 말 안 했잖아요"에서 시작되고, 이때 기준이 되는 게 계약서입니다. 제가 여러 건 진행하며 정리한 체크리스트 9가지를 공개합니다.
1. 개발 범위(Scope)가 문서로 첨부되었는가
가장 중요한 단 하나. "쇼핑몰 웹/앱 개발" 같은 한 줄은 무효에 가깝습니다. 기능 목록·화면 목록·제외 항목이 별첨 문서로 붙어야 이후 "그건 포함이냐 아니냐" 분쟁이 줄어듭니다.
2. 산출물이 명확한가
단순히 "개발 완료"가 아니라 (1) 동작하는 서비스 URL, (2) 소스코드 전달 방식(Git 리포지토리 공유), (3) 배포·인프라 접근 계정, (4) 필요한 문서까지 리스트업. 특히 소스코드 인도 방식은 자주 빠지는 항목입니다.
3. 단가 구조 — 고정/시간제/성과
- 고정(Fixed): 범위가 또렷할 때. 범위 변경 시 변경 단가가 별도 명시돼야 함.
- 시간제(T&M): 변동성 큰 프로젝트. 상한선(cap)과 주간 리포트 의무가 보호 장치.
- 성과 연동: 드물지만 존재. 성과 측정 기준이 계량화돼야 함.
4. 일정과 지연 규정
단순히 "3개월"이 아니라 "착수일·중간 마일스톤·최종 인도일"을 각각 명시. 지연 시 페널티와 면책 조건(정책 변경·API 변경·클라이언트 피드백 지연)을 양쪽 모두 적으면 공정합니다.
5. 대금 지급 조건
일반적으론 착수금 30~40%, 중간 30~40%, 완료·인수 후 20~30%. 완료 후 전액 지급은 개발사에 과중, 100% 선금은 의뢰자에 과중입니다. 중간 지급 트리거도 구체화해야 합니다(예: "사용자 화면 90% 완성 시").
6. 검수·인수 기간
의뢰자가 산출물을 확인하고 수정 요청할 수 있는 기간(보통 2~4주)을 명시. 이 기간 내 통보 없으면 자동 검수 완료로 간주한다는 조항이 일반적입니다. 너무 길면 개발사에 불리, 너무 짧으면 의뢰자에 불리.
7. 유지보수 조건
"무상 유지보수 1~3개월 + 이후 유상"이 표준. 무상 기간에 포함되는 것(버그 수정)과 포함되지 않는 것(신기능 개발)을 반드시 구분. "사용자가 늘어 서버가 뻗는 것"은 버그인지 성능 개선인지 모호하므로 사전 명시 권장.
8. 지적재산권(IP)
기본은 대금 완납 후 의뢰자에게 귀속. 그러나 개발사가 보유한 프레임워크·라이브러리·재사용 모듈까지 넘기는 건 아닙니다. "프로젝트 고유 산출물은 의뢰자, 범용 구성요소는 개발사" 같은 구분 조항을 붙이면 좋습니다.
9. 해지·분쟁 조항
- 조기 해지: 어느 쪽이 해지할 수 있는지, 해지 시 지급·산출물 처리를 명시.
- 분쟁 해결: 협의 → 조정 → 관할 법원 순서. 관할은 서울중앙지방법원 기재가 일반적.
- 기밀유지(NDA): 계약 기간 + 종료 후 2~3년이 표준.
추가로 자주 빠지는 2가지
클라이언트 피드백 지연 규정: 의뢰자의 피드백이 7일 이상 늦어지면 전체 일정이 자동 연장된다는 조항. 없으면 개발사가 부당하게 책임을 지게 됩니다.
외부 서비스 비용 부담 주체: API 사용료·서버 요금·도메인 등. 개발비에 포함인지 별도인지 명시. 이게 없으면 나중에 월 수십만 원 단위의 분쟁 씨앗이 됩니다.
결론 — 계약서는 신뢰의 반대가 아니라 표현
좋은 계약서는 서로를 의심하는 문서가 아니라 서로의 기대를 정리한 문서입니다. 위 9개를 점검하는 데 한두 시간이면 됩니다. 그 한두 시간이 프로젝트의 나머지 수백 시간을 안전하게 만들어 줍니다.