로봇 시스템을 만들다 보면 어느 순간
"이 장비들끼리 어떻게 통신시키지?"라는 문제에 부딪힌다.
HTTP는 너무 무겁고, 그렇다고 소켓을 하나하나 직접 짜기? 일단 짜는 것도 문제고, 관리가 지옥이다.
그 외에는 난 ROS밖에 몰랐었는데,
업무 회의 중에 갑자기 MQTT라는 녀석이 등장했다.
MQTT가 뭐지
MQTT는 Message Queuing Telemetry Transport의 약자다.
가볍고, 느린 네트워크에서도 잘 돌아가는 메시징 프로토콜이다.
원래 1999년에 석유 파이프라인 원격 모니터링용으로 만들어졌다고 한다.
석유 파이프라인이라니, 출생부터가 산업 현장이다.
위성 통신처럼 대역폭이 극도로 제한된 환경에서 센서 데이터를 보내기 위해 설계됐고,
프로토콜 헤더가 최소 2바이트밖에 안 된다.
Pub/Sub 모델
MQTT의 핵심은 Publish/Subscribe 구조다. 익숙한 개념이다.
발행자(Publisher)는 메시지를 특정 "토픽"에 던진다.
구독자(Subscriber)는 관심 있는 토픽을 구독한다.
그런데 이 둘은 서로의 존재를 모르는데,
그걸 가운데서 브로커가 중개를 해준다.
장비가 늘어나도 구조가 안 바뀐다.
1:1 소켓 통신이었으면 연결 수가 으로 폭발할 상황이,
Pub/Sub에서는 구독자만 추가하면 끝이다.
토픽 설계
토픽은 슬래시(/)로 계층을 나눈다.
robot/01/status
robot/01/command
robot/02/status
sensor/temperature/zone_a와일드카드도 있다.
+는 단일 레벨, #는 하위 전체다.
robot/+/status- 모든 로봇의 상태를 구독robot/#- 로봇 관련 모든 메시지를 구독
토픽 설계를 처음에 대충 하면 나중에 진짜 고생한다.
data 하나에 다 때려넣으면 나중에 필터링할 방법이 없다.
실제로 때려박다가 리팩토링한 경험이 있다
QoS 레벨
QoS(Quality of Service)는
"메시지가 얼마나 확실하게 도착해야 하는가"에 대한 약속이다.
이 역시 ROS에서 다뤄봤던 개념이다.
QoS 0 - At most once
한 번 보내고 끝이고, 도착 확인도 안 한다.
센서 데이터를 초당 수십 회 쏘는 경우에 적합하다.
하나 빠져도 바로 다음 게 오니까.
QoS 1 - At least once
최소 한 번 도착을 보장한다.
브로커가 PUBACK을 보내고, 발행자는 이걸 받을 때까지 재전송한다.
대신 중복 수신이 발생할 수 있다.
QoS 2 - Exactly once
정확히 한 번만 도착한다.
4단계 핸드셰이크를 거치기 때문에 가장 무겁다.
QoS를 무조건 높이는 게 능사는 아니다.
실시간성이 중요할 땐 QoS 1로 보내되 수신 측에서 중복 처리하는 게 QoS 2로 느리게 보내는 것보다 나을 수 있다.
Retain, Will, Keep Alive
소개 글에서 자주 빠지는데,
실제로 시스템을 짜보면 없으면 안 되는 기능들이라고 한다.
나도 이 사항들에 대해선 이번에 알게 돼서 업무에 적용해봐도 좋을 것 같다.
Retain 메시지
브로커가 토픽의 마지막 메시지를 보관한다.
새로운 구독자가 붙으면 즉시 받는다.
이게 없으면 새로 연결된 클라이언트는
다음 메시지가 올 때까지 현재 상태를 알 수 없다.
ROS2를 써봤다면 Durability QoS의 transient_local이 떠오를 수도 있다.
새 구독자가 붙었을 때 이전 메시지를 바로 받을 수 있다는 점에서 Retain과 감각이 비슷하다.
LWT(Last Will and Testament)
"나 갑자기 죽으면 이 메시지 대신 보내줘"를
접속할 때 미리 등록해두는 거다.
로봇이 예상치 못하게 꺼지면
브로커가 알아서 유언 메시지를 발행한다.
이게 없으면 "응답이 없는데, 바쁜 건지 죽은 건지 모르겠다"가 계속된다.
(생각보다 이런 상황이 자주 온다.)
Keep Alive
"나 살아있다"를 주기적으로 확인하는 핑이다.
설정한 시간 동안 아무 패킷도 안 오면 연결 끊김으로 판단하고 LWT를 발동시킨다.
너무 짧으면 네트워크 잠깐 흔들릴 때마다 끊김 처리되고,
너무 길면 장애 감지가 늦어진다.
ROS1과의 공통점
ROS를 접해본 사람이라면 뭔가 익숙한 느낌이 들 수 있다.
ROS2도 topic, publish subscribe 등의 개념이 겹칠 순 있지만, 중앙에서 제어하는 개념은 전혀 다르다.
반면 ROS1에는 Master라는 중앙 노드가 있었다.
모든 노드가 Master에 등록하고, Master가 노드 간 연결을 중개하는 구조였다.
이건 분명 MQTT 브로커를 떠올리게 하는 구조다.
| ROS1 | MQTT | |
|---|---|---|
| 중앙 노드 | Master | Broker |
| 통신 방식 | Pub/Sub (토픽) | Pub/Sub (토픽) |
| 노드 등록 | Master에 등록 | Broker에 연결 |
| 중앙 노드 죽으면 | 새 노드 등록 불가 | 메시지 라우팅 불가 |
둘 다 중앙에 무언가가 있고, 토픽 기반 Pub/Sub으로 동작한다.
구조적 사고방식이 같다.
처음엔 이름만 낯설었지,
용어와 방식들이 생각보다 익숙한 이유가 여기에 있었다.
실제 로봇에서는 어떻게 쓰이나
로봇 시스템에서는 한 PC 안에서 여러 프로그램이 동시에 돌아간다.
비전 처리, UI, 로직 판단 같은 것들이 각각 별도 프로그램으로 존재하고,
이 프로그램들이 서로 데이터를 주고받아야 한다.
여기에 MQTT가 들어간다.
비전 프로그램이 좌표를 토픽에 발행하면,
로직 프로그램이 구독해서 판단하고,
UI 프로그램이 같은 토픽을 구독해서 화면에 표시한다.
프로그램이 하나 추가돼도 토픽만 구독하면 된다.
기존 코드를 건드릴 필요가 없다.
이게 Pub/Sub 구조의 진짜 강점인 것 같다.
마무리
사실 업무에서 MQTT 이야기가 처음 나온 건 2025년 10월쯤이었다.
그때 바로 개념까지 같이 정리했으면 좋았겠지만,
현실은 늘 그렇듯 급한 일부터 처리하느라 계속 뒤로 밀렸다.
좀 늦었어도 이번에 정리해봤다.
아무튼 MQTT는 꽤 가볍고,
확장성도 좋고,
여러 프로그램을 느슨하게 연결하기에도 편한 프로토콜이다.
처음엔 이름만 들으니 좀 낯설었고 의심도 해봤는데,
왜 산업 현장이나 로봇 시스템 쪽에서 자주 나오는지 금방 이해된다.
나도 ROS 말고는 잘 모르던 상태에서 시작했는데,
막상 구조를 보고 나니 생각보다 훨씬 익숙한 얼굴이었다.
