# 킨텍스 AI 전시·행사시스템 (KINTEX AI Exhibition & Event System) 기획서 > 작성: 기획 에이전트(planner) · 작성일: 2026-07-11 · 최종 갱신: 2026-07-12 · 버전: **v3.2** > **제품 공식 명칭(소유자 확정 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은 대외 트랙 외부에 그대로 유지). > **문서 소유권**: 본 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`). --- ## 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 플로어플랜 스튜디오
3안 생성·선택/병합·규정검증] M3[M3 부스 설계 스튜디오
3안 생성·선택/병합] M4[M4 유틸리티 설계
전기·조명/네트워크·급배수] M5[M5 나노바나나
시공 후 예상 사진] end subgraph 판매운영["판매·발주·정산"] M1[M1 홀 배정·자동 견적] M6[M6 서류·마일스톤] M7[M7 등록업체 매칭] M15[M15 공사/장치 옥션
역경매·견적서 응찰] M8[M8 반입/반출 물류] M9[M9 정산·결제] end subgraph 관람참가["관람·참가·마케팅"] M10[M10 관람객 등록·배지
체크인·리드캡처] M11[M11 비즈니스 매칭] M12[M12 마케팅·EDM
공개 홍보 사이트] M13[M13 wayfinding
실내 내비] M14[M14 현장운영
혼잡·안전·주차·에너지] end subgraph 경영["경영·콘텐츠·관리"] M16[M16 경영분석 BI
매출·가동률·P&L·수요예측] M17[M17 CMS
콘텐츠·마이크로사이트·다국어] M18[M18 관리자 시스템
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 추가). 게스트 예매 후 간편가입 시 예매 이력을 티켓 지갑에 병합. - **채널**: 관람객 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 집계 | - **데이터마트 설계(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가 이벤트 발행). ### 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`이나(재시작·다중 인스턴스 취약) — 본 시스템은 **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)
반응형: 데스크톱=설계·에디터, 모바일=조회·승인·현장] CANVAS[플로어플랜 캔버스
SVG/WebGL 편집기] end subgraph Backend API[Spring Boot 3.x (Java 17)
REST + WebSocket/STOMP 진행 알림] RULE[룰 엔진
규정 검증·요율 계산 (서비스 계층)] LAYOUT[배치·배선 엔진
제약 솔버 + PostGIS 공간 SQL] MYB[MyBatis
매퍼·공간 SQL 바인딩] QUEUE[비동기 작업 큐 Redis
RenderJob·서류 생성·알림] NB[나노바나나 Python 워커 사이드카
tools/nanobanana · google-genai SDK] end subgraph Data PG[(PostgreSQL + PostGIS
공간 데이터·업무 데이터)] OBJ[(오브젝트 스토리지
도면·생성 이미지·서식)] 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. 공개 홍보 사이트
SEO·SSR·다국어] FV[관람객 모바일 앱
배지·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
라운드·순위·낙찰스코어] 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 미반영. --- ## 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. 변경 이력 | 버전 | 일자 | 작성자 | 내용 | |---|---|---|---| | 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.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 후속 반영 필요), 시크릿 미기재 |