1261.32 서비스 통신의 적용 사례와 제약

1. 서비스 통신의 주요 적용 사례

1.1 매개변수 조회 및 설정

ROS2에서 노드의 런타임 매개변수(Parameter)를 외부에서 조회하거나 변경하는 작업은 서비스 통신의 전형적인 적용 사례이다. ROS2의 매개변수 시스템은 내부적으로 서비스 인터페이스를 사용하여 구현되어 있으며, set_parameters, get_parameters, list_parameters, describe_parameters 등의 서비스를 각 노드가 자동으로 제공한다.

매개변수 조회는 명확한 요청-응답 관계를 가지며, 조회 결과가 후속 처리의 전제 조건이 되는 전형적인 동기적 상호작용이다.

1.2 좌표 변환 연산 요청

로봇 시스템에서 특정 좌표 프레임 간의 변환 행렬을 요청하는 작업에 서비스 통신이 활용된다. TF2(Transform Framework 2)의 정적 변환 조회는 내부적으로 토픽과 캐싱을 사용하지만, 변환 트리의 검증이나 특수 변환 연산 요청에서는 서비스 호출이 적합하다. 입력 좌표와 목표 프레임을 요청으로 제공하고, 변환된 좌표를 응답으로 수신하는 구조는 서비스 통신의 설계 의도에 정확히 부합한다.

1.3 센서 보정(Calibration) 실행

카메라, IMU, LiDAR 등의 센서 보정 절차를 개시하는 데 서비스 통신이 사용된다. 보정 요청은 일회성으로 발생하며, 보정이 완료된 후 성공 여부와 보정 매개변수를 응답으로 반환한다. 이 과정은 연속적 데이터 스트림이 아닌 단발성 작업이므로 토픽 통신보다 서비스 통신이 적합하다.

1.4 모드 전환 및 시스템 구성 변경

로봇의 운용 모드를 수동(Manual)에서 자율(Autonomous)로 전환하거나, 특정 센서의 활성화·비활성화를 수행하는 작업에 서비스 통신이 활용된다. std_srvs/srv/SetBool 서비스 타입은 부울 값을 통해 기능의 활성화 여부를 설정하고 결과를 반환하는 범용 인터페이스를 제공한다.

1.5 지도 데이터 요청

SLAM(Simultaneous Localization and Mapping) 시스템이 생성한 점유 격자 지도(Occupancy Grid Map)를 다른 노드가 요청하는 경우, nav_msgs/srv/GetMap 서비스를 통해 최신 지도 데이터를 일회성으로 조회할 수 있다. 지도 데이터는 스트리밍이 아닌 스냅샷 방식으로 전달되므로 서비스 통신이 효율적이다.

1.6 경로 계획 요청

내비게이션 시스템에서 출발점과 목표점을 지정하여 전역 경로(Global Path)를 계산하는 작업에 서비스 통신이 사용된다. Nav2의 ComputePathToPose 서비스는 시작 위치와 목표 위치를 요청으로 받아 계산된 경로를 응답으로 반환한다. 이 작업은 명확한 입출력 관계를 가지며, 결과의 도착이 후속 행동의 전제 조건이 되는 상호작용이다.

1.7 노드 상태 진단

시스템 관리자나 모니터링 도구가 각 노드의 건강 상태(Health Status), 실행 통계, 자원 사용량 등을 조회하는 데 서비스 통신이 활용된다. diagnostic_msgs 패키지의 진단 서비스는 노드의 현재 상태를 구조화된 응답으로 반환한다.

2. 서비스 통신의 제약 사항

2.1 장시간 작업에 대한 부적합성

서비스 통신은 요청에 대한 응답이 비교적 짧은 시간 내에 반환되는 작업에 적합하도록 설계되었다. 로봇의 내비게이션, 매니퓰레이션 궤적 실행, 대규모 데이터 처리 등 수초에서 수분에 걸쳐 수행되는 장시간 작업에서는 다음과 같은 문제가 발생한다.

• 진행 상황 보고 불가: 서비스 통신에는 작업의 중간 진행 상황을 클라이언트에 보고하는 메커니즘이 존재하지 않는다. 클라이언트는 응답이 도착할 때까지 작업의 현재 상태를 파악할 수 없다.
• 작업 취소 불가: 서비스 호출 후 진행 중인 작업을 외부에서 취소하는 표준 인터페이스가 제공되지 않는다. 클라이언트가 요청을 전송한 후 해당 작업을 중단시키려면 별도의 취소 서비스를 구현하여야 한다.
• 타임아웃 위험: 장시간 작업 중 서비스 응답이 지연되면 클라이언트 측에서 타임아웃이 발생하여 통신 실패로 처리될 수 있다.

2.2 일대일 통신 구조의 제약

서비스 통신은 하나의 클라이언트 요청에 대해 하나의 서버가 응답하는 일대일(One-to-One) 구조를 기본으로 한다. 이 구조에서 발생하는 제약은 다음과 같다.

• 로드 밸런싱 미지원: 동일 서비스 이름으로 복수의 서버를 등록하여 요청을 분산 처리하는 메커니즘이 표준으로 제공되지 않는다.
• 브로드캐스트 요청 불가: 하나의 서비스 호출로 복수의 서버에 동시에 요청을 전달하고 각각의 응답을 수집하는 방식은 서비스 통신에서 지원되지 않는다.

2.3 서버 가용성에 대한 시간적 의존

서비스 통신은 요청 시점에 서버가 활성 상태이어야 하며, 서버가 비활성 상태인 경우 요청 처리가 불가능하다. 토픽 통신의 TRANSIENT_LOCAL 내구성 정책과 같이 서비스 요청을 큐에 저장하고 서버가 활성화될 때 처리하는 메커니즘은 존재하지 않는다.

2.4 콜백 차단으로 인한 시스템 영향

단일 스레드 실행자 환경에서 서비스 콜백의 처리 시간이 과도하게 길어지면, 동일 노드 내의 다른 콜백(토픽 구독자, 타이머 등)의 실행이 차단된다. 이는 센서 데이터 수신 지연, 제어 주기 위반 등 시스템 전반의 성능 저하로 이어질 수 있다.

2.5 네트워크 단절 시 복구 메커니즘 부재

네트워크 단절로 인해 요청이 서버에 도달하지 못하거나, 응답이 클라이언트에 반환되지 못하는 경우, ROS2 서비스 통신은 자동 재시도 메커니즘을 제공하지 않는다. DDS 미들웨어의 RELIABLE QoS 정책이 전송 계층에서의 재전송을 수행하나, 응용 수준에서의 실패 복구는 개발자가 명시적으로 구현하여야 한다.

2.6 응답 크기와 전송 제약

대용량 데이터(예: 고해상도 지도, 대규모 포인트 클라우드)를 서비스 응답으로 반환하는 경우, DDS 미들웨어의 최대 메시지 크기 제한과 직렬화 오버헤드가 병목이 될 수 있다. 이러한 경우에는 서비스 응답에 데이터의 위치나 식별자를 반환하고, 실제 데이터는 토픽이나 파일 전송을 통해 별도로 전달하는 간접적 방식이 사용된다.

3. 서비스 통신의 적합성 판단 기준

서비스 통신의 사용 여부를 결정하기 위한 판단 기준은 다음과 같이 요약된다.

서비스 통신이 적합하지 않은 사용 사례에서는 토픽 통신이나 액션(Action) 통신의 사용을 고려하여야 한다. 특히, 장시간 작업의 관리에는 액션 통신이 진행 상황 보고, 작업 취소, 결과 반환을 통합적으로 지원하므로 적합하다.

4. 참고 문헌

• Open Robotics, “ROS 2 Documentation: Humble Hawksbill,” https://docs.ros.org/en/humble/, 2022.
• Open Robotics, “Navigation 2 Documentation,” https://navigation.ros.org/, 2022.
• OMG, “Data Distribution Service (DDS) Specification, Version 1.4,” Object Management Group, 2015.
• Maruyama, Y., Kato, S., Azumi, T., “Exploring the Performance of ROS2,” Proceedings of the 13th International Conference on Embedded Software (EMSOFT), 2016.