MQTT 25주년

 (andypiper.co.uk)
4P by GN⁺ | ★ favorite | 댓글 1개
  • MQTT는 1999년 10월 최초 명세가 공개된 뒤 25년 동안, 작은 기기와 불안정한 네트워크를 위한 경량 프로토콜에서 산업·가정·앱 전반으로 확산됨
  • 제한된 전력과 간헐적 연결을 전제로 한 단순한 발행/구독 구조가 네트워크와 엣지 기기 환경이 달라진 뒤에도 강점으로 남음
  • IBM 주변에서 쓰이던 MQTT는 2009~2011년 커뮤니티 확산이 본격화됐고, Mosquitto와 Eclipse Paho를 거치며 IBM 바깥의 오픈 프로토콜 생태계로 넓어짐
  • 현재는 Node-RED 기반 Raspberry Pi 메시지 처리, Dyson 공기청정기와 앱, 3D 프린터 제어, 홈 알림, 제조 현장 등 사용자가 의식하지 못하는 곳에도 들어가 있음
  • 25주년을 맞아 커뮤니티는 X의 오래된 프로젝트 계정 대신 Mastodon의 @mqtt@fosstodon.org로 이동했고, ActivityPub 기반 Fediverse에도 첫 메시지를 게시함

제한된 환경에서 출발한 경량 메시징

  • 2024년 10월은 MQTT가 최초 명세로 이어질 문서가 공개된 지 25주년이 되는 시점임
  • MQTT는 1990년대 후반의 작고 제한된 기기, 가볍거나 불안정한 네트워크를 전제로 설계된 네트워크 프로토콜임
  • 멀리 떨어진 환경 모니터링 장치처럼 연결이 간헐적이고 전력도 제한된 상황에서 센서 데이터를 더 큰 시스템으로 보내는 데 초점이 맞춰짐
    • 이런 장치는 전력, 대역폭, 네트워크 가용성을 아껴 써야 함
    • MQTT는 데이터를 작지만 유용한 형식으로 발행하고 수집·수신하는 방식에 잘 맞음
  • 네트워크가 더 빠르고 안정적으로 바뀌고 엣지·홈 자동화·휴대용 기기가 늘어난 뒤에도, 프로토콜의 단순성은 MQTT의 핵심 강점으로 남아 있음

IBM 주변에서 오픈 생태계로 확산

  • 2001년 IBM에 합류한 뒤 IBM MQ, 비즈니스 통합, 메시지 큐잉, 애플리케이션 연결, 미들웨어 관련 고객 프로젝트를 수행함
  • IBM Hursley Lab은 MQ의 기반이자 MQTT 공동 창작자인 Andy Stanford-Clark의 활동 기반이었고, 그 주변에서 MQTT 실험이 시작됨
  • 당시 MQTT는 외부에 프로토콜로 공개되어 있었지만 IBM 바깥에서는 잘 알려지거나 널리 구현되지 않았음
  • 2009~2011년 무렵 MQTT를 IBM의 작은 구현 범위 밖으로 알리는 활동이 진전됨
    • 당시 브로커 선택지는 기업용이며 고가인 IBM WebSphere Message Broker, 닫힌 소스의 microbroker, 닫힌 소스지만 무료로 제공되던 Really Small Message Broker 등이었음
    • Roger Light가 만든 오픈소스 Mosquitto는 지금도 널리 쓰이는 무료 구현 중 하나임
    • Roger Light는 2009년 첫 OggCamp에서 Andy Stanford-Clark의 연결된 스마트홈 발표를 들은 뒤 Mosquitto를 만들었고, 이는 명세 생성일로부터 10년 뒤였음

Eclipse Paho와 공식 표준화

  • 2011년 IBM의 MQTT 구현이 Eclipse 커뮤니티에 기부되면서 Eclipse Paho 프로젝트가 시작됨
  • 2012년 IBM을 떠난 뒤에도 Paho 프로젝트와의 연결은 이어졌고, Cloud Foundry 재직 시기에도 역할을 맡음
  • 2014년 Twitter에 합류한 뒤에는 공식적인 관여에서 물러남
  • 그 시기에 MQTT는 OASIS와 ISO/IEC에서 공식 표준화 과정을 거침

오늘날 보이지 않는 곳의 MQTT

  • MQTT는 IBM의 경계를 넘어 오픈 프로토콜 성공 사례가 되었고, 25년 뒤에는 사용자가 인식하지 못하는 여러 제품과 장소에 들어가 있음
  • 대표적인 사용처는 다음과 같음
    • 취미 개발자와 메이커의 프로젝트
    • Dyson 공기청정기와 관련 앱
    • 3D 프린터 제어 시스템
    • 홈 알림 시스템
    • 산업과 제조 현장
  • 개인 작업 공간에서도 MQTT가 여러 방식으로 쓰이고 있음
    • Bambu Lab X1C 3D 프린터가 내부 통신에 MQTT를 사용함
    • 벽에 있는 연결 기기들이 MQTT 알림에 반응해 데이터를 표시하거나 불을 켬
    • Raspberry Pi에서 실행 중인 Node-RED가 MQTT 메시지를 처리함
  • 현재 휴대폰에 있는 앱 중 하나 이상도 스택 어딘가에서 MQTT를 사용할 가능성이 큼

25주년과 커뮤니티 이동

  • MQTT 커뮤니티 계정은 기존 X 프로젝트 계정 대신 Mastodon으로 이동함
  • 새 계정은 @mqtt@fosstodon.org에서 팔로우할 수 있음
  • 25주년을 기념해 MQTT는 ActivityPub을 통해 Fediverse에 첫 메시지를 게시하며 open social web에 합류함
  • Andy Stanford-Clark는 HiveMQ와 fireside chat을 진행했고, HiveMQ의 팟캐스트 The Unstructured Message도 MQTT 관련 내용을 더 볼 수 있는 곳으로 소개됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 아직도 운영 중이고 매일 쓰이는 첫 프로젝트는 대형 스키 리조트의 제설·소방용 배관/펌프/밸브 수계 SVG 지도를 가져와 상태 표시 웹사이트로 만든 것이었음
    각 펌프, 밸브, 배관 구간마다 MQTT 토픽을 만들고 물 흐름 방향, 펌프/밸브 온오프, 압력 같은 상태를 붙였으며, mqtt.js와 jQuery로 SVG 색과 채움을 갱신했음
    정적 호스팅에 컨테이너로 띄운 MQTT 브로커가 거의 10년째 손대지 않고 돌고 있고, mqtt.js는 웹소켓 위에서 동작해 상태가 바뀌면 모두에게 자동으로 반영됨

    • Docker가 벌써 11년 된 기술이라는 게 놀라움

  • 최근 프로젝트에서 MQTT를 써봤지만 크게 마음에 들지는 않았음
    프로토콜에 옵션이 많고, 각 옵션이 무엇을 하는지·왜 중요한지·어떤 조합으로 써야 의도대로 동작하는지 바로 알기 어려웠으며 문서도 그 설명을 잘 못해줌
    일부는 사용한 Eclipse Mosquitto Python 클라이언트 탓일 수도 있는데, 느린 시스템에서 경쟁 상태가 생겨 토픽 구독이 조용히 무시되고 콜백이 망가지는 걸 알아내는 데 며칠 걸렸음
    문서를 100% 따랐는데도 그랬고, 오래되지 않은 프로토콜 치고는 가장 지저분한 경험 중 하나였음

    • 여기서는 클라이언트가 그냥 별로였던 것 같음
      Eclipse 클라이언트들, 예를 들어 Paho를 Python과 C++에서 써본 경험도 비슷했고, 지나치게 복잡하며 너무 저수준처럼 느껴졌고 구조 때문에 버그도 좀 있었음
      아마도 거의 한 사람이 유지보수하는 수준이라 시간이 지나며 이렇게 된 듯함. C++ 클라이언트도 최근 6개월간 기여자가 한 명뿐이었고 최근 3개월은 아무도 기여하지 않았음
      명백한 버그를 고치는 단순한 PR, 단어 하나 바꾸는 수준도 리뷰와 병합까지 2년 걸렸음. 비난이라기보다 라이브러리와 버그와 일이 많고, 과로한 소수의 사람이 처리하는 상태처럼 보인다는 뜻임
      다른 클라이언트로 옮기니 Python, Rust, C#, C++에서 경험이 훨씬 좋아졌고, 대부분은 고수준·저수준 API 조합이 좋아서 토픽에 메시지만 보내고 싶다면 확인 응답이나 재시도 같은 걸 신경 쓰지 않아도 됨
      반대로 제어가 필요하면 제어할 수도 있음. 지금 상태로 paho 등을 살려두는 게 오히려 해가 되는 건 아닌지 걱정됨. 공식적으로 죽었다면 최소한 문제가 강제로 드러났을 텐데, 지금은 사용자가 이런 경험을 하고 MQTT를 포기하거나 자신이 잘못하고 있다고 생각하게 됨
    • paho Python MQTT 라이브러리로 MQTT를 써왔고 꽤 많은 걸 만들긴 했지만, 전반적으로 끔찍한 경험이었음
      API 설계, 빈약한 문서, Python 관례를 따르지 않는 듯한 방식까지 모두 거슬렸음
      처음 시작은 쉬워 보이지만 프로토콜과 구현의 폭이 점점 발목을 잡음. 한때 서버에 성공적으로 연결됐는지 확인하는 신뢰 가능한 방법이, 같은 토픽을 두 번 구독해 보고 on_connect 메시지의 특정 오류 코드를 잡는 것이었음. 당시 그 코드는 문서상 성공 코드로 되어 있었음
      말도 안 되게 들린다는 건 알지만, 더 나은 방법이 있었더라도 쉽게 찾을 수 있지는 않았음. 그래도 불평은 쉽고, 이 라이브러리를 만든 많은 사람들에게 감사함. 그들이 없었다면 지금 만든 것도 만들 수 없었고, 이런 거대한 프로젝트를 맡는 사람들을 존경함
    • Python, C, C++에서 Paho API를 써봤지만 결국 모두 쓰지 않게 됨
      가능하면 mosquitto_sub와 mosquitto_pub로 프로토콜을 처리하고 표준 입출력만 읽고 쓰는 쪽을 택함
      버그 때문만은 아니고, 브로커 연결 관리를 이미 작성되고 테스트된 프로그램에 맡기는 편이 더 쉬웠음
      다만 유언 메시지에서는 이 방식을 효과적으로 쓰지 못했고, Linux 같은 걸 돌리지 않는 마이크로컨트롤러에도 맞지 않음
    • MQTT와 직접 경쟁하는 건 아니지만 https://pipe.pico.sh는 SSH로 통신하는 훌륭한 발행/구독 도구임
      사실상 인증된 네트워크 *nix 파이프 시스템을 만들며, 이벤트를 보내고 받는 가장 단순한 방법을 목표로 함
    • 어디선가 “그냥 TCP 쓰면 안 되나”를 봤고, 내 IoT 프로젝트에는 평범한 TCP로 충분했음
      내 사용 사례에는 무한 대기열이 중요했는데 MQTT는 그걸 제공하지 않았고, MQTT가 자체 메시지 ID를 추적해 브로커로 보내도록 내가 또 메시지 ID를 관리해야 한다면 굳이 쓸 이유가 없었음
      이미 MQTT에 맞춰진 프로젝트와 연동하는 게 아니라면 최적의 사용처가 뭔지 잘 모르겠음

  • 최근 몇 년 사이 MQTT는 공장 내부에서 기계 간 데이터를 공유하는 데 훨씬 많이 쓰이고 있음
    역사적으로는 Oil & Gas 분야에서 원격 유정 사이트 데이터를 가져오는 SCADA 용도로 쓰였음
    10년 넘게 전에 Kepware(OPC 서버)에 MQTT를 추가해 태그 값을 “클라우드”로 스트리밍했는데, 발표 후 MQTT 창시자 중 한 명인 Arlen Nipper가 와서 “괜찮게 했다”고 해줘 겸손해졌음
    지금은 HighByte라는 새 회사에서 엣지에서 공장 데이터를 모델링하고 MQTT, SparkplugB(MQTT 위 프로토콜), S3, Azure Blob 등으로 보내고 있음
    요컨대 MQTT는 Industry 4.0의 큰 동력이고, 오랜 시간이 지난 지금도 이렇게 많이 쓰이는 게 멋짐

    • 현재 Kepware IoT 플러그인으로 초당 약 80만 태그를 MQTT로 스트리밍해 최종적으로 VictoriaMetrics DB에 넣고 있음
      조금 투박하고 원하는 것보다 처리 단계가 많음. Kepware가 IoT 플러그인에 매년 반복 라이선스 비용을 부과해서, 지금은 그 솔루션에서 벗어나 telegraf가 Kepware에서 OPC-UA 데이터를 직접 읽게 하는 쪽으로 옮기는 중임
      Kepware에서 일했거나 일하고 있는지 궁금함
    • 같은 업계에서 일하고 있는데 OPC Foundation 표준의 기술적 열세, 범위 확장, NIH 증후군이 꽤 당혹스러움
      그냥 Sparkplug B를 쓰고 그 위에 의미론용 명세를 구현했으면 좋겠음
      게다가 지금 하는 비동기 관련 작업도 너무 과설계되어 있고 형편없음. 한동안 회의에 참여했는데, MQTT 명세가 50쪽도 안 되고 읽기 쉬운데도 읽어본 적이 없고 헤더가 무엇을 위한 것인지도 이해하지 못한 상태였음. 예를 들어 실제로는 페이로드에 들어가야 할 것을 헤더에 넣으려 했음
      Microsoft 쪽 한 사람은 MQTT로 경쟁자들이 뭘 하는지 먼저 보자는 제안에도 기분 나빠했음. 복사보다 새로 만들고 싶어 했기 때문임
      내 제안으로 우리 회사는 OPC UA를 맨 엣지에서만 다루고, 우리 기술과는 최대한 격리할 예정임
    • 나도 MQTT를 처음 본 곳이 화학 생산 쪽이었고, 항공과 철도 제어 시스템에서도 많이 봤음
      다만 요즘은 Kafka와 RabbitMQ가 MQTT의 시장 영역으로 더 많이 밀고 들어오는 것도 보임
    • 예전에는 Modbus를 썼을 곳에서 MQTT가 쓰이고 있는 건지 궁금함

  • 약 15년 전, 트윗하는 IoT 기기가 흔하지 않던 시절에 Andy Stanford Clark의 집이 뉴스거리가 된 적이 있었음
    https://www.bbc.co.uk/blogs/technology/2009/06/things_that_t...
    핵심 프로토콜은 위성 링크에서 1바이트 전송에 1달러가 들던 시절에 고안돼서, 믿기 어려울 정도로 효율적이고 구현도 단순함

  • 예전에 한 클라이언트의 방화벽에서 쓸 수 있는 유일한 포트가 MQTT 1883뿐이었던 적이 있음
    센서 데이터를 그렇게 받고 있었기 때문인데, 아무리 요청해도 다른 포트를 열어주지 않아 MQTT 위에 실시간 TCP 래퍼를 만들어 우회했음
    로컬 멀티스레드 TCP 데몬이 특정 포트에서 나가는 요청을 듣고 MQTT로 감싼 뒤 고유 토픽으로 발행했으며, 서버 데몬은 그 토픽을 감지해 풀어낸 뒤 서버 프로세스로 전달했음
    클라이언트 머신 입장에서는 우리 서버에 실시간 TCP 연결을 맺는 것처럼 보였지만, 중간에는 보이지 않는 이상한 MQTT 래퍼가 있었음
    동작하고 나서는 우아했지만 디버깅은 정말 고통스러웠고, 여러 막다른 길을 거쳐 전체를 제대로 맞추기까지 몇 달 걸렸음

    • 이런 식으로 방화벽 규칙을 우회하면 해고될 수 있는 곳에서도 일해봤음
      이제는 아무 일도 못 하고 손만 만지작거려야 하는 상황을 “프로세스가 작동하게 두기”라고 부름
    • 사실상 MQTT-Sockets 프로토콜을 구현한 셈이고, 그걸로 반대편 WebSockets 서버에도 연결할 수 있었겠음

  • 재미있는 사실로, 가장 유명한 C++ 라이브러리인 Boost가 같은 시점에 async-mqtt5 구현(https://github.com/mireo/async-mqtt5)을 Boost.MQTT로 포함할지 리뷰 중임: https://lists.boost.org/Archives/boost/2024/10/index.php

    • 요즘 새 프로젝트에서도 사람들이 여전히 Boost를 고르는지 궁금함
      일화적으로는 2000년대와 아주 이른 2010년대, 즉 모두가 C++0x/C++11을 강제하기 전 도입이 대부분이었고, 요즘은 드물게만 봄
      boost.org는 과거 여행 같음. 2008년쯤 기억하던 모습 그대로고, 비상 정지 버튼에 합성된 “Get Boost”까지 그대로임

  • MQTT는 정말 괜찮은 작은 프로토콜이고, 취미 프로젝트에 쓸 만큼 “충분히 작을” 뿐 아니라 Facebook Messenger 같은 것에도 쓰일 만큼 확장됨
    [1]: https://engineering.fb.com/2011/08/12/android/building-faceb...

  • MQTT가 가볍고 효율적이라는 식의 홍보는 잘 납득이 안 됨
    결국 TCP/IP를 쓰는 것뿐이고, 당시 기준으로는 상대적으로 특별했을 수 있지만 그런 주장을 뒷받침하는 실제 증거는 계속되는 자랑 말고는 본 적이 없음
    표준이라서 지원되는 기성 장치에 연결할 수 있다는 점은 좋음. 그래도 발행/구독이나 메시지 대기열에는 더 나은 선택지가 있다고 보고, 특히 소비자 쪽 장애 조치가 필요하면 더 그렇다고 생각함

    • 더 나은 선택지가 무엇인지 궁금함
      MQTT의 좋은 점이자 내가 본 거의 모든 다른 발행/구독 구현이 잘못하는 점은, MQTT의 핵심 자료구조가 대기열과 토픽이 아니라 구독 클라이언트라는 점임
      그래서 원하는 만큼 큰 주소 공간을 토픽 트리에 매핑할 수 있음. 토픽 트리가 수조 개 엔드포인트를 가져도 되고, 원한다면 임베디드 서버에서도 모든 IPv6 주소마다 엔드포인트 하나를 둘 수 있음
      토픽 트리가 풍부하니 구독을 필요한 만큼 선택적으로 만들 수 있고, 서버는 작은 자원 사용량으로도 빠르게 동작할 수 있음
    • 진심으로, 발행/구독과 메시지 대기열에서 더 나은 대안이 무엇인지 궁금함

  • 몇 년 동안 IoT 수업에서 MQTT를 써왔고, 매우 다재다능한 도구임이 입증됐음
    웹소켓으로도 지원된다는 점도 편리함

  • 최근 임베디드 시스템 프로젝트에서 MQTT를 프로세스 간 메시징 시스템으로 써서 꽤 재미있었음
    브로커와 클라이언트가 같은 머신에서 돌았음
    뭔가를 스니핑하거나 디버깅해야 하면 장치를 네트워크에 붙이고 MQTT Explorer로 메시지를 기록하거나 주입하면 돼서 쉬웠음
    LAN 밖으로 포트를 열어 원격 근무 중인 동료가 시스템을 다루게 할 수도 있었음

    • 이런 식으로 많이 쓰는 건 못 봤지만 바람직한 특성이 있어 보임
      시스템 구성요소로 쓸 때 가장 걱정되는 건 내구성 보장이고, 브로커 구현이 데이터를 잃지 않을 거라는 신뢰가 크지 않음
    • 우리는 이 용도로 ZeroMQ를 씀. 브로커가 필요 없음
    • 여기서는 ZeroMQ가 대안이 될 수 있지 않을까?
답변달기