MQTT 토픽 설계 모범 사례와 네이밍 규칙
디바이스와 애플리케이션 간 메시지 흐름을 명확히 정의하기 위한 MQTT 토픽 설계 원칙과 네이밍 규칙을 한눈에 볼 수 있는 실무용 참고자료
목차
개요
MQTT는 경량 메시징 프로토콜이다. 토픽은 메시지 라우팅의 핵심 요소이다. 잘 설계된 토픽은 확장성과 보안, 운영 편의성을 모두 개선한다. 이 글은 mqtt topic 설계 가이드 관점에서 실무에 적용 가능한 원칙과 예시를 정리한다. 처음 접하는 독자도 쉽게 이해하도록 단계별로 설명한다.
토픽의 기본 개념
토픽 계층 구조
토픽은 슬래시(/)로 구분되는 계층 구조를 가진다. 이 구조는 리소스를 계층화하고 구독 필터를 단순화한다. 예를 들어 장치 위치, 장치 유형, 데이터 타입 순으로 구성하면 검색과 필터링이 명확해진다.
와일드카드와 필터링
MQTT는 단일 레벨 와일드카드(+)와 다중 레벨 와일드카드(#)를 제공한다. 적절히 사용하면 구독 범위를 유연하게 지정할 수 있다. 하지만 무분별한 사용은 불필요한 트래픽을 유발할 수 있다.
설계 원칙
- 일관성: 동일한 의미의 요소는 동일한 위치에 배치한다.
- 명확성: 각 토픽은 의미를 명확히 드러낸다.
- 유일성: 충돌을 피하기 위해 네임스페이스를 분리한다.
- 확장성: 새로운 장치나 기능이 추가돼도 구조 변경이 최소화되도록 설계한다.
- 보안과 접근 제어: 인증·인가 정책과 연동 가능한 구조를 고려한다.
- 메타데이터 분리: 상태나 로그와 같은 메타데이터는 별도 토픽에 둔다.
일관성 유지 전략
토픽 규칙을 문서화한 뒤 팀 전반에 적용한다. 예컨대 접두사로 환경(environment)을 명시하거나, 장치 ID 규칙을 통일하면 운영 시 혼선을 줄일 수 있다.
네이밍 규칙 제안
다음은 실제로 적용 가능한 표준화 규칙이다. mqtt 토픽 네이밍 규칙을 반영해 실무에서 사용하기 쉬운 형태로 정리했다.
- 계층 순서:
도메인/환경/위치/장치유형/장치ID/데이터타입 - 소문자 사용: 대소문자 혼용으로 인한 혼란을 방지한다.
- 구분자: 공백 대신 하이픈(-)이나 언더스코어(_) 대신 슬래시(/)만 사용한다.
- 버전 관리: 토픽 변경 시 버전 접두사(v1, v2)를 사용한다.
- ID 포맷: 장치 ID는 고정 길이 또는 UUID 형식을 권장한다.
- 상태/명령 분리: 상태는
/state, 명령은/cmd로 구분한다.
구체적 예시
home/prod/livingroom/thermostat/thermo-001/state
home/prod/livingroom/thermostat/thermo-001/cmd
factory/dev/lineA/machine/mach-0001/metrics
위 예시는 위치와 장치 유형이 명확히 구분되어 있다. 구독자는 와일드카드를 통해 유연하게 데이터를 수신할 수 있다.
구독 패턴과 성능 고려
구독 패턴은 네트워크 트래픽과 브로커 부하에 직접적인 영향을 준다. 가능한 구독 범위를 좁히고, 고빈도 메시지는 별도 토픽으로 분리한다. 또한 QoS 수준과 메시지 Retain 설정을 정책화하면 불필요한 재전송을 줄일 수 있다.
QoS와 Retain 정책
- QoS 0: 센서와 같이 짧은 주기의 데이터에 적합하다.
- QoS 1: 적중률이 중요하지만 지연을 어느 정도 허용하는 경우.
- QoS 2: 중복 방지가 필수인 경우에만 사용한다.
- Retain: 최신 상태를 항상 보관해야 하는 토픽에만 사용한다.
보안과 접근 통제
토픽 기반 접근 제어는 보안의 핵심이다. 토픽 네임스페이스를 분리하면 권한 정책을 단순화할 수 있다. 예를 들어 운영자, 모니터링, 제어 권한을 토픽 레벨로 나눠서 적용한다.
버전 관리와 마이그레이션 전략
토픽 구조 변경은 호환성 문제를 유발한다. 버전 접두사나 신규 네임스페이스를 사용하면 기존 구독자에 영향 없이 점진적으로 전환할 수 있다. 또한 변환 브리지 서비스를 두면 메시지 동기화를 쉽게 처리할 수 있다.
체크리스트
- 토픽 계층이 명확한가
- 규칙이 문서화되어 있는가
- 와일드카드 사용이 적절한가
- 보안 정책과 연계되어 있는가
- 버전 전략이 마련되어 있는가
- QoS와 Retain 정책이 정의되어 있는가
결론
좋은 토픽 설계는 운영 비용을 줄이고 시스템 확장성을 높인다. 토픽은 단순한 문자열이 아니라 설계의 일부다. 이 글을 통해 mqtt topic 설계 가이드와 mqtt 토픽 네이밍 규칙, 토픽 설계 best practice를 참고하여 자기 조직에 맞는 규칙을 마련하면 운영과 개발 모두에서 이득을 얻을 수 있다.