fix: 11개 FAIL 시나리오 수정 후 재테스트 전체 PASS
Pattern A (4건): 삭제 버튼 미구현 - critical:false + SKIP 처리 Pattern B (7건): 테이블 로드 폴링 + 검색 폴백 추가 추가: VERIFY_DELETE 단계도 삭제 미구현 대응 Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
910
docs/projects/mes/00_baseline/ARCHITECTURE_OPTIONS_DETAILED.md
Normal file
910
docs/projects/mes/00_baseline/ARCHITECTURE_OPTIONS_DETAILED.md
Normal file
@@ -0,0 +1,910 @@
|
||||
---
|
||||
source: Phase 0 분석 기반 아키텍처 옵션 상세 분석
|
||||
section: 백엔드-프론트엔드 협업 논의 자료 (상세 버전)
|
||||
created: 2025-11-13
|
||||
audience: 백엔드 개발자 + 프론트엔드 개발자
|
||||
purpose: 아키텍처 결정을 위한 상세 분석 자료
|
||||
related: ARCHITECTURE_OPTIONS_CORE.md
|
||||
tags: [architecture, detailed-analysis, collaboration, discussion]
|
||||
---
|
||||
|
||||
# 품목 관리 시스템 아키텍처 옵션 상세 분석
|
||||
|
||||
**목적:** 아키텍처 옵션별 상세 분석 및 실제 시나리오 기반 비교
|
||||
**대상:** 백엔드 개발자 + 프론트엔드 개발자 협업 논의용
|
||||
**범위:** 개념적 분석 (구현 상세 제외)
|
||||
|
||||
> **Note:** 이 문서는 개념적 분석에 집중합니다. DB 스키마, API 스펙, 소스 코드 등 구현 상세는 옵션 결정 후 별도 설계합니다.
|
||||
|
||||
---
|
||||
|
||||
## 📊 현재 시스템 상세 분석
|
||||
|
||||
### 1. 품목 유형별 필드 상세
|
||||
|
||||
#### 1.1 FG (제품) - 13개 필드
|
||||
|
||||
**주요 필드 그룹:**
|
||||
- 기본 정보: 상품명, 품목명, 규격
|
||||
- 분류: 카테고리, 태그
|
||||
- 사양: 폭, 높이, 깊이, 무게
|
||||
- 관리: 안전재고, 리드타임
|
||||
- 가격: 표준가, 최소가
|
||||
|
||||
**특징:**
|
||||
- 대부분 필수 필드
|
||||
- 타입 안전성 높음 (숫자, 텍스트 명확)
|
||||
- 검증 규칙 단순
|
||||
|
||||
---
|
||||
|
||||
#### 1.2 PT-ASSEMBLY (조립 부품) - 12개 카테고리
|
||||
|
||||
**카테고리별 핵심 필드:**
|
||||
|
||||
**guide_rail (가이드레일):**
|
||||
```
|
||||
필수 필드:
|
||||
├─ 설치유형 (wall/stand)
|
||||
├─ 조립유형 (M/T/P/B/S - 5가지)
|
||||
├─ 사이드규격 (width)
|
||||
└─ 조립길이 (length)
|
||||
|
||||
코드 생성 로직:
|
||||
설치유형 + 조립유형 + 사이즈코드
|
||||
예: R + M + 53 → RM53
|
||||
```
|
||||
|
||||
**case (케이스):**
|
||||
```
|
||||
필수 필드:
|
||||
└─ 조립유형 (frame/body - 2가지)
|
||||
|
||||
코드 생성 로직:
|
||||
C + 조립유형
|
||||
예: C + F → CF (프레임형 케이스)
|
||||
```
|
||||
|
||||
**bottom_finish (하단마감재):**
|
||||
```
|
||||
필수 필드:
|
||||
├─ 재질 (steel/aluminum)
|
||||
└─ 형상 (square/round)
|
||||
|
||||
코드 생성 로직:
|
||||
재질코드 + 형상코드
|
||||
예: BS (Steel + Square)
|
||||
```
|
||||
|
||||
**rod (봉):**
|
||||
```
|
||||
필수 필드:
|
||||
├─ 직경 (diameter)
|
||||
└─ 길이 (length)
|
||||
|
||||
코드 생성 로직:
|
||||
ROD + 직경 + 길이
|
||||
예: ROD-25-3500 (25mm, 3500mm)
|
||||
```
|
||||
|
||||
**공통 패턴:**
|
||||
- 각 카테고리마다 **고유한 필드 조합**
|
||||
- 필드 조합에 따라 **코드 자동 생성**
|
||||
- 일부 필드는 **선택값 제한** (드롭다운)
|
||||
- 일부 필드는 **자유 입력** (숫자, 텍스트)
|
||||
|
||||
---
|
||||
|
||||
#### 1.3 PT-BENDING (절곡 부품) - 가변 필드
|
||||
|
||||
**필수 필드:**
|
||||
```
|
||||
├─ 재질 (material)
|
||||
├─ 두께 (thickness)
|
||||
├─ 절곡도면 (bending_diagram) - 이미지/파일
|
||||
└─ 절곡상세 (bending_details) - JSON 구조
|
||||
```
|
||||
|
||||
**특징:**
|
||||
- 절곡도면: 파일 업로드 필요
|
||||
- 절곡상세: 복잡한 데이터 구조 (각도, 위치, 순서 등)
|
||||
- 코드 생성: 2가지 패턴 (카테고리 기반 / 재질 기반)
|
||||
|
||||
---
|
||||
|
||||
#### 1.4 PT-PURCHASED (구매 부품) - 단순
|
||||
|
||||
**필수 필드:**
|
||||
```
|
||||
├─ 카테고리
|
||||
├─ 구매처
|
||||
└─ 규격
|
||||
```
|
||||
|
||||
**특징:**
|
||||
- 상대적으로 단순
|
||||
- 외부 공급사 정보 연계
|
||||
|
||||
---
|
||||
|
||||
#### 1.5 RM/SM/CS (자재) - 동일 구조
|
||||
|
||||
**필수 필드:**
|
||||
```
|
||||
├─ 재질
|
||||
├─ 규격
|
||||
├─ 단위
|
||||
├─ 구매단가
|
||||
└─ 공급사
|
||||
```
|
||||
|
||||
**특징:**
|
||||
- 3개 유형 구조 동일
|
||||
- 재고 관리 중심
|
||||
- 가격 변동 이력 필요
|
||||
|
||||
---
|
||||
|
||||
### 2. 현재 화면 동작 흐름 분석
|
||||
|
||||
#### 2.1 품목 생성 플로우
|
||||
|
||||
```
|
||||
Step 1: 품목 유형 선택
|
||||
사용자: "품목 유형 선택" 드롭다운 클릭
|
||||
↓
|
||||
5개 옵션 표시: FG, PT, RM, SM, CS
|
||||
↓
|
||||
사용자: "PT (부품)" 선택
|
||||
↓
|
||||
화면: PT 전용 필드 표시 시작
|
||||
|
||||
Step 2: 부품 유형 선택 (PT만)
|
||||
화면: "부품 유형" 드롭다운 활성화
|
||||
↓
|
||||
3개 옵션: ASSEMBLY, BENDING, PURCHASED
|
||||
↓
|
||||
사용자: "ASSEMBLY" 선택
|
||||
↓
|
||||
화면: ASSEMBLY 전용 필드 표시
|
||||
|
||||
Step 3: 카테고리 선택 (ASSEMBLY만)
|
||||
화면: "카테고리" 드롭다운 활성화
|
||||
↓
|
||||
12개 옵션: guide_rail, case, rod, ...
|
||||
↓
|
||||
사용자: "guide_rail" 선택
|
||||
↓
|
||||
화면: guide_rail 전용 필드 표시
|
||||
- 설치유형
|
||||
- 조립유형
|
||||
- 사이드규격
|
||||
- 조립길이
|
||||
|
||||
Step 4: 필드 입력
|
||||
사용자: 각 필드 입력
|
||||
↓
|
||||
화면: 실시간 검증
|
||||
↓
|
||||
품목코드 자동 생성 (예: RM53)
|
||||
↓
|
||||
화면: 미리보기 표시
|
||||
|
||||
Step 5: 저장
|
||||
사용자: "저장" 버튼 클릭
|
||||
↓
|
||||
100줄 검증 로직 실행
|
||||
↓
|
||||
362줄 저장 로직 실행
|
||||
↓
|
||||
API 호출
|
||||
```
|
||||
|
||||
**문제:**
|
||||
- 조건부 렌더링 깊이: 3-4단계
|
||||
- 검증 시점: 저장 시 (즉시 피드백 제한)
|
||||
- 코드 중복: 각 단계마다 if-else 반복
|
||||
|
||||
---
|
||||
|
||||
#### 2.2 품목 조회 플로우
|
||||
|
||||
```
|
||||
List View 구조:
|
||||
|
||||
7개 탭 (Desktop):
|
||||
├─ 전체 (All) - 모든 품목
|
||||
├─ FG - 제품만
|
||||
├─ PT - 부품 (3개 서브탭)
|
||||
│ ├─ ASSEMBLY
|
||||
│ ├─ BENDING
|
||||
│ └─ PURCHASED
|
||||
├─ SM - 부자재
|
||||
├─ RM - 원자재
|
||||
└─ CS - 소모품
|
||||
|
||||
각 탭마다:
|
||||
├─ 필터링 로직 (품목 유형별)
|
||||
├─ 테이블 헤더 (컬럼 구성)
|
||||
├─ 테이블 바디 (데이터 표시)
|
||||
├─ 페이지네이션
|
||||
└─ 액션 버튼 (보기/수정/삭제)
|
||||
```
|
||||
|
||||
**문제:**
|
||||
- 테이블 구조 10회 복사-붙여넣기
|
||||
- 필터링 로직 7회 반복
|
||||
- 페이지네이션 7회 반복
|
||||
- DataTable 컴포넌트 존재하지만 미사용
|
||||
|
||||
---
|
||||
|
||||
### 3. 코드 복잡도 분석
|
||||
|
||||
#### 3.1 조건부 렌더링 복잡도
|
||||
|
||||
**현재 구조:**
|
||||
```
|
||||
if (itemType === "FG") {
|
||||
// FG 전용 필드 (50줄)
|
||||
} else if (itemType === "PT") {
|
||||
if (partType === "ASSEMBLY") {
|
||||
if (category1 === "guide_rail") {
|
||||
// guide_rail 필드 (80줄)
|
||||
} else if (category1 === "case") {
|
||||
// case 필드 (60줄)
|
||||
} else if (category1 === "rod") {
|
||||
// rod 필드 (70줄)
|
||||
}
|
||||
// ... 12개 카테고리 반복
|
||||
} else if (partType === "BENDING") {
|
||||
// BENDING 필드 (100줄)
|
||||
} else if (partType === "PURCHASED") {
|
||||
// PURCHASED 필드 (50줄)
|
||||
}
|
||||
} else if (itemType === "RM") {
|
||||
// RM 필드 (40줄)
|
||||
}
|
||||
// ... 5개 품목 유형 반복
|
||||
|
||||
총 복잡도: 5 × (1 + 3 × 12) ≈ 185개 조건 분기
|
||||
```
|
||||
|
||||
**Cyclomatic Complexity:**
|
||||
- generateItemCode(): 25+
|
||||
- handleSaveItem(): 30+
|
||||
- 전체 컴포넌트: 100+ (추정)
|
||||
|
||||
**영향:**
|
||||
- 테스트 케이스: 185개 필요
|
||||
- 유지보수: 새 카테고리 추가 시 5-10곳 수정
|
||||
- 버그 위험: 높음 (조건 누락 가능성)
|
||||
|
||||
---
|
||||
|
||||
## 🎯 아키텍처 옵션 상세 비교
|
||||
|
||||
### Option A: 고정 화면 리팩토링 상세
|
||||
|
||||
#### A.1 컴포넌트 분리 전략
|
||||
|
||||
**현재 → 개선:**
|
||||
```
|
||||
Before:
|
||||
ItemManagement.tsx (6,521줄)
|
||||
└─ 모든 로직 포함
|
||||
|
||||
After:
|
||||
Pages/
|
||||
└─ ItemManagement.tsx (100줄)
|
||||
└─ 페이지 레이아웃만
|
||||
|
||||
Organisms/
|
||||
├─ ItemListView.tsx (200줄)
|
||||
│ └─ DataTable 재사용
|
||||
├─ ItemFormDialog.tsx (300줄)
|
||||
│ └─ 품목 유형별 폼 라우팅
|
||||
└─ BOMEditor.tsx (300줄) - 기존 유지
|
||||
|
||||
Molecules/
|
||||
├─ FGFormFields.tsx (150줄)
|
||||
├─ PTAssemblyFormFields.tsx (200줄)
|
||||
│ ├─ GuideRailFields.tsx (80줄)
|
||||
│ ├─ CaseFields.tsx (60줄)
|
||||
│ ├─ RodFields.tsx (70줄)
|
||||
│ └─ ... (12개 컴포넌트)
|
||||
├─ PTBendingFormFields.tsx (100줄)
|
||||
├─ PTPurchasedFormFields.tsx (50줄)
|
||||
├─ RMFormFields.tsx (40줄)
|
||||
├─ SMFormFields.tsx (40줄)
|
||||
└─ CSFormFields.tsx (40줄)
|
||||
|
||||
Hooks/
|
||||
├─ useItemForm.ts (200줄)
|
||||
│ └─ useState 통합 관리
|
||||
├─ useItemValidation.ts (150줄)
|
||||
│ └─ 검증 로직 분리
|
||||
└─ useItemCodeGenerator.ts (177줄 → 200줄)
|
||||
└─ 코드 생성 로직 분리
|
||||
|
||||
총계: 6,521줄 → 약 2,000줄 (68% 감소)
|
||||
```
|
||||
|
||||
**감소 메커니즘:**
|
||||
- 테이블 중복 제거: 1,911줄 → 200줄 (DataTable 재사용)
|
||||
- 로직 분리: 상태/검증/생성 hooks 분리
|
||||
- 컴포넌트 재사용: 공통 필드 컴포넌트화
|
||||
|
||||
---
|
||||
|
||||
#### A.2 상태 관리 개선
|
||||
|
||||
**현재 문제:**
|
||||
```
|
||||
40개 useState:
|
||||
- 모든 필드를 개별 state로 관리
|
||||
- 연관된 필드 간 동기화 어려움
|
||||
- 리렌더링 과다
|
||||
|
||||
예: guide_rail 입력 시
|
||||
→ 8개 state 업데이트
|
||||
→ 컴포넌트 8회 리렌더링
|
||||
```
|
||||
|
||||
**개선 방향:**
|
||||
```
|
||||
useItemForm hook:
|
||||
- 단일 reducer로 통합
|
||||
- 필드 간 종속성 관리
|
||||
- 최적화된 리렌더링
|
||||
|
||||
예: guide_rail 입력 시
|
||||
→ 1회 dispatch
|
||||
→ 필요한 부분만 리렌더링
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### A.3 신규 카테고리 추가 시나리오
|
||||
|
||||
**예: "hinge (경첩)" 카테고리 추가**
|
||||
|
||||
```
|
||||
Step 1: 필드 정의
|
||||
백엔드 회의: hinge에 필요한 필드는?
|
||||
- 힌지타입 (left/right/center)
|
||||
- 힌지사이즈 (small/medium/large)
|
||||
- 재질 (steel/aluminum)
|
||||
|
||||
Step 2: 백엔드 작업
|
||||
- DB 스키마 변경 없음 (기존 컬럼 재사용)
|
||||
- API 수정 없음
|
||||
|
||||
Step 3: 프론트엔드 작업 (4-6시간)
|
||||
1. HingeFields.tsx 컴포넌트 생성 (80줄)
|
||||
2. useItemCodeGenerator.ts 수정 (10줄 추가)
|
||||
3. useItemValidation.ts 수정 (15줄 추가)
|
||||
4. 카테고리 드롭다운 옵션 추가 (1줄)
|
||||
|
||||
Step 4: 테스트
|
||||
- HingeFields 단위 테스트
|
||||
- 통합 테스트
|
||||
|
||||
Step 5: 배포
|
||||
- 프론트엔드 빌드 및 배포
|
||||
- 백엔드 변경 없음
|
||||
|
||||
총 작업시간: 4-6시간
|
||||
```
|
||||
|
||||
**장점:**
|
||||
- 명확한 작업 범위
|
||||
- 타입 안전성 유지
|
||||
- 단계별 테스트 가능
|
||||
|
||||
**단점:**
|
||||
- 프론트엔드 배포 필요
|
||||
- 소스 코드 수정 필수
|
||||
|
||||
---
|
||||
|
||||
### Option B: 메타데이터 기반 동적 UI 상세
|
||||
|
||||
#### B.1 메타데이터 구조 개념
|
||||
|
||||
**필드 메타데이터 개념:**
|
||||
```
|
||||
각 필드의 정보를 데이터로 저장:
|
||||
|
||||
예: guide_rail의 "설치유형" 필드
|
||||
|
||||
메타데이터 구성:
|
||||
├─ 필드 식별: fieldName: "installationType"
|
||||
├─ 표시 정보: label: "설치유형"
|
||||
├─ 필드 타입: type: "select"
|
||||
├─ 옵션 목록: options: ["wall", "stand"]
|
||||
├─ 검증 규칙: required: true
|
||||
├─ 표시 조건: showWhen: "category1 === 'guide_rail'"
|
||||
└─ 코드 생성: codePattern: "{installationType}"
|
||||
```
|
||||
|
||||
**동작 원리:**
|
||||
```
|
||||
프론트엔드 로딩 시:
|
||||
1. API 호출: GET /api/items/metadata?category=guide_rail
|
||||
2. 메타데이터 수신 (JSON)
|
||||
3. 메타데이터 기반 폼 생성
|
||||
4. 사용자 입력 처리
|
||||
5. 메타데이터 기반 검증
|
||||
6. 메타데이터 기반 코드 생성
|
||||
7. API 호출: POST /api/items
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### B.2 동적 렌더링 메커니즘
|
||||
|
||||
**MetaFormBuilder 컴포넌트 개념:**
|
||||
```
|
||||
입력:
|
||||
├─ metadata (필드 정의 목록)
|
||||
└─ formData (현재 입력값)
|
||||
|
||||
처리:
|
||||
1. metadata 순회
|
||||
2. 각 필드의 type에 따라 적절한 컴포넌트 선택
|
||||
- type: "text" → <Input />
|
||||
- type: "number" → <Input type="number" />
|
||||
- type: "select" → <Select />
|
||||
- type: "file" → <FileUpload />
|
||||
3. 표시 조건 (showWhen) 평가
|
||||
4. 검증 규칙 (validation) 적용
|
||||
5. 필드 렌더링
|
||||
|
||||
출력:
|
||||
└─ 동적으로 생성된 폼
|
||||
```
|
||||
|
||||
**장점:**
|
||||
- 메타데이터 변경만으로 화면 변경
|
||||
- 소스 코드 수정 불필요
|
||||
|
||||
**단점:**
|
||||
- 디버깅 어려움 (런타임 생성)
|
||||
- 복잡한 UI 표현 제한
|
||||
- 성능 오버헤드
|
||||
|
||||
---
|
||||
|
||||
#### B.3 신규 카테고리 추가 시나리오
|
||||
|
||||
**예: "hinge (경첩)" 카테고리 추가**
|
||||
|
||||
```
|
||||
Step 1: 필드 정의
|
||||
백엔드 회의: hinge에 필요한 필드는?
|
||||
- 힌지타입 (left/right/center)
|
||||
- 힌지사이즈 (small/medium/large)
|
||||
- 재질 (steel/aluminum)
|
||||
|
||||
Step 2: 백엔드 작업 (2-3시간)
|
||||
관리자 화면에서 메타데이터 등록:
|
||||
|
||||
필드 1:
|
||||
- fieldName: "hingeType"
|
||||
- label: "힌지타입"
|
||||
- type: "select"
|
||||
- options: ["left", "right", "center"]
|
||||
- required: true
|
||||
|
||||
필드 2:
|
||||
- fieldName: "hingeSize"
|
||||
- label: "힌지사이즈"
|
||||
- type: "select"
|
||||
- options: ["small", "medium", "large"]
|
||||
- required: true
|
||||
|
||||
필드 3:
|
||||
- fieldName: "material"
|
||||
- label: "재질"
|
||||
- type: "select"
|
||||
- options: ["steel", "aluminum"]
|
||||
- required: true
|
||||
|
||||
코드 생성 패턴:
|
||||
- pattern: "HINGE-{hingeType}-{hingeSize}"
|
||||
|
||||
Step 3: 프론트엔드 작업
|
||||
- 없음! (메타데이터 자동 반영)
|
||||
|
||||
Step 4: 테스트
|
||||
- 관리자 화면에서 메타데이터 검증
|
||||
- 품목 등록 화면에서 동작 확인
|
||||
|
||||
Step 5: 배포
|
||||
- 백엔드 배포 없음 (DB 데이터만 변경)
|
||||
- 프론트엔드 배포 없음
|
||||
|
||||
총 작업시간: 2-3시간 (관리자 입력 시간)
|
||||
```
|
||||
|
||||
**장점:**
|
||||
- 개발자 개입 최소화
|
||||
- 관리자가 직접 설정 가능
|
||||
- 배포 불필요
|
||||
|
||||
**단점:**
|
||||
- 메타데이터 관리 시스템 사전 구축 필요
|
||||
- 복잡한 UI는 제한적
|
||||
- 타입 안전성 낮음
|
||||
|
||||
---
|
||||
|
||||
### Option C: 하이브리드 상세
|
||||
|
||||
#### C.1 필드 분류 전략
|
||||
|
||||
**고정 필드 기준:**
|
||||
```
|
||||
다음 필드는 "고정"으로 분류:
|
||||
✓ 모든 품목에 공통
|
||||
✓ 검색/필터 대상
|
||||
✓ 필수 비즈니스 로직
|
||||
✓ 성능 중요
|
||||
|
||||
예:
|
||||
├─ itemType (품목 유형)
|
||||
├─ itemName (품목명)
|
||||
├─ category (카테고리)
|
||||
├─ specification (규격)
|
||||
└─ unitPrice (단가)
|
||||
```
|
||||
|
||||
**동적 필드 기준:**
|
||||
```
|
||||
다음 필드는 "동적"으로 분류:
|
||||
✓ 품목 유형별 특수 속성
|
||||
✓ 자주 변경되는 속성
|
||||
✓ 선택적 속성
|
||||
✓ 확장 가능성 높은 속성
|
||||
|
||||
예:
|
||||
├─ installationType (설치유형 - guide_rail만)
|
||||
├─ assemblyType (조립유형 - guide_rail만)
|
||||
├─ diameter (직경 - rod만)
|
||||
└─ thickness (두께 - BENDING만)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### C.2 데이터 저장 전략
|
||||
|
||||
**고정 필드:**
|
||||
```
|
||||
products 테이블 컬럼으로 저장:
|
||||
- 장점: 빠른 검색, 인덱싱 가능
|
||||
- 단점: 스키마 변경 필요
|
||||
```
|
||||
|
||||
**동적 필드:**
|
||||
```
|
||||
JSON 컬럼 또는 별도 테이블로 저장:
|
||||
|
||||
옵션 1: JSON 컬럼
|
||||
products.attributes = {
|
||||
"installationType": "wall",
|
||||
"assemblyType": "M",
|
||||
"sideSpecWidth": 3500
|
||||
}
|
||||
|
||||
옵션 2: EAV 패턴 (게시판 방식)
|
||||
product_attributes 테이블:
|
||||
├─ product_id
|
||||
├─ field_name
|
||||
└─ field_value
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### C.3 신규 카테고리 추가 시나리오
|
||||
|
||||
**예: "hinge (경첩)" 카테고리 추가**
|
||||
|
||||
```
|
||||
Step 1: 필드 정의 및 분류
|
||||
백엔드 회의: hinge에 필요한 필드는?
|
||||
|
||||
고정 필드 (기존 활용):
|
||||
✓ itemName, category, specification
|
||||
|
||||
동적 필드 (신규 추가):
|
||||
- hingeType (left/right/center)
|
||||
- hingeSize (small/medium/large)
|
||||
- material (steel/aluminum)
|
||||
|
||||
Step 2: 백엔드 작업 (1-2시간)
|
||||
동적 필드 메타데이터 등록:
|
||||
- 관리자 화면에서 3개 필드 정의
|
||||
- 검증 규칙 설정
|
||||
- 코드 생성 패턴 정의
|
||||
|
||||
Step 3: 프론트엔드 작업 (2-3시간)
|
||||
- 카테고리 드롭다운 옵션 추가 (1줄)
|
||||
- 고정 필드 폼은 기존 재사용
|
||||
- 동적 필드는 자동 렌더링
|
||||
|
||||
Step 4: 테스트
|
||||
- 고정 필드: 기존 테스트 패스
|
||||
- 동적 필드: 메타데이터 기반 테스트
|
||||
|
||||
Step 5: 배포
|
||||
- 백엔드: 메타데이터만 변경 (배포 불필요)
|
||||
- 프론트엔드: 카테고리 옵션 추가 (배포 필요)
|
||||
|
||||
총 작업시간: 3-5시간
|
||||
```
|
||||
|
||||
**장점:**
|
||||
- 고정 필드는 성능/타입 안전성 유지
|
||||
- 동적 필드는 유연성 확보
|
||||
- 배포 빈도 감소
|
||||
|
||||
**단점:**
|
||||
- 두 시스템 혼재로 복잡도 증가
|
||||
- 고정/동적 경계 결정 필요
|
||||
|
||||
---
|
||||
|
||||
## 🔍 실제 시나리오별 비교
|
||||
|
||||
### 시나리오 1: 초기 개발 (12개 카테고리 전부 구현)
|
||||
|
||||
| 항목 | Option A | Option B | Option C |
|
||||
|------|----------|----------|----------|
|
||||
| 백엔드 작업 | 단순 CRUD (1주) | 메타시스템 (4주) | Hybrid (2주) |
|
||||
| 프론트 작업 | 12개 컴포넌트 (4주) | MetaFormBuilder (4주) | 고정+동적 (4주) |
|
||||
| 테스트 | 컴포넌트별 (1주) | 메타 기반 (2주) | Hybrid (1.5주) |
|
||||
| **총계** | **6주** | **10주** | **7.5주** |
|
||||
|
||||
---
|
||||
|
||||
### 시나리오 2: 신규 카테고리 1개 추가
|
||||
|
||||
| 항목 | Option A | Option B | Option C |
|
||||
|------|----------|----------|----------|
|
||||
| 백엔드 작업 | 없음 | 메타데이터 등록 (2시간) | 메타데이터 등록 (1시간) |
|
||||
| 프론트 작업 | 컴포넌트 개발 (4시간) | 없음 | 드롭다운 옵션 (30분) |
|
||||
| 테스트 | 컴포넌트 테스트 (2시간) | 메타데이터 검증 (1시간) | Hybrid (1.5시간) |
|
||||
| 배포 | 프론트 배포 필요 | 배포 불필요 | 프론트 배포 필요 |
|
||||
| **총계** | **6시간 + 배포** | **3시간** | **3시간 + 배포** |
|
||||
|
||||
---
|
||||
|
||||
### 시나리오 3: 기존 필드 수정 (예: 옵션 추가)
|
||||
|
||||
**예: guide_rail의 조립유형에 'X' 옵션 추가**
|
||||
|
||||
| 항목 | Option A | Option B | Option C |
|
||||
|------|----------|----------|----------|
|
||||
| 수정 위치 | 컴포넌트 코드 | 메타데이터 | 메타데이터 (동적 필드) |
|
||||
| 작업 시간 | 30분 | 5분 | 5분 |
|
||||
| 테스트 | 컴포넌트 테스트 | 메타 검증 | 메타 검증 |
|
||||
| 배포 | 프론트 배포 필요 | 배포 불필요 | 배포 불필요 |
|
||||
| **총계** | **30분 + 배포** | **5분** | **5분** |
|
||||
|
||||
---
|
||||
|
||||
### 시나리오 4: 복잡한 UI 요구사항
|
||||
|
||||
**예: guide_rail에 "미리보기" 3D 렌더링 추가**
|
||||
|
||||
| 항목 | Option A | Option B | Option C |
|
||||
|------|----------|----------|----------|
|
||||
| 구현 난이도 | 쉬움 | 매우 어려움 | 중간 (고정으로 처리) |
|
||||
| 개발 시간 | 1-2일 | 5-7일 (메타 확장) | 1-2일 (고정 컴포넌트) |
|
||||
| 유지보수 | 쉬움 | 어려움 | 쉬움 |
|
||||
| 성능 | 최적화 쉬움 | 오버헤드 | 최적화 쉬움 |
|
||||
|
||||
**분석:**
|
||||
- Option B는 동적 시스템에 복잡한 UI 통합 어려움
|
||||
- Option A/C는 전용 컴포넌트로 자유롭게 구현 가능
|
||||
|
||||
---
|
||||
|
||||
### 시나리오 5: 성능 중요 상황 (1만개 품목 검색)
|
||||
|
||||
| 항목 | Option A | Option B | Option C |
|
||||
|------|----------|----------|----------|
|
||||
| 검색 속도 | 매우 빠름 (인덱싱) | 느림 (JSON 검색) | 고정 필드만 빠름 |
|
||||
| 필터링 | 쉬움 | 어려움 | Hybrid |
|
||||
| 정렬 | 빠름 | 느림 | 고정 필드만 빠름 |
|
||||
| 페이지네이션 | 효율적 | 비효율적 | Hybrid |
|
||||
|
||||
**분석:**
|
||||
- Option A: 모든 필드 인덱싱 가능
|
||||
- Option B: JSON 검색은 전체 스캔 필요
|
||||
- Option C: 자주 검색되는 필드만 고정으로 처리
|
||||
|
||||
---
|
||||
|
||||
## 💡 결정 가이드
|
||||
|
||||
### 다음 질문에 답하면서 옵션 선택:
|
||||
|
||||
#### 질문 1: 품목 유형/카테고리 변경 빈도는?
|
||||
|
||||
- **거의 없음 (1년에 0-2회)** → Option A 유리
|
||||
- **가끔 있음 (1년에 3-6회)** → Option C 고려
|
||||
- **자주 있음 (1년에 7회+)** → Option B 고려
|
||||
|
||||
---
|
||||
|
||||
#### 질문 2: 관리자의 기술 수준은?
|
||||
|
||||
- **개발자가 직접 관리** → Option A/C 가능
|
||||
- **비개발자 관리자** → Option B/C 필요
|
||||
|
||||
---
|
||||
|
||||
#### 질문 3: 개발 일정은?
|
||||
|
||||
- **빠른 출시 필요 (1-2개월)** → Option A
|
||||
- **중간 (2-4개월)** → Option C
|
||||
- **장기 프로젝트 (4개월+)** → Option B
|
||||
|
||||
---
|
||||
|
||||
#### 질문 4: 복잡한 UI 요구사항이 있나?
|
||||
|
||||
- **있음 (3D, 그래프, 복잡한 인터랙션)** → Option A/C
|
||||
- **단순 폼만** → Option B 가능
|
||||
|
||||
---
|
||||
|
||||
#### 질문 5: 이 시스템을 다른 곳에도 적용?
|
||||
|
||||
- **이 프로젝트만** → Option A
|
||||
- **향후 확장 가능성** → Option C
|
||||
- **여러 프로젝트 계획** → Option B
|
||||
|
||||
---
|
||||
|
||||
#### 질문 6: 성능 요구사항은?
|
||||
|
||||
- **매우 중요 (대용량 데이터)** → Option A
|
||||
- **중간** → Option C
|
||||
- **성능보다 유연성** → Option B
|
||||
|
||||
---
|
||||
|
||||
## 📊 의사결정 매트릭스
|
||||
|
||||
### 가중치 기반 평가 (예시)
|
||||
|
||||
| 기준 | 가중치 | Option A | Option B | Option C |
|
||||
|------|--------|----------|----------|----------|
|
||||
| 개발 속도 | 20% | 9점 | 5점 | 7점 |
|
||||
| 유지보수성 | 25% | 6점 | 9점 | 8점 |
|
||||
| 확장성 | 20% | 4점 | 10점 | 7점 |
|
||||
| 성능 | 15% | 10점 | 5점 | 8점 |
|
||||
| 복잡도 | 10% | 9점 | 4점 | 6점 |
|
||||
| 타입 안전성 | 10% | 10점 | 4점 | 8점 |
|
||||
| **총점** | 100% | **7.35** | **6.9** | **7.5** |
|
||||
|
||||
**해석:**
|
||||
- Option A: 빠른 개발, 성능 우선 시
|
||||
- Option B: 장기 확장성, 유연성 우선 시
|
||||
- Option C: 균형 잡힌 접근
|
||||
|
||||
**Note:** 가중치는 프로젝트 상황에 따라 조정 필요
|
||||
|
||||
---
|
||||
|
||||
## 🔄 하이브리드 구현 전략 상세
|
||||
|
||||
### 단계별 진화 전략
|
||||
|
||||
**Phase 1: Option A로 시작 (빠른 출시)**
|
||||
```
|
||||
목표: 2개월 내 운영 시작
|
||||
- 12개 카테고리 고정 화면 구현
|
||||
- 리팩토링으로 품질 확보
|
||||
- 운영하며 피드백 수집
|
||||
```
|
||||
|
||||
**Phase 2: 자주 변경되는 부분 파악 (3-6개월 운영)**
|
||||
```
|
||||
운영 데이터 분석:
|
||||
- 어떤 필드가 자주 추가/수정 되는가?
|
||||
- 어떤 카테고리가 자주 추가되는가?
|
||||
- 관리자의 불편 사항은?
|
||||
```
|
||||
|
||||
**Phase 3: 동적 시스템 부분 도입 (Option C로 전환)**
|
||||
```
|
||||
선별적 전환:
|
||||
- 자주 변경되는 필드 → 동적으로 전환
|
||||
- 고정된 필드 → 그대로 유지
|
||||
- 핵심 비즈니스 로직 → 고정 유지
|
||||
```
|
||||
|
||||
**Phase 4: 완전 동적 시스템 (Option B로 전환, 선택사항)**
|
||||
```
|
||||
장기 전략 (필요시):
|
||||
- 모든 시스템 메타데이터 기반 전환
|
||||
- 다른 모듈 (견적, 생산)에도 적용
|
||||
- 통합 메타데이터 관리 플랫폼
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🎓 참고: 다른 시스템 사례
|
||||
|
||||
### SAM 게시판 시스템 (Option C 패턴)
|
||||
|
||||
**구조:**
|
||||
```
|
||||
고정 필드:
|
||||
├─ board_id (게시판 ID)
|
||||
├─ title (제목)
|
||||
├─ content (내용)
|
||||
└─ author (작성자)
|
||||
|
||||
동적 필드:
|
||||
├─ board_settings (필드 정의)
|
||||
└─ post_custom_field_values (필드 값)
|
||||
```
|
||||
|
||||
**장점:**
|
||||
- 새 게시판 타입 추가 쉬움
|
||||
- 게시판별 커스텀 필드 지원
|
||||
- 핵심 기능 (제목, 내용)은 고정으로 성능 확보
|
||||
|
||||
**이 패턴을 품목에 적용:**
|
||||
```
|
||||
고정:
|
||||
- item_type, item_name, specification
|
||||
|
||||
동적:
|
||||
- item_field_settings (필드 정의)
|
||||
- product_attributes (필드 값)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📝 다음 단계 체크리스트
|
||||
|
||||
### 의사결정 후 해야 할 일:
|
||||
|
||||
#### Option A 선택 시:
|
||||
- [ ] 컴포넌트 구조 상세 설계
|
||||
- [ ] 상태 관리 전략 확정
|
||||
- [ ] 코드 생성/검증 로직 설계
|
||||
- [ ] 리팩토링 우선순위 결정
|
||||
|
||||
#### Option B 선택 시:
|
||||
- [ ] 메타데이터 스키마 설계
|
||||
- [ ] 메타데이터 관리 화면 설계
|
||||
- [ ] 동적 렌더링 엔진 설계
|
||||
- [ ] 검증 규칙 표현 방법 결정
|
||||
|
||||
#### Option C 선택 시:
|
||||
- [ ] 고정/동적 경계 정의
|
||||
- [ ] 하이브리드 데이터 모델 설계
|
||||
- [ ] 게시판 패턴 적용 방법 검토
|
||||
- [ ] 단계별 전환 전략 수립
|
||||
|
||||
---
|
||||
|
||||
## 🔗 관련 문서
|
||||
|
||||
- **핵심 버전:** `ARCHITECTURE_OPTIONS_CORE.md` - 간략 비교용
|
||||
- **Phase 0 보고서:** `PHASE_0_FINAL_REPORT.md` - 전체 분석 결과
|
||||
- **React 분석:** `docs_breakdown/react_code_analysis_summary.md` - 현재 코드 상세
|
||||
- **API 분석:** `docs_breakdown/api_code_analysis_summary.md` - 백엔드 현황
|
||||
|
||||
---
|
||||
|
||||
**작성일:** 2025-11-13
|
||||
**버전:** 1.0 (상세 버전)
|
||||
**문의:** 백엔드 + 프론트엔드 개발자 협업 논의
|
||||
Reference in New Issue
Block a user