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

AI 로봇 에이전트의 구조

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

Summary

로봇 에이전트는 하나의 모델이 아니라 하나의 시스템이다

AI 로봇 에이전트라고 하면 거대한 인공지능 모델 하나가 카메라를 보고, 생각하고, 팔을 움직이고, 실패까지 알아서 고치는 모습을 떠올리기 쉽다. 영화 속 로봇이라면 그렇게 보일 수 있다. 하지만 실제 로봇 시스템은 그렇게 단순하지 않다. 로봇은 물리 세계에서 움직인다. 카메라에는 노이즈가 끼고, 물체는 미끄러지며, 사람은 갑자기 로봇 앞을 지나간다. 바닥은 완벽히 평평하지 않고, 로봇팔의 관절은 명령한 각도에 아주 미세하게 늦게 도착한다.

그래서 좋은 AI 로봇 에이전트는 "똑똑한 모델 하나"보다 "잘 나뉜 구조"에 가깝다. 카메라로 보는 부분, 명령을 해석하는 부분, 경로를 계획하는 부분, 모터를 움직이는 부분, 실패를 감지하는 부분, 위험한 행동을 막는 부분이 서로 연결되어야 한다. 마치 레스토랑이 셰프 한 명만으로 돌아가지 않고 주문 접수, 재료 준비, 조리, 서빙, 계산, 안전 관리가 함께 움직이는 것과 같다.

AI 로봇 에이전트의 기본 흐름은 다음과 같이 볼 수 있다.

인식 모듈은 카메라와 센서로 환경을 읽고 물체, 위치, 상태를 파악한다.
계획 모듈은 사용자의 목표를 로봇이 수행할 수 있는 작업 순서로 바꾼다.
실행 모듈은 MoveIt2, Navigation, 그리퍼 제어 같은 실제 로봇 기능을 호출한다.
피드백 모듈은 실행 결과를 확인하고 성공인지 실패인지 판단한다.
재계획 모듈은 실패 원인을 바탕으로 다른 방법을 찾는다.
안전 제어 계층은 전체 과정에서 충돌, 과속, 위험 구역 진입, 사람과의 접촉 가능성을 감시한다.

중요한 점은 이 구조가 한 번만 흐르는 직선 파이프라인이 아니라는 것이다. 로봇은 보고, 계획하고, 움직이고, 다시 보고, 틀렸으면 고치고, 위험하면 멈춘다. 즉 AI 로봇 에이전트의 핵심은 반복 루프다.

AI 로봇 에이전트의 구조

전체 아키텍처를 먼저 그려 보기

자연어 명령을 수행하는 로봇을 상상해 보자. 사용자가 "책상 위의 빨간 컵을 집어서 오른쪽 상자에 넣어줘"라고 말한다. 이 문장은 사람에게는 간단하지만 로봇에게는 여러 단계의 문제다. 빨간 컵이 어디 있는지 찾아야 하고, 오른쪽 상자가 무엇인지 알아야 하며, 컵을 잡을 수 있는 위치를 계산해야 한다. 로봇팔이 그 위치까지 안전하게 갈 수 있는지도 확인해야 한다. 잡은 뒤에는 컵이 실제로 그리퍼 안에 있는지 확인해야 하고, 상자에 넣는 과정에서 충돌이 없어야 한다.

이 과정을 모듈 단위로 나누면 훨씬 명확해진다.

사용자 명령
   ↓
명령 해석 / 작업 계획
   ↓
환경 인식
   ↓
로봇 스킬 선택
   ↓
경로 계획 / 제어 실행
   ↓
결과 확인
   ↓
성공이면 종료, 실패면 재계획

여기에 항상 옆에서 감시하는 계층이 하나 더 있다. 바로 안전 제어다. 안전 제어는 특정 단계에만 붙어 있는 기능이 아니다. 카메라가 물체를 잘못 봤을 때도 필요하고, 계획이 위험할 때도 필요하며, 실행 중 사람이 가까이 왔을 때도 필요하다. 그래서 안전 제어는 전체 구조를 감싸는 보호막처럼 설계하는 것이 좋다.

┌──────────────────────────────────────┐
│              안전 제어 계층            │
│  충돌 방지 · 속도 제한 · 권한 제한 · 정지 │
│                                      │
│  인식 → 계획 → 실행 → 피드백 → 재계획    │
└──────────────────────────────────────┘

이 구조를 이해하면 앞으로 배울 로봇 비전, 로봇팔 조작, 모방학습, 강화학습, LLM 에이전트가 어디에 들어가는지 보이기 시작한다. 객체 검출은 인식 모듈에 들어가고, MoveIt2는 실행 모듈에 들어간다. LLM은 주로 계획 모듈에서 강점을 발휘한다. 강화학습으로 학습한 정책은 특정 실행 스킬로 들어갈 수 있고, 모방학습 모델도 마찬가지로 하나의 행동 스킬이 될 수 있다.

인식 모듈: 로봇이 세상을 읽는 방법

인식 모듈의 역할은 로봇에게 "지금 주변이 어떤 상태인지" 알려주는 것이다. 사람은 컵을 보면 컵이라는 사실뿐 아니라 컵의 위치, 크기, 놓인 방향, 잡기 쉬운 부분까지 대략 파악한다. 로봇도 비슷한 정보가 필요하다. 단지 로봇은 그것을 숫자로 알아야 한다.

카메라는 가장 대표적인 센서다. RGB 카메라는 색상 이미지를 제공하고, 깊이 카메라는 각 픽셀이 카메라로부터 얼마나 떨어져 있는지 알려준다. 여기에 라이다, 초음파 센서, 힘 센서, 관절 엔코더 같은 정보가 함께 사용될 수 있다. 관절 엔코더는 로봇팔의 각 관절이 현재 어떤 각도에 있는지 알려주는 센서라고 생각하면 된다.

인식 모듈은 원본 센서 데이터를 그대로 계획 모듈에 넘기지 않는다. 이미지 한 장은 사람에게는 직관적이지만, 계획 모듈이 바로 쓰기에는 너무 복잡하다. 그래서 인식 모듈은 센서 데이터를 더 의미 있는 정보로 바꾼다.

예를 들어 카메라 이미지에서 다음과 같은 정보를 추출할 수 있다.

red_cup: 빨간 컵이 이미지 안에 존재한다.
red_cup.position: 빨간 컵의 3D 위치가 로봇 기준 좌표로 (0.42, -0.18, 0.11)이다.
red_cup.grasp_candidates: 컵을 잡을 수 있는 후보 자세가 여러 개 있다.
box.position: 상자의 위치가 로봇 오른쪽 작업 영역 안에 있다.
obstacle: 컵과 상자 사이에 충돌 가능성이 있는 장애물이 있다.

여기서 중요한 표현이 "로봇 기준 좌표"다. 카메라는 자기 기준으로 물체를 본다. 하지만 로봇팔이 움직이려면 물체 위치를 로봇팔 기준 좌표로 알아야 한다. 카메라 입장에서 "오른쪽 아래에 있는 컵"이 로봇팔 입장에서는 "베이스 기준 x축으로 42cm, y축으로 -18cm, z축으로 11cm 위치"가 되어야 한다. 이 변환이 제대로 되지 않으면 로봇은 컵이 아니라 허공을 집게 된다.

인식 모듈은 완벽하지 않다. 조명이 어두우면 물체를 놓칠 수 있고, 비슷한 색의 물체를 혼동할 수도 있다. 투명한 컵이나 반짝이는 금속 물체는 깊이 카메라에서 이상하게 보이기도 한다. 그래서 인식 결과에는 가능하면 신뢰도를 함께 붙이는 것이 좋다. "컵이 있다"보다 "컵일 확률이 0.91이다"가 더 유용하다. 계획 모듈은 신뢰도가 낮을 때 가까이 가서 다시 보거나, 사용자에게 확인을 요청할 수 있다.

계획 모듈: 목표를 작업 순서로 바꾸기

계획 모듈은 사용자의 목표를 로봇이 실행할 수 있는 순서로 바꾼다. 사용자는 보통 로봇에게 관절 각도나 좌표를 말하지 않는다. "컵을 치워줘", "문 앞까지 가줘", "책상 위를 정리해줘"처럼 말한다. 이런 명령은 사람에게는 자연스럽지만 로봇에게는 아직 실행 가능한 명령이 아니다.

계획 모듈은 이 문장을 더 작은 작업으로 나눈다. 예를 들어 "빨간 컵을 집어서 오른쪽 상자에 넣어줘"라는 명령은 다음과 같은 순서로 바뀔 수 있다.

빨간 컵을 찾는다.
오른쪽 상자를 찾는다.
빨간 컵의 3D 위치와 잡기 후보 자세를 계산한다.
로봇팔을 컵 근처 접근 위치로 이동한다.
그리퍼를 열고 컵을 잡는다.
컵을 들어 올린다.
상자 위로 이동한다.
컵을 내려놓고 그리퍼를 연다.
컵이 상자 안에 있는지 확인한다.

LLM은 이 계획 단계에서 특히 유용하다. LLM은 자연어 명령을 이해하고, 모호한 표현을 해석하며, 작업을 단계로 나누는 데 강하다. 예를 들어 "오른쪽에 놓아줘"라는 말이 작업대 오른쪽 영역을 뜻하는지, 오른쪽 상자를 뜻하는지 문맥을 보고 추론할 수 있다. 하지만 LLM이 로봇의 모터를 직접 제어하게 해서는 안 된다. "관절 1을 0.3초 동안 12도 움직여라" 같은 저수준 제어는 물리 제약과 안전 검사가 필요하기 때문이다.

따라서 LLM은 보통 "무엇을 어떤 순서로 할지"를 정하고, 실제 움직임은 검증된 로봇 스킬이 수행한다. 좋은 계획 모듈은 자유로운 자연어와 엄격한 로봇 명령 사이의 번역기 역할을 한다.

계획 결과는 다음처럼 구조화된 형태로 표현할 수 있다.

{
  "goal": "put red cup into right box",
  "steps": [
    { "skill": "detect_object", "args": { "name": "red cup" } },
    { "skill": "detect_object", "args": { "name": "right box" } },
    { "skill": "pick", "args": { "object": "red cup" } },
    { "skill": "place", "args": { "target": "right box" } },
    { "skill": "check_status", "args": { "condition": "red cup in right box" } }
  ]
}

이런 구조의 장점은 명확성이다. 계획 모듈이 막연한 문장을 내보내는 대신, 실행 모듈이 이해할 수 있는 스킬 이름과 인자를 넘긴다. 실행 모듈은 이 명령이 가능한지 확인하고, 불가능하면 실패 이유를 되돌려준다.

실행 모듈: 계획을 실제 움직임으로 바꾸기

실행 모듈은 계획을 물리적인 행동으로 바꾸는 부분이다. 여기서부터 로봇은 진짜 세계와 부딪힌다. 계획 모듈이 "컵을 집어라"라고 말하는 것은 쉽다. 하지만 실행 모듈은 컵까지 어떤 경로로 갈지, 로봇팔이 테이블에 부딪히지 않을지, 그리퍼를 얼마나 열어야 할지, 물체를 잡은 뒤 얼마나 들어 올릴지를 계산해야 한다.

로봇팔에서는 MoveIt2 같은 경로 계획 도구가 자주 사용된다. MoveIt2는 목표 자세가 주어졌을 때 로봇팔의 관절을 어떻게 움직이면 되는지 계산하고, 중간에 충돌이 없는지도 확인한다. 이동 로봇에서는 Navigation 계열 시스템이 비슷한 역할을 한다. 목적지가 주어지면 지도 위에서 경로를 찾고, 장애물을 피하며, 현재 위치를 추정하면서 이동한다.

실행 모듈은 여러 스킬의 묶음으로 설계하는 것이 좋다. 스킬은 로봇이 수행할 수 있는 하나의 기능 단위다. 너무 작게 만들면 계획이 복잡해지고, 너무 크게 만들면 재사용이 어려워진다. 예를 들어 move_joint_1_by_3_degree는 너무 낮은 수준의 스킬이고, clean_room_completely는 너무 높은 수준의 스킬이다. 반면 detect_object, move_to, pick, place, navigate_to, stop, check_status 같은 스킬은 계획 모듈이 호출하기에 적당하다.

실행 스킬은 내부적으로 복잡할 수 있다. pick(object)라는 하나의 스킬 안에도 접근, 정렬, 하강, 그리퍼 닫기, 들어 올리기, 잡힘 확인 같은 단계가 들어간다. 하지만 계획 모듈은 이 세부 과정을 모두 알 필요가 없다. 이것이 모듈화의 힘이다. 운전자가 엔진 내부 폭발 과정을 몰라도 자동차를 운전할 수 있는 것과 비슷하다.

좋은 실행 모듈은 결과를 반드시 반환한다. 단순히 "실행 완료"라고만 말하는 것이 아니라, 성공 여부와 실패 원인을 함께 알려야 한다.

{
  "skill": "pick",
  "status": "failed",
  "reason": "object_slipped",
  "detail": "gripper force was not enough"
}

이런 결과가 있어야 피드백 및 재계획 루프가 작동한다. 로봇이 실패를 말하지 못하면, 에이전트는 같은 실수를 반복하게 된다.

피드백: 로봇에게는 확인하는 습관이 필요하다

사람도 컵을 집을 때 눈으로 보고 손의 감각으로 확인한다. 컵을 잡았다고 생각했는데 미끄러지면 다시 잡는다. 로봇에게도 이 확인 과정이 필요하다. 특히 현실 세계에서는 "명령을 보냈다"와 "작업이 성공했다"가 같은 뜻이 아니다.

그리퍼를 닫았다고 해서 물체를 잡은 것은 아니다. 물체가 옆으로 밀렸을 수도 있고, 그리퍼 사이에서 빠졌을 수도 있다. 이동 로봇이 목적지에 도착했다고 보고했더라도 실제로는 사람이나 의자 때문에 문 앞에서 멈춰 있을 수 있다. 따라서 실행 후에는 반드시 상태를 다시 확인해야 한다.

피드백 모듈은 센서와 실행 결과를 모아 현재 상태를 판단한다. 로봇팔이라면 그리퍼 힘 센서, 관절 상태, 카메라 이미지, 물체 위치를 함께 볼 수 있다. 이동 로봇이라면 현재 위치, 목표까지의 거리, 장애물 정보, 바퀴 속도, 충돌 센서 상태를 볼 수 있다.

피드백에서 중요한 질문은 단순하다.

목표가 달성되었는가?
중간 상태가 예상과 다른가?
위험한 상황이 발생했는가?
같은 계획을 계속해도 되는가?
다른 계획이 필요한가?

이 질문에 답할 수 있어야 로봇은 조금 더 사람처럼 행동한다. 실패를 감지하지 못하는 로봇은 고집 센 로봇이 된다. 컵이 없는데도 계속 허공을 잡고, 길이 막혔는데도 같은 벽으로 다가간다. 반대로 피드백이 있는 로봇은 자신의 행동을 관찰하고 수정한다.

재계획: 실패는 예외가 아니라 기본 상황이다

로봇 개발에서 실패는 특별한 사건이 아니다. 실패는 기본값에 가깝다. 물체가 예상보다 멀리 있거나, 컵이 넘어져 있거나, 조명이 바뀌거나, 사람이 물체를 옮겨 놓을 수 있다. 그래서 AI 로봇 에이전트는 처음 계획이 틀릴 수 있다는 전제로 설계해야 한다.

재계획은 실패가 발생했을 때 새로운 행동 순서를 만드는 과정이다. 중요한 것은 실패를 하나로 뭉뚱그리지 않는 것이다. "실패했다"는 정보만으로는 다음 행동을 정하기 어렵다. 왜 실패했는지가 필요하다.

예를 들어 pick 스킬이 실패했을 때 원인에 따라 다음 행동은 달라진다. 물체가 검출되지 않았다면 카메라 위치를 바꾸거나 조명을 확인해야 한다. 잡기 자세가 좋지 않았다면 다른 grasp 후보를 선택해야 한다. 그리퍼 힘이 부족했다면 잡는 위치를 바꾸거나 더 안정적인 방식으로 접근해야 한다. 충돌 위험 때문에 경로 계획이 실패했다면 장애물을 치우거나 다른 접근 방향을 찾아야 한다.

재계획은 크게 두 수준에서 일어난다. 첫째는 지역적 재계획이다. 전체 목표는 유지한 채 작은 단계만 바꾸는 방식이다. 컵을 집는 데 실패했다면 다른 잡기 후보를 시도하는 식이다. 둘째는 전역적 재계획이다. 목표 달성 방식 자체를 바꾸는 것이다. 정면 접근이 불가능하면 로봇팔 베이스 위치를 바꾸거나, 이동 로봇이 다른 쪽으로 돌아가는 식이다.

재계획이 잘 작동하려면 계획 모듈, 실행 모듈, 피드백 모듈 사이의 인터페이스가 명확해야 한다. 실행 모듈은 실패 이유를 알려주고, 피드백 모듈은 현재 상태를 갱신하며, 계획 모듈은 새 상태를 바탕으로 다음 행동을 정한다. 이 루프가 빠르고 안정적으로 돌아갈수록 로봇은 더 유연해진다.

계획 실행
   ↓
결과 확인
   ↓
성공 → 다음 단계
실패 → 원인 분석 → 대안 선택 → 다시 실행

이 구조는 단순해 보이지만 실제 로봇 지능의 핵심이다. 로봇이 똑똑해 보이는 순간은 처음부터 모든 것을 맞힐 때가 아니라, 틀렸을 때 자연스럽게 고칠 때다.

안전 제어: 똑똑한 로봇보다 안전한 로봇이 먼저다

AI 로봇 에이전트에서 안전은 선택 기능이 아니다. 로봇은 화면 안에서만 움직이는 프로그램이 아니다. 로봇팔은 실제 힘을 가지고 있고, 이동 로봇은 사람과 같은 공간을 다닌다. 잘못된 명령 하나가 물체 파손이나 사람의 부상으로 이어질 수 있다.

특히 LLM을 사용하는 로봇에서는 안전 계층이 더 중요하다. LLM은 자연어를 잘 이해하지만, 물리 세계의 모든 제약을 정확히 알지는 못한다. 때로는 존재하지 않는 스킬을 호출하려 하거나, 위험한 순서를 제안하거나, 불확실한 정보를 확신하는 것처럼 말할 수 있다. 이것을 환각이라고 부른다. 환각은 모델이 실제 근거가 부족한 내용을 그럴듯하게 만들어 내는 현상이다.

그래서 LLM의 출력은 곧바로 로봇 명령이 되어서는 안 된다. 중간에 검증 계층이 필요하다. 이 계층은 계획이 허용된 스킬만 사용하는지, 목표 위치가 안전 구역 안에 있는지, 속도와 힘 제한을 넘지 않는지 확인한다. 위험하면 실행하지 않고 거부하거나 사람에게 확인을 요청해야 한다.

안전 제어는 여러 층으로 나누어 두는 것이 좋다.

명령 안전: 사용자의 명령 자체가 허용 가능한지 확인한다.
계획 안전: 생성된 작업 순서가 금지 행동을 포함하지 않는지 검사한다.
경로 안전: 이동 경로나 로봇팔 궤적에 충돌 위험이 없는지 확인한다.
실행 안전: 실제 움직임 중 속도, 힘, 거리, 장애물 변화를 감시한다.
비상 안전: 위험 상황에서 즉시 정지하고 사람 개입을 요청한다.

예를 들어 사용자가 "저 유리컵을 최대한 빨리 집어 던져줘"라고 말한다면 계획 모듈은 이를 작업으로 바꿀 수 있을지도 모른다. 하지만 안전 계층은 "던지기"가 허용된 스킬이 아니며, 고속 동작이 위험하다고 판단해 실행을 막아야 한다. 안전한 로봇은 사용자의 모든 명령을 따르는 로봇이 아니라, 해도 되는 일과 하면 안 되는 일을 구분하는 로봇이다.

모듈 사이의 약속: 인터페이스가 지능을 만든다

복잡한 시스템에서 모듈을 나누는 것만큼 중요한 것이 모듈 사이의 약속이다. 이 약속을 인터페이스라고 부른다. 인터페이스는 한 모듈이 다른 모듈에게 어떤 형식으로 정보를 주고받을지 정한 규칙이다.

인식 모듈이 물체 위치를 보낼 때 어떤 좌표계를 쓰는지 분명해야 한다. 카메라 좌표인지, 로봇 베이스 좌표인지, 지도 좌표인지 섞이면 큰 문제가 생긴다. 계획 모듈이 pick을 호출할 때는 물체 이름만 줄 것인지, 정확한 3D 위치까지 줄 것인지 정해야 한다. 실행 모듈이 실패를 반환할 때도 실패 코드와 설명을 일정한 형식으로 맞추는 것이 좋다.

예를 들어 다음과 같은 스킬 인터페이스를 생각할 수 있다.

{
  "skill_name": "pick",
  "input": {
    "object_id": "red_cup_01",
    "target_pose": {
      "frame": "robot_base",
      "x": 0.42,
      "y": -0.18,
      "z": 0.11
    }
  },
  "output": {
    "status": "success_or_failed",
    "reason": "optional_failure_reason"
  }
}

여기서 frame은 좌표계 이름이다. 같은 (0.42, -0.18, 0.11)이라도 어떤 좌표계를 기준으로 하느냐에 따라 완전히 다른 위치가 된다. 좌표계가 명확하지 않은 로봇 시스템은 주소 없이 택배를 보내는 것과 같다. 운이 좋으면 도착할 수도 있지만, 대부분은 엉뚱한 곳으로 간다.

인터페이스를 잘 설계하면 나중에 모듈을 교체하기 쉬워진다. 처음에는 간단한 색상 기반 객체 검출을 쓰다가 나중에 딥러닝 객체 검출 모델로 바꿀 수 있다. 실행 모듈도 시뮬레이터에서 테스트하다가 실제 로봇으로 옮길 수 있다. 계획 모듈 역시 규칙 기반 플래너에서 LLM 기반 플래너로 바꿀 수 있다. 모듈 내부는 바뀌어도 입출력 약속이 유지되면 전체 시스템은 크게 흔들리지 않는다.

예시: 컵을 상자에 넣는 에이전트

이제 하나의 작은 장면으로 전체 구조를 연결해 보자. 작업대 위에 빨간 컵과 파란 상자가 있다. 사용자가 "빨간 컵을 파란 상자에 넣어줘"라고 말한다.

먼저 계획 모듈은 명령에서 목표를 추출한다. 목표 물체는 빨간 컵이고, 목적지는 파란 상자다. 그러고 나서 필요한 스킬 순서를 만든다. 컵을 찾고, 상자를 찾고, 컵을 집고, 상자에 놓고, 결과를 확인하는 순서다.

인식 모듈은 카메라 이미지를 분석해 빨간 컵과 파란 상자를 찾는다. 깊이 정보가 있다면 각 물체의 3D 위치를 계산한다. 카메라 좌표로 얻은 위치는 로봇 베이스 좌표로 변환된다. 이때 컵의 중심점뿐 아니라 잡기 후보 위치도 함께 계산할 수 있다.

실행 모듈은 pick(red_cup)을 수행한다. 내부에서는 MoveIt2가 로봇팔 경로를 계획하고, 그리퍼가 컵을 잡을 수 있도록 열린다. 로봇팔은 컵 위 접근 위치로 이동한 뒤 천천히 내려가고, 그리퍼를 닫은 뒤 컵을 들어 올린다.

피드백 모듈은 컵이 실제로 들렸는지 확인한다. 카메라에서 컵 위치가 상승했는지 볼 수도 있고, 그리퍼의 힘 센서나 손가락 간격을 확인할 수도 있다. 만약 컵이 미끄러졌다면 실행 결과는 실패가 된다.

재계획 모듈은 실패 원인을 확인한다. 컵이 미끄러진 이유가 잡기 위치가 너무 위쪽이었기 때문이라면 더 낮은 위치를 잡도록 계획을 수정한다. 충돌 때문에 접근하지 못했다면 다른 방향에서 접근한다. 컵을 찾지 못했다면 카메라를 다시 움직이거나 사용자에게 "빨간 컵이 보이지 않습니다. 컵이 작업대 위에 있나요?"라고 물을 수 있다.

마지막으로 안전 제어 계층은 전체 과정에서 계속 감시한다. 로봇팔이 작업대에 너무 가까이 가면 속도를 줄이고, 사람이 작업 영역 안에 들어오면 정지한다. 계획 모듈이 허용되지 않은 스킬을 호출하면 실행 전에 차단한다.

이 장면에서 눈에 띄는 것은 어느 한 모듈도 혼자 영웅이 아니라는 점이다. 인식이 좋아도 계획이 엉망이면 실패한다. 계획이 좋아도 실행이 불안정하면 물체를 떨어뜨린다. 실행이 좋아도 피드백이 없으면 실패를 모른다. 그리고 모든 것이 좋아 보여도 안전이 없으면 실제 환경에 놓을 수 없다.

좋은 AI 로봇 에이전트를 위한 설계 원칙

AI 로봇 에이전트를 만들 때는 처음부터 거대한 범용 로봇을 만들려고 하기보다 작고 명확한 구조에서 시작하는 것이 좋다. "컵을 집어 상자에 넣기"처럼 제한된 작업이라도 인식, 계획, 실행, 피드백, 안전이 모두 필요하다. 작은 작업에서 이 구조를 제대로 만들면 더 큰 작업으로 확장할 수 있다.

좋은 설계는 다음 원칙을 따른다.

모듈을 나누되, 각 모듈의 입력과 출력을 명확히 한다.
LLM은 고수준 계획에 사용하고, 저수준 제어는 검증된 로봇 제어기에 맡긴다.
모든 실행 결과는 성공, 실패, 실패 이유를 반환하게 한다.
실패를 예외가 아니라 정상적인 흐름의 일부로 다룬다.
안전 제어는 마지막에 붙이는 장식이 아니라 처음부터 포함한다.
시뮬레이션과 실제 로봇에서 같은 인터페이스를 쓰도록 설계한다.

이 원칙을 지키면 시스템이 커져도 덜 흔들린다. 객체 검출 모델을 바꾸거나, 로봇팔을 교체하거나, LLM을 다른 모델로 바꾸더라도 전체 구조는 유지될 수 있다. 이것이 모듈형 아키텍처의 가장 큰 장점이다.

핵심 정리

AI 로봇 에이전트는 자연어를 이해하는 모델 하나로 완성되지 않는다. 로봇은 물리 세계에서 행동해야 하므로 인식, 계획, 실행, 피드백, 재계획, 안전 제어가 함께 작동해야 한다. 인식 모듈은 센서 데이터를 물체와 위치 정보로 바꾸고, 계획 모듈은 목표를 작업 순서로 나눈다. 실행 모듈은 로봇 스킬을 호출해 실제 움직임을 만들고, 피드백 모듈은 결과를 확인한다. 실패하면 재계획이 새로운 방법을 찾고, 안전 제어 계층은 모든 단계에서 위험한 행동을 막는다.

복잡한 로봇 시스템을 만드는 첫걸음은 복잡함을 없애는 것이 아니라, 복잡함을 잘 나누는 것이다. 로봇이 보고, 생각하고, 움직이고, 확인하고, 다시 시도하는 구조를 갖추면 그 위에 더 강력한 비전 모델, 더 좋은 제어 알고리즘, 더 똑똑한 LLM을 차례로 얹을 수 있다. 앞으로 다룰 로봇 비전, 로봇팔 조작, 모방학습, 강화학습, LLM 에이전트는 모두 이 구조의 한 부분으로 연결된다.

책 목록

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

전체 목차 보기