기획 문서 원문
WBS.md
※ 이 설계 문서는 사후에 정리한 산출물이 아니라, Claude Code와 대화하며 프로젝트 설계를 진행한 원문 그대로입니다.
⚠️ [2026-07-10] 이 문서는 더 이상 갱신되지 않습니다. 1차 개발 완료 처리에 따라 이 파일은
docs/1차/WBS.md로 정리·이관되었습니다(2차 이관 표시 포함). 2차 개발 관련 내용은docs/2차/인수인계.md참고. 아래는 원본 그대로 보존된 내용입니다.기준 문서:
가계부_아키텍처_설계.md,기능명세서_IA.md
작업 코드 체계:S-= 시스템 구현(인프라/DB/배포 등, 사용자 화면 없음),F-= 앱 기능(화면/사용자 동작) —기능명세서_IA.md의 F-코드와 동일
개발 방식: PM 1인, Claude(Pro 플랜)와 바이브 코딩 — Claude Code 터미널 + claude.ai 채팅 병행
0. 일정 추정 전제 (Claude Pro 사용량 기준)
Anthropic은 2026년 5월부터 Pro/Max 플랜의 사용량을 고정 메시지/토큰 수치로 공개하지 않고, "5시간 롤링 윈도우 + 주간 캡, 토큰 기반 측정"으로만 안내합니다. 또한 claude.ai 채팅과 Claude Code 사용량은 같은 풀(pool)을 공유합니다. 따라서 이 WBS는 정확한 토큰 수 대신 다음 가정으로 일정을 추정합니다.
| 가정 항목 | 내용 |
|---|---|
| 작업 단위 | 1세션 = Claude Pro의 5시간 롤링 윈도우 1회 |
| 1세션당 처리량(경험적 추정) | 소규모 TASK 1~2개 (예: 테이블 마이그레이션 1개 + RLS 정책, 또는 CRUD 화면 1개 + 기본 테스트) — TASK를 잘게 쪼갠 이유가 여기에 있음 (세션 안에 끝낼 수 있는 크기로 분해) |
| 1일 가용 세션 | Pro 플랜은 보통 1일 1~2세션 정도가 안정적 (그 이상은 주간 캡에 걸릴 가능성, 실제론 작업 복잡도/모델 선택에 따라 유동적) |
| 권장 운영 | /usage 명령으로 잔여량 수시 확인 → 세션 캡에 자주 걸리면 Max 5x로 업그레이드 고려 (난이도 높은 TASK는 Opus, 단순 반복 작업은 Sonnet/Haiku로 모델을 나눠 쓰면 같은 풀 안에서 처리량 향상 가능) |
| TASK 크기 기준 | 모든 TASK는 "한 세션 안에 끝낼 수 있는 단위"(약 0.5~1세션)로 분해. 그보다 크면 하위 TASK로 추가 분할 |
⚠️ 위 "1세션당 처리량"은 공개된 고정 수치가 아니라 소규모 개인 프로젝트 바이브 코딩 기준의 경험적 추정치입니다. 실제 진행하면서 본인의
/usage소진 속도를 1주일 정도 관찰한 뒤, 아래 일정의 세션 수를 보정하는 것을 권장합니다.
일정 환산: 예상 세션 수 ÷ 1일 가용 세션(1~1.5) = 예상 소요일 (주말 제외, 매일 작업 가정)
1. Phase 구성 (아키텍처 7장 로드맵과 매칭)
| Phase | 아키텍처 로드맵 단계 | 범위 |
|---|---|---|
| Phase 0 | (사전) | 프로젝트/저장소/Supabase 초기 셋업 |
| Phase 1 | 1단계 | 메인앱 Core + 인증 + 수동 입력 가계부 + 기본 대시보드 |
| Phase 2 | 2단계 | 서브앱 1개(관리비) Webhook 연동 |
| Phase 3 | 3단계 | 통계 분리/캐시/대시보드 고도화 |
| Phase 4 | 4단계 | 서브앱 확장(구독/카드), 계정연결 정식화 |
| Phase 5 | (사전 출시) | 통합 테스트 / QA / 출시 |
2. Phase 0 — 사전 셋업 (시스템, 아키텍처 2장/8장)
| TASK ID | 구분 | 작업명 | 설계서 참조 | 선행작업 | 세션(추정) |
|---|---|---|---|---|---|
| S-0-1 | 시스템 | GitHub 저장소 생성 + 브랜치 전략 설정(main/develop) | 8-2 | - | 0.3 |
| S-0-2 | 시스템 | pnpm workspace + Turborepo 모노레포 스캐폴딩 | 2 | S-0-1 | 0.5 |
| S-0-3 | 시스템 | apps/main/web Next.js(App Router) 프로젝트 생성 |
2, 6 | S-0-2 | 0.3 |
| S-0-4 | 시스템 | Tailwind + shadcn/ui 셋업 | 8-1 | S-0-3 | 0.3 |
| S-0-5 | 시스템 | packages/ui, packages/types, packages/utils, packages/config 패키지 골격 생성 |
2 | S-0-2 | 0.5 |
| S-0-6 | 시스템 | Supabase 프로젝트 생성 (Cloud) | 8-1 | - | 0.2 |
| S-0-7 | 시스템 | Supabase CLI 로컬 설치 + supabase init + supabase/ 폴더 구성 |
2, 8-1 | S-0-6, S-0-25 | 0.3 |
| S-0-8 | 시스템 | Supabase ↔ GitHub 연동(Working directory 지정, Preview Branch 옵션 활성화) | 8-2 | S-0-1, S-0-7 | 0.3 |
| S-0-9 | 시스템 | packages/supabase-client 패키지 작성 (브라우저/서버 클라이언트 초기화) |
2 | S-0-5, S-0-6 | 0.4 |
| S-0-10 | 시스템 | GitHub Actions ci.yml (lint/typecheck/test/build) 작성 |
8-3 | S-0-2 | 0.5 |
| S-0-11 | 시스템 | GitHub Actions deploy-migrations.yml 작성 (main push → supabase db push) |
8-3 | S-0-7, S-0-8 | 0.4 |
| S-0-12 | 시스템 | 프론트 배포 방식 결정 및 연동 (Vercel GitHub 연동 또는 8-3-1의 B~D 중 선택) | 8-3-1 | S-0-3 | 0.5 |
| S-0-13 | 시스템 | 시크릿 등록 (SUPABASE_ACCESS_TOKEN, SUPABASE_SERVICE_ROLE_KEY 등 GitHub Secrets) |
8-3 | S-0-8 | 0.2 |
| S-0-14 | 시스템 | ESLint + Prettier 공유 설정 (packages/config) 작성 및 각 앱에 연결 |
2, 8-1 | S-0-5 | 0.4 |
| S-0-15 | 시스템 | Husky + lint-staged 설정 (pre-commit: lint/format, pre-push: typecheck) | 8-3 | S-0-14 | 0.3 |
| S-0-16 | 시스템 | .gitignore + 환경변수 관리 체계 (.env.example, local/CI/production 분리 규칙 문서화) |
8-1 | S-0-3, S-0-6 | 0.3 |
| S-0-17 | 시스템 | README.md 작성 (프로젝트 개요, 로컬 실행법, 디렉토리 설명) |
- | S-0-2 | 0.3 |
| S-0-18 | 시스템 | 루트 tsconfig.json + path alias 설정, 각 패키지 tsconfig 상속 구조 |
2 | S-0-5 | 0.4 |
| S-0-19 | 시스템 | Node/pnpm 버전 고정 (.nvmrc, package.json의 packageManager/engines) |
2 | S-0-2 | 0.1 |
| S-0-20 | 시스템 | turbo.json 파이프라인 정의 (build/lint/test/dev 태스크 의존관계+캐싱) |
2 | S-0-2, S-0-14 | 0.4 |
| S-0-21 | 시스템 | 테스트 프레임워크 설치/설정 — 단위테스트(Vitest) + E2E(Playwright) 골격, pnpm test/pnpm test:e2e 스크립트 |
8-1 | S-0-3, S-0-5 | 0.7 |
| S-0-22 | 시스템 | commitlint 설정 (Husky commit-msg 훅과 연계, [TASK-ID] ... 형식 강제) |
8-3 | S-0-15 | 0.3 |
| S-0-23 | 시스템 | GitHub 브랜치 보호 규칙 (main: PR 필수 + CI status check 통과 필수, 직접 push 금지) | 8-2 | S-0-1, S-0-10 | 0.2 |
| S-0-24 | 시스템 | VS Code 워크스페이스 권장 설정 (.vscode/settings.json, extensions.json) — 선택 |
- | S-0-3 | 0.2 |
| S-0-25 | 시스템 | Docker 설치/실행 확인 (Supabase CLI 로컬 개발에 필수 — supabase start가 Docker 의존) |
8-1 | - | 0.1 |
Phase 0 소계: 약 8.1세션
3. Phase 1 — 메인앱 Core (1단계)
3-1. 시스템: 데이터베이스 구현 (아키텍처 4장 ERD)
| TASK ID | 구분 | 작업명 | 설계서 참조 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| S-1-1 | 시스템 | CATEGORY 테이블 마이그레이션 + 시스템 기본 카테고리 시드 데이터(seed.sql, 데이터정책_및_시드정의서 1-1 참조) |
4 | S-0-7 | 0.5 |
| S-1-2 | 시스템 | PAYMENT_METHOD 테이블 마이그레이션 + 현금(고정) 시드 (데이터정책_및_시드정의서 1-2 참조) |
4 | S-0-7 | 0.4 |
| S-1-3 | 시스템 | VENDOR 테이블 마이그레이션 |
4 | S-0-7 | 0.3 |
| S-1-4 | 시스템 | ITEM 테이블 마이그레이션 (aliases, merged_into_item_id 포함) |
4 | S-0-7 | 0.4 |
| S-1-5 | 시스템 | UNIT 테이블 마이그레이션 + 시스템 기본 단위 시드 (데이터정책_및_시드정의서 1-3 참조) |
4 | S-0-7 | 0.3 |
| S-1-6 | 시스템 | TRANSACTION 테이블 마이그레이션 |
4 | S-1-1~S-1-5 | 0.5 |
| S-1-7 | 시스템 | TRANSACTION_DETAIL 테이블 마이그레이션 |
4 | S-1-6, S-1-4, S-1-5 | 0.4 |
| S-1-8 | 시스템 | BUDGET 테이블 마이그레이션 |
4 | S-1-1 | 0.3 |
| S-1-9 | 시스템 | 전체 테이블 RLS 정책 작성 (데이터정책_및_시드정의서 3장 표 그대로 구현) |
3, 4 | S-1-1~S-1-8 | 0.8 |
| S-1-10 | 시스템 | Postgres 함수/트리거: TRANSACTION.amount 자동계산(상세 합계) |
1-1③ | S-1-7 | 0.6 |
| S-1-11 | 시스템 | supabase gen types typescript 연동 + packages/types/database.generated.ts 생성 확인 |
8-3 | S-1-1~S-1-8 | 0.3 |
소계: 약 4.8세션
3-2. 시스템: 인증 (아키텍처 3장)
| TASK ID | 구분 | 작업명 | 참조 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| S-1-12 | 시스템 | Supabase Auth 이메일 로그인 활성화 + 설정 | 3 | S-0-6 | 0.3 |
| S-1-13 | 시스템 | 소셜 로그인(OAuth Provider) 설정 (선택) | 3 | S-1-12 | 0.4 |
| S-1-14 | 시스템 | 인증 미들웨어(Next.js middleware, 세션 검증) 구현 | 3 | S-0-9, S-1-12 | 0.5 |
3-3. 앱 기능: 인증 화면 (F-3)
| TASK ID | 구분 | 작업명 | F-코드 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| F-1-3-1 | 앱기능 | 회원가입 화면/폼 | F-3-1 | S-1-12 | 0.5 |
| F-1-3-2 | 앱기능 | 로그인 화면/폼 | F-3-2 | S-1-12 | 0.4 |
| F-1-3-3 | 앱기능 | 로그아웃/세션 만료 처리 | F-3-3 | S-1-14 | 0.3 |
| F-1-3-4 | 앱기능 | 계정 설정 화면 | F-3-4 | F-1-3-2 | 0.4 |
| T-1-3-1 | 테스트 | 인증 단위/통합 테스트 (가입→로그인→로그아웃) | F-3-x | F-1-3-1~3 | 0.5 |
소계: 약 3.3세션
3-4. 앱 기능: 마스터 데이터 관리 (F-1-1-1~3, 1-1-13 일부)
| TASK ID | 구분 | 작업명 | F-코드 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| F-1-4-1 | 앱기능 | 지출분류 관리 화면 (현금 표시 + 카드 등록/수정/삭제) | F-1-1-1 | S-1-2, S-1-9 | 0.7 |
| F-1-4-2 | 앱기능 | 지출항목 관리 화면 (CRUD, 단일 항목) | F-1-1-2 | S-1-1, S-1-9 | 0.7 |
| F-1-4-3 | 앱기능 | 지출처 관리 화면 (CRUD) | F-1-1-3 | S-1-3, S-1-9 | 0.5 |
| T-1-4-1 | 테스트 | 마스터 데이터 CRUD 단위 테스트 | F-1-1-1~3 | F-1-4-1~3 | 0.5 |
소계: 약 2.4세션
3-5. 앱 기능: 지출 입력 (F-1-1-4~10) — 가장 복잡한 영역, 세분화 필수
| TASK ID | 구분 | 작업명 | F-코드 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| F-1-5-1 | 앱기능 | 지출 입력 폼 기본 골격 (지출분류/지출항목/지출처 선택 UI) | F-1-1-4 | F-1-4-1~3 | 0.6 |
| F-1-5-2 | 앱기능 | 지출처 자동완성(검색) 컴포넌트 | F-1-1-3 | F-1-5-1 | 0.4 |
| F-1-5-3 | 앱기능 | 금액 직접입력 모드(상세 미사용) 저장 로직 | F-1-1-4 | F-1-5-1 | 0.4 |
| F-1-5-4 | 앱기능 | 상세항목 추가 UI(동적 행 추가/삭제) | F-1-1-5 | F-1-5-1 | 0.6 |
| F-1-5-5 | 앱기능 | 상세항목 자동완성(Item 검색) 컴포넌트 | F-1-1-6 | F-1-5-4, S-1-4 | 0.6 |
| F-1-5-6 | 앱기능 | 신규 Item 생성 플로우(자동완성 없을 때) | F-1-1-6 | F-1-5-5 | 0.4 |
| F-1-5-7 | 앱기능 | 유사 항목 제안 팝업 (편집거리 기반, 동의어 사전 연동) | F-1-1-7 | F-1-5-5 | 0.7 |
| F-1-5-8 | 앱기능 | 수량/단위 입력 필드 + 파싱(숫자+단위 분리) 로직 | F-1-1-9 | F-1-5-4 | 0.6 |
| F-1-5-9 | 앱기능 | 단위 자동완성/신규 단위 등록 제안 | F-1-1-10 | F-1-5-8, S-1-5 | 0.5 |
| F-1-5-10 | 앱기능 | 상세 금액 합계 → Transaction.amount 자동표시(읽기전용) UI 연동 | F-1-1-5 | F-1-5-4, S-1-10 | 0.4 |
| F-1-5-11 | 앱기능 | 지출 저장(API 연동, 검증) | F-1-1-4~5 | F-1-5-3, F-1-5-10 | 0.5 |
| F-1-5-12 | 앱기능 | 지출 내역 리스트 화면 (페이지네이션) | F-1-1-11 | F-1-5-11 | 0.6 |
| F-1-5-13 | 앱기능 | 지출 내역 필터(기간/분류/카테고리/지출처) | F-1-1-11 | F-1-5-12 | 0.5 |
| F-1-5-14 | 앱기능 | 지출 수정/삭제 화면 | F-1-1-12 | F-1-5-11 | 0.6 |
| T-1-5-1 | 테스트 | 지출 입력 단위테스트(금액 자동계산 검증 포함) | F-1-1-4~10 | F-1-5-11 | 0.6 |
| T-1-5-2 | 테스트 | 지출 입력 E2E 테스트(직접입력/상세입력 두 경로) | F-1-1-4~5 | F-1-5-14 | 0.6 |
소계: 약 8.0세션 — 가장 큰 블록. 일정 지연 시 우선 모니터링 대상
3-6. 앱 기능: 품목/단위 관리 화면 (F-1-1-8)
| TASK ID | 구분 | 작업명 | F-코드 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| F-1-6-1 | 앱기능 | 품목(Item) 목록 화면 | F-1-1-8 | S-1-4 | 0.5 |
| F-1-6-2 | 앱기능 | 품목 별칭 추가/수정 UI | F-1-1-8 | F-1-6-1 | 0.4 |
| F-1-6-3 | 앱기능 | 품목 수동 병합(merge) UI + 과거 집계 재계산 트리거 | F-1-1-8 | F-1-6-1 | 0.6 |
| T-1-6-1 | 테스트 | 병합 로직 단위테스트(merged_into_item_id 그룹화 검증) | F-1-1-8 | F-1-6-3 | 0.4 |
소계: 약 1.9세션
3-7. 앱 기능: 예산 (F-4)
| TASK ID | 구분 | 작업명 | F-코드 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| F-1-7-1 | 앱기능 | 예산 설정 화면(전체 예산 우선 등록 → 카테고리별 월 한도 배분, 2026-07-03 정정 — BUDGET_TOTAL 테이블 신설) |
F-4-1 | S-1-8, F-1-4-2 | 0.5 |
| F-1-7-2 | 앱기능 | 예산 소진율 게이지 컴포넌트 | F-4-2 | F-1-7-1 | 0.4 |
소계: 약 0.9세션
3-8. 앱 기능: 대시보드 1차 (F-5-1~3, MV 없이 단순 쿼리)
| TASK ID | 구분 | 작업명 | F-코드 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| S-1-15 | 시스템 | 대시보드용 단순 집계 쿼리/뷰 작성 (1단계는 MV 없이 직접 쿼리) | 5 | S-1-6, S-1-7 | 0.5 |
| F-1-8-1 | 앱기능 | 대시보드 개요 화면(요약 카드) | F-5-1 | S-1-15 | 0.5 |
| F-1-8-2 | 앱기능 | 월별 추이 차트 | F-5-2 | S-1-15 | 0.5 |
| F-1-8-3 | 앱기능 | 항목별(카테고리) 도넛/트리맵 차트 | F-5-3 | S-1-15 | 0.5 |
| T-1-8-1 | 테스트 | 대시보드 화면 E2E (데이터 입력 후 반영 확인) | F-5-1~3 | F-1-8-1~3 | 0.5 |
소계: 약 2.5세션
3-9. 반응형 대응 (cross-cutting, 아키텍처 6장)
| TASK ID | 구분 | 작업명 | 참조 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| F-1-9-1 | 앱기능 | 전체 화면 반응형 점검/보정 (모바일 1열, 데스크탑 다열) | 6 | Phase 1 모든 화면 완료 | 0.8 |
| F-1-9-2 | 앱기능 | PWA 매니페스트 적용 | 6 | F-1-9-1 | 0.3 |
소계: 약 1.1세션
3-10. 앱 기능: 지출 내역 캘린더 뷰 (2026-07-04 백로그 B-7 채택, Phase 1 완료 후 추가)
| TASK ID | 구분 | 작업명 | F-코드 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| F-1-10-1 | 앱기능 | 지출 내역 캘린더 조회 화면 (월별 그리드, 일자별 지출 카드 나열) | F-1-1-14 | F-1-5-12 | 0.7 |
| F-1-10-2 | 앱기능 | 날짜별 빠른 지출 입력 레이어 팝업 ("+" 트리거, 저장 즉시 캘린더 반영) | F-1-1-14 | F-1-10-1 | 0.6 |
| T-1-10-1 | 테스트 | 캘린더 조회 + 빠른입력 E2E (월 이동, 일자별 표시, 팝업 저장 후 반영 확인) | - | F-1-10-1~2 | 0.5 |
소계: 약 1.8세션
Phase 1 총합: 약 27.5세션 → 1일 1.2세션 가정 시 약 23일(영업일 기준, 주말 제외 시 약 4.7주)
4. Phase 2 — 서브앱(관리비) Webhook 연동 (2단계)
4-1. 시스템: Webhook 수신 인프라
| TASK ID | 구분 | 작업명 | 참조 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| S-2-1 | 시스템 | packages/event-contracts 패키지 + zod 스키마 작성 |
2 | S-0-5 | 0.5 |
| S-2-2 | 시스템 | supabase/functions/subapp-webhook-receiver Edge Function 골격 |
2, 8-1 | S-0-7, S-2-1 | 0.5 |
| S-2-3 | 시스템 | Webhook 서명 검증 로직(서비스 토큰/API 키) | 3 | S-2-2 | 0.5 |
| S-2-4 | 시스템 | 멱등성 체크(external_id+source_app 유니크) 로직 |
4 | S-2-2, S-1-6 | 0.4 |
| S-2-5 | 시스템 | Webhook → TRANSACTION+TRANSACTION_DETAIL insert 로직 (input_type=SUBAPP) |
1-1③, 4 | S-2-4 | 0.6 |
| S-2-6 | 시스템 | GitHub Actions deploy-functions.yml (Edge Functions 배포) |
8-3 | S-2-2 | 0.4 |
| T-2-1 | 테스트 | Webhook 수신 통합테스트(정상/중복/위조 서명 케이스) | - | S-2-5 | 0.6 |
소계: 약 3.5세션
4-2. 시스템: 계정 연결/항목 매핑 데이터 구조
| TASK ID | 구분 | 작업명 | 참조 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| S-2-7 | 시스템 | SUB_APP 테이블 마이그레이션 |
4 | S-0-7 | 0.3 |
| S-2-8 | 시스템 | ACCOUNT_LINK 테이블 마이그레이션 + RLS |
3, 4 | S-2-7 | 0.4 |
| S-2-9 | 시스템 | SUB_APP_ITEM_MAP 테이블 마이그레이션 |
4 | S-2-7, S-1-1, S-1-3 | 0.4 |
소계: 약 1.1세션
4-3. 앱 기능: 서브앱 연동 화면 (F-1-2)
| TASK ID | 구분 | 작업명 | F-코드 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| F-2-1-1 | 앱기능 | 서브앱 목록/소개 화면 | F-1-2-1 | S-2-7 | 0.4 |
| F-2-1-2 | 앱기능 | 계정 연결(Account Link) 플로우 화면 | F-1-2-2 | S-2-8 | 0.7 |
| F-2-1-3 | 앱기능 | 항목 매핑 설정 화면 | F-1-2-3 | S-2-9 | 0.6 |
| F-2-1-4 | 앱기능 | 연동 내역 확인 화면(원본보기, raw_payload) | F-1-2-4 | S-2-5 | 0.5 |
| F-2-1-5 | 앱기능 | 연동 해제 기능 | F-1-2-5 | F-2-1-2 | 0.3 |
| T-2-2 | 테스트 | 계정연결~매핑~Webhook수신 E2E 테스트 | F-1-2-x | F-2-1-1~4 | 0.7 |
소계: 약 3.2세션
4-4. 관리비 서브앱 (별도 작업물, 최소 구현)
| TASK ID | 구분 | 작업명 | 참조 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| S-2-10 | 시스템 | apps/sub-apps/utility-bill 프로젝트 골격 |
2 | S-0-2 | 0.4 |
| F-2-2-1 | 앱기능 | 관리비 명세 입력 화면(수동 입력 MVP, OCR은 후순위) | - | S-2-10 | 0.6 |
| S-2-11 | 시스템 | 관리비 → 메인앱 Webhook 발행 로직(publisher) | 2 | S-2-1, F-2-2-1 | 0.5 |
| T-2-3 | 테스트 | 관리비 입력→Webhook 발행→메인 반영 통합테스트 | - | S-2-11 | 0.5 |
소계: 약 2.0세션
Phase 2 총합: 약 9.8세션 → 약 8~9일
5. Phase 3 — 통계 분리/캐시/대시보드 고도화 (3단계)
| TASK ID | 구분 | 작업명 | F/참조 코드 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| S-3-1 | 시스템 | tx_stats Materialized View 작성 |
5 | S-1-6 | 0.5 |
| S-3-2 | 시스템 | item_stats Materialized View 작성 |
5 | S-1-7 | 0.5 |
| S-3-3 | 시스템 | item_unit_stats Materialized View 작성 (quantity_value/unit_id 필터) |
5 | S-1-7, S-1-5 | 0.6 |
| S-3-4 | 시스템 | MV 리프레시 트리거/스케줄(Edge Function 또는 트리거) | 5 | S-3-1~3 | 0.6 |
| S-3-5 | 시스템 | Upstash Redis 연동 (캐시 레이어) | 8-1 | S-0-9 | 0.5 |
| S-3-6 | 시스템 | Top10/통계 API 캐시 적용 (item_top10:{userId}:{period} 등 키 설계) |
5 | S-3-2, S-3-5 | 0.6 |
| F-3-1-1 | 앱기능 | 지출분류별(①) 통계 화면 (현금/카드, 카드(카드사명)별) | F-5-4 | S-3-1 | 0.5 |
| F-3-1-2 | 앱기능 | 지출처 Top N 화면 | F-5-5 | S-3-2 | 0.5 |
| F-3-1-3 | 앱기능 | 상세항목 Top10 화면 + 드릴다운(지출처별) | F-5-6 | S-3-2, S-3-6 | 0.7 |
| F-3-1-4 | 앱기능 | 단가 분석 화면(품목×단위 추이 차트) | F-5-7 | S-3-3 | 0.7 |
| F-3-1-5 | 앱기능 | 동의어 사전 관리 화면(운영자) | F-1-1-13 | - | 0.6 |
| T-3-1 | 테스트 | 통계 정확도 검증(수동 계산값과 MV 결과 비교) | F-5-x | F-3-1-1~4 | 0.7 |
| T-3-2 | 테스트 | 캐시 갱신/무효화 테스트 | - | S-3-6 | 0.4 |
Phase 3 총합: 약 7.7세션 → 약 6~7일
6. Phase 4 — 서브앱 확장 + 계정연결 정식화 (4단계)
| TASK ID | 구분 | 작업명 | 참조 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| S-4-1 | 시스템 | apps/sub-apps/subscription 골격 + Webhook 발행 연동 |
2 | S-2-1, S-2-2 | 0.8 |
| S-4-2 | 시스템 | apps/sub-apps/card-statement 골격 + Webhook 발행 연동 |
2 | S-2-1, S-2-2 | 0.8 |
| F-4-1-1 | 앱기능 | 다중 서브앱 대응 UI 보정 (목록/매핑 화면 확장성 점검) | F-1-2-1~3 | F-2-1-1~3 | 0.5 |
| S-4-3 | 시스템 | Event Bus 전환 필요성 재검토 (서브앱 3개 기준 Webhook 부하 점검, 필요시 Upstash Kafka 등 도입) | 1, 8-1 | S-4-1, S-4-2 | 0.5 |
| T-4-1 | 테스트 | 서브앱 3종 동시 연동 회귀테스트 | - | S-4-1, S-4-2 | 0.7 |
Phase 4 총합: 약 3.3세션 → 약 3일
7. Phase 5 — 통합 테스트 / QA / 출시
| TASK ID | 구분 | 작업명 | 참조 | 선행작업 | 세션 |
|---|---|---|---|---|---|
| T-5-1 | 테스트 | 전체 기능 회귀테스트(F-코드 전체 체크리스트) | 기능명세서_IA | Phase 1~4 완료 | 1.0 |
| T-5-2 | 테스트 | RLS 정책 보안 점검(타 사용자 데이터 접근 차단 검증) | 3, 4 | S-1-9 | 0.6 |
| T-5-3 | 테스트 | 반응형 크로스 디바이스 점검 | 6 | F-1-9-1 | 0.5 |
| T-5-4 | 테스트 | 성능 점검(대시보드 응답속도, MV/캐시 효과 확인) | 5, 8-1 | S-3-6 | 0.5 |
| S-5-1 | 시스템 | 운영 환경 마이그레이션 최종 점검 + 프로덕션 배포 | 8-3 | 전체 | 0.4 |
| S-5-2 | 시스템 | 모니터링/에러로깅 설정(선택) | 8-1 | S-5-1 | 0.4 |
Phase 5 총합: 약 3.4세션 → 약 3일
8. 전체 일정 요약
| Phase | 세션(추정) | 예상 소요일(1일 1.2세션 가정) |
|---|---|---|
| Phase 0 사전 셋업 | 8.1 | 7일 |
| Phase 1 메인앱 Core | 25.7 | 21일 |
| Phase 2 서브앱 Webhook 연동 | 9.8 | 8일 |
| Phase 3 통계/캐시 고도화 | 7.7 | 6일 |
| Phase 4 서브앱 확장 | 3.3 | 3일 |
| Phase 5 통합테스트/QA/출시 | 3.4 | 3일 |
| 총합 | 약 58.0세션 | 약 48일(영업일 기준, 주말 제외 시 약 10주) |
이 추정은 "TASK를 세션 단위로 끝낼 수 있게 잘게 쪼갠다"는 전제 위에서 나온 숫자이며, 실제로는 ① Claude Pro 세션당 처리량이 작업 복잡도/모델 선택에 따라 더 적거나 많을 수 있고 ② 1인 PM이 직접 검수/디버깅하는 시간(Claude 세션 외 시간)은 포함되지 않았습니다. 1주차 진행 후 실제 세션 소진 속도를
/usage로 확인하여 Phase 1 일정을 보정하는 것을 권장합니다. 세션이 자주 부족하면 Max 5x 업그레이드를, 반대로 여유가 있으면 Phase를 병렬로 당겨와도 됩니다.
9. 작업 순서 검토 — 권장 진행 순서 핵심 원칙
- DB(S) 먼저, 화면(F) 나중: 모든 Phase에서 테이블/RLS 마이그레이션을 먼저 끝내고 화면을 붙입니다. 화면을 먼저 만들면 DB 스키마가 바뀔 때 재작업이 커집니다.
- 마스터 데이터(F-1-1-1~3) → 지출 입력(F-1-1-4~10) → 대시보드(F-5-x) 순서 고정: 지출 입력 화면은 지출분류/지출항목/지출처가 먼저 있어야 선택 UI를 만들 수 있고, 대시보드는 지출 데이터가 쌓여야 검증 가능합니다.
- Phase 1의 "3-5. 지출 입력" 블록(8세션)이 최대 리스크 구간입니다. 이 블록만 따로 주 단위로 진행 상황을 점검하고, 필요하면 F-1-1-7(유사 항목 제안)·F-1-1-9/10(수량단위 구조화)처럼 "있으면 좋은" 기능은 우선순위를 낮춰 Phase 1 후반이나 Phase 3로 미루는 것도 가능합니다(단, 미룰 경우 데이터 스키마는 미리 만들어두고 UI만 늦추는 방식 권장 — 마이그레이션 재작업 방지).
- 통계(Phase 3)는 데이터가 어느 정도 쌓인 후 검증 가능하므로, Phase 1에서 임시로 만든 단순 쿼리 기반 대시보드(S-1-15)를 운영하면서 Phase 3에서 MV/캐시로 교체하는 점진적 전환을 권장합니다.
- 서브앱(Phase 2, 4)은 메인앱 Webhook 수신부(S-2-2~5)가 먼저 완성된 후 착수합니다 — 서브앱이 보낼 데이터 계약(
event-contracts)이 먼저 확정돼야 서브앱 publisher 구현이 가능합니다. - 테스트(T-코드)는 각 기능 블록이 끝날 때마다 바로 진행 — 마지막에 몰아서 하면 버그 원인 추적이 어려워지고, 디버깅에 드는 Claude 세션이 급증합니다.