노드로 나눈 로봇 프로그램은 어떤 통신을 선택해야 할까? 지금은 이름을 외우기보다 데이터의 주기·응답·취소 필요성을 기준으로 고른다. 노드는 책임 단위, 토픽은 반복 흐름, 서비스는 짧은 요청·응답, 액션은 진행·취소·결과가 필요한 장시간 작업이다.
01
지금 수업에서 다시 보는 세 가지 선택
현재 커리큘럼에서는 5단계 ‘ROS 2와 시뮬레이션’의 통신 기본을 다시 보는 중이다. 첫 Shorts의 노드는 카메라, 상태, 제어처럼 한 책임을 맡은 실행 단위라는 출발점을 준다. 두 번째 Shorts의 토픽은 보내는 쪽인 publisher와 받는 쪽인 subscriber가 계속 데이터를 주고받는 통로다. 센서값처럼 반복되는 흐름에 어울린다.
세 번째 Shorts는 서비스와 액션을 나눈다. 서비스는 reset처럼 짧은 요청과 응답을 주고받고, 액션은 이동처럼 시간이 걸리는 작업에서 중간 진행 상황(feedback), 취소(cancel), 최종 결과(result)를 다룬다. 세 영상은 노드를 나눈 뒤 데이터의 성격과 작업 시간을 보고 통신 계약을 선택하는 순서로 이어진다.
“같은 명령이라도 계속 흐르는가, 바로 답하는가, 진행 중 취소해야 하는가에 따라 통신이 달라진다.”
02
내가 배운 내용을 다시 확인하는 방식
내가 세운 첫 검증표는 노드 이름·토픽 이름·메시지 타입·QoS·발행 주기다. 여기에 source·build·실행 결과를 분리해 적는다. DAPIER는 이 판단을 쌓아 가는 개인 학습 레포이지 외부 교재가 아니다.
오늘 확인한 것은 개념의 연결이다. 아직 실제 `colcon build`, custom interface 생성, QoS가 맞지 않을 때의 출력, 하드웨어까지 이어지는 동작은 확인하지 못했다. 다음 수업 전에는 작은 publisher/subscriber를 실행하고 `ros2 node list`, `ros2 topic echo`로 메시지를 확인한 뒤, 짧은 service 요청과 action의 feedback·cancel 흐름을 각각 기록해 보려 한다.
03
11월까지의 계획과 다음 질문
숙련자에게 남길 질문은 통신 계약의 깊이다. timestamp·단위·frame_id·유효성·timeout·안전 제한을 어디까지 명시해야 재현 가능한 평가가 될까? 이름과 타입만 맞아도 연결은 되지만, 오래된 센서값은 안전한 행동이 아니다.
11월까지의 계획: 노드·인터페이스를 작은 실습으로 검증하고, 그 결과를 episode 기록과 연결한 뒤, 성공 여부뿐 아니라 지연·취소·안전 정지·실패 원인을 비교할 수 있는 기준을 만들어 가겠다. 교육은 아직 진행 중이며, 다음 단계는 계획으로 남기고 직접 확인한 범위만 계속 기록하겠다.
SOURCES
2026.08.13 Shorts와 기록 경계
- ROS 2 노드: 로봇 프로그램을 작게 나누는 방법 2026.08.13
- 토픽: 로봇 프로그램이 메시지를 나누는 길 2026.08.13
- 서비스와 액션은 토픽과 언제 다를까 2026.08.13
교육은 2026년 11월까지 진행 중이다. Notion은 비공개 수업·학습 원본으로만 사용했고, 이 글에는 개인 URL·페이지 ID·경로·원문 전사를 넣지 않았다. DAPIER는 내가 배운 내용을 정리해 가는 개인 학습 레포이며, 이번 글은 공개 DAPIER 코드나 실행 결과를 근거로 삼지 않았다.