Multi-tenant factory inspection system (SpiFox, Enkid, Alpet): - FastAPI backend with JWT auth, PostgreSQL (asyncpg) - Next.js 16 frontend with App Router, SWR data fetching - Machines CRUD with equipment parts management - Part lifecycle tracking (hours/count/date) with counters - Partial unique index for soft-delete support - 24 pytest tests passing, E2E verified Co-Authored-By: Claude Opus 4 <noreply@anthropic.com>
15 KiB
스피폭스 설비검사/품질검사 종합 분석 및 개발계획
작성일: 2026-02-09 참고자료: 개발회의.md (멘토 회의), 스피폭스 사업계획서 v2, factoryOps 코드베이스, Oracle 아키텍처 컨설팅
1. 스피폭스 최종 목표
1.1 회사 개요
| 항목 | 내용 |
|---|---|
| 기업명 | (주)스피폭스 (Speefox CO., LTD.) |
| 설립 | 1985년 (약 40년 업력) |
| 주력 제품 | 알루미늄 전해 콘덴서용 케이스 |
| 시장 점유율 | SMD 전해 콘덴서 LIQUID TYPE 세계 시장 50% 이상 |
| 주요 거래선 | 케미콘, 니치콘, 파나소닉 등 글로벌 기업 |
| 특이사항 | 스크랩 재활용 '파파야시스템'으로 자원순환율 100% 달성 |
1.2 최종 비전
"시뮬레이션 기반 최적 공급망 관리(SCM) 및 물류 자동화 → 자율형 공장"
구체적으로:
- 디지털 트윈 기반 생산계획 최적화 — What-if 시뮬레이션으로 150종 반제품/500종 완제품의 우선순위 및 설비 할당
- AI 금형 마모 예측 — LSTM 시계열 예측, 정확도 95% 이상 → 고장 전 부품 교체
- AI 비전 품질 전수검사 — 머신비전 30대→80대 확장, CNN 결함 감지, 불량률 1.51%→1.00%
- 자율형 공장 — 현 2단계(관제) → 3단계(모델링/시뮬레이션 디지털 트윈)
1.3 정량 KPI 목표
| KPI | 현재 | 목표 | 개선율 |
|---|---|---|---|
| 시간당 생산량 | 1,560 kpcs/h | 1,700 kpcs/h | +9% |
| 재공재고량 | 79,983 kpcs | 72,000 kpcs | -10% |
| 완제품 불량률 | 1.51% | 1.00% | -34% |
| 생산계획 시뮬레이션 정확도 | 0% | 85% | 신규 |
| 디지털트윈 리프레시 | 0 fps | 20 fps | 신규 |
| AI 품질 이상감지 정밀도 | 0% | 95% | 신규 |
1.4 주요 설비 현황
| 설비 유형 | 대수 | 비고 |
|---|---|---|
| 완제품 프레스 | 186대 | 핵심 생산 설비 |
| 반제품 프레스 | 30대 | |
| 머신비전 검사장치 | 30대 (→80대) | 현재 전체의 16%, 확대 예정 |
| 건조설비 | 8대 | |
| 탈유기 | 6대 | |
| 세척기 | 8대 | |
| 열처리기 | 4대 | |
| 자동창고 | WMS 연동 |
1.5 현재 문제점 (사업계획서 기준)
- 생산계획: 단순 모니터링 수준, 시뮬레이션 없음, 긴급 주문 대응 부족
- 품질관리: 자동검사 범위 16%, 숙련공 경험 의존, 품질-공정 데이터 연계 미흡
- 설비관리: 금형 마모 사전 예측 없음 → 갑작스러운 품질 문제 및 라인 정지
2. 개발 회의 핵심 분석
2.1 선배 개발자의 아키텍처 지침
핵심 원리: 설비검사와 품질검사는 동일한 원리, 대상만 다르다
- 설비검사 → 대상은 설비(Equipment)
- 품질검사 → 대상은 생산품(Product)
Layer 1 — 기준정보 (Base Information)
설비/생산품 기본정보
└── 관리 영역 (Management Area)
├── 검사 주기 설정: 1일 / 주간 / 월간 / 연간 / 수시
├── 검사 항목 (사용자 자유 입력)
│ ├── 항목명, 카테고리
│ ├── 값 유형: 수치 / 날짜 / 텍스트 / 선택
│ └── 스펙 범위 (상한/하한)
└── 부품 연결 (Parts Linkage)
├── 수명 관리 방식: 시간(hours) / 타발수(count) / 날짜(date)
├── 수명 한계값
└── 알람 조건 (e.g. 9,000개 도달 시 알람)
Layer 2 — 운영 데이터 (Operational Data)
- 누적 카운터: 설비별 부품별 누적값 관리, 부품 교체 시 리셋
- 데이터 소스:
- PLC 인터페이스 (직접): 타발수, 온도, 압력 등
- 생산 실적 (간접): 작업지시 → 실적 등록 → 카운터 증가
- 핵심: 설비 자체 데이터만 쓸지, 생산 데이터와 연결할지 구분 필요
Layer 3 — 액션/이력 (Actions & History)
- 임계값 도달 시 알람
- 부품 교체 이력 추적 (언제, 누가, 누적값 얼마에서)
- 검사 결과 이력 조회 (설비별, 부품별, 기간별)
핵심 설계 원칙
- 기준정보가 먼저 → 그 다음에 목표에 따라 테이블이 생성됨
- 진행 중인 검사는 반드시 저장 (화면 이탈 시 초기화 금지)
- 목표는 두 종류:
- 데이터 목표: "부품 고장 전 교체" 같은 실질적 목표
- UX 목표: "터치 두 번 만에 완료", "화면 들락날락 금지" 같은 사용성 목표
- UX 목표를 못 지키면 시스템 사용률 90% 실패 (실사용 요구가 핵심)
2.2 선배가 요청한 사전 준비 리스트
- 스피폭스 설비 목록 전체 뽑기
- 설비별 인터페이스/수집 데이터 종류 정리
- 부품 종류 및 검사 항목 리스트 확보
- 스피폭스의 최종 목표 리스트 뽑기 → (이건 사업계획서에서 추출 완료)
- 위 자료로 기준정보 테이블 설계
- 화면 구성은 편의성 기준으로 설계
3. 현재 코드베이스 Gap 분석
3.1 이미 구현된 것 (FactoryOps)
| 기능 | 상태 | 위치 |
|---|---|---|
| 설비(Machine) CRUD | ✅ 완료 | models.py, equipment_sync.py |
| 검사 계획(InspectionPlan) | ✅ 완료 | api/inspection.py |
| 검사 기록(Inspection) | ✅ 완료 | api/inspection.py |
| 체크리스트 (JSON 기반) | ✅ 완료 | InspectionPlan.checklist, Inspection.checklist_results |
| 검사 분석 (OK/NG 비율) | ✅ 완료 | inspection_analytics |
| PLC 데이터 수신/저장 | ✅ 완료 | DiecastingMachineData, 60+ 파라미터 |
| 건강점수 / 스코어링 | ✅ 완료 | scoring/health_calculator.py |
| 알람 서비스 | ✅ 완료 | alarm/service.py |
| 불량 유형 6가지 | ✅ 완료 | domain/defect_type.py |
| 고장 유형 13가지 | ✅ 완료 | domain/failure_type.py |
| 부품(Part) 재고 관리 | ✅ 완료 | parts, inventory_items |
| PM 예방보전 스케줄 | ✅ 완료 | pm_schedules, pm_work_orders |
| 온톨로지 Knowledge Graph | ✅ 완료 | ontology_edges |
| 프론트엔드 검사 페이지 | ✅ 완료 | /inspections, /inspection-plans, /analytics |
3.2 아직 없는 것 (Gap)
| 기능 | 중요도 | 설명 |
|---|---|---|
| 검사 기준정보 템플릿 | 🔴 최우선 | 설비/생산품별 검사항목 사전 정의 시스템 |
| 설비 부품 관리 (장착 부품) | 🔴 최우선 | 재고 부품이 아닌, 설비에 장착된 부품 인스턴스 |
| 부품 수명 관리 | 🔴 최우선 | 시간/타발수/날짜 기반 수명 추적 |
| 누적 카운터 시스템 | 🔴 최우선 | 부품별 누적값 관리, 교체 시 리셋 |
| 부품 교체 이력 | 🟡 중요 | 교체 시점 스냅샷, 이력 추적 |
| 검사 진행 중 저장 | 🟡 중요 | InspectionSession, partial_results 저장 |
| 품질검사 전용 기능 | 🟡 중요 | 생산품 대상, 로트/샘플 사이즈, AQL |
| 반복 검사 스케줄링 | 🟡 중요 | 일간/주간/월간 자동 생성 |
| 검사 알람 | 🟡 중요 | 부품 수명 초과, 검사 미실시, 스펙 이탈 |
| 품질검사 대시보드 | 🟠 보통 | 설비검사와 분리된 품질 분석 화면 |
| SPC 통계적 공정관리 | 🟠 보통 | 관리도, 파레토, 상관 분석 |
4. 아키텍처 설계 방향
4.1 핵심 원칙: 단일 엔진, 이중 대상
Oracle 컨설팅 결과: 설비검사와 품질검사는 하나의 엔진으로 구현하되,
subject_type구분자로 분리
InspectionTemplate
├── subject_type = 'equipment' → machine_id에 바인딩
└── subject_type = 'product' → product_type_id에 바인딩
이유:
- 90%의 로직이 동일 (템플릿 → 세션 → 결과 → 이력)
- 하나의 코드베이스로 유지보수
- 분석 시 교차 쿼리 용이
- 선배 개발자가 명확히 "같은 원리"라고 언급
4.2 신규 테이블 설계
[Layer 1: 기준정보]
EquipmentPart — 설비에 장착된 부품 인스턴스
InspectionTemplate — 검사 기준정보 템플릿 (설비/품질 공용)
InspectionTemplateItem — 검사 항목 정의 (data_type, spec_min/max, 부품연결, PLC태그)
[Layer 2: 누적 카운터]
PartCounter — 부품별 누적값 (hours/count/date), 교체 시 리셋
PartReplacementLog — 부품 교체 이력 + 교체 시점 스냅샷
[Layer 3: 검사 실행]
InspectionSession — 진행 중 저장 지원, partial_results JSON
[Layer 4: 알람]
InspectionAlarm — 부품수명/검사미실시/스펙이탈 알람
4.3 기존 모델과의 관계
Machine (기존) ←──── EquipmentPart (신규)
│ │
├── InspectionPlan ←── InspectionTemplate (신규, 기존 plan 확장)
│ │ │
│ └── Inspection ←── InspectionSession (신규, 진행중 저장)
│
└── DiecastingMachineData ──→ PartCounter (신규, PLC값으로 카운터 갱신)
Part (기존, 재고) ←── EquipmentPart.part_id (장착 부품 ↔ 재고 부품 연결)
4.4 데이터 흐름
[데이터 소스] [카운터 갱신] [액션]
PLC → DiecastingMachineData ──→ PartCounter 갱신 ──→ 알람 발생
(shotno 증가분) (lifecycle_pct > 알람%)
│
작업지시 → 생산실적 ────────────→ PartCounter 갱신
(ok_qty + ng_qty)
│
부품 교체 ────────────────────→ PartCounter 리셋
+ PartReplacementLog 기록
5. 개발계획 (Phase별)
전체 로드맵 (FactoryOps 범위 기준)
| Phase | 기간 | 내용 | 스피폭스 KPI 연관 |
|---|---|---|---|
| P1 | 1~3개월 | 기준정보 관리 + 설비검사 세션 (진행중 저장) | 기반 |
| P2 | 3~5개월 | 부품 수명 카운터 + PLC 연동 + 알람 | 금형 마모 추적 기반 |
| P3 | 5~7개월 | 품질검사 (같은 엔진, product subject) + 생산실적 연동 | 불량률 1.00% 추적 |
| P4 | 7~10개월 | 반복 스케줄 엔진 + 대시보드 분석 고도화 | OEE 가시성 |
| P5 | 10~14개월 | AI 연동 포인트: 카운터→LSTM 금형예측, 검사이미지→CNN | AI 95% 정확도 |
| P6 | 14~18개월 | 디지털트윈 데이터 피드 + 이력 추적 고도화 | 시뮬레이션 |
| P7 | 18~24개월 | 부품 자동 발주 + 물류 최적화 | 자율화 |
P1 상세 (기준정보 + 설비검사 세션) — 최우선
백엔드
-
EquipmentPart모델 + CRUD API- 설비별 장착 부품 등록/수정/삭제
- 재고 Part와 연결 (optional)
- 수명 관리 설정 (lifecycle_type, lifecycle_limit)
-
InspectionTemplate+InspectionTemplateItem모델 + CRUD API- 설비검사/품질검사 공용 템플릿
- 검사 주기(scope) 설정
- 항목별: data_type, spec_min/max, 부품연결, 데이터소스
-
InspectionSession모델 + API- 진행 중 저장 (
partial_resultsJSON) - 자동저장 엔드포인트 (debounced)
- 세션 완료 → 최종 결과 생성
- 진행 중 저장 (
프론트엔드
-
기준정보 관리 화면
- 설비 선택 → 부품 관리 탭
- 검사 템플릿 편집기 (항목 추가/삭제/순서변경)
- 주기 설정 UI
-
검사 실행 화면 (모바일 대응)
- 템플릿 기반 체크리스트 렌더링
- 자동저장 (2초 debounce)
- 화면 이탈 시 경고 + 자동 저장
P2 상세 (카운터 + 알람) — 핵심 가치
백엔드
-
PartCounter모델 + 갱신 서비스- PLC 데이터 수신 시 자동 갱신 (기존 diecasting ingestion 확장)
- 생산실적 입력 시 카운터 증가
- lifecycle_pct 자동 계산
-
PartReplacementLog모델 + 교체 API- 교체 시 카운터 리셋
- 교체 시점 스냅샷 저장
-
InspectionAlarm모델 + 알람 서비스- 부품 수명 초과 알람 (
part_lifecycle) - 정기검사 미실시 알람 (
inspection_overdue) - 스펙 이탈 알람 (
spec_violation)
- 부품 수명 초과 알람 (
프론트엔드
- 부품 수명 현황 대시보드
- 설비별 부품 수명 게이지 (%)
- 알람 목록 + 확인(acknowledge) 기능
- 부품 교체 이력 타임라인
6. 스피폭스에서 받아야 할 자료
선배 개발자가 지시한 사전 수집 자료:
| # | 자료 | 용도 | 상태 |
|---|---|---|---|
| 1 | 설비 전체 목록 | 기준정보 등록 | ❌ 미확보 |
| 2 | 설비별 수집 데이터 종류 (PLC 태그 리스트) | 인터페이스 설계, 자동 입력 항목 | ❌ 미확보 |
| 3 | 부품 종류 및 규격 | 부품 수명 관리 설정 | ❌ 미확보 |
| 4 | 기존 검사 항목 리스트 (현장 검사지) | 템플릿 초기 데이터 | ❌ 미확보 |
| 5 | 관리 목표 리스트 | 테이블/알람 설계 기준 | ✅ 사업계획서에서 추출 |
| 6 | 현장 작업자 UX 요구 | 화면 구성 기준 | ❌ 미확보 |
[액션 아이템] 1~4번, 6번 자료를 스피폭스에 요청해야 P1 설계를 확정할 수 있음
7. 역할 분담 명확화
| 담당 | 범위 |
|---|---|
| FactoryOps | 설비 데이터 수집/분석, 스코어링, 알람, 예지보전, 설비검사, 품질검사 기준정보 |
| digital-twin-web | 디지털트윈 3D 시각화, AI 노트북, ESG, AAS 표준 |
| digital-twin-gpu | AI 모델 (LSTM 금형예측, CNN 결함감지) |
| MES (별도) | 영업, 구매, 생산실적, 금형관리, 가동률, 작업지시 |
FactoryOps ↔ MES 연동 포인트
- MES의 생산실적 → FactoryOps PartCounter 갱신 (API 연동)
- MES의 작업지시 → FactoryOps 검사 트리거 (품질검사 시점)
- FactoryOps의 알람 → MES 정비 요청 (웹훅)
8. 주의사항 (Oracle 컨설팅 기반)
8.1 카운터 레이스 컨디션
PLC 갱신과 수동 리셋이 동시에 발생할 수 있음. SELECT FOR UPDATE 또는 optimistic locking 필수.
8.2 템플릿 버전 관리
검사 수행 후 템플릿이 변경되어도 기존 이력은 변경 불가. 세션 시작 시 템플릿 스냅샷을 InspectionSession에 저장.
8.3 자동저장 UX
선배 개발자가 강조한 "진행 중 저장" — 필드 변경마다 2초 debounce 자동저장. SWR 낙관적 업데이트 패턴 적용.
8.4 "테이블은 목표에 따라 생성된다"
동적 DDL이 아님. InspectionTemplate + InspectionTemplateItem의 JSON 기반 유연한 구조로 해결. 고객별로 다른 검사항목을 같은 테이블 구조에서 수용.
9. 다음 단계 (즉시 실행)
- 스피폭스에 자료 요청 (설비목록, PLC태그, 부품목록, 검사지, UX요구)
- 자료 수집 후 기준정보 테이블 확정 및 상세 ERD 작성
- P1 백엔드 개발 착수 (EquipmentPart, InspectionTemplate, InspectionSession)
- P1 프론트엔드 설계 (화면 와이어프레임, 모바일 대응)