계약서보다 먼저 요구사항이 정리되어 있어야 합니다.
계약서에 “웹서비스 개발 일체”라고만 적혀 있다면 나중에 어떤 기능이 포함되는지 판단하기 어렵습니다. 계약 본문뿐 아니라 기능 목록, 화면설계서, 견적서, 일정표 등 프로젝트 범위를 구체화하는 자료가 어떤 방식으로 계약의 기준이 되는지 확인해야 합니다.
1. 개발범위 — 무엇을 만드는가?
사용자 기능, 관리자 기능, 외부연동 등 포함되는 개발범위를 확인합니다.
디자인, 콘텐츠 입력, 데이터 이관, 앱 개발 등 제외되는 항목도 명확히 합니다.
웹·모바일웹·앱, 브라우저와 기기 등 필요한 지원환경을 확인합니다.
견적서·기능목록·화면설계 등 어떤 자료가 개발범위를 정의하는지 확인합니다.
2. 일정·대금 — 언제 무엇을 기준으로 지급하는가?
| 확인 항목 | 확인 질문 |
|---|---|
| 착수일·완료일 | 전체 기간뿐 아니라 주요 단계의 일정이 있는가? |
| 중간검수 | 어느 시점에 어떤 결과물을 확인하는가? |
| 대금 지급 | 계약금·중도금·잔금의 지급 조건은 무엇인가? |
| 발주자 협조 | 자료·피드백 지연이 일정에 미치는 영향은 어떻게 처리하는가? |
| 일정 변경 | 지연 또는 범위 변경 시 일정 조정 절차가 있는가? |
3. 요구사항 변경 — “수정”이라는 말을 하나로 묶지 마세요.
개발 중 가장 많은 해석 차이가 생기는 부분입니다. 기존 요구사항을 제대로 구현하지 못한 오류와, 기존 요구를 구체화하는 작업, 새 기능을 추가하는 변경은 서로 다르게 다뤄질 수 있습니다.
발주자가 변경내용을 기록
개발범위·일정·비용 확인
진행 여부와 조건 확정
합의된 변경사항 반영
변경 결과를 다시 확인
4. 검수·하자보수 — 무엇을 ‘완료’라고 볼 것인가?
| 구분 | 확인할 내용 |
|---|---|
| 검수 기준 | 기능목록·화면설계·업무흐름 등 어떤 기준으로 완료를 판단하는지 |
| 검수 기간 | 결과물 제출 후 확인·수정할 기간과 절차 |
| 오류 처리 | 합의된 요구사항대로 동작하지 않는 경우의 수정 방식 |
| 하자보수 | 완료 후 오류 수정의 기간·범위·대응방법 |
| 추가개발 | 새 기능이나 정책 변경을 어떤 절차로 별도 산정하는지 |
5. 소스·권리·계정·산출물 — 완료 후 무엇이 남는가?
제공 범위, 저장소 접근, 인계 시점과 방식
신규 개발물과 기존 자산, 제3자 라이선스의 권리관계
소유 주체, 관리자 권한, 결제정보와 프로젝트 종료 후 권한
디자인 원본, DB, API·배포문서 등 실제 운영에 필요한 산출물
6. 계약 종료·중단 — 끝까지 완료되지 않을 때도 정해두세요.
모든 프로젝트가 처음 계획대로 끝나는 것은 아닙니다. 일정 지연, 사업방향 변경, 수행 문제 등으로 계약을 중단하거나 업체를 변경해야 할 수 있으므로 중도 종료 시점의 처리도 확인하는 것이 좋습니다.
| 상황 | 확인할 내용 |
|---|---|
| 중도 종료 | 해지·종료 조건과 통지 절차 |
| 기성 정산 | 이미 수행된 작업의 범위와 대금 산정 기준 |
| 부분 결과물 | 종료 시점까지 작성된 소스·디자인·문서 등의 인계 조건 |
| 계정·데이터 | 서버·DB·외부서비스 접근권한과 데이터 이전 |
| 비밀정보 | 계약 종료 후 자료 보관·반환·삭제 등 계약상 처리방법 |
7. 서명하기 전에 확인할 계약 체크리스트
좋은 외주개발 계약서는 ‘문제가 생기면 어떻게 할까?’보다 ‘프로젝트를 어떻게 진행할까?’가 명확한 계약서입니다.
범위 → 일정·대금 → 변경 → 검수 → 하자보수 → 권리 → 산출물 → 인수인계가 하나의 흐름으로 연결되어 있는지 확인하세요.