마키나락스 창원 AI Engineering Team 은 영남권 제조 현장에서 예측·이상탐지·예지보전·머신비전 AI 를 PoC부터 배포·운영까지 구축하고 MLOps 로 재학습까지 돌립니다. 설비 센서로 이상·예지보전 신호를 모델과 근거로 잡는 이 PoC 는 그 기술 코어(현장 데이터→이상탐지→근거→재학습)를 정면으로 입증합니다. 다만 이 공고는 FDE Lead(10년+·조직 구축·SI 리딩)이고 제조 공정 도메인 깊이·팀 리더십은 포트폴리오로 증명되지 않으므로 주장하지 않으며, 제조는 테마로만 닿게 했습니다. 센서 신호를 이상탐지와 정비 우선순위로 잇는 사슬은 단순 측정 조회 맥락으로는 그대로 만들 수 없습니다.
영남권 제조 현장에서 예측·이상탐지·예지보전·공정 최적화·머신비전 AI 시스템을 구축하는 창원 AI Engineering Team 입니다. 설비 이상탐지 PoC 가 직접 정렬됩니다.
데이터 수집부터 모델 학습·배포·모니터링·재학습까지 MLOps 파이프라인을 다룹니다. 재학습 포함 PoC 가 환경과 정렬됩니다.
고객 요구사항 분석부터 설계·개발·검증·배포·안정화까지 프로젝트 전체를 수행합니다. 이상탐지 PoC 가 비즈니스와 정렬됩니다.
설비 센서 측정(설비·라인·지표·측정값·정상 범위·모델 이상 점수·라벨·이상 플래그)을 받아, 규칙(임계 초과·모델 이상·추세 드리프트·결측)으로 점검이 필요한 설비를 잡고 어느 지표가 왜 위험한지 근거와 함께 보여줍니다. 임계는 규칙이, 이상 점수는 가벼운 이상탐지 모델(z-score·IsolationForest 수준)이 내고, LLM 은 근거 설명만 맡습니다. 새 데이터가 쌓이면 재학습으로 정상 기준을 갱신합니다. 설비·라인 마스터를 붙여 표기를 정규화합니다. 고장 확정이 아니라 정비 우선순위입니다.
마키나락스 창원 팀의 FDE 가 만드는 도구의 사용자는 제조 현장 정비·운영 담당자입니다. 설비별 센서를 그래프로 일일이 넘겨보며 이상을 찾던 일을, 한 화면에서 점검 설비와 근거를 함께 보고 싶은 사람입니다.
설비 센서를 한 스키마로 묶고 설비·라인 마스터를 붙이면, (a) 임계 초과·모델 이상·추세 드리프트를 규칙과 모델로 잡고, (b) 어느 지표가 왜 위험한지 LLM 이 측정 근거를 들어 풀며, (c) 새 데이터로 재학습해 정상 기준을 현장에 맞춥니다.
설비 센서를 받아 임계 규칙과 가벼운 이상탐지 모델로 점검 설비를 잡고 어느 지표가 왜 위험한지 근거 카드로 보여주는 동작하는 도구입니다. 데이터는 설비 센서를 가정한 더미로 시작합니다.
이상 판정을 더미에 심은 정답 라벨과 비교하고, 정비 검토자 2명이 라벨링해 정밀도·재현율과 일치도를 보여주는 화면입니다.
새 데이터로 정상 기준을 재학습하는 파이프라인과 설비·지표별 이상 추이를 누적 집계해 보여주는 화면입니다.
이상 시나리오 12종(임계 초과·드리프트·결측)을 넣으면, 이상 카드와 근거가 몇 초 안에 나오는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(측정값 null·미등록 설비·설비 표기 흔들림)을 넣어도 출력 형식(스키마)이 한 번도 안 깨집니다
더미에 심은 정답 라벨 40건 중 이상 판정이 일치한 게 36건(약 90%)입니다. 단, 라벨·데이터를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미데이터 자가채점이며, 실제 정밀도·재현율은 마키나락스가 다루는 실 설비 데이터와 실 정비 검토자가 있어야 측정 가능합니다. 이 도구는 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다
이건 고객·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 데이터 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명하는 게 오히려 신뢰를 줍니다
이 포트폴리오가 입증하는 것은 센서 데이터→이상탐지→근거→재학습으로 잇는 AI 파이프라인 기술입니다. 이 공고는 FDE Lead(10년+·조직 구축·SI 리딩)이고 제조 공정 도메인(FDC·설비 물리)·팀 리더십은 포트폴리오로 증명되지 않으므로 주장하지 않습니다. 제조는 테마로 닿게 했을 뿐이며, 모르는 도메인 깊이·리더십 경력은 면접에서 솔직히 말하는 편이 낫습니다
정답을 작성자가 만들었으니 잘 맞는 게 당연합니다. 그래서 측정값 누락·미등록 설비·임계 경계 같은 결측·경계 케이스를 더미에 일부러 섞어, 쉬운 이상만 잡는 게 아님을 보여줍니다
이건 고장 확정이 아니라 정비 우선순위입니다. 이상 설비는 규칙·모델이 결정하고 고장 여부는 단정하지 않으며 '점검·정비 권고'로 표시합니다
설비·라인 표기가 제각각입니다. 정규화로 같은 설비로 묶고, 못 묶은 건 추측하지 말고 '미매핑'으로 알립니다. 실제 도입 시 정상 범위·이상 기준이 더미와 다르므로 모델·임계를 다시 맞추고 온프레미스 배포·검토자도 실제로 교체해야 합니다(도입 단계 과제로 분리)
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
설비 센서 측정 로그. 이상 규칙·모델·근거 설명이 가장 먼저 질의하는 테이블입니다. 측정값 결측·미등록 설비·설비 표기 흔들림·임계/드리프트 경계값을 일부러 섞고, label 로 정답을 심어 자가채점합니다.
| row_id | equip_raw | equip_id | metric | value | low | high | anomaly_score | label | ts |
|---|---|---|---|---|---|---|---|---|---|
| sr_001 | 프레스 1호기 | eq_p1 | temp | 62 | 40 | 80 | 0.1 | normal | 2026-03-04T09:00 |
| sr_002 | 프레스1호기 | eq_p1 | temp | 96 | 40 | 80 | 0.93 | anomaly | 2026-03-05T09:00 |
| sr_003 | 용접 2호기 | eq_w2 | vibration | 3.1 | 0 | 5 | 0.2 | normal | 2026-03-04T10:00 |
| sr_004 | 용접 2호기 | eq_w2 | vibration | — | 0 | 5 | — | normal | 2026-03-04T11:00 |
| sr_005 | 신규설비X | — | current | 12 | 5 | 20 | 0.15 | normal | 2026-03-04T12:00 |
아래 Zod 스키마에 맞는 설비 센서 측정 60행 JSON 배열로 생성합니다. 설비 5~7개, 지표(temp/vibration/current) 분포, 정상 위주에 이상을 섞습니다. value 가 [low,high] 밖이거나 anomaly_score 가 높으면 label='anomaly'.
z.object({ row_id: z.string(), equip_raw: z.string(), equip_id: z.string().nullable(), metric: z.enum(["temp","vibration","current"]), value: z.number().nullable(), low: z.number(), high: z.number(), anomaly_score: z.number().nullable(), label: z.enum(["normal","anomaly"]), ts: z.string() })
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 이상만 잡는 함정 회피): (1) 같은 설비의 표기 별칭('프레스 1호기'/'프레스1호기', '용접 2호기'/'용접2호기'처럼 equip_master 로 정규화돼야 함) 3건 이상, (2) 미등록 설비(equip_id=null) 2건, (3) 결측: value/anomaly_score 가 null 인 행 각 1~2건, (4) 경계값 — 임계 직상회(value 가 high 를 살짝 초과)·정상 범위 안인데 모델 점수만 높은 드리프트(anomaly_score 0.78~0.93) 각 2건, (5) 같은 설비가 드리프트→임계 초과로 악화되는 시계열 2~3건. label 은 위 규칙대로 정직하게 부여. JSON 배열만.z.object({ row_id: z.string(), equip_raw: z.string(), equip_id: z.string().nullable(), metric: z.enum(["temp","vibration","current"]), value: z.number().nullable(), low: z.number(), high: z.number(), anomaly_score: z.number().nullable(), label: z.enum(["normal","anomaly"]), ts: z.string() })| Python | 센서 파서·이상탐지 모델·점검 규칙의 구현 언어입니다 |
| PyTorch | 이상탐지 모델 학습·추론을 가정합니다(소규모는 z-score·IsolationForest 로 대체) |
| Airflow | 적재·학습·재학습을 주기 실행하는 파이프라인 오케스트레이션입니다 |
| Docker | 온프레미스 현장 배포를 가정한 컨테이너 패키징입니다 |
| Kubernetes | 현장·프라이빗 클라우드 배포 대상 런타임을 가정합니다 |
| MLOps | 데이터→학습→배포→모니터링→재학습 루프 구성입니다 |
| Zod | 센서 입력과 LLM 출력의 런타임 형식 검증입니다 |
| Claude | 이상 설비 근거 설명 LLM 입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(탐지가 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(재학습 파이프라인·설비별 추이)로 진행합니다.
설비 1건의 이상 점검 카드. 이상 등급·요인·근거를 한 스키마로 담아 화면 카드에 씁니다. 고장 확정이 아니라 정비 우선순위입니다.
z.object({ equip_id: z.string().nullable(), metric: z.enum(["temp","vibration","current"]), severity: z.enum(["ok","watch","high","urgent"]), factors: z.array(z.enum(["threshold_exceed","model_anomaly","trend_drift","unmapped_equip","missing_metric"])), reason: z.string().min(20), evidence: z.string().min(8), hedge: z.string().nullable() })[
{
"input_ref": "sr_002 (프레스 1호기 온도 임계 초과 + 모델 이상)",
"output": {
"equip_id": "eq_p1",
"metric": "temp",
"severity": "urgent",
"factors": [
"threshold_exceed",
"model_anomaly"
],
"reason": "프레스 1호기 온도 96이 정상 범위 40~80 을 넘고 모델 이상 점수도 0.93 으로 높습니다. 과열로 인한 라인 정지 위험으로 정비 점검이 시급합니다. 고장 확정은 정비팀 몫입니다.",
"evidence": "value=96, high=80, anomaly_score=0.93",
"hedge": "정비 우선순위이며 고장 확정은 하지 않습니다"
}
},
{
"input_ref": "sr_009 (용접 2호기 정상 범위 안인데 모델 이상 — 드리프트)",
"output": {
"equip_id": "eq_w2",
"metric": "vibration",
"severity": "high",
"factors": [
"trend_drift",
"model_anomaly"
],
"reason": "진동 4.6 은 정상 범위 안이지만 평소 대비 패턴이 달라 모델 이상 점수가 0.78 입니다. 임계 전 드리프트 징후로 예지보전 점검을 권고합니다.",
"evidence": "value=4.6, high=5, anomaly_score=0.78",
"hedge": "임계 미초과라 즉시 고장은 아니며 추세 관찰이 필요합니다"
}
},
{
"input_ref": "sr_004 (용접 2호기 측정 결측)",
"output": {
"equip_id": "eq_w2",
"metric": "vibration",
"severity": "watch",
"factors": [
"missing_metric"
],
"reason": "진동 측정값과 모델 점수가 비어 있어 이상을 단정하지 않습니다. 센서·수집 점검과 데이터 재수집이 필요합니다.",
"evidence": "value=null, anomaly_score=null",
"hedge": "측정 결측이라 이상은 단정하지 않습니다"
}
},
{
"input_ref": "sr_005 (미등록 설비)",
"output": {
"equip_id": null,
"metric": "current",
"severity": "watch",
"factors": [
"unmapped_equip"
],
"reason": "설비가 마스터에 없어 이상을 단정하지 않습니다. 측정·점수는 정상이라 설비 등록 후 집계 반영이 필요합니다.",
"evidence": "equip_id=null, anomaly_score=0.15",
"hedge": "미등록 설비라 이상 등급은 추정하지 않습니다"
}
}
][자동 검증] 1. Zod parse 로 출력 형식(필드·enum)이 스키마를 통과하는지 확인합니다. 2. factors 가 규칙·모델 결과와 일치하는지 봅니다(임계 초과는 결정적 규칙, model_anomaly 는 점수 임계). 3. severity 를 더미에 심은 정답 label 과 비교해 정밀도·재현율을 계산합니다. 4. value/anomaly_score 가 null 이거나 미등록 설비면 단정을 보류하고 고장 단정 표현은 차단합니다. [수동 검증] 1. 정비 검토자 2명이 비동기로 이상 설비를 라벨링해 정밀도·재현율과 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체의 5% 를 사람이 직접 점검합니다.