2023.10 - 2026.05
기간 - 2023.10 - 2026.05
제조 설비 예지보전 모니터링 플랫폼
진동·AE·온도·가스·PLC 등 설비 상태 데이터를 수집 서버에서 API, DB, 운영 화면으로 연결하고 Raw 조회, Trend, Spectrum, STFT, 대시보드, 알람, 진단 이력, 관리자 모드와 서버-DB 운영 안정화까지 구현한 산업 IoT 플랫폼입니다.
Vue / React / TypeScript / Node.js
역할, 구현 흐름, 결과 중심으로 정리
단일 MySQL에 시계열·메타 혼재 → 집계 조회(GROUP BY 시간버킷) 병목·저장 급증.
시계열=InfluxDB, 핫데이터=Redis, 관계형=MySQL로 책임 분리.
접근 패턴·보존 주기 기준 라우팅, 다운샘플·재연결 정책, 부하테스트로 검증.
신규 과제 기본 저장 구조로 표준화, 파일 저장소 분리까지 확장.
문제에서 구현 결과까지
진동·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/알람/진단 데이터를 한 흐름에서 확인할 수 있는 화면 구조 구현
기능 개발 단위로 본 구현 범위
하나의 프로젝트 안에서 직접 설계하고 구현한 주요 기능을 화면, 역할, 구현 내용, 결과 단위로 나눠 정리했습니다.
대용량 시계열 조회 성능 저하 → 저장 계층 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개 앱 도메인을 멀티테넌트로 운용
트러블슈팅 — 겪은 문제와 해결
개발·운영 중 실제로 마주친 문제를 증상, 원인 추적, 조치, 결과 단위로 정리했습니다.
간헐적 수집 실패·통신 장애 → 로그·연결 테스트로 계층별 원인 추적
현장 수집이 간헐적으로 실패하고 통신이 끊겼는데, 원인이 단말·망·서버 여러 계층에 걸쳐 있어 재현이 어려웠습니다.
- 수집 실패 시 로그·재시도 기준을 정의해 실패 지점을 기록
- 연결 테스트로 단말→망→서버 계층을 좁혀 원인 격리
- 권한·포트·Nginx 라우팅 이슈를 개별로 재현·수정
결과 데이터 누락·통신 실패·권한/포트/라우팅 문제를 원인 계층까지 좁혀 해결
운영 중 메모리 부하 → 고정 특징 데이터 적재·처리 구조 개선
고정 특징 데이터를 비효율적으로 적재·처리해 운영 중 메모리 부하가 커졌습니다.
- 적재·처리 경로를 재구성하고 불필요한 상시 로딩을 제거
- 조회 패턴에 맞게 캐시·쿼리 경로를 정리
결과 메모리 사용량 약 28% 절감
MaxListenersExceededWarning 반복·수신 불안정 → 소켓 게이트웨이 전역 단일화
43개 도메인 모듈이 각자 EventGateway를 providers에 등록해 리스너가 누적, Node 기본 한계를 초과하며 실시간 수신이 간헐적으로 불안정해졌다.
- @Global() SocketGatewayModule을 신설하고 EventGateway를 단일 등록 — AppModule에서 한 번만 임포트
- 별도 EventHandlerGateway(80줄)를 삭제하고 joinRoom·leaveAllRoom·insert* 핸들러를 EventGateway로 통합
- 기존 소켓 엔드포인트·이벤트 계약은 유지한 채 55개 파일 정리
결과 MaxListenersExceededWarning 완전 제거, 실시간 수신 안정화 — NestJS 공유 싱글톤은 global module로 선언하는 패턴 확립 (커밋 39190656)
센서 두절인데 옛 값이 '정상'처럼 표시 → 오프라인 '—' 표기 정책 통일
센서가 10분 이상 데이터를 보내지 않아도 RPM·전류·전압이 마지막 수신값으로 남아, 운영자가 설비 가동 중으로 오인할 위험이 있었다. 원인은 OFF 분기의 값 초기화 누락 + 포매터가 결측 센티널을 0으로 처리 + 대시보드별 오프라인 임계 불일치(5분/10분).
- 10분 초과 OFF 분기에서 표시값 초기화를 멱등 호출로 보장
- 포매터가 '-' 센티널을 0이 아닌 '—'로 통과하도록 정책 통일
- 대시보드별 오프라인 임계를 10분으로 일원화, 표시 셀만 «—» 처리(계산값은 보존) — 7개 파일
결과 '데이터 없음'과 '정상값 0'을 UI에서 명확히 구분해 오판 방지 — 오프라인 표기 정책 전 화면 일관화 (커밋 2d2b9f15)
'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건)
문제
-장 설비 데이터가 여러 수집 경로, 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%↓)