7장 — Phase 분리: 코끼리를 냉장고에 넣는 방법

1탄 7장

Phase 분리: 코끼리를 냉장고에 넣는 방법

Phase가 너무 클 때 쪼개는 메타 원칙과 실제 방법

📑 이 챕터에서 다룰 내용

들어가며 — Phase가 너무 클 때
7-1. Phase 크기 검증 — 두 가지 기준 복기
7-2. 잘못 나눈 Phase vs 올바르게 나눈 Phase — 두 사례 비교
7-3. Phase가 너무 크면 이렇게 쪼갠다
📌 챕터 정리

새 6장에서 PLAN.md v2를 완성하면서 "30일 테스트"와 "10파일 테스트" 두 검증 기준을 봤습니다. 둘 중 하나라도 통과하지 못하면 Phase를 더 쪼개야 합니다. 이 장은 그 "쪼개는 방법"입니다.

분량은 짧습니다. 새 6장에서 이미 검증 기준을 다뤘으므로, 이 장은 "왜 쪼개는가"의 메타 원칙과 "어떻게 쪼개는가"의 실제 방법만 다룹니다.

📚 사전 지식 체크	🎯 이 장의 목적	✅ 완료 후 결과물
새 6장 PLAN.md v2 완성 / 30일·10파일 테스트 인지	파킨슨의 법칙 이해 + Phase가 30일·10파일 기준 초과 시 쪼개는 방법 익힘	Phase 1 범위 최종 확정 + "이것만으로 배포 가능" 확인

📘 이론적 배경 — 파킨슨의 법칙 (시릴 노스코트 파킨슨, 1955)

영국의 행정학자 파킨슨이 발견한 법칙: "일은 주어진 시간을 모두 채우도록 팽창한다."

실험: 같은 보고서를 1주일 주면 1주일이 걸리고, 2주일 주면 2주일이 걸립니다. 이건 게으름이 아니라 인간 심리의 본질입니다.

Phase를 30일로 강제 제한하는 이유가 여기 있습니다. 기간을 제한하지 않으면 기능은 끝없이 늘어나고, 앱은 영원히 완성되지 않습니다. "이 Phase에 이 기능도 넣자"가 반복되는 것을 막는 구조적 방법이 30일 제한입니다.

💡 코끼리를 냉장고에 넣는 방법

① 냉장고 문을 연다 ② 코끼리를 넣는다 ③ 냉장고 문을 닫는다.

농담처럼 들리지만, 이게 Phase 분리의 핵심입니다. 어떤 복잡한 앱도 Phase 1·2·3...으로 쪼개면 각 Phase는 "냉장고 문 열기"만큼 단순해집니다. 처음부터 "전체"를 보면 막막하지만, Phase 1 하나만 보면 할 수 있습니다.

Phase가 클수록 막막함이 커집니다. 막막하면 쪼갭니다. 그것이 전부입니다.

7-1 Phase 크기 검증 — 두 가지 기준 복기 🔗

새 6장에서 다룬 두 기준을 짧게 복기합니다.

기준 1 — 30일 테스트	기준 2 — 10파일 테스트
혼자서 30일 안에 완성할 수 있는가?	변경될 파일이 10개 이하인가?
Yes → 크기 OK	Yes → /clear 안전하게 사용 가능
No → 두 개로 나눈다	No → Phase를 더 쪼개야 합니다

30일은 한 달입니다. 솔로 개발자가 하루 2~4시간을 투자했을 때 완성할 수 있는 현실적인 단위예요. 더 짧으면 너무 작아 의미 있는 기능을 만들기 어렵고, 더 길면 파킨슨의 법칙에 의해 기능이 계속 추가됩니다.

10파일 기준은 /clear 안전성과 관련됩니다. 10개 이상 파일을 변경하는 작업은 Claude Code가 한 번에 파악하기 어렵고, 파악하지 못한 부분에서 실수가 생기고, 그 실수 디버깅에 시간이 더 걸립니다.

📘 표준 도구의 자리

GSD의 "phase별 wave 시스템"도 같은 사상입니다. wave는 병렬 실행 가능한 작업 그룹 — "한 wave 안의 작업이 너무 많으면 의존성이 깨진다"라는 직관이 5파일+의 "10파일 기준"과 같은 원리입니다. 다만 GSD는 자동 (코드 분석 후 wave 자동 분리), 5파일+ 는 수동 (학습 가치)입니다.

7-2 잘못 나눈 Phase vs 올바르게 나눈 Phase — 두 사례 비교 🔗

같은 앱을 Phase로 나눌 때 어떻게 달라지는지 두 사례로 봅니다.

사례 1 — 줍줍

❌ 잘못된 Phase 분리	✅ 올바른 Phase 분리
Phase 1: API 4개 + LLM 분류 + 두 탭 + 기여 시스템 + 잠금 해제 + 통계 + FCM + 공유 카드 + 어드민 + 심사 + 홍보 + 수익화 (구독 결제)	Phase 1: 정보 수집 + 두 탭 + 기여 시스템 + 무료 사용 + 심사 + 홍보
변경 파일 50개 이상	변경 파일 약 25개
완성에 6개월 이상	10주 완성
수익화가 Phase 1에 있어도 무수익 6개월 — 신뢰 축적 못함	Phase 2 (6개월 후)에 수익화 분리 — 신뢰 축적 후

💡 핵심 메타 원칙

"수익화 시도는 커뮤니티 신뢰를 망친다"는 사용자 직관(E2 페이스)이 Phase 분리에 반영됩니다. SPEC §10(수익 모델)의 "Phase 1: 수익 없음, 신뢰와 데이터 축적에만 집중"이 PLAN의 Phase 1·2 분리로 자연스럽게 이어집니다.

사례 2 — TotalSportsView

❌ 잘못된 Phase 분리	✅ 올바른 Phase 분리
Phase 1: 19리그 + 6 페르소나 + COACH·INSIDER 추가 + SEO 깊이 + 운영자 패널 + 프리미엄 구독 + 광고 + B2B 데이터 판매	Phase 1.0 (33일): 5리그 × 2 페르소나 (STAT + OBSERVER) — 다관점 가설 검증
변경 파일 80개 이상	변경 파일 약 30개
12개월 안에 완성 불가	33일 완성
다관점 가설이 검증되지 않은 채 모든 페르소나 출시	Day 14 가설 검증 게이트로 안전하게 진행

이후 Phase 1.1 (5리그 → 9리그 + COACH 추가) → Phase 1.2 (수익화) → Phase 2.0 (19리그 + 다른 스포츠 추가) 같은 점진 확장으로 이어집니다.

📘 핵심: "가설 검증이 본질, 캘린더는 도구"

Phase 1.0의 본질은 "다관점 페르소나가 단관점 대비 클릭률 ≥15%"의 검증입니다. 날짜를 맞추는 것이 목적이 아니라, 가설을 검증하는 것이 목적이에요.

7-3 Phase가 너무 크면 이렇게 쪼갠다 🔗

PLAN.md를 Claude Code에서 다음과 같이 요청합니다.

💻 Claude Code 프롬프트

이 Phase 1이 너무 큰 것 같아. "이것만으로 배포 가능한 최소 버전"
과 "그 다음에 추가할 것"으로 2개로 나눠줘. 변경 파일을 각각 10개
이하로 유지해줘. 수익화는 어느 Phase에 둘지 결정도 같이 해줘.

💡 "너무 쪼개면 가치 없는 앱 아닌가요?"

Phase 1이 너무 빈약하다는 걱정은 당연합니다. 하지만 생각해보세요:

인스타그램 첫 버전: 사진 올리기 + 팔로우, 딱 두 가지
에어비앤비 첫 버전: 사진 올리고 가격 받기, 그게 전부
페이스북 첫 버전: 하버드 학생 프로필 공유만 가능

지금의 거대한 서비스들도 모두 아주 작게 시작했습니다. Phase 1은 "존재하는 것"이 "완벽한 것"보다 중요합니다.

📌 새 7장 정리

1️⃣ 핵심 한 줄: 파킨슨의 법칙 ↔ Phase 30일·10파일 강제 제한. 코끼리도 "냉장고 문 열기" 단계로 쪼개면 단순합니다.
2️⃣ 두 검증 기준: 30일 테스트 (혼자 30일 안에 완성 가능?) + 10파일 테스트 (변경 파일 10개 이하?) — 둘 다 Yes여야 Phase로 인정됩니다.
3️⃣ 줍줍 사례: Phase 1 (10주 무수익) + Phase 2 (6개월 후 수익화) 분리
4️⃣ TSV 사례: Phase 1.0 (33일 5리그 × 2 페르소나) 가설 검증 → Phase 1.1 확장
5️⃣ 표준 도구의 자리: GSD wave 시스템도 같은 사상 (병렬 작업 그룹). 자동 vs 수동 차이.
6️⃣ 메타 원칙: 막막하면 쪼갑니다. Phase 1 = MVP. "존재하는 것" > "완벽한 것"
7️⃣ 수익화 위치: "신뢰 축적" 메타 원칙에 따라 결정합니다 (줍줍 사례 참조)

🎉 Phase 크기가 완벽합니다

이제 BUILD 전 마지막 관문 REVIEW.md로 넘어갑니다. 다음 장에서 REVIEW.md + E3 두 검토자의 사각지대 패턴을 데이터로 확인합니다.