🎯 방법론 개요

하이브리드 셰이핑은 Shape Up의 유연성, 워터폴의 구조적 안정성, AI Agentic의 협업 효율성을 결합한 중소 개발사 맞춤형 방법론입니다.

핵심 원칙

• 3층 문서 구조: PRD → BA → 구현 단계별 명확한 책임
• 4+1주 사이클: B2B SaaS에 최적화된 개발 주기
• AI 협업 중심: 문서 작성부터 코드 구현까지 AI가 능동적 지원

📋 3층 문서 구조

1단계: PRD (Product Requirements Document)

목적: "왜 만드는가?"의 심오한 간결성

작성 내용:

• 문제 정의: 고객 페인 포인트, 비즈니스 임팩트
• 핵심 사용자 스토리: 3-5개 메인 플로우
• 제약사항: 기술적/비즈니스적 제약, 성공 기준

AI 역할: 경쟁사 분석, 스토리 일관성 검증, 비즈니스 로직 검토

2단계: BA (Business Analysis Document)

목적: "어떻게 만들 것인가?"의 빈틈없는 설계

작성 내용:

• 요구사항 매트릭스: 기능별 상세 요구사항, 예외 처리, 검증 기준
• 데이터 모델: ERD, 비즈니스 규칙과 데이터 규칙 매핑
• API 스펙: OpenAPI 기반 명세, 프론트엔드-백엔드 계약

AI 역할: 누락 요구사항 탐지, 예외 상황 시나리오 생성, 데이터 모델 검증

3단계: 구현 문서

목적: "무엇을 코딩할 것인가?"의 기술적 상세

작성 내용:

• 아키텍처 설계: 컴포넌트 구조, 의존성 관리
• 테스트 케이스: 단위/통합/E2E 테스트 시나리오
• 배포 계획: CI/CD 파이프라인, 롤백 전략

AI 역할: 코드 생성, 테스트 케이스 작성, 리팩토링 제안

⏰ 4+1주 개발 사이클

📅 개발 사이클 구조

Week 1: PRD 완성 → BA 시작
├── PRD 리뷰 및 승인
├── BA 요구사항 분석 착수
└── 이전 사이클 배포 및 피드백 수집

Week 2-3: BA 완성 → 구현 시작
├── BA 문서 완성 및 검토
├── API 스펙 확정
├── 개발 환경 설정
└── 핵심 기능 구현

Week 4: 구현 완료 → 테스트
├── 기능 구현 완료
├── 통합 테스트
├── 사용자 테스트
└── 버그 수정

Week 5: 버퍼 + 다음 사이클 준비
├── 배포 준비 및 문서 정리
├── 다음 사이클 PRD 셰이핑
├── 팀 회고 및 프로세스 개선
└── 기술 부채 정리

🤖 AI Agentic 협업 프로세스

PRD 단계에서의 AI 활용

AI의 능동적 역할:

• 시장 동향 분석 및 경쟁사 벤치마킹
• 사용자 스토리 일관성 자동 검증
• 비즈니스 로직의 누락 사항 탐지
• 성공 지표 및 KPI 제안

인간의 전략적 역할:

• 비즈니스 가치 판단 및 우선순위 결정
• 전략적 방향 설정 및 목표 정의
• 이해관계자 조율 및 의사결정

BA 단계에서의 AI 협업

AI의 분석적 역할:

• 요구사항 상세화 및 매트릭스 자동 생성
• 예외 상황 시나리오 도출
• 데이터 모델 및 ERD 자동 생성
• API 스펙 초안 작성

인간의 설계적 역할:

• 비즈니스 규칙 정의 및 검증
• 사용자 경험 관점에서 요구사항 검토
• 기술적 제약사항 반영

구현 단계에서의 AI 지원

AI의 생산적 역할:

• 보일러플레이트 코드 자동 생성
• 테스트 케이스 작성 및 실행
• 코드 리뷰 및 품질 체크
• 성능 최적화 제안

인간의 창조적 역할:

• 아키텍처 설계 및 기술 선택
• 복잡한 비즈니스 로직 구현
• 코드 품질 및 보안 검토

✅ 품질 관리 체크포인트

PRD 완성 기준

• 비즈니스 가치 정량화: ROI, 사용자 임팩트 측정 가능
• 핵심 사용자 스토리: 3-5개 메인 플로우 정의 완료
• AI 일관성 검증: 논리적 모순 및 누락 사항 없음
• 이해관계자 승인: 기획, 개발, 비즈니스 팀 합의

BA 완성 기준

• 요구사항 완전성: 모든 기능의 상세 요구사항 정의
• 예외 처리 커버리지: 예상 가능한 예외 상황 100% 정의
• API 스펙 검증: 프론트엔드-백엔드 계약 완성
• 데이터 모델 검증: ERD 및 비즈니스 규칙 매핑 완료
• AI 품질 검증: 누락사항 탐지 결과 반영

구현 완성 기준

• 기능 구현 완료: BA 요구사항 100% 구현
• 테스트 통과: AI 생성 테스트 케이스 전체 통과
• 코드 품질: 정적 분석 도구 기준 달성
• 성능 기준: 응답 시간, 처리량 목표 달성
• 보안 검증: 취약점 스캔 및 보안 가이드라인 준수

🚀 개발 가속화 전략

1. 동시 진행 파이프라인

병렬 처리를 통한 개발 속도 향상

현재 사이클: [구현 중]
다음 사이클: [BA 작성 중]
다다음 사이클: [PRD 셰이핑 중]

2. AI 기반 자동화

• 문서 자동화: 요구사항 → API 스펙 → 테스트 케이스 자동 변환
• 코드 자동화: 반복적 CRUD 작업 AI 자동 생성
• 품질 자동화: 코드 리뷰, 테스트, 배포 자동화

3. 협업 도구 통합

• 실시간 문서 협업: Notion, Confluence 기반 동시 편집
• AI 챗봇 지원: 프로젝트 관련 질의응답 24/7 지원
• 자동 알림 시스템: 단계별 완료 시점 자동 통보

💡 중소 개발사 맞춤 포인트

리소스 효율성

• 문서 재사용: 템플릿 기반 빠른 문서 작성
• AI 활용 극대화: 반복 작업 최소화로 개발자 창조적 업무 집중
• 병렬 처리: 적은 인원으로도 여러 프로젝트 동시 진행

품질 보장

• 체계적 문서화: 인수인계 및 유지보수 용이성
• 자동화된 품질 관리: 수동 검토 부담 최소화
• 지속적 학습: AI와의 협업을 통한 팀 역량 향상

B2B SaaS 특화

• 고객 피드백 반영: 빠른 사이클로 고객 요구사항 신속 대응
• 확장 가능한 아키텍처: 중장기 성장에 대비한 설계
• 보안 및 컴플라이언스: 기업 고객 요구사항 기본 충족

📊 성공 지표 (KPI)

개발 효율성

• 개발 완료율: 계획 대비 실제 완료 비율 (목표: 95% 이상)
• 버그 발생률: 배포 후 30일 내 버그 신고 건수 (목표: 5건 미만/기능)
• 문서 품질: AI 검증 통과율 (목표: 98% 이상)

팀 만족도

• 협업 만족도: 분기별 팀 만족도 조사 (목표: 4.5/5.0 이상)
• 학습 효과: AI 협업을 통한 개인 역량 향상도
• 업무 효율성: 반복 작업 시간 단축 비율

비즈니스 성과

• 출시 속도: 아이디어 → 배포까지 소요 시간 (목표: 5주 이내)
• 고객 만족도: 배포 기능에 대한 고객 피드백 점수
• 매출 기여도: 신규 기능의 비즈니스 임팩트 측정

...

🎯 마무리: 성공적인 도입을 위한 체크리스트

조직 준비사항

• 팀원 AI 도구 활용 교육 완료
• 문서 템플릿 및 협업 도구 세팅
• 품질 관리 자동화 시스템 구축

프로세스 준비사항

• PRD-BA-구현 단계별 책임자 지정
• AI 협업 가이드라인 수립
• 회고 및 개선 프로세스 정의

기술 준비사항

• AI 개발 도구 (GitHub Copilot, ChatGPT 등) 도입
• CI/CD 파이프라인 자동화
• 모니터링 및 알림 시스템 구축

이 방법론을 통해 문서의 품질은 높이면서도 개발 속도는 빠르게, AI의 도움을 받으면서도 인간의 창조성은 더욱 발휘하는 이상적인 개발 환경을 만들어나갈 수 있습니다

부제 : 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 템플릿

...

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주차: 통합 및 비기능 요구사항 구현

협업 도구와 프로세스

문서 협업 방식

1. PRD: 기획자 주도 + 전체 팀 리뷰
2. BA 문서: 기획자-개발자 페어 분석
3. 구현: 개발자 주도 + 일일 도메인 세션

문서 품질 보장 체계

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 개선사항 반영

성공 요인:

1. 명확한 역할 분담: PRD는 방향성만, BA는 구체적 요구사항만
2. 지속적 협업: 매일 30분 도메인 세션으로 오해 제거
3. 점진적 구현: 완전한 기능 조각부터 시작해 확장
4. 빠른 피드백: 문제 발생 즉시 논의하고 해결

결론: AI 시대에 더욱 중요한 인간의 협업

AI가 코드를 생성하는 시대일수록, **"무엇을 만들지"**와 **"왜 만드는지"**에 대한 인간의 협업이 더욱 중요해집니다. Shape-Driven Development는 이러한 협업을 체계화하여 50인 미만의 B2B SaaS 팀이 빠르고 정확하게 제품을 만들 수 있도록 돕는 방법론입니다.

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