BLE와 MQTT 중 무엇을 선택해야 하나요?
BLE와 MQTT를 둘 중 하나로 고르는 질문부터 다시 정리해야 합니다. BLE·Wi-Fi·LTE는 기기의 연결 수단을 검토할 때 등장하고, MQTT는 연결된 장치와 서버 사이에서 메시지를 주고받는 방식입니다. 예를 들어 센서는 BLE로 게이트웨이에 연결하고 게이트웨이는 인터넷을 통해 MQTT 메시지를 서버로 보낼 수 있습니다.
통신 규격보다 먼저 확인할 현장 조건
- 기기는 이동하는가, 특정 위치에 고정되는가
- 배터리 교체가 가능한가, 상시 전원을 공급할 수 있는가
- 스마트폰·공유기·게이트웨이를 누가 설치하고 관리하는가
- 수집만 하는가, 원격 제어도 필요한가
- 인터넷이 끊겨도 계속 수행해야 하는 기능은 무엇인가
- 벽·금속 설비·지하 공간 등 현장 장애물이 있는가
| 후보 | 먼저 확인할 조건 | 견적 요청서에 적을 질문 |
|---|---|---|
| BLE + 스마트폰 | 사용자가 기기 근처에서 앱을 쓰는 흐름 | 앱이 없는 동안 측정값은 어디에 저장하나요? |
| Wi-Fi | 공유기 설치·초기 등록·네트워크 관리 주체 | 비밀번호나 공유기가 바뀌면 어떻게 복구하나요? |
| LTE 계열 | 설치 지역 통신 환경·단말·요금제 | 개통·통신비·해지와 음영 구간은 누가 관리하나요? |
| LoRa 계열 | 현장 배치·게이트웨이·전송량 요구 | 정확한 규격과 데이터·제어 지연 조건을 확인했나요? |
| RS485 연결 장비 | 배선·장비별 상위 프로토콜·레지스터 문서 | 기존 장비의 데이터 주소와 단위가 제공되나요? |
위 표는 특정 통신 방식의 성능을 보장하는 사양표가 아닙니다. 도달 거리나 배터리 수명은 모듈·안테나·전송 주기·설치 환경에 따라 달라집니다. 제안서에 숫자가 제시되면 측정 조건과 현장 검증 방법을 함께 요청하세요. 특히 LoRa와 LoRaWAN, RS485와 그 위에서 쓰는 장비 프로토콜을 같은 이름으로 뭉뚱그리지 않는 것이 좋습니다.
MQTT를 쓰면 데이터 누락과 중복이 해결되나요?
자동으로 해결되지는 않습니다. MQTT의 전달 수준과 브로커 구현의 지원 범위를 확인하고, 서비스에서 누락·중복을 처리하는 기준을 정해야 합니다. AWS IoT Core는 MQTT QoS 0과 1을 지원하며 QoS 1에서는 중복 전달 가능성을 고려해야 합니다. 다른 브로커를 선택하면 해당 제품의 지원 범위와 제한을 별도로 확인해야 합니다.
측정 데이터에는 기기 식별자, 측정 시각, 메시지 식별 정보를 포함하는 방안을 검토하세요. 서버가 받은 시각과 실제 측정한 시각을 구분하면 통신 복구 후 과거 데이터를 현재 상태로 잘못 표시하는 일을 줄일 수 있습니다. 원격 제어도 ‘명령 접수’와 ‘장치 실행 완료’를 다른 상태로 다뤄야 합니다.
개발사와 연결 구조를 합의하는 방법
- 기기 → 게이트웨이 → 서버 → 앱·관제의 흐름을 한 장으로 그립니다.
- 각 구간의 담당자와 데이터 형식, 인증 방법, 실패 시 동작을 적습니다.
- 정상 전송과 통신 단절 후 복구를 모두 PoC에 포함합니다.
- 예상 대수와 전송 주기를 기준으로 운영 규모를 계산합니다.
- 최종 선택 이유와 현장 검수 조건을 요구사항 문서에 남깁니다.
참고 자료
기술 동작은 아래 공식 문서를 참고했습니다. 적용 조건과 지원 버전은 프로젝트 환경에 맞게 확인하세요.
작성팀 소개
TOPPING 기술팀 · 개발 · 아키텍처 · QA
웹·앱·백엔드·IoT·데이터 연동을 수행하는 TOPPING의 개발·아키텍처 담당 팀입니다. 시스템 구조 설계, 기술 검수, 인수인계와 운영 안정화를 담당합니다.
