feat: Re:Link MVP 초기 구현 - 도메인/서비스/프론트엔드 전체

- 모노레포 구조 (Turborepo + pnpm): @relink/domain, @relink/shared, @relink/infrastructure, @relink/database, @relink/web
- 도메인 레이어: 매장(store), 매칭(matching), 업체(vendor), 보조금(subsidy), 계약/에스크로(contract) TDD 완료 (158 단위 테스트)
- 서비스 레이어: 전 도메인 서비스 함수 + 통합 테스트 (58 테스트)
- 프론트엔드: Next.js 15 App Router, 13개 페이지 (사용자 6 + 관리자 7)
- 인프라: PostgreSQL 16 + PostGIS, Prisma ORM, Docker Compose, AuditLog + OutboxEvent 패턴
- .env 파일 포함 (로컬 개발 기본값만 포함, 실제 시크릿 없음)

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/policies/contract-escrow-policy.md

@@ -0,0 +1,585 @@
+# Re:Link 계약-에스크로-분쟁 정책서
+
+> 문서 버전: 1.0.0
+> 기준일: 2026-03-07
+> 적용 범위: Re:Link MVP Phase 1
+> DRI: 대표 (제품 정책), FINANCE_OPERATOR (정산 실행), TRUST_OPERATOR (계약·검수·분쟁)
+
+---
+
+## 목적
+
+이 문서는 Re:Link 플랫폼에서 계약 생성, 전자서명 증적 수집, 에스크로 결제, 검수 절차, 정산 해제, 분쟁 처리, 환불, 수동 보정에 관한 운영 기준을 정의한다. 모든 개발 구현과 운영 의사결정은 이 문서를 최우선 기준으로 삼는다.
+
+---
+
+## 1. 계약 생성 규칙
+
+### 1-1. 계약 생성 전제조건
+
+계약은 아래 조건이 모두 충족된 경우에만 생성할 수 있다.
+
+| 조건 | 설명 |
+|------|------|
+| 매칭 요청 상태 | `MatchRequest.status = ACCEPTED` 상태여야 한다. `PENDING`, `REVIEWING`, `REJECTED`, `EXPIRED` 상태에서는 계약 생성이 불가능하다. |
+| 폐업자 계정 상태 | 계약 당사자인 폐업자의 계정이 활성 상태여야 한다. |
+| 업체 인증 상태 | 계약 상대방 업체의 `VendorCertification.status = APPROVED` 상태여야 한다. 인증이 유효하지 않거나 `SUSPENDED` 상태인 업체와는 계약을 생성할 수 없다. |
+| 매장 상태 | 해당 매장의 상태가 `CONTRACTED` 전환이 허용된 상태 (`MATCHING` 또는 `RESERVED`)여야 한다. |
+| 중복 계약 없음 | 동일한 `matchRequestId`로 이미 `DRAFT` 이상의 계약이 존재하면 신규 생성이 불가능하다. |
+
+계약 생성은 매칭 수락 시 시스템이 자동으로 시작하거나, 운영자가 운영 콘솔에서 수동으로 개시할 수 있다.
+
+### 1-2. 계약 유형별 참여자 구성
+
+계약 유형은 `Contract.contractType` 필드로 구분하며, 유형에 따라 계약 당사자와 역할이 달라진다.
+
+| 계약 유형 | 코드 | 폐업자 역할 | 상대방 역할 | 계약 목적 |
+|----------|------|------------|------------|----------|
+| 시설 인수 | `ACQUISITION` | 양도인 (매도인) | 창업자 (양수인) | 영업시설, 비품, 권리금 일부 양도 |
+| 철거 용역 | `DEMOLITION` | 의뢰인 | 철거업체 (수급인) | 내부 시설 및 설비 철거 용역 |
+| 인테리어 공사 | `INTERIOR` | 의뢰인 또는 창업자 | 인테리어업체 (수급인) | 매장 인테리어 공사 용역 |
+
+MVP에서 `INTERIOR` 계약의 의뢰인이 창업자인 경우, 폐업자는 계약 당사자가 아니며 매장 상태 전환에만 연동된다.
+
+### 1-3. 템플릿 코드와 버전 관리 원칙
+
+- 계약서는 반드시 `Contract.templateCode`로 지정된 표준 템플릿을 기반으로 생성한다. 임의로 작성한 계약서를 직접 업로드하여 계약 효력을 부여하는 것은 MVP에서 허용하지 않는다.
+- 템플릿은 계약 유형별로 구분하며, 법무 검토를 통과한 버전만 유효 템플릿으로 등록한다.
+- 계약 생성 시점에 사용된 템플릿 버전은 `ContractVersion.versionNo`에 고정 기록한다. 이후 템플릿이 개정되어도 기존 계약에 소급 적용하지 않는다.
+- 템플릿 개정이 발생하면 신규 `templateCode` 또는 버전 번호를 부여하고, 개정 이력과 유효 기간을 별도 마스터 테이블에 관리한다.
+- 법무 검토가 완료되지 않은 템플릿은 `feature flag: contract_template_draft` 뒤에 두고 운영 환경에 노출하지 않는다.
+
+### 1-4. 계약서 문서 해시 저장과 무결성 검증
+
+- 계약서 문서는 생성 즉시 객체 스토리지에 저장하고 `ContractVersion.documentStorageKey`에 경로를 기록한다.
+- 저장 완료 시 문서 전체에 대한 SHA-256 해시를 계산하여 `ContractVersion.documentSha256`에 저장한다.
+- 서명 완료 이후 계약서 문서에 변조가 의심되는 경우, 저장된 해시와 현재 파일의 해시를 대조하여 무결성을 검증한다.
+- 계약 문서는 계약 종료 후에도 법적 보존 의무 기간(최소 5년) 동안 삭제하지 않는다. 보존 기간은 법무 검토 결과를 우선 적용한다.
+
+### 1-5. 계약 상태 전이
+
+```
+DRAFT -> GENERATED -> SIGNING -> SIGNED -> IN_PROGRESS -> COMPLETED
+                                                       -> CANCELLED
+```
+
+| 전이 | 조건 | 실행 주체 |
+|------|------|----------|
+| `DRAFT -> GENERATED` | 템플릿 렌더링 및 문서 저장 완료 | 시스템 자동 |
+| `GENERATED -> SIGNING` | 계약 당사자에게 서명 요청 발송 | 시스템 자동 |
+| `SIGNING -> SIGNED` | 양측 서명 완료 | 시스템 자동 (서명 증적 수집 후) |
+| `SIGNED -> IN_PROGRESS` | 에스크로 결제 완료 | 시스템 자동 |
+| `IN_PROGRESS -> COMPLETED` | 에스크로 정산 해제 완료 | 운영자 승인 후 시스템 |
+| `IN_PROGRESS -> CANCELLED` | 분쟁 해결 결과가 전액 환불인 경우, 또는 운영자 판단 | 운영자 직접 |
+| `SIGNING -> CANCELLED` | 서명 기한 초과 (기본 7일) | 시스템 자동 또는 운영자 |
+
+---
+
+## 2. 서명 증적 규칙
+
+### 2-1. 전자서명 증적에 반드시 포함해야 할 정보
+
+모든 서명 행위는 `SignatureEvidence` 레코드로 저장한다. 아래 항목은 누락 없이 수집해야 한다.
+
+| 항목 | 필드 | 설명 |
+|------|------|------|
+| 서명자 식별자 | `userId` | 서명한 사용자의 내부 ID |
+| 서명자 역할 | `signerRole` | 계약 내 역할 (예: `TRANSFEROR`, `TRANSFEREE`, `CLIENT`, `CONTRACTOR`) |
+| 서명 시각 | `signedAt` | 서명이 완료된 UTC 타임스탬프 (밀리초 단위) |
+| 서명 IP | `ipAddress` | 서명 요청이 전송된 클라이언트 IP 주소 |
+| User-Agent | `userAgent` | 서명에 사용된 브라우저/기기 정보 |
+| 문서 버전 | `contractVersionId` | 서명 당시 적용된 `ContractVersion`의 ID |
+| 문서 해시 | `documentHash` | 서명 당시 문서의 SHA-256 해시 (저장 해시와 일치 여부 검증용) |
+| 증적 유형 | `evidenceType` | 서명 방식 코드 (아래 참조) |
+| 제공자 코드 | `providerCode` | 서명 기술 제공자 (예: `RELINK_CHECKBOX`, `KAKAOPAY_SIGN`) |
+| 서명 해시 | `signatureHash` | 서명 행위 자체에 대한 해시 (재현 가능한 증적) |
+
+### 2-2. MVP 서명 방식
+
+MVP에서는 법적 요건을 충족하는 최소 증적을 수집하는 체크박스 동의 방식으로 시작한다.
+
+**MVP 서명 방식 (evidenceType: `CHECKBOX_CONSENT`)**
+
+1. 사용자가 계약서 전문을 화면에서 열람한다. 열람 이벤트와 스크롤 완료 여부를 기록한다.
+2. "본 계약서의 내용을 확인하였으며 동의합니다" 체크박스를 선택한다.
+3. 선택 시점의 타임스탬프, IP, User-Agent, 문서 버전, 문서 해시를 수집하여 `SignatureEvidence`를 생성한다.
+4. 사용자에게 서명 완료 확인 이메일 또는 알림톡을 발송하고 발송 기록을 저장한다.
+
+**MVP 이후 확장 계획**
+
+| 단계 | 방식 | 조건 |
+|------|------|------|
+| Phase 1 (MVP) | 체크박스 동의 + 메타데이터 저장 | 현재 적용 |
+| Phase 1.5 | 카카오페이 전자서명 | 카카오페이 전자서명 API 계약 완료 후 |
+| Phase 2 | 공인전자서명 (PASS 등) | 법무 검토 및 거래 규모 기준 충족 시 |
+
+서명 방식이 확장될 때 기존 `CHECKBOX_CONSENT` 서명의 법적 효력에 영향을 주지 않는다. 확장 방식은 신규 계약부터 적용한다.
+
+### 2-3. 양측 서명 완료 시 계약 상태 전이
+
+- 계약에 참여하는 모든 역할의 `SignatureEvidence`가 수집된 시점에 계약 상태를 `SIGNING -> SIGNED`로 전환한다.
+- 단방향 서명(한쪽만 완료)은 서명 완료로 인정하지 않는다.
+- 서명 만료 기간은 계약 생성 후 7일로 설정한다. 기간 내에 양측 서명이 완료되지 않으면 시스템이 `SIGNING -> CANCELLED`로 전환하고 관련자에게 알림을 발송한다.
+- 만료된 계약을 재활성화하려면 운영자가 새 계약을 수동으로 생성해야 한다.
+
+---
+
+## 3. 에스크로 결제 규칙
+
+### 3-1. 결제 시점
+
+에스크로 결제는 아래 조건이 모두 충족된 직후에 개시한다.
+
+- `Contract.status = SIGNED` (양측 서명 완료)
+- 모든 당사자의 `SignatureEvidence`가 유효한 상태로 저장됨
+- 계약 금액이 0원 초과
+
+결제 요청은 계약 서명 완료 이벤트가 발생한 즉시 결제 페이지로 안내하거나, 사용자 확인 단계를 거친 후 PG사에 결제 요청을 보낸다.
+
+### 3-2. 에스크로 상태 전환 규칙
+
+```
+NOT_STARTED -> DEPOSIT_PENDING -> HOLDING -> RELEASE_REVIEW -> RELEASED
+                                                             -> REFUNDED
+                          HOLDING -> DISPUTED
+                    RELEASE_REVIEW -> DISPUTED
+```
+
+| 상태 전이 | 조건 | 전환 가능 주체 |
+|----------|------|--------------|
+| `NOT_STARTED -> DEPOSIT_PENDING` | 결제 요청 발송 | 시스템 자동 |
+| `DEPOSIT_PENDING -> HOLDING` | PG 결제 성공 웹훅 수신 및 idempotency 검증 완료 | 시스템 자동 (웹훅 처리) |
+| `DEPOSIT_PENDING -> NOT_STARTED` | PG 결제 실패 또는 취소 웹훅 수신 | 시스템 자동 |
+| `HOLDING -> RELEASE_REVIEW` | 검수 승인 완료 (`InspectionRecord.status = APPROVED`) | 시스템 자동 |
+| `RELEASE_REVIEW -> RELEASED` | 운영자 정산 승인 | `TRUST_OPERATOR`, `FINANCE_OPERATOR`, `SUPER_ADMIN` |
+| `RELEASE_REVIEW -> REFUNDED` | 운영자 전액 환불 결정 | `FINANCE_OPERATOR`, `SUPER_ADMIN` |
+| `HOLDING -> DISPUTED` | 분쟁 접수 완료 | 시스템 자동 (분쟁 접수 즉시) |
+| `RELEASE_REVIEW -> DISPUTED` | 정산 검토 중 분쟁 접수 | 시스템 자동 |
+| `DISPUTED -> RELEASED` | 분쟁 해결 결과 `FULL_RELEASE` 또는 `NEGOTIATED` (정산 포함) | 운영자 분쟁 해결 처리 |
+| `DISPUTED -> REFUNDED` | 분쟁 해결 결과 `FULL_REFUND` | 운영자 분쟁 해결 처리 |
+
+모든 상태 전환 시 `AuditLog`와 `EventLog`를 동시에 기록한다.
+
+### 3-3. PG 웹훅 처리 원칙
+
+**idempotency 보장**
+
+- 모든 PG 웹훅은 `EscrowTransaction.idempotencyKey`를 기준으로 중복 처리를 방지한다.
+- 동일한 `idempotencyKey`로 이미 처리된 웹훅이 재수신되면 성공 응답을 반환하되 상태 변경은 실행하지 않는다.
+- `idempotencyKey`는 PG 거래 ID와 이벤트 유형을 조합하여 생성한다.
+
+**재시도 정책**
+
+- PG 웹훅 수신 실패 시 자동 재시도를 지원한다. 재시도는 지수 백오프(Exponential Backoff) 방식으로 최대 5회 시도한다.
+- 재시도 간격: 1분 -> 5분 -> 15분 -> 1시간 -> 4시간
+- 5회 모두 실패한 경우 `FINANCE_OPERATOR`에게 알림을 발송하고 수동 처리 큐에 등록한다.
+
+**실패 처리**
+
+- 웹훅 처리 중 내부 오류가 발생한 경우 PG에 오류 응답(5xx)을 반환하여 PG의 재전송을 유도한다.
+- 내부 오류 발생 시 관련 정보를 구조화 로그로 남기고 Sentry에 오류를 전송한다.
+- 웹훅 원문 페이로드는 전체를 보관하여 이후 재처리(replay)가 가능하도록 한다.
+
+**검증 원칙**
+
+- 수신된 웹훅의 서명(Signature) 또는 HMAC을 반드시 검증한다.
+- 웹훅 페이로드의 금액이 `Contract`에 기록된 계약 금액과 일치하지 않는 경우 처리를 거부하고 운영자에게 알림을 발송한다.
+
+### 3-4. 금액 단위와 통화
+
+- 모든 금액은 **대한민국 원(KRW)** 단위로 저장한다.
+- 소수점을 허용하지 않는다. 금액 계산 결과에 소수점이 발생한 경우 내림(floor) 처리한다.
+- 금액 필드는 부호 없는 정수(unsigned integer)로 저장한다. 음수 금액은 허용하지 않는다.
+- 환불 또는 공제 금액은 별도의 `EscrowTransaction` 레코드(transactionType: `REFUND` 또는 `ADJUSTMENT`)로 기록한다.
+
+---
+
+## 4. 검수 규칙
+
+### 4-1. 검수 요청 시점
+
+- 검수는 용역 계약(`DEMOLITION`, `INTERIOR`) 또는 인수 계약(`ACQUISITION`)에서 업체(수급인) 또는 창업자가 작업 완료를 주장하며 사진을 업로드할 때 시작한다.
+- 검수 요청은 `Contract.status = IN_PROGRESS` 상태에서만 접수할 수 있다.
+- 검수 요청 시 `InspectionRecord`를 생성하고 상태를 `REQUESTED`로 설정한다.
+
+### 4-2. 검수 승인 주체
+
+검수는 2단계로 진행한다.
+
+| 단계 | 승인 주체 | 역할 |
+|------|----------|------|
+| 1차 | 폐업자 (의뢰인) | 작업 결과를 육안으로 확인하고 만족 여부를 표시한다. |
+| 2차 | 운영자 (`TRUST_OPERATOR`) | 1차 승인된 검수를 최종 확인하여 기준 충족 여부를 판단한다. |
+
+- 폐업자가 1차에서 거부한 경우, 업체는 보완 작업 후 재업로드할 수 있다. 재검수는 새로운 `InspectionRecord`로 처리한다.
+- 폐업자가 7일 이내에 1차 승인 또는 거부를 하지 않은 경우, 운영자는 직접 2차 검수를 진행할 수 있다. 이 경우 운영자는 사유를 반드시 기록해야 한다.
+- 2차 운영자 승인 없이 에스크로 정산 검토 단계로 전이하지 않는다.
+
+### 4-3. 검수 사진 최소 요구사항
+
+| 항목 | 요건 |
+|------|------|
+| 작업 전 사진 | 필수. 최소 3장. 작업 대상 공간의 전체 상태를 확인할 수 있어야 한다. |
+| 작업 후 사진 | 필수. 최소 3장. 작업 완료 후 동일 각도에서 촬영한 사진이어야 한다. |
+| 주요 부위 상세 사진 | 계약 유형에 따라 추가 요구 (예: 철거의 경우 바닥/벽/배선 상태) |
+| 사진 메타데이터 | 촬영 일시(EXIF) 포함 권장. EXIF가 없는 경우 업로드 시각으로 대체. |
+| 파일 형식 | JPG, PNG, HEIC 허용. 단일 파일 최대 20MB. |
+| 위조 방지 | 업로드 시 파일 해시를 `InspectionRecord.evidencePayloadJson`에 저장. |
+
+기준 미달(사진 장수 부족, 작업 전 사진 누락 등)인 경우 시스템이 업로드를 거부하고 이유를 안내한다.
+
+### 4-4. 검수 상태 전이
+
+```
+REQUESTED -> SUBMITTED -> REVIEWING -> APPROVED
+                                    -> REJECTED
+```
+
+| 전이 | 조건 | 실행 주체 |
+|------|------|----------|
+| `REQUESTED -> SUBMITTED` | 사진 업로드 완료 및 최소 요건 충족 | 시스템 자동 |
+| `SUBMITTED -> REVIEWING` | 폐업자 1차 검토 시작 | 시스템 자동 |
+| `REVIEWING -> APPROVED` | 폐업자 1차 승인 + 운영자 2차 승인 | 2단계 각각 실행 |
+| `REVIEWING -> REJECTED` | 폐업자 또는 운영자 거부 | 해당 주체 |
+
+검수 승인 후 에스크로 상태가 `HOLDING -> RELEASE_REVIEW`로 자동 전환된다.
+
+---
+
+## 5. 정산 해제 규칙
+
+### 5-1. 정산 해제 전제조건
+
+아래 조건이 모두 충족되어야 정산 해제 절차를 시작할 수 있다.
+
+| 조건 | 설명 |
+|------|------|
+| 검수 승인 완료 | 해당 계약의 최종 `InspectionRecord.status = APPROVED` 상태여야 한다. |
+| 분쟁 없음 | 해당 계약에 `DisputeCase.status`가 `OPEN`, `INVESTIGATING`, `MEDIATING`인 건이 없어야 한다. |
+| 에스크로 상태 | `EscrowTransaction`의 에스크로 상태가 `RELEASE_REVIEW`여야 한다. |
+| 운영자 승인 | MVP에서 모든 정산은 운영자의 명시적 승인이 필요하다. 자동 정산 해제는 허용하지 않는다. |
+
+### 5-2. 운영자 승인 (MVP 원칙)
+
+MVP 기간 동안 모든 정산 해제는 `TRUST_OPERATOR`, `FINANCE_OPERATOR`, `SUPER_ADMIN` 중 한 명이 운영 콘솔에서 직접 승인해야 실행된다. 자동 정산 해제 기능은 `feature flag: auto_escrow_release` 뒤에 두고 MVP에서 비활성화 상태로 유지한다.
+
+### 5-3. 정산 금액 계산
+
+```
+정산 금액 = 계약 금액 - 플랫폼 수수료
+플랫폼 수수료 = 계약 금액 * 수수료율 (소수점 이하 내림)
+```
+
+수수료는 KRW 단위이며 소수점 이하를 내림(floor) 처리한다. 수수료 계산 결과와 정산 금액은 `EscrowTransaction` 레코드에 각각 기록한다.
+
+### 5-4. 수수료율 정의
+
+| 계약 유형 | 수수료율 | 비고 |
+|----------|---------|------|
+| `ACQUISITION` (시설 인수) | 3% | 거래 금액의 3% |
+| `DEMOLITION` (철거 용역) | 5% | 용역 금액의 5% |
+| `INTERIOR` (인테리어 공사) | 5% | 용역 금액의 5% |
+
+수수료율 변경은 운영 정책 개정 절차를 거쳐야 하며, 변경 효력은 변경 시점 이후 신규 생성 계약부터 적용한다. 기존 계약의 수수료율에 소급 적용하지 않는다.
+
+수수료율은 코드에 하드코딩하지 않고 별도 설정 테이블(`FeePolicy`)에 관리한다.
+
+### 5-5. 정산 실행 후 상태 전이
+
+정산 승인이 완료되면 아래 상태가 순차적으로 전환된다.
+
+1. `EscrowTransaction` 에스크로 상태: `RELEASE_REVIEW -> RELEASED`
+2. 실제 출금 처리: PG사 또는 수동 정산 방식으로 업체 계좌에 정산 금액 송금
+3. `Contract.status`: `IN_PROGRESS -> COMPLETED`
+4. `Store.status`: `CONTRACTED -> CLOSED` (해당되는 경우)
+5. `EventLog`: `escrow_released`, `transaction_completed` 이벤트 기록
+
+PG 출금 API 호출 실패 시 에스크로 상태를 `RELEASE_REVIEW`로 복귀하고 `FINANCE_OPERATOR`에게 알림을 발송한다.
+
+---
+
+## 6. 분쟁 처리 규칙
+
+### 6-1. 분쟁 접수 가능 시점
+
+분쟁은 아래 조건에서만 접수할 수 있다.
+
+- 에스크로 상태가 `HOLDING` 또는 `RELEASE_REVIEW`인 상태
+- 계약 상태가 `IN_PROGRESS`인 상태
+- 동일 계약에 이미 `OPEN`, `INVESTIGATING`, `MEDIATING` 상태의 분쟁 건이 없는 경우
+
+분쟁 접수 주체는 계약 당사자(폐업자, 창업자, 업체) 또는 운영자가 될 수 있다.
+
+### 6-2. 분쟁 사유 코드
+
+| 코드 | 설명 |
+|------|------|
+| `QUALITY_ISSUE` | 작업 품질이 계약 기준을 충족하지 못함 |
+| `SCOPE_DIFFERENCE` | 실제 작업 범위가 계약서 내용과 다름 |
+| `TIMELINE_BREACH` | 계약에서 정한 작업 기간을 초과함 |
+| `DAMAGE` | 작업 중 발생한 시설 또는 비품 파손 |
+| `INCOMPLETE_WORK` | 작업이 완전히 완료되지 않은 채 검수 요청됨 |
+| `OTHER` | 위 항목에 해당하지 않는 기타 사유 |
+
+`OTHER` 선택 시 사유 텍스트 입력을 필수로 요구한다.
+
+### 6-3. 분쟁 발생 시 에스크로 자동 보류
+
+분쟁이 접수되면 시스템은 즉시 아래 처리를 실행한다.
+
+1. `DisputeCase.status = OPEN`으로 생성
+2. 에스크로 상태를 `DISPUTED`로 전환 (단, PG 자금은 실제 동결 상태를 유지)
+3. 자동 정산 해제 프로세스가 중단됨
+4. 계약 당사자 전원 및 `TRUST_OPERATOR`에게 분쟁 접수 알림 발송
+5. 분쟁 건이 운영자 처리 큐에 등록됨
+
+분쟁이 접수된 상태에서 정산을 임의로 해제하는 것은 불가능하다. 정산을 재개하려면 반드시 분쟁 해결 절차를 완료해야 한다.
+
+### 6-4. 운영자 조사 및 중재 프로세스
+
+| 단계 | 상태 | 주요 활동 | 담당 역할 |
+|------|------|----------|----------|
+| 접수 | `OPEN` | 분쟁 내용 확인, 당사자 진술 수집 요청 | `TRUST_OPERATOR` |
+| 조사 | `INVESTIGATING` | 계약서, 검수 사진, 커뮤니케이션 이력 검토, 추가 증빙 요청 | `TRUST_OPERATOR` |
+| 중재 | `MEDIATING` | 당사자에게 조정안 제시 및 수락 여부 확인 | `TRUST_OPERATOR`, `OPS_MANAGER` |
+| 해결 | `RESOLVED` | 해결 방식과 사유 기록, 후속 정산 또는 환불 처리 | `TRUST_OPERATOR`, `FINANCE_OPERATOR` |
+| 종료 | `CLOSED` | 분쟁 건 최종 종료 (합의 또는 해결 불가 종료 포함) | `TRUST_OPERATOR` |
+
+- 분쟁 접수 후 2영업일 이내에 운영자가 조사를 시작해야 한다.
+- 조사 기간은 최대 10영업일로 한다. 기간 내 해결이 어려운 경우 당사자에게 사유를 안내하고 기간을 연장할 수 있다.
+- 모든 조사 및 중재 단계에서 운영자의 메모와 사유 코드를 `DisputeCase`에 기록한다.
+
+### 6-5. 분쟁 해결 유형
+
+| 해결 코드 | 설명 | 정산 처리 |
+|----------|------|----------|
+| `FULL_RELEASE` | 분쟁 기각, 정산 정상 진행 | 전액 정산 해제 |
+| `PARTIAL_REFUND` | 일부 환불 후 나머지 정산 | 환불액과 정산액을 분리하여 각각 처리 |
+| `FULL_REFUND` | 전액 환불 | 업체에 정산 없음, 의뢰인에게 전액 환불 |
+| `NEGOTIATED` | 당사자 합의 도달 | 합의 내용에 따라 정산 및 환불 처리 |
+
+분쟁 해결 유형(`DisputeCase.resolutionCode`)과 해결 요약(`resolutionSummary`)은 반드시 기록해야 한다. 기록 없이 분쟁 상태를 `RESOLVED`로 전환할 수 없다.
+
+### 6-6. 분쟁 해결 후 정산 처리
+
+분쟁 해결 시 정산 처리는 아래 순서로 진행한다.
+
+1. 운영자가 `DisputeCase`의 해결 코드와 금액(환불액, 정산액)을 기록
+2. `DisputeCase.status = RESOLVED`로 전환
+3. 에스크로 상태를 해결 방식에 따라 `RELEASED` 또는 `REFUNDED`로 전환
+4. `PARTIAL_REFUND`의 경우 환불 `EscrowTransaction`과 정산 `EscrowTransaction`을 각각 생성
+5. PG 또는 수동 방식으로 환불 및 정산 실행
+6. 계약 상태 전환: `IN_PROGRESS -> COMPLETED` 또는 `CANCELLED`
+
+---
+
+## 7. 환불 규칙
+
+### 7-1. 환불 가능 사유
+
+환불은 아래 사유에 해당하는 경우에만 진행할 수 있다.
+
+| 사유 | 설명 | 처리 방식 |
+|------|------|----------|
+| 분쟁 해결 결과 환불 | `DisputeCase.resolutionCode`가 `FULL_REFUND` 또는 `PARTIAL_REFUND` | 분쟁 해결 절차 완료 후 처리 |
+| 계약 서명 전 취소 | `Contract.status = SIGNING` 이전 취소 | 자동 환불 (PG 취소) |
+| 업체 귀책 철수 | 업체가 계약을 이행하지 않고 철수한 경우 운영자 판단 | 운영자 승인 후 전액 환불 |
+| 매장 사정으로 인한 계약 불능 | 폐업자의 불가피한 사유로 계약 진행 불가 | 운영자 검토 후 전액 또는 부분 환불 |
+| 기타 운영 판단 | 서비스 오류, 플랫폼 귀책 등 | `SUPER_ADMIN` 또는 `FINANCE_OPERATOR` 승인 |
+
+환불은 **원칙적으로 전액 또는 부분**으로만 처리하며, 계약 금액을 초과하는 환불은 허용하지 않는다.
+
+### 7-2. 환불 금액 계산
+
+| 환불 유형 | 계산 방식 |
+|----------|----------|
+| 전액 환불 | 에스크로에 입금된 원금 전액 반환. 플랫폼 수수료를 환불 금액에서 공제하지 않는다. |
+| 부분 환불 | 운영자가 환불액을 직접 지정. 나머지는 업체에 정산. 환불액 + 정산액 = 계약 금액. |
+
+수수료 환급 여부:
+- 업체 귀책 또는 플랫폼 귀책의 경우: 수수료 전액 환급
+- 의뢰인 단순 변심 또는 의뢰인 귀책의 경우: 수수료 비환급 (단, MVP에서는 운영자 재량 허용)
+
+### 7-3. 환불 운영자 승인 필수
+
+모든 환불은 `FINANCE_OPERATOR` 또는 `SUPER_ADMIN`의 명시적 승인이 필요하다. 시스템이 자동으로 환불을 실행하는 경우는 계약 서명 전 PG 취소 건에 한한다.
+
+환불 승인 시 아래 정보를 반드시 기록한다.
+
+- 환불 사유 코드
+- 환불 금액 (전액 또는 부분)
+- 승인자 ID
+- 승인 시각
+- 운영 메모
+
+### 7-4. 환불 후 계약 상태 전이
+
+| 환불 유형 | 계약 상태 전이 | 에스크로 상태 전이 |
+|----------|--------------|-----------------|
+| 전액 환불 | `IN_PROGRESS -> CANCELLED` | `DISPUTED -> REFUNDED` 또는 `RELEASE_REVIEW -> REFUNDED` |
+| 부분 환불 | `IN_PROGRESS -> COMPLETED` | `DISPUTED -> RELEASED` (정산 완료 후) |
+| 서명 전 취소 | `SIGNING -> CANCELLED` | `DEPOSIT_PENDING -> NOT_STARTED` |
+
+---
+
+## 8. 운영자 수동 보정 규칙
+
+### 8-1. 수동 보정이 필요한 상황
+
+수동 보정은 시스템이 자동으로 처리할 수 없는 예외 상황에서만 실행한다.
+
+- PG 웹훅 수신 실패로 인한 에스크로 상태 불일치
+- 분쟁 해결 후 부분 환불 금액의 수동 분배
+- 계약 금액 오류 정정 (계약 생성 단계의 시스템 오류)
+- 운영자 판단에 의한 에스크로 보류 또는 해제
+- 기타 정산 이상 건 처리
+
+### 8-2. 수동 보정 가능 주체
+
+| 작업 | 허용 역할 |
+|------|----------|
+| 에스크로 상태 수동 전환 | `TRUST_OPERATOR`, `FINANCE_OPERATOR`, `SUPER_ADMIN` |
+| 정산 금액 수동 보정 | `FINANCE_OPERATOR`, `SUPER_ADMIN` |
+| 환불 금액 수동 결정 | `FINANCE_OPERATOR`, `SUPER_ADMIN` |
+| 계약 상태 수동 전환 | `TRUST_OPERATOR`, `SUPER_ADMIN` |
+| 수수료 면제 처리 | `SUPER_ADMIN` |
+
+`OPS_MANAGER`와 `SUBSIDY_OPERATOR`는 계약-에스크로-정산 영역의 수동 보정 권한을 갖지 않는다.
+
+### 8-3. 수동 보정 시 필수 기록 항목
+
+수동 보정 실행 전 아래 정보를 입력하지 않으면 보정을 진행할 수 없다.
+
+| 항목 | 설명 |
+|------|------|
+| 보정 사유 코드 | 미리 정의된 코드 중 선택 (예: `WEBHOOK_FAILURE`, `DISPUTE_RESOLUTION`, `CONTRACT_ERROR`, `OPERATOR_OVERRIDE`) |
+| 보정 전 상태 | 변경 전 에스크로 상태 또는 금액 (시스템이 자동 캡처) |
+| 보정 후 상태 | 변경 후 예상 상태 또는 금액 |
+| 운영 메모 | 보정 배경과 판단 근거를 서술 (최소 20자 이상) |
+| 관련 문서 또는 링크 | 분쟁 건 ID, 채팅 스레드 ID, 외부 근거 링크 등 |
+
+### 8-4. AuditLog 필수 기록
+
+모든 수동 보정은 `AuditLog`에 아래 정보를 반드시 기록한다.
+
+| 필드 | 내용 |
+|------|------|
+| `actorId` | 보정을 실행한 운영자 ID |
+| `actorRole` | 운영자 역할 |
+| `targetEntity` | 보정 대상 엔티티 (예: `EscrowTransaction`, `Contract`) |
+| `targetId` | 보정 대상의 ID |
+| `action` | 수행한 작업 코드 |
+| `beforeState` | 변경 전 상태 (JSON 스냅샷) |
+| `afterState` | 변경 후 상태 (JSON 스냅샷) |
+| `reasonCode` | 보정 사유 코드 |
+| `memo` | 운영 메모 |
+| `occurredAt` | 보정 실행 시각 |
+
+`AuditLog` 기록은 삭제하거나 수정할 수 없다. 감사 로그는 최소 7년간 보존한다.
+
+---
+
+## 9. Feature Flag 규칙
+
+### 9-1. MVP Feature Flag 목록
+
+MVP Phase 1에서 아래 기능은 feature flag 뒤에 두고 기본값은 비활성화(`false`) 상태로 유지한다.
+
+| Flag 이름 | 기능 설명 | MVP 기본값 | 활성화 조건 |
+|----------|----------|----------|------------|
+| `contract_template_draft` | 법무 검토 미완료 템플릿 사용 허용 | `false` | 법무 검토 완료 후 `true`로 전환 |
+| `auto_escrow_release` | 검수 승인 후 운영자 승인 없이 자동 정산 해제 | `false` | 정산 운영 안정화 확인 후 단계적 활성화 |
+| `kakao_sign_enabled` | 카카오페이 전자서명 사용 | `false` | 카카오페이 전자서명 API 계약 완료 후 |
+| `partial_refund_ui` | 부분 환불 UI 운영 콘솔 노출 | `true` | MVP 출시 시 활성화. 단, 실행은 `FINANCE_OPERATOR` 이상만 가능. |
+| `dispute_auto_hold` | 분쟁 접수 시 에스크로 자동 보류 | `true` | MVP 출시 시 활성화. 비활성화 금지. |
+| `inspection_photo_min` | 검수 사진 최소 요건 강제 검증 | `true` | MVP 출시 시 활성화. |
+| `fee_policy_override` | 개별 계약 수수료율 수동 오버라이드 | `false` | `SUPER_ADMIN` 필요 시 개별 활성화 |
+| `vendor_auto_contract` | 업체 인증 승인 즉시 계약 생성 자동화 | `false` | 운영 안정화 후 검토 |
+
+### 9-2. Feature Flag 운영 원칙
+
+- Feature flag 값의 변경은 `SUPER_ADMIN`만 실행할 수 있다.
+- Flag 변경 시 변경자 ID, 변경 시각, 이전 값, 이후 값, 사유를 `AuditLog`에 기록한다.
+- `dispute_auto_hold`와 `inspection_photo_min`은 운영 안전을 위해 비활성화를 원칙적으로 금지한다. 비활성화가 필요한 경우 대표와 CTO의 동시 승인이 필요하다.
+- Feature flag는 환경별(개발/스테이징/운영)로 독립적으로 관리한다. 스테이징에서 활성화한 flag가 운영 환경에 자동으로 적용되지 않는다.
+
+---
+
+## 10. 계약-에스크로 흐름 전체 요약
+
+```
+[매칭 수락]
+    |
+    v
+[계약 생성 (DRAFT -> GENERATED)]
+    |
+    v
+[서명 요청 발송 (SIGNING)]
+    |
+[양측 서명 완료]
+    |
+    v
+[계약 SIGNED / 에스크로 DEPOSIT_PENDING]
+    |
+[PG 결제 완료 웹훅]
+    |
+    v
+[에스크로 HOLDING / 계약 IN_PROGRESS]
+    |
+    +--[분쟁 접수]---> [에스크로 DISPUTED / DisputeCase OPEN]
+    |                       |
+    |                  [조사/중재]
+    |                       |
+    |                  [해결 유형 결정]
+    |                       |
+    |           +-----------+-----------+
+    |           |           |           |
+    |      [FULL_RELEASE] [PARTIAL] [FULL_REFUND]
+    |           |           |           |
+    |           v           v           v
+    |       [RELEASED]  [RELEASED  [REFUNDED]
+    |                   +REFUNDED]
+    |
+    v
+[검수 요청 (REQUESTED -> SUBMITTED -> REVIEWING)]
+    |
+[폐업자 1차 승인 + 운영자 2차 승인]
+    |
+    v
+[에스크로 RELEASE_REVIEW]
+    |
+[운영자 정산 승인]
+    |
+    v
+[에스크로 RELEASED / 계약 COMPLETED]
+```
+
+---
+
+## 부록 A. 관련 운영 역할 요약
+
+| 역할 | 계약 | 에스크로 | 검수 | 분쟁 | 정산 | 환불 | 수동 보정 |
+|------|------|---------|------|------|------|------|----------|
+| `SUPER_ADMIN` | O | O | O | O | O | O | O |
+| `TRUST_OPERATOR` | O | 보류/해제 | O | O | - | - | 상태 전환 |
+| `FINANCE_OPERATOR` | - | 정산/환불 | - | 정산 | O | O | 금액 보정 |
+| `OPS_MANAGER` | 조회 | 조회 | - | 중재 지원 | - | - | - |
+| `SUBSIDY_OPERATOR` | - | - | - | - | - | - | - |
+
+---
+
+## 부록 B. 주요 용어 정의
+
+| 용어 | 정의 |
+|------|------|
+| 에스크로 | 거래 대금을 제3자(PG사 또는 플랫폼)가 보관하다가 조건 충족 시 수령인에게 지급하는 결제 방식 |
+| 정산 해제 | 에스크로에 보관된 금액을 수급인(업체)에게 지급하는 행위 |
+| 검수 | 용역 또는 거래 완료 여부를 사진 및 현장 확인을 통해 검증하는 절차 |
+| 분쟁 | 계약 당사자 간 계약 이행 관련 이의 제기 |
+| 수동 보정 | 시스템 자동화 범위 밖의 예외 상황에서 운영자가 직접 상태 또는 금액을 변경하는 행위 |
+| idempotency | 동일한 요청이 여러 번 실행되어도 결과가 동일하게 유지되는 성질 |
+| AuditLog | 운영자 및 시스템의 모든 상태 변경 이력을 변경 불가 형태로 기록하는 감사 로그 |
+
+---
+
+*이 문서는 Re:Link MVP 운영 기준 문서이며, 구현 코드보다 이 문서가 우선합니다. 정책 변경이 필요한 경우 이 문서를 먼저 개정하고 개정 이력을 기록한 뒤 코드 구현에 반영합니다.*

docs/policies/data-exposure-policy.md

@@ -0,0 +1,500 @@
+# 폐업 정보 공개 정책서
+
+> Re:Link MVP — 정보 공개 기준 및 역할별 열람 권한 정책
+> 문서 버전: v1.0.0
+> 최초 작성: 2026-03-07
+> 적용 범위: Phase 1 MVP 전체, Phase 2 데이터 구조 준비 포함
+> DRI: 대표 (정책), CTO (기술 구현)
+
+---
+
+## 목차
+
+1. [정보 공개 등급 체계](#1-정보-공개-등급-체계)
+2. [역할별 열람 범위 매트릭스](#2-역할별-열람-범위-매트릭스)
+3. [데이터 항목별 공개 등급 분류](#3-데이터-항목별-공개-등급-분류)
+4. [공개 시점 규칙](#4-공개-시점-규칙)
+5. [동의 체계](#5-동의-체계)
+6. [열람 이력 기록](#6-열람-이력-기록)
+7. [API 응답 필터링 원칙](#7-api-응답-필터링-원칙)
+8. [개인정보보호법 준수](#8-개인정보보호법-준수)
+
+---
+
+## 1. 정보 공개 등급 체계
+
+Re:Link는 폐업자의 민감한 정보를 보호하면서 거래 목적에 맞는 정보만 단계적으로 공개하는 4단계 등급 체계를 운영한다. 폐업 등록 즉시 모든 정보가 공개되지 않으며, 매칭 진행 상황과 역할에 따라 정보 접근이 제한적으로 확대된다.
+
+### 1-1. 등급 정의
+
+| 등급 | 코드 | 열람 대상 | 목적 |
+|------|------|-----------|------|
+| 공개 요약 | `PUBLIC_SUMMARY` | 인증 여부 무관, 접근 가능한 모든 사용자 | 매장 탐색 및 관심 유도 |
+| 제한 공개 | `RESTRICTED` | 역할 인증이 완료된 플랫폼 회원 | 매칭 의사결정을 위한 상세 정보 제공 |
+| 매칭 전용 | `MATCHED_ONLY` | 매칭 수락이 완료된 당사자 양측 | 실제 거래 진행에 필요한 연락 및 계약 정보 |
+| 내부 전용 | `INTERNAL` | 운영자 및 시스템 자동 처리 | 감사, 컴플라이언스, 내부 운영 |
+
+### 1-2. 등급별 상세 기준
+
+#### PUBLIC_SUMMARY — 공개 요약
+
+누구나 볼 수 있는 비식별화된 요약 정보다. 상세 주소 대신 지역 클러스터 단위(예: 역삼·선릉권)를 표시하며, 임대 금액 대신 범위(예: 보증금 1억~2억대)만 표시한다.
+
+- 포함: 지역 클러스터, 업종 분류, 전용면적 범위, 대표 사진 1장, 폐업 예정 시기 범위(월 단위), 시설 키워드(예: 주방 있음, 덕트 있음)
+- 제외: 정확한 주소, 동호수, 연락처, 정확한 임대 금액, 폐업 사유, 소유자 개인정보
+
+#### RESTRICTED — 제한 공개
+
+역할 인증이 완료된 플랫폼 회원에게 공개하는 상세 정보다. 거래 의향을 판단할 수 있는 수준의 정보를 제공하되, 직접 연락은 불가능하다.
+
+- 포함: 시설 상세(전용면적 정확값, 좌석 수, 설비 목록, 층수, 주차), 임대 조건 개요(보증금·월세·권리금 정확값, 잔여 임대기간), 내부 사진 전체, 폐업 예정일(일 단위), 폐업 사유 유형(경영악화/임대만료/이전 등 분류 수준), 인수 가능일
+- 제외: 상세 주소(동호수), 소유자 연락처, 임대인 정보, 사업자등록 번호
+
+#### MATCHED_ONLY — 매칭 전용
+
+매칭 요청이 수락되어 계약 절차가 시작된 당사자 양측에게만 공개하는 정보다. 이 단계부터 직접 연락과 현장 방문이 가능하다.
+
+- 포함: 상세 주소(동호수 포함), 소유자 연락처(전화, 이메일), 임대인 정보(운영자 중개 시), 사업자등록번호(계약 목적), 추가 현장 사진 및 도면, 임대차 계약서 사본(운영자 검토 후 제공)
+- 제외: 정부 지원금 수령 정보, 세금 관련 내부 메모, 타 매칭 이력
+
+#### INTERNAL — 내부 전용
+
+운영자와 시스템만 접근 가능한 정보다. 외부에 절대 노출되어서는 안 되며, 접근 시마다 감사 로그가 생성된다.
+
+- 포함: 운영자 내부 메모, 반려 사유 상세, 검토 히스토리, 개인정보 원본(주민등록번호 등), 정부 지원금 수령 내역 및 금액, 세금계산서 정보, 분쟁 처리 내부 기록, 시스템 감사 로그 전체, 법적 처리 관련 서류
+
+---
+
+## 2. 역할별 열람 범위 매트릭스
+
+아래 매트릭스는 각 사용자 역할이 각 공개 등급 정보를 열람할 수 있는지를 나타낸다. O는 열람 가능, X는 열람 불가, C는 조건부 열람(별도 조건 명시)을 의미한다.
+
+| 역할 | PUBLIC_SUMMARY | RESTRICTED | MATCHED_ONLY | INTERNAL |
+|------|:--------------:|:----------:|:------------:|:--------:|
+| 비인증 방문자 | O | X | X | X |
+| CLOSING_OWNER (본인 매장) | O | O | O | X |
+| CLOSING_OWNER (타인 매장) | O | X | X | X |
+| FOUNDER (창업자) | O | O | C¹ | X |
+| VENDOR_MANAGER (철거/인테리어) | O | C² | C³ | X |
+| OPS_MANAGER | O | O | O | O |
+| SUBSIDY_OPERATOR | O | O | C⁴ | C⁵ |
+| TRUST_OPERATOR | O | O | O | C⁶ |
+| FINANCE_OPERATOR | O | O | C⁷ | C⁸ |
+| SUPER_ADMIN | O | O | O | O |
+
+**조건 주석**
+
+- C¹: 창업자(FOUNDER)가 해당 매장에 대해 매칭 요청을 보내고 폐업자가 수락한 경우에만 열람 가능
+- C²: 역할 인증(업체 인증)이 완료된 VENDOR_MANAGER만 열람 가능. 미인증 업체는 PUBLIC_SUMMARY만 접근
+- C³: VENDOR_MANAGER는 철거 또는 인테리어 견적 요청이 매칭 수락된 경우에만 열람 가능. 단, 연락처는 운영자 중개 방식으로만 제공
+- C⁴: SUBSIDY_OPERATOR는 해당 매장의 지원금 케이스가 할당된 경우에만 MATCHED_ONLY 열람 가능
+- C⁵: SUBSIDY_OPERATOR는 지원금 관련 정보(INTERNAL 중 지원금 항목)만 열람 가능. 일반 내부 메모와 분쟁 기록은 접근 불가
+- C⁶: TRUST_OPERATOR는 분쟁·계약·검수 처리 목적의 INTERNAL 항목만 열람 가능. 재무 정보는 접근 불가
+- C⁷: FINANCE_OPERATOR는 결제·정산 관련 MATCHED_ONLY 정보(사업자등록번호, 계좌 정보)만 열람 가능
+- C⁸: FINANCE_OPERATOR는 세금계산서, 에스크로 거래 내역, 정산 로그만 열람 가능. 분쟁·감사 로그 전체는 접근 불가
+
+---
+
+## 3. 데이터 항목별 공개 등급 분류
+
+### 3-1. 매장 기본 정보
+
+| 항목 | 공개 등급 | 비고 |
+|------|----------|------|
+| 매장 제목 (상호 제외) | PUBLIC_SUMMARY | "역삼동 1층 카페" 형식, 상호명은 제외 |
+| 업종 분류 (대분류) | PUBLIC_SUMMARY | F&B, 소매업 등 |
+| 업종 분류 (중·세분류) | RESTRICTED | 커피전문점, 한식당 등 |
+| 지역 클러스터 | PUBLIC_SUMMARY | 구·상권 단위, 동 단위 이상은 RESTRICTED |
+| 정확한 주소 (동·번지) | RESTRICTED | |
+| 상세 주소 (호수·층·동) | MATCHED_ONLY | |
+| 상호명 | MATCHED_ONLY | 계약 및 권리금 협상 목적 |
+| 사업자등록번호 | MATCHED_ONLY | 계약 목적으로만 제공 |
+| 매장 등록 날짜 | RESTRICTED | |
+
+### 3-2. 시설 정보
+
+| 항목 | 공개 등급 | 비고 |
+|------|----------|------|
+| 전용면적 (범위, 10평 단위) | PUBLIC_SUMMARY | 예: 30~40평대 |
+| 전용면적 (정확값, ㎡·평) | RESTRICTED | |
+| 건물 층수 | RESTRICTED | |
+| 주차 가능 여부 | PUBLIC_SUMMARY | |
+| 주차 대수 | RESTRICTED | |
+| 좌석 수 (범위) | PUBLIC_SUMMARY | |
+| 좌석 수 (정확값) | RESTRICTED | |
+| 주방 설비 유무 | PUBLIC_SUMMARY | 유/무만 표시 |
+| 주방 설비 상세 | RESTRICTED | 장비 목록, 상태 |
+| 전기 용량 | RESTRICTED | |
+| 가스 공급 여부 | PUBLIC_SUMMARY | |
+| 가스 용량 및 종류 | RESTRICTED | |
+| 배수 설비 | RESTRICTED | |
+| 덕트 설비 | PUBLIC_SUMMARY | 유/무만 표시 |
+| 덕트 상세 스펙 | RESTRICTED | |
+| 냉난방 설비 | RESTRICTED | |
+| 기타 설비 목록 | RESTRICTED | |
+
+### 3-3. 임대 정보
+
+| 항목 | 공개 등급 | 비고 |
+|------|----------|------|
+| 보증금 (억 단위 범위) | PUBLIC_SUMMARY | 예: 1억~2억대 |
+| 보증금 (정확값) | RESTRICTED | |
+| 월세 (만 단위 범위) | PUBLIC_SUMMARY | 예: 200~300만 원대 |
+| 월세 (정확값) | RESTRICTED | |
+| 관리비 유무 | PUBLIC_SUMMARY | |
+| 관리비 정확값 | RESTRICTED | |
+| 권리금 존재 여부 | PUBLIC_SUMMARY | 유/무만 표시 |
+| 권리금 정확값 | RESTRICTED | |
+| 잔여 임대기간 (개월 단위 범위) | PUBLIC_SUMMARY | 예: 6~12개월 |
+| 잔여 임대기간 (정확값) | RESTRICTED | |
+| 임대차 계약 만료일 | RESTRICTED | |
+| 임대인 정보 (성명, 연락처) | MATCHED_ONLY | 운영자 중개 방식으로만 제공 |
+| 임대차 계약서 사본 | MATCHED_ONLY | 운영자 검토 후 제공 |
+
+### 3-4. 사진
+
+| 항목 | 공개 등급 | 비고 |
+|------|----------|------|
+| 대표 사진 (외관) 1장 | PUBLIC_SUMMARY | 주소 특정 불가한 앵글로 운영자 검수 |
+| 대표 사진 (내부 전경) 1장 | PUBLIC_SUMMARY | |
+| 내부 전체 사진 | RESTRICTED | |
+| 주방 설비 사진 | RESTRICTED | |
+| 외관 전체 사진 (간판 포함) | RESTRICTED | 상호 노출 포함 가능 |
+| 도면 및 평면도 | RESTRICTED | |
+| 설비 상세 사진 | RESTRICTED | |
+| 현장 추가 사진 (매칭 후 요청) | MATCHED_ONLY | |
+
+> 사진 분류 시 `StorePhoto.visibilityScope` 필드를 기준으로 서버에서 필터링하며, 사진 업로드 단계에서 폐업자가 카테고리를 지정하고 운영자가 최종 검수한다.
+
+### 3-5. 폐업 관련 정보
+
+| 항목 | 공개 등급 | 비고 |
+|------|----------|------|
+| 폐업 예정 시기 (월 단위) | PUBLIC_SUMMARY | |
+| 폐업 예정일 (일 단위) | RESTRICTED | |
+| 인수 가능일 | RESTRICTED | |
+| 철거 예정일 | RESTRICTED | |
+| 폐업 사유 유형 (경영악화/임대만료/이전 등) | RESTRICTED | 세부 사유는 INTERNAL |
+| 폐업 사유 상세 서술 | INTERNAL | |
+| 폐업 확인서 등 공문서 | INTERNAL | |
+
+### 3-6. 정부 지원금 관련 정보
+
+모든 정부 지원금 관련 정보는 INTERNAL 등급이며, SUBSIDY_OPERATOR 이상의 운영자만 접근 가능하다.
+
+| 항목 | 공개 등급 | 비고 |
+|------|----------|------|
+| 지원금 신청 자격 여부 | INTERNAL | |
+| 신청 대상 지원금 목록 | INTERNAL | |
+| 제출 서류 및 상태 | INTERNAL | |
+| 지원금 수령 금액 및 내역 | INTERNAL | |
+| 운영자 검토 메모 | INTERNAL | |
+
+> 폐업자에게는 지원금 신청 과정에서 본인의 케이스 상태(체크리스트 완료 여부, 운영자 검토 결과)는 별도 지원금 전용 화면에서 확인 가능하다. 이 화면은 공개 등급 체계와 별도로 동작하는 개인화 뷰이며, 타인에게 노출되지 않는다.
+
+### 3-7. 연락처 및 개인정보
+
+| 항목 | 공개 등급 | 비고 |
+|------|----------|------|
+| 전화번호 | MATCHED_ONLY | 운영자 중개 방식 우선 권장 |
+| 이메일 | MATCHED_ONLY | |
+| 성명 | MATCHED_ONLY | 계약 목적으로만 제공 |
+| 주민등록번호 / 생년월일 | INTERNAL | 본인확인 목적, 암호화 저장 |
+| 계좌번호 | INTERNAL | 정산 목적, 암호화 저장 |
+
+---
+
+## 4. 공개 시점 규칙
+
+매장의 `publicationStatus`와 `reviewStatus`의 조합에 따라 공개 범위가 결정된다. 공개 상태의 전환은 운영자 또는 시스템이 `AuditLog`와 함께 기록한다.
+
+### 4-1. 상태별 공개 범위
+
+| 매장 상태 | 공개 범위 | 접근 가능 역할 |
+|-----------|----------|----------------|
+| `DRAFT` | 공개 없음 | 본인(CLOSING_OWNER) + 운영자 |
+| `SUBMITTED` | 공개 없음 | 본인(CLOSING_OWNER) + 운영자 |
+| `REVIEWING` | 공개 없음 | 본인(CLOSING_OWNER) + 운영자 |
+| `APPROVED` + `PUBLISHED` | 공개 등급에 따라 역할별 노출 | 역할 매트릭스 참조 |
+| `APPROVED` + `PRIVATE` | 공개 없음 | 본인(CLOSING_OWNER) + 운영자 |
+| 매칭 수락 완료 | MATCHED_ONLY 정보 해제 | 매칭 당사자 양측 + 운영자 |
+| `UNPUBLISHED` | 기존 매칭 당사자 외 비공개 | 기존 매칭 당사자 + 운영자 |
+| `CLOSED` / `CANCELLED` | 운영자만 | 운영자 전용 |
+
+### 4-2. 공개 전환 규칙
+
+- DRAFT → SUBMITTED: 폐업자가 직접 제출. 공개 범위 변동 없음.
+- SUBMITTED → REVIEWING: 운영자가 검토 시작. 공개 범위 변동 없음.
+- REVIEWING → APPROVED: 운영자가 승인. `publicationStatus`는 여전히 `PRIVATE`이며, 폐업자가 공개 동의 후 `PUBLISHED`로 전환.
+- APPROVED + PRIVATE → APPROVED + PUBLISHED: 폐업자의 정보 공개 동의 완료 시점에 자동 전환. 이 시점부터 역할 매트릭스에 따른 공개 시작.
+- PUBLISHED → MATCHING: 매칭 요청이 수락되어도 publicationStatus는 유지. MATCHED_ONLY 정보만 추가 해제.
+- PUBLISHED → UNPUBLISHED: 폐업자 요청 또는 운영자 결정. 기존 매칭 진행 중인 당사자에게는 MATCHED_ONLY 정보 유지, 신규 접근자에게는 PUBLIC_SUMMARY도 비공개.
+
+### 4-3. MATCHED_ONLY 정보 해제 조건
+
+MATCHED_ONLY 정보는 아래 조건이 모두 충족될 때 해당 당사자에게만 해제된다.
+
+1. 매칭 요청의 상태가 `ACCEPTED`로 전환되었을 것
+2. 폐업자(CLOSING_OWNER)가 정보 공개 동의를 완료했을 것 (최초 PUBLISHED 전환 시 동의 수집)
+3. 상대방(FOUNDER 또는 VENDOR_MANAGER)이 플랫폼 이용약관과 개인정보 처리방침에 동의했을 것
+
+VENDOR_MANAGER의 경우 연락처는 운영자 중개 방식을 우선 사용하며, 운영자가 직접 연결을 승인한 경우에만 직접 노출한다.
+
+### 4-4. 매장 삭제 및 비공개 전환 시 처리
+
+- 폐업자가 매장을 `UNPUBLISHED`로 전환하면 즉시 검색 결과에서 제거된다.
+- 기존에 `ACCEPTED` 상태인 매칭이 있는 경우, 해당 매칭 당사자에게는 MATCHED_ONLY 정보가 유지되며 운영자에게 알림이 발송된다.
+- 매장 데이터는 실제로 삭제되지 않으며, `publicationStatus`만 변경된다. 법적 보관 의무 기간 동안 INTERNAL 접근으로 유지된다.
+
+---
+
+## 5. 동의 체계
+
+### 5-1. 동의 수집 항목
+
+Re:Link는 `UserConsent` 모델을 통해 동의 유형별로 수집 시점, 버전, 철회 가능 여부를 관리한다.
+
+| 동의 항목 | `consentType` 코드 | 수집 시점 | 철회 가능 여부 |
+|----------|-------------------|-----------|----------------|
+| 서비스 이용약관 동의 | `TERMS_OF_SERVICE` | 회원가입 시 | 회원 탈퇴로만 가능 |
+| 개인정보 처리방침 동의 (필수) | `PRIVACY_POLICY_REQUIRED` | 회원가입 시 | 회원 탈퇴로만 가능 |
+| 개인정보 처리방침 동의 (마케팅) | `PRIVACY_POLICY_MARKETING` | 회원가입 시 (선택) | 언제든지 철회 가능 |
+| 정보 공개 동의 (매장 공개) | `STORE_PUBLICATION_CONSENT` | 최초 공개 전환 직전 | 매장 비공개 전환으로 실질 효력 중단 |
+| MATCHED_ONLY 정보 제공 동의 | `MATCHED_INFO_DISCLOSURE` | 매칭 수락 직전 | 매칭 취소 시 효력 중단 |
+| 제3자 정보 제공 동의 (매칭 상대방) | `THIRD_PARTY_MATCHED_PARTY` | 매칭 수락 직전 | 매칭 취소 시 효력 중단 |
+| 알림톡 수신 동의 | `NOTIFICATION_KAKAO` | 회원가입 시 (선택) | 언제든지 철회 가능 |
+
+### 5-2. 동의 수집 방법
+
+- 동의 항목은 체크박스 형식으로 표시하며, 선택 동의와 필수 동의를 시각적으로 명확히 구분한다.
+- 동의서 본문 전체를 읽을 수 있어야 하며, 요약본과 전문(全文)을 함께 제공한다.
+- 동의 완료 시 `UserConsent` 레코드에 `policyVersionId`, `isGranted: true`, `grantedAt` 타임스탬프, 동의 당시 클라이언트 정보(IP, User-Agent)를 저장한다.
+- 동의 화면을 건너뛰거나 묵시적으로 동의 처리하지 않는다.
+
+### 5-3. 정책 버전 관리
+
+정책 본문이 변경될 때마다 `policyVersionId`를 새로 부여하며, 주요 변경의 경우 기존 동의자에게 재동의를 요청한다.
+
+| 변경 유형 | 대응 방식 |
+|-----------|----------|
+| 오탈자 수정, 법령 명칭 변경 등 경미한 수정 | 버전 업데이트 후 고지만 진행 (재동의 불요) |
+| 수집 항목 추가, 이용 목적 변경 등 실질적 변경 | 버전 업데이트 + 기존 동의자 재동의 요청, 미동의 시 해당 기능 이용 제한 |
+| 제3자 제공 범위 확대 | 버전 업데이트 + 전원 재동의 필수 |
+
+### 5-4. 동의 철회 시 처리
+
+- 철회 요청은 즉시 처리되며, `UserConsent.isGranted`를 `false`로 업데이트하고 `revokedAt` 타임스탬프를 기록한다.
+- `STORE_PUBLICATION_CONSENT` 철회 시: 해당 매장의 `publicationStatus`를 즉시 `PRIVATE`으로 전환하고, 진행 중인 매칭이 있으면 운영자에게 알림을 발송한다.
+- `MATCHED_INFO_DISCLOSURE` 철회 시: 철회 시점 이후 새로운 매칭에는 MATCHED_ONLY 정보를 제공하지 않는다. 이미 정보를 열람한 매칭 당사자의 열람 이력은 삭제되지 않는다.
+- 마케팅 동의 철회는 즉시 효력이 발생하며 영업일 기준 3일 이내에 마케팅 수신이 중단된다.
+- 동의 철회 이력(이전 동의 기록)은 법적 보관 의무에 따라 일정 기간 유지된다.
+
+---
+
+## 6. 열람 이력 기록
+
+### 6-1. 기록 원칙
+
+모든 RESTRICTED 등급 이상의 정보 열람은 `AuditLog`에 기록된다. PUBLIC_SUMMARY 열람은 집계 통계로만 처리하며, 개인 단위 기록은 남기지 않는다.
+
+### 6-2. AuditLog 기록 항목
+
+| 필드 | 내용 | 비고 |
+|------|------|------|
+| `id` | 고유 감사 로그 ID | |
+| `actorId` | 열람자 사용자 ID | |
+| `actorRole` | 열람자 역할 | |
+| `targetType` | 열람 대상 엔티티 타입 | `STORE`, `STORE_PHOTO`, `MATCH_REQUEST` 등 |
+| `targetId` | 열람 대상 엔티티 ID | |
+| `action` | 수행한 행동 | `VIEW`, `DOWNLOAD`, `EXPORT`, `ADMIN_OVERRIDE` |
+| `visibilityScope` | 열람한 정보의 등급 | `RESTRICTED`, `MATCHED_ONLY`, `INTERNAL` |
+| `fieldAccessed` | 열람한 특정 필드 목록 | JSON 배열 |
+| `ipAddress` | 열람자 IP | 마스킹 처리 후 저장 |
+| `userAgent` | 클라이언트 정보 | |
+| `requestId` | API 요청 추적 ID | |
+| `createdAt` | 열람 시각 | UTC 기준 |
+
+### 6-3. B2B 알림 상품을 위한 데이터 준비 (Phase 2 준비)
+
+Phase 1 MVP에서는 B2B 알림 상품을 출시하지 않는다. 단, Phase 2에서 "지역·업종별 폐업 예정 정보 알림" 구독 상품을 출시할 수 있도록 아래 데이터 구조를 지금부터 축적한다.
+
+**축적할 데이터:**
+
+| 데이터 항목 | 용도 | 공개 등급 |
+|------------|------|----------|
+| 지역 클러스터별 매장 등록 건수 | 지역별 수요 파악 | INTERNAL (집계값) |
+| 업종별 매장 등록 트렌드 | 알림 상품 단가 설정 | INTERNAL (집계값) |
+| `AlertSubscription` 관심 등록 수 | 잠재 구독자 규모 파악 | INTERNAL |
+| 매장별 열람 횟수 (역할별) | 콘텐츠 수요 측정 | INTERNAL (집계값) |
+| VENDOR_MANAGER의 관심 표시 이력 | 리드 품질 측정 | INTERNAL |
+
+**B2B 알림 상품 정책 원칙 (Phase 2 적용 예정):**
+
+- 알림 발송 대상은 익명화된 집계 정보(지역·업종·시설 유형)에 한정하며, 개인 식별 정보(상호명, 주소, 연락처)는 구독만으로 제공하지 않는다.
+- 구독자가 관심 매장에 매칭 요청을 보내고 수락된 경우에만 MATCHED_ONLY 정보 접근이 허용된다.
+- 원본 개인정보를 B2B 데이터로 직접 판매하거나 제3자에게 제공하지 않는다.
+
+### 6-4. 열람 이력 보관 기간
+
+| 정보 등급 | 보관 기간 | 근거 |
+|----------|----------|------|
+| PUBLIC_SUMMARY 집계 통계 | 5년 | 서비스 품질 분석 |
+| RESTRICTED 열람 이력 | 3년 | 분쟁 소멸시효 고려 |
+| MATCHED_ONLY 열람 이력 | 5년 | 계약 분쟁 대응 |
+| INTERNAL 열람 이력 | 10년 | 법적 감사 의무 |
+
+---
+
+## 7. API 응답 필터링 원칙
+
+### 7-1. 서버 사이드 필터링 원칙
+
+정보 공개 등급에 따른 필드 필터링은 반드시 서버에서 처리한다. 클라이언트(프론트엔드)에서 조건부로 UI를 숨기는 방식은 보안 통제 수단으로 인정하지 않는다.
+
+- API 응답 생성 시 호출자의 역할(`actorRole`)과 매장과의 관계(`matchStatus`)를 검사한다.
+- 공개 등급을 초과하는 필드는 응답 객체에서 제거(삭제)하며, `null` 또는 마스킹된 값으로 대체하지 않는다.
+- 단, 사용자 경험을 위해 접근 불가 필드가 존재함을 클라이언트에 알려야 할 경우에는 `_restricted: true` 메타 플래그를 해당 필드 위치에 포함할 수 있다.
+
+### 7-2. 필터링 레이어 구조
+
+```
+HTTP 요청
+  → 인증 미들웨어 (세션/토큰 검증)
+  → 인가 미들웨어 (역할 + 매장 관계 확인)
+  → 서비스 레이어 (비즈니스 로직)
+  → 응답 직렬화 레이어 (visibilityScope 기준 필드 필터링)
+  → HTTP 응답
+```
+
+응답 직렬화 레이어에서 `visibilityScope`와 호출자의 접근 등급을 대조하여 필드를 제거한다. 이 레이어는 도메인 로직과 분리된 별도 계층으로 구현한다.
+
+### 7-3. 캐시 레이어에서의 개인정보 노출 방지
+
+- RESTRICTED 이상의 정보를 포함한 API 응답은 공유 캐시(Redis, CDN)에 저장하지 않는다.
+- PUBLIC_SUMMARY 응답만 공유 캐시에 저장 가능하며, 캐시 키에 사용자 식별자가 포함되지 않도록 한다.
+- MATCHED_ONLY 및 INTERNAL 응답은 캐시를 완전히 비활성화하고, `Cache-Control: no-store` 헤더를 반드시 포함한다.
+- 사용자별 개인화 캐시가 필요한 경우, 캐시 키에 사용자 ID와 매칭 관계 해시를 포함하여 다른 사용자에게 노출되지 않도록 격리한다.
+
+### 7-4. 사진 접근 제어
+
+- 사진 파일 자체는 서명된 URL(Signed URL)로만 제공하며, 직접 URL을 통한 무제한 접근을 허용하지 않는다.
+- 서명 URL의 만료 시간: PUBLIC_SUMMARY 사진 24시간, RESTRICTED 사진 1시간, MATCHED_ONLY 사진 1시간
+- 서명 URL 생성 시마다 AuditLog를 기록한다.
+- 서명 URL이 만료된 이후에는 재생성 API를 통해서만 접근 가능하며, 재생성 시에도 동일한 권한 검사를 수행한다.
+
+### 7-5. 관리자 직접 접근 시 추가 보호
+
+INTERNAL 정보에 접근하는 운영자 API는 아래 추가 보호를 적용한다.
+
+- 운영자 계정에 대한 다단계 인증(MFA) 필수
+- 접근 사유 코드를 API 요청 파라미터로 반드시 포함
+- 모든 접근을 AuditLog에 기록하며 실시간 모니터링 알림 설정
+- 개인정보 원본(주민등록번호, 계좌번호) 조회는 SUPER_ADMIN과 TRUST_OPERATOR(사유 코드 포함 시)만 가능
+
+---
+
+## 8. 개인정보보호법 준수
+
+### 8-1. PII 식별 및 분리 저장
+
+Re:Link에서 개인정보(PII)로 분류하는 항목과 저장 방식은 아래와 같다.
+
+| 분류 | 항목 | 저장 방식 | 접근 통제 |
+|------|------|----------|----------|
+| 식별 정보 | 성명, 이메일, 전화번호 | 암호화 저장 (AES-256) | MATCHED_ONLY 이상 |
+| 고유 식별자 | 주민등록번호 | 단방향 해시 + 분리 저장 | INTERNAL, SUPER_ADMIN만 |
+| 금융 정보 | 계좌번호, 카드 정보 | PG사 위탁 또는 토큰화 | INTERNAL, FINANCE_OPERATOR만 |
+| 위치 정보 | 상세 주소 | 암호화 저장 | MATCHED_ONLY 이상 |
+| 사업자 정보 | 사업자등록번호 | 평문 저장 (공개 정보) | MATCHED_ONLY 이상 |
+
+사업자등록번호는 공개 정보이나, Re:Link 내에서는 계약 목적으로만 사용하며 검색 노출은 MATCHED_ONLY로 제한한다.
+
+### 8-2. 개인정보 수집 및 이용 목적
+
+Re:Link가 수집하는 개인정보는 아래 목적으로만 사용한다.
+
+| 수집 목적 | 해당 항목 | 보관 기간 |
+|----------|----------|----------|
+| 서비스 회원 관리 및 인증 | 이메일, 전화번호, 소셜 계정 ID | 회원 탈퇴 후 30일 |
+| 매장 등록 및 매칭 서비스 제공 | 성명, 전화번호, 이메일, 상세 주소 | 거래 종료 후 5년 |
+| 계약 이행 및 정산 | 사업자등록번호, 계좌번호 | 계약 종료 후 5년 (세법 기준) |
+| 정부 지원금 신청 보조 | 개인 서류 일체 | 지원금 케이스 종료 후 5년 |
+| 분쟁 처리 및 법적 대응 | 관련 기록 전체 | 분쟁 종료 후 5년 |
+| 서비스 개선 및 통계 분석 | 익명화된 이용 이력 | 5년 |
+
+### 8-3. 개인정보 보관 기간 및 파기 정책
+
+- 회원 탈퇴 시: 서비스 이용 기록은 탈퇴 후 30일 이내 파기. 단, 진행 중인 거래, 계약, 분쟁이 있는 경우 해당 케이스 종료 후 법정 보관 기간을 적용한다.
+- 매장 등록 정보: 거래 종료(CLOSED/CANCELLED) 후 5년. 운영자가 법적 근거를 문서화한 경우에 한해 연장 가능.
+- 정부 지원금 관련 서류: 서류에 명시된 법정 보관 기간을 우선 적용하며, 최소 5년.
+- 파기 방법: DB에 저장된 데이터는 완전 삭제(DELETE) 처리하며, 파일 스토리지의 파일은 영구 삭제 후 파기 이력을 별도 로그로 보관한다.
+- 자동 파기 스케줄러를 운영하며, 파기 실행 결과를 운영자가 확인할 수 있는 보고서를 제공한다.
+
+### 8-4. 제3자 제공 시 동의 요건
+
+개인정보의 제3자 제공은 아래 경우에만 허용된다.
+
+| 제공 유형 | 제공 조건 | 동의 요건 |
+|----------|----------|----------|
+| 매칭 상대방 (창업자/폐업자 간) | 매칭 수락 완료 | 사전 동의 (`THIRD_PARTY_MATCHED_PARTY`) 필수 |
+| 철거/인테리어 업체 | 운영자 승인 + 매칭 수락 | 사전 동의 + 운영자 승인 |
+| 정부 기관 (법적 요청) | 수사·법원 요청 등 법적 의무 | 동의 불요, 운영자 승인 + 법무 검토 |
+| 정산·결제 대행사 (PG사) | 결제 처리 목적 | 서비스 이용약관에 포함 (별도 동의 불요) |
+| 통계·분석 서비스 (익명화) | 개인 식별 불가한 집계 데이터 | 동의 불요 |
+
+B2B 알림 상품 출시 시(Phase 2) 업체에 대한 정보 제공 범위가 확대될 수 있으며, 이 경우 반드시 별도 동의를 재수집해야 한다.
+
+### 8-5. 개인정보 처리 위탁
+
+Re:Link가 개인정보 처리를 위탁하는 수탁자와 위탁 업무 범위는 개인정보 처리방침에 공개한다.
+
+| 수탁자 | 위탁 업무 |
+|--------|----------|
+| 토스페이먼츠 | 결제 처리 및 에스크로 관리 |
+| AWS / IDC 사업자 | 데이터 보관 및 인프라 운영 |
+| 카카오 | 알림톡 발송 |
+| 소셜 로그인 제공자 (Kakao, Naver, Google) | 본인인증 및 계정 연동 |
+
+수탁자는 위탁 받은 업무 범위 외에 개인정보를 이용하거나 제3자에게 제공하지 않는다. 위탁 계약 체결 시 개인정보 보호 의무를 계약서에 명시한다.
+
+### 8-6. 정보주체의 권리
+
+폐업자를 포함한 모든 사용자는 아래 권리를 행사할 수 있다.
+
+| 권리 | 요청 방법 | 처리 기한 |
+|------|----------|----------|
+| 열람 요청 | 앱 내 개인정보 관리 메뉴 또는 운영자 이메일 | 10일 이내 |
+| 정정·삭제 요청 | 앱 내 개인정보 관리 메뉴 | 10일 이내 |
+| 처리 정지 요청 | 운영자 이메일 | 10일 이내 |
+| 동의 철회 | 앱 내 동의 관리 메뉴 | 즉시 처리 |
+
+---
+
+## 부록: 용어 정의
+
+| 용어 | 정의 |
+|------|------|
+| CLOSING_OWNER | 폐업 매장을 등록한 사용자. 본인이 등록한 매장에 대해서는 RESTRICTED 등급까지 기본 접근 권한을 가짐 |
+| FOUNDER | 창업 목적으로 매장 인수를 탐색하는 사용자 |
+| VENDOR_MANAGER | 철거 또는 인테리어 서비스를 제공하는 업체의 담당자. 업체 인증 완료 후 RESTRICTED 접근 가능 |
+| OPS_MANAGER | 매장 등록 검토, 매칭 보정, 운영 품질을 담당하는 운영자 |
+| SUBSIDY_OPERATOR | 정부 지원금 서류 검토 및 상태 관리를 담당하는 운영자 |
+| TRUST_OPERATOR | 업체 인증, 계약, 검수, 분쟁을 담당하는 운영자 |
+| FINANCE_OPERATOR | 정산, 결제 대사, 환불을 담당하는 운영자 |
+| SUPER_ADMIN | 전체 시스템 설정 및 긴급 조치 권한을 가진 최고 관리자 |
+| visibilityScope | 데이터 항목(특히 사진)에 부여된 공개 등급 필드 |
+| publicationStatus | 매장 전체의 공개 상태 (PRIVATE, RESTRICTED, PUBLISHED, UNPUBLISHED) |
+| reviewStatus | 운영자 검토 상태 (DRAFT, SUBMITTED, REVIEWING, APPROVED, REJECTED) |
+| AuditLog | 시스템 내 모든 주요 행위를 추적하는 감사 로그 |
+| PII | 개인식별정보 (Personally Identifiable Information) |
+| 서명 URL | 일정 시간 동안만 유효한 인증된 파일 접근 URL |
+
+---
+
+## 문서 이력
+
+| 버전 | 날짜 | 변경 내용 | 작성자 |
+|------|------|----------|--------|
+| v1.0.0 | 2026-03-07 | 최초 작성 | 대표 + CTO |
+
+> 이 문서는 Re:Link 운영 및 개발의 기준 정책 문서입니다. 변경 시 DRI(대표)의 승인을 거쳐야 하며, 변경 이력을 반드시 기록해야 합니다.

docs/policies/subsidy-policy.md

@@ -0,0 +1,594 @@
+# Re:Link 지원금 대행 정책서
+
+> 문서 코드: D001
+> 버전: 1.0.0
+> 작성일: 2026-03-07
+> 적용 범위: MVP Phase 1 (희망리턴패키지)
+> 승인 상태: 초안 (법무 검토 전)
+> 다음 검토일: 2026-04-01 (G0 게이트 정책 확정 전)
+
+---
+
+## 목차
+
+1. [서비스 범위 정의](#1-서비스-범위-정의)
+2. [자격 판별 규칙](#2-자격-판별-규칙)
+3. [체크리스트 정의](#3-체크리스트-정의)
+4. [상태 전환 규칙](#4-상태-전환-규칙)
+5. [운영자 역할](#5-운영자-역할)
+6. [사용자 경험 흐름](#6-사용자-경험-흐름)
+7. [정책 변경 대응](#7-정책-변경-대응)
+8. [리스크 및 면책](#8-리스크-및-면책)
+
+---
+
+## 1. 서비스 범위 정의
+
+### 1-1. 포지션 원칙
+
+Re:Link의 지원금 서비스는 **정부 사업의 경쟁자가 아닌 신청 보조 파트너**다.
+
+플랫폼은 폐업자가 정부 지원금을 받기 위해 스스로 준비해야 할 서류와 절차를 안내하고, 운영자가 서류 구비 상태를 검토하여 제출 준비 완료 여부를 판정하는 역할까지만 담당한다. 정부 기관을 대신하여 자동으로 서류를 제출하거나, 심사 결과에 영향을 주는 행위는 MVP에서 하지 않는다.
+
+### 1-2. MVP 서비스 범위
+
+| 구분 | 범위 |
+|------|------|
+| 서비스 유형 | 가이드형 + 운영자 검토형 |
+| 지원 프로그램 | 희망리턴패키지 (단일) |
+| 적용 사용자 | 폐업자 (UserRole: CLOSING_OWNER) |
+| 케이스 생성 기준 | Store 1개당 1개의 active SubsidyCase |
+
+### 1-3. 지원 가능 프로그램 목록
+
+**MVP (Phase 1) 지원 프로그램:**
+
+| 프로그램 코드 | 프로그램명 | 주관 기관 | 지원 내용 요약 |
+|--------------|-----------|----------|----------------|
+| `HOPE_RETURN_PKG` | 희망리턴패키지 | 소상공인시장진흥공단 | 폐업 소상공인 대상 점포철거비, 법률·세무 컨설팅, 재취업·재창업 지원 |
+
+**Phase 2 이후 추가 예정 (참고용):**
+
+| 프로그램 코드 | 프로그램명 | 추가 예정 시점 |
+|--------------|-----------|----------------|
+| `RESTART_LOAN` | 재기지원 융자 | Phase 2 검토 |
+| `CLOSURE_CONSULTING` | 폐업 컨설팅 지원 | Phase 2 검토 |
+
+Phase 2 프로그램은 법무 검토 및 운영 준비 완료 후 별도 정책서로 추가한다.
+
+### 1-4. 플랫폼이 하는 것과 하지 않는 것
+
+**플랫폼이 하는 것:**
+
+- 자격 요건 체크리스트를 기반으로 자격 판별 결과를 안내한다.
+- 필수/선택 서류 목록을 제공하고 업로드 기능을 지원한다.
+- 업로드된 서류의 진행 상태와 운영자 피드백을 사용자에게 보여준다.
+- 운영자가 서류 구비 상태를 검토하고 보완 요청 또는 제출 준비 완료를 판정한다.
+- 각 상태 변화 시 사용자에게 알림을 발송한다.
+
+**플랫폼이 하지 않는 것:**
+
+- 정부 기관(소진공) 포털에 사용자를 대리하여 자동 제출하지 않는다.
+- 정부 심사 결과를 보장하거나 승인 가능성을 수치로 제시하지 않는다.
+- 법적 대리인 자격으로 서류에 서명하거나 행위를 대행하지 않는다.
+- 세무·법률 전문가의 의견을 대체하는 법적 자문을 제공하지 않는다.
+- 지원금 수령액을 미리 보장하거나 확약하지 않는다.
+
+---
+
+## 2. 자격 판별 규칙
+
+### 2-1. 희망리턴패키지 자격 요건
+
+자격 판별은 사용자가 입력한 정보를 기반으로 시스템이 체크하며, 최종 판정은 정부 기관이 수행한다. 플랫폼의 자격 판별 결과는 신청 가능성에 대한 **안내 목적**이며, 법적 효력이 없다.
+
+**기본 요건:**
+
+| 항목 | 조건 | 비고 |
+|------|------|------|
+| 사업자등록 유지 여부 | 현재 사업자등록이 유효한 상태여야 함 | 이미 폐업 처리된 경우 일부 항목 신청 불가 |
+| 사업 영위 기간 | 사업자등록 후 6개월 이상 실제 영업 | 영업 사실 서류 필요 |
+| 폐업 의사 | 폐업 예정이거나 폐업 절차 진행 중 | 이미 폐업 처리된 경우 일부 항목은 신청 가능 |
+| 매출액 기준 | 연 매출 10억 5,000만 원 이하 소상공인 기준 충족 | 소상공인기본법 기준 |
+| 업종 기준 | 제조업·건설업·운수업 등 소상공인 해당 업종 | 금융업·보험업 등 일부 제외 업종 존재 |
+| 중복 수혜 이력 | 동일 프로그램 기수혜 이력 없음 | 기수혜자는 항목별 제한 상이 |
+
+**업종 제한 (MVP 기준):**
+
+- 금융·보험업 종사자는 신청 불가
+- 부동산업, 임대업 일부는 별도 확인 필요
+- 전문직(의사·변호사·회계사 등) 사업자는 별도 확인 필요
+
+상기 업종 제한은 소진공 공지 기준이며 사업 연도별로 변경될 수 있다. 운영자는 최신 공고를 확인하여 판별 기준을 업데이트한다.
+
+### 2-2. 자격 판별 결과 유형
+
+자격 판별 결과는 `eligibilityResult` 필드에 저장되며, 4가지 유형으로 분류된다.
+
+#### ELIGIBLE (신청 가능)
+
+모든 자격 요건을 충족한 것으로 판단되는 경우.
+
+사용자 안내 메시지:
+> "입력하신 정보를 기준으로 희망리턴패키지 신청 자격을 갖춘 것으로 확인됩니다. 아래 체크리스트에 따라 필요 서류를 준비하고 업로드해 주세요. 최종 자격 판정은 소상공인시장진흥공단에서 확인합니다."
+
+#### CONDITIONALLY_ELIGIBLE (조건부 가능)
+
+일부 요건이 불확실하거나 추가 확인이 필요한 경우. (예: 업종 경계 케이스, 매출 기준 근접, 중복 수혜 이력 불명확)
+
+사용자 안내 메시지:
+> "입력하신 정보 중 일부 항목을 추가로 확인해야 합니다. 운영자가 서류를 검토하면서 자격 여부를 함께 안내드리겠습니다. 체크리스트 서류를 준비하여 업로드해 주세요."
+
+#### NOT_ELIGIBLE (신청 불가)
+
+명확히 자격 요건을 충족하지 못하는 경우. (예: 사업자등록 말소, 연 매출 초과, 제외 업종)
+
+사용자 안내 메시지:
+> "입력하신 정보를 기준으로 현재 희망리턴패키지 신청 자격을 충족하기 어렵습니다. 구체적인 사유는 아래에서 확인하실 수 있습니다. 상황이 변경되거나 문의가 필요하시면 운영팀에 연락해 주세요."
+
+NOT_ELIGIBLE 판별 시 사유 코드를 함께 저장한다:
+- `ALREADY_CLOSED`: 사업자등록 이미 말소
+- `REVENUE_EXCEEDED`: 소상공인 매출 기준 초과
+- `EXCLUDED_INDUSTRY`: 제외 업종
+- `DUPLICATE_BENEFIT`: 동일 프로그램 기수혜
+
+#### UNKNOWN (판별 불가)
+
+입력 정보 부족 또는 시스템 오류로 판별이 불가능한 경우.
+
+사용자 안내 메시지:
+> "자격 판별에 필요한 정보가 부족합니다. 매장 정보와 사업자 정보를 보완해 주시면 다시 확인해 드리겠습니다. 궁금한 사항은 운영팀에 문의해 주세요."
+
+### 2-3. 자격 판별 재시도 원칙
+
+- 사용자가 매장 정보를 수정하거나 보완하면 자격 판별을 재실행할 수 있다.
+- 재판별 결과는 새로운 `eligibilitySnapshotJson`으로 저장하되, 기존 SubsidyCase의 `eligibilityResult`를 갱신한다.
+- 자격 판별 재실행 시 AuditLog를 남긴다.
+
+---
+
+## 3. 체크리스트 정의
+
+### 3-1. 체크리스트 운영 원칙
+
+- 체크리스트는 `checklistVersionCode`로 버전을 관리한다.
+- SubsidyCase 생성 시점의 체크리스트 버전을 케이스에 고정한다.
+- 체크리스트 항목은 `SubsidyChecklistItem` 테이블에 생성된다.
+- 각 항목은 `itemCode`로 식별하며, 정부 공고 변경 시 새 버전으로 추가한다.
+
+### 3-2. 희망리턴패키지 필수 서류 목록 (체크리스트 버전: `HOPE_RETURN_PKG_V1`)
+
+| itemCode | 서류명 | 설명 | isRequired |
+|----------|--------|------|------------|
+| `HRP_DOC_001` | 사업자등록증 사본 | 현재 유효한 사업자등록증 사본 (발급일 3개월 이내 권장) | true |
+| `HRP_DOC_002` | 폐업 사유서 | 자필 또는 서식 작성, 폐업 사유와 의사를 구체적으로 기재 | true |
+| `HRP_DOC_003` | 본인 확인 서류 | 주민등록증, 운전면허증, 여권 중 택1 (사업자 본인) | true |
+| `HRP_DOC_004` | 최근 6개월 부가세 신고 내역 또는 매출 확인 서류 | 홈택스 발급 가능, 간이과세자는 대체 서류 허용 | true |
+| `HRP_DOC_005` | 임대차 계약서 사본 | 현재 영업 중인 매장의 임대차 계약서 (해당하는 경우) | true |
+| `HRP_DOC_006` | 점포 철거비 견적서 | 철거업체 발행 공식 견적서 (철거비 지원 신청 시 필수) | true |
+| `HRP_DOC_007` | 통장 사본 | 지원금 수령 계좌 확인용, 사업자 본인 명의 | true |
+
+### 3-3. 선택 서류 목록
+
+| itemCode | 서류명 | 설명 | 제출 권장 상황 |
+|----------|--------|------|----------------|
+| `HRP_DOC_101` | 가족관계증명서 | 대표자 확인 보완 서류 | 본인 확인 서류 외 추가 요청 시 |
+| `HRP_DOC_102` | 영업 사실 확인 서류 | 카드단말기 내역, 영업허가증 등 | 영업 기간이 짧거나 확인이 어려운 경우 |
+| `HRP_DOC_103` | 부채 확인 서류 | 대출 잔액 확인서 등 | 재기 지원 신청 동시 진행 시 |
+| `HRP_DOC_104` | 건물 등기부등본 | 매장 소재지 확인용 | 임대차 계약서 없이 자가 영업인 경우 |
+
+### 3-4. 서류 상태 코드
+
+각 `SubsidyDocument`의 `reviewStatus` 값:
+
+| 상태 코드 | 의미 |
+|----------|------|
+| `PENDING` | 업로드 완료, 운영자 검토 대기 중 |
+| `APPROVED` | 운영자 검토 완료, 서류 정상 |
+| `REJECTED` | 반려, 재업로드 또는 교체 필요 |
+| `RESUBMITTED` | 반려 후 사용자가 재업로드 완료 |
+
+### 3-5. 체크리스트 버전 관리 원칙
+
+- 정부 공고 변경 시 신규 버전 코드를 발행한다. (예: `HOPE_RETURN_PKG_V2`)
+- 기존 진행 중인 케이스는 케이스 생성 시점의 버전을 유지한다.
+- 신규 케이스부터 최신 버전이 적용된다.
+- 버전 변경 내역은 운영 문서로 기록한다.
+- 체크리스트 버전과 `PolicyVersion` 테이블은 연동하여 관리한다.
+
+---
+
+## 4. 상태 전환 규칙
+
+### 4-1. SubsidyCase 상태머신
+
+```
+DRAFT
+  |
+  | [사용자: 자격 판별 요청]
+  v
+ELIGIBILITY_CHECKED
+  |
+  | [자격 결과 ELIGIBLE 또는 CONDITIONALLY_ELIGIBLE]
+  v
+DOCUMENTS_PENDING
+  |
+  | [사용자: 필수 서류 전체 업로드 완료 후 검토 요청]
+  v
+REVIEWING
+  |
+  |-- [운영자: 보완 요청] --> DOCUMENTS_PENDING (보완 요청 상태)
+  |
+  | [운영자: 제출 준비 완료 판정]
+  v
+READY_TO_SUBMIT
+  |
+  | [사용자: 최종 제출 확인 및 동의]
+  v
+SUBMITTED
+  |
+  |-- [결과: 승인] --> APPROVED
+  |-- [결과: 반려] --> REJECTED
+```
+
+NOT_ELIGIBLE 판별 시: ELIGIBILITY_CHECKED 상태에서 케이스를 CLOSED 처리한다.
+
+### 4-2. 각 상태별 전제 조건
+
+#### DRAFT
+
+- SubsidyCase가 생성된 초기 상태.
+- 전제 조건: Store가 존재하고, 해당 Store에 대한 active SubsidyCase가 없어야 함.
+- 같은 `storeId + programCode` 조합으로 active 케이스는 1개만 허용한다.
+
+#### ELIGIBILITY_CHECKED
+
+- 전제 조건: 사용자가 자격 판별에 필요한 매장 정보 및 사업자 정보를 입력 완료.
+- 전환 주체: 사용자 (시스템 자동 판별).
+- 저장 내용: `eligibilityResult`, `eligibilitySnapshotJson`, `policyVersionId`.
+
+#### DOCUMENTS_PENDING
+
+- 전제 조건: `eligibilityResult`가 `ELIGIBLE` 또는 `CONDITIONALLY_ELIGIBLE`.
+- 전환 주체: 시스템 자동 전환 (ELIGIBILITY_CHECKED 이후).
+- NOT_ELIGIBLE인 경우 이 단계로 진입하지 않는다.
+- 보완 요청으로 되돌아온 경우: `rejectionReasonCode`와 운영자 메모를 사용자에게 표시.
+
+#### REVIEWING
+
+- 전제 조건: 필수 서류(`isRequired: true`) 전체가 업로드 완료 상태여야 함.
+- 전환 주체: 사용자 (검토 요청 버튼 클릭).
+- 전환 조건 검증: 시스템이 필수 항목 누락 여부를 실시간으로 검사하며, 누락 항목이 있으면 검토 요청 불가.
+
+#### READY_TO_SUBMIT
+
+- 전제 조건: 운영자가 모든 서류를 APPROVED 처리.
+- 전환 주체: `SUBSIDY_OPERATOR` 역할 운영자.
+- 이 상태에서 운영자는 제출을 위한 최종 안내 메시지를 사용자에게 작성한다.
+
+#### SUBMITTED
+
+- 전제 조건: 사용자가 최종 제출 동의 완료.
+- 전환 주체: 사용자.
+- MVP에서는 시스템이 자동으로 정부 포털에 제출하지 않는다. 사용자가 직접 제출하였음을 확인하는 방식으로 운영한다.
+- `submittedAt` 타임스탬프 기록.
+
+#### APPROVED / REJECTED
+
+- 전환 주체: `SUBSIDY_OPERATOR` 역할 운영자 (정부 결과 확인 후 수동 업데이트).
+- 정부 기관의 최종 결과를 운영자가 플랫폼에 반영한다.
+- REJECTED 시 `rejectionReasonCode`와 사유 메모를 함께 기록한다.
+
+### 4-3. 전환 가능한 역할 매트릭스
+
+| 전환 | 전환 가능 역할 |
+|------|----------------|
+| DRAFT → ELIGIBILITY_CHECKED | 사용자 본인 (CLOSING_OWNER) |
+| ELIGIBILITY_CHECKED → DOCUMENTS_PENDING | 시스템 자동 |
+| DOCUMENTS_PENDING → REVIEWING | 사용자 본인 (CLOSING_OWNER) |
+| REVIEWING → DOCUMENTS_PENDING (보완 요청) | SUBSIDY_OPERATOR, SUPER_ADMIN |
+| REVIEWING → READY_TO_SUBMIT | SUBSIDY_OPERATOR, SUPER_ADMIN |
+| READY_TO_SUBMIT → SUBMITTED | 사용자 본인 (CLOSING_OWNER) |
+| SUBMITTED → APPROVED | SUBSIDY_OPERATOR, SUPER_ADMIN |
+| SUBMITTED → REJECTED | SUBSIDY_OPERATOR, SUPER_ADMIN |
+| 모든 상태 → CLOSED (케이스 종료) | SUBSIDY_OPERATOR, SUPER_ADMIN |
+
+### 4-4. 상태 전환 시 생성되는 로그
+
+모든 상태 전환은 반드시 아래 두 로그를 동시에 생성한다.
+
+**AuditLog:**
+
+| 필드 | 내용 |
+|------|------|
+| `resourceType` | `SubsidyCase` |
+| `resourceId` | 해당 케이스 ID |
+| `actionType` | 전환 액션 코드 (예: `SUBSIDY_CASE_STATUS_CHANGED`) |
+| `actorUserId` | 전환을 실행한 사용자 또는 운영자 ID |
+| `actorRole` | 실행자 역할 |
+| `reasonCode` | 전환 사유 코드 (운영자 전환 시 필수) |
+| `memo` | 운영자 메모 (선택, 사용자 피드백 포함 시 필수) |
+| `beforeJson` | 전환 전 상태 스냅샷 |
+| `afterJson` | 전환 후 상태 스냅샷 |
+
+**EventLog:**
+
+| 필드 | 내용 |
+|------|------|
+| `aggregateType` | `SubsidyCase` |
+| `aggregateId` | 해당 케이스 ID |
+| `eventName` | 이벤트명 (예: `subsidy_case_reviewed`) |
+| `payloadJson` | `subsidyCaseId`, `result`, `reason_code`, `operator_id` 포함 |
+| `piiLevel` | `LOW` (개인 식별 정보 최소화) |
+
+---
+
+## 5. 운영자 역할
+
+### 5-1. 담당 운영자 역할
+
+지원금 관련 운영은 `SUBSIDY_OPERATOR` 역할이 담당한다. `SUPER_ADMIN`은 모든 권한을 보유한다.
+
+### 5-2. 서류 검토 프로세스
+
+운영자는 아래 순서로 서류를 검토한다.
+
+1. 운영 콘솔의 지원금 서류 검토 큐에서 REVIEWING 상태 케이스를 확인한다.
+2. 각 `SubsidyDocument`를 순서대로 열람한다.
+3. 서류별로 APPROVED 또는 REJECTED를 판정한다.
+4. REJECTED 처리 시 반려 사유 코드와 구체적인 보완 요청 내용을 기재한다.
+5. 필수 서류 전체 APPROVED 시, 케이스를 READY_TO_SUBMIT으로 전환한다.
+6. 보완이 필요한 경우 케이스를 DOCUMENTS_PENDING으로 되돌리고 보완 요청 알림을 발송한다.
+
+### 5-3. 반려 사유 코드 목록
+
+| 코드 | 명칭 | 설명 | 사용자 안내 예시 |
+|------|------|------|------------------|
+| `MISSING_DOCUMENT` | 서류 누락 | 필수 서류가 업로드되지 않음 | "필수 서류가 누락되어 있습니다. 해당 서류를 업로드해 주세요." |
+| `INVALID_DOCUMENT` | 서류 유효하지 않음 | 잘못된 서류 제출 (기간 만료, 타인 명의, 관계없는 서류 등) | "제출하신 서류를 확인할 수 없습니다. 올바른 서류를 다시 업로드해 주세요." |
+| `ILLEGIBLE_DOCUMENT` | 서류 판독 불가 | 사진 품질 불량, 잘린 이미지, 흐릿한 스캔 | "서류 내용을 확인하기 어렵습니다. 선명하게 다시 촬영하거나 스캔하여 업로드해 주세요." |
+| `EXPIRED_DOCUMENT` | 서류 유효기간 만료 | 유효기간이 지난 서류 제출 | "제출하신 서류의 유효기간이 만료되었습니다. 최신 서류를 발급받아 다시 업로드해 주세요." |
+| `ELIGIBILITY_ISSUE` | 자격 요건 미충족 의심 | 서류 검토 결과 자격 요건 충족 여부가 불확실 | "서류 내용을 검토한 결과 추가 확인이 필요합니다. 운영팀에서 연락드리겠습니다." |
+| `INCOMPLETE_INFO` | 정보 불완전 | 서류 내용이 부분적으로 기재되지 않거나 서명 누락 | "서류의 일부 항목이 작성되지 않았습니다. 모든 항목을 기재하여 다시 제출해 주세요." |
+| `MISMATCHED_INFO` | 정보 불일치 | 다른 서류와 내용이 일치하지 않음 (주소, 이름, 사업자번호 등) | "제출하신 서류의 정보가 다른 서류와 일치하지 않습니다. 내용을 확인하고 수정하여 다시 제출해 주세요." |
+| `WRONG_FORMAT` | 형식 오류 | 요구된 형식과 다른 서류 제출 (예: 견적서 양식 불일치) | "올바른 형식의 서류가 아닙니다. 안내된 서식에 맞게 작성하여 다시 업로드해 주세요." |
+
+### 5-4. 보완 요청 절차
+
+1. 운영자가 반려 사유 코드와 메모를 입력하여 케이스를 DOCUMENTS_PENDING으로 전환한다.
+2. 시스템이 사용자에게 카카오 알림톡 또는 이메일로 보완 요청 알림을 발송한다.
+3. 알림에는 반려된 서류명과 보완 요청 내용이 포함된다.
+4. 사용자가 서류를 재업로드하면 해당 서류의 `reviewStatus`가 `RESUBMITTED`로 변경된다.
+5. 사용자가 보완 완료 후 다시 검토 요청하면 케이스가 REVIEWING으로 전환된다.
+
+보완 요청은 횟수 제한이 없으나, 동일 사유로 3회 이상 반복 반려 시 운영자는 케이스에 메모를 남기고 별도 상담을 안내한다.
+
+### 5-5. 운영자 SLA (검토 기한)
+
+| 케이스 유형 | 목표 검토 기한 | 최대 기한 |
+|------------|----------------|-----------|
+| 일반 REVIEWING 케이스 | 영업일 기준 3일 이내 | 영업일 기준 5일 |
+| 재제출(RESUBMITTED) 포함 케이스 | 영업일 기준 2일 이내 | 영업일 기준 3일 |
+| READY_TO_SUBMIT 이후 사용자 문의 | 영업일 기준 1일 이내 | 영업일 기준 2일 |
+
+검토 기한 초과 시 운영 콘솔에서 해당 케이스를 알림 표시하고, `OPS_MANAGER`에게 에스컬레이션 알림을 발송한다.
+
+베타 운영 기간(2026년 8~9월)에는 SLA 준수율을 주간 단위로 측정하고, 케이스 수량에 따라 기한을 재조정할 수 있다.
+
+---
+
+## 6. 사용자 경험 흐름
+
+### 6-1. 폐업자 화면 흐름
+
+아래는 폐업자(CLOSING_OWNER)가 희망리턴패키지를 신청하기까지의 전체 흐름이다.
+
+**Step 1: 케이스 생성**
+
+- 진입 경로: 매장 상세 페이지 > "지원금 신청" 탭 > "희망리턴패키지 신청 시작"
+- 사용자 확인 내용: 서비스 소개, 범위 안내, 면책 고지 동의
+- 동의 완료 시 SubsidyCase 생성 (상태: DRAFT)
+- 이미 active 케이스가 있는 경우 기존 케이스로 이동
+
+**Step 2: 자격 판별**
+
+- 화면: 자격 확인 체크리스트 (입력 또는 자동 불러오기)
+- 항목: 사업자등록 유지 여부, 영업 기간, 업종, 매출 규모, 중복 수혜 이력
+- 매장 등록 시 이미 입력된 정보는 자동으로 불러온다.
+- 제출 시 시스템이 자격 판별 결과를 생성하고 사용자에게 표시
+- 표시 내용: 판별 결과 유형, 결과별 안내 메시지, 다음 단계 안내
+
+**Step 3: 체크리스트 확인**
+
+- ELIGIBLE, CONDITIONALLY_ELIGIBLE인 경우에만 접근 가능
+- 화면: 필수 서류 목록, 선택 서류 목록, 각 서류별 설명 및 예시
+- 각 서류 항목에 업로드 버튼 제공
+- 진행률(%) 표시: 필수 서류 업로드 완료 수 / 전체 필수 서류 수
+
+**Step 4: 서류 업로드**
+
+- 지원 파일 형식: PDF, JPG, PNG (최대 10MB/건)
+- 업로드 후 미리보기 가능
+- 업로드된 서류는 `reviewStatus: PENDING` 상태로 저장
+- 서류 교체 가능 (PENDING 또는 REJECTED 상태에서만)
+
+**Step 5: 검토 요청**
+
+- 모든 필수 서류 업로드 완료 시 "검토 요청" 버튼 활성화
+- 버튼 클릭 시 케이스 상태: DOCUMENTS_PENDING → REVIEWING
+- 사용자 화면: "운영자가 서류를 검토하고 있습니다. 영업일 기준 3일 내 결과를 알려드립니다."
+- 카카오 알림톡 또는 이메일로 접수 확인 알림 발송
+
+**Step 6: 검토 결과 확인**
+
+- 보완 요청인 경우: 알림 수신 → 케이스 페이지에서 반려 서류 및 사유 확인 → 재업로드 → 재검토 요청
+- 제출 준비 완료인 경우: 알림 수신 → READY_TO_SUBMIT 상태 화면 확인
+
+**Step 7: 최종 제출**
+
+- READY_TO_SUBMIT 상태에서 "최종 제출" 버튼 표시
+- 클릭 시 최종 제출 안내 팝업: 서류 목록 요약, 정부 포털 제출 방법 안내, 면책 동의 재확인
+- 동의 및 확인 클릭 시 상태: SUBMITTED
+- 사용자 화면: "제출이 완료되었습니다. 소상공인시장진흥공단에서 심사 결과를 안내드립니다."
+
+**Step 8: 결과 확인**
+
+- 정부 심사 결과를 운영자가 플랫폼에 업데이트하면 사용자에게 알림 발송
+- APPROVED: "희망리턴패키지 신청이 승인되었습니다. 소진공에서 안내된 절차에 따라 지원금을 수령하세요."
+- REJECTED: "안타깝게도 이번 신청이 반려되었습니다. 사유를 확인하고 재신청 여부를 검토해 주세요."
+
+### 6-2. 단계별 알림 발송 기준
+
+| 이벤트 | 발송 대상 | 채널 | 내용 |
+|--------|-----------|------|------|
+| 케이스 생성 | 사용자 | 이메일 | 신청 접수 확인, 다음 단계 안내 |
+| 검토 요청 접수 | 사용자 | 카카오 알림톡 | 검토 요청 접수 확인, 예상 처리 기한 안내 |
+| 보완 요청 | 사용자 | 카카오 알림톡 + 이메일 | 반려 서류명, 보완 요청 내용, 재업로드 링크 |
+| 제출 준비 완료 | 사용자 | 카카오 알림톡 | 검토 완료 안내, 최종 제출 방법 안내 |
+| 제출 완료 | 사용자 | 이메일 | 제출 확인, 소진공 심사 일정 안내 |
+| 결과 (승인/반려) | 사용자 | 카카오 알림톡 + 이메일 | 결과 통보, 후속 절차 안내 |
+| SLA 초과 | 운영자 | 내부 알림 | 검토 기한 초과 케이스 알림 |
+
+---
+
+## 7. 정책 변경 대응
+
+### 7-1. 정부 프로그램 변경 시 기존 케이스 처리 원칙
+
+정부 프로그램(희망리턴패키지)의 지원 내용, 자격 요건, 서류 목록이 변경되는 경우:
+
+1. `PolicyVersion` 테이블에 신규 버전을 등록한다.
+2. 신규 케이스부터 새 버전이 적용된다.
+3. 기존 케이스(DRAFT ~ REVIEWING 상태)는 원칙적으로 기존 버전을 유지한다.
+4. 변경 내용이 기존 케이스에 불이익을 줄 수 있는 경우, 운영자가 영향받는 케이스를 식별하고 개별 안내한다.
+5. READY_TO_SUBMIT 이후 상태의 케이스는 정책 변경 영향을 받지 않는다.
+
+**케이스별 처리 지침:**
+
+| 케이스 상태 | 처리 방법 |
+|-------------|-----------|
+| DRAFT | 재시작 권유 (새 버전 적용) 또는 기존 버전 유지 (운영자 판단) |
+| ELIGIBILITY_CHECKED | 자격 재판별 안내 발송 |
+| DOCUMENTS_PENDING | 신규 필수 서류가 추가된 경우 추가 업로드 안내 |
+| REVIEWING | 운영자가 새 기준 적용 여부를 케이스별 판단 |
+| READY_TO_SUBMIT 이후 | 정책 변경 적용 없이 기존 버전으로 진행 |
+
+### 7-2. 체크리스트 버전 업데이트 시 진행 중 케이스 처리
+
+체크리스트 항목이 추가/변경/삭제되는 경우:
+
+- 삭제된 항목: 기존 케이스에서 해당 항목을 선택 서류로 변경하거나 비활성 처리한다.
+- 추가된 필수 항목: 기존 진행 케이스 중 REVIEWING 이전 상태는 추가 항목 업로드 안내를 발송한다.
+- 기준 완화: 기존 케이스에도 소급 적용 가능하나 운영자 확인 후 처리한다.
+
+### 7-3. PolicyVersion 연결 원칙
+
+- SubsidyCase 생성 시 해당 시점의 active PolicyVersion ID를 `policyVersionId` 필드에 저장한다.
+- 저장된 `policyVersionId`는 케이스 종료 전까지 변경하지 않는다.
+- 정책 재판별이 필요한 경우 운영자가 사유와 함께 `policyVersionId`를 갱신할 수 있다. 이 경우 AuditLog를 반드시 남긴다.
+- `eligibilitySnapshotJson`에는 판별 시점의 정책 기준 요약을 포함시킨다.
+
+---
+
+## 8. 리스크 및 면책
+
+### 8-1. 법적 면책 고지 문구
+
+서비스 이용 전 사용자 동의 화면에 아래 내용을 명시한다.
+
+**[이용자 안내 및 면책 고지]**
+
+Re:Link 지원금 서비스는 소상공인의 정부 지원금 신청 절차를 안내하는 보조 서비스입니다.
+
+1. Re:Link는 정부 기관(소상공인시장진흥공단 등)을 대리하지 않으며, 지원금 심사 및 승인 결과에 영향을 주지 않습니다.
+2. 플랫폼이 제공하는 자격 판별 결과는 입력 정보 기반의 안내용이며, 법적 효력이 없습니다.
+3. 최종 지원금 심사 및 승인 여부는 소상공인시장진흥공단의 결정에 따릅니다.
+4. Re:Link는 지원금 수령을 보장하거나 확약하지 않습니다.
+5. 제출 서류의 진실성과 정확성에 대한 책임은 신청자 본인에게 있습니다.
+6. 허위 서류 제출 또는 부정 수급 시 관련 법령에 따라 환수 및 제재를 받을 수 있습니다.
+7. Re:Link는 세무·법률 전문가의 의견을 대체하는 자문을 제공하지 않습니다.
+
+### 8-2. 정부 승인 불보장 원칙
+
+플랫폼 내 어떤 화면, 메시지, 알림에서도 아래 표현을 사용하지 않는다.
+
+- "승인 보장", "합격 보장", "수령 확정"에 해당하는 표현
+- 승인 가능성을 구체적인 수치(%)로 제시하는 표현
+- 플랫폼 검토 완료가 정부 승인을 의미한다는 오해를 줄 수 있는 표현
+
+대신 아래 표현 기준을 따른다:
+
+- "서류 구비 완료", "제출 준비 완료"는 플랫폼 운영자의 서류 검토 완료를 의미함을 명시한다.
+- "제출 완료"는 사용자가 정부 포털에 직접 제출하였음을 기록한 것임을 명시한다.
+
+### 8-3. 개인정보 처리 원칙
+
+지원금 서비스에서 수집·처리하는 개인정보는 아래 원칙을 따른다.
+
+**수집 목적 한정:**
+
+- 희망리턴패키지 신청 보조 서비스 제공 목적으로만 사용한다.
+- 수집된 서류 및 정보는 마케팅, 제3자 제공에 활용하지 않는다.
+
+**보관 기간:**
+
+| 항목 | 보관 기간 | 근거 |
+|------|-----------|------|
+| 케이스 처리 내역 | 케이스 종료 후 5년 | 정부 감사 대비 |
+| 업로드 서류 원본 | 케이스 종료 후 3년 | 분쟁 대비 (법무 검토 후 조정) |
+| AuditLog | 최소 3년 | 운영 감사 기록 |
+
+실제 보관 기간은 개인정보보호법 및 관련 법령 검토 후 최종 확정한다. (법무 검토 필요)
+
+**접근 제한:**
+
+- 업로드 서류는 서명 URL(시간 제한 있는 임시 접근 링크) 방식으로 접근한다.
+- 운영자의 서류 열람은 AuditLog에 기록된다.
+- 케이스 신청자 본인 및 담당 `SUBSIDY_OPERATOR` 외에는 서류에 직접 접근하지 않는다.
+
+**사용자 권리:**
+
+- 케이스 종료 후 사용자는 업로드한 서류 삭제를 요청할 수 있다. (법정 보관 기간 내 서류는 즉시 삭제 불가)
+- 보관 기간 만료 시 서류를 자동 삭제한다.
+
+### 8-4. 법무 검토 필요 항목
+
+현재 초안 단계로, 아래 항목은 법무 검토 완료 전 운영하지 않거나 제한 운영한다.
+
+| 항목 | 현재 상태 | 법무 검토 후 조치 |
+|------|-----------|------------------|
+| 정부 포털 자동 제출 기능 | 구현 금지 | 법무 검토 + 소진공 협의 후 검토 |
+| 보관 기간 확정 | 잠정 기준 적용 | 개인정보보호법 해석 확인 후 확정 |
+| 대리 신청 가능 범위 | MVP에서 사용자 직접 제출만 허용 | 행정사법 등 검토 후 결정 |
+| 지원금 수수료 구조 | 미정 | 법적 대행 허용 범위 확인 후 결정 |
+
+---
+
+## 부록
+
+### A. 관련 문서
+
+| 문서 | 경로 |
+|------|------|
+| 개발 계획서 | `/DEVELOPMENT_PLAN.md` |
+| Prisma 스키마 초안 | `/docs/database/schema-prisma-draft.md` |
+| 베타 마스터 데이터 | `/docs/master-data/beta-master-data.md` |
+| 정보 공개 정책서 (예정) | `/docs/policies/data-exposure-policy.md` |
+| 계약-에스크로-분쟁 정책서 (예정) | `/docs/policies/contract-escrow-policy.md` |
+
+### B. 용어 정의
+
+| 용어 | 정의 |
+|------|------|
+| 지원금 대행 | MVP에서는 신청 보조 및 서류 검토 지원을 의미하며, 법적 대리 행위를 포함하지 않음 |
+| 자격 판별 | 사용자 입력 정보 기반의 자격 안내 (법적 효력 없음) |
+| 운영자 검토 | SUBSIDY_OPERATOR가 업로드 서류의 구비 완료 여부를 확인하는 행위 |
+| 제출 준비 완료 | 운영자가 서류 구비 상태가 충족되었다고 판단한 상태 (정부 승인 아님) |
+| 체크리스트 버전 | 정부 공고 기준으로 관리되는 필수/선택 서류 목록의 버전 |
+| PolicyVersion | 플랫폼 정책 기준 시점을 관리하는 내부 버전 테이블 |
+
+### C. 개정 이력
+
+| 버전 | 날짜 | 변경 내용 | 작성자 |
+|------|------|-----------|--------|
+| 1.0.0 | 2026-03-07 | 초안 작성 (MVP Phase 1 기준) | - |