OOA/D Inception Canvas
Larman의 Inception 단계에서 사용하는 한 페이지 캔버스. Lean Canvas나 BMC처럼 핵심 요소를 빠르게 정리하여 how-to-conduct-inception을 효율적으로 진행하고, OOA/D(Object-Oriented Analysis and Design)로 넘어가기 전 팀 정렬 도구로 사용한다.
템플릿 (한 페이지 형식)
┌─────────────────────────────────────────────────────────────────────────┐
│ OOA/D INCEPTION CANVAS │
│ [프로젝트 이름] - [날짜] │
└─────────────────────────────────────────────────────────────────────────┘
┌────────────────────────┬────────────────────────┬────────────────────────┐
│ 1. WHY (비전) │ 2. WHO (Actors) │ 3. SUCCESS (성공 기준)│
│ │ │ │
│ 우리가 해결하는 문제: │ Primary Actors: │ 프로젝트 성공이란: │
│ │ □ │ □ │
│ │ □ │ □ │
│ 핵심 가치: │ □ │ □ │
│ │ │ │
│ │ Supporting Actors: │ 측정 지표: │
│ │ □ │ □ │
│ │ □ │ □ │
└────────────────────────┴────────────────────────┴────────────────────────┘
┌────────────────────────────────────────────────────────────────────────┐
│ 4. WHAT (핵심 Use Cases - 10~20%) │
│ │
│ □ [Use Case 1] - Brief: ________________________________ │
│ □ [Use Case 2] - Brief: ________________________________ │
│ □ [Use Case 3] - Brief: ________________________________ │
│ □ [Use Case 4] - Brief: ________________________________ │
│ │
└─────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────┬──────────────────────────────────────────────┐
│ 5. DOMAIN (핵심 개념) │ 6. SCOPE (범위) │
│ │ │
│ 핵심 도메인 개념 5-7개:│ ✓ IN SCOPE (할 것): │
│ □ │ □ │
│ □ │ □ │
│ □ │ □ │
│ □ │ │
│ □ │ ✗ OUT OF SCOPE (하지 않을 것): │
│ │ □ │
│ 중요 관계: │ □ │
│ - [개념A] -- [개념B] │ □ │
│ │ │
└─────────────────────────┴──────────────────────────────────────────────┘
┌─────────────────────────┬──────────────────────────────────────────────┐
│ 7. RISKS (주요 리스크) │ 8. ARCHITECTURE SKETCH │
│ │ │
│ HIGH 리스크: │ [간단한 아키텍처 스케치] │
│ □ [리스크1] │ │
│ → 완화: ________ │ 계층: │
│ □ [리스크2] │ □ Presentation │
│ → 완화: ________ │ □ Application/Domain │
│ │ □ Persistence │
│ MEDIUM 리스크: │ │
│ □ [리스크3] │ 핵심 기술: │
│ │ □ [언어/프레임워크] │
│ 가정 (검증 필요): │ □ [DB] │
│ □ [가정1] │ □ [주요 라이브러리] │
│ □ [가정2] │ │
│ │ │
└─────────────────────────┴──────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────┐
│ 9. CONSTRAINTS (제약사항) │ 10. GO/NO-GO │
│ │ │
│ 기술적: │ □ GO - Elaboration으로 진행 │
│ □ │ □ NO-GO - 프로젝트 중단 │
│ □ │ │
│ │ 결정 날짜: __________ │
│ 비즈니스: │ 결정자: __________ │
│ □ │ │
│ □ │ 이유: │
│ │ │
│ 일정/예산: │ │
│ - 기간: _______ │ │
│ - 예산: _______ │ │
│ - 팀: _______ │ │
└─────────────────────────────────────┴───────────────────────────────────┘
사용 방법
1. 준비 (5분)
참가자: Product Owner, Tech Lead, 핵심 개발자 2-3명
자료: 화이트보드 또는 Miro/Mural에 이 캔버스 그리기
2. 작성 순서 (30분~1시간)
Step 1: WHY (10분)
- 문제 진술: "현재 [누가]는 [무엇] 때문에 고통받는다"
- 핵심 가치: "우리 시스템은 [어떻게] 해결한다"
Step 2: WHO (5분)
- Primary Actors: what-is-use-case에서 정의한 주요 사용자
- Supporting Actors: 외부 시스템, 서비스
Step 3: WHAT (10분)
- 핵심 what-is-use-case 3-5개만
- Brief format: 이름 + 한 줄 설명
Step 4: DOMAIN (10분)
- 핵심 도메인 개념 5-7개 (나중에 Domain Model의 핵심 클래스가 됨)
- 중요한 관계만 (has-a, is-a 등)
Step 5: SCOPE (5분)
- IN/OUT 명확히 구분
- "하지 않을 것"이 더 중요!
Step 6: RISKS (10분)
- HIGH 리스크 위주
- 각 리스크에 대한 완화 방안 간략히
Step 7: ARCHITECTURE (5분)
- 매우 간단한 스케치만
- 계층 구조, 주요 기술만
Step 8: CONSTRAINTS (5분)
- 기술적, 비즈니스, 일정/예산 제약
Step 9: SUCCESS (5분)
- 프로젝트 성공의 정의
- 측정 가능한 지표
Step 10: GO/NO-GO (5분)
- 팀 전체 합의
- 결정 기록
3. 결과
GO 결정 시:
- 이 캔버스 → Elaboration 단계의 입력
- Use Case를 Fully Dressed로 확장
- Domain Model 작성 시작
- 아키텍처 구체화
NO-GO 결정 시:
- 이것도 성공! (잘못된 것 만들지 않음)
- 캔버스 보관 (나중에 재검토 가능)
Markdown 템플릿
복사해서 바로 사용할 수 있는 마크다운 버전:
# OOA/D Inception Canvas: [프로젝트 이름]
**날짜**: [YYYY-MM-DD]
**참가자**: [이름들]
---
## 1. WHY (비전)
### 우리가 해결하는 문제
<!-- 현재 [누가]는 [무엇] 때문에 고통받는다 -->
### 핵심 가치
<!-- 우리 시스템은 [어떻게] 해결한다 -->
---
## 2. WHO (Actors)
### Primary Actors
- [ ]
- [ ]
- [ ]
### Supporting Actors (외부 시스템)
- [ ]
- [ ]
---
## 3. SUCCESS (성공 기준)
### 프로젝트 성공이란
- [ ]
- [ ]
- [ ]
### 측정 지표
- [ ]
- [ ]
---
## 4. WHAT (핵심 Use Cases - 10~20%)
- [ ] **[Use Case 1]**: [한 줄 설명]
- [ ] **[Use Case 2]**: [한 줄 설명]
- [ ] **[Use Case 3]**: [한 줄 설명]
- [ ] **[Use Case 4]**: [한 줄 설명]
---
## 5. DOMAIN (핵심 개념)
### 핵심 도메인 개념 (5-7개)
- [ ]
- [ ]
- [ ]
- [ ]
- [ ]
### 중요 관계
- [개념A] --has-a--> [개념B]
- [개념C] --is-a--> [개념D]
---
## 6. SCOPE (범위)
### ✓ IN SCOPE (할 것)
- [ ]
- [ ]
- [ ]
### ✗ OUT OF SCOPE (하지 않을 것)
- [ ]
- [ ]
- [ ]
---
## 7. RISKS (주요 리스크)
### HIGH 리스크
1. **[리스크1]**
- 완화:
2. **[리스크2]**
- 완화:
### MEDIUM 리스크
-
### 가정 (검증 필요)
- [ ]
- [ ]
---
## 8. ARCHITECTURE SKETCH
### 계층 구조
- [ ] Presentation
- [ ] Application/Domain
- [ ] Persistence
### 핵심 기술
- **언어/프레임워크**:
- **데이터베이스**:
- **주요 라이브러리**:
### 간단한 스케치
<!-- 여기에 아키텍처 다이어그램 또는 설명 -->
---
## 9. CONSTRAINTS (제약사항)
### 기술적
-
-
### 비즈니스
-
-
### 일정/예산
- **기간**:
- **예산**:
- **팀 규모**:
---
## 10. GO/NO-GO
- [ ] **GO** - Elaboration으로 진행
- [ ] **NO-GO** - 프로젝트 중단
**결정 날짜**: [YYYY-MM-DD]
**결정자**: [이름]
**이유**:
---
## Next Steps
**GO 결정 시**:
1. Use Case를 Fully Dressed로 확장
2. Domain Model 작성 시작
3. System Sequence Diagram 작성
4. 첫 iteration 계획
**NO-GO 결정 시**:
- 이 캔버스 보관
- 미래 재검토 가능성 열어두기
Miro/Mural 템플릿 레이아웃
물리적 보드나 Miro에서 사용할 때:
┌─────────────────────────────────────────────────────────┐
│ OOA/D INCEPTION CANVAS │
│ [프로젝트 이름] │
└─────────────────────────────────────────────────────────┘
┌──────────┬──────────┬──────────┬──────────┬────────────┐
│ WHY │ WHO │ SUCCESS │ WHAT │ DOMAIN │
│ │ │ │ │ │
│ 큰 블록 │ 중간 블록│ 중간 블록│ 큰 블록 │ 중간 블록 │
│ │ │ │ │ │
└──────────┴──────────┴──────────┴──────────┴────────────┘
┌────────────────────┬────────────────────┬──────────────┐
│ SCOPE │ RISKS │ ARCHITECTURE │
│ │ │ │
│ 중간 블록 │ 중간 블록 │ 중간 블록 │
│ │ │ │
└────────────────────┴────────────────────┴──────────────┘
┌─────────────────────────────┬──────────────────────────┐
│ CONSTRAINTS │ GO/NO-GO │
│ │ │
│ 작은 블록 │ 작은 블록 │
│ │ │
└─────────────────────────────┴──────────────────────────┘
색상 코딩 (추천):
- WHY/SUCCESS: 노란색 (목표 관련)
- WHO/WHAT: 파란색 (기능 관련)
- DOMAIN: 초록색 (모델 관련)
- RISKS/CONSTRAINTS: 빨간색 (제약 관련)
- ARCHITECTURE: 보라색 (기술 관련)
- SCOPE: 주황색 (경계 관련)
- GO/NO-GO: 회색 (결정 관련)
다른 캔버스와의 비교
vs Lean Canvas
| OOA/D Inception Canvas | Lean Canvas | |---|---| | OOA/D 시작 전 정렬 | 스타트업 비즈니스 모델 | | Use Case 중심 | Problem/Solution 중심 | | Actors & Domain 명시 | Customer Segments 중심 | | 기술 아키텍처 포함 | 수익 모델 중심 | | Go/No-Go 결정 | 지속적 pivot |
vs Business Model Canvas
| OOA/D Inception Canvas | BMC | |---|---| | 소프트웨어 프로젝트 범위 | 전체 비즈니스 모델 | | 기술적 실현 가능성 | 비즈니스 실행 가능성 | | Elaboration 입력 | 사업 계획 입력 |
vs Larman's UP Inception 산출물
| OOA/D Canvas (한 페이지) | UP Inception (여러 문서) | |---|---| | 30분~1시간 작성 | 1-2주 작성 | | 팀 정렬 도구 | 공식 문서 | | 캔버스 형태 | Vision Doc, Use Case Model, Risk List... | | 가볍고 빠름 | 완전하고 상세 |
결론: OOA/D Canvas는 UP Inception의 **최소 실행 가능 버전(MVP)**이다.
실전 사용 예시
예시: POS 시스템
# OOA/D Inception Canvas: NextGen POS
**날짜**: 2026-02-15
**참가자**: Alice (PO), Bob (Tech Lead), Carol (Dev), Dave (Dev)
---
## 1. WHY
**문제**: 소규모 매장이 복잡하고 비싼 POS 시스템 때문에 어려움
**가치**: 5분 안에 배울 수 있는 간단한 클라우드 POS
---
## 2. WHO
**Primary**: Cashier, Manager
**Supporting**: Payment Service, Tax Calculator
---
## 3. SUCCESS
- 매장 주인이 1일 안에 직접 설정
- 계산대당 평균 30초 이내 결제
- 월 구독료 $50 이하
---
## 4. WHAT
- [x] **Process Sale**: 고객이 상품을 구매한다
- [x] **Handle Returns**: 상품을 반품한다
- [x] **Cash In/Out**: 현금을 넣고 뺀다
- [ ] **Generate Reports**: 일일 매출 보고서
---
## 5. DOMAIN
**핵심 개념**:
- Sale
- SaleLineItem
- Product
- Payment
- Register
**관계**:
- Sale --has-many--> SaleLineItem
- SaleLineItem --refers-to--> Product
- Sale --has-one--> Payment
---
## 6. SCOPE
**IN**:
- 상품 판매 & 반품
- 현금/카드 결제
- 기본 보고서
**OUT**:
- 재고 자동 발주
- 직원 급여 관리
- 온라인 판매 통합
---
## 7. RISKS
**HIGH**:
1. 카드 결제 연동 안 될 수 있음
- 완화: PaymentService API 사전 검증
2. 동시 10대 성능 문제
- 완화: 초기 프로토타입 부하 테스트
**가정**:
- [ ] 매장에 안정적인 인터넷 연결 있음
- [ ] Cashier가 기본 컴퓨터 사용 가능
---
## 8. ARCHITECTURE
**계층**:
- Web UI (React)
- REST API (Node.js)
- PostgreSQL
**핵심 기술**:
- React + TypeScript
- Express.js
- Stripe (결제)
---
## 9. CONSTRAINTS
**기술**: 클라우드만 (온프레미스 불가)
**비즈니스**: PCI-DSS 준수 필요
**일정**: 6개월, 5명
---
## 10. GO/NO-GO
- [x] **GO**
**날짜**: 2026-02-15
**결정자**: Alice (PO)
**이유**: 리스크 관리 가능, 명확한 시장 니즈
핵심 원칙
1. 한 페이지, 한 시간
- 30분~1시간 안에 작성
- 상세 내용은 Elaboration에서
- Inception은 "탐색"이지 "설계" 아님
2. 팀 정렬이 목표
- 문서 완성도 < 팀 이해도
- 모든 블록 채울 필요 없음
- 중요한 것: 같은 그림 보기
3. Living Document
- Inception 이후에도 계속 업데이트
- Elaboration에서 배운 것 반영
- "얼어붙은 문서" 아님
4. Go/No-Go 결정 도구
- 캔버스 완성 != 자동 Go
- 리스크 감당 가능? → Go
- 리스크 너무 높음? → No-Go
- No-Go도 성공
이 캔버스는 unified-process-phases의 Inception을 Lean Canvas/BMC 스타일로 재해석한 것이다. 복잡한 문서 대신 한 페이지로 빠르게 팀을 정렬하고, OOA/D로 자연스럽게 넘어갈 수 있게 한다.