158 lines
16 KiB
Markdown
158 lines
16 KiB
Markdown
1. 문서 전제 수정 필요
|
|
|
|
현재 (부정확):
|
|
▎ "모든 테넌트에게 모든 메뉴가 보입니다" → 모듈 분리로 해결
|
|
|
|
실제:
|
|
▎ 메뉴 표시/숨김은 권한 시스템이 이미 처리함. 모듈 분리는 권한으로 안 되는 영역을 보완하는 것
|
|
|
|
---
|
|
2. 모듈 분리가 해야 할 것 (권한과 중복 제거)
|
|
|
|
┌───────────────────────────┬───────────────────────────────┬───────────────────────────┐
|
|
│ 항목 │ 현재 모듈 분리 │ 제안 │
|
|
├───────────────────────────┼───────────────────────────────┼───────────────────────────┤
|
|
│ 사이드바 메뉴 숨김 │ isRouteAllowed로 이중 필터링 │ 제거 — 권한 시스템이 담당 │
|
|
├───────────────────────────┼───────────────────────────────┼───────────────────────────┤
|
|
│ 라우트 차단 (ModuleGuard) │ PermissionGate 위에 이중 차단 │ 제거 검토 — 권한으로 충분 │
|
|
├───────────────────────────┼───────────────────────────────┼───────────────────────────┤
|
|
│ 대시보드 섹션 필터링 │ 모듈 기반 섹션 ON/OFF │ 유지 — 권한으로 불가능 │
|
|
├───────────────────────────┼───────────────────────────────┼───────────────────────────┤
|
|
│ 대시보드 API 호출 스킵 │ 비활성 모듈 API 미호출 │ 유지 — 성능 최적화 │
|
|
├───────────────────────────┼───────────────────────────────┼───────────────────────────┤
|
|
│ 크로스 모듈 import 규칙 │ 코드 아키텍처 경계 │ 유지 — 코드 품질 │
|
|
└───────────────────────────┴───────────────────────────────┴───────────────────────────┘
|
|
|
|
---
|
|
3. 두 가지 방향 중 선택
|
|
|
|
A안: 모듈 분리를 "대시보드 전용"으로 축소
|
|
|
|
- ModuleGuard, 사이드바 필터링 제거
|
|
- 대시보드 섹션/API 최적화 + 코드 아키텍처 경계만 유지
|
|
- 메뉴/라우트 접근 제어는 100% 권한 시스템에 위임
|
|
- 장점: 중복 제거, 단순화
|
|
- 단점: 권한 미설정 시 불필요한 페이지 접근 가능
|
|
|
|
B안: 모듈 분리를 "권한 자동 설정의 상위 레이어"로 재정의
|
|
|
|
- industry 설정 시 → 백엔드에서 해당 업종의 메뉴 권한을 자동으로 일괄 설정
|
|
- 프론트엔드 모듈 분리 코드 대부분 제거 (권한 시스템이 처리하므로)
|
|
- 대시보드 최적화만 프론트에 유지
|
|
- 장점: 권한 시스템 하나로 통합, 프론트 코드 단순화
|
|
- 단점: 백엔드 작업 필요 (industry → 메뉴 권한 매핑 로직)
|
|
|
|
---
|
|
4. 제 추천: B안
|
|
|
|
이유:
|
|
- 권한 시스템이 이미 견고하게 구축되어 있음
|
|
- 프론트에서 이중으로 제어할 이유가 없음
|
|
- industry 값은 "새 테넌트 온보딩 시 메뉴 권한 기본값을 자동으로 세팅"하는 용도로 활용
|
|
- 대시보드 섹션/API 최적화만 프론트에 남기면 깔끔
|
|
|
|
현재: industry → 프론트에서 메뉴 숨김 + 라우트 차단 + 대시보드 필터링
|
|
개선: industry → 백엔드에서 메뉴 권한 자동 설정 + 프론트 대시보드 최적화만
|
|
|
|
|
|
1. 테넌트 온보딩 자동화 (B안 확장)
|
|
|
|
현재 새 테넌트 추가 시 메뉴 권한을 수동으로 하나씩 설정해야 합니다.
|
|
|
|
현재 흐름:
|
|
테넌트 생성 → 글로벌 메뉴 동기화 → 역할 생성 → 메뉴 권한 하나씩 설정 (수십 개)
|
|
|
|
개선 흐름:
|
|
테넌트 생성 → industry 선택 → 업종별 메뉴 프리셋 자동 적용
|
|
|
|
백엔드에 메뉴 프리셋 테이블 또는 시더 로직 추가:
|
|
// 예시: industry별 기본 활성 메뉴 세트
|
|
$presets = [
|
|
'shutter_mes' => ['대시보드', '판매관리', '생산관리', '품질관리', '차량관리', ...],
|
|
'construction' => ['대시보드', '판매관리', '시공관리', '차량관리', ...],
|
|
];
|
|
|
|
이러면 테넌트 생성 시 클릭 한 번으로 수십 개 메뉴 권한이 자동 세팅됩니다.
|
|
|
|
---
|
|
2. 대시보드 섹션도 권한 시스템으로 통합 검토
|
|
|
|
현재 대시보드 섹션은 모듈 분리에서만 제어하는데, 이것도 메뉴 권한으로 통합 가능합니다.
|
|
|
|
현재: 대시보드는 하나의 메뉴 (/dashboard) → 내부 섹션은 모듈 분리가 제어
|
|
대안: 대시보드 섹션을 가상 메뉴로 등록 → 권한으로 제어
|
|
|
|
예:
|
|
menu: "대시보드 > 생산현황" url: /dashboard#production → view 권한
|
|
menu: "대시보드 > 시공현황" url: /dashboard#construction → view 권한
|
|
|
|
다만 이건 과도할 수 있으니, 대시보드만큼은 모듈 분리(또는 사용자 설정)로 유지하는 게 현실적일 수
|
|
있습니다. 현재 CEO 대시보드에 섹션 설정 팝업이 이미 있으니까요.
|
|
|
|
---
|
|
3. 프론트엔드 코드 정리 범위
|
|
|
|
B안 채택 시 제거 가능한 코드:
|
|
|
|
┌───────────────────────────────┬────────────────────────────┬────────────────────────────────┐
|
|
│ 파일 │ 현재 역할 │ B안 적용 후 │
|
|
├───────────────────────────────┼────────────────────────────┼────────────────────────────────┤
|
|
│ ModuleGuard.tsx │ 라우트 차단 │ 제거 — PermissionGate가 처리 │
|
|
├───────────────────────────────┼────────────────────────────┼────────────────────────────────┤
|
|
│ useModules.ts → │ 사이드바 메뉴 필터링 │ 제거 — 백엔드 메뉴 응답이 이미 │
|
|
│ isRouteAllowed │ │ 필터링 │
|
|
├───────────────────────────────┼────────────────────────────┼────────────────────────────────┤
|
|
│ useModules.ts → isEnabled │ 컴포넌트 내 분기 │ 대시보드 전용으로 축소 │
|
|
├───────────────────────────────┼────────────────────────────┼────────────────────────────────┤
|
|
│ 각 페이지의 명시적 가드 │ /sales/production-orders │ 제거 — 권한 시스템이 처리 │
|
|
│ │ 등 │ │
|
|
├───────────────────────────────┼────────────────────────────┼────────────────────────────────┤
|
|
│ verify-module-separation.sh │ 크로스 모듈 import 검증 │ 유지 — 코드 품질 │
|
|
├───────────────────────────────┼────────────────────────────┼────────────────────────────────┤
|
|
│ MODULE.md 경계 마커 │ 모듈 경계 문서 │ 유지 — 개발 가이드 │
|
|
└───────────────────────────────┴────────────────────────────┴────────────────────────────────┘
|
|
|
|
---
|
|
4. industry 값의 위치 재검토
|
|
|
|
현재 문서는 tenant.options.industry에 저장하는데, 이게 맞는지:
|
|
|
|
┌────────────────────────────────┬───────────────────────────┬────────────────────┐
|
|
│ 방식 │ 장점 │ 단점 │
|
|
├────────────────────────────────┼───────────────────────────┼────────────────────┤
|
|
│ tenant.options.industry (현재) │ 마이그레이션 불필요, 유연 │ 검색/인덱싱 어려움 │
|
|
├────────────────────────────────┼───────────────────────────┼────────────────────┤
|
|
│ tenants.industry 컬럼 추가 │ 검색/인덱싱 가능, 명시적 │ 마이그레이션 필요 │
|
|
└────────────────────────────────┴───────────────────────────┴────────────────────┘
|
|
|
|
B안에서 industry가 메뉴 프리셋 자동 적용의 트리거가 된다면, 별도 컬럼이 더 적절할 수 있습니다.
|
|
다만 컬럼 추가 정책(FK/조인키만 컬럼)과 충돌하므로 options JSON 유지가 맞을 수도 있고요.
|
|
|
|
---
|
|
5. 향후 SaaS 확장 시 모듈 과금
|
|
|
|
지금은 고려 안 해도 되지만, 향후 SAM을 SaaS로 확장할 때:
|
|
|
|
Free: 공통 ERP (회계, 인사, 영업)
|
|
Standard: + 생산관리 OR 시공관리
|
|
Premium: + 품질관리 + 차량관리 + AI 분석
|
|
|
|
이런 구조가 된다면, industry 대신 구독 플랜 기반 모듈 활성화가 필요합니다. 그때는 B안의
|
|
"백엔드에서 모듈 → 메뉴 권한 자동 매핑" 구조가 그대로 확장 가능합니다.
|
|
|
|
---
|
|
정리: 우선순위
|
|
|
|
┌──────┬──────────────────────────────────────────────────┬─────────────┬─────────────┐
|
|
│ 순위 │ 항목 │ 난이도 │ 효과 │
|
|
├──────┼──────────────────────────────────────────────────┼─────────────┼─────────────┤
|
|
│ 1 │ 문서 전제 수정 (부정확한 내용 교정) │ 낮음 │ 혼란 방지 │
|
|
├──────┼──────────────────────────────────────────────────┼─────────────┼─────────────┤
|
|
│ 2 │ 프론트 중복 코드 정리 (ModuleGuard, 명시적 가드) │ 중간 │ 코드 단순화 │
|
|
├──────┼──────────────────────────────────────────────────┼─────────────┼─────────────┤
|
|
│ 3 │ 테넌트 온보딩 자동화 (industry → 메뉴 프리셋) │ 중간 │ 운영 편의성 │
|
|
├──────┼──────────────────────────────────────────────────┼─────────────┼─────────────┤
|
|
│ 4 │ 대시보드 최적화 유지 │ 없음 (현행) │ 성능 │
|
|
├──────┼──────────────────────────────────────────────────┼─────────────┼─────────────┤
|
|
│ 5 │ SaaS 과금 구조 │ 높음 (향후) │ 사업 확장 │
|
|
└──────┴──────────────────────────────────────────────────┴─────────────┴─────────────┘ |