2탄 — 줍줍 10주 출시 매뉴얼 · 권1 제0·1장
Phase 0 시작 + SPEC v1
빈 폴더부터 5파일까지 · 7항목 + 회색지대 인식
📑 이 챕터에서 다룰 내용
1탄을 마치신 두 분께 다시 한 번 인사드립니다. 5파일+ 사이클 + 5확장 + 9개 표준 도구의 풍경이 손에 들리신 자리.
📘 2탄은 매뉴얼입니다
2탄은 "읽고 끝나는 책"이 아닙니다. 매일 펼치는 운영 매뉴얼. 줍줍이라는 실제 앱을 10주 안에 출시하는 과정의 실시간 트레이스이고, 두 분이 함께 5파일+ 사이클을 손으로 적용하는 자리입니다.
💡 1탄·2탄·3탄의 관계 복기
- 1탄: 5파일+ 사이클의 정체성과 형식 (방법론)
- 2탄: 줍줍 10주 출시 (B2C 앱 사례)
- 3탄: TotalSportsView 12개월 운영 (미디어 플랫폼 사례)
- 권7: 표준 + 확장 컴패니언 (자유 창작 단계)
줍줍을 소개합니다
"정부지원금, 아는 사람만 줍는 거 이제 같이 줍자."
이 한 줄이 줍줍의 본질입니다. 정부 지원금은 매년 수십조 원 규모로 풀리지만, "신청 과정의 고통"은 공식 사이트 어디에도 공유되지 않습니다. 서류 탈락 이유, 소요 시간, 담당자 팁 — 이 "집단 지성"이 줍줍의 차별 가치입니다.
줍줍의 두 탭 구조
💻 줍줍 앱 구조
줍줍 ├── 🏪 소상공인 탭 ← 첫 진입. 업종/사업단계별 지원금 + 후기 └── 👤 개인 복지 탭 ← 연령/소득분위별 복지 혜택 + 후기
두 탭을 하나의 앱에 통합하되, 첫 진입은 "소상공인 탭 고정". 이유: "사장님을 위한 전문 앱" 정체성 우선.
10주 일정의 본질
| 주차 | 핵심 |
|---|---|
| 1~2주차 (Phase 0) | SPEC v4 + PLAN v2.1 + REVIEW READY + CLAUDE.md |
| 3~4주차 (Phase 1.0 BUILD) | DB 4 테이블 + 카카오 로그인 + LLM 분류 파이프라인 + pg_cron |
| 5~6주차 | 두 탭 UI + 단계적 기여 시스템 (사용자 1명 줍줍 가능) |
| 7~8주차 | 통계 시각화 + FCM 알림 + 공유 카드 |
| 9~10주차 | 약관/개인정보 + 어드민 + QA + 앱스토어 심사 + 1순위 커뮤니티 |
10주 끝 시점의 목표 — 앱스토어 심사 통과 + 첫 100 사용자 + 1순위 커뮤니티 게시.
2탄의 권1·2·3 구조
| 권 | 분량 | 다루는 영역 |
|---|---|---|
| 권1 — Phase 0 (1~2주차) | 약 80KB | 5파일+ 사이클 7단계 (SPEC v1 → 외부 검토 → 사용자 직관 → 두 검토자 → SPEC v4 → PLAN v2.1 → REVIEW READY → CLAUDE.md) |
| 권2 — Phase 1.0 BUILD (3~6주차) | 약 80KB | Day 1~28 — DB·API·LLM 분류·두 탭 UI·기여 시스템 |
| 권3 — Phase 1.1 + 출시 (7~10주차) | 약 70KB | Day 29~70 — 통계·알림·QA·앱스토어 심사·1순위 커뮤니티 + Phase 2 예고 |
권1 제0장에서는 1탄 v2 새 2장(프로젝트 시작 30분)의 절차를 줍줍에 적용합니다. 그러나 그 절차에 들어가기 전에, 먼저 줍줍이라는 이름이 어떻게 결정됐는가의 첫 LogOnTable 트레이스를 봅니다.
📘 첫 결정 트레이스
[Phase 0 Day -1, 프로젝트 시작 전 결정]
Junho: 정부 지원금 정보 + 후기 공유 앱을 만들 거야. 이름 후보:
(1) "정부지원" — 직설적·검색 친화
(2) "혜택톡" — 친근·소셜
(3) "줍줍" — 가벼움·집단 경험·바이럴
어느 것이 좋을까?
Claude: 세 후보의 트레이드오프:
(1) "정부지원": SEO 강함. 그러나 "공식 절차" 인식 = 후기 공유
커뮤니티 톤과 거리. 시민 톤과 사장님 톤 통합 어려움.
(2) "혜택톡": 친근하지만 "톡" 접미가 카카오톡 의존 인식.
B2C 앱 정체성 약함. 차별 부족.
(3) "줍줍": "공짜로 줍는다" 가벼움 = 후기 공유 톤과 일치.
소상공인·개인 두 탭 모두 적용 가능.
단, 정부 공식 절차와 거리 = E1 회색지대 발생.
이 회색지대는 SPEC §회색지대 결정에 명시적으로 박아야 함.
권장: (3) "줍줍". 회색지대 위험은 E1 결정으로 안전 항해 가능.
Junho: "줍줍" 채택. E1 회색지대는 SPEC v1 작성 시 §회색지대
결정 섹션에 명시.
4 요소 트레이스 형식
| 요소 | 내용 |
|---|---|
| 결정 | 프로젝트명 "줍줍" 채택 |
| 근거 | 차별성 + 바이럴 가치, 두 탭 통합 가능 |
| 대안 비교 | "정부지원" (SEO 강함, 톤 거리) / "혜택톡" (차별 부족) |
| 부작용 | E1 회색지대 발생 → SPEC §회색지대 결정에 박아야 함 |
이 트레이스가 BUILD.md의 첫 entry 후보. 6개월 후 동업자가 "왜 줍줍이라는 이름인가?" 펼치면 이 4 요소가 답입니다.
💻 프로젝트 초기화 (터미널)
# ① 프로젝트 폴더 생성 mkdir jupjup && cd jupjup # ② git 초기화 git init # .gitignore (Expo + Supabase 환경) cat > .gitignore << 'EOF' node_modules/ .env .env.local .env*.local .expo/ .expo-shared/ dist/ ios/build/ android/build/ android/app/build/ *.log .DS_Store EOF # ③ 5파일 생성 (빈 파일) touch SPEC.md PLAN.md REVIEW.md BUILD.md CLAUDE.md # 생성 확인 ls *.md # BUILD.md CLAUDE.md PLAN.md REVIEW.md SPEC.md # ④ CLAUDE.md 최소 내용 (10 섹션 중 3개만) cat > CLAUDE.md << 'EOF' # 줍줍 (Jupjup) # 상태: Phase 0 시작 — SPEC.md 작성 전 ## 3. Critical Constraints (어떤 상황에서도 지킨다) - 요청하지 않은 파일을 임의로 수정하지 않는다 - API 키를 코드에 직접 넣지 않는다 - 작업 전 변경할 파일 목록을 먼저 말한다 ## 10. Current State - ✅ 프로젝트 초기화 + 5파일 빈 껍데기 (Phase 0 Day -1) - ✅ 프로젝트명 "줍줍" 결정 (LogOnTable 트레이스 보존) - 🚧 다음: SPEC v1 작성 (권1 제1장) EOF # ⑤ BUILD.md 첫 entry — 이름 결정 트레이스 # (터미널에서 작성 후) # ⑥ 첫 commit git add . git commit -m "Phase 0 Day -1: 프로젝트 초기화 + 줍줍 이름 결정 + 5파일 빈 껍데기" # ⑦ Claude Code 실행 claude /powerup
30분 안에 완료된 것
| 산출물 | 상태 |
|---|---|
jupjup/ 폴더 | ✅ |
.gitignore | ✅ Expo + Supabase 환경 맞춤 |
SPEC.md (빈) | ✅ 권1 제1장에서 v1 작성 |
PLAN.md (빈) | ✅ 권1 제6장에서 v1 작성 |
REVIEW.md (빈) | ✅ 권1 제7장에서 작성 |
BUILD.md (Day -1 entry) | ✅ 첫 LogOnTable 트레이스 박힘 |
CLAUDE.md (3 섹션 최소) | ✅ 권1 제7장에서 10 섹션 완성 |
git init + first commit | ✅ |
| Claude Code 실행 + /powerup | ✅ |
🎉 핵심 포인트
E4 LogOnTable이 프로젝트 시작 첫 30분에 이미 등장했습니다. BUILD.md = 일자별 양식 + LogOnTable 트레이스가 이름 결정에서 시작됐습니다.
📌 권1 제0장 정리
- 핵심 한 줄: 줍줍 Phase 0 시작 — 빈 폴더 + 5파일 + git init + 첫 LogOnTable 트레이스 (이름 결정).
- 결정: "줍줍" 채택 / 근거: 차별성 + 바이럴 + 두 탭 통합 / 부작용: E1 회색지대
- 5파일 상태: SPEC.md (빈), PLAN.md (빈), REVIEW.md (빈), BUILD.md (Day -1 entry), CLAUDE.md (3 섹션 최소)
- 다음 장: 권1 제1장 — SPEC v1 작성
권1 제0장에서 빈 5파일과 git이 준비됐고, 이름 결정 LogOnTable이 박혔습니다. 이제 5파일+ 사이클의 단계 ① SPEC v1 작성입니다.
💻 Phase 0 Day 1 시작
# Phase 0 Day 1 시작 claude /model claude-opus-4-6 # SPEC.md 작성은 Opus /effort high # 고품질 출력
💡 비개발자 동업자께
Opus는 가장 강력한 모델로, 복잡한 비즈니스 로직과 장기 일관성에 강합니다. SPEC.md는 "앱의 헌법"이라 한 번 잘못 쓰면 PLAN·REVIEW·BUILD 모두 영향을 받습니다. Opus 비용은 높지만 SPEC 단계만큼은 정당한 선택이에요.
줍줍의 도메인 분류
| 시나리오 | 줍줍 적용 정도 |
|---|---|
| B2C 앱 | ✅ 개인 복지 탭 |
| B2B SaaS | △ 소상공인 탭 (B2B 인접) |
| 마켓플레이스 | ❌ |
| 교육 앱 | ❌ |
| 콘텐츠 앱 | △ 후기 공유 부분 |
결론: B2C + 콘텐츠 혼합형. 두 탭 모두 콘텐츠 (지원금 정보 + 후기) + 두 탭 모두 사용자 직접 사용. 이 분류가 수익화 모델 선택과 성공 기준 단위에 직결됩니다.
💻 작성 요청 프롬프트
[Claude Code, /model claude-opus-4-6 + /effort high] SPEC.md를 작성해줘. 줍줍은 정부 지원금 정보 + 후기 공유 앱이야. 아래 정보를 기반으로 7항목을 모두 채워줘: 앱 이름: 줍줍 (Jupjup) 한 줄 정의: "정부지원금, 아는 사람만 줍는 거 이제 같이 줍자" 사용자 A: 자영업자/소상공인 (식당·카페·소규모 도소매·서비스업) - 30~60대, 운영 1~10년차 - "복잡한 절차로 시간 낭비"가 첫 번째 고통 사용자 B: 일반 시민 (개인 복지 수혜 후보자) - 청년·취준생·1인 가구·장애인·노인 - "정부에서 뭐 주는지 모름"이 첫 번째 고통 Phase 1 핵심 기능 3가지: 1. 두 탭 (소상공인 / 개인 복지) 2. 후기 공유 시스템 (단계적 기여) 3. 알림 (마감 D-7 + 신규 매칭) + 통계 시각화 성공 기준: 앱스토어 심사 통과 + 100 사용자 + 후기 작성 8명+ 기술 스택: - 프론트: Expo 52 + TypeScript + NativeWind + Zustand + TanStack Query - 백엔드: Supabase (PostgreSQL + Auth + Edge Functions + Storage + pg_cron) - LLM: Claude Haiku 4.5 (분류) + Sonnet 4.6 (운영) - 인증: 카카오 로그인, 알림: FCM, 배포: EAS Build
Claude (Opus + high)가 생성한 SPEC.md v1 — 발췌
📘 SPEC.md v1 핵심 내용 발췌
# SPEC.md — 줍줍 (Jupjup) v1
## 1. 한 줄 정의
정부 지원금 정보를 정리하고, 사용자 후기를 공유하는 B2C 앱.
소상공인 탭 + 개인 복지 탭 두 영역을 통합.
## 4. Phase 1 핵심 기능 (10주)
[1] 두 탭 (소상공인 / 개인 복지)
- 카테고리·필터별 지원금 목록 (검색·정렬 포함)
- 첫 진입은 소상공인 탭 고정
[2] 후기 공유 시스템 — 단계적 기여
- 부담 0: "내가 신청해본 것" 체크박스 (5초)
- 부담 낮음: "결과는?" SUCCESS / FAILED / IN_PROGRESS 선택
- 선택: "어떤 점이 어려웠나" 자유 후기 (200자)
- 익명 닉네임 자동 부여 (실명 비공개)
[3] 알림 + 통계 시각화
- FCM 마감 D-7 + 신규 매칭 즉시
- 통계: 성공률 / 평균 소요 일수 / 카테고리 트렌드
## 5. 성공 기준 (Phase 1 종료 시 — 10주차)
| 지표 | 기준 |
|----------------|------------|
| 앱스토어 심사 | iOS + Android 모두 |
| 사용자 가입 | 100명+ |
| 후기 작성 사용자| 8명+ |
| 1순위 커뮤니티 | 반응 50건+ |
## DB 스키마 초안 (4 테이블)
[users], [benefits], [jupjups]
- ⚠️ UNIQUE (user_id, benefit_id) — 통계 조작 차단
[reports]
## 8. 회색지대 인식 (권1 제3장에서 본격 결정 — E1)
[1] "줍줍" 표현의 정직한 위치
[2] 개인정보 처리 위치 (PIPA 준수)
💡 v1의 "의도적 불완전"의 본질
v1은 일부러 완성도가 낮습니다. 이유:
- LLM 분류 confidence 임계값 — 미명시 (Gemini가 잡을 것)
- UNIQUE 제약은 있지만 IP 추적 — 미명시
- 운영자 검수 큐 — 미명시
- JSON 외 출력 fallback — 미명시
- 행정구역 코드 변경 처리 — 미명시
- source_url null 처리 — 미명시
이 누락들이 권1 제2장(Gemini 1차 검토)에서 보완됩니다. v1을 완벽하게 만들려 하면 영원히 끝나지 않습니다.
💻 SPEC v1 저장 + git commit
git add SPEC.md git commit -m "SPEC.md v1: 7항목 + DB 스키마 초안 + 회색지대 인식"
📘 7+1 체크리스트 (1탄 v2 새 5장 5-6 절)
□ 앱 이름이 있다 — "줍줍 (Jupjup)" ✅ □ 해결하는 문제가 한 문장으로 있다 ✅ □ 사용자 A·B가 구분돼 있다 — 자영업자 + 일반 시민 ✅ □ Phase 1 기능이 3가지 이하다 — 두 탭·후기·알림+통계 ✅ □ 성공 기준이 숫자로 있다 — 100명·8명+·200건·50건+ ✅ □ 수익화 방법이 Phase 1에 포함돼 있다 — 의도적 무수익 명시 ✅ □ DB 스키마 초안이 있다 — 4 테이블 + UNIQUE ✅ □ ⭐ § 회색지대 결정 섹션이 있다 — 인식만 ✅ (권1 제3장에서 본격)
8개 모두 ✅. SPEC v1 완성.
📌 권1 제0·1장 정리
- 1️⃣ Phase 0 시작: 빈 폴더 + 5파일 + git init + 첫 LogOnTable 트레이스 (이름 결정)
- 2️⃣ 이름 결정: "줍줍" — 차별성 + 바이럴 + 두 탭 통합 가능. E1 회색지대 발생 → SPEC §회색지대에 명시 예정
- 3️⃣ SPEC v1: Opus + high + 7항목 + DB 스키마 + 회색지대 인식. 의도적 불완전 (6개 누락 인지)
- 4️⃣ 5파일+ 사이클 단계: 단계 ① SPEC v1 ✅ / 다음: 단계 ② Gemini 외부 검토 (권1 제2장)
- 5️⃣ 5확장 등장: E4 LogOnTable (BUILD.md Day -1·Day 1 트레이스) / E1 회색지대 (인식만) / E2 (누적 시간 3.5h 추적 시작)
🎉 권1 제1장을 마치며
SPEC v1이 완성됐습니다. 약 8~10KB의 "의도적으로 불완전한 헌법". 이게 다음 챕터에서 Gemini에게 보여 "빠진 것을 찾아달라" 부탁할 자료입니다.
E4 LogOnTable이 BUILD.md에 두 번 (Day -1 이름 결정 + Day 1 SPEC v1) 박혔습니다.