- 미사용 코드 삭제: ThemeContext, itemStore, utils/date.ts, utils/formatAmount.ts - 유틸리티 이동: date, formatAmount → src/lib/utils/ (중앙 집중화) - 다수 page.tsx 클라이언트 컴포넌트 패턴 통일 - DateRangeSelector 리팩토링 및 date-range-picker UI 컴포넌트 추가 - ThemeSelect/themeStore Zustand 직접 연동으로 전환 - 건설/회계/영업/품목/출하 등 전반적 컴포넌트 개선 - UniversalListPage, IntegratedListTemplateV2 타입 확장 - 프론트엔드 종합 리뷰 문서 및 개선 체크리스트 추가 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
7.9 KiB
7.9 KiB
동적 렌더링 플랫폼 전략 — 기준관리 기반 화면 자동 구성
작성일: 2026-02-19 상태: 비전 정리 (논의 기반) 관련 기술 설계:
[DESIGN-2026-02-11] dynamic-field-type-extension.md관련 구현 현황:[IMPL-2026-02-11] dynamic-field-components.md관련 로드맵:item-master/[DESIGN-2025-12-12] item-master-form-builder-roadmap.md
1. 핵심 비전
기준관리 페이지에서 설정 → API로 메타데이터 전달 → 프론트가 자동 렌더링
목표: 개발자가 매번 화면을 코딩하는 것이 아니라, 기준관리 페이지에서 등록한 설정값에 따라 프론트엔드가 동적으로 화면을 구성하는 ERP 커스터마이징 플랫폼.
2. 운영 워크플로우 비전
2.1 전체 흐름
현장 방문 (영업자/매니저)
├─ 녹음, 체크리스트, 문서 수집
└─ → MD 파일 정리 (요구사항)
│
↓
기준관리 페이지 (관리자/컨설턴트)
├─ MD 보고 속성, 칼럼, 옵션 등록
└─ → 메타데이터 저장 (DB)
│
↓ API
│
프론트엔드 (자동 렌더링)
└─ 메타데이터 기반으로 동적 화면 구성
2.2 역할 변화
| 역할 | 현재 | 비전 |
|---|---|---|
| 영업자/매니저 | 요구사항 전달 → 개발 대기 | 현장에서 MD 파일 작성 |
| 관리자/컨설턴트 | — | MD 보고 기준관리에 설정 입력 |
| 개발자 | 요구사항마다 화면 코딩 | 플랫폼 유지보수 + 새 블록 타입 추가 시에만 개입 |
2.3 개발자 개입이 필요한 시점
- 기존 블록(Input, Select, DatePicker 등)으로 조합 가능 → 개발자 불필요
- 새로운 입력 타입/계산 로직 필요 → 블록 1개 추가 → 이후 재사용
- 기준관리 UI 자체 개선 → 설계/검증
- page-builder 고도화 → 설계/구현
3. 현재 자산 현황
3.1 이미 있는 것
UI 블록 (공통 컴포넌트)
src/components/ui/
├─ Input, NumberInput, QuantityInput, CurrencyInput
├─ Select, Checkbox, DatePicker, Textarea
├─ Button, Badge, Card, Dialog
└─ ...
모든 도메인별 테이블이 이 공통 블록을 사용 중.
동적 필드 시스템 (14종 완성)
DynamicItemForm/fields/
├─ 기존 6종: textbox, number, dropdown, checkbox, date, textarea
└─ 신규 8종: reference, multi-select, file, currency, unit-value, radio, toggle, computed
Phase 1~3 프론트 구현 완료 (백엔드 작업 대기).
범용 테이블 섹션
DynamicTableSection — config 기반 칼럼 정의, 행 CRUD, 요약행
TableCellRenderer — 테이블 셀 = DynamicFieldRenderer 재사용
속성 관리 시스템 (품목기준관리)
useAttributeManagement — 속성 옵션 상태 관리
AttributeTabContent — 동적 탭 렌더링
OptionColumn[] + MasterOption[] — 메타데이터 구조
page-builder 프로토타입
/dev/page-builder — 드래그앤드롭, 섹션/필드 구성, Undo/Redo, 반응형 뷰포트
3.2 현재 구조: "기준관리 → 동적 렌더링" 패턴
품목기준관리 (Admin) 품목 등록 (User)
ItemMasterDataManagement.tsx DynamicItemForm/index.tsx
↓ 설정 (pages/sections/fields) ↓ 읽어서 렌더링
DB에 메타데이터 저장 DynamicFieldRenderer (14종 switch)
DynamicTableSection (config 기반)
이 패턴이 핵심이고, 다른 도메인에도 동일하게 확장하는 것이 비전.
4. 확장 대상 분석
4.1 도메인별 동적 렌더링 적합성
| 도메인 | 적합도 | 이유 |
|---|---|---|
| 품목기준관리 | ✅ 이미 적용 | 테넌트/업종별 관리 항목이 다름 |
| 설비/자산 관리 | ✅ 높음 | 설비 종류별 관리 속성이 다름 |
| 거래처 관리 | ✅ 높음 | 업종별 추가 정보 다름 |
| 공정/라우팅 관리 | ✅ 높음 | 제조 방식별 공정 구성 다름 |
| 검사 항목 관리 | ✅ 높음 | 품목별 검사 항목/기준 다름 |
| 견적서/발주서 | 🟡 부분 | 테이블은 동적 가능, 비즈니스 로직은 고정 |
| 세금계산서 | ❌ 낮음 | 법정 양식, 테넌트별 차이 없음 |
| 대시보드 | ❌ 낮음 | 위젯 기반이 더 적합 |
4.2 편집 가능 테이블 현황
| 컴포넌트 | 공통 컴포넌트 사용 | 자동 계산 | 합계 행 |
|---|---|---|---|
| EditableTable (공통) | 본인이 공통 | ❌ | ❌ |
| TaxInvoiceItemTable | ❌ 개별 | ✅ | ✅ |
| OrderDetailItemTable | ❌ 개별 | ❌ | ✅ |
| EstimateDetailTableSection | ❌ 개별 | ✅ (복잡) | ✅ |
| DynamicTableSection | ❌ 개별 (config 기반) | ✅ (요약) | ✅ |
테이블 안의 부품(Input, Select 등)은 전부 공통 ui 컴포넌트 사용. 껍데기(테이블 구조, 계산 로직)만 각자 구현.
5. page-builder 갭 분석
5.1 현재 page-builder 상태
/dev/page-builder (프로토타입)
✅ 드래그앤드롭 (섹션/필드 → 캔버스)
✅ 섹션 타입 (BASIC, BOM, CUSTOM)
✅ 필드 타입 (기본 6종)
✅ 조건부 표시 (DisplayCondition)
✅ 검증 규칙 (ValidationRule)
✅ BOM 테이블
✅ 마스터 필드 연동
✅ Undo/Redo 히스토리
✅ 반응형 뷰포트 (desktop/tablet/mobile)
✅ API 변환 타입 정의
5.2 비전 대비 부족한 점
| 항목 | 현재 | 필요 |
|---|---|---|
| 대상 도메인 | 품목 전용 (ItemType: FG/PT/SM/RM/CS) | 모든 기준관리 |
| 사용자 | 개발자용 프로토타입 | 비개발자(영업/매니저/관리자) |
| 테이블 섹션 | BOM만 (고정 칼럼) | 동적 칼럼 + 행 CRUD (DynamicTableSection 연결) |
| 신규 필드 타입 | 기본 6종만 | 14종 전체 반영 |
| API 연동 | 타입만 정의 | 실제 저장/조회 |
| 프리셋 | 하드코딩 | 산업별 섹션 프리셋 선택 |
5.3 고도화 방향
1단계: 도메인 범용화
- ItemType 종속 제거
- "기준관리 도메인" 선택 → 해당 도메인의 페이지 구성
2단계: 14종 필드 타입 반영
- ComponentPalette에 신규 8종 필드 추가
- PropertyPanel에 각 필드별 config 편집 UI
3단계: DynamicTableSection 연결
- BOM 외 범용 테이블 섹션 지원
- 칼럼 정의 UI (타입/너비/필수 설정)
4단계: 비개발자 UX
- 용어 단순화 (field_type → "입력 형태")
- 미리보기 강화
- 저장/불러오기
6. 4-Level 아키텍처 요약
기존 기술 설계서([DESIGN-2026-02-11])의 핵심:
Level 1: 필드 타입 컴포넌트 (14종) — 코드 레벨, 거의 안 바뀜
Level 2: properties config (JSON) — 설정 레벨, 코드 변경 없음
Level 3: 섹션 프리셋 (JSON) — 템플릿 레벨, 코드 변경 없음
Level 4: reference sources (API URL) — 연결 레벨, 코드 변경 없음
새 산업 진출 시에도 프론트엔드 코드 변경 = 0줄. 백엔드 API + config JSON만 추가.
7. 관련 문서
| 문서 | 위치 | 내용 |
|---|---|---|
| 동적 필드 타입 확장 설계 | architecture/[DESIGN-2026-02-11] |
4-Level 구조, 14종 필드, 범용 테이블, 산업별 확장 |
| 동적 필드 컴포넌트 구현 | architecture/[IMPL-2026-02-11] |
Phase 1~3 프론트 구현 완료 상태 |
| Form Builder 로드맵 | item-master/[DESIGN-2025-12-12] |
Low-Code Form Builder 초기 로드맵 |
| 백엔드 API 스펙 | item-master/[API-REQUEST-2026-02-12] |
동적 필드 타입 백엔드 API 요청서 |
| page-builder 참조 | dev/[REF] page-builder-implementation.md |
페이지 빌더 구현 참조 |
| 멀티테넌시 최적화 | architecture/[PLAN-2026-02-06] multi-tenancy-optimization-roadmap.md |
테넌트별 격리/최적화 |
문서 버전: 1.0 마지막 업데이트: 2026-02-19