Jaemin HanIndustrial IT Portfolio
홈연락

기간 - 2023.10 - 2026.05

제조 설비 예지보전 모니터링 플랫폼

진동·AE·온도·가스·PLC 등 설비 상태 데이터를 수집 서버에서 API, DB, 운영 화면으로 연결하고 Raw 조회, Trend, Spectrum, STFT, 대시보드, 알람, 진단 이력, 관리자 모드와 서버-DB 운영 안정화까지 구현한 산업 IoT 플랫폼입니다.

수행 역할요구사항을 UI, API, DB, 알람/진단 흐름으로 구현

2023.10 - 2026.05

검증 자료3개 시각 자료 · 17개 성과 근거

Vue / React / TypeScript / Node.js

공개 범위고객사·서버·내부망 정보 제외

역할, 구현 흐름, 결과 중심으로 정리

개요·성과프로젝트 요약기능 개발 단위트러블슈팅기여 내용갤러리상세 설명성과기술 스택
STAR · 프로젝트 개요
S
SITUATION · 상황
분야·사업별로 독립된 모니터링 시스템 → 중복 개발·버전관리 비효율, 통합 플랫폼 필요.
T
TASK · 과제
분산 시스템을 플랫폼 중심 구조로 통합, 다양한 산업군 설비 모니터링을 설계·개발·운영 담당.
A
ACTION · 실행
공통 기능 모듈화·데이터 구조 표준화로 단계적 통합 — 인수받은 단일 MySQL을 Redis/InfluxDB/MySQL 3계층으로 재아키텍처하고 실시간 인입 서버를 분리.
R
RESULT · 성과
국책 3건·기업 납품 3건, 누적 등록 설비 392대(센서 포인트 936개), 제조·화학·선박 등 다분야 구축·운용.
성과 · X-Y-Z
실측392
누적 등록 설비
센서 포인트 936
실측203배
집계조회 가속
13.4s→66ms
실측98.29%
캐시 적중률
프로덕션 실측
세부 과제 · 데이터 저장 3계층
WHY · 왜

단일 MySQL에 시계열·메타 혼재 → 집계 조회(GROUP BY 시간버킷) 병목·저장 급증.

WHAT · 무엇을

시계열=InfluxDB, 핫데이터=Redis, 관계형=MySQL로 책임 분리.

HOW · 어떻게

접근 패턴·보존 주기 기준 라우팅, 다운샘플·재연결 정책, 부하테스트로 검증.

WHAT NEXT · 다음

신규 과제 기본 저장 구조로 표준화, 파일 저장소 분리까지 확장.

집계조회 203배(13.4s→66ms) · 관계형 증가 ~137GB/년 억제 · 캐시 98.29% [실측]
CASE STUDY

문제에서 구현 결과까지

진동·AE·온도·가스·PLC 등 설비 상태 데이터를 수집 서버에서 API, DB, 운영 화면으로 연결하고 Raw 조회, Trend, Spectrum, STFT, 대시보드, 알람, 진단 이력, 관리자 모드와 서버-DB 운영 안정화까지 구현한 산업 IoT 플랫폼입니다.

문제

-장 설비 데이터가 여러 수집 경로, DB, 화면에 나뉘어 있어 운영자가 설비 상태와 이상 징후를 빠르게 확인하기 어려웠습니다. 고주파 Raw 데이터, 통신 장애, 메모리 부하, DB 권한·포트 이슈, 현장별 알람 기준 차이도 수집 안정성과 기능 반영 속도에 영향을 줬습니다.

구현 역할

요구사항을 화면, API, 데이터 저장/조회, 알람/진단 흐름으로 분해하고 구현했습니다.

해결 흐름

설비/공정/라인 구조를 UI와 DB에 반영하고 Raw 수집 주기 설정, 데이터 갱신, 다운로드, 임계치 알람, 진단 이력 조회, 관리자 기능을 구현했습니다. 데이터 수집·저장·조회 흐름에서는 InfluxDB, MySQL, Redis 역할을 나누고 웹/소켓 서버 분리, Docker Compose, 서버 이전, 백업/복원, 버전 업그레이드까지 운영 관점에서 정리했습니다.

결과

Raw·Trend·STFT·Spectrum·특징공간·진단 이력 등 6+ 차트 뷰 통합 / 진동·AE·온도·가스·PLC 5종 설비 데이터를 단일 모니터링 흐름에 연결 / 운영자가 Raw/Trend/알람/진단 데이터를 한 흐름에서 확인할 수 있는 화면 구조 구현

기술 스택
VueReactTypeScriptNode.jsNestJSREST APIWebSocketSocket.IOMySQLInfluxDB
제조 설비 예지보전 모니터링 플랫폼 - 구조도 - 모니터링 시스템 4계층 구조 (입력→수집→서비스→AI&DB)
구조도 모니터링 시스템 4계층 구조 (입력→수집→서비스→AI&DB)
제조 설비 예지보전 모니터링 플랫폼 - 구조도 - 바이너리 소켓 수집 게이트웨이 — 수집→디코딩→분기 흐름과 고정폭 레코드 레이아웃
구조도 바이너리 소켓 수집 게이트웨이 — 수집→디코딩→분기 흐름과 고정폭 레코드 레이아웃
제조 설비 예지보전 모니터링 플랫폼 - 구조도 - nginx 리버스 프록시 — 단일 도메인 path 분리로 운영·개발 v1/v2 동시 서빙 + 하드닝 5건
구조도 nginx 리버스 프록시 — 단일 도메인 path 분리로 운영·개발 v1/v2 동시 서빙 + 하드닝 5건
이 프로젝트의 하위 기능제조 설비 예지보전 모니터링 플랫폼3개 기능 개발 단위
FEATURE BUILDS

기능 개발 단위로 본 구현 범위

하나의 프로젝트 안에서 직접 설계하고 구현한 주요 기능을 화면, 역할, 구현 내용, 결과 단위로 나눠 정리했습니다.

01

대용량 시계열 조회 성능 저하 → 저장 계층 3분할

최근값·장기 이력·메타를 성격이 다른데도 관계형 DB 한 곳에 저장했고, 센서 포인트가 급증하며 인덱스가 비대해져 실시간 조회 성능이 급락했습니다.

대용량 시계열 조회 성능 저하 → 저장 계층 3분할 - 구조도 - BEFORE 단일 MySQL → AFTER 3계층 분리 — 이 과제의 실제 재아키텍처 구조
BEFORE 단일 MySQL → AFTER 3계층 분리 — 이 과제의 실제 재아키텍처 구조
담당 역할

저장 구조 재설계·구현 담당

  • 대시보드 최근값·알람 체크는 Redis 실시간 캐시로 분리
  • 원본 전량은 InfluxDB에 저장하고 Continuous Query로 장기 다운샘플(hot/cold 라우팅)
  • 메타·이력은 관계형 DB 전담으로 남기고 시간 파티션 샤드로 조회 최적화

결과 집계 조회 203배(13.4s→66ms) 단축 · 관계형 증가 ~137GB/년 억제 · 프로덕션 캐시 적중 98.29% [실측]

InfluxDBRedisMySQL
02

이식·버전업 제약 → Docker 컨테이너화 + CI/CD

컨테이너 기반이 아니어서 서버 이전·버전 업그레이드에 제약이 컸고, 개발·운영 서버가 분리되지 않아 검증 없이 반영되며 오류가 잦았습니다.

이식·버전업 제약 → Docker 컨테이너화 + CI/CD - 구조도 - 호스트 직접 설치 → Docker Compose 스택 2벌을 한 호스트에서 격리 공존
호스트 직접 설치 → Docker Compose 스택 2벌을 한 호스트에서 격리 공존
이식·버전업 제약 → Docker 컨테이너화 + CI/CD - 구조도 - GitHub Actions 3단 배포 — PR 품질 게이트 → 개발 서버 자동 배포 → 운영 수동 게이트
GitHub Actions 3단 배포 — PR 품질 게이트 → 개발 서버 자동 배포 → 운영 수동 게이트
이식·버전업 제약 → Docker 컨테이너화 + CI/CD - 구조도 - 브랜치 = 환경 매핑(GitOps) — develop·react_upgrade는 개발 서버, master는 운영
브랜치 = 환경 매핑(GitOps) — develop·react_upgrade는 개발 서버, master는 운영
담당 역할

컨테이너화·배포 흐름 구축

  • 웹·DB·부가 서비스 계층을 Docker Compose로 컨테이너화
  • 개발·운영 서버를 분리하고 Nginx 라우팅을 정리
  • Git 브랜치+PR 전략 도입(develop→개발서버 자동배포·검증→master 운영 배포)

결과 클린 호스트에서 DB 스택 cold-start 약 28초, 단계별 배포 흐름 확립으로 반영 오류 감소

DockerNginxCI/CDGit
03

5단계 설비 확인 → 공정별 1화면 통합

설비 상태를 보려면 공정>설비>포인트>분석까지 여러 화면을 옮겨 다녀야 했고, 현장마다 설비 계층·센서 구성·알람 기준이 달라 반영이 번거로웠습니다.

담당 역할

운영 화면·관리자 기능 구현

  • 공정별 대시보드 1화면으로 Raw·Trend·STFT·알람·진단 이력을 통합
  • 설비/라인/센서 메타·임계치·표시 기준을 관리자 기능에서 수정 가능하게 구현
  • 규칙 기반·AI 진단 결과를 공통 저장·조회·알람 흐름에 연결

결과 5단계 화면 전환을 1화면으로 통합하고 11개 앱 도메인을 멀티테넌트로 운용

VueNestJSSciChartRBAC
이 프로젝트에서 해결한 이슈제조 설비 예지보전 모니터링 플랫폼5개 트러블슈팅
TROUBLESHOOTING

트러블슈팅 — 겪은 문제와 해결

개발·운영 중 실제로 마주친 문제를 증상, 원인 추적, 조치, 결과 단위로 정리했습니다.

01

간헐적 수집 실패·통신 장애 → 로그·연결 테스트로 계층별 원인 추적

현장 수집이 간헐적으로 실패하고 통신이 끊겼는데, 원인이 단말·망·서버 여러 계층에 걸쳐 있어 재현이 어려웠습니다.

  • 수집 실패 시 로그·재시도 기준을 정의해 실패 지점을 기록
  • 연결 테스트로 단말→망→서버 계층을 좁혀 원인 격리
  • 권한·포트·Nginx 라우팅 이슈를 개별로 재현·수정

결과 데이터 누락·통신 실패·권한/포트/라우팅 문제를 원인 계층까지 좁혀 해결

NginxLinuxDocker
02

운영 중 메모리 부하 → 고정 특징 데이터 적재·처리 구조 개선

고정 특징 데이터를 비효율적으로 적재·처리해 운영 중 메모리 부하가 커졌습니다.

  • 적재·처리 경로를 재구성하고 불필요한 상시 로딩을 제거
  • 조회 패턴에 맞게 캐시·쿼리 경로를 정리

결과 메모리 사용량 약 28% 절감

NestJSRedisInfluxDB
03

MaxListenersExceededWarning 반복·수신 불안정 → 소켓 게이트웨이 전역 단일화

43개 도메인 모듈이 각자 EventGateway를 providers에 등록해 리스너가 누적, Node 기본 한계를 초과하며 실시간 수신이 간헐적으로 불안정해졌다.

  • @Global() SocketGatewayModule을 신설하고 EventGateway를 단일 등록 — AppModule에서 한 번만 임포트
  • 별도 EventHandlerGateway(80줄)를 삭제하고 joinRoom·leaveAllRoom·insert* 핸들러를 EventGateway로 통합
  • 기존 소켓 엔드포인트·이벤트 계약은 유지한 채 55개 파일 정리

결과 MaxListenersExceededWarning 완전 제거, 실시간 수신 안정화 — NestJS 공유 싱글톤은 global module로 선언하는 패턴 확립 (커밋 39190656)

NestJSSocket.IO
04

센서 두절인데 옛 값이 '정상'처럼 표시 → 오프라인 '—' 표기 정책 통일

센서가 10분 이상 데이터를 보내지 않아도 RPM·전류·전압이 마지막 수신값으로 남아, 운영자가 설비 가동 중으로 오인할 위험이 있었다. 원인은 OFF 분기의 값 초기화 누락 + 포매터가 결측 센티널을 0으로 처리 + 대시보드별 오프라인 임계 불일치(5분/10분).

  • 10분 초과 OFF 분기에서 표시값 초기화를 멱등 호출로 보장
  • 포매터가 '-' 센티널을 0이 아닌 '—'로 통과하도록 정책 통일
  • 대시보드별 오프라인 임계를 10분으로 일원화, 표시 셀만 «—» 처리(계산값은 보존) — 7개 파일

결과 '데이터 없음'과 '정상값 0'을 UI에서 명확히 구분해 오판 방지 — 오프라인 표기 정책 전 화면 일관화 (커밋 2d2b9f15)

Vue
05

'Unknown column' 에러·메뉴 미로딩 → 3중 분산 권한 데이터를 단일 테이블로 통합

메뉴 권한이 authorities.sidebar_menus 컬럼·authority_sidebar_menus·authority_tab_menus 세 곳에 분산·중복돼 진짜 소스가 불명확했고, 컬럼명 변경으로 /api/entry가 에러를 냈다.

  • authority_menus 단일 테이블로 통합(menu_type = 'sidebar'|'tab'|'uiSettings')
  • 컬럼 제거 후 OneToMany 관계로 대체, AuthorityMenu 엔티티 신설
  • 하드코딩된 Vib/AE/Gas 탭 섹션을 설비 sensor_type 기반 동적 섹션으로 리팩터링 — 14개 파일, +1,578/−298줄

결과 스키마 3개→1개, 에러 해소 — authority별 메뉴 순서·노출·라벨을 DB 행 하나로 제어 (커밋 c1654f0e 외 3건)

NestJSTypeORMMySQL
내가 기여한 부분2023.10 - 2026.05

문제

-장 설비 데이터가 여러 수집 경로, DB, 화면에 나뉘어 있어 운영자가 설비 상태와 이상 징후를 빠르게 확인하기 어려웠습니다. 고주파 Raw 데이터, 통신 장애, 메모리 부하, DB 권한·포트 이슈, 현장별 알람 기준 차이도 수집 안정성과 기능 반영 속도에 영향을 줬습니다.

해결

설비/공정/라인 구조를 UI와 DB에 반영하고 Raw 수집 주기 설정, 데이터 갱신, 다운로드, 임계치 알람, 진단 이력 조회, 관리자 기능을 구현했습니다. 데이터 수집·저장·조회 흐름에서는 InfluxDB, MySQL, Redis 역할을 나누고 웹/소켓 서버 분리, Docker Compose, 서버 이전, 백업/복원, 버전 업그레이드까지 운영 관점에서 정리했습니다.

상세 설명

상세 구현 설명 펼쳐보기

맡은 역할

  • 설비 상태 데이터가 수집 서버, 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 운영 안정화를 연결한 산업 예지보전 플랫폼 대표 사례로 정리했습니다.

성과

  • 운영자가 Raw/Trend/알람/진단 데이터를 한 흐름에서 확인할 수 있는 화면 구조 구현
  • 진동·AE·온도·가스·PLC 5종 설비 데이터를 수집 서버, API/DB, 운영 화면에 연결
  • Raw 수집 주기 설정과 고주파 데이터 조회 흐름 구현
  • 현장 실증 피드백을 화면, DB, 알람 조건, 매뉴얼·보고 산출물에 반영
  • InfluxDB, MySQL, Redis 역할 분리로 저장/조회 흐름 정리
  • 웹/소켓 서버 분리, 서버 이전, Docker Compose 구성, Redis/InfluxDB 안정 버전 업그레이드 대응
  • 화학 반응기 펌프·모터 예지보전에 의사결정트리 다중분류(92%)와 임계치·AI 이중 알람을 적용해 운용
  • 데이터 누락, 차트 오류, API 장애, 알람 조건 변경, DB 권한·포트 이슈 등 운영 이슈 대응

핵심 지표

  • Raw·Trend·STFT·Spectrum·특징공간·진단 이력 등 6+ 차트 뷰 통합
  • 진동·AE·온도·가스·PLC 5종 설비 데이터를 단일 모니터링 흐름에 연결
  • 1초 주기 공정 데이터 수집 구조 설계 및 InfluxDB 시계열 DB 적용
  • 운영 서버 이전 + 웹/소켓 서버 분리 + Docker Compose 컨테이너화 대응
  • Redis/InfluxDB EoS 전 안정 버전 업그레이드와 백업/복원/연결 검증 수행
  • 공정 > 설비 > 포인트 3단계 설비 계층과 회사/설비/포인트 CRUD 구현
  • 화학 반응기 펌프·모터 예지보전 — 결함 데이터가 부족한 환경을 의사결정트리로 풀어 다중분류 92% 정확도를 달성하고, 임계치·AI 이중 알람으로 진단 신뢰도를 높여 현재 운용 중
  • 고정 특징 데이터의 적재·처리 구조를 개선해 메모리 사용량 28% 절감
  • 6개 현장을 직접 구축·운영(플랫폼 누적 등록 현장 32개)·설비 392대·센서 936개를 단일 플랫폼으로 수용
  • 설비 확인까지 공정>설비>포인트>분석 5단계 화면 전환을 공정별 대시보드 1화면으로 통합
  • InfluxDB 이관 + 보존정책으로 관계형 시계열 증가를 상수화 — 관계형에 계속 뒀다면 연 ~137GB 증가 압력을 억제(유입 실측 3.10M pts/일 기준).
  • 집계 트렌드 조회를 최대 203배 단축(1년치 13.4s→66ms) — InfluxDB 5.4x·Redis 캐시 85~120x, 동일 데이터 A/B 실측.
  • 센서 수집 소켓을 고정폭 바이너리로 설계해 페이로드 5.7배(82%↓)·소켓 전송 최대 10.5배(HTTP 헤더 400B 제거) 절감.
  • 전체 스택을 Docker Compose로 컨테이너화해 클린 환경에서 DB 스택 cold-start 약 28초 달성 — 호스트 수작업 DB 설치 제거
  • InfluxDB에 일 ~3.10M 시계열 포인트를 적재·서빙(원본 보존 + CQ 장기 다운샘플)하고, 누적 등록 설비 392대 규모를 다수 앱 도메인 멀티테넌트로 운용.
  • 개발 벤치마크 실측 — Redis 캐시 적중률 98.29%로 대시보드 최근값·알람 조회 부하 최소화
  • 개발 벤치마크 실측 — 멀티스테이지 컨테이너 이미지 4.72GB→1.36GB(71%↓), CVE 666→344(48%↓)

기술 스택

VueReactTypeScriptNode.jsNestJSREST APIWebSocketSocket.IOMySQLInfluxDBRedisDockerDocker ComposeNginxLinuxCI/CDSciChartEChartsRBAC

링크

Masked Case Note → Masked Architecture Note →

갤러리

구현 화면과 핵심 산출물

제조 설비 예지보전 모니터링 플랫폼 - 구조도 - 모니터링 시스템 4계층 구조 (입력→수집→서비스→AI&DB)
구조도 · 이미지 01

모니터링 시스템 4계층 구조 (입력→수집→서비스→AI&DB)

제조 설비 예지보전 모니터링 플랫폼 - 구조도 - 바이너리 소켓 수집 게이트웨이 — 수집→디코딩→분기 흐름과 고정폭 레코드 레이아웃
구조도 · 이미지 02

바이너리 소켓 수집 게이트웨이 — 수집→디코딩→분기 흐름과 고정폭 레코드 레이아웃

제조 설비 예지보전 모니터링 플랫폼 - 구조도 - nginx 리버스 프록시 — 단일 도메인 path 분리로 운영·개발 v1/v2 동시 서빙 + 하드닝 5건
구조도 · 이미지 03

nginx 리버스 프록시 — 단일 도메인 path 분리로 운영·개발 v1/v2 동시 서빙 + 하드닝 5건

제조 설비 예지보전 모니터링 플랫폼 - 구조도 - 장기 집계 조회 202.8배 — MySQL 13,419ms → InfluxDB 사전집계 66ms (동일 데이터 A/B)
구조도 · 이미지 04

장기 집계 조회 202.8배 — MySQL 13,419ms → InfluxDB 사전집계 66ms (동일 데이터 A/B)

제조 설비 예지보전 모니터링 플랫폼 - 구조도 - 캐시 적중률 98.27% vs 워밍율 50.3% — 분모가 다른 두 지표
구조도 · 이미지 05

캐시 적중률 98.27% vs 워밍율 50.3% — 분모가 다른 두 지표

제조 설비 예지보전 모니터링 플랫폼 - 구조도 - 멀티스테이지 재구성 — 이미지 4.72GB → 1.36GB, CVE 666 → 344
구조도 · 이미지 06

멀티스테이지 재구성 — 이미지 4.72GB → 1.36GB, CVE 666 → 344

연결해서 볼 프로젝트

현재 사례와 기술 또는 업무 흐름이 이어지는 페이지입니다.

공작기계/MCT 신호분석 및 AI 진단2023.12 - 2026.05스마트그린산단/지하배관 관제 시스템 개발2024.01 - 2026.04온프레미스 RAG·Agent LLM 시스템2026.05 - 2026.06
프로젝트 목록으로
© 2026 Jaemin Han. All rights reserved.HAN JAEMIN — PORTFOLIO