1261.36 토픽, 서비스, 액션의 비교 분석

1. 서론

ROS2는 로봇 시스템의 다양한 통신 요구를 충족하기 위하여 토픽(Topic), 서비스(Service), 액션(Action)이라는 세 가지 핵심 통신 패러다임을 제공한다. 각 패러다임은 고유한 통신 구조, 데이터 흐름 특성, 그리고 시간적 특성을 가지며, 로봇 행동 제어 시스템의 설계에서 적절한 패러다임의 선택은 시스템의 성능과 안정성에 직접적인 영향을 미친다. 본 절에서는 이 세 가지 통신 메커니즘을 통신 모델, 시간적 특성, 데이터 흐름 방향성, 상태 관리 능력, 그리고 적용 적합성의 관점에서 체계적으로 비교·분석한다.

2. 통신 모델의 구조적 비교

2.1 토픽의 발행-구독 모델

토픽은 발행-구독(Publish-Subscribe) 패턴에 기반한 비동기 통신 메커니즘이다. 발행자(Publisher)는 특정 토픽 이름으로 메시지를 발행하며, 해당 토픽에 등록된 구독자(Subscriber)는 메시지가 도착할 때 콜백 함수를 통하여 이를 수신한다. 발행자와 구독자 사이에는 직접적인 연결이 존재하지 않으며, 양자 간의 결합도(coupling)가 낮다는 것이 구조적 특징이다.

토픽 통신에서 발행자는 구독자의 존재 여부를 인지하지 못하며, 구독자 역시 발행자의 수나 상태에 대한 정보를 보유하지 않는다. 이러한 익명성(anonymity)은 시스템의 모듈화와 확장성을 극대화하는 장점이 있으나, 메시지 전달의 확인(acknowledgement)이 통신 프로토콜 수준에서 보장되지 않는다는 제약을 수반한다.

2.2 서비스의 요청-응답 모델

서비스는 요청-응답(Request-Response) 패턴에 기반한 동기적 또는 비동기적 통신 메커니즘이다. 서비스 클라이언트(Service Client)가 서비스 서버(Service Server)에 요청(Request)을 전송하면, 서버는 해당 요청을 처리한 후 응답(Response)을 반환한다. 이 패턴은 원격 프로시저 호출(Remote Procedure Call, RPC)과 구조적으로 유사하다.

서비스 통신은 일대일(one-to-one) 관계를 기본으로 하며, 하나의 서비스 이름에 대하여 단일 서버만 존재할 수 있다. 클라이언트는 복수 존재할 수 있으나, 각 요청-응답 쌍은 독립적으로 처리된다. 서비스 호출은 요청의 전송과 응답의 수신이라는 명확한 두 단계로 구성되며, 응답의 수신을 통하여 요청 처리의 완료를 확인할 수 있다.

2.3 액션의 복합 통신 모델

액션은 토픽과 서비스를 결합한 복합(composite) 통신 메커니즘이다. 액션은 내부적으로 세 가지 하위 통신 채널로 구성된다. 첫째, 목표 전송(Goal) 채널은 서비스 통신으로 구현되어 액션 클라이언트가 액션 서버에 목표를 전달하고 수락 또는 거부 응답을 수신한다. 둘째, 피드백(Feedback) 채널은 토픽 통신으로 구현되어 작업 진행 과정의 중간 상태를 주기적으로 전달한다. 셋째, 결과(Result) 채널은 서비스 통신으로 구현되어 작업 완료 시 최종 결과를 반환한다. 이에 더하여 취소(Cancel) 요청을 위한 별도의 서비스 채널이 존재한다.

이러한 복합 구조는 액션이 장시간 수행되는 비동기 작업의 생명주기(lifecycle) 전체를 관리할 수 있게 한다.

3. 시간적 특성의 비교

3.1 즉시성과 지속성

토픽 통신은 본질적으로 연속적(continuous) 데이터 스트림에 적합하다. 센서 데이터의 주기적 발행, 로봇 상태의 실시간 모니터링 등 데이터가 지속적으로 갱신되는 상황에서 토픽은 효율적인 통신 수단이 된다. 토픽 메시지에는 작업의 시작과 종료라는 개념이 존재하지 않으며, 각 메시지는 독립적인 데이터 단위(datum)로 처리된다.

서비스 통신은 일회성(one-shot) 상호작용에 적합하다. 요청의 전송으로 시작하여 응답의 수신으로 종료되는 단일 트랜잭션(transaction) 구조를 갖는다. 서비스 호출은 일반적으로 짧은 시간 내에 완료될 것이 기대되며, 장시간 소요되는 처리에는 구조적으로 부적합하다. 서비스 서버가 요청을 처리하는 동안 클라이언트는 응답을 대기하여야 하며, 이 기간 중 진행 상태에 대한 정보를 수신할 수 없다.

액션 통신은 장시간(long-running) 작업의 관리에 특화되어 있다. 목표의 전송에서 결과의 수신까지 수 초에서 수 분, 경우에 따라 수 시간에 걸치는 작업의 전 과정을 관리할 수 있다. 피드백 채널을 통하여 작업 진행률, 현재 상태, 추정 잔여 시간 등의 중간 정보를 주기적으로 제공할 수 있으며, 작업 수행 중의 취소 요청도 지원한다.

3.2 블로킹 특성

토픽의 발행 연산은 비블로킹(non-blocking)이다. 발행자는 메시지를 DDS 미들웨어의 전송 버퍼에 기록한 후 즉시 반환되며, 구독자의 수신 여부와 무관하게 제어 흐름이 지속된다.

서비스의 동기 호출(synchronous call)은 블로킹(blocking) 연산이다. 클라이언트는 call() 메서드를 호출한 시점부터 서버의 응답이 도착할 때까지 현재 스레드의 실행이 차단된다. ROS2는 비동기 호출(async_send_request())도 지원하여 이 제약을 완화할 수 있으나, 이 경우에도 응답 수신을 위한 별도의 콜백 또는 future 객체의 관리가 필요하다.

액션은 근본적으로 비동기(asynchronous) 통신 모델이다. 목표의 전송은 비블로킹으로 수행되며, 피드백의 수신과 결과의 확인은 콜백 함수를 통하여 이벤트 구동(event-driven) 방식으로 처리된다.

4. 데이터 흐름 방향성의 비교

토픽은 단방향(unidirectional) 데이터 흐름을 제공한다. 발행자에서 구독자로의 일방적 데이터 전달만 이루어지며, 구독자가 발행자에게 데이터를 회신하는 경로는 토픽 자체에 포함되지 않는다. 양방향 통신이 필요한 경우 별도의 토픽을 추가로 구성하여야 한다.

서비스는 양방향(bidirectional) 데이터 흐름을 제공한다. 클라이언트에서 서버로의 요청과 서버에서 클라이언트로의 응답이 단일 통신 세션 내에서 이루어진다. 그러나 이 양방향성은 단일 왕복(single round-trip)에 한정되며, 중간 과정에서의 추가적인 데이터 교환은 지원되지 않는다.

액션은 다방향(multidirectional) 데이터 흐름을 제공한다. 클라이언트에서 서버로의 목표 전달, 서버에서 클라이언트로의 수락/거부 응답, 서버에서 클라이언트로의 주기적 피드백, 그리고 서버에서 클라이언트로의 최종 결과 반환이 하나의 통합된 인터페이스 내에서 이루어진다. 또한 클라이언트에서 서버로의 취소 요청이 작업 수행 중 언제든 전달될 수 있다.

5. 상태 관리 능력의 비교

토픽 통신은 상태 비보존(stateless) 특성을 갖는다. 각 메시지는 이전 메시지와의 관계 없이 독립적으로 처리되며, 통신 자체가 특정 작업의 상태를 추적하거나 관리하는 기능을 제공하지 않는다.

서비스 통신은 제한적 상태 관리를 제공한다. 요청의 전송과 응답의 수신이라는 두 가지 상태만 존재하며, 요청 처리 과정의 세부 상태는 통신 프로토콜이 관리하지 않는다.

액션 통신은 포괄적 상태 관리를 제공한다. 각 목표(goal)에 대하여 ROS2 액션 프로토콜은 다음과 같은 상태 전이를 정의한다.

이러한 상태 전이 모델은 장시간 작업의 생명주기를 체계적으로 관리할 수 있게 하며, 클라이언트가 작업의 현재 단계를 정확히 파악할 수 있도록 한다.

6. 통신 패러다임의 종합 비교

다음 표는 세 가지 통신 패러다임의 핵심 특성을 요약한 것이다.

7. 오버헤드와 복잡도의 비교

7.1 구현 복잡도

토픽은 가장 단순한 구현 구조를 갖는다. 발행자 또는 구독자 노드를 생성하고 콜백 함수를 등록하는 것만으로 통신이 가능하다. 메시지 정의는 .msg 파일을 통하여 이루어지며, 별도의 상태 관리 로직이 불필요하다.

서비스는 중간 수준의 구현 복잡도를 갖는다. 요청과 응답의 메시지 타입을 .srv 파일에 정의하여야 하며, 서버 측에서는 요청 처리 콜백을, 클라이언트 측에서는 응답 처리 로직을 구현하여야 한다.

액션은 가장 높은 구현 복잡도를 갖는다. .action 파일에 목표, 피드백, 결과의 세 가지 메시지 타입을 정의하여야 하며, 서버 측에서는 목표 수락/거부 콜백, 실행 콜백, 취소 처리 콜백을 구현하여야 한다. 클라이언트 측에서는 목표 응답 콜백, 피드백 수신 콜백, 결과 수신 콜백을 각각 등록하여야 한다.

7.2 통신 오버헤드

토픽은 단일 DDS 토픽을 사용하므로 통신 오버헤드가 가장 낮다. 서비스는 요청용과 응답용 두 개의 DDS 토픽을 내부적으로 사용한다. 액션은 목표 서비스, 결과 서비스, 취소 서비스, 피드백 토픽, 상태 토픽 등 복수의 DDS 엔드포인트를 생성하므로 통신 오버헤드가 가장 높다. 따라서 단순한 데이터 전달이나 짧은 시간의 원격 호출에 액션을 사용하는 것은 불필요한 리소스 소비를 유발할 수 있다.

8. 행동 제어 관점에서의 적합성 분석

로봇 행동 제어 시스템에서 각 통신 패러다임은 다음과 같은 역할에 적합하다.

토픽은 센서 데이터의 연속적 스트리밍, 로봇 상태의 실시간 모니터링, 제어 명령의 주기적 전송 등 지속적인 데이터 흐름이 요구되는 영역에 적합하다. 예를 들어, 관성 측정 장치(IMU) 데이터의 발행, 로봇 관절 상태의 모니터링, 속도 명령의 전달 등에 토픽이 사용된다.

서비스는 파라미터의 조회 및 설정, 시스템 구성의 변경, 즉각적인 상태 질의 등 일회성이면서 짧은 시간 내에 완료되는 상호작용에 적합하다. 예를 들어, 지도 데이터의 요청, 센서 캘리브레이션의 트리거, 제어 모드의 전환 등에 서비스가 사용된다.

액션은 자율 내비게이션, 매니퓰레이션 작업, 순찰 임무 등 장시간에 걸쳐 수행되며 진행 상황의 모니터링과 중간 취소가 필요한 작업에 적합하다. Nav2의 NavigateToPose 액션, MoveIt2의 MoveGroup 액션 등이 대표적인 사례이다. 이러한 작업은 수행 시간이 불확정적이며, 외부 조건의 변화에 따라 작업의 중단이나 수정이 요구될 수 있다.

9. 결론

토픽, 서비스, 액션은 ROS2가 제공하는 상호 보완적인 통신 패러다임이며, 각각 고유한 설계 목적과 적용 영역을 갖는다. 토픽은 연속적이고 비동기적인 데이터 스트림에, 서비스는 동기적이고 즉결적인 원격 호출에, 액션은 장시간 비동기 작업의 생명주기 관리에 최적화되어 있다. 로봇 행동 제어 시스템의 설계에서는 각 통신 요구의 시간적 특성, 데이터 흐름 패턴, 상태 관리 필요성을 정밀하게 분석하여 적합한 패러다임을 선택하여야 하며, 이 세 가지 메커니즘의 적절한 조합이 견고하고 확장 가능한 로봇 소프트웨어 아키텍처의 기반이 된다.