Unified Process의 4단계: Inception → Elaboration → Construction → Transition
Larman이 소개하는 RUP(Rational Unified Process) 또는 UP(Unified Process)는 반복적/점진적 개발 방법론이다. 전통적인 Waterfall처럼 순차적으로 진행하지 않고, 각 단계 내에서 여러 번의 iteration을 돌며 점진적으로 시스템을 완성한다.
1. Inception (시작 단계)
목표: "이 프로젝트를 할 만한가?"를 판단하는 단계
주요 활동
- 프로젝트 비전과 범위를 대략적으로 설정
- 핵심 use case 10~20% 정도만 식별
- 주요 리스크 파악 (기술적 불확실성, 비용, 일정)
- 비용 대비 효과 평가
- 프로젝트 계속 진행 여부 결정
산출물
- Vision 문서
- 초기 Use Case 모델
- 대략적인 아키텍처 스케치
- 초기 리스크 목록
기간
전체 프로젝트의 약 10%
핵심 질문
- "이 시스템을 만들 가치가 있는가?"
- "대략 얼마나 걸리고 얼마나 드는가?"
- "기술적으로 실현 가능한가?"
2. Elaboration (정교화 단계)
목표: "어떻게 만들 것인가?"에 대한 구체적인 답을 마련하는 단계
이 단계가 UP에서 가장 중요하다. 많은 프로젝트가 여기를 대충 하고 넘어가서 Construction에서 큰 문제를 겪는다.
주요 활동
- 아키텍처의 핵심을 실제로 구현 (프로토타입이 아니라 production 수준의 코드)
- 가장 위험한 부분부터 공략 (성능 이슈, 새로운 기술, 복잡한 알고리즘 등)
- Use case의 약 80%를 식별하고 분석
- Domain Model 구체화
- 여러 iteration을 통해 점진적으로 완성도 향상
산출물
- 실행 가능한 아키텍처 베이스라인 (Executable Architecture Baseline)
- 대부분의 Use Case 명세
- 구체화된 Domain Model
- 상세한 프로젝트 계획
기간
전체 프로젝트의 30~40%
왜 중요한가?
- Construction 단계에 들어가기 전에 큰 불확실성을 제거해야 한다
- "나중에 알고 보니 안 되더라"를 방지
- 이 단계가 끝나면 "이제 나머지는 반복 작업"이라는 확신이 생겨야 한다
- 아키텍처의 핵심 리스크가 모두 검증되어야 한다
Elaboration vs Prototyping
- 프로토타입: 빨리 만들어서 버리는 코드
- Elaboration의 산출물: 실제로 사용할 아키텍처 기반
3. Construction (구축 단계)
목표: 아키텍처 위에 나머지 기능을 빠르게 채워 넣기
주요 활동
- Elaboration에서 확립한 아키텍처 위에 기능 추가
- 여러 iteration을 통해 점진적으로 완성
- 테스트, 통합
- 배포 준비
산출물
- 완성된 시스템
- 테스트 결과
- 사용자 매뉴얼
기간
전체 프로젝트의 40~50%
특징
- Elaboration이 제대로 됐다면 비교적 예측 가능한 단계
- 큰 아키텍처 변경은 없어야 함 (있다면 Elaboration을 제대로 안 한 것)
- 각 iteration마다 동작하는 시스템을 만듦
- 대부분의 코딩이 여기서 발생
4. Transition (전환 단계)
목표: 실제 운영 환경으로 시스템을 이전
주요 활동
- 베타 테스트
- 사용자 교육
- 배포 및 설치
- 운영 환경에서의 문제 해결
- 성능 튜닝, 버그 수정
산출물
- 배포된 시스템
- 운영 문서
- 교육 자료
기간
전체 프로젝트의 10~20%
주의점
- "완성했다고 끝이 아니다"
- 실제 사용 환경에서는 개발 환경에서 몰랐던 문제가 드러난다
- 사용자 피드백에 따라 작은 수정이 계속 발생
핵심 철학
전통적 Waterfall과의 차이
Waterfall:
- 분석 → 설계 → 구현 → 테스트 (각 단계를 한 번씩 순차적으로)
- 문제: 후반부에 가서야 큰 문제 발견
UP:
- Inception → (Elaboration의 여러 반복) → (Construction의 여러 반복) → Transition
- 각 iteration마다 분석/설계/구현/테스트를 모두 수행
- 점진적으로 리스크를 줄이고 이해도를 높임
반복적 개발 (Iterative Development)
각 단계, 특히 Elaboration과 Construction은 여러 번의 iteration으로 구성된다:
- 각 iteration은 2~6주 정도의 짧은 주기
- iteration마다 동작하는 소프트웨어를 만듦
- iteration마다 분석, 설계, 구현, 테스트를 다 함
- 점진적으로 기능이 추가되고 완성도가 높아짐
Larman이 강조하는 핵심 원칙
1. Early & High-Risk First
- Elaboration 단계에서 가장 어렵고 위험한 것부터 해결해야 한다
- 불확실성이 높은 기술적 요소를 먼저 검증
- "쉬운 것부터"가 아니라 "리스크 높은 것부터"
2. Architecture-Centric
- 아키텍처가 프로젝트의 성패를 좌우한다
- Elaboration에서 아키텍처를 제대로 세우지 못하면 Construction에서 엄청난 재작업 발생
- 아키텍처는 문서가 아니라 실행 가능한 코드로 검증되어야 한다
3. Iterative & Incremental
- 한 번에 완벽하게 만들려고 하지 않는다
- 작은 단위로 반복하면서 점진적으로 완성
- 각 iteration에서 피드백을 받고 개선
실전에서의 함정
Elaboration을 대충 하는 경우
- "일단 코딩부터" 하고 싶은 유혹
- 결과: Construction에서 아키텍처 문제 발견 → 대규모 재작업
- Elaboration의 목적은 리스크 제거임을 잊지 말 것
Inception을 너무 길게 하는 경우
- 완벽한 요구사항을 모으려는 시도
- Inception은 "Go/No-Go 결정"을 위한 단계일 뿐
- 자세한 것은 Elaboration과 Construction에서 반복적으로 발견
Construction에서 아키텍처 변경
- Construction에서 큰 아키텍처 변경이 발생한다면, Elaboration을 제대로 안 한 것
- 작은 개선은 괜찮지만, 근본적인 구조 변경은 경고 신호
이 4단계 접근법의 핵심은 불확실성을 점진적으로 줄여가는 것이다. Inception에서 "할까?"를 결정하고, Elaboration에서 "어떻게?"를 확실히 하고, Construction에서 "만들고", Transition에서 "넘긴다". 각 단계가 다음 단계의 리스크를 줄여준다.