Files
factoryOps-v2/planning/spifox-inspection-analysis.md
Johngreen ab2a3e35b2 feat: Phase 0-2 complete — auth, machines, equipment parts with full CRUD
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>
2026-02-10 12:05:22 +09:00

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) 및 물류 자동화 → 자율형 공장"

구체적으로:

  1. 디지털 트윈 기반 생산계획 최적화 — What-if 시뮬레이션으로 150종 반제품/500종 완제품의 우선순위 및 설비 할당
  2. AI 금형 마모 예측 — LSTM 시계열 예측, 정확도 95% 이상 → 고장 전 부품 교체
  3. AI 비전 품질 전수검사 — 머신비전 30대→80대 확장, CNN 결함 감지, 불량률 1.51%→1.00%
  4. 자율형 공장 — 현 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 현재 문제점 (사업계획서 기준)

  1. 생산계획: 단순 모니터링 수준, 시뮬레이션 없음, 긴급 주문 대응 부족
  2. 품질관리: 자동검사 범위 16%, 숙련공 경험 의존, 품질-공정 데이터 연계 미흡
  3. 설비관리: 금형 마모 사전 예측 없음 → 갑작스러운 품질 문제 및 라인 정지

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)

  • 임계값 도달 시 알람
  • 부품 교체 이력 추적 (언제, 누가, 누적값 얼마에서)
  • 검사 결과 이력 조회 (설비별, 부품별, 기간별)

핵심 설계 원칙

  1. 기준정보가 먼저 → 그 다음에 목표에 따라 테이블이 생성됨
  2. 진행 중인 검사는 반드시 저장 (화면 이탈 시 초기화 금지)
  3. 목표는 두 종류:
    • 데이터 목표: "부품 고장 전 교체" 같은 실질적 목표
    • UX 목표: "터치 두 번 만에 완료", "화면 들락날락 금지" 같은 사용성 목표
  4. 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 상세 (기준정보 + 설비검사 세션) — 최우선

백엔드

  1. EquipmentPart 모델 + CRUD API

    • 설비별 장착 부품 등록/수정/삭제
    • 재고 Part와 연결 (optional)
    • 수명 관리 설정 (lifecycle_type, lifecycle_limit)
  2. InspectionTemplate + InspectionTemplateItem 모델 + CRUD API

    • 설비검사/품질검사 공용 템플릿
    • 검사 주기(scope) 설정
    • 항목별: data_type, spec_min/max, 부품연결, 데이터소스
  3. InspectionSession 모델 + API

    • 진행 중 저장 (partial_results JSON)
    • 자동저장 엔드포인트 (debounced)
    • 세션 완료 → 최종 결과 생성

프론트엔드

  1. 기준정보 관리 화면

    • 설비 선택 → 부품 관리 탭
    • 검사 템플릿 편집기 (항목 추가/삭제/순서변경)
    • 주기 설정 UI
  2. 검사 실행 화면 (모바일 대응)

    • 템플릿 기반 체크리스트 렌더링
    • 자동저장 (2초 debounce)
    • 화면 이탈 시 경고 + 자동 저장

P2 상세 (카운터 + 알람) — 핵심 가치

백엔드

  1. PartCounter 모델 + 갱신 서비스

    • PLC 데이터 수신 시 자동 갱신 (기존 diecasting ingestion 확장)
    • 생산실적 입력 시 카운터 증가
    • lifecycle_pct 자동 계산
  2. PartReplacementLog 모델 + 교체 API

    • 교체 시 카운터 리셋
    • 교체 시점 스냅샷 저장
  3. InspectionAlarm 모델 + 알람 서비스

    • 부품 수명 초과 알람 (part_lifecycle)
    • 정기검사 미실시 알람 (inspection_overdue)
    • 스펙 이탈 알람 (spec_violation)

프론트엔드

  1. 부품 수명 현황 대시보드
    • 설비별 부품 수명 게이지 (%)
    • 알람 목록 + 확인(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. 다음 단계 (즉시 실행)

  1. 스피폭스에 자료 요청 (설비목록, PLC태그, 부품목록, 검사지, UX요구)
  2. 자료 수집 후 기준정보 테이블 확정 및 상세 ERD 작성
  3. P1 백엔드 개발 착수 (EquipmentPart, InspectionTemplate, InspectionSession)
  4. P1 프론트엔드 설계 (화면 와이어프레임, 모바일 대응)