파트리지시스템즈는 자율주행·스마트팩토리 등 물리적 세계의 데이터 병목을 푸는 피지컬 AI 데이터옵스 플랫폼 데이터반(databahn)을 만들고, FDE 는 고객 현장의 센서·영상·로그를 분석해 데이터 수집·전처리·모델 적용·검색·리포트 생성까지 end-to-end 워크플로우를 직접 구현합니다. 이기종 현장 데이터를 한 스키마로 모아 규칙으로 이상 이벤트를 잡고, 정비 문서를 검색해 근거로 인용하며 조치 리포트로 잇는 이 파이프라인은 그 end-to-end 사슬(수집·전처리 → 규칙 이상 검출 → 문서 검색·인용 → 조치 리포트)을 정면으로 입증합니다. 이 포트폴리오가 입증하는 것은 그 파이프라인 구현 기술이며, Databahn 경량화 엔진·VLM 영상 인식·Physical AI 도메인 깊이는 주장하지 않고 면접에서 솔직히 다룹니다. 센서·로그를 결함 사전·정비 문서와 잇는 이 사슬은 파트리지가 고객 현장에서 다루는 이기종 데이터와 정비 문서 맥락이 있어야 의미가 있어, 일반 로그 대시보드로는 그대로 만들 수 없습니다.
고객 현장의 센서·영상·로그를 분석해 풀어야 할 AI·Data 문제를 정의하고 모호한 요구를 기술 문제로 구조화합니다. 이 파이프라인의 이상 이벤트 검출·정의가 직접 정렬됩니다.
데이터 수집·전처리·모델 적용·검색·리포트 생성까지 하나의 워크플로우로 구현합니다. 수집·전처리부터 검색·리포트까지 잇는 이 파이프라인 골조가 정면으로 정렬됩니다.
PoC 에서 발견한 반복 가능한 문제 해결 패턴을 제품 기능으로 제안하는 데이터옵스 지향입니다. 재사용 코어와 도메인 교체층으로 나눈 이 파이프라인이 그 제품화와 정렬됩니다.
현장 설비 센서 창 집계(온도·진동·전류)와 설비 로그를 받아, 규칙(임계·지속 시간·결측·미등록 자산)으로 이상 이벤트를 검출하고, 각 이벤트에 맞는 정비 매뉴얼 절을 검색해 근거로 인용하며 조치 리포트를 만듭니다. 이상 이벤트 판정은 센서 임계 규칙으로, 정비 문서 선택은 검색 적중으로 결정하고, LLM 은 조치 리포트 문장 작성과 인용 보조만 맡습니다. Databahn 경량화 엔진이나 VLM 영상 인식을 만드는 게 아니라, 배포 현장이 남긴 이기종 데이터를 한 파이프라인으로 모아 이상 이벤트를 잡고 정비 문서로 조치를 잇는 도구입니다. (근거는 채용공고 정렬이고, 데이터는 작성자가 만든 더미입니다.)
파트리지시스템즈 FDE(현장 배포 엔지니어). 고객 현장의 센서·영상·로그를 받아 이상을 찾고 정비 문서를 뒤져 조치를 정하던 일을, 한 파이프라인에서 이상 이벤트·근거·정비 문서·조치 리포트를 함께 보고 싶은 사람입니다.
현장 센서·로그를 한 스키마로 모으면, (a) 규칙으로 이상 이벤트(과열·진동·전류 스파이크)를 검출하고, (b) 각 이벤트에 맞는 정비 매뉴얼 절을 검색해 근거로 인용하며, (c) 여러 자산·현장의 이기종 로그를 끊김 없이 하나의 조치 리포트 파이프라인으로 모읍니다.
이기종 센서·설비 로그를 한 스키마로 모아 규칙으로 이상 이벤트를 검출하고, 이벤트별로 정비 매뉴얼 절을 검색해 근거로 붙여 조치 리포트를 만드는 동작하는 파이프라인입니다. 데이터는 현장 배포를 가정한 합성 센서 로그와 정비 매뉴얼 더미로 시작하고, 영상은 VLM 이 만든 결함 태그 메타데이터를 가정해 소비합니다(영상 모델 학습·온프레미스 배포는 2·3주차).
이상 검출과 문서 검색을 심은 정답·현장 엔지니어 2명 라벨과 비교해 검출 정밀도·재현율과 검색 적중률(hit@1)을 보여주는 화면입니다.
Docker·Kubernetes 로 두 번째 현장 배포를 가정하고, 자산·결함 타입별 이벤트·조치 분포를 누적 집계해 반복 열화 자산을 보여주는 화면입니다.
이벤트 시나리오 12종(정상·과열·진동·전류 스파이크·센서 두절·미등록 자산)을 넣으면, 이상 이벤트·근거·매칭된 정비 문서·조치 리포트가 몇 초 안에 나오는 걸 시연합니다
일부러 만든 악성·결측 입력 30종(센서 값 결측·미등록 자산·자산 표기 흔들림·해당 문서 없음)을 넣어도 출력 형식(스키마)이 한 번도 안 깨지고, 진단에 필요한 신호가 비면 '진단 불가, 현장 확인 필요'로, 맞는 문서가 없으면 '해당 문서 없음'으로 정직하게 알립니다
더미에 심은 정답 60건 중 이상 이벤트 검출이 일치한 게 52건(약 87%), 정비 문서 검색이 정답 문서를 상위 1건으로 맞춘 게 48건(hit@1 약 80%)입니다. 단, 정답·센서 데이터·정비 문서를 모두 작성자가 만든 합성 기준이라 '성능 검증'이 아니라 '데모 조건에서의 동작'임을 명시합니다
진짜 성능 검증은 여기서 멈춥니다. 위 수치는 전부 작성자가 만든 더미 센서 로그·정비 문서 자가채점이며, 실제 검출 정밀도·검색 적중률은 파트리지시스템즈가 배포한 현장의 실 센서 데이터와 실 정비 문서, 실 현장 엔지니어가 있어야 측정 가능합니다. 이 파이프라인은 그 검증을 바로 돌릴 수 있는 상태까지 만듭니다
이건 고객·실데이터 없이 혼자 만든 포트폴리오입니다. 모든 수치는 합성 센서 로그·정비 문서 자가채점이라 성능 증명이 아닙니다. 면접에서는 데모 동작과 실검증 준비 상태로 솔직히 설명하는 게 오히려 신뢰를 줍니다
이 포트폴리오가 입증하는 것은 이기종 센서·로그를 한 스키마로 모으는 수집·전처리 + 규칙 기반 이상 이벤트 검출 + 정비 문서 검색(RAG)·근거 인용 + 조치 리포트 생성 파이프라인 기술입니다. Databahn 경량화 엔진·VLM 영상 인식·실시간 스트리밍 인프라·Physical AI 도메인 깊이는 포트폴리오로 증명되지 않으므로 주장하지 않으며, 그 깊이는 면접에서 모르면 모른다고 말하는 편이 낫습니다. 데모는 배포 현장이 남긴 이기종 데이터를 소비하는 파이프라인으로 기술만 입증합니다
정답을 작성자가 만들었으니 잘 맞는 게 당연합니다. 그래서 센서 값 결측·미등록 자산·자산 표기 흔들림·해당 문서 없음·임계 경계값 같은 케이스를 더미에 일부러 섞어, 쉬운 로그만 통과시키는 게 아님을 보여줍니다
이상 신호가 늘 한 원인은 아니고, 검색은 그럴듯한 엉뚱한 문서를 인용할 위험이 있습니다. 그래서 규칙은 여러 신호를 우선순위로 하나만 고르되 신호가 약하거나 결측이면 '진단 불가'로 돌리고, 리포트의 문서 인용은 검색된 정비 문서 본문의 substring 인지 강제 매칭하며 맞는 문서가 없으면 '해당 문서 없음'으로 둡니다
자산·부품 표기가 제각각입니다. 정규화로 같은 자산으로 묶고, 못 묶은 건 추측하지 말고 '미등록'으로 알립니다. 실제 도입 시 센서 임계·정비 문서·영상 결함 태그가 더미와 다르므로 설비별로 다시 맞춰야 하고, 실 현장 엔지니어 검수와 영상(VLM) 실연동은 도입 단계 과제로 분리합니다
① 인라인 샘플 · ② seed.json 다운로드 · ③ 증강 프롬프트. 세 층 모두 동일한 schema 에서 파생.
현장 설비 센서 창 집계 로그. 이상 검출 규칙이 가장 먼저 질의하는 테이블입니다. 센서 값 결측·미등록 자산·자산 표기 흔들림·임계 경계값을 일부러 섞고, fault_type 으로 정답을, gold_doc_id 로 검색 정답 문서를 심어 자가채점합니다.
| window_id | asset_raw | asset_id | temp_p95 | vibration_rms | current_spike_ratio | sustained_min | fault_type | gold_doc_id | ts |
|---|---|---|---|---|---|---|---|---|---|
| sw_001 | PUMP-01 | pump_01 | 62 | 2.1 | 1.1 | 0 | none | — | 2026-03-04T09:00 |
| sw_002 | PUMP-01 | pump_01 | 88.5 | 2.4 | 1.2 | 12 | overheat | doc_overheat_01 | 2026-03-04T10:00 |
| sw_003 | MOTOR-A | motor_a | 64 | 6.2 | 1.3 | 8 | vibration_high | doc_vibration_01 | 2026-03-04T11:00 |
| sw_004 | MOTOR-A | motor_a | 60 | 2 | 2.7 | 3 | current_spike | doc_current_01 | 2026-03-04T12:00 |
| sw_005 | PUMP 01 | pump_01 | 82 | 2.2 | 1.1 | 7 | overheat | doc_overheat_01 | 2026-03-04T13:00 |
아래 JSON Schema 에 맞는 현장 설비 센서 창 집계 60행 JSON 배열로 생성합니다. 자산 4~6대(pump·motor 계열), 정상 위주에 과열·진동·전류 스파이크·센서 두절을 섞습니다.
{"type":"object","properties":{"window_id":{"type":"string"},"asset_raw":{"type":"string"},"asset_id":{"type":["string","null"]},"temp_p95":{"type":["number","null"]},"vibration_rms":{"type":["number","null"]},"current_spike_ratio":{"type":["number","null"]},"sustained_min":{"type":"number"},"fault_type":{"enum":["none","overheat","vibration_high","current_spike","sensor_dropout","unmapped_asset","undiagnosable"]},"gold_doc_id":{"type":["string","null"]},"ts":{"type":"string"}},"required":["window_id","asset_raw","asset_id","sustained_min","fault_type","gold_doc_id","ts"]}
fault_type·gold_doc_id 규칙(우선순위 위에서부터 먼저 맞는 것 적용): (1) asset_id=null 이면 fault_type=unmapped_asset, gold_doc_id=null. (2) temp_p95·vibration_rms·current_spike_ratio 셋 다 null 이면 fault_type=sensor_dropout, gold_doc_id=doc_sensor_01. (3) 셋 중 일부만 null 이면 fault_type=undiagnosable, gold_doc_id=null. (4) temp_p95>80 이고 sustained_min>=5 이면 fault_type=overheat, gold_doc_id=doc_overheat_01. (5) vibration_rms>4.5 이면 fault_type=vibration_high, gold_doc_id=doc_vibration_01. (6) current_spike_ratio>2.0 이면 fault_type=current_spike, gold_doc_id=doc_current_01. (7) 그 외 정상이면 fault_type=none, gold_doc_id=null.
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(쉬운 로그만 통과시키는 함정 회피): (1) 같은 자산의 표기 별칭(asset_raw 'PUMP-01'/'PUMP 01'처럼 정규화 후 같은 asset_id 로 묶여야 함) 3건 이상, (2) 미등록 자산(asset_id=null) 3건(과열·진동처럼 이상으로 보이지만 자산 미등록이라 unmapped_asset 으로 가야 함), (3) 결측: 센서 일부 null 로 undiagnosable 2건과 전부 null 로 sensor_dropout 2건, (4) 경계값(임계 바로 위·아래): temp_p95 80/81, sustained_min 5, vibration_rms 4.5, current_spike_ratio 2.0 근처 각 2건. fault_type·gold_doc_id 는 위 규칙대로 정직하게. JSON 배열만.{"type":"object","properties":{"window_id":{"type":"string"},"asset_raw":{"type":"string"},"asset_id":{"type":["string","null"]},"temp_p95":{"type":["number","null"]},"vibration_rms":{"type":["number","null"]},"current_spike_ratio":{"type":["number","null"]},"sustained_min":{"type":"number"},"fault_type":{"enum":["none","overheat","vibration_high","current_spike","sensor_dropout","unmapped_asset","undiagnosable"]},"gold_doc_id":{"type":["string","null"]},"ts":{"type":"string"}},"required":["window_id","asset_raw","asset_id","sustained_min","fault_type","gold_doc_id","ts"]}정비 매뉴얼·조치 문서 코퍼스. 검색(RAG)이 이상 이벤트별로 관련 절을 찾는 대상입니다. 검색 정답은 sensor_window 의 gold_doc_id 와 일치하는 문서로 심습니다. 결함마다 표기가 살짝 다른 유사 문서(과열/발열)와 결함 키워드를 스치는 일반 안전 문서(distractor)를 일부러 섞어, 검색이 키워드만 겹치는 엉뚱한 문서를 고르지 않는지 보여줍니다.
표면 온도 P95 가 80도를 5분 이상 지속하면 과열로 판단합니다. 냉각수 유량과 흡기구 막힘을 먼저 점검하고, 부하를 20% 낮춘 뒤 온도 회복을 15분간 관찰합니다. 회복되지 않으면 라인을 멈추고 현장 엔지니어를 호출합니다.
장비 발열이 심할 때는 잠시 가동을 멈추고 식힌 뒤 다시 켭니다. 구버전 안내로 임계·지속 기준이 명시돼 있지 않아 정식 과열 대응 절차 문서를 우선 적용합니다.
아래 JSON Schema 에 맞는 정비 매뉴얼 문서 20개 JSON 배열로 생성합니다. 결함 전용 문서(overheat·vibration_high·current_spike·sensor_dropout)와 일반·distractor 문서(general)를 섞습니다.
{"type":"object","properties":{"doc_id":{"type":"string"},"title":{"type":"string"},"body":{"type":"string"},"fault_tag":{"enum":["overheat","vibration_high","current_spike","sensor_dropout","general"]},"asset_family":{"type":["string","null"]}},"required":["doc_id","title","body","fault_tag"]}
검색 정답 규칙: 각 결함 타입(overheat·vibration_high·current_spike·sensor_dropout)마다 임계·지속 기준이 본문에 명시된 정식 전용 문서를 1개씩 두고, 그 doc_id 가 sensor_window 의 gold_doc_id 와 일치하게 합니다(doc_overheat_01·doc_vibration_01·doc_current_01·doc_sensor_01).
쉬운 데이터만 만들지 말 것. 다음 하드 케이스를 의도적으로 섞어라(키워드만 겹치는 엉뚱한 문서를 고르는 함정 회피): (1) 같은 결함의 유사·구버전 문서(예: '과열'과 '발열'처럼 표기가 다르고 임계 기준이 빠진 참고 문서) 2~3건, 이때 정식 전용 문서가 검색 정답이어야 함, (2) 결함 키워드(과열·진동·전류)를 스치지만 즉시 조치 절차가 아닌 일반·예방·교정 문서(general) 4건 이상, 이것을 조치 근거로 고르면 오검색, (3) 정상·미등록·진단 불가 상황에는 대응 문서가 없어 검색이 '해당 문서 없음'을 반환해야 함을 전제로, general 문서가 그 빈자리를 억지로 채우지 않도록 본문에 '즉시 조치 절차가 아님'을 명시. JSON 배열만.{"type":"object","properties":{"doc_id":{"type":"string"},"title":{"type":"string"},"body":{"type":"string"},"fault_tag":{"enum":["overheat","vibration_high","current_spike","sensor_dropout","general"]},"asset_family":{"type":["string","null"]}},"required":["doc_id","title","body","fault_tag"]}| Python | 센서·로그 수집·전처리, 임계 규칙 검출 엔진, 정비 문서 검색(RAG), 리포트 백엔드를 구현하는 대표 언어입니다 |
| Docker | 수집·검출·검색 파이프라인을 컨테이너로 묶어 현장(온프레미스 폐쇄망 가정)에 그대로 올릴 수 있게 하는 배포 단위입니다 |
| Kubernetes | 자산·현장이 여러 곳으로 늘 때 수집·검색 워커를 나눠 돌리는 배포 골조입니다(3주차 확장 수단) |
| RAG | 검출된 이상 이벤트마다 정비 매뉴얼 문서에서 관련 절을 검색해 조치 근거로 인용하는 핵심 검색 계층입니다 |
| LLM | 검색된 정비 문서 절과 센서 값을 받아 현장 담당자용 조치 리포트 문장을 작성하는 생성 모델입니다(판정·문서 선택은 규칙·검색이 결정) |
| VLM | 영상 프레임의 결함 태그를 만든 비전-언어 모델을 가정한 메타데이터 어댑터입니다. 영상 모델 자체는 학습하지 않고 그 결함 태그만 이벤트 신호로 소비합니다 |
| Computer Vision | 센서·수치 외에 영상 결함 신호를 이상 이벤트로 해석하는 도메인 맥락입니다(VLM 결함 태그 경유) |
| MLOps | 파이프라인 실행·재현·회귀 검증을 자동화하는 골든셋 검증과 형식(스키마) 검증 계층입니다 |
✓ pass → 그대로 멈춰도 완결입니다. 더 키우려면 2주차(검출·검색이 맞았는지 확인)로 진행합니다.
✓ pass → 여기서 멈춰도 완결입니다. 더 키우면 3주차(여러 자산·현장으로 확장)로 진행합니다.
이상 이벤트 1건의 조치 리포트 카드. 이상 타입·요인·근거·검색된 정비 문서·조치를 한 스키마로 담아 화면 카드와 리포트에 씁니다. 이상 타입은 센서 임계 규칙으로, 정비 문서는 검색 적중으로 결정하고, 리포트 문장은 그 근거를 센서 값·문서 절 인용으로 풉니다.
{"type":"object","properties":{"window_id":{"type":"string"},"asset_id":{"type":["string","null"]},"fault_type":{"enum":["none","overheat","vibration_high","current_spike","sensor_dropout","unmapped_asset","undiagnosable"]},"factors":{"type":"array","items":{"enum":["high_temp","high_vibration","current_spike","sensor_missing","unmapped_asset","sustained_exceed"]}},"evidence":{"type":"string","minLength":8},"retrieved_doc_id":{"type":["string","null"]},"doc_citation":{"type":["string","null"]},"recommended_action":{"type":"string","minLength":8},"report_text":{"type":"string","minLength":20},"hedge":{"type":["string","null"]}},"required":["window_id","asset_id","fault_type","factors","evidence","retrieved_doc_id","recommended_action","report_text"]}[
{
"input_ref": "sw_002 (과열 지속)",
"output": {
"window_id": "sw_002",
"asset_id": "pump_01",
"fault_type": "overheat",
"factors": [
"high_temp",
"sustained_exceed"
],
"evidence": "temp_p95=88.5, sustained_min=12.0",
"retrieved_doc_id": "doc_overheat_01",
"doc_citation": "표면 온도 P95 가 80도를 5분 이상 지속하면 과열로 판단합니다",
"recommended_action": "냉각수 유량·흡기구 점검 후 부하 20% 저감, 15분 관찰",
"report_text": "pump_01 표면 온도 P95 가 88.5도로 12분 지속돼 과열 임계를 넘었습니다. 정비 매뉴얼(과열 대응 절차)에 따라 냉각수 유량과 흡기구 막힘을 점검하고 부하를 20% 낮춰 15분간 온도 회복을 관찰하도록 권합니다.",
"hedge": "합성 기준 임계라 실제 설비에서는 냉각 사양별 임계 재설정이 필요합니다"
}
},
{
"input_ref": "sw_004 (전류 스파이크)",
"output": {
"window_id": "sw_004",
"asset_id": "motor_a",
"fault_type": "current_spike",
"factors": [
"current_spike"
],
"evidence": "current_spike_ratio=2.7",
"retrieved_doc_id": "doc_current_01",
"doc_citation": "전류 스파이크 비율이 기준 대비 2.0 배를 넘으면 순간 과부하로 판단합니다",
"recommended_action": "기동 시퀀스·결선 접촉 점검, 반복 시 인버터 보호 설정 확인",
"report_text": "motor_a 전류 스파이크 비율이 2.7 배로 순간 과부하 임계를 넘었습니다. 정비 매뉴얼(전류 스파이크 조치 절차)에 따라 기동 시퀀스와 결선 접촉 불량을 점검하고, 반복되면 인버터 보호 설정을 확인해 부하를 분산하도록 권합니다.",
"hedge": null
}
},
{
"input_ref": "sw_006 (미등록 자산)",
"output": {
"window_id": "sw_006",
"asset_id": null,
"fault_type": "unmapped_asset",
"factors": [
"unmapped_asset"
],
"evidence": "asset_id=null, asset_raw=펌프1호",
"retrieved_doc_id": null,
"doc_citation": null,
"recommended_action": "자산 마스터 등록 후 재평가",
"report_text": "asset_raw '펌프1호' 가 자산 마스터에 없어 asset_id 로 정규화되지 않았습니다. 온도가 높아 보여도 자산이 미등록이라 이상을 단정하지 않고, 자산 등록 후 재평가하도록 검토로 돌립니다. 해당 상황에 대응하는 정비 문서가 없어 '해당 문서 없음'으로 둡니다.",
"hedge": "자산 등록 전에는 이상 판정과 문서 매칭을 신뢰할 수 없습니다"
}
},
{
"input_ref": "sw_008 (센서 일부 결측)",
"output": {
"window_id": "sw_008",
"asset_id": "motor_b",
"fault_type": "undiagnosable",
"factors": [
"sensor_missing"
],
"evidence": "vibration_rms=null, temp_p95=85.0",
"retrieved_doc_id": null,
"doc_citation": null,
"recommended_action": "센서 로그 복구 후 재평가, 현장 확인",
"report_text": "motor_b 온도가 85도로 높아 보이나 진동 신호가 비어 이상 원인을 가릴 근거가 부족합니다. 단정하지 않고 센서 로그 복구 후 재평가하도록 현장 확인으로 돌립니다.",
"hedge": "일부 센서 결측이라 과열로 확정하지 않고 진단 불가로 둡니다"
}
}
][자동 검증] 1. 출력 형식(필드·enum·minLength)이 JSON Schema 를 통과하는지 확인합니다. 2. fault_type 이 센서 임계 규칙(미등록→unmapped_asset·전 센서 결측→sensor_dropout·일부 결측→undiagnosable·temp_p95>80 & 지속 5분→overheat·vibration_rms>4.5→vibration_high·current_spike_ratio>2.0→current_spike·그 외 none)과 일치하는지 봅니다. 3. evidence 가 입력 창의 실제 센서 값 인용인지 토큰 매칭으로 확인하고, 필요한 신호가 결측이면 fault_type 이 정상 이상으로 확정되지 않게 강제합니다. 4. retrieved_doc_id 가 심은 gold_doc_id 와 일치하는지(검색 hit@1) 확인하고, doc_citation 이 그 문서 body 의 substring 인지 매칭합니다. gold_doc_id 가 null 이면 retrieved_doc_id·doc_citation 도 null('해당 문서 없음')이어야 합니다. 5. fault_type 을 심은 정답과 비교해 검출 정밀도·재현율을, retrieved_doc_id 를 gold 와 비교해 검색 적중률을 계산합니다. [수동 검증] 1. 현장 엔지니어 2명이 비동기로 이상 타입·조치를 라벨링해 정밀도·재현율과 bootstrap Cohen's κ(두 사람 일치가 우연 이상인 정도, 0~1) 하한 0.6 이상을 봅니다. 2. 전체의 5% 를 사람이 직접 점검합니다.