책에 포함된 노트AI 로봇 에이전트 만들기: 비전·로봇팔·학습·LLM으로 자연어 명령을 실행하는 로봇

LLM은 로봇에서 무엇을 할 수 있는가

2026-05-15Views 41약 11분생성형 AI 활용

Summary

이제 로봇은 말을 이해해야 한다

앞 장들에서 우리는 로봇이 세상을 보는 방법, 물체를 집는 방법, 시뮬레이션에서 행동을 학습하는 방법을 차례로 살펴보았다. 카메라는 픽셀을 좌표로 바꾸고, 로봇팔은 목표 자세로 움직이며, 강화학습 정책은 반복 경험을 통해 더 나은 행동을 찾는다. 이제 마지막 큰 조각이 남았다. 사람이 로봇에게 자연스럽게 말했을 때, 로봇은 그 말을 어떻게 행동으로 바꿀 것인가?

예를 들어 사용자가 이렇게 말한다고 해 보자.

책상 위에 있는 빨간 컵을 집어서 노트북 오른쪽에 놓아줘.

사람에게는 별로 어려운 말이 아니다. 하지만 로봇 입장에서는 이 한 문장 안에 여러 문제가 숨어 있다. '책상 위'가 어디인지 알아야 하고, '빨간 컵'이 어떤 물체인지 찾아야 하며, '노트북 오른쪽'이라는 상대적 위치를 계산해야 한다. 컵을 집을 수 있는지 확인해야 하고, 놓는 위치에 장애물이 없는지도 봐야 한다. 만약 컵이 보이지 않거나, 노트북 오른쪽에 다른 물건이 있으면 어떻게 할지도 정해야 한다.

여기서 LLM, 즉 대규모 언어 모델이 등장한다. LLM은 문장을 이해하고, 목표를 정리하고, 작업을 단계로 나누고, 필요한 도구를 고르는 데 강하다. 사람의 애매한 말을 로봇 시스템이 실행할 수 있는 형태로 바꾸는 번역기이자 계획자 역할을 할 수 있다.

하지만 중요한 점이 있다. LLM이 똑똑해 보인다고 해서 로봇의 모터를 직접 제어하게 하면 안 된다. LLM은 언어를 다루는 모델이지, 실시간 물리 제어기가 아니다. 로봇은 단어를 잘못 고르는 정도로 끝나지 않는다. 잘못 움직이면 컵을 깨뜨릴 수도 있고, 책상을 긁을 수도 있으며, 사람과 부딪힐 수도 있다.

이 장의 핵심은 단순하다.

LLM은 로봇에게 '무엇을 해야 하는지'와 '어떤 순서로 해야 하는지'를 알려주는 데 적합하다. 그러나 '모터를 몇 도씩 얼마나 빠르게 움직일지'를 직접 결정하는 데는 적합하지 않다.

LLM은 로봇에서 무엇을 할 수 있는가

LLM은 로봇의 두뇌인가, 통역사인가

많은 사람이 LLM을 로봇의 두뇌라고 표현한다. 틀린 말은 아니지만, 조금 더 정확하게 말하면 LLM은 로봇 시스템 안에서 '언어 기반 판단 계층'에 가깝다. 로봇의 전체 두뇌를 하나의 모델로 만들기보다는, 여러 모듈이 각자의 일을 하고 LLM은 그 사이에서 목표와 계획을 조율하는 역할을 맡는 편이 안전하고 현실적이다.

로봇 시스템에는 이미 여러 종류의 지능이 들어 있다. 카메라 모델은 물체를 찾고, 세그멘테이션 모델은 물체의 영역을 분리하고, MoveIt2 같은 경로 계획기는 충돌을 피하는 경로를 계산한다. 강화학습 정책은 특정 자세로 다가가거나 물체를 조심스럽게 밀어 넣는 행동을 학습할 수 있다. 이 모듈들은 각자 잘하는 일이 분명하다.

LLM은 이 모듈들을 대신하는 것이 아니라, 이 모듈들을 언제 어떤 순서로 사용할지 결정한다. 사람의 말을 듣고, 필요한 정보를 묻고, 실행 가능한 스킬을 골라 호출한다. 그래서 LLM을 '모든 것을 직접 하는 조종사'가 아니라 '상황을 읽고 작업을 배치하는 지휘자'로 보는 편이 좋다.

예를 들어 오케스트라 지휘자는 바이올린을 직접 켜지 않는다. 트럼펫을 직접 불지도 않는다. 하지만 언제 어떤 악기가 들어와야 하는지, 전체 흐름이 어떻게 이어져야 하는지 결정한다. 로봇 에이전트에서 LLM의 위치도 비슷하다. 물체 검출 모델, 경로 계획기, 그리퍼 제어기, 안전 제어기가 각각 악기라면 LLM은 이들을 묶어 하나의 작업으로 만드는 지휘자다.

자연어 이해: 말 속에서 목표를 꺼내기

LLM이 로봇에서 가장 먼저 할 수 있는 일은 자연어 명령을 이해하는 것이다. 여기서 이해란 철학적인 의미가 아니라, 로봇이 실행에 필요한 정보를 뽑아내는 실용적인 의미다.

사용자 명령에는 보통 목표, 대상, 위치, 제약 조건, 선호 조건이 섞여 있다. 사람은 이것을 자연스럽게 말하지만 로봇은 구조화된 정보가 필요하다.

다음 명령을 보자.

깨지기 쉬운 유리컵은 건드리지 말고, 파란 머그컵만 싱크대 옆으로 옮겨줘.

이 문장에서 로봇이 알아야 하는 정보는 여러 가지다.

목표: 파란 머그컵을 옮긴다.
대상: 파란 머그컵.
제외 대상: 깨지기 쉬운 유리컵.
목적지: 싱크대 옆.
제약 조건: 유리컵을 건드리지 않는다.
필요한 확인: 파란 머그컵과 유리컵을 구분할 수 있는가.

이 구조를 얻으면 이후 모듈이 일하기 쉬워진다. 객체 검출 모듈은 '파란 머그컵'을 찾고, 장소 인식 모듈은 '싱크대 옆'을 좌표로 바꾼다. 계획기는 컵을 집고 옮기는 순서를 만든다. 안전 모듈은 유리컵 주변을 위험 구역으로 표시할 수 있다.

LLM의 장점은 사용자가 꼭 정해진 명령어 형식으로 말하지 않아도 된다는 점이다. 사용자는 다음처럼 말할 수 있다.

저기 파란 컵 좀 치워줘.

이 짧은 문장에도 애매함이 많다. '저기'가 어디인지, '파란 컵'이 여러 개면 어느 것인지, '치워줘'가 어디로 옮기라는 뜻인지 불분명하다. 좋은 로봇 에이전트는 이럴 때 무작정 움직이지 않는다. LLM은 문장의 빈칸을 감지하고 되묻는 역할을 할 수 있다.

파란 컵이 두 개 보입니다. 왼쪽 컵을 옮길까요, 오른쪽 컵을 옮길까요?

또는 다음처럼 말할 수 있다.

컵을 어디로 옮기면 될까요? 휴지통 옆, 싱크대 옆, 또는 빈 공간 중 하나를 선택할 수 있습니다.

이런 대화 능력은 로봇을 훨씬 자연스럽게 만든다. 명령을 한 번에 완벽하게 입력해야 하는 시스템보다, 필요한 정보를 확인하며 함께 작업하는 로봇이 실제 환경에서 더 유용하다.

작업 분해: 한 문장을 여러 스킬로 나누기

LLM의 두 번째 역할은 복잡한 명령을 작은 작업으로 나누는 것이다. 로봇은 보통 '빨간 컵을 집어 오른쪽에 놓기'라는 명령을 한 번에 실행하지 않는다. 내부적으로는 여러 개의 스킬을 순서대로 호출한다.

예를 들어 다음 명령을 다시 보자.

빨간 컵을 집어서 노트북 오른쪽에 놓아줘.

LLM은 이 명령을 다음과 같은 실행 흐름으로 나눌 수 있다.

현재 장면을 인식한다.
빨간 컵을 찾는다.
노트북을 찾는다.
노트북 오른쪽의 빈 공간을 계산한다.
빨간 컵을 집을 수 있는 위치를 만든다.
로봇팔을 접근 자세로 이동한다.
그리퍼로 컵을 잡는다.
컵을 들어 올린다.
목표 위치로 이동한다.
컵을 내려놓는다.
그리퍼를 연다.
결과를 카메라로 확인한다.

여기서 중요한 점은 LLM이 모든 동작을 직접 계산하지 않는다는 것이다. LLM은 'detect_object', 'pick', 'place', 'check_status' 같은 고수준 스킬을 고른다. 실제 좌표 계산, 충돌 회피, 모터 제어는 각 전문 모듈이 담당한다.

이렇게 하면 시스템을 훨씬 안정적으로 만들 수 있다. LLM이 실수를 하더라도 스킬 서버와 안전 제어 계층이 잘못된 호출을 막을 수 있다. 예를 들어 LLM이 존재하지 않는 물체를 집으라고 계획하더라도, detect_object 스킬이 실패를 반환하면 실행은 다음 단계로 넘어가지 않는다. 로봇은 '대상을 찾을 수 없습니다'라고 말하고 멈출 수 있다.

작업 분해는 특히 명령이 길어질수록 중요해진다.

책상 위를 정리해줘. 빈 컵은 싱크대로 옮기고, 책은 책장 앞에 쌓아두고, 노트북은 그대로 둬.

이 명령에는 여러 대상과 여러 목적지가 있다. 게다가 '노트북은 그대로 둬'라는 금지 조건도 있다. LLM은 이런 문장을 해석해 작업 목록을 만들 수 있다. 하지만 실제 실행은 하나씩 확인하면서 진행해야 한다. 컵을 옮긴 뒤 다시 장면을 보고, 책을 옮긴 뒤 다시 확인한다. 물리 세계에서는 한 번 움직일 때마다 환경이 바뀌기 때문이다.

계획 생성: 실행 가능한 순서를 만드는 법

작업을 나누는 것과 실행 가능한 계획을 만드는 것은 비슷해 보이지만 조금 다르다. 작업 분해가 '무엇을 해야 하는가'를 쪼개는 과정이라면, 계획 생성은 '어떤 순서로 하면 안전하고 성공 가능성이 높은가'를 정하는 과정이다.

예를 들어 책상 위에 컵과 책, 휴대폰이 놓여 있다고 하자. 사용자가 컵을 오른쪽으로 옮기라고 했다. 단순히 컵을 집어 오른쪽에 놓으면 될 것 같지만, 오른쪽 공간이 책으로 막혀 있을 수 있다. 그러면 계획은 바뀌어야 한다.

먼저 오른쪽 공간을 확인한다. 공간이 비어 있으면 컵을 옮긴다. 공간이 막혀 있으면 사용자에게 물어보거나 다른 후보 위치를 찾는다. 만약 컵이 너무 가까이 벽에 붙어 있어 그리퍼가 접근하기 어렵다면, 다른 접근 방향을 시도해야 한다. 이런 판단이 계획 생성에 포함된다.

LLM 기반 계획은 보통 다음과 같은 정보를 입력으로 받는다.

사용자 명령: 사용자가 무엇을 원하는가.
장면 정보: 어떤 물체가 어디에 있는가.
사용 가능한 스킬 목록: 로봇이 실제로 무엇을 할 수 있는가.
제약 조건: 만지면 안 되는 물체, 안전 구역, 속도 제한 등.
이전 실행 결과: 방금 어떤 단계가 성공하거나 실패했는가.

LLM은 이 정보를 바탕으로 다음에 호출할 스킬을 결정한다. 좋은 계획기는 멋진 문장을 만드는 모델이 아니라, 현재 로봇이 실제로 할 수 있는 행동 안에서 다음 단계를 고르는 모델이다.

예를 들어 사용할 수 있는 스킬이 다음과 같다고 하자.

사용 가능한 스킬:
- detect_object(name)
- estimate_pose(object_id)
- pick(object_id, grasp_hint)
- place(target_pose)
- move_to(named_location)
- check_workspace(region)
- ask_user(question)
- stop(reason)

이때 LLM은 존재하지 않는 teleport_object 같은 마법 스킬을 호출하면 안 된다. 로봇 에이전트에서 LLM을 사용할 때는 반드시 '사용 가능한 스킬 목록'을 명확히 알려 주고, 그 범위 안에서만 계획하게 해야 한다. 이것은 단순한 구현 팁이 아니라 안전 설계의 핵심이다.

도구 호출: 말에서 함수 실행으로

LLM을 로봇 시스템에 연결할 때 가장 실용적인 방식 중 하나가 도구 호출이다. 도구 호출이란 LLM이 직접 로봇을 움직이는 대신, 정해진 함수나 서비스를 선택하고 필요한 인자를 채워 호출하는 방식이다.

사람이 보기에는 로봇이 말을 듣고 움직이는 것처럼 보인다. 하지만 내부에서는 이런 흐름이 일어난다.

사용자가 자연어 명령을 입력한다.
LLM이 명령을 해석한다.
LLM이 호출할 스킬과 파라미터를 만든다.
스킬 서버가 요청을 검증한다.
로봇 제어 모듈이 실제 동작을 실행한다.
실행 결과가 다시 LLM에 전달된다.
LLM이 다음 단계나 사용자 응답을 결정한다.

이 구조에서 LLM은 실행 버튼을 누르는 사람이 아니라, 실행 요청서를 작성하는 사람에 가깝다. 실제 실행 요청서가 올바른지 확인하고, 위험하면 거절하는 계층이 반드시 필요하다.

예를 들어 LLM이 다음과 같은 호출을 생성했다고 하자.

skill: detect_object
params:
  name: red_cup

객체 검출 스킬은 카메라 이미지에서 빨간 컵을 찾고 결과를 반환한다.

result:
  success: true
  object_id: obj_17
  confidence: 0.91
  bbox: [320, 180, 120, 160]

이 결과를 받은 LLM은 다음 단계를 고른다.

skill: pick
params:
  object_id: obj_17
  grasp_hint: top_grasp

하지만 만약 검출 결과가 실패라면 계획은 달라진다.

result:
  success: false
  reason: object_not_found

이때 LLM은 바로 pick을 호출하면 안 된다. 대신 카메라를 다시 확인하거나, 사용자에게 물어보거나, 작업을 중단해야 한다.

빨간 컵을 찾지 못했습니다. 컵을 카메라가 볼 수 있는 위치로 옮겨 주시겠어요?

이처럼 도구 호출은 LLM의 언어 능력과 로봇의 실행 능력을 연결하는 다리다. 다만 다리는 튼튼해야 한다. LLM이 만든 호출을 그대로 믿지 말고, 타입 검사, 범위 검사, 안전 검사, 실행 가능성 검사를 거쳐야 한다.

코드 생성: 편리하지만 조심해야 하는 능력

LLM은 코드 생성에도 강하다. 로봇 개발에서 이것은 꽤 유용하다. 예를 들어 ROS2 노드의 기본 구조를 만들거나, 센서 데이터를 로그로 저장하는 스크립트를 작성하거나, 반복되는 실험 설정 파일을 만드는 데 도움을 줄 수 있다.

개발자는 LLM에게 다음과 같이 요청할 수 있다.

ROS2에서 /camera/color/image_raw 토픽을 구독하고, 1초마다 이미지를 저장하는 Python 노드를 만들어줘.

또는 다음처럼 요청할 수도 있다.

pick 스킬의 성공률과 실패 원인을 CSV로 기록하는 로거 클래스를 작성해줘.

이런 작업에서 LLM은 생산성을 크게 높여 준다. 특히 로봇 프로젝트는 작은 연결 코드가 많다. 토픽 이름을 읽고, 메시지를 변환하고, 로그를 남기고, 파라미터를 불러오는 코드가 반복된다. LLM은 이런 접착 코드, 즉 여러 모듈을 이어 붙이는 코드를 빠르게 초안으로 만들 수 있다.

하지만 코드 생성도 그대로 믿으면 안 된다. LLM이 만든 코드는 실행되기 전에 사람이 검토해야 하고, 테스트를 통과해야 하며, 실제 로봇에 연결되기 전에는 시뮬레이션에서 먼저 확인해야 한다. 특히 모터 명령, 속도 제한, 안전 정지와 관련된 코드는 더 엄격해야 한다.

LLM이 만든 코드가 겉으로는 그럴듯해도 내부에 위험한 가정이 숨어 있을 수 있다. 예를 들어 좌표계 축을 반대로 해석하거나, 단위를 미터가 아니라 밀리미터로 착각하거나, 실패했을 때 예외 처리를 하지 않을 수 있다. 이런 실수는 일반 소프트웨어에서는 버그지만, 로봇에서는 물리적 사고가 될 수 있다.

따라서 LLM 코드 생성은 다음 영역에서 특히 유용하게 쓰는 것이 좋다.

실험용 스크립트 초안 작성.
로그 분석과 시각화 코드 작성.
ROS2 노드의 기본 구조 작성.
설정 파일과 테스트 코드 생성.
문서화와 주석 정리.

반대로 실제 로봇을 움직이는 핵심 제어 루프, 안전 정지 로직, 충돌 회피 로직은 사람이 설계하고 검증해야 한다. LLM이 도와줄 수는 있지만, 최종 책임을 맡겨서는 안 된다.

LLM이 직접 제어하면 왜 위험한가

이제 가장 중요한 질문으로 가 보자. LLM이 이렇게 똑똑하다면, 그냥 LLM에게 카메라 이미지를 주고 '모터를 제어해'라고 하면 안 될까?

답은 분명하다. 일반적인 로봇 시스템에서는 그렇게 하면 위험하다.

첫째, LLM은 실시간 제어에 맞춰 만들어진 모델이 아니다. 로봇의 저수준 제어는 매우 빠른 주기로 동작한다. 관절 속도 제어, 토크 제어, 균형 제어 같은 작업은 수십 헤르츠에서 수백 헤르츠, 때로는 그 이상으로 안정적으로 반복되어야 한다. 반면 LLM의 응답은 상대적으로 느리고 일정하지 않다. 네트워크 지연이 생길 수도 있고, 응답 시간이 매번 달라질 수도 있다. 로봇 제어에서 불규칙한 지연은 큰 문제다.

둘째, LLM은 숫자 정밀도와 물리 제약을 안정적으로 보장하지 않는다. 문장을 잘 만드는 능력과 관절 각도를 안전하게 계산하는 능력은 다르다. 로봇팔이 특정 물체를 피하면서 움직이려면 기구학, 동역학, 충돌 검사, 속도 제한을 모두 고려해야 한다. LLM이 그럴듯한 좌표를 말할 수는 있지만, 그 좌표가 실제로 도달 가능한지, 중간 경로에서 충돌하지 않는지 보장하지는 않는다.

셋째, LLM은 환각을 일으킬 수 있다. 환각이란 모델이 실제로는 없는 정보를 있는 것처럼 말하거나, 잘못된 내용을 확신 있게 출력하는 현상이다. 일반 대화에서는 틀린 설명으로 끝날 수 있지만, 로봇에서는 위험한 행동으로 이어질 수 있다.

예를 들어 카메라에 컵이 보이지 않는데 LLM이 '컵이 왼쪽에 있습니다'라고 판단했다고 해 보자. 로봇팔이 그 방향으로 움직이면 빈 공간을 향해 그리퍼를 닫을 수도 있고, 근처의 다른 물건을 칠 수도 있다. 또는 사람이 작업 공간에 손을 넣었는데 LLM이 이를 인식하지 못하고 다음 동작을 계속 지시할 수도 있다.

넷째, LLM은 안전 책임을 질 수 없다. 로봇 제어는 항상 '잘했는가'보다 '위험하지 않은가'를 먼저 따져야 한다. LLM의 계획이 아무리 그럴듯해도, 안전 제어 계층은 독립적으로 존재해야 한다. 속도 제한, 힘 제한, 작업 공간 제한, 비상 정지, 충돌 감지는 LLM보다 아래 계층에서 강제되어야 한다.

결론은 명확하다. LLM은 고수준 계획자와 대화 인터페이스로 사용하고, 저수준 제어는 검증된 제어기와 로봇 소프트웨어가 담당해야 한다.

좋은 역할 분담: LLM과 로봇 제어기의 경계

안전한 로봇 에이전트를 만들려면 역할 분담이 분명해야 한다. LLM에게 맡길 일과 맡기지 말아야 할 일을 구분해야 한다.

LLM에게 맡기기 좋은 일은 다음과 같다.

사용자의 자연어 명령을 구조화하기.
목표, 대상, 위치, 제약 조건을 추출하기.
복잡한 작업을 여러 단계로 나누기.
사용 가능한 스킬 중 적절한 것을 선택하기.
실패 결과를 해석하고 다음 행동을 제안하기.
사용자에게 확인 질문을 만들기.

반대로 LLM에게 직접 맡기면 위험한 일도 있다.

관절 토크나 모터 PWM을 직접 생성하기.
충돌 검사를 건너뛰고 좌표를 바로 실행하기.
센서 확인 없이 물체 위치를 추측하기.
안전 구역 침범 여부를 단독으로 판단하기.
사람 주변에서 속도와 힘 제한을 무시하고 움직이기.
실패한 동작을 무제한 반복하기.

이 경계를 지키면 LLM은 강력한 도구가 된다. 로봇은 자연어를 이해하고, 여러 스킬을 조합하고, 실패했을 때 대화로 복구할 수 있다. 반대로 이 경계를 무시하면 LLM은 위험한 자동 조종 장치가 된다.

실전 시스템에서는 보통 다음과 같은 계층 구조를 사용한다.

사용자
  ↓
LLM 에이전트: 명령 이해, 계획 생성, 도구 선택
  ↓
스킬 서버: pick, place, detect, navigate 같은 기능 제공
  ↓
계획기와 제어기: 경로 계획, 충돌 회피, 속도 제어
  ↓
안전 계층: 제한 구역, 비상 정지, 힘 제한, 사람 감지
  ↓
로봇 하드웨어

이 구조의 핵심은 LLM이 로봇 하드웨어에 직접 닿지 않는다는 것이다. LLM은 요청을 만들고, 아래 계층은 그 요청이 가능한지 확인한 뒤 실행한다. 이때 모든 실행 결과는 다시 위로 올라간다. 성공했는지, 실패했는지, 왜 실패했는지가 LLM에게 전달되어야 다음 계획을 세울 수 있다.

불확실성을 말하는 로봇

좋은 LLM 로봇 에이전트는 모르는 것을 모른다고 말할 수 있어야 한다. 실제 환경은 애매함으로 가득하다. 조명이 어두울 수도 있고, 물체가 서로 겹쳐 있을 수도 있으며, 사용자의 표현이 불분명할 수도 있다.

예를 들어 사용자가 이렇게 말한다.

저 컵 좀 가져와.

카메라에는 컵이 세 개 보인다. 빨간 컵, 흰 컵, 투명 컵이 있다. 이때 로봇이 마음대로 하나를 고르면 안 된다. 더 나은 반응은 다음과 같다.

컵이 세 개 보입니다. 빨간 컵, 흰 컵, 투명 컵 중 어떤 컵을 가져올까요?

또는 객체 검출 신뢰도가 낮을 때는 이렇게 말할 수 있다.

컵으로 보이는 물체를 찾았지만 확신이 낮습니다. 다시 확인한 뒤 진행하겠습니다.

이런 응답은 로봇을 덜 똑똑하게 보이게 만드는 것이 아니라, 오히려 더 믿을 수 있게 만든다. 사람도 확실하지 않으면 확인한다. 로봇이 불확실성을 표현할 수 있어야 실제 환경에서 안전하게 일할 수 있다.

LLM은 이런 대화형 확인에 강하다. 단순히 실패 코드를 출력하는 대신, 사람이 이해할 수 있는 문장으로 상황을 설명할 수 있다.

object_not_found라는 결과를 사용자는 알 필요가 없다. 대신 로봇은 이렇게 말하면 된다.

요청하신 빨간 컵을 찾지 못했습니다. 컵이 다른 물체 뒤에 가려져 있을 수 있습니다.

path_blocked라는 결과도 마찬가지다.

컵까지 가는 경로가 막혀 있습니다. 앞에 있는 상자를 먼저 치울까요?

이처럼 LLM은 로봇의 내부 상태와 사람의 언어 사이를 이어 준다. 로봇이 단순히 움직이는 기계가 아니라, 상황을 설명하고 협력하는 파트너처럼 느껴지는 이유가 여기에 있다.

실패 결과를 읽고 다음 행동을 고르기

로봇 작업은 자주 실패한다. 컵을 집으려 했는데 미끄러질 수 있고, 물체가 카메라에서 사라질 수 있으며, 경로 계획이 실패할 수도 있다. 이전 장들에서 우리는 실패 감지와 재시도 전략의 중요성을 여러 번 다루었다. LLM은 여기서 상위 수준의 복구 계획을 만드는 데 도움을 줄 수 있다.

예를 들어 pick 스킬이 다음과 같은 결과를 반환했다고 하자.

success: false
stage: grasp
reason: object_slipped

LLM은 이 결과를 읽고 다음 선택지를 만들 수 있다. 같은 위치에서 다시 집기, 다른 grasp 후보를 사용하기, 물체를 더 잘 보이게 카메라 각도를 바꾸기, 사용자에게 도움을 요청하기 같은 선택이 가능하다.

하지만 여기서도 무제한 재시도는 금물이다. 로봇은 실패할 때마다 주변을 어지럽힐 수 있다. 컵을 계속 밀다가 책상 밖으로 떨어뜨릴 수도 있다. 따라서 재시도 횟수, 힘 제한, 위험 물체 주변 동작 제한은 시스템 규칙으로 정해 두어야 한다.

좋은 복구 흐름은 다음처럼 설계할 수 있다.

1차 실패: 다른 집기 후보로 재시도
2차 실패: 카메라 재인식 후 자세 보정
3차 실패: 사용자에게 상황 설명 후 중단 또는 도움 요청

LLM은 이 규칙 안에서 자연스러운 대화를 만들 수 있다.

컵을 한 번 잡았지만 미끄러졌습니다. 다른 방향에서 다시 시도하겠습니다.

두 번째 시도에서도 컵을 안정적으로 잡지 못했습니다. 컵 표면이 미끄럽거나 위치가 불안정할 수 있습니다. 계속 진행할까요?

이런 방식은 로봇이 실패를 숨기지 않고, 실패를 작업의 일부로 다룬다는 점에서 중요하다. 실제 로봇은 완벽하지 않다. 그래서 좋은 에이전트는 성공만 계획하는 시스템이 아니라, 실패 후 복구까지 계획하는 시스템이어야 한다.

LLM 로봇 에이전트의 기본 루프

이제 LLM이 로봇에서 어떤 일을 할 수 있는지 하나의 루프로 정리해 보자. 자연어 명령 로봇은 보통 다음 흐름으로 동작한다.

사용자 명령 입력
  ↓
명령 해석: 목표, 대상, 제약 조건 추출
  ↓
현재 상태 확인: 카메라, 지도, 로봇 상태 읽기
  ↓
계획 생성: 실행할 스킬 순서 결정
  ↓
도구 호출: detect, pick, place, navigate 등 호출
  ↓
실행 결과 확인: 성공, 실패, 불확실성 판단
  ↓
재계획 또는 사용자에게 질문
  ↓
작업 완료 보고

이 루프에서 LLM은 매번 전체 계획을 다시 생각할 수도 있고, 한 단계씩 다음 행동만 선택할 수도 있다. 실전에서는 한 번에 긴 계획을 모두 세우기보다, 실행 결과를 보며 조금씩 진행하는 방식이 더 안전하다. 물리 세계에서는 계획이 항상 틀어지기 때문이다.

예를 들어 처음에는 컵이 책상 중앙에 있었지만, 로봇이 접근하는 동안 컵이 살짝 밀릴 수 있다. 그러면 처음 계산한 좌표는 더 이상 맞지 않는다. 따라서 중요한 단계마다 다시 인식하고, 다시 확인하고, 필요하면 계획을 수정해야 한다.

이것이 LLM 로봇 에이전트의 핵심이다. LLM은 한 번 멋진 계획을 만들고 끝나는 모델이 아니다. 환경을 확인하고, 실행하고, 결과를 읽고, 다시 계획하는 반복 루프 안에서 사용되어야 한다.

작은 예제: '책상 위를 정리해줘'

마지막으로 조금 더 생생한 예제를 보자. 사용자가 로봇에게 말한다.

책상 위를 정리해줘. 컵은 싱크대 옆에 두고, 책은 왼쪽으로 쌓아줘. 휴대폰은 건드리지 마.

LLM은 먼저 명령을 구조화한다.

목표: 책상 정리
대상 1: 컵
컵 목적지: 싱크대 옆
대상 2: 책
책 목적지: 책상 왼쪽 쌓기 영역
금지 대상: 휴대폰
제약 조건: 휴대폰과 충돌하거나 집지 않는다

그다음 현재 장면을 확인해야 한다.

call: detect_object(name=cup)
call: detect_object(name=book)
call: detect_object(name=phone)
call: check_workspace(region=desk)

만약 휴대폰이 책 바로 옆에 있다면, 책을 집을 때 휴대폰을 건드릴 위험이 있다. 그러면 LLM은 바로 책을 집으라고 하지 않고 안전한 순서를 선택해야 한다. 예를 들어 컵을 먼저 옮긴 뒤, 책 주변의 여유 공간을 다시 확인할 수 있다. 또는 사용자에게 휴대폰을 먼저 치워 달라고 요청할 수도 있다.

계획:
1. 컵 위치 확인
2. 싱크대 옆 빈 공간 확인
3. 컵 집기 및 이동
4. 책 위치와 휴대폰 위치 재확인
5. 책을 집을 수 있는지 판단
6. 안전하면 책을 왼쪽으로 이동
7. 휴대폰이 너무 가까우면 사용자에게 확인 요청

이 예제에서 LLM은 사람의 말을 이해하고, 여러 물체 사이의 관계를 정리하고, 작업 순서를 만든다. 그러나 컵을 실제로 집는 순간에는 로봇팔 제어기, 그리퍼 제어기, 충돌 회피 계획기, 안전 필터가 일을 한다. LLM은 그 위에서 전체 흐름을 관리한다.

이 역할 분담이 바로 자연어 명령 로봇의 현실적인 설계다.

다음으로 넘어가기 전에

LLM은 로봇을 훨씬 자연스럽고 유연하게 만든다. 사용자는 더 이상 버튼과 메뉴만으로 로봇을 조작하지 않아도 된다. '빨간 컵을 오른쪽에 놓아줘', '회의실 앞으로 가줘', '책상 위를 정리해줘'처럼 사람의 언어로 목표를 말할 수 있다.

하지만 LLM이 할 수 있는 일과 해서는 안 되는 일을 구분해야 한다. LLM은 자연어를 이해하고, 작업을 나누고, 계획을 만들고, 도구 호출 형식을 생성하는 데 강하다. 반면 저수준 모터 제어, 충돌 회피, 안전 정지, 힘 제한 같은 일은 검증된 로봇 제어 계층이 맡아야 한다.

이 장에서 기억할 문장은 하나다.

LLM은 로봇에게 생각의 방향을 제시할 수 있지만, 로봇의 몸을 직접 휘두르게 해서는 안 된다.

다음 장에서는 이 관점을 바탕으로 자연어 명령을 실제 작업 순서로 바꾸는 방법을 더 구체적으로 살펴본다. 사용자의 말에서 목표를 추출하고, 조건을 파악하고, 예외 상황까지 포함한 실행 계획을 만드는 과정을 단계별로 다룰 것이다.

책 목록

AI 로봇 에이전트 만들기: 비전·로봇팔·학습·LLM으로 자연어 명령을 실행하는 로봇

전체 목차 보기