# 킨텍스 AI 전시·행사시스템 (KINTEX AI Exhibition & Event System) 기획서

> 작성: 기획 에이전트(planner) · 작성일: 2026-07-11 · 최종 갱신: 2026-07-12 · 버전: **v3.4**
> **제품 공식 명칭(소유자 확정 2026-07-12): "KINTEX AI 전시·행사시스템"** — 기존 "자동전시시스템(Exhibition Automation Platform)"을 대체한다. 전시(exhibition)뿐 아니라 행사·이벤트(event) 전반을 포괄한다는 의미를 명칭에 반영. 본 명칭이 정본이며, 이하 본문·3-트랙 기획·타 문서 후속 반영 시 이 명칭을 사용한다(기존 "자동전시시스템" 표기는 문맥 보존을 위해 삭제하지 않고 잔존하나, 신규 표기는 정본 명칭을 따른다).
> 근거 문서: `docs/analysis/kintex-website.md` (킨텍스 웹사이트 25개 페이지 + 전시주최자매뉴얼 PDF + 참가업체 매뉴얼 PDF 전수 분석, 2026-07-11)
> 근거 문서: `docs/analysis/coex-website.md` (코엑스 VISITOR/BUSINESS/CYBER 3-사이트 IA 분석 + 킨텍스 대비표, 2026-07-12) — §2-2 대외 접점 3-트랙 재구성 확정 근거
> 근거 문서: `docs/analysis/reroomai-source.md` (ReRoomAI 이미지 파이프라인 소스 분석, 2026-07-11) — 6장 나노바나나 파이프라인 제어 파라미터 확정 근거
> 근거(글로벌 벤치마크, 2026-07-11 크롤링): Eventleaf·VenueSight·Whova·ExpoPlatform(전시관리·부스판매·리드캡처), Eventbase·Pointr·Swapcard·Brella·Grip(wayfinding·비즈매칭), RainFocus·Bizzabo(등록·리벤뉴), ExhibitForce·Ways·FinancialModelsLab·Digitevent(전시 BI/KPI), FindRFP·Procore·4castplus(RFQ/Tender/역경매). 각 §5 모듈에 매핑.
>
> **v2.0 정체성 확장**: 본 시스템은 "부스 시공 도구"를 넘어 **킨텍스 자동전시시스템(Exhibition Automation Platform)** 이다 — 전시 기획·판매·시공·운영·관람객·사후분석 전 주기를 아우른다. 기존 M2~M5 부스 시공 코어(P0)·나노바나나 파이프라인(§6)·확정 스택(§8)은 **보존**하고, 그 위에 관람객/비즈매칭/마케팅·공개사이트/wayfinding/현장운영/공사 옥션/BI/CMS/관리자 모듈(M10~M18)을 확장한다.
> **v3.0 정체성 확장 — 다중 전시관 SaaS**: 본 시스템은 **킨텍스 전용에서 다중 전시관(Venue) 멀티테넌트 SaaS**로 확장한다. 킨텍스(KINTEX)는 **기준 테넌트(테넌트 #1)** 로 유지되고, 코엑스(COEX) 등 여타 전시관을 테넌트로 온보딩한다. 기능(M1~M18·§5B·§6 나노바나나·§8 확정 스택)은 **전부 보존**하고, 그 위에 **테넌트 격리 레이어(tenant_id 전파·컨텍스트 해소·역할 계층)** 만 얹는다 — 기능은 그대로, 데이터·권한·컨텍스트가 전시관 단위로 분리된다. 상세는 **§1A**, 격리 전략은 **§8-2**.
> **v3.2 대외 접점 3-트랙 재구성**: 코엑스(COEX) IA 분석(3-사이트 분리: VISITOR/BUSINESS/CYBER)을 근거로, 대외 접점을 **visitor(관람객) / business(비즈니스=주최자·참가업체) / agency(에이전시=공사·장치·협력사)** 3개 트랙으로 분리·재편한다. 기존 6역할·7페르소나(§2)·포털 매트릭스(§2-1)·모듈(M1~M18)·화면(SCR-*)은 **전부 보존**하고, 그 위에 **트랙 셸(track shell) — 랜딩 3-분기 + 트랙별 서브홈 + 트랙-스코프 로그인 후 홈** IA 레이어만 얹는다. 상세는 **§2-2**(내부 역할 ops·admin은 대외 트랙 외부에 그대로 유지).
> **v3.4 AI 사용성 & 토큰 최소화**: 소유자 지시(2026-07-12) — "AI 기능을 쉽게 사용하도록 기획 + 토큰을 최소한으로 사용하는 방식 채용". 산재해 있던 AI 규약을 **§8A**로 명문화한다 — ① AI 사용성 표준(전 화면 인라인 진입점·예시 질문 칩·원탭 액션·다음 명령 제시·구조화 카드+근거 인용·대화 히스토리·다국어/모바일/음성) ② 토큰 최소화 6원칙(결정론 우선 라우팅으로 LLM 우회·소형모델 우선 티어링·RAG 발췌로 프롬프트 축소·캐싱·출력 상한/구조화·집계는 SQL) ③ 측정지표·목표 ④ design/개발 계약 포인트. 기존 스코프(§5B 공통 AI·§6 나노바나나·§8 스택·§8-2 격리)·화면·라우트 보존, 원칙·계약·지표만 순증. M10 관람객 AI 도우미·M16 BI·§5B 공통 AI 보조에 §8A 링크. 이미 진행 중(visitor-assistant DB 근거 응답·AiTextRouter Claude→Ollama 폴백)과 정합(재발명 아님·표준화). src·design.md 미수정(designer/backend 후속).
> **v3.3 로그인 사용자 구분 → 메인페이지·메뉴 그룹 결정 규칙**: 소유자 확정(2026-07-12) — **"로그인한 사용자의 사용자 구분으로 메인페이지가 결정되고, 좌측 메뉴 그룹도 결정된다."** §2-2의 3-트랙(visitor/business/agency) + 내부 역할(ops/admin) 위에, **미인증 기본 진입 = visitor 공개 관람 랜딩**, **인증 후 역할별 전용 메인**(business 메인·agency 메인·visitor 메인은 신규 화면 — designer Stitch 의뢰, admin/내부 = 관리 메인 또는 비즈니스 메인+시스템관리)과 **트랙별 좌측 메뉴 그룹 노출/숨김**을 결정하는 규칙을 **§2-3**에 확정한다. 기존 §2·§2-2·화면(SCR-*)·라우트는 보존(안 B 정합), 결정 규칙·트랙 메인 화면 목록만 순증. src·design.md 미수정(frontend·designer 후속).
> **문서 소유권**: 본 PLANNING.md는 planner만 수정한다. design.md·타 문서는 이 문서 변경 시 "designer/planner 후속 반영 필요"로만 표기하고 직접 수정하지 않는다.

---

## 1. 개요 및 비전

### 1-1. 배경

킨텍스는 총 전시면적 108,011㎡(국내 최대, 2028년 제3전시장 완공 시 178,000㎡)를 운영하지만, 전시 준비 실무는 여전히 **HWP 서식 다운로드 → 이메일/방문 제출**, **CAD 수작업 배치도 → 홀매니저 육안 검수**, **수기 위치표시도 기반 유틸리티 신청**에 머물러 있다. 온라인 작업신고 시스템(kxwp.kintex.com)이 존재하나 로그인 기반 서류 업로드 창구 수준이며, 참가업체 유틸리티 신청은 킨텍스 공통 플랫폼 없이 전시회별 주최자 사무국 시스템(예: 코리아팩)에 파편화되어 있다.

### 1-2. 비전

**"신청서를 내는 순간, 시공 후 사진을 먼저 본다."**

전시장 운영 전 과정(홀 배정 → 부스 배치 → 장치공사 설계 → 전기/조명 → 네트워크/유틸리티 배선 → 반입/반출)을 AI로 자동 설계·검증하고, 그 결과를 **나노바나나(Gemini 이미지 생성 모델)로 '공사 후 결과 사진'처럼 시공 전에 미리 생성해 보여주는** 것이 본 시스템의 핵심 차별화다.

기존 전시관리 솔루션(부스 배치 SW, 온라인 신청 포털)은 도면과 표를 보여준다. 본 시스템은 **주최자·참가업체가 도면을 읽지 못해도 의사결정할 수 있는 사진 수준의 시각화**를 제공한다.

### 1-2-1. v2.0 비전 재정의 — 킨텍스 자동전시시스템

부스 시공 시각화(P0)는 여전히 심장이지만, v2.0에서 본 시스템은 전시 생애주기 전체를 하나의 데이터·계정 체계로 자동화하는 **베뉴 운영 플랫폼(Venue Operating Platform)** 으로 확장된다. 글로벌 전시테크(ExpoPlatform·VenueSight·Swapcard·RainFocus 등)가 제공하는 기능을 킨텍스 도메인에 이식하되, **킨텍스만의 차별점 — 실측 공간 데이터(PostGIS) + 나노바나나 시공 예측 이미지 — 을 관통시켜** 다른 전시테크가 하지 못하는 "설계→시각화→발주(옥션)→시공→운영→분석"의 폐루프를 완성한다.

| 생애주기 단계 | 담당 모듈 | v1.x 대비 |
|---|---|---|
| 판매·기획 | M1(홀 배정·견적), M16(BI 수요예측·수율) | M16 신규(BI 승격) |
| 설계·시각화 (**심장, 불변**) | M2 배치 · M3 부스설계 · M4 배선 · **M5 나노바나나** | 보존 |
| 발주·계약 | M6 서류, M7 등록업체, **M15 공사/장치 옥션(입찰)**, M9 정산 | M15 신규(옥션 핵심) |
| 참가·관람 | M10 관람객 등록·배지·리드캡처, M11 비즈매칭, M12 마케팅·공개사이트, M13 wayfinding | 전부 신규 |
| 현장 운영 | M8 물류, M14 현장운영(혼잡·안전·주차·에너지) | M14 신규 |
| 사후·경영 | M16 BI(이벤트 P&L·리텐션·KPI), M17 CMS, M18 관리자 | 전부 신규 |

이 폐루프의 핵심 연결고리가 **M15 공사/장치 옥션**이다: M2~M5가 생성한 AI 설계·물량·시공 예측 이미지가 곧 **역경매(reverse auction) 응찰의 근거 자료**가 되어, 참가업체/주최자가 사진 수준 자료를 보고 시공 발주까지 한 흐름에서 종결한다.

### 1-3. 목표 (정량)

| 목표 | 현재 (As-Is) | 목표 (To-Be) | 근거 |
|---|---|---|---|
| 홀 배정 견적 회신 | 문의→협의→견적 수일 | 즉시 자동 견적 (2,250원/㎡ × 성수기/전시장 규칙) | 요율이 규칙화 가능 |
| 부스 배치도 초안 작성 | 주최자 CAD 수작업 수일~수주 | 조건 입력 후 수 분 내 복수 안 생성 | 홀 규격(63×171m 등) 공개 |
| 도면 규정 검수 | 홀매니저 육안 검토 | 규정 위반 자동 플래깅(높이 5m, 방염 등) 후 사람 확정 | 규정이 수치화되어 있음 |
| 유틸리티 위치표시도 | 참가업체 수기 작도 | 부스 좌표 클릭 → 자동 배선안 + 자동 견적 | 트렌치 위치·단가 공개 |
| 시공 결과 예측 | 불가(조감도 별도 외주) | 표준 샷 세트 자동 생성(부스 정면/야간 조명/통로 뷰) | 나노바나나 파이프라인 |

### 1-4. 범위 제외 (Non-Goals)

- 킨텍스 임대계약 자체의 법적 체결(전자계약)은 Phase 3 이후 검토 — 초기에는 견적·서류 준비까지만.
- 구조계산서의 **구조 안전성 판정 자체를 AI가 대신하지 않는다.** (규정 항목 체크·누락 검출까지만, 최종 판정은 구조기술사/킨텍스)
- 관람객 대상 서비스(주차·티켓)는 P2 부가 범위.
- **멀티테넌시(§1A)는 데이터·권한 격리 레이어**이며, 전시관별 신규 도메인 로직(전시관 고유 규정 파서 등) 자동 생성은 Non-Goal — 새 전시관 온보딩은 마스터데이터 입력(§1A-5·§8-2) 수준까지.

---

## 1A. 멀티테넌시 (다중 전시관 SaaS) — v3.0

> **핵심 원칙**: 기능·화면·모듈(M1~M18)·나노바나나 파이프라인(§6)·확정 스택(§8)은 **전부 보존**한다. v3.0이 더하는 것은 **① 테넌트(전시관) 모델 ② 전 도메인 엔티티 `tenant_id` 전파와 격리 ③ 테넌트 컨텍스트 해소 ④ 플랫폼/테넌트 2계층 관리자 역할 ⑤ 기존 데이터의 테넌트 #1(KINTEX) 백필**뿐이다. 즉 "무엇을 하는가"는 그대로, "누구의 데이터인가(전시관 단위)"만 분리된다.

### 1A-1. 테넌트 = 전시관(Venue) 모델

**테넌트가 곧 전시관이다.** KINTEX = 테넌트 #1(기준), COEX = 테넌트 #2, … 신규 전시관은 테넌트 #N으로 온보딩. 테넌트 마스터를 **최상위 스코프**로 신설하고, 기존 마스터데이터(홀·요율·규정 룰셋·부스 표준)를 **테넌트 소유(tenant-owned)** 로 재정의한다.

| 테넌트 마스터 필드 | 내용 | 예 |
|---|---|---|
| `tenant_code` | 전시관 식별 코드(불변) | `KINTEX`, `COEX` |
| `tenant_name` | 전시관 명칭(다국어) | 킨텍스 / KINTEX, 코엑스 / COEX |
| `branding` | 로고·색상·테마 토큰(공유 디자인시스템 위 테넌트 오버라이드) | 로고 URL·프라이머리 컬러 (designer 후속 반영) |
| `domain` / `subdomain` | 접속 도메인(§1A-3 컨텍스트 해소 키) | `kintex.wise.ai.kr`, `coex.wise.ai.kr` |
| `active` | 활성/비활성(온보딩 중·종료 테넌트 게이트) | true/false |
| `locale_default` | 기본 로케일·통화·시간대 | ko-KR / KRW / Asia/Seoul |

**테넌트 소유 마스터데이터(§7-1 재정의)**: 홀 마스터·요율표·유틸리티 요금·규정 룰셋·부스 표준·등록업체 DB는 **각 전시관이 소유**한다. 킨텍스 홀1~10(§7-1 실측값)은 **테넌트 #1의 자산**이고, 코엑스 홀(A~D홀 등)은 테넌트 #2의 자산으로 별도 등록된다. 즉 §7-1의 킨텍스 실측 마스터는 **테넌트 #1의 초기 시드**로 위치가 재정의되며, 요율(2,250원/㎡ 등)·규정(높이 5m·리깅 6.5~8.5m 등)도 전시관마다 다른 값을 가질 수 있다(코엑스 실측값은 미확보 — 온보딩 시 입력, 근거 없는 추정 금지).

### 1A-2. `tenant_id` 전파 및 테넌트 격리

**전 도메인 엔티티에 `tenant_id`(FK → 테넌트 마스터)를 추가**하고, 모든 조회/쓰기를 `tenant_id`로 스코프한다(횡단 접근 원천 차단).

| 구분 | 대상 | tenant_id 처리 |
|---|---|---|
| **테넌트 스코프(격리)** | Event·Hall·Booth·DesignPlan·UtilityOrder·RenderJob·Document·Payment · Auction·Quotation·Award · Visitor·Registration·Badge·CheckIn·Lead·Meeting · KpiSnapshot·Content·Microsite · Company(등록업체) · User membership·Role 매핑·AuditLog · MasterData(홀·요율·요금·룰셋·부스표준) | 전 행에 `tenant_id` 컬럼, 전 쿼리 `WHERE tenant_id = :ctx` 강제(§8-2) |
| **전역 참조(공유)** | 시스템 공통코드 중 도메인 불변분(국가·통화·언어 코드 등), 플랫폼 설정 | `tenant_id` 없음(전역) 또는 `tenant_id IS NULL` = 전역 + 테넌트 오버라이드 |
| **테넌트 스코프 참조** | 공종 14분류·유틸리티 요금코드·부스유형 등 전시관마다 다를 수 있는 코드 | `tenant_id` 부여(전역 기본값을 테넌트가 오버라이드) |

- **격리 규칙(불변)**: 어떤 사용자도 자신이 소속되지 않은 테넌트의 데이터를 **조회·수정·검색·집계할 수 없다**(예외 = 플랫폼 슈퍼관리자, §1A-4). 행사(Event) 단위 RBAC(§2)는 **테넌트 내부로 스코프**된다 — 즉 "행사 격리 ⊂ 테넌트 격리"의 2중 구조.
- **공용 참조 구분**: 코드성 데이터는 "전역(플랫폼 표준) vs 테넌트 오버라이드"를 구분한다. 예: 공종 14분류는 킨텍스 기준을 전역 기본값으로 두되, 전시관이 분류 체계를 달리하면 테넌트 스코프로 오버라이드.
- **크로스-테넌트 집계**: M16 BI의 전 테넌트 통합 지표는 **플랫폼 슈퍼관리자 전용**이며 별도 권한 게이트로만 접근(테넌트 관리자는 자기 전시관 범위만).

### 1A-3. 테넌트 컨텍스트 해소 (Tenant Context Resolution)

요청마다 **어느 테넌트인가**를 판별해 컨텍스트에 주입한다(§8-2 필터 계층).

1. **서브도메인 우선**: `kintex.wise.ai.kr` → 테넌트 #1, `coex.wise.ai.kr` → 테넌트 #2. 게이트웨이/필터가 Host 헤더에서 `tenant_code`를 해소.
2. **사용자 소속 보조**: 로그인 사용자의 테넌트 멤버십으로 판별(서브도메인과 불일치 시 **거부** — 세션 하이재킹·오접속 차단). 다중 테넌트 소속(예: 복수 전시관 운영 대행사)은 명시적 테넌트 선택 후 컨텍스트 고정.
3. **주입**: 해소된 `tenant_id`를 요청 컨텍스트(ThreadLocal/Request scope)에 주입 → 서비스·MyBatis 매퍼가 이를 강제 바인딩(§8-2). 컨텍스트 미해소 요청은 **거부(fail-closed)**.
4. **공개 사이트(M12·M17)**: 서브도메인으로 테넌트 브랜딩·콘텐츠 분기(kintex/coex 공개 홍보 사이트가 각 테넌트 콘텐츠만 노출).

### 1A-4. 역할 계층 확장 — 플랫폼 vs 테넌트 (2계층)

기존 6역할(§2) 위에 **관리자 역할을 2계층으로 분리**한다.

| 계층 | 역할 | 범위 | 권한 |
|---|---|---|---|
| **플랫폼** | **플랫폼 슈퍼관리자(Platform Super Admin)** | **전 테넌트(크로스-테넌트)** | 테넌트 마스터 CRUD·온보딩, 전 테넌트 사용자/감사 통제, 전역 코드·플랫폼 설정, 전 테넌트 BI(§1A-2). GUARDiA 플랫폼 운영 주체(zio) |
| **테넌트(전시관)** | **테넌트 관리자(Venue/Tenant Admin)** | **자기 전시관(단일 테넌트) 내부만** | 자기 전시관의 마스터데이터(홀·요율·규정 룰셋·부스 표준)·사용자·RBAC·감사로그·시스템설정. 예: 킨텍스 관리자 ↔ 코엑스 관리자 상호 격리 |
| **행사(Event)** | 주최자·참가업체·업체·홀매니저(§2 기존 6역할) | 테넌트 내부의 행사·부스 | **테넌트 내부로 스코프된** 기존 행사 RBAC(변경 없음, 단 상위에 tenant 경계 추가) |

- **재정의**: §2의 기존 "관리자(Admin)" 페르소나는 **v3.0에서 "테넌트 관리자"로 재정의**되고, 그 위에 **플랫폼 슈퍼관리자**가 신설된다. §2-1 백오피스(`admin.`)는 두 계층이 **동일 앱·차등 권한**으로 진입(플랫폼 슈퍼관리자는 테넌트 스위처 보유, 테넌트 관리자는 자기 테넌트 고정).
- **홀매니저**: 킨텍스 홀매니저는 테넌트 #1 내부 계정으로, 코엑스 홀매니저는 테넌트 #2 내부 계정으로 각각 자기 전시관 행사만 열람/승인(크로스-테넌트 불가).

### 1A-5. 마이그레이션 영향 및 백필 방침

- **기존 데이터 = 테넌트 #1(KINTEX)로 백필**: v2.0까지 축적된 전 데이터(행사·홀·부스·옥션·관람객·마스터데이터 등)는 **일괄 `tenant_id = 1(KINTEX)`** 로 백필한다. 킨텍스는 기준 테넌트이므로 기존 운영에 **무중단**.
- **스키마 변경은 설계만 — 임의 DDL 금지**: `tenant_id` 컬럼 추가·FK·인덱스·NOT NULL 제약·백필 DDL은 **db-engineer/DA 후속 트랙**이 수행한다(planner는 설계·영향 범위만 확정). 적용 순서(권고): ① 테넌트 마스터 테이블 신설 + KINTEX 시드(#1) → ② 각 도메인 테이블 `tenant_id` nullable 추가 → ③ 전 행 `1`로 백필 → ④ NOT NULL + FK + `(tenant_id, …)` 복합 인덱스 → ⑤ 애플리케이션 필터(§8-2) 활성화. 멱등 DDL·`sql.init mode=always`+continue-on-error 패턴(§5B-3) 준수.
- **회귀 방지**: 백필 완료 전에는 격리 필터를 강제하지 않고(단일 테넌트 동작 유지), 컬럼·인덱스·백필 검증 후 필터를 켠다(§8-2). 신규 테넌트(COEX) 온보딩은 필터 활성화 이후.
- **미확보 데이터**: 코엑스 등 신규 전시관의 홀 실측·요율·규정은 **온보딩 시 해당 테넌트가 입력**하며, 근거 없는 추정 시드는 금지(§10 R4 정합).

> **후속 반영 필요**: 본 절의 스키마·필터·온보딩 절차는 `docs/design.md`·`docs/architecture/data.md`·src에 **미반영 상태** — db-engineer/DA/designer 후속 반영 필요(planner는 설계만 확정, 타 문서 직접 수정 안 함).

---

## 2. 사용자 정의 및 페르소나

| 사용자군 | 페르소나 | 핵심 과업 | 현재 고통 | 본 시스템에서 얻는 것 |
|---|---|---|---|---|
| **주최자** (Organizer) | 김주최, 전시기획사 PM 8년차. 연 3회 킨텍스 행사 운영 | D-150 홀 배정신청 → 계약 → D-30 사전협의 → D-7 신고서류 → 정산 | HWP 서식 수기 작성, 부스배치도 CAD 외주, D-7 서류 7종 마감 추적 | 자동 견적, 배치도 자동 생성, 마일스톤 자동 트래킹, 완공 예상 이미지로 참가업체 영업 |
| **참가업체** (Exhibitor) | 박참가, 중소 제조사 마케팅 담당. 전시 경험 2회 | 부스 선택(조립/독립), 유틸리티 신청(D-25), 반입/반출 | 전기 몇 kW 필요한지 모름, 위치표시도 수기 작성, 시공 결과를 개장일에 처음 봄 | 클릭 신청 + 자동 견적, **시공 전 부스 사진 확인**, 마감 리마인더 |
| **장치·시공업체** (Contractor) | 이장치, 킨텍스 등록 장치업체(739개 등록업체 중 전시디자인설치 분류) 실장 | 평면도·입면도·조감도·전기도면 kxwp 제출, D-7 리깅 구조계산서, 현장 시공 | 규정(높이 5m, 방염, 리깅 6.5~8.5m) 반려 리스크, 도면 수정 반복 | 제출 전 자동 규정 검증, 배선/분전반 설계 자동 초안, 고객 컨펌용 예상 사진 |
| **킨텍스 운영팀 (홀매니저)** | 최매니저, 행사지원팀. 홀 3개 담당 | 사전업무협의(D-30), 신고서류 검토, 현장 안전 관리(소음 70~75dB, 안전모) | 서류 육안 검수 병목, 행사별 협의 이력 분산, 위반 현장 사후 적발 | 위반 자동 플래깅 대시보드, 협의 이력 일원화, 홀 단위 유틸리티 부하 집계 |
| **관람객** (Visitor) — P1로 승격 | 정관람, 일반 관람객/바이어 | 일정 검색 → 사전등록·티켓 → 교통(GTX-A 킨텍스역 도보 3분) → 주차(iparking) → 배지·체크인 → 관람·비즈매칭 | 부스 위치 탐색 불편, 현장 등록 대기 | 사전등록·모바일 배지/QR·wayfinding·비즈매칭·인터랙티브 플로어플랜 |
| **테넌트(전시관) 관리자** (Tenant/Venue Admin) — v3.0 재정의 | 한관리, 킨텍스 전시관 운영 관리자 (코엑스는 별도 관리자) | **자기 전시관 내부** 사용자·권한(RBAC)·마스터데이터(홀·요율·규정 룰셋·부스 표준)·감사로그·시스템설정 | 데이터 산재, 권한 통제 부재 | 자기 전시관 백오피스에서 행사 통제·감사·룰셋 버전 관리(타 전시관 격리) |
| **플랫폼 슈퍼관리자** (Platform Super Admin) — v3.0 신규 | 플랫폼(zio) 운영자 | **전 테넌트** 온보딩·테넌트 마스터·전역 코드·크로스-테넌트 감사·통합 BI | (신규 — 다중 전시관 통합 통제 부재) | 테넌트 스위처로 전 전시관 통제, 새 전시관(코엑스 등) 온보딩(§1A-4·§1A-5) |
| **일반 대중** (Public) — 신규 | 불특정 다수 잠재 관람객·잠재 주최자 | 킨텍스 전시 홍보 열람, 참가 문의 | 킨텍스 공식 사이트는 정보·서식 다운로드 수준 | SEO·다국어 공개 홍보 사이트(M12), 참가업체 마이크로사이트(M17), 관람 유도 |

**권한 모델**: **테넌트(전시관) 격리 ⊃ 행사(Event) 단위 워크스페이스 + 행사 RBAC**의 3중 구조(§1A-4). 최상위에 테넌트 경계가 있고(전시관 간 데이터 원천 차단), 그 안에서 행사 단위 RBAC가 동작한다. 주최자가 행사 owner, 참가업체는 부스 단위 멤버, 장치/공사업체는 참가업체·주최자가 초대(등록업체 DB 검증 — 미등록 업체 초대·옥션 응찰 차단), 홀매니저는 **소속 전시관 내부** 계정으로 자기 전시관 행사 전체 열람+승인. **테넌트 관리자**는 자기 전시관 백오피스에서 통제(타 전시관 격리), **플랫폼 슈퍼관리자**만 크로스-테넌트 통제(§1A-4). 관람객·일반 대중은 공개/셀프서비스 계정(행사 데이터 쓰기 권한 없음, 등록·매칭·조회만) — 접속 서브도메인으로 테넌트가 고정(§1A-3).

### 2-1. 역할별 웹/모바일 포털 분리 (IA·채널 매트릭스)

각 역할은 목적이 다르므로 **별도 프론트 앱(도메인/서브패스 분리)**으로 제공하되, 공유 Spring Boot 백엔드 + SSO + 역할 RBAC 위에 얹는다. 데스크톱(설계·에디터·대시보드)과 모바일(현장·조회·승인)의 용도를 명확히 나눈다. **계정 체계·모바일 앱 채널은 §2-1-1(소유자 확정 2026-07-11)** 을 따른다.

| 역할 | 웹 포털 (데스크톱 주력) | 모바일 채널 (앱 타깃) | 가입 트랙 | 주 사용 모듈 | 인증/권한 |
|---|---|---|---|---|---|
| **주최자** | 주최자 콘솔 `organizer.` — 홀 배정·배치·행사 대시보드·옥션 발주·BI | **운영 앱(B2B)** — 조회·승인·현장 상황판 | 승인/초대 + **2FA(OTP) 필수** | M1·M2·M6·M15·M16·M12 | Event owner |
| **참가업체** | 참가업체 포털 `exhibitor.` — 부스 신청·설계·유틸리티·옥션 발주 | **운영 앱(B2B)** — 현장 체크인·**리드캡처(배지 스캔)**·승인 | 승인/초대 + **2FA(OTP) 필수** | M3·M4·M5·M10·M11·M15·M9 | Event member(부스 단위) |
| **장치/공사업체** | 업체 포털 `contractor.` — 도면 제출·**AI 설계자료 열람·옥션 응찰(견적서 제출)** | **운영 앱(B2B)** — 현장 시공·반입 통행증·안전 체크 | 승인/초대(등록업체 검증) + **2FA(OTP) 필수** | M3·M4·M15·M8·M7 | 등록업체 검증 계정 |
| **킨텍스 직원(홀매니저·운영)** | 운영 대시보드 `ops.` — 검수·규정 플래그·홀 부하·물류·현장운영 | **운영 앱(B2B)** — 현장 검수·안전·혼잡 모니터 | 내부 계정 발급 + **2FA(OTP) 필수** | M2·M6·M8·M14·M16 | 내부 계정(행사 전체 열람·승인) |
| **테넌트 관리자** | 백오피스 `admin.`(테넌트 컨텍스트 고정) — 자기 전시관 사용자·RBAC·감사로그·마스터데이터·룰셋·시스템설정 | (없음, 웹 전용) | 내부 계정 발급 + **2FA(OTP) 필수** | **M18** | 테넌트(전시관) 관리자(단일 테넌트 스코프) |
| **플랫폼 슈퍼관리자** | 백오피스 `admin.`(테넌트 스위처) — 테넌트 마스터·온보딩·전역 코드·크로스-테넌트 감사·통합 BI | (없음, 웹 전용) | 내부 계정 발급 + **2FA(OTP) 필수** | **M18 + 테넌트 관리** | 플랫폼 슈퍼관리자(크로스-테넌트, §1A-4) |
| **관람객/일반 대중** | 공개 홍보 사이트 `www/expo.` (SEO·다국어) + 관람객 사전등록·**게스트 예매(가입 없이 티켓 구매)** | **관람객 앱(B2C, 스토어 공개)** — 배지/QR·티켓 지갑·wayfinding·비즈매칭·플로어플랜 | **간편가입(이메일/소셜) + 게스트 예매 허용 · 2FA 미강제** | M12·M10·M11·M13·M17 | 공개/셀프서비스(쓰기 제한) |

- **분리 원칙**: 6개 프론트(organizer·exhibitor·contractor·ops·admin·public+visitor)는 **역할별 번들 분리**로 최소권한·공격면 축소. 공유 디자인 시스템(design.md)·공유 컴포넌트 라이브러리·공유 API 계약을 상속한다. (UI 상세·화면 목록은 designer 후속 반영 필요.)

#### 2-1-1. 계정 체계 및 모바일 앱 채널 전략 (소유자 확정 2026-07-11)

> **개정 표기**: 본 소절은 v3.1에서 소유자 확정안을 신설한 것이며, 기존 §2 권한 모델·§5B-3 인증·M10을 삭제하지 않고 정밀화한다(상충 시 본 확정안 우선). 근거: `docs/analysis/ticketing-app-benchmark.md`(게스트 예매·간편가입은 티켓팅 업계 표준).

**(A) 계정 체계 — 단일 통합 + 가입 트랙 분리.** 계정 테이블/RBAC는 **하나(단일 통합)** 로 두고, 그 위에서 **가입 트랙(등급)만 분리**한다.

| 가입 트랙 | 대상 | 가입 방식 | 2FA(OTP) | 예매/조회 |
|---|---|---|---|---|
| **업무 트랙(B2B)** | 주최자·참가업체·공사업체·킨텍스 직원·관리자 | **승인/초대 기반 가입(SCR-49)** | **필수** | 역할 RBAC에 따름 |
| **관람객 트랙(B2C)** | 일반 관람객·바이어 | **간편가입(이메일 또는 소셜 로그인)** | 미강제(선택) | **게스트 예매 허용**(가입 없이 티켓 구매, SCR-P7 기반영) |

- **계정 승격 연속성**: 관람객 → 바이어/참가업체 담당자로 승격 시 **단일 계정 위 등급 상향**으로 처리하여 **데이터 연속성(리드·비즈매칭·재방문 이력)** 을 유지한다(계정 재생성 없음). 승격 시 업무 트랙 요건(승인·2FA)이 추가 적용된다.
- 게스트 예매자는 사후 간편가입 시 예매 이력을 계정에 병합(티켓 지갑 연속).

**(B) 모바일 앱 — 코드베이스 1개(Expo `mobile/`), 배포 타깃 2개.**

| 앱 타깃 | 대상 | 배포 채널 | 핵심 화면 |
|---|---|---|---|
| **① 운영 앱(B2B)** | 업무 사용자 전용 | **스토어 미공개** — 사내 QR/APK 배포 | 현장 체크리스트·검수·승인 |
| **② 관람객 앱(B2C)** | 일반 관람객·바이어 | **스토어 공개 배포** | 간편가입·티켓 지갑·배지/QR·wayfinding·비즈매칭 (SCR-M5~M9·M14/M15 계열) |

- 두 타깃은 **단일 Expo 코드베이스(`mobile/`)** 에서 빌드 프로파일/엔트리로 분기한다(중복 구현 회피). 배포 채널·스토어 정책만 다르다.
- **관람객 1차 접점은 공개 웹(SCR-P7/P8)** 이며, 관람객 앱은 **리텐션 채널**(재방문·티켓 지갑·현장 wayfinding)로 위치한다. 앱 미설치 관람객도 웹 게스트 예매로 전 여정 완결 가능.
- 백오피스(관리자)는 모바일 미제공(웹 전용). 업무 사용자 모바일은 운영 앱으로만 제공.

---

## 2-2. 대외 접점 3-트랙 재구성 (visitor / business / agency) — v3.2

> **소유자 확정(2026-07-12)**: 대외 접점을 **visitor(관람객) / business(비즈니스=주최자·참가업체) / agency(에이전시=공사·장치·협력사)** 3개 트랙으로 나눠 분리한다. 근거 = `docs/analysis/coex-website.md` — 코엑스가 방문자 유형별로 **사이트(도메인) 자체를 3개(VISITOR `coex.co.kr` / BUSINESS `business.coex.co.kr` / CYBER 참가신청 `cybercoex.co.kr`)로 분리**한 IA를 킨텍스 도메인에 이식한다.
>
> **보존 원칙**: 본 절은 §2 페르소나·§2-1 역할별 포털 매트릭스·§2-1-1 계정 체계·M1~M18·§8 아키텍처를 **삭제·재작성하지 않는다.** 6역할/7페르소나 구조는 유지되고, 그 위에 "대외 접점을 3개 트랙으로 묶어 진입점·서브홈·네비게이션 IA를 재편하는" **트랙 셸 레이어**만 순증한다. 내부 전용 역할(킨텍스 직원 ops·테넌트/플랫폼 관리자 admin)은 대외 트랙이 아니므로 3-트랙 밖에 그대로 둔다.

### 2-2-1. 3-트랙 정의 — 대상·핵심 여정·진입 화면·제공 기능

| 트랙 | 대상(§2 역할 매핑) | 코엑스 대응 | 핵심 여정 | 진입 화면 | 제공 기능(모듈·SCR) |
|---|---|---|---|---|---|
| **visitor** (관람객) | 관람객 + 일반 대중(Public) | VISITOR `coex.co.kr` + 가이드 | 행사 탐색 → 사전등록/티켓 → 방문(교통·주차·길찾기) → 배지·체크인 → 관람·매칭 → 재방문 | visitor 서브홈(공개 랜딩) → SCR-P1 | 공개 홍보 사이트 M12(SCR-P1·P2·P3·P5), 사전등록·티켓 M10(SCR-P4·P6·P7·P8), wayfinding M13, 비즈매칭 M11, 관람객 앱(SCR-M5~M9·M14·M15) |
| **business** (비즈니스) | 주최자(Organizer) + 참가업체(Exhibitor) | BUSINESS `business.coex.co.kr` + CYBER `cybercoex.co.kr` | (주최자) 홀배정·견적 → 배치·서류 → 옥션 발주 → 정산·BI / (참가업체) 부스 신청 → 설계·유틸리티 → 시각화 → 리드 | business 서브홈 → 로그인 → 역할별 홈(주최자 SCR-02 / 참가 SCR-05) | 홀배정·견적 M1, 배치 M2, 부스설계 M3, 유틸리티 M4, 시각화 M5, 서류·마일스톤 M6, 옥션 발주 M15, 정산 M9, 관람·리드 M10, BI M16 |
| **agency** (에이전시) | 장치·공사업체(Contractor) + 등록·협력업체 | BUSINESS 하위 **서비스협력업체** + 안전경영 **온라인작업신고** (킨텍스는 독립 트랙으로 승격) | 등록업체 검증 → AI 설계자료 열람 → **옥션 응찰(견적서 제출)** → 수주 → 도면 제출·규정검증 → 현장 시공·작업신고 | agency 서브홈 → 로그인 → 수주/응찰 대시보드(SCR-27/28) | 부스설계(공유) M3, 규정검증 M3(SCR-09), 옥션 응찰 M15(SCR-27·28), 등록업체 매칭 M7(SCR-38), 반입/작업신고 M8, 현장 앱(SCR-M1·M10) |

- **트랙 ↔ 역할 관계**: 트랙은 역할의 **상위 묶음(진입점 그룹)** 이지 역할의 대체가 아니다. business 트랙 안에 organizer·exhibitor 2역할이 공존하고, agency 트랙 안에 contractor + 등록업체 계정이 공존한다. 로그인 후 실제 권한·화면은 기존 §2 역할 RBAC 그대로.
- **코엑스와의 차이(정당화)**: 코엑스는 agency(협력사)를 BUSINESS 하위로 흡수했으나, 킨텍스는 **독립부스 등록 장치업체 필수·미등록 시공 엄금·리깅 구조계산서·739개 등록업체 DB·M15 역경매 옥션**이라는 강한 도메인이 있어 agency를 **독립 트랙**으로 세운다(§4 대비표 근거).

### 2-2-2. 코엑스에서 차용할 요소 (트랙별)

| 트랙 | 코엑스 차용 요소 | 킨텍스 반영 |
|---|---|---|
| visitor | "가이드" 단일 허브(오시는 길·주차·실내 길찾기·VR·편의시설·알림마당·문의) + 관심분야 맞춤 알림 + 수어/접근성 전면 노출 | visitor 서브홈에 방문 가이드 허브 구성(교통 GTX-A·주차 iparking·wayfinding M13·편의시설), 맞춤 알림·접근성 고지(M12·M10) |
| business | 임대절차→시설규격→요금→서류/도면 **단계별 실무 흐름** + 참가업체 신청 **공통 플랫폼(cybercoex)** 일원화 | business 서브홈에 주최자(대관·M1)·참가업체(신청·M3/M4) 단계 안내 + 킨텍스 최대 공백인 **참가업체 공통 e-서비스**를 business 트랙으로 통합 |
| agency | 서비스협력업체 리스트 + 안전경영 온라인작업신고 통합 | agency 서브홈에 등록업체 검증·수주·옥션·도면제출·작업신고(kxwp 릴레이)를 하나로(코엑스보다 강한 독립 트랙) |

### 2-2-3. 공개 사이트 구조 — 랜딩 3-분기 + 트랙별 서브홈 + 로그인 후 홈

**(A) 랜딩(루트) = 3-트랙 분기 관문.** 최상위 진입점(예: `www.` 또는 테넌트 루트)은 코엑스 스타일로 **visitor / business / agency 3개 카드로 명확히 분기**하는 관문 랜딩을 제공한다. 관람객이 절대다수이므로 visitor를 시각적 1순위(히어로·행사 카드)로 두고, business·agency는 상단 유틸리티/카드로 노출(코엑스가 VISITOR를 메인에 두고 BUSINESS를 링크로 분리한 패턴 차용).

**(B) 트랙별 서브홈(전용 공개 홈 3개).**
- **visitor 서브홈** — 공개·비로그인. 행사 일정·히어로·사전등록/티켓 CTA·방문 가이드 허브(SCR-P1 확장). SEO·다국어·MDI 비적용(§8-1).
- **business 서브홈** — 공개(안내) + 로그인 유도. 주최자 대관 안내·참가업체 참가 안내·요금·서류 안내(SCR-P6 확장) → "로그인/신청" CTA.
- **agency 서브홈** — 공개(안내) + 등록업체 로그인. 등록업체 안내·진행 중 옥션 공고·작업신고 안내 → 등록업체 로그인 CTA.

**(C) 로그인 후 랜딩 — 권고: "트랙-스코프 홈(Track-scoped Home)".**
로그인 후 홈은 **단일 범용 홈(역할별 변형)** vs **트랙별 별도 홈** 두 안 중, **트랙별 별도 홈(단, 트랙 내부는 역할 변형)** 을 권고한다.

| 안 | 내용 | 장점 | 단점 | 판정 |
|---|---|---|---|---|
| 단일 범용 홈(역할별 위젯 변형) | 로그인 후 하나의 홈, 역할에 따라 위젯만 다름 | 구현 단순, 계정 승격 연속성(§2-1-1) 매끄러움 | 트랙 정체성 약함, business·agency·visitor 혼재로 IA 혼란 | 부분 채택(트랙 내부) |
| **트랙별 별도 홈(트랙 내 역할 변형)** | 트랙 셸마다 홈, 홈 안에서 역할(주최자/참가 · 시공/등록)로 위젯 변형 | 코엑스식 트랙 정체성·최소권한·공격면 축소(§2-1), 기존 SCR-02/05/27 재사용 | 홈 3벌 유지 | **권고** |

- **권고 근거**: business 트랙은 organizer(SCR-02)·exhibitor(SCR-05) **기존 홈을 그대로** 트랙 내 역할 변형으로 재사용하고, agency는 수주/응찰 대시보드(SCR-27/28)를 홈으로 삼는다 → **신규 홈 화면 최소**(트랙 관문 랜딩 + 서브홈 3개만 신규, 나머지는 재배치). 계정 승격 연속성(§2-1-1)은 **단일 통합 계정** 위에서 유지되므로 트랙별 홈이어도 데이터 연속성은 훼손되지 않는다(관람객→바이어/참가 승격 시 business 트랙 접근 권한만 추가).

### 2-2-4. 라우트 체계 — 마이그레이션 비용 비교 후 권고

| 안 | 라우트 | 마이그레이션 비용 | SEO/딥링크 | 판정 |
|---|---|---|---|---|
| A. 전면 트랙 프리픽스 | 기존 `/o/`·`/e/`·`/c/`·`/tickets/`를 `/business/o/`·`/business/e/`·`/agency/c/`·`/visitor/tickets/`로 재작성 | **높음** — 전 딥링크·MDI 세션키(§design 2.7 `kintex.mdi.{role}.{eventId}`)·티켓 공개 라우트(`/tickets/:orderNo`) SEO 인덱스 전면 변경, 리다이렉트 맵 필요 | 기존 인덱스 무효화 위험 | 미채택 |
| **B. 트랙 셸 레이어 + 기존 딥 라우트 유지(하이브리드)** | **신규 얕은 트랙 진입 라우트만 추가** — `/`(관문 랜딩), `/visitor`(서브홈), `/business`(서브홈), `/agency`(서브홈). 로그인 후 **기존 역할 딥 라우트(`/o/{eventId}/...`·`/e/{eventId}/...`·`/m/...`·`/gallery/...`·`/tickets/...`)는 그대로 유지** | **낮음** — 기존 화면·MDI·티켓 SEO·세션키 불변, 트랙은 상위 셸/네비로만 그룹핑 | 기존 인덱스 보존, 신규 트랙 랜딩만 인덱싱 | **권고** |
| C. 서브도메인 분리 | `visit.` / `business.` / `agency.` 서브도메인(코엑스식) | 중간 — 배포·인증서·SSO 쿠키 도메인 조정, 단 §2-1·§8-1이 이미 역할 서브도메인(organizer.·exhibitor.·contractor.) 전제 | 트랙별 브랜딩·격리 명확 | **선택적 상위 옵션**(운영 단계) |

- **권고 = 안 B(하이브리드) + 안 C 선택 결합**: 1차는 **경로 기반 트랙 셸(안 B)** 로 마이그레이션 비용 없이 트랙 IA를 얹고, 기존 딥 라우트(`/o/`·`/e/`·`/m/`·`/tickets/`)와 MDI 셸(design §2.7)·티켓 공개 라우트(SCR-P7/P8)를 **불변**으로 둔다. 운영 확장 시 §2-1의 역할 서브도메인 전략과 정합하여 트랙 서브도메인(안 C)을 상위에 얹을 수 있다(예: `business.` → business 서브홈 → 내부적으로 organizer/exhibitor 앱).
- **트랙 ↔ 기존 서브도메인 매핑**(§2-1 보존): visitor 트랙 ⊇ {`www/expo.` 공개 + 관람객 앱}, business 트랙 ⊇ {`organizer.`·`exhibitor.`}, agency 트랙 ⊇ {`contractor.`}. ops·admin 서브도메인은 트랙 외부(내부 전용).

### 2-2-5. 기존 화면 재배치 매핑표 (현행 SCR/라우트 → 트랙)

> 원칙: **화면·라우트는 이동·재작성하지 않는다**(안 B). 아래는 각 화면이 **어느 트랙 셸의 네비게이션·진입 그룹에 속하는가**의 논리적 귀속 표이며, designer/frontend는 이를 트랙 서브홈·네비 구성에만 사용한다.

| 트랙 | 귀속 화면(design.md SCR) | 현행 라우트(유지) | 신규(트랙 셸) |
|---|---|---|---|
| **관문 랜딩** | (신규) 3-트랙 분기 관문 | `/` | ★신규 SCR 필요(designer) |
| **visitor** | SCR-P1·P2·P3·P5(공개사이트), SCR-P4·P6(등록·문의), SCR-P7·P8(티켓), SCR-M5~M9·M14·M15(관람객 앱) | `www/expo.` 공개, `/tickets/*`, 관람객 앱 | ★visitor 서브홈(SCR-P1 확장) |
| **business** | SCR-01(로그인), SCR-02·03·04·19(주최자), SCR-05·06·07·08·12(참가), SCR-15·18·20·21·22·23·24·25·26·29(M1/M6/M8/M9/M15 발주), SCR-13(BI), SCR-30·31·32(관람·리드), SCR-39~48(공통업무) | `/o/{eventId}/*`, `/e/{eventId}/*`, `/gallery/*` | ★business 서브홈(SCR-P6 확장) |
| **agency** | SCR-06·09(설계·규정, 공유), SCR-27·28(옥션 응찰), SCR-38(등록업체), SCR-M1·M10(현장·통행증) | `/c/{eventId}/*`(contractor, 기존 exhibitor 포털 공유 라우트), 옥션 응찰 라우트 | ★agency 서브홈(등록업체·옥션 공고) |
| **트랙 외부(내부)** | SCR-10·11(홀매니저), SCR-14(현장운영), SCR-16·A1~A10(관리자·시스템관리) | `/m/{eventId}/*`, `admin.` | (트랙 재편 대상 아님, 보존) |

- **신규 화면 = 4종만**(관문 랜딩 1 + 서브홈 3). 나머지는 전량 기존 SCR 재사용 → designer/frontend 작업량 최소(§구현 지시서 `_workspace/plan_3track.md`).

---

## 2-3. 사용자 구분 → 랜딩(메인페이지)·메뉴/탭 그룹 결정 규칙 — 웹+모바일 공통 (v3.3, 소유자 확정 2026-07-12)

> **소유자 확정 규칙**: **"로그인한 사용자의 사용자 구분(역할)으로 메인페이지가 결정되고, 좌측 메뉴 그룹(모바일은 하단 탭바)도 결정된다."** 두 가지 축을 확정한다 — ① **미인증(비로그인) 기본 진입 = visitor 트랙**(공개 관람 랜딩), ② **인증 후에는 역할이 매핑되는 트랙의 전용 메인**으로 랜딩하고 메뉴/탭 그룹을 트랙-스코프로 노출한다. **웹과 모바일 앱은 동일 로직**을 따른다(모바일은 셸 대신 하단 탭바 구성이 역할별로 결정).
> **보존·경계**: §2 6역할/7페르소나·§2-2 3-트랙·§2-1 포털 매트릭스·기존 화면(SCR-*)·기존 딥 라우트(안 B, §2-2-4)를 **삭제·재작성하지 않는다.** 본 절은 그 위에 **랜딩 결정 로직 + 트랙별 메뉴/탭 가시성 + 신규 트랙 메인 화면 목록**만 순증한다. 본 절은 §2-2-3(C)의 "트랙-스코프 홈" 권고를 소유자 확정으로 **정밀화**한다 — 기존 홈(SCR-02/05/27)을 그대로 재사용하는 대신, **각 트랙 전용 "메인" 신규 화면(designer Stitch 의뢰)이 기존 역할 위젯을 조합**하는 형태로 확정.
> **현행 기준(실측)**: 현재 로그인 후 전원 `/home`(SCR-HOME) 고정(`LoginPage.completeLogin → navigate('/home')`), AppShell `GROUPS`(ops·design·visitor·finance·work·system) 전원 동일 노출(system 그룹만 `isAdmin` 게이트). 역할 신호: `EventRole = ORGANIZER|EXHIBITOR|CONTRACTOR|HALL_MANAGER`(워크스페이스 `myRole`) + `globalRole`(`app_user.role_code` = ADMIN|MANAGER|VISITOR…). authStore: `globalRole()`·`roleForCurrent()`·`workspaces`. **src·design.md 미수정(frontend·kintex-mobile·designer 후속).**

### 2-3-1. 역할 → 트랙 매핑 확정표 (웹·모바일 공통)

| 트랙 | 구성 역할(§2) | 판정 신호 | 웹 셸 | 모바일 앱 타깃(§2-1-1) |
|---|---|---|---|---|
| **visitor**(관람) | 관람객·일반대중·게스트 | **미인증** OR `globalRole=VISITOR` OR 업무 워크스페이스 0개 | 공개/관람객 셸(MDI 비적용, §2.7-6) | **관람객 앱(B2C)** |
| **business**(비즈니스) | ORGANIZER·EXHIBITOR | `myRole ∈ {ORGANIZER, EXHIBITOR}` 워크스페이스 보유 | AppShell(MDI) | **운영 앱(B2B)** |
| **agency**(에이전시) | CONTRACTOR·등록/협력업체 | `myRole=CONTRACTOR` 워크스페이스 보유(상위 트랙 없음) | AppShell(MDI) | **운영 앱(B2B)** |
| **내부-ops** | HALL_MANAGER·킨텍스 운영 | `globalRole=MANAGER` OR `myRole=HALL_MANAGER` 워크스페이스 | AppShell(MDI) | **운영 앱(B2B)** |
| **내부-admin** | 테넌트/플랫폼 관리자 | `globalRole=ADMIN`(=현행 `isAdmin`) | AppShell(MDI) + 시스템관리 그룹 | 웹 전용(모바일 백오피스 미제공, §2-1-1) |

- **트랙 판정 헬퍼**: `trackOf(EventRole)` → ORGANIZER/EXHIBITOR = business, CONTRACTOR = agency, HALL_MANAGER = 내부-ops. `globalRole` 오버레이 → ADMIN = 내부-admin(system 그룹 부여), MANAGER = 내부-ops, VISITOR/null = visitor(업무 워크스페이스 없을 때).

### 2-3-2. 판정 우선순위 · 멀티역할 · 트랙 스위칭

- **primaryTrack 우선순위(높음→낮음)**: **내부-admin > 내부-ops > business > agency > visitor.** 복수 역할 사용자(계정 통합, §2-1-1)의 **로그인 랜딩**은 이 우선순위로 결정한다. 예: `admin+organizer` → 내부-admin 랜딩(관리 메인, 단 비즈니스 메뉴도 접근), `contractor+exhibitor` → business 랜딩(둘 다 업무 트랙, business 우위).
- **activeTrack(반응형)**: 좌측 상단 **행사 전환 드롭다운(기존)** 으로 워크스페이스를 바꾸면 `activeTrack = trackOf(roleForCurrent())` 로 따라 바뀌어 메뉴/탭이 재스코프된다 → **별도 트랙 스위처 UI 신설 최소화**(기존 워크스페이스 선택 재사용). `globalRole=ADMIN` 의 시스템관리 오버레이는 activeTrack과 무관하게 항상 유지(현행 `isAdmin` 게이트 보존).
- **연속성**: 트랙별 메인/메뉴가 달라도 계정은 단일 통합(§2-1-1)이므로 리드·비즈매칭·재방문 이력은 훼손되지 않는다(관람객→바이어/참가 승격 시 business 트랙 접근 권한만 추가).

### 2-3-3. 랜딩(메인페이지) 결정표

**(A) 웹** — `completeLogin` 분기 + 미인증 루트 가드.

| 순서 | 상태·조건(신호) | 트랙 | 메인페이지 | 라우트(권고·안 B) | 화면 |
|---|---|---|---|---|---|
| 0 | **미인증(토큰 없음)** | visitor | 공개 관람 랜딩 | `/` (현행 `/login` 리다이렉트 → visitor 랜딩으로) | **SCR-T0(신규)** |
| 1 | `globalRole=ADMIN` | 내부-admin | 관리 메인(**또는** 비즈니스 메인+시스템관리) | `/admin`(또는 `/home`) | SCR-16(+SCR-T2) |
| 2 | `globalRole=MANAGER` OR HALL_MANAGER ws | 내부-ops | 운영 메인(비즈니스 메인 운영 변형) | `/home` | SCR-T2(운영 변형) |
| 3 | ORGANIZER/EXHIBITOR ws | business | 비즈니스 메인 | `/home` | **SCR-T2(신규)** |
| 4 | CONTRACTOR ws(1~3 없음) | agency | 에이전시 메인(수주·옥션) | `/contractor/dashboard`(또는 `/agency`) | **SCR-T3(신규)** |
| 5 | `globalRole=VISITOR` OR 업무 ws 0 | visitor | 관람객 메인 | `/visitor` | **SCR-T1(신규)** |
| — | 판정 불가(폴백) | — | 안전 폴백 | `/home` | SCR-HOME(현행) |

**(B) 모바일 앱** — 동일 로직(진입 시 미인증=관람객, 로그인 후 역할별 홈 탭 네비게이터 스위칭).

| 순서 | 상태·조건 | 트랙/역할 | 모바일 진입(랜딩) | 화면 |
|---|---|---|---|---|
| 0 | **미인증(토큰 없음)** | visitor(게스트) | **관람객 진입** — 행사탐색·사전등록·티켓·게스트 예매 | 모바일 관람객 홈(신규) |
| 1 | ADMIN | (모바일 백오피스 없음) | 보유 업무역할 메인, 없으면 관람 최소 뷰 | — |
| 2 | MANAGER/HALL_MANAGER | 내부-ops | 운영 홈(승인·현장 상황판) | SCR-M2 계열 + 운영 홈(신규) |
| 3 | ORGANIZER/EXHIBITOR | business | 업무 홈(주최=대시보드 / 참가=내 부스) | 모바일 비즈니스 홈(신규) |
| 4 | CONTRACTOR | agency | 수주/옥션 홈 + 현장 | SCR-M1 계열 + 모바일 에이전시 홈(신규) |
| 5 | VISITOR/게스트 | visitor | 관람객 홈(티켓·배지·wayfinding·매칭) | SCR-M5~M9·M14·M15 계열 |

### 2-3-4. 좌측 메뉴 그룹 매트릭스 (웹 AppShell `GROUPS`)

노출 규칙: `●` 전체 노출 · `◐` 부분(항목 필터) · `✕` 숨김. 현행 `visibleGroups = GROUPS.filter(!g.admin || isAdmin)` 를 **트랙 필터 추가**로 확장.

| `GROUPS.id` (그룹명) | 내부-admin | 내부-ops | business(주최) | business(참가) | agency | visitor |
|---|---|---|---|---|---|---|
| `ops` 전시 운영 | ● | ● | ● | ◐(대시보드·참가업체 조회) | ✕ | ✕ |
| `design` 설계·시공 | ● | ●(검수·홀 부하) | ● | ●(부스설계·유틸·시각화) | ●(수주부스·공사옥션·규정·반입) | ✕ |
| `visitor` 관람객·마케팅 | ● | ● | ● | ◐(리드) | ✕ | ✕(셸 미노출) |
| `finance` 정산·분석 | ● | ● | ● | ◐(내 정산) | ✕ | ✕ |
| `work` 업무 공통 | ● | ● | ● | ● | ● | ✕ |
| `system` 시스템관리 | ● | ✕ | ✕ | ✕ | ✕ | ✕ |

- **visitor 트랙**은 업무 AppShell(GROUPS) 미노출 — §2-2-3(B)의 공개/관람객 셸(내 티켓·내 행사·방문가이드·알림 최소 메뉴)을 사용한다.
- **agency `design` 그룹 부분(◐→항목)**: 노출 = `수주 부스`(`/contractor/dashboard`)·`공사 옥션`(`/auctions`)·`서류·마일스톤`(도면제출)·`반입·반출`. 숨김 = 주최자 전용 `플로어플랜 스튜디오` 편집.
- **내부-ops(홀매니저)**: `design`은 검수·홀 부하 관점(플로어플랜 RO), `system` 제외(테넌트 관리자 아님).

### 2-3-5. 하단 탭바 매트릭스 (모바일, 역할별 결정)

design.md §2-2 모바일 하단 탭 4개(홈/내 부스·승인/알림/더보기)를 **역할별 구성으로 확정**(탭 4~5개).

| 트랙/역할 | 탭1 (홈) | 탭2 | 탭3 | 탭4 | 탭5 |
|---|---|---|---|---|---|
| visitor(미인증·관람객) | 행사탐색 | 티켓·배지 | 길찾기(wayfinding) | 알림 | 더보기(게스트→가입) |
| business 주최자 | 대시보드 | 참가·승인 | 현장 상황판 | 알림 | 더보기 |
| business 참가업체 | 내 부스 | 체크인·리드스캔 | 시각화 | 알림 | 더보기 |
| agency 공사·협력 | 수주·옥션 | 현장 체크리스트 | 통행증 | 알림 | 더보기 |
| 내부-ops 홀매니저 | 홈 | 승인·검수 | 현장(안전·혼잡) | 알림 | 더보기 |
| 내부-admin | (모바일 백오피스 미제공 — 웹 전용) | | | | |

### 2-3-6. 신규 트랙 메인 화면 목록·스펙 (designer Stitch 의뢰 대상)

> planner는 **화면 목록·용도·핵심 섹션·재사용 위젯**까지 확정한다. **SCR 번호 확정·Stitch 영어 프롬프트 작성·생성·이식은 designer 소관**(MEMORY: 전 화면 Stitch 경유). 아래 가칭 SCR-T0~T3(웹)·모바일 3종은 designer가 design.md에서 정식 번호·프롬프트로 확정한다.

| # | 화면(가칭) | 채널 | 트랙 | 핵심 섹션/위젯 | 셸 | 조합할 기존 위젯 |
|---|---|---|---|---|---|---|
| 1 | **SCR-T0 공개 관람 랜딩(루트)** | 웹 | visitor(미인증) | 히어로·행사 카드·사전등록/티켓 CTA·**business/agency 로그인 진입**·방문가이드 허브 | 공개 셸 | §2-2-3(B) visitor 서브홈, SCR-P1 |
| 2 | **SCR-T1 관람객 메인** | 웹 | visitor(인증) | 내 티켓·모바일 배지·행사탐색·wayfinding·비즈매칭 | 관람객 셸 | SCR-P4·P7·P8 |
| 3 | **SCR-T2 비즈니스 메인** | 웹 | business/내부-ops | KPI·D-데이 할일·내 행사 — **역할 변형**(주최=마일스톤·홀 SCR-02 / 참가=내 부스·마감 SCR-05) | AppShell | SCR-02·05·HOME |
| 4 | **SCR-T3 에이전시 메인** | 웹 | agency | 수주 목록·진행 중 옥션·응찰 현황·규정검증 요약·작업신고 | AppShell | SCR-27·28·09·38 |
| 5 | **모바일 관람객 홈** | 모바일 | visitor | 행사탐색·티켓·배지·wayfinding | 관람객 앱 | SCR-M5~M9 |
| 6 | **모바일 비즈니스 홈** | 모바일 | business | 대시보드/내 부스·승인·리드(역할 변형) | 운영 앱 | (신규) |
| 7 | **모바일 에이전시 홈** | 모바일 | agency | 수주·옥션·현장 | 운영 앱 | SCR-M1 |

- **관리 메인**(내부-admin)은 **기존 SCR-16 관리 대시보드 재사용**(신규 아님) — 비즈니스 메인(SCR-T2)+시스템관리 그룹 조합 대안 병기.
- **신규 Stitch 화면 = 웹 4(SCR-T0~T3) + 모바일 3 = 7종.** 나머지 세부 업무 화면은 전량 기존 SCR 재사용(안 B).

### 2-3-7. 구현 권고 및 담당 (지시서 포인터)

- **웹 (frontend 담당)**: ① `LoginPage.completeLogin` 을 `resolveLandingTrack(user, workspaces)` → `landingPath(track)` 분기로 교체(현행 `/home` 고정 폐기, business/내부는 `/home` 유지 = 회귀 0, agency=`/contractor/dashboard`·visitor=`/visitor` 신설 분기). ② 미인증 루트 `/` = SCR-T0(현행 `/login` 강제 리다이렉트 완화). ③ `AppShell.visibleGroups` 에 **트랙 필터** 추가(`GROUPS`/item에 선택적 `tracks?` 허용목록 필드, `activeTrack` 파생). ④ authStore에 `activeTrack()` 셀렉터 신설. **라우트·화면 재작성 없음(안 B).**
- **모바일 (kintex-mobile 담당)**: ① 앱 진입 미인증 = 관람객 탭 네비게이터. ② 로그인 후 `resolveLandingTrack` 동일 규칙으로 역할별 탭 네비게이터 스위칭(§2-3-5). ③ 탭 구성은 트랙-스코프. WISE 모바일 레퍼런스 컨벤션 준수.
- **지시서**: `_workspace/plan_role_routing.md`(웹+모바일 섹션·담당·웨이브 명시). **design.md/designer 후속**: 신규 트랙 메인 7종 Stitch 의뢰 + §2.7-6 역할별 적용·§2-1 사이트맵·§4 모바일 탭 매트릭스에 본 규칙 반영.

---

## 3. 현행(As-Is) 프로세스 분석

### 3-1. 주최자 타임라인과 병목

분석 문서 기준 실제 프로세스:

| 시점 | 현행 프로세스 | 매체 | Pain Point |
|---|---|---|---|
| D-150 ~ D-14 (인기 행사 1~2년 전) | 전시홀 배정신청서 제출 → 배정협의 → 견적 | **HWP 양식**, 방문/이메일 (온라인 제출 안내는 있으나 실체는 서식 다운로드) | 가용성 실시간 조회 불가, 견적 대기 |
| 계약 | 계약금 20% → 중도금 30%+20% → 잔금 30% + 관리비 예치금(임대료의 15~20%) | 공문+계약서 | 납부 일정 수동 관리 |
| D-30 | 홀매니저 배정 후 사전업무협의(장치·홍보·로비·보안) 완료 기한 | 대면/유선 | 협의 이력 비정형, 담당자 의존 |
| D-25 내외 | 참가업체 유틸리티 신청 마감(전기 등) | **전시회별 주최자 사무국 시스템** (킨텍스 공통 플랫폼 부재) | 행사마다 신청 채널 상이, 누락 빈발 |
| D-7 | 신고서류 일괄 제출: 행사운영계획서, 부스배치도, 재해대처계획서, 방화관리 책임서약서, 주차관리 신청서, 보안요원 배치계획, 위험물 반입신고서 + 리깅 구조계산서 | kxwp.kintex.com 업로드 | 서류 7종+ 마감 집중, 육안 검수 병목 |
| 행사 후 | 폐기물 처리비·전기사용료 등 관리비 정산 | 세금계산서 | 예치금 대비 실사용 정산 불투명 |

### 3-2. 참가업체·장치업체 병목

- **독립부스는 킨텍스 등록 장치업체 시공 필수**(미등록 엄금, 자체시공 원칙 불가) — 그러나 등록업체 DB(14개 분류 × 739개)는 단순 리스트+엑셀 다운로드로, 매칭·견적 비교 기능 없음.
- 장치 도면(평면·입면·조감·전기)을 kxwp에 제출 → 사람이 검토. 규정은 수치로 명확(높이 5m 이하, 리깅 6.5~8.5m + 구조계산서 D-7, 복층 1/2 이내, 전 자재 방염, 홀별 바닥하중 2~5t/㎡)하나 검증은 수작업.
- 유틸리티는 **바닥 트렌치** 공급(전기·급배수·압축공기·전화·인터넷, 홀1·7은 가스 포함)인데, 참가업체가 **시공 위치표시도를 수기로 그려 온라인 등록**해야 하며 인터넷은 현장 추가신청 불가 — 마감(약 D-25) 놓치면 구제 수단 없음.
- 요금은 정형화되어 있으나 견적 자동화 없음: 전기 220V 단상 1kW 55,000원, 분전반 50A 추가 100,000원, 압축공기(내경 8mm) 150,000원/구, 급배수(급수15mm/배수25mm) 150,000원/구, 인터넷 유선 150,000원/회선(KT 경유 회선당 80,000원 안내 병존).
- 반입/반출: 화물차 순번제·통행증, 중량물(5t 이상) 우선 반입, 지게차 지정업체 사전신청(유료) — 슬롯 예약 시스템 없이 현장 대기열 운영.

### 3-3. 구조적 공백 (분석 문서 §5 종합)

1. **참가업체 공통 포털 부재** — 유틸리티 신청이 행사별로 파편화. 가장 큰 공백.
2. 배치도·도면·위치표시도 등 **공간 데이터가 전부 이미지/수기**로 오가며 구조화되지 않음 → 자동 검증·시각화·정산의 원천 데이터가 없음.
3. D-150/D-30/D-25/D-7 마일스톤이 시스템화되어 있지 않음.
4. 시공 결과를 사전에 볼 수단이 없음 — 조감도는 장치업체 외주 산출물이며 배선·조명 반영 안 됨.

---

## 4. 시스템 구성 (모듈 맵)

```mermaid
graph TB
    subgraph 포털["역할별 포털 (§2-1)"]
        ORG[주최자 콘솔]
        EXH[참가업체 포털]
        CON[업체 포털]
        MGR[운영 대시보드]
        ADM[관리자 백오피스]
        PUB[공개사이트/관람객앱]
    end

    subgraph 코어["설계·시각화 코어 (P0·불변)"]
        M2[M2 플로어플랜 스튜디오<br/>3안 생성·선택/병합·규정검증]
        M3[M3 부스 설계 스튜디오<br/>3안 생성·선택/병합]
        M4[M4 유틸리티 설계<br/>전기·조명/네트워크·급배수]
        M5[M5 나노바나나<br/>시공 후 예상 사진]
    end

    subgraph 판매운영["판매·발주·정산"]
        M1[M1 홀 배정·자동 견적]
        M6[M6 서류·마일스톤]
        M7[M7 등록업체 매칭]
        M15[M15 공사/장치 옥션<br/>역경매·견적서 응찰]
        M8[M8 반입/반출 물류]
        M9[M9 정산·결제]
    end

    subgraph 관람참가["관람·참가·마케팅"]
        M10[M10 관람객 등록·배지<br/>체크인·리드캡처]
        M11[M11 비즈니스 매칭]
        M12[M12 마케팅·EDM<br/>공개 홍보 사이트]
        M13[M13 wayfinding<br/>실내 내비]
        M14[M14 현장운영<br/>혼잡·안전·주차·에너지]
    end

    subgraph 경영["경영·콘텐츠·관리"]
        M16[M16 경영분석 BI<br/>매출·가동률·P&L·수요예측]
        M17[M17 CMS<br/>콘텐츠·마이크로사이트·다국어]
        M18[M18 관리자 시스템<br/>RBAC·감사·마스터데이터]
    end

    subgraph 외부["외부·기존 시스템"]
        KXWP[kxwp/kxfp 작업신고]
        CCPY[등록업체 DB 739개]
        EVT[행사일정 시스템]
        PG[PG 결제]
        GEM[Gemini 나노바나나]
        SGN[사이니지/wayfinding HW]
    end

    ORG --> M1 --> M2
    ORG --> M6
    ORG --> M16
    EXH --> M3 --> M4
    CON --> M3
    CON --> M15
    MGR --> M2
    MGR --> M14
    ADM --> M18
    PUB --> M12
    PUB --> M10

    M2 --> M3 --> M4
    M2 & M3 & M4 --> M5
    M4 --> M9
    M1 --> M9
    M3 --> M7
    M2 & M3 & M4 & M5 --> M15
    M15 --> M9
    EXH --> M8
    M10 --> M11
    M10 --> M14
    M2 --> M13
    M9 --> M16
    M10 --> M16
    M12 --> M17
    M18 -.룰셋·마스터.-> M1
    M18 -.RBAC.-> 포털

    M5 --> GEM
    M6 -.릴레이.-> KXWP
    M7 --- CCPY
    M15 --- CCPY
    M1 --- EVT
    M9 --- PG
    M13 --- SGN
    M17 --- SGN
```

**설계 원칙**: (1) M2(홀 좌표계 위 부스 폴리곤) → M3(부스 내부 설계) → M4(배선) → M5(시각화)가 **하나의 공간 데이터 모델(PostGIS 지오메트리)을 공유**한다. 모든 모듈의 산출물이 좌표를 가지므로 시각화·검증·정산·wayfinding·BI가 같은 원천에서 나온다. (2) **폐루프 연결고리 = M15 옥션**: 코어(M2~M5)의 AI 산출물을 응찰 근거로 소비해 발주(M9)·시공으로 잇는다. (3) **M18 관리자**가 룰셋·마스터데이터·RBAC를 전 모듈·전 포털에 공급한다.

### 4-1. 모듈 우선순위 총괄 (M1~M18)

| 계열 | 모듈 | 우선순위 | v2.0 |
|---|---|---|---|
| 코어 | M2 배치 · M3 부스설계 · M4 배선 · **M5 나노바나나** | **P0** | 보존 |
| 판매운영 | M1 배정견적 · M6 서류 · M7 매칭 · M9 정산 | P1 | 보존 |
| 판매운영 | **M15 공사/장치 옥션(입찰)** | **P1(핵심 플로우)** | 신규 |
| 판매운영 | M8 반입/반출 물류 | P2 | 보존 |
| 관람참가 | **M10 관람객 등록·배지·체크인·리드캡처** | **P1** | 신규 |
| 관람참가 | **M12 마케팅·EDM·공개 홍보 사이트** | **P1** | 신규 |
| 관람참가 | M11 비즈니스 매칭 | P2 | 신규 |
| 관람참가 | M13 wayfinding·실내 내비 | P2 | 신규 |
| 관람참가 | M14 현장운영(혼잡·안전·주차·에너지) | P2 | 신규 |
| 경영 | **M16 경영분석 BI** | **P1(승격)** | 신규 |
| 경영 | **M17 CMS** | **P1** | 신규 |
| 경영 | **M18 관리자 시스템** | **P1** | 신규 |

---

## 5. 기능 상세 (모듈별)

우선순위 기준: **P0** = 핵심 차별화 + 첫 상용 행사 적용 필수 / **P1** = 운영 효율 핵심 / **P2** = 확장.

### M1. 행사·홀 배정 및 자동 견적 — P1

- **현재**: HWP 배정신청서 제출 → 담당자 협의 → 견적 수령 (수일).
- **AI 자동화 후**: 행사일정 DB 연동 가용성 캘린더에서 홀/반홀(예: 5A홀) 선택 → 규칙 엔진이 즉시 견적: `2,250원/㎡ × 면적 × 일수 × 성수기(3~5월·9~11월 +10%)/비수기(1·2·7·12월 -10%) × 1전시장 +10%` + 초과시간(시간당 1일 임대료의 1/10, 기본 12시간 08~20시, 장치일 6시간 무료) + 관리비 예치금 15~20%. 로비 10,000원/㎡·옥외 2,000원/㎡ 포함. 배정신청서는 웹폼 입력 → 킨텍스 제출 서식 자동 생성.
- **기대 효과**: 견적 리드타임 수일 → 즉시. 배정 협의는 사람이 유지(인기 행사 1~2년 전 접수 등 영업 판단 존재).
- **한계**: 최종 배정 확정은 킨텍스 내부 의사결정 — 시스템은 '신청+가견적'까지.
- **필요 데이터**: 임대요율표, 행사일정 DB, 홀/반홀 면적 마스터(1A 4,941㎡/1B 5,670㎡ 등).
- **연동**: 행사일정 시스템, M9 결제.

### M2. 플로어플랜 스튜디오 (부스 배치 자동화) — **P0**

- **현재**: 주최자가 CAD로 배치도 수작업 → D-7 kxwp 제출 → 홀매니저 육안 검수.
- **AI 자동화 후**:
  1. 홀 선택(예: 홀7 126×90m·바닥하중 5t/㎡·510부스 기준) + 조건 입력(목표 부스 수, 3×3m 기본/프리미엄 비율, 주출입구·무대·라운지)
  2. 배치 엔진이 통로 폭·비상구 접근·트렌치 위치를 제약조건으로 **정확히 3안(1안·2안·3안) 생성** (제약 충족 솔버 + 휴리스틱; 생성형 LLM이 아닌 결정적 알고리즘 중심, LLM은 조건 해석에 사용). 3안은 서로 다른 최적화 목표를 갖도록 다양화(예: 1안=부스 수 최대, 2안=동선·프리미엄 가시성 우선, 3안=피난·안전 여유 우선).
  3. **선택 또는 병합(merge)**: 사용자는 ① 한 안을 그대로 **선택**하거나, ② 여러 안의 구역/블록을 골라 **병합** — 예: "1안의 통로 구성 + 2안의 프리미엄존 배치 + 3안의 무대 위치"를 조합해 하나의 최종 배치로 합성. 병합 편집 화면에서 안별 레이어를 토글·드래그로 조합.
  4. 규정 자동 검증: 피난 통로 확보, 홀별 바닥하중(홀6 2t/㎡ vs 홀7~10 5t/㎡), 복층부스 가능 홀(고층고 12~15m 홀) 여부, 소방 규정 체크리스트. **병합 결과는 규정 검증을 재실행**(통로·바닥하중·비상구 재판정) — 병합으로 제약이 깨질 수 있으므로 확정 전 필수.
  5. **최종안 확정 → 버전 기록**: 확정 배치는 버전으로 저장(선택/병합 출처 안 번호 추적). 부스별 좌표·번호가 확정되면 참가업체 초대 링크 발급 → M3/M4의 입력이 됨.
- **기대 효과**: 배치 초안 수일 → 수 분. 검수는 "위반 플래그 확인" 작업으로 전환. 3안 비교·병합으로 주최자 영업 관행 반영 유연성 확보(R7 완화).
- **한계**: 소방 법규의 최종 유권해석·승인은 관할 기관/킨텍스 몫. 시스템 검증은 사전 필터.
- **필요 데이터**: 홀별 실측 도면(63×171m, 층고 10~15m, 기둥·셔터·비상구 좌표 — **킨텍스로부터 CAD 원본 확보 필요, 미확보 시 공개 규격 기반 근사 도면으로 Phase 1 진행**), 트렌치 그리드 좌표.
- **연동**: M5(홀 전경 시각화), M6(부스배치도 제출 서류 자동 생성), kxwp.

### M3. 부스 설계 스튜디오 (인테리어·장치 공사 설계) — **P0**

- **현재**: 조립부스는 주최측 기본 구조에 간판/가구/조명 옵션 신청서 작성. 독립부스는 장치업체가 평면·입면·조감·전기도면 작성 → kxwp 제출 → 반려 시 재작업.
- **AI 자동화 후**:
  - **조립부스**: 옵션(간판 문구, 가구, 조명)을 웹에서 선택 → 3D 프리뷰 + M5 예상 사진 즉시 생성.
  - **독립부스**: 부스 크기·업종·전시품·예산을 입력하면 AI가 레이아웃 초안(안내데스크, 시연존, 상담존, 창고) + 파라메트릭 구조(벽체·트러스·사인)를 **정확히 3안(1안·2안·3안) 생성**(예: 1안=시연 강조, 2안=상담·상권 동선 우선, 3안=예산 절감형). 사용자는 M2와 동일하게 ① 한 안 **선택** 또는 ② 여러 안의 구역/집기 블록을 조합해 **병합**해 최종 부스 설계를 만든다. 병합 결과는 규정 사전 검증(높이·이격·방염)을 재실행하고 최종안은 버전으로 기록. 장치업체는 확정 초안을 편집.
  - **규정 사전 검증**: 높이 5m 이하, 리깅 천장 6.5~8.5m(구조계산서 D-7 필요 플래그), 복층 1/2 이내, 방염 자재 체크리스트, 장내 금지작업(전기톱·용접·페인트) 공정 경고를 **제출 전에** 자동 플래깅.
  - 기존 도면(PDF/이미지) 업로드 시 비전 모델로 치수·구조 추출 → 동일 검증 적용 (정확도 한계로 "참고용 검증" 라벨).
- **기대 효과**: 반려 재작업 감소, 참가업체-장치업체 간 컨펌 사이클 단축(예상 사진으로 합의).
- **한계**: 자동 생성 설계는 '초안'. 시공 상세도·구조 판정은 장치업체/구조기술사 책임 — UI에 명시.
- **필요 데이터**: 부스 좌표(M2), 조립부스 표준 자재 카탈로그, 장치 규정집.
- **연동**: M7(장치업체 매칭), M5, kxwp(도면 제출).

### M4. 유틸리티 설계 자동화 (전기·조명 / 네트워크·급배수) — **P0**

두 서브모듈로 구성하되 하나의 배선 엔진 공유.

**M4a. 전기·조명**
- **현재**: 참가업체가 필요 용량을 추정해 신청(1kW 55,000원, 분전반 50A 추가 100,000원), 위치표시도 수기 작성, 공급은 장치 마지막 날 오후. 조명 설계는 장치업체 감.
- **AI 자동화 후**: 부스 내 기기 목록(전시장비·조명·PC) 입력 → kW 합산 → 분전반 용량·수량 자동 산출 → 최근접 트렌치에서 분전반까지 배선 경로 자동 생성(통로 횡단 최소화) → 요금 자동 견적. 조명은 부스 설계(M3) 기반 조도 목표(전시품 강조/상담존)별 배치안 제안 → 야간 점등 예상 이미지(M5).
- **기대 효과**: 용량 과소신청(현장 증설 불가 리스크)·과다신청 방지, 홀매니저는 홀 단위 부하 집계로 안전 관리.
- **한계**: 실제 전기 시공은 등록 전기시설 업체 수행. 조도 계산은 근사치(정밀 조도 시뮬레이션은 P2).

**M4b. 네트워크(인터넷/전화)·급배수·압축공기**
- **현재**: 인터넷 유선 150,000원/회선(KT 경유 회선당 80,000원 안내 병존 — **요금 정합성 킨텍스 확인 필요**), **현장 추가신청 불가**, 마감 약 D-25. 급배수·압축공기 각 150,000원/구, 위치표시도 온라인 등록 필수.
- **AI 자동화 후**: 부스 도면 위 단말 위치 클릭 → 트렌치 최단 배선 자동 산출 → 위치표시도 자동 생성(수기 작도 폐지) → 견적·신청·마감 리마인더(D-25 역산 알림)를 한 화면에서. 배선은 M5 오버레이 이미지로 확인.
- **기대 효과**: "현장 추가 불가" 유틸리티의 신청 누락 방지가 참가업체 최대 리스크 제거.
- **필요 데이터**: 홀별 트렌치 그리드 실측 좌표(홀1·7 가스 포함 여부 등 홀별 공급 매트릭스), 요금표 마스터.
- **연동**: M9(결제), kxwp/주최자 사무국(신청 릴레이), KT(인터넷 개통 — Phase 2 협의).

### M5. 나노바나나 시각화 — **P0 (핵심 차별화)**

- **현재**: 시공 결과를 사전에 볼 수 없음. 조감도는 외주 산출물로 배선·조명 미반영.
- **AI 자동화 후**: M2~M4의 구조화 데이터를 프롬프트로 컴파일해 Gemini 이미지 생성으로 "시공 후 사진" 표준 샷 세트 자동 생성. 상세는 6장.
- **기대 효과**: 참가업체 의사결정 가속, 주최자의 참가업체 유치 영업 자료, 장치업체 컨펌 커뮤니케이션 비용 절감.
- **한계**: 생성 이미지는 실제 시공과 다를 수 있음 — 전 이미지 워터마크·고지 필수(10장 리스크 참조).

### M6. 서류·마일스톤 워크플로 — P1

- **현재**: D-7에 신고서류 7종+(행사운영계획서, 부스배치도, 재해대처계획서, 방화관리 책임서약서, 주차관리 신청서, 보안요원 배치계획, 위험물 반입신고서, 리깅 구조계산서)를 HWP 작성 후 kxwp 업로드. 마감 추적은 담당자 수첩.
- **AI 자동화 후**: 행사 생성 시 D-150(배정)/D-30(사전협의)/D-25(유틸리티)/D-7(신고서류) 마일스톤 자동 생성·역산 알림. 서식은 웹폼 → HWP/PDF 자동 생성(킨텍스 제출 형식 유지). LLM 서류 검수: 누락 항목, 배치도-운영계획서 간 불일치(부스 수 등), 재해대처계획서 필수 요소 체크 → 홀매니저에게 검수 요약 리포트.
- **기대 효과**: 마감 지연 사고 감소, 홀매니저 검수 시간 단축.
- **한계**: kxwp 내부 API 미공개(robots.txt 차단, 로그인 폐쇄형) — 초기에는 "제출용 파일 생성 + 업로드 안내" 릴레이 방식, 연동은 킨텍스 협의 후.

### M7. 등록업체 매칭·견적 — P1

- **현재**: 14개 분류(전시디자인설치, 리깅, 전기시설, 카펫/파이텍스, 급배수/Air, 가스설비, 철거, 운수통관, 가구비품, 경비용역, 광고싸인물, 지게차, 방염, 구조해석) × 739개 업체 리스트를 지역 필터로 검색, 엑셀 다운로드.
- **AI 자동화 후**: 부스 규모·업종·예산·지역 기반 추천 → M3 설계안 첨부한 견적요청(RFQ)을 복수 업체에 발송 → 견적 비교. **독립부스 미등록 업체 시공 엄금** 규정을 시스템이 강제(등록업체만 초대 가능).
- **한계**: 업체 응답률·견적 품질은 시장 참여에 의존. 초기엔 매칭+연락 중개까지.

### M8. 반입/반출 물류 슬롯 — P2

- **현재**: 화물차 순번제·통행증, 중량물 5t 이상 우선, 지게차 지정업체 사전신청, 적재물 방치 시 즉시 폐기 — 현장 대기열 운영.
- **AI 자동화 후**: 하역장·화물출입구 슬롯 예약제, 중량물 우선순위 자동 배치, 통행증 QR 발급, 지게차 신청 연동. 철거일 피크 대기열 시뮬레이션.
- **한계**: 현장 통제 인력 운영과 결합해야 실효 — 킨텍스 운영팀 협업 전제.

### M9. 정산·결제 — P1

- **현재**: 계약금 20%→중도금 30%+20%→잔금 30%+예치금 15~20% 수동 관리, 행사 후 전기사용료·폐기물 처리비 정산.
- **AI 자동화 후**: 납부 스케줄 자동 생성·알림, 유틸리티 신청 건 PG 결제, 행사 후 실사용(전기 검침 등) 대비 예치금 정산 내역 투명화.
- **한계**: 킨텍스 재무 프로세스(세금계산서 등)와의 연동 협의 필요.

---

## 5A. v2.0 신규 모듈 (M10~M18)

> 벤치마크 근거는 각 모듈 말미 "근거"에 명시(크롤링 §머리말). 근거 없는 기능 확장은 배제하고, 킨텍스 도메인(공간 데이터·나노바나나·등록업체 규정)과 접합점이 있는 것만 채택했다.

### M15. 공사/장치 옥션(입찰) 플랫폼 — **P1 (핵심 플로우)**

> v2.0의 사업적 종결 모듈. **P0 코어(M2~M5)의 AI 산출물이 곧 응찰 근거 자료**가 되어, 설계→시각화→발주가 한 흐름으로 닫힌다.

- **현재**: 독립부스 시공은 킨텍스 등록 장치업체 필수이나(미등록 엄금), 참가업체는 739개 업체 리스트를 엑셀로 받아 개별 접촉·수기 견적 취합. 견적 비교·경쟁 유도 수단 없음.
- **AI 자동화 후 — 역경매(reverse auction) 옥션**:
  1. **자료 열람**: 참가업체/주최자가 옥션을 개설하면, 초대(또는 공개)된 **킨텍스 등록업체만** 포털에서 AI 생성 자료 — M2 배치도·M3 부스 설계안·M4 배선/**물량서(BOQ)**·M5 나노바나나 시공 예상 이미지 + 스펙/사양서 — 를 열람.
  2. **응찰 = 견적서(Quotation) 제출**: 업체는 열람 자료에 근거해 **정식 견적서를 제출하는 것으로 응찰**한다. 견적서 모델 = 항목(공종·자재)·수량·단가·금액·납기·유효기간·조건 라인 + 첨부(도면/사양)·**총액·부가세**. 견적서는 **PDF로 산출·버전 관리**(수정 시 새 버전, 라운드 내 재응찰 이력 보존).
  3. **옥션 메커니즘**: 옥션 유형 설정형 — **기본 역경매**(라운드/마감 내 더 낮은 금액 또는 더 높은 종합점수로 재응찰) / 필요 시 단일 라운드 RFQ·고정가 비교. **응찰 라운드·마감·실시간 순위** 노출(현재 순위/최저가/내 위치, 익명 순위 옵션). 라운드 종료 자동 마감.
  4. **낙찰 기준**: **최저가** 또는 **종합평가**(가격 + 평판(과거 시공 평점·규정 준수 이력) + 납기) 가중 스코어. 기준·가중치는 옥션 개설 시 설정, 결과 화면에서 항목별 비교표 제공.
  5. **낙찰(Award) → 계약·발주 연동**: 전시업체(참가업체/주최자)가 옥션 결과로 **업체를 확정(낙찰)** → 낙찰 견적서를 계약/발주 문서로 전환(M6 서류·M9 정산 연동), 시공 일정은 M8 반입/마일스톤과 연결.
- **등록업체 게이트(불변)**: M7 등록업체 DB 검증으로 **미등록 업체 응찰 원천 차단**. 14개 분류(전시디자인설치·리깅·전기시설 등)별 옥션 세분 가능.
- **엔티티**: `Auction(옥션: 유형·라운드·마감·낙찰기준·가중치) 1─N Quotation(=Bid, 견적서: 라인아이템·총액·부가세·납기·유효기간·PDF·버전·업체) ─ Award(낙찰: 선정 견적서·사유·계약/발주 링크)`.
- **기대 효과**: 견적 취합 수일·불투명 → 경쟁 응찰로 가격 최적화·투명화. AI 자료 기반이라 **동일 사양 위 공정 비교**(사과 대 사과) 가능.
- **한계**: 업체 참여율·응찰 품질은 시장에 의존. 킨텍스가 등록업체 옥션을 공식 채널로 인정하는지 협의 필요(규정상 '등록업체 시공 필수'는 옥션과 정합). 실제 계약 체결·법적 효력은 당사자 책임 — 시스템은 견적 경쟁·낙찰 기록까지.
- **필요 데이터**: 등록업체 DB(M7), M2~M4 물량/사양, 평판 데이터(초기엔 규정 준수 이력·자기신고, 축적 후 시공 평점), 공종 표준 단가(선택).
- **연동**: M2~M5(자료), M7(업체 검증), M6(계약 서류), M9(발주·정산), M8(시공 일정).
- **근거**: FindRFP·Procore·4castplus(RFQ/RFP/Tender 구분·역경매·종합평가), Exhibitoronline(전시 부스 RFP 항목·타임라인 RFI 180일/RFP 120~150일/RFQ 90일 전).

#### 입찰(옥션) 플로우 다이어그램

```mermaid
sequenceDiagram
    participant EX as 참가업체/주최자
    participant AU as M15 옥션
    participant CORE as M2~M5 AI 자료
    participant C1 as 등록업체 A
    participant C2 as 등록업체 B
    participant M7 as M7 등록업체 검증
    participant AW as 낙찰·발주(M6/M9)

    EX->>AU: 옥션 개설(유형=역경매, 낙찰기준=종합평가, 라운드/마감)
    CORE-->>AU: 배치·설계·배선/물량서·나노바나나 이미지 첨부
    AU->>M7: 응찰 자격 검증(등록업체만)
    M7-->>AU: A·B 적격 / 미등록 C 차단
    AU-->>C1: 자료 열람 권한
    AU-->>C2: 자료 열람 권한
    C1->>AU: 견적서 v1 제출(총액·납기)
    C2->>AU: 견적서 v1 제출
    AU-->>C1: 실시간 순위(현재 2위)
    AU-->>C2: 실시간 순위(현재 1위)
    C1->>AU: 견적서 v2 재응찰(라운드 내 인하)
    AU->>AU: 마감 → 종합점수(가격+평판+납기) 산정
    AU-->>EX: 견적서 비교표 + 순위
    EX->>AW: 낙찰(Award) 선정
    AW-->>C1: 낙찰 통지 → 계약/발주 전환
```

### M10. 관람객 등록·티켓·배지·현장체크인·리드캡처 — **P1**

- **현재**: 킨텍스 공식은 행사일정 검색 수준. 관람객 등록·배지·리드캡처는 행사별 주최자 사무국에 파편화(공통 플랫폼 부재).
- **AI 자동화 후**: **간편가입(이메일 또는 소셜 로그인) 또는 게스트 예매(가입 없이 티켓 구매, SCR-P7 기반영)** → 온라인 사전등록(관람객/바이어 유형별 폼) → **모바일 배지/QR 발급** → 현장 QR 체크인(즉석 배지 인쇄·오프라인 대비) → 실시간 입장 집계. 참가업체 **리드캡처**: 운영 앱(B2B)으로 관람객 배지 QR 스캔 → 연락처·관심도 평점·메모 저장 → 팔로업 EDM(M12) 연계. 사전등록·체크인 데이터는 M16 BI로 흐른다.
- **계정 트랙·승격 연속성(소유자 확정 2026-07-11, §2-1-1)**: 관람객은 **간편가입 트랙(2FA 미강제)** 이며 게스트 예매를 허용한다. 관람객 → **바이어/참가업체 담당자 승격** 시 **단일 계정 위 등급 상향**으로 처리해 **리드·비즈매칭·재방문 이력의 데이터 연속성**을 유지한다(계정 재생성 없음, 승격 시 업무 트랙 요건 2FA 추가). 게스트 예매 후 간편가입 시 예매 이력을 티켓 지갑에 병합.
- **관람객 AI 도우미(§8A 정합)**: visitor 메인의 AI 도우미는 **§8A-1 사용성 표준**(인라인 진입점·예시 질문 칩·구조화 카드+근거 인용)과 **§8A-2 토큰 최소화**(일정·교통·주차·부스 위치 등 사실조회는 **DB 직접 응답=LLM 미호출 P1**, 종합 필요 시에만 소형모델 우선 P2·RAG 발췌 P3)를 따른다. 이미 DB 근거로 답하는 구조를 §8A 계약(`/ai/ask`)으로 표준화.
- **채널**: 관람객 1차 접점은 공개 웹(SCR-P7/P8), 리텐션은 **관람객 앱(B2C, 스토어 공개)** — 티켓 지갑·배지/QR·wayfinding·비즈매칭(§2-1-1 B).
- **기대 효과**: 현장 등록 대기 제거, 게스트 예매로 가입 마찰 최소화, 참가업체 ROI 측정(리드 수·품질), 관람객 흐름 데이터 확보.
- **한계**: 배지 QR·리드캡처는 개인정보(§10 R10) — 동의·보존정책 필수. 오프라인 체크인 폴백 필요(현장 네트워크 불안정). 게스트 예매는 최소 개인정보 수집·사후 계정 병합 정책 명시 필요.
- **필요 데이터**: 관람객 폼 스키마, 배지 템플릿(M17 CMS), 부스-참가업체 매핑(M2).
- **연동**: M11 비즈매칭, M12 마케팅, M13 wayfinding, M16 BI.
- **근거**: Eventleaf·VenueSight·Whova·WebMobi(자가등록·QR 체크인·즉석 배지·리드 리트리벌 앱·관심도 평점·메모).

### M11. 비즈니스 매칭 — P2

- **현재**: 없음(주최자 개별 운영).
- **AI 자동화 후**: 관람객/참가업체 프로필·관심 업종·의향(intent) 기반 **AI 미팅 추천** → 미팅 슬롯 예약·일정 관리 → 부스 위치(M2)·wayfinding(M13) 연계 길안내. 매칭 성과는 M16 BI.
- **한계**: 매칭 품질은 프로필 데이터 충실도에 의존. AI 추천은 온프레미스/승인된 모델 범위 내(외부 API 게이트 §10 R12 준수).
- **필요 데이터**: 참가/관람 프로필(M10), 부스 업종 태그(M3).
- **연동**: M10·M13·M16.
- **근거**: Brella·Grip·Swapcard·RainFocus·Bizzabo(프로필·intent·행동신호 기반 AI 매치메이킹, 미팅 스케줄링).

### M12. 마케팅·EDM·공개 홍보 사이트(일반 대중) — **P1**

- **현재**: 킨텍스 공식 사이트는 정보·서식 다운로드 중심, 참가업체 전용 GNB 없음.
- **AI 자동화 후**: (1) **공개 홍보 사이트**(불특정 다수 대상) — 행사 소개·일정·교통·사전등록 유도, **SEO·다국어(한/영/중/일)** 최적화, 공개 인터랙티브 플로어플랜(M2 데이터 부산물). (2) **EDM/마케팅 자동화** — 세그먼트별(사전등록자·과거 관람객·바이어) 캠페인, 리마인더, 리드 팔로업(M10). AI 카피 초안·이미지(나노바나나 부스 예상샷 활용) 지원. 콘텐츠는 M17 CMS로 관리.
- **기대 효과**: 관람객 유치·재방문, 참가업체 노출, 킨텍스 브랜드 채널 통합.
- **한계**: 발송 규정(정보통신망법·수신동의) 준수, 다국어 번역 품질 검수 필요.
- **필요 데이터**: 행사 마스터(M1), 관람객 세그먼트(M10), 콘텐츠(M17).
- **연동**: M10·M11·M16·M17.
- **근거**: Event Tech Live·Swapcard(등록→리벤뉴 퍼널·EDM), 공개사이트·다국어는 GUARDiA 표준(SEO/다국어) 정렬.

### M13. Wayfinding·실내 내비 — P2

- **현재**: 없음. 양 전시장 100m 무빙워크·복수 홀 구조로 길찾기 난이도 높음.
- **AI 자동화 후**: M2 실측 플로어플랜 위 **블루닷 실내 내비**(부스·시설·비상구·화장실 검색·경로), 관람객 앱(M10)·비즈매칭(M11) 연계. 킨텍스 규모상 UWB/BLE 비콘 하드웨어 인프라 협의 전제(정밀), 미보유 시 **지도 기반 존-레벨 길안내(하드웨어 무의존)로 시작**.
- **한계**: 정밀 측위는 비콘 인프라 투자 필요(킨텍스 시설 협의). 초기엔 인터랙티브 지도·QR 스팟 안내로 대체.
- **필요 데이터**: M2 지오메트리, 시설 POI, (선택)비콘 좌표.
- **연동**: M2·M10·M11·M17(사이니지).
- **근거**: Pointr·Eventbase·Mapsted·Swapcard(블루닷·UWB+BLE·CES 2026 70만 세션), 존-레벨 폴백 실증.

### M14. 현장운영(혼잡·안전·주차·에너지) — P2

- **현재**: 소음 70~75dB 초과 시 전기 차단 등 수기 통제. 주차 iparking. 안전(안전모·금지작업)은 현장 육안.
- **AI 자동화 후**: 홀매니저 운영 대시보드에 **입장·혼잡 실시간(M10 체크인)**, 홀 단위 **전력 부하 집계(M4)**·에너지 모니터, 주차 점유(iparking 연계), 안전 체크(규정 위반 신고·소음·금지작업 플래그). 이상 시 알림.
- **한계**: 센서·IoT 연동은 킨텍스 시설 인프라 의존. 초기엔 M4/M10 파생 데이터 + 수기 입력 결합.
- **필요 데이터**: 체크인(M10), 전력(M4), 주차(iparking), 안전 룰셋(M18).
- **연동**: M4·M8·M10·M16.
- **근거**: Mapsted·Event Tech Live(현장 혼잡·에너지·운영 모니터링), 킨텍스 실측(소음/전력 규정).

### M16. 경영분석 BI — **P1 (P2→P1 승격)**

> 기존 design.md에서는 P2 게이트였으나 v2.0에서 **정식 P1 모듈로 스코프 편입**. **design.md 반영은 후속 designer 몫으로 표기**(planner는 스코프·데이터만 확정).

- **현재**: 정산·가동률·참가사 데이터가 산재. 경영 의사결정은 수기 집계.
- **AI 자동화 후**: 경영 대시보드 — **매출**(임대·유틸리티·옥션 수수료), **홀 가동률**(RevPAD·㎡당 수익·점유율), **참가사 리텐션**(재참가율), **이벤트 P&L**(행사별 손익), **수요예측**(성수기·홀별), **수율/가격 최적화**(요율·성수기 계수 시뮬레이션), **KPI 대시보드**. 온프레미스/승인 모델 범위 내 예측·이상탐지.
- **기대 효과**: 저성과 홀·시즌 식별, 가격·배정 전략 데이터화.
- **한계**: 정확도는 원천 데이터(M1·M9·M10·M15) 정합성에 의존. 예측은 참고치.
- **필요 데이터**: M1 배정·M9 정산·M10 관람·M15 옥션·행사일정.
- **연동**: 전 모듈(데이터 소비), M18(권한).
- **근거**: ExhibitForce·JoinWays·FinancialModelsLab·Digitevent·TicketFairy(RevPAD·㎡당 수익·점유율 60~75%·이벤트 P&L·B2B 전시 KPI).

#### M16-1. 운영사(킨텍스·venue operator) 관점 수익성/ROI

> **관점 구분 필수**: BI는 두 관점을 분리 제공한다 — **① 참가업체 관점 ROI**(리드 수·품질·부스 비용 대비 성과, M10 리드 기반)와 **② 킨텍스 운영사 관점 수익성/ROI**(전시장 자산 수익화). 본 소절은 **② 운영사 관점**을 명시한다. 두 관점은 별도 대시보드·권한(참가업체는 자기 부스, 킨텍스는 전 행사)으로 격리.

| # | 운영사 지표 | 정의/산식 | 데이터원 |
|---|---|---|---|
| ① | **홀·기간별 가동률(occupancy)** | 점유 홀·일수 / 가용 홀·일수 × 100, 반홀(1A/1B) 분할·공실 구분, 성수기/비수기 별 | M1 배정·행사일정 |
| ② | **매출 구성(revenue mix)** | 임대료(2,250원/㎡ 등) + 유틸리티(전기·급배수·인터넷) + 부대시설(옥외·로비·회의실·주차·옥션 수수료) 세그먼트별 | M1·M4·M9·M15 |
| ③ | **행사별 P&L / 수익성(마진)** | 행사 매출 − 직접원가(운영·에너지·인력) = 공헌이익·마진율, 행사 단위 손익 | M9 정산·M14 에너지·비용 마스터(M18) |
| ④ | **행사 유치·전시장별 ROI** | 전시장(1전시장/2전시장/홀별)·행사유형별 투자 대비 수익, RevPAD·㎡당 수익(㎡ 정규화로 대형홀 vs 소형홀 생산성 비교) | M1·M9·PostGIS 면적 |
| ⑤ | **참가사 리텐션·LTV** | 재참가율(코호트)·이탈률, 참가사 생애가치(LTV=누적 임대+유틸+옥션·평균 재참가 주기) | M1·M9 이력·다년 데이터 |
| ⑥ | **수요예측·수율/가격(yield/pricing) 최적화** | 성수기 계수·홀별 수요 예측, 요율·성수기(+10%)/비수기(-10%)·1전시장(+10%) 계수 시뮬레이션으로 수율 최적가 탐색 | M1 요율·과거 배정·M18 룰셋 |
| ⑦ | **경영진 KPI 대시보드** | 위 ①~⑥ 요약 + 목표 대비 실적(점유율 목표 60~75%·매출·마진·리텐션), 전시장·분기 드릴다운 | KpiSnapshot 집계 |

- **BI AI(§8A 정합·토큰 최소화 핵심)**: 모든 **집계·랭킹·추이 수치는 데이터마트 SQL이 산출(§8A-2 P6)**, LLM은 그 수치에 대한 **자연어 설명·해석만** 담당(수치 계산에 LLM 금지). 자연어 질의(예 "지난 분기 홀7 가동률은?")도 **SQL 집계 → 카드 렌더**를 우선하고, LLM은 설명·후속 제안에만 사용. 동일 기간/스코프 요약은 캐시 재사용(§8A-2 P4).
- **데이터마트 설계(DA 트랙)**: 위 지표는 운영 DB 직조회가 아니라 **BI 데이터마트(스타 스키마: FactBooking·FactSettlement·FactUtility·FactAuction·FactVisitor + DimHall·DimEvent·DimDate·DimExhibitor)** 로 집계한다. `KpiSnapshot`(배치/야간 적재) 또는 읽기 전용 복제로 운영 부하 회피(§8-1). **데이터마트 상세 모델링은 DA(데이터 분석가) 후속 트랙**이며, planner는 지표·데이터원·관점 분리만 확정.
- **한계**: LTV·리텐션은 다년 축적 데이터 필요(초기엔 단년 근사). 수율 최적가는 시뮬레이션 참고치이며 최종 요율 확정은 킨텍스 경영 의사결정(§10 R8).
- **근거**: JoinWays·FinancialModelsLab·TicketFairy(RevPAD·㎡당 수익·점유율 60~75% 목표·이벤트별 P&L·수율 관리), ExhibitForce(이벤트 ROI·수익성 대시보드).

### M17. CMS — **P1**

- **현재**: 킨텍스 공지 852건·홍보자료를 공식 사이트가 정적 관리. 참가업체 마이크로사이트 개념 없음.
- **AI 자동화 후**: 전시 **콘텐츠·공지 관리**, **참가업체 마이크로사이트**(부스 소개·제품·나노바나나 예상샷 게시), **다국어**(한/영/중/일) 콘텐츠, **사이니지 연계**(디지털 사이니지·wayfinding 화면 콘텐츠 배포 — GUARDiA Signage 패턴 참고). 게시 워크플로(초안→검수→게시)·버전관리.
- **한계**: 사이니지 하드웨어 연동은 킨텍스 시설 협의. 다국어 번역 검수 필요.
- **필요 데이터**: 콘텐츠 스키마, 행사/부스 마스터, (선택)사이니지 기기.
- **연동**: M12(마케팅)·M13(wayfinding)·M10(배지 템플릿).
- **근거**: GUARDiA CMS·Signage 하네스 패턴(헤드리스 콘텐츠·게시 워크플로·다국어·사이니지 배포) 정렬 + 킨텍스 공지/홍보 도메인.

### M18. 관리자 시스템(백오피스) — **P1**

> **M18 = §5B 공통/시스템관리 레이어의 "시스템관리(system)" 모듈이 킨텍스 도메인 마스터데이터를 얹은 것.** 즉 M18은 독립 재구현이 아니라 **UIWS 표준 `system` 모듈을 채택·확장**한 것으로 정의한다(중복 제거).

- **현재**: 없음(데이터·권한 통제 부재).
- **AI 자동화 후**: 별도 백오피스(`admin.`, 웹 전용) — UIWS 표준 시스템관리(사용자·역할 RBAC·공통코드·메뉴·감사로그·시스템설정) + **킨텍스 마스터데이터 관리**(홀 마스터·요율표·유틸리티 요금·규정 룰셋·등록업체 DB·표준 단가). 룰셋은 **버전 관리**(연 단위 요율·규정 개정 대응 — §8 룰 엔진과 결합).
- **기대 효과**: 크로스-테넌트 통제, 규정·요율 개정의 안전한 반영, 감사 대응.
- **한계**: 마스터데이터 원천(킨텍스 공식 확정본) 확보 필요(§7).
- **필요 데이터**: 전 마스터데이터, 사용자·권한 스키마(UIWS `TB_*`).
- **연동**: 전 모듈·전 포털(RBAC·룰셋 공급).
- **근거**: **UIWS 표준(`workspace/uiws`) 시스템관리** + GUARDiA 표준 프레임워크 §1·§3(사용자·RBAC·감사로그·시스템설정 백오피스 표준) 정렬.

---

## 5B. 공통/시스템관리 레이어 (UIWS 표준 이식)

> **채택 근거**: kintex 스택(Spring Boot 3.x·Java 17·React·MyBatis·PostgreSQL)이 **UIWS(UIMS, `workspace/uiws`) = GUARDiA 표준 프레임워크**와 동일하므로, 시스템관리·공통 업무 기능을 재설계하지 않고 **UIWS 표준을 공통 레이어로 그대로 이식**한다. 킨텍스 도메인 모듈(부스 M2~M5·옥션 M15·관람객 M10·BI M16·CMS M17 등)은 **이 공통 레이어 위에 얹힌다.** 이식 레퍼런스·정본 = `workspace/uiws`(읽기 전용), 표준 명세 = `workspace/_framework/GUARDIA_STANDARD_FRAMEWORK.md`. 이식 실행은 `uiws-port-orchestrator` 트랙(후속 개발). — **P1 (전 모듈 선행 기반)**

### 5B-1. 시스템관리 (system) — M18과 통합

UIWS 표준 시스템관리를 kintex 관리자 백오피스(`admin.`)의 기반으로 채택. **M18은 이 모듈 + 킨텍스 마스터데이터 확장**이며 중복 정의하지 않는다.

| 기능 | UIWS 표준 | kintex 확장/접합 |
|---|---|---|
| 사용자 관리 | `TB_USER` CRUD·상태·부서 | 6역할(§2) + 등록업체 계정·관람객 셀프서비스 계정 |
| 역할/권한 RBAC | 역할 게이트 `/api/admin/** = hasRole(ADMIN)` | 플랫폼 레벨(관리자) + 행사 레벨(주최자/참가/업체/홀매니저) 이중 평가(§8-1) |
| 공통코드(adminCode) | 코드 그룹·상세 | 홀/부스유형/공종(14분류)/유틸리티 요금코드 등 도메인 코드 |
| 메뉴 관리 | 메뉴 트리·권한 매핑 | 역할별 포털 IA(§2-1) 메뉴 구동 |
| 감사로그(audit) | `TB_AUDIT_LOG` | 승인·**낙찰(M15)**·설계 변경·룰셋 개정·리드 접근(개인정보) 전수 기록 |
| 시스템설정 | 환경설정 | 요율/규정 룰셋 버전, AI 게이트, 마감(D-25/D-7) 정책 |

### 5B-2. 공통 업무 기능 (전 역할 공용)

UIWS 표준 공통 모듈을 이식해 전 포털이 공유. 킨텍스 도메인 접합점을 명시(불필요 이식 배제).

| 공통 모듈 | UIWS 표준 | kintex 접합 |
|---|---|---|
| worklog(업무일지) | 일일 업무일지·댓글 | 홀매니저 현장 일지, 업체 시공 일지 |
| schedule(일정) | 개인/부서 일정·캘린더 | 행사 마일스톤(M6)·옥션 마감·반입 슬롯(M8) 통합 뷰 |
| message(쪽지) | 사내 쪽지 | 주최자↔참가업체↔업체↔홀매니저 행사 내 커뮤니케이션 |
| notice(공지) | 공지 게시·팝업 | 킨텍스 공지(852건 도메인)·행사 공지 → M17 CMS와 채널 정합 |
| opinion(의견접수) | 의견/건의 | 고객의소리·규정 문의 |
| search(통합검색) | 크로스 모듈 검색 | 행사·부스·업체·문서·콘텐츠 통합 검색 |
| meeting(회의록) | 회의 녹음→STT→회의록(Jasper PDF) | 사전업무협의(D-30) 회의록 자동화 |
| report/보고(stats) | 일/주/월/분기/연 업무보고·통계(Jasper PDF) | 운영 리포트·M16 BI 원천 피드(중복 회피: 경영지표=M16, 업무보고=공통) |
| notification(알림센터) | 통합 알림 | 마감 리마인더(D-데이)·낙찰·승인·결제 알림, WebSocket |
| preference(개인화) | 즐겨찾기·최근방문 | 역할별 대시보드 개인화 |

> **경계(중복 제거)**: 경영·수익 지표는 **M16 BI**가 권위, 일상 업무보고·통계는 공통 `report/stats`가 담당. 콘텐츠/공지 발행은 **M17 CMS**가 권위, 사내 알림성 공지는 공통 `notice`. 알림 발송 채널은 공통 `notification` 단일화(M10·M12·M15가 이벤트 발행).

> **공통 AI 보조(§8A 정합)**: 전 업무 화면의 AI 보조(search·meeting 액션아이템·report 요약·초안 생성 등)는 **§8A 단일 AI 계약(`/ai/ask`)·사용성 표준·토큰 최소화 원칙**을 공유한다 — 사실조회는 결정론/DB 직답(LLM 미호출), 종합은 소형모델 우선·Claude 승급(`AiTextRouter`)·RAG 발췌·캐시·구조화 출력. 신규 LLM 직접 호출 경로 신설 금지(중앙 `/ai/ask` 경유).

### 5B-3. 인증 (UIWS 표준: JWT + 2FA/OTP)

kintex 인증은 §2 행사 단위 RBAC를 **UIWS 표준 인증 위에** 구현한다(재설계 금지).

- **JWT + RBAC**: 발급·역할 게이트. §8-1 SSO(플랫폼+행사 이중 권한)와 결합.
- **2차 인증 OTP(TOTP RFC6238)**: SHA1·30s·6자리·±1 윈도우. `TotpService` 이식 — 로그인 2단계(비번→OTP), 최초 QR 등록, 마이페이지 재설정/해제, 관리자 OTP 초기화(`otp_secret=NULL`). **대상(소유자 확정 2026-07-11, §2-1-1 정합)**: **업무 사용자(주최자·참가업체·공사업체·킨텍스 직원·플랫폼/테넌트 관리자) = 필수**, **일반 관람객 셀프서비스 = 미강제(선택)**. 관람객이 바이어/참가업체 담당자로 승격(§2-1-1 A)하면 그 시점부터 업무 트랙 요건으로 2FA가 필수 전환된다.
- **로그인 실패 잠금** + 관리자 해제.
- **admin 비밀번호**: env `ADMIN_PASSWORD_ENC`(AES-256-GCM) + `ADMIN_KEY_FILE`(별도 키파일 root 600) 복호 → 기동 시 BCrypt 재시드. **하드코딩 `admin123` 시드 금지**(§10 보안).
- **스키마**: UIWS `TB_USER`·OTP 시크릿 컬럼·`TB_AUDIT_LOG` 이식(멱등 DDL, sql.init `mode=always`+continue-on-error).

### 5B-4. 이식 원칙

1. **재설계 금지·이식 우선**: 공통 레이어는 `workspace/uiws` 코드/스키마/디자인을 이식(수정 최소화). 킨텍스 고유는 도메인 모듈에만.
2. **선행 기반**: 공통/시스템관리·인증은 도메인 모듈(M1~M17)보다 **선행**(Phase 1 착수 전제 — §9 갱신).
3. **중복 제거**: M18=시스템관리(5B-1), 기존 문서의 "관리자 시스템"은 본 절로 흡수. BI/CMS/알림은 위 경계 규칙으로 공통과 분리.
4. **디자인**: 공통 화면은 UIWS/WISE 디자인을 kintex design.md 토큰으로 정합 — **designer 후속 반영 필요**(planner는 스코프·구조만 확정).

---

### 기능 우선순위 총괄표

| 모듈 | 기능 | 우선순위 | 필요 데이터 | 연동 |
|---|---|---|---|---|
| M2 | 부스 배치 자동 생성·규정 검증 | **P0** | 홀 실측 도면, 트렌치 좌표 | kxwp, M5 |
| M3 | 부스 설계 초안 + 규정 사전 검증 | **P0** | 규정집, 자재 카탈로그 | M7, M5, kxwp |
| M4a | 전기 용량·분전반·배선 + 조명 | **P0** | 트렌치 좌표, 요금표 | M9, M5 |
| M4b | 네트워크·급배수 배선 + 위치표시도 자동화 | **P0** | 트렌치 좌표, 요금표 | M9, KT |
| M5 | 나노바나나 시공 예상 사진 | **P0** | M2~M4 데이터, 참조 사진 | Gemini API |
| M1 | 가용성 조회·자동 견적 | P1 | 요율표, 행사일정 | 행사일정 DB |
| M6 | 마일스톤·서류 워크플로 | P1 | 서식 템플릿 | kxwp |
| M7 | 등록업체 매칭 | P1 | 등록업체 DB 739 | CCPY |
| M9 | 정산·결제 | P1 | 요율·납부 규칙 | PG |
| M8 | 반입/반출 슬롯 | P2 | 하역장 배치 | 운영팀 |
| **M15** | **공사/장치 옥션(역경매·견적서 응찰·낙찰)** | **P1(핵심)** | M2~M4 물량/사양, 등록업체 DB, 평판 | M2~M5, M7, M9, M6 |
| **M10** | **관람객 등록·배지·체크인·리드캡처** | **P1** | 관람객 폼, 배지 템플릿, 부스 매핑 | M11, M12, M13, M16 |
| **M12** | **마케팅·EDM·공개 홍보 사이트(SEO·다국어)** | **P1** | 행사 마스터, 관람 세그먼트 | M10, M16, M17 |
| **M16** | **경영분석 BI(운영사 관점 수익성/ROI + 참가사 ROI: 가동률·매출구성·행사별 P&L·전시장 ROI·리텐션/LTV·수율/가격·경영진 KPI)** | **P1(승격)** | M1·M4·M9·M10·M15·행사일정 → BI 데이터마트 | 전 모듈 |
| **M17** | **CMS(콘텐츠·마이크로사이트·다국어·사이니지)** | **P1** | 콘텐츠 스키마, 행사/부스 마스터 | M12, M13 |
| **M18** | **관리자 백오피스(RBAC·감사·마스터데이터·룰셋)** | **P1** | 전 마스터데이터, 사용자/권한 | 전 모듈·전 포털 |
| **§5B** | **공통/시스템관리 레이어(UIWS 표준 이식) + JWT+OTP 인증** | **P1(전 모듈 선행 기반)** | UIWS `TB_*`·표준 스키마 | 전 모듈·전 포털 |
| M11 | 비즈니스 매칭 | P2 | 프로필, 부스 업종 태그 | M10, M13, M16 |
| M13 | wayfinding·실내 내비 | P2 | M2 지오메트리, POI, (선택)비콘 | M2, M10, M17 |
| M14 | 현장운영(혼잡·안전·주차·에너지) | P2 | 체크인·전력·주차·안전 룰셋 | M4, M8, M10 |
| — | 다국어 규정 챗봇, 관람객 플로어플랜 | P2 | 매뉴얼 코퍼스 | — |

---

## 6. 나노바나나 시각화 파이프라인

> **제어 파라미터 확정 (v1.1)**: 본 장의 모델·SDK·프롬프트 아키텍처·방어 로직은 ReRoomAI 소스 분석(`docs/analysis/reroomai-source.md`)의 실증 기법으로 확정되었다. ReRoomAI는 "건축 골격 보존 + 표면 요소 교체"라는 동형(同型) 문제(빈 부스 골격 유지 + 배치·인테리어·조명·배선 시공 결과 합성)를 검증된 단일 호출로 해결하고 있어, 그 호출 스택·프롬프트 패턴·방어 로직을 부스 도메인으로 치환해 채택한다.

### 6-1. 파이프라인 개요

```
구조화 데이터(M2~M4) → 씬 컴파일러(3D 간이 렌더/도면 래스터, 긴 쪽 1024px) → 프롬프트 빌더(구조화 사전 조립)
→ Gemini image-to-image 편집(참조 이미지 inlineData + 지시문 text) → RenderJob 방어·검수 → 후처리(워터마크·메타데이터) → CDN 캐시
```

핵심 원칙: **텍스트 프롬프트 단독 생성이 아니라, 시스템이 만든 도면/간이 렌더를 참조 이미지로 넣어 구조(부스 위치·크기·통로·앵글)를 보존하고 스타일만 사실화**한다. ReRoomAI의 "참조 이미지 기반 구조 보존 + 스타일 변환" 패턴을 부스 도메인으로 이식한다. Stable Diffusion·ControlNet 등 별도 파이프라인 없이 **Gemini 이미지 모델 단일 호출**이 원본 구조를 참조·보존한다는 점이 ReRoomAI에서 실증되었다.

### 6-2. 입력 데이터 스키마 (요약)

```yaml
scene:
  hall: { id: "H7", dims_m: [126, 90], ceiling_m: 12, floor: "concrete_polished" }
  booth: { id: "A-102", polygon: [...], size_m: [6, 3], height_m: 4.2, type: "independent" }
  design:                       # M3 산출
    walls: [...], signage: { text: "...", height_m: 3.8 }
    zones: [{ type: "demo" }, { type: "consult" }]
    materials: [{ part: "wall", finish: "matte_white", fire_retardant: true }]
  lighting:                     # M4a 산출
    fixtures: [{ type: "spot", count: 6, target: "product" }]
    mode: "day" | "night"
  wiring:                       # M4 산출, 오버레이 샷 전용
    power: [{ from_trench: [x,y], to: [x,y], kw: 3 }]
    network: [{ type: "lan", path: [...] }]
shot: { preset: "front", camera_height_m: 1.6, fov: 60 }
render_hints: { style: "photoreal_tradeshow", crowd: "sparse" }
```

### 6-3. 표준 샷 세트

| 샷 | 카메라 | 용도 | 생성 트리거 |
|---|---|---|---|
| S1 부스 정면 | 통로에서 눈높이 1.6m | 참가업체 컨펌 기본 컷 | M3 저장 시 자동 |
| S2 야간/점등 뷰 | S1 동일 구도, lighting=night | 조명 설계 검토 | M4a 조명 확정 시 |
| S3 통로 뷰 | 인접 통로에서 비스듬히, 옆 부스 포함 | 관람객 시선 시뮬레이션 | 요청 시 |
| S4 부스 내부 | 부스 안 상담존 시점 | 내부 동선 검토 | 요청 시 |
| S5 Before/After | 빈 홀 바닥 사진 ↔ S1 합성 페어 | 영업·홍보 | S1 생성 시 자동 페어링 |
| S6 배선 오버레이 | S1/평면 탑뷰에 전기(적)·네트워크(청)·급배수(녹) 경로 오버레이 | 시공업체·홀매니저 검증용 | M4 저장 시 |
| S7 홀 전경(조감) | 홀 전체 아이소메트릭 | 주최자 배치안 비교 | M2 배치안 생성 시 |

S6(배선 오버레이)는 **생성형 이미지가 아니라 백엔드 래스터 합성이 우선**이다. 시공업체·홀매니저의 검증 산출물이므로 좌표 정확성이 목적이며, 생성 모델의 재질/색 왜곡이 개입되면 안 된다 → PostGIS 배선 지오메트리(전기 적·네트워크 청·급배수 녹)를 S1/평면 탑뷰 위에 백엔드 렌더러로 정확 오버레이하고, **배경만(부스 골격·바닥) 생성 이미지를 사용**한다. 이 경로는 Gemini 호출 없이(또는 배경 1회만) 결정적으로 산출된다. (BACKLOG B-02 — developer 트랙 백엔드 래스터 렌더러로 구현)

### 6-4. 모델·SDK·프롬프트 아키텍처 (ReRoomAI 실증 기법 확정)

**(1) 호출 스택 — 검증된 정답 채택**

| 항목 | 확정값 | 근거 |
|---|---|---|
| SDK | `@google/genai` (Google 공식) | ReRoomAI `route.ts` 프로덕션 검증 |
| 모델 | `gemini-3.1-flash-image-preview` (나노바나나 2 / Nano Banana 2) | 동일 |
| 호출 형태 | `ai.models.generateContent()` — image-to-image 편집 | 동일 |
| 입력 구성 | `parts` 배열에 **입력 이미지 `{ inlineData: { mimeType, data(base64) } }` + 지시문 `{ text }`** 동시 전달 | 멀티모달 인페인팅형 편집 — 원본 구조 참조·보존 |
| 응답 처리 | candidate에서 `inlineData`(생성 이미지 base64) 추출 | 동일 |

`tools/nanobanana/`(프로젝트 규칙) 모듈이 이 호출 패턴을 표준화하며, `nanobanana-visualize` 스킬이 부스 도메인 래퍼를 제공한다.

**(2) 프롬프트 = 구조화 사전 조립 + "보존/교체 명시적 분리"**

ReRoomAI `lib/constants.ts`의 핵심 패턴 — UI 라벨(한글)과 프롬프트 조각(영문)을 한 객체에 묶어 **UI 선택과 서버 프롬프트가 단일 출처를 공유** — 를 부스 도메인 구조화 사전으로 이식한다. 각 항목은 `{ id, label(한글), prompt(영문), swatch? }` 형태.

```ts
// 부스 유형 — 골격 특성 프롬프트 조각
BOOTH_TYPES = [
  { id: "assembled", label: "조립부스", prompt: "standard octanorm shell scheme booth, aluminium frame walls" },
  { id: "independent", label: "독립부스", prompt: "custom-built independent booth, free-standing structure" },
  { id: "corner", label: "코너부스", prompt: "corner booth open on two aisle-facing sides" },
  { id: "island", label: "아일랜드부스", prompt: "island booth open on all four sides" },
]

// 부스 스타일 — 표면·분위기 프롬프트 조각(+ swatch 색3종)
BOOTH_STYLES = [
  { id: "luxury", label: "럭셔리", prompt: "premium luxury exhibition design: warm wood, brass accents, layered lighting" },
  { id: "tech",    label: "테크",   prompt: "high-tech booth: LED walls, dark palette, cool white accent lighting" },
  { id: "eco",     label: "친환경", prompt: "sustainable booth: recycled timber, greenery, warm diffuse lighting" },
  { id: "minimal", label: "미니멀", prompt: "minimal booth: clean white surfaces, hidden lighting, uncluttered" },
]

// 시공 레이어 — 조명/전기/네트워크 레이어별 프롬프트 조각(변형 렌더용)
FIXTURE_LAYERS = {
  lighting: { day:   "even daylight-balanced exhibition lighting",
              night: "dramatic accent spotlights on products, dimmed ambient" },
  power:    "power outlets and distribution box neatly integrated at booth base",
  network:  "network access point and cabling routed along booth structure",
}
```

이 사전들은 M2(부스 유형)·M3(스타일·집기)·M4(조명 모드·배선 레이어) UI 선택값과 그대로 매핑되어, 프롬프트 빌더가 조각을 조립한다.

**(3) 부스 도메인 프롬프트 템플릿 (보존/교체 명시 잠금)**

ReRoomAI 4단 구성(대상+스타일 → 보존 잠금 → 교체 지정 → 사진 품질)을 부스로 치환:

```
Render this exhibition booth as if construction is complete.
① 대상+스타일: {BOOTH_TYPES.prompt} at KINTEX exhibition hall, styled as {BOOTH_STYLES.prompt}.
② 보존 잠금(KEEP EXACTLY THE SAME):
   booth outer footprint dimensions, structural columns, floor trench grid,
   ceiling truss, aisle direction and the camera angle.
③ 교체·배치(REPLACE / PLACE):
   fixtures — desks, shelves, banners, signage;
   {FIXTURE_LAYERS.lighting[mode]}; {FIXTURE_LAYERS.power}; {FIXTURE_LAYERS.network};
   carpet and booth wall graphics — to match the target style.
④ 사진 품질:
   photorealistic trade-show photography, natural exposure, high detail,
   Korean exhibition hall interior (concrete polished / carpet floor per hall).
```

- **가변 직렬화**: 씬 스키마(6-2)의 치수·자재·간판 문구를 자연어로 직렬화해 위 슬롯에 주입. 홀별 사전 촬영 참조 사진을 함께 참조 이미지로 전달(홀6 카펫·홀7 콘크리트 폴리싱 등).
- **구조 보존 강화**: 씬 컴파일러 간이 렌더(회색 박스 수준)를 참조 이미지 `inlineData`로 제공 → "이 구도·배치를 유지, 사실적 재질로만".
- **간판 텍스트**: 생성 후 비전 모델로 오탈자 자동 검수. **한글 텍스트 렌더링 불안정은 알려진 한계** → 실패 시 간판 영역 후처리 합성.
- **레이어 변형**: `FIXTURE_LAYERS.lighting.night`만 교체하면 S2(야간 점등), 배선 레이어 강조는 S6(단, S6은 6-3대로 래스터 합성 우선).

**(4) 일관성·비용 제어**

- **일관성**: 같은 부스 S1~S5는 동일 참조 체인(간이 렌더 + 직전 결과)으로 생성해 컷 간 자재·색상 일치 유도. 완전 일치는 보장 불가 — UI에 "컷별 차이 존재 가능" 고지. (Gemini 시드 지원 범위는 구현 시 확인 — BACKLOG B-12)
- **비용 제어**: 저장 시 자동 생성은 S1·S7만, 나머지는 온디맨드. **동일 스키마 해시 캐시**. RenderJob 쿼터는 성공 시에만 차감(6-5).

### 6-5. RenderJob 방어 로직 및 UX (ReRoomAI (D)(E)(G) 이식)

**(1) Canvas 1024px 전처리 (전송량·비용·지연 동시 절감)**
- 클라이언트에서 도면/현장 사진을 **긴 쪽 1024px 다운스케일 → `toDataURL('image/jpeg', 0.85)` → base64 data URL**로 변환 후 전송. ReRoomAI `Studio.handleImageFile`과 동일. 부스 간이 렌더도 동일 규격으로 정규화.

**(2) RenderJob 워커 방어 로직 (ReRoomAI `route.ts` 골격 복제)**
- **다층 크기 가드**: content-length 상한(8MB) → base64 실크기(×1.33) 재검증.
- **mimeType 자동 감지**: data URL에서 mimeType + base64 정규식 분리(하드코딩 금지).
- **SAFETY 처리**: 응답 `finishReason==='SAFETY'` → 차단 에러로 분기.
- **에러 분기 → 친화적 한글 메시지**: `API_KEY_INVALID` / `RESOURCE_EXHAUSTED·quota·429` / `SAFETY` 구분.
- **성공 시에만 쿼터 차감**: 실패는 사용량 소모 안 함. ReRoomAI는 인메모리 `Map<ip,...>`이나(재시작·다중 인스턴스 취약) — 본 시스템은 **PostgreSQL/Redis 기반 RenderJob 쿼터**(행사별 상한, 6-4 비용 제어와 통합)로 대체.
- 전 과정 비동기(8장): RenderJob 큐잉 → 워커 Gemini 호출 → WebSocket 완료 푸시 → 재시도·비용 상한·스키마 해시 캐시 워커 레벨 관리.

**(3) 단계별 로딩 UX**
- ReRoomAI `LOADING_STATUSES` 순환 패턴을 부스용으로 치환: **"부스 골격 인식 → 집기 배치 → 전기·조명 배선 → 최종 고화질 렌더링"**을 `aria-live`로 순환 표시. 진행 배지("생성 중… 평균 40초")와 연결. 결과는 Before/After 드래그 슬라이더(ReRoomAI `CompareSlider.tsx` 거의 무수정 재사용 — clip-path + 포인터 캡처 + 키보드/ARIA)로 S5(빈 부스 ↔ 시공 후) 표시.

### 6-6. 워터마크·고지 정책 (필수)

- 모든 생성 이미지에 시각 워터마크 "**AI 생성 예상 이미지 — 실제 시공 결과와 다를 수 있음**" + 메타데이터(생성일, 스키마 해시, 모델 버전) 임베드.
- 계약·심사 서류에는 생성 이미지 사용 금지(도면만 유효) — 시스템이 서류 생성 시 자동 배제.
- 참가업체-장치업체 간 분쟁 예방: 컨펌 화면에 "시공 기준은 도면" 동의 체크.

---

## 7. 데이터 및 연동

### 7-1. 마스터 데이터 (킨텍스 실측)

| 데이터셋 | 내용(분석 문서 실측값) | 확보 방법 | 상태 |
|---|---|---|---|
| 홀 마스터 | 1전시장 홀1~5(홀당 10,611~10,773㎡, **171×63×15m**, 5t/㎡, 약 600부스) + **옥외전시장 2,849㎡**, 2전시장 홀6(5,580㎡=**93×60×10m**, 2t/㎡, 카펫, 200부스)·홀7/8(각 11,290㎡, 126×90×12m, 510부스)·홀9(13,238㎡)/홀10(13,072㎡, 132×99×15m). 반홀 분할(1A 4,941㎡/1B 5,670㎡ 등). **제3전시장(2028) 홀11~18 계획** | 공개 스펙 + 킨텍스 CAD 원본 요청 | 공개값 확보(2차 검증 반영), CAD 협의 필요 |
| 트렌치 그리드 | 홀별 트렌치 위치·공급 매트릭스(전기·급배수·압축공기·전화·인터넷, 홀1·7 가스) | **킨텍스 제공 필수** — 미공개 | 미확보 (Phase 1 착수 조건) |
| 요율 마스터 | 전시홀 2,250원/㎡(12h), 로비 10,000원/㎡, 옥외 2,000원/㎡, 이벤트홀 2,420원/㎡, 성수기 +10%/비수기 -10%/1전시장 +10%, 용도 외 30% 할증, 예치금 15~20% | 공개 임대요율표 | 확보 |
| 유틸리티 요금 | 전기 1kW 55,000원·분전반 50A 100,000원, 압축공기 150,000원/구, 급배수 150,000원/구, 인터넷 150,000원/회선(KT 80,000원 병존 — 정합 확인 필요) | 참가업체 매뉴얼 | 확보(검증 필요) |
| 부스 표준 사양 | **조립(기본)부스 표준 포함 품목: 스포트라이트 5개·220V 2구 콘센트 1개·방염 A급 바닥재·기본 전력 1kW/부스. 프리미엄 부스 6×3×4m·2kW.** 초과 전력·조명은 유틸리티 추가 신청 | 참가업체 매뉴얼(kintex.com 2차 검증) | 확보 |
| 규정 룰셋 | 높이 5m, 리깅 6.5~8.5m+구조계산서 D-7, 복층 1/2, 방염, 소음 70~75dB, **이격(인접 벽 30cm·천장 60cm), 조명 반입 금지(지정 조명만 사용)**, 금지작업 목록 | 매뉴얼 → 룰 엔진 코드화 | 확보 |
| 회의실 마스터 | 37개 회의실, 시간대별 요금 (P2 범위) | 공개 요율표 | 확보 |

> **v3.0 테넌트 스코프 재정의(§1A-1)**: 위 §7-1 마스터데이터는 모두 **테넌트(전시관) 소유**로 재정의된다 — 표에 기재된 킨텍스 실측값(홀1~10, 2,250원/㎡, 높이 5m·리깅 6.5~8.5m 등)은 **테넌트 #1(KINTEX)의 초기 시드**이며, 코엑스 등 신규 테넌트는 자기 전시관의 홀·요율·유틸리티 요금·규정 룰셋·부스 표준을 **별도 소유·입력**한다(값이 다를 수 있음, 근거 없는 추정 금지). 각 마스터 행에 `tenant_id`가 부여된다(§1A-2). 코엑스 실측값은 미확보 — 온보딩 시 입력(§1A-5).

### 7-2. 외부 연동

| 대상 | 방식 | 불확실성 |
|---|---|---|
| kxwp/kxfp 작업신고 | 초기: 제출 파일 자동 생성 + 업로드 안내(수동 릴레이). 목표: API 연동 | **높음** — 폐쇄형, API 미공개. 킨텍스 IT 협의 필수 |
| 등록업체 DB(739) | 웹 공개 데이터 주기 수집(엑셀 다운로드 제공됨) → 자체 DB화, 추후 공식 피드 | 낮음 |
| 행사일정 시스템 | 공개 캘린더 수집 → 가용성 역산(정확한 가용성은 킨텍스 내부 데이터 필요) | 중간 |
| Gemini API | `tools/nanobanana/` 모듈 경유(프로젝트 규칙), `GEMINI_API_KEY` | 낮음 (쿼터·비용 관리 필요) |
| PG 결제 | 국내 PG(카드·계좌이체·세금계산서) | 낮음 |
| KT 인터넷 개통 | Phase 2 협의 | 중간 |
| iparking(주차) | P2 | — |

### 7-3. 핵심 엔티티 (요약 ERD)

`Event(행사) 1─N Hall배정 1─N Booth(부스, PostGIS polygon) 1─N DesignPlan(버전, 3안·선택/병합 출처 추적) / UtilityOrder(전기·네트워크·급배수, 배선 LineString) / RenderJob(샷, 상태, 이미지) / Document(서식, 마일스톤) / Company(등록업체) / Payment`

**v2.0 추가 엔티티**:
- 옥션: `Auction(유형·라운드·마감·낙찰기준·가중치) 1─N Quotation(=Bid, 견적서: 라인아이템[공종·자재·수량·단가·금액]·총액·부가세·납기·유효기간·조건·첨부·PDF·버전·업체) ─ Award(낙찰: 선정 견적서·사유·계약/발주 링크)`. Auction은 Booth/DesignPlan/UtilityOrder(물량)·RenderJob(이미지)을 참조 자료로 첨부.
- 관람: `Visitor(관람객) 1─N Registration(등록·유형) 1─N Badge(QR) ─ CheckIn(체크인) ; Lead(리드: 참가업체─관람객·관심도·메모) ; Meeting(비즈매칭 미팅·슬롯)`.
- 경영/관리: `KpiSnapshot(BI 집계) ; Content(CMS 콘텐츠·다국어·버전) ; Microsite(참가업체) ; MasterData(홀·요율·요금·룰셋·버전) ; User·Role·AuditLog(M18)`.
- 공간 데이터 공유(불변): Booth 폴리곤·배선 LineString은 M13 wayfinding·M14 부하집계·M16 ㎡당 수익이 동일 PostGIS 원천을 재사용.

**v3.0 추가 엔티티 (멀티테넌시 §1A)**:
- 최상위 테넌트: `Tenant/Venue(전시관: tenant_code·tenant_name(다국어)·branding·domain/subdomain·active·locale_default) 1─N (전 도메인 엔티티)`. 킨텍스=`tenant_id=1`(기준), 코엑스=`tenant_id=2`.
- **`tenant_id` 전파(불변 격리)**: 위 §7-3의 **전 도메인 엔티티**(Event·Hall·Booth·DesignPlan·UtilityOrder·RenderJob·Document·Payment·Company·Auction·Quotation·Award·Visitor·Registration·Badge·CheckIn·Lead·Meeting·KpiSnapshot·Content·Microsite·MasterData·User membership·Role 매핑·AuditLog)에 `tenant_id`(FK → Tenant) 추가. 모든 조회/쓰기는 `WHERE tenant_id = :ctx` 강제(§8-2).
- **참조 데이터 구분**: 전역 공통코드(국가·통화·언어)는 `tenant_id` 없음(전역), 전시관마다 다를 수 있는 코드(공종 14분류·유틸리티 요금코드·부스유형)는 `tenant_id` 부여(전역 기본값 + 테넌트 오버라이드).
- **역할 계층**: `Role`에 플랫폼 슈퍼관리자(크로스-테넌트) vs 테넌트 관리자(단일 테넌트) 계층(§1A-4). User–Tenant 멤버십(다중 소속 허용, 컨텍스트는 단일 고정 §1A-3).
- **마이그레이션**: 기존 전 행 `tenant_id=1(KINTEX)` 백필(§1A-5, DDL은 db-engineer/DA 후속).

---

## 8. 아키텍처 개요

전제 스택 (확정, GUARDiA 표준 프레임워크 정렬): **React 18/19(Vite·TypeScript) + Spring Boot 3.x(Java 17) + MyBatis + PostgreSQL(PostGIS) + Redis 작업 큐 + 나노바나나 Python 워커 사이드카**.

```mermaid
graph LR
    subgraph Frontend
        WEB[React 18/19 웹 (Vite·TS)<br/>반응형: 데스크톱=설계·에디터, 모바일=조회·승인·현장]
        CANVAS[플로어플랜 캔버스<br/>SVG/WebGL 편집기]
    end
    subgraph Backend
        API[Spring Boot 3.x (Java 17)<br/>REST + WebSocket/STOMP 진행 알림]
        RULE[룰 엔진<br/>규정 검증·요율 계산 (서비스 계층)]
        LAYOUT[배치·배선 엔진<br/>제약 솔버 + PostGIS 공간 SQL]
        MYB[MyBatis<br/>매퍼·공간 SQL 바인딩]
        QUEUE[비동기 작업 큐 Redis<br/>RenderJob·서류 생성·알림]
        NB[나노바나나 Python 워커 사이드카<br/>tools/nanobanana · google-genai SDK]
    end
    subgraph Data
        PG[(PostgreSQL + PostGIS<br/>공간 데이터·업무 데이터)]
        OBJ[(오브젝트 스토리지<br/>도면·생성 이미지·서식)]
    end
    WEB --> API
    CANVAS --> API
    API --> RULE
    API --> LAYOUT
    API --> MYB --> PG
    LAYOUT --> MYB
    API --> QUEUE --> NB --> OBJ
    NB -.완료 푸시(WebSocket).-> API
    NB -.Gemini API.-> EXT[Google Gemini]
```

- **백엔드 = Spring Boot 3.x(Java 17) + MyBatis**: REST API와 실시간 진행 알림은 Spring Web + WebSocket(STOMP)로 처리. 룰 엔진(규정·요율)과 배치/배선 엔진은 Spring 서비스 계층으로 두고, 공간 연산은 MyBatis 매퍼가 바인딩하는 **PostgreSQL PostGIS 공간 SQL**(부스 폴리곤·트렌치 포인트·배선 LineString)로 수행.
- **공간 데이터 일원화**: 부스 폴리곤·트렌치 포인트·배선 경로를 PostGIS 지오메트리로 저장 — 최단 배선(라우팅), 통로 폭 검증(버퍼 연산), 면적 정산이 모두 SQL 수준에서 수행. MyBatis가 `ST_*` 함수 호출을 매퍼 XML로 관리.
- **프론트 = React 18/19(Vite·TypeScript)**: 반응형(데스크톱=설계/에디터, 모바일=조회·승인·현장). 플로어플랜 캔버스는 SVG/WebGL. 현장 시나리오(홀매니저 검수 체크, 참가업체 승인, 반입 QR)는 모바일 뷰 최적화. UI 상세는 후속 `docs/design.md`.
- **이미지 생성은 전면 비동기 — Python 워커 사이드카**: Spring 백엔드가 RenderJob을 Redis 작업 큐에 넣으면 **별도 Python 워커(`tools/nanobanana`)** 가 소비해 Gemini(google-genai Python SDK)로 이미지를 생성하고, 결과를 오브젝트 스토리지에 적재한 뒤 WebSocket으로 완료를 푸시한다. 서류/알림 생성도 동일 큐를 경유. 재시도·비용 상한·스키마 해시 캐시는 워커 레벨에서 관리.
  - **Python 워커 유지 근거**: 나노바나나 호출 스택(client.py)은 방금 ReRoomAI 검증 패턴으로 확정되었고 **google-genai는 Python SDK**를 사용한다(§6-4). 이를 Java로 재구현하면 검증된 방어 로직·프롬프트 조립을 이식·재검증하는 비용이 발생하므로, image-to-image 파이프라인은 **Python 워커 사이드카로 유지**하고 Spring 백엔드는 큐·오케스트레이션·상태 관리만 담당한다(Java 재구현 대신 얇은 큐 계약으로 결합).
- **룰 엔진 분리**: 규정(높이·방염·하중)과 요율을 코드가 아닌 버전 관리되는 룰셋 데이터로 유지 — 킨텍스 규정 개정(연 단위 요율 변경 등) 대응. Spring 서비스 계층이 룰셋을 로드·평가.
- 인증: 행사 단위 RBAC(2장 권한 모델) + JWT. 오브젝트 스토리지에 도면·생성 이미지·서식 적재. 도면·설계 데이터는 행사 종료 후 보존 정책 별도 정의(참가업체 자산).

### 8-1. v2.0 아키텍처 보강 — 역할별 분리 프론트 + 공유 백엔드 + 공개사이트/백오피스

확정 스택(React + Spring Boot 3.x(Java 17) + MyBatis + PostgreSQL/PostGIS + Redis + 나노바나나 Python 워커)은 **불변**. 그 위에 v2.0의 다중 포털·공개사이트·백오피스를 얹는다.

```mermaid
graph TB
    subgraph 프론트["역할별 분리 프론트 (React·Vite·TS, 공유 디자인시스템)"]
        FO[organizer. 주최자 콘솔]
        FE[exhibitor. 참가업체 포털]
        FC[contractor. 업체 포털·옥션]
        FM[ops. 운영 대시보드]
        FA[admin. 관리자 백오피스]
        FP[www/expo. 공개 홍보 사이트<br/>SEO·SSR·다국어]
        FV[관람객 모바일 앱<br/>배지·wayfinding·매칭]
    end
    subgraph 게이트["SSO · 역할 RBAC · API Gateway"]
        SSO[JWT SSO + 역할·행사 RBAC]
    end
    subgraph 백엔드["공유 Spring Boot 3.x 백엔드"]
        API[REST + WebSocket/STOMP]
        RULE[룰 엔진·요율/규정]
        LAYOUT[배치·배선 엔진 PostGIS]
        AUC[옥션 엔진 M15<br/>라운드·순위·낙찰스코어]
        BI[BI 집계 M16]
        CMS[CMS·다국어 M17]
        QUEUE[Redis 큐]
        NB[나노바나나 Python 워커]
    end
    subgraph 데이터["PostgreSQL+PostGIS · 오브젝트 스토리지"]
        PG[(업무·공간 데이터)]
        OBJ[(도면·이미지·서식·콘텐츠)]
    end
    FO & FE & FC & FM & FA & FP & FV --> SSO --> API
    API --> RULE & LAYOUT & AUC & BI & CMS
    API --> QUEUE --> NB --> OBJ
    API --> PG
    FP -. 캐시/CDN .-> OBJ
```

- **역할별 프론트 분리**: organizer·exhibitor·contractor·ops·admin 5개 인증 앱 + public(공개)·visitor(관람객 모바일). 각기 별도 번들·도메인/서브패스로 배포해 **최소권한·공격면 축소**, 단 **공유 디자인 시스템(design.md)·공유 컴포넌트·공유 API 계약**을 상속(중복 구현 금지). 데스크톱=설계/에디터/대시보드, 모바일=현장/조회/승인(§2-1 매트릭스).
- **SSO + 역할 RBAC + 2FA/OTP (§5B UIWS 표준)**: 단일 JWT SSO 위에 플랫폼 레벨(관리자)과 행사 레벨(주최자/참가/업체/홀매니저) 권한을 이중으로 평가. **인증 스택은 UIWS 표준을 이식** — JWT + TOTP(RFC6238) 2차 인증 + 로그인 실패 잠금 + admin 비번 env(`ADMIN_PASSWORD_ENC` AES-256-GCM + 별도 키파일) 주입(§5B-3). M18(=§5B-1 시스템관리)이 역할·권한·공통코드·메뉴·감사로그 마스터를 공급. 공통 업무 기능(worklog·schedule·message·notice·search·meeting·report·notification 등, §5B-2)은 전 포털 공유 레이어.
- **공개 홍보 사이트·CMS(M12·M17) — SEO·다국어**: 불특정 다수 대상이므로 **SSR/정적 생성 + 메타·사이트맵·구조화 데이터(SEO)**, **다국어(한/영/중/일) i18n·hreflang**, CDN 캐시. 인증 앱과 별도 렌더 경로(공개 성능·검색 노출 목적). 콘텐츠는 M17 헤드리스 CMS가 공급, 참가업체 마이크로사이트도 동일 파이프라인.
- **관리자 백오피스(M18)**: 웹 전용 별도 앱. 마스터데이터·룰셋(요율·규정)은 **버전 관리 데이터**로 룰 엔진에 로드 — 킨텍스 연 단위 개정 무중단 반영. 전 승인·낙찰·설계 변경은 감사로그.
- **옥션 엔진(M15)**: Spring 서비스 계층 + Redis(실시간 순위·라운드 마감 타이머) + WebSocket(순위 푸시). 견적서 PDF 생성은 서류 생성 큐(Redis) 재사용, 나노바나나와 동일 비동기 패턴.
- **BI(M16)**: 운영 DB 부하 회피를 위해 집계는 배치/스냅샷(KpiSnapshot) 또는 읽기 전용 복제 권장(구현 트랙 결정). 예측·이상탐지는 §10 R12(외부 API 게이트) 준수 — 온프레미스/승인 모델 범위.

### 8-2. v3.0 멀티테넌트 격리 전략 (§1A 구현 아키텍처)

확정 스택(§8·§8-1)은 **불변**. 그 위에 테넌트 격리 레이어를 얹는다.

- **격리 전략 = 공유 스키마 + `tenant_id` 컬럼(단일 DB 유지)**: 현행 단일 DB `kintex_db`를 **유지**하고, 전 도메인 테이블에 `tenant_id` 컬럼을 두어 논리 격리한다. **테넌트별 DB 분리(DB-per-tenant)·스키마 분리는 채택하지 않는다** — 전시관 수(수 개~수십 개) 대비 운영·마이그레이션·배포 비용이 과하고, 크로스-테넌트 BI(§1A-2)·공유 나노바나나 워커·단일 배포 파이프라인과 상충. 공유 스키마 + tenant_id가 GUARDiA 표준(단일 DB·Hikari max 3) 및 SaaS 정석에 정합.

  | 전략 | 채택 | 사유 |
  |---|---|---|
  | 공유 스키마 + `tenant_id` 컬럼 | **채택** | 단일 `kintex_db` 유지, 운영·배포 단순, 크로스-테넌트 집계 용이, 온보딩 저비용 |
  | 스키마-per-tenant | 미채택 | 마이그레이션 N배·커넥션 풀 부담, 이득 대비 과함 |
  | DB-per-tenant | 미채택 | 인프라·배포·백업 N배, 소수 전시관에 과대 |

- **강제 격리 계층 (fail-closed 다층 방어)**:
  1. **컨텍스트 해소 필터**: 게이트웨이/서블릿 필터가 서브도메인·JWT 클레임에서 `tenant_id`를 해소해 요청 컨텍스트에 주입(§1A-3). 미해소·불일치 요청은 **거부**.
  2. **서비스 계층 가드**: 컨텍스트 `tenant_id`를 신뢰 원천으로, 클라이언트가 보낸 tenant 파라미터는 **무시/검증**(위조 차단).
  3. **MyBatis 매퍼 강제 바인딩**: 전 매퍼 SQL에 `AND tenant_id = #{ctxTenantId}` 조건을 **공통 인터셉터/베이스 매퍼**로 주입(개별 쿼리 누락 방지). 쓰기 시 `tenant_id`를 컨텍스트에서 자동 세팅(클라이언트 입력 금지).
  4. **PostGIS 공간 쿼리도 동일**: 부스 폴리곤·배선 라우팅·면적 정산 등 `ST_*` 쿼리도 `tenant_id` 조건 하에서만 수행(전시관 간 공간 데이터 혼입 차단).
- **성능(테넌트 인덱스)**: 격리 쿼리가 항상 `tenant_id`를 선행 조건으로 가지므로 **`(tenant_id, …)` 선두 복합 인덱스**를 표준화(예: `(tenant_id, event_id)`, `(tenant_id, hall_id)`, PostGIS는 `tenant_id` + GiST 부분 인덱스). BI 데이터마트(§M16 Fact/Dim)도 `DimTenant` 추가·`tenant_id` 파티션 키 고려(DA 후속).
- **보안(교차 테넌트 차단)**: 전 계층 tenant 강제 + 감사로그(§5B-1)에 `tenant_id` 기록. 크로스-테넌트 접근은 플랫폼 슈퍼관리자 전용 API로만(명시적 권한 게이트·감사). 나노바나나 오브젝트 스토리지 경로·RenderJob 쿼터(§6-5)도 `tenant_id` 프리픽스로 격리(전시관별 이미지·쿼터 분리).
- **온보딩(새 전시관 추가 절차)**: ① 플랫폼 슈퍼관리자가 테넌트 마스터 생성(tenant_code·subdomain·branding·active=false) → ② 서브도메인·DNS·(선택)브랜딩 테마 등록 → ③ 해당 전시관 마스터데이터 입력(홀·요율·규정 룰셋·부스 표준·등록업체 — 근거 없는 추정 금지, §1A-5) → ④ 테넌트 관리자·홀매니저 계정 발급(OTP 등록) → ⑤ 스모크(격리 검증: 타 테넌트 데이터 불가시 확인) → ⑥ `active=true`. **코드 배포 없이 데이터 온보딩만으로 신규 전시관 오픈**(공유 스키마 이점).
- **후속 반영 필요**: 필터·인터셉터·인덱스·마이그레이션 DDL은 **db-engineer/DA/backend 후속 트랙**(planner 설계만). `docs/architecture/*.md`·`docs/design.md`·src 미반영.

---

## 8A. AI 사용성 & 토큰 최소화 아키텍처 (v3.4, 소유자 지시 2026-07-12)

> **소유자 지시**: "기획자는 AI 기능을 **쉽게 사용**할 수 있도록 기획하고, **토큰을 최소한으로 사용**하는 방식을 채용하라." 본 절은 전 모듈에 걸친 **AI 사용성 표준(§8A-1)** 과 **토큰 최소화 설계 원칙(§8A-2)** 을 명문화한다. **재발명이 아니라 이미 진행 중인 패턴의 표준화**다 — visitor 관람객 AI 도우미가 이미 **DB 근거로 답하고**, 공통 AI 계층이 **`AiTextRouter`로 Claude→Ollama(소형) 폴백**하며, 크롤 적재 DB(행사 데이터 등)를 근거로 삼는 구조가 존재한다. 본 절은 이를 **원칙·계약·측정지표로 고정**해 전 모듈(M10 관람객 AI 도우미·M16 BI·§5B 공통 AI 보조)이 동일 규약을 따르게 한다.
> **보존·경계**: §5B 공통 레이어·§8 확정 스택·§8-2 테넌트 격리·§6 나노바나나(이미지 생성은 별개 파이프라인·본 절의 "토큰"은 **텍스트 LLM** 대상)를 삭제·재작성하지 않는다. AI 게이트(외부 API 금지, `api.anthropic.com` 예외 — §10)·온프레미스 소형모델 RAM 제약([[project_ollama_ram_constraint]])과 정합한다.

### 8A-1. AI 사용성 표준 — "어디서나 한 번에 물어본다"

전 화면에 **동일한 AI 진입 규약**을 심어, 사용자가 메뉴를 뒤지지 않고 자연어로 즉시 도움을 받게 한다. 관람객(visitor 메인 AI 도우미)과 업무 사용자(업무 화면 AI 보조)가 **같은 컴포넌트·같은 로직**을 공유한다.

| # | 사용성 요소 | 내용 | 적용 범위 |
|---|---|---|---|
| U1 | **인라인 AI 진입점** | 전 화면 공통 위치(헤더/우하단)에 "AI에게 물어보기" 버튼 + 자연어 질문창(공통 컴포넌트 `AiAssistant`). 화면 컨텍스트(현재 행사·부스·화면 ID)를 자동 첨부 | 웹·모바일 전 화면 |
| U2 | **예시 질문 칩(prompt chips)** | 자주 묻는 질문을 원클릭 칩으로 노출(화면·역할별 큐레이션). 예: 관람객 "오늘 열리는 전시는?"·"주차 어디?"·"부스 어떻게 찾아?" / 참가업체 "내 유틸리티 신청 마감일?"·"이 도면 규정 위반 있나?" | 화면·역할별 |
| U3 | **원탭 AI 액션** | 목록/상세에서 버튼 한 번으로 요약·추천·초안 생성. 예: 서류 요약, 옥션 응찰 비교 요약, EDM 카피 초안(M12), 회의록 액션아이템 추출(§5B meeting) | 목록·상세 화면 |
| U4 | **다음 명령 제시(proactive)** | 결과 하단에 후속 액션·후속 질문 칩 제시("이 배치안으로 시각화 생성?"·"이 업체에 옥션 초대?"). 프로액티브 제안은 **규칙 기반 우선**(LLM 미사용, §8A-2 P1) | 결과 카드 |
| U5 | **구조화 카드 + 근거 인용** | 답변은 자유 서술 대신 **구조화 카드**(핵심값·표·링크) + **근거 인용**(출처 레코드/문서 링크·"근거: 행사마스터 #123"). 근거 없으면 **"모름" 폴백**(환각 차단, GUARDiA AI-trust 정합) | 전 답변 |
| U6 | **대화 히스토리·후속 질문** | 세션 내 멀티턴 히스토리 + 후속 질문 칩. 히스토리는 **요약 압축**해 컨텍스트 재주입 최소화(§8A-2 P4) | 도우미 패널 |
| U7 | **접근성·다국어·모바일·음성** | 동일 로직을 웹·모바일 공유(§2-3 채널 규칙 정합), 다국어(한/영/중/일) UI, 스크린리더 대응, **음성 입력 옵션**(온디바이스 STT 고려·서버 부하·토큰 무관) | 전 채널 |

- **관람객 vs 업무 사용자 공통화**: 두 페르소나가 **단일 `AiAssistant` 컴포넌트 + 단일 `/ai/ask` 계약**을 공유하고, 노출 위치·예시 칩·허용 액션만 역할/트랙(§2-3)으로 스코프한다 → 구현 중복 회피·UX 일관성.
- **신뢰성 우선**: 사용성(쉽게)은 신뢰성(근거·모름 폴백)과 함께 간다 — "빠르고 그럴듯한 환각"보다 "근거 있는 절제된 답"을 표준으로 한다(U5).

### 8A-2. 토큰 최소화 설계 원칙 (핵심 설계 원칙 — 비용 효율)

> **대원칙: "LLM은 최후에 최소로."** 답할 수 있는 것은 DB/규칙/집계로 먼저 답하고, 자연어 종합이 실제 필요한 부분에만, 가장 작은 모델로, 가장 짧은 컨텍스트로 호출한다. 아래 6원칙은 **`/ai/ask` 오케스트레이션의 결정 순서**이기도 하다.

| 원칙 | 내용 | 계약/구현 지점 |
|---|---|---|
| **P1. 결정론 우선 라우팅** | 의도 분류(키워드·규칙·화면 컨텍스트)로 **LLM 없이 답할 수 있으면 LLM을 호출하지 않는다.** 연/월 일정·교통·주차·마감일·요금·부스 위치·통계 수치 등 **사실 조회형은 DB/뷰가 직접 응답**(카드 렌더). LLM은 **요약·추천·자연어 종합·다중 근거 통합**이 실제 필요할 때만 | `IntentRouter`(규칙 테이블) → `DirectAnswer`(DB) vs `LlmAnswer` 분기 |
| **P2. 소형모델 우선 티어링** | 기본 온프레미스 **소형(Ollama `qwen3:1.7b`/`llama3.2:1b`)** 로 처리 → 난도·실패 시에만 **Claude로 에스컬레이션**(`AiTextRouter` 폴백 체인 역방향 활용: 저비용 우선 → 고비용 승급). 난도 판정 = 컨텍스트 길이·요구 추론 깊이·소형모델 신뢰도 | `AiTextRouter`(기존)·`AiConfig` 티어 정책. RAM 제약([[project_ollama_ram_constraint]]) 정합 |
| **P3. RAG 그라운딩으로 프롬프트 축소** | 크롤 적재/도메인 DB에서 **필요 레코드만 발췌**(top_k 제한·컬럼 프로젝션)해 **짧은 컨텍스트**로 전달. **전체 문서·전체 테이블 주입 금지.** 근거 스니펫만 넣어 프롬프트 길이·환각 동시 억제 | RAG 검색 `top_k`(기본 3~5)·발췌 요약·근거 스니펫 |
| **P4. 캐싱** | ① **응답 캐시**: 동일 의도+동일 파라미터 질의 결과 캐시(TTL, 예 일정·요금 24h) ② **시스템 프롬프트 캐시**(프롬프트 프리픽스 재사용) ③ **동일 기간/스코프 요약 재사용**(M16 BI·기간 요약). 히스토리는 요약본만 재주입 | Redis 응답 캐시(키=의도+파라미터+tenant+locale), 프롬프트캐시 |
| **P5. 출력 상한·구조화** | `max_tokens` 상한 강제, **구조화(JSON/카드) 출력**으로 장문 방지. **스트리밍은 UX 체감용일 뿐 토큰량은 불변**임을 명시(비용 절감 아님) | `max_tokens`·`response_format`(structured), 스트리밍=표시 옵션 |
| **P6. 집계는 SQL로** | 통계·집계·랭킹·추이는 **LLM이 아니라 DB 집계(뷰/데이터마트)** 로 산출. LLM은 그 수치에 대한 **자연어 설명·해석만** 담당(수치 계산에 LLM 금지 — 환각·비용 이중 방지) | M16 BI 데이터마트(§M16-1)·SQL 집계 → LLM은 설명만 |

**오케스트레이션 흐름(요약)**: `사용자 질문 → IntentRouter(P1) → [사실조회면] DB/뷰 카드 응답(LLM 0토큰) / [종합필요면] RAG 발췌(P3) → 캐시 조회(P4) → 소형모델(P2) → (난도↑) Claude 승급 → max_tokens·구조화 출력(P5) → 근거 인용 카드(U5)`. 통계는 항상 SQL 선처리(P6).

### 8A-3. 측정지표 및 목표 (비용 가시성)

> 토큰 최소화는 **측정되어야 관리된다.** 아래 지표를 `ai_usage_log`(질의별 토큰·모델·경로·캐시히트·지연)로 적재하고 M16 BI/관리자 대시보드에 노출한다. 목표치는 초기 가설이며 파일럿 후 보정(근거 없는 확정 금지).

| 지표 | 정의 | 목표(초기 가설) |
|---|---|---|
| **LLM 우회율(deflection)** | 전 질의 중 P1 결정론/DB로 **LLM 없이** 처리된 비율 | **≥ 40%** (일정·요금·위치·통계형 다수) |
| **소형모델 처리율** | LLM 호출 중 소형(Ollama)로 완결(Claude 미승급) 비율 | **≥ 70%** |
| **캐시 적중률** | 캐시(P4)로 응답한 비율 | **≥ 30%**(반복 질의 화면) |
| **호출당 평균 입력 토큰** | LLM 호출 1건당 평균 프롬프트 토큰(RAG 발췌·히스토리 요약 후) | **≤ 1,500** |
| **호출당 평균 출력 토큰** | `max_tokens` 상한 하 평균 출력 | **≤ 400** |
| **근거 인용률** | LLM 답변 중 근거 링크·"모름" 폴백을 포함한 비율(U5) | **≥ 95%** |

- **비용 귀속**: `ai_usage_log`는 `tenant_id`(§8-2)·모듈·역할을 태깅해 **테넌트/모듈별 비용 배분**을 가능케 한다(플랫폼 슈퍼관리자 크로스-테넌트 집계).

### 8A-4. design/개발 에이전트 계약 포인트

> planner는 원칙·계약을 확정한다. **화면·컴포넌트 상세는 designer(Stitch 경유), 라우팅·캐시·모델 티어 구현은 backend/ai-dev 후속.** design.md·src 미수정.

1. **단일 AI 계약** `POST /ai/ask` — 입력: `{ question, contextRef(화면·행사·부스), locale, history(요약) }`, 출력: `{ answerCard(구조화), citations[], followups[], route(direct|small|escalated), usage(tokens·cached) }`. 전 화면·전 채널(웹·모바일)이 이 단일 계약을 사용(U1·U7).
2. **라우팅 계약**: `IntentRouter`는 **규칙 테이블(공통코드)** 로 관리(코드 배포 없이 의도·직답 매핑 추가). 사실조회 의도는 **DB 리졸버 매핑**(일정·요금·위치·통계). 미매핑만 LLM 경로.
3. **캐시 계약**: 캐시 키 = `hash(intent + params + tenant_id + locale)`, TTL은 의도별 정책(공통코드). 무효화 = 원천 데이터 변경 이벤트(§5B notification 버스 재사용).
4. **모델 티어 계약**: `AiConfig`(§5B, 기존 AiTextRouter/AiConfig 패턴)에 **티어 정책**(기본 소형·승급 임계·모델명) 설정형 노출 — 하드코딩 금지, 관리자 조정 가능. 실패 시 폴백(소형↔Claude 상호).
5. **UI 컴포넌트 계약**: 공통 `AiAssistant`(진입점·질문창·칩·카드·히스토리) + `AiActionButton`(원탭 액션). 예시 칩·허용 액션은 **화면/역할 메타데이터**로 주입(designer가 화면별 큐레이션, Stitch 프롬프트에 반영).
6. **모듈 링크**: M10(§5A 관람객 AI 도우미)·M16(§M16-1 BI 자연어 설명)·§5B 공통 AI 보조가 본 절 원칙을 **동일 계약으로** 준수. 나노바나나(§6) 이미지 생성은 본 절 토큰 원칙 대상 아님(별도 RenderJob 쿼터·캐시).

---

## 9. 로드맵

### Phase 1 — 설계·시각화 코어 (MVP, ~4개월)

| 항목 | 내용 |
|---|---|
| 범위 | **§5B 공통/시스템관리 레이어 이식 선행(UIWS: 인증 JWT+OTP·시스템관리·핵심 공통모듈 — 전 모듈 기반)**, M2(단일 홀, 근사 도면), M3(조립부스 전체 + 독립부스 초안 생성), M4(전기·네트워크 배선 + 자동 견적, 신청서·위치표시도 파일 생성까지), M5(S1·S2·S6·S7 샷) |
| 산출물 | 웹 앱(주최자·참가업체·장치업체), 나노바나나 파이프라인 v1, 룰셋 v1(장치 규정·요금표), 근사 홀 도면 1종(홀7 권장 — 규격 공개 충실) |
| 검증 | 파일럿 1개 행사(또는 과거 행사 데이터 재현)로 배치→설계→배선→시각화 전체 여정 시연 |
| 착수 조건 | Gemini API 키, 홀 참조 사진 촬영(샷 프리셋별 배경), 트렌치 좌표(미확보 시 공개 스펙 기반 가정 그리드로 진행하되 '가정' 라벨) |

### Phase 2 — 워크플로·운영 통합 (~4개월)

| 항목 | 내용 |
|---|---|
| 범위 | M1(가용성+자동 견적), M6(마일스톤·서식 자동 생성·AI 서류 검수), M7(업체 매칭·RFQ), M9(PG 결제·납부 스케줄), 홀매니저 대시보드, 전 홀(10개) 도면 확장 |
| 산출물 | kxwp 제출 릴레이(파일 생성+안내), 등록업체 DB 수집 파이프라인, 정산 리포트 |
| 전제 | 킨텍스 협의: CAD 도면·트렌치 실측, kxwp 연동 논의 개시, 요금 정합성(인터넷 150,000 vs 80,000) 확인 |

### Phase 3 — 현장·확장 (~4개월+)

| 항목 | 내용 |
|---|---|
| 범위 | M8(반입/반출 슬롯·QR 통행증), kxwp 정식 API 연동(협의 성사 시), 정밀 조도 시뮬레이션, 다국어(영·중·일) 규정 챗봇, 관람객 플로어플랜 공개, 회의실·리깅 구조 사전 체크 확장 |
| 산출물 | 현장 모바일 운영 도구, 제3전시장(2028) 대비 홀 마스터 확장 구조 |

각 Phase 종료 시 reviewer 에이전트 교차 검증(기획-디자인-구현 정합성) — CLAUDE.md 워크플로 준수.

---

## 10. 리스크 및 제약

| # | 리스크/제약 | 영향 | 완화 |
|---|---|---|---|
| R1 | **AI 생성 이미지가 실제 시공과 다름** — 재질·색·디테일 오차는 구조적으로 불가피. 참가업체가 이미지를 계약 근거로 오인 시 분쟁 | 높음 | 전 이미지 워터마크·고지(6-5), 계약·심사 서류에서 자동 배제, "시공 기준은 도면" 동의 절차 |
| R2 | **도면 심사 책임 문제** — 자동 검증 통과가 킨텍스/소방 승인을 의미하지 않음. 시스템 통과 후 현장 반려 시 책임 소재 | 높음 | 시스템 역할을 '사전 필터'로 법적 정의, 최종 승인 주체(킨텍스·구조기술사) 명시, 검증 리포트에 면책 문구·룰셋 버전 기록 |
| R3 | **kxwp 연동 불확실성** — 폐쇄형 시스템, API 미공개. 연동 실패 시 이중 입력 부담 | 중간 | Phase 1~2는 '제출 파일 자동 생성+수동 업로드' 릴레이로 독립 가치 확보, 병행하여 킨텍스 IT 협의 |
| R4 | **트렌치·CAD 실측 데이터 미확보** — 배선 자동화 정확도 좌우 | 높음 | 공개 규격 기반 가정 그리드로 개발 진행 + '가정' 라벨, 킨텍스 데이터 제공을 Phase 2 전제조건으로 계약화 |
| R5 | 한글 간판 텍스트 렌더링 불안정(생성 모델 한계) | 중간 | 오탈자 자동 검수 + 실패 시 간판 영역 후처리 합성(6-4) |
| R6 | 이미지 생성 비용·지연 — 부스 수백 개(홀당 200~600부스) 동시 생성 시 비용 급증 | 중간 | 자동 생성은 S1·S7 한정, 온디맨드+캐시, 행사별 생성 쿼터 |
| R7 | 배치 엔진 결과가 주최자 영업 관행(프리미엄 부스 위치 정책 등)과 충돌 | 중간 | 자동안은 '초안', 수동 편집 캔버스 우선. 제약조건을 주최자가 조정 가능하게 |
| R8 | 요금·규정 데이터의 공식성 — 웹 공개값(예: 인터넷 150,000원 vs KT 80,000원 병존)이 실계약가와 다를 수 있음 | 중간 | 견적에 "공시가 기준, 최종가는 킨텍스 확정" 고지, 요율 마스터를 킨텍스 확인본으로 교체하는 절차 마련 |
| R9 | 이해관계 충돌 — 장치업체는 설계 자동화를 일감 위협으로 인식 가능 | 중간 | 포지셔닝을 '초안+검증 도구'로: 반려 감소·컨펌 단축이라는 업체 이득 강조, M7로 수주 채널 제공 |
| R10 | 개인정보·영업비밀 — 참가업체 부스 설계는 경쟁사에 민감 | 중간 | 행사 단위 격리, 부스 데이터 접근은 소유 참가업체+주최자+홀매니저로 한정 |
| R11 | ~~ReRoomAI 파이프라인 분석 미완 — 구조 보존 제어 상세는 소스 분석 후 확정~~ **[해소 v1.1]** | 낮음 | **해소(2026-07-11)**: `reroomai-source.md` 분석 완료 → 6장 모델·SDK·프롬프트 아키텍처·방어 로직 확정(6-4/6-5). BACKLOG B-11 done |
| R12 | **나노바나나(Gemini) 외부 API 미승인** — GUARDiA 외부 API 금지 원칙상 현재 승인 예외는 `api.anthropic.com`뿐이며, Gemini(`generativelanguage.googleapis.com`)는 미승인. kintex는 GUARDiA ITSM(관공서 관제)과 별개 도메인의 독립 저장소(`zio/kintex`)이나, 승인 없이 M5 구현 착수 시 원칙 위반 | 높음 | **M5 파이프라인 구현 착수 전 소유자 승인 확정 선행(게이트)**. 승인 시 `GEMINI_API_KEY`는 서버 env로만 로드(코드·DB·커밋·로그·응답 기록 금지, ReRoomAI (E) 방어 패턴 준수). **미승인 시 완화책**: 온프레미스 이미지 생성(SDXL 등) 폴백 어댑터 검토 — 단 image-to-image 구조보존 품질 재평가 필요 |

---

## 11. 변경 이력

| 버전 | 일자 | 작성자 | 내용 |
|---|---|---|---|
| **v3.4** | 2026-07-12 | planner | **AI 사용성 & 토큰 최소화 아키텍처 신설(소유자 지시 2026-07-12).** 기존 스코프·화면·라우트 전부 보존, AI 원칙·계약·지표만 순증. ①헤더 v3.4 라인 + 버전 상향 ②**§8A 신설**(§8-2 뒤·§9 앞) — (8A-1) AI 사용성 표준 U1~U7(인라인 진입점 `AiAssistant`·예시 질문 칩·원탭 AI 액션·다음 명령 제시(규칙 우선)·구조화 카드+근거 인용·"모름" 폴백·대화 히스토리 요약·접근성/다국어/모바일/음성, 관람객·업무 사용자 단일 컴포넌트 공유) (8A-2) 토큰 최소화 6원칙 P1~P6(결정론 우선 라우팅으로 사실조회 LLM 미호출·소형모델 우선 티어링 AiTextRouter 저비용→승급·RAG 발췌 top_k 제한·캐싱 응답/프롬프트/기간요약·max_tokens 상한+구조화 출력(스트리밍=UX용 토큰 불변)·집계는 SQL LLM은 설명만) + 오케스트레이션 흐름 (8A-3) 측정지표·목표(LLM 우회율≥40%·소형모델 처리율≥70%·캐시 적중률≥30%·평균 입력≤1500/출력≤400·근거 인용률≥95%, `ai_usage_log` 적재·tenant/모듈 비용 귀속) (8A-4) design/개발 계약 6종(단일 `/ai/ask`·규칙테이블 IntentRouter·캐시 키·AiConfig 티어·공통 `AiAssistant`/`AiActionButton`·모듈 링크) ③**M10·M16-1·§5B-2에 §8A 정합 링크** 순증(관람객 AI 도우미 DB 직답·BI 집계 SQL/LLM 설명만·공통 AI 보조 중앙 `/ai/ask` 경유). 이미 진행 중(visitor-assistant DB 근거·AiTextRouter 폴백)과 정합·표준화(재발명 아님). 외부 API 게이트·RAM 제약 정합. **src·design.md 미수정** — designer(AiAssistant/칩 Stitch)·backend/ai-dev(라우팅·캐시·티어) 후속 |
| v1.0 | 2026-07-11 | planner | 최초 작성 — kintex-website.md 분석 기반 전체 기획. ReRoomAI 소스 분석(reroomai-source.md)은 추가 시 6장 갱신 예정 |
| v1.1 | 2026-07-11 | planner | ReRoomAI 소스 분석 반영. ①§6 나노바나나 파이프라인 제어 파라미터 확정 — 모델 `gemini-3.1-flash-image-preview`(나노바나나 2)·`@google/genai` SDK·image-to-image(inlineData+text parts) 호출 스택, 구조화 사전(BOOTH_TYPES·BOOTH_STYLES·FIXTURE_LAYERS) + "보존/교체 명시 분리" 부스 프롬프트 템플릿(§6-4), Canvas 1024px 전처리·RenderJob 방어 로직(크기 가드·SAFETY·에러 분기·성공 시에만 쿼터 차감)·단계별 로딩 UX 신설(§6-5). ②S6 배선 오버레이 백엔드 래스터 합성 우선 명확화(§6-3). ③§7 마스터 데이터 순증 반영(기본부스 표준 품목·프리미엄 6×3×4m 2kW·조명 반입 금지·이격 30/60cm·옥외 2,849㎡·홀6 93×60×10m·제3전시장 홀11~18). ④§10 R11 해소, R12(Gemini 외부 API 미승인·소유자 승인 게이트) 추가. BACKLOG B-11 done, B-09 정리 |
| v1.2 | 2026-07-11 | planner | **기술 스택 확정 — React + Spring Boot 3.x(Java 17) + MyBatis + PostgreSQL(PostGIS), 나노바나나 Python 워커 사이드카. GUARDiA 표준 프레임워크 정렬(사용자 지정).** §8 아키텍처 전면 정합화: 백엔드 FastAPI→Spring Boot 3.x + MyBatis(REST + WebSocket/STOMP, 룰·배치/배선 엔진=서비스 계층 + PostGIS 공간 SQL), 프론트 Next.js→React 18/19(Vite·TS, SVG/WebGL 캔버스), 비동기 큐 Redis 유지 + 이미지 생성은 별도 **Python 워커 사이드카(`tools/nanobanana`, google-genai Python SDK)** 로 분리(Spring이 RenderJob 큐잉→Python 워커 소비·생성→오브젝트 스토리지 적재→WebSocket 완료 푸시, 서류·알림도 동일 큐). Python 워커 유지 근거 명시(ReRoomAI 검증 client.py·Python SDK — Java 재구현 회피). 인증(행사 단위 RBAC+JWT)·오브젝트 스토리지 유지. §8 mermaid 갱신. **기능 범위(M1~M9)·우선순위·나노바나나 파이프라인 로직 불변** — 스택 표기 정합화만 수행 |
| **v2.0** | 2026-07-11 | planner | **정체성 확장 — 킨텍스 자동전시시스템(Exhibition Automation Platform).** 글로벌 전시테크 크롤링(Eventleaf·VenueSight·Whova·ExpoPlatform·Eventbase·Pointr·Swapcard·Brella·Grip·RainFocus·ExhibitForce·FindRFP·Procore·4castplus) 근거로 확장. ①§1 비전 재정의(생애주기 폐루프, M15 옥션이 코어를 발주로 연결) ②§2 역할·포털 매트릭스 신설 — 6역할(주최자·참가·업체·홀매니저·관리자·관람객/대중) 웹/모바일 분리(organizer·exhibitor·contractor·ops·admin·public+visitor), 관리자·일반대중 페르소나 추가 ③§4 모듈맵 mermaid 확장(M10~M18) + 우선순위 총괄 ④§5A 신규 모듈 상세: **M15 공사/장치 옥션(P1·핵심, 역경매·견적서(Quotation)=응찰·실시간 순위·종합평가 낙찰·등록업체만 응찰·Auction 1─N Quotation ─ Award·PDF/버전, 입찰 플로우 시퀀스 다이어그램)**, M10 관람객 등록·배지·리드캡처(P1), M12 마케팅·EDM·공개 홍보 사이트(P1·SEO/다국어), M16 경영분석 BI(P2→**P1 승격**, design.md 반영은 designer 후속), M17 CMS(P1), M18 관리자 백오피스(P1), M11 비즈매칭·M13 wayfinding·M14 현장운영(P2) ⑤**M2·M3 3안 생성→선택/병합 UX 구체화**(1·2·3안 다양화, 구역/블록 병합, 병합 후 규정 재검증, 버전 기록) ⑥§7-3 엔티티 확장(Auction/Quotation/Award·Visitor/Badge/Lead·KPI/Content/User) ⑦§8-1 아키텍처 보강(역할별 분리 프론트+SSO/RBAC+공개사이트 SEO/다국어+백오피스+옥션 엔진) ⑧**§5B 공통/시스템관리 레이어(UIWS 표준 이식) 신설** — kintex 스택=UIWS(GUARDiA 표준 프레임워크) 동일 → 시스템관리(사용자·RBAC·공통코드·메뉴·감사로그·시스템설정)와 공통 업무기능(worklog·schedule·message·stats·notice·opinion·search·meeting·report·notification·audit) + 인증(JWT + **2차 인증 OTP TOTP RFC6238** + 로그인 실패 잠금 + admin 비번 env `ADMIN_PASSWORD_ENC` 주입)을 `workspace/uiws` 레퍼런스로 이식, 도메인 모듈은 그 위에 적재. **M18 관리자 시스템을 UIWS 시스템관리와 통합(중복 제거)**, BI/CMS/알림 경계 규칙 정의, Phase 1 선행 기반으로 로드맵 반영. ⑨**§5A M16-1 운영사(킨텍스·venue operator) 관점 수익성/ROI 소절 신설** — 참가업체 관점 ROI(리드 기반)와 명시 구분하고, 킨텍스 관점 7지표(홀·기간별 가동률/매출구성/행사별 P&L·마진/전시장별 ROI·RevPAD·㎡당 수익/참가사 리텐션·LTV/수요예측·수율·가격 최적화/경영진 KPI) + 데이터원(M1·M4·M9·M10·M15) + **BI 데이터마트(스타 스키마 Fact/Dim, DA 후속 트랙)** 정의. **기존 M2~M5 P0 코어·§6 나노바나나 로직·§8 확정 스택 보존.** design.md/타 문서는 미수정 — designer/planner/DA 후속 반영 필요로 표기 |
| **v3.0** | 2026-07-11 | planner | **멀티테넌시(다중 전시관 SaaS) 확장 — 킨텍스 전용 → 다중 전시관, KINTEX=기준 테넌트 #1.** 기존 스코프(부스 코어 M2~M5·도메인 M10~M18·§5B 공통 레이어·§6 나노바나나·§8 확정 스택) **전부 보존**, 격리 레이어만 순증. ①헤더 v3.0 정체성 확장(다중 전시관 SaaS) ②**§1A 멀티테넌시 절 신설** — 테넌트=전시관(Venue) 모델(tenant_code·명칭·branding·domain/subdomain·active·locale, 홀·요율·규정 룰셋·부스표준을 테넌트 소유로 재정의)·`tenant_id` 전파 및 격리(전 도메인 엔티티 격리 vs 전역/테넌트 참조 구분)·테넌트 컨텍스트 해소(서브도메인 kintex/coex.wise.ai.kr 우선 + 사용자 소속 보조, fail-closed 주입)·역할 계층(플랫폼 슈퍼관리자 vs 테넌트 관리자 2계층, 행사 RBAC는 테넌트 내부 스코프)·마이그레이션(기존 데이터 tenant_id=1 백필, DDL은 db-engineer/DA 후속) ③**§2 역할 갱신** — 페르소나 관리자 행을 테넌트 관리자로 재정의 + 플랫폼 슈퍼관리자 신규, 권한 모델을 "테넌트 격리 ⊃ 행사 RBAC" 3중 구조로, §2-1 포털 매트릭스 admin 2계층 분리 ④**§7 데이터모델 갱신** — §7-1 마스터데이터 테넌트 스코프 재정의(킨텍스 실측=테넌트#1 시드), §7-3 Tenant/Venue 엔티티·tenant_id 전파·참조 구분·역할 계층·백필 추가 ⑤**§8-2 멀티테넌트 격리 전략 신설** — 공유 스키마 + tenant_id 컬럼(단일 kintex_db 유지·DB/스키마 분리 미채택, 비교표)·fail-closed 다층 강제(필터→서비스가드→MyBatis 공통 인터셉터→PostGIS)·성능(`(tenant_id,…)` 선두 인덱스)·보안(교차 차단·감사·스토리지/쿼터 격리)·온보딩 6단(코드 배포 없이 데이터 온보딩) ⑥§1 Non-Goal에 온보딩 범위 한정 추가. **design.md·architecture/*.md·src 미수정** — db-engineer/DA/designer 후속 반영 필요로 표기. 근거 없는 코엑스 실측 추정 배제(온보딩 시 입력) |
| **v3.3** | 2026-07-12 | planner | **사용자 구분 → 랜딩(메인페이지)·메뉴/탭 그룹 결정 규칙 확정 — 웹+모바일 공통(소유자 확정 2026-07-12).** 기존 스코프(§2 6역할·§2-2 3-트랙·§2-1 포털·화면 SCR-*·딥 라우트) 전부 보존, 결정 로직·트랙 메인 목록만 순증(안 B). ①헤더 v3.3 규칙 요약 라인 + 버전 상향 ②**§2-3 신설** — (2-3-1) 역할→트랙 매핑 확정표(visitor/business/agency/내부-ops/내부-admin, 판정 신호=EventRole `myRole`+globalRole `role_code`, 웹 셸·모바일 앱 타깃) (2-3-2) primaryTrack 우선순위(내부-admin>내부-ops>business>agency>visitor)·activeTrack 반응형(기존 행사 전환 재사용)·멀티역할 연속성 (2-3-3) 랜딩 결정표 **(A)웹**(미인증=SCR-T0 공개 관람 랜딩, 인증=역할별 전용 메인, completeLogin 분기·현행 `/home` 고정 교체) **(B)모바일**(동일 로직·역할별 홈 탭 스위칭) (2-3-4) 웹 AppShell `GROUPS` 트랙별 노출 매트릭스(●/◐/✕, `visibleGroups` 트랙 필터 확장) (2-3-5) **모바일 하단 탭바 역할별 매트릭스** (2-3-6) **신규 트랙 메인 화면 목록·스펙 7종**(웹 SCR-T0 공개랜딩·T1 관람객·T2 비즈니스(역할변형)·T3 에이전시 + 모바일 관람객/비즈니스/에이전시 홈 — designer Stitch 의뢰 대상, 관리 메인=SCR-16 재사용) (2-3-7) 구현 권고·담당(웹=frontend·모바일=kintex-mobile, 지시서 `_workspace/plan_role_routing.md`). §2-2-3(C) "트랙-스코프 홈" 권고를 소유자 확정으로 정밀화(기존 홈 재사용→전용 신규 메인이 기존 위젯 조합). **src·design.md 미수정** — frontend/kintex-mobile/designer 후속 반영 필요 |
| **v3.2** | 2026-07-12 | planner | **제품 명칭 확정 + 대외 접점 3-트랙 재구성(소유자 확정 2026-07-12).** 기존 스코프(M1~M18·§1A 멀티테넌시·§2 6역할/7페르소나·§2-1 포털 매트릭스·§5B 공통레이어·§6 나노바나나·§8 아키텍처·design.md SCR-*) **전부 보존**, IA 레이어만 순증. ①**제품 공식 명칭 = "KINTEX AI 전시·행사시스템"**(기존 "자동전시시스템/Exhibition Automation Platform" 대체 — 전시+행사/이벤트 포괄) → H1 제목·헤더 명칭 절 갱신, 정본 선언(기존 표기는 문맥 보존상 잔존) ②**`docs/analysis/coex-website.md` 신설** — 코엑스 3-사이트 IA(VISITOR `coex.co.kr`/BUSINESS `business.coex.co.kr`/CYBER 참가신청 `cybercoex.co.kr`) 분석 + 킨텍스(kintex.com) 대비표 11축 + 차용 요소. WebFetch 3사이트 + WebSearch 보조 ③**§2-2 대외 접점 3-트랙 재구성 신설** — visitor(관람객)/business(주최자·참가업체)/agency(공사·장치·협력사) 3-트랙 정의(대상·여정·진입화면·기능 매핑), 코엑스 차용요소, 공개사이트 구조(관문 랜딩 3-분기 + 트랙별 서브홈 3 + **로그인 후 트랙-스코프 홈 권고**), **라우트 체계 3안 비교→하이브리드(트랙 셸 + 기존 딥라우트 유지, 마이그레이션 비용 최소) 권고**, 기존 SCR/라우트→트랙 재배치 매핑표(신규 화면 4종=관문+서브홈3만, 나머지 재사용). 트랙은 역할의 상위 묶음(대체 아님), 내부역할 ops·admin은 트랙 외부 유지. 헤더 v3.2 정체성 라인 추가. **design.md·src 미수정(designer/frontend 후속)** — 구현 지시서 `_workspace/plan_3track.md` 별도 작성 |
| **v3.1** | 2026-07-11 | planner | **계정 통합 + 가입 트랙 분리 · 모바일 2타깃 확정(소유자 확정 2026-07-11).** 기존 스코프 전부 보존, 계정·앱 채널 전략만 정밀화(상충 시 확정안 우선·삭제 없이 개정 표기). ①**§2-1 채널 매트릭스 개정** — 모바일 열을 운영 앱(B2B)/관람객 앱(B2C)으로 분리, 가입 트랙 열 신설(업무=승인·초대+2FA 필수 vs 관람객=간편가입/게스트 예매+2FA 미강제) ②**§2-1-1 신설** — (A)계정 체계 단일 통합+가입 트랙 분리(승격 시 단일 계정 등급 상향으로 리드·비즈매칭·재방문 이력 연속성 유지), (B)모바일 코드베이스 1개(Expo `mobile/`)·배포 타깃 2개(운영 앱=스토어 미공개 사내 QR/APK, 관람객 앱=스토어 공개), 관람객 1차 접점=공개 웹(SCR-P7/P8)·앱=리텐션 채널 ③**§5B-3 인증 정밀화** — 2FA 대상을 "업무 사용자 필수·관람객 미강제"로, 승격 시 2FA 필수 전환 명시 ④**M10 갱신** — 간편가입/게스트 예매(SCR-P7)·계정 승격 연속성·게스트 예매 개인정보/병합 정책 반영. 근거: `docs/analysis/ticketing-app-benchmark.md`(게스트 예매·간편가입 업계 표준). design.md·타 문서 미수정(designer 후속 반영 필요), 시크릿 미기재 |
