조명/기기 제어 자동화로 구축하는 Smart Building Solution

🛠️ Skills

• NestJS(TS), typeORM, mqtt-js, jest, typemoq
• Go, mqtt-go, go-mongo-driver, viper, client-go, gorm, bunDB, goconvey, gomock
• AWS RDS, S3, AWS EKS, AWS ECR, AWS CloudWatch, EMQX
• Create React App(TS), MobX, mqtt-js

✍🏻 Description

기존 GRID의 제어 스케줄 기능을 "센서, 날씨 연동 조명 제어 자동화"로 확장하여 단순 시간 설정에 따른 조명 제어뿐만 아니라 연동된 센서 종류와 발동 조건에 따라 다양한 환경에서도 자동으로 스마트하게 제어, 관리되는 Smart Building Solution으로 발전시킨 장기 프로젝트입니다. 프로젝트는 서버 개발자 5명, 그리고 PM과 임베디드 개발자 1명으로 구성되어 풀스택 서버 개발자로서 참여하였습니다. 수행한 업무는 Smart Building Solution 사전 토대 격이라고 할 수 있는 “외부 Zigbee 통신 센서 산업용 시스템 통합 FE, BE 개발(2023)”과 “IR 가전 연동 FE, BE 개발(2024)”이고 2024년에는 PM 역할도 같이 겸하였습니다.

📝 Experience

💥 Zigbee 센서 GRID 시스템 내 통합으로 제어 스케줄 기능 업그레이드 근간 구축

Nov 2022 ~ May 2023

What’s the issue?

기존 조명 제어 스케줄 기능에는 설정 예약 시간에 맞춰 일회성 발동 기능만 존재. 여기에 타이머 기능, 특정 시간대 구간 설정과 조건 충족 시점마다의 발동 조건을 더한 “제어 자동화”로의 업그레이드를 위해서는 외부 센서를 통한 설정 필요. 자사 MESH 통신 모듈이 아닌 Zigbee 통신 모듈을 탑재한 타사 센서 사용을 위한 GRID 시스템 통합 도입이 선행되어야 함

What did I do?

• Zigbee Sensor 등록, 운용, 삭제 과정과 센서 타입별 데이터 분석 후 스펙, 파싱 로직 정의. 공통 데이터 저장 DB 스키마 구축 및 정규화 ⇒ 조도센서, 재실센서, 온습도센서, 문열림 센서, 모션센서 5종 센서 처리 완료. 센서↔데이터 1:N RDB relation 구축으로 결합도 낮추고 응집성 향상 ⇒ RDB, MongoDB를 사용하여 각각 센서 등록/삭제 이력, 일별 센서 정보 데이터 관리 및 사용자 맞춤 CSV 제공 ⇒ 센서 데이터 처리 페이로드 사이즈 최적화로 초기 200 ms → 평균 40 ms 로 처리 속도 1/5 수준 개선
• Zigbee Sensor 연동 자동화 신규 기능 중 조건 스마트 디밍, 동작 알림 메시지 기능 개발 기여 ⇒ MQTT Topic 메시지 수신 후 SMS 문자 발송까지 28 ms 내 처리 로직 구현 ⇒ Redis TTL 특성을 활용해서 조건 트리거 마다 무분별한 문자 발송 차단과 문자 사용 비용 절감. 이후 RDB 로 기능 fully migration에도 기능 호환 서빙 ⇒ 모션센서를 통한 인체활동 감지/미감지 구간 내 자동 밝기 조절 스마트 디밍 기능 추가로 단순 조명 ON/OFF 동작 외 다양한 사용자 경험 제공

Retrospective points

• 센서 타입마다 Zigbee 스펙이 다 다르고 방대한 데이터 사이즈를 최적화하기 위해 임베디드 개발자와 장시간 논의하며 필드를 지정하여 1 byte에 맞는 값으로 배열의 인덱스로 필드값을 전달하는 “byte order 컨벤션” 방식 도출
• 예를 들어 [0,1,255,3] 값을 받는다면 배열의 인덱스에 해당하는 필드는 각각 식별자, 타입, 센서값, 벤더 라고 약속하여 서버에서 파싱, 매핑 후 관리하는 것
• 이를 통해 json 구조를 최소화 하여 자사 임베디드 디바이스의 FW 처리 부담을 줄이고 향후 MQTT 스펙 정의에도 적절하게 활용하는 계기가 됨
• DB 스키마 설계할 때 Zigbee 센서의 info 와 value를 각각 별도 테이블로 나누고, value에는 data 날 것 그대로를 comma separated 문자열로 저장하여 사용처에서 매번 파싱하도록 했음. 추후, 팀 내 다른 개발자에 의해 타입/값 두 가지 컬럼을 넣는 것으로 바꿨는데 그 당시에 이런 구현 고민하지 않아 기술 부채로 남은 아쉬움이 있음
• 초기 설계 시 일일 SMS 문자 발송 제한을 위해 MySQL보다 Redis의 TTL 사용의 효용성이 크다 판단하여 적용했는데 이후 팀차원에서 Redis 사용을 줄여나가면서 이를 MySQL로 이관하며 두 처리방식의 장단점을 고민해봄

💥 IR 가전 GRID 시스템 내 통합으로 제어 자동화 업그레이드

Mar 2024 ~ Aug 2024

What’s the issue?

Zigbee 센서를 통해 기존 스케줄 기능을 조명 제어 자동화로 확장했지만, 사용 고객사 현장에선 자동화의 발동 동작으로 조명뿐만 아니라 에어컨과 같은 IR 가전 제어도 가능했으면 하는 니즈가 있었음. 이를 위해 B2C 서비스인 Home Recipe에서만 가능했던 조명을 이용한 가전 제어 기능을 B2B 서비스인 GRID에 도입하는 작업이 선행되어야 함

What did I do?

• MQTT topic 로직 & IR Device CRUD 풀스택 개발 ⇒ S 사, L 사 시스템 에어컨 제어 요청 시 평균 응답 속도 100 ms 대 수준 구현 ⇒ 신규 IR 가전 확장 시 서버에 유연하게 추가할 수 있게 관리자 웹 편집 기능 제공
• 에어컨 정보 리더기(자사 mesh 기기) 연동/해제 DB 스키마, MQTT topic 정의 및 REST API 개발 ⇒ 리더기를 통해 수집한 에어컨 상태 정보 CSV 파일화 및 사용자 HTTP 요청 시 400 ms 내 제공 ⇒ 기존 조명 제어만 가능했던 자동화를 복합 기기 조건 및 에어컨 제어 가능 자동화로 기능 업그레이드

Retrospective points

• B2C 서비스에만 있어 다뤄보지 못한 IR 신호 가전 제어 기능을 직접 서비스에 접목하면서, 수반되는 부수 설계와 개발 문서 작성도 진행했으나, 이를 통한 B2C 레거시 서비스 개선까지 같이 병행하지 못해서 아쉬움
• IR 가전과 자사 에어컨 상태 리더기(하드웨어 디바이스) 연동, 미연동 여부에 따라 Read/Write 대상이 되는 DB 저장 값 차이, 상태 추상화 등 일반적인 “기기 등록”과 다른 로직 설계를 고민하는 계기도 되었음