DESIGN v2.0 2026-03

report_problem Problem

error
이상감지와 조치 사이에 간극이 있다.
현재 FLOPI는 이상을 감지하지만, "왜 발생했는지"와 "뭘 바꿔야 하는지"는 사람이 직접 판단해야 한다. RCA Studio가 있지만 매번 수동 대화가 필요하고, 조치 수준이 "라우팅 변경하세요" 같은 모호한 안내에 그친다.

반도체 FAB에서 요구하는 진단-조치 수준:

현재 수준필요한 수준
"컨베이어 과부하 발생""LINE02-ZONE-C 컨베이어 과부하, 원인: 라우팅 편중"
"라우팅을 변경하세요""ZONE-C→ZONE-D 우회 비율을 20%→50%로 변경"
"LOT 우선순위 조정 필요""LOT-0342~0348 (7건) NORMAL→LOW로 변경"
"PM 일정 검토""EQP-TRACK-02 PM 주기 720h→500h 단축"

visibility Vision

이상감지 → 자동 진단 → 구체적 조치 제안의 완전한 체인을 만든다.

4
새 모듈
N:M
유연한 연결
AI
판단은 AI가
Guard
울타리 안에서
lightbulb
핵심 원칙: "구조화된 자유"
AI에게 판단을 맡기되, 진단 결과 후보와 조치 후보를 미리 정의하여 엉뚱한 진단이나 위험한 조치가 나오지 않도록 울타리를 친다. AI는 후보 중에서 선택하고, 구체적 파라미터 값을 채우고, 근거를 설명한다.

네 모듈의 역할

모듈역할비유
Tool Studio (기존) 데이터를 읽는 도구 (SELECT) 청진기, 혈압계
Action Studio (신규) 진단 결과 관리 + 데이터를 바꾸는 도구 처방전 + 약
Validation Studio (신규) 조치를 검증하는 도구 (DT, 시뮬레이터, 지식 참조) 약 부작용 검사
Playbook Studio (신규) Tool + AI + Action + Validation을 엮는 시나리오 진료 프로토콜

architecture Architecture

┌───────────────────────────────────────────────────────────────┐ │ 이상감지 규칙 │ │ "컨베이어 부하율 > 90%" │ └──────────────┬────────────────────────────────────────────────┘ │ 트리거 (1:N) ▼ ┌───────────────────────────────────────────────────────────────┐ │ Playbook: "물류 병목 진단" │ │ │ │ Collect → Tool Studio 도구로 현황 수집 │ │ Diagnose → AI가 진단 결과 후보 중 선택 + 근거 │ │ Act → 선택된 진단에 연결된 Action 중 선택 + 파라미터 │ │ Validate → Action에 연결된 검증 도구로 사전 검증 │ └──────────────┬────────────────────────────────────────────────┘ │ ▼ ┌───────────────────────────────────────────────────────────────┐ │ 진단 리포트 │ │ │ │ 원인: LINE02-ZONE-C 라우팅 편중 (70% 집중) │ │ 조치: ZONE-C→ZONE-D 우회 비율 20% → 50% │ │ │ │ [승인] [수정] [반려] │ └───────────────────────────────────────────────────────────────┘
info
연결 관계 요약
이상감지 규칙 1:N Playbook  |  Playbook N:M Diagnosis  |  Diagnosis N:M Action  |  Action N:M Validator

biotech Action Studio — Diagnosis (진단 결과)

진단 결과는 Action Studio에서 독립적으로 관리되며, 여러 Playbook에서 재사용할 수 있다.

진단 결과 유형

유형의미후속 조치예시
action_required 조치 필요 연결된 Action 실행 제안 "라우팅 편중", "PM 주기 초과"
monitoring 관찰 필요 Action 없음, 감시 강화 "추세 상승 중이나 임계치 미만"
escalation 에스컬레이션 담당자 알림 "원인 불명, 현장 확인 필요"
false_alarm 가성 이상 이상 자동 해소 "일시적 스파이크, 정상 복귀"
unknown 원인 미상 에스컬레이션 + 추가 조사 "기존 패턴과 불일치"

진단 결과 정의 구조

diagnosis_id:     자동 생성
name:             "라우팅 편중"
type:             action_required
description:      "특정 존에 반송이 집중되어 병목 발생"
category:         "logistics"
actions:          [라우팅 비율 변경, LOT 우선순위 조정]  # N:M 연결
psychology
가성 이상 피드백 루프
가성 이상(false_alarm)이 누적되면 해당 이상감지 규칙의 정확도를 측정할 수 있다. "규칙 X에서 40%가 가성 이상" → 임계치 조정 또는 규칙 재설계 신호.

bolt Action Studio — Action (조치)

Action은 FAB 운영 파라미터를 변경하는 구체적 조치이다. 파라미터 범위, 승인 등급까지 정의하여 AI가 안전한 범위 내에서만 제안할 수 있게 한다.

Action 정의 구조

alt_route
라우팅 비율 변경
MES 반송 라우팅 테이블
action_id:        자동 생성
name:             "라우팅 비율 변경"
target_system:    "MES routing_table"
parameters:
  zone_from:      TEXT   # 출발 존
  zone_to:        TEXT   # 도착 존
  ratio:          INT    # 변경할 비율 (0~100)
constraints:      "같은 zone_from의 ratio 합계 = 100%"
approval_level:   engineer
execution:        "SQL UPDATE / MES API"
current_value_tool: "get_routing_table"  # 현재값 조회 Tool
validators:          [물류 흐름 시뮬레이터]  # Validation Studio 연결
low_priority
LOT 우선순위 조정
MES dispatch_queue
name:             "LOT 우선순위 조정"
target_system:    "MES dispatch_queue"
parameters:
  lot_ids:        TEXT[]  # 대상 LOT 목록
  priority:       ENUM   # HIGH / NORMAL / LOW
constraints:      "납기 24시간 이내 LOT은 LOW 불가"
approval_level:   operator
current_value_tool: "get_lot_queue"
validators:          []  # 검증 불필요 (단순 우선순위 변경)
build
PM 주기 변경
MES equipment_master
name:             "PM 주기 변경"
target_system:    "MES equipment_master"
parameters:
  equipment_id:   TEXT   # 설비 ID
  pm_interval_h:  INT    # PM 주기 (시간), 범위: 100~2000
constraints:      "최소 100시간, 최대 2000시간"
approval_level:   engineer
current_value_tool: "get_equipment_pm_schedule"
validators:          [PM 주기 KB 검증]  # Knowledge Base 참조 검증
verified
안전 장치
AI는 Action의 parameters 범위와 constraints를 벗어나는 값을 제안할 수 없다. approval_level에 따라 자동 실행 또는 승인 대기가 결정된다. current_value_tool로 현재 값을 먼저 조회하여 변경 전후를 명확히 제시한다. validators에 연결된 검증 도구(Validation Studio)로 조치 효과를 사전 검증한다.

menu_book Playbook Studio — Structure

Playbook은 이상감지 규칙에 연결되어, Collect → Diagnose → Act 3단계로 실행된다.

menu_book
Playbook: 물류 병목 진단
이상감지 규칙 "컨베이어 과부하"에 연결
# ── 1. Collect: 어떤 데이터를 수집할지 ──
collect:
  - get_conveyor_load        # 컨베이어 부하율
  - get_vehicle_status       # AGV/OHT 상태
  - get_stocker_status       # 스토커 잔량
  - get_transfer_log         # 최근 30분 반송 로그

# ── 2. Diagnose: 가능한 진단 결과 후보 ──
diagnosis_candidates:
  - "라우팅 편중"             # → Action: 라우팅 비율 변경, LOT 우선순위
  - "AGV 고장"               # → Action: 대체 경로 활성화
  - "스토커 포화"             # → Action: LOT 우선순위 조정
  - "일시적 과부하"           # → 모니터링 (Action 없음)
  - "가성 이상"              # → 이상 자동 해소

# ── 3. AI 역할 ──
ai_instruction: "수집 데이터를 분석하여 위 진단 후보 중 하나를 선택하고,
                  선택 근거를 3줄 이내로 설명하세요."

하나의 이상에 여러 Playbook

같은 이상감지 규칙에 여러 관점의 Playbook을 연결할 수 있다.

이상감지: "컨베이어 과부하" │ ├── Playbook A: 물류 관점 진단 │ Collect: 부하율, AGV, 스토커, 반송로그 │ Diagnose: 라우팅 편중 / AGV 고장 / 스토커 포화 / 가성 이상 │ Act: 라우팅 변경, LOT 우선순위, 대체 경로 │ └── Playbook B: 설비 관점 진단 Collect: 설비 가동률, PM 이력, 알람 이력 Diagnose: PM 지연 / 센서 이상 / 가성 이상 Act: PM 주기 변경, 수리 요청

psychology AI의 역할

AI는 3가지 역할을 수행하되, 모두 정해진 범위 안에서 동작한다.

search
1. 데이터 해석
Collect 단계에서 수집된 데이터를 종합 분석

"컨베이어 부하율 92%, AGV-003 ERROR, 스토커 95% — 이 데이터들이 의미하는 것은?"

fact_check
2. 진단 결과 선택
후보 중에서 고르고, 근거를 설명

"5개 후보 중 '라우팅 편중'을 선택합니다. 근거: ZONE-C 반송 비율 70%, ZONE-D는 30%로 불균형..."

tune
3. Action 파라미터 결정
Action의 파라미터를 구체적 값으로 채움

"라우팅 비율 변경 Action: zone_from=LINE02-ZONE-C, zone_to=LINE04-ZONE-D, ratio=50 (현재 20%)"

AI가 할 수 없는 것

제한이유
후보에 없는 진단 결과 생성검증되지 않은 진단은 위험
등록되지 않은 Action 제안파라미터 범위 / 승인 체계가 없음
파라미터 범위 밖의 값 제안constraints 위반 = 안전 사고 가능
승인 없이 직접 실행반드시 사람의 승인/반려를 거침

Playbook 자동 생성 (AI 어시스턴트)

auto_awesome
AI가 Playbook 초안도 만들어준다
엔지니어가 "컨베이어 과부하 규칙에 Playbook 만들어줘" 라고 하면, AI가 기존 Tool Studio 도구 목록과 Action Studio 항목을 참조하여 Playbook 초안을 생성한다. 엔지니어가 검토 → 수정 → 확정하면 운영에 투입된다.

이미 워크플로우 빌더에서 동일한 AI 생성 패턴이 검증되어 있으므로 재활용 가능.

play_circle Execution Flow

전체 실행 흐름

01 이상감지 규칙 트리거 │ 컨베이어 부하율 92% > 임계치 90% ▼ 02 연결된 Playbook(들) 실행 시작 │ Playbook A: "물류 병목 진단" ▼ 03 Collect: Tool Studio 도구 순차 호출 │ get_conveyor_load(&zone=LINE02-ZONE-C) → 92% │ get_vehicle_status(&zone=LINE02-ZONE-C) → AGV-003 ERROR │ get_stocker_status(&line=LINE02) → STK-01 95% │ get_transfer_log(&minutes=30) → 87건 (LINE02: 61건) ▼ 04 Diagnose: AI에게 수집 결과 + 후보 전달 │ "아래 데이터를 분석하여 진단 후보 중 하나를 선택하세요." │ AI 응답: "라우팅 편중" 선택 │ 근거: "LINE02 반송 비율 70%, AGV 1대 ERROR로 처리량 감소" ▼ 05 Act: 선택된 진단에 연결된 Action 제안 │ Action "라우팅 비율 변경": │ zone_from: LINE02-ZONE-C │ zone_to: LINE04-ZONE-D │ ratio: 20% → 50% ▼ 06 진단 리포트 생성 + 승인 요청 │ 엔지니어에게 알림 → [승인] [수정] [반려] ▼ 07 Validate: Validation Studio 검증 (선택적) │ [물류 흐름 시뮬레이터] 비율 50%로 변경 시 ZONE-C 부하 92%→63% 예측 │ 부작용 체크: "ZONE-D 부하 42%→58% (안전 범위)" → 판정: Safe ▼ 08 승인 시 자동 실행 or 수동 실행 안내

verified_user Validation Studio — 검증 스튜디오

Action이 승인되기 전에 사전 검증을 수행한다. 검증 방법은 독립적으로 관리되며, Action에 N:M으로 연결한다.

science
왜 검증 스튜디오가 필요한가?
AI가 파라미터 범위 안에서 제안했더라도, 실제 적용 시 예상치 못한 연쇄 효과가 발생할 수 있다. 검증 도구를 통해 조치의 효과를 사전에 시뮬레이션하거나, 전문가 지식과 대조하여 안전성을 확인한다.

DT(Digital Twin)는 검증 방법의 한 종류일 뿐이다. 검증은 다양한 형태로 이루어질 수 있다.

검증 방법 유형

유형설명예시
Digital Twin FAB 전체 또는 구간 DT 모델로 시뮬레이션 물류 흐름 DT로 라우팅 변경 영향 예측
Small Simulator 특정 영역에 특화된 소규모 시뮬레이터 스토커 큐잉 시뮬레이터, 열전달 모델
Knowledge Base 전문가 지식/매뉴얼/과거 사례 참조 검증 PM 주기 변경 시 메이커 권장 범위 대조

Validator 정의 구조

hub
물류 흐름 시뮬레이터
Digital Twin 기반 검증
validator_id:     자동 생성
name:             "물류 흐름 시뮬레이터"
type:             digital_twin
description:      "물류 반송 경로/부하율 변경 시 연쇄 효과를 DT로 시뮬레이션"
config:
  model:          "logistics_flow"       # DT 모델명
  simulate_minutes: 30                    # 몇 분 후 예측
  check_metrics:                           # 검증할 지표
    - "conveyor_load_all_zones"
    - "transfer_throughput"
    - "stocker_utilization"
  risk_thresholds:
    caution:       "any zone > 80%"
    risky:         "any zone > 90% OR throughput drop > 20%"
memory
스토커 큐잉 시뮬레이터
Small Simulator 기반 검증
name:             "스토커 큐잉 시뮬레이터"
type:             small_simulator
description:      "LOT 우선순위 변경 시 스토커 대기열 영향을 시뮬레이션"
config:
  endpoint:       "http://localhost:8610/simulate/stocker-queue"
  input_schema:   # 시뮬레이터에 전달할 파라미터
    - "lot_ids"
    - "priority_change"
    - "current_queue_state"
  risk_thresholds:
    caution:       "avg_wait_time > 15min"
    risky:         "avg_wait_time > 30min OR queue_overflow"
auto_stories
PM 주기 KB 검증
Knowledge Base 참조 검증
name:             "PM 주기 KB 검증"
type:             knowledge_base
description:      "PM 주기 변경 시 메이커 매뉴얼/과거 사례와 대조하여 안전성 확인"
config:
  kb_categories:  # 참조할 KB 카테고리
    - "equipment_manual"
    - "pm_history"
  query_template: "{equipment_type} PM 주기 {pm_interval_h}시간 안전 범위"
  ai_instruction: "검색된 지식을 바탕으로 제안된 PM 주기가 메이커 권장 범위 이내인지,
                   과거 동일 변경에서 문제가 없었는지 판단하세요."

검증 흐름

AI 조치 제안 │ "ZONE-C→ZONE-D 우회 비율 20% → 50%" ▼ Action에 연결된 Validator(들) 실행 │ [1] 물류 흐름 시뮬레이터 (DT) │ → 현재 FAB 상태 스냅샷 + 제안 파라미터 → 30분 후 예측 │ [2] (추가 검증이 있다면 순차 실행) ▼ 검증 결과 종합 ├── 직접 효과: ZONE-C 부하 92% → 63% (▼29%p) ├── 연쇄 효과: ZONE-D 부하 42% → 58% (▲16%p) ├── 병목 이동: 없음 (ZONE-D 여유 충분) └── 종합 판정: 안전 / 주의 / 위험 ▼ 검증 결과와 함께 엔지니어에게 승인 요청

검증 결과 판정

판정의미후속
안전 (Safe) 모든 Validator 통과, 연쇄 효과 안전 범위 승인 권고와 함께 리포트 제시
주의 (Caution) 일부 Validator에서 주의 신호 리포트 + 주의사항 명시 후 엔지니어 판단
위험 (Risky) 하나라도 위험 판정 시 자동 승인 차단, 대안 파라미터 재탐색
schedule
검증은 선택적(Optional)
모든 Action에 검증이 필요한 것은 아니다. 영향 범위가 큰 조치(라우팅 변경, PM 주기 변경)에만 Validator를 연결하고, 단순 조치(알림 발송, 티켓 생성)는 검증 없이 바로 승인 프로세스로 진행한다. Action에 Validator가 연결되어 있지 않으면 검증 단계를 건너뛴다.
extension
Validator 확장
새로운 검증 방법이 필요하면 Validation Studio에 등록만 하면 된다. 예: 비용 영향 분석기, 품질 예측 모델, 외부 시스템 API 연동 등. 각 Validator는 독립적이므로 다른 Action에도 재사용 가능하다.

storage Data Model

테이블 설계

테이블역할주요 컬럼
action_diagnoses 진단 결과 정의 diagnosis_id, name, type, description, category
action_items 조치 정의 action_id, name, target_system, parameters(JSON), constraints, approval_level, current_value_tool
validators 검증 도구 정의 validator_id, name, type(digital_twin/small_simulator/knowledge_base), description, config(JSON)
action_validators 조치-검증 연결 (N:M) action_id, validator_id, execution_order
diagnosis_actions 진단-조치 연결 (N:M) diagnosis_id, action_id
playbooks Playbook 정의 playbook_id, name, description, collect_tools(JSON), ai_instruction
playbook_diagnoses Playbook-진단 연결 (N:M) playbook_id, diagnosis_id
rule_playbooks 규칙-Playbook 연결 (1:N) rule_id, playbook_id, priority
diagnosis_reports 진단 실행 이력 report_id, anomaly_id, playbook_id, diagnosis_id, ai_reasoning, proposed_actions(JSON), status, approved_by

ER Diagram

detection_rules │ 1:N ▼ rule_playbooks ──────── playbooks │ N:M ▼ playbook_diagnoses ── action_diagnoses │ N:M ▼ diagnosis_actions ── action_items │ N:M ▼ action_validators ── validators 실행 이력: diagnosis_reports ── anomaly_id, playbook_id, diagnosis_id, actions, validation_results, status

science Examples

Example 1: 컨베이어 과부하 → 라우팅 변경

warning
이상감지: 컨베이어 부하율 92%
규칙: conveyor_overload (critical > 90%)

Playbook 실행: 물류 병목 진단

Collect 결과:

AI 진단: "라우팅 편중" 선택

AI 근거: "LINE02에 반송의 70%가 집중되어 있고, AGV-003 장애로 처리 용량이 감소한 상태. LINE04-ZONE-D는 부하율 42%로 여유 있음."

조치 제안:

검증 (Validation Studio):

Example 2: 설비 알람 → 가성 이상 판정

check_circle
이상감지: TRACK-02 온도 알람
규칙: equipment_temp_alarm (critical > 85°C)

Playbook 실행: 설비 온도 이상 진단

Collect 결과:

AI 진단: "가성 이상" 선택

AI 근거: "알람 발생 시점의 86°C는 일시적 스파이크로, 현재 83°C로 정상 복귀. 연속 알람이 아니며 추세도 하강 중."

후속: 이상 자동 해소 (resolved, reason: false_alarm)

Example 3: 원인 불명 → 에스컬레이션

help
이상감지: WIP 급증 (LINE03)
규칙: wip_surge (LINE03 재공량 > 500)

Playbook 실행: 재공 이상 진단

Collect 결과:

AI 진단: "원인 불명" 선택

AI 근거: "수집된 데이터에서 설비, 반송, 투입 모두 정상 범위. 재공 급증 원인을 데이터만으로 특정할 수 없음."

후속: 에스컬레이션 — LINE03 담당 엔지니어에게 알림 + 현장 확인 요청