17. LLM은 로봇의 뇌가 될 수 있을까?

로봇 이야기를 하다 보면 요즘 가장 자주 듣는 문장이 있습니다. "이제 LLM만 붙이면 로봇이 알아서 생각하고 움직이는 거 아닌가요?" 언뜻 보면 그럴듯합니다. LLM은 사람의 말을 꽤 잘 이해하고, 긴 문장을 요약하고, 해야 할 일을 순서대로 정리하는 데도 능합니다. 게다가 API 몇 줄만 연결하면 로봇이 말을 듣고 대답하는 장면까지 금방 만들 수 있습니다.

하지만 여기서 중요한 구분이 하나 있습니다. 말을 잘 이해하는 것과, 안전하게 몸을 움직이는 것은 전혀 다른 문제라는 점입니다. 로봇은 화면 속 앱이 아닙니다. 바퀴가 벽에 부딪힐 수 있고, 로봇팔이 예상과 다르게 흔들릴 수 있으며, 센서가 잠깐 잘못 읽은 값 때문에 위험한 동작이 나올 수도 있습니다. 그래서 LLM을 로봇의 만능 두뇌로 보는 시선은 반쯤 맞고, 반쯤 틀립니다.

이 장의 목표는 간단합니다. LLM에 대한 환상을 줄이는 대신, 실제로 어디에 쓰면 강력한지 분명하게 잡는 것입니다. 결론부터 말하면, LLM은 로봇의 "전부"가 되기 어렵지만, 로봇 시스템 안에서 아주 유능한 "고수준 사고 계층"이 될 수 있습니다.¹²

왜 사람들은 LLM을 로봇의 뇌라고 부를까

그 이유는 분명합니다. LLM은 자연어를 다룹니다. 즉, 사람이 평소 하듯이 "거실을 한번 둘러보고 문 앞에 박스가 있으면 알려줘"라고 말하면, 그 문장을 기계 명령으로 바꾸는 데 강합니다. 예전에는 이런 일을 하려면 명령어 체계를 따로 설계하고, 문법을 정하고, 예외 규칙을 잔뜩 만들어야 했습니다. 이제는 LLM이 그 틈을 많이 메워 줍니다.

특히 ROS와 결합한 최근 프레임워크들은 자연어로 작업을 설명하면, 이를 로봇 액션과 서비스 호출 형태로 바꾸는 방향으로 발전하고 있습니다. 어떤 연구는 LLM이 긴 작업을 순서형 실행, 상태 머신, 비헤이비어 트리 같은 구조로 정리하도록 돕는 방식을 제안했고, 오픈소스 프로젝트들은 비교적 짧은 시간 안에 ROS 기반 로봇에 자연어 인터페이스를 붙일 수 있게 만들었습니다.¹²

이 말은 곧, LLM이 로봇에게 새로운 종류의 "입"과 "귀", 그리고 어느 정도의 "기획 능력"을 제공한다는 뜻입니다. 문제는 여기서 많은 사람이 한 걸음 더 나아가, 그 기획 능력이 곧바로 실시간 운동 제어까지 해결해 줄 것이라 기대한다는 점입니다. 바로 그 지점에서 현실과 기대가 갈라집니다.

LLM이 로봇에서 정말 잘하는 일

LLM의 가장 큰 강점은 고수준 해석과 계획입니다. 쉽게 말해, "무슨 뜻인지 알아듣고", "무엇부터 할지 정하고", "상황을 말로 설명하는 일"입니다.

첫째, 명령 해석에 강합니다. 사용자가 "책상 위 컵이 어디 있는지 보고, 있으면 사진 찍어서 알려줘"라고 말했을 때, LLM은 이 문장을 여러 단계의 작업으로 쪼갤 수 있습니다. 컵 탐지, 위치 확인, 사진 촬영, 결과 보고 같은 흐름으로 바꾸는 식입니다.

둘째, 애매한 지시를 다루는 데 유용합니다. 사람은 늘 정확하게 말하지 않습니다. "저기 좀 치워줘" 같은 말에는 대상도, 위치도, 성공 조건도 빠져 있습니다. 이때 LLM은 곧바로 움직이는 대신 "어떤 물체를 치울까요?" 또는 "책상 왼쪽 서류를 말하시는 건가요?"처럼 되묻는 인터페이스를 만들기에 좋습니다. 로봇이 덜 멍청해 보이는 순간이 바로 여기입니다.

셋째, 작업 계획을 세우는 데 강합니다. 예를 들어 "순찰하고 이상이 있으면 알려줘"라는 지시를 받으면, LLM은 순찰 경로 시작, 카메라 확인, 특정 객체 탐지, 결과 요약 같은 상위 단계 계획을 만들 수 있습니다. 이때 실제 이동과 인식은 각각 내비게이션 스택, 비전 모델, 센서 노드가 담당하고, LLM은 이들을 조합하는 관리자 역할을 맡는 편이 가장 현실적입니다.¹⁵

넷째, 도구 호출에 적합합니다. 로봇 세계에서 도구란 함수, API, ROS 액션, 서비스 같은 것입니다. LLM은 "문 열림 상태 확인" 함수를 부르고, "목표 위치로 이동" 액션을 실행하고, "현재 배터리 잔량 조회" 서비스를 부르는 식의 오케스트레이션, 즉 여러 기능을 지휘하는 데 꽤 잘 맞습니다.²

다섯째, 설명과 보고가 뛰어납니다. 로봇이 왜 멈췄는지, 지금 무엇을 하려는지, 다음 단계가 무엇인지 사람에게 자연스럽게 설명하는 일은 LLM의 장기입니다. 이것은 생각보다 중요합니다. 로봇은 잘 움직이는 것도 중요하지만, 사람이 이해할 수 있게 행동을 설명해야 신뢰를 얻기 때문입니다.

LLM이 로봇에서 잘 못하는 일

이제 냉정하게 보겠습니다. LLM은 똑똑해 보여도, 로봇의 모든 문제를 풀어 주지는 않습니다.

가장 먼저, 실시간 제어에 약합니다. 로봇의 제어 계층은 몇 밀리초, 더 짧게는 서브밀리초 단위로 센서를 읽고 모터 출력을 갱신해야 하는 경우가 많습니다. 이런 계층에서는 계산 결과가 맞는 것만큼이나 "정해진 시간 안에 반드시 나오는 것"이 중요합니다. 일반적인 LLM 호출은 이런 종류의 시간 보장을 제공하지 못합니다. 네트워크 지연, 토큰 생성 시간, 시스템 부하에 따라 응답이 흔들릴 수 있기 때문입니다.³

둘째, 연속적인 모션 제어에 적합하지 않습니다. 로봇팔이 컵을 집을 때는 관절 각도, 속도, 가속도, 때로는 저크까지 고려해야 합니다. MoveIt 같은 도구가 시간 매개변수화와 속도·가속도 제한, 스무딩을 별도로 다루는 이유가 여기에 있습니다. 이런 영역은 문장 생성 문제가 아니라, 운동학과 동역학, 제약 조건을 다루는 제어 문제입니다.⁴

셋째, 세계를 정확히 안다고 가정하면 위험합니다. LLM은 센서를 직접 믿을 수 있는 형태로 이해하지 못합니다. 카메라가 본 물체가 정말 컵인지, 거리가 몇 센티미터인지, 손이 닿는 범위 안에 있는지 같은 문제는 비전 모델, 깊이 센서, 좌표 변환, 충돌 검사로 따져야 합니다. LLM은 이 정보를 받아 해석할 수는 있어도, 그 자체가 정확한 측정 장비는 아닙니다.

넷째, 안전 판단을 단독으로 맡기기 어렵습니다. "사람이 가까우면 멈춰" 같은 문장은 쉬워 보여도, 실제 시스템은 거리 계산, 정지 시간, 제동 거리, 장애 감지 지연, 고장 감지 같은 요소를 포함한 결정론적 안전 구조가 필요합니다. 최근 연구들도 LLM을 안전 규칙 해석이나 정형화 보조에 사용할 수는 있다고 보지만, 실제 실행은 저지연·중복·감시 구조 위에서 이뤄져야 한다고 강조합니다.⁶

다섯째, 그럴듯한 틀린 답을 만들 수 있습니다. LLM은 없는 함수 이름을 지어내거나, 존재하지 않는 센서 값을 가정하거나, 로봇이 할 수 없는 행동을 자신 있게 제안할 수 있습니다. 사람과 채팅할 때는 웃고 넘길 수 있지만, 로봇에서는 바닥에 떨어진 물건보다 더 큰 문제가 될 수 있습니다. 잘못된 계획은 곧 물리적 오류가 되기 때문입니다.

그러면 LLM은 로봇의 어디에 있어야 할까

가장 좋은 비유는 이것입니다. LLM은 로봇의 손발이 아니라, "상황을 이해하고 지시를 정리하는 기획자"에 가깝습니다.

로봇 시스템을 층으로 나누면 이해가 쉽습니다.

• 아래층은 실시간 제어 계층입니다. 모터 드라이버, MCU, 서보 루프, PID, 충돌 회피, 긴급 정지 같은 것들이 있습니다.

• 가운데층은 기능 실행 계층입니다. 내비게이션, 물체 인식, 경로 계획, 그리퍼 제어, 상태 추정 같은 모듈이 여기에 있습니다.

• 위층은 고수준 추론 계층입니다. 사용자 명령 해석, 작업 분해, 우선순위 결정, 예외 설명, 보고 생성이 이 층의 일입니다.³⁵

LLM은 이 셋 중 맨 위층에 놓을 때 가장 빛납니다. NVIDIA도 피지컬 AI 스택을 설명할 때 실시간 제어, 인식 및 계획, 고차원 추론을 분리해서 봅니다. 즉, "생각하는 층"과 "즉시 반응하는 층"은 같은 컴퓨터 안에 있을 수는 있어도, 같은 방식으로 동작해서는 안 된다는 뜻입니다.⁵

이 구분을 이해하면 많은 혼란이 사라집니다. LLM이 로봇의 뇌가 될 수 있느냐는 질문에 대한 더 정확한 대답은 이렇습니다. "로봇 전체의 뇌"는 아니지만, "언어와 계획을 담당하는 전두엽 비슷한 역할"은 할 수 있습니다.

현실적인 아키텍처: LLM에게는 계획을, 제어기에는 제어를

개인 개발자가 가장 실용적으로 가져갈 수 있는 구조는 다음과 같습니다.

사용자가 자연어로 명령을 내리면, LLM이 먼저 의도를 해석합니다. 그다음 로봇이 실제로 가진 기능 목록을 바탕으로 실행 가능한 계획을 만듭니다. 이 계획은 자유로운 문장이 아니라, 가능한 한 구조화된 형태여야 합니다. 예를 들어 JSON, 함수 호출, 액션 목록, 상태 머신, 비헤이비어 트리 같은 방식이 좋습니다.¹²

그다음 단계가 중요합니다. 계획이 만들어졌다고 바로 실행하면 안 됩니다. 반드시 검증기가 끼어들어야 합니다. 목표 좌표가 유효한지, 해당 행동이 현재 배터리 상태에서 가능한지, 카메라 인식 결과의 신뢰도가 충분한지, 사람 접근 시 정지 규칙을 어기지 않는지 확인해야 합니다. 이 검증기가 일종의 문지기 역할을 합니다.

그 후에야 실제 로봇 모듈이 움직입니다. 이동은 내비게이션 스택이, 팔 동작은 모션 플래너가, 그리퍼는 저수준 컨트롤러가 담당합니다. 실행 중에는 다시 피드백이 올라옵니다. "목표 물체를 찾지 못함", "경로 막힘", "집기 실패" 같은 결과를 받으면, 그때 LLM이 재계획하거나 사용자에게 질문을 돌려보냅니다.

짧게 쓰면 이런 흐름입니다.

사용자 명령 → LLM 의도 해석 → 구조화된 계획 생성 → 안전·실행 가능성 검증 → 로봇 모듈 실행 → 결과 피드백 → 필요 시 재계획

이 구조의 장점은 명확합니다. LLM이 잘하는 일과 못하는 일을 분리할 수 있습니다. 말은 LLM이 알아듣고, 몸은 제어기가 움직입니다. 둘을 섞어 놓지 않는 것이 핵심입니다.

예제로 보는 좋은 역할 분담

사용자가 이렇게 말한다고 해봅시다.

"책상 위에서 빨간 컵을 찾아서, 있으면 집어서 오른쪽 트레이에 놓아줘."

이때 LLM이 해야 할 일은 다음과 같습니다. 먼저 명령의 목표를 이해합니다. 대상은 빨간 컵이고, 성공 조건은 오른쪽 트레이에 놓는 것입니다. 그리고 작업을 단계로 나눕니다. 컵 탐지, 위치 확인, 접근, 집기, 트레이 이동, 내려놓기 순서로 계획을 세우는 식입니다.

하지만 여기서부터는 LLM의 차례가 아닙니다. 컵을 찾는 것은 카메라와 비전 모델의 일입니다. 로봇팔이 컵까지 어떻게 갈지는 역기구학과 모션 플래너의 일입니다. 잡는 힘을 얼마나 줄지는 그리퍼 제어와 센서 피드백의 문제입니다. 사람 손이 갑자기 작업 공간에 들어오면 멈추는 것은 안전 로직의 일입니다.

LLM이 이 모든 것을 직접 하려고 들면 시스템은 불안정해집니다. 반대로 LLM이 "무엇을 해야 하는지"만 정리하고, 각 전문 모듈이 "어떻게 할지"를 맡으면 훨씬 강하고 안전한 로봇이 됩니다.

개인 개발자가 흔히 빠지는 오해

LLM을 로봇에 붙일 때 초보자가 자주 하는 오해는 몇 가지로 정리할 수 있습니다.

• LLM이 똑똑하니 센서 오차도 알아서 보정해 줄 것이라고 기대한다.

• 프롬프트를 잘 쓰면 제어 알고리즘을 대체할 수 있다고 생각한다.

• 로봇 기능 목록이 불완전한데도 자연어만 넣으면 새 능력이 생긴다고 믿는다.

• 안전 문제를 "상식적인 답변"으로 해결할 수 있다고 착각한다.

하지만 로봇은 결국 물리 시스템입니다. 바퀴는 마찰을 받고, 배터리는 떨어지고, 카메라는 역광에서 흔들리고, 모터는 발열합니다. LLM은 이런 현실을 말로 설명할 수는 있어도, 물리 법칙을 건너뛰게 해주지는 않습니다.

그래서 좋은 질문은 "LLM으로 로봇을 다 만들 수 있을까?"가 아닙니다. "LLM을 어디에 넣으면 개발 속도와 사용성이 가장 크게 좋아질까?"입니다. 이 질문으로 바꾸는 순간 답이 훨씬 현실적이 됩니다.

지금 당장 써먹을 수 있는 현실적인 활용법

개인 개발자에게 특히 효과적인 LLM 활용법은 세 가지입니다.

첫째, 자연어 인터페이스입니다. 키보드나 음성으로 명령을 내리고, 로봇이 실행 가능한 액션으로 변환하게 하세요. 이것만으로도 프로젝트의 체감 완성도가 크게 올라갑니다.

둘째, 작업 플래너입니다. 복잡한 명령을 단계별 작업으로 나누고, 실패했을 때 대안을 제시하게 하세요. 예를 들어 물체를 찾지 못하면 "카메라 각도를 바꿔 다시 탐색" 같은 재시도를 설계할 수 있습니다.

셋째, 설명기이자 운영 비서입니다. 현재 상태 요약, 오류 설명, 로그 요약, 사용자에게 되묻기 같은 기능은 LLM이 특히 잘합니다. 로봇이 갑자기 멈췄을 때 "모터 고장"보다 "전방 40cm에 장애물이 있어 일시 정지했고, 우회 경로를 계산 중입니다"라고 말해 주면 사용 경험이 훨씬 좋아집니다.

이 세 가지는 비교적 적은 비용으로 구현할 수 있고, 잘못 설계해도 바로 위험한 제어 문제로 이어질 가능성이 낮습니다. 개인 프로젝트라면 여기서 시작하는 것이 현명합니다.

이 장의 결론

LLM은 로봇의 뇌가 될 수 있을까요? 대답은 "부분적으로는 그렇다"입니다.

LLM은 사람의 말을 이해하고, 의도를 해석하고, 작업을 계획하고, 결과를 설명하는 데 매우 강합니다. 그래서 로봇의 고수준 인터페이스와 계획 계층에서는 강력한 도구가 됩니다. 하지만 실시간 제어, 정밀한 모션 생성, 센서 기반 안전 판단, 결정론적 응답 보장이 필요한 계층에서는 여전히 전통적인 제어기와 전문 로봇 소프트웨어가 중심이어야 합니다.³⁴⁶

즉, LLM은 로봇의 만능 두뇌가 아니라, "말을 이해하는 기획자"이자 "작업 관리자"로 보는 편이 정확합니다. 그리고 바로 그 자리에 둘 때, 가장 실용적이고 가장 강력합니다.

다음 장에서는 이 관점을 바탕으로, 생각하는 AI와 움직이는 로봇을 어떻게 분리해서 설계해야 하는지 더 구체적으로 살펴보겠습니다. 이제부터 진짜 중요한 질문은 이것입니다. "LLM을 붙일까?"가 아니라, "어디까지 맡기고 어디서부터 제어기가 책임질까?"입니다.

참고

¹ROS-LLM: A ROS framework for embodied AI with task feedback and structured reasoning

²ROS-LLM GitHub 프로젝트 소개

³Real-Time Control Systems in Robotics Architecture

⁴Time Parameterization — MoveIt Documentation

⁵피지컬 AI를 위한 궁극의 플랫폼 NVIDIA Jetson Thor을 소개합니다

⁶LLM-Guided Safety Agent for Edge Robotics with an ISO-Compliant Perception-Compute-Control Architecture