← 이전: Week 2 목차 다음: Week 4 →

Week 3: 서비스 분석 설계 및 요건 정의

📌 학습 목표

📚 주요 내용

1. 문제 정의 프레임워크

1.1 핵심 문제 진술 (Core Problem Statement)

구성 요소:

예시:

1.2 증거 기반 문제 정의

정량적 데이터 활용:

예시:

문제: 온라인 쇼핑몰 장바구니 이탈률 높음

정량적 데이터:
- 장바구니 이탈률: 69.57% (업계 평균 대비 +10%p)
- 월 평균 잠재 매출 손실: 3,500만원
- 주요 이탈 지점: 결제 정보 입력 단계 (45%)

근거 자료:
- 구글 애널리틱스 데이터 (3개월 집계)
- 사용자 설문 (n=200, 이탈 경험자 대상)
- 경쟁사 벤치마킹 (업계 리포트)

경계 및 제약 조건:

2. As-Is / To-Be 분석

2.1 As-Is 분석 (현재 상태)

조사 항목:

분석 도구:

예시: 온라인 주문 프로세스 As-Is

1. 고객이 웹사이트 접속 (평균 3초 로딩)
2. 카테고리 탐색 (평균 2분)
3. 상품 검색 (검색 기능 발견률 60%)
4. 상품 상세 페이지 확인 (이미지 로딩 5초)
5. 옵션 선택 (사이즈 정보 불충분으로 고민 1분)
6. 장바구니 담기
7. 결제 페이지 이동 (회원가입 강제 → 70% 이탈)
8. 배송지 입력 (반복 입력으로 불편)
9. 결제 수단 선택 (옵션 제한적)
10. 주문 완료

Pain Points:
- 느린 로딩 시간
- 검색 기능 발견 어려움
- 사이즈 정보 부족
- 회원가입 강제
- 복잡한 결제 과정

2.2 To-Be 분석 (미래 상태)

설계 요소:

예시: 개선된 주문 프로세스 To-Be

1. 고객 웹사이트 접속 (1초 로딩, CDN 적용)
2. AI 추천 상품 즉시 노출 (개인화)
3. 스마트 검색 (자동완성, 오타 보정)
4. 빠른 상품 확인 (이미지 최적화)
5. 스마트 옵션 추천 (구매 이력 기반)
6. 원클릭 장바구니
7. 게스트 주문 허용 (회원가입 선택사항)
8. 저장된 배송지 자동 입력
9. 간편 결제 (카카오페이, 토스페이)
10. 주문 완료 + SMS 확인

기대 효과:
- 주문 완료 시간: 10분 → 3분
- 장바구니 이탈률: 70% → 40%
- 고객 만족도: 3.2 → 4.5

2.3 Gap 분석

주요 Gap 영역:

Gap 분석 매트릭스:

영역 As-Is To-Be Gap 우선순위 해결 방안
페이지 로딩 3초 1초 2초 High CDN, 이미지 최적화
검색 정확도 60% 90% 30%p High AI 검색 엔진 도입
결제 완료율 30% 70% 40%p Critical 게스트 주문, 간편 결제
고객 만족도 3.2/5 4.5/5 1.3점 Medium 전체 UX 개선

3. Root Cause Analysis (근본 원인 분석)

3.1 5 Whys 기법

방법:

  1. 문제 현상 기술
  2. “왜?”라는 질문을 5번 반복
  3. 표면적 원인이 아닌 근본 원인 도출

예시 1: 웹사이트 로딩 속도

  1. 문제: 웹사이트 로딩이 느리다
  2. Why 1: 서버 응답 시간이 느리다
  3. Why 2: 데이터베이스 쿼리가 복잡하다
  4. Why 3: 인덱싱이 되어 있지 않다
  5. Why 4: 초기 설계 시 성능 최적화를 고려하지 않았다
  6. Why 5: 개발 일정이 촉박하여 설계 단계를 축소했다

근본 원인: 개발 프로세스에서 성능 설계 단계 부재

해결책:

예시 2: 고객 이탈률 증가

  1. 문제: 월간 고객 이탈률이 15%로 증가했다
  2. Why 1: 고객들이 서비스에 불만족한다
  3. Why 2: 기대한 기능이 제공되지 않는다
  4. Why 3: 고객 요구사항을 제대로 파악하지 못했다
  5. Why 4: 사용자 인터뷰를 충분히 하지 않았다
  6. Why 5: 빠른 출시를 위해 사용자 조사 단계를 생략했다

근본 원인: 사용자 중심 설계 프로세스 부재

3.2 Fishbone Diagram (Ishikawa Diagram)

분류 카테고리 (6M):

예시: 앱 크래시 문제

                    앱 크래시 빈발
                         ↑
                         |
    Man           Method  |  Machine        Material
     |              |     |     |              |
  교육부족        프로세스   |   서버성능       데이터품질
  경험부족        QA부재    |   메모리부족     API응답
  인력부족        배포방식   |   인프라한계     대용량파일
                         |
                         |
Environment    Measurement
     |              |
  출시압박        모니터링부족
  예산제약        로그분석
  조직문화        성능지표

3.3 Pareto Chart (80/20 법칙)

원리:

예시 데이터: 고객 문의 유형

문의 유형 건수 비율 누적 비율
배송 지연 450 45% 45%
상품 결함 300 30% 75%
결제 오류 150 15% 90%
기타 100 10% 100%

분석 결과:

액션:

  1. 배송 추적 시스템 고도화 (우선순위 1)
  2. 품질 관리 프로세스 강화 (우선순위 2)

4. Empathy Map (공감 지도)

4.1 구성 요소

Think & Feel (생각하고 느끼는 것):

See (보는 것):

Hear (듣는 것):

Say & Do (말하고 행동하는 것):

Pain (고통/불편):

Gain (이익/편익):

4.2 작성 예시: 직장인 점심 주문 앱

Persona: 직장인 김대리 (29세, 마케팅팀, 강남 근무)

+--------------------------------------------------+
|              Think & Feel                        |
|                                                  |
| • "점심시간이 너무 짧아"                          |
| • "항상 같은 메뉴만 먹게 되네"                    |
| • "건강한 식단을 유지하고 싶어"                   |
| • "새로운 맛집을 찾고 싶지만 시간이 없어"          |
| • "동료들과 함께 먹고 싶어"                       |
+--------------------------------------------------+
|       See                |        Hear           |
|                          |                       |
| • 동료들이 배달 앱 사용   | • "또 치킨이야?"       |
| • 사무실 근처 식당들     | • "이 집 맛있다더라"    |
| • 점심시간 대기줄        | • "다이어트 해야 해"    |
| • SNS 맛집 포스팅        | • "회식 때 가자"       |
|                          | • "건강 챙겨"          |
+--------------------------------------------------+
|               Say & Do                           |
|                                                  |
| • "뭐 먹을까?" (매일 반복)                        |
| • 배달 앱에서 리뷰 확인                          |
| • 같은 메뉴 반복 주문                            |
| • 점심시간 10분 전부터 고민                       |
| • 동료들과 메뉴 상의                             |
+--------------------------------------------------+
|       Pain               |        Gain           |
|                          |                       |
| • 선택장애 (너무 많은 옵션)| • 빠른 주문 완료       |
| • 배달 지연 (점심시간 초과)| • 새로운 맛집 발견     |
| • 메뉴 정보 부족         | • 건강한 식단          |
| • 주문 실수 (잘못된 옵션) | • 동료들과 함께 식사   |
| • 배송비 부담            | • 시간 절약           |
+--------------------------------------------------+

4.3 작성 팁

데이터 기반 작성:

구체적 표현:

팀 검증:

5. Jobs-to-Be-Done (JTBD) 프레임워크

5.1 JTBD 정의

프레임워크:

“When [상황], I want to [동기], so I can [기대 결과].”

Job 유형:

5.2 JTBD 예시

예시 1: 아침 출근길 뉴스 앱

예시 2: 피트니스 앱

예시 3: 온라인 쇼핑

5.3 JTBD 분석 포인트

상황 (Context) 중요성:

진정한 동기 파악:

경쟁 분석 관점:

6. 사용자 인터뷰 가이드

6.1 인터뷰 준비

목적 설정:

예시 목적:

리크루팅:

예시 리크루팅 기준:

Primary Target:
- 25-35세 직장인
- 강남/여의도 오피스 근무
- 주 3회 이상 배달 주문 경험

Secondary Target:
- 재택근무자
- 1인 가구
- 건강식 관심군

Exclusion:
- 학생 (구매력 다름)
- 자영업자 (시간 패턴 다름)
- 60세 이상 (디지털 사용 패턴 다름)

6.2 질문 스크립트

질문 유형:

단계별 질문 예시:

1단계: 워밍업 (5분)

- 자기소개 부탁드립니다
- 평소 점심은 어떻게 해결하세요?
- 오늘 점심은 뭘 드셨나요?

2단계: 현재 행동 탐구 (15분)

- 점심 메뉴를 정할 때 어떤 과정을 거치시나요?
- 배달 앱을 사용할 때 가장 먼저 하는 행동은?
- 메뉴 선택에 보통 얼마나 시간을 쓰세요?
- 주문 후에는 무엇을 하시나요?

3단계: 불편사항 탐구 (15분)

- 배달 주문할 때 가장 불편한 점은?
- 언제 주문을 포기하게 되나요?
- 실망했던 경험이 있다면?
- 이런 문제가 얼마나 자주 발생하나요?

4단계: 이상적 솔루션 탐구 (10분)

- 이상적으로는 점심 주문이 어떻게 되었으면 좋겠어요?
- 새로운 기능이 있다면 어떤 걸 원하세요?
- 돈을 더 내더라도 해결하고 싶은 문제가 있나요?

5단계: 마무리 (5분)

- 추가로 말씀하고 싶은 것이 있나요?
- 다른 동료분들은 어떻게 생각하실까요?

6.3 인터뷰 진행 윤리

사전 동의:

진행 태도:

개인정보 보호:

6.4 분석 워크플로우

1단계: Transcription (녹취록 작성)

2단계: Highlight (주요 인사이트 추출)

3단계: Clustering (그룹핑)

4단계: Mapping

5단계: 검증

인센티브 가이드:

7. SRS (Software Requirement Specification) 작성

7.1 SRS 개요

정의:

중요성:

7.2 SRS 문서 구조

1. 개요 (Introduction)

2. 전체 설명 (Overall Description)

3. 기능 요구사항 (Functional Requirements)

4. 비기능 요구사항 (Non-functional Requirements)

5. 외부 인터페이스 요구사항

7.3 기능 요구사항 예시

FR-001: 사용자 로그인

FR-002: 상품 검색

FR-003: 장바구니 담기

7.4 비기능 요구사항 예시

NFR-001: 응답 시간

NFR-002: 동시 접속

NFR-003: 보안

NFR-004: 접근성

NFR-005: 호환성

8. User Story 및 Acceptance Criteria

8.1 User Story 작성 형식

템플릿:

“As a [사용자 역할], I want [기능], so that [목적/가치].”

예시:

8.2 INVEST 원칙

I - Independent (독립적):

N - Negotiable (협상 가능):

V - Valuable (가치 제공):

E - Estimable (추정 가능):

S - Small (작은 단위):

T - Testable (테스트 가능):

8.3 Acceptance Criteria

Given-When-Then 형식:

예시 1: 장바구니 담기

User Story: 
As a 쇼핑몰 고객, I want 상품을 장바구니에 담을 수 있어서, 
나중에 한꺼번에 결제할 수 있다.

Acceptance Criteria:

Scenario 1: 로그인 사용자의 장바구니 담기
- Given: 사용자가 로그인된 상태
  And: 상품 상세 페이지에 있음
  And: 재고가 충분함
- When: "장바구니 담기" 버튼 클릭
- Then: 장바구니에 해당 상품이 추가됨
  And: 장바구니 아이콘에 수량 배지가 표시됨
  And: "장바구니에 추가되었습니다" 알림 표시
  And: 3초 후 알림이 자동으로 사라짐

Scenario 2: 비로그인 사용자
- Given: 사용자가 비로그인 상태
- When: "장바구니 담기" 버튼 클릭  
- Then: 로그인 페이지로 리다이렉트
  And: 로그인 후 해당 상품 페이지로 복귀

Scenario 3: 재고 부족
- Given: 상품 재고가 부족함 (1개 남음)
- When: 수량 2개로 "장바구니 담기" 클릭
- Then: "재고가 부족합니다 (1개 남음)" 에러 메시지
  And: 수량을 1개로 자동 조정 제안

예시 2: 검색 기능

User Story:
As a 쇼핑몰 고객, I want 원하는 상품을 빠르게 검색할 수 있어서,
시간을 절약하고 정확한 상품을 찾을 수 있다.

Acceptance Criteria:

Scenario 1: 일반 검색
- Given: 사용자가 메인 페이지에 있음
- When: 검색창에 "나이키 운동화" 입력 후 Enter
- Then: 검색 결과 페이지로 이동
  And: "나이키 운동화" 관련 상품 목록 표시
  And: 검색어가 하이라이트됨
  And: 검색 결과 수 표시 ("총 45개 상품")

Scenario 2: 검색 결과 없음  
- Given: 검색창에 존재하지 않는 브랜드명 입력
- When: 검색 실행
- Then: "검색 결과가 없습니다" 메시지 표시
  And: 연관 상품 추천 ("이런 상품은 어떠세요?")
  And: 인기 검색어 표시

Scenario 3: 자동완성
- Given: 검색창이 활성화된 상태
- When: "나이" 까지 입력
- Then: 자동완성 목록 표시 (나이키, 나일론 등)
  And: 방향키로 선택 가능
  And: Enter 또는 클릭으로 선택

8.4 Story Points 추정

Planning Poker 방법:

추정 기준:

🛠️ 실습 과제

과제 1: 문제 정의서 작성

과제 2: 5 Whys 분석

과제 3: Empathy Map 작성

과제 4: 사용자 인터뷰 실시

과제 5: User Story 작성

📖 참고 자료

🔄 복습 체크리스트

📝 다음 주 예습

Week 4: BMC & 시장 예측

← 이전: Week 2 목차 다음: Week 4 →

Last Updated: 2026-02-14