514 lines
21 KiB
Markdown
514 lines
21 KiB
Markdown
# SAM 특허 후보 기술 요약서
|
||
|
||
> **작성일**: 2026-03-11
|
||
> **작성 목적**: 변리사 미팅용 기술 요약서
|
||
> **대상 시스템**: SAM (Smart Automation Management) - 블라인드/스크린 제조업 특화 ERP/MES 통합 SaaS
|
||
> **출원인**: (주)코드브릿지엑스
|
||
> **상태**: 운영 중 (2개 제조업체 실 사용)
|
||
|
||
---
|
||
|
||
## 목차
|
||
|
||
1. [SAM 시스템 개요](#1-sam-시스템-개요)
|
||
2. [신규성 — 기존 시장에 없던 새로운 관리 프로세스](#2-신규성--기존-시장에-없던-새로운-관리-프로세스)
|
||
3. [진보성 — 기존 대비 비용/시간을 획기적으로 줄인 기술](#3-진보성--기존-대비-비용시간을-획기적으로-줄인-기술)
|
||
4. [산업상 이용 가능성 — 실제 현장 검증 사례](#4-산업상-이용-가능성--실제-현장-검증-사례)
|
||
5. [특허 출원 전략 제안](#5-특허-출원-전략-제안)
|
||
6. [핵심 증빙 파일 목록](#6-핵심-증빙-파일-목록)
|
||
|
||
---
|
||
|
||
## 1. SAM 시스템 개요
|
||
|
||
### 1.1 비즈니스 배경
|
||
|
||
- **산업**: 블라인드/스크린/셔터 제조 및 시공업
|
||
- **고객사**: 경동기업(Tenant 287), 주일기업(Tenant 1) — 2개 제조업체가 실 운영 중
|
||
- **레거시**: 5130.co.kr (순수 PHP 시스템, 20년+ 운영) → SAM으로 전환 중
|
||
- **레거시 문제**: 견적 3~5시간 소요, BOM 수기 작성, 공정 데이터 단절, 엑셀 기반 단가 관리
|
||
|
||
### 1.2 기술 스택
|
||
|
||
| 구분 | 기술 |
|
||
|------|------|
|
||
| 백엔드 | Laravel 12 (PHP 8.4) |
|
||
| 프론트엔드 | Next.js (React) + HTMX + Tailwind CSS |
|
||
| 데이터베이스 | MySQL 8.0 (운영 DB: `sam_prod`, 분석 DB: `sam_stat`) |
|
||
| 인프라 | Nginx + PHP-FPM + Supervisor + Jenkins CI/CD |
|
||
| 아키텍처 | Multi-tenant SaaS (tenant_id 기반 Row-Level 데이터 격리) |
|
||
| 규모 | 220개 Eloquent 모델, 459개 마이그레이션, 1,027+ API 엔드포인트 |
|
||
|
||
### 1.3 경쟁 환경
|
||
|
||
| 기능 | SAP S/4HANA | Oracle NetSuite | 국산 ERP | **SAM** |
|
||
|------|:-----------:|:---------------:|:--------:|:-------:|
|
||
| 블라인드/스크린 특화 BOM | X | X | 약함 | **최적화** |
|
||
| 멀티테넌트 SaaS | 약함 | 중간 | 약함 | **강함** |
|
||
| 동적 필드 시스템 | 제한적 | 제한적 | 약함 | **매우 유연** |
|
||
| 견적 → 생산 자동화 | 범용 | 범용 | 수작업 | **산업 특화** |
|
||
| 원가 실시간 추적 | 복잡 | 중간 | 약함 | **자동** |
|
||
| API-First | 약함 | 중간 | 약함 | **100%** |
|
||
|
||
---
|
||
|
||
## 2. 신규성 — 기존 시장에 없던 새로운 관리 프로세스
|
||
|
||
### 발명 후보 A: 제조업 특화 동적 BOM 자동 생성 및 수식 엔진
|
||
|
||
#### 기술적 과제
|
||
|
||
블라인드/스크린 제조업은 제품별(스크린, 셔터, 블라인드) 견적 계산 방식이 완전히 다르다. 기존 ERP는 범용 BOM 구조만 지원하여, 개구부 치수 입력 → 제작규격 변환 → 파생변수 계산 → BOM 전개 → 단가 조회 → 금액 산출의 **10단계 자동 계산 파이프라인**이 존재하지 않았다.
|
||
|
||
#### 해결 수단
|
||
|
||
```
|
||
[입력] [자동 처리 엔진] [출력]
|
||
개구부 치수(W0, H0) → 제작규격 자동 변환 → BOM 항목 목록
|
||
수량(QTY) → (W1 = W0 + 마진값) → 항목별 수량/단가
|
||
설치유형(벽/천장) → 파생변수 계산 → 카테고리별 소계
|
||
모터유형 → (M=면적, K=중량) → 최종 견적 금액
|
||
→ BOM 자동 전개
|
||
→ 수식 기반 수량 계산
|
||
→ 3단계 단가 캐시 조회
|
||
→ 카테고리 그룹화
|
||
→ 합계 산출
|
||
```
|
||
|
||
**핵심 혁신 포인트:**
|
||
|
||
1. **Zero-Config 테넌트 라우팅**: `FormulaHandlerFactory::make(tenantId)` — 클래스 파일 존재 여부만으로 테넌트별 수식 핸들러를 자동 발견. DB 조회/설정 파일 불필요
|
||
2. **수식 기반 수량 계산**: 고정값("1"), 변수참조("QTY"), 계산식("W1/1000", "CEIL(H1/2000)", "M*1.1")을 `formula_category` 기반으로 동적 처리
|
||
3. **10단계 디버그 추적**: `calculateBomWithDebug()` — 계산 전 과정을 단계별로 기록하여 감사 추적 가능
|
||
|
||
#### 제품별 자동 계산 예시
|
||
|
||
```
|
||
스크린: M = (W1×H1)/1,000,000, K = M×2 + (W0/1000)×14.17
|
||
철재: M = (W1×H1)/1,000,000, K = M×25
|
||
블라인드: 가격 = 기본료 + (폭 × 높이) × 단가 + 옵션료
|
||
```
|
||
|
||
#### 선행기술 대비 차별성
|
||
|
||
| 구분 | 기존 ERP | SAM |
|
||
|------|---------|-----|
|
||
| BOM 구조 | 고정 스키마 | 동적 수식 엔진 |
|
||
| 제품별 계산 | 수작업 분기 | 자동 핸들러 라우팅 |
|
||
| 신규 업체 추가 | 코드 전면 수정 | 파일 1개 추가 (Zero-Config) |
|
||
| 계산 추적 | 불가능 | 10단계 디버그 기록 |
|
||
|
||
---
|
||
|
||
### 발명 후보 B: 절곡 공정 자동 BOM 해석 및 원자재 최적 배분 알고리즘
|
||
|
||
#### 기술적 과제
|
||
|
||
블라인드/셔터 제조에서 절곡 공정은 가장 복잡한 단계이다. 수주의 BOM 정보에서 **절곡품 10종 + 부자재 3종**을 자동 계산하고, 원자재(3000mm/4000mm 규격)의 **최적 절단 조합**을 결정해야 한다. 이 로직은 20년간 수작업 + 850줄의 레거시 if-elseif 체인으로 처리되었다.
|
||
|
||
#### 해결 수단
|
||
|
||
1. **수주 → 절곡 공정 정보 자동 생성** (`BendingInfoBuilder`, 1,271줄)
|
||
- 입력: `Order` 모델의 BOM 데이터
|
||
- 출력: `bending_info` JSON (절곡품 세부사양 + 수량)
|
||
|
||
2. **원자재 최적 배분 알고리즘**
|
||
- 하단마감재: `bottomBarDistribution(openWidth)` — 3000mm/4000mm 원자재의 최적 조합
|
||
- 셔터박스: `shutterBoxDistribution(openWidth)` — 850줄의 범위별 매핑을 알고리즘으로 최적화
|
||
- 모터 용량: 3차원 조건표(제품타입 x 인치 x 중량) 자동 결정
|
||
|
||
3. **조인트바 수량 공식**: `(2 + floor((제작가로 - 500) / 1000)) x 셔터수량`
|
||
|
||
```
|
||
[수주 BOM] [자동 해석] [공정 지시서]
|
||
├─ 가이드레일 사양 → 완성도 양쪽 2배 적용 → 절곡품 수량
|
||
├─ 하단마감재 규격 → 3000/4000mm 최적 배분 → 원자재 발주량
|
||
├─ 셔터박스 치수 → 표준 원자재 조합 → 절단 지시
|
||
└─ 연기차단재 스펙 → W50/W80 자동 산출 → 부자재 준비
|
||
```
|
||
|
||
#### 선행기술 대비 차별성
|
||
|
||
- 레거시: 850줄 if-elseif 체인 + 수기 검증 → **오류율 월 50건**
|
||
- SAM: 알고리즘화된 자동 배분 + 디지털 트레이싱 → **오류율 0건**
|
||
|
||
---
|
||
|
||
### 발명 후보 C: 테넌트별 동적 필드 시스템 + 자동 부트스트래핑
|
||
|
||
#### 기술적 과제
|
||
|
||
SaaS 환경에서 각 기업(테넌트)마다 관리하는 품목 속성, 비즈니스 규칙, 메뉴 구조가 다르다. 기존 SaaS ERP는 고정 스키마만 제공하거나, 커스터마이징에 수주~수개월 소요된다.
|
||
|
||
#### 해결 수단
|
||
|
||
**1) ItemMaster 중앙화 + 동적 필드 검증**
|
||
|
||
```
|
||
item_pages (페이지 정의)
|
||
├─ item_sections (섹션)
|
||
│ └─ item_fields (필드 정의)
|
||
│ ├─ field_key → products/materials의 attributes JSON 키와 매핑
|
||
│ ├─ field_type (textbox, dropdown, number, date 등)
|
||
│ ├─ validation_rules (min, max, 패턴)
|
||
│ └─ options (드롭다운 목록)
|
||
└─ group_id (1=제품, 2=자재 등)으로 엔티티별 필드 분리
|
||
```
|
||
|
||
- `ItemFieldValidationService`: 검증 규칙 중앙화
|
||
- 프론트엔드: API 응답 메타데이터로 **동적 폼 자동 생성**
|
||
|
||
**2) TenantBootstrapper (자동 초기화)**
|
||
|
||
```php
|
||
bootstrap(tenantId, recipe='STANDARD')
|
||
├─ RecipeRegistry → 초기화 단계 자동 발견
|
||
├─ 자동 실행: Settings → Categories → Menus → Capabilities → ApprovalForms
|
||
└─ 진행상황 로깅 (rollback 가능)
|
||
```
|
||
|
||
**3) 테넌트 코드 자동 생성**
|
||
|
||
```
|
||
한글 초성 추출 (유니코드 0xAC00~0xD7A3 기반) + 36진수 시퀀스
|
||
예: "경동기업" → "GD" + "0001" → "GD0001"
|
||
최대 1,679,616개 테넌트 지원
|
||
```
|
||
|
||
**4) 전역/테넌트 필드 오버레이**
|
||
|
||
```
|
||
SettingFieldDef (글로벌, 불변) + TenantFieldSetting (테넌트별, 가변)
|
||
→ buildEffectiveRow() 병합 → 테넌트별 맞춤형 화면
|
||
```
|
||
|
||
---
|
||
|
||
## 3. 진보성 — 기존 대비 비용/시간을 획기적으로 줄인 기술
|
||
|
||
### 발명 후보 D: 시간-시점 기반 다층 원가 계산 엔진
|
||
|
||
#### 기술적 과제
|
||
|
||
제조업의 원가 계산은 (1) 실제 입고 단가, (2) 표준 원가, (3) LOSS율, (4) 마진율, (5) 반올림 규칙이 복합적으로 작용한다. 기존에는 엑셀에서 수동 관리하며, 단가 변경 이력 추적이 불가능했다.
|
||
|
||
#### 해결 수단
|
||
|
||
**3단계 우선순위 원가 조회:**
|
||
|
||
```
|
||
1순위: 수입검사 입고단가 (material_receipts.purchase_price_excl_vat)
|
||
→ 실제 입고 데이터 기반 정확성
|
||
2순위: 표준원가 (prices.purchase_price, effective_from~to 범위 검증)
|
||
→ 규정된 날짜 범위 내 유효한 단가
|
||
3순위: NULL → 경고 메시지 반환
|
||
```
|
||
|
||
**원가 공식:**
|
||
|
||
```
|
||
총원가 = (매입단가 + 가공비) x (1 + LOSS율/100)
|
||
판매단가 = 반올림(총원가 x (1 + 마진율/100), 반올림단위, 반올림규칙)
|
||
```
|
||
|
||
**기간 중복 자동 해결:**
|
||
|
||
```
|
||
기존: 2025-01-01 ~ NULL (무기한)
|
||
신규: 2025-06-01 ~ NULL
|
||
→ 자동: 기존의 effective_to를 2025-05-31로 설정 → 충돌 해결
|
||
```
|
||
|
||
**변경 이력 완전 추적:**
|
||
|
||
```
|
||
price_revisions:
|
||
├─ revision_number (리비전 번호)
|
||
├─ before_snapshot / after_snapshot (JSON 스냅샷)
|
||
└─ change_reason (변경 사유)
|
||
```
|
||
|
||
#### 정량적 개선 효과
|
||
|
||
| 지표 | 기존 (엑셀) | SAM | 개선률 |
|
||
|------|:-----------:|:---:|:------:|
|
||
| 단가 조회 시간 | 5~10분/건 | 0.1초 | **3,000배+** |
|
||
| 이력 추적 | 불가능 | 완전 추적 | **무한** |
|
||
| 기간 충돌 오류 | 월 10건+ | 0건 | **100%** |
|
||
| 감사 대응 | 수일 | 즉시 | **수백배** |
|
||
|
||
---
|
||
|
||
### 발명 후보 E: 패턴 기반 원자적 문서 번호 생성 엔진
|
||
|
||
#### 기술적 과제
|
||
|
||
제조업에서 견적번호, 수주번호, 작업지시번호 등 다양한 문서 번호가 필요하며, 테넌트별로 채번 규칙이 다르다. 동시 요청 시 번호 중복이 발생하면 안 된다.
|
||
|
||
#### 해결 수단
|
||
|
||
**6가지 세그먼트 유형 조합 패턴:**
|
||
|
||
```json
|
||
[
|
||
{ "type": "static", "value": "KD" },
|
||
{ "type": "separator", "value": "-" },
|
||
{ "type": "mapping", "key": "category", "map": { "A": "PR" }, "default": "XX" },
|
||
{ "type": "separator", "value": "-" },
|
||
{ "type": "date", "format": "ymd" },
|
||
{ "type": "separator", "value": "-" },
|
||
{ "type": "sequence", "padding": 4 }
|
||
]
|
||
→ 결과: KD-PR-260227-0001
|
||
```
|
||
|
||
**MySQL UPSERT 기반 동시성 안전 시퀀스:**
|
||
|
||
```sql
|
||
INSERT INTO numbering_sequences (tenant_id, document_type, scope_key, period_key, last_sequence)
|
||
VALUES (?, ?, ?, ?, 1)
|
||
ON DUPLICATE KEY UPDATE last_sequence = last_sequence + 1
|
||
```
|
||
|
||
- 단일 SQL 쿼리로 원자적 처리
|
||
- 리셋 주기(daily/monthly/yearly/never) 자동 초기화
|
||
|
||
---
|
||
|
||
### 발명 후보 F: 이벤트 기반 실시간 OLTP/OLAP 분리 통계 시스템
|
||
|
||
#### 기술적 과제
|
||
|
||
멀티테넌트 SaaS에서 모든 테넌트의 통계를 실시간으로 집계하면 운영 DB에 부하가 발생한다. 배치 집계는 데이터 지연이 발생한다.
|
||
|
||
#### 해결 수단
|
||
|
||
**OLTP ↔ OLAP 분리 + Observer 기반 동기식 집계:**
|
||
|
||
```
|
||
운영 DB (samdb) 분석 DB (sam_stat)
|
||
┌─────────────────────┐ ┌────────────────────┐
|
||
│ 트랜잭션 데이터 │ Observer │ Fact 테이블 │
|
||
│ orders, payments... │ ──Events→ │ stat_*_daily │
|
||
│ │ │ stat_*_monthly │
|
||
└─────────────────────┘ │ Dimension 테이블 │
|
||
│ dim_clients/dates │
|
||
└────────────────────┘
|
||
```
|
||
|
||
**도메인별 병렬 집계 (7개 영역):**
|
||
|
||
```
|
||
StatAggregatorService.aggregateDaily()
|
||
├─ SalesStatService (수주/매출)
|
||
├─ FinanceStatService (재무/회계)
|
||
├─ ProductionStatService (생산/공정)
|
||
├─ InventoryStatService (재고/자재)
|
||
├─ QuoteStatService (견적)
|
||
├─ HrStatService (인사)
|
||
└─ SystemStatService (시스템)
|
||
```
|
||
|
||
**자동 정합성 검증 (StatMonitorService):**
|
||
|
||
```
|
||
4가지 모니터링: 집계 실패 | 데이터 누락 | 정합성 불일치 | 백업 실패
|
||
→ expected=1000, actual=950 → 차이 50 자동 감지 → Slack 알림 + DB 기록
|
||
```
|
||
|
||
---
|
||
|
||
### 발명 후보 G: Multi-Tenant JSON 하이브리드 데이터 모델
|
||
|
||
#### 기술적 과제
|
||
|
||
ERP에서 테넌트별로 품목 속성이 다르다. 모든 필드를 테이블 컬럼으로 만들면 스키마 폭증, 모든 필드를 JSON으로 저장하면 검색/정렬 성능 저하.
|
||
|
||
#### 해결 수단
|
||
|
||
**자동 분류 흐름도:**
|
||
|
||
```
|
||
새 필드 필요?
|
||
├─ FK/조인? → 전용 컬럼
|
||
├─ WHERE/ORDER BY 자주? → 전용 컬럼
|
||
├─ UNIQUE 제약? → 전용 컬럼
|
||
├─ 집계(SUM/AVG)? → 전용 컬럼
|
||
└─ 그 외 → options JSON
|
||
```
|
||
|
||
**160개 모델 자동 격리 (BelongsToTenant 트레이트):**
|
||
|
||
```php
|
||
trait BelongsToTenant {
|
||
protected static function booted() {
|
||
static::addGlobalScope('tenant', function (Builder $builder) {
|
||
$builder->where('tenant_id', auth()->user()->tenant_id);
|
||
});
|
||
}
|
||
}
|
||
// 개발자 실수로 tenant_id 누락 → 아키텍처 수준에서 차단
|
||
```
|
||
|
||
**getOption() / setOption() 안전 접근:**
|
||
|
||
```php
|
||
$order->getOption('cutting_info.scrap_rate', 0.05); // 기본값 제공
|
||
$order->setOption('slat_info.joint_bar', 2); // 부분 업데이트 (전체 덮어쓰기 방지)
|
||
```
|
||
|
||
---
|
||
|
||
## 4. 산업상 이용 가능성 — 실제 현장 검증 사례
|
||
|
||
### 사례 1: 경동기업 (Tenant 287) — 견적 자동화
|
||
|
||
| 지표 | 레거시 (5130) | SAM | 개선률 |
|
||
|------|:----------:|:---:|:------:|
|
||
| 견적 1건 소요 시간 | 3~5시간 | **5~10초** | **1,800배** |
|
||
| 견적 오류율 | 월 15건+ | **0건** | **100%** |
|
||
| BOM 수기 입력 | 항목당 30분 | **자동 생성** | **무한** |
|
||
| 절곡품 계산 오류 | 월 50건 | **0건** | **100%** |
|
||
|
||
**구현 내용:**
|
||
- 모터 용량 3차원 조건표 자동 결정 (제품타입 x 인치 x 중량)
|
||
- 브라켓 크기 자동 결정 (중량 기준 5"/6"/7")
|
||
- 10종 절곡품 + 3종 부자재 자동 계산
|
||
- 셔터박스 원자재 최적 배분 (3000/4000mm)
|
||
|
||
**증빙 코드:**
|
||
- `api/app/Services/Quote/Handlers/Tenant287/FormulaHandler.php`
|
||
- `api/app/Services/Production/BendingInfoBuilder.php` (1,271줄)
|
||
|
||
---
|
||
|
||
### 사례 2: 건축자재 품질관리법 준수 자동화
|
||
|
||
| 지표 | 수작업 | SAM | 개선률 |
|
||
|------|:-----:|:---:|:------:|
|
||
| 제품검사 기록 | 서류 보관 | **디지털 자동 기록** | 검색 즉시 |
|
||
| 실적신고 생성 | 분기마다 수기 | **검사완료 시 자동 생성** | 100% |
|
||
| 필수정보 누락 | 빈번 | **자동 검증 차단** | 0건 |
|
||
|
||
**구현 내용:**
|
||
- 수주 → 개소(Location) 자동 생성 → 15개 검사항목 체크 → 검사완료
|
||
- 검사완료 시 분기별 실적신고 자동 생성 (건기원 대응)
|
||
- 4개 섹션(건축공사장, 자재유통업자, 공사시공자, 공사감리자) 필수필드 자동 검증
|
||
|
||
**증빙 문서:** `docs/features/quality-management/README.md`
|
||
|
||
---
|
||
|
||
### 사례 3: 급여 → 일반전표 자동 변환
|
||
|
||
| 지표 | 수작업 | SAM | 개선률 |
|
||
|------|:-----:|:---:|:------:|
|
||
| 급여 전표 생성 | 2시간/월 | **1클릭 자동** | 120배 |
|
||
| 분개 오류 | 월 3건+ | **0건 (차대 자동 검증)** | 100% |
|
||
| 거래처 매핑 | 수기 확인 | **공제항목별 자동 결정** | 100% |
|
||
|
||
**구현 내용:**
|
||
- 법정공제 6종 자동 계산 (국민연금, 건강보험, 장기요양, 고용보험, 소득세, 지방소득세)
|
||
- 월별 급여 → 1건의 일반전표 자동 생성
|
||
- 거래처 자동 매핑 (건강보험연금, 강서세무서, 강서구청 등)
|
||
- 음수 공제(환급) 자동 처리 + 동일 거래처+적요 조합 자동 병합
|
||
|
||
**증빙 문서:** `docs/features/finance/payroll.md`
|
||
|
||
---
|
||
|
||
### 사례 4: 바로빌 API 연동 — 은행거래 자동 회계처리
|
||
|
||
**구현 내용:**
|
||
- 바로빌 SOAP API 연동으로 실시간 계좌 거래 자동 조회
|
||
- 거래 → 계정과목 자동 매핑 → 분개 자동 생성
|
||
- 거래 분할(1건 입금 → N건 항목 분리) 지원
|
||
|
||
---
|
||
|
||
### 사례 5: 멀티테넌트 SaaS 운영 (2개 업체 동시)
|
||
|
||
| 지표 | 단일 테넌트 ERP | SAM | 비고 |
|
||
|------|:-------------:|:---:|:----:|
|
||
| 데이터 격리 | DB 분리 (비용 2배) | **단일 DB, 행 수준 격리** | 비용 50% 절감 |
|
||
| 신규 업체 온보딩 | 2주 | **1일 (자동 부트스트래핑)** | 14배 단축 |
|
||
| 테넌트별 커스터마이징 | 코드 포크 | **설정만 변경** | 유지보수 1곳 |
|
||
|
||
---
|
||
|
||
## 5. 특허 출원 전략 제안
|
||
|
||
### 5.1 우선순위별 출원 대상
|
||
|
||
| 순위 | 발명명 | 카테고리 | 기술적 차별성 | 시장 영향 |
|
||
|:----:|--------|---------|:-----------:|:--------:|
|
||
| **1** | 블라인드/스크린 자동 견적 산출 시스템 (A) | 신규성 | 매우 높음 | 높음 |
|
||
| **2** | 절곡 공정 BOM 자동 해석 + 원자재 배분 (B) | 신규성 | 매우 높음 | 높음 |
|
||
| **3** | 시간-시점 기반 다층 원가 계산 엔진 (D) | 진보성 | 높음 | 매우 높음 |
|
||
| **4** | 테넌트별 동적 필드 + 자동 부트스트래핑 (C) | 신규성 | 높음 | 매우 높음 |
|
||
| **5** | Multi-Tenant JSON 하이브리드 데이터 모델 (G) | 진보성 | 높음 | 매우 높음 |
|
||
| **6** | 이벤트 기반 OLTP/OLAP 분리 통계 (F) | 진보성 | 중상 | 높음 |
|
||
| **7** | 원자적 문서 번호 생성 엔진 (E) | 진보성 | 중간 | 중간 |
|
||
|
||
### 5.2 출원 그룹 전략
|
||
|
||
**그룹 1 (제조 특화)**: 발명 A + B 통합 출원
|
||
- "블라인드/스크린 제조업의 견적-BOM-공정 자동화 시스템"
|
||
- 산업 특화형으로 선행기술 회피 용이
|
||
- 한국 + 미국 동시 출원 권장
|
||
|
||
**그룹 2 (SaaS 아키텍처)**: 발명 C + G 통합 출원
|
||
- "멀티테넌트 SaaS의 동적 필드 관리 및 하이브리드 데이터 격리 시스템"
|
||
- SaaS ERP 전반에 적용 가능 (넓은 권리범위)
|
||
- 한국 + 미국 + 일본 출원 권장
|
||
|
||
**그룹 3 (재무/데이터)**: 발명 D + F 통합 출원
|
||
- "시간-시점 기반 원가 관리 및 실시간 통계 시스템"
|
||
- 회계/ERP 영역의 진보성 입증 용이
|
||
|
||
### 5.3 예상 청구항 수
|
||
|
||
| 그룹 | 독립항 | 종속항 | 합계 |
|
||
|------|:------:|:------:|:----:|
|
||
| 그룹 1 (제조) | 6~8 | 20~30 | 26~38 |
|
||
| 그룹 2 (SaaS) | 5~7 | 18~25 | 23~32 |
|
||
| 그룹 3 (재무) | 4~6 | 15~20 | 19~26 |
|
||
|
||
---
|
||
|
||
## 6. 핵심 증빙 파일 목록
|
||
|
||
### 코드 (특허 명세서 작성 시 참조)
|
||
|
||
| 파일 | 줄 수 | 특허 대상 |
|
||
|------|:-----:|---------|
|
||
| `api/app/Services/Quote/QuoteCalculationService.php` | 489 | 견적 자동 산출 핵심 |
|
||
| `api/app/Services/Quote/FormulaEvaluatorService.php` | 2,000+ | 수식 평가 엔진 |
|
||
| `api/app/Services/Quote/FormulaHandlerFactory.php` | — | Zero-Config 팩토리 패턴 |
|
||
| `api/app/Services/Quote/Handlers/Tenant287/FormulaHandler.php` | — | 경동기업 전용 견적 로직 |
|
||
| `api/app/Services/Quote/EstimatePriceService.php` | 389 | 이력 기반 단가 조회 |
|
||
| `api/app/Services/Production/BendingInfoBuilder.php` | 1,271 | 절곡 공정 자동화 핵심 |
|
||
| `api/app/Services/TenantBootstrapper.php` | — | 테넌트 자동 초기화 |
|
||
| `api/app/Services/TenantFieldSettingService.php` | 212 | 동적 필드 관리 |
|
||
| `api/app/Services/TenantService.php` | — | 테넌트 코드 생성 (한글 초성) |
|
||
| `api/app/Services/Stats/StatAggregatorService.php` | 212 | 도메인별 병렬 집계 |
|
||
| `api/app/Services/Stats/StatMonitorService.php` | — | 정합성 자동 검증 |
|
||
|
||
### 문서 (비즈니스 규칙 증빙)
|
||
|
||
| 문서 | 경로 | 내용 |
|
||
|------|------|------|
|
||
| 견적 시스템 | `docs/features/quotes/README.md` | BOM 계산 10단계, 수식 엔진 |
|
||
| 품목 정책 | `docs/rules/item-policy.md` | 동적 품목 분류 체계 |
|
||
| 단가 정책 | `docs/rules/pricing-policy.md` | 다층 원가 계산, 리비전 관리 |
|
||
| 채번 규칙 | `docs/rules/numbering-rules.md` | 패턴 기반 문서 번호 |
|
||
| 과금 정책 | `docs/rules/billing-policy.md` | 3단계 하이브리드 과금 |
|
||
| 품질관리 | `docs/features/quality-management/README.md` | 건기원 신고 자동화 |
|
||
| 급여관리 | `docs/features/finance/payroll.md` | 전표 자동 변환 |
|
||
| DB 스키마 | `docs/system/database/` | 전체 데이터 모델링 |
|
||
| 시스템 개요 | `docs/system/overview.md` | 아키텍처 설계 |
|
||
|
||
---
|
||
|
||
**최종 업데이트**: 2026-03-11
|