소프트웨어 외주 개발에서 갈등이 생기는 핵심 원인은 기술적 구현 난이도보다 '서로가 생각한 작업 범위의 불일치'에 있습니다.
발주자는 "이런 서비스에 로그인과 결제는 기본이니 당연히 포함인 줄 알았다"고 생각하고, 개발사는 "견적서에 명시되지 않은 요구사항이므로 추가 견적이 발생한다"며 대립합니다. 이 갈등이 심해지면 납기가 무기한 지연되거나 잔금 지급 거부, 심지어 법적 소송으로 이어집니다.
8년간 1인 풀스택 개발사 큐룸(QUROOM)을 운영하며 수많은 MVP와 플랫폼을 직접 구축·배포해 온 입장에서, 계약서에서 가장 중요한 조항은 '무엇을 개발할 것인가(In-Scope)'가 아니라 '무엇을 이번 계약에서 개발하지 않을 것인가(Out-of-Scope)'를 사전에 선 긋는 일입니다.
이번 글에서는 추가금 갈등과 일정 지연을 사전에 예방하는 WBS 5대 제외 범위 명세 기준과, 주관적 평가를 배제하는 동작 기반 인수 검수 기준(Acceptance Criteria)을 실무 템플릿과 함께 공유합니다.
1. 계약서에 '포함 기능'보다 '제외 범위'를 못 박아야 하는 이유
외주 계약서나 견적서에 흔히 적히는 추상적인 단어 한 줄은 양측에 전혀 다른 기대를 심어줍니다.
예를 들어 과업 항목에 회원가입 및 사용자 인증 (1식)이라고 적혀 있을 때, 각자의 머릿속에 떠오르는 그림은 다음과 같습니다:
- 발주자의 기대: 카카오·네이버·구글·애플 소셜 로그인 4종, 통신사 본인인증(PASS), 아이디/비밀번호 찾기(SMS 인증), 1년 이상 미접속자 휴면 계정 분리 보관, 마케팅 수신동의 이력 관리.
- 개발사의 산정: NextAuth 또는 Django 내장 인증을 이용한 이메일/비밀번호 가입 폼 1종 및 세션/JWT 토큰 발급.
양쪽 모두 틀린 말을 한 것이 아닙니다. 기능의 '깊이(Depth)'에 대한 기준선이 없었을 뿐입니다.
견적서에 포함 항목만 나열하면 발주자는 가장 넓은 범위를 기대하게 됩니다. 따라서 계약 전 과업지시서(WBS)에 "이번 1차 린(Lean) MVP 스프린트에서는 여기까지 구현하며, 아래 항목은 명시적으로 제외한다"는 제외 범위를 명확히 합의해야만 예산과 일정을 지킬 수 있습니다. 특히 에이전시와의 견적 산정 차이가 궁금하시다면 스타트업 MVP 외주 개발 견적 분석을 함께 살펴보시는 것을 권장합니다.
2. 외주 분쟁을 사전 예방하는 WBS 5대 제외 범위 (Out-of-Scope)
실무 계약서에 별첨으로 반드시 첨부해야 하는 5대 과업 제외 범위 항목입니다.
🚫 제1조: P0 확정 요구사항 외 기획 변경 및 부가 기능
- 원칙: 이번 계약의 개발 범위는 WBS 명세서 상의
P0 (런칭 필수)기능으로 한정합니다. - 제외 내용:
- 개발 진행 중 신규 화면 추가, 확정된 비즈니스 로직 및 DB 필드 구조의 임의 변경.
- "보통 다른 앱에도 다 있는 기능(다크모드 지원, 다국어 i18n, 인앱 1:1 채팅 등)"이라 하더라도 P0 목록에 명시되지 않은 항목.
- 처리 절차: P0 외 신규 아이디어는
P1/P2 (차기 백로그)로 분류하여 서비스 런칭 후 2차 개발 스프린트로 이관하거나, 별도의 추가 M/D(Man-Day) 견적을 상호 합의한 뒤 진행합니다. 프로토타입에서 살릴 영역과 걷어낼 영역의 구체적 분리 기준은 AI 프로토타입 상용화 리팩토링 가이드를 참조하십시오.
🚫 제2조: 외부 플랫폼 심사 지연 및 정책 변경
- 원칙: 개발사는 정상적인 API 연동 코드 작성과 규격 준수를 책임지며, 서드파티 플랫폼의 자체 심사 지연이나 장애는 개발사 귀책 사유에서 제외합니다.
- 제외 내용:
- PG사(포트원, 토스페이먼츠 등) 가맹점 가입 심사 지연, 통신판매업 신고 지연, 서울보증보험 증권 발급 지연.
- 카카오 비즈니스 채널 승인 및 알림톡 템플릿 검수 반려, 공공데이터 OpenAPI 인증키 승인 지연.
- 외부 서비스 자체의 서버 장애 또는 API 스펙 강제 변경으로 인한 연동 오류.
- 처리 절차: 클라이언트는 외부 기관 심사에 필요한 사업자 등록증 및 인허가 서류를 적기에 제출할 책임을 가지며, 연동 검증은 Mock 또는 테스트 샌드박스 환경에서의 정상 통신을 기준으로 판정합니다.
🚫 제3조: 앱스토어(Apple/Google) 비즈니스 모델 사유 리젝
- 원칙: 앱 바이너리 빌드 및 스토어 제출 기술 규격 준수는 개발사 책임이나, 사업 모델·콘텐츠·법적 사유의 심사 거절은 제외됩니다.
- 제외 내용:
- 소스코드 결함(앱 크래시, 권한 선언 누락)이 아닌 사업 모델(디지털 상품 인앱결제 IAP 수수료 우회 문제), 저작권 증빙 부족, 이용약관/개인정보처리방침 문구 미비로 인한 리젝.
- 애플/구글 가이드라인의 사후 변경으로 인한 화면 기획 및 UI 전면 재설계.
- 처리 절차: 기술적 결함으로 인한 1차 리젝은 무상 수정 제출하며, 사업 정책상의 리젝은 클라이언트와 협의하여 가이드라인에 맞추어 기획 요건을 조정합니다.
🚫 제4조: 하자보수(무상)와 기능 개선(유상)의 명확한 경계
- 원칙: 무상 하자보수 기간은 검수 완료일로부터 3개월로 규정합니다.
- 무상 하자보수 대상:
- WBS P0 명세서에 정의된 기능이 명세대로 작동하지 않는 명백한 버그 또는 시스템 에러.
- 유상 기능 개선 대상:
- "실제로 써보니 동선이 어색해서 버튼 위치나 탭 순서를 변경하고 싶다", "글자 폰트 및 테마 색상 변경", "통계 집계 조건 추가" 등 기존 명세와 무관한 편의성 개선.
- 클라이언트 측에서 임의로 서버 설정(Nginx, Docker, 환경변수)을 변경하거나 외부 작업자가 코드를 수정한 경우.
🚫 제5조: 인프라 운영 실비 및 플랫폼 운영 대행
- 원칙: 소프트웨어 개발 용역비는 기능 구축 및 초기 배포 공수에 대한 대가이며, 서비스 운영에 수반되는 월간 인프라 실비와 수작업 운영은 포함되지 않습니다.
- 제외 내용:
- 도메인 구입/갱신 비용, 유료 SSL 인증서 비용, 클라우드 VPS(AWS, Dokku 호스팅) 월 서버 비용. 저비용 운영 인프라 구성은 월 1~2만 원대 VPS Dokku 구축 가이드를 참고할 수 있습니다.
- DB 스토리지 증설, OpenAI/Anthropic API 토큰 사용료, 트래픽 폭증에 따른 CDN 네트워크 비용.
- 배포 완료 후 일상적인 데이터 수기 등록, 고객 CS 응대, 정기 DB 백업 감시 등 일상 운영 업무.
3. 주관적 분쟁을 없애는 동작 기반 인수 검수 기준 (Acceptance Criteria)
외주 납품 시 "제가 생각한 느낌이 아닌데요", "아직 마음에 안 듭니다" 같은 주관적인 평가로 잔금 지급이 미뤄지는 상황을 막으려면, 검수 기준을 시스템 로그와 데이터베이스 트랜잭션 기록으로 구체화해야 합니다.
실무 인수 검수 기준표 예시 (P0 모듈 기준)
| 대상 모듈 | 기능 명세 | 정량적 인수 검수 기준 (Acceptance Criteria) | 검증 방법 |
|---|---|---|---|
| 회원 인증 | 카카오 간편 로그인 | 카카오 인가 코드를 받아 서버 세션 쿠키가 정상 발급되고, DB users 테이블에 신규 레코드가 1회 생성될 것 | 브라우저 시연 & DB 조회 |
| 증상 접수 | 모바일 사진 업로드 | 최대 3장의 이미지가 WebP로 클라이언트 압축되어 S3 스토리지에 저장되고, 게시글 레코드에 URL이 바인딩될 것 | 네트워크 탭 & S3 버킷 확인 |
| 결제 연동 | 단건 카드 결제 | 결제창 호출 ➡️ 결제 완료 ➡️ 웹훅 수신 시 금액 변조 검증 통과 ➡️ orders 상태가 PAID로 원자적(Atomic) 갱신될 것 (포트원 결제 웹훅 멱등성 가이드 구현 원칙 준수) | PG 테스트 결제 & DB 트랜잭션 |
| 알림톡 | 접수 완료 알림 | 주문 결제 완료 이벤트 발생 시 비즈톡 API를 통해 지정된 수신자 번호로 카카오 알림톡이 5초 이내 발송될 것 | 실제 모바일 수신 확인 |
| 서버 배포 | 실서버 무중단 환경 | HTTPS SSL 인증서 유효, Docker/Dokku 컨테이너 자동 재시작 정책 설정, 시스템 재부팅 후에도 서비스 정상 구동 (실서버 배포 장애 해결 가이드 기준 준수) | curl -I 및 도메인 접속 |
4. 실전 과업지시서(WBS) 작성 템플릿
실제 외주 계약을 체결할 때 견적서와 함께 첨부할 수 있는 마크다운 형식의 표준 WBS 예시입니다.
# [프로젝트명] 린 MVP 외주 개발 과업지시서 (WBS)
## 1. 기본 개요
- 발주사: (주)OOOO (대표: OOO)
- 개발사: 큐룸 (QUROOM, 대표: 김상은)
- 개발 기간: 착수일로부터 총 3주 (스프린트 단위 배포)
- 런칭 목표: 핵심 비즈니스 검증용 린 MVP 실서버 릴리즈
## 2. P0 출시 필수 기능 목록 (총 13.0 M/D)
1. 사용자 인증 (OAuth 2.0 카카오 1초 간편 로그인): 2.0 M/D
2. 서비스 대시보드 (PostgreSQL 전문검색 기반 실시간 신청 목록): 3.0 M/D
3. 모바일 증상 접수 폼 (반응형 모바일 UI + 사진 업로드 WebP 압축): 2.5 M/D
4. 결제 연동 (포트원 V2 REST API + 웹훅 멱등성 보장 처리): 2.5 M/D
5. 알림톡 자동 발송 (접수 완료 알림 카카오 비즈톡 연동): 1.5 M/D
6. 실서버 인프라 배포 (VPS Dokku PaaS + Nginx 리버스 프록시 + SSL): 1.5 M/D
## 3. P1/P2 제외 항목 (명시적 Out-of-Scope)
- 네이버/구글/애플 다중 소셜 로그인 (카카오 단일 로그인으로 출시 후 반응 검증)
- 관리자 화면 엑셀 다운로드 및 커스텀 대시보드 차트 기능
- 실시간 1:1 채팅 (카카오톡 채널 상담 링크 버튼으로 대체)
## 4. 최종 인수 검수 기준
1. 스테이징 서버에서 상기 P0 6개 모듈 단위 시연 및 DB 데이터 무결성 검증.
2. Git 원격 저장소 소스코드 전체 Push 및 README 환경변수 셋업 가이드 제공.
3. 실도메인 HTTPS 배포 완료 확인 후 '과업완료 검수조서' 상호 날인.5. 8년 차 엔지니어가 권장하는 외주 성공 원칙
외주 개발에서 가장 비싼 비용은 개발비 자체가 아니라 "만들고 나서 아무도 쓰지 않거나, 엉뚱한 기능을 만드느라 허비한 3~6개월의 시간"입니다.
- 처음에는 무조건 P0 기능 3~5개만 만드십시오: 관리자 통계, 커뮤니티 게시판, 화려한 마이크로 인터랙션은 첫 고객이 결제하거나 유입된 이후에 붙여도 늦지 않습니다.
- 견적서에 단 한 줄의 모호한 수식어도 남기지 마십시오: "사용자 친화적인 인터페이스", "철저한 보안 환경", "확장 가능한 시스템" 같은 모호한 문구 대신, 화면 경로와 처리할 데이터베이스 트랜잭션을 기술적으로 적어야 분쟁이 발생하지 않습니다.
- 중간 하청이 없는 실무 책임자와 직접 소통하십시오: 영업 담당자, 기획자, 개발자가 분리된 대형 에이전시에서는 전달 과정에서 요구사항이 왜곡되기 쉽습니다. 아키텍처를 설계하고 직접 코드를 작성할 엔지니어와 WBS 5대 제외 범위를 상의할 때 가장 정확하고 가벼운 견적이 도출됩니다.
📚 함께 읽으면 좋은 큐룸(QUROOM) 기술 아티클
- 🛠️ Codex·Claude 생성 코드를 실서버에 배포할 때 발생하는 기술적 장애 4가지와 해결 절차
- 💳 포트원 V2 결제 웹훅 멱등성 보장과 금액 위변조 방지 아키텍처
- 🏗️ Codex·Claude로 만든 AI 프로토타입, 상용화할 때 '살릴 코드'와 '버릴 코드'의 기술적 기준
- 🖥️ 월 1~2만 원대 VPS에 Dokku로 구축하는 Heroku급 무중단 Git Push 배포 인프라 가이드
- 💰 스타트업 MVP 외주 개발 견적 분석: 에이전시 M/M 산정 방식 vs 1인 풀스택 린 아키텍처
- 🏠 큐룸(QUROOM) 8년 차 풀스택 개발사 소개 및 린 MVP 자문 안내
＊ 본 글은 8년 차 1인 풀스택 개발사 큐룸(QUROOM)의 실제 경험을 바탕으로 AI와 함께 작성했습니다.