부제 : Shape-Driven Development
현재 문제 상황 분석
우리가 겪고 있는 핵심 문제는 **"고약한 문제"**를 **"합당한 문제"**처럼 다루려 했기 때문입니다. PRD에 모든 것을 담으려 하고, 개발 시작 전 완벽한 문서를 원하는 것은 전형적인 워터폴 사고방식의 한계를 보여줍니다.
PRD 과부하의 문제점
- 범위 혼재: 비즈니스 방향성과 기술적 세부사항이 뒤섞임
- 해석의 어려움: 추상적 요구사항과 구체적 구현이 구분되지 않음
- 변경 저항성: 모든 것이 하나의 문서에 있어 변경 시 전체가 흔들림
요구사항 분석의 빈약함
- 시기적 문제: 구현 단계에서야 상세 분석 시작
- 커뮤니케이션 부족: 도메인 전문가(기획자)와 개발자 간 언어 불일치
- 책임 모호: 누가 언제 무엇을 분석해야 하는지 불분명
새로운 하이브리드 방법론: "Shape-Driven Development"
Shape Up + DDD + 선별적 워터폴의 조합으로, 50인 미만 B2B SaaS 조직에 최적화된 방법론입니다.
1단계: Shaping (방향성 설정) - PRD의 올바른 역할
PRD는 "심오한 간결성"을 추구해야 합니다.
PRD 작성 원칙
✅ 포함해야 할 것:
- 해결하려는 비즈니스 문제 (Why)
- 핵심 사용자 시나리오 3-5개
- 성공 지표와 제약사항
- 대략적인 해결 방향 (What의 방향성)
❌ 포함하지 말아야 할 것:
- 구체적인 UI/UX 세부사항
- 기술적 구현 방법
- 데이터베이스 스키마
- API 스펙Shape 기반 PRD 템플릿
## 문제 정의 (Problem)
- 현재 고객이 겪는 pain point
- 비즈니스 임팩트 (정량적 지표)
## 핵심 사용자 여정 (Key User Journey)
- As a [user type], I want to [goal] so that [business value]
- 3-5개의 핵심 시나리오만
## 성공 기준 (Success Criteria)
- 측정 가능한 지표
- 6주 내 달성 가능한 범위
## 제약사항과 경계 (Constraints & Boundaries)
- 하지 않을 것 (Out of Scope)
- 기술적/비즈니스적 제약
2단계: Domain Analysis (요구사항 분석) - BA의 전문 영역
워터폴의 장점을 활용한 체계적 분석 단계
BA 문서의 목적과 범위
- 목적: Shape을 실행 가능한 구체적 요구사항으로 변환
- 범위: 기술적 구현이 아닌 비즈니스 로직과 규칙 명세
- 기간: 1-2주 집중 분석 (전체 6주 사이클의 1/3)
요구사항 분석 문서 구조
## 1. 도메인 모델링
### 핵심 엔티티와 관계
- 비즈니스 객체 정의
- 상태 전이 다이어그램
- 비즈니스 규칙과 제약사항
## 2. 기능 명세 (Functional Requirements)
### 유스케이스별 상세 플로우
- 정상 플로우
- 예외 상황 처리
- 비즈니스 규칙 적용
## 3. 비기능 요구사항 (Non-Functional Requirements)
- 성능 요구사항
- 보안 요구사항
- 확장성 고려사항
## 4. 인터페이스 정의
- 외부 시스템 연동 포인트
- 데이터 형식과 검증 규칙
- 에러 처리 방식3단계: Collaborative Building (협업 기반 구현)
일일 도메인 모델링 세션 (Daily Domain Session)
- 참여자: 기획자(도메인 전문가) + 개발자 + 디자이너
- 시간: 매일 30분
- 목적: 유비쿼터스 언어 구축 및 모델 정제
구현 우선순위: "Vertical Slice" 접근
1주차: 핵심 엔티티 1개 + 기본 CRUD (완전한 세로 조각)
2주차: 핵심 비즈니스 로직 1개 구현
3-4주차: 추가 엔티티 및 관계 구현
5-6주차: 통합 및 비기능 요구사항 구현협업 도구와 프로세스
문서 협업 방식
- PRD: 기획자 주도 + 전체 팀 리뷰
- BA 문서: 기획자-개발자 페어 분석
- 구현: 개발자 주도 + 일일 도메인 세션
문서 품질 보장 체계
PRD 단계: "간결함 체크리스트"
- 10분 내 읽을 수 있는가?
- 핵심 시나리오 3개로 요약 가능한가?
- 측정 가능한 성공 기준이 있는가?
BA 단계: "완전성 체크리스트"
- 모든 예외 상황이 정의되었는가?
- 비즈니스 규칙이 명확한가?
- 외부 의존성이 식별되었는가?상황극: 실패 vs 성공 시나리오
😨 실패 시나리오: "완벽주의의 함정"
배경: B2B 고객 온보딩 기능 개발
1주차 월요일 스프린트 시작
기획자: "PRD 봤죠? 온보딩 플로우 구현하면 됩니다."
개발자: "이 PRD로는 DB 설계도 못하겠는데요? 단계가 몇 개인지도 모르겠고..."
기획자: "UX 보면 나와있잖아요. 바보같은 질문 하지 마세요."
2주차 화요일
개발자: "온보딩 중간에 결제 실패하면 어떻게 처리하죠?"
기획자: "그건... 당연히 다시 시도하게 해야죠."
개발자: "몇 번까지요? 실패 로그는 어디에 남기죠? 관리자는 볼 수 있나요?"
기획자: "그런 세부사항까지 다 정해줘야 하나요?"
4주차 목요일
PM: "진행률이 30%밖에 안 되네요. 왜 이렇게 늦죠?"
개발자: "요구사항이 계속 바뀌어서..."
기획자: "저는 바뀐 적 없는데요?"결과: 6주 후 50% 완성도로 사이클 실패, 팀 간 신뢰 저하
😊 성공 시나리오: "Shape-Driven 협업"
배경: 동일한 B2B 고객 온보딩 기능 개발
사이클 시작 전 (Shaping 완료)
PRD 요약: "신규 B2B 고객이 30분 내 기본 설정을 완료하고 첫 번째 프로젝트를 생성할 수 있다"
핵심 시나리오 3개:
1. 회사 정보 입력 → 팀원 초대 → 첫 프로젝트 생성
2. 결제 설정 → 플랜 선택 → 서비스 활성화
3. 온보딩 중단 → 이메일 리마인더 → 재시작
1주차 (Domain Analysis)
기획자 + 개발자: 매일 30분 도메인 모델링
- "온보딩 상태"는 어떻게 정의할까?
- "팀원 초대"와 "권한 설정"의 관계는?
- "결제 실패" 시나리오별 대응 방안
월요일: 엔티티 정의 (Company, User, OnboardingStep)
화요일: 상태 전이 정의 (Draft → InProgress → Completed → Failed)
수요일: 비즈니스 규칙 정의 (재시도 횟수, 타임아웃, 알림 조건)
목요일: 외부 연동 정의 (결제 게이트웨이, 이메일 서비스)
금요일: BA 문서 검토 및 확정
2주차 (First Vertical Slice)
개발자: Company 엔티티 + 기본 정보 입력 화면 + API 완성
기획자: 매일 30분 세션에서 화면 검토 및 예외상황 발견
"회사명 중복 체크는 어떻게 하죠?" → 즉석에서 논의하고 BA 문서 업데이트
3주차 (Core Business Logic)
개발자: 팀원 초대 로직 구현
기획자: 권한 설정 시나리오 추가 발견 → 함께 해결 방안 도출
"초대받은 사람이 이미 다른 회사 소속이면?" → 새로운 비즈니스 규칙 추가
6주차 완료
결과: 핵심 시나리오 100% 구현, 예외상황 처리 완료
보너스: 개발 과정에서 발견된 UX 개선사항 반영성공 요인:
- 명확한 역할 분담: PRD는 방향성만, BA는 구체적 요구사항만
- 지속적 협업: 매일 30분 도메인 세션으로 오해 제거
- 점진적 구현: 완전한 기능 조각부터 시작해 확장
- 빠른 피드백: 문제 발생 즉시 논의하고 해결
결론: AI 시대에 더욱 중요한 인간의 협업
AI가 코드를 생성하는 시대일수록, **"무엇을 만들지"**와 **"왜 만드는지"**에 대한 인간의 협업이 더욱 중요해집니다. Shape-Driven Development는 이러한 협업을 체계화하여 50인 미만의 B2B SaaS 팀이 빠르고 정확하게 제품을 만들 수 있도록 돕는 방법론입니다.
핵심은 **"완벽한 문서"**가 아닌 **"지속적인 대화"**입니다.