외주 개발을 맡길 때 가장 큰 리스크는 기능이 다르게 나오거나, 일정이 밀리거나, 추가 비용이 계속 붙거나, 심하면 소스코드를 못 받는 상황입니다.

이 글은 변호사 자문을 대체하지 않으며, 대표/PM이 계약 전에 놓치기 쉬운 포인트를 점검하기 위한 실무 체크리스트입니다.

작성: 지지직(ZIZIZIG) System (외주 개발/웹·앱 구축 전문). 필요하시면 아래 링크로 무료 견적/상담을 요청하실 수 있습니다.

1) 계약서가 필요한 이유(견적서만으로 부족한 이유)

견적서에는 보통 “무엇을 만든다” 정도만 담깁니다. 하지만 분쟁은 대부분 ‘어디까지가 범위인지’, ‘언제/어떻게 검수하는지’, ‘소스코드와 계정의 소유권이 누구인지’ 같은 디테일에서 발생합니다.

계약서는 “돈을 얼마”보다 프로젝트 운영 규칙을 정하는 문서입니다.

2) 외주 개발 계약서 체크리스트 12가지

1. 범위(Scope)와 산출물(Deliverables)을 문서로 고정

• 화면 목록(페이지/기능), 관리자 기능, 결제/알림/검색 등 핵심 모듈을 목록화
• “포함/미포함”을 명확히: 예) 앱스토어 등록 포함 여부, 서버 운영 포함 여부
• 산출물 예: 소스코드, 빌드 산출물, DB 스키마, API 문서, 관리자 매뉴얼

2. 일정과 마일스톤(중간 점검) 정의

• 전체 일정 + 주차별/단계별 마일스톤(기획/디자인/개발/테스트/배포)
• 마일스톤마다 데모 링크/스테이징 URL 제공

3. 검수(Acceptance) 기준과 절차

• 검수 기간(예: 7일)과 “무응답 시 승인” 여부
• 버그 vs 변경요청의 정의

4. 변경요청(Change Request) 처리 규칙

• 요청 → 영향도(일정/비용) 산정 → 승인 후 진행
• 추가 비용 산정 기준(시간 단가/기능 단가/스프린트 단가)

5. 결제 조건(착수금/중도금/잔금)과 지급 트리거

• 마일스톤 완료를 기준으로 지급 트리거 정의(예: ‘기능 A 완료 + 데모 제공’)
• 잔금은 최종 검수 통과 + 산출물 인도 후 지급이 안전

6. 소스코드/지적재산권(IP) 소유권 및 인도 시점

• 최종 산출물의 저작권 귀속, 소스코드 인도 범위(서버/클라이언트/인프라)
• 3rd-party 라이선스(유료 템플릿/플러그인/폰트) 사용 시 비용/권리 주체 명시

7. 계정/인프라 소유권(도메인, 클라우드, 이메일, 애널리틱스)

• 도메인/클라우드(AWS/GCP), DNS, 이메일, GA/GSC, 앱스토어 계정의 소유자 지정
• 가능하면 고객 계정으로 생성하고 권한만 위임

8. 데이터/개인정보/보안 책임

• 개인정보 처리 위탁/수탁 관계 및 접근 권한 관리
• 로그/백업/권한/암호화(비밀번호 해시 등) 기준

9. 하자보수(버그 수정) 범위와 기간

• 무상 하자보수 기간(예: 3개월/6개월/1년)
• 하자보수 제외 항목(운영환경 변경, 외부 API 장애 등) 명시

10. 운영/유지보수 계약(선택) 조건

• 월 유지보수 범위(모니터링/경미 수정/서버관리)와 SLA
• 유지보수 없이도 서비스가 돌아가도록 문서/권한 인도 포함

11. 커뮤니케이션 규칙

• 주간 리포트/회의 주기, 의사결정 채널(이메일/슬랙/카톡) 고정
• 요구사항은 가능한 한 티켓/문서로 남기기

12. 계약 해지/중단 시 정산 및 인도

• 중단 시점까지의 작업물(소스/디자인/문서) 인도 범위
• 정산 방식(진척률/마일스톤 기준)과 분쟁 해결 절차

3) 자주 생기는 분쟁 5가지와 예방 팁

1. “이건 범위에 포함 아닌가요?” → 범위/미포함/추가비용 규칙을 표로 정리
2. “검수 통과 기준이 애매해요” → 체크리스트(필수 시나리오)로 검수 기준 고정
3. “소스코드를 못 받았어요” → 인도 항목과 시점을 계약서에 명시
4. “추가 비용이 계속 늘어요” → 변경요청 승인 프로세스 필수화
5. “일정이 계속 밀려요” → 마일스톤 데모/주간 리포트/지연 대응 규정

4) 무료 견적 요청 전에 준비하면 좋은 자료

• 참고 서비스 URL 2~3개(좋은 점/싫은 점)
• 필수 기능 5~10개 우선순위
• 관리자 필요 여부(상품/콘텐츠/주문/정산/통계 등)
• 예상 일정(런칭 목표일)과 예산 범위