ROS 2 QoS는 Reliable과 Best Effort 중 하나만 고르는 옵션이 아닙니다. 신선도, 손실 허용, 재시작 후 전달, 큐 깊이와 마감시간을 토픽의 의미에 맞추고 발행자·구독자의 호환성을 확인해야 합니다.
아래에서는 용어의 차이를 실제 시스템 경계, 실패 조건과 검증 순서로 나눠 살펴봅니다.
센서와 명령의 QoS는 데이터가 늦거나 사라졌을 때의 피해로 고른다
고주기 카메라나 라이다는 몇 프레임을 잃더라도 최신 샘플을 빨리 받는 편이 나을 수 있습니다. 반면 모드 전환, 작업 승인, 맵 배포와 같은 이산 이벤트는 한 메시지 손실이 상태 불일치로 이어질 수 있어 전달 확인과 별도 응답 설계가 중요합니다.
QoS는 ROS 2 실시간 제어와도 경계가 다릅니다. QoS는 DDS 통신의 전달·보관·수명 정책을 조정하지만 관절 제어 루프의 마감시간, 메모리 할당과 스케줄링을 자동으로 보장하지 않습니다.
QoS 프로필은 여러 정책의 묶음이다
ROS 2 공식 QoS 문서는 History, Depth, Reliability, Durability, Deadline, Lifespan, Liveliness 등을 하나의 프로필로 설명합니다. Reliable 하나만 맞춰도 History나 Durability가 다르면 기대한 보관과 재연결 동작이 나오지 않을 수 있습니다.
설정표에는 정책 이름뿐 아니라 토픽의 발행 주기, 메시지 크기, 최대 허용 나이, 구독자의 최악 처리시간을 함께 적는 편이 좋습니다. 그래야 큐 깊이와 재전송이 지연과 메모리에 미치는 영향을 계산할 수 있습니다.
연결은 발행자의 offered와 구독자의 requested가 호환돼야 생긴다
ROS 2의 QoS 호환성은 발행자가 제공하는 수준과 구독자가 요구하는 수준의 관계로 판단합니다. 대표적으로 Best Effort 발행자에 Reliable 구독자를 붙이면 구독자의 요구를 충족할 수 없어 메시지가 전달되지 않지만, Reliable 발행자와 Best Effort 구독자는 연결될 수 있습니다.
노드는 보이고 토픽 이름과 타입도 맞는데 데이터가 전혀 오지 않는다면 방화벽보다 QoS 호환성을 먼저 확인할 가치가 있습니다. 배포 전에 각 토픽의 발행·구독 프로필을 표로 만들고 여러 구현체와 도구가 추가될 때도 같은 검사를 자동화해야 합니다.
Reliable은 재전송을 허용하지만 최신성을 보장하지 않는다
Reliable은 전달되지 않은 샘플을 다시 보내는 메커니즘을 사용하므로 손실을 줄이는 데 도움이 됩니다. 그러나 수신자가 느리거나 무선망 손실이 크면 재전송과 대기로 오래된 샘플이 쌓여 제어·인식 파이프라인의 현재 시각과 멀어질 수 있습니다.
ROS 2 DDS 튜닝 문서도 손실이 있는 연결에서 신뢰성 향상의 이득과 비용을 개별 사례별로 비교하도록 안내합니다. Reliable을 ‘안전’, Best Effort를 ‘불안전’으로 번역하지 말고 지연 분포와 데이터 의미로 판단해야 합니다.
연속 센서에는 최신 샘플과 작은 큐가 우선일 때가 많다
카메라, 라이다, 고주기 IMU처럼 다음 샘플이 곧 도착하는 스트림은 한 프레임을 재전송해 늦게 받는 것보다 일부 손실을 허용하고 최신 샘플을 유지하는 편이 유리할 수 있습니다. ROS 2의 Sensor Data 프로필이 Best Effort와 작은 큐를 사용하는 이유도 이 신선도 우선 특성입니다.
하지만 모든 센서가 Best Effort여야 하는 것은 아닙니다. 낮은 주기의 진단 이벤트, 측정 횟수가 제한된 검사 데이터와 재현이 필요한 원시 로그는 손실 비용이 더 클 수 있으므로 별도 토픽과 프로필로 분리합니다.
| 데이터 예 | 우선 질문 | 시작 프로필 |
|---|---|---|
| 카메라·라이다 스트림 | 오래된 프레임보다 최신 프레임인가 | Best Effort, Keep Last, 작은 Depth |
| 로봇 상태 스트림 | 현재값과 변화 이력 중 무엇이 필요한가 | 주기·소비자별 분리 |
| 모드 전환 이벤트 | 한 번의 손실이 상태 불일치인가 | Reliable + 명시적 확인 |
| 정적 설정·맵 | 늦게 켠 노드도 받아야 하는가 | Reliable, 필요 시 Transient Local |
로봇 명령은 Reliable만으로 완결되지 않는다
명령 토픽을 Reliable로 만들면 전송 손실 가능성은 줄지만 명령의 중복 실행, 오래된 명령, 수신 후 실행 실패까지 해결하지는 못합니다. 위험한 동작에는 명령 ID, 유효시간, 현재 상태 조건, 수락·완료·거부 응답과 중복 처리 규칙이 필요합니다.
짧은 연속 속도 명령은 오래된 값이 뒤늦게 도착하지 않도록 Lifespan과 watchdog을 고려하고, 이산 작업 요청은 service나 action처럼 응답과 취소·진행 상태를 표현하는 인터페이스가 더 적합할 수 있습니다. 통신 QoS와 작업 상태 머신의 책임을 분리해야 합니다.
History와 Depth는 손실보다 큐 지연을 만들 수 있다
Keep Last의 Depth는 구독자가 잠시 느려졌을 때 보관할 샘플 수입니다. 깊이가 너무 작으면 순간 부하에서 샘플이 덮어써지고, 너무 크면 수신자가 회복한 뒤 오래된 데이터를 순서대로 처리하느라 현재 상태를 늦게 볼 수 있습니다.
Depth는 임의의 10이 아니라 발행 주기와 허용 정체시간에서 시작해야 합니다. 예를 들어 100 Hz 스트림에서 50 ms 이상 지난 데이터가 무의미하다면 큐와 처리 정책도 그 시간 경계를 넘기지 않도록 측정해야 합니다.
Durability는 늦게 들어온 구독자에게 과거 샘플을 줄지 정한다
Volatile은 새로 연결된 구독자가 연결 이후의 메시지만 받는 방식이고, Transient Local은 발행자가 일정 이력을 보관해 늦은 구독자에게 제공할 수 있게 합니다. 정적 맵, 좌표 설정이나 현재 구성처럼 재시작 후 즉시 필요한 값에는 유용할 수 있습니다.
반대로 서비스 요청이나 일회성 동작 명령을 남겨 두면 재시작한 서버가 오래된 요청을 받는 위험이 생길 수 있습니다. 보관이 필요한 것은 ‘명령’이 아니라 검증된 ‘현재 상태’인지 먼저 구분하고, 발행자와 구독자 양쪽의 Durability 호환을 확인해야 합니다.
Deadline·Lifespan·Liveliness는 시간 이상을 드러낸다
Deadline은 기대한 주기 안에 샘플이 오지 않았음을 알리는 기준이고, Lifespan은 너무 오래된 샘플을 전달 대상에서 제외하는 기준입니다. Liveliness는 발행자가 살아 있다고 간주할 조건과 임대 시간을 표현합니다.
이 정책들은 로봇을 직접 안전 정지시키는 기능이 아니라 이상을 감지하고 상위 상태 머신이 대응할 단서를 제공합니다. 이벤트 콜백이 지연되거나 사라질 수 있는 고장까지 고려하고, 안전 관련 정지는 독립적인 안전 경로에서 다뤄야 합니다.
rosbag2와 CLI 도구도 토픽 QoS에 맞춰야 한다
rosbag2 QoS 오버라이드 공식 가이드는 토픽별로 Reliability, Durability, History와 Depth 등을 덮어쓰는 YAML 방법을 설명합니다. 기록기가 발행자와 호환되지 않으면 화면에서는 보이는 토픽이 가방 파일에 빠질 수 있습니다.
재생 때도 원래 발행자와 다른 프로필이 적용되면 실제 시스템과 연결되지 않거나 재시작 전달 특성이 달라질 수 있습니다. 현장 로그 도구, 시각화 도구와 브리지까지 생산 노드의 QoS 매트릭스에 포함해 시험해야 합니다.
QoS 검증은 손실망과 느린 구독자를 의도적으로 만든다
정상 유선망에서 한 번 통신하는 시험만으로는 큐 정체와 재전송 문제가 드러나지 않습니다. 패킷 손실, 대역폭 제한, 큰 메시지, 느린 구독자, 구독자 재시작과 발행자 재시작을 각각 주입해 전달률과 샘플 나이, 큐 사용량을 기록합니다.
합격 기준은 ‘메시지가 왔다’보다 구체적이어야 합니다. 센서 스트림은 최신 샘플 나이와 드롭 허용률, 이벤트는 누락·중복 여부, 명령은 수락부터 완료까지의 상태 일관성과 만료된 명령 거부를 확인합니다.
| 시험 | 주입 조건 | 관찰값 |
|---|---|---|
| 호환성 | 정책 조합 변경 | 연결 성립·QoS 이벤트 |
| 손실망 | 손실·지연·대역폭 제한 | 전달률·재전송·샘플 나이 |
| 느린 구독자 | 처리 지연·일시 중단 | 큐 깊이·오래된 데이터 |
| 재시작 | 발행자·구독자 순차 재기동 | 과거 샘플·상태 복구 |
토픽 계약서와 런타임 관측을 함께 운영한다
QoS 표에는 토픽 이름·타입뿐 아니라 의미, 발행 주기, 최대 나이, 손실·중복 허용, 프로필과 소유 팀을 적습니다. ROS 2·DDS 보안과 센서 퓨전의 시간 정합성도 같은 인터페이스 계약에 연결하면 전달 문제와 의미 문제를 구분하기 쉽습니다.
배포 후에는 `ros2 topic info –verbose` 같은 도구로 실제 엔드포인트의 QoS를 확인하고, 샘플 타임스탬프와 수신 시각의 차이를 지표로 남깁니다. 코드 기본값에만 의존하지 말고 변경 시 호환성 시험을 자동화해야 새 노드 하나가 전체 토픽을 침묵시키는 일을 줄일 수 있습니다.
ROS 2 QoS 설정에서 자주 묻는 질문
센서 토픽은 항상 Best Effort가 맞나요?
아닙니다. 최신 연속 샘플이 중요한 경우 좋은 출발점이지만, 저주기 이벤트나 재현이 필요한 측정은 손실 비용을 따로 평가해야 합니다.
Reliable이면 메시지가 절대 사라지지 않나요?
프로세스 종료, 자원 한계, 만료, 호환성 오류와 애플리케이션 실패는 남습니다. 종단 간 확인과 상태 머신이 필요할 수 있습니다.
Publisher와 Subscriber의 Reliability가 다르면 항상 연결이 안 되나요?
Best Effort 발행자에 Reliable 구독자는 호환되지 않지만 Reliable 발행자와 Best Effort 구독자는 연결될 수 있습니다. 전체 request–offered 규칙을 확인해야 합니다.
Depth를 크게 하면 데이터 손실이 해결되나요?
일시 정체를 흡수할 수 있지만 메모리와 지연이 늘고 오래된 샘플을 처리할 수 있습니다. 허용 데이터 나이와 소비 속도로 정해야 합니다.
QoS가 맞는데 토픽이 늦는 이유는 무엇인가요?
발행 주기, 직렬화, 큰 메시지, 네트워크 손실, 구독자 처리 지연과 CPU 스케줄링을 함께 측정해야 합니다.
이 글은 ROS 2 QoS의 설계와 진단 원리를 설명합니다. 실제 지원 정책과 기본값은 사용 중인 ROS 2 배포판, RMW와 DDS 구현체의 공식 문서를 함께 확인해야 합니다.