MQTT 프로토콜 사용 시 QoS 레벨(0, 1, 2)의 구현 방식은?

MQTT 프로토콜 사용 시 QoS 레벨(0, 1, 2)의 구현 방식은?

IoT(Internet of Things)와 M2M(Machine to Machine) 통신 환경에서 가장 널리 사용되는 프로토콜인 MQTT(Message Queuing Telemetry Transport)는 지연 시간이 길거나 네트워크 대역폭이 제한적인 환경에서도 안정적으로 데이터를 전달하도록 설계되었습니다.

MQTT의 신뢰성을 결정짓는 가장 핵심적인 메커니즘은 바로 QoS(Quality of Service)입니다. 서비스 품질을 의미하는 QoS는 메시지 송신자와 수신자 간의 데이터 전달 보장 수준을 정의합니다. 본 가이드에서는 QoS의 세 가지 레벨(0, 1, 2)이 내부적으로 어떻게 구현되고, 어떤 제어 프레임을 사용하여 정합성을 맞추는지 상세히 분석합니다.

---

1. QoS Level 0: At most once (최대 한 번 전송)

QoS 0은 소위 '보내고 잊기(Fire and Forget)' 방식입니다. 메시지 전달에 대한 보장이 가장 낮지만, 그만큼 오버헤드가 적어 네트워크 부하가 거의 없습니다.

• 구현 방식: 송신자(Client/Broker)는 메시지를 한 번만 전송하고, 수신자가 제대로 받았는지 확인하는 절차를 거치지 않습니다.
• 제어 프레임: 오직 PUBLISH 프레임 하나만 발생합니다.
• 특징: 수신 측에서 메시지를 못 받았을 경우 재전송이 이루어지지 않으며, 메시지 유실 가능성이 존재합니다.
• 적합한 케이스: 온습도 센서 데이터처럼 데이터의 정밀도보다 실시간성이 중요하고, 한두 번의 누락이 전체 시스템에 큰 영향을 주지 않는 경우에 사용됩니다.

---

2. QoS Level 1: At least once (최소 한 번 전송)

QoS 1은 메시지가 수신자에게 적어도 한 번 이상 전달됨을 보장합니다. 전달 여부를 확인하는 응답 과정이 추가됩니다.

• 구현 방식: 1. 송신자는 메시지를 담은 PUBLISH 프레임을 보냅니다. 이때 메시지 식별자(Packet ID)를 포함합니다.

2. 수신자는 메시지를 정상적으로 받으면 해당 Packet ID를 포함한 PUBACK 프레임을 송신자에게 보냅니다.
3. 송신자는 PUBACK을 받을 때까지 해당 메시지를 저장해 두며, 일정 시간 내에 응답이 오지 않으면 동일한 메시지를 다시 전송합니다.

• 제어 프레임: PUBLISH $\rightarrow$ PUBACK
• 특징: 메시지 유실은 없지만, 네트워크 상태에 따라 중복(Duplicate) 메시지가 발생할 수 있습니다. 수신 측에서는 동일한 Packet ID의 메시지가 중복 수신될 경우에 대한 처리(Idempotency)가 필요할 수 있습니다.
• 적합한 케이스: 전등 스위치 제어나 상태 알림처럼 유실은 절대 안 되지만, 중복 수신 시 로직으로 제어가 가능한 경우에 사용됩니다.

---

3. QoS Level 2: Exactly once (정확히 한 번 전송)

QoS 2는 MQTT에서 가장 높은 신뢰 수준을 제공합니다. 메시지가 정확히 한 번만 전달되도록 보장하며, 이를 위해 4단계의 핸드셰이크(4-way Handshake) 과정을 거칩니다.

• 구현 방식:

1. PUBLISH: 송신자가 Packet ID와 함께 메시지를 보냅니다.
2. PUBREC (Publish Received): 수신자는 메시지를 안전하게 저장하고, 송신자에게 수신 완료를 알리는 PUBREC을 보냅니다. 이때 수신자는 해당 Packet ID를 보관하여 중복 처리를 방지합니다.
3. PUBREL (Publish Release): 송신자는 PUBREC을 받으면 메시지 발송을 중지하고, 수신자에게 "이제 보관하고 있는 메시지를 처리해도 좋다"는 의미의 PUBREL을 보냅니다.
4. PUBCOMP (Publish Complete): 수신자는 메시지를 최종 처리(배포)한 뒤 송신자에게 모든 과정이 끝났음을 알리는 PUBCOMP를 보냅니다. 송신자는 이 신호를 받고 나서야 Packet ID를 폐기합니다.

• 제어 프레임: PUBLISH $\rightarrow$ PUBREC $\rightarrow$ PUBREL $\rightarrow$ PUBCOMP
• 특징: 메시지의 유실과 중복을 모두 방지합니다. 하지만 다른 레벨에 비해 네트워크 왕복 횟수가 많아지고 브로커와 클라이언트의 리소스 소모가 큽니다.
• 적합한 케이스: 금융 결제, 의료 데이터 전송 등 메시지의 중복 발생이 심각한 오류를 초래할 수 있는 중요 트랜잭션 환경에 필수적입니다.

---

4. QoS 선택 시 아키텍처 고려사항

단순히 높은 QoS가 좋은 것은 아닙니다. 시스템의 목적에 맞는 전략적 선택이 필요합니다.

1. 네트워크 비용: QoS 2는 QoS 0에 비해 최소 4배 이상의 제어 프레임이 발생합니다. 수천, 수만 개의 장치가 연결된 환경에서는 대역폭 비용과 브로커의 세션 유지 부하를 고려해야 합니다.
2. 클라이언트 성능: 저전력 임베디드 장비의 경우 QoS 2의 4단계 핸드셰이크를 유지하는 것이 부담스러울 수 있습니다.
3. 데이터의 휘발성: 분 단위로 계속 들어오는 스트리밍 성격의 데이터라면 QoS 0이나 1로도 충분합니다. 반면 시스템의 설정 변경이나 치명적인 경고 알림은 반드시 QoS 1 이상을 사용해야 합니다.

---

5. 요약: QoS 레벨별 구현 비교

항목	QoS 0	QoS 1	QoS 2
의미	최대 한 번 (유실 가능)	최소 한 번 (중복 가능)	정확히 한 번 (정합성 보장)
핸드셰이크	없음 (1단계)	2단계 (PUBACK)	4단계 (PUBREC, PUBREL, PUBCOMP)
메시지 저장	불필요	ACK 수신 전까지 저장	전체 단계 완료 전까지 저장
성능 오버헤드	매우 낮음	보통	높음

MQTT 프로토콜을 활용한 설계 시, 각 토픽의 비즈니스 중요도에 따라 QoS 레벨을 세분화하여 적용하는 것이 시스템의 효율성과 신뢰성을 동시에 확보하는 길입니다.