말로 움직이는 로봇이라는 환상과 현실
"주방에 가서 빨간 컵을 가져와."
이 문장을 들은 로봇이 바로 모터를 돌리고, 바퀴를 굴리고, 팔을 뻗는 모습을 상상하기 쉽다. 요즘의 대규모 언어 모델, 즉 LLM은 사람의 말을 꽤 그럴듯하게 이해한다. 그래서 마치 로봇에게 말만 하면 로봇이 알아서 모든 일을 해낼 것처럼 보인다.
하지만 실제 로봇 시스템은 그렇게 단순하지 않다. 자연어 명령은 곧바로 모터 명령이 되지 않는다. "주방으로 가라"는 말은 먼저 목표 위치로 바뀌어야 하고, "빨간 컵"은 카메라나 객체 인식 결과와 연결되어야 하며, "가져와"는 이동, 탐색, 집기, 운반, 놓기 같은 여러 하위 작업으로 나뉘어야 한다. 그리고 그 모든 과정은 로봇의 현재 위치, 배터리 상태, 장애물, 팔의 도달 가능 범위, 사람과의 거리, 안전 규칙을 고려해야 한다.
이 장의 핵심은 바로 여기에 있다. LLM은 로봇의 모터를 직접 조종하는 마법의 두뇌가 아니다. 더 정확히 말하면, LLM은 사람이 말한 목표를 해석하고, 해야 할 일을 순서로 나누고, 로봇 시스템이 이해할 수 있는 명령 형태로 바꾸는 계획 보조 계층에 가깝다. 잘 설계된 AI 로봇은 LLM에게 모든 것을 맡기지 않는다. LLM은 "무엇을 어떤 순서로 할지"를 제안하고, 실제 이동과 조작, 충돌 회피, 정지, 힘 조절은 검증된 로봇 제어기와 안전 시스템이 맡는다.
자연어 명령은 어떻게 로봇 명령이 되는가
사람의 말은 느슨하다. "저쪽으로 가", "책상 위에 있는 거 치워", "위험하면 멈춰" 같은 문장은 인간에게는 자연스럽지만 로봇에게는 모호하다. 로봇은 "저쪽"이 어느 좌표인지, "있는 거"가 어떤 물체인지, "치워"가 집어서 어디에 놓으라는 뜻인지 알아야 한다.
그래서 LLM 기반 로봇 에이전트는 보통 다음과 같은 흐름으로 동작한다.
사용자가 자연어로 명령을 입력하면, LLM은 먼저 문장의 의도를 해석한다. 예를 들어 "회의실에 가서 의자가 몇 개인지 확인해 줘"라는 명령을 받으면, 이 문장이 단순 이동 명령이 아니라 이동, 관찰, 개수 세기, 보고라는 작업 묶음이라는 점을 파악한다. 그런 다음 목표와 제약 조건을 나눈다. 목표는 "회의실에 도착해 의자 개수를 보고하기"이고, 제약 조건은 "안전하게 이동하기", "문이 닫혀 있으면 사용자에게 알리기", "사람을 밀치지 않기" 같은 형태가 될 수 있다.
그다음 LLM 또는 별도의 플래너는 이 목표를 하위 작업으로 분해한다. 회의실 위치 확인, 내비게이션 실행, 카메라로 장면 확인, 의자 탐지, 결과 요약, 사용자에게 보고가 순서대로 이어진다. 여기서 중요한 점은 각 하위 작업이 로봇이 실제로 실행할 수 있는 기능이어야 한다는 것이다. 로봇에 의자 탐지 기능이 없다면 LLM이 아무리 "의자를 세겠다"고 말해도 실제로는 실행할 수 없다.
ROS2를 사용하는 로봇이라면 이 하위 작업은 토픽, 서비스, 액션, 로그 조회 같은 구체적인 인터페이스와 연결된다. 토픽은 센서값이나 상태를 계속 흘려보내는 통신 통로이고, 서비스는 "지금 배터리 상태 알려 줘"처럼 요청과 응답이 있는 호출이며, 액션은 "목표 지점까지 이동해"처럼 시간이 걸리고 중간 피드백이 필요한 작업에 적합하다. 로그는 로봇 시스템이 남긴 상태 메시지와 오류 기록이다.
이를 아주 단순화하면 다음과 같은 변환이 일어난다.
"회의실에 가서 의자가 몇 개인지 확인해 줘."
→ 목표: 회의실에서 의자 개수 확인
→ 하위 작업: 현재 위치 확인, 회의실로 이동, 카메라 관찰, 의자 탐지, 결과 보고
→ 실행 명령: 내비게이션 액션 호출, 카메라 토픽 구독, 객체 인식 노드 호출, 음성 또는 채팅 응답 생성
이 과정에서 LLM은 자연어와 로봇의 기능 사이를 이어 주는 번역자 역할을 한다. 로봇공학에서는 이런 연결을 흔히 그라운딩이라고 부른다. 그라운딩은 말이나 기호를 실제 세계의 물체, 위치, 행동과 연결하는 과정이다. "컵"이라는 단어가 카메라 속 특정 물체와 연결되고, "주방"이라는 단어가 지도 위 특정 영역과 연결될 때 비로소 로봇은 말을 행동으로 바꿀 수 있다.
LLM이 잘하는 일
LLM은 로봇공학에서 꽤 매력적인 도구다. 특히 사람이 로봇에게 명령하는 방식이 훨씬 자연스러워진다. 예전에는 로봇에게 일을 시키려면 좌표를 입력하거나, 특정 버튼을 누르거나, 미리 정해진 명령어를 사용해야 했다. 이제는 "충전기로 돌아가", "작업대 주변을 확인해", "왜 멈췄는지 설명해 줘"처럼 사람의 말에 가까운 방식으로 상호작용할 수 있다.
LLM이 특히 잘하는 영역은 고수준 언어 이해와 설명이다. 예를 들어 사용자가 "창고 입구 근처에 있는 상자를 확인하고, 길을 막고 있으면 알려 줘"라고 말하면 LLM은 이 명령에 이동, 관찰, 판단, 보고가 포함되어 있음을 파악할 수 있다. "먼저 창고 입구로 이동한 뒤 카메라로 상자를 찾고, 통로 폭을 확인한 다음 사용자에게 보고한다"는 식의 작업 순서를 제안할 수도 있다.
또한 LLM은 로봇의 상태를 사람이 이해하기 쉬운 말로 바꾸는 데 유용하다. 예를 들어 로봇 내부에서는 /battery_state, /odom, /diagnostics, /navigate_to_pose/_action/status 같은 이름으로 정보가 오갈 수 있다. 개발자에게는 익숙한 표현이지만 일반 사용자에게는 낯설다. LLM은 이런 정보를 모아 "배터리는 18%이고, 현재 로봇은 복도 중간에 있으며, 목표 지점까지 이동하던 중 장애물 때문에 정지했습니다"라고 설명할 수 있다.
LLM이 유용한 대표적인 일은 다음과 같다.
자연어 명령의 의도와 조건 해석
긴 작업을 여러 하위 작업으로 나누기
로봇 상태와 오류 로그를 사람이 이해하기 쉬운 말로 요약하기
애매한 명령에 대해 되묻기
기존 스킬을 조합해 새로운 작업 순서 제안하기
작업 실패 후 가능한 원인을 설명하고 재시도 방법 제안하기
예를 들어 사용자가 "저 의자 가져와"라고 말했는데 카메라에 의자가 세 개 보인다면, 좋은 로봇 에이전트는 아무 의자나 집으러 가지 않는다. "왼쪽 의자, 가운데 의자, 오른쪽 의자 중 어느 것을 말씀하시나요?"라고 되묻는 편이 안전하다. LLM은 이런 대화형 clarification, 즉 명확화 질문을 만드는 데 강하다.
LLM이 직접 맡기 어려운 일
반대로 LLM에게 맡기면 위험한 일도 분명하다. 로봇은 물리 세계에서 움직인다. 말 한마디가 모터 회전이 되고, 모터 회전이 바퀴와 팔의 움직임이 되며, 그 움직임은 사람이나 물체와 부딪힐 수 있다. 텍스트를 잘 생성하는 능력과 안전하게 힘을 조절하는 능력은 전혀 다른 능력이다.
LLM은 확률적으로 다음 단어를 예측하는 모델이다. 물론 현대 LLM은 그 과정에서 상당한 추론 능력과 지식 활용 능력을 보이지만, 기본적으로 센서값을 실시간으로 해석하고 밀리초 단위로 모터를 제어하도록 만들어진 시스템은 아니다. 카메라 이미지 한 장을 설명할 수 있다고 해서, 로봇팔이 깨지기 쉬운 컵을 어느 힘으로 쥐어야 하는지 즉시 정확하게 판단할 수 있는 것은 아니다.
특히 다음과 같은 영역은 LLM이 직접 담당하기 어렵다.
실시간 모터 제어
충돌 회피와 비상 정지
힘과 토크 조절
센서 노이즈가 섞인 물리량의 정밀 판단
빠른 주기로 반복되는 자세 안정화
안전 등급이 필요한 산업용 동작
지도 기반 경로 추종과 장애물 회피의 저수준 제어
예를 들어 바퀴 로봇이 초당 수십 번씩 장애물 거리를 확인하며 속도를 조절해야 한다고 해 보자. 이 일은 내비게이션 스택과 제어기가 맡아야 한다. LLM에게 매 순간 "앞에 장애물이 있나요? 왼쪽으로 갈까요? 속도를 줄일까요?"라고 물어보는 구조는 너무 느리고 불안정하다. 네트워크 지연이 생기거나 모델 응답이 늦어지는 순간 로봇은 이미 벽에 가까워져 있을 수 있다.
로봇팔도 마찬가지다. "컵을 집어"라는 명령은 LLM이 이해할 수 있지만, 실제 집기 과정에는 물체 위치 추정, 충돌 없는 팔 경로 생성, 그리퍼 접근 방향 계산, 접촉 순간의 힘 조절, 실패 감지 같은 작업이 필요하다. 이 작업들은 MoveIt 같은 모션 플래닝 도구, 힘/토크 센서, 그리퍼 제어기, 안전 모니터가 처리해야 한다.
그래서 좋은 설계 원칙은 간단하다. LLM은 말과 계획을 다루고, 로봇의 실시간 물리 행동은 검증된 로봇 소프트웨어가 다루게 해야 한다.
계획과 실행을 분리해야 하는 이유
LLM 기반 로봇에서 가장 중요한 설계 원칙은 고수준 계획과 저수준 실행의 분리다. 이 원칙을 이해하면 "AI 로봇"이라는 말이 훨씬 덜 신비롭게 느껴진다.
고수준 계획은 "무엇을 할 것인가"에 가깝다. 예를 들어 "창고 A 구역을 점검하고 이상이 있으면 사진을 찍어 보고한다"는 목표를 받고, 이를 "A 구역으로 이동하기 → 주변 촬영하기 → 이상 물체 탐지하기 → 사진 저장하기 → 보고하기"로 나누는 일이다. 이 수준에서는 언어 이해, 상식 추론, 작업 순서 구성, 예외 상황에 대한 대화가 중요하다. LLM이 잘 어울리는 영역이다.
저수준 실행은 "어떻게 물리적으로 할 것인가"에 가깝다. 목적지까지 어떤 속도로 갈지, 장애물을 어떻게 피할지, 팔의 각 관절을 어떤 궤적으로 움직일지, 그리퍼를 어느 힘으로 닫을지, 로봇이 기울어질 때 어떻게 균형을 잡을지가 여기에 속한다. 이 수준에서는 정확한 센서 처리, 빠른 제어 주기, 물리 모델, 안전 검사가 중요하다. 전통적인 제어기, 내비게이션 스택, 모션 플래너, 안전 회로가 맡아야 한다.
이 둘을 분리하면 시스템이 훨씬 안전하고 이해하기 쉬워진다. LLM이 만든 계획이 이상하면 실행 전에 검증할 수 있다. 로봇이 실제 실행 중 장애물을 만나면 내비게이션 스택이 즉시 정지하거나 우회할 수 있다. 작업이 실패하면 실행 모니터가 실패 원인을 기록하고, 그 결과를 다시 LLM이나 플래너에게 전달해 재계획할 수 있다.
예를 들어 사용자가 "창고 끝까지 가서 박스를 확인해"라고 했다고 하자. LLM은 다음과 같은 계획을 만들 수 있다.
1. 현재 지도에서 '창고 끝' 위치를 확인한다.
2. 해당 위치까지 navigate_to_pose 액션을 실행한다.
3. 도착하면 카메라로 주변을 촬영한다.
4. 객체 인식 스킬로 박스를 찾는다.
5. 박스가 보이면 개수와 위치를 보고한다.
6. 박스가 보이지 않으면 사용자에게 추가 지시를 요청한다.그러나 실제 이동 중에 갑자기 사람이 지나가면 어떻게 해야 할까? 이때 LLM에게 다시 물어보기 전에 로봇은 즉시 감속하거나 멈춰야 한다. 이 판단은 안전 모니터와 내비게이션 시스템이 담당한다. LLM은 이후 "사람이 경로에 들어와 일시 정지했습니다. 계속할까요?"라고 설명하고 다음 행동을 정하는 데 도움을 줄 수 있다.
이 구조는 사람의 조직과도 비슷하다. LLM은 작업 지시를 이해하는 현장 관리자에 가깝고, 로봇 제어기는 실제 장비를 움직이는 숙련 작업자에 가깝다. 현장 관리자가 "저 선반으로 가서 상자를 확인해 주세요"라고 말할 수는 있지만, 지게차의 브레이크를 매 순간 직접 밟는 것은 운전 시스템과 작업자의 몫이다.
LLM 로봇 에이전트의 기본 구조
그렇다면 실제 LLM 기반 로봇 에이전트는 어떤 부품들로 이루어질까? 이름은 프로젝트마다 다르지만, 기본 구조는 대체로 비슷하다. 중요한 것은 LLM 하나만 있는 것이 아니라, LLM 주변에 컨텍스트, 도구, 로봇 인터페이스, 실행 감시, 안전 장치가 함께 있어야 한다는 점이다.
LLM 로봇 에이전트의 기본 구성 요소는 다음과 같이 나눌 수 있다.
사용자 인터페이스: 사람이 명령을 입력하는 창구다. 채팅창, 음성 명령, 태블릿 앱, 관제 화면이 될 수 있다.
프롬프트와 컨텍스트: LLM에게 로봇의 역할, 사용할 수 있는 도구, 금지된 행동, 현재 상황을 알려 주는 정보 묶음이다.
ROS/ROS2 연결 노드: LLM 에이전트와 로봇 시스템을 이어 주는 중간 노드다. 토픽을 읽고, 서비스를 호출하고, 액션을 보낸다.
도구 선택기: LLM이 어떤 기능을 호출해야 할지 고르는 부분이다. 예를 들어 위치 조회, 지도 확인, 이동 명령, 카메라 캡처, 로그 조회 중 적절한 도구를 선택한다.
월드 모델: 로봇이 알고 있는 세계의 상태다. 지도, 물체 위치, 사람 위치, 문이 열렸는지 여부, 현재 작업 상태 같은 정보가 들어간다.
플래너: 목표를 실행 가능한 단계로 나누는 부분이다. LLM이 직접 맡을 수도 있고, 행동 트리나 상태 기계, 태스크 플래너와 함께 동작할 수도 있다.
스킬 라이브러리: 로봇이 실제로 할 수 있는 동작들의 목록이다. 이동하기, 물체 찾기, 집기, 놓기, 사진 찍기, 충전기로 복귀하기 같은 기능이 여기에 들어간다.
실행 모니터: 계획이 제대로 실행되는지 지켜본다. 실패, 시간 초과, 충돌 위험, 센서 이상, 목표 미도달을 감지한다.
피드백 루프: 실행 결과와 센서 피드백을 다시 플래너나 LLM에게 전달한다. 이를 통해 설명, 재질문, 재계획이 가능해진다.
이 구조에서 가장 중요한 부품 중 하나가 스킬 라이브러리다. LLM은 로봇에게 없는 능력을 만들어 낼 수 없다. 로봇이 "컵 찾기" 스킬은 있지만 "와인잔 깨짐 여부 판단" 스킬이 없다면, LLM은 이를 솔직히 말하거나 사람에게 추가 확인을 요청해야 한다. 만약 없는 기능을 있는 것처럼 호출한다면 그것이 바로 로봇에서의 환각, 즉 hallucination 문제다.
그래서 최근의 LLM-ROS 연결 도구들은 로봇이 실제로 제공하는 기능 목록을 명확히 등록하고, LLM이 제안한 행동이 그 목록 안에 있는지 확인하는 방향으로 발전하고 있다. 예를 들어 ros2_lingua는 로봇 노드가 자신이 할 수 있는 기능을 구조화된 capability, 즉 능력 명세로 등록하고, LLM이 만든 계획을 등록된 기능 목록과 대조한 뒤 실행하는 구조를 제안한다.1 이런 방식은 LLM이 "그럴듯하지만 존재하지 않는 명령"을 만들어 내는 위험을 줄여 준다.
ROS2와 LLM은 어떻게 만나는가
ROS2를 이미 알고 있다면 LLM 에이전트는 새로운 종류의 노드라고 생각해도 좋다. 이 노드는 사람의 말을 입력으로 받고, 로봇 시스템의 상태를 읽고, 필요한 ROS2 인터페이스를 호출한다.
예를 들어 로봇 안에 다음과 같은 기능이 있다고 해 보자.
/navigate_to_pose액션: 목표 위치로 이동한다./detect_objects서비스: 현재 카메라 이미지에서 물체를 찾는다./battery_state토픽: 배터리 상태를 계속 알려 준다./diagnostics토픽: 시스템 진단 정보를 알려 준다./emergency_stop서비스: 로봇을 즉시 정지시킨다.
사용자가 "충전이 부족하면 충전기로 돌아가고, 아니면 회의실로 가"라고 말하면 LLM 에이전트는 먼저 배터리 상태를 확인해야 한다고 판단할 수 있다. 배터리가 충분하면 회의실 좌표를 찾고 내비게이션 액션을 호출한다. 배터리가 부족하면 충전기 위치로 이동한다. 이때 LLM은 직접 바퀴 속도를 계산하지 않는다. 액션 목표를 보내고, 진행 상태를 모니터링하며, 실패하면 이유를 해석한다.
이런 구조는 실제 연구와 오픈소스 프로젝트에서도 나타난다. NASA JPL의 ROSA는 ROS1과 ROS2 기반 로봇 시스템을 자연어로 점검하고, 진단하고, 이해하고, 조작할 수 있도록 만든 에이전트로 소개된다. 예시 명령도 "구독자는 없지만 발행자는 있는 토픽 목록을 보여 줘"처럼 로봇 시스템을 자연어로 조회하는 형태를 포함한다.2 여기서 중요한 점은 ROSA가 로봇의 저수준 제어기를 대체한다기보다, ROS 시스템을 사람이 말로 살펴보고 명령할 수 있게 해 주는 인터페이스에 가깝다는 것이다.
ROS-LLM 연구도 비슷한 방향을 보여 준다. 이 프레임워크는 자연어 프롬프트와 ROS의 문맥 정보를 이용해 비전문가가 로봇 작업을 지정할 수 있게 하며, LLM 출력에서 행동을 추출해 ROS 액션이나 서비스를 실행하는 구조를 제안한다. 또한 실행 표현으로 순차 실행, 행동 트리, 상태 기계 같은 방식을 지원하고, 사람과 환경 피드백을 통한 반영 과정을 포함한다.3 여기서도 핵심은 LLM 하나가 모든 것을 직접 제어하는 것이 아니라, 기존 로봇 실행 구조 위에 언어 기반 계획 계층을 얹는다는 점이다.
예시: "빨간 컵을 가져와"라는 명령의 내부 여행
이제 하나의 명령이 로봇 내부에서 어떻게 여행하는지 따라가 보자.
사용자가 거실에서 로봇에게 말한다.
"주방 테이블 위에 있는 빨간 컵을 가져와."
LLM은 먼저 이 문장을 해석한다. 목표 물체는 빨간 컵이다. 예상 위치는 주방 테이블 위다. 최종 목표는 컵을 사용자에게 가져오는 것이다. 여기에는 이동, 탐색, 인식, 조작, 복귀가 모두 들어 있다.
좋은 에이전트라면 곧바로 움직이지 않고 현재 조건을 확인한다. 로봇팔이 사용 가능한지, 배터리가 충분한지, 주방 위치를 알고 있는지, 컵을 집을 수 있는 그리퍼가 장착되어 있는지 확인한다. 만약 지도를 모른다면 "주방 위치가 등록되어 있지 않습니다"라고 말해야 한다. 컵을 집는 스킬이 없다면 "컵을 찾을 수는 있지만 집을 수는 없습니다"라고 설명해야 한다.
조건이 맞는다면 플래너는 작업을 나눈다. 먼저 주방으로 이동한다. 이동은 Nav2 같은 내비게이션 스택이 담당한다. 도착하면 카메라와 객체 인식 스킬을 사용해 테이블과 컵을 찾는다. 빨간 컵이 여러 개라면 사용자에게 어느 컵인지 물어볼 수 있다. 하나만 보인다면 로봇팔의 모션 플래너가 컵에 접근할 경로를 계산한다. 그리퍼는 정해진 힘 범위 안에서 컵을 잡고, 들어 올린 뒤, 로봇은 사용자 위치로 돌아온다.
중간에 실패할 수도 있다. 주방으로 가는 길이 막혀 있을 수 있고, 테이블 위에 컵이 없을 수 있으며, 컵이 너무 멀리 있어 팔이 닿지 않을 수도 있다. 이때 실행 모니터는 실패 사실과 원인을 기록한다. LLM은 이 정보를 받아 사용자에게 설명한다.
"주방까지 이동했지만 테이블 위에서 빨간 컵을 찾지 못했습니다. 싱크대 쪽도 확인할까요?"
여기서 LLM의 장점이 드러난다. 단순히 실패 코드 OBJECT_NOT_FOUND를 띄우는 대신, 로봇이 무엇을 했고 어디서 막혔는지 사람이 이해할 수 있게 설명한다. 또 다음 선택지를 제안한다. 하지만 컵을 집는 순간의 손가락 힘 조절은 여전히 그리퍼 제어기가 맡는다.
피드백을 이용한 재계획
로봇의 세계는 항상 계획대로 흘러가지 않는다. 사람이 물건을 옮기고, 문이 닫히고, 조명이 바뀌고, 센서가 흔들리고, 바닥에 갑자기 장애물이 생긴다. 그래서 LLM 기반 로봇 에이전트에는 피드백 루프가 반드시 필요하다.
피드백 루프는 실행 결과를 다시 판단 계층으로 올려 보내는 구조다. 로봇이 목표 지점에 도착했는지, 물체를 찾았는지, 집기에 성공했는지, 충돌 위험이 있었는지, 사용자가 중간에 명령을 바꿨는지를 계속 확인한다. 성공하면 다음 단계로 넘어가고, 실패하면 이유를 분석해 재계획한다.
예를 들어 로봇이 "책상 위 노트북 옆에 있는 펜을 가져와"라는 명령을 수행하다가 펜을 찾지 못했다고 하자. 나쁜 시스템은 그냥 멈춘다. 조금 나은 시스템은 "펜을 찾지 못했습니다"라고 말한다. 더 좋은 시스템은 카메라 결과와 위치 정보를 바탕으로 이렇게 말할 수 있다.
"책상 위를 확인했지만 펜으로 인식된 물체가 없습니다. 다만 노트북 오른쪽에 검은색 길쭉한 물체가 일부 가려져 보입니다. 가까이 가서 다시 확인할까요?"
이런 재계획에는 LLM이 도움이 된다. 센서와 실행 모니터가 제공한 정보를 사람이 이해할 수 있는 설명으로 바꾸고, 가능한 다음 행동을 제안할 수 있기 때문이다. ROS-LLM 같은 연구에서도 사람과 환경의 피드백을 LLM 반영 과정에 활용해 장기 작업이나 원격 감독 상황에서 작업을 이어 가는 구조가 강조된다.3
다만 피드백을 LLM에게 넘긴다고 해서 모든 문제가 해결되는 것은 아니다. LLM이 상황을 잘못 이해할 수 있고, 센서 결과를 과신할 수 있으며, 실제로는 불가능한 재시도 방법을 제안할 수도 있다. 따라서 재계획 역시 실행 전 검증 단계를 거쳐야 한다.
안전 장치: 말 잘 듣는 로봇보다 안전한 로봇
자연어 로봇에서 가장 위험한 순간은 로봇이 사람의 말을 너무 잘 듣는 순간일 수 있다. 사용자가 장난으로 "앞에 있는 걸 밀어 버려"라고 말했을 때 로봇이 그대로 실행하면 안 된다. 사용자가 실수로 "문 밖으로 나가"라고 했는데 그 문 밖이 계단이라면 멈춰야 한다. LLM이 잘못된 도구 호출을 만들어 내거나, 권한 없는 명령을 실행하려 할 수도 있다.
따라서 LLM 로봇 에이전트에는 안전 장치가 여러 겹으로 들어가야 한다.
허용된 도구 목록: LLM은 등록된 기능만 호출할 수 있어야 한다. 없는 서비스나 위험한 내부 명령을 마음대로 만들면 안 된다.
명령 검증: 실행 전 계획이 로봇의 능력, 현재 상태, 안전 규칙에 맞는지 검사해야 한다.
권한 관리: 일반 사용자는 조회나 단순 이동만 가능하고, 위험한 조작이나 시스템 종료는 관리자 승인 후 실행되도록 할 수 있다.
인간 승인: 사람 근처에서 팔을 움직이거나 무거운 물체를 드는 작업은 실행 전 확인을 요구할 수 있다.
안전 모니터: LLM과 무관하게 충돌 위험, 과속, 과전류, 낙하 위험을 감시해야 한다.
비상 정지: 언제든 로봇을 즉시 멈출 수 있는 독립적인 수단이 있어야 한다.
로그와 감사 기록: 누가 어떤 명령을 내렸고, LLM이 어떤 도구를 호출했으며, 로봇이 무엇을 실행했는지 남겨야 한다.
이 중에서도 허용된 도구 목록과 명령 검증은 LLM 시대의 로봇에서 특히 중요하다. LLM은 때때로 존재하지 않는 함수 이름이나 그럴듯한 명령을 만들어 낸다. 텍스트 답변에서는 이것이 단순한 오류로 끝날 수 있지만, 로봇에서는 물리적 사고로 이어질 수 있다. 그래서 LLM의 출력은 곧바로 실행되어서는 안 된다. 반드시 "이 명령이 실제로 등록된 기능인가?", "이 매개변수는 허용 범위 안인가?", "현재 상태에서 실행해도 안전한가?"를 확인해야 한다.
ros2_lingua가 강조하는 '등록된 능력에 대한 검증'이나 '의존성 있는 실행 계획'은 바로 이런 문제의식과 맞닿아 있다.1 예를 들어 사용자가 "병을 집어 와"라고 했을 때 로봇이 안정화되어 있지 않다면, 먼저 stabilize_robot 같은 선행 작업을 자동으로 넣고 그다음 이동과 집기 작업을 수행하는 식이다. 이는 LLM이 만든 계획을 그대로 믿는 것이 아니라, 로봇의 상태와 능력 명세에 맞춰 다시 확인하는 접근이다.
로컬 LLM과 클라우드 LLM
LLM 로봇 에이전트를 만들 때 또 하나의 중요한 선택은 모델을 어디에서 실행할 것인가이다. 클라우드 LLM은 보통 성능이 좋고 복잡한 추론에 강하다. 하지만 인터넷 연결이 필요하고, 응답 지연이 생길 수 있으며, 민감한 센서 데이터나 작업 정보가 외부로 나갈 수 있다.
반대로 로컬 LLM은 로봇 내부 컴퓨터나 현장 서버에서 실행된다. 네트워크가 끊겨도 동작할 수 있고, 데이터가 외부로 나가지 않는다는 장점이 있다. 다만 로봇에 탑재된 컴퓨터는 전력과 메모리, 발열에 제한이 있기 때문에 큰 모델을 그대로 돌리기 어렵다. 그래서 모델의 크기를 줄이거나, 양자화라는 방법을 사용한다. 양자화는 모델의 숫자 표현을 더 가볍게 만들어 메모리와 계산량을 줄이는 기술이다.
llama_ros 같은 도구는 양자화된 LLM을 ROS2 시스템 안에서 실행할 수 있도록 연결하는 접근을 보여 준다. 이 도구는 llama.cpp 기반의 LLM 실행 기능을 ROS2 액션과 서비스 형태로 노출해, 로봇 시스템 내부에서 자연어 생성과 이해 기능을 활용할 수 있게 한다.4
실제 시스템에서는 둘을 섞어 쓰기도 한다. 빠르고 민감한 1차 명령 해석은 로컬 모델이 맡고, 복잡한 대화나 긴 설명은 클라우드 모델이 맡는 식이다. 하지만 어떤 방식을 쓰든 중요한 원칙은 같다. 모델이 어디서 실행되든, 안전과 저수준 제어는 로봇 내부의 확실한 시스템이 맡아야 한다.
LLM 에이전트는 두뇌인가, 인터페이스인가
많은 사람이 LLM을 로봇의 "두뇌"라고 부른다. 완전히 틀린 표현은 아니다. LLM은 목표를 이해하고, 계획을 세우고, 사람과 대화한다. 이전 세대 로봇에 비해 훨씬 지능적인 느낌을 준다.
하지만 입문 단계에서 더 정확한 비유는 "두뇌 전체"보다는 "언어 기반 인터페이스이자 계획 보조자"다. 로봇의 지능은 LLM 하나에 들어 있지 않다. 지도 작성, 위치 추정, 경로 계획, 행동 계획, 컴퓨터 비전, 모션 플래닝, 피드백 제어, 안전 감시가 함께 모여 로봇의 지능을 만든다. LLM은 그중 사람의 말과 로봇의 기능을 연결하는 강력한 층이다.
ROSA의 사례를 떠올려 보자. 자연어로 ROS 시스템의 토픽을 확인하고, 상태를 진단하고, 로봇을 조작할 수 있다는 점은 매우 유용하다.2 하지만 그것은 로봇의 모든 제어 루프를 LLM이 대체한다는 뜻이 아니다. 오히려 복잡한 ROS 시스템을 사람이 더 쉽게 이해하고 다룰 수 있게 해 주는 창구에 가깝다.
ROS-LLM도 마찬가지다. 자연어에서 행동을 추출하고, ROS 액션과 서비스로 실행하며, 행동 트리나 상태 기계 같은 구조를 활용한다.3 이는 기존 로봇공학을 버리고 LLM만으로 가자는 흐름이 아니다. 반대로 기존 로봇공학의 단단한 실행 구조 위에 LLM의 언어 이해 능력을 얹는 흐름이다.
따라서 앞으로의 AI 로봇을 이해할 때는 이렇게 생각하는 편이 좋다.
LLM은 로봇에게 말을 알아듣게 해 주지만, 로봇을 안전하게 움직이게 하는 것은 전체 시스템이다.
좋은 LLM 로봇 설계의 원칙
이제 이 장의 내용을 하나의 설계 원칙으로 정리해 보자. 말로 지시하는 로봇을 만들 때 가장 중요한 질문은 "LLM이 얼마나 똑똑한가?"만이 아니다. 더 중요한 질문은 "LLM이 틀렸을 때 시스템이 어떻게 안전하게 막는가?"이다.
좋은 LLM 로봇 에이전트는 먼저 로봇의 능력을 명확히 정의한다. 이동할 수 있는지, 팔을 쓸 수 있는지, 어떤 물체를 인식할 수 있는지, 어떤 공간에 들어갈 수 있는지, 어떤 명령은 금지되는지 분명히 해야 한다. 그런 다음 LLM에게 이 능력 목록을 알려 주고, LLM이 만든 계획이 그 목록 안에서만 실행되게 한다.
또한 좋은 시스템은 애매하면 되묻는다. "방으로 가"라고 했을 때 어느 방인지 모르면 질문해야 한다. "저 물건 가져와"라고 했을 때 물건이 여러 개라면 확인해야 한다. "빨리 와"라는 말이 안전 속도를 넘기라는 뜻은 아니므로, 속도 제한은 그대로 지켜야 한다.
마지막으로 좋은 시스템은 실패를 숨기지 않는다. 로봇은 실패할 수 있다. 중요한 것은 실패하지 않는 척하는 것이 아니라, 실패를 감지하고, 설명하고, 안전하게 다음 선택지를 제안하는 것이다. 이때 LLM은 매우 좋은 설명자가 될 수 있다. 복잡한 오류 코드와 센서 상태를 사람이 이해할 수 있는 언어로 바꿔 주기 때문이다.
다음으로 나아가기 전에
이 장까지 오면서 우리는 로봇을 이루는 큰 흐름을 거의 한 바퀴 돌았다. 로봇은 센서로 세상을 보고, 좌표계로 위치를 표현하고, 오차 속에서 자기 위치를 추정한다. 모터와 액추에이터로 움직이고, 제어로 흔들림을 줄이며, 지도와 경로 계획으로 목적지를 찾아간다. 행동 계획은 여러 작업을 순서로 묶고, 인공지능은 인식과 학습, 판단을 확장한다. 그리고 LLM은 사람의 말을 이 모든 시스템과 연결한다.
이제 남은 질문은 조금 다르다.
"그렇다면 우리는 로봇공학을 어떤 순서로 배워야 할까?"
수학부터 해야 할까, Python부터 해야 할까, ROS2를 먼저 설치해야 할까, 아니면 작은 바퀴 로봇을 만들어 보는 것이 좋을까? 다음 부에서는 로봇공학을 처음 배우는 사람이 길을 잃지 않도록 학습 로드맵을 그려 본다. 로봇이라는 넓은 세계를 센서, 제어, ROS2, SLAM, AI 로봇으로 어떻게 차근차근 밟아 갈 수 있는지 살펴볼 차례다.
참고
1ros2_lingua: Natural language to ROS2 actions
2ROSA: Robot Operating System Agent
3ROS-LLM: A ROS framework for embodied AI with task feedback and structured reasoning
4Integrating Quantized LLMs into Robotics Systems as Edge AI
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.