학습된 정책은 파일로만 존재할 때는 아직 로봇 기술이 아니다. 카메라를 보고, 로봇 상태를 읽고, 다음 행동을 계산한 뒤, 실제 모터에 안전하게 명령을 보낼 때 비로소 작업 수행 능력이 된다. 이 장의 목표는 훈련된 LeRobot 정책을 실제 로봇에서 실행하는 마지막 연결 단계를 이해하는 것이다.
배포는 단순히 명령어 하나를 실행하는 일이 아니다. 학습 때의 관측 구성과 배포 때의 센서 구성이 같아야 하고, 추론 속도와 통신 지연이 제어 주기 안에 들어와야 하며, 예상 밖의 행동이 나왔을 때 즉시 멈출 수 있어야 한다. 그래서 배포의 핵심은 "잘 돌아가는지"보다 "같은 조건에서, 충분히 빠르게, 안전하게 돌아가는지"를 확인하는 데 있다.
AI 생성 이미지
첫 실행은 lerobot-rollout으로 시작한다
LeRobot에서 훈련된 정책을 실제 로봇에 실행할 때 기본적으로 사용하는 명령은 lerobot-rollout이다. 이 명령은 정책을 불러오고, 로봇을 연결하고, 카메라와 상태를 읽어 실시간 추론 루프를 실행한다. 공식 문서에서 제시하는 기본 형태는 --policy.path, --robot.type, --robot.port, --task, --duration을 함께 넘기는 방식이다.1
예를 들어 Hugging Face Hub에 올라간 정책을 30초 동안 실행하려면 다음처럼 시작할 수 있다.
lerobot-rollout \
--strategy.type=base \
--policy.path=lerobot/act_koch_real \
--robot.type=koch_follower \
--robot.port=/dev/ttyACM0 \
--task='pick up cube' \
--duration=30여기서 --policy.path는 두 가지를 받을 수 있다. 하나는 Hugging Face Hub의 모델 ID이고, 다른 하나는 로컬 체크포인트 경로다. 직접 학습한 결과를 바로 실행한다면 다음처럼 로컬 경로를 지정할 수 있다.
--policy.path=outputs/train/my_policy/checkpoints/last/pretrained_model--duration은 롤아웃 실행 시간이다. 처음 배포할 때는 긴 시간을 주지 않는 편이 좋다. 5초, 10초, 30초처럼 짧게 시작해 로봇이 어떤 방향으로 움직이는지 확인한다. 문서상 0은 무한 실행을 의미하지만, 실제 로봇에서는 안전 구조를 충분히 갖춘 뒤에만 사용해야 한다.1
로봇과 카메라 설정을 학습 때와 맞춘다
정책은 자신이 학습할 때 보았던 입력 형식을 기대한다. 학습 때 front 카메라 영상을 사용했다면 배포 때도 같은 이름의 front 카메라가 있어야 한다. 학습 때 640×480 해상도와 특정 관절 상태를 사용했다면 배포 때도 가능한 한 같은 조건을 맞춰야 한다.
카메라를 함께 지정해야 한다면 --robot.cameras에 설정을 넘긴다.
lerobot-rollout \
--strategy.type=base \
--policy.path=${HF_USER}/my_policy \
--robot.type=so100_follower \
--robot.port=/dev/ttyACM0 \
--robot.cameras='{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}' \
--task='pick up the cube' \
--duration=30이때 중요한 것은 카메라가 "나오는지"가 아니라 "학습 때와 같은 의미를 가지는지"다. 예를 들어 학습 데이터에서 front가 로봇 정면 카메라였는데, 배포 환경에서 front가 측면 카메라로 바뀌면 정책은 장면을 잘못 해석한다. 물체가 오른쪽에 있다고 판단해 왼쪽으로 움직일 수도 있다.
배포 전에는 다음 항목을 확인한다.
카메라 이름이 학습 데이터의 이름과 같은가
카메라 위치와 방향이 크게 달라지지 않았는가
해상도와 프레임레이트가 정책 입력 처리와 맞는가
로봇 관절 상태와 그리퍼 상태의 순서가 학습 때와 같은가
작업 설명인
--task가 학습 때 사용한 언어 조건과 비슷한가
--task는 단순한 장식 문구가 아니다. 언어 조건을 사용하는 정책에서는 작업 설명도 입력의 일부가 된다. 학습 때 "pick up cube"와 비슷한 표현으로 수집·학습했다면, 배포 때도 같은 의미의 짧고 명확한 문장을 쓰는 편이 좋다.
관측에서 행동까지의 경로를 점검한다
실시간 배포 루프는 크게 네 단계로 볼 수 있다.
첫째, 카메라 프레임을 가져온다. 둘째, 로봇의 현재 관절과 그리퍼 상태를 읽는다. 셋째, 이 관측값과 작업 설명을 정책에 넣어 다음 행동을 예측한다. 넷째, 예측된 행동을 로봇 명령으로 변환해 전송한다.
LeRobot의 롤아웃 구조는 내부적으로 롤아웃 컨텍스트를 만들고 전략 루프를 실행하는 형태로 구성된다. 기본 실행에는 --strategy.type=base를 사용할 수 있으며, 이는 별도 기록 없이 자율 실행을 수행하는 단순한 배포 방식이다.1
이 경로에서 하나라도 어긋나면 정책 성능은 급격히 떨어진다. 카메라가 한 프레임 늦게 들어오는 정도는 괜찮아 보일 수 있지만, 로봇 팔이 빠르게 움직이는 작업에서는 물체 위치와 현재 팔 위치가 서로 맞지 않는 입력이 된다. 관절 값의 단위나 순서가 달라지는 것도 치명적이다. 정책은 "1번 관절"이라고 생각하고 낸 행동이 실제로는 다른 축에 적용될 수 있기 때문이다.
따라서 첫 배포에서는 성공 여부보다 입력과 출력이 정상적으로 연결되는지부터 본다. 로봇을 넓은 작업 공간에 두고, 속도를 낮추고, 짧은 시간 실행한다. 그리고 다음을 관찰한다.
카메라 영상이 끊기지 않는가
현재 관절 상태가 실제 자세와 일치하는가
정책 출력이 특정 방향으로 계속 치우치지 않는가
그리퍼 명령이 열림·닫힘 범위 안에서 움직이는가
실행 종료 후 로봇이 안전한 자세에 머무는가
지연 시간은 제어 품질을 바꾼다
실제 로봇 배포에서 자주 놓치는 문제가 지연 시간이다. 정책 자체가 좋아도 전체 루프가 느리면 로봇은 흔들린다. 카메라 캡처, 이미지 전처리, 모델 추론, 행동 후처리, 직렬 통신이 모두 시간을 사용한다. 이 시간이 누적되면 로봇은 이미 지나간 장면을 보고 뒤늦게 움직인다.
기본 추론 방식에서는 제어 틱마다 정책을 한 번 호출한다. LeRobot 문서에서는 이를 sync 방식으로 설명한다. 반면 rtc 방식은 비동기적으로 행동 청크를 다루는 실시간 청킹 방식으로 제공된다.1 처음에는 단순한 기본 방식으로 시작하고, 추론 지연이 작업 성능을 제한한다고 판단될 때 더 복잡한 방식을 검토하는 편이 안전하다.
실무적으로는 다음 순서로 안정성을 높인다.
카메라 해상도를 낮춰본다. 1280×720이 꼭 필요하지 않다면 640×480이 더 안정적일 수 있다.
프레임레이트를 현실적인 값으로 맞춘다. 카메라가 30fps로 설정되어도 실제 처리 루프가 10Hz라면 병목은 다른 곳에 있다.
모델 실행 장치를 확인한다. GPU를 사용할 수 있는데 CPU에서 돌고 있으면 추론 시간이 크게 늘 수 있다.
불필요한 시각화나 저장 작업을 끈다. 배포 중 화면 표시와 디스크 쓰기가 지연을 만들 수 있다.
롤아웃 시간을 짧게 두고 실제 움직임이 끊기는 지점을 찾는다.
정책 배포에서 목표는 "가장 높은 fps"가 아니다. 일정한 주기로 명령이 갱신되는 것이 더 중요하다. 평균 30Hz보다 가끔 1초씩 멈추는 루프가 더 위험하다. 로봇은 일관된 리듬을 좋아한다.
행동값은 반드시 안전 범위 안에 있어야 한다
모델 출력은 숫자다. 하지만 실제 로봇에게 그 숫자는 힘, 속도, 위치 변화가 된다. 따라서 정책이 낸 행동값을 그대로 모터에 보내는 것은 위험하다. 하드웨어의 허용 관절 범위, 속도 제한, 그리퍼 열림 범위 안으로 행동을 제한해야 한다.
기본적인 보호 장치는 세 가지다.
첫째, 클리핑이다. 행동값이 허용 범위를 넘으면 최소·최대값으로 잘라낸다. 예를 들어 그리퍼 명령이 0에서 1 사이여야 한다면, 그 밖의 값은 범위 안으로 넣는다.
둘째, 속도 제한이다. 한 번의 제어 주기에서 관절 목표가 너무 크게 바뀌지 않도록 제한한다. 정책이 갑자기 큰 움직임을 출력해도 실제 로봇은 작은 변화로 나누어 움직인다.
셋째, 스무딩이다. 연속된 행동 명령을 부드럽게 만들어 진동을 줄인다. 다만 스무딩을 너무 강하게 적용하면 반응이 늦어질 수 있다. 그래서 작업에 필요한 민첩성과 안정성 사이에서 조정해야 한다.
이 장치는 정책 성능을 방해하는 것이 아니다. 오히려 학습된 행동을 실제 하드웨어가 감당할 수 있는 형태로 바꾸는 번역 과정이다. 시뮬레이션이나 데이터셋 안에서는 괜찮았던 작은 오차가 실제 로봇에서는 충돌과 과전류로 이어질 수 있다.
사람에게 제어권이 남아 있어야 한다
배포 중에는 언제든 예상 밖의 행동이 나올 수 있다. 물체 위치가 학습 데이터와 다르거나, 조명이 바뀌거나, 카메라가 살짝 밀렸거나, 관절 캘리브레이션이 어긋났을 수 있다. 정책은 이런 상황에서 자신이 모른다는 신호를 보내지 않는다. 그저 그럴듯한 행동을 계속 출력할 뿐이다.
그래서 안전 구조가 필요하다.
물리적 비상 정지 버튼을 손이 닿는 곳에 둔다.
실행자는 로봇 작업 공간 밖에서 관찰한다.
처음에는 낮은 속도와 짧은
--duration을 사용한다.로봇 주변에 사람, 깨지기 쉬운 물건, 케이블을 두지 않는다.
이상 행동이 보이면 성공 가능성을 기다리지 말고 즉시 멈춘다.
좋은 배포 절차는 보수적이다. 첫 실행에서 바로 전체 작업을 맡기지 않는다. 5초 동안 팔이 올바른 방향으로 가는지 확인하고, 다음에는 10초 동안 접근 동작을 확인하고, 그다음에 집기와 놓기를 본다. 작업 시간을 늘리는 것은 신뢰를 확인한 뒤의 일이다.
실행 결과는 다시 데이터로 기록한다
정책을 실행해 보는 것만으로는 개선이 어렵다. 어떤 장면에서 성공했고, 어떤 장면에서 실패했는지 남겨야 한다. LeRobot에서는 lerobot-record에 --policy.path를 지정해 정책 추론 롤아웃을 데이터셋으로 기록할 수 있다. 공식 가이드에서도 학습 후 평가 단계에서 정책 체크포인트를 넣어 실제 로봇 실행 결과를 기록하는 방식을 설명한다.2
예시는 다음과 같다.
lerobot-record \
--robot.type=so100_follower \
--robot.port=/dev/ttyACM0 \
--robot.cameras='{ front: {type: opencv, index_or_path: 0, width: 640, height: 480, fps: 30}}' \
--dataset.repo_id=${HF_USER}/eval_so100_pick_cube \
--dataset.num_episodes=10 \
--policy.path=${HF_USER}/my_policy \
--task='pick up the cube'시연 데이터 수집과 거의 비슷하지만, 사람이 조종하는 대신 정책이 행동을 만든다는 점이 다르다. 데이터셋 이름은 평가용임을 알아보기 쉽게 eval로 시작하면 관리가 편하다. 기록된 롤아웃은 성공률 계산, 실패 유형 분석, 다음 학습 데이터 보강에 사용할 수 있다.
중요한 것은 실패 데이터를 버리지 않는 것이다. 실패는 정책이 아직 모르는 분포를 보여준다. 예를 들어 물체를 잡기 직전에 그리퍼가 너무 빨리 닫히는 실패가 반복된다면, 그 구간의 시연을 추가로 수집하거나 해당 장면을 포함해 재학습할 수 있다. 정책이 물체에 접근은 잘하지만 놓는 위치에서 흔들린다면, 놓기 단계의 데이터를 더 촘촘히 모아야 한다.
이렇게 배포는 끝이 아니라 다음 학습의 시작이 된다.
정책을 짧게 실행한다.
성공과 실패를 기록한다.
실패 장면의 원인을 분류한다.
필요한 데이터를 추가 수집하거나 정제한다.
다시 학습하고 새 체크포인트를 배포한다.
이 반복이 쌓일수록 정책은 실험실의 데모가 아니라 실제 환경의 변화를 견디는 기술이 된다.
배포 체크리스트
마지막으로 실제 로봇 앞에서 확인할 항목을 정리하자.
--policy.path가 올바른 Hub 모델 ID 또는 로컬 체크포인트를 가리키는가--robot.type과--robot.port가 현재 연결된 로봇과 맞는가카메라 이름, 위치, 해상도, fps가 학습 때와 일치하는가
--task문장이 학습 때의 작업 표현과 어긋나지 않는가첫 실행의
--duration이 충분히 짧은가행동값 클리핑, 속도 제한, 그리퍼 범위 제한이 적용되어 있는가
비상 정지와 수동 개입 방법이 준비되어 있는가
실행 결과를
lerobot-record로 남길 계획이 있는가
정책 배포는 모델을 믿는 과정이 아니라 조건을 검증하는 과정이다. 같은 관측을 넣고, 충분히 빠르게 추론하고, 안전한 행동으로 제한하고, 결과를 다시 데이터로 남긴다. 이 연결이 갖춰질 때 LeRobot의 학습 파이프라인은 실제 로봇 작업 능력으로 이어진다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.