MVP·시제품 외주개발 계약 점검
MVP·시제품 외주개발 계약,
서명 전 8가지를 확인하세요.
MVP·시제품 외주개발 분쟁은 개발 자체보다 “어디까지가 계약 범위인지”,
“무엇을 넘겨받는지”, “변경 요청은 어떻게 처리하는지”가 불명확해서 발생하는 경우가 많습니다.
계약 전 기준을 문서로 남기는 것이 중요합니다.
계약서에서 가장 중요한 4가지
범위 · 완료기준 · 권리 · 인수인계
금액과 일정만 확인하지 말고 개발 종료 후 서비스를 계속 운영할 수 있는 조건까지 확인하세요.
계약 문구는 프로젝트마다 달라질 수 있습니다.
아래 내용은 개발 계약을 검토할 때 확인할 실무 항목을 정리한 일반적인 가이드입니다.
개별 계약의 법률적 판단이나 분쟁 가능성이 있는 조항은 필요에 따라 법률 전문가의 검토를 받는 것이 좋습니다.
계약 8개 영역
외주개발 계약 전 8개 영역 확인
체크되지 않은 항목은 계약 전에 협의
01
무엇을 만드는가
개발 범위
분쟁 가능성 높음
개발 기능 목록이 문서로 첨부되어 있는가?“웹서비스 개발”처럼 포괄적으로 적지 말고 기능·화면·관리자 범위를 명확히 합니다.
확인: 요구사항서·화면목록·기능목록을 계약 부속서로 첨부
포함 항목과 제외 항목이 구분되어 있는가?디자인, 데이터 이관, 서버, 외부 API, 앱스토어 등록 등을 구분합니다.
확인: “별도 협의” 항목이 지나치게 많지 않은지
착수금·중도금·잔금 지급 조건이 결과물과 연결되어 있는가?단순 날짜보다 단계별 산출물 확인 후 지급하는 구조가 명확합니다.
예: 착수 / 1차 검수 / 최종 검수 완료 기준
일정 지연 시 책임 기준이 정해져 있는가?발주자 요청 변경으로 인한 지연과 개발업체 귀책 지연을 구분합니다.
확인: 일정 변경 승인 절차 포함
03
바뀔 때
요구사항 변경
분쟁 가능성 높음
추가개발과 오류수정의 기준이 있는가?기존 합의 기능이 동작하지 않는 것과 새로운 기능 요청을 구분합니다.
확인: 변경 요청서 → 영향도 → 비용·일정 승인 절차
변경 요청 시 비용 산정 방식이 정해져 있는가?구두 요청으로 개발이 진행되지 않도록 승인 절차를 둡니다.
확인: 추가비용 발생 전 서면 승인
“개발 완료”의 기준이 명확한가?화면 구현만이 아니라 주요 기능 동작, 오류 수정, 배포까지 범위를 확인합니다.
예: 테스트 서버 → 검수 → 수정 → 운영 반영
검수 기간과 수정 절차가 정해져 있는가?검수 요청 후 며칠 이내 확인하고 발견된 하자를 어떻게 수정할지 정합니다.
확인: 검수기간, 재검수, 완료확인 절차
소스코드 인도 시점과 범위가 명시되어 있는가?최종 ZIP 파일만이 아니라 실제 개발에 사용한 전체 코드와 저장소 인계 범위를 확인합니다.
확인: 프론트·백엔드·DB 스크립트·설정파일 범위
저작권과 사용권 조건이 계약서에 명확한가?개발비 지급만으로 모든 권리가 자동 이전된다고 단정하지 말고 계약 문구를 확인합니다.
필요 시 전문 법률 검토 권장
오픈소스·상용 라이선스 사용 내역을 확인할 수 있는가?제3자 라이브러리 사용으로 발생할 수 있는 라이선스 조건을 파악합니다.
확인: 라이선스 목록 및 비용 부담 주체
06
계정 통제
서버·도메인·계정
운영 연속성
도메인과 클라우드 계정이 발주자 명의로 관리되는가?개발업체 계정에만 서비스가 묶이지 않도록 운영 주체를 명확히 합니다.
권장: 발주자 계정 생성 후 개발자 권한 부여
Git·앱스토어·외부 API 계정도 인계 대상인가?서비스 운영에 필요한 모든 접근권한을 목록으로 관리합니다.
확인: 관리자 계정 및 권한 회수 절차
무상 하자보수 기간과 범위가 명확한가?운영 중 발견된 오류가 언제까지 무상 수정 대상인지 확인합니다.
확인: 기간 + 하자의 정의 + 대응시간
유지보수 계약을 하지 않아도 인수인계가 가능한가?특정 업체와 계속 계약해야만 서비스가 운영되는 구조인지 확인합니다.
중요: 타 업체 유지보수 가능 여부
08
끝날 때
계약 종료·인수인계
반드시 확인
중도 종료 시 현재까지 개발된 결과물을 받을 수 있는가?계약 해지 상황에서도 지급된 비용 범위에 해당하는 결과물의 처리 기준을 확인합니다.
확인: 소스·문서·계정·데이터 처리
최종 인수인계 항목이 목록으로 정의되어 있는가?“관련 자료 일체”보다 실제 넘겨받을 자료를 구체적으로 적는 것이 좋습니다.
계약 부속서: 인수인계 산출물 목록
다시 볼 표현
계약서에서 다시 확인해야 할 표현
표현 1
“기타 필요한 사항”
범위가 지나치게 포괄적이면 발주자와 개발업체 모두 서로 다른 기대를 가질 수 있습니다.
표현 2
“개발 완료 시 지급”
무엇을 기준으로 완료인지 정의되지 않으면 잔금 지급 시점에서 갈등이 생길 수 있습니다.
표현 3
“소스 제공 가능”
가능 여부가 아니라 언제, 어떤 범위와 형태로 제공되는지를 계약서에 명시하는 것이 좋습니다.
인수인계 항목
계약서 부속서에 넣을 인수인계 항목
항목별 기준을 부속서 문구로 활용하세요
코드·데이터
- 전체 소스코드운영 중인 버전과 일치하는 최종본
- Git 저장소 및 이력커밋 이력 포함, 발주자 계정으로 이전
- DB 구조·스크립트스키마, 초기 데이터, 마이그레이션 스크립트
계정·인프라
- 서버·클라우드 계정소유자 권한과 결제 수단 이전
- 도메인·DNS 정보등록 계정과 DNS 설정값
- 외부 API 계정·키발급 계정과 키 재발급 방법
- 관리자 계정최고 권한 계정, 인계 후 비밀번호 변경
원본·권리
- 디자인 원본편집 가능한 원본 파일
- 오픈소스·라이선스 목록사용 라이브러리와 라이선스 조건
운영 자료
- 배포·운영 방법빌드·배포 절차와 환경 설정
- 테스트 결과·미해결 이슈검수 결과와 남은 이슈 목록
- 운영·유지보수 문서장애 대응, 백업, 주요 설정 설명
서명 전
계약서에 서명하기 전, 이 질문에 답할 수 있어야 합니다.
“개발이 끝났을 때 무엇을 받아야 하는가?”
“요구사항이 바뀌면 어떻게 처리하는가?”
“개발업체가 바뀌어도 서비스를 계속 운영할 수 있는가?”
이 세 질문의 답이 계약서에 반영되어 있다면 개발 이후의 불확실성을 크게 줄일 수 있습니다.