메시지가 도착했다고 업무가 끝난 것은 아닙니다
센서 이벤트를 받아 작업 지시를 만드는 시스템에서는 전송 성공과 작업 생성 성공이 서로 다른 사건입니다. 수신 후 데이터베이스 저장 전에 프로세스가 멈출 수 있고, 저장 후 응답 전에 연결이 끊길 수도 있습니다. MQTT의 QoS 설정만으로 데이터베이스·알림·외부 API까지 한 번만 실행된다고 가정하면 재전송 때 중복 업무가 생깁니다.
업무 이벤트에 중복 판단 키를 부여합니다
기기 ID와 이벤트 ID, 발생 시각을 함께 전달하고 서버에는 같은 이벤트를 이미 처리했는지 확인할 기준을 둡니다. 메시지 패킷 식별자를 장기 업무 ID처럼 사용하지 않도록 주의하세요. 선택한 브로커의 지원 QoS와 제한도 확인해야 합니다. 표준에 있는 모든 기능이 제품에서 동일하게 지원되는 것은 아니므로 브로커·SDK 조합을 검수 대상에 넣습니다.
| 구간 | 확인할 결과 |
|---|---|
| 브로커 수신 | 선택한 QoS와 세션 조건에 따른 전달 |
| 서버 저장 | 같은 이벤트 키로 중복 원장 생성 방지 |
| 알림·작업 실행 | 재시도 후에도 결과와 실행 이력을 추적 |
저장 직후 장애를 재현해 봅니다
온도 초과 이벤트를 저장한 직후 소비자를 종료하고 동일 메시지를 다시 전달합니다. 원본 이벤트는 한 건으로 남고, 아직 보내지 못한 알림만 재시도되는지 확인하세요. 알림이 이미 발송됐는지 외부 서비스에서 확인할 수 없다면 무조건 재발송하기보다 불확실 상태를 운영자가 조회하도록 설계할 수 있습니다. 검수에는 정상 연결보다 이런 경계 시점이 더 많은 정보를 줍니다.
검수 후 남겨둘 자료
이벤트 원장 예시에는 eventId, deviceId, 발생 시각, 처리 상태와 외부 작업 ID를 넣습니다. 통신 담당자와 업무 서버 담당자가 같은 식별자로 로그를 대조할 수 있는지 확인하세요. 중복 수신 횟수와 업무 실행 횟수를 따로 집계하면 정상적인 재전송이 불필요한 작업 증가로 이어지는지 운영에서도 확인할 수 있습니다.
프로젝트에서 확인할 항목
- 기기 이벤트 ID가 재전송에도 유지되는가
- 브로커의 실제 지원 범위를 확인했는가
- 저장 후 장애에서 중복 작업이 생기지 않는가
참고 자료
자료 확인일: 2026.10.11 · 본문의 적용 예시와 체크리스트는 참고 자료를 바탕으로 정리한 실무 제안입니다.
기술 동작은 아래 공식 문서를 참고했습니다. 적용 조건과 지원 버전은 프로젝트 환경에 맞게 확인하세요.
작성팀 소개
TOPPING 편집팀 · IoT·헬스케어 개발 콘텐츠
공식 기술 문서를 바탕으로 개발 범위, 데이터 연동과 검수 기준을 정리합니다. 글에 제시된 적용 예시는 프로젝트 검토를 위한 제안이며, 특정 고객사의 구축 실적이나 의료적 판단을 의미하지 않습니다.
