외주 계약서에서 반드시 확인해야 할 5가지 함정

외주 개발 프로젝트가 실패하는 가장 큰 이유 중 하나는 계약서를 제대로 확인하지 않는 것입니다. 개발이 끝난 후에야 '소스코드가 내 것이 아니었다'거나 '수정을 요청하니 추가 비용을 요구한다'는 사실을 알게 되는 경우가 비일비재합니다.

함정 1: 소스코드 소유권이 명시되지 않은 계약

놀랍게도 많은 외주 계약서에 소스코드 소유권 조항이 빠져 있습니다. 이 경우 법적으로 저작권은 개발사에 귀속됩니다. 나중에 다른 개발자에게 유지보수를 맡기려 해도 코드를 넘겨받을 수 없는 상황이 발생합니다.

반드시 확인할 것:

• "납품 완료 후 소스코드 일체의 저작권은 갑(클라이언트)에게 양도한다" 문구 포함 여부
• 소스코드뿐 아니라 디자인 파일, DB 스키마, API 문서 등 산출물 전체를 포함하는지
• 오픈소스 라이선스 사용 목록을 제공하는지

함정 2: 수정 횟수 제한

"수정 3회 포함" 같은 조건이 있다면 주의하세요. 소프트웨어 개발에서 수정 3회는 사실상 아무것도 아닙니다. 기획 변경, 디자인 피드백, QA 이슈 등 수정은 필연적으로 발생합니다.

좋은 계약: 마일스톤별 피드백 주기를 명시하고, 각 마일스톤 내 합리적 수정을 포함 나쁜 계약: 전체 프로젝트에 수정 N회로 제한

함정 3: 모호한 범위 정의

"쇼핑몰 개발 일체"처럼 범위가 모호한 계약은 분쟁의 씨앗입니다. 개발사는 최소한으로, 클라이언트는 최대한으로 해석합니다.

범위 정의에 포함되어야 할 것:

• 기능 목록(요구사항 명세서) 별도 첨부
• 화면(페이지) 목록과 각 화면의 기능
• 포함되지 않는 항목 명시 (예: SEO 최적화, 콘텐츠 입력 등)

함정 4: 하자보수 기간과 범위

출시 후 버그가 발견됐는데 "계약 범위 밖"이라고 하면 곤란합니다. 최소 3개월의 무상 하자보수 기간을 명시하세요.

• 하자보수 범위: 개발사 과실로 인한 버그 수정
• 응답 시간: 긴급 이슈 24시간 내, 일반 이슈 72시간 내
• 하자보수 후 유지보수 계약은 별도 협의

함정 5: 중도 해지 조건 부재

프로젝트가 잘못되고 있는데 해지 조건이 없으면, 결과물 없이 비용만 날리게 됩니다. 계약서에 반드시 포함할 것:

• 일정 지연 시 해지 가능 조건 (예: 2주 이상 지연)
• 해지 시 기납품 산출물의 귀속
• 해지 시 비용 정산 방법 (마일스톤 기준)

VibeBuild가 다른 이유

VibeBuild는 이런 계약서 리스크를 구조적으로 제거했습니다. 무료 MVP를 먼저 확인하고, 마음에 들 때만 계약하니까요. 소스코드 100% 양도, 투명한 마일스톤, 명확한 범위 정의가 기본입니다. 외주 계약이 처음이라 불안하다면, 부담 없이 상담부터 시작하세요.