MVP 개발 계약 시 주의사항 — 대표가 꼭 확인할 5가지

결론부터

MVP 외주 분쟁의 90%는 계약서에서 시작됩니다. 코드를 한 줄 쓰기 전에 작업 범위, 대금 지급, 소스코드 소유권, 검수 기준, 해지 조건 — 이 5가지를 반드시 확인하세요.

왜 계약서가 중요한가

"잘 만들어주세요"로 시작해서 "이건 제가 요청한 게 아닌데요"로 끝나는 프로젝트가 많습니다. 대부분 기술력의 문제가 아닙니다. 계약서에 범위와 기준이 명확하지 않았던 것이 원인입니다.

특히 스타트업 대표가 첫 외주를 맡길 때 계약서를 꼼꼼히 보지 않는 경우가 많습니다. "좋은 사람이니 잘 되겠지"라는 생각은 프로젝트 중반에 무너집니다. 좋은 관계를 유지하려면 오히려 계약서가 명확해야 합니다.

1. 작업 범위: "기타 개발 일체"가 있으면 위험하다

계약서에서 가장 중요한 조항입니다. 범위가 모호하면 나머지 조항이 아무리 좋아도 소용없습니다.

확인 포인트:

• 작업 범위가 별첨 문서(작업범위정의서, 기능명세서 등)에 구체적으로 정의되어 있는가
• 포함되는 것과 포함되지 않는 것이 명시되어 있는가
• 추가/변경 요청 시 별도 견적 절차가 정의되어 있는가
• 구두 요청은 계약 범위에 포함되지 않는다는 조항이 있는가

경계해야 할 문구:

"을은 갑이 요청하는 개발 및 기타 필요한 업무 일체를 수행한다."

이 한 줄이 있으면 고객은 무엇이든 요청할 근거가 생깁니다. 디자인, 기획, 서버 운영, 마케팅 페이지까지 "기타 업무"에 포함될 수 있습니다.

이렇게 바꿔야 합니다:

"을의 작업 범위는 별첨 [작업범위정의서]에 명시된 기능 및 산출물로 한정한다. 별첨에 명시되지 않은 기능은 변경 견적서를 통해 별도 합의한다."

2. 대금 지급: "검수 후 일괄 지급"은 함정이다

3~6개월 개발하고 검수 후 한 번에 받는 구조는 개발사에게 매우 불리하고, 프로젝트 자체도 위험합니다. 고객 입장에서도 분할 지급이 더 안전합니다 — 단계별로 결과물을 확인할 수 있기 때문입니다.

확인 포인트:

• 총 금액이 부가세 별도로 명시되어 있는가
• 지급이 단계별(계약금 → 중도금 → 잔금)로 나뉘어 있는가
• 각 단계의 지급 시점과 기한이 구체적인가
• 지급 지연 시 어떻게 되는지 명시되어 있는가

경계해야 할 문구:

"대금은 갑의 최종 검수 후 일괄 지급한다." "갑의 내부 결재 완료 후 지급한다."

첫 번째는 전체 작업이 끝날 때까지 한 푼도 못 받는 구조입니다. 두 번째는 시점이 불명확합니다.

이렇게 바꿔야 합니다:

"계약금 30%: 계약 체결 후 7영업일 이내. 중도금 40%: 1차 검수 통과 후 7영업일 이내. 잔금 30%: 최종 검수 완료 후 7영업일 이내."

특히 계약금 없이 착수하는 업체는 주의하세요. 계약금은 프로젝트에 대한 양측의 진지함을 보여주는 최소한의 장치입니다.

3. 소스코드 소유권: "모든 소유권은 갑에게"를 그대로 넘기지 마라

소스코드를 누가 소유하는지는 프로젝트 이후에 큰 차이를 만듭니다. 소유권이 개발사에 남아 있으면 다른 업체로 이전하거나 내부 팀이 유지보수할 때 처음부터 다시 만들어야 할 수 있습니다.

반대로, 개발사가 이전 프로젝트에서 만들어둔 라이브러리나 프레임워크까지 고객에게 넘겨야 한다면 — 그 개발사는 다음 프로젝트에서 같은 코드를 쓸 수 없게 됩니다. 이건 양측 모두에게 좋지 않습니다.

확인 포인트:

• 대금 완납 시 소스코드 소유권이 고객에게 이전되는 구조인가
• 대금 미완납 시 소유권이 유보되는 조항이 있는가
• 개발사의 기존 라이브러리/프레임워크는 이전 범위에서 제외되는가
• 서버, 도메인, 앱스토어 계정이 고객 명의인가

경계해야 할 문구:

"본 프로젝트와 관련하여 을이 개발한 모든 소스코드, 라이브러리, 도구의 소유권은 갑에게 귀속된다."

이렇게 바꿔야 합니다:

"을이 본 프로젝트를 위해 '신규로 작성한' 소스코드의 소유권은 갑의 대금 완납 시 갑에게 이전된다. 을이 프로젝트 착수 전부터 보유한 라이브러리, 프레임워크는 이전 범위에서 제외하며, 갑에게는 운영에 필요한 비독점적 사용 라이선스를 부여한다."

4. 검수와 하자보수: "만족할 때까지 수정"은 끝이 없다

검수 기준이 없으면 프로젝트는 영원히 끝나지 않습니다. "뭔가 좀 다른데요"라는 피드백이 무한 반복되면, 개발사는 지치고 고객은 불만족하는 최악의 상황이 됩니다.

확인 포인트:

• 검수 기간이 명시되어 있는가 (예: 납품 후 14영업일)
• 검수 기준이 작업범위정의서 기준인가 (주관적 만족도가 아닌)
• 검수 기간 내 이의가 없으면 완료 간주되는 조항이 있는가
• 보완 횟수에 제한이 있는가 (예: 최대 2회)
• 하자보수 기간과 유지보수가 분리되어 있는가

경계해야 할 문구:

"갑은 을의 산출물에 대해 갑이 만족할 때까지 수정을 요청할 수 있다." "을은 납품 후 12개월간 무상으로 유지보수를 제공한다."

첫 번째는 검수가 끝나지 않습니다. 두 번째는 1년간 무료 노동이 됩니다.

하자보수와 유지보수의 차이:

구분	하자보수	유지보수
정의	납품 범위 내 버그 수정	새 기능, 운영, 서버 관리
기간	1~3개월 (프로젝트 규모에 따라)	별도 계약
비용	무상 (프로젝트 비용에 포함)	유상 (월 단위 계약)

이 둘을 섞어놓은 계약서가 많습니다. 반드시 분리하세요.

5. 해지와 손해배상: 일방적으로 불리한 구조가 아닌지

프로젝트가 중간에 멈출 수 있습니다. 고객 사정이 바뀌거나, 자금이 끊기거나, 방향이 달라질 수 있습니다. 그때 기 완료된 작업에 대한 정산이 어떻게 되는지가 핵심입니다.

확인 포인트:

• 해지 사유가 양쪽 모두에게 대칭적인가 (고객만 해지할 수 있는 구조가 아닌가)
• 해지 시 기 완료 작업에 대한 정산 방식이 있는가 (진행률 비례)
• 고객의 대금 미지급이 개발사의 해지 사유가 될 수 있는가
• 손해배상 총액에 상한이 있는가 (통상 계약 금액 이내)
• 간접 손해, 매출 손실 배상은 제외되는가

경계해야 할 문구:

"갑은 서면 통보로 언제든지 본 계약을 해지할 수 있으며, 을은 기 수령한 대금을 전액 반환한다." "을은 본 계약과 관련하여 갑에게 발생하는 모든 손해를 배상한다."

첫 번째는 3개월 일하고 전액 반환해야 하는 상황이 될 수 있습니다. 두 번째는 간접 손해, 매출 손실까지 무한 책임입니다.

이렇게 바꿔야 합니다:

"해지 시 기 완료된 작업에 대한 대금은 진행률에 비례하여 정산한다." "을의 배상 범위는 본 계약 총 대금을 상한으로 하며, 간접 손해 및 일실이익은 배상 범위에서 제외한다."

계약 전 체크리스트 요약

계약서에 서명하기 전에 이 5가지를 확인하세요.

• 작업 범위가 별첨 문서로 구체적으로 한정되어 있는가
• 대금이 단계별(계약금/중도금/잔금)로 분할 지급되는가
• 소스코드 소유권이 대금 완납 시 고객에게 이전되고, 개발사 기존 자산은 분리되어 있는가
• 검수 기간·기준·보완 횟수가 명확하고, 하자보수와 유지보수가 분리되어 있는가
• 해지 시 진행률 비례 정산이 있고, 손해배상에 상한이 있는가

하나라도 빠져 있다면, 서명 전에 수정을 요청하세요. 좋은 개발사는 이 요청을 거부하지 않습니다.

마무리

계약서는 관계가 좋을 때 만드는 보험입니다. 서로 신뢰하더라도, 범위·돈·소유권·검수·해지는 문서로 명확히 합의해야 합니다. 그래야 문제가 생겼을 때 감정이 아니라 계약서를 기준으로 해결할 수 있습니다.

MVP 계약이 처음이라 어떤 조항을 넣어야 할지 모르겠다면, 요구사항과 함께 문의해 주세요. 범위 정의부터 계약 구조까지 함께 정리해 드리겠습니다.