외주 프리랜서를 위한 스코프 방어 전략
클라이언트의 모호한 요청을 명확한 프로젝트 범위로 전환하고, 스코프 크립을 사전에 방지하는 방법을 알아봅니다.
|
이 요청, 익숙하지 않나요?
"스타벅스 사이렌오더 같은 커피숍 모바일 주문 앱을 만들고 싶습니다. 고객이 앱에서 주문하고 결제하면 바리스타가 확인해서 만들고, 사장님은 매출을 볼 수 있으면 좋겠습니다. 3개월 안에 가능할까요?"
프리랜서라면 심장이 쿵 하고 내려앉는 순간입니다.
겉보기엔 간단해 보입니다. 주문, 결제, 매출 확인. 세 문장이 전부니까요.
하지만 경험 많은 개발자라면 이미 알고 있습니다:
- "결제"라는 두 글자 뒤에 PG 연동, 보안 인증, 환불 정책이 숨어있고
- "바리스타가 확인"은 실시간 알림, 상태 관리, 품절 처리를 의미하며
- "3개월"은 iOS + Android + 웹 대시보드를 동시에 요구할 수 있습니다
문제는, 클라이언트는 이걸 모른다는 겁니다. 그리고 그게 클라이언트 잘못이 아닙니다.
모호한 요청이 가져오는 결과
위 요청을 uDocit에 넣으면, AI가 즉시 경고를 보냅니다:
게이트 상태: BLOCK
- 게이트 점수: 45점 (100점 만점)
- 차단 이슈: 2개
- 경고: 1개
발견된 핵심 리스크
| 구분 | 이슈 | 심각도 |
|---|---|---|
| 🔴 보안 | 결제 및 개인정보 보호를 위한 보안 아키텍처 정의 전무 | 차단 |
| 🔴 일정 | 3개월 내 다중 인터페이스 개발 범위 과다 | 차단 |
| 🟡 명확성 | "~하고 싶습니다", "~좋겠습니다" 등 희망형 표현 | 경고 |
AI가 찾아낸 숨겨진 전제들
클라이언트가 말하지 않았지만, 당연히 가정하고 있는 것들:
- 기존 POS 시스템이나 백엔드가 없다 → 신규 구축 비용 증가
- PG사 연동이 필수 → 심사 기간에 따른 일정 지연 리스크
- 실시간 주문 알림 필요 → 푸시 서버 또는 WebSocket 구현 필요
세 문장이 이렇게 바뀝니다
1. 프로젝트 정의
| Before | After |
|---|---|
| "스타벅스 같은 앱" | 커피숍 모바일 주문 및 관리 시스템 |
| 범위 불명확 | 고객용 앱 + 바리스타용 제조관리 + 점주용 대시보드 |
| 막연한 기대 | 실시간 주문 결제, 제조 상태 알림, 기간별 매출 통계 |
2. 사용자 유형: "사용자"에서 구체적인 페르소나로
하나의 "사용자"가 3개의 완전히 다른 페르소나로 분리됩니다:
자동 생성된 페르소나
| 페르소나 | 역할 | 핵심 목표 | 기술 숙련도 |
|---|---|---|---|
| 김지수 | 바쁜 직장인 (고객) | 대기 없이 커피 픽업 | 높음 |
| 이민호 | 선임 바리스타 | 주문 폭주에도 누락 없이 처리 | 보통 |
| 박영희 | 개인 카페 운영자 | 메뉴별 판매 분석, 재고 계획 | 낮음 |
각 페르소나별로 구체적인 Pain Point와 User Journey가 생성됩니다:
김지수 (모바일 주문 고객)의 여정:
- 메뉴 선택 — 앱을 실행하여 선호 매장을 선택하고 아이스 아메리카노를 장바구니에 담음
- 원클릭 결제 — 등록된 카드로 즉시 결제 완료
- 실시간 모니터링 — 제조 단계와 대기 번호를 앱에서 실시간 확인
"출근길에 미리 주문하고 기다림 없이 바로 커피를 가져가고 싶어요."
3. 유저 스토리: 모호함에서 인수조건까지
| Before | After |
|---|---|
| "메뉴를 볼 수 있다" | 카테고리별 실시간 메뉴 조회 및 상세 옵션 선택 |
| 우선순위: 높음 · 예상 공수: 32시간 |
생성된 인수 조건 예시:
- 메뉴 상세에서 온도(HOT/ICED), 사이즈, 퍼스널 옵션을 선택할 수 있어야 함
- 선택 옵션에 따라 실시간으로 최종 가격이 합산되어 표시되어야 함
- 필수 옵션 미선택 시 '장바구니 담기' 버튼이 비활성화되어야 함
- 바리스타 시스템의 품절 설정이 실시간으로 메뉴에 반영되어야 함
4. 최종 스코프: 숫자로 보는 프로젝트
세 문장의 요청에서 추출된 실제 범위:
프로젝트 규모 요약
| 항목 | 수량 |
|---|---|
| 에픽 (Epic) | 14개 |
| 유저 스토리 | 31개 |
| 총 예상 공수 | 700+ 시간 |
| 현실적 일정 | 16주 (4개월) |
일정 산출: "3개월 가능하냐"에 대한 답
AI가 생성한 타임라인입니다. 9개 마일스톤으로 구성됩니다:
| 단계 | 기간 | 주요 내용 |
|---|---|---|
| 1. 기본 주문 및 결제 | 2주 | 메뉴 조회, 원클릭 결제 핵심 기능 |
| 2. 주문 접수 및 상태 관리 | 2주 | 바리스타 주문 수락, 실시간 상태 변경 |
| 3. 픽업 알림 및 완료 처리 | 2주 | 제조 완료 푸시 알림, 픽업 대기 관리 |
| 4. 실시간 재고 및 품절 관리 | 1주 | 메뉴/옵션 품절 실시간 제어 |
| 5. 매출 대시보드 기초 | 2주 | 기간별 매출 통계 시각화 |
| 6. 정산 검증 및 상세 조회 | 2주 | PG사 데이터 대조, 정합성 검증 |
| 7. 인기 메뉴 분석 리포트 | 2주 | 판매 선호도 분석, 엑셀/PDF 내보내기 |
| 8. 운영 최적화 및 설정 | 1.5주 | 피크 타임 분석, 운영 시간 관리 |
| 9. 메뉴 및 옵션 고도화 | 1주 | 가격 변동 관리, 옵션별 품절 처리 |
결론: 12주(3개월)로는 부족합니다. 최소 16주(4개월)가 필요합니다.
왜 이게 중요한가요?
계약 전에 이 분석을 보여주면:
추가 요청에 대응 가능
"알림톡도 보내주세요"
→ "현재 범위에 푸시 알림은 포함되어 있지만, 알림톡은 별도 기능입니다. 추가 시 2주 공수가 필요합니다."
견적 근거 확보
"왜 이렇게 비싸요?"
→ "31개 유저 스토리 기반으로 산정한 700시간 공수입니다. 여기 인수조건 목록이 있습니다."
분쟁 예방
"이거 완성 아니잖아요"
→ "인수조건 충족 여부로 판단합니다. 체크리스트 보시죠."
직접 해보세요
클라이언트 요청을 받으면 바로 견적 내지 마세요.
5분만 투자해서 범위를 먼저 정리하세요.
모호한 세 문장이 어떻게 명확한 프로젝트 정의로 바뀌는지 직접 확인해보세요.
