POOOLING FOREST
맨땅에 헤딩하던 IoT 프로젝트, ThingsBoard로 구원받은 이야기 - 초보 IoT 개발자가 겪은 시행착오와 오픈소스 플랫폼 ThingsBoard를 통해 데이터 수집, 시각화, 규
Case Studies

맨땅에 헤딩하던 IoT 프로젝트, ThingsBoard로 구원받은 이야기

초보 IoT 개발자가 겪은 시행착오와 오픈소스 플랫폼 ThingsBoard를 통해 데이터 수집, 시각화, 규칙 엔진 문제를 해결하며 프로젝트를 성공시킨 경험담을 공유합니다.

김영태

테크리드

안녕하세요. 풀링포레스트 테크리드 김영태입니다.

개발자 생활을 하다 보면 종종 "이거 간단해 보이는데 금방 만들겠지?"라고 시작했다가, 거대한 파도에 휩쓸리는 경험을 하곤 합니다. 저에게는 몇 년 전 처음 맡았던 IoT 프로젝트가 딱 그랬습니다. 당시엔 센서 데이터 몇 개 받아서 DB에 넣고 그래프로 보여주면 끝 아니냐고 생각했습니다. 솔직히 말해, 그 안일한 생각이 팀 전체를 야근의 늪으로 빠트릴 줄은 꿈에도 몰랐습니다.

MQTT 브로커를 띄우고 디바이스와 통신하는 것까진 좋았습니다. 그런데 디바이스가 100개, 1,000개로 늘어나자 문제가 터지기 시작했습니다. 디바이스 인증은 어떻게 관리할 것인지, 서로 다른 프로토콜(CoAP, HTTP)을 사용하는 장비는 어떻게 통합할 것인지, 무엇보다 쏟아지는 데이터를 실시간으로 시각화하는 대시보드를 프론트엔드 팀 없이 어떻게 구축할 것인지 막막했습니다. 결국 비즈니스 로직을 짜는 시간보다 인프라와 보일러플레이트 코드를 만드는 데 시간을 다 쏟고 있었죠.

그때 "왜 바퀴를 다시 발명하고 있을까"라는 자괴감 속에서 찾아낸 오픈소스가 바로 ThingsBoard였습니다. 오늘은 제가 직접 겪은 시행착오를 바탕으로, IoT 백엔드를 구축하려는 분들에게 이 도구가 왜 강력한 무기가 될 수 있는지 이야기해보려 합니다.

ThingsBoard를 처음 접했을 때 가장 놀랐던 점은 단순히 데이터를 받아주는 '브로커' 역할에 그치지 않는다는 점이었습니다. 디바이스 관리부터 데이터 수집, 처리, 시각화까지 올인원으로 제공하는, 말 그대로 '플랫폼'이더군요.

가장 먼저 우리 팀을 구원한 기능은 'Rule Engine(규칙 엔진)'이었습니다. 이전에는 특정 온도 이상일 때 알람을 보내려면 백엔드 코드에 if문을 박아 넣고 배포 과정을 거쳐야 했습니다. 하지만 ThingsBoard의 룰 엔진은 노드 기반의 UI로 데이터 흐름을 시각적으로 설계할 수 있게 해줍니다.

예를 들어, 텔레메트리 데이터가 들어오면 유효성을 검증하고, 특정 임계값을 넘으면 이메일을 발송하고, 동시에 DB에 저장하는 로직을 코딩 한 줄 없이 '체인'으로 엮어서 구현할 수 있습니다. 운영 중에 로직을 변경해야 할 때 서버를 재배포할 필요가 없다는 건 운영 관점에서 엄청난 이점입니다.

두 번째로 인상 깊었던 건 '시각화' 능력입니다. 보통 백엔드 개발자들이 가장 고통받는 부분이 대시보드입니다. 데이터를 잘 쌓아놔도 예쁘게 보여주지 못하면 클라이언트는 만족하지 않으니까요. ThingsBoard는 내장된 위젯 라이브러리가 상당히 강력합니다. 시계열 차트는 물론이고, 산업 현장에서 쓰이는 SCADA 스타일의 심볼이나 지오메트리 맵까지 지원합니다. 프론트엔드 개발자의 리소스를 들이지 않고도 그럴싸한 관제 화면을 뚝딱 만들어낼 수 있었을 때의 그 안도감은 아직도 생생합니다.

기술 스택 관점에서도 매력적입니다. 자바(Java) 기반으로 작성되어 있어 엔터프라이즈 환경에 익숙한 백엔드 개발자들이 접근하기 좋고, 마이크로서비스 아키텍처(MSA)를 지원해서 카프카(Kafka) 같은 메시지 큐와 연동해 대용량 트래픽을 처리하도록 확장하기도 용이합니다. 단순히 장난감 프로젝트용이 아니라, 실제 스마트 팜이나 스마트 에너지 같은 대규모 산업 현장에서도 충분히 버틸 수 있는 구조를 갖추고 있다는 뜻입니다.

물론 은탄환은 없습니다. 기능이 방대한 만큼 초기 러닝 커브가 분명히 존재합니다. 엔티티 간의 관계를 정의하거나 복잡한 룰 체인을 디버깅할 때는 문서와 씨름해야 하는 시간도 필요합니다. 하지만 센서 데이터를 수집하기 위해 밑바닥부터 네티(Netty) 서버를 띄우고 프로토콜 파서를 짜는 고생에 비하면, 이건 즐거운 고민에 가깝습니다.

결국 우리가 집중해야 할 것은 '데이터를 어떻게 받을까'가 아니라 '그 데이터로 어떤 가치를 만들까'입니다. 인프라 구축에 에너지를 쏟느라 정작 중요한 비즈니스 로직을 놓치고 있다면, ThingsBoard 같은 검증된 오픈소스 플랫폼을 적극적으로 도입해보시길 권합니다.

여러분의 프로젝트가 '삽질'보다는 '가치 창출'에 더 가까워지기를 응원합니다. 다음에는 이 플랫폼을 실제 쿠버네티스 환경에 배포하며 겪었던 트러블슈팅 경험을 들고 오겠습니다.

지금 읽으신 내용, 귀사에 적용해보고 싶으신가요?

상황과 목표를 알려주시면 가능한 옵션과 현실적인 도입 경로를 제안해드립니다.