Industrial IT Portfolio
한재민
센서 수집부터 이상예지 AI까지, 현장에서 돌아가는 시스템을 만드는 제조 AI 개발자
AI의 가치는 벤치마크 숫자가 아니라 현장에서 끝까지 돌아가는 데 있다고 믿습니다. 그래서 모델 성능보다 '현장에 정착하는 시스템'을 만드는 데 집중해 왔습니다. 학부 연구생으로 신호분석·산업 AI를 시작해 석사에서 예지보전을 연구했고, 졸업 전 스카우트되어 요구사항 협의부터 개발·서버 설치·운영까지 직접 반복하며 실무를 다졌습니다. 센서 수집 서버부터 API·DB, 운영 화면, 알람, AI 진단까지 하나의 흐름으로 잇고 장애까지 직접 책임집니다. 국책 3건·기업 납품 3건, 누적 등록 설비 392대 규모 플랫폼을 만들고 그중 6개 현장을 직접 구축·운영했고, 공작기계 AI 진단은 실 운용에서 불량 9건을 감지했으며, 지하배관에서는 AE 누수 위치추정을 평균 오차율 2.37%로 올렸습니다. 최근에는 설비 매뉴얼·정비 데이터를 근거로 답하는 온프레미스 RAG 진단 에이전트(전문가 호출 5→1 중복 제거로 호출 비용 ~20배 절감)로 폭을 넓히며, 구축에서 멈추지 않고 개선과 현장 적용으로 가치를 만듭니다.
제조 AI·산업 데이터
설비 이상예지 모델(스펙트로그램 CNN 98%+·의사결정트리 92%·AE 위치추정 오차 2.37%), Vision 접근 PoC, 제조 데이터 거버넌스(시계열 전환·메타데이터 카탈로그), AI 인프라 운영 경험을 중심으로 구성합니다.
울산대학교 · 학사
IT융합학부 · 2017–2023 · 전공학점 3.81/4.5
울산대학교 대학원 · 석사
전기전자컴퓨터공학과 · 2023–2025 · 석사 연구: MCT 테스트베드에서 수집한 진동 데이터를 기반으로 공작기계 설비 건전성 진단을 위한 신호처리와 상태 분류를 연구했습니다. 1D-CNN, Ta…
선임연구원 / 제조 AI·데이터 플랫폼 개발자 · 2025.03 - 현재
진동·AE·온도·가스·PLC 5종 설비 데이터를 수집 서버→REST/WebSocket API→InfluxDB·MySQL·Redis 3종 DB→운영 화면·알람·AI 진단 이력으로 잇는 예지보전 플랫폼을 개발해, 6개 현장 직접 구축·운영(플랫폼 누적 등록 현장 32개)…
NestJS / Node.js / TypeScript / REST API / WebSocket / Socket.IO / TypeORM (ORM)
Python / PyTorch / STFT / 2D 스펙트로그램 (Spectrogram) / DTW (Dynamic Time Warping) / 포락 스펙트럼 (Envelope Spectrum)
Vue.js / TypeScript / SCSS/Sass / SciChart / ECharts / Chart.js
InfluxDB (시계열) / MySQL / MySQL / Redis (ioredis) / SQL / 시계열 데이터 파이프라인 / ETL / Query Optimization
지원 직무 적합 근거
제조 AI — 설비 이상예지·데이터 플랫폼 개발자
이상예지 모델 개발
스펙트로그램 CNN·DTW 이상탐지 98%+(데이터셋 기준), 의사결정트리 다중분류 92%, AE 누수 위치추정 평균 오차율 2.37% — 모두 현장 시스템에 탑재·운용
AI·Vision 활용 PoC
진동 신호를 공정별 2D 스펙트로그램 이미지로 변환해 CNN 학습(과제 중 실결함 1건 100% 탐지), 석사 연구(1D-CNN·TabNet·XAI)를 제품 기능으로 확장
데이터 거버넌스·품질
단일 RDB를 Redis·InfluxDB·MySQL 3계층으로 분리(1년치 집계조회 203배, 캐시 적중률 98.29%), 보존정책·다운샘플 체계화, 센서 모델·특징값 메타데이터 카탈로그화, PLC 역분석·전기 노이즈 규명으로 품질 확보
AI 인프라 운영
AI 서빙 서버(알고리즘 9계열·44 라우트)와 16개 앱 진단 오케스트레이션, Docker·CI/CD, 코어 DB 6주+ 무중단 운영
※ 모든 수치는 운영 DB 실측(2026-07) 또는 과제 산출물 기준이며, 재현 가능한 측정 쿼리·스크립트를 보존하고 있습니다. 규모 지표(사이트·설비·포인트)는 멀티테넌트 플랫폼 누적 등록 기준이며, 저장 16배는 대표 앱 기준(타 앱 9.6~14.2배)입니다.
센서·설비 데이터를 3계층 저장 플랫폼(Redis·InfluxDB·MySQL, 1년치 집계조회 203배)과 운영 화면·알람·AI 진단으로 연결한 예지보전 플랫폼
진동을 2D 스펙트로그램 이미지로 변환해 CNN·DTW로 이상탐지 98%+를 구현·탑재한 Vision 기반 설비 진단
1차년도 11개 배관·센서 87개(진동 44·AE 43)를 직접 설치하고 AE 누수 위치추정(오차 2.37%)까지 구축해 운용 중인(고도화 14개 배관 진행, 총 25개)…
현장 문서·데이터를 외부 유출 없이 다루는 온프렘 RAG·에이전트 LLM 구축 — 배관 관제의 로컬 LLM 일일 진단보고서와 이어지는 AI 인프라 경험
2023.10 - 2026.05
제조 설비 예지보전 모니터링 플랫폼
개요
진동·AE·온도·가스·PLC 등 설비 상태 데이터를 수집 서버에서 API, DB, 운영 화면으로 연결하고 Raw 조회, Trend, Spectrum, STFT, 대시보드, 알람, 진단 이력, 관리자 모드와 서버-DB 운영 안정화까지 구현한 산업 IoT 플랫폼입니다.
센서·설비 데이터를 3계층 저장 플랫폼(Redis·InfluxDB·MySQL, 1년치 집계조회 203배)과 운영 화면·알람·AI 진단으로 연결한 예지보전 플랫폼
문제
-장 설비 데이터가 여러 수집 경로, DB, 화면에 나뉘어 있어 운영자가 설비 상태와 이상 징후를 빠르게 확인하기 어려웠습니다. 고주파 Raw 데이터, 통신 장애, 메모리 부하, DB 권한·포트 이슈, 현장별 알람 기준 차이도 수집 안정성과 기능 반영 속도에 영향을 줬습니다.
-장 설비 데이터가 여러 수집 경로, DB, 화면에 나뉘어 있어 운영자가 설비 상태와 이상 징후를 빠르게 확인하기 어려웠습니다. 고주파 Raw 데이터, 통신 장애, 메모리 부하, DB 권한·포트 이슈, 현장별 알람 기준 차이도 수집 안정성과 기능 반영 속도에 영향을 줬습니다.
해결
설비/공정/라인 구조를 UI와 DB에 반영하고 Raw 수집 주기 설정, 데이터 갱신, 다운로드, 임계치 알람, 진단 이력 조회, 관리자 기능을 구현했습니다. 데이터 수집·저장·조회 흐름에서는 InfluxDB, MySQL, Redis 역할을 나누고 웹/소켓 서버 분리, Docker Compose, 서버 이전, 백업/복원, 버전 업그레이드까지 운영 관점에서 정리했습니다.
설비/공정/라인 구조를 UI와 DB에 반영하고 Raw 수집 주기 설정, 데이터 갱신, 다운로드, 임계치 알람, 진단 이력 조회, 관리자 기능을 구현했습니다. 데이터 수집·저장·조회 흐름에서는 InfluxDB, MySQL, Redis 역할을 나누고 웹/소켓 서버 분리, Docker Compose, 서버 이전, 백업/복원, 버전 업그레이드까지 운영 관점에서 정리했습니다.
성과
- 운영자가 Raw/Trend/알람/진단 데이터를 한 흐름에서 확인할 수 있는 화면 구조 구현
- 진동·AE·온도·가스·PLC 5종 설비 데이터를 수집 서버, API/DB, 운영 화면에 연결
- Raw 수집 주기 설정과 고주파 데이터 조회 흐름 구현
- 현장 실증 피드백을 화면, DB, 알람 조건, 매뉴얼·보고 산출물에 반영
현장 적용·문서 대응
운영자 화면은 차트만으로 완성되지 않았고 수집 상태, DB 역할, 알람 기준, 진단 이력, 관리자 설정, 배포 환경이 함께 맞아야 했습니다. 원본 데이터 보존과 화면 표시 보정, 수집 서버와 API/DB의 장애 경계를 함께 정리했습니다.
대용량 시계열 조회 성능 저하 → 저장 계층 3분할
최근값·장기 이력·메타를 성격이 다른데도 관계형 DB 한 곳에 저장했고, 센서 포인트가 급증하며 인덱스가 비대해져 실시간 조회 성능이 급락했습니다.
역할 저장 구조 재설계·구현 담당
- 대시보드 최근값·알람 체크는 Redis 실시간 캐시로 분리
- 원본 전량은 InfluxDB에 저장하고 Continuous Query로 장기 다운샘플(hot/cold 라우팅)
- 메타·이력은 관계형 DB 전담으로 남기고 시간 파티션 샤드로 조회 최적화
결과 집계 조회 203배(13.4s→66ms) 단축 · 관계형 증가 ~137GB/년 억제 · 프로덕션 캐시 적중 98.29% [실측]
이식·버전업 제약 → Docker 컨테이너화 + CI/CD
컨테이너 기반이 아니어서 서버 이전·버전 업그레이드에 제약이 컸고, 개발·운영 서버가 분리되지 않아 검증 없이 반영되며 오류가 잦았습니다.
역할 컨테이너화·배포 흐름 구축
- 웹·DB·부가 서비스 계층을 Docker Compose로 컨테이너화
- 개발·운영 서버를 분리하고 Nginx 라우팅을 정리
- Git 브랜치+PR 전략 도입(develop→개발서버 자동배포·검증→master 운영 배포)
결과 클린 호스트에서 DB 스택 cold-start 약 28초, 단계별 배포 흐름 확립으로 반영 오류 감소
5단계 설비 확인 → 공정별 1화면 통합
설비 상태를 보려면 공정>설비>포인트>분석까지 여러 화면을 옮겨 다녀야 했고, 현장마다 설비 계층·센서 구성·알람 기준이 달라 반영이 번거로웠습니다.
역할 운영 화면·관리자 기능 구현
- 공정별 대시보드 1화면으로 Raw·Trend·STFT·알람·진단 이력을 통합
- 설비/라인/센서 메타·임계치·표시 기준을 관리자 기능에서 수정 가능하게 구현
- 규칙 기반·AI 진단 결과를 공통 저장·조회·알람 흐름에 연결
결과 5단계 화면 전환을 1화면으로 통합하고 11개 앱 도메인을 멀티테넌트로 운용
2023.12 - 2026.05
공작기계/MCT 신호분석 및 AI 진단
개요
공작기계와 회전 설비의 진동 데이터를 기반으로 STFT, FFT, 스펙트럼, CNN, One-Class SVM 분석을 수행하고 진단 화면과 알람 흐름으로 연결했습니다.
진동을 2D 스펙트로그램 이미지로 변환해 CNN·DTW로 이상탐지 98%+를 구현·탑재한 Vision 기반 설비 진단
문제
원시 신호만으로는 현장 운영자가 설비 이상을 판단하기 어렵기 때문에, 신호처리 결과와 AI/규칙 기반 진단 결과를 화면에서 해석 가능한 형태로 제공해야 했습니다.
원시 신호만으로는 현장 운영자가 설비 이상을 판단하기 어렵기 때문에, 신호처리 결과와 AI/규칙 기반 진단 결과를 화면에서 해석 가능한 형태로 제공해야 했습니다.
해결
STFT 기간 조회, 스펙트럼/스펙트로그램 차트, 공구 상태 UI, 라벨링 프로그램, 이상치 보정, 규칙 기반 진단 차트, AI 진단 결과 저장 흐름을 구현했습니다.
STFT 기간 조회, 스펙트럼/스펙트로그램 차트, 공구 상태 UI, 라벨링 프로그램, 이상치 보정, 규칙 기반 진단 차트, AI 진단 결과 저장 흐름을 구현했습니다.
성과
- STFT, 스펙트럼, 스펙트로그램 기반 설비 진단 화면 구현
- AI/규칙 기반 진단 결과를 운영 화면과 알람 흐름에 연결
- 석사 연구의 신호처리·상태분류 경험을 제품 기능과 기술 문서로 확장
현장 적용·문서 대응
AI 진단 결과는 실험 파일로 남는 것보다 현장 사용자가 해석할 수 있는 화면, 저장 이력, 알람 흐름으로 연결될 때 제품 가치가 생겼습니다. STFT/FFT/모델 결과를 운영 UI에 맞게 구현했습니다.
문서·담당자 없는 PLC → 역분석해 공정 데이터 소스화
절삭 시점·공구 사용 횟수 같은 공정 상태를 담은 PLC 데이터가 필요했지만 매뉴얼도, 이를 아는 담당자도 없었습니다.
역할 PLC 역분석·공정 라벨링 담당
- 저장된 PLC 데이터를 연구원과 함께 역분석해 의미를 규명
- 공정 시작 시점·공구 교체 구간을 메타데이터로 구조화
- 공구 교체 기준 STFT 페이징에 PLC 사용 횟수를 분 단위로 연동
결과 공정 상태 라벨을 확보해 센서 신호와 결합한 학습 데이터 구성 기반을 마련
스펙트럼만으로 분류 성능 부족 → 공정별 2D 스펙트로그램·DTW 결합
기존 스펙트럼 데이터만으로는 이상 분류 성능이 확보되지 않아 원인을 분석하고 표현 방식을 바꿔야 했습니다.
역할 신호처리·모델 설계·탑재 담당
- 진동 신호를 공정별 2D 스펙트로그램 이미지로 변환해 CNN 학습
- 정상 레퍼런스와 DTW 특징 비교를 결합해 이상 판정
- 정상/베어링/기어/공구 4분류를 1D-CNN·TabNet·OC-SVM으로 서빙
결과 데이터셋 기준 평균 98% 이상 이상탐지를 구현·현장 탑재하고, 실 운용에서 불량 9건을 사전 감지
저장 용량 폭증 → 회전 성분 기반 특징 추출 경량화
진동 데이터를 전 주파수로 저장하면 용량이 커 중소 제조 현장에서는 운영이 어려웠습니다.
역할 석사 연구·현장 적용
- 회전 성분을 기준으로 정보가 큰 대역은 촘촘히, 낮은 대역은 로그 스케일 대표값으로 추출
- 경량화된 특징으로 TabNet·1D-CNN 다중분류 학습
- 모니터링 시스템에 적용해 과제 실증에서 안정 동작 확인
결과 데이터를 경량화하면서도 분류 성능은 오히려 향상됨을 석사 논문으로 검증
2024.01 - 2026.04
스마트그린산단/지하배관 관제 시스템 개발
개요
지하배관 24개에 진동·AE 센서를 직접 설치하고 P-LTE로 자체 웹 서버에 연결해 실시간 모니터링·규칙 기반 진단·AE 기반 누수 위치 추정까지 구축한 현장 운용 시스템입니다. 배관·맨홀·관제센터 계층 구조, 센서 위치/특징값, RawData 수집, 외부 예측진단 API 연동, 모바일 QR, CI/CD를 담당했습니다.
1차년도 11개 배관·센서 87개(진동 44·AE 43)를 직접 설치하고 AE 누수 위치추정(오차 2.37%)까지 구축해 운용 중인(고도화 14개 배관 진행, 총 25개) 현장 관제 시스템
문제
센서 위치 좌표 누락, 특징값 미수신, 관제센터 API 연동, 지하배관 용어·계층 정리가 혼재하여 관제 화면에서 배관·맨홀·포인트 상태를 일관되게 보여주기 어려웠습니다.
센서 위치 좌표 누락, 특징값 미수신, 관제센터 API 연동, 지하배관 용어·계층 정리가 혼재하여 관제 화면에서 배관·맨홀·포인트 상태를 일관되게 보여주기 어려웠습니다.
해결
배관·맨홀·포인트 계층과 센서 위치를 정리해 지도 화면에 반영하고, 외부 예측진단 API 연동, 모바일 QR 기반 현장 조회, CI/CD와 개발/운영 서버 분리까지 수행했습니다.
배관·맨홀·포인트 계층과 센서 위치를 정리해 지도 화면에 반영하고, 외부 예측진단 API 연동, 모바일 QR 기반 현장 조회, CI/CD와 개발/운영 서버 분리까지 수행했습니다.
성과
- 진동·AE 센서를 24개 배관에 직접 설치하고 P-LTE로 자체 웹 서버에 연결해 실시간 수집·규칙 기반 진단 운용(현재 운용 중)
- AE 신호 기반 배관 누수(Leak) 위치 추정 알고리즘을 실증 테스트베드 데이터로 검증 후 시스템에 탑재
- 진동·AE 데이터를 종합해 매일 진단보고서를 생성하는 로컬 LLM 기능 개발
현장 적용·문서 대응
외부 API와 현장 계층 구조가 함께 엮인 시스템에서는 용어, 위치, 센서 좌표, 임계치 조건을 먼저 정리해야 구현 속도가 안정됩니다. 데이터 보정 범위와 협업 비용을 줄였습니다.
이기종 현장 단말 연결 + 전송 불안정 → P-LTE 경로 분리로 데이터 유실 방지
지하배관 현장의 센서·게이트웨이를 전용 P-LTE 망으로 자체 웹서버까지 이어야 했고, 외부 기관 전송이 불안정할 때도 데이터가 유실되면 안 됐습니다.
역할 수집 연동·서버 경로 설계
- 센서·게이트웨이 데이터를 P-LTE로 자체 웹서버에 실시간 연결
- 외부 전송이 불안정해도 로컬 저장은 반드시 성공하도록 수집 경로를 분리
- 외부 관제센터 예측진단 API를 연동하고 임계치 초과 시 전송값을 필터링·보정
결과 1차년도 배관 11개에 진동·AE 센서 87개(진동 44·AE 43)를 실시간 수집·운용(고도화 14개 진행, 총 25개)
기관마다 다른 좌표 체계 → 배관·맨홀·포인트 3단계 위치 표준
여러 업체가 참여해 배관·센서를 가리키는 단위와 위치 체계가 제각각이라 통합 과정에서 혼선이 있었습니다.
역할 위치 데이터 모델·협의 담당
- 배관·맨홀·포인트 3단계 위치 계층으로 표준을 정의
- 관계 기관과 용어·좌표 기준을 협의해 일관된 체계로 정리
- 표준 위치를 지도 화면에 연동해 센서·배관 위치를 표시
결과 위치 기준을 통일해 사고·결함 시 정확한 위치 전달 기반을 마련
누수 위치 파악 → AE 신호 기반 위치추정 알고리즘 탑재
지하배관 누수 발생 위치를 신호로 추정해 현장 대응으로 이어야 했습니다.
역할 알고리즘 연동·화면·저장 구현·검증
- 연구원이 개발한 AE 누수 위치추정 알고리즘을 모니터링 화면·저장 로직으로 구현
- 실증 테스트베드 데이터로 반복 검증하며 안정적으로 탑재
- 진동·AE 데이터를 종합한 일일 진단 보고서 생성(로컬 LLM) 기능과 연결
결과 AE 누수 위치추정 평균 오차율 2.37%(실증 테스트베드, 최저 1.27%)
2026.05 - 2026.06
온프레미스 RAG·Agent LLM 시스템
개요
외부 API 없이 사내 GPU 서버에서 동작하는 설비 유지보수 전문가 AI 시스템입니다. 문서 기반 RAG, 하이브리드 검색, Tool Calling Agent, 품질 가드레일, 관측성 지표를 구현했습니다.
현장 문서·데이터를 외부 유출 없이 다루는 온프렘 RAG·에이전트 LLM 구축 — 배관 관제의 로컬 LLM 일일 진단보고서와 이어지는 AI 인프라 경험
문제
제조·플랜트 환경의 설비 매뉴얼과 정비 이력은 외부 API로 보내기 어려운 기밀 데이터이므로, 내부망에서만 동작하면서도 문서 근거가 있는 답변과 복합 추론을 제공해야 했습니다.
제조·플랜트 환경의 설비 매뉴얼과 정비 이력은 외부 API로 보내기 어려운 기밀 데이터이므로, 내부망에서만 동작하면서도 문서 근거가 있는 답변과 복합 추론을 제공해야 했습니다.
해결
Ollama 기반 로컬 LLM, BGE-M3 임베딩, Chroma 벡터 DB, BM25, Cross-Encoder 리랭커를 결합하고, FastAPI로 RAG·스트리밍·Agent API를 제공했습니다. 응답 품질은 사전 방어와 사후 검증 레이어로 관리했습니다.
Ollama 기반 로컬 LLM, BGE-M3 임베딩, Chroma 벡터 DB, BM25, Cross-Encoder 리랭커를 결합하고, FastAPI로 RAG·스트리밍·Agent API를 제공했습니다. 응답 품질은 사전 방어와 사후 검증 레이어로 관리했습니다.
성과
- 외부 API 없이 내부 서버에서 동작하는 설비 유지보수 질의응답 구조 설계
- Vector Search + BM25 + RRF + Cross-Encoder 기반 하이브리드 검색 구현
- Tool Calling Agent로 문서 검색, 현재 시간, 계산 도구를 조합한 복합 질문 처리
현장 적용·문서 대응
기업 실증, 현장 적용, 보고서·매뉴얼·시연 자료 대응은 프로젝트 수행 전반에 함께 반영했습니다.
외부 반출 불가 설비 데이터 → 온프레미스 로컬 LLM RAG
설비 유지보수 자료는 외부 API로 보낼 수 없어, 폐쇄망 안에서만 도는 질의응답 구조가 필요했습니다.
역할 RAG 파이프라인·서버 설계
- 외부 API 없이 내부 서버에서 동작하는 로컬 LLM(Ollama) 기반 질의응답 구성
- chat·streaming·upload·RAG·Agent·metrics 등 7개 엔드포인트로 구조화
- Docker Compose로 폐쇄망에 이식 가능하게 패키징
결과 설비 매뉴얼·정비 자료를 외부 반출 없이 근거 기반으로 답하는 사내 에이전트 구축
근거 없는 답변·환각 → 하이브리드 검색 + 이중 가드레일
정비 판단에 쓰려면 출처 없는 답변이나 환각을 구조적으로 막아야 했습니다.
역할 검색·품질 파이프라인 구현
- Vector Search + BM25 + RRF 융합 + Cross-Encoder 리랭킹 하이브리드 검색
- 사전 방어 + 사후 검증 + 최대 3회 자동 재시도로 응답 품질 관리
- LLM-as-Judge 품질 평가를 비동기 백그라운드로 분리
결과 근거 문서가 없으면 답을 거부하고 출처를 강제해 환각을 차단
복합 질문·운영 관측 → Tool Calling Agent + 관측성 API
단순 검색을 넘어 계산·시간 등 도구를 조합한 복합 질문 처리와, 운영 상태를 지표로 볼 방법이 필요했습니다.
역할 에이전트·관측성 구현
- 문서 검색·현재 시간·계산 도구를 조합하는 Tool Calling Agent 구현
- P95/P99 레이턴시·차단율·품질 점수를 SQLite에 기록하는 관측성 API 구현
결과 복합 질문을 처리하면서 응답 지연·차단·품질을 지표로 추적 가능하게 구성
Other Projects / Research / Certifications
대표 프로젝트 외에도 직무 연관성이 있는 연구, 개인 프로젝트, 수상·자격 근거를 압축했습니다.
PredicTrade: LLM 결합 암호화폐 알고리즘 트레이딩 시스템
2026.01 - 현재실자본으로 운용 중인 암호화폐 알고리즘 트레이딩 시스템입니다. 9개 마이크로서비스 기반으로 거래소 WebSocket/REST 데이터, 온체인·뉴스 데이터, 17개 이상 전략 앙상블, LightGBM 메타 레이블링, HMM 레짐 감지, 50개 이상 진입 게이트, LLM 손실 복기 루프를 연결했습니다. 단순 자동매매가 아니라 데이터 신뢰성, 신호 검증, 리스크 제어, 운영 관측성을 함께 검증하는 개인 AX 자동화 프로젝트입니다.
드라이브·앤·컨트롤 2024 춘계학술대회 발표
한국인공지능융합기술학회 2023 하계학술대회 발표
진동 센서를 활용한 AAS 기반 제조설비 고장진단 시스템
인공지능 기반 제조설비 고장진단 시스템 개발
소방 안전 10년간의 산불 데이터를 활용한 위험 요인 분석 및 시각화
공유 킥보드 사고 방지를 위한 앱 기반 인공지능 모델
영어 말하기 공인 시험 · 응시번호 102458 · 자격증번호 추후 등록
국가기술자격 — 필기 합격, 실기 응시 예정
데이터 핵심 개념과 Azure 데이터 서비스 기초
데이터 분석·사이언스 직무 능력 인증 과정
Thank You
센서 수집부터 이상예지 AI, 데이터 플랫폼, 현장 운영까지 — 숫자로 증명되는 제조 AI 시스템을 만들어온 개발자 한재민입니다. 감사합니다.
부록 · 측정 방법론
아래는 본문 수치의 도출 근거입니다. 운영 서버는 전 과정 읽기 전용(INFO·SELECT·SHOW)만 접촉했고, 빌드·부하·재기동 측정은 개발 서버 또는 로컬 격리 환경에서만 수행했습니다.
시계열 DB 전환 (관계형 → InfluxDB)
| 항목 | 값 | 측정 방법 · 도출식 |
|---|---|---|
| 저장 효율 | 약 16배 | MySQL은 information_schema의 (data_length+index_length)÷행수로 포인트당 125.2B, InfluxDB는 SHOW STATS의 diskBytes÷포인트수로 7.85B를 실측해 비율을 산출(rmm 대표값; acene 14.2·pipe 9.6배로 교차검증). mysql·influxdb 조회 |
| 트렌드 조회 | 5~12배 | 동일 설비 point_id 필터 쿼리를 서버측 EXPLAIN ANALYZE로 실측. 7일 MySQL 2,030~2,584ms ↔ Influx 337~450ms(5~6배), 3개월 MySQL 1,996ms ↔ Influx history(10분 다운샘플) 169ms(약 12배). EXPLAIN ANALYZE |
| 누적 규모 | 약 4.9억 pt | 11개 앱 도메인의 InfluxDB 시리즈별 포인트 카운트와 SHOW STATS 디스크(9.32GB)를 합산. influxdb 조회 |
캐시·저장 계층 (Redis — 2026-08 프로덕션 실측)
| 항목 | 값 | 측정 방법 · 도출식 |
|---|---|---|
| 캐시 적중률 | 98.27% | 프로덕션 Redis INFO stats에서 keyspace_hits ÷ (hits+misses) = 24.6억 ÷ 25.0억. 서버 전역 누적치이며 읽기 전용 INFO 조회. redis INFO |
| 캐시 커버리지 | A 70% · B 50% | A=SCAN으로 센 트렌드 키 1,720 ÷ 전체 키 2,473(키스페이스 점유). B=캐시된 설비 172 ÷ 센서보유 설비 342(MySQL points의 DISTINCT facility_id)=실제 대시보드 워밍율. SCAN + MySQL |
| 관계형 증가 억제 | 약 137GB/년 | MySQL 실측 행당 바이트(pipe 134·rmm 120B) × InfluxDB 실측 유입률(2.30M·0.79M pt/일) × 365. 관계형에 계속 적재했다면 늘었을 증가량(회피량)이며 InfluxDB 실디스크 절대치가 아님. information_schema + SHOW |
수집·인프라 (개발 서버 / 로컬 격리)
| 항목 | 값 | 측정 방법 · 도출식 |
|---|---|---|
| 바이너리 압축 | 약 5.8배 | 고정폭 레이아웃(헤더 12B + feature 16B, 타임스탬프 배치당 1회)과 JSON 92B/건을 배치 100+ 기준 비교. 로컬 격리 디코드 벤치. Node 벤치 |
| Docker cold-start | 약 28초 | 핀 버전 DB 3종을 throwaway compose로 클린 로컬에서 pull(18s)→기동(10s)까지 실측. 운영 무접촉. 로컬 docker |
| 이미지 감량 | 71%↓ | 개발 서버에서 단일 스테이지(4.72GB) vs 멀티 스테이지(1.36GB) 이미지를 빌드해 docker images 크기를 비교. docker build |
| 인증 부하 | 약 395 RPS | 개발 서버 온박스에서 Python ThreadPoolExecutor로 JWT 검증+조인이 걸린 인증 API를 부하. 동시성 100까지 에러 0에서 포화 RPS. Python 부하 |
AI · 신호처리 (모델·알고리즘, 데이터셋 기준)
| 항목 | 값 | 측정 방법 · 도출식 |
|---|---|---|
| 이상탐지 | 98%+ | 공정 단위 2D 스펙트로그램 + DTW 분류의 보유 데이터셋 기준 정확도(운영 라이브 지표 아님). |
| AE 위치추정 오차 | 2.37% | AE 이벤트 음원 위치추정 결과의 배관 길이축 대비 오차율(데이터셋 기준). |
| 의사결정트리 | 92% | 결함 데이터가 부족한 설비의 대체 진단(임계치+AI 이중 알람) 분류 정확도. |
- 규모 수치(등록 127사·592설비·누적 4.9억 포인트)는 멀티테넌트 플랫폼의 누적 등록/저장 기준입니다. 본인이 직접 운영한 범위는 6개 현장·약 800 포인트로 경력기술과 구분합니다.
- 저장 16배는 rmm 대표값(앱별 9.6~16배)이고, 조회 배수는 설비 필터 대표 쿼리 기준입니다. 무필터 전체 스캔이나 고밀도 원본(raw) 구간은 밀도 차로 결과가 달라질 수 있어 별도로 봅니다.
- 운영 서버는 전 과정 읽기 전용만 접촉했습니다. 빌드·부하·재기동처럼 상태를 바꾸는 측정은 개발 서버 또는 로컬 격리 환경에서만 수행했습니다.
- 137GB/년은 회피된 증가량 계산치이며 InfluxDB 압축 후 실디스크 절대치가 아닙니다. AI 정확도(98%+·92%·2.37%)는 데이터셋 기준입니다.
자기소개 요약
센서 수집부터 AI 이상탐지 모델 탑재·현장 운용까지, 예지보전 시스템의 전 과정을 직접 만들어 온 제조 AI 개발자입니다. 진동·AE·온도·가스 데이터를 수집 서버와 시계열 DB, 운영 화면·알람·AI 진단으로 잇고, 국책 3건·기업 납품 3건, 누적 등록 설비 392대 규모 플랫폼을 만들고 그중 6개 현장을 직접 구축·운영하며 실제로 돌아가는 시스템으로 정착시켜 왔습니다.
경력 사항
진동·AE·온도·가스·PLC 5종 설비 데이터를 수집 서버→REST/WebSocket API→InfluxDB·MySQL·Redis 3종 DB→운영 화면·알람·AI 진단 이력으로 잇는 예지보전 플랫폼을 개발해, 6개 현장 직접 구축·운영(플랫폼 누적 등록 현장 32개)·설비 392대·센서 936개 규모에서 운영자가 6종 이상 차트 뷰로 설비 상태를 실시간 확인할 수 있게 했습니다. Docker 컨테이너화·서버 이전·백업/복원·DB 버전 업그레이드까지 직접 맡아, 현장에서 끊김 없이 돌아가는 시스템으로 운영했습니다.
- 운영자가 설비 이상을 즉시 파악하도록 Raw·Trend·STFT·Spectrum·특징공간·진단 이력 6종 데이터를 단일 화면과 API로 통합해, 현장 점검 동선과 확인 시간을 줄였습니다.
- 1초 주기 고주기 시계열도 지연 없이 조회되도록 InfluxDB·MySQL·Redis를 목적별 3계층으로 분리해, 조회 성능과 수집 신뢰성을 동시에 확보했습니다.
- 운영 중단 없이 현장을 유지하기 위해 Docker Compose·Nginx·CI/CD와 서버 이전·백업/복원·DB 버전 업그레이드를 직접 수행해, 포트·권한·수집 장애를 무중단으로 해결했습니다.
- AI 진단을 실사용 제품 기능으로 만들기 위해 추론 결과를 저장·조회·알람·진단 화면으로 연결하고, 최근 결과는 Redis·영구 이력은 RDB로 저장 계층을 분리해 진단 이력의 검색·메타데이터 관리성을 높였습니다.
- 고객·기관 실증을 통과하기 위해 요구사항을 설비 계층·센서 구성·알람 기준·운영 화면·보고서로 구체화해, 다수의 현장 검증과 평가 산출물을 납기 내 완료했습니다.
- 데이터 수집부터 저장·조회·진단·알람·운영까지 서비스 전주기를 끝까지 책임진 풀사이클 개발 경험
- 현장망·오프라인·권한·포트·차트 API·DB 연결 등 실제 고객 환경 장애를 분석해 운영 중단 없이 조치
공작기계 설비 건전성 진단을 주제로 FFT·STFT·스펙트럼 분석과 1D-CNN·TabNet·XAI를 적용해, 정상·베어링·기어·공구 4종 결함을 분류하는 딥러닝 진단 모델을 개발했습니다. 국책과제·기업 실증의 실설비 데이터와 테스트베드로 검증하고, 결과를 2025년 석사학위논문과 진단 화면·보고서로 연결해 연구가 현장 시스템으로 이어지게 했습니다.
- 설비 고장을 조기에 잡기 위해 공작기계 진동 데이터로 정상·베어링·기어·공구 4종 결함 분류 모델을 연구해, 상태 진단 성능을 끌어올렸습니다.
- 설비 상태를 해석 가능한 특징으로 바꾸기 위해 FFT·STFT·스펙트럼 등 주파수 영역 분석을 적용해, 진단 모델의 핵심 입력 특징을 도출했습니다.
- 딥러닝 판단의 신뢰성을 확보하기 위해 1D-CNN·TabNet에 XAI 기반 특징 해석을 결합해, 모델의 판단 근거를 검증했습니다.
- 연구를 현장 신뢰로 잇기 위해 국책과제·기업 연계 프로젝트의 실설비 데이터와 테스트베드로 검증해, 실증 단계까지 통과시켰습니다.
- 연구를 재현·이전 가능하게 만들기 위해 결과를 논문·학위논문·시연·보고서·현장 적용 자료로 정리했습니다.
- 2025년 석사학위논문: 공작기계 설비 건전성 진단을 위한 신호처리 알고리즘 개발 및 딥러닝 기반 상태 분류 알고리즘 연구
- 산업 AI 연구를 웹·서버 개발, 데이터 시각화, 운영 화면 구현 경험으로 확장
핵심 역량 요약
주요 역할
설비 이상예지·신호처리 AI 시스템 개발 / 백엔드·데이터 플랫폼 구축/운영 / 온프레미스 LLM·자동화 확장
실무 전달력
- 제조기업·기관 협업에서 요구사항을 설비 계층, 센서 구성, 알람 기준, 데이터 조회 방식, 운영 화면으로 구체화했습니다.
- 원본 데이터 보존과 화면 표시 보정, 수집 장애와 조회 부하, 서버·DB 운영 이슈를 함께 다루며 데이터 신뢰성을 지켰습니다.
- 기업명·서버·내부망 정보는 제외하고 문제, 역할, 구현, 운영 이슈, 결과 중심으로 설명할 수 있습니다.
강점 요약
- 공정 단위 2D 스펙트로그램·DTW로 데이터셋 98%+ 이상탐지를 구현하고, 결함 데이터가 부족한 설비는 의사결정트리(92%)·임계치+AI 이중 알람으로 해결한 경험
- 설비·센서·PLC 데이터를 수집 서버, API/DB, 운영 화면, 알람, AI 진단 이력으로 연결한 경험
- 석사 연구의 신호처리·딥러닝 결과를 실제 제조 설비 모니터링 기능과 현장 산출물로 확장한 경험
- Docker, CI/CD, 서버 이전, DB 백업·복원, 장애 대응까지 포함해 운영 안정성을 고려한 개발 경험
- 온프레미스 RAG·LLM과 실자본 금융 자동화 개인 프로젝트로 대규모 데이터·리스크 제어·운영 관측성을 넓힌 경험
핵심 역량
백엔드·API
NestJS / Node.js / TypeScript / REST API / WebSocket / Socket.IO / TypeORM (ORM) / JWT·Passport 인증 / Python / 비동기 처리
AI·신호분석
Python / PyTorch / STFT / 2D 스펙트로그램 (Spectrogram) / DTW (Dynamic Time Warping) / 포락 스펙트럼 (Envelope Spectrum) / 1D-CNN / TabNet / XAI / Anomaly Detection / 이상예지 (Anomaly Prediction) / Decision Tree 다중분류 / AE Leak 위치추정
프론트엔드·시각화
Vue.js / TypeScript / SCSS/Sass / SciChart / ECharts / Chart.js / RBAC 권한 화면
데이터베이스·데이터
InfluxDB (시계열) / MySQL / MySQL / Redis (ioredis) / SQL / 시계열 데이터 파이프라인 / ETL / Query Optimization / Backup/Restore / Retention Policy
인프라·DevOps
Docker / Docker Compose / Nginx (리버스 프록시) / Linux 서버 운영 / CI/CD (GitHub Actions) / Server Migration / 온프레미스·망분리(오프라인) 배포 / Git / GitHub
GenAI·LLM
RAG / 온프레미스 LLM (Ollama) / Embedding (BGE-M3) / Vector DB (Chroma) / Hybrid Search / Tool Calling Agent
산업 도메인
산업 IoT (IIoT) / 예지보전 (PdM) / 상태진단 (Condition Monitoring) / 스마트팩토리 / OT 데이터 / PLC 데이터 연동 / AE·진동 센서 모니터링 / 멀티테넌트 아키텍처 / AX/DX
주요 프로젝트
2023.10 - 2026.05
제조 설비 예지보전 모니터링 플랫폼
진동·AE·온도·가스·PLC 등 설비 상태 데이터를 수집 서버에서 API, DB, 운영 화면으로 연결하고 Raw 조회, Trend, Spectrum, STFT, 대시보드, 알람, 진단 이력, 관리자 모드와 서버-DB 운영 안정화까지 구현한 산업 IoT 플랫폼입니다.
대용량 시계열 조회 성능 저하 → 저장 계층 3분할
최근값·장기 이력·메타를 성격이 다른데도 관계형 DB 한 곳에 저장했고, 센서 포인트가 급증하며 인덱스가 비대해져 실시간 조회 성능이 급락했습니다.
역할 저장 구조 재설계·구현 담당
- 대시보드 최근값·알람 체크는 Redis 실시간 캐시로 분리
- 원본 전량은 InfluxDB에 저장하고 Continuous Query로 장기 다운샘플(hot/cold 라우팅)
- 메타·이력은 관계형 DB 전담으로 남기고 시간 파티션 샤드로 조회 최적화
결과 집계 조회 203배(13.4s→66ms) 단축 · 관계형 증가 ~137GB/년 억제 · 프로덕션 캐시 적중 98.29% [실측]
이식·버전업 제약 → Docker 컨테이너화 + CI/CD
컨테이너 기반이 아니어서 서버 이전·버전 업그레이드에 제약이 컸고, 개발·운영 서버가 분리되지 않아 검증 없이 반영되며 오류가 잦았습니다.
역할 컨테이너화·배포 흐름 구축
- 웹·DB·부가 서비스 계층을 Docker Compose로 컨테이너화
- 개발·운영 서버를 분리하고 Nginx 라우팅을 정리
- Git 브랜치+PR 전략 도입(develop→개발서버 자동배포·검증→master 운영 배포)
결과 클린 호스트에서 DB 스택 cold-start 약 28초, 단계별 배포 흐름 확립으로 반영 오류 감소
5단계 설비 확인 → 공정별 1화면 통합
설비 상태를 보려면 공정>설비>포인트>분석까지 여러 화면을 옮겨 다녀야 했고, 현장마다 설비 계층·센서 구성·알람 기준이 달라 반영이 번거로웠습니다.
역할 운영 화면·관리자 기능 구현
- 공정별 대시보드 1화면으로 Raw·Trend·STFT·알람·진단 이력을 통합
- 설비/라인/센서 메타·임계치·표시 기준을 관리자 기능에서 수정 가능하게 구현
- 규칙 기반·AI 진단 결과를 공통 저장·조회·알람 흐름에 연결
결과 5단계 화면 전환을 1화면으로 통합하고 11개 앱 도메인을 멀티테넌트로 운용
문제
-장 설비 데이터가 여러 수집 경로, DB, 화면에 나뉘어 있어 운영자가 설비 상태와 이상 징후를 빠르게 확인하기 어려웠습니다. 고주파 Raw 데이터, 통신 장애, 메모리 부하, DB 권한·포트 이슈, 현장별 알람 기준 차이도 수집 안정성과 기능 반영 속도에 영향을 줬습니다.
해결
설비/공정/라인 구조를 UI와 DB에 반영하고 Raw 수집 주기 설정, 데이터 갱신, 다운로드, 임계치 알람, 진단 이력 조회, 관리자 기능을 구현했습니다. 데이터 수집·저장·조회 흐름에서는 InfluxDB, MySQL, Redis 역할을 나누고 웹/소켓 서버 분리, Docker Compose, 서버 이전, 백업/복원, 버전 업그레이드까지 운영 관점에서 정리했습니다.
성과
- 운영자가 Raw/Trend/알람/진단 데이터를 한 흐름에서 확인할 수 있는 화면 구조 구현
- 진동·AE·온도·가스·PLC 5종 설비 데이터를 수집 서버, API/DB, 운영 화면에 연결
- Raw 수집 주기 설정과 고주파 데이터 조회 흐름 구현
- 현장 실증 피드백을 화면, DB, 알람 조건, 매뉴얼·보고 산출물에 반영
- InfluxDB, MySQL, Redis 역할 분리로 저장/조회 흐름 정리
- 웹/소켓 서버 분리, 서버 이전, Docker Compose 구성, Redis/InfluxDB 안정 버전 업그레이드 대응
- 화학 반응기 펌프·모터 예지보전에 의사결정트리 다중분류(92%)와 임계치·AI 이중 알람을 적용해 운용
- 데이터 누락, 차트 오류, API 장애, 알람 조건 변경, DB 권한·포트 이슈 등 운영 이슈 대응
기술 스택
Vue / React / TypeScript / Node.js / NestJS / REST API / WebSocket / Socket.IO / MySQL / InfluxDB / Redis / Docker / Docker Compose / Nginx / Linux / CI/CD / SciChart / ECharts / RBAC
상세 설명 보기
맡은 역할
설비 상태 데이터가 수집 서버, API/DB, 운영 화면으로 이어지는 전체 흐름에서 화면·DB·API 구현과 운영 이슈 대응을 맡았습니다.
Raw 데이터 조회, 갱신, 다운로드, Trend·Spectrum·STFT·특징공간 차트, 대시보드, 알람, 진단 이력, 관리자 기능을 구현했습니다.
수집 서버, API 장애, DB, 캐시, 배포 환경에서 발생하는 운영 이슈를 개발 과제로 보고 원인을 추적했습니다.
현장별 설비 계층, 센서 구성, 알람 기준이 다른 조건을 화면과 데이터 모델에 반영했습니다.
주요 구현
진동, AE, 온도, 가스, 누설, PLC 기반 설비 데이터를 Raw, Trend, Spectrum, STFT, 특징공간 화면에서 확인할 수 있게 구성했습니다.
SciChart와 ECharts로 고주파 시계열 데이터와 분석 결과를 운영자가 읽을 수 있는 차트로 구현했습니다.
사용자 권한과 메뉴 제어를 결합해 일반 사용자, 기업 관리자, 시스템 관리자 흐름을 분리했습니다.
운영 중 자주 바뀌는 설비/라인/센서 메타데이터, 임계치, 화면 표시 기준을 관리자 기능에서 수정할 수 있게 만들었습니다.
규칙 기반 진단과 AI 진단 결과를 공통 저장·조회·알람 흐름에 연결했습니다.
데이터 인프라/운영
InfluxDB는 시계열 데이터 저장·조회, MySQL는 서비스 메타데이터와 관리 이력, Redis는 캐시와 상태 처리로 역할을 나눴습니다.
Raw 수집 주기 설정 값을 DB/API/UI까지 연결하고, 수집 실패 시 로그와 재시도 기준으로 장애 원인을 추적했습니다.
웹/소켓 서버 분리, 운영 서버 이전, Docker/Docker Compose 구성, Nginx 라우팅, 백업/복원, Redis/InfluxDB 안정 버전 업그레이드를 수행했습니다.
데이터 누락, 통신 실패, 메모리 부하, 권한 오류, 라우팅 문제를 로그와 연결 테스트로 좁혀 해결했습니다.
공개 범위
기업명, 서버 식별자, 인증서, 내부망 정보, 운영망 구성은 공개하지 않습니다.
공개 포트폴리오에서는 제품 기능, 데이터 수집, 서버-DB 운영 안정화를 연결한 산업 예지보전 플랫폼 대표 사례로 정리했습니다.
2023.12 - 2026.05
공작기계/MCT 신호분석 및 AI 진단
공작기계와 회전 설비의 진동 데이터를 기반으로 STFT, FFT, 스펙트럼, CNN, One-Class SVM 분석을 수행하고 진단 화면과 알람 흐름으로 연결했습니다.
문서·담당자 없는 PLC → 역분석해 공정 데이터 소스화
절삭 시점·공구 사용 횟수 같은 공정 상태를 담은 PLC 데이터가 필요했지만 매뉴얼도, 이를 아는 담당자도 없었습니다.
역할 PLC 역분석·공정 라벨링 담당
- 저장된 PLC 데이터를 연구원과 함께 역분석해 의미를 규명
- 공정 시작 시점·공구 교체 구간을 메타데이터로 구조화
- 공구 교체 기준 STFT 페이징에 PLC 사용 횟수를 분 단위로 연동
결과 공정 상태 라벨을 확보해 센서 신호와 결합한 학습 데이터 구성 기반을 마련
스펙트럼만으로 분류 성능 부족 → 공정별 2D 스펙트로그램·DTW 결합
기존 스펙트럼 데이터만으로는 이상 분류 성능이 확보되지 않아 원인을 분석하고 표현 방식을 바꿔야 했습니다.
역할 신호처리·모델 설계·탑재 담당
- 진동 신호를 공정별 2D 스펙트로그램 이미지로 변환해 CNN 학습
- 정상 레퍼런스와 DTW 특징 비교를 결합해 이상 판정
- 정상/베어링/기어/공구 4분류를 1D-CNN·TabNet·OC-SVM으로 서빙
결과 데이터셋 기준 평균 98% 이상 이상탐지를 구현·현장 탑재하고, 실 운용에서 불량 9건을 사전 감지
저장 용량 폭증 → 회전 성분 기반 특징 추출 경량화
진동 데이터를 전 주파수로 저장하면 용량이 커 중소 제조 현장에서는 운영이 어려웠습니다.
역할 석사 연구·현장 적용
- 회전 성분을 기준으로 정보가 큰 대역은 촘촘히, 낮은 대역은 로그 스케일 대표값으로 추출
- 경량화된 특징으로 TabNet·1D-CNN 다중분류 학습
- 모니터링 시스템에 적용해 과제 실증에서 안정 동작 확인
결과 데이터를 경량화하면서도 분류 성능은 오히려 향상됨을 석사 논문으로 검증
문제
원시 신호만으로는 현장 운영자가 설비 이상을 판단하기 어렵기 때문에, 신호처리 결과와 AI/규칙 기반 진단 결과를 화면에서 해석 가능한 형태로 제공해야 했습니다.
해결
STFT 기간 조회, 스펙트럼/스펙트로그램 차트, 공구 상태 UI, 라벨링 프로그램, 이상치 보정, 규칙 기반 진단 차트, AI 진단 결과 저장 흐름을 구현했습니다.
성과
- STFT, 스펙트럼, 스펙트로그램 기반 설비 진단 화면 구현
- AI/규칙 기반 진단 결과를 운영 화면과 알람 흐름에 연결
- 석사 연구의 신호처리·상태분류 경험을 제품 기능과 기술 문서로 확장
- 기업 실증 과정의 테스트베드 검증, 보고서, 시연 자료로 진단 결과 설명
- 원본 데이터 보존과 화면 보정을 분리해 분석 신뢰성과 사용성을 함께 고려
- 신호분석과 AI 진단 결과를 운영 화면과 알람 흐름에 연결
기술 스택
Python / PyTorch / MATLAB / STFT / FFT / CNN / One-Class SVM / TabNet / Vue / SciChart
상세 설명 보기
맡은 역할
공작기계와 회전 설비의 진동 데이터를 분석 가능한 형태로 변환하고, 신호처리 결과를 운영 화면에 연결했습니다.
STFT, FFT, 스펙트럼, 스펙트로그램, 특징값 파싱, 라벨링, CNN, One-Class SVM 기반 진단 흐름을 다뤘습니다.
석사 연구에서 다룬 신호처리·상태분류 경험을 제품 기능, 화면 설계, 문서화로 확장했습니다.
주요 구현
기간 조건으로 STFT 데이터를 조회하고, 스펙트럼/스펙트로그램 차트를 통해 주파수 성분 변화를 확인할 수 있도록 구현했습니다.
학습 이미지와 라벨 데이터를 구성하고, 모델 결과가 단순 파일이나 실험 결과에 머물지 않도록 진단 화면과 저장 흐름으로 연결했습니다.
센서 노이즈처럼 보이는 값은 원본 데이터 보존과 화면 출력 보정을 분리해 처리했습니다.
P99 초과 spike 탐지, 예외 처리, 규칙 기반 진단 차트 연동을 통해 운영 화면에서 해석 가능한 이상 징후를 만들었습니다.
설명 방식
특정 장비 보유 기업명과 실증 현장명은 공개하지 않습니다.
공개 페이지에서는 공작기계/제조 설비 진단, 신호처리, AI 기반 상태분류 경험으로 표현합니다.
2024.01 - 2026.04
스마트그린산단/지하배관 관제 시스템 개발
지하배관 24개에 진동·AE 센서를 직접 설치하고 P-LTE로 자체 웹 서버에 연결해 실시간 모니터링·규칙 기반 진단·AE 기반 누수 위치 추정까지 구축한 현장 운용 시스템입니다. 배관·맨홀·관제센터 계층 구조, 센서 위치/특징값, RawData 수집, 외부 예측진단 API 연동, 모바일 QR, CI/CD를 담당했습니다.
이기종 현장 단말 연결 + 전송 불안정 → P-LTE 경로 분리로 데이터 유실 방지
지하배관 현장의 센서·게이트웨이를 전용 P-LTE 망으로 자체 웹서버까지 이어야 했고, 외부 기관 전송이 불안정할 때도 데이터가 유실되면 안 됐습니다.
역할 수집 연동·서버 경로 설계
- 센서·게이트웨이 데이터를 P-LTE로 자체 웹서버에 실시간 연결
- 외부 전송이 불안정해도 로컬 저장은 반드시 성공하도록 수집 경로를 분리
- 외부 관제센터 예측진단 API를 연동하고 임계치 초과 시 전송값을 필터링·보정
결과 1차년도 배관 11개에 진동·AE 센서 87개(진동 44·AE 43)를 실시간 수집·운용(고도화 14개 진행, 총 25개)
기관마다 다른 좌표 체계 → 배관·맨홀·포인트 3단계 위치 표준
여러 업체가 참여해 배관·센서를 가리키는 단위와 위치 체계가 제각각이라 통합 과정에서 혼선이 있었습니다.
역할 위치 데이터 모델·협의 담당
- 배관·맨홀·포인트 3단계 위치 계층으로 표준을 정의
- 관계 기관과 용어·좌표 기준을 협의해 일관된 체계로 정리
- 표준 위치를 지도 화면에 연동해 센서·배관 위치를 표시
결과 위치 기준을 통일해 사고·결함 시 정확한 위치 전달 기반을 마련
누수 위치 파악 → AE 신호 기반 위치추정 알고리즘 탑재
지하배관 누수 발생 위치를 신호로 추정해 현장 대응으로 이어야 했습니다.
역할 알고리즘 연동·화면·저장 구현·검증
- 연구원이 개발한 AE 누수 위치추정 알고리즘을 모니터링 화면·저장 로직으로 구현
- 실증 테스트베드 데이터로 반복 검증하며 안정적으로 탑재
- 진동·AE 데이터를 종합한 일일 진단 보고서 생성(로컬 LLM) 기능과 연결
결과 AE 누수 위치추정 평균 오차율 2.37%(실증 테스트베드, 최저 1.27%)
문제
센서 위치 좌표 누락, 특징값 미수신, 관제센터 API 연동, 지하배관 용어·계층 정리가 혼재하여 관제 화면에서 배관·맨홀·포인트 상태를 일관되게 보여주기 어려웠습니다.
해결
배관·맨홀·포인트 계층과 센서 위치를 정리해 지도 화면에 반영하고, 외부 예측진단 API 연동, 모바일 QR 기반 현장 조회, CI/CD와 개발/운영 서버 분리까지 수행했습니다.
성과
- 진동·AE 센서를 24개 배관에 직접 설치하고 P-LTE로 자체 웹 서버에 연결해 실시간 수집·규칙 기반 진단 운용(현재 운용 중)
- AE 신호 기반 배관 누수(Leak) 위치 추정 알고리즘을 실증 테스트베드 데이터로 검증 후 시스템에 탑재
- 진동·AE 데이터를 종합해 매일 진단보고서를 생성하는 로컬 LLM 기능 개발
- 지하배관·맨홀·포인트 계층과 센서 위치를 지도 화면에 연동
- 외부 예측진단 API 연동 및 센서 데이터 전송값 보정 로직 구현
- 모바일 QR 시스템과 기존 모니터링 DB(배관/진동 트렌드) 연동
- CI/CD 파이프라인 구축 및 개발/운영 서버 분리
- 현장 서버 연동 테스트, 요구사항 반영, 보고·시연 산출물 대응
기술 스택
Vue / Node.js / NestJS / REST API / MySQL / InfluxDB / Docker / CI/CD / Nginx / Mobile QR
상세 설명 보기
맡은 역할
지하배관 관제 API 및 통합관제센터 서버 구축·연동 작업을 수행했습니다.
지하배관 시스템의 계층 구조(배관/맨홀/포인트), 센서 위치, 용어를 정리하고 웹 UI에 반영했습니다.
모바일 QR 시스템, CI/CD 파이프라인, 개발/운영 서버 분리를 진행했습니다.
주요 구현
관제 API 개발: 센서 위치, 전용 특징값 요청, 회사/설비 정보 조회
통합관제센터 서버 구축 및 API/센서 통신 테스트, 특징값·설비 정보 데이터 이전
외부 예측진단 API를 호출해 지도상에 결과를 출력하는 구조 개발
위치 좌표 누락 확인 및 조치, 센서 임계치 초과 시 알람 조건 확인 후 API 전송값 필터링/보정
지하배관 용어·계층(배관/맨홀/포인트) 정리 후 지도 위치 기능 개선
모바일 QR 로그인 기능 및 기존 모니터링 DB(배관/센서 정보·진동 트렌드) 연동
Vib/AE 소리 재생 오류 해결
CI/CD 파이프라인 구축, 개발/운영 서버 분리
2026.01 - 현재
PredicTrade: LLM 결합 암호화폐 알고리즘 트레이딩 시스템
실자본으로 운용 중인 암호화폐 알고리즘 트레이딩 시스템입니다. 9개 마이크로서비스 기반으로 거래소 WebSocket/REST 데이터, 온체인·뉴스 데이터, 17개 이상 전략 앙상블, LightGBM 메타 레이블링, HMM 레짐 감지, 50개 이상 진입 게이트, LLM 손실 복기 루프를 연결했습니다. 단순 자동매매가 아니라 데이터 신뢰성, 신호 검증, 리스크 제어, 운영 관측성을 함께 검증하는 개인 AX 자동화 프로젝트입니다.
단일 전략 과최적화 위험 → 17+ 전략 앙상블 + 메타 레이블링 2차 검증
하나의 전략에 의존하면 특정 국면에 과최적화되기 쉬워, 신호를 한 번 더 걸러 낼 구조가 필요했습니다.
역할 전략 앙상블·ML 게이트 설계
- 17개 이상 전략을 앙상블하고 8개 심볼·7개 타임프레임으로 신호 생성
- LightGBM 메타 레이블링으로 기존 전략 신호를 2차 검증
- 심볼별 HMM 레짐 감지와 온체인·뉴스·거시 지표를 진입 게이트에 반영
결과 walk-forward OOS 구간에서 Sharpe 1.12~1.88 범위를 검증
실자본 손실 리스크 → 50+ 진입 게이트·다층 방어
실제 자본을 운용하므로 나쁜 진입을 걸러 내고 급락 상황에서 손실을 제한하는 안전장치가 필수였습니다.
역할 리스크 게이트·실행 계층 구현
- 50개 이상 진입 게이트를 hard block·scale·model·execution 단계로 구성
- 일일 손실·연속 손실·MDD·플래시 크래시 방어 규칙 적용
- 9개 마이크로서비스로 수집·전략·LLM 분석·백테스트·알림을 분리
결과 실자본 환경에서 620건 이상 라이브 트레이드 운용, 733개 pytest로 회귀 검증
반복되는 손실 패턴 → LLM 손실 복기·교훈 폐쇄 루프
같은 실수를 반복하지 않으려면 손실을 사람처럼 복기하고 다음 매매에 반영하는 자기학습이 필요했습니다.
역할 LLM 오케스트레이션·자기학습 루프 설계
- LLM이 손실 거래를 복기해 교훈을 토큰으로 저장
- 교훈을 Thompson Sampling 기반 스케일 조정에 반영해 폐쇄 루프 구성
- 로컬 LLM 판단과 ML 게이트를 결합해 진입 크기를 결정
결과 손실 복기 → 교훈 저장 → 다음 매매 반영으로 이어지는 자기학습 사이클 구현
문제
24시간 움직이는 암호화폐 시장에서는 사람이 모든 시장 기회를 추적하기 어렵고, 단일 전략은 특정 장세에 과최적화되기 쉽습니다. 실제 자본을 투입하는 환경에서는 진입 신호보다 더 중요한 것이 손실 제한, 포지션 크기 조절, 데이터 품질 검증, 실패 거래의 재학습 구조였습니다.
해결
거래소 데이터는 Redis 링버퍼와 InfluxDB 시계열 저장소로 분리하고, 주문·포지션·게이트·교훈 데이터는 SQLite에 기록했습니다. trading-engine은 10초 루프에서 전략 앙상블 점수를 계산하고, LightGBM 메타 레이블러와 HMM 레짐 감지, 하드 블록·스케일·모델·실행 게이트를 통과한 경우에만 주문을 실행합니다. 손실 거래는 LLM이 복기해 교훈 토큰으로 정리하고, Thompson Sampling 기반 스케일 조정과 패턴 차단 후보에 반영했습니다.
성과
- 9개 마이크로서비스 기반으로 실시간 데이터 수집, 전략 실행, LLM 분석, 백테스트, 대시보드, 알림을 분리 구현
- 17개 이상 전략 앙상블과 LightGBM 메타 레이블링으로 기존 전략 신호를 2차 검증하는 구조 설계
- 심볼별 HMM 레짐 감지와 온체인·뉴스·거시 지표를 진입 게이트와 포지션 스케일링에 반영
- 50개 이상 진입 게이트를 hard block, scale, model, execution 단계로 구성해 실자본 운용 리스크를 제어
- LLM 손실 복기 결과를 교훈 토큰으로 저장하고 Thompson Sampling 기반 스케일 조정에 반영하는 폐쇄 루프 구현
- 620건 이상 라이브 트레이드와 pytest 733개 회귀 테스트를 통해 운영 데이터와 코드 안정성을 함께 관리
기술 스택
Python / FastAPI / asyncio / ccxt / LightGBM / hmmlearn / VectorBT / Redis / InfluxDB / SQLite / Qdrant / Ollama / React / TypeScript / Docker Compose / pytest
상세 설명 보기
맡은 역할
실시간 데이터 수집, 전략 실행, 리스크 게이트, 포지션 관리, LLM 복기, 대시보드, 알림까지 포함한 개인 트레이딩 자동화 시스템을 설계·개발·운용했습니다.
실자본 운용 환경에서 수익과 손실을 모두 기록하며 데이터 품질, 진입 조건, 손실 제한 규칙을 지속적으로 개선했습니다.
단순히 매수/매도 봇을 만든 것이 아니라, 신호 품질을 검증하고 손실을 제한하며 실패 거래를 다음 판단에 반영하는 운영 루프를 구축했습니다.
주요 구현
FastAPI 기반 9개 마이크로서비스로 trading-engine, data-pipeline, blockchain-collector, news-collector, llm-service, backtest-engine, expert-coach, telegram-bot, web 대시보드를 분리했습니다.
거래소 WebSocket/REST 데이터를 Redis 500-bar 링버퍼와 InfluxDB OHLCV 저장소에 적재하고, SQLite에는 trades, positions, gates, lessons 등 운영 이력을 기록했습니다.
17개 이상 전략 앙상블을 7개 타임프레임과 8개 심볼에 적용하고, LightGBM 메타 레이블러로 기존 전략 신호를 2차 필터링했습니다.
HMM 기반 시장 레짐 감지를 심볼별로 적용하고 Redis 캐시와 백그라운드 갱신 구조로 trading-engine의 메인 루프 지연을 줄였습니다.
50개 이상 진입 게이트를 hard block, scale, model, execution 단계로 구성해 레버리지, 일일 손실, 연속 손실, MDD, 플래시 크래시, 온체인·거시 지표 위험을 제어했습니다.
LLM이 손실 거래를 복기해 교훈 패턴을 추출하고, Thompson Sampling으로 다음 진입 스케일을 조정하거나 반복 손실 패턴을 차단 후보로 올리는 폐쇄 루프를 구현했습니다.
VectorBT 기반 백테스트, purged holdout과 embargo, walk-forward OOS 검증, pytest 회귀 테스트로 전략 변경의 안정성을 확인했습니다.
확장 역량
금융 도메인에서 실시간 데이터 파이프라인, ML 신호 검증, LLM 기반 사후 분석, 리스크 제어, 운영 관측성을 하나의 제품형 시스템으로 연결한 사례입니다.
금융 데이터 기반 의사결정, 리스크 제어, 운영 관측성을 하나의 자동화 플랫폼으로 연결한 확장 사례입니다.