AMR(자율 이동 로봇) 완벽 가이드 | 소프트웨어 엔지니어를 위한 로보틱스 기초

이 글의 핵심

물류창고, 스마트팩토리, 병원 등에 투입되는 AMR(Autonomous Mobile Robot, 자율 이동 로봇) 은 더 이상 로보틱스 전공자만의 영역이 아닙니다. 물류 자동화, 플릿 관리 플랫폼, 산업용 IoT 백엔드를 다루는 소프트웨어 엔지니어라면 채용 공고와 코드베이스 곳곳에서 SLAM, ROS2, 코스트맵(costmap), 파티클 필터 같은 용어를 마주치게 됩니다. 이 글은 하드웨어 조립이나 로봇 공학 수식이 아니라, 소프트웨어 엔지니어가 AMR 도메인 코드베이스와 대화하는 데 필요한 최소한의 개념 지도를 제공하는 데 목표를 둡니다.

왜 이 글을 쓰는가: 물류 자동화나 로보틱스 팀에 새로 합류하는 백엔드·플랫폼 엔지니어는 흔히 “AGV랑 AMR이 뭐가 다른가요?”라는 질문에서부터 막힙니다. 이 질문에 자신 있게 답할 수 있으면, 이후 SLAM·경로 계획·ROS2 같은 개념들이 훨씬 자연스럽게 이어집니다.

---

1. AMR이란 무엇인가 — AGV와의 근본적인 차이

1.1 AGV: 정해진 길을 따라가는 로봇

AGV(Automated Guided Vehicle, 무인 반송차) 는 1950년대부터 산업 현장에서 쓰여온 오래된 개념입니다. 바닥에 설치한 자기 테이프, 매설된 유도선, QR 코드 마커, 반사 랜드마크 같은 물리적 인프라를 센서로 따라가며 이동합니다. AGV의 소프트웨어는 본질적으로 “선을 따라가면서 정지선에서 멈추고, 교차로에서 우선순위를 조율하는” 수준의 제어 로직에 가깝습니다.

AGV의 장점은 예측 가능성입니다. 경로가 물리적으로 고정되어 있으므로 움직임이 항상 동일하고, 안전 인증도 상대적으로 단순합니다. 반면 단점은 경직성입니다. 창고 레이아웃을 바꾸거나 새로운 라인을 추가하려면 바닥 공사를 다시 해야 하므로, 변경 비용과 다운타임이 큽니다.

1.2 AMR: 스스로 길을 찾는 로봇

AMR(Autonomous Mobile Robot) 은 물리적 유도 인프라 없이, 주변 환경을 센서로 인식하고 소프트웨어로 지도를 만들어 스스로 경로를 계산합니다. LiDAR나 카메라로 주변을 스캔해 지도를 그리고(SLAM), 그 지도 위에서 목적지까지의 경로를 계산하며(경로 계획), 이동 중 예상치 못한 장애물(사람, 지게차, 떨어진 상자)을 만나면 실시간으로 우회 경로를 다시 계산합니다.

이 차이는 단순한 기술적 디테일이 아니라 운영 모델 자체를 바꿉니다. AGV는 레이아웃이 바뀔 때마다 물리적 인프라 재설치가 필요하지만, AMR은 소프트웨어의 지도 데이터만 갱신하면 됩니다. 그래서 최근 물류센터들이 AGV에서 AMR로 전환하거나, 두 방식을 혼용하는 하이브리드 플릿을 운영하는 경우가 늘고 있습니다.

1.3 AMR vs AGV vs 산업용 로봇 팔 — 세 축으로 정리하는 비교

신입 엔지니어가 가장 헷갈려 하는 지점 중 하나는 “로봇”이라는 단어 아래 서로 완전히 다른 세 가지 시스템이 뭉뚱그려진다는 점입니다.

구분	AGV	AMR	산업용 로봇 팔
이동 방식	고정 경로(자기 테이프/유도선)	자유 항법(SLAM 기반 지도)	대개 고정 위치, 이동하지 않음
환경 변화 대응	인프라 재설치 필요	소프트웨어 지도 갱신만으로 대응	해당 없음(작업 반경 내 정밀 제어)
핵심 소프트웨어	라인 추종 제어, 정지/신호 로직	SLAM, 경로 계획, 센서 퓨전	역기구학(inverse kinematics), 궤적 제어
대표 용도	반복적인 정형 운송(창고 내 고정 루트)	유동적인 피킹, 배송, 순찰	조립, 용접, 팔레타이징 등 정밀 작업
안전 개념	고정 경로 기반 접근 제한 구역	동적 장애물 회피 + 안전 인증 센서	협동로봇(cobot)이 아니면 펜스/라이트커튼 격리

산업용 로봇 팔은 “이동”이 아니라 “정밀한 자세 제어”가 핵심이라는 점에서 AMR·AGV와 완전히 다른 문제를 풉니다. 반면 AGV와 AMR은 둘 다 “바닥 위를 이동한다”는 공통점 때문에 자주 혼동되지만, 경로가 미리 정해져 있는가(AGV) 아니면 실시간으로 계산되는가(AMR) 가 두 시스템을 가르는 결정적인 기준입니다.

---

2. AMR 소프트웨어 파이프라인 — 인지에서 모션 제어까지

AMR의 소프트웨어 스택은 흔히 하나의 거대한 “자율주행 알고리즘”으로 오해받지만, 실제로는 각자 명확한 입력과 출력을 가진 여러 단계의 파이프라인으로 구성됩니다. 이 파이프라인 구조를 이해하면 이후 코드베이스에서 어떤 모듈이 어떤 역할을 하는지 훨씬 빠르게 파악할 수 있습니다.

[센서 원시 데이터]
      ↓
  1. 인지(Perception)      — 센서 데이터를 의미 있는 객체/특징으로 변환
      ↓
  2. 측위(Localization)    — "나는 지도 위 어디에 있는가?"
      ↓                         (지도작성과 상호 의존 — SLAM)
  2. 지도작성(Mapping)      — "주변 환경은 어떻게 생겼는가?"
      ↓
  3. 경로 계획(Path Planning) — "목적지까지 어떻게 갈 것인가?"
      ↓
  4. 모션 제어(Motion Control) — "계획한 경로를 실제 바퀴 명령으로 변환"
      ↓
  5. 장애물 회피(Obstacle Avoidance) — 이동 중 실시간 안전 보정
      ↓
  [바퀴 모터 구동 명령]

2.1 인지(Perception): 센서 데이터를 의미로 바꾸기

인지 단계는 LiDAR의 포인트 클라우드, 카메라의 픽셀 배열처럼 의미 없는 숫자 덩어리를 “여기 사람이 서 있다”, “저기 박스가 놓여 있다” 같은 의미 있는 정보로 바꾸는 단계입니다. 딥러닝 기반 객체 탐지(YOLO 계열 등)가 카메라 인지에 널리 쓰이고, LiDAR 포인트 클라우드는 클러스터링으로 장애물 덩어리를 분리하는 방식이 흔히 쓰입니다.

인지 단계의 출력은 다음 단계인 측위와 지도작성, 그리고 장애물 회피 두 곳 모두에 공급됩니다. 같은 센서 데이터라도 “이것이 고정된 벽인가, 움직이는 사람인가”를 구분하는 일은 인지 단계의 몫이며, 이 구분이 잘못되면 이후 경로 계획이 엉뚱한 결정을 내리게 됩니다.

2.2 측위와 지도작성: SLAM으로 묶이는 두 문제

측위(Localization)는 “로봇이 지도 위 어디에 있는가”를 추정하는 문제이고, 지도작성(Mapping)은 “환경이 어떻게 생겼는가”를 추정하는 문제입니다. 이 둘은 별개의 문제처럼 보이지만 실제로는 강하게 얽혀 있으며, 이 상호 의존성이 바로 SLAM이라는 별도의 절(3장)로 다룰 만큼 중요한 이유입니다.

2.3 경로 계획(Path Planning): 전역과 지역의 역할 분담

경로 계획은 다시 전역 계획(Global Planning) 과 지역 계획(Local Planning) 으로 나뉩니다. 전역 계획은 현재 위치에서 목적지까지 지도 전체를 놓고 “대략 어느 길로 갈 것인가”를 한 번에 계산합니다. 지역 계획은 그 경로를 따라가면서 수백 밀리초 단위로 “바로 앞의 장애물을 어떻게 피할 것인가”를 반복적으로 재계산합니다. 이 둘의 관계는 4장에서 자세히 다룹니다.

2.4 모션 제어(Motion Control): 계획을 실제 명령으로

경로 계획이 만들어낸 것은 “이 궤적을 따라가라”는 기하학적 정보일 뿐, 실제 모터를 구동하는 명령은 아닙니다. 모션 제어 단계는 이 궤적을 선속도(linear velocity)와 각속도(angular velocity) 같은 실제 구동 명령으로 변환합니다. 차동 구동(differential drive) 방식의 AMR이라면 좌우 바퀴의 회전 속도 차이로 회전을 만들어내는데, 이 변환 과정에서 로봇의 물리적 제약(최대 가속도, 최소 회전 반경 등)을 반영해야 실제로 실행 가능한 명령이 나옵니다.

2.5 장애물 회피(Obstacle Avoidance): 마지막 안전판

아무리 정교한 경로 계획도 갑자기 튀어나온 사람이나 예상치 못한 장애물까지 미리 예측할 수는 없습니다. 장애물 회피는 파이프라인의 마지막 단계에서, 지역 계획과 거의 통합된 형태로 동작하며 초당 수십 번씩 센서 데이터를 다시 확인하고 필요하면 즉시 감속하거나 정지 명령을 내립니다. 안전과 직결되는 만큼, 이 계층은 흔히 다른 계층보다 낮은 지연시간과 높은 신뢰성 요구사항을 가집니다.

---

3. SLAM — 지도와 위치를 동시에 푸는 문제

3.1 닭이 먼저냐 달걀이 먼저냐 문제

SLAM(Simultaneous Localization and Mapping, 동시 위치추정 및 지도작성) 이 왜 별도로 다뤄질 만큼 중요한 문제인지는, 이름 그대로의 역설에서 출발합니다.

• 로봇이 자기 위치를 알려면 지도가 있어야 합니다. (지도 위 좌표와 센서로 관측한 특징을 대조해야 위치를 알 수 있으므로.)
• 그런데 지도를 만들려면 각 관측을 어디서 했는지, 즉 위치를 알아야 합니다. (위치를 모르면 관측된 특징들을 지도 위 어디에 이어 붙일지 알 수 없으므로.)

이 순환 의존성이 SLAM을 “지도작성”이나 “측위” 각각보다 훨씬 어려운 문제로 만듭니다. SLAM은 이 둘을 동시에, 점진적으로 추정해 나가는 방법론입니다. 로봇이 이동하며 센서로 주변을 관측하면, 그 관측 결과를 이용해 “지금까지의 지도”와 “지금까지의 위치 추정”을 함께 갱신하고, 이 과정을 반복하며 점점 더 정확한 지도와 위치를 수렴시켜 나갑니다.

3.2 LiDAR 기반 SLAM vs 비주얼 SLAM

SLAM을 구현하는 방식은 크게 어떤 센서를 주력으로 쓰는지에 따라 나뉩니다.

LiDAR 기반 SLAM은 레이저 거리 센서로 얻은 포인트 클라우드를 이용해 지도를 그립니다. 실내 물류창고처럼 조명 변화가 적고 벽·선반 같은 구조물이 뚜렷한 환경에서 특히 안정적입니다. 대표적인 알고리즘으로는 Gmapping, Cartographer, slam_toolbox 등이 있으며, 결과물은 흔히 점유 격자 지도(Occupancy Grid Map) — 공간을 작은 격자로 나누고 각 칸이 “비어 있음/차 있음/미확인” 중 무엇인지 표시하는 2D 지도 — 형태로 저장됩니다.

비주얼 SLAM(Visual SLAM, VSLAM)은 카메라 영상에서 추출한 특징점(코너, 엣지 등)을 이용해 지도를 그립니다. LiDAR보다 저렴한 센서로 구현할 수 있고, 색상·질감 정보를 담은 더 풍부한 지도를 만들 수 있다는 장점이 있지만, 조명 변화나 텍스처가 부족한 환경(흰 벽만 있는 복도 등)에서는 특징점을 찾기 어려워 정확도가 떨어지는 약점이 있습니다. ORB-SLAM 계열이 대표적인 비주얼 SLAM 알고리즘입니다.

실무에서는 두 방식 중 하나만 쓰기보다, LiDAR를 주 센서로 쓰고 카메라를 보조 인지(사람/장애물 인식, 시각적 랜드마크 보정)에 활용하는 조합이 흔합니다. 비용, 환경 특성, 요구 정확도에 따라 조합 비율이 달라집니다.

3.3 SLAM 두 단계로 이해하기

SLAM의 내부 동작을 아주 단순화하면 다음 두 단계의 반복으로 볼 수 있습니다.

반복(로봇이 이동할 때마다):
  1. 예측(Prediction)
     - 이전 위치 추정치 + 오도메트리(바퀴 회전량 등)로
       "대략 여기쯤 있을 것이다"를 예측
  2. 보정(Correction/Update)
     - 현재 센서 관측(LiDAR 스캔 등)을 지도와 비교
     - 예측 위치와 실제 관측이 얼마나 잘 맞는지 계산해
       위치 추정치를 보정
     - 새로 관측된 영역을 지도에 반영

이 예측-보정 반복 구조는 뒤에서 다룰 칼만 필터, 파티클 필터와 본질적으로 같은 패턴입니다. SLAM은 이 반복을 지도 전체에 대해, 그리고 지도와 위치 두 가지를 함께 추정하도록 확장한 것이라고 이해하면 됩니다.

---

4. AMR의 눈과 귀 — 센서와 센서 퓨전

4.1 대표 센서와 각각의 강점/약점

센서	강점	약점	주 용도
LiDAR	정확한 거리 측정, 조명 무관, 넓은 시야각	유리·검은 물체 인식 취약, 상대적으로 고가	SLAM, 장애물 회피
IMU(관성 측정 장치)	매우 빠른 갱신 주기, 급격한 자세 변화 감지	시간이 지날수록 누적 오차(드리프트) 발생	단기 자세·가속도 추정
휠 인코더(오도메트리)	저렴, 계산 간단, 실내 어디서나 동작	바퀴 미끄러짐·마모로 장거리 누적 오차 발생	단거리 이동량 추정
깊이/RGB-D 카메라	색상·질감 정보, 상대적으로 저렴	조명 변화에 민감, 야외 직사광선에 취약	객체 인식, 비주얼 SLAM
초음파 센서	저렴, 투명한 물체(유리)도 감지 가능	측정 거리 짧고 정확도 낮음	근거리 충돌 방지 보조

4.2 왜 센서 하나로는 부족한가 — 센서 퓨전과 칼만 필터

위 표를 보면 알 수 있듯, 완벽한 센서는 존재하지 않습니다. LiDAR는 유리문을 통과해 버릴 수 있고, 카메라는 창고 조명이 바뀌는 순간 특징점을 놓칠 수 있으며, 휠 인코더는 바퀴가 살짝 미끄러지는 것만으로도 위치 추정이 어긋나기 시작합니다. 특히 오도메트리(바퀴 회전 수로 이동 거리를 추정하는 데드 레커닝(Dead Reckoning) 방식)는 한 번의 오차가 다음 추정에 그대로 누적되는 구조이기 때문에, 시간이 지날수록 실제 위치와 점점 벌어지는 드리프트(drift) 문제를 피할 수 없습니다.

이 문제를 해결하는 표준적인 방법이 센서 퓨전(Sensor Fusion) 입니다. 서로 다른 센서의 데이터를 하나의 추정치로 통합해서, 한 센서의 약점을 다른 센서의 강점으로 보완하는 방식입니다. 가장 널리 쓰이는 수학적 도구가 칼만 필터(Kalman Filter), 그리고 비선형 시스템에 맞게 확장한 확장 칼만 필터(EKF, Extended Kalman Filter) 입니다.

칼만 필터의 핵심 아이디어는 SLAM에서 본 예측-보정 구조와 동일합니다.

1. 예측: IMU와 오도메트리로 “다음 순간 로봇이 어디에 있을지” 빠르게 예측합니다.
2. 보정: LiDAR나 카메라 같은, 상대적으로 느리지만 더 정확한 센서의 관측치로 예측을 보정합니다.
3. 이때 각 센서의 신뢰도(불확실성) 를 가중치로 반영해서, 더 신뢰할 수 있는 센서의 관측에 더 큰 비중을 둡니다.

실무에서는 robot_localization 같은 ROS2 패키지가 이 EKF 融합 과정을 표준화된 형태로 제공하며, 엔지니어는 어떤 센서를 어떤 신뢰도로 섞을지 설정 파일로 튜닝하는 방식으로 작업하는 경우가 많습니다. 즉, 칼만 필터의 수식을 직접 구현할 일은 드물지만, “왜 위치 추정값이 튀는가”를 디버깅하려면 이 예측-보정 구조와 각 센서의 신뢰도 개념을 이해하고 있어야 합니다.

4.3 파티클 필터(Monte Carlo Localization)

칼만 필터가 위치 추정을 하나의 확률 분포(주로 정규분포)로 표현한다면, 파티클 필터(Particle Filter), 흔히 몬테카를로 측위(Monte Carlo Localization, MCL) 라 불리는 방식은 위치 추정을 수백~수천 개의 가상 위치 후보(파티클) 로 표현합니다. 각 파티클은 “로봇이 여기 있을 수도 있다”는 하나의 가설이며, 로봇이 이동하고 센서로 관측할 때마다 실제 관측과 더 잘 맞는 파티클은 살아남고(가중치가 커지고), 맞지 않는 파티클은 도태됩니다.

이 방식은 로봇 위치가 여러 후보로 갈릴 수 있는 상황(예: 대칭적인 복도 구조에서 어느 쪽 복도에 있는지 처음엔 확신할 수 없는 경우)을 자연스럽게 표현할 수 있다는 장점이 있어, 이미 만들어진 지도 위에서 로봇의 초기 위치를 찾거나 위치를 지속적으로 추정하는 데 널리 쓰입니다. ROS2의 Nav2 스택에서 기본으로 제공하는 AMCL(Adaptive Monte Carlo Localization) 노드가 이 방식의 대표적인 구현체입니다.

---

5. 경로 계획 — 전역 계획과 지역 계획

5.1 전역 계획: 지도 전체에서 최단 경로 찾기

전역 경로 계획은 완성된 지도 위에서 시작점부터 목적지까지의 경로를 한 번에 계산하는 문제로, 본질적으로 그래프 탐색 문제입니다. 지도를 격자나 노드-엣지 그래프로 표현하면, 컴퓨터공학에서 익숙한 최단 경로 알고리즘을 그대로 적용할 수 있습니다.

• Dijkstra 알고리즘: 시작점에서 모든 지점까지의 최단 거리를 보장하며 탐색하지만, 목적지 방향에 대한 정보 없이 사방으로 탐색을 넓혀가기 때문에 비교적 느립니다.
• A* 알고리즘: Dijkstra에 “목적지까지 남은 거리를 대략 추정하는” 휴리스틱을 더해, 목적지 방향으로 탐색을 집중시켜 훨씬 빠르게 최단 경로에 가까운 결과를 찾습니다. 실무 AMR 전역 계획기에서 가장 흔히 쓰이는 알고리즘입니다.

A* 알고리즘의 동작을 의사코드로 단순화하면 다음과 같습니다.

함수 A_STAR(시작, 목적지, 지도):
    open_set = {시작}                  # 아직 탐색하지 않은 후보 노드
    g_cost[시작] = 0                   # 시작점에서 이 노드까지의 실제 비용
    f_cost[시작] = 휴리스틱(시작, 목적지)  # 예상 총 비용(실제+추정)

    반복 open_set이 비어있지 않은 동안:
        현재 = open_set에서 f_cost가 가장 작은 노드
        만약 현재 == 목적지:
            경로 재구성 후 반환

        open_set에서 현재 제거
        각 이웃 in 현재의 인접 노드(지도 상 이동 가능한 칸):
            새_g = g_cost[현재] + 이동비용(현재, 이웃)
            만약 새_g < g_cost.get(이웃, 무한대):
                g_cost[이웃] = 새_g
                f_cost[이웃] = 새_g + 휴리스틱(이웃, 목적지)
                open_set에 이웃 추가

    반환 실패  # 경로 없음

여기서 휴리스틱 함수는 흔히 직선 거리나 격자 맨해튼 거리를 사용합니다. 이 값이 실제 남은 거리를 과대평가하지 않는 한(admissible heuristic), A*는 항상 최적 경로를 찾는다는 성질이 있어 경로 계획기의 기본값으로 널리 채택됩니다.

5.2 지역 계획: 코스트맵 위에서 실시간으로 장애물 피하기

전역 계획이 만든 경로는 “정적인 지도” 기준의 경로일 뿐, 실행 시점에 갑자기 나타난 사람이나 지게차까지 반영하지는 못합니다. 이 간극을 메우는 것이 지역 계획(Local Planning) 이며, 여기서 핵심 데이터 구조가 코스트맵(Costmap) 입니다.

코스트맵은 지도를 격자로 나누고, 각 칸에 “이 칸을 지나가는 것이 얼마나 위험/비용이 큰가”를 값으로 저장한 지도입니다. 정적 장애물(벽, 선반)뿐 아니라 실시간 센서로 감지한 동적 장애물(사람, 다른 로봇)까지 반영해서, 장애물 근처일수록 높은 비용이, 장애물에서 멀수록 낮은 비용이 매겨집니다. 지역 계획기는 이 코스트맵 위에서 “다음 짧은 구간을 어떻게 움직여야 가장 안전하고 효율적인가”를 초당 수 회~수십 회 반복해서 재계산합니다.

지역 계획 알고리즘 중 대표적인 것이 DWA(Dynamic Window Approach) 입니다. DWA는 로봇이 짧은 시간 동안 낼 수 있는 여러 속도 조합(선속도, 각속도)을 후보로 시뮬레이션해보고, 각 후보가 “코스트맵상 안전한가”, “목표 방향에 가까운가”, “로봇의 가속도 한계 안에서 실행 가능한가”를 종합 점수로 매겨 가장 좋은 속도 명령을 선택하는 방식입니다. “동적 윈도우”라는 이름은 로봇의 물리적 가감속 한계 때문에 다음 순간 낼 수 있는 속도 범위가 제한된다는 점에서 따온 것입니다.

정리하면, 전역 계획은 “큰 그림에서 어디로 갈지”를, 지역 계획은 “지금 당장 어떻게 움직일지”를 담당하며, 이 둘이 계층적으로 협력해서 하나의 자연스러운 이동을 만들어냅니다. 신입 엔지니어가 로그에서 로봇이 이상하게 멈칫거리는 모습을 볼 때, 전역 경로 자체의 문제인지 지역 계획기의 순간적인 판단 문제인지를 구분하는 것이 트러블슈팅의 첫걸음입니다.

---

6. ROS2 — 왜 이 미들웨어를 모르고는 코드베이스를 읽기 어려운가

6.1 ROS2가 푸는 문제: 수십 개 모듈을 어떻게 통신시킬 것인가

지금까지 설명한 인지, 측위, 지도작성, 경로 계획, 모션 제어는 실제로는 서로 독립적으로 실행되는 여러 개의 프로세스(노드) 로 구현되는 경우가 대부분입니다. 이 노드들이 서로 데이터를 주고받으려면 통신 방식이 필요한데, 매번 직접 소켓을 구현하는 대신 이 문제를 표준화한 것이 ROS(Robot Operating System), 그리고 그 후속 버전인 ROS2입니다.

이름과 달리 ROS는 운영체제가 아니라, 로봇 소프트웨어를 위한 미들웨어이자 개발 프레임워크에 가깝습니다. ROS2는 이전 버전인 ROS1의 한계(단일 마스터 노드에 대한 의존, 실시간성 부족, 산업 현장 보안 요구 미흡)를 개선해 DDS(Data Distribution Service)라는 산업 표준 통신 프로토콜 위에서 동작하도록 재설계되었으며, 현재 신규 AMR 프로젝트에서는 사실상 기본 선택지로 자리잡았습니다.

6.2 노드, 토픽, 발행/구독(pub/sub) 모델

ROS2를 이해하는 데 필요한 최소한의 개념은 다음 세 가지입니다.

• 노드(Node): 하나의 독립된 프로세스입니다. LiDAR 드라이버 노드, SLAM 노드, 경로 계획 노드, 모션 제어 노드가 각각 별도의 노드로 실행되며, 노드 하나가 죽어도 나머지 노드에 곧바로 영향을 주지 않도록 격리됩니다.
• 토픽(Topic): 노드 간에 데이터를 주고받는 이름 붙은 채널입니다. 예를 들어 LiDAR 노드는 /scan이라는 토픽에 센서 데이터를 계속 발행(publish) 하고, SLAM 노드는 같은 /scan 토픽을 구독(subscribe) 해서 데이터를 받습니다.
• 발행/구독(Pub/Sub) 모델: 발행자와 구독자는 서로의 존재를 직접 알 필요가 없습니다. 발행자는 그저 토픽에 데이터를 내보내고, 구독자는 관심 있는 토픽을 듣기만 하면 됩니다. 이 느슨한 결합(loose coupling) 덕분에 노드를 추가·교체·재시작해도 나머지 시스템에 미치는 영향이 최소화됩니다.

간단한 예로, LiDAR 데이터를 구독해서 가장 가까운 장애물까지의 거리를 로그로 출력하는 Python 노드는 다음과 같은 형태를 띱니다.

import rclpy
from rclpy.node import Node
from sensor_msgs.msg import LaserScan

class ClosestObstacleLogger(Node):
    def __init__(self):
        super().__init__('closest_obstacle_logger')
        # '/scan' 토픽을 구독하고, 메시지가 올 때마다 콜백 실행
        self.subscription = self.create_subscription(
            LaserScan,
            '/scan',
            self.scan_callback,
            10  # QoS 큐 depth
        )

    def scan_callback(self, msg: LaserScan):
        # ranges 배열에서 유효한 최소 거리값 찾기
        valid_ranges = [r for r in msg.ranges if r > msg.range_min]
        if valid_ranges:
            closest = min(valid_ranges)
            self.get_logger().info(f'가장 가까운 장애물까지 거리: {closest:.2f}m')

def main():
    rclpy.init()
    node = ClosestObstacleLogger()
    rclpy.spin(node)  # 콜백을 기다리며 계속 실행
    node.destroy_node()
    rclpy.shutdown()

이 코드에서 눈여겨볼 부분은 create_subscription 호출입니다. 메시지 타입(LaserScan), 토픽 이름(/scan), 콜백 함수, 그리고 QoS(Quality of Service) 큐 depth만 지정하면, 이후 LiDAR 드라이버 노드가 언제 어떤 속도로 데이터를 보내든 이 노드는 알아서 콜백을 통해 데이터를 받습니다. 실제로 LiDAR 노드가 C++로 구현되어 있어도, 이 Python 노드는 아무 문제 없이 데이터를 주고받을 수 있습니다 — ROS2가 언어 간 통신까지 표준화하고 있기 때문입니다.

6.3 소프트웨어 엔지니어에게 ROS2가 의미하는 것

전체 ROS2 튜토리얼을 따라 할 필요는 없더라도, 코드베이스나 배포 로그에서 다음과 같은 사실을 읽어낼 수 있으면 실무에서 크게 도움이 됩니다.

• 노드 하나가 크래시했다고 전체 로봇이 멈추는 것은 아니며, 어떤 노드가 어떤 토픽을 구독/발행하는지를 보면 장애 파급 범위를 가늠할 수 있습니다.
• ros2 topic echo /scan, ros2 node list 같은 CLI 명령으로 실시간 데이터 흐름을 확인하는 것이 로그 파일을 뒤지는 것보다 훨씬 빠른 디버깅 방법인 경우가 많습니다.
• Nav2(ROS2의 표준 내비게이션 스택)는 앞서 설명한 전역 계획, 지역 계획, 코스트맵, AMCL 측위를 이미 표준 노드 구성으로 제공하므로, 많은 AMR 프로젝트가 이를 바닥부터 구현하지 않고 Nav2 위에서 파라미터 튜닝과 커스텀 플러그인 작성으로 시작합니다.

---

7. 실전 배포에서 마주치는 문제들

7.1 플릿 관리: 여러 대의 AMR을 어떻게 조율할 것인가

로봇 한 대만 다룰 때는 신경 쓰지 않아도 되는 문제들이, 수십~수백 대의 AMR을 운영하는 순간 전면에 등장합니다. 플릿 관리(Fleet Management) 시스템은 여러 로봇의 위치, 배터리 상태, 작업 큐를 중앙에서 파악하고 작업을 배분하는 역할을 합니다.

가장 흔히 발생하는 문제가 교차로 충돌 회피(traffic control) 입니다. 각 로봇이 독립적으로 지역 계획만 수행하면, 좁은 통로에서 두 로봇이 서로를 피하려다 오히려 교착 상태(deadlock)에 빠지는 경우가 생깁니다. 이를 막기 위해 플릿 관리 시스템은 특정 구간을 “예약(reservation)” 방식으로 관리해서, 한 번에 하나의 로봇만 진입을 허용하거나, 우선순위 규칙(먼저 도착한 로봇 우선, 배터리가 적은 로봇 우선 등)으로 교차로 통행을 중재합니다. 서로 다른 제조사의 AMR을 함께 운영해야 하는 환경에서는 이 조율을 표준화하기 위해 VDA5050 같은 로봇-플릿 통신 프로토콜이 쓰이기도 합니다.

7.2 WMS 연동: 로봇은 결국 창고 시스템의 일부다

AMR은 그 자체로 독립된 시스템이 아니라, 대부분 WMS(Warehouse Management System, 창고 관리 시스템) 의 지시를 받아 움직이는 하나의 실행 계층입니다. WMS가 “B구역 선반에서 상품을 픽업해 C구역 포장대로 옮겨라”는 작업을 API로 내려보내면, 플릿 관리 시스템이 이 작업을 특정 로봇에게 배정하고, 로봇은 이를 실제 이동·픽업 동작으로 실행합니다. 이 연동은 흔히 REST API나 메시지 큐(MQTT, RabbitMQ 등)를 통해 이루어지며, 백엔드 엔지니어가 AMR 도메인에 합류했을 때 가장 먼저 맡게 되는 영역이 바로 이 WMS-플릿 관리 API 연동 계층인 경우가 많습니다.

7.3 안전 표준: 로봇은 결국 사람과 같은 공간에 있다

AMR은 사람이 일하는 공간을 함께 돌아다니기 때문에, 성능만큼이나 안전 인증이 중요합니다. 대표적으로 국제 표준 IEC 61508과 산업용 이동 로봇에 특화된 ISO 3691-4 같은 규격이 요구하는 안전 등급 LiDAR(Safety-rated LiDAR) 는 일반 항법용 LiDAR와 별도로 장착되어, 정의된 감지 구역 안에 장애물이 들어오면 하드웨어 레벨에서 즉시 감속·정지 신호를 발생시킵니다. 이 신호는 일반 소프트웨어 스택(인지, 장애물 회피 등)과 독립적으로 동작하도록 설계되는 경우가 많은데, 소프트웨어에 버그가 있어도 최소한의 안전을 보장하기 위한 이중 안전장치 개념입니다.

또한 대부분의 AMR은 물리적인 비상 정지 버튼(E-Stop) 을 갖추고 있으며, 소프트웨어 장애나 통신 두절 시 자동으로 정지하는 워치독(watchdog) 타이머 로직도 표준적으로 구현됩니다. 소프트웨어 엔지니어 입장에서는 “내가 만드는 기능이 이 안전 계층을 절대 우회해서는 안 된다”는 원칙을 처음부터 인지하고 설계하는 것이 중요합니다.

---

8. 마치며 — 다음 학습 단계

이 글에서 다룬 개념들은 서로 독립적이지 않고 하나의 파이프라인으로 연결되어 있습니다. 인지가 만든 정보 위에서 SLAM이 지도와 위치를 동시에 추정하고, 그 지도 위에서 전역 계획(A)* 이 큰 경로를 그리면, 지역 계획(DWA) 이 코스트맵을 보며 실시간으로 세부 동작을 조정하고, 이 모든 결과가 모션 제어를 거쳐 실제 바퀴 명령으로 나갑니다. 이 전체가 ROS2라는 통신 프레임워크 위에서 여러 노드로 나뉘어 동작하며, 실제 현장에서는 여기에 플릿 관리, WMS 연동, 안전 인증이라는 운영 계층이 추가로 얹힙니다.

처음 이 도메인에 합류하는 소프트웨어 엔지니어에게 권하고 싶은 다음 단계는, ROS2와 Nav2를 시뮬레이터(Gazebo, turtlebot3 등)로 직접 띄워보며 /scan, /odom, /cmd_vel 같은 토픽에 실제로 어떤 데이터가 흐르는지 눈으로 확인해보는 것입니다. 개념을 아는 것과, 로그와 토픽 데이터를 직접 들여다보며 “지금 로봇이 왜 이렇게 움직였는가”를 추론할 수 있는 것 사이에는 꽤 큰 간극이 있으며, 그 간극은 결국 직접 돌려보는 경험으로만 메울 수 있습니다.