비스텔리젼스는 제조 데이터를 온톨로지로 모델링하고 Agent가 이상 징후를 분석해 담당자에게 조치를 추천하는 시스템을 예시 프로젝트로 명시합니다. 이벤트를 설비·공정·담당자 관계로 묶어 조치를 추천하는 이 도구는 그 업무를 그대로 MVP로 만든 것입니다. FDE가 고객 문제를 제품 구조로 번역해 Python·SQL·TypeScript로 구현하는 자리라, 온톨로지·추론 규칙·콘솔 화면까지 한 사람이 끝까지 구현하는 데 적합합니다.
고객 도메인의 객체·관계·이벤트·액션을 온톨로지로 모델링해 Agent가 추론·실행하게 만드는 게 핵심 역할입니다. 설비·공정·품질을 관계로 묶는 이 콘솔이 그 업무와 곧바로 정렬됩니다.
제조 고객의 생산·품질·재고 데이터로 Agent가 이상 징후를 분석해 담당자에게 조치를 추천하는 시스템이 예시 프로젝트로 명시됩니다. 이 도구의 핵심 출력과 그대로 맞습니다.
모호한 업무 문제를 Agent가 실행 가능한 요구사항으로 바꾸고 Python·SQL·TypeScript로 프로토타입을 구현하는 자리입니다. 한 사람이 데이터·추론·화면을 끝까지 만드는 흐름과 닿습니다.
제조 현장의 생산·품질·재고 이벤트를 받아 설비·공정·담당자 관계(온톨로지)로 묶고, 임계 이탈·불량 급증·재고 결품 같은 이상 징후를 규칙과 Agent로 짚어, 원인 후보와 담당자별 조치를 근거 이벤트 인용과 함께 추천해 제조 운영 콘솔에 모읍니다. 설비·공정 마스터를 붙여 표기를 정규화하고 미등록 설비를 표시합니다.
비스텔리젼스 Forward Deployed Engineer가 만드는 도구를 쓰는 제조 고객사 현장 관리자입니다. 생산·품질·재고 데이터를 화면마다 따로 보다가 이상의 원인과 담당자를 찾느라 시간을 쓰던 상황을, 한 콘솔에서 이상 징후와 근거 이벤트, 담당자별 조치 추천을 함께 보고 무엇부터 처리할지 바로 판단하고 싶은 사람입니다.
제조 이벤트와 설비·공정·담당자 온톨로지를 한 표준 구조로 묶으면, (a) 임계 이탈·불량 급증·재고 결품 이상 징후를 규칙으로 짚고, (b) 관계를 따라 원인 후보와 담당자별 조치를 근거 인용과 함께 추천하며, (c) 추천이 심어둔 정답 조치·담당자와 맞는지 대조로 채점합니다.
생산·품질·재고 이벤트를 받아 설비·공정 관계로 묶고 이상 징후를 짚어 원인 후보와 담당자별 조치를 근거 이벤트와 함께 추천하는 동작하는 콘솔입니다. 입력은 제조 고객 운영 데이터를 가정한 더미 이벤트로 시작하고, 모호하면 단정 대신 '확인 권고'로 표시합니다. 1주차 기본 기능은 Next 프론트를 Vercel로 배포해 바로 도는 데모로 만듭니다.
추천한 조치·담당자를 심어둔 정답과 대조해 정확도를 보여주고, 모호 사례는 현장 검토자 2명이 라벨링해 일치도를 보여주는 화면입니다. Agent가 조치를 바로 실행하지 않고 담당자 승인을 받는 human-in-the-loop 경계를 명시합니다.
고객사마다 다른 설비·공정 온톨로지와 이상 규칙을 공통 블록으로 묶어, 새 제조 라인을 빠르게 붙여 이상 분석·조치 추천이 도는 단계입니다.
제조 이벤트 12종(불량 급증·설비 임계 이탈·재고 결품 등)을 넣으면, 이상 징후와 원인 후보·담당자별 조치 추천이 근거 이벤트와 함께 몇 초 안에 나오는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(센서 결측·정상 범위 경계·미등록 설비·담당자 미지정)을 넣어도 출력 형식(스키마)이 한 번도 안 깨지고 모호하면 확인 권고로 표시되는 걸 보여줍니다
이벤트가 들어오면 이상 분석과 조치 추천이 자동으로 이어지는 걸 시연으로 보여줍니다
내가 만든 정답 40건 중 추천한 조치·담당자가 정답과 일치한 게 34건(약 85%)입니다. 이상 정답은 임계 규칙으로 결정하고 담당자는 온톨로지 관계로 결정해 심어둔 값이라 객관 채점됩니다. 단, 정답과 데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 추천 정확도는 비스텔리젼스 실 고객 설비 데이터와 실 현장 담당자가 있어야 측정 가능합니다. 이 도구는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다
이건 고객·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명하는 게 오히려 신뢰를 줍니다
정답 조치를 작성자가 만들었으니 잘 맞는 게 당연합니다. 그래서 센서 결측·정상 범위 경계·미등록 설비 같은 경계 케이스를 더미에 일부러 섞어, 쉬운 문제만 푸는 게 아님을 보여줍니다
이상의 원인은 상관이 인과가 아닐 수 있고 Agent는 근거 없는 조치를 지어낼 수 있습니다. 원인·조치는 근거 이벤트 인용을 강제하고, 실행은 사람 승인을 받으며, 모호하면 단정 대신 확인 권고로 표시합니다
설비·공정 표기가 데이터마다 제각각입니다. 온톨로지 마스터로 같은 설비로 묶고, 못 묶은 건 추측하지 말고 '미등록 설비'로 알립니다
실제 도입 시 달라지는 점을 명시합니다. 실 설비 데이터 분포·담당자 조직·조치 권한은 더미와 다르므로 온톨로지·이상 규칙을 다시 맞추고 검토자도 실제 현장 인력으로 교체해야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
제조 현장의 생산·품질·재고 이벤트. 이상 분석이 읽는 입력입니다. 센서 결측·경계값·미등록 설비·표기 흔들림을 일부러 섞어, 쉬운 데이터만 푸는 게 아님을 보여줍니다.
| event_id | machine_raw | machine_id | metric | value | event_time |
|---|---|---|---|---|---|
| e_001 | EQ-01 | eq_01 | defect_rate | 1.2 | 2026-05-01T09:00 |
| e_002 | EQ-01 | eq_01 | defect_rate | 8.7 | 2026-05-01T13:00 |
| e_003 | eq 01 | eq_01 | temp | — | 2026-05-01T13:05 |
| e_004 | EQ-02 | eq_02 | temp | 240 | 2026-05-01T10:00 |
| e_005 | EQ-02 | eq_02 | defect_rate | 2 | 2026-05-01T10:05 |
아래 JSON Schema({"type":"object","properties":{"event_id":{"type":"string"},"machine_raw":{"type":"string"},"machine_id":{"type":["string","null"]},"metric":{"enum":["defect_rate","temp","stock_qty"]},"value":{"type":["number","null"]},"event_time":{"type":"string"}},"required":["event_id","machine_raw","machine_id","metric","value","event_time"]})에 맞는 제조 운영 이벤트 더미 40행을 JSON 배열로 생성합니다. 설비 3~5종, 지표 defect_rate/temp/stock_qty. 모두 가상 더미.
쉬운 데이터만 만들지 말 것. 이상 정답이 임계 규칙으로 결정되게 심되 다음 하드 케이스를 의도적으로 섞어라(쉬운 문제만 푸는 함정 회피): (1) 센서 결측(value=null) 4건, (2) 경계값(defect_rate 임계 근처, temp 극단 240, stock_qty=0 결품) 3건, (3) 미등록 설비(machine_id=null) 2건, (4) 설비 표기 흔들림('EQ-01'/'eq 01'/'EQ-02 ') 3건. JSON 배열만.{"type":"object","properties":{"event_id":{"type":"string"},"machine_raw":{"type":"string"},"machine_id":{"type":["string","null"]},"metric":{"enum":["defect_rate","temp","stock_qty"]},"value":{"type":["number","null"]},"event_time":{"type":"string"}},"required":["event_id","machine_raw","machine_id","metric","value","event_time"]}설비·공정·담당자 관계와 이상별 정답 조치 온톨로지 마스터. 조치 추천이 대조하는 기준입니다. 미등록 설비·담당자 미지정·결측 임계를 일부러 섞어, 쉬운 데이터만 푸는 게 아님을 보여줍니다.
| row_id | machine_id | process | owner | metric | threshold | gold_action |
|---|---|---|---|---|---|---|
| o_001 | eq_01 | 조립 | 김반장 | defect_rate | 5 | 불량률 임계 초과 시 조립 라인 정지 후 김반장이 원인 점검 |
| o_002 | eq_01 | 조립 | 김반장 | stock_qty | 10 | 부품 재고 10 미만 시 김반장이 발주 요청 |
| o_003 | eq_02 | 건조 | 이기사 | temp | 200 | 건조로 온도 200 초과 시 이기사가 설정 온도 조정 |
| o_004 | eq_02 | 건조 | 이기사 | defect_rate | 5 | 불량률 임계 초과 시 이기사가 건조 조건 점검 |
| o_005 | eq_03 | 포장 | — | stock_qty | 5 | — |
아래 JSON Schema에 맞는 설비·공정·담당자 온톨로지 마스터 40행을 JSON 배열로 생성합니다. 지표 defect_rate/temp/stock_qty.
{"type":"object","properties":{"row_id":{"type":"string"},"machine_id":{"type":["string","null"]},"process":{"type":"string"},"owner":{"type":["string","null"]},"metric":{"enum":["defect_rate","temp","stock_qty"]},"threshold":{"type":["number","null"]},"gold_action":{"type":["string","null"]}},"required":["row_id","machine_id","process","owner","metric","threshold","gold_action"]}
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라: (1) 담당자 미지정(owner=null, gold_action=null) 2건, (2) 결측 임계(threshold=null, gold_action=null) 2건, (3) 미등록 설비 기본 규칙(machine_id=null) 1건, (4) 설비마다 지표별 정답 조치·담당자가 다른 정상 행 다수. gold_action은 owner·metric·threshold와 일관되게. JSON 배열만.{"type":"object","properties":{"row_id":{"type":"string"},"machine_id":{"type":["string","null"]},"process":{"type":"string"},"owner":{"type":["string","null"]},"metric":{"enum":["defect_rate","temp","stock_qty"]},"threshold":{"type":["number","null"]},"gold_action":{"type":["string","null"]}},"required":["row_id","machine_id","process","owner","metric","threshold","gold_action"]}| Python | 이상 분석·조치 추천 Agent·온톨로지 추론 규칙의 구현 언어 |
| TypeScript | 제조 운영 콘솔 화면·이상 카드·관계 그래프 뷰의 구현 언어 |
| JavaScript | 콘솔 글루 코드·근거 이벤트 하이라이트 렌더 |
| LLM | 이상 원인 후보 설명과 담당자별 조치 추천 문장을 생성 |
| RAG | 설비 매뉴얼·과거 조치 이력을 검색해 추천 조치의 근거로 제공 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(정답 조치 대조 채점 + 사람 승인 루프)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(도메인별 온톨로지·이상 규칙 재사용 블록화)로 진행합니다.
이벤트 1건의 이상·조치 카드. 짚은 이상 징후와 원인 후보, 담당자별 조치(근거 이벤트 인용·확신도), 사람 승인 필요 여부를 한 스키마로 담아 제조 운영 콘솔에 씁니다.
{"type":"object","properties":{"event_id":{"type":"string"},"anomaly":{"type":["string","null"]},"root_cause_candidates":{"type":"array","items":{"type":"string"}},"action":{"type":"object","properties":{"owner":{"type":["string","null"]},"todo":{"type":["string","null"]},"evidence_event":{"type":["string","null"]},"confidence":{"enum":["low","mid","high"]}},"required":["owner","todo","evidence_event","confidence"]},"checks":{"type":"object","properties":{"needs_human_approval":{"type":"boolean"},"unknown_machine":{"type":"boolean"},"note":{"type":["string","null"]}},"required":["needs_human_approval","unknown_machine","note"]},"hedge":{"type":["string","null"]}},"required":["event_id","anomaly","root_cause_candidates","action","checks","hedge"]}[
{
"input_ref": "e_002 (EQ-01 불량률 8.7 — 임계 5.0 초과)",
"output": {
"event_id": "e_002",
"anomaly": "조립 설비 EQ-01 불량률이 임계를 초과했습니다",
"root_cause_candidates": [
"직전 시각 EQ-01 온도 센서 결측으로 공정 조건 변동 가능",
"조립 부품 재고 부족으로 대체 부품 투입 가능"
],
"action": {
"owner": "김반장",
"todo": "조립 라인을 정지하고 원인을 점검합니다",
"evidence_event": "defect_rate 8.7 > threshold 5.0 (e_002)",
"confidence": "high"
},
"checks": {
"needs_human_approval": true,
"unknown_machine": false,
"note": "라인 정지는 담당자 승인 후 실행합니다."
},
"hedge": null
}
},
{
"input_ref": "e_006 (미등록 설비 EQ-03 재고 0)",
"output": {
"event_id": "e_006",
"anomaly": "재고 결품 가능성이 있으나 설비가 미등록입니다",
"root_cause_candidates": [
"설비 EQ-03이 온톨로지에 등록되지 않아 공정·담당자 매핑 불가"
],
"action": {
"owner": "박주임",
"todo": "설비를 등록한 뒤 재점검합니다",
"evidence_event": "stock_qty 0 (e_006)",
"confidence": "mid"
},
"checks": {
"needs_human_approval": true,
"unknown_machine": true,
"note": "EQ-03이 마스터에 없어 기본 규칙으로만 처리했습니다."
},
"hedge": "미등록 설비라 담당자·조치를 단정하지 않고 확인 권고합니다."
}
},
{
"input_ref": "e_003 (EQ-01 온도 결측)",
"output": {
"event_id": "e_003",
"anomaly": null,
"root_cause_candidates": [],
"action": {
"owner": null,
"todo": null,
"evidence_event": null,
"confidence": "low"
},
"checks": {
"needs_human_approval": false,
"unknown_machine": false,
"note": "온도 센서값이 결측이라 이상 판정을 보류합니다."
},
"hedge": "센서 결측으로 임계 판정이 불가해 조치를 내지 않습니다."
}
}
][자동 검증 — 코드가 매 출력마다 자동으로 거릅니다] 1) JSON Schema 형식 통과: 출력이 정한 필드·타입을 지키는지 검사하고, 어기면 거부합니다. 2) anomaly 가 이벤트와 온톨로지 임계를 비교한 규칙 결과와 일치하는지 코드가 자동 판정합니다 — 규칙으로 결정되는 이상을 임의로 바꾸지 못하게 합니다. 3) action.owner 가 온톨로지의 설비·공정 담당자 매핑과 일치하는지, evidence_event 가 실제 이벤트를 인용했는지 대조합니다 — 근거 없는 조치를 지어내지 못하게 합니다. 4) checks.unknown_machine 은 설비 마스터와 대조해, needs_human_approval 은 실행성 조치(라인 정지 등)면 true 로 코드가 강제합니다. 5) evidence_event 가 null 이면 action.confidence=high 를 금지합니다(근거 없는 단정 방지). [수동 검증 — 사람이 일부만 확인합니다] 1) 현장 검토자 2명이 같은 모호 사례의 조치를 따로 라벨링해, 두 사람 판단이 우연 이상으로 일치하는지 봅니다(Cohen's κ ≥ 0.6 — 0~1, 높을수록 일치). 2) 전체 출력의 5%는 사람이 직접 다시 확인합니다(spot check). [전제] 이상 정답은 임계 규칙으로, 담당자는 온톨로지 관계로 결정해 심어두므로, 추천 정밀도·재현율을 객관적으로 채점할 수 있습니다.