18. 로봇 에이전트 설계: 생각하는 AI와 움직이는 로봇 분리하기

지난 장에서 우리는 LLM이 로봇의 모든 것을 대신할 수는 없지만, 명령을 이해하고 계획을 세우고 결과를 설명하는 데는 매우 강력하다는 점을 살펴봤습니다. 이제 한 걸음 더 나아가 보겠습니다. 그렇다면 실제 로봇 시스템에서는 이 능력을 어디에 두어야 할까요?

핵심은 아주 단순합니다. 생각하는 계층과 움직이는 계층을 분리해야 합니다. 사람으로 비유하면, "무엇을 할지 정하는 머리"와 "정해진 동작을 정확히 수행하는 몸"을 따로 설계하는 것입니다. 이 구분이 없으면 로봇은 말은 그럴듯한데 행동은 불안정한, 조금 무서운 존재가 됩니다. 반대로 이 구분이 잘 되어 있으면 시스템은 더 안전해지고, 기능을 추가하기도 쉬워집니다.

이번 장에서는 사용자 명령이 들어온 뒤, 의도를 해석하고, 작업 계획을 만들고, 안전을 검사하고, 제어 API를 호출하고, 결과를 다시 사람에게 보고하는 흐름을 하나의 로봇 에이전트 아키텍처로 정리해 보겠습니다.

왜 '생각'과 '행동'을 분리해야 할까

로봇을 처음 만들 때 흔히 떠올리는 구조는 이렇습니다. 사용자가 말을 하면 AI가 이해하고, 바로 모터를 움직입니다. 데모 영상으로는 멋져 보입니다. 하지만 실제 환경에서는 문제가 금방 드러납니다.

첫 번째 문제는 속도입니다. 생각은 느려도 되지만, 제어는 느리면 안 됩니다. 사용자의 문장을 해석하고 계획을 짜는 과정은 1초쯤 걸려도 괜찮을 때가 많습니다. 하지만 장애물을 감지하고 바퀴를 멈추는 일은 그 정도로 느리면 이미 늦습니다.

두 번째 문제는 형식입니다. 사람의 명령은 모호합니다. "저거 좀 치워줘", "한번 둘러봐", "위험하면 멈춰" 같은 말은 사람끼리는 통하지만, 기계는 그대로 실행하기 어렵습니다. 그래서 먼저 해석과 정리가 필요합니다. 반면 모터 제어는 모호하면 안 됩니다. 속도, 방향, 목표 위치, 허용 오차처럼 분명한 값이 있어야 합니다.

세 번째 문제는 책임입니다. 로봇이 잘못 움직였을 때 어디서 문제가 생겼는지 추적할 수 있어야 합니다. 명령 해석이 틀렸는지, 계획이 비현실적이었는지, 센서가 오작동했는지, 제어기가 명령을 잘못 수행했는지 분리되어야 디버깅이 가능합니다.

쉽게 말해, 생각과 행동을 한 덩어리로 만들면 로봇은 똑똑한 척하다가 갑자기 이상한 행동을 할 수 있습니다. 생각과 행동을 나누면 로봇은 조금 덜 화려해 보여도 훨씬 믿을 만해집니다.

로봇 에이전트를 한 문장으로 정의하면

로봇 에이전트는 단순한 챗봇이 아닙니다. 사용자의 말을 이해한 뒤, 로봇이 실제로 할 수 있는 행동으로 바꾸고, 그 행동이 안전한지 확인한 다음, 적절한 모듈을 호출해 실행하고, 결과를 다시 사람에게 설명하는 작업 관리자입니다.

여기서 중요한 포인트는 에이전트가 직접 바퀴를 미세하게 조종하거나, 모터 PWM 값을 만지는 존재가 아니라는 점입니다. 에이전트는 "무엇을 해야 하는지"를 정리하고, 저수준 제어기는 "어떻게 안정적으로 할지"를 책임집니다.

이 역할 분담이 바로 개인 개발자에게도 필요한 이유입니다. 처음에는 작은 데스크 로봇 하나를 만들더라도, 나중에 카메라를 추가하고, 팔을 붙이고, 음성 인터페이스를 얹고, ROS 2 노드로 분리하다 보면 시스템은 빠르게 복잡해집니다. 그때 생각과 행동이 뒤섞여 있으면 확장이 거의 불가능해집니다.

기본 아키텍처: 명령에서 결과 보고까지

가장 실용적인 로봇 에이전트 구조는 다음 흐름으로 이해할 수 있습니다.

사용자 명령 → 의도 해석 → 작업 계획 → 안전 검사 → 로봇 제어 API 호출 → 실행 모니터링 → 결과 보고

이 한 줄 안에 로봇 에이전트 설계의 거의 모든 핵심이 들어 있습니다. 각각을 차근차근 보겠습니다.

1단계: 사용자 명령 받기

로봇은 먼저 사람의 입력을 받아야 합니다. 입력 방식은 여러 가지일 수 있습니다. 텍스트 채팅일 수도 있고, 음성 명령일 수도 있고, 앱의 버튼일 수도 있습니다. 중요한 것은 입력 방식보다 입력의 의미를 일관되게 다루는 것입니다.

예를 들어 사용자가 "책상을 한 바퀴 둘러보고 컵이 있으면 알려줘"라고 말했다고 해봅시다. 이 문장은 겉으로는 하나의 문장이지만, 안에는 여러 조건이 숨어 있습니다. 어디를 둘러볼 것인지, 컵을 어떻게 찾을 것인지, 찾았을 때 무엇을 알려줄 것인지가 다 들어 있습니다.

이 단계에서 해야 할 일은 사용자의 말을 그대로 믿고 실행하는 것이 아니라, 일단 시스템이 이해할 수 있는 입력 이벤트로 바꾸는 것입니다. 즉, 음성은 텍스트로 변환하고, 텍스트는 명령 요청 객체로 저장합니다. 나중에 로그를 확인하고 재현하려면 이 기록이 꼭 필요합니다.

2단계: 의도 해석하기

의도 해석은 "사용자가 정말 원하는 일이 무엇인가?"를 파악하는 단계입니다. 여기서 LLM이 빛을 발합니다.

예를 들어 "책상을 순찰해"라는 명령은 사람에게는 자연스럽지만 기계에게는 불친절합니다. 책상 주변 어느 경로를 말하는지, 한 번만 돌라는 것인지 반복 순찰인지, 무엇을 발견하면 보고해야 하는지 빠져 있습니다.

좋은 에이전트는 이 단계에서 곧장 행동하지 않습니다. 먼저 명령의 성격을 분류합니다. 관찰인지, 이동인지, 집기인지, 알림인지, 대화인지 나눕니다. 그리고 빠진 정보가 있으면 되묻습니다. 예를 들면 이런 식입니다.

• "순찰 범위를 책상 위로 한정할까요, 책상 주변 바닥까지 포함할까요?"

• "컵을 찾으면 사진도 함께 보낼까요?"

• "한 번만 확인할까요, 10분마다 반복할까요?"

이 되묻기 과정이 로봇을 훨씬 덜 멍청하게 만듭니다. 동시에 위험도 줄여 줍니다. 사람은 애매하게 지시하는 경우가 정말 많기 때문입니다.

3단계: 작업 계획으로 쪼개기

의도를 이해했다고 해서 바로 모터를 돌리면 안 됩니다. 그다음에는 명령을 작업 계획으로 바꿔야 합니다.

작업 계획은 자유로운 문장보다 구조화된 형태가 좋습니다. 쉽게 말해 "로봇이 해야 할 일을 순서대로 적은 체크리스트"입니다. 예를 들어 "빨간 컵을 찾아 오른쪽 트레이에 놓아줘"라는 명령은 다음처럼 쪼갤 수 있습니다.

• 카메라로 책상 영역 스캔

• 빨간 컵 후보 탐지

• 컵 위치 좌표 추정

• 집기 가능한 자세 계산

• 로봇팔 이동

• 그리퍼 닫기

• 오른쪽 트레이로 이동

• 컵 내려놓기

• 성공 여부 확인

• 사용자에게 결과 보고

이때 중요한 점은, 계획은 어디까지나 상위 수준의 작업 목록이어야 한다는 것입니다. "관절 2를 13도 움직여라" 같은 저수준 명령까지 들어가면 에이전트가 제어기 역할을 침범하게 됩니다. 에이전트는 "컵을 집어라"까지 정하면 되고, 실제 관절 경로는 모션 플래너가 계산해야 합니다.

4단계: 계획을 곧바로 믿지 말고 안전 검사하기

이 부분이 특히 중요합니다. LLM이 세운 계획은 말은 그럴듯해도, 실제 로봇에게는 무리한 요구일 수 있습니다. 그래서 계획과 실행 사이에는 반드시 안전 검사기가 들어가야 합니다.

안전 검사는 로봇의 문지기입니다. 여기서는 "이 명령을 실행해도 되는가?"를 따집니다. 검사 항목은 로봇 종류에 따라 다르지만, 개인 개발자 기준으로는 다음 정도를 기본으로 잡으면 좋습니다.

• 현재 배터리로 작업을 끝낼 수 있는가

• 목표 위치가 로봇의 작업 범위 안에 있는가

• 사람이나 반려동물이 가까이 있는가

• 카메라 인식 결과의 신뢰도가 충분한가

• 그리퍼가 집을 수 없는 크기나 재질은 아닌가

• 금지 구역이나 위험 구역으로 이동하려는 것은 아닌가

• 충돌 가능성이 있는 경로는 아닌가

• 네트워크 지연이나 센서 오류가 심한 상태는 아닌가

예를 들어 사용자가 "책상 끝에 있는 유리컵을 빨리 집어"라고 말해도, 안전 검사기가 "물체가 가장자리 2cm 이내에 있음", "집기 실패 시 낙하 위험이 큼"이라고 판단하면 실행을 보류할 수 있어야 합니다. 이때 좋은 로봇은 조용히 멈추는 대신 이렇게 말합니다. "유리컵이 책상 끝에 가까워 낙하 위험이 있습니다. 손으로 조금 안쪽으로 옮겨 주시면 다시 시도하겠습니다."

이 한 문장이 로봇을 훨씬 안전하고 현실적인 도구로 만들어 줍니다.

5단계: 제어 API 호출하기

안전 검사를 통과하면, 그제야 로봇은 실제 기능 모듈을 호출합니다. 이 부분이 바로 생각하는 AI와 움직이는 로봇의 경계선입니다.

에이전트는 직접 모터를 다루지 않고, 미리 정의된 제어 API나 로봇 스킬을 호출합니다. 예를 들어 이런 함수들이 있을 수 있습니다.

• navigate_to(location)

• scan_desk()

• detect_object(label)

• pick_object(object_id)

• place_object(target_zone)

• speak(text)

• capture_image()

• stop_motion()

이런 식으로 제어 인터페이스를 명확하게 만들어 두면 장점이 큽니다. 에이전트는 복잡한 로봇 내부 구현을 몰라도 되고, 실행 계층은 입력 형식만 맞으면 안정적으로 동작할 수 있습니다.

비유하자면, 에이전트는 식당에서 손님 주문을 정리하는 매니저이고, 제어 API는 주방과 홀 직원에게 전달하는 표준 주문서입니다. 매니저가 직접 프라이팬을 잡기 시작하면 식당은 곧 난장판이 됩니다.

6단계: 실행 중에도 계속 감시하기

실행 버튼을 눌렀다고 해서 끝난 것이 아닙니다. 로봇은 물리 세계에서 움직이기 때문에, 실행 중간에도 상황이 바뀔 수 있습니다.

예를 들어 이동 중에 사람이 앞을 지나갈 수 있고, 잡으려던 물체가 다른 곳으로 밀릴 수 있고, 조명이 바뀌어 인식이 실패할 수 있습니다. 따라서 에이전트는 한 번 계획을 세우고 잊어버리는 존재가 아니라, 실행 상태를 계속 확인하는 관리자여야 합니다.

실행 모니터링에서는 보통 이런 질문을 계속 던집니다.

• 작업이 정상적으로 진행되고 있는가

• 예상보다 오래 걸리고 있지는 않은가

• 오류가 발생했는가

• 재시도가 가능한 오류인가

• 지금 멈추고 사용자 확인을 받아야 하는가

예를 들어 물체 인식이 실패했다고 해서 바로 전체 작업을 포기할 필요는 없습니다. 카메라 각도를 바꿔 다시 시도할 수 있고, 조명을 켜 볼 수도 있고, 사용자에게 "컵 색상을 다시 알려주세요"라고 물어볼 수도 있습니다. 이 재시도 전략이 들어가면 로봇은 훨씬 끈질기고 실용적인 도구가 됩니다.

7단계: 결과 보고하기

로봇은 행동만 잘해서는 충분하지 않습니다. 사람이 이해할 수 있게 결과를 설명해야 합니다.

결과 보고는 단순히 "완료"라고 말하는 수준을 넘어서야 합니다. 무엇을 했는지, 어디서 실패했는지, 다시 하려면 무엇이 필요한지 알려줘야 합니다. 예를 들어 다음과 같은 차이가 있습니다.

나쁜 보고: "실패했습니다."

좋은 보고: "책상 위를 스캔했지만 빨간 컵을 찾지 못했습니다. 조명이 어두워 인식 신뢰도가 낮았습니다. 조명을 켠 뒤 다시 시도할 수 있습니다."

이런 설명 능력은 로봇에 대한 신뢰를 크게 높입니다. 사용자는 로봇이 단순히 멈춘 것이 아니라, 왜 멈췄는지 이해할 수 있기 때문입니다. 특히 개인 프로젝트에서는 이 기능이 생각보다 중요합니다. 실제 성능이 완벽하지 않아도, 상태 설명이 좋으면 사용 경험은 훨씬 좋아집니다.

로봇 에이전트의 핵심 구성 요소

지금까지의 흐름을 시스템 구성으로 바꾸면, 로봇 에이전트는 대체로 다음 여섯 덩어리로 나눌 수 있습니다.

• 인터페이스 계층: 음성, 텍스트, 앱 버튼처럼 사용자 입력을 받는 부분입니다.

• 의도 해석 계층: 사용자의 말을 이해하고, 필요한 경우 되묻는 부분입니다.

• 플래너 계층: 목표를 단계별 작업으로 쪼개는 부분입니다.

• 가드레일 계층: 안전, 정책, 실행 가능성을 검사하는 부분입니다.

• 실행 계층: 이동, 인식, 집기, 발화 같은 실제 로봇 스킬을 수행하는 부분입니다.

• 관찰 및 보고 계층: 현재 상태를 모니터링하고 사람에게 설명하는 부분입니다.

이 여섯 가지가 분리되어 있으면, 나중에 시스템을 업그레이드하기도 편합니다. 예를 들어 음성 인식 엔진을 바꾸더라도 플래너는 그대로 둘 수 있고, 카메라 모델을 교체하더라도 사용자 인터페이스는 건드리지 않을 수 있습니다.

에이전트가 가져야 할 '로봇 자기소개서'

좋은 로봇 에이전트는 자기 능력을 알아야 합니다. 다시 말해, "내가 무엇을 할 수 있고, 무엇은 못 하는지"를 명시적으로 가지고 있어야 합니다.

이를 능력 목록, 툴 카탈로그, 스킬 레지스트리라고 생각하면 됩니다. 예를 들면 이런 정보가 들어갑니다.

• 이동 가능 여부와 이동 방식

• 장착된 센서 종류

• 집기 가능 무게와 크기

• 카메라 인식 가능한 객체 종류

• 현재 배터리 상태

• 금지 구역 정보

• 작업 가능 시간대

• 온라인 API 의존 기능 여부

이 정보가 없으면 에이전트는 없는 능력을 상상해 낼 위험이 큽니다. 예를 들어 로봇팔이 없는데 "컵을 집어라"라는 계획을 세우거나, 깊이 센서가 없는데 정확한 3차원 좌표를 가정하는 식입니다.

그래서 개인 개발자도 단순한 JSON 파일 하나라도 좋으니, 로봇의 현재 능력을 구조화해 두는 습관이 중요합니다. 로봇은 환상으로 움직이지 않고, 가진 기능 안에서만 움직입니다.

'생각 루프'와 '제어 루프'는 주기가 다르다

이 구분은 로봇 설계에서 매우 중요합니다. 생각 루프와 제어 루프는 같은 컴퓨터 안에 있어도, 같은 템포로 돌아가면 안 됩니다.

생각 루프는 비교적 느립니다. 사용자 문장을 이해하고, 작업을 계획하고, 실패를 요약하는 데는 시간이 조금 걸려도 됩니다. 반면 제어 루프는 빠르고 일정해야 합니다. 모터 제어, 센서 피드백, 장애물 회피, 균형 유지 같은 기능은 정해진 주기로 돌아야 합니다.

쉽게 말해, 생각 루프는 회의실이고 제어 루프는 브레이크 페달입니다. 회의실에서 결론이 늦게 나는 것은 답답한 일일 뿐이지만, 브레이크 페달이 늦게 반응하면 사고가 납니다.

따라서 에이전트는 "목표를 정하는 느린 두뇌"로 두고, 제어기는 "반응하는 빠른 몸"으로 두는 것이 맞습니다.

개인 개발자를 위한 현실적인 구현 패턴

개인이 처음부터 거대한 에이전트 프레임워크를 만들 필요는 없습니다. 오히려 다음처럼 소박한 구조로 시작하는 편이 좋습니다.

라즈베리파이나 PC에서 Python으로 에이전트 프로세스를 돌리고, ROS 2 토픽이나 서비스, 혹은 단순한 HTTP API로 로봇 기능을 호출하는 방식입니다. 이동, 카메라, 집기, 음성 출력 같은 기능은 각각 별도 모듈로 두고, 에이전트는 이들을 조합만 합니다.

예를 들어 데스크 어시스턴트 로봇이라면 다음 정도로 시작할 수 있습니다.

• 음성 입력을 텍스트로 바꾸는 모듈

• 명령을 작업 계획으로 바꾸는 에이전트 모듈

• 카메라 인식 모듈

• 서보나 바퀴를 제어하는 로봇 모듈

• 현재 상태를 저장하는 상태 관리자

• 결과를 말하거나 화면에 표시하는 보고 모듈

처음에는 함수 몇 개만 호출해도 충분합니다. 중요한 것은 기능 수가 아니라 경계가 분명한 구조입니다.

예시 시나리오: "책상을 순찰하고 이상이 있으면 알려줘"

이제 실제로 한 번 굴려 보겠습니다.

사용자가 "책상을 순찰하고 이상이 있으면 알려줘"라고 말합니다.

에이전트는 먼저 의도를 해석합니다. 이 명령은 단순 이동이 아니라 관찰 작업이라는 점을 파악합니다. 그런데 "이상"이 무엇인지 모호합니다. 그래서 미리 정의된 기준을 확인하거나, 필요하면 사용자에게 되묻습니다. 예를 들어 "컵이 엎질러졌거나 낯선 물체가 있는 경우를 이상으로 볼까요?"라고 물을 수 있습니다.

기준이 정해지면 계획을 만듭니다. 책상 좌측 촬영, 중앙 촬영, 우측 촬영, 이미지 분석, 이상 여부 판단, 결과 보고 같은 순서가 될 수 있습니다.

그다음 안전 검사를 합니다. 현재 배터리가 충분한지, 카메라가 정상인지, 서보 각도 제한을 넘지 않는지 확인합니다.

검사를 통과하면 제어 API를 호출합니다. 카메라 팬을 좌우로 움직이고, 각 지점에서 이미지를 캡처하고, 비전 모듈에 분석을 요청합니다.

실행 도중 카메라가 가려지면 에이전트는 재시도하거나, 사용자의 도움을 요청할 수 있습니다. 작업이 끝나면 "책상 중앙에 평소 없던 상자가 감지되었습니다. 사진을 함께 전송합니다."처럼 결과를 보고합니다.

이 예시에서 중요한 점은, 에이전트가 카메라 서보의 PWM 값을 계산하지 않았다는 것입니다. 그것은 제어 모듈의 일입니다. 에이전트는 순찰이라는 목표를 구조화하고, 필요한 스킬을 순서대로 호출했을 뿐입니다.

실패를 잘 다루는 로봇이 진짜 똑똑하다

로봇 에이전트 설계에서 많은 사람이 계획 생성에만 집중합니다. 하지만 실제 사용성은 실패 처리에서 갈립니다.

현실의 로봇은 자주 실패합니다. 물체를 못 찾을 수도 있고, 경로가 막힐 수도 있고, 네트워크가 끊길 수도 있습니다. 그래서 좋은 에이전트는 실패를 부끄러워하지 않고, 체계적으로 다룹니다.

실패는 대체로 세 종류로 나눌 수 있습니다.

첫째는 재시도 가능한 실패입니다. 카메라가 흔들렸거나 인식 신뢰도가 낮은 경우처럼, 한 번 더 시도하면 될 수 있습니다.

둘째는 계획 수정이 필요한 실패입니다. 원래 경로가 막혀 다른 경로를 찾아야 하거나, 물체를 집는 순서를 바꿔야 하는 경우입니다.

셋째는 사람 개입이 필요한 실패입니다. 위험 물체, 작업 범위 초과, 센서 고장처럼 로봇이 혼자 해결하면 안 되는 상황입니다.

이 분류만 잘해도 로봇은 훨씬 실전적이 됩니다. 모든 실패를 똑같이 "실패"라고 처리하면 사용자는 금방 질립니다. 하지만 "다시 해볼게요", "방법을 바꿔볼게요", "여기서는 사람 도움이 필요합니다"라고 구분해 주면 로봇은 훨씬 성숙해 보입니다.

상태 저장이 없으면 에이전트는 금붕어가 된다

에이전트는 직전 대화와 현재 로봇 상태를 기억해야 합니다. 그렇지 않으면 방금 하던 일도 잊어버립니다.

상태에는 여러 종류가 있습니다. 현재 작업 목표, 마지막으로 본 물체 위치, 배터리 수준, 최근 오류, 현재 모드, 금지 구역, 사용자 선호 설정 같은 것들입니다. 이 정보가 있어야 에이전트가 일관되게 행동할 수 있습니다.

예를 들어 사용자가 "아까 찾던 컵 다시 보여줘"라고 말했을 때, 상태가 없다면 에이전트는 "무슨 컵이요?"라고 되물을 것입니다. 하지만 상태를 가지고 있다면 "10분 전에 책상 오른쪽에서 찾은 빨간 컵 말씀하시는 건가요?"라고 자연스럽게 이어갈 수 있습니다.

다만 여기서도 분리가 필요합니다. 대화 맥락을 저장하는 메모리와, 실시간 제어 상태를 저장하는 메모리는 성격이 다릅니다. 전자는 말의 흐름을 잇기 위한 기억이고, 후자는 안전과 실행을 위한 시스템 상태입니다. 둘을 한 통에 넣으면 혼란이 생깁니다.

확장 가능한 로봇 에이전트를 만드는 설계 원칙

지금까지의 내용을 개인 개발자가 바로 써먹을 수 있는 원칙으로 정리해 보겠습니다.

• 자연어 출력보다 구조화된 계획 출력을 우선하라.

• 에이전트가 직접 모터를 제어하지 못하게 하라.

• 모든 실행 앞에 안전 검사 단계를 넣어라.

• 로봇의 능력 목록을 명시적으로 관리하라.

• 실패를 재시도, 재계획, 사람 요청으로 나눠 처리하라.

• 작업 상태와 대화 상태를 구분해 저장하라.

• 언제든 사람이 개입해 멈출 수 있는 수동 우선권을 남겨 두어라.

이 일곱 가지만 지켜도, 로봇 프로젝트는 갑자기 훨씬 어른스러워집니다. 코드가 조금 길어질 수는 있지만, 대신 시스템은 훨씬 덜 위험하고, 더 고치기 쉬워집니다.

작은 프로젝트일수록 이 구조가 더 중요하다

재미있게도 이런 설계는 거대한 산업용 로봇보다 오히려 개인 프로젝트에 더 중요합니다. 대기업은 팀이 나뉘어 있고, 모듈화가 어느 정도 강제됩니다. 하지만 개인 개발자는 혼자서 모든 것을 한 파일에 몰아넣기 쉽습니다. 음성 처리 함수 아래에 카메라 코드가 있고, 그 아래에 모터 제어 코드가 있고, 중간에 프롬프트 문자열이 끼어드는 식입니다.

처음에는 빨리 돌아가는 것처럼 보여도, 기능이 두 개만 늘어나면 금방 버거워집니다. "앞으로 가"는 잘 되는데 "멈춰"는 가끔 먹지 않고, 카메라를 켜면 음성 응답이 느려지고, 팔을 붙이자 전체 시스템이 불안정해지는 식입니다.

그래서 오히려 작은 프로젝트일수록 초반에 경계를 잡아 두는 것이 좋습니다. 생각은 에이전트로, 움직임은 제어 모듈로, 안전은 별도 검사기로, 결과 설명은 보고 계층으로 분리해 두면 이후 확장이 훨씬 쉬워집니다.

이 장의 핵심 정리

로봇 에이전트 설계의 핵심은 화려한 AI를 붙이는 것이 아니라, 역할을 올바르게 나누는 것입니다.

로봇 안에는 크게 두 종류의 지능이 있습니다. 하나는 사람의 말을 이해하고, 목표를 정리하고, 계획을 세우는 느린 지능입니다. 다른 하나는 센서를 읽고, 위험을 피하고, 몸을 정확히 움직이는 빠른 지능입니다. 이 둘은 협력해야 하지만, 같은 방식으로 작동하면 안 됩니다.

좋은 로봇 에이전트는 사용자 명령을 의도로 바꾸고, 그 의도를 작업 계획으로 쪼개고, 안전하게 실행 가능한지 확인한 뒤, 로봇의 기능 API를 호출하고, 실행 결과를 다시 사람에게 설명합니다. 즉, 에이전트는 지휘자이고, 실제 로봇 모듈은 연주자입니다.

이 관점을 잡으면 "AI가 로봇을 직접 움직인다"는 막연한 환상에서 벗어날 수 있습니다. 대신 "AI는 계획하고, 로봇은 검증된 방식으로 실행한다"는 현실적이고 강한 구조를 만들 수 있습니다.

다음 장에서는 이 아키텍처를 한 단계 더 확장해 보겠습니다. 이제 로봇은 단지 명령을 듣는 수준을 넘어, 카메라 이미지와 음성, 텍스트, 센서 정보를 함께 다루는 멀티모달 시스템으로 발전합니다. 즉, 보고, 듣고, 말하고, 움직이는 로봇으로 넘어갈 차례입니다.