부제 : 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 팀이 빠르고 정확하게 제품을 만들 수 있도록 돕는 방법론입니다.

핵심은 **"완벽한 문서"**가 아닌 **"지속적인 대화"**입니다.