자유 창작 준비: 1탄·2탄·3탄 이후

1탄 v2의 마지막 챕터입니다. 1탄을 시작할 때 "두 분의 독자를 모두 환영"했습니다 — 개발 경험이 있는 분과 비개발자 동업자. 이 자리까지 오신 두 분 모두에게 진심으로 축하드립니다.

1탄을 마쳤습니다. 여기서 중요한 구분 하나.

5파일+ 는 학습 도구입니다. 1탄 전체가 "5파일+로 어떻게 프로젝트를 구조화하는가"를 가르치는 학습 과정. 개념 인지, 사이클 이해, E1~E5 적용 — 이게 목적.

실전 프로젝트는 다릅니다.

새 실전 프로젝트를 시작할 때는 Day 0부터 표준 도구(GSD·BMAD·Spec-Kit 등)로 세팅합니다. 학습용 5파일+로 시작하다가 나중에 표준 도구로 전환하는 것은 이중 작업 — 낭비입니다.

경로 A — 새 실전 프로젝트: Day 0 표준 도구 세팅

새 프로젝트를 시작하는 경우, 처음부터 표준 도구로 세팅합니다.

Day 0 폴더 구조 (TypeScript + GSD 예시):

my-project/
├── .planning/           # GSD 계획 폴더
│   ├── SPEC.md
│   ├── PLAN.md
│   └── REVIEW.md
├── src/
│   ├── index.ts
│   ├── routes/
│   ├── services/
│   └── types/
├── CLAUDE.md
├── package.json
├── tsconfig.json
└── .env.example

표준 패키지 선택 표 (TypeScript 스택):

{
  "compilerOptions": {
    "target": "ES2022",
    "module": "ESNext",
    "moduleResolution": "bundler",
    "strict": true,
    "outDir": "./dist"
  }
}

경로 B — 기존 5파일+ 프로젝트: 점진적 전환

이미 5파일+로 만든 프로젝트(줍줍·TSV처럼)가 있고, 표준 도구로 옮기고 싶다면:

현재 프로젝트 구조를 감사해줘.

[SPEC.md 내용 붙여넣기]
[BUILD.md 최근 3일 붙여넣기]

질문:
1. 파일 구조에서 표준 패키지로 교체할 수 있는 곳 3개
2. 테스트 없이 리팩터 가능한 자체 구현 2개
3. 타입 안전이 부족한 영역 2개

주 1회 파일 분리 3단계:

5파일+ 개념 → 표준 도구 매핑

5파일+ 사이클 — 7단계 흐름

[① SPEC v1] → [② 외부 검토] → [③ SPEC v2]
       → [④ 사용자 직관] → [⑤ SPEC v3 → 두 검토자 → SPEC v4]
       → [⑥ PLAN v1 → v2] → [⑦ REVIEW + READY → BUILD]

이 7단계가 모든 새 프로젝트에 적용 가능한 사이클입니다. 도메인 (B2C 앱·미디어·교육·B2B SaaS)이 달라도 7단계는 같습니다.

5파일

프로젝트폴더/
├── SPEC.md          무엇 만들 것인가 + ⚖️ E1 회색지대
├── PLAN.md          어떤 순서로 + 게이트 + 리스크 + ★ E2 페이스
├── REVIEW.md        진입 준비 됐는가 + ⭐ E3 두 검토자 + 3단계 판정
├── BUILD.md         매일 무엇 했는가 + ⭐ E4 결정
└── CLAUDE.md        AI 컨텍스트 200줄 + ⭐ E5 콘텐츠 SSOT

5확장 (E1~E5)

표준 도구 9개가 모두 다루지 못하는 영역입니다. 운영자 자체 의식입니다.

9개 표준 도구의 풍경

Claude Code 슬래시 명령

매일 쓰는 4개 (/effort · /model · /clear · /compact) + 자주 쓰는 4개 (/context · /memory · /plan · /security-review) + 커스텀 7개 + 헤드리스 모드. TDD는 별도 슬래시 명령이 아니라 자연어 지시로 진행합니다.

이 다섯 가지가 1탄 졸업 시점에 손에 들리는 자산입니다.

1탄을 마친 후 새 프로젝트를 시작하실 때 이 5단계를 따르시면 됩니다.

새 폴더 + 5파일 빈 껍데기 + git init (30분)
  ↓
SPEC v1 (Opus + high) (1.5~2h)
  ↓
Gemini 1차 검토 (30m)
  ↓
SPEC v2 + ⚖️ E1 회색지대 결정 (3h, 해당 시)
  ↓
사용자 직관 (1h)
  ↓
SPEC v3 → 두 검토자 (Claude 시뮬 + Gemini) → SPEC v4 (1.5h)
  ↓
PLAN v1 → +α 시간 갭 흡수 → PLAN v2 (3h)
  ↓
REVIEW 15가지 체크 → 75분 패치 → READY: YES (2h)
  ↓
CLAUDE.md 10 섹션 + ⭐ E5 SSOT (해당 시) (1h)

새 프로젝트 또는 Phase 2~3에서 "5파일+를 계속 쓸 것인가, 표준 도구로 옮길 것인가"의 결정 트리입니다.

시작
  ↓
[질문 1] 프로젝트 규모가 1인 수동 관리 한계를 넘어섰는가?
  - 기능 수 50개+ 또는 페르소나/리그 19개+
  - YES → 질문 2로
  - NO → 5파일+ 계속 사용

[질문 2] 팀 규모가 5명+ 인가?
  - 페르소나 협업 + 역할 분리 필요
  - YES → BMAD-METHOD 추천
  - NO → 질문 3으로

[질문 3] 기존 코드 (brownfield) 인가, 새 프로젝트 (greenfield) 인가?
  - brownfield + 변경 명세 중심 → OpenSpec 추천
  - greenfield → 질문 4로

[질문 4] 자동화 깊이 vs 헌법 일관성 중 어느 것이 더 가치 있는가?
  - 자동화 깊이 → GSD 추천 (TÂCHES)
  - 헌법 일관성 → Spec-Kit 추천 (GitHub)

[질문 5 — 보조] 작업 분해가 가장 큰 통증인가?
  - YES → Taskmaster 추가 (다른 도구와 결합)
  - NO → 단일 도구로 충분

[질문 6 — 보조] 마이크로서비스 환경 + living spec 필요?
  - YES → Intent 추가 (상용)
  - NO → 단일 도구로 충분

의사결정 트리 시각 정리

표준 도구로 옮긴 후에도 5확장 5개는 자체 보강 영역으로 남습니다.

E1 회색지대 — 새 프로젝트 적용

4단계 결정 프레임을 그대로 적용합니다.

• ① 영역 식별: "내 도메인에 어떤 회색지대가 있는가" (법적·윤리적·시장적)
• ② 포함 / 배제: 명시적 5개 + 명시적 5개
• ③ 표현 정제: 외부 노출 텍스트 (About·약관·콘텐츠 정책)
• ④ SPEC 명시: SPEC.md "§ 회색지대 결정" 섹션

E2 1인 페이스 — 새 프로젝트 적용

3가지 형태를 그대로 적용합니다: (a) 시간 갭 정직 계산 / (b) 게이트 + 휴식 의식 / (c) R4 1인 번아웃 리스크 등록.

E3 두 검토자 — 새 프로젝트 적용

Claude + Gemini 조합: SPEC v1 → Gemini 1차 → SPEC v2 → 사용자 직관 → SPEC v3 → Claude 시뮬 + Gemini 2차 → SPEC v4.

E4 결정 — 새 프로젝트 적용

BUILD.md 일자별 양식 그대로 적용합니다. 트레이스 4 요소: 결정 + 근거 + 대안 비교 + 부작용.

E5 콘텐츠 SSOT — 새 프로젝트 적용

삼중 안전장치 그대로: ① SSOT 인터페이스 (단일 출처) ② 시스템 프롬프트 환각 방지 ③ 자동 일관성 테스트.

권7 5장 구조 (예정)

두 가지 사실

두 가지 질문을 가지고 가세요

다음 권으로

다음 권은 2탄 — 줍줍 10주 출시 매뉴얼. 5파일+ 사이클이 실제 출시 프로젝트에서 어떻게 작동하는지 실전 사례입니다. 그 다음 3탄 — TotalSportsView 12개월 운영 매뉴얼. 1년 장기 프로젝트의 5파일+ 진화입니다.

두 권 모두 "이론"이 아니라 "매일 펼치는 운영 자료"입니다. 이 1탄을 손에 들고 두 매뉴얼로 넘어가십시오.