10만+ 기기 제어 및 운용에 적합한 GRID(산업용 IoT 조명 제어 솔루션) 성능 최적화

🛠️ Skills

• NestJS(TS), TypeORM, mongoose, kafkajs, mqtt-js
• AWS RDS, S3, AWS EKS, AWS ECR, AWS Route53, AWS CloudWatch
• EMQX, Apache Kafka, Prometheus, Grafana, kafka-ui
• jenkins CI, terraform
• Create React App(TS), React-router-dom, react hooks, react-bootstrap, mui, emotion, mobX

✍🏻 Description

GRID는 허브(Hub)라는 Wi-Fi 펌웨어 기반 중앙제어 하드웨어 기기를 통해 메를로랩의 MESH 기술이 탑재된 조명, 장치, 센서 등의 디바이스를 클라우드 서버 내에서 관리하기 위한 B2B IoT Web Server Application 입니다. 2022년부터 메인 풀스택 웹 애플리케이션 개발을 시작으로 기존 기능 유지보수와 신규 기능 추가, 메인 코드 리뷰어를 담당했습니다.

📝 Experience

💥 최대 1만 개 조명 제어 수용 한계 개선과 에너지모니터링 데이터 관리 체계 개편

Jan 2022 ~ Jan 2023

What’s the issue?

유저가 등록 조명의 “에너지모니터링” 파일 다운로드를 요청 시 서버가 재시작을 반복하다 제어 불능까지 되는 문제로 인해 당시 서버는 최대 1만 개만 조명 수용이 가능한 구조적 한계 존재. 이는 서버에서 소모전력량 계산 및 에너지모니터링 로그 기록 중 RDB에 빈번한 Read/Write 시도로 DB 커넥션 pool 과다 점유, 커넥션 해제 지연, 서버 다운이 복합적으로 일어나기 때문으로 서비스 안정성 및 확장성 저하 유발하게 됨.

What did I do?

• 불필요한 DB READ 원천 차단을 위해 레거시 컬럼 삭제 후 정규화, “에너지모니터링” DB 스키마를 재정의하고 전력량 계산과 저장 데이터 성격에 더 적합한 NoSQL 방식인 MongoDB로 migration ⇒ DB 과부하와 무분별한 커넥션 점유 현상 차단, Read/Write 목적에 부합하는 DB 다변화로 기존 RDB 의존성 해결 및 ORM 성능 개선
• 조명 순간 소모 전력량 계산 및 기록을 메인 서버에서 분리하고 이벤트 트리거와 Kafka를 통해 마이크로서비스에서 메시지 구독 후 비동기 처리하는 방식을 도입 ⇒ 단일 서버 로직 편중 구조, 서버 부하 및 의존성 해소
• 서버에 등록된 허브 개별 하루치 분량의 소모전력량, 누적소모전력량 일괄 계산하여 CSV 파일로 만들어 AWS S3 버킷에 저장하는 CronJob 개발 ⇒ 조명 제어 / 전력량 계산 / 로그 기록 / 파일 추출 일련의 독립된 자동화 프로세스 완성 ⇒ 웹에서 다운로드 요청시 4.4MB 파일 기준 서버 shutdown → 137 ms 로 안정적인 데이터 서빙
• 11개의 Server Application과 12개의 CronJob이 하나의 쿠버네티스 클러스터 환경에서 동작하는 MSA 구축 기여 ⇒ 기존 단일 BE 서버 구조 처리 한계인 10K 조명 제어 → 최소 100K 동시 조명 제어 처리 구조로 확대

Retrospective points

• 입사 초기 상용 설치 조명 수는 1만 개도 채 되지 않았으나 조명 소모 전력량 에너지모니터링 로그 파일 다운로드 시 서버다운 현상 방지를 최우선 과제로 삼아 온보딩 이후 개선 작업 돌입. 시스템을 빠르고 깊게 이해하게 된 결정적인 프로젝트가 되었음
• 문제 해결 과정에서 AWS CloudWatch, Grafana 등 다양한 모니터링 방법을 이해할 수 있었으나, 초기 셋팅값 이후 Prometheus 메트릭 지표 추가 처럼 더 deep하게 파고들지 않아 아쉬움이 있음
• 초기 전력량 계산 로직은 “에너지 모니터링 CSV 다운로드”라는 하나의 비즈니스 로직에서 연속적으로 진행되었음. 문제 해결을 위해 전력량 계산 연관 변수와 수식의 복잡성을 간소화하며 도메인 이벤트의 정의와 단일 책임 원칙(SRP)을 고민해 봄
• CSV 다운로드는 CSV 다운로드의 비즈니스만 처리하자는 개념을 잡고 여기에 필요한 제어 유형별, 주기 별 전력량 계산을 기존 백엔드 애플리케이션에서 분리하는 것을 고안. 이때 이벤트로 처리하기보다 동일 프레임워크 베이스의 마이크로서비스로 분리 처리하는 것으로 방향 제시하고 진행함
• 대량의 제어 데이터를 비동기적으로 수신할 수 있고, 메시지 큐에 적재하며 장애 발생 이후도 커버가능한 kafka 도입을 주도해 봄. 이후 마이크로서비스와 pub/sub 구조를 가지면서 부하 분산과 대용량 대규모 서비스 기반도 경험해 본 건 좋았으나 이후 시스템 내 활용도를 더 높이지 못한 아쉬움도 있음
• 소모 전력량 데이터의 의의와 목적을 깊이 고민한 후 기존 RDB에서 NoSQL 방식의 MongoDB를 채택함으로써 MySQL 이외의 문법과 스키마를 공부해 보고, 향후 서비스 전반에 확대해 나갈 수 있었음
• CSV 다운로드 속도 개선을 위해 데이터 저장 정책 수립을 마련하고, S3 presigned 저장소 활용을 도입하며, 초기 1개만 있던 cronjob을 적극 활용하게 된 계기가 됨

💥 22MiB로 최적화된 Git 모노레포 소스코드 관리 구성 및 일관된 팀 개발방법론 정착

Jan 2022 ~ Nov 2025

What’s the issue?

팀 내 신규 개발자 유입과 더불어 6명의 적은 인력으로 GRID의 시스템과 세부기능, 목적에 맞는 마이크로서비스를 유지보수, 개발하고 컴팩트하게 관리를 하기 위해 지속가능한 코드 품질, 관리 체계가 필요함을 느낌

What did I do?

• Jest 기반의 단위테스트와 supertest, typemoq을 이용한 통합 테스트 보완 ⇒ Jest Test suites 287 → 515개, 총 테스트 927 → 2,511개로 시스템 전체 테스트 커버리지 2.5배 향상 기여
• Backend application 내 4 계층 아키텍처, DDD(도메인 주도 개발) 적용으로 조명 제어, 인증/인가 처리, 임베디드 펌웨어 관리 등 솔루션 내 여러 비즈니스 도메인 단위 로직 개발 참여 ⇒ 임베디드 허브(Hub) 기기와의 MQTT 통신 메시지 규약 정의 기여 ⇒ yarn, nx, workspace 기반의 모노레포 구성을 위한 NestJS 애플리케이션 공통 모듈, configuration 환경 변수 설정, Jenkins CI/CD 파이프라인 단일화 기여 ⇒ 2025년 11월 기준 깃헙 레포지토리 최다 기여(1,352개 / 4,974개)

Retrospective points

• nx를 사용한 모노레포 소스코드 관리와 MSA 등을 입사 초기부터 경험해 보고 서비스 규모가 커져갈 때의 방향, yarn 에서 pnpm 으로의 전환을 통한 성능 개선에 대해서 고민해 볼 수 있었음
• 도메인 주도 설계 패러다임으로 IoT 제어라는 도메인을 두고 여러 요구 기능을 개발하고 발전시키는 팀 내 일관된 개발 기조 형성이 적은 개발 인력으로 시스템 운영 및 확장하는 데 도움이 되었음
• 자사 Mesh 모듈 탑재한 기기의 등록 방식에 따라 조명과 구분되는데, 기존에는 조명 외에 “Switch”라는 이름으로 존재했음. 유지보수 하면서 다양한 Mesh 기기가 시스템에 추가되고, Switch가 예약어이기도 하고 도메인에 부적합하다고 느껴 “MeshDevice” 라는 도메인으로 확장하여 리펙토링 진행. 이를 통해 적절한 유비쿼터스 언어로 소프트웨어에 지속적인 발전을 해야 할 중요성을 체감
• MQTT topic 메시지 관련 로직에서는 Delegating Pattern도 부분적으로 도입 및 적용해 봄
• 특화된 도메인 전문가(기획) 부재와 도메인 이벤트 정의 및 별도 이벤트 스토밍 시간 부족은 개선 여지 존재하지만 팀원들과 지속적인 회의를 통해 보완하고 발전해 나갈 수 있었음
• Jandi 웹 훅 연결, AWS CloudWatch 로깅, 깃헙 slack 웹 훅 연동도 진행했으나, 지금 다시 손볼 수 있다면 정확한 지표 수집과 에러 모니터링을 위해 Prometheus와 Sentry 도 붙여볼 것 같음
• 2024년 TDD 본격 도입 이후 기존 파일에 대한 단위 테스트, 통합 테스트 보강을 진행했으나 e2e 테스트 커버리지 향상 역시 필요성을 느낌