개발 외주 맡기기 전 꼭 확인해야 할 체크리스트
외주 계약 후 자주 발생하는 분쟁 상당수는 계약 전에 범위와 인수 기준을 명확히 하면 줄일 수 있습니다. 견적·계약 범위·관리자 페이지·유지보수·소스코드 인수 단계별로 짚어야 할 체크리스트를 정리했습니다.
개발 외주에서 사고가 나는 패턴은 거의 비슷합니다. 견적이 모호했거나, 계약서에 명시되지 않은 영역에서 의견이 갈리거나, 운영 단계가 준비되지 않은 채 출시했거나. 개발 외주 분쟁은 대부분 "무엇을 어디까지 만들기로 했는지"가 불명확할 때 시작되므로, 계약 전에 짚어야 할 항목을 단계별 체크리스트로 정리했습니다.
1. 견적서 단계
견적서를 받았을 때 다음 항목이 명시되어 있는지 확인합니다.
- 기능별 산정 내역 — '앱 개발 일체' 같은 한 줄짜리 견적은 위험. 화면 단위로 인일이 적혀 있어야 함
- 포함되지 않은 항목 — 디자인, 이미지/카피 제공, 호스팅 비용, 외부 API 비용은 누가 부담하는지
- 추가 견적 단가 — 변경 요청 시 시간당 / 인일당 단가
- 결제 일정 — 마일스톤 분할 지급이 표준
- 납기 + 검수 기간
2. 계약 범위와 SOW
SOW(Statement of Work)는 "무엇을 만드는지"를 화면·기능 단위로 적은 문서입니다. SOW는 계약서 본문만큼 중요합니다. 실제 분쟁은 "무엇을 만들기로 했는지"에서 발생하는 경우가 많기 때문에, SOW를 계약서의 부속 문서로 편입하고 계약서와 SOW가 충돌할 때의 우선순위도 정해 두는 것이 좋습니다. 다음이 빠져 있으면 사고가 납니다.
- 화면 목록과 화면별 주요 기능
- 사용자 권한 (회원/관리자/슈퍼관리자)
- 외부 시스템 연동 목록
- 비기능 요구사항 (응답속도, 동시접속, 보안 기준)
- 명시적으로 포함하지 않는 범위
3. 관리자 페이지
운영을 누가 어떻게 할지 사전에 정해야 합니다.
- 회원 관리, 콘텐츠 관리 등 어떤 화면이 필요한지
- 통계/리포트 자동화 수준
- 권한 분리 (편집자 vs 관리자)
- 운영 매뉴얼 인계 여부
관리자 페이지가 없으면 사소한 변경에도 개발사 호출이 필요하고, 이는 곧 추가 비용입니다.
4. 유지보수와 SLA
다음 항목을 계약서에 명시합니다.
- 무상 하자보수 기간 (출시 후 N개월)
- 월정액 유지보수 단가와 포함 범위
- 장애 대응 시간 (예: critical 2시간, major 24시간)
- 정기 점검·백업·보안 패치 책임 주체
5. 소스코드와 지식재산권
가장 자주 분쟁이 일어나는 영역입니다.
- 소스코드 소유권이 의뢰사에 귀속되는지
- 결제 완료 후 GitHub/GitLab 저장소가 이관되는지
- 외부 라이브러리 라이선스 정리 문서가 제공되는지
- 디자인 원본 파일(Figma 등)도 인계되는지
"우리가 갖고 있다가 필요할 때 드리겠다"는 답변은 위험 신호입니다.
6. 계약서에 문장으로 남겨야 하는 항목
외주 계약에서는 "구두로 약속했다"보다 문장으로 남기는 것이 중요합니다. 다음 항목은 계약서 또는 SOW에 명시하는 것을 권장합니다.
- 산출물: 소스코드, 디자인 원본, API 문서, 배포 문서, 운영 매뉴얼
- 인수 조건: 검수 완료 후 저장소, 계정, 문서 인계 방식
- 지식재산권: 대금 지급 완료 후 귀속 범위와 사용권
- 오픈소스: 사용 라이선스 목록과 상업적 사용 가능 여부
- 유지보수: 하자보수와 기능 추가의 구분
- 장애 대응: 장애 등급, 응답 시간, 업무시간 외 대응 여부
특히 소스코드와 디자인 원본은 "필요할 때 제공"이 아니라, 프로젝트 종료 시점에 어떤 형태로 인계되는지까지 정해 두는 것이 안전합니다.
7. 보안과 개인정보
서비스 성격에 따라 다음을 확인해야 합니다.
- 법령·인증 적용 범위: 개인정보 처리 여부와 서비스 규모에 따라 개인정보보호법, 정보통신망법, ISMS-P/ISMS 인증 대상 여부를 확인합니다. 모든 외주 프로젝트가 ISMS 인증 대상은 아니지만, 인증 대상이 아니더라도 관련 법령상 안전성 확보 의무는 적용될 수 있습니다.
- 개인정보 처리 항목 정리: 개인정보를 처리하는 서비스라면 수집 항목, 보관 기간, 접근 권한, 접속기록, 암호화 대상, 유출 사고 발생 시 신고·통지 책임을 계약 전에 정리합니다.
- 암호화 범위: 통신 암호화(HTTPS), 비밀번호 단방향 해시, 고유식별정보·민감정보 등 주요 데이터의 암호화 범위
- 접속기록: 누가, 언제, 어떤 개인정보 또는 주요 데이터에 접근했는지 남기는 접속기록과 보관 기간
- 침해사고 대응: 침해사고 발생 시 신고·통지 책임 주체와 절차
8. 출시 이후 인계 절차
- 운영 매뉴얼 (관리자 페이지 사용법, 자주 묻는 운영 작업)
- 배포 문서 (어떻게 새 버전을 올리는지)
- 모니터링 도구 접근 권한 (APM, 에러 추적, 로그)
- 외부 서비스 계정 인계 (도메인, 클라우드, PG, 푸시, 분석)
체크리스트 한 페이지로 보기
위 항목을 RFP 단계에서 표 형태로 정리해 요청 시 함께 보내면, 받은 견적서를 같은 기준으로 비교할 수 있고 계약 시 부속 문서로 그대로 활용할 수 있습니다.
엠아이솔루션은 견적 단계에서 이 체크리스트 기반의 SOW 초안을 함께 작성해 드립니다. 자세한 개발 플로우를 참고하시거나, 무료 상담으로 프로젝트 요건을 함께 정리해 보세요.
자주 묻는 질문
Q. 표준 계약서가 있나요?▾
참고 기준으로는 과학기술정보통신부가 배포한 SW분야 표준계약서와 공정거래위원회의 소프트웨어사업 표준하도급계약서를 확인할 수 있습니다. 다만 실제 계약에서는 산출물, 검수 기준, 하자보수 기간, 지식재산권 귀속, 소스코드 인수 조건을 프로젝트 상황에 맞게 별도로 명시해야 합니다.
Q. 선급금은 얼마가 적당한가요?▾
프로젝트 규모와 신뢰도에 따라 다르지만, 실무에서는 마일스톤 단위(기획 완료 시, 디자인 완료 시, 출시 시)로 분할 지급하는 방식을 자주 활용합니다. 한 번에 큰 비율을 선지급할수록 분쟁 시 리스크가 커지므로, 진행 단계와 산출물 인수 시점에 맞춰 나눠 지급하는 것이 안전합니다.
Q. 출시 후 버그는 누가 책임지나요?▾
검수 완료 후 일정 기간(많은 경우 1~3개월)의 무상 하자보수를 두는 것이 일반적입니다. 이 기간 이후 발생하는 이슈와 신규 기능 요청은 별도 유지보수 계약으로 분리하는 편이 양쪽 모두에게 명확합니다.