startover/DEVELOPMENT_PLAN.md

# Re:Link (리링크) 실행형 개발계획서

> 폐업-철거-인테리어 선순환 통합 매칭 플랫폼
> 작성일: 2026-03-07 | 기준 문서: 2026년 예비창업패키지 사업계획서
> 목적: 사업계획서를 실제 제품 개발, 운영, 배포가 가능한 실행 문서로 재구성

---

## 1. 문서 목적

이 문서는 단순 기능 목록이 아니라, Re:Link MVP를 실제로 만들기 위해 먼저 고정해야 할 **정책, 운영, 계측, 아키텍처, 일정**을 정리한 실행 기준 문서다.

### 1-1. 문서 역할

- 사업계획서의 비전과 수익 모델을 제품 요구사항으로 번역한다.
- 개발 전에 애매한 의사결정을 줄이고, 구현 중 재작업을 최소화한다.
- 운영자 개입이 많은 초기 플랫폼의 현실을 반영한다.
- 실제 구현은 별도 `plan.md`에서 TDD 기준으로 관리한다.

### 1-2. 토스식 의사결정 원칙

Re:Link의 MVP 의사결정은 아래 원칙을 기본값으로 삼는다.

| 원칙 | 적용 방식 |
|------|-----------|
| 정책이 코드보다 먼저 | 정부 지원금, 정보 공개, 정산, 분쟁 규칙을 먼저 문서화하고 그 다음 구현한다. |
| 운영 가능한 MVP 우선 | 완전 자동화보다 운영자 승인형 플로우를 먼저 출시한다. |
| 계측 없는 기능은 출시하지 않음 | 모든 핵심 기능은 이벤트 스키마와 KPI 계산식이 먼저 정의되어야 한다. |
| 외부 연동은 격리 | PG, 알림, 지도, 사업자 인증은 모두 어댑터 계층과 재시도 정책 뒤에 둔다. |
| 작게 출시하고 빠르게 보정 | 베타 지역과 업종을 좁혀 feature flag 기반으로 순차 출시한다. |
| 롤백 가능하게 설계 | 결제, 알림, 문서 처리, 상태 전환은 replay 가능한 로그와 감사 기록을 남긴다. |
| DRI 명확화 | 각 도메인마다 최종 의사결정 책임자를 한 명으로 고정한다. |

### 1-3. 문서 계층

| 문서 | 역할 |
|------|------|
| 사업계획서 HTML | 왜 이 사업을 하는지와 시장/수익 전략을 설명 |
| `DEVELOPMENT_PLAN.md` | 무엇을 어떤 원칙으로 만들지 결정 |
| `plan.md` | 현재 구현 중인 테스트와 작업 순서를 관리 |

---

## 2. 제품 정의

### 2-1. 핵심 가치 제안

폐업자가 매장 정보를 **1회 등록**하면, 창업자-철거업체-인테리어업체를 **동시 연결**하여 폐업 비용을 줄이고 재창업/인수 기회를 높이는 선순환 플랫폼을 만든다.

### 2-2. 핵심 사용자

| 코드 | 사용자 | 핵심 니즈 | 초기 수익 연결 |
|------|--------|----------|----------------|
| U1 | 폐업자 | 철거비 절감, 시설 처분, 지원금 신청 도움 | 거래 성사, 부가 서비스 |
| U2 | 창업자 | 시설 인수, 인테리어 비용 절감 | 성공 수수료 |
| U3 | 철거업체 | 안정적 수주, 인증, 정산 안정성 | 수수료, 향후 구독 |
| U4 | 인테리어업체 | 선제 영업 정보, 리드 확보 | 향후 구독, 광고 |
| U5 | 운영자/관리자 | 심사, 검수, 중재, 정산, 계측 | 서비스 신뢰 유지 |

### 2-3. 초기 베타 범위

- 지역: 서울 강남권 `역삼/선릉/논현`, 마포권 `홍대/합정/연남`
- 업종: F&B 우선
- 출시 방식: 운영자 개입형 assisted marketplace
- 목표 사용자: 폐업자 100명, 철거업체 50개, 초기 창업자 리드 확보

### 2-4. MVP 성공 기준

| 항목 | 기준 |
|------|------|
| 공급 확보 | 검수 가능한 폐업 매장 데이터가 지속 유입된다. |
| 거래 신뢰 | 계약, 검수, 정산, 분쟁 처리의 운영 기준이 흔들리지 않는다. |
| 측정 가능성 | 핵심 KPI가 이벤트 로그만으로 재현 가능하다. |
| 운영 가능성 | 운영 콘솔 없이 수작업 엑셀에 의존하지 않는다. |
| 확장성 | Phase 2에서 B2B 구독과 직거래 장터를 붙일 수 있는 데이터 구조를 확보한다. |

---

## 3. MVP 범위 재정의

### 3-1. Phase 1 MVP

| 우선순위 | 기능 묶음 | MVP 포함 범위 | MVP 제외 범위 |
|---------|-----------|----------------|----------------|
| P0 | 사용자/인증 | 역할 선택 가입, 소셜 로그인, 기본 사업자 확인, 운영자 수동 보정 | 고도화된 KYC 자동화 |
| P0 | 매장 등록 | 매장 기본 정보, 임대/시설 정보, 사진 업로드, 검토 요청, 공개/비공개 전환 | 복수 지점 일괄 등록 |
| P0 | 매칭 | 검색, 필터, 매칭 요청, 운영자 수동 추천, 요청 승인/거절 | 실시간 추천 고도화, 자동 배정 |
| P0 | 정부 지원금 가이드형 대행 | 자격 판별, 서류 체크리스트, 업로드, 운영자 검토, 상태 추적 | 법적 자격 없이 완전 대리 제출 자동화 |
| P0.5 | 운영 백오피스 | 등록 검토, 업체 인증, 지원금 검토, 검수 승인, 정산 보류/해제, 감사 로그 | 고급 BI, 복잡한 권한 위임 체계 |
| P1 | 신뢰 인프라 | 업체 인증, 표준 계약서 템플릿, 서명 증적 저장, 에스크로 결제, 사진 검수, 분쟁 접수 | 완전 자동 정산, 고도화된 분쟁 자동 판정 |
| P1 | 시세 추천 | 규칙 기반 범위 추천, 견적 비교 기준 제공 | ML 기반 가격 예측 |

### 3-2. Phase 2

| 우선순위 | 기능 | 범위 |
|---------|------|------|
| P2 | 폐업 물품 직거래 장터 | 물품 등록, 검색, 예약, 거래 완료 |
| P2 | B2B 폐업 예정지 알림 | 지역/업종별 구독, 정기 결제, 알림 상품화 |
| P2 | 정부 지원금 대행 고도화 | 문서 자동 생성, 운영 자동화 |
| P2 | 스마트 시세 추천 고도화 | ML 모델 전환, 정확도 검증 |
| P2 | 모바일 앱 | React Native 기반 모바일 전환 |

### 3-3. MVP에서 의도적으로 늦추는 것

- 실시간 채팅 대신 `문의 스레드 + 운영자 브릿지`를 먼저 사용한다.
- B2B 구독은 데이터 모델과 정책만 먼저 준비하고 유료화는 Phase 2에서 시작한다.
- 직거래 장터는 MVP 핵심 거래 흐름이 안정화된 뒤 붙인다.

---

## 4. 반드시 고정할 제품/운영 정책

### 4-1. 정책 기본값

| 정책 | 기본 결정 |
|------|-----------|
| 정부 지원금 신청 대행 | MVP는 `가이드형 + 운영자 검토형`으로 시작한다. 법적 자격 검토 전 완전 대행 자동화는 하지 않는다. |
| 폐업 정보 공개 | 기본값은 비식별/제한 공개다. 상세 주소, 연락처, 민감 정보는 소유자 동의와 권한 검증 후 노출한다. |
| B2B 데이터 판매/알림 | MVP에서는 익명화된 리드성 데이터 구조만 준비한다. 원본 개인 정보 직접 판매는 하지 않는다. |
| 계약/에스크로 | 계약 생성과 결제는 가능하되 정산 해제는 검수 승인 또는 운영자 승인 이후에만 진행한다. |
| 분쟁 처리 | 분쟁 발생 시 자동 정산 해제는 중단되고 운영자 검토 상태로 전환한다. |
| 권리금/임대차 | MVP에서는 권리금 협상과 임대차 법률 행위의 직접 중개를 하지 않는다. 정보 제공과 파트너 연결만 한다. |
| 업체 인증 | 인증 서류, 영업 이력, 서비스 가능 지역, 제재 이력을 기준으로 운영자 승인형으로 관리한다. |
| 개인정보/문서 보관 | 문서 접근은 서명 URL과 감사 로그 기반으로 제한하고, 보존 기간은 법적 검토 결과를 우선 적용한다. |

### 4-2. 지원금 대행 정책

- 서비스 포지션은 `정부 사업 경쟁자`가 아니라 `신청 보조 파트너`다.
- 사용자에게는 체크리스트, 업로드, 진행 상태, 운영자 피드백을 제공한다.
- 운영자는 서류 누락, 반려 사유, 제출 준비 여부를 판정한다.
- 정책/법무 검토 전에는 시스템이 정부 기관을 대리해 자동 제출하는 구조를 만들지 않는다.

### 4-3. 정보 공개 정책

- 폐업 등록 즉시 모든 정보가 공개되지 않는다.
- 창업자에게는 매칭 가능한 핵심 요약 정보를 먼저 보여준다.
- 철거업체/인테리어업체에는 역할과 권한에 맞는 정보만 공개한다.
- B2B 알림 상품은 Phase 2에서 시작하되, 지금부터 `공개 등급`, `권한`, `동의`, `열람 이력` 데이터를 남긴다.

### 4-4. 계약/정산 정책

- 계약은 표준 템플릿 기반으로 생성한다.
- 서명 행위는 증적을 남겨야 하며, 문서 버전과 타임스탬프를 같이 저장한다.
- 에스크로 상태는 결제 성공과 운영 승인, 검수 승인, 분쟁 여부를 기준으로 전이한다.
- 부분 환불, 수동 정산, 보류 해제는 운영 콘솔에서만 실행한다.

---

## 5. 도메인 모델

### 5-1. 바운디드 컨텍스트

| 컨텍스트 | 책임 |
|----------|------|
| Identity | 사용자, 역할, 인증, 사업자 확인 |
| Store Supply | 매장 등록, 시설/임대 정보, 사진, 공개 상태 |
| Matching | 매칭 후보 계산, 요청, 수락/거절, 운영자 추천 |
| Subsidy | 지원금 체크리스트, 서류, 상태, 운영자 검토 |
| Trust | 업체 인증, 계약, 에스크로, 검수, 분쟁 |
| Notification | 알림톡, 푸시, 이메일, 메시지 템플릿 |
| Backoffice | 운영 큐, 감사 로그, 수동 보정, 통계 |
| Analytics | 이벤트 로그, KPI, 리포트, 데이터 파이프라인 |

### 5-2. 핵심 엔티티

```
User
├── UserProfile
├── UserConsent
├── Store[]
└── Vendor[]

Store
├── StoreLease
├── StoreFacility
├── StoreLifecycle
├── StorePhoto[]
├── StoreAsset[]
├── MatchLead[]
├── MatchRequest[]
└── PriceEstimate[]

Vendor
├── VendorCertification
├── VendorCoverageArea[]
├── VendorQuote[]
└── VendorPenalty[]

MatchRequest
├── MatchReview
└── Contract?

Contract
├── ContractVersion[]
├── SignatureEvidence[]
├── EscrowTransaction
├── InspectionRecord[]
└── DisputeCase?

SubsidyCase
├── SubsidyDocument[]
├── SubsidyChecklistItem[]
└── SubsidyReviewLog[]

AlertSubscription
AuditLog
EventLog
```

### 5-3. 베타에 반드시 필요한 마스터 데이터

| 데이터 | 설명 |
|--------|------|
| `RegionHierarchy` | 시/구/동/상권/클러스터 구조 |
| `IndustryTaxonomy` | 대분류/중분류/세분류/영업형태 |
| `StoreLease` | 보증금, 월세, 관리비, 권리금, 잔여 임대기간 |
| `StoreFacility` | 전용면적, 층수, 좌석 수, 전기, 가스, 배수, 덕트, 주방 설비 |
| `StoreLifecycle` | 폐업 예정일, 인수 가능일, 철거 예정일 |
| `VendorCoverageArea` | 업체 서비스 권역 |
| `VendorCapability` | 철거/인테리어 가능 범위, 장비, 인증 상태 |

### 5-4. 상태머신

| 도메인 | 상태 |
|--------|------|
| Store | `DRAFT -> SUBMITTED -> REVIEWING -> PUBLISHED -> MATCHING -> RESERVED -> CONTRACTED -> CLOSED/CANCELLED` |
| MatchRequest | `PENDING -> REVIEWING -> ACCEPTED/REJECTED -> CONTRACTING -> COMPLETED/EXPIRED` |
| SubsidyCase | `DRAFT -> ELIGIBILITY_CHECKED -> DOCUMENTS_PENDING -> REVIEWING -> READY_TO_SUBMIT -> SUBMITTED -> APPROVED/REJECTED` |
| VendorCertification | `APPLIED -> REVIEWING -> APPROVED/REJECTED -> SUSPENDED` |
| Contract | `DRAFT -> GENERATED -> SIGNING -> SIGNED -> IN_PROGRESS -> COMPLETED/CANCELLED` |
| Escrow | `PENDING -> DEPOSIT_PAID -> HOLDING -> RELEASE_REVIEW -> RELEASED/REFUNDED` 또는 `HOLDING/RELEASE_REVIEW -> DISPUTED` |
| Inspection | `REQUESTED -> UPLOADED -> REVIEWING -> APPROVED/REJECTED` |
| DisputeCase | `OPEN -> INVESTIGATING -> MEDIATING -> RESOLVED/CLOSED` |

모든 상태 전환은 `AuditLog`와 `EventLog`를 동시에 남긴다.

---

## 6. 운영 백오피스 설계

### 6-1. MVP 필수 운영 화면

- 매장 등록 검토 큐
- 공개/비공개 전환 및 반려 사유 관리
- 업체 인증 심사 큐
- 지원금 서류 검토 큐
- 계약 문서/서명 증적 뷰어
- 검수 사진 승인 화면
- 분쟁 접수/메모/상태 변경 화면
- 정산 보류/해제 및 결제 대사 화면
- 이벤트/KPI 대시보드
- 감사 로그 조회

### 6-2. 운영 역할

| 역할 | 책임 |
|------|------|
| `SUPER_ADMIN` | 전체 설정, 권한, 긴급 조치 |
| `OPS_MANAGER` | 등록 검토, 매칭 보정, 운영 품질 |
| `SUBSIDY_OPERATOR` | 지원금 서류 검토, 상태 관리 |
| `TRUST_OPERATOR` | 업체 인증, 계약, 검수, 분쟁 |
| `FINANCE_OPERATOR` | 정산, 결제 대사, 환불 처리 |

### 6-3. 운영 기본 원칙

- 운영자가 개입한 모든 결정에는 사유 코드와 메모를 남긴다.
- 사람이 개입해 상태를 바꾼 경우 원래 상태와 변경자를 감사 로그에 남긴다.
- 베타 단계에서는 자동화보다 운영 안정성이 우선이다.

---

## 7. 아키텍처와 인프라

### 7-1. 아키텍처 방향

Phase 1은 **Next.js 기반 모듈러 모놀리스**로 시작하되, 도메인 로직은 프레임워크 바깥 계층에 두어 Phase 2의 분리를 `재작성`이 아닌 `어댑터 추가`로 만든다.

### 7-2. 추천 프로젝트 구조

```
re-link/
├── apps/
│   ├── web/                    # Next.js 사용자 웹
│   ├── admin/                  # Next.js 운영 콘솔
│   └── api/                    # Phase 2 NestJS 어댑터
├── packages/
│   ├── domain/                 # 엔티티, 값 객체, 상태 규칙
│   ├── application/            # 유스케이스, 서비스, 정책
│   ├── infrastructure/         # PG/알림/지도/파일/결제 어댑터
│   ├── database/               # Prisma 스키마 + 마이그레이션
│   ├── analytics/              # 이벤트 스키마, KPI 계산
│   ├── ui/                     # 공통 UI
│   └── shared/                 # 공통 타입, 상수, 유틸
└── docs/
    └── policies/               # 제품/운영 정책 문서
```

### 7-3. 기술 선택

| 레이어 | 선택 | 원칙 |
|--------|------|------|
| 프론트엔드 | Next.js 15 + TypeScript | 웹/운영 콘솔 동시 대응 |
| 상태 관리 | Zustand + TanStack Query v5 | 클라이언트/서버 상태 분리 |
| UI | shadcn/ui + Tailwind CSS v4 | 빠른 조립과 일관성 |
| 백엔드 | Next.js Route Handler + Service Layer | HTTP 어댑터를 얇게 유지 |
| ORM | Prisma | 타입 안정성과 마이그레이션 |
| DB | PostgreSQL 16 + PostGIS | 지역 기반 검색과 관계 모델 |
| 캐시 | Redis | 캐시, 세션, 읽기 성능 개선 |
| 비동기 처리 | Postgres Outbox + Worker | MVP에서 신뢰성 있는 재시도와 idempotency 확보 |
| 파일 | 객체 스토리지 인터페이스 | IDC 환경에서도 MinIO/S3 호환 구조로 추상화 |
| 결제 | 토스페이먼츠 | 국내 PG/에스크로 연동 |
| 인증 | Auth.js 계열 + 소셜 로그인 | 접근성 확보 |
| 지도 | Kakao Maps SDK + 로컬 API | 국내 주소/좌표 정확도 |
| 알림 | 카카오 알림톡 + FCM + SES | 템플릿형 커뮤니케이션 |
| 관측 | Sentry + 구조화 로그 + 대시보드 | 운영 중심 모니터링 |

### 7-4. 외부 연동 규칙

| 연동 | MVP 원칙 |
|------|-----------|
| 토스페이먼츠 | 웹훅은 idempotent 하게 처리하고 replay 기능을 제공한다. |
| 알림 | 템플릿 ID를 관리하고 발송 실패 시 재시도한다. |
| 지도 | 주소 정규화와 좌표 캐시를 둔다. |
| 사업자 확인 | 자동 조회 실패 시 운영자 수동 승인 절차를 둔다. |
| 파일 업로드 | 서명 URL, 접근 로그, 업로드 용량 제한을 적용한다. |

### 7-5. 배포 원칙

- PR 단계에서 lint, type-check, unit test를 통과해야 한다.
- staging에서 integration test와 smoke test를 통과해야 production 배포가 가능하다.
- 결제, 정산, 분쟁 관련 기능은 feature flag 뒤에서 점진 출시한다.

---

## 8. 보안 및 컴플라이언스

| 영역 | 대책 |
|------|------|
| 인증 | 세션/토큰 만료 정책, 소셜 로그인, 운영자 계정 보호 |
| 인가 | RBAC + API 단위 권한 검사 |
| 개인정보 | PII 분리 저장, 민감 필드 암호화, 접근 로그 |
| 결제 | 카드 정보 비저장, PG 위임, 정산 로그 보존 |
| 문서 | 서명 URL 기반 접근, 버전 보존, 다운로드 로그 |
| API | Rate limiting, CORS, CSRF, 입력 검증 |
| 인프라 | VPC, 프라이빗 DB, 보안 그룹, 비밀값 관리 |
| 감사 | 운영자 조작 로그, 상태 변경 이력, 이벤트 추적 |

---

## 9. 데이터 계측과 KPI 정의

### 9-1. KPI 소스 오브 트루스

| KPI | 정의 | 소스 이벤트 |
|-----|------|-------------|
| 등록 폐업자 | `store_submitted`를 1회 이상 발생시킨 고유 폐업자 수 | `store_submitted` |
| 입점 업체 수 | 인증 승인된 업체 수 | `vendor_certification_approved` |
| 월 거래 건수 | 인수 완료 또는 철거 정산 완료된 거래 수 | `transaction_completed` |
| MRR | 월 인식 반복 매출 합계 | `revenue_recognized_monthly` |
| B2B 구독 업체 | 유료 구독이 활성 상태인 업체 수 | `subscription_activated` |
| 시설인수 매칭 성공률 | 인수 대상 매장 중 계약 완료된 매장 비율 | `store_published`, `acquisition_contract_signed` |
| 유지율 | 기준 기간 내 재방문 또는 재거래한 사업자 비율 | `monthly_active_user`, `transaction_completed` |

### 9-2. MVP 필수 이벤트

| 이벤트명 | 필수 속성 |
|----------|-----------|
| `store_draft_created` | `user_id`, `region_cluster`, `industry_code` |
| `store_submitted` | `store_id`, `user_id`, `region_cluster`, `industry_code` |
| `store_reviewed` | `store_id`, `result`, `reason_code`, `operator_id` |
| `store_published` | `store_id`, `region_cluster`, `industry_code`, `publish_channel` |
| `match_requested` | `store_id`, `requester_role`, `requester_id` |
| `match_accepted` | `store_id`, `match_request_id`, `operator_involved` |
| `subsidy_case_started` | `subsidy_case_id`, `store_id`, `eligibility_result` |
| `subsidy_case_reviewed` | `subsidy_case_id`, `result`, `reason_code`, `operator_id` |
| `vendor_certification_applied` | `vendor_id`, `service_type`, `coverage_area` |
| `vendor_certification_approved` | `vendor_id`, `operator_id` |
| `contract_generated` | `contract_id`, `store_id`, `contract_type` |
| `acquisition_contract_signed` | `contract_id`, `store_id`, `industry_code`, `region_cluster` |
| `contract_signed` | `contract_id`, `signed_by_role`, `document_version` |
| `escrow_paid` | `escrow_id`, `amount`, `payment_provider` |
| `inspection_submitted` | `inspection_id`, `contract_id`, `photo_count` |
| `inspection_approved` | `inspection_id`, `operator_id` |
| `dispute_opened` | `dispute_id`, `contract_id`, `reason_code` |
| `escrow_released` | `escrow_id`, `amount`, `release_type` |
| `transaction_completed` | `transaction_type`, `store_id`, `contract_id`, `amount` |
| `revenue_recognized_monthly` | `revenue_type`, `amount`, `recognized_month` |
| `subscription_activated` | `vendor_id`, `plan_code`, `billing_cycle` |
| `monthly_active_user` | `user_id`, `user_role`, `activity_month` |
| `notification_sent` | `channel`, `template_code`, `target_role` |

### 9-3. 계측 원칙

- 이벤트 스키마에는 버전을 둔다.
- PII는 analytics 이벤트에 직접 싣지 않는다.
- 베타 이전에 운영자가 KPI를 직접 확인할 수 있는 대시보드를 연다.
- 계산식이 정의되지 않은 지표는 KPI로 선언하지 않는다.

---

## 10. 테스트 및 품질 기준

### 10-1. 개발 방식

- 모든 기능은 `Red -> Green -> Refactor`의 TDD 사이클로 구현한다.
- 개발 시작 전에 별도 `plan.md`를 만들고 테스트 단위를 먼저 쪼갠다.
- 구조적 변경과 행위적 변경은 같은 커밋에 섞지 않는다.

### 10-2. 테스트 레이어

| 레이어 | 범위 |
|--------|------|
| Unit Test | 정책 함수, 상태머신, 가격 규칙, 권한 규칙 |
| Integration Test | API, DB, PG 웹훅, 알림 어댑터, 파일 업로드 |
| E2E Test | 매장 등록, 매칭 요청, 지원금 서류 제출, 계약/검수/정산 흐름 |

### 10-3. 베타 전 필수 시나리오

- 폐업자가 매장을 등록하고 운영자 검토 후 공개할 수 있다.
- 창업자가 공개 매장을 검색하고 매칭 요청을 보낼 수 있다.
- 운영자가 지원금 서류를 검토하고 상태를 변경할 수 있다.
- 업체 인증 승인 후 계약 생성과 결제가 진행된다.
- 검수 승인 전에는 정산이 해제되지 않는다.
- 분쟁이 열리면 정산이 자동으로 보류된다.

---

## 11. 게이트 기반 일정

### 11-1. 전제 조건

- 26.04 협약 시작
- 대표 1명 + CTO 1명 즉시 투입
- 26.05 백엔드 1명, 디자이너 1명 합류
- 기존 프로토타입 코드와 운영 방식이 존재함

### 11-2. 게이트 정의

| 게이트 | 종료 조건 |
|--------|-----------|
| G0 정책 고정 | 지원금, 정보 공개, 정산/분쟁 정책 문서 확정 |
| G1 공급 유입 준비 | 회원, 매장 등록, 검토 큐, 지역/업종 마스터 완료 |
| G2 Assisted Matching 준비 | 공개/검색/요청/수동 추천/알림까지 동작 |
| G3 Trust 인프라 준비 | 업체 인증, 계약, 결제, 검수, 분쟁 흐름 검증 |
| G4 Beta Ready | 계측, 대시보드, 보안, 관제, 운영 런북 완료 |

### 11-3. 스프린트 계획

| 스프린트 | 기간 | 목표 | 산출물 |
|---------|------|------|--------|
| S1 | 04.01~04.14 | G0 준비 | 프로토타입 리뷰, 정책 초안, 도메인 모델, 이벤트 스키마, 인프라 초안 |
| S2 | 04.15~04.28 | G0 완료 | 정책 문서 확정, 운영 권한 모델, 백오피스 IA, CI/CD |
| S3 | 04.29~05.12 | G1 시작 | 회원/인증, 지역/업종 마스터, 매장 등록, 검토 큐 |
| S4 | 05.13~05.26 | G1 완료 | 매장 공개, 기본 검색, 운영자 검토, 사진 업로드 |
| S5 | 05.27~06.09 | G2 | 매칭 요청/수락, 수동 추천, 문의 스레드, 알림 |
| S6 | 06.10~06.23 | G2 확장 | 지원금 가이드형 대행, 체크리스트, 운영자 리뷰 |
| S7 | 06.24~07.07 | G3 시작 | 업체 등록/인증, 계약서 템플릿, 서명 증적 |
| S8 | 07.08~07.21 | G3 완료 | 에스크로 샌드박스, 검수, 분쟁, 정산 보류/해제 |
| S9 | 07.22~08.04 | G4 시작 | KPI 대시보드, 감사 로그, 장애 알람, 런북 |
| S10 | 08.05~08.18 | G4 완료 | 통합 테스트, E2E, 보안 점검, 운영 온보딩 |
| S11 | 08.19~09.01 | 베타 런칭 | 강남/마포 베타, 모니터링, 운영 데이터 수집 |
| S12~S16 | 09.02~12.31 | Phase 2 준비 | 직거래 장터, B2B 알림, 시세 고도화, 모바일 전환 준비 |

### 11-4. 우선순위 재정렬 원칙

- 정책과 운영이 고정되지 않으면 자동화 기능을 미룬다.
- 정산과 분쟁이 불안정하면 채팅이나 고급 UX보다 먼저 보완한다.
- 베타 이전에는 `운영 도구`와 `계측`이 신규 기능보다 우선이다.

### 11-5. MVP DRI

| 영역 | DRI |
|------|-----|
| 제품 정책/우선순위 | 대표 |
| 아키텍처/배포/품질 | CTO |
| 결제/정산/외부 연동 | 백엔드 개발 |
| 운영 프로세스/백오피스 | 대표 + 운영 담당 |
| UX/플로우 설계 | UI/UX 디자이너 |

---

## 12. 외부 의존성과 리스크

### 12-1. 외부 의존성

| 영역 | 파트너 | 착수 시점 | 실패 시 fallback |
|------|--------|-----------|------------------|
| 결제/에스크로 | 토스페이먼츠 | S1 | 수동 정산 승인형 운영 |
| 계약/법무 | 법률사무소 | S1~S2 | 계약 템플릿은 법무 승인 전 제한 사용 |
| 정부 지원 연계 | 소상공인 지원 기관 | S2~S3 | 가이드형 서비스로 축소 |
| 초기 공급 확보 | 지역 철거업체 협회/파트너 | S3~S4 | 운영자 직접 온보딩 |
| 인프라 | AWS/IDC | S1 | 환경 이중화와 저장소 추상화 |

### 12-2. 핵심 리스크

| 등급 | 리스크 | 대응 |
|------|--------|------|
| CRITICAL | 에스크로 계약/연동 지연 | S1 즉시 착수, 웹훅/정산 구조 선구현, 운영 fallback 준비 |
| CRITICAL | 지원금 대행의 법적 경계 불명확 | 가이드형 MVP 유지, 법무 검토 후 범위 확장 |
| HIGH | 폐업 정보 확보 부족 | 지원금 유입 채널, 협회/기관 제휴, 운영자 소싱 병행 |
| HIGH | 분쟁/정산 운영 과부하 | 백오피스와 사유 코드 체계 선구축 |
| HIGH | 지역/업종 데이터 품질 부족 | 강남/마포, F&B로 범위 축소 후 데이터 정제 |
| MEDIUM | 실시간 기능 복잡도 | 문의 스레드 우선, 실시간 채팅은 뒤로 이동 |
| MEDIUM | 파일 저장 안정성 | 객체 스토리지 추상화, 접근 제어, 백업 정책 적용 |

---

## 13. 개발 착수 전 즉시 해야 할 일

### 13-1. 반드시 이번 주에 끝낼 것

1. 프로토타입 코드와 현재 운영 방식 실사
2. `지원금 대행 정책서` 작성
3. `폐업 정보 공개 정책서` 작성
4. `계약-에스크로-분쟁 정책서` 작성
5. KPI 계산식과 이벤트 스키마 고정
6. 베타 지역/업종 마스터 데이터 정의

### 13-2. 바로 만들어야 할 산출물

- `plan.md`
- `docs/policies/subsidy-policy.md`
- `docs/policies/data-exposure-policy.md`
- `docs/policies/contract-escrow-policy.md`
- `docs/analytics/event-schema.md`
- `docs/ops/runbook.md`

---

## 14. 최종 정리

Re:Link의 MVP는 단순한 매칭 앱이 아니라, **정책과 운영으로 신뢰를 만드는 거래 플랫폼**이다. 따라서 개발 우선순위는 `예쁜 UI`나 `기능 수`가 아니라 아래 순서를 따라야 한다.

1. 정책 고정
2. 운영 도구 구축
3. 계측 삽입
4. 핵심 거래 흐름 구현
5. 베타 검증
6. 이후 자동화와 확장

이 순서를 지키면 사업계획서의 강점인 `정부 연계`, `신뢰 인프라`, `데이터 자산화`가 코드 구조와 운영 구조 안에서 살아난다.