1261.38 통신 패러다임 선택 기준과 의사결정 프레임워크

1. 서론

로봇 행동 제어 시스템의 설계에서 통신 패러다임의 선택은 시스템 아키텍처의 근간을 결정하는 핵심적 설계 결정이다. ROS2가 제공하는 토픽, 서비스, 액션의 세 가지 통신 메커니즘은 각각 상이한 특성을 보유하며, 부적절한 패러다임의 선택은 시스템의 성능 저하, 복잡도 증가, 유지보수성 악화를 초래한다. 본 절에서는 통신 패러다임 선택을 위한 체계적 기준을 정립하고, 설계자가 일관되고 합리적인 의사결정을 수행할 수 있도록 구조화된 프레임워크를 제시한다.

2. 차 선택 기준: 통신의 시간적 특성

2.1 연속성 대 이산성

통신 패러다임 선택의 최우선 기준은 데이터 흐름의 시간적 특성이다. 데이터가 명확한 시작과 종료 없이 지속적으로 흐르는 경우, 즉 데이터 스트림(data stream)의 성격을 갖는 경우에는 토픽이 적합하다. 센서 데이터의 주기적 발행, 로봇 상태의 연속적 모니터링, 제어 명령의 반복적 전송이 이에 해당한다.

반면 명확한 시작과 종료가 존재하는 이산적(discrete) 상호작용의 경우에는 서비스 또는 액션이 적합하다. 이 경우 작업의 예상 수행 시간이 2차 선택 기준으로 작용한다.

2.2 수행 시간의 분류

이산적 상호작용에서 작업의 예상 수행 시간은 패러다임 선택을 결정짓는 핵심 요인이다. 다음의 분류 기준은 ROS2 커뮤니티에서 광범위하게 수용되는 경험적 지침이다.

• 즉시 응답 작업(수 밀리초 이내): 서비스가 적합하다. 파라미터 조회, 단순 상태 질의, 좌표 변환 계산 등이 해당한다.
• 단기 처리 작업(수십 밀리초에서 수백 밀리초): 서비스가 적합하나, 처리 시간의 가변성이 큰 경우 서비스의 타임아웃 설정에 주의가 필요하다.
• 중기 처리 작업(수 초): 작업의 특성에 따라 서비스와 액션 사이의 경계 영역에 놓인다. 피드백의 필요성과 취소 가능성이 판단의 기준이 된다.
• 장시간 작업(수 초 이상, 상한 불확정): 액션이 적합하다. 내비게이션, 매니퓰레이션, 순찰 임무 등이 해당한다.

3. 차 선택 기준: 기능적 요구사항

3.1 피드백 필요성

작업 수행 과정에서 중간 상태 정보의 보고가 필요한 경우, 액션이 유일한 적합한 선택이다. 토픽은 작업의 개념이 부재하여 특정 작업에 대한 피드백을 연관짓는 메커니즘이 없으며, 서비스는 요청 전송과 응답 수신 사이에 중간 데이터를 전달하는 경로가 존재하지 않는다.

피드백의 필요성은 다음의 관점에서 평가한다.

• 사용자 인터페이스에서 진행률 표시가 요구되는가
• 작업 수행 중 외부 모니터링 시스템이 상태를 추적하여야 하는가
• 작업의 중간 결과에 기반한 동적 의사결정이 필요한가
• 로깅 또는 진단 목적으로 작업 과정의 기록이 필요한가

이 중 하나라도 해당되는 경우 액션의 사용이 권장된다.

3.2 취소 가능성

작업 수행 도중 외부 요인에 의한 작업 중단이 요구될 수 있는 경우, 액션이 선택되어야 한다. ROS2 서비스는 요청 전송 이후 처리 도중 취소를 지원하는 표준 메커니즘을 제공하지 않는다. 액션은 cancel_goal 서비스를 통하여 표준화된 취소 절차를 보장한다.

취소 필요성의 평가 기준은 다음과 같다.

• 사용자가 작업 도중 수동 개입할 가능성이 존재하는가
• 환경 변화(장애물 출현, 목표 무효화 등)에 의한 작업 중단이 예상되는가
• 우선순위가 높은 작업에 의한 선점(preemption)이 발생할 수 있는가
• 안전 관련 조건(비상 정지, 경계 이탈 등)에 의한 즉각 중단이 필요한가

3.3 응답 보장의 필요성

요청에 대한 처리 결과의 확인이 필수적인 경우에는 서비스 또는 액션이 적합하다. 토픽의 발행-구독 모델은 메시지 전달의 확인 메커니즘을 통신 프로토콜 수준에서 제공하지 않는다. RELIABLE QoS 정책은 DDS 계층에서의 전달 신뢰성을 향상시키나, 이는 수신자의 처리 완료를 의미하지 않는다.

4. 차 선택 기준: 아키텍처적 고려사항

4.1 결합도와 확장성

발행-구독 모델 기반의 토픽은 가장 낮은 결합도를 제공한다. 새로운 구독자의 추가나 기존 구독자의 제거가 발행자에 영향을 미치지 않으며, 시스템의 확장이 용이하다. 반면 서비스와 액션은 클라이언트-서버 관계를 기본으로 하므로 상대적으로 높은 결합도를 보인다.

다대다(many-to-many) 통신이 요구되는 경우에는 토픽이 적합하며, 일대일(one-to-one) 또는 다대일(many-to-one) 통신이 요구되는 경우에는 서비스 또는 액션이 적합하다.

4.2 통신 오버헤드

각 통신 패러다임은 상이한 수준의 시스템 자원을 소비한다. 토픽은 단일 DDS 엔드포인트를 사용하며, 서비스는 요청용과 응답용 두 개의 DDS 엔드포인트를 생성한다. 액션은 목표 서비스, 취소 서비스, 결과 서비스, 피드백 토픽, 상태 토픽 등 다수의 DDS 엔드포인트를 내부적으로 생성한다.

자원이 제약된 임베디드 시스템이나 통신 대역폭이 제한된 환경에서는 통신 오버헤드가 중요한 선택 기준이 된다. 단순한 상호작용에 액션을 사용하는 것은 불필요한 자원 소비를 유발한다.

4.3 구현 복잡도와 유지보수성

통신 패러다임의 복잡도는 토픽 < 서비스 < 액션 순으로 증가한다. 프로젝트의 개발 일정, 팀의 기술 역량, 장기 유지보수 계획 등이 패러다임 선택에 영향을 미칠 수 있다. 그러나 구현 복잡도의 최소화를 위하여 기능적 요구사항에 부합하지 않는 패러다임을 선택하는 것은 지양하여야 한다. 기능적 부적합은 차후 시스템 수준의 우회 구현(workaround)을 유발하며, 이는 전체 복잡도를 오히려 가중시킨다.

5. 의사결정 프레임워크

5.1 단계적 의사결정 흐름

다음은 통신 패러다임 선택을 위한 체계적 의사결정 흐름이다.

1단계: 데이터 흐름의 연속성 판단

데이터가 명확한 시작/종료 없이 연속적으로 흐르는가? 그러하다면 토픽을 선택한다.

2단계: 수행 시간 판단

작업의 예상 수행 시간이 수 초 이상이거나 상한이 불확정적인가? 그러하다면 액션을 선택한다.

3단계: 피드백 필요성 판단

작업 수행 중 중간 상태 정보의 보고가 필요한가? 그러하다면 액션을 선택한다.

4단계: 취소 가능성 판단

작업 수행 도중 취소가 요구될 수 있는가? 그러하다면 액션을 선택한다.

5단계: 기본 선택

위 조건 중 어느 것에도 해당하지 않으면 서비스를 선택한다.

5.2 의사결정 매트릭스

다음 표는 주요 판단 기준의 조합에 따른 권장 패러다임을 정리한 것이다.

5.3 경계 사례의 처리

일부 시나리오는 단일 패러다임으로 명확히 분류되지 않는 경계 사례에 해당한다.

수행 시간이 가변적인 서비스 호출: 일반적으로는 수 밀리초 이내에 완료되나, 특정 조건에서 수 초 이상 소요될 수 있는 연산이 존재한다. 이 경우 최악 조건(worst case)의 수행 시간을 기준으로 판단하여야 하며, 최악 시간이 수 초를 초과하는 경우 액션의 사용을 권장한다.

피드백이 유용하나 필수적이지 않은 작업: 피드백이 사용자 경험(user experience)을 향상시키나 시스템 기능에 필수적이지 않은 경우, 구현 복잡도와 기능적 이점을 비교하여 결정한다. 장기적 관점에서 피드백 기능의 추가가 예상된다면, 초기 설계에서 액션을 채택하는 것이 재설계 비용을 절감한다.

복합 작업의 분해: 하나의 요청이 내부적으로 다수의 하위 작업으로 분해되는 경우, 전체 작업은 액션으로 관리하고 개별 하위 작업은 서비스 또는 토픽으로 처리하는 계층적 설계가 적합하다. 예를 들어, 자율 내비게이션 액션 내에서 경로 계획은 서비스로, 경로 추종 제어 명령은 토픽으로 구현할 수 있다.

6. 반패턴(Anti-Pattern)의 식별

6.1 토픽의 오용

서비스 또는 액션이 적합한 상호작용에 토픽을 사용하는 것은 대표적인 반패턴이다. 예를 들어, 요청-응답 관계를 토픽의 쌍(pair)으로 구현하는 경우, 요청과 응답의 대응 관계를 애플리케이션 수준에서 관리하여야 하며, 이는 불필요한 복잡도와 오류 가능성을 유발한다.

6.2 서비스의 오용

장시간 작업을 서비스로 구현하는 것은 클라이언트 측의 블로킹 또는 타임아웃 문제를 야기한다. 비동기 서비스 호출(async_send_request)을 사용하더라도, 서비스 프로토콜 자체가 중간 상태 보고와 취소를 지원하지 않으므로 근본적인 제약이 해소되지 않는다.

6.3 액션의 오용

짧은 시간 내에 완료되는 단순 질의에 액션을 사용하는 것은 불필요한 통신 오버헤드와 구현 복잡도를 유발한다. 액션의 내부 구현은 다수의 DDS 엔드포인트를 생성하므로, 단순 작업에 대한 과도한 자원 할당이 된다.

7. 결론

통신 패러다임의 선택은 데이터 흐름의 연속성, 작업 수행 시간, 피드백 필요성, 취소 가능성의 네 가지 핵심 기준에 의하여 체계적으로 결정되어야 한다. 본 절에서 제시한 단계적 의사결정 프레임워크는 이 기준들을 순차적으로 평가하여 일관된 패러다임 선택을 유도한다. 설계자는 이 프레임워크를 기계적으로 적용하되, 경계 사례에 대해서는 시스템의 장기적 진화 방향과 확장 가능성을 고려한 판단이 필요하다. 반패턴의 조기 식별과 회피는 시스템의 견고성과 유지보수성을 보장하는 데 기여한다.