architecture 전체 아키텍처

왜 단일 앱인가

반도체 FAB 폐쇄망에서는 마이크로서비스 배포가 현실적으로 어렵습니다. 네트워크 제약, 인프라 관리 인력 부족, 컨테이너 환경 미지원 등의 이유로 모노리스 단일 앱을 선택했습니다. 대신 내부를 모듈 단위로 명확히 분리하여 코드 결합도를 낮췄습니다.

3-Tier 구조

기술 선택 근거

전체 파일 맵

FLOPI/
├── main.py              # FastAPI 진입점 + APScheduler (655 lines)
├── config.py            # 통합 설정 — 환경변수 기반 (195 lines)
├── init_db.py           # DB 초기화 + admin 계정 + 마이그레이션 (2,202 lines)
├── mcp_server.py        # MCP 서버 — Claude 연동 (132 lines)
├── rules.yaml           # 탐지 규칙 seed (YAML)
├── seed.json            # Tool Studio 도구 seed
│
├── api/                 # REST API 라우터 (22 files, ~5,600 lines, 20 routers)
│   ├── anomalies.py     #   이상 CRUD + 상태 관리
│   ├── dashboard.py     #   대시보드 KPI 집계
│   ├── rules.py         #   규칙 CRUD + 테스트 + 감사
│   ├── system.py        #   시스템 상태 + 수동 감지
│   ├── system_settings.py #  런타임 설정 관리
│   ├── data_studio.py   #   Tool Studio CRUD + 실행
│   ├── deep_rca.py      #   딥 RCA 세션 + 시나리오
│   ├── workflow.py      #   워크플로우 CRUD + 실행
│   ├── knowledge_base.py #  KB 문서 CRUD + 검색
│   ├── ai_chat.py       #   AI 대화 (SSE 스트리밍)
│   ├── llm_usage.py     #   LLM 사용량 통계
│   ├── users.py         #   사용자 CRUD + 인증
│   ├── rca.py           #   이상별 RCA 조회
│   ├── chat_scenarios.py #  챗 매크로 CRUD
│   ├── user_prompts.py  #   사용자 개인 프롬프트
│   ├── countermeasures.py # 대안/조치 플레이북 CRUD
│   ├── migration.py     #   이관 관리 (블록별 상태 + 스키마 비교)
│   ├── activity_log.py  #   활동 로그 조회
│   ├── question_flows.py #  질문 흐름 CRUD
│   ├── tool_requests.py #   도구 요청 CRUD
│   └── deps.py          #   공통 의존성 (인증, 권한 검사)
│
├── core/                # 공통 인프라 (47 files, ~7,300 lines)
│   ├── auth/            #   인증 + 권한 (permissions.py)
│   ├── db/              #   DB 레이어 (oracle.py + queries/ 16개 쿼리 모듈)
│   ├── llm/             #   LLM 클라이언트 + 도구 레지스트리 + 에이전트 루프
│   ├── rag/             #   RAG 파이프라인 (청킹 + 임베딩 + 검색 + 구조화)
│   ├── simulator/       #   SQLite 시뮬레이터 (monkey-patch)
│   ├── workflow/        #   DAG 실행 엔진 + AI 워크플로우 생성기
│   ├── migration/       #   DB 마이그레이션 (checker.py + router.py)
│   ├── audit.py         #   활동 감사 로그 헬퍼
│   ├── code_interpreter.py # Python 코드 실행 엔진 (AI Chat용)
│   └── settings_manager.py # 시스템 설정 인메모리 캐시
│
├── detection/           # 이상탐지 엔진 (14 files, ~1,300 lines)
│   ├── scheduler.py     #   탐지 사이클 오케스트레이터
│   ├── evaluator.py     #   규칙 평가 + 이상 생성
│   ├── lifecycle.py     #   DetectionLifecycleManager
│   ├── agents.py        #   LLM 에이전트 분석
│   ├── resolver.py      #   이상 자동 해소 (auto-resolve)
│   ├── prompts.py       #   이상탐지 시스템 프롬프트
│   ├── rules/           #   규칙 로더 + 엔진 + 모델
│   └── tools/           #   Tool Studio 브릿지
│
├── rca/                 # 딥 RCA (12 files, ~3,000 lines)
│   ├── workflow_converter.py # RCA → 워크플로우 변환
│   └── sample_data/     #   SPC/FDC/알람 테스트 데이터
│
├── data_studio/         # Tool Studio (8 files, ~2,100 lines)
│   └── pages/           #   Data Studio 전용 페이지
│
└── ui/                  # NiceGUI 대시보드 (29 files, ~16,100 lines)
    └── pages/           #   20개 페이지

모듈별 규모 요약

dashboard Dashboard

왜 필요한가

FAB 현장 관리자는 한 화면에서 전체 상황을 1초 안에 파악해야 합니다. 이상이 몇 건인지, 심각도는 어떤지, 마지막 탐지 사이클은 정상이었는지를 여러 페이지를 돌아다니며 확인하는 것은 비효율적입니다.

구성 요소

설계 결정

• 30초 자동 갱신: ui.timer(30.0, refresh)로 API 연결 상태 표시를 자동 갱신합니다. 데이터 자체는 페이지 진입 시 1회 + 수동 감지 후 갱신.
• @ui.refreshable: NiceGUI 패턴으로, 수동 감지 실행 후 대시보드 전체가 자동 재렌더링됩니다.
• 최근 이상 5건: severity_badge + status_badge + 감지시각으로 즉시 식별 가능한 카드 형태.

파일 구조

API

sensors 이상탐지 엔진

왜 필요한가

FAB MES 데이터에서 자동으로 이상을 탐지해야 합니다. 사람이 24시간 모니터링하는 것은 불가능하고, 단순 임계치 비교만으로는 복잡한 패턴(예: 서서히 증가하는 부하율)을 잡아내기 어렵습니다. 임계치 기반 빠른 탐지 + LLM 기반 정밀 분석을 공존시켜야 합니다.

핵심 설계: 틱 기반 평가

4가지 체크 타입

LLM 에이전트 분석

llm_enabled=true인 규칙은 ReAct 에이전트 루프를 거칩니다. 최대 max_agent_rounds(기본 3)회 LLM ↔ 도구 호출을 반복하며, JSON 형식으로 {is_anomaly, confidence, severity, title, analysis}를 반환합니다.

데이터 소스 분기

• source_type=sql: query_template SQL을 Oracle/SQLite에 직접 실행
• source_type=tool: tool_registry.dispatch()로 Tool Studio 도구 또는 내장 도구 호출

라이프사이클 관리

DetectionLifecycleManager가 APScheduler 잡 등록/해제를 캡슐화합니다. start(), update_interval(), run_once()(수동 트리거)를 제공하여 런타임 중 탐지 주기를 변경하거나 즉시 실행할 수 있습니다.

파일 구조

detection/
├── lifecycle.py      # DetectionLifecycleManager (start/stop/update_interval)
├── scheduler.py      # run_detection_cycle() 오케스트레이터
├── evaluator.py      # 규칙 평가 + 이상 생성
├── agents.py         # LLM 에이전트 분석 (analyze_and_save)
├── resolver.py       # 이상 자동 해소 (auto-resolve)
├── prompts.py        # 이상탐지 시스템 프롬프트
├── rules/
│   ├── models.py     # Pydantic — RuleCreate/RuleUpdate
│   ├── loader.py     # YAML ↔ DB 동기화 (DB-first)
│   └── engine.py     # 4가지 체크 타입 평가
└── tools/
    └── ds_bridge.py  # Tool Studio 브릿지 (sync_ds_tools)

Auto-Resolve (자동 해소) v1.7.0

API 엔드포인트

감지 사이클 상세 흐름

rule 규칙 엔진

왜 필요한가 — DB-first 전략

K8s 멀티 Pod 환경에서 YAML을 source of truth로 하면 Pod 재시작 시 DB 변경이 증발합니다. 따라서 DB가 런타임 원본이고, rules.yaml은 초기 seed + 버전관리 백업 역할입니다.

DB-first 동기화 흐름

89개 내장 FAB 도구 카탈로그

규칙 생성 UI에서 선택 가능한 사전 정의 도구 목록입니다.

변경 이력 추적

모든 규칙 CRUD 후 sync_db_to_yaml()이 best-effort로 호출되며 (실패 시 무시), 변경 이력은 rule_audit_log 테이블에 diff와 함께 저장됩니다. 누가, 언제, 어떤 규칙을, 어떻게 변경했는지 추적할 수 있습니다. POST /api/rules/sync로 DB → YAML 수동 내보내기도 가능합니다.

API 엔드포인트

receipt_long 탐지 로그

왜 필요한가

이상탐지 시스템은 "왜 이 이상이 탐지되었는가?"와 "마지막 탐지 사이클은 정상이었는가?"를 추적할 수 있어야 합니다. 탐지 결과만이 아니라 탐지 과정 자체를 로깅합니다.

UI 구조

상태 전이 매트릭스

state_change 권한이 있는 사용자만 상태를 변경할 수 있습니다 (operator 이상). 허용되지 않은 전이는 HTTP 400으로 거부됩니다.

파일 구조

상태 전이 상세

build Tool Studio

왜 필요한가

FAB 엔지니어가 코드를 작성하지 않고 SQL 기반 데이터 조회 도구를 만들 수 있어야 합니다. 만든 도구는 이상탐지 규칙, AI Chat, 워크플로우, Claude(MCP)에서 동일하게 재사용됩니다. 한 번 정의하면 4곳에서 쓸 수 있는 "도구 허브" 개념입니다.

아키텍처

3종 엔진

Tool Registry 브릿지

서버 시작 시 sync_ds_tools()가 실행됩니다. DB의 활성 Tool Studio 도구를 tool_registry에 동적 등록하여, 이상탐지 규칙의 source_type=tool에서 바로 호출할 수 있습니다. 각 도구마다 OpenAI function calling 스키마도 자동 생성됩니다.

caller 추적

ds_query_log.caller 필드로 호출 출처를 추적합니다: ai_chat detection workflow mcp api

파일 구조

data_studio/
├── manager.py        # DataStudioManager (도구 실행 + 스키마 빌드 + 카테고리 자동 분류)
├── executor.py       # SQL 실행기 (Rate Limit + 캐싱 + 타임아웃)
├── queries.py        # 연결/도구/로그 CRUD 쿼리
├── codegen.py        # Python 코드 자동 생성
├── cache.py          # 쿼리 결과 캐시 관리
├── rate_limiter.py   # 분당 요청 수 제한
└── pages/            # Data Studio 전용 페이지

API 엔드포인트 (17개)

3종 엔진 비교

account_tree RCA Studio

왜 필요한가

반도체 FAB의 이상 원인분석(Root Cause Analysis) 노하우는 전문가의 머릿속에만 있습니다. SOP 문서는 만들기 번거롭고 비일관적이며, 퇴직 시 지식이 사라집니다. AI 대화를 통해 자연스럽게 분석 과정을 구조화하고, Mermaid 플로차트로 자동 변환하여 지식을 축적합니다.

핵심 플로우

UI: 3패널 스플리터

노드 타입

그래프 검증 엔진

Analyst.validate_graph()가 STRUCTURER_SYSTEM 프롬프트로 전체 그래프를 검증합니다:

• 빠진 분기: decision 노드에 정상/비정상 두 분기 모두 있는지
• 고립 노드: 들어오는/나가는 엣지 모두 없는 노드
• 끊긴 경로: start에서 도달 불가능한 노드
• 판단 기준 누락: decision에 임계값/조건이 없음

검증 결과는 pass / warning / fail 상태 + 이슈 목록 + 자동 수정 제안(fixes)으로 반환됩니다.

시나리오 재활용

저장된 시나리오는 이후 새 분석 시 참고 시나리오로 AI 컨텍스트에 주입됩니다. AI가 기존 패턴과 비교하며 "이 단계 다음에 보통 X를 확인하는데, 맞나요?" 식으로 질문합니다. 분석이 쌓일수록 AI가 더 정확해지는 선순환 구조입니다.

파일 구조

rca/
├── analyst.py              # AI 대화 + 구조 추출 (Analyst 클래스)
├── structurer.py           # FlowGraph → Mermaid 변환
├── prompts.py              # ANALYST_SYSTEM / STRUCTURER_SYSTEM 프롬프트
├── models.py               # 데이터 모델 (Session, Message, Node, Edge)
├── queries.py              # DB CRUD (세션/메시지/노드/엣지/시나리오)
├── workflow_converter.py   # RCA → 워크플로우 자동 변환
├── pages/                  # RCA 전용 페이지
└── sample_data/
    ├── spc.py              # SPC 통계적 공정 제어 테스트 데이터
    ├── fdc.py              # FDC 결함 분류 테스트 데이터
    └── alarms.py           # 알람 로그 테스트 데이터

API 엔드포인트 (13개)

route Workflow

왜 필요한가

"데이터 조회 → AI 분석 → 조건 분기 → 알림"의 자동화 파이프라인을 코드 없이 시각적으로 구성하고 실행할 수 있어야 합니다. Dify/n8n 스타일의 비주얼 워크플로우 빌더를 FLOPI 내부에 구현했습니다.

12가지 노드 타입

이벤트 트리거 — 이상탐지 연동

AI 워크플로우 생성 (core/workflow/generator.py)

워크플로우 빌더 우측 패널에서 자연어 대화로 워크플로우를 직접 생성합니다.

실행 엔진: Kahn's Algorithm

변수 템플릿 시스템

condition 노드 샌드박스

eval(expression) 실행 시 builtins를 제한합니다: len, str, int, float + ctx, prev, v 변수만 허용. condition 결과가 true/false에 따라 반대 방향 후손 노드를 모두 skipped 처리합니다.

캔버스 구현 (JS)

파일 구조

API 엔드포인트 (11개)

menu_book Knowledge Base

왜 필요한가

FAB 전문가 지식(SOP, 매뉴얼, 분석 노하우)을 등록하면 자동으로 청킹/임베딩되어 워크플로우의 rag_search 노드와 AI Chat에서 시맨틱 검색으로 활용할 수 있습니다. 키워드 검색이 아닌 의미 기반 검색으로, "컨베이어 병목"이라고 질문하면 "반송 지연 현상"이라고 적힌 문서도 찾아냅니다.

RAG 파이프라인

검색 프로세스

search(query, top_k, category): 쿼리 텍스트 임베딩 → ChromaDB cosine 유사도 검색 → score = 1.0 - distance 변환 → {chunk_text, score, doc_title, category} 반환.

교체 가능한 추상화

always_on 도구

파일 구조

core/rag/
├── embedder.py       # 추상 임베더 + Gemini/OpenAI 구현
├── vectorstore.py    # 추상 벡터저장소 + ChromaDB 구현
├── chunker.py        # 문단 기반 텍스트 청킹 (chunk_size=500, overlap=50)
├── structurer.py     # LLM 기반 문서 구조화 (비정형 → 계층 청크)
│                     #   preserve 모드: 원본 구조 유지
│                     #   reorganize 모드: LLM이 계층 재구성
└── searcher.py       # 통합 시맨틱 검색 (임베더 + 벡터저장소)

core/db/queries/knowledge_base.py   # 문서 메타데이터 CRUD
api/knowledge_base.py               # REST API (14개 엔드포인트)
ui/pages/knowledge_base.py          # 관리 페이지 (문서 CRUD + 검색 테스트 + 재임베딩)

검색 결과 반환 형식

{
  "results": [
    {
      "chunk_text": "PHOTO 공정에서 오버레이 불량 발생 시...",
      "score": 0.87,
      "doc_title": "PHOTO 공정 SOP",
      "doc_id": "kb_001",
      "category": "SOP",
      "chunk_index": 3,
      "heading": "오버레이 불량 대응"
    }
  ],
  "total": 5,
  "query": "오버레이 불량 대응 방법"
}

API 엔드포인트 (14개)

설정 옵션

chat AI Chat

왜 필요한가

FAB 운영자가 자연어로 "지금 PHOTO 공정 WIP가 얼마야?"라고 질문하면 AI가 실제 MES 데이터를 조회하고 분석하여 답변해야 합니다. 일반적인 챗봇이 아니라 Tool-augmented AI입니다.

v1.7.0 신규 기능

SSE 스트리밍 구조

SSE 이벤트 타입

Smart Tool Selector

89개 이상의 도구가 등록될 것을 대비한 시맨틱 도구 선별기입니다.

• Short-circuit: 도구 수 ≤ top_k(15)이면 전체 반환 (임베딩 호출 없음)
• always_on 도구: knowledge_base_search 등은 무조건 포함
• 쿼리 임베딩: 사용자 질문을 벡터화
• ChromaDB 검색: tool_embeddings 컬렉션에서 top_k×2 후보 검색
• 카테고리 다양성: 카테고리당 max_per_category(5)개까지만 허용

API 엔드포인트 (11개)

User Prompts API (사용자 개인 프롬프트)

Code Interpreter 상세

Agent Loop 상세 흐름

compare_arrows Migration (이관 관리)

왜 필요한가

운영 중인 시스템에서 DB 스키마를 변경하고, SQLite에서 Oracle로 블록별 이관을 관리해야 합니다. 블록별 이관 상태 추적, 스키마 비교, DDL 자동 생성을 통해 SQLite 시뮬레이터에서 Oracle 운영 환경으로 안전하게 전환합니다.

파일 구조

core/migration/
├── __init__.py        # 패키지
├── checker.py         # Oracle 스키마 검증 (필수 테이블/컬럼 확인)
└── router.py          # 이관 라우팅 로직

api/migration.py         # 이관 관리 REST API (블록별 상태 + 스키마 비교 + DDL 생성)
ui/pages/migration.py    # 이관 관리 UI 페이지

API 엔드포인트

analytics LLM Usage

왜 필요한가

FAB 폐쇄망 환경에서 LLM API 비용과 사용량을 모듈별로 추적해야 합니다. 어떤 기능이 토큰을 가장 많이 소비하는지, 일별 추이는 어떤지, 과다 사용이 발생하고 있는지를 관리자가 모니터링할 수 있어야 합니다.

자동 태깅

from core.llm.client import set_llm_module
set_llm_module("detection")   # 이후 모든 LLM 호출이 "detection"으로 태깅
# ... LLM 호출 ...
set_llm_module("ai_chat")     # 모듈 전환

llm_usage_log 테이블에 module, model, prompt_tokens, completion_tokens, total_tokens, duration_ms가 자동 기록됩니다.

파일 구조

core/llm/
├── client.py          # LLMClient (OpenAI-compatible)
│   ├── chat()         # 도구 포함 호출
│   ├── chat_stream()  # 스트리밍 호출
│   └── simple_chat()  # 단순 호출
├── tool_registry.py   # ToolRegistry 싱글턴
│   ├── register()     # 도구 등록 (@registry.tool 데코레이터)
│   ├── dispatch()     # 도구 실행 (단일 진입점)
│   └── get_openai_tools()  # OpenAI function calling 스키마
├── tool_selector.py   # SmartToolSelector
│   ├── select_tools() # 시맨틱 검색으로 관련 도구 선택
│   └── sync()         # 도구 임베딩 동기화 (dirty 플래그)
└── agent_loop.py      # Multi-round ReAct Agent
    └── run_agent_loop()  # LLM ↔ 도구 호출 루프 (max_rounds)

자동 추적 메커니즘

UI 구성

API 엔드포인트

LLM 설정 환경변수

group Users & RBAC

왜 필요한가

FAB 환경에서 관리자/엔지니어/운영자/열람자의 접근 권한이 명확히 분리되어야 합니다. Tool Studio 설정을 운영자가 변경하거나, 열람자가 이상 상태를 변경하는 것은 심각한 문제를 야기할 수 있습니다.

4단계 RBAC

권한 레벨

• full — CRUD 전체
• view — 읽기만
• state_change — 이상 상태 변경만 (operator 전용)
• None — 접근 불가 (사이드바에서도 숨김)

커스텀 오버라이드

// users.page_permissions 컬럼 (JSON)
{"workflow": "full", "data_studio": "view"}

네비게이션 필터링

get_nav_items(user)가 역할 + 커스텀 권한으로 접근 가능한 페이지만 사이드바에 표시합니다. 그룹("이상감지", "Studio", "관리") 구조로 접기/펼치기를 지원합니다.

파일 구조

모듈별 권한 매트릭스 (상세)

API 엔드포인트 (9개)

hub MCP Server

왜 필요한가

Claude(claude.ai 또는 Claude Code)에서 FAB MES 데이터를 직접 조회할 수 있도록 Tool Studio 도구를 MCP(Model Context Protocol)로 노출합니다. 엔지니어가 Claude에서 "지금 PHOTO 공정 WIP 알려줘"라고 하면 실제 데이터를 가져옵니다.

연결 흐름

설정

// .mcp.json
{
  "mcpServers": {
    "flopi": {
      "command": "python",
      "args": ["mcp_server.py", "--sqlite", "simulator.db"]
    }
  }
}

파일 구조

별도 디렉토리 없이 단일 파일로 구현. Tool Studio DB에서 활성 도구를 로드하여 MCP Tool 스키마로 자동 변환합니다.

도구 등록 흐름

설정 옵션

// .mcp.json — Claude Code / Claude Desktop 연동
{
  "mcpServers": {
    "flopi": {
      "command": "python",
      "args": ["mcp_server.py", "--sqlite", "simulator.db"]
    }
  }
}

// 운영 환경 (Oracle 직접 연결)
{
  "mcpServers": {
    "flopi": {
      "command": "python",
      "args": ["mcp_server.py"]
    }
  }
}

• --sqlite <path> — 시뮬레이터 모드 (Oracle 불필요)
• 플래그 없음 — 운영 모드 (Oracle 연결 필수)

science SQLite 시뮬레이터

왜 필요한가

FAB 폐쇄망의 Oracle DB에 항상 접근할 수 없으므로, 개발/테스트 환경에서 동일한 코드를 SQLite로 실행할 수 있어야 합니다. 코드 분기 없이 --sqlite 플래그 하나로 전환됩니다.

Monkey-Patch 패턴

파일 구조

core/simulator/
├── sqlite_backend.py  # Monkey-patch + SQLite 연결 관리
├── sql_compat.py      # Oracle → SQLite SQL 변환
├── seeder.py          # MES 더미 데이터 생성 (컨베이어, 차량, WIP, 설비, LOT)
└── scenarios.py       # 사전 정의 장애 시나리오

Monkey-Patch 대상

SQL 호환 변환

sql_compat.py의 oracle_to_sqlite(sql) 함수가 Oracle 문법을 SQLite로 변환:

초기화 흐름

cable 모듈 간 연결

전체 연결 맵

도구 흐름 (Tool Studio 중심)

Tool Registry 중앙 허브

도구 실행 흐름 비교

settings System Settings

왜 필요한가

FAB 운영 중 서버 재시작 없이 설정을 변경해야 하는 경우가 많습니다. LLM 모델 변경, 탐지 간격 조정, 알림 설정 등을 UI에서 즉시 반영합니다. 모든 설정은 DB 기반으로 저장되어 재시작 후에도 유지됩니다.

파일 구조

API 엔드포인트

주요 설정 항목

quiz Question Flows (질문 흐름)

왜 필요한가

AI Chat 매 응답마다 LLM을 추가 호출해 후속질문을 생성하면 토큰 낭비 + 맥락 없는 질문이 됩니다. FAB에선 질문 패턴이 정해져 있습니다 (설비 상태 → 알람 → OEE → PM). 관리자가 질문 흐름을 DB에 등록하면, LLM이 참고하여 자연스럽고 간결한 후속질문을 생성합니다.

하이브리드 방식

흐름이 매칭되면 → LLM에 흐름 컨텍스트 전달 → 다음 단계 기반 후속질문.
흐름이 없으면 → 기존처럼 자유 생성 (폴백). 키워드 매칭으로 현재 위치를 파악하고 남은 단계를 추출합니다.

파일 구조

API 엔드포인트

기본 시드 흐름 (5개)

build_circle Tool Requests (도구 요청)

왜 필요한가

AI Chat에서 사용자가 질문했는데 적합한 도구가 없으면, AI가 자동으로 도구 추가 요청을 생성합니다. 관리자가 요청 목록을 확인하고 상태 관리 (대기 → 진행 중 → 완료/반려)하여 도구 확장 사이클을 체계적으로 운영합니다.

파일 구조

API 엔드포인트

상태 워크플로우

pending (대기) → in_progress (진행 중) → completed (완료) / rejected (반려)

history Activity Log (활동 로그)

왜 필요한가

누가 언제 무엇을 했는지 추적합니다. 규칙 변경, 이상 상태 변경, 도구 수정 등 주요 액션을 자동 기록하여 감사(audit) 추적과 문제 발생 시 원인 파악에 활용합니다.

파일 구조

기록 대상

play_circle Chat Scenarios (챗 매크로) v1.7.0

왜 필요한가

FAB 운영자가 반복적으로 실행하는 도구 조합이 있습니다. "일일 점검"이라고 입력하면 설비가동률 → 재공현황 → 이상이력을 순차 실행하고 종합 분석해야 합니다. 매번 같은 질문을 반복하는 대신, 키워드 트리거 기반 매크로로 도구 체인을 자동 실행합니다.

동작 방식

파일 구조

API 엔드포인트

forum Chat History (채팅 이력) v1.7.0

왜 필요한가

관리자가 전체 사용자의 AI Chat 세션을 한눈에 조회하고 관리할 수 있어야 합니다. 사용 패턴 분석, 문제 세션 추적, 사용자 지원 등을 위해 별도의 관리자 전용 이력 페이지가 필요합니다.

파일 구조

shield Countermeasures (대안/조치 플레이북) v1.7.0

왜 필요한가

이상이 탐지되었을 때 "그래서 어떻게 해야 하는가?"에 대한 표준 대응 절차가 필요합니다. 이상 유형(카테고리/심각도)별로 대안/조치 플레이북을 DB에 등록하면, 이상 발생 시 관련 대응 절차를 자동으로 제시할 수 있습니다.

파일 구조

API 엔드포인트

주요 필드