# BOOTHPIN — 시나리오로 읽는 기능 명세

> 의뢰자께서 주신 기능 명세서는 **화면 단위 목록**이라, 각 버튼이 어떤 상황에서 왜 필요한지가 드러나지 않습니다.
> 이 문서는 명세서의 기능들을 **실제 사용 흐름에 배치**해, 하나하나가 어떤 필요를 푸는지 설명합니다.
> 괄호 안의 ①~⑱은 [데모](../index.html)의 화면 번호입니다.

---

## 0. 이 문서를 읽는 법

이 플랫폼은 **한 번의 행사가 열리고 끝나는 과정**을 담고 있습니다.
그 과정에는 두 사람이 있습니다 — **부스를 차리는 사람(셀러)** 과 **행사를 여는 사람(주최자)**.

명세서의 기능은 전부 이 둘 중 누군가가, 어느 시점에, 무엇이 답답해서 누르는 버튼입니다.
그래서 이 문서는 기능을 나열하지 않고 **시간순으로** 따라갑니다.

---

## 1. 등장인물 — 누가 이 앱을 쓰나

| | 셀러 (참가자) | 주최자 (개최자) |
|---|---|---|
| **누구** | 핸드메이드 작가, 푸드트럭, 소규모 브랜드, 농가 | 지자체·재단, 상권 조합, 카페·복합공간, 개인 기획자 |
| **원하는 것** | 팔 곳을 찾는 것. 좋은 자리, 맞는 손님 | 부스를 채우는 것. 좋은 셀러, 다양한 구성 |
| **불안한 것** | 신청했는데 연락이 없음 / 가 봤더니 사람이 없음 / 개인정보 노출 | 신청이 안 참 / 당일에 안 나타남 / 품목이 겹침 |
| **앱에서 하는 일** | 찾기 → 신청 → 대기 → 참여 | 열기 → 모집 → 심사 → 운영 |

**중요한 점:** 이 둘은 **다른 사람이 아닙니다.** 카페 사장이 자기 가게 앞 마켓을 열면서(주최자), 다른 동네 플리마켓엔 셀러로 나갑니다. 그래서 명세서의 홈 화면에 **"개최 행사관리"와 "참여 행사관리"가 나란히** 놓여 있습니다(①). 계정을 나누지 않고 역할을 오가는 구조입니다.

---

## 2. 전체 그림 — 한 번의 행사가 돌아가는 과정

```
                    [주최자]                          [셀러]
   D-30   행사 만들기 ③ ──────────────┐
                                       │  지도에 핀으로 노출 ⑩
   D-25                                └──────────────▶ 발견 → 정보 확인 ⑫
                                                          │
   D-20                       ┌────────────────────── 참여 신청 ⑬
                              │  (품목·소개·사진·옵션·결제)
   D-18   참여자 목록 ⑤ ◀─────┘
          → 상세 확인 ⑥ ── 승인 ──────────────▶ 승인 알림 ⑧
                          └ 거절(사유 40자) ──▶ 사유 확인 ⑧
   D-14   채팅방 개설 ⑮ ◀━━━━━━━━━━━━━━━━━━━▶ 공지 수신 ⑮
                              (배치·준비물·주차 안내)
   D-0    출석 QR 발급 ⑦ ──────────────────▶ QR 스캔 ⑨
          출석 체크 ⑤                          └ 참여 확정
   D+1    엑셀 다운로드 ⑤                     참여기록 발자국 ⑩
          (정산·이력 관리)                     등급 상승 ⑯
```

---

## 3. 시나리오 A — 셀러 "마루공방" 이야기

> 유리 테라리움을 만드는 1인 공방. 온라인 판매만 하다가 오프라인에 나가보려 합니다.

### 3-1. 처음 — "어디서 열리는지를 모르겠다"

**상황.** 플리마켓에 나가고 싶은데, 정보가 인스타그램·카페 공지에 흩어져 있습니다. 어디서 언제 열리는지 한눈에 보이지 않고, 알았을 땐 이미 마감입니다.

**쓰는 화면.** 지도 탐색 ⑩ · 근처 행사 ⑪

- **지도에 핀으로 표시** — "이번 주말 내 주변에 뭐가 열리나"는 목록보다 지도가 빠릅니다. 셀러에게 거리는 곧 이동 비용이라, 위치가 첫 번째 판단 기준입니다.
- **가까운 곳부터 정렬** — 짐이 많은 셀러에게 20km 차이는 참가 여부를 가릅니다.
- **행사 종류 필터** — 핸드메이드 작가에게 푸드페스티벌은 무의미합니다. 10종 분류가 여기서 쓰입니다.

> 이 기능이 없으면: 인스타를 매일 뒤져야 하고, 대부분 마감 후에 발견합니다.

### 3-2. 판단 — "나가도 되는 자리인가"

**상황.** 마음에 드는 마켓을 찾았습니다. 그런데 참가비가 3만원. 하루 매출이 그만큼 나올지, 내 품목이 어울리는 자리인지 알아야 합니다.

**쓰는 화면.** 행사 정보 보기 ⑫

- **모집 품목** — 여기에 '핸드메이드'가 있는지가 핵심입니다. 없으면 신청해도 떨어집니다.
- **모집 인원 + 현재 신청 수** — "40명 중 34명 신청"은 두 가지를 알려줍니다. 인기가 있다는 것, 그리고 서둘러야 한다는 것.
- **날짜·장소·참가비** — 다른 일정과 겹치는지, 이동 가능한지, 손익이 맞는지.
- **행사 소개 사진** — 작년 사진 한 장이 "사람이 오는 마켓인가"를 말해 줍니다.

> 이 기능이 없으면: 주최자에게 일일이 DM으로 물어봐야 합니다. 주최자도 같은 질문을 수십 번 받습니다.

### 3-3. 신청 — "내가 뭘 파는 사람인지 설명해야 한다"

**상황.** 신청하기로 했습니다. 그런데 주최자는 나를 모릅니다. 뽑히려면 내가 뭘 만드는지 보여줘야 합니다.

**쓰는 화면.** 참여 신청 ⑬

| 입력 항목 | 왜 필요한가 |
|---|---|
| **판매 품목 선택** | 주최자가 구성을 짤 때 씁니다. 액세서리만 20팀이면 마켓이 심심해지므로, 카테고리별로 균형을 맞춥니다. |
| **제품 한 줄 소개** | 주최자가 신청 목록을 훑을 때 보는 한 줄. 40명을 다 열어볼 수 없으니 목록에서 바로 판단할 근거가 필요합니다. |
| **판매할 품목 사진 (1~5장)** | 심사의 실질적 근거입니다. 글로는 다 좋아 보이지만 사진은 퀄리티를 그대로 보여줍니다. **최소 1장**은 심사를 위해, **최대 5장**은 업로드 부담과 검토 시간을 줄이기 위해. |
| **추가 옵션 (전기·테이블 등)** | 셀러는 조명이 필요하고, 주최자는 전기 수요를 **미리** 알아야 배치도를 그립니다. 당일에 "전기 있나요?"는 이미 늦습니다. |

- **프로필은 표시만, 수정 불가(상호작용 X)** — 명세서에 이렇게 되어 있는 이유는, 신청 시점의 프로필이 **심사 근거로 고정**되어야 하기 때문입니다. 신청 후 프로필을 바꾸면 주최자가 본 것과 달라집니다.

> 이 기능이 없으면: 주최자가 "사진 좀 보내주세요"를 40번 반복하고, 셀러는 카톡으로 파일을 보냅니다.

### 3-4. 대기 — "연락이 없다"

**상황.** 신청하고 사흘이 지났습니다. 됐는지 안 됐는지 모르니 다른 마켓 신청도 못 합니다.

**쓰는 화면.** 참여 행사관리 ⑧

- **승인 / 대기 / 거절 상태 표시** — 셀러에게 가장 답답한 구간입니다. 상태 한 줄이 다른 일정을 잡을지 말지를 결정합니다.
- **거절 사유 40자** — 이게 명세서에서 인상적인 부분입니다. 그냥 "거절"만 뜨면 셀러는 이유를 모른 채 다음에도 같은 이유로 떨어집니다. **"반려동물 품목이 아니어서"** 라는 한 줄이 있으면 다음엔 맞는 행사에 신청합니다.
- **거절 건은 상호작용 없음** — 항의·재신청 창구를 열면 주최자 업무가 폭증합니다. 사유만 전달하고 끝내는 것이 양쪽 모두에 낫습니다.

> 이 기능이 없으면: "저 됐나요?" DM이 주최자에게 쏟아집니다.

### 3-5. 준비 — "뭘 챙겨가야 하나"

**상황.** 승인됐습니다. 그런데 몇 시까지 가야 하는지, 주차는 되는지, 테이블은 주는지 모릅니다.

**쓰는 화면.** 채팅방 ⑮

- **행사별 단체 채팅방** — 공지가 여러 번, 여러 명에게 나갑니다. 개별 연락은 불가능하고 문자는 안 읽힙니다.
- **참가자 목록 → 프로필 보기** — 누가 같이 나오는지 궁금합니다. 옆 부스가 뭘 파는지 알면 품목이 겹치는지, 손님 흐름이 어떨지 가늠됩니다. 실제로 셀러끼리 미리 인사하고 물물교환도 합니다.

> 이 기능이 없으면: 오픈채팅방을 따로 파야 하고, 참가자 명단은 관리되지 않습니다.

### 3-6. 당일 — "왔다는 걸 증명해야 한다"

**상황.** 아침 9시, 짐을 들고 도착했습니다. 접수 데스크에 줄이 길게 서 있습니다.

**쓰는 화면.** QR 출석 체크 ⑨

- **QR 스캔으로 출석** — 이름 대조는 한 명당 30초, 60팀이면 30분입니다. 그동안 설치가 밀립니다.
- **(제안) 오프라인 동작** — 명세서에는 없지만, 행사장은 수백 명이 동시 접속해 네트워크가 가장 먼저 죽는 곳입니다. 승인 명단을 미리 받아두고 오프라인에서 처리한 뒤 나중에 동기화하도록 했습니다.

> 이 기능이 없으면: 종이 명단에 체크하고, 그 종이를 나중에 엑셀로 옮겨 적습니다.

### 3-7. 이후 — "다음에도 나가고 싶다"

**상황.** 마켓이 끝났습니다. 매출도 괜찮았고 다음에도 나가고 싶습니다.

**쓰는 화면.** 마이프로필 ⑯ · 지도의 참여기록 ⑩

- **참여기록 발자국** — 내가 다녀온 곳이 지도에 남습니다. 실용적 기능은 아니지만(명세서에도 상호작용 X), **활동의 흔적**이 보이는 것 자체가 재방문 동기가 됩니다.
- **등급 상승** — 참여할수록 등급이 오릅니다. 셀러에게는 성취감이고, **주최자에게는 신뢰 지표**입니다. "다이아 등급이면 여러 번 해본 사람이구나."
- **포트폴리오 누적** — 참여할수록 보여줄 것이 쌓이고, 다음 심사에서 유리해집니다.

> ⚠️ 다만 현재 등급 규칙은 그대로 계산되지 않습니다 — [등급 진단 ⑰](../index.html) 화면과 [기획_설계.md](기획_설계.md) 2장 ③ 참조.

---

## 4. 시나리오 B — 주최자 "성수문화재단" 이야기

> 성수동 광장에서 봄 플리마켓을 엽니다. 부스 40개를 채워야 합니다.

### 4-1. 모집 개설 — "어떤 마켓인지 정확히 알려야 한다"

**상황.** 날짜와 장소는 정해졌습니다. 이제 셀러를 모아야 하는데, 아무나 오면 안 됩니다. 성수동 감성에 맞는 구성이 필요합니다.

**쓰는 화면.** 행사 만들기 ③

| 입력 항목 | 왜 필요한가 |
|---|---|
| **행사 종류 (10종)** | 셀러의 필터 기준입니다. '플리마켓'으로 등록하면 플리마켓을 찾는 셀러에게 노출됩니다. |
| **모집 판매품목 (중복 선택)** | **이 마켓의 성격을 정의합니다.** 핸드메이드·패션·푸드만 열어두면 그 셀러들만 신청합니다. 사전 필터링 장치입니다. |
| **모집 인원** | 부스 개수는 물리적으로 정해져 있습니다. 초과 신청을 받아 심사할지, 선착순 마감할지의 기준. |
| **장소 (주소 + 상세)** | 주소는 **지도 핀 좌표**가 되고, 상세주소("광장 동편")는 당일 셀러가 찾아오는 데 씁니다. 용도가 다릅니다. |
| **참가비 + 추가 옵션** | 운영비 충당. 옵션을 분리한 이유는 **필요한 사람만 내게** 하기 위함입니다. 전기 안 쓰는 셀러에게 전기료를 걷으면 참가율이 떨어집니다. |
| **소개 사진·설명** | 셀러 모집을 위한 홍보물입니다. 작년 사진이 있으면 신청률이 확실히 다릅니다. |

### 4-2. 심사 — "40명 중 누구를 뽑을까"

**상황.** 34팀이 신청했습니다. 부스는 28개. 다 받을 수 없고, 품목이 겹치지 않게 골라야 합니다.

**쓰는 화면.** 참여자 목록 ⑤ → 참여자 상세 ⑥

- **목록에서 보이는 것** — 닉네임, 등급, 판매 품목, 한 줄 소개. 34명을 빠르게 훑으며 **1차 분류**를 합니다. 여기서 등급이 신뢰 필터로 작동합니다.
- **클릭하면 보이는 것** — 실명, 나이, 품목 사진, 포트폴리오, 추가 옵션 여부. **최종 판단**을 위한 정보입니다.
- **왜 실명·나이가 필요한가** — 이건 계약 관계이기 때문입니다. 참가비를 받고 자리를 배정하는 거래이므로 상대가 누구인지 알아야 하고, 사고 발생 시 연락이 닿아야 합니다. 다만 **다른 셀러에게는 공개되지 않습니다**(명세서의 "개최자만 볼 수 있음").
- **추가 옵션 여부** — 심사와 동시에 **배치 계획**을 세웁니다. 전기 신청자는 전원 가까운 A구역으로 묶어야 합니다.
- **승인 / 거절(사유 40자)** — 거절 사유를 쓰게 한 것은 셀러를 위한 배려이면서, 동시에 **주최자 자신을 위한 기록**이기도 합니다. "왜 떨어뜨렸더라"를 나중에 확인할 수 있습니다.

> 이 기능이 없으면: 카톡·메일·인스타 DM에 흩어진 신청서를 엑셀로 옮겨 적으며 심사합니다.

### 4-3. 소통 — "같은 말을 28번 하고 싶지 않다"

**상황.** 28팀이 확정됐습니다. 이제 설치 시간, 주차, 배치도, 우천 시 대응을 안내해야 합니다.

**쓰는 화면.** 채팅방 ⑮

- **승인자 자동 초대** — 승인과 동시에 채팅방 멤버가 됩니다. 별도로 연락처를 모으고 오픈채팅 링크를 뿌리는 과정이 사라집니다.
- **행사별로 분리** — 여러 행사를 동시에 운영하면 방이 섞입니다. 명세서에서 채팅 목록을 "개최/참여한 행사목록"으로 정의한 이유입니다.

### 4-4. 당일 운영 — "누가 왔고 누가 안 왔나"

**상황.** 행사 당일 아침. 28팀이 순서대로 도착합니다. 그런데 9시 반이 지나도 안 오는 팀이 있습니다.

**쓰는 화면.** 출석 QR 발급 ⑦ → 참여자 목록 출석 체크 ⑤

- **QR 발급·인쇄** — 데스크에 붙여두면 셀러가 알아서 스캔합니다. 접수 인력이 줄어듭니다.
- **출석 버튼 (한 번 더 누르면 취소)** — QR을 못 쓰는 셀러(폰 배터리, 앱 미설치)는 운영자가 수동 체크합니다. **취소 기능은 오조작 대비**입니다. 현장은 정신없고 옆 사람을 잘못 누릅니다.
- **실시간 출석 현황** — "21/28 출석"이 보이면 **빈 부스를 파악**해 자리를 재배치하거나 대기 셀러를 부를 수 있습니다.

### 4-5. 마무리 — "정산하고 기록을 남긴다"

**상황.** 행사가 끝났습니다. 정산 보고서를 써야 하고, 다음 회차 준비도 해야 합니다.

**쓰는 화면.** 참여자 목록 → 엑셀 다운로드 ⑤

- **엑셀 다운로드** — 참가비 정산, 지자체 보고, 다음 회차 셀러 풀 관리에 씁니다. 앱 안에서만 볼 수 있으면 실무에서 쓸 수 없습니다.
- **출석 데이터** — 누가 왔고 안 왔는지가 남습니다. **다음 회차 심사의 근거**가 됩니다.

> ⚠️ 명세서에는 출석 기록 **이후의 흐름이 없습니다.** 노쇼 셀러에 대한 조치가 없으면 출석 체크는 단순 기록으로 끝납니다 — [기획_설계.md](기획_설계.md) 2장 ⑤ 참조.

---

## 5. 두 사람이 만나는 지점

명세서의 기능 중 **양쪽이 같은 데이터를 다르게 보는** 지점들입니다. 개발 시 가장 주의해야 할 부분입니다.

| 데이터 | 셀러가 보는 것 | 주최자가 보는 것 |
|---|---|---|
| **프로필** | 내 정보 (수정 가능) | 심사 대상 (실명·나이 포함, 수정 불가) |
| **신청서** | 작성 폼 | 심사 카드 |
| **참여자 목록** | 같이 나가는 사람들 (프로필·등급·품목만) | 관리 대상 (+ 실명·나이·출석·승인 버튼) |
| **QR** | 스캔하는 쪽 (카메라) | 발급·인쇄하는 쪽 |
| **거절 사유** | 읽기만 (상호작용 X) | 작성 (40자 제한) |
| **채팅방** | 공지 받는 쪽 | 공지 보내는 쪽 |

**핵심:** 같은 "참여자 목록" 화면이지만 **역할에 따라 보이는 항목이 다릅니다.** 명세서에도 개최 행사관리의 참여자 목록에는 실명·나이·승인버튼이 있고, 참여 행사관리의 참여자 목록에는 없습니다. 이 차이가 권한 설계의 핵심입니다.

---

## 6. 기능별 존재 이유 — 명세서 전수 매핑

| 명세서 기능 | 누가 | 언제 | 어떤 필요 |
|---|---|---|---|
| 홈 4버튼 | 둘 다 | 진입 시 | 한 사람이 두 역할을 오가므로 입구를 나눔 |
| 셀러 등록 | 셀러 | 최초 1회 | 신청할 때마다 같은 정보를 다시 쓰지 않기 위해 |
| 실명·나이 (개최자만) | 셀러 | 등록 시 | 거래 상대 확인은 필요하되, 불특정 다수 노출은 방지 |
| 연락처 (비공개) | 셀러 | 등록 시 | 당일 긴급 연락용. 평상시엔 열 이유가 없음 |
| 포트폴리오 | 셀러 | 등록·심사 | 심사 근거이자 셀러의 자산. 참여할수록 쌓임 |
| 행사 만들기 | 주최자 | 모집 시작 | 흩어진 공지를 한 곳에 |
| 행사 종류 10종 | 주최자 | 등록 시 | 셀러의 탐색 필터 기준 |
| 모집 품목 (중복) | 주최자 | 등록 시 | 마켓 성격 정의 + 사전 필터링 |
| 추가 옵션 | 둘 다 | 등록·신청 | 필요한 사람만 부담 + 주최자의 배치 계획 근거 |
| 지도 핀 | 셀러 | 탐색 | 거리 = 이동 비용. 첫 번째 판단 기준 |
| 근처 순 정렬 + 필터 | 셀러 | 탐색 | 내게 맞는 행사만 빠르게 |
| 참여기록 발자국 | 셀러 | 상시 | 활동 흔적. 재참여 동기 (상호작용 없는 이유) |
| 행사 정보 보기 | 셀러 | 판단 | DM 문의를 대체 |
| 참여 신청 | 셀러 | 신청 | 심사에 필요한 정보를 구조화해 수집 |
| 품목 사진 1~5장 | 셀러 | 신청 | 최소 1장=심사 근거 / 최대 5장=검토 부담 관리 |
| 참여자 목록 | 주최자 | 심사·당일 | 1차 스캔용 요약 |
| 참여자 상세 | 주최자 | 심사 | 최종 판단용 전체 정보 |
| 승인 / 거절 | 주최자 | 심사 | 부스 수 제한 + 구성 균형 |
| 거절 사유 40자 | 주최자 | 심사 | 셀러의 다음 기회 + 주최자의 기록 |
| 출석 QR 발급·인쇄 | 주최자 | 당일 | 접수 병목 해소 |
| QR 스캔 | 셀러 | 당일 | 줄 서지 않기 |
| 출석 버튼 (재클릭 취소) | 주최자 | 당일 | QR 실패 대비 + 현장 오조작 복구 |
| 엑셀 다운로드 | 주최자 | 사후 | 정산·보고·다음 회차 관리 |
| 채팅방 | 둘 다 | 준비~당일 | 1:N 공지. 개별 연락 불가능 |
| 채팅방 참가자 보기 | 둘 다 | 준비 | 옆 부스 파악 (품목 중복·손님 흐름) |
| 등급 | 둘 다 | 상시 | 셀러=동기 / 주최자=신뢰 필터 |

---

## 7. 시나리오를 그려보니 비는 구멍 — 미팅에서 확인 필요

기능을 흐름에 배치해 보니, **명세서에 정의가 없어 개발 중 막히는 지점**들이 보입니다.
아래는 답이 정해져야 개발을 시작할 수 있는 것들입니다.

### ① 후기·평가가 없습니다 — 등급이 신뢰 지표로 작동하지 않습니다

현재 등급은 **참여 횟수만으로** 결정됩니다. 그러면 매번 지각하고, 자리를 어지럽히고, 일찍 철수하는 셀러도 **참여만 하면 등급이 올라갑니다.** 주최자가 등급을 보고 심사하는데, 그 등급이 "성실함"이 아니라 "출석 횟수"만 뜻한다면 신뢰 필터로 쓸 수 없습니다.

> **확인 필요:** 행사 종료 후 주최자가 셀러를 평가하는 절차를 넣을지? (별점 또는 재초대 의향 정도의 가벼운 형태)

### ② 행사가 취소되면 어떻게 되나요

우천·행정 사유로 행사가 취소되는 일은 드물지 않습니다. 그런데 명세서에는 **행사 취소 기능 자체가 없습니다.**

> **확인 필요:** 취소 시 참가비 환불 처리, 승인된 셀러 일괄 통보, 채팅방 처리를 어떻게 할지?

### ③ 셀러가 승인 후 못 가게 되면

승인받고 나서 사정이 생기는 경우입니다. 명세서에는 **셀러의 참여 취소 기능이 없습니다.** 그냥 안 가면 노쇼로 기록됩니다.

> **확인 필요:** 참여 취소 기능을 넣을지, 넣는다면 환불 기준(D-7/D-3/당일)과 취소 이력이 등급에 반영될지?

### ④ 모집 마감은 언제, 어떻게

"모집 인원 40명"이 다 차면 자동으로 마감되는지, 날짜가 지나면 마감인지, 주최자가 수동으로 닫는지 정의가 없습니다. 초과 신청을 받아 심사할 수도 있습니다(34명 신청 → 28명 승인).

> **확인 필요:** 선착순 자동 마감 / 초과 신청 후 심사 / 주최자 수동 마감 중 어느 방식인지?

### ⑤ 참가비 정산은 언제 주최자에게 가나요

셀러가 결제한 참가비가 **언제** 주최자에게 넘어가는지가 정해져야 합니다. 신청 즉시라면 거절된 셀러 환불이 복잡해지고, 행사 후라면 주최자가 운영비를 먼저 써야 합니다.

> **확인 필요:** 승인 시점 / 행사 종료 후 정산 중 어느 쪽인지? (PG 구조 설계가 여기서 갈립니다 — [기획_설계.md](기획_설계.md) 2장 ①)

### ⑥ 채팅방은 언제까지 남나요

행사가 끝나도 방이 계속 남으면 목록이 쌓입니다. 반대로 바로 닫으면 사후 정산 문의를 할 곳이 없습니다.

> **확인 필요:** 행사 종료 후 N일 뒤 자동 보관 처리?

### ⑦ 신고·차단이 없습니다

단체 채팅방이 있는 이상 문제 상황이 생깁니다. 광고 도배, 시비, 부적절한 언행. 명세서에는 **신고 기능도, 운영자 권한도 없습니다.**

> **확인 필요:** 채팅 신고 / 셀러 신고 / 플랫폼 운영자(주최자와 별개)의 제재 권한을 넣을지?

### ⑧ 플랫폼 운영자 화면이 없습니다

명세서의 "관리자"는 **행사 주최자**를 뜻합니다. 그런데 서비스 전체를 관리하는 사람 — 부적절한 행사 삭제, 회원 제재, 정산 확인, 통계 — 의 화면이 없습니다.

> **확인 필요:** 플랫폼 운영자용 웹 백오피스가 1차 범위에 포함되는지? (별도 개발 공수가 발생합니다)

---

## 8. 정리

명세서의 기능은 **거의 모두 명확한 필요에서 나온 것**이었습니다. 특히 다음 세 가지는 실무를 아는 분이 설계했다는 인상을 줍니다.

- **거절 사유 40자** — 셀러의 다음 기회를 배려한 설계
- **실명·나이를 개최자에게만** — 신뢰와 프라이버시의 균형점
- **출석 버튼 재클릭 취소** — 현장 오조작을 예상한 설계

다만 **행사가 정상적으로 진행되는 흐름**에 집중되어 있어, 취소·이탈·분쟁 같은 **예외 상황의 정의가 비어 있습니다**(7장). 이 부분은 개발 중에 반드시 마주치므로, 착수 전에 정리해 두면 일정이 흔들리지 않습니다.

---

**관련 문서**
- [기획_설계.md](기획_설계.md) — 니즈 분석, 법적·운영 리스크 6건, 견적 산정 근거
- [기능명세(의뢰자 원본).txt](../기능명세(의뢰자%20원본).txt) — 원본 명세서 전사
- [데모](../index.html) — 18개 화면 실제 동작