외주 개발 계약서에 반드시 넣어야 할 항목 10가지

웹사이트나 웹서비스 개발을 외주로 맡길 때 계약서는 단순히 금액과 일정만 정하는 문서가 아닙니다.

개발 프로젝트는 제작 과정에서 요구사항이 구체화되거나 변경될 수 있고, 완료 여부를 판단하는 기준도 사람마다 다를 수 있습니다.

계약서가 불명확하면 다음과 같은 문제가 발생할 수 있습니다.

• 당연히 포함된 줄 알았던 기능이 제외됨
• 기능 추가 비용을 두고 갈등이 생김
• 검수와 완료 시점이 불분명함
• 소스코드를 받지 못함
• 서버와 계정이 개발 업체 명의로 남음
• 일정이 늦어져도 책임 기준이 없음
• 오류 수정과 유지보수 범위를 구분하기 어려움

따라서 계약 전에는 프로젝트의 특성에 맞게 범위, 일정, 검수, 산출물과 인계 조건을 구체적으로 정하는 것이 좋습니다.

아래 내용은 외주 개발 계약을 준비할 때 확인할 수 있는 실무 항목입니다. 개별 계약의 법적 판단이나 중요한 권리관계는 변호사 등 전문가의 검토를 받는 것이 안전합니다.

1. 프로젝트 목적과 개발 범위

계약서에서 가장 중요한 부분은 무엇을 만드는지입니다.

웹서비스 개발 일체처럼 추상적으로 작성하면 서로 다른 해석이 생길 수 있습니다.

가능하면 다음 내용을 구체적으로 정합니다.

• 서비스 목적
• 사용자 유형
• 사용자 기능
• 관리자 기능
• 외부 API
• 지원 기기
• 지원 브라우저
• 디자인 범위
• 서버와 배포
• 데이터 이전
• 다국어
• 제외 항목

범위 작성 예시

개발 범위

1. 사용자
- 이메일 회원가입과 로그인
- 비밀번호 찾기
- 프로필 조회와 수정
- 서비스 신청
- 결제 내역 조회

2. 관리자
- 회원 목록과 검색
- 신청 내역 조회
- 상태 변경
- 콘텐츠 등록·수정·삭제
- 엑셀 다운로드

3. 공통
- PC·모바일 반응형
- 운영 서버 배포
- 소스코드 제공

기능 목록은 계약서 본문이 아니라 별도 부속 문서나 요구사항 정의서로 관리할 수도 있습니다.

중요한 것은 계약서와 실제 기능 목록이 연결되어 있어야 한다는 점입니다.

2. 포함 범위와 제외 범위

포함되는 업무만큼 포함되지 않는 업무도 명확해야 합니다.

포함 범위 예시

• 요구사항 정리
• 디자인
• 프론트엔드
• 백엔드
• 관리자
• 테스트
• 서버 배포
• 운영 인계

제외 범위 예시

• 콘텐츠 작성
• 제품 사진 촬영
• 데이터 수작업 입력
• 외부 서비스 이용료
• 앱 개발
• 장기 유지보수
• 마케팅
• 검색 순위 보장

제외 범위가 명확하면 프로젝트 중간에 당연히 포함된 줄 알았다는 갈등을 줄일 수 있습니다.

3. 개발 일정과 단계별 마감

전체 완료일만 정하기보다 주요 단계별 일정을 함께 정하는 것이 좋습니다.

예시는 다음과 같습니다.

1단계 요구사항 확정: 8월 10일
2단계 주요 디자인 확정: 8월 25일
3단계 1차 개발본 공유: 9월 20일
4단계 전체 기능 개발: 10월 15일
5단계 검수와 수정: 10월 16일~10월 31일
6단계 운영 배포: 11월 5일

일정과 함께 다음 조건도 정해야 합니다.

• 의뢰사의 자료 제공 기한
• 피드백 기한
• 외부 서비스 심사 기간
• 요구사항 변경 시 일정 조정
• 불가항력과 외부 지연
• 일정 변경 통지 방식

개발 업체의 작업이 늦어진 경우와 의뢰사의 자료 제공이 늦어진 경우를 구분해야 합니다.

4. 개발 대금과 지급 조건

총금액뿐 아니라 지급 시점과 조건을 정합니다.

일반적인 방식은 다음과 같습니다.

선금·중도금·잔금

선금 30%: 계약 체결 시
중도금 40%: 주요 기능 개발 완료 시
잔금 30%: 최종 검수와 배포 완료 시

단계별 지급

기획, 디자인, 개발, 배포 단계별로 지급합니다.

확인할 항목은 다음과 같습니다.

• 부가세 포함 여부
• 세금계산서
• 지급 기한
• 지급 조건
• 외부 서비스 비용
• 추가 작업 단가
• 계약 종료 시 정산
• 지연 지급 처리

중도금 지급 기준은 진행률 50%처럼 추상적으로 정하기보다 확인 가능한 결과물과 연결하는 것이 좋습니다.

5. 요구사항 변경과 추가 비용

개발 중 요구사항이 바뀌는 경우가 많습니다.

다음 상황을 구분해야 합니다.

오류 수정

합의한 기능이 요구사항대로 작동하지 않는 경우

단순 수정

합의된 범위 안에서 문구나 위치를 일부 조정하는 경우

기능 변경

합의된 동작 방식을 다른 방식으로 바꾸는 경우

기능 추가

기존 요구사항에 없던 기능을 새로 만드는 경우

계약서에 다음 절차를 정할 수 있습니다.

1. 변경 요청을 문서로 전달한다.
2. 개발 업체가 비용과 일정 영향을 검토한다.
3. 양측이 추가 견적과 변경 일정을 합의한다.
4. 합의 후 작업을 진행한다.

구두 요청이나 메신저 한 줄만으로 범위가 변경되지 않도록 기록하는 것이 좋습니다.

6. 중간 결과물과 진행 보고

완성일까지 기다리지 않고 개발 상태를 확인할 방법을 정합니다.

• 주간 보고
• 테스트 URL
• 기능별 데모
• 디자인 시안
• 이슈 목록
• 회의
• 작업 관리 도구

계약 문구 예시

개발 업체는 주요 기능 단위로 테스트 가능한 결과물을 제공한다.

의뢰사는 결과물 제공 후 5영업일 이내 검토 의견을 전달한다.

정해진 기간 내 의견이 없는 경우 다음 단계 진행 여부를 별도로 협의한다.

프로젝트 규모와 진행 방식에 맞게 조정해야 합니다.

7. 검수 방법과 완료 기준

정상적으로 작동하는 상태만으로는 완료 여부를 판단하기 어렵습니다.

다음 내용을 정할 수 있습니다.

• 검수 기간
• 테스트 환경
• 오류 전달 방법
• 수정 횟수
• 오류 등급
• 재검수
• 최종 승인
• 운영 배포
• 검수 지연 처리

완료 기준 예시

- 합의한 기능이 작동한다.
- PC·모바일에서 주요 화면을 사용할 수 있다.
- 운영 서버에 배포한다.
- 관리자 계정을 제공한다.
- 소스와 주요 계정을 인계한다.
- 검수 중 확인된 중대 오류를 해결한다.

디자인의 주관적인 만족도를 완료 기준으로 사용하기보다 승인된 시안과 기능 정의를 기준으로 판단하는 것이 좋습니다.

8. 소스코드·저작권·산출물

개발 결과물의 권리와 제공 범위를 계약서에 명시해야 합니다.

확인할 항목은 다음과 같습니다.

• 소스코드 제공 여부
• 제공 시점
• 디자인 원본
• 데이터베이스
• 개발 문서
• 제3자 라이브러리
• 오픈소스
• 유료 플러그인
• 기존에 보유한 공통 코드
• 결과물의 사용·수정 권한

개발 업체가 기존에 보유한 공통 모듈과 이번 프로젝트를 위해 새로 만든 결과물의 권리가 다를 수 있습니다.

또한 오픈소스와 외부 라이브러리는 각 라이선스 조건의 영향을 받을 수 있습니다.

중요한 프로젝트라면 권리 이전 범위와 사용 조건을 전문가에게 검토받는 것이 좋습니다.

9. 서버·도메인·외부 계정의 소유와 인계

서비스 운영에는 소스코드 외에도 여러 계정이 필요합니다.

• 도메인
• 서버
• 데이터베이스
• 파일 저장소
• 결제
• 이메일
• 알림톡
• 소셜 로그인
• AI API
• 분석 도구
• Search Console
• 관리자 계정

계약서에서 다음을 정하는 것이 좋습니다.

• 누구 명의로 계정을 만드는가?
• 누가 비용을 결제하는가?
• 개발 업체가 접근할 권한은 어디까지인가?
• 계약 종료 후 권한을 회수하는가?
• API 키를 어떻게 인계하는가?
• 계정 복구 정보는 누가 보유하는가?

장기 운영할 서비스의 핵심 계정은 의뢰사 명의로 생성하는 것이 안전한 경우가 많습니다.

10. 하자보수와 유지보수

개발 완료 후 지원 범위를 구분해야 합니다.

하자보수

합의한 기능이 정상적으로 작동하지 않는 오류를 수정하는 기간입니다.

유지보수

• 콘텐츠 변경
• 새로운 기능
• 서버 관리
• 외부 API 변경
• 보안 업데이트
• 운영 지원

계약서에 다음 내용을 정할 수 있습니다.

• 무상 오류 수정 기간
• 오류 접수 방법
• 대응 시간
• 제외 조건
• 기능 추가 비용
• 월 유지보수 여부
• 서버 장애 대응
• 외부 서비스 변경 대응

3개월 무상 유지보수라고만 적기보다 무엇이 무상인지 구체적으로 정하는 것이 좋습니다.

추가로 확인하면 좋은 항목

비밀유지

개발 과정에서 다음 정보를 공유할 수 있습니다.

• 사업 아이디어
• 고객 정보
• 내부 데이터
• 재무 자료
• 소스코드
• 계정
• 영업 정보

필요하다면 비밀정보의 범위와 사용 목적, 보관·삭제 기준을 정합니다.

개인정보와 보안

개발 업체가 실제 회원 데이터에 접근할 수 있다면 다음을 확인합니다.

• 접근 가능 인력
• 테스트 데이터 사용
• 개인정보 다운로드
• 계정 공유 금지
• 보안 사고 통지
• 계약 종료 후 삭제
• 운영 데이터 접근 기록

민감한 개인정보를 다루는 경우 관련 전문가의 검토가 필요할 수 있습니다.

재하도급

계약한 업체가 일부 업무를 다른 개발자나 회사에 맡길 수 있습니다.

• 재하도급 허용 여부
• 사전 통지
• 비밀유지
• 책임 주체
• 실제 수행 인력

실제 투입 인력과 담당 범위를 계약 전에 확인하는 것이 좋습니다.

계약 해지와 중도 종료

프로젝트가 중단되는 경우를 대비해 다음을 정할 수 있습니다.

• 해지 조건
• 사전 통지
• 완료한 작업 정산
• 중간 산출물 제공
• 소스코드 제공
• 계정 반환
• 데이터 삭제
• 선급금 처리

양측 모두 프로젝트를 계속하기 어려운 상황에 대한 절차가 필요합니다.

손해와 책임

지연이나 장애에 대한 책임 범위는 프로젝트에 따라 달라질 수 있습니다.

과도하거나 불명확한 책임 조항은 분쟁의 원인이 될 수 있으므로 중요한 계약은 전문가 검토를 받는 것이 좋습니다.

분쟁 해결

• 협의 절차
• 통지 방식
• 관할
• 준거 규정

법률적 효력이 중요한 항목이므로 표준 문구를 그대로 복사하기보다 실제 계약에 맞게 확인해야 합니다.

계약서에 첨부하면 좋은 문서

계약서 본문만으로 모든 기능을 상세히 적기 어려울 수 있습니다.

다음 문서를 부속 문서로 연결할 수 있습니다.

• 요구사항 정의서
• 기능 목록
• 화면 목록
• 디자인 범위
• 개발 일정
• 견적서
• 산출물 목록
• 검수 체크리스트
• 유지보수 범위

각 문서의 버전과 작성일을 표시하고 어떤 문서가 우선하는지 정하는 것이 좋습니다.

계약 전 체크리스트

[ ] 프로젝트 목적이 적혀 있는가?
[ ] 사용자와 관리자 기능이 구분되어 있는가?
[ ] 포함·제외 범위가 명확한가?
[ ] 단계별 일정이 있는가?
[ ] 의뢰사의 자료 제공 기한이 있는가?
[ ] 대금 지급 조건이 결과물과 연결되어 있는가?
[ ] 변경 요청 처리 방식이 있는가?
[ ] 중간 결과물을 확인할 수 있는가?
[ ] 검수 기간과 완료 기준이 있는가?
[ ] 소스코드 제공 여부가 적혀 있는가?
[ ] 서버와 계정 명의가 정해져 있는가?
[ ] 외부 서비스 비용을 누가 부담하는가?
[ ] 무상 오류 수정 범위가 명확한가?
[ ] 유지보수 범위가 구분되어 있는가?
[ ] 중도 종료 시 산출물 처리 기준이 있는가?

계약서에서 피해야 할 모호한 표현

필요한 기능 일체
충분한 수준으로 제작
최대한 빠르게 완료
무제한 수정
모든 오류 무상 처리
서비스가 완벽하게 작동하는 상태

이러한 표현은 사람마다 다르게 해석할 수 있습니다.

가능하면 확인 가능한 기준으로 바꾸는 것이 좋습니다.

마무리

외주 개발 계약서는 개발 업체를 불신하기 위한 문서가 아닙니다.

양측이 같은 범위와 일정, 완료 기준을 이해하고 프로젝트를 안정적으로 진행하기 위한 기준입니다.

특히 다음 항목은 구체적으로 정하는 것이 좋습니다.

1. 개발 범위
2. 포함·제외 항목
3. 일정
4. 대금
5. 변경 요청
6. 중간 결과물
7. 검수와 완료 기준
8. 소스와 권리
9. 서버·계정 인계
10. 하자보수와 유지보수

기능과 비용이 크거나 개인정보, 결제, 중요한 권리관계가 포함된 계약이라면 체결 전에 법률 전문가의 검토를 받는 것이 안전합니다.