kintex/docs/PLANNING.md

킨텍스 자동전시시스템 (Exhibition Automation Platform) 기획서

작성: 기획 에이전트(planner) · 작성일: 2026-07-11 · 버전: v3.1 근거 문서: docs/analysis/kintex-website.md (킨텍스 웹사이트 25개 페이지 + 전시주최자매뉴얼 PDF + 참가업체 매뉴얼 PDF 전수 분석, 2026-07-11) 근거 문서: 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. 문서 소유권: 본 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)로 위치한다. 앱 미설치 관람객도 웹 게스트 예매로 전 여정 완결 가능.
• 백오피스(관리자)는 모바일 미제공(웹 전용). 업무 사용자 모바일은 운영 앱으로만 제공.

---

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. 시스템 구성 (모듈 맵)

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일 전).

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

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. 입력 데이터 스키마 (요약)

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? } 형태.

// 부스 유형 — 골격 특성 프롬프트 조각
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 워커 사이드카.

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의 다중 포털·공개사이트·백오피스를 얹는다.

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 미반영.

---

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.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 후속 반영 필요), 시크릿 미기재