learn

Inception 단계는 어떻게 진행하는가

Inception 단계는 어떻게 진행하는가

Inception은 "설계"하는 단계가 아니라 "탐색"하는 단계다. 많은 사람들이 Inception을 상세 설계 단계로 오해하지만, 실제로는 프로젝트의 실행 가능성을 빠르게 판단하는 것이 목적이다.


Inception의 본질

핵심 목표

"이 프로젝트를 할까 말까?"를 결정하는 Go/No-Go 의사결정 단계

Inception은 unified-process-phases에서 가장 짧은 단계로, 전체 프로젝트의 약 10% 정도만 차지한다.

하는 것 vs 하지 않는 것

Inception에서 하는 것:

  • 프로젝트 비전 정의
  • 범위 대략 설정
  • 핵심 기능 10~20%만 식별
  • 주요 리스크 파악
  • 대략적인 비용/일정 추정
  • Go/No-Go 결정

Inception에서 하지 않는 것:

  • 상세 설계 ❌
  • 아키텍처 설계 ❌
  • 데이터베이스 스키마 설계 ❌
  • UI/UX 설계 ❌
  • 전체 요구사항 수집 ❌
  • 프로토타입 개발 ❌

왜 설계를 하지 않는가

불확실성이 너무 높다

Inception 시점에는:

  • 요구사항이 명확하지 않음
  • 사용자가 진짜 무엇을 원하는지 모름
  • 기술적 제약이 무엇인지 모름
  • 도메인 이해도가 낮음

이 상태에서 설계를 하면:

  • 나중에 대부분 바뀜 → 시간 낭비
  • 잘못된 가정에 기반한 설계 → 프로젝트 실패 리스크
  • Analysis Paralysis (분석 마비) → 프로젝트가 시작도 못함

반복적 개발의 철학

전통적 Waterfall:
Inception에 모든 걸 다 정의 → 나중에 변경 불가

Larman/UP 방식:
Inception에 최소한만 → Elaboration에서 발견 → 반복하며 정제

Inception의 구체적 활동

기간

보통 1~2주 정도 (짧게!)

주요 활동

1. 비전 문서 작성 (Vision Document)

목적: "우리가 뭘 만드는가?"를 한 페이지로 요약

내용:

  • 문제 진술: "현재 어떤 문제가 있는가?"
  • 제안 솔루션: "우리 시스템은 X를 Y하게 해준다"
  • 핵심 가치 제안
  • 주요 이해관계자

길이: 1~2 페이지 (길면 안 됨)

예시 (POS 시스템):

Vision: "소규모 매장을 위한 간단하고 빠른 POS 시스템"

Problem: 
기존 POS는 너무 복잡하고 비싸서 소상공인이 쓰기 어렵다

Solution:
- 직관적인 UI로 5분 안에 사용법 습득
- 클라우드 기반으로 설치 불필요
- 월 구독료 $50

2. 핵심 Use Case 식별

전체가 아니라 핵심만 (10~20%)

Brief Format으로 작성:

  • Use Case 이름 + 한 줄 설명
  • 상세 시나리오 ❌

예시 (POS 시스템):

Use Case 목록:
1. Process Sale - 고객이 상품을 구매한다
2. Handle Returns - 고객이 상품을 반품한다
3. Cash In/Out - 계산대에 현금을 넣거나 빼낸다
4. Generate End-of-Day Report - 일일 매출을 집계한다

3. Actor 식별

누가 시스템을 사용하는가?

  • 사람 (Cashier, Manager, Customer)
  • 외부 시스템 (Payment Service, Tax Calculator)

예시:

Primary Actors:
- Cashier (계산원)
- Manager (관리자)

Supporting Actors:
- Payment Authorization Service (카드 승인)
- Tax Calculator Service (세금 계산)

4. 리스크 목록 작성

기술적 리스크:

  • "실시간 카드 승인 통합 가능한가?"
  • "동시에 10개 계산대 처리 가능한가?"

비즈니스 리스크:

  • "예산 안에서 완성 가능한가?"
  • "경쟁 제품 대비 우위 확보 가능한가?"

조직 리스크:

  • "개발팀에 필요한 기술력이 있는가?"
  • "이해관계자들의 합의 가능한가?"

5. 대략적 추정

얼마나? (비용):

  • ±50% 오차 허용
  • "대략 $300K 정도"

얼마 동안? (일정):

  • "6개월 정도"
  • 정확하지 않아도 됨

몇 명? (인력):

  • "개발자 3명, 디자이너 1명, PM 1명"

6. Go/No-Go 결정

결정 기준:

  • ROI (투자 대비 수익)
  • 기술적 실현 가능성
  • 리스크 vs 기회

결과:

  • Go: Elaboration으로 진행
  • No-Go: 프로젝트 취소 (이것도 중요한 결정!)

Inception 활동 타임라인 예시

1주 스프린트:

Day 1-2: Vision 워크샵
- 이해관계자 인터뷰
- 문제 정의
- Vision 문서 작성

Day 3: Actor & Use Case 식별
- 브레인스토밍
- 핵심 Use Case 10개 정도 도출

Day 4: 리스크 분석
- 기술 스파이크 필요성 판단
- 리스크 목록 작성

Day 5: 추정 & 결정
- 대략적 추정
- Go/No-Go 회의

Inception의 산출물

1. Vision Document (1-2페이지)

  • 프로젝트 목표와 범위

2. Initial Use Case Model (간략)

  • Use Case 목록 (Brief format)
  • Actor 목록

3. Supplementary Specification (초안)

  • 비기능 요구사항 (성능, 보안 등)
  • 제약사항

4. Glossary (용어집)

  • 도메인 용어 정의
  • 예: "Sale", "Line Item", "Payment"

5. Risk List

  • 주요 리스크와 우선순위

6. Business Case (경영 사례)

  • 비용/편익 분석
  • ROI 추정

Inception vs Elaboration

비유: 여행 계획

Inception (1주):
"제주도 갈까? 얼마 들까? 재밌을까?"
- 예산: 대략 100만원
- 기간: 3박 4일
- 볼 것: 한라산, 해변, 맛집
→ 결정: 간다!

Elaboration (4주):
- 비행기 예약
- 호텔 선택
- 일정표 작성
- 렌터카 vs 대중교통 결정
- 주요 코스 구체화

Construction (12주):
- 실제 여행
- 계획대로 실행

Inception의 깊이

요구사항 수집:

  • Inception: 10~20%
  • Elaboration: 80~90%
  • Construction: 나머지

분석 깊이:

  • Inception: "어떤 기능이 필요한가?" (목록)
  • Elaboration: "어떻게 동작하는가?" (상세 시나리오, 모델)
  • Construction: "어떻게 구현하는가?" (코드)

흔한 실수들

1. Inception을 너무 길게

증상:

  • 한 달 넘게 요구사항 수집
  • "모든 것을 명확히 하고 시작하자"

문제:

  • Analysis Paralysis
  • 아직 잘 모르는 상태에서 결정 → 나중에 다 바뀜
  • 프로젝트 시작이 늦어짐

해결:

  • Inception은 1~2주로 제한
  • 불확실한 것은 Elaboration에서 해결

2. Inception에서 설계 시작

증상:

  • 데이터베이스 ERD 그리기
  • 클래스 다이어그램 작성
  • 아키텍처 문서 작성

문제:

  • 아직 요구사항도 명확하지 않은데 설계?
  • 나중에 요구사항 바뀌면 설계도 다 바뀜

해결:

  • 설계는 Elaboration에서
  • Inception은 "무엇을"에 집중, "어떻게"는 나중에

3. 완벽한 Use Case 작성

증상:

  • Fully Dressed Format으로 모든 Use Case 작성
  • 모든 예외 상황까지 다 정의

문제:

  • 시간 낭비
  • 아직 잘 모르는 상태에서 쓴 것 → 나중에 다 바뀜

해결:

  • Brief Format으로만 (이름 + 한 줄)
  • 상세 내용은 Elaboration에서

성공적인 Inception의 신호

좋은 Inception 끝난 후

명확한 것:

  • 프로젝트가 왜 필요한가 (Vision)
  • 누가 사용하는가 (Actors)
  • 핵심 기능이 무엇인가 (Key Use Cases)
  • 주요 리스크가 무엇인가

불명확해도 되는 것:

  • 정확한 일정
  • 모든 요구사항
  • 기술 스택
  • 아키텍처 설계

결정:

  • 프로젝트를 계속할지 말지 명확

핵심 원칙

1. 짧게 (Keep it Short)

  • 1~2주면 충분
  • 길어야 전체의 10%

2. 가볍게 (Keep it Light)

  • 두꺼운 문서 ❌
  • 핵심만 1~2페이지

3. 탐색적으로 (Exploratory)

  • "정답 찾기"가 아니라 "가능성 탐색"
  • 틀려도 됨, 나중에 수정할 것

4. 결정 지향적 (Decision-focused)

  • 목표는 Go/No-Go 결정
  • 설계는 목적이 아님

Inception은 "빨리 가볍게 탐색하고, Elaboration에서 진짜 시작"하는 단계다. "준비에 준비를 거듭하다가 시작도 못하는" 함정을 피하기 위한 장치이기도 하다.