메를로랩 에너지 모니터링 시스템(MEMS) 대시보드 개발

🛠️ Skills

• NestJS(TS), TypeORM, Go
• AWS RDS, AWS EKS, AWS ECR, InfluxDB v2
• React(TS), react hooks, mui, emotion, mobX, echarts

✍🏻 Description

Energy Monitoring System(EMS)은 전력, 가스 등의 에너지원의 소모량을 실시간으로 측정하고 관제하며 사용 효율을 높이고 비용을 절감하는 데에 효용성이 큰 시스템입니다. 메를로랩만의 MEMS를 구축함으로써, 전력량 계측 시스템과 메를로랩 IoT 조명의 소모 전력 및 절감 전력을 실시간으로 모니터링하고 나타내어 사용 고객사에게 단순 조명 제어 뿐만 아니라 에너지 관리까지 가능한 폭넓은 경험을 제공하는데에 큰 의의가 있습니다. 프로젝트는 초기 AMI 모니터링 대시보드 FE, BE 개발과 시계열 DB 적용, 1차 프로덕션 배포까지 1인 개발로 마친 후 7월, 2차 자사 조명 연계 절감량 표기 개발부터는 BE 개발 2명, FE 개발 1명으로 하여 프로젝트 리드와 FE 개발을 맡아 진행하였습니다.

📝 Experience

💥 시계열DB를 이용한 AMI 소모전력량 데이터 모니터링 대시보드 개발

Feb 2025 ~ Jun 2025

What’s the issue?

AMI는 Advanced Metering Infrastructure의 약자로, 양방향 통신망을 이용하여 전력사용량, 시간대별 사용요금을 실시간으로 원격 확인할 수 있는 전자식 전력량 계측 시스템. 메를로랩의 AMI 기기를 사용하는 주요 고객사 소모전력량 모니터링을 위해 영업부서에서는 타 회사 전력량 모니터링 제품을 매달 구매하여 사용하고 있었음. AMI 기기 설치 현장이 늘어남에 따라 수입 비용 지출을 줄이고 제한적인 기능과 기존 서버와의 낮은 확장성 해결을 위해 새로운 자사 모니터링 시스템 개발의 필요성을 느낌.

What did I do?

• 시계열 DB 중 하나인 InfluxDB ver.2 도입, 시계열 DB 스키마 정의 및 Go 언어 기반 서버내 migration 코드 설계 ⇒ 실시간 기록 bucket, 15분 합산 bucket과 task로 자동 집계 및 15분별 전력량 데이터 기준 수립 ⇒ 기존 MySQL로는 표현하지 못했던 시계열 데이터 처리 팀 표준 마련 및 bucket별 저장 데이터 유지기간 다변화로 DB 최적화 개선
• 시간 흐름에 따른 데이터 기록으로 NestJS 서버 내 실시간 CSV 파일 변환 기능 도입 ⇒ 기존 당일 데이터 다운로드 불가, 특정 기간 CSV 추출 기술적 한계 해소 ⇒ AWS S3 별도 저장 및 소모전력량 계산용 cronjob 애플리케이션 대체로 서버 비용절감 기여
• 사용자 웹 화면 대시보드 내 AMI 모니터링 화면 구현 ⇒ 계정 내 등록된 허브, AMI 기기, 연결 채널 별 monitoring 세분화 차트 제공으로 사용자 편의성 증진 ⇒ 전력량 원격 검침 지원 및 기존 외부 모니터링 서비스 대체를 통해 월간 600만원 운영비 절감 기여
• 15분 합산 데이터 bucket 내 월,일,15분 데이터 집계 로직 성능 개선 ⇒ 초기 HTTP GET 요청시 최대 7.3s → 최대 356 ms 단축 ⇒ 4,000만 개의 InfluxDB 데이터 기준 influxDB task(cronjob) OOMKilled → 21초 수행 및 안정적 유지

Retrospective points

• 시계열 DB 접목에 대한 외주 개발 자문 의뢰 이후 설계부터 관리까지 해보며 IoT 데이터 관련 추적, 로깅, 변화량 시각화에 대한 인사이트를 기를 수 있었음
• 기존 MySQL 방식으로는 시간에 따른 값의 변화량을 담기에는 향후 방대해질 양과 관련 로직 설계에 적절하지 않다고 팀 내부적으로도 공감함
• 시계열 DB 솔루션 중 커뮤니티가 제일 크고 TICK 스택으로의 확장이 수월한 InfluxDB 도입으로 자연스럽게 되었는데 다른 솔루션들 대비 명확한 배제 근거를 수립하지 못해서 아쉬움이 남음
• NestJS와 Go 기반 두 서버 애플리케이션에서 InfluxDB를 각각 사용하며 Flux Query를 이해하고 여기에 대한 빌더 패턴을 적용해 볼 수 있었음
• 기존에 처리 불가하던 당일 실시간 데이터 CSV 변환 및 추출이 가능해지면서 향후 AMI 이외 다양한 기기들에도 적용이 된다면 이전 제약 사항들이 다소 해결될 수 있겠다는 생각을 할 수 있게됨
• 최초 설계에서는 월, 일별 데이터를 15분씩 하루 96개 합산 데이터를 내려주어 월말까지 데이터가 쌓일수록 GET 응답 속도가 점점 느렸음
• 해당 월, 해당 일자 합산 데이터를 주기적으로 계산하고 따로 저장하도록 설계를 수정하니 속도가 훨씬 빨라지고 확장성이 생기는 것을 체감하며 필요에 맞는 시계열 데이터 가공에 대해서도 고민해 볼 수 있었음
• cronjob과 같이 주기성 로직을 수행하는 influxDB의 task를 통해 월/일/15분 별 합산데이터를 산출하는데 성능 테스트 하는 과정에서 flux 문법 자체로 속도와 안정성 측면에서 큰 개선을 이끌어낼 수 있게됨

💥 등록된 조명의 절감전력량이 추가된 “에너지 모니터링 대시보드” 로의 확장

Jul 2025 ~ Sep 2025

What’s the issue?

배전함에 조명용 전력을 별도로 분리 구축하고 AMI 기기를 연결하여 전력 소모량을 계측한 현장의 경우 메를로랩 조명이 설치되었다면 수집되는 전력량 데이터는 조명의 소모전력량으로 볼 수 있음. 이 때, 조명의 밝기를 낮추어 운용한다면 100% 밝기 대비 절감된 소모전력량을 측정할 수 있게 되고, 이를 대시보드에 같이 표현함으로써 사용 중인, 절감된 전력 소모량에 대한 에너지 모니터링으로의 확장이 필요하게 됨.

What did I do?

• AMI 기기 내 하위 채널 각각에 고객사가 등록한 조명을 연동할 수 있는 페이지 및 GET API 개발 ⇒ mui의 x-tree-view를 활용한 그룹별 조명 리스트 트리 구조 표기로 1,000개 이상 많은 조명을 가진 현장도 그룹 기반으로 접고 펼치며 손쉽게 GUI로 연동 가능
• 허브 내 등록된 AMI 기기/채널 별 연동 기기 리스트 요약 페이지 및 GET API 개발 ⇒ 기존 장치 상세 페이지로는 표현할 수 없던 AMI의 설정/표시 기능을 세분화하면서 사용자 경험 향상 기여 ⇒ 모니터링 대시보드 화면에서 AMI에 연동된 조명에 대해 서버에서 절감전력량을 계산, 수집할 수 있는 트리거 역할 마련
• AMI Monitoring → Energy Monitoring 대시보드로의 확장에 따른 연동 조명 절감량 그래프 표기 추가 ⇒ AMI 전력량 데이터 위에 서버로부터 계산한 절감전력 계산값을 스택 차트로 확장. 이를 통해 월별/일별/15분별 절감량 요약 시각화 경험 향상

Retrospective points

• 리드 개발과 PM을 병행하며 서비스 기획과 UI 개발을 고안하는 과정이 쉽지는 않았지만 사용자의 입장과 서비스 흐름에서 어떻게 화면을 그리고 컴포넌트를 배치할지 깊게 고민할 수 있었음
• AMI 기기에 조명을 논리적으로 연동하는 기능을 위한 DB 구조 설계를 하면서 Many to Many 관계의 설계와 FK에 대해 함께 하는 팀원들과 같이 토론하고 적절한 구조로 적용할 수 있었음
• 조명이 물리적으로 등록해제되거나 공장초기화되는 경우 기존 레코드 처리를 위해 이벤트 하나의 추가 로직으로 처리를 했는데 별도 이벤트로 처리를 하면 어땠을까 생각해봄
• 조명을 연동하고, 연동된 조명에 대한 절감량 연산 관련 기능에서 Domain Model 정의와 Aggregate 도출, 리팩터링을 고민할 시간이 부족하여 다음 개발 task로 넘길 수 밖에 없던 게 아쉬움이 남았음
• 트리 구조로 허브 내 그룹 > 조명에 이르도록 UI 구성을 했는데 더 가독성과 직관성을 높일 수 있는 UI가 있을지 생각해봄