기술 선택 전에 고정해야 할 것: 로봇 관제 실시간 메시징 요구사항
실시간 메시징은 도구 선택보다 요구사항 정의가 먼저다. 요구사항이 모호하면 Kafka든 MQTT든 결국 운영에서 같은 문제를 반복한다.
이 글은 로봇 관제 시스템에서 먼저 고정해야 할 메시징 요구사항을 정리한다.
왜 요구사항부터 정의해야 하나
당시 가장 큰 문제는 “기술 비교"를 먼저 한 것이었다. 먼저 정해야 했던 것은 아래였다.
- 어떤 메시지는 반드시 전달되어야 하는가
- 몇 초 이상 지연되면 무효 처리할 것인가
- 재연결 시 어떤 메시지를 복원할 것인가
필수 요구사항
- 메시지 유형별 전달 보장 수준 정의
- 클라이언트 지연 허용치(SLA) 정의
- 재연결 시 마지막 메시지 처리 정책
- 다중 서버 환경에서 라우팅/세션 정책
- 관측 지표(지연, 유실, 재전송, 재연결률)
요구사항을 수치로 고정하기
요구사항은 문장보다 표가 운영에 유리하다.
| 항목 | 기준 예시 | 비고 |
|---|---|---|
| 제어 명령 반영 지연 | p95 300ms 이하 | 네트워크 품질별 별도 계측 |
| 상태 이벤트 전달 성공률 | 99.9% 이상 | 중복 허용, 유실 최소화 |
| 재연결 후 상태 복원 | 2초 이내 | last known state 전략 필요 |
| 중복 처리 | idempotency 보장 | event_id 필수 |
설계 판단
- 웹 관제는 WebSocket 계열 연결을 기본으로 둔다
- Pub/Sub 계층은 메시지 특성에 맞게 분리한다
- 분산 구조는 초기부터 가정하되 구현은 단계적으로 진행한다
핵심은 복잡한 시스템을 바로 구축하는 것이 아니라
운영 기준을 먼저 고정한 뒤 기술을 선택하는 것이다.
운영 체크리스트
- 메시지 타입별 QoS/TTL/재시도 정책 문서화
- 연결 단절 시 replay 범위와 최대 길이 고정
- 재연결 폭주(thundering herd) 완화 정책 적용
- 장애 시 수집할 필수 로그 필드 표준화
참고 및 인용
참고: RFC 6455는 WebSocket 프레임/연결/오류 처리의 표준을 정의한다. RFC 6455: The WebSocket Protocol
참고: MQTT 표준은 메시지 전달 보장(QoS)과 세션 지속성 요구사항을 구조화할 때 기본 근거가 된다. MQTT Specification
참고: SLO 관점 요구사항 정리는 지연/성공률 목표를 운영 지표와 직접 연결해 준다. Implementing SLOs