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. 이후 자동화와 확장

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