FLOPI — 4-Agent Pipeline & Playbook Studio Design Document

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-Agent Pipeline

이상감지 → 자동 진단 → 구체적 조치 제안 → 사전 검증 → 승인/자동실행의 완전한 체인을 만든다.

AI Agent

Studio

N:M

유연한 연결

Guard

울타리 안에서

lightbulb

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

6개 Studio의 역할

Studio	역할	비유
Tool Studio	데이터를 읽는 도구 (SELECT 쿼리)	청진기, 혈압계
Detection Studio	이상을 감지하는 규칙 (임계치 + AI 판단)	모니터링 센서
Diagnosis Studio NEW	진단 후보를 정의 (증상 → 원인 케이스)	진단 차트
Action Studio	데이터를 바꾸는 조치 (UPDATE, API 호출)	처방전 + 약
Validation Studio	조치를 검증 (DT, 시뮬레이터, KB)	약 부작용 검사
Playbook Studio	모든 것을 엮는 시나리오 + 파이프라인 설정	진료 프로토콜

hub Big Picture

이상감지 규칙에 플레이북을 연결하면, 이상 발생 시 4단계 AI 파이프라인이 자동으로 실행된다.

flowchart TB subgraph Detection["🔍 이상감지"] R["이상감지 규칙
컨베이어 부하율 > 90%"] A["🚨 이상 발생!
severity: critical"] R -->|"임계치 위반"| A end subgraph Pipeline["🤖 4-Agent Pipeline"] direction TB D["🔬 Diagnostician
진단분석 Agent"] AD["💡 Advisor
조치제안 Agent"] V["✅ Validator
대안검증 Agent"] AP{{"승인 판정"}} D --> AD --> V --> AP end subgraph Studios["📦 Studios (지식 저장소)"] DS["Diagnosis Studio
진단 후보 케이스"] AS["Action Studio
조치 정의 + 파라미터"] VS["Validation Studio
DT / 시뮬 / KB 검증기"] end A -->|"Playbook 트리거"| D D -.->|"후보 로드"| DS AD -.->|"액션 로드"| AS V -.->|"검증기 실행"| VS AP -->|"Safe + 자동실행"| EX["⚡ 자동 실행"] AP -->|"그 외"| WA["⏳ 승인 대기
엔지니어 확인"] WA -->|"승인"| EX WA -->|"거부"| RJ["❌ 종료"] style Detection fill:#fef2f2,stroke:#ef4444,stroke-width:2px style Pipeline fill:#eff6ff,stroke:#3b82f6,stroke-width:2px style Studios fill:#f0fdf4,stroke:#10b981,stroke-width:2px

info

연결 관계
이상감지 규칙 1:N Playbook | Playbook N:M Diagnosis | Diagnosis N:M Action | Action N:M Validator

groups 4 Agents & Pipeline Flow

파이프라인은 4개의 독립 AI 에이전트가 순차적으로 실행되며, 각 에이전트는 자신의 Studio에서 지식을 로드한다.

파이프라인 실행 흐름

단계	phase	Agent	역할	실패 시
1	`diagnosis`	Diagnostician	플레이북→진단 케이스 매칭	신뢰도 < 30% → `inconclusive` (중단)
2	`action`	Advisor	결정 가이드 참고 → 액션 선택 + 파라미터 제안	에러 → `failed`
3	`validation`	Validator	DT/시뮬/KB로 검증 → Safe/Caution/Risky	에러 → `failed`
4a	`completed`	—	`auto` + Safe → 즉시 실행 (auto_approved)	—
4b	`awaiting_approval`	—	그 외 → 승인 대기	거부 → `rejected`

phase / approval_status 값

`pipeline_phase`	의미	터미널?
`diagnosis`	진단 중
`action`	조치 제안 중
`validation`	검증 중
`awaiting_approval`	승인 대기
`completed`	실행 완료	✓
`inconclusive`	진단 불가 (신뢰도 부족)	✓
`failed`	파이프라인 오류	✓
`rejected`	승인 거부	✓

`approval_status`	의미
`none`	아직 승인 단계 미도달
`auto_approved`	자동 실행됨 (auto + Safe)
`awaiting_approval`	승인 대기 중
`approved`	수동 승인됨
`rejected`	수동 거부됨

🔍

Sentinel

이상감지 (기존)

Detection Studio

🔬

Diagnostician

진단분석 Agent

Diagnosis Studio

💡

Advisor

조치제안 Agent

Action Studio

✅

Validator

대안검증 Agent

Validation Studio

account_tree

파이프라인 vs 기존 Runner
Playbook에 진단 후보(Diagnosis)가 연결되어 있으면 → 4-Agent Pipeline 사용
진단 후보가 없으면 → 기존 PlaybookRunner 사용 (하위호환)

biotech Agent 1: Diagnostician (진단분석)

이상 데이터를 받아서 Diagnosis Studio에 등록된 진단 후보 중 하나를 선택하고 근거를 설명한다.

flowchart LR A["🚨 이상 데이터
rule_id, severity,
measured_value"] --> L["🧠 LLM"] C["📋 진단 후보 5개
Diagnosis Studio"] --> L L --> R["🔬 진단 결과
diagnosis_id
confidence: 0.85
reasoning: ..."] style A fill:#fef2f2,stroke:#ef4444 style C fill:#faf5ff,stroke:#8b5cf6 style R fill:#f0fdf4,stroke:#10b981

진단 매칭 로직

1단계: 등록 케이스 매칭

Diagnosis Studio의 후보를 LLM에 전달하여 선택

LLM은 이상 데이터(severity, measured_value, category)와 진단 후보(symptoms, root_cause)를 비교하여 가장 적합한 케이스를 선택한다.

선택된 케이스의 confidence가 시스템 설정(pipeline.diagnosis_confidence_threshold, 기본 0.7) 이상이면 매칭 성공.

auto_awesome

2단계: 매칭 실패 → 진단 불가 (inconclusive)

등록 케이스 중 매칭되는 것이 없으면 파이프라인 중단

매칭 실패 시 inconclusive 상태로 파이프라인이 중단된다. 파이프라인 모니터에서 "진단 실패" 필터로 모아볼 수 있으며, 진단 케이스를 추가로 등록하여 커버리지를 확대한다.

진단 결과 구조

DiagnosisResult
  diagnosis_id:     3              # 매칭된 진단 케이스 ID (자율이면 None)
  type:             "action_required"
  reasoning:        "ZONE-C 반송 비율 70%, AGV-003 ERROR..."
  confidence:       0.85
  is_autonomous:    False           # True면 반드시 승인 필요
  matched_actions:  [1, 5]          # 연결된 Action ID 목록

tips_and_updates Agent 2: Advisor (조치제안)

Diagnostician이 선택한 진단 결과에 연결된 Action들을 로드하고, 진단 케이스의 결정 가이드(guidance)를 참고하여 어떤 액션을 실행할지 결정하고 파라미터를 제안한다.

flowchart LR D["🔬 진단 결과
라우팅 편중"] --> AD["🧠 Advisor"] G["📋 결정 가이드
pb_diagnoses.guidance"] --> AD ACT["⚡ 연결 Actions
Action Studio"] --> AD AD --> P["💡 조치 제안
zone_to=ZONE-D
ratio=50"] style D fill:#faf5ff,stroke:#8b5cf6 style G fill:#fffbeb,stroke:#f59e0b style ACT fill:#eff6ff,stroke:#3b82f6 style P fill:#f0fdf4,stroke:#10b981

Advisor가 하는 일

단계	설명	데이터 소스
1. Action 로드	진단에 연결된 Action 목록 가져오기	`pb_diagnosis_actions` (N:M)
2. 결정 가이드 로드	진단 케이스의 `guidance` 참조 → 상황별 액션 선택 기준	`pb_diagnoses.guidance`
3. LLM 제안	이상 데이터 + 결정 가이드 + 액션 목록 → 최적 액션 + 파라미터 결정	LLM
4. 승인 레벨	모든 제안 Action 중 최고 `approval_level` 계산	Action Studio

조치 제안 구조

ActionProposal
  proposed_actions:
    - action_id: 1
      action_name: "라우팅 비율 변경"
      proposed_params: {zone_from: "ZONE-C", zone_to: "ZONE-D", ratio: 50}
      approval_level: "approval"
    - action_id: 5
      action_name: "LOT 우선순위 조정"
      proposed_params: {target: "LOW"}
      approval_level: "auto"
  reasoning: "ZONE-C 70% 집중, ZONE-D 42% 여유..."
  highest_approval_level: "approval"

verified

결정 가이드 (guidance)
각 진단 케이스에는 guidance 필드가 있어 Advisor에게 상황별 조치 기준을 전달한다.
예: "부하 90% 이상 → 라우팅 변경, 70~90% → LOT 우선순위 조정"
AI는 가이드 범위 안에서 액션을 선택하고 파라미터를 결정한다.

verified Agent 3: Validator (대안검증)

Advisor가 제안한 조치를 실행하기 전에 Validation Studio의 검증기로 사전 검증한다.

flowchart TB P["💡 조치 제안
ratio=50%"] --> V1["🏭 Digital Twin
물류 흐름 DT"] P --> V2["🧮 Small Simulator
스토커 큐잉"] P --> V3["📚 Knowledge Base
PM 매뉴얼 참조"] V1 --> J{{"종합 판정"}} V2 --> J V3 --> J J -->|"모두 통과"| S["🟢 Safe"] J -->|"일부 주의"| C["🟡 Caution"] J -->|"하나라도 위험"| R["🔴 Risky"] style S fill:#f0fdf4,stroke:#10b981,stroke-width:2px style C fill:#fffbeb,stroke:#f59e0b,stroke-width:2px style R fill:#fef2f2,stroke:#ef4444,stroke-width:2px

검증 방법 유형 (3종)

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

종합 판정

판정	의미	후속
Safe	모든 Validator 통과, 연쇄 효과 안전 범위	`approval_level=auto`면 자동 실행, 아니면 승인 대기
Caution	일부 Validator에서 주의 신호	반드시 승인 필요 (자동 실행 불가)
Risky	하나라도 위험 판정	자동 실행 차단, 승인 대기 + 위험 경고

how_to_reg Approval Flow (승인 흐름)

Validator 판정 후, 파이프라인이 어떻게 분기되는지 보여준다.

stateDiagram-v2 [*] --> diagnosing: 이상 발생 diagnosing --> inconclusive: 매칭 실패 diagnosing --> advising: 진단 완료 advising --> validating: 조치 제안 완료 validating --> auto_approved: approval_level=auto + Safe validating --> awaiting_approval: approval/sign_off 또는 Caution/Risky auto_approved --> completed: 즉시 실행 awaiting_approval --> completed: 승인 awaiting_approval --> rejected: 거부 completed --> [*] rejected --> [*] inconclusive --> [*]

자동 실행 조건 (모두 충족해야 함)

flash_on

액션 승인 레벨: approval_level = auto (모든 제안 액션이 auto)
Validator 판정: Safe

하나라도 미충족 → 승인 대기 (awaiting_approval)

승인 대기 시 UI

Playbook Studio 상단에 노란색 배너로 승인 대기 건이 표시된다.

엔지니어는 각 건의 진단 결과, 제안 조치, 검증 결과를 확인한 뒤 승인 또는 거부한다.

⏳ 승인 대기 2건 │ ├── #42 — 물류 병목 진단 │ 진단: 라우팅 편중 (confidence 0.85) │ 조치: ZONE-C→ZONE-D 우회 20%→50% │ 검증: Safe (DT 시뮬 통과) │ [승인] [거부] [상세] │ └── #43 — 설비 온도 이상 진단: 자율 진단 (등록 케이스 없음) 조치: TRACK-02 쿨링 팬 속도 80%→100% 검증: Caution (소음 우려) [승인] [거부] [상세]

biotech Diagnosis Studio (진단 스튜디오)

진단 후보 케이스를 등록·관리하는 6번째 Studio. 여러 Playbook에서 재사용할 수 있다.

진단 케이스 유형

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

진단 케이스 정의 구조

pb_diagnoses
  id:              자동 생성
  name:            "라우팅 편중"
  type:            action_required
  category:        "logistics"
  symptoms:        "특정 zone 반송 비율 60%+, 인접 zone 대비 2배 이상"
  root_cause:      "라우팅 테이블 고정 비율 설정, 동적 분산 미적용"
  confidence_hint: 0.8             # AI 매칭 기준점
  guidance:        "부하 90% 이상→라우팅 변경, 70~90%→LOT 우선순위 조정"  # Advisor 결정 가이드
  actions:         [라우팅 비율 변경, LOT 우선순위]  # N:M 연결

psychology

가성 이상 피드백 루프
false_alarm 진단이 누적되면 해당 이상감지 규칙의 정확도를 측정할 수 있다. "규칙 X에서 40%가 가성 이상" → 임계치 조정 또는 규칙 재설계 신호.

bolt Action Studio (조치 스튜디오)

FAB 운영 파라미터를 변경하는 구체적 조치를 정의한다. 파라미터 범위, 승인 등급, 현재값 조회 도구까지 관리한다.

alt_route

라우팅 비율 변경

tool_call • approval_level: approval

name:               "라우팅 비율 변경"
action_type:        tool_call
description:        "컨베이어 구간간 라우팅 비율을 변경합니다"
approval_level:     approval          # auto / approval / sign_off

승인 레벨 (3단계)

레벨	의미	예시
`auto`	자동 실행 (검증 Safe 시 즉시)	알림 발송, 모니터링 주기 변경
`approval`	승인 필요 (운영자 확인)	라우팅 변경, LOT 우선순위 조정
`sign_off`	결재 필요 (관리자 서명)	설비 정지, PM 주기 변경

verified_user Validation Studio (검증 스튜디오)

Action 실행 전 사전 검증을 수행한다. 검증기는 Action에 N:M으로 연결되며, 독립적으로 재사용 가능하다.

검증 흐름

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 / Caution / Risky

menu_book Playbook Studio (플레이북 스튜디오)

모든 Studio를 엮어서 파이프라인을 구성한다. 이상감지 규칙에 연결하면 자동 실행된다.

Playbook 설정 항목

항목	설명
`trigger_rule_ids`	어떤 이상감지 규칙에 의해 트리거되는가 (다중 선택)
`severity_filter`	특정 severity에서만 실행 (critical, warning 등)
`diagnosis_candidates`	진단 후보 (Diagnosis Studio에서 선택, N:M)
`diagnose_prompt`	AI 진단 시 추가 컨텍스트 (선택)
`steps`	기존 수동 스텝 (하위호환, JSON 배열)

이상감지 규칙에서 Playbook 연결

link

양방향 연결
규칙 편집 화면에서 "이 규칙에 대응할 플레이북"을 선택할 수 있고,
플레이북 편집 화면에서 "이 플레이북을 트리거할 규칙"을 선택할 수도 있다.
하나의 규칙에 여러 플레이북을 연결하면 서로 다른 관점에서 동시에 진단한다.

이상감지 규칙: "컨베이어 과부하" │ ├── Playbook A: 물류 관점 진단 │ 진단 후보: 라우팅 편중 / AGV 고장 / 스토커 포화 / 가성 이상 │ 조치 후보: 라우팅 변경, LOT 우선순위, 대체 경로 │ 검증: 물류 흐름 DT 시뮬레이터 │ └── Playbook B: 설비 관점 진단 진단 후보: PM 지연 / 센서 이상 / 가성 이상 조치 후보: PM 주기 변경, 수리 요청 검증: PM 주기 KB 검증

storage Data Model

테이블 관계도

erDiagram detection_rules ||--o{ pb_playbooks : "trigger_rule_ids (1:N)" pb_playbooks ||--o{ pb_playbook_diagnoses : "" pb_diagnoses ||--o{ pb_playbook_diagnoses : "" pb_diagnoses ||--o{ pb_diagnosis_actions : "" pb_actions ||--o{ pb_diagnosis_actions : "" pb_actions ||--o{ pb_action_validators : "" pb_validators ||--o{ pb_action_validators : "" pb_playbooks ||--o{ pb_playbook_runs : "" detection_rules { int rule_id PK string rule_name string category string check_type } pb_playbooks { int id PK string name string trigger_rule_ids "JSON array" string severity_filter string steps "JSON array" } pb_diagnoses { int id PK string name string type "action_required etc" string category string symptoms string root_cause string guidance "결정 가이드" float confidence_hint } pb_actions { int id PK string name string action_type "tool_call etc" string approval_level "auto/approval/sign_off" } pb_validators { int id PK string name string validator_type "digital_twin etc" } pb_playbook_runs { int id PK int playbook_id FK string status string pipeline_phase string ai_reasoning string proposed_actions "JSON" string validation_results "JSON" string approval_status } pb_playbook_diagnoses { int playbook_id FK int diagnosis_id FK } pb_diagnosis_actions { int diagnosis_id FK int action_id FK } pb_action_validators { int action_id FK int validator_id FK }

파이프라인 실행 이력 (pb_playbook_runs 확장 컬럼)

컬럼	타입	설명
`diagnosis_id`	INTEGER	매칭된 진단 케이스 ID
`ai_reasoning`	TEXT	AI 진단 근거 (JSON)
`proposed_actions`	TEXT	제안된 조치 목록 (JSON)
`validation_results`	TEXT	검증 결과 (JSON, overall + details)
`approval_status`	TEXT	none / auto_approved / approved / rejected / awaiting_approval
`approved_by`	TEXT	승인/거부한 사용자
`approved_at`	TEXT	승인/거부 시각
`pipeline_phase`	TEXT	현재 파이프라인 단계

science Examples

Example 1: 컨베이어 과부하 → 라우팅 변경 (자동 실행)

warning

이상감지: 컨베이어 부하율 92%

규칙: conveyor_overload (critical > 90%)

Phase 1: Diagnostician

진단 후보 5개 중 "라우팅 편중" 선택 (confidence: 0.85)

근거: "LINE02 반송 70% 집중, AGV-003 ERROR로 처리량 감소"

Phase 2: Advisor

결정 가이드: "부하 90% 이상 → 라우팅 변경, 70~90% → LOT 우선순위 조정"

라우팅 비율 변경: ZONE-C → ZONE-D 우회 50% (approval_level: auto)
LOT 우선순위 조정: LOT-0342~0348 NORMAL → LOW (approval_level: auto)

최고 승인 레벨: auto

Phase 3: Validator

[물류 흐름 DT] ZONE-C 부하 92%→63%, ZONE-D 42%→58% → Safe

Phase 4: 자동 실행 (auto_approved)

approval_level=auto + Safe → 즉시 자동 실행

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

check_circle

이상감지: TRACK-02 온도 알람 86°C

규칙: equipment_temp_alarm (critical > 85°C)

Phase 1: Diagnostician

진단: "가성 이상" (confidence: 0.92)

근거: "현재 83°C로 정상 복귀, 단발성 스파이크"

후속

진단 유형 false_alarm → Advisor/Validator 건너뜀 → 이상 자동 해소

Example 3: 진단 실패 (inconclusive)

help

이상감지: WIP 급증 (LINE03)

규칙: wip_surge

Phase 1: Diagnostician

등록 케이스 5개 중 매칭 실패 → 신뢰도 0.15 (기준 0.30 미달)

결과: inconclusive — 파이프라인 중단

후속

파이프라인 모니터 "진단 실패" 필터로 확인 → 새 진단 케이스를 등록하여 커버리지 확대

엔지니어가 직접 원인 분석 후 Diagnosis Studio에 케이스 추가