Elaboration Iteration에서 만드는 다이어그램과 그 흐름
Larman의 Applying UML and Patterns가 답하려는 질문은 하나다: 요구사항에서 코드까지, 객체지향으로 어떻게 체계적으로 도달하는가?
그 답은 Unified Process의 Elaboration 단계에서 iteration을 반복하며 드러난다.
Iteration 안에서 일어나는 일
매 iteration마다 아래 활동이 순서대로 연결된다:
각 산출물의 역할을 풀어보면 이렇다.
01-use-case-writing|Use Case → 사용자와 시스템 간의 상호작용을 텍스트로 기술한다. 모든 것의 출발점.
03-system-sequence-diagram|System Sequence Diagram (SSD) → 시스템을 블랙박스로 놓고, 외부 액터가 보내는 이벤트를 시간순으로 나열한다. "무엇을" 하는지만 다루고 "어떻게"는 아직 모른다.
06-operation-contract|Operation Contract → SSD에서 도출된 시스템 이벤트 각각에 대해 사전/사후 조건을 명세한다. 선택적이지만, 유스케이스 텍스트만으로 모호할 때 정밀도를 더해준다.
04-domain-model|Domain Model → 문제 도메인의 개념 클래스, 연관관계, 속성을 시각화한다. 소프트웨어 클래스가 아니라 현실 세계의 개념이다. 메서드가 없다.
08-interaction-diagram|Interaction Diagram → 설계의 심장. 소프트웨어 객체 간 메시지 흐름을 그리면서 "누가 이 책임을 질 것인가"를 결정한다. 이때 07-grasp-patterns|GRASP 패턴을 적용한다. SSD의 시스템 이벤트가 이 다이어그램의 첫 번째 메시지가 된다.
09-design-class-diagram|Design Class Diagram (DCD) → Interaction Diagram에서 발견된 클래스, 메서드, 관계를 정적으로 정리한다. Domain Model에서 이름을 빌려오지만 이건 소프트웨어 클래스 정의다.
3번의 Iteration, 각각의 강조점
Larman은 Elaboration을 3개 iteration으로 나눠서 보여주는데, 각각 다루는 깊이가 다르다.
Iteration 1 — 기본기. 단순한 cash-only 시나리오로 시작해서 "wide and shallow" 아키텍처를 세운다. 07-grasp-patterns|GRASP 기본 5개 패턴(Information Expert, Creator, Controller, Low Coupling, High Cohesion)을 적용하며 책임 할당의 감각을 잡는다.
Iteration 2 — 디자인 패턴. 10-gof-patterns|GoF 패턴(Adapter, Factory, Singleton, Strategy, Composite, Facade, Observer)을 도입한다. 외부 서비스 연동, 다양한 결제 방식 같은 복잡한 시나리오를 다루면서 패턴이 왜 필요한지를 체감시킨다.
Iteration 3 — 아키텍처와 정제. 아키텍처 분석, 프레임워크 설계, 일반화/특수화, 도메인 모델 정제. 시스템 전체의 구조를 다듬는 단계.
핵심 다이어그램 4개 (Mermaid 템플릿 우선순위)
매 iteration에서 실질적으로 만드는 다이어그램은 네 가지다:
| 다이어그램 | Mermaid 타입 | 핵심 포인트 |
|---|---|---|
| system-sequence-diagram-larman\|SSD | sequenceDiagram | 액터 → 시스템 이벤트. 블랙박스 관점 |
| domain-model-larman\|Domain Model | classDiagram (메서드 없음) | 현실 세계 개념. 속성과 연관관계만 |
| interaction-diagram-use-case-realization\|Interaction Diagram | sequenceDiagram | 시스템 내부 객체 간 메시지. GRASP 적용 지점 |
| design-class-diagram-larman\|DCD | classDiagram (메서드 포함) | Interaction Diagram 결과의 정적 정리 |
SSD와 Interaction Diagram은 둘 다 시퀀스 다이어그램이지만 관점이 다르다. SSD는 시스템 바깥에서 본 것이고, Interaction Diagram은 시스템 안을 열어본 것이다.
Elaboration을 잘못 이해한 징후
Larman이 꼽은 경고 신호들:
- Elaboration이 "몇 달" 이상 걸린다
- iteration이 1번뿐이다
- 대부분의 요구사항이 elaboration 전에 정의되었다
- 프로그래밍 없이 모델만 만든다
- 사용자 피드백 없이 진행한다
- 아키텍처를 프로그래밍 전에 확정하려 한다
이 증상이 보이면 waterfall을 iterative 껍데기로 포장한 것에 불과하다.
바이브 코딩 가이드
이 산출물들을 LLM 프롬프트에 활용하는 방법은 11-vibe-coding-with-ooad에 정리되어 있다.