외주 개발 분쟁이 생기는 이유는 계약서에 적혀있는 것 때문이 아닙니다. 적혀있지 않은 것 때문입니다. "이건 당연히 포함이죠"와 "이건 별도입니다"가 충돌하는 순간, 계약서를 펼쳐봤는데 해당 내용이 없으면 — 그때부터 분쟁입니다.

모호한 조항이 만드는 문제

계약서에 자주 등장하는 표현들이 있습니다.

"합리적인 범위 내에서"

"합리적인 범위 내에서 수정을 지원합니다." 합리적인 범위가 뭔가요? 클라이언트는 디자인 전체를 바꾸는 것도 합리적이라 생각할 수 있고, 개발사는 오타 수정 정도를 합리적이라 생각할 수 있습니다. 기준이 없으면 서로의 합리가 다릅니다.

"기술적으로 불가능한 경우 제외"

"기술적으로 불가능한 경우를 제외하고 구현합니다." 기술적으로 불가능한 것은 거의 없습니다. 다만 비용과 시간이 많이 들 뿐입니다. 이 표현은 개발사가 어려운 기능을 거절할 수 있는 포괄적인 면책 조항이 됩니다.

"상호 협의하에"

"일정 변경은 상호 협의하에 진행합니다." 한쪽이 협의를 거부하면? 협의가 안 되면 어떻게 하는지에 대한 규정이 없으면, 이 조항은 의미가 없습니다.

계약서에 반드시 명시해야 할 것

범위

기능 목록을 구체적으로 적어야 합니다. "쇼핑몰 개발"이 아니라, "상품 등록, 장바구니, 결제(카드/계좌이체), 주문 내역 조회, 관리자 상품 관리 — 이 기능을 포함한다"까지 적어야 합니다. 목록에 없는 기능은 추가 비용이라는 것도 함께 명시합니다.

일정 지연 패널티

납기일을 넘기면 어떻게 되는지. 클라이언트 귀책 사유(피드백 지연, 요구사항 변경)로 인한 지연은 어떻게 처리하는지. 양쪽 모두에게 적용되는 규정이 있어야 합니다.

소스코드 양도

프로젝트 완료 후 소스코드의 소유권이 누구에게 있는지. 잔금 지급 후 양도인지, 단계별 지급에 따라 부분 양도인지. "당연히 우리 거 아니에요?"라고 생각하지만, 계약서에 없으면 당연하지 않습니다.

사후 지원

무상 수정 기간은 얼마인지. 무상 수정의 범위는 어디까지인지. 버그 수정과 기능 추가의 기준은 무엇인지. 무상 기간 이후 유지보수 비용은 어떻게 산정하는지.

좋은 계약서의 기준

좋은 계약서는 문제가 없을 때는 필요 없습니다. 서로 신뢰하고, 소통이 잘 되고, 프로젝트가 순조로우면 계약서를 꺼내볼 일이 없습니다.

하지만 문제는 반드시 생깁니다. 일정이 지연되거나, 결과물이 기대와 다르거나, 추가 비용이 발생하거나. 그때 계약서를 펼쳤을 때 명확한 기준이 적혀있으면 분쟁이 아니라 협의가 됩니다. 기준이 없으면 감정 싸움이 됩니다.

계약서는 서로를 의심하기 위한 문서가 아닙니다. 문제가 생겼을 때 서로를 보호하기 위한 문서입니다.

*외주 개발 계약에 대해 상담이 필요하시다면, 프로젝트 상담을 통해 문의해 주세요. 명확한 범위와 조건으로 시작합니다.*