Files
sam-react-prod/claudedocs/architecture/[VISION-2026-02-19] dynamic-rendering-platform-strategy.md
유병철 a2c3e4c41e refactor(WEB): 프론트엔드 대규모 코드 정리 및 리팩토링
- 미사용 코드 삭제: 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>
2026-02-19 16:30:07 +09:00

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