# QoS Compatibility(호환성)와 이슈 사례

ROS2의 QoS(Quality of Service)는 토픽 단위로 서로 다른 노드 간 통신 특성을 조정하기 위해 사용된다. 그러나 QoS 설정이 서로 맞지 않거나, 맞더라도 특정 조합에서 예상치 못한 동작이 발생하기도 한다. 이러한 QoS 호환성 문제는 분산 환경에서 매우 복잡하게 얽히며, DDS 계층에서 정해진 정책이 ROS2 상위 레벨에서 어떻게 해석되는지에 따라 달라질 수 있다. 여기서는 호환성을 가르는 여러 QoS 정책과 그 이슈 사례를 깊이 살펴본다.

#### QoS 프로파일의 기본 호환성

Reliability: `Reliable` vs. `Best Effort`

* Publisher가 `Reliable`, Subscriber가 `Best Effort`인 경우, DDS 스펙상으로는 '상호 통신 가능' 판정을 내릴 수 있다. 다만 실제 메시지 전달 보장 수준이 Subscriber 쪽에서 `Best Effort`로 동작하기 때문에, 패킷 손실 시 재전송을 기대하기 어렵다.
* Publisher가 `Best Effort`, Subscriber가 `Reliable`인 경우, DDS에서 명시적으로 막지는 않지만, Subscriber가 `Reliable`로 구동된다고 해도 Publisher가 재전송을 제공하지 않으므로 메시지 유실 가능성은 동일하다.

Durability: `Transient Local` vs. `Volatile`

* `Transient Local`은 Publisher가 종료되더라도 일정 시간(또는 샘플 수) 동안 과거 메시지를 보존한다. Subscriber가 새로 연결되면 이전 메시지를 받을 수 있다. 반면 `Volatile`인 경우에는 메시지가 즉시 소멸한다.
* 호환성 여부는 'Subscriber가 받을 준비를 하기 전의 메시지'를 얼마나 중시하느냐에 따라 갈린다. `Transient Local` Publisher와 `Volatile` Subscriber의 조합은 가능하지만, Subscriber가 과거 메시지를 받는 기능은 사용하지 못한다.

Deadline:

* Deadline은 메시지가 주어진 주기 내에 도착해야 한다는 것을 의미한다. Publisher와 Subscriber 간에 주기가 다르면 'Deadline Missed Callback'이 잦아질 수 있다.
* Deadline이 서로 다른 노드가 통신 가능성이 있다고 판단되더라도, Publisher 측에서 $T\_p$의 주기로 데이터를 송신하고 Subscriber가 $T\_s$의 주기로 메시지를 받아야 하는 상황에서 $T\_p \neq T\_s$라면 비정상적인 Deadline Miss 이벤트가 발생할 수 있다.
* Deadline $T$를 설정했을 때, Publisher가 $T \geq t\_p$ (평균 메시지 송신 간격), Subscriber가 $T \geq t\_s$ (수신 처리를 위한 가용 시간) 조건을 만족하지 못하면 호환성 문제가 생긴다.

$$
T\_p \geq t\_p,\quad T\_s \geq t\_s
$$

위와 같은 조건을 만족해야 DDS 레벨에서 Deadline QoS가 '호환 가능'한 것으로 간주된다.

#### Liveliness

* Liveliness QoS는 노드가 '정상 동작 중임을' 확인하는 방법과 시간 간격을 정한다. `Automatic`, `Manual by Participant`, `Manual by Topic` 등이 있다.
* Liveliness 손실(Liveliness Lost)는 Publisher가 정해진 Liveliness 갱신 주기를 지키지 못했을 때 발생하며, Subscriber가 Publisher가 사라진 것으로 간주할 수도 있다.
* 서로 다른 Liveliness 설정이라도 DDS 스펙상 '부적합(incompatible)'하다고 즉시 판정하지는 않을 수 있지만, 운영 측면에서 Subscriber가 Publisher를 ‘정상적’이라고 판단하지 못하는 상황이 생긴다.

#### 호환성 판정의 주요 원칙

일반적으로 아래 조건을 모두 만족해야 '호환성 있음'으로 판단된다.

1. **Reliability**: Publisher와 Subscriber 간에 `Reliable - Reliable` 조합 또는 `Reliable - Best Effort` 조합 등이 DDS에서 허용된다. 그러나 실제 응답 기대치가 일치하는지는 별개 문제다.
2. **Durability**: `Transient Local` Publisher를 `Volatile` Subscriber가 구독할 수 있지만, 과거 메시지 보존은 불가능해진다.
3. **Deadline**: 서로간의 Deadline 설정이 유사하거나 Subscriber가 Publisher의 송신 주기를 수용 가능해야 한다.
4. **Liveliness**: Liveliness 모드가 다르더라도 통신은 되지만, Subscriber 쪽에서 Liveliness 콜백 처리가 올바르게 동작하는지는 별도의 고려가 필요하다.

이러한 DDS 단계의 호환성 판정과 실제 시스템 운영에서 발생하는 문제는 괴리가 있을 수 있다. 예를 들어 DDS 레벨에서는 호환 가능이라고 선언하더라도, ROS2 애플리케이션 로직 레벨에서 메시지 유실이나 Deadline 미스가 계속 발생할 수 있다.

#### QoS 호환성 이슈 사례

서버-클라이언트 통신에서의 Reliability mismatch

* 액션(Action) 기반 통신 또는 서비스(Service)에서 Client 노드가 `Reliable`를 요구하는데, 서버(Server) 노드가 `Best Effort`로 동작하면 문제 발생. 이때 DDS 로는 구독 가능하다고 나오지만, Request-Response 구조에서 재시도가 보장되지 않아 통신 안정성이 떨어진다.

녹화(Recording) 파이프라인에서의 Durability 이슈

* ROS Bag2를 사용하여 데이터를 기록하려고 할 때, 카메라 토픽의 QoS가 `Transient Local`로 설정되어 있다고 가정한다. 이를 구독하는 `Volatile` 녹화 노드가 갑작스레 재시작하면 이전 이미지를 받지 못한다. 원하는 과거 영상이 모두 누락될 수 있다.

Deadline 미스 콜백과 타이밍 분산

* 센서 노드가 $t\_p = 10\text{ ms}$ 주기로 메시지를 발행하고, Subscriber는 $T\_s = 15\text{ ms}$ Deadline으로 설정했을 때, 일정한 네트워크 지연이나 처리 지연이 발생하면 Subscriber 측에서 Deadline 미스 콜백이 불필요하게 발생할 수 있다.

Liveliness 관련 서비스 노드 스케일링 문제

* Liveliness가 `Manual by Participant`로 설정된 Publisher가 여러 개 존재하는 대규모 시스템에서, Subscriber는 각각의 Publisher가 정해진 방식으로 Liveliness를 신호 보내지 않으면 노드 '사망'으로 간주할 수 있다. 스케일링 시 간헐적으로 Liveliness Lost 이벤트가 발생해 시스템 내에서 계속해서 Disconnect-Alarms가 뜨는 현상이 발견된다.

#### QoS 설정과 DDS 구현체별 호환성 차이

ROS2는 DDS를 기반으로 하며, 여러 DDS 구현체(eProsima Fast DDS, CycloneDDS, RTI Connext, OpenSplice 등) 중 하나를 선택해 사용할 수 있다. 그러나 QoS 호환성은 DDS 구현체별로 약간씩 다른 해석이나 기능적 차이가 있어서, 아래와 같은 이슈가 발생하기도 한다.

**Discovery 단계에서의 차이**:

각 DDS 구현체는 Discovery(Participant 혹은 Topic discovery 등) 프로토콜과 QoS 정보를 주고받는 과정에서 자체적으로 최적화나 다른 운영 방식을 취할 수 있다. 예를 들어, Participant 연결 시점에 특정 QoS(예: Deadline, Liveliness) 정보가 어떻게 반영되는지, 구독 요청 시점에 `Unknown` 상태로 인해 호환성 판정이 지연되거나 제대로 이뤄지지 않는 경우도 보고된 바 있다.

**Multicast vs. Unicast와 Reliability 문제**:

`Reliable` QoS일 때, DDS 구현체마다 멀티캐스트 사용 방식이 다르다. 어떤 구현체는 멀티캐스트를 능동적으로 활용해 전송 효율을 높이지만, 어떤 구현체는 멀티캐스트 지원을 제한적이거나 아예 끈 상태에서 동작하기도 한다. 이때 Subscriber가 여러 대 존재할 경우, 재전송 로직이 복잡해져 Publisher-Subscriber 간의 QoS 호환성이 흔들릴 수 있다.

* 예: 멀티캐스트를 사용하는 DDS에서 `Reliable` QoS를 설정하면, 스케일아웃이 커질수록 특정 Subscriber에게 재전송 핸드셰이크가 지연되어 메시지 도달률 문제가 발생할 수 있다.

**Transport 레이어별 세부 설정 차이**:

DDS는 QoS 설정 외에도 전송 레이어(UDP, TCP, SHM 등)에 따라 동작이 달라질 수 있다. TCP 기반 연결을 일부 DDS 구현체가 공식적으로 지원하지만, 다른 구현체는 UDP 기반만 지원하기도 하며, SHM(shared memory)를 활용해 고속 통신을 지원할 수도 있다. 이러한 전송 방식 차이로 인해, `Reliable` QoS를 설정하더라도 실제 ACK/NACK 메커니즘 또는 버퍼 관리 방식이 달라 노드 간 예기치 못한 비호환 문제가 생길 수 있다.

#### QoS 정책 간 상호 종속성

ROS2/DDS의 QoS들은 독립적으로 보이지만, 실제로는 서로 연관되며 상호 간섭이 일어난다.

**Reliability와 Durability의 연관성**

* `Transient Local + Best Effort` 조합은, DDS 상에서 메시지 재전송은 기대할 수 없는데 과거 메시지 저장을 해두는 다소 모순된 상황이 된다.
* `Transient Local + Reliable` 조합에서, Publisher가 메시지를 재전송할 수 있으나, Subscriber가 늦게 연결되면 과거 샘플을 받아야 하는지(Transient Local) 혹은 새로 전송받으면 되는지(Reliable) DDS 구현체마다 처리 방식이 다를 수 있다.

**Deadline과 Liveliness의 충돌**

* Publisher가 짧은 Deadline을 요구하고, 동시에 Liveliness를 `Manual by Participant`로 설정해 놓은 상황에서, 갱신 주기가 Deadline보다 길면 Subscriber 관점에서 ‘Deadline 미스’와 ‘Liveliness Lost’ 모두 발생할 수 있다.
* Subscriber가 이를 구분 없이 동일한 장애 이벤트로 처리하는 경우, 운영 로직이 혼선을 일으킬 수 있다.

**Latency Budget vs. Reliability**

* Latency Budget은 ‘대략 이 정도 시간 안에 메시지가 수신자에게 도달하는 것을 선호한다’는 힌트이며, DDS 구현체가 네트워크 패킷을 빠르게 보내야 하는지 지연을 허용해도 되는지 결정하는 참고 지표다.
* Reliability가 `Reliable`인 경우라면, Latency Budget을 작게 잡아도 재전송 때문에 실제 도달 시간이 늘어날 수 있다. 이는 Subscriber가 메시지를 빨리 받지 못해도 QoS 상 ‘부적합’이 아니지만, 애플리케이션 레벨 성능엔 영향을 준다.

#### 극단적 상황에서의 비호환 사례

**Push/Pull 모델 혼재 환경**:

ROS2에서 일반적으로 토픽은 Publisher가 Push하며 Subscriber가 Pull하지 않는 구조다. 그러나 특정 DDS 벤더가 `Pull` 기반 인터페이스를 부분적으로 사용하는 경우, QoS 호환성 계산이 오작동할 수 있다.

예: Publisher 측에서는 메시지를 계속 보낼 준비가 되어 있으나, Subscriber가 Pull 요청을 만족시키지 못해 데이터가 수집되지 않고 DDS 측에서 ‘충돌’ 판정이 날 수 있다.

**노드 재시작 시점의 Durability Reconnection 이슈**:

$t\_0$ 시점에 `Transient Local` Publisher가 동작 중이고, $t\_1$ 시점에 Subscriber가 구독을 시작하면 과거 메시지를 받아야 한다.

Subscriber가 $t\_1$에 연결되자마자 곧바로 재시작($t\_2$)하는 경우, DDS 구현체가 재연결 과정을 스무스하게 처리하지 못하면, Publisher와 Subscriber 간 'Durability QoS' 세팅이 충돌하여 메시지를 일부만 받거나 아예 못 받는 현상이 발생한다.

**비정상적 네트워크 세그멘테이션에서의 Reliability Timeouts**:

클러스터가 여러 네트워크 세그먼트로 나누어져 있을 때, 특정 DDS 구현체가 Domain Participant들 사이에 Relay 노드를 세우지 못하면 `Reliable` QoS 설정하에서도 메시지가 종종 유실된다. DDS 자체는 호환된다고 표시하지만, 실제로 패킷 전송이 이루어지지 않아, 애플리케이션에서 Subscription Timeout이 빈번히 발생한다.

#### 노드 라이프사이클(Lifecycle)과 QoS 불일치 이슈

ROS2에서 노드 라이프사이클을 관리하는 방식(Lifecycle Node)은 일반 노드와 달리 상태(state) 전환이 있으며, 특정 상태에서만 토픽을 발행(Publish)하거나 구독(Subscribe)할 수 있게 제약한다. 이와 함께 QoS 설정이 맞지 않으면 다음과 같은 문제가 발생한다.

**Unconfigured 상태에서의 QoS 잠금(lock-in)**:

* 노드가 Unconfigured 상태에서 DDS Participant를 생성하는 경우, QoS가 초기값으로 설정된 뒤 노드가 Inactive→Active로 전환되어도 QoS 설정을 다시 적용하지 못하는 DDS 구현체가 있다.
* 예: Lifecycle 노드가 Inactive→Active로 갈 때, 내부적으로 ‘새로 구독 시작’ 기능을 발동해도 이미 DDS 계층에 Topic이 생성되어 있으면 QoS가 바뀌지 않아, 원하는 통신 특성을 얻지 못할 수 있다.

**Inactive 상태의 Subscriber가 Deadline을 지키지 못하는 문제**:

* 만약 노드가 Inactive 상태에서 Subscriber 소켓만 열어놓은 상태라면, Publisher의 Deadline QoS에서 ‘미수신’ 상태가 누적된다. Subscriber가 반응(콜백)을 주지 않으므로 의도치 않게 Deadline Miss 콜백이 계속 발생할 수 있다.

#### 멀티스레드 콜백 스핀(Spin)과 QoS 간섭

노드 내에서 콜백을 처리하는 방식이 싱글스레드인지 멀티스레드인지, 혹은 Callback Group을 어떻게 구성하는지에 따라 QoS 측면에서 아래와 같은 부작용이 생길 수 있다.

**Reliable QoS와 멀티스레드 메시지 처리 지연**:

* 멀티스레드 스핀 환경에서 콜백 큐가 처리 지연에 시달리면, Subscriber가 메시지를 즉시 꺼내 처리하지 못해 DDS 레벨에서 ‘Ack/Nack’ 지연이 발생할 수 있다.
* Publisher는 ‘Reliable’ 재전송 로직 때문에 여러 개의 메시지를 동일 Subscriber에 대해 대기 상태로 유지하고, 결국 큐가 가득 차서 전체 메시지 지연을 일으킨다.

**Callback Group 간 Deadline 적용 충돌**:

* 하나의 노드 내에서 여러 Subscriber를 구동하는 경우, Subscriber마다 Deadline이 다를 수 있다. 한 Subscriber의 Deadline 미스 이벤트가 콜백 처리를 독점하면 다른 Subscriber의 콜백이 밀려나는 현상이 발생할 수 있다.

#### QoS Override와 RMW 계층/브리지(Bridge) 연동

ROS2의 RMW 계층은 DDS와의 인터페이스 구간으로, 일부 설정은 RMW 레벨에서 QoS를 재정의(override)해 버릴 수 있다. 또한 ROS1-ROS2 브리지나 다른 미들웨어와의 브리지 시스템을 사용할 때, 양쪽 시스템 간 QoS가 어긋날 수 있다.

**RMW 레벨 QoS Override**:

* ros2 run 시점에 환경 변수를 설정해서 QoS를 자동 조정하게 만드는 기능이 있다. 예: `RMW_QOS_PROFILE`로 미리 정해둔 QoS를 강제 적용.
* 이 경우 애플리케이션 코드에서 QoS를 `Reliable`로 설정해도, RMW가 `Best Effort`로 덮어씌워 다른 노드와의 호환성을 의도치 않게 바꿔버릴 수 있다.

**ROS1-ROS2 브리지에서의 호환성**:

* ROS1에는 QoS라는 개념이 제한적이므로, ROS2의 특정 QoS(예: `Transient Local`, `Reliable`)가 ROS1 쪽에 매핑되지 않는 문제가 생긴다.
* 브리지에서 단순 `Reliable=TCP, Best Effort=UDP` 식으로 대응하는 경우가 많지만, 실제로는 ROS1 Subscriber/Pub이 상태를 알 수 있는 API가 제한적이라서, DDS 상 ‘호환 가능’ 판정이 나와도 메시지가 누락될 수 있다.

#### 실시간(Real-time) 요구사항과 QoS의 상충

ROS2를 실시간 제어나 임베디드 환경에서 사용하려면, 주기적이며 안정적인 메시지 전달이 필요하다. 그러나 DDS 계층의 QoS 설정이 실시간 스케줄링과 충돌하기도 한다.

**Reliable vs. Hard Real-time**:

* 하드 실시간 시스템에서는 메시지 처리 지연이 절대 허용되지 않는다. 그러나 `Reliable` QoS는 재전송을 보장하기 위해 어느 정도 네트워크/시스템 지연을 감수한다. 이는 하드 실시간 스케줄링 모델과 어긋난다.
* 따라서 하드 실시간 환경에선 오히려 `Best Effort` QoS를 선호하기도 한다.

**Liveliness와 실시간 스레드 간섭**:

* 실시간 스레드가 Publisher를 운영할 때, Liveliness에 따른 ‘토픽 생존 신호’를 주기적으로 DDS에 보내야 한다. 이 과정이 정해진 타이밍과 맞물리지 않으면 Liveliness Lost가 발생할 수 있다.
* 실시간 우선순위 스레드가 아닌 일반 우선순위 스레드에서 Liveliness를 송출하면, 실시간 태스크 우선순위에 밀려서 결과적으로 Subscriber가 Publisher ‘죽음’을 잘못 감지하기도 한다.

#### QoS 설정 시 주의 사항과 베스트 프랙티스

아직은 DDS의 세부 옵션과 ROS2의 단순화된 QoS 인터페이스 사이에 불일치가 많아, 아래와 같은 점을 주의해야 한다.

**가능하면 동일 프로파일 세트**:

* 시스템 전체에서 동일 QoS 프로파일을 적극적으로 사용해, 노드 간 혼선을 줄인다. 예: 센서류 노드는 `Reliable + Volatile`, 영상류 노드는 `Best Effort + Volatile` 식으로 통일.

**동적 변동(Dynamic Change) 최소화**:

* 런타임에 QoS를 자주 변경하는 기능은 DDS 스펙에는 존재하지만, ROS2의 경우 완전한 지원이 이뤄지지 않았다. QoS 동적 변경은 호환성 문제를 일으키기 쉬우므로 가급적 사용하지 않는다.

**통신 트래픽 분석 툴 활용**:

* rtpsdump, FastDDS Monitor 등의 DDS 분석 툴을 통해 실제 QoS 값이 어떻게 협상(Negotiation)되었는지, 메시지 유실이 있는지 확인하는 과정이 필수적이다.

#### QoS 디버깅과 호환성 점검 절차

QoS 문제는 단순히 '설정값이 서로 맞느냐'로 끝나지 않고, 실제 시스템 실행 단계에서 예상치 못한 동작(메시지 누락, 연결 지연, Deadline Miss 등)으로 드러난다. 이를 효율적으로 진단하기 위해 다음과 같은 접근 방식을 활용할 수 있다.

**DDS 상태 조회 API**:

* 각 DDS 구현체(eProsima Fast DDS, Cyclone DDS 등)는 Participant, Publisher, Subscriber의 상태 정보를 노출하는 API를 제공한다. 이를 통해 현재 QoS 설정, Topic 정보, Discovery 상황 등을 확인할 수 있다.
* 예: Fast DDS의 경우 `fastdds discovery -i` 커맨드를 사용하면 현재 Domain 내 노드들의 QoS 요약을 텍스트로 확인할 수 있다(버전에 따라 제공 유무가 달라질 수 있음).

```shell
fastdds discovery -i
```

**QoS 호환성 로그(Logging) 확인**:

* DDS 레벨에서 호환성 체크 시 `WARNING: Incompatible Qos` 등의 로그가 출력되기도 한다. 이를 통해 어느 부분에서 불일치가 있는지 식별 가능하다.
* ROS2 노드 실행 시 `--ros-args --log-level debug` 옵션 등으로 DDS 하위 로그가 노출되도록 설정할 수 있다.

```shell
ros2 run <패키지명> <실행파일명> --ros-args --log-level debug
```

**Wireshark/rtpsdump 패킷 분석**:

* 네트워크 트래픽 레벨에서 RTPS(Real Time Publish Subscribe) 패킷을 캡처하여 실제 QoS/Discovery 정보가 어떻게 교환되는지 확인할 수 있다.
* rtpsdump, Wireshark DDS 플러그인을 사용하면 QoS가 협상(Negotiation)되는 과정, 메시지 수신 여부 등을 상세하게 볼 수 있다.

**토픽 Echo/Monitor 도구**:

* ROS2 명령행 툴(예: `ros2 topic echo`, `ros2 topic info`) 또는 rqt\_graph, RViz 등을 통해 현재 어떤 토픽이 생성되었는지, QoS가 어떻게 설정되었는지 확인할 수 있다.
* 메시지가 일부만 오거나 전혀 오지 않는 경우, 양쪽 노드(Publisher와 Subscriber)의 QoS 설정값을 각각 조회해 대조해 본다.

#### QoS 트러블슈팅: 단계별 체크리스트

**DDS 구성 확인**:

* 사용하는 RMW(DDS 구현체)는 무엇이며, 해당 버전에서 지원하는 QoS 정책과 제한사항을 확인한다.
* Domain Participant 수, Discovery 모드(Multicast/Unicast), Transport(UDP/TCP/SHM) 등을 명확히 파악한다.

**ROS2 레벨 QoS 설정값 비교**:

* Publisher와 Subscriber의 프로파일 이름 또는 코드 상 설정값(`rclcpp::QoS(...)`)을 전부 수집한다. `reliability`, `durability`, `deadline`, `liveliness` 등 핵심 파라미터가 일치하거나 호환 가능한지 확인한다.

**환경 변수 및 Override 확인**:

* `RMW_IMPLEMENTATION`, `ROS_DISCOVERY_SERVER`, `FASTRTPS_DEFAULT_PROFILES_FILE` 등으로 인해 QoS가 재정의되고 있지 않은지 검토한다.

**라이프사이클/상태 관리 로직 검증**:

* Lifecycle 노드를 사용한다면, 상태 전환 시점에 어떤 QoS가 적용되고 Topic이 실제로 어떻게 생성되는지 체크한다.

**실시간 스케줄링/멀티스레드 분석**:

* 메시지 수신 처리에 지연이 없는지, Callback Group이 Deadline 미스를 유발하지 않는지 점검한다. 실시간 우선순위를 가진 스레드가 DDS 내부 콜백 처리 스레드보다 높다면 메시지 Ack/Nack가 늦어질 수 있다.

**DDS Monitoring 및 로깅 도구 활용**:

* DDS 구현체 별 모니터링 툴(eProsima Fast DDS Monitor 등)이나 Wireshark로 RTPS 패킷을 캡처하여 실제 재전송(ACK/NACK) 및 Discovery 흐름을 추적한다.
* QoS가 호환 불가능으로 판정된 경우, Inconsistent Topic으로 표시될 수 있으며 이는 로그나 모니터 화면에서 ‘빨간 경고’로 확인할 수 있다.

#### QoS 호환성 극복을 위한 추가 기법

**Bridging 노드/리레이(Relay) 사용**:

* 만약 특정 노드는 `Reliable`만 지원하고, 다른 노드는 `Best Effort`가 필요한 상황이라면 중간에 ‘Bridge Node’를 두어 ‘Reliable→Reliable 구독 후 Best Effort→발행’ 식으로 변환하는 방법을 취하기도 한다.
* 이때 브리지 노드가 성능 병목이 되거나 메시지 지연을 가져올 수 있으므로 모니터링이 필수다.

**QoS Compatibility 자동 튜닝 라이브러리 활용**:

* ROS2 커뮤니티에서 다양한 QoS 자동 조정 툴이나 정책 자동화 시도가 이루어지고 있다. 예를 들어, QoS가 맞지 않아 메시지가 끊길 경우 자동으로 ‘Fallback QoS’를 적용해 보는 방식이다.
* 아직은 실험적 단계에 머무르는 경우가 많지만, 시스템 규모가 크면 일일이 모든 노드의 QoS를 맞추는 것보다는 자동화 툴을 쓰는 편이 효율적일 수 있다.

**별도의 MCDP(Model, Configure, Deploy, Process) 접근**:

* 대규모 프로젝트에서 QoS를 체계적으로 관리하기 위해, DDS 수준의 XML 프로파일을 설계(모델)하고, 이를 ROS2에서 Configuration 단계에서 로드하며, 최종 Deploy 시 DevOps 파이프라인 내에서 검증, Process 모니터링까지 연계하는 전략이 있다.
* 예: "Fast-DDS XML QoS Profile"을 GitOps에 저장해 두고, CI/CD 파이프라인에서 `fastdds discovery -i` 결과와 비교하여 불일치가 있으면 빌드를 중단시키는 식이다.