책에 포함된 노트처음 만나는 로봇공학: 로봇은 어떻게 보고, 생각하고, 움직이는가

AI 로봇 중심 학습 루트

2026-05-14Views 90약 11분생성형 AI 활용

Summary

AI를 공부하다가 로봇으로 넘어오면 처음에는 이상한 느낌을 받는다. 컴퓨터 비전 모델을 학습시켰고, PyTorch로 추론도 할 수 있고, LLM API도 다뤄 봤는데 막상 로봇에 연결하려고 하면 갑자기 질문이 달라진다.

"정확도가 몇 퍼센트인가?"보다 먼저 "카메라 영상이 어디에서 들어오는가?"를 물어야 한다. "모델이 컵을 찾았는가?"보다 "그 컵의 위치를 로봇 좌표계에서 어떻게 표현할 것인가?"가 중요해진다. "LLM이 그럴듯한 계획을 말했는가?"보다 "그 계획을 안전하게 실행할 수 있는 실제 로봇 스킬이 있는가?"가 더 중요해진다.

AI 로봇 학습은 인공지능 모델을 하나 더 배우는 과정이 아니다. AI의 출력을 로봇의 조건문, 좌표, 명령, 피드백 루프에 연결하는 과정이다. 이 장에서는 AI를 공부한 독자가 로봇으로 확장할 때 어떤 순서로 OpenCV, PyTorch, 강화학습, 모방학습, LLM 계획을 연결하면 좋은지 살펴본다.

AI 로봇 중심 학습 루트

AI 로봇은 모델이 아니라 흐름으로 이해해야 한다

AI 로봇을 처음 만들 때 많은 사람이 "좋은 모델을 붙이면 똑똑한 로봇이 되겠지"라고 생각한다. 하지만 실제 로봇 시스템은 그렇게 단순하지 않다. 로봇은 카메라 한 장을 보고 끝나는 프로그램이 아니라, 계속 들어오는 센서 데이터 속에서 판단하고 움직이며 다시 관측하는 시스템이다.

예를 들어 카메라가 책상 위의 빨간 공을 본다고 해 보자. AI 프로그램이라면 "빨간 공이 있다"는 결과만으로도 충분할 수 있다. 하지만 로봇에게는 그다음 질문이 따라온다. 공이 화면의 왼쪽에 있는가, 오른쪽에 있는가? 가까운가, 먼가? 로봇이 회전해야 하는가, 앞으로 가야 하는가? 너무 가까워서 멈춰야 하는가? 이처럼 인식 결과는 곧바로 행동 조건으로 바뀌어야 한다.

AI 로봇의 기본 흐름은 다음처럼 볼 수 있다.

인식: 카메라, LiDAR, 마이크, 힘 센서 등에서 의미 있는 정보를 뽑는다.
판단: 인식 결과와 현재 목표를 비교해 다음 행동을 고른다.
제어: 바퀴, 로봇팔, 그리퍼 같은 액추에이터에 명령을 보낸다.
피드백: 행동 결과를 다시 센서로 확인하고 계획을 수정한다.

이 구조를 잊지 않으면 AI 기술을 어디에 붙여야 하는지 훨씬 분명해진다. OpenCV는 주로 인식의 가장 앞단에서 카메라 영상을 다룬다. PyTorch는 물체 인식, 자세 추정, 장면 이해 같은 더 복잡한 인식 모델을 실행한다. 강화학습과 모방학습은 특정 상황에서 어떤 행동을 할지 배우는 데 쓰인다. LLM은 사용자의 자연어 명령을 작업 단계로 나누고, 이미 준비된 로봇 스킬을 호출하는 계획자 역할을 맡을 수 있다.

중요한 점은 이 모든 것이 따로 놀면 안 된다는 것이다. AI 로봇 학습의 목표는 "OpenCV를 배웠다", "PyTorch를 배웠다", "LLM을 붙였다"가 아니다. 최종 목표는 인식 노드 → 판단 노드 → 제어 노드로 이어지는 로봇 소프트웨어 구조를 만드는 것이다.

첫 출발은 OpenCV: 화면을 띄우는 것에서 끝내지 말자

AI 로봇 학습의 첫 단계로 OpenCV를 추천하는 이유는 단순하다. 로봇에게 카메라는 가장 다루기 쉬우면서도 가장 강력한 센서 중 하나이기 때문이다. OpenCV는 카메라 영상을 읽고, 색을 바꾸고, 윤곽선을 찾고, 특징점을 검출하고, 화면 위의 좌표를 계산하는 데 널리 쓰이는 컴퓨터 비전 라이브러리다.

하지만 여기서 조심해야 할 점이 있다. OpenCV 입문은 자칫 "웹캠 영상을 띄워 보았다"에서 멈추기 쉽다. 로봇공학 관점에서는 거기서 한 걸음 더 가야 한다. 화면을 보는 것이 아니라, 화면 속 정보를 로봇의 행동 조건으로 바꾸는 연습을 해야 한다.

가장 좋은 첫 프로젝트는 색상 기반 물체 추적이다. 예를 들어 노란 공을 따라가는 작은 바퀴 로봇을 생각해 보자. 처음에는 카메라 영상을 띄운다. 그다음 RGB 이미지를 HSV 색 공간으로 바꾼다. HSV는 색상, 채도, 밝기를 나눠 표현하는 방식이라 특정 색을 분리하기 쉽다. 노란색 범위만 남기고 나머지는 검은색으로 지운다. 그 결과에서 윤곽선을 찾고, 가장 큰 윤곽선의 중심 좌표를 구한다.

여기까지 하면 단순한 영상 처리처럼 보인다. 하지만 로봇에게는 이미 충분한 판단 재료가 생긴다.

공의 중심이 화면 왼쪽에 있다  → 왼쪽으로 회전
공의 중심이 화면 중앙에 있다  → 앞으로 이동
공의 크기가 너무 커졌다        → 가까우므로 정지

이것이 OpenCV를 로봇답게 배우는 방식이다. 물체 이름을 맞히는 것보다 먼저, 영상에서 얻은 숫자를 로봇의 조건문으로 연결해야 한다.

ROS2와 함께 사용할 때는 카메라 영상도 하나의 메시지로 흐른다. 흔히 카메라 노드가 이미지 토픽을 발행하고, 비전 노드가 그 토픽을 구독해 OpenCV 이미지로 변환한 뒤 처리한다. ROS2에서 OpenCV 이미지를 ROS 이미지 메시지와 주고받기 위해 cv_bridge 같은 도구를 사용하며, 웹캠 영상을 퍼블리셔와 서브스크라이버 노드로 나누어 다루는 기본 예제도 이런 구조를 따른다.¹

처음에는 다음 네 가지를 순서대로 익히면 좋다.

카메라 프레임 읽기와 이미지 토픽 구독
색상 분할, 이진화, 윤곽선 검출
물체 중심 좌표와 크기 추정
중심 좌표를 회전·전진·정지 명령으로 변환

여기서 핵심은 "정확한 인식"이 아니라 "행동 가능한 인식"이다. 로봇에게 필요한 인식 결과는 예쁜 시각화가 아니다. 왼쪽으로 돌지, 오른쪽으로 돌지, 멈출지, 집을지 결정할 수 있는 정보다.

OpenCV 프로젝트를 로봇 명령으로 연결하기

OpenCV 미니 프로젝트를 로봇공학 프로젝트로 바꾸려면 출력 형식을 바꿔야 한다. 일반적인 컴퓨터 비전 예제는 화면에 사각형을 그리고 imshow로 보여 주는 데서 끝난다. 그러나 로봇은 화면을 감상하지 않는다. 로봇은 메시지를 받아 움직인다.

예를 들어 비전 노드가 다음과 같은 정보를 만든다고 하자.

object_detected: true
center_x: 420
center_y: 260
area: 13500
confidence: 0.86

이제 판단 노드는 이 정보를 보고 명령을 만든다. 화면 폭이 640픽셀이라면 중앙은 대략 320픽셀이다. center_x가 420이면 물체가 오른쪽에 있으므로 로봇은 오른쪽으로 조금 회전한다. area가 너무 작으면 멀리 있다고 보고 앞으로 간다. area가 너무 크면 가까이 있다고 보고 멈춘다.

이 간단한 구조 안에 로봇 인공지능의 핵심이 들어 있다. 인식 모델의 출력은 곧바로 모터 명령이 되지 않는다. 중간에 판단 규칙이 있다. 이 판단 규칙이 나중에는 상태 기계가 되고, 행동 트리가 되고, 더 복잡한 작업 계획기가 된다.

초보 단계에서는 다음과 같은 프로젝트가 좋다.

색깔 공을 화면 중앙에 오도록 회전하는 로봇
특정 색 테이프를 따라가는 라인트레이서
손 모양이나 마커를 보고 정지·출발하는 카메라 로봇
화면 속 물체 중심을 따라 팬틸트 카메라를 움직이는 장치

이 프로젝트들은 화려하지 않지만 매우 중요하다. AI 로봇의 출발점은 거대한 모델이 아니라 "카메라 좌표 하나가 로봇 행동을 바꾸는 경험"이다. 이 경험이 있어야 나중에 PyTorch 모델이나 LLM을 붙여도 시스템이 무너지지 않는다.

PyTorch는 로봇의 눈을 더 똑똑하게 만든다

OpenCV만으로도 많은 일을 할 수 있지만, 색상이나 단순 윤곽선만으로는 한계가 있다. 조명이 바뀌면 색상 분할이 깨지고, 물체가 겹치면 윤곽선이 엉키고, 복잡한 장면에서는 규칙을 일일이 만들기 어렵다. 이때 PyTorch 기반 딥러닝 모델이 등장한다.

PyTorch는 딥러닝 모델을 만들고 학습하고 추론하는 데 널리 쓰이는 프레임워크다. 로봇에서는 주로 다음 작업에 사용된다.

물체 인식: 이미지 안에서 컵, 사람, 의자, 문 같은 물체를 찾는다.
자세 추정: 사람의 관절, 손의 위치, 물체의 방향을 추정한다.
장면 이해: 바닥, 벽, 장애물, 통로처럼 장면의 의미를 구분한다.
정책 학습: 관측을 입력받아 다음 행동을 출력하는 신경망을 학습한다.

예를 들어 YOLO 계열 물체 검출 모델을 쓰면 카메라 이미지에서 여러 물체의 바운딩 박스, 클래스 이름, 신뢰도를 얻을 수 있다. 바운딩 박스는 물체를 둘러싼 사각형이고, 신뢰도는 모델이 그 결과를 얼마나 확신하는지 나타내는 값이다. 여기까지는 일반적인 AI 프로젝트와 비슷하다.

하지만 로봇에서는 그다음이 중요하다. 바운딩 박스의 중심 픽셀을 구하고, 깊이 카메라가 있다면 그 픽셀의 거리 값을 읽는다. 그러면 물체가 카메라로부터 어느 방향, 어느 거리에 있는지 대략 추정할 수 있다. 이후 카메라 좌표계를 로봇 베이스 좌표계나 지도 좌표계로 변환하면, "화면 속 컵"이 "로봇 기준 앞쪽 1.2미터, 오른쪽 0.3미터에 있는 컵"으로 바뀐다. 실제 LLM 로봇 프로젝트에서도 YOLO의 바운딩 박스 중심과 깊이 정보를 이용해 물체의 실제 위치를 추정하고, 카메라 좌표계에서 월드 좌표계로 변환하는 방식을 사용한다.²

이 변환이 바로 AI 로봇에서 가장 중요한 연결 지점이다. 딥러닝 모델은 보통 이미지 좌표에서 답을 준다. 로봇은 물리 공간에서 움직인다. 따라서 모델 출력은 다음 세 단계를 거쳐야 한다.

의미 변환: class_id=39를 "병" 또는 "컵" 같은 사람이 이해할 수 있는 물체 이름으로 바꾼다.
공간 변환: 픽셀 좌표를 카메라 좌표, 로봇 좌표, 지도 좌표로 연결한다.
행동 변환: 물체 위치를 바라보기, 접근하기, 집기, 피하기 같은 행동 목표로 바꾼다.

PyTorch 모델을 로봇에 붙인다는 것은 단순히 model(image)를 실행하는 일이 아니다. 카메라 입력 형식, 이미지 전처리, 추론 시간, GPU 사용량, 결과 메시지 형식, 좌표 변환, ROS2 토픽 연결까지 함께 설계하는 일이다.

로봇에서 딥러닝 모델은 지연 시간과 싸운다

노트북에서 이미지 한 장을 넣고 모델을 실행할 때는 0.5초가 걸려도 큰 문제가 아닐 수 있다. 하지만 움직이는 로봇에서는 0.5초가 꽤 긴 시간이다. 로봇이 초당 0.5미터로 움직인다면 0.5초 동안 25센티미터를 간다. 그 사이 장애물이 가까워질 수도 있고, 사람이 지나갈 수도 있고, 로봇팔이 목표 위치를 지나칠 수도 있다.

그래서 로봇 딥러닝에서는 정확도뿐 아니라 지연 시간이 중요하다. 지연 시간은 입력이 들어온 순간부터 결과가 나올 때까지 걸리는 시간이다. 카메라 노출, 이미지 전송, 전처리, 모델 추론, 후처리, 메시지 발행까지 모두 지연에 포함된다.

로봇에서 PyTorch 모델을 사용할 때는 다음 질문을 습관처럼 던져야 한다.

모델은 초당 몇 프레임을 처리할 수 있는가?
추론 결과가 나올 때 로봇은 이미 얼마나 움직였는가?
오래된 인식 결과를 사용하고 있지는 않은가?
GPU가 없어도 실행 가능한가, 아니면 엣지 GPU가 필요한가?
추론 노드가 느려질 때 제어 노드까지 멈추지는 않는가?

엣지 컴퓨팅 보드, 예를 들어 NVIDIA Jetson 계열 장치에서는 ROS2와 딥러닝 추론을 함께 사용하는 사례가 많다. NVIDIA의 ROS2 관련 패키지들은 TensorRT, Triton, DeepStream 같은 도구를 통해 객체 검출, 분류, 자세 추정, AprilTag 검출 등을 ROS2 노드 형태로 실행할 수 있게 한다.³ TensorRT는 딥러닝 모델을 NVIDIA GPU에서 더 빠르게 실행하도록 최적화하는 도구라고 이해하면 된다.

입문 단계에서 반드시 TensorRT까지 깊게 배울 필요는 없다. 다만 "모델이 맞히는가?"만 보지 말고 "모델이 로봇이 쓸 수 있을 만큼 빨리, 안정적으로 결과를 내는가?"를 함께 봐야 한다. AI 로봇은 데모 영상 한 번으로 끝나는 프로그램이 아니라, 센서 스트림 속에서 계속 작동해야 하는 시스템이다.

ROS2로 인식, 판단, 제어를 분리하기

AI 로봇 프로젝트가 복잡해지는 순간은 대부분 한 파일에 모든 것을 넣었을 때 찾아온다. 카메라를 읽고, 모델을 실행하고, 조건문을 판단하고, 모터 명령을 보내고, 로그를 찍고, 에러 처리까지 한 코드 안에 넣으면 처음에는 빠르게 만들 수 있다. 그러나 조금만 커지면 수정하기 어려운 덩어리가 된다.

ROS2를 배우는 이유는 이 덩어리를 나누기 위해서다. ROS2에서는 기능을 노드로 나누고, 노드 사이에서 토픽, 서비스, 액션으로 데이터를 주고받는다. 토픽은 계속 흐르는 데이터에 적합하다. 카메라 영상, 로봇 위치, 속도 명령처럼 주기적으로 오가는 정보가 여기에 해당한다. 서비스는 요청과 응답이 있는 짧은 작업에 적합하고, 액션은 목적지까지 이동하기처럼 시간이 걸리고 중간 피드백이 필요한 작업에 적합하다. ROS2는 노드, 토픽, 서비스, 액션 같은 구조를 통해 로봇의 인식, 계획, 제어, 시뮬레이션을 연결하는 미들웨어 역할을 한다.⁴

AI 로봇에서는 다음처럼 나누는 습관이 중요하다.

카메라 노드
  → /camera/image_raw 발행

인식 노드
  → /detections 발행

판단 노드
  → /target_object 또는 /cmd_vel 발행

제어 노드
  → 모터 드라이버, Nav2, MoveIt2 등에 명령 전달

이렇게 나누면 장점이 많다. OpenCV 인식 노드를 PyTorch 인식 노드로 바꿔도 판단 노드는 그대로 둘 수 있다. 실제 카메라 대신 시뮬레이터 카메라를 연결해도 나머지 구조는 유지된다. 바퀴 로봇 대신 로봇팔을 붙일 때도 인식 결과 메시지를 재사용할 수 있다.

처음에는 작은 구조로 충분하다. 예를 들어 "사람을 보면 멈추는 로봇"을 만든다고 하자. 카메라 노드는 이미지를 발행한다. 인식 노드는 사람 검출 결과를 발행한다. 판단 노드는 사람과의 거리가 가까우면 정지 명령을 보낸다. 제어 노드는 실제 바퀴 속도를 조절한다. 이 구조를 만들 수 있다면 AI 로봇의 뼈대를 이해한 것이다.

중요한 것은 "모델 중심"이 아니라 "메시지 중심"으로 생각하는 것이다. 로봇 소프트웨어에서는 어떤 모델을 쓰는지도 중요하지만, 그 모델의 입력과 출력이 어떤 메시지로 흐르는지가 더 중요할 때가 많다.

강화학습은 로봇에게 시행착오를 가르친다

강화학습은 에이전트가 환경 안에서 행동을 선택하고, 그 결과로 보상을 받으며 더 나은 행동을 배우는 방법이다. 게임 AI를 떠올리면 이해하기 쉽다. 에이전트가 움직이고, 성공하면 보상을 받고, 실패하면 낮은 보상을 받으면서 점점 나은 전략을 찾아간다.

로봇에서 강화학습은 매력적으로 보인다. 사람이 규칙을 일일이 만들지 않아도 로봇이 스스로 균형 잡기, 걷기, 물체 밀기, 잡기 같은 행동을 배울 수 있기 때문이다. 하지만 입문자가 꼭 기억해야 할 점이 있다. 강화학습을 실제 로봇에 바로 적용하면 위험하고 비싸다.

강화학습은 수많은 시행착오를 필요로 한다. 시뮬레이션 안에서는 로봇이 넘어지고 부딪히고 실패해도 다시 시작하면 된다. 하지만 실제 로봇에서는 모터가 망가지고, 배터리가 과열되고, 로봇팔이 책상을 때리고, 주변 사람이 다칠 수 있다. 그래서 강화학습은 보통 Gazebo, Isaac Sim 같은 시뮬레이터에서 먼저 실험한다.

강화학습 프로젝트를 시작한다면 처음부터 실제 로봇을 움직이기보다 아주 단순한 환경을 고르는 것이 좋다. 예를 들어 2차원 평면에서 목표 지점까지 가는 에이전트, 장애물을 피하는 작은 바퀴 로봇, 로봇팔 끝을 목표 위치로 보내는 문제처럼 상태와 행동이 명확한 과제가 적합하다.

강화학습을 로봇에 연결할 때는 다음 요소를 정해야 한다.

관측: 로봇이 무엇을 볼 것인가. 예를 들어 거리 센서, 카메라 이미지, 로봇 위치, 관절 각도 등이 있다.
행동: 로봇이 무엇을 출력할 것인가. 예를 들어 선속도·각속도, 관절 목표 각도, 그리퍼 열기·닫기 등이 있다.
보상: 어떤 행동을 잘했다고 평가할 것인가. 목표에 가까워지면 보상, 충돌하면 벌점처럼 설계한다.
종료 조건: 성공, 실패, 시간 초과를 어떻게 판단할 것인가.

강화학습에서 가장 어려운 부분은 알고리즘 이름을 외우는 것이 아니라 보상을 설계하는 일이다. 보상이 애매하면 로봇은 이상한 방법을 배운다. 목표 지점까지 가라고 했더니 벽에 바짝 붙어 흔들거리거나, 물체를 집으라고 했더니 손끝으로 툭 치기만 하는 식이다. 로봇은 우리가 의도한 의미를 이해하는 것이 아니라, 우리가 정의한 보상을 최대화하려고 한다.

모방학습은 사람의 시범에서 출발한다

모방학습은 사람이 보여 준 행동 데이터를 바탕으로 로봇이 행동을 배우는 방법이다. 강화학습이 "해 보면서 배운다"에 가깝다면, 모방학습은 "보고 따라 하며 배운다"에 가깝다.

예를 들어 사람이 조이스틱으로 로봇을 조종해 복도를 지나가는 데이터를 모은다. 또는 사람이 로봇팔을 직접 움직여 컵을 잡는 궤적을 기록한다. 그 데이터에는 관측과 행동이 함께 들어 있다. 카메라 이미지가 이럴 때 사람은 왼쪽으로 돌았다. 물체가 이 위치에 있을 때 사람은 그리퍼를 닫았다. 모델은 이런 대응 관계를 배운다.

모방학습은 강화학습보다 출발이 쉬울 수 있다. 로봇이 처음부터 무작위로 행동하지 않아도 되고, 사람이 알고 있는 기본 요령을 데이터로 전달할 수 있기 때문이다. 하지만 모방학습에도 한계가 있다. 사람이 보여 준 상황과 조금만 달라져도 로봇이 당황할 수 있다. 데이터에 없는 각도, 조명, 물체 위치가 나오면 엉뚱한 행동을 할 수 있다.

그래서 모방학습 프로젝트는 작은 스킬 단위로 시작하는 것이 좋다. "집 안을 모두 정리하는 로봇"처럼 큰 목표보다 "특정 위치의 컵을 향해 팔을 뻗기", "라인을 따라 천천히 주행하기", "사람의 손짓 방향으로 회전하기"처럼 좁은 행동을 먼저 학습한다.

나중에 LLM 기반 로봇 에이전트를 만들 때도 이 관점이 중요해진다. LLM이 모든 행동을 직접 배우는 것이 아니라, 강화학습이나 모방학습으로 만든 작은 행동 정책을 스킬 라이브러리에 넣고 필요할 때 호출하는 방식이 더 현실적이다. 실제 ROS-LLM 연구에서도 원자 행동을 강화학습, 모방학습, 최적 제어 등으로 구현하고, 이를 ROS 액션이나 서비스 형태의 라이브러리로 관리한 뒤 언어 모델이 조합하는 구조를 제시한다.⁵

시뮬레이션에서 배운 로봇은 왜 현실에서 흔들릴까

강화학습과 모방학습을 공부하다 보면 반드시 만나는 문제가 있다. 시뮬레이션에서는 잘 되는데 실제 로봇에서는 잘 안 되는 문제다. 이것을 흔히 시뮬레이션-현실 차이, 또는 Sim-to-Real gap이라고 부른다.

시뮬레이터 속 세계는 깨끗하다. 바닥 마찰은 일정하고, 센서 노이즈는 제한적이며, 카메라 렌즈는 완벽하고, 모터는 명령한 대로 즉시 반응하는 경우가 많다. 하지만 현실은 다르다. 바퀴는 미끄러지고, 바닥은 기울어져 있고, 조명은 바뀌고, 카메라는 흔들리고, 모터에는 지연이 있고, 배터리 전압이 떨어지면 힘도 달라진다.

그래서 시뮬레이션에서 좋은 성능을 보인 정책을 실제 로봇에 바로 올리면 위험하다. 특히 로봇팔이나 이동 로봇처럼 물리적 충돌이 있는 시스템에서는 더 조심해야 한다. 실제 적용 전에는 반드시 단계적으로 검증해야 한다.

현실적인 검증 순서는 다음과 같다.

시뮬레이터에서 낮은 속도와 단순 환경으로 먼저 테스트한다.
센서 노이즈, 지연, 마찰 변화, 조명 변화를 일부러 넣어 본다.
실제 로봇에서는 바퀴를 띄우거나 모터 출력을 제한한 상태로 명령을 확인한다.
넓고 안전한 공간에서 낮은 속도로 짧은 동작부터 실행한다.
비상 정지, 충돌 감지, 속도 제한, 작업 공간 제한을 항상 준비한다.

여기서 중요한 태도는 "한 번에 성공시키기"가 아니라 "작게 실패시키기"다. 시뮬레이션에서 크게 실험하고, 현실에서는 아주 작게 확인해야 한다. AI 로봇 학습에서 안전은 마지막 장식이 아니라 시스템 설계의 일부다.

LLM 로봇은 모터를 직접 움직이지 않는다

LLM이 등장하면서 많은 사람이 자연어로 로봇을 조종하는 모습을 상상하게 되었다. "부엌에 가서 컵을 가져와." "책상 위를 정리해." "빨간 상자를 파란 상자 옆에 놓아." 이런 명령을 로봇이 이해하고 실행한다면 매우 매력적이다.

하지만 여기서도 오해를 피해야 한다. LLM이 모터 속도를 직접 출력하는 구조는 좋은 설계가 아니다. 언어 모델은 문장을 잘 다루고, 목표를 단계로 나누고, 모호한 지시를 해석하고, 필요한 정보를 질문하는 데 강하다. 반면 센서 노이즈, 실시간 제어, 충돌 회피, 모터 안정화 같은 일은 전통적인 로봇 제어기와 계획기가 훨씬 잘한다.

따라서 LLM 기반 로봇은 보통 다음과 같은 구조로 설계한다.

사용자 명령
  → LLM 계획 모듈
  → 작업 단계 생성
  → 스킬 라이브러리 호출
  → ROS2 액션·서비스 실행
  → 센서 피드백 확인
  → 필요하면 재계획 또는 사용자에게 질문

예를 들어 사용자가 "책상 위의 컵을 가져와"라고 말한다면 LLM은 직접 바퀴 속도나 로봇팔 관절 각도를 만들지 않는다. 대신 다음과 같은 단계로 나눌 수 있다.

1. find_object("cup")
2. navigate_to(object_location)
3. align_to_object("cup")
4. grasp_object("cup")
5. navigate_to(user_location)
6. release_object("cup")

각 단계는 이미 검증된 로봇 스킬이어야 한다. navigate_to는 Nav2 같은 내비게이션 시스템이 맡고, grasp_object는 로봇팔 계획기와 그리퍼 제어기가 맡고, find_object는 비전 노드가 맡는다. LLM은 지휘자에 가깝다. 연주 자체는 각 악기가 한다.

LLM과 ROS를 결합한 연구와 프로젝트들도 대체로 이런 방향을 따른다. ROS-LLM 프레임워크는 자연어 입력을 받아 ROS 액션과 서비스 실행으로 연결하고, 행동을 순차 실행, 행동 트리, 상태 기계 같은 형태로 표현하며, 사람과 환경의 피드백을 반영하는 구조를 제시한다.⁵ 또 ROS2와 MoveIt2를 결합한 LLM 로봇팔 프로젝트에서는 자연어 명령을 구조화된 로봇 행동으로 바꾸고, 실제 궤적 계획은 MoveIt2가 담당하도록 분리한다. 이 프로젝트 역시 LLM의 비결정적 행동 때문에 실제 하드웨어에서는 별도의 안전 검증이 필요하다고 설명한다.⁶

이것이 계획과 실행을 분리해야 하는 이유다. LLM은 "무엇을 어떤 순서로 할지"를 제안할 수 있다. 하지만 "지금 이 속도로 모터를 돌려도 안전한지", "팔이 장애물과 충돌하지 않는지", "센서가 실제로 물체를 확인했는지"는 로봇 시스템이 검증해야 한다.

스킬 라이브러리를 먼저 만들자

LLM 로봇을 만들고 싶다면 LLM부터 붙이고 싶어진다. 하지만 순서는 반대가 좋다. 먼저 로봇이 할 수 있는 작은 스킬을 만들어야 한다. LLM은 할 수 없는 행동을 마법처럼 만들어 주지 않는다. 스킬이 없는 로봇에게 "방을 정리해"라고 말해도 실행할 도구가 없다.

스킬 라이브러리는 로봇이 안정적으로 수행할 수 있는 행동들의 목록이다. 각 스킬은 입력, 출력, 성공 조건, 실패 조건을 가져야 한다.

예를 들어 이동 로봇이라면 다음 스킬부터 만들 수 있다.

go_to(location): 지정된 위치로 이동한다.
turn_to(angle): 특정 방향을 바라본다.
find_object(name): 카메라에서 특정 물체를 찾는다.
approach_object(name): 물체 근처까지 천천히 접근한다.
stop(): 즉시 정지한다.
ask_user(question): 모호한 상황에서 사용자에게 질문한다.

로봇팔이라면 다음 스킬이 필요할 수 있다.

move_to_pose(pose): 말단 장치를 특정 위치와 자세로 이동한다.
open_gripper(): 그리퍼를 연다.
close_gripper(): 그리퍼를 닫는다.
pick(object_id): 물체를 집는다.
place(location): 물체를 내려놓는다.
home(): 안전한 기본 자세로 돌아간다.

좋은 스킬은 이름만 그럴듯한 함수가 아니다. 실행 전 조건과 실행 후 확인이 있어야 한다. 예를 들어 pick(cup)은 컵이 보이는지, 컵까지의 거리가 적절한지, 로봇팔 경로가 충돌하지 않는지 확인해야 한다. 실행 후에는 그리퍼 힘이나 물체 위치를 통해 실제로 잡았는지도 확인해야 한다.

LLM은 이 스킬들을 조합한다. "컵을 가져와"라는 명령이 들어오면 find_object, go_to, approach_object, pick, go_to, place를 순서대로 호출한다. 중간에 컵이 여러 개 발견되면 ask_user를 호출해 "왼쪽 컵과 오른쪽 컵 중 어느 것을 가져올까요?"라고 물을 수 있다. 이것이 자연어 명령 로봇의 현실적인 구조다.

AI 로봇 프로젝트의 현실적인 순서

이제 전체 학습 루트를 하나의 길로 정리해 보자. AI 로봇을 처음부터 거창하게 만들려고 하면 거의 반드시 막힌다. 카메라, 딥러닝, ROS2, 시뮬레이터, 실제 로봇, LLM을 한꺼번에 붙이면 어디서 문제가 생겼는지 알 수 없다. 따라서 작은 기능을 검증하며 누적해야 한다.

가장 현실적인 순서는 다음과 같다.

영상 인식 미니 프로젝트
  → PyTorch 추론 모델 연결
  → ROS2 통신 구조화
  → 시뮬레이션 실험
  → 실제 로봇 적용
  → LLM 계획 모듈 추가

첫째, 영상 인식 미니 프로젝트를 만든다. OpenCV로 색상 물체를 찾고 중심 좌표를 계산한다. 화면에 사각형을 그리는 데서 멈추지 말고, 중심이 왼쪽인지 오른쪽인지 판단해 간단한 명령으로 바꾼다.

둘째, PyTorch 추론 모델을 연결한다. 처음부터 직접 학습하지 않아도 된다. 사전 학습된 객체 검출 모델을 사용해 사람, 컵, 의자 같은 물체를 찾아본다. 이때 모델 성능만 보지 말고 추론 시간과 결과 형식을 함께 확인한다.

셋째, ROS2 통신 구조로 나눈다. 카메라 노드, 인식 노드, 판단 노드, 제어 노드를 분리한다. 각 노드가 어떤 토픽을 발행하고 구독하는지 그림으로 그려 본다. 이 단계에서 rqt_graph, ros2 topic echo, RViz 같은 도구로 데이터 흐름을 확인하는 습관을 들인다.

넷째, 시뮬레이션에서 실험한다. Gazebo나 Isaac Sim 같은 환경에서 로봇을 움직이며 인식과 제어를 연결한다. 실제 로봇을 망가뜨릴 걱정 없이 실패를 반복할 수 있는 것이 시뮬레이션의 장점이다.

다섯째, 실제 로봇에 아주 작은 기능부터 올린다. 속도를 낮추고, 비상 정지를 준비하고, 주변을 정리한 뒤 테스트한다. 시뮬레이션에서 잘 되던 것도 실제 카메라, 실제 바닥, 실제 조명에서는 달라질 수 있다.

여섯째, LLM 계획 모듈을 추가한다. 이때 LLM은 이미 만들어진 스킬을 호출하는 역할로 제한한다. 자연어를 바로 모터 명령으로 바꾸지 않는다. 사용자의 명령을 작업 단계로 나누고, 각 단계가 성공했는지 센서 피드백으로 확인하도록 만든다.

이 순서의 장점은 실패 지점이 분명하다는 것이다. 로봇이 물체를 못 따라간다면 OpenCV 단계 문제인지, ROS2 메시지 문제인지, 제어 명령 문제인지 나눠서 볼 수 있다. LLM이 잘못된 계획을 세워도 스킬 실행기는 안전 검사를 통해 막을 수 있다.

추천 미니 프로젝트: 사람을 보면 멈추는 로봇

두 번째 프로젝트는 PyTorch 모델을 연결하기에 좋다. 목표는 간단하다. 카메라에서 사람을 검출하면 로봇이 멈춘다. 사람을 검출하지 못하면 천천히 움직인다.

이 프로젝트에서 딥러닝 모델은 사람 검출을 맡는다. 모델은 바운딩 박스와 신뢰도를 출력한다. 판단 노드는 신뢰도가 일정 값 이상이고, 바운딩 박스 크기가 충분히 크면 사람이 가까이 있다고 판단한다. 그러면 제어 노드에 정지 명령을 보낸다.

이 프로젝트는 실제 서비스 로봇의 기본 안전 구조와도 닮아 있다. 물론 실제 안전 인증을 받으려면 훨씬 더 엄격한 센서와 검증이 필요하다. 하지만 학습 단계에서는 "AI 인식 결과가 제어 명령을 제한할 수 있다"는 중요한 원리를 배울 수 있다.

여기서 한 가지 더 생각해 볼 수 있다. 딥러닝 모델은 가끔 사람을 놓칠 수 있다. 조명이 어둡거나 사람이 일부만 보이거나 카메라가 흔들리면 검출이 실패할 수 있다. 그러므로 실제 로봇에서는 AI 모델 하나만 믿으면 안 된다. LiDAR, 초음파 센서, 범퍼, 속도 제한 같은 다른 안전 장치와 함께 써야 한다.

이 점은 AI 로봇 학습에서 매우 중요하다. AI는 로봇을 더 똑똑하게 만들지만, 안전을 대신 책임져 주지는 않는다.

추천 미니 프로젝트: 자연어로 이동 목표 지정하기

세 번째 프로젝트는 LLM 계획 모듈을 붙이는 연습이다. 목표는 "부엌으로 가", "충전기로 돌아가", "책상 근처로 이동해" 같은 자연어 명령을 로봇의 이동 목표로 바꾸는 것이다.

처음에는 복잡한 자유 대화를 만들 필요가 없다. 미리 정의된 장소 목록을 준비한다.

kitchen:  x=2.1, y=1.3
desk:     x=0.5, y=-1.0
charger:  x=-1.2, y=0.2

LLM은 사용자의 문장에서 어느 장소를 말하는지 고른다. 그런 다음 go_to(location) 스킬을 호출한다. 실제 이동은 Nav2 같은 내비게이션 시스템이 맡는다. LLM이 직접 경로를 만들거나 속도 명령을 내리지 않는다.

이 프로젝트에서 배워야 할 핵심은 모호성 처리다. 사용자가 "방으로 가"라고 말했는데 방이 여러 개라면 로봇은 마음대로 정하면 안 된다. "침실과 작업실 중 어디로 갈까요?"라고 물어야 한다. 사용자가 "컵 가져와"라고 했는데 컵이 여러 개라면 어떤 컵인지 확인해야 한다.

좋은 LLM 로봇은 말을 잘하는 로봇이 아니라, 모를 때 멈추고 물어볼 줄 아는 로봇이다.

AI 로봇 학습자가 자주 빠지는 함정

AI를 먼저 배운 독자가 로봇으로 넘어올 때 자주 빠지는 함정이 있다. 첫째, 모델 정확도만 본다. 하지만 로봇에서는 지연 시간, 좌표 변환, 센서 동기화, 통신 안정성도 중요하다. 정확도 95퍼센트 모델이 1초 늦게 반응한다면 빠르게 움직이는 로봇에는 적합하지 않을 수 있다.

둘째, 시각화 결과를 실제 행동 결과로 착각한다. 화면에 사각형이 잘 그려지는 것과 로봇이 물체를 잘 집는 것은 완전히 다른 문제다. 사각형 중심을 실제 3차원 위치로 바꾸고, 로봇팔이 접근할 수 있는 자세를 계산하고, 충돌 없는 경로를 만들어야 한다.

셋째, LLM에게 너무 많은 권한을 준다. LLM은 그럴듯한 계획을 만들 수 있지만, 항상 옳지는 않다. 존재하지 않는 스킬을 호출하거나, 현재 로봇이 할 수 없는 행동을 제안하거나, 안전하지 않은 순서를 만들 수도 있다. 따라서 LLM의 출력은 반드시 검증되어야 한다.

넷째, 시뮬레이션 성공을 현실 성공으로 착각한다. 시뮬레이터에서 로봇이 잘 움직였다고 해서 실제 로봇도 바로 잘 움직이는 것은 아니다. 현실에는 노이즈, 마찰, 지연, 조명 변화, 전원 문제, 통신 끊김이 있다.

다섯째, 모든 것을 한 번에 만들려고 한다. AI 로봇은 작은 기능의 누적이다. 카메라 한 장을 읽는 것, 토픽 하나를 발행하는 것, 속도 명령 하나를 보내는 것, 물체 중심 하나를 좌표로 바꾸는 것, 이런 작은 연결들이 쌓여서 지능 시스템이 된다.

AI 로봇 학습 루트 정리

AI 로봇 중심 학습 루트는 다음처럼 정리할 수 있다.

단계	목표	핵심 질문
OpenCV	카메라 영상에서 행동 가능한 숫자를 뽑기	이 픽셀 정보가 로봇 명령으로 바뀔 수 있는가?
PyTorch	물체 인식과 장면 이해 모델 연결	모델 출력이 좌표와 메시지로 변환되는가?
ROS2	인식·판단·제어 노드 분리	데이터가 토픽, 서비스, 액션으로 잘 흐르는가?
시뮬레이션	실패를 안전하게 반복	센서 노이즈와 지연을 넣어도 버티는가?
실제 로봇	낮은 속도로 기능 검증	안전하게 멈추고 복구할 수 있는가?
LLM 계획	자연어를 스킬 호출로 변환	계획과 실행이 분리되어 있는가?

이 루트의 핵심은 AI 기술을 로봇의 몸에 붙이는 것이다. OpenCV는 눈의 앞단을 만든다. PyTorch는 더 깊은 인식을 만든다. ROS2는 여러 기능이 대화하게 만든다. 강화학습과 모방학습은 행동 정책을 만든다. LLM은 목표를 단계로 나누고 스킬을 조합한다.

하지만 마지막까지 기억해야 할 문장이 있다.

로봇은 모델 하나로 움직이지 않는다. 로봇은 인식, 판단, 계획, 제어, 피드백이 연결될 때 움직인다.

AI를 공부한 사람에게 로봇공학은 매우 흥미로운 다음 단계다. 화면 속 데이터가 실제 세계의 움직임으로 이어지는 순간, 인공지능은 더 이상 파일 안의 숫자가 아니다. 그것은 바퀴를 굴리고, 팔을 뻗고, 실패를 감지하고, 다시 시도하는 물리적 지능이 된다.

다음 장에서는 이 모든 학습을 바탕으로 나만의 로봇 프로젝트를 어떻게 설계할지 살펴본다. 이동 로봇, 로봇팔, AI 에이전트, 콘텐츠 제작형 프로젝트 중 무엇을 선택하든 핵심은 같다. 너무 큰 꿈을 한 번에 만들려 하지 말고, 작지만 실제로 작동하는 기능을 하나씩 쌓아 올리는 것이다.