대규모에서 MQTT 사용: 보통 문제가 발생하는 곳

Source: Dev.to

“그냥 퍼블리시 해”… 그리고 갑자기 아무것도 서로 통신하지 않는다

(MQTT, UNS, 그리고 왜 패턴이 중요한가)

“그냥 MQTT야 — 진행하면서 알아보면 돼.”
몇 스프린트가 지난 뒤:

• 절반 정도의 토픽이 팀마다 다른 의미를 갖게 된다
• 페이로드가 누군가 눈치채지 못한 채 점점 변한다
• 대시보드 간에 결과가 일치하지 않는다
• 디버깅이 엔지니어링이 아니라 고고학처럼 느껴진다

이 상황이 익숙하다면, 문제는 보통 MQTT 자체가 아니라 그 사용 방식에 있다.

Unified Namespace (UNS)

Unified Namespace (UNS)는 제품이 아니다. 이벤트‑드리븐 데이터 통합을 위한 아키텍처 패턴이다.

시스템을 빽빽하게 결합하거나 생산자 → 소비자 관계를 직접 연결하는 대신, 데이터를 한 번만 공유되고 구조화된 네임스페이스에 퍼블리시한다. 나머지는 모두 구독한다.

소프트웨어 관점에서 보면 보통 다음과 같다:

• 서비스 간 하드 의존성이 감소
• 생산자와 소비자 사이 경계가 명확해짐
• 변경 사항을 이해하기 쉬워짐
• 어떤 데이터가 존재하고 어떻게 흐르는지 가시성이 향상

대부분 MQTT가 전송 계층으로 사용되지만, MQTT만으로는 구조, 의미론, 안전성을 제공하지 않는다. 여기서 패턴이 중요한 이유다.

팀이 이 패턴을 채택하는 이유

잘 구현된 UNS는 팀이 흔히 겪는 고통을 많이 줄여준다:

• “아무것도 건드리지 마” 라는 깨지기 쉬운 통합이 감소
• 데이터 컨텍스트(무엇을 / 어디서 / 언제)가 명확해져 다운스트림 코드가 추측하지 않음
• 새로운 소비자(대시보드, 분석, ML, 알림) 도입이 쉬워짐
• 디버깅이 단순해짐 — 누가 언제 무엇을 퍼블리시했는지 추적 가능
• 데이터 계약과 버전 관리를 자연스럽게 적용할 수 있는 위치 제공

하지만 이 모든 것이 MQTT만 도입한다고 “공짜”로 얻어지는 것은 아니다.

Do’s ✅ (소프트웨어 친화적)

• 토픽 구조를 API 인터페이스처럼 다룰 것
• 명시적인 데이터 계약을 사용할 것
• 첫날부터 관측성을 구축할 것

Don’ts ❌

• 네임스페이스를 데이터 쓰레기통으로 만들지 말 것
• 조용히 깨지는 변경을 배포하지 말 것
• 거버넌스를 건너뛰지 말 것

나는 너무 많은 팀이 “작은” MQTT 변경 때문에 몇 주씩 시간을 낭비하는 모습을 보았다. 이런 변화는 별거 아니었어야 하지만, 패턴이 없었기에 복잡해졌다.

MQTT와 함께하는 UNS에 대한 실용적인 분석, 모범 사례, 일반적인 패턴, 그리고 팀이 흔히 빠지는 지점을 보고 싶다면 전체 기사를 참고하라:

👉