시뮬레이션 환경에서 첫 정책 학습하기

왜 첫 학습은 시뮬레이션에서 시작해야 할까

실제 로봇은 느리고, 비싸고, 실수에 취약하다. 잘못된 action 하나가 그리퍼를 책상에 밀어 넣거나 케이블을 당길 수 있다. 반면 시뮬레이션은 같은 실험을 빠르게 반복할 수 있고, 실패해도 하드웨어가 망가지지 않는다. 그래서 LeRobot을 처음 배울 때의 목표는 "완벽한 로봇 정책"이 아니라 "학습 파이프라인이 끝까지 연결되는지 확인하는 것"이어야 한다.

LeRobot의 기본 흐름은 단순하다. 데이터셋을 읽고, 정책을 만들고, 학습하고, 체크포인트를 저장한 뒤, 환경에서 평가한다. 공식 저장소도 lerobot-train으로 정책을 학습하고 lerobot-eval로 환경에서 평가하는 흐름을 제시한다.¹ 이 장에서는 실제 로봇 없이 이 흐름을 먼저 통과해 본다.

AI 생성 이미지

태스크를 고르기 전에 입출력부터 본다

시뮬레이션 태스크를 고를 때 가장 먼저 볼 것은 멋진 화면이 아니다. 정책이 무엇을 보고, 무엇을 출력하는지다. 이를 각각 관찰 공간과 행동 공간이라고 한다.

관찰 공간은 정책의 입력이다. 예를 들어 다음과 같은 값이 들어갈 수 있다.

• 전면 카메라 이미지

• 손목 카메라 이미지

• 로봇 관절 위치

• 그리퍼 열림 정도

• 태스크를 설명하는 문장

행동 공간은 정책의 출력이다. 예를 들어 다음과 같다.

• 각 관절의 목표 위치

• 엔드이펙터의 이동량

• 그리퍼 열기 또는 닫기 명령

• 일정 시간 동안 실행할 action 시퀀스

첫 실험에서는 짧고 판정이 쉬운 태스크가 좋다. 물체 집기, 블록 옮기기, 문 열기처럼 시작과 끝이 분명한 작업이 적합하다. 성공 기준도 모호하면 안 된다. "블록이 지정된 영역 안에 들어가고 1초 이상 유지되면 성공"처럼 판단 가능한 문장으로 적어야 한다.

학습 전에 데이터셋이나 환경 설정에서 다음을 확인한다.

lerobot-info

이 명령은 설치된 LeRobot의 상태를 확인하는 출발점이다. 그다음에는 사용할 데이터셋의 feature를 확인한다. 특히 observation.images.*, observation.state, action의 이름과 shape가 중요하다. 카메라 이름이 학습 설정과 다르면 모델은 입력을 제대로 받지 못한다. action 차원이 다르면 학습은 시작되더라도 실제 평가에서 전혀 다른 명령을 내릴 수 있다.

첫 정책은 단순하게 시작한다

LeRobot에는 ACT, Diffusion Policy, VQ-BeT, VLA 계열 모델 등 여러 정책이 있다.¹ 하지만 첫 실험부터 복잡한 모델을 고를 필요는 없다. 처음에는 ACT 같은 기본 모방학습 정책으로 데이터 로딩, 학습 루프, 체크포인트 저장, 평가 명령이 정상 동작하는지 확인하는 편이 좋다.

공식 예시는 다음과 같은 형태로 정책 학습을 실행한다.¹

lerobot-train --policy=act --dataset.repo_id=lerobot/aloha_mobile_cabinet

여기서 핵심은 세 가지다.

• --policy=act: 사용할 정책 구조를 지정한다.

• --dataset.repo_id=...: 학습에 사용할 Hugging Face Hub 데이터셋을 지정한다.

• 실행 결과 디렉터리: 로그, 설정, 체크포인트가 저장되는 위치다.

내가 만든 시뮬레이션 데이터셋을 사용할 때는 dataset.repo_id를 자신의 데이터셋으로 바꾼다. 로컬 데이터셋을 쓰는 경우에는 설치한 LeRobot 버전의 lerobot-train --help를 확인해 로컬 경로 인자명을 확인한다. LeRobot은 빠르게 발전하는 프로젝트이므로, 책의 예제보다 현재 설치된 CLI 도움말이 항상 우선이다.

첫 학습에서는 옵션을 많이 바꾸지 않는다. 정책, 데이터셋, 출력 경로 정도만 명확히 하고 실행한다. 많은 옵션을 동시에 바꾸면 실패했을 때 원인을 찾기 어렵다.

로그에서 무엇을 봐야 할까

학습이 시작되면 여러 숫자가 출력된다. 처음에는 모두 중요해 보이지만, 실제로 먼저 볼 것은 몇 가지뿐이다.

첫째, loss다. loss는 정책이 예측한 action과 데이터셋의 정답 action이 얼마나 다른지를 나타내는 값이다. 일반적으로 학습이 진행되며 감소해야 한다. 단, loss가 낮다고 반드시 로봇이 성공하는 것은 아니다. 데이터셋 안의 평균 행동을 잘 맞혔지만 실제 환경에서는 물체를 놓칠 수도 있다.

둘째, 학습 속도다. 한 step이 지나치게 오래 걸리면 이미지 해상도, 카메라 수, 배치 크기, 모델 크기를 확인해야 한다. GPU 메모리가 부족하면 학습이 중단되거나 batch size를 줄이라는 오류가 날 수 있다.

셋째, 평가 성공률이다. 시뮬레이션 환경에서 평가를 함께 돌릴 수 있다면 success rate를 본다. 성공률은 일정한 조건에서 몇 번 중 몇 번 성공했는지를 나타낸다. 예를 들어 10회 평가 중 7회 성공하면 70%다. 평가 횟수가 너무 적으면 우연의 영향이 크다. 처음에는 5~10회로 빠르게 확인하고, 후보 모델을 고를 때 평가 횟수를 늘린다.

공식 예시는 다음처럼 시뮬레이션 또는 벤치마크 환경에서 정책을 평가하는 형태를 보여준다.¹

lerobot-eval \
  --policy.path=lerobot/pi0_libero_finetuned \
  --env.type=libero \
  --env.task=libero_object \
  --eval.n_episodes=10

이 명령에서 policy.path는 평가할 모델 위치다. Hub의 모델 ID일 수도 있고, 로컬 체크포인트 경로일 수도 있다. env.type과 env.task는 평가할 시뮬레이션 환경과 작업을 고른다. eval.n_episodes는 평가 반복 횟수다.

하이퍼파라미터는 한 번에 하나씩 바꾼다

하이퍼파라미터는 학습자가 직접 정하는 설정값이다. 모델이 데이터에서 배우는 값이 아니라, 우리가 학습 방식을 조절하기 위해 주는 값이다. 처음부터 모든 값을 최적화하려고 하면 안 된다. 의미를 이해하고 하나씩 바꿔야 한다.

학습률은 모델이 한 번 업데이트될 때 얼마나 크게 움직일지 정한다. 너무 크면 loss가 불안정하게 튀고, 너무 작으면 학습이 거의 진행되지 않는다. loss가 처음부터 폭발하거나 NaN이 나오면 학습률을 낮춰 본다. 반대로 loss가 거의 변하지 않으면 학습률이 너무 낮거나 데이터와 설정이 맞지 않을 수 있다.

배치 크기는 한 번의 업데이트에 사용할 샘플 수다. 배치가 크면 학습 신호가 안정적일 수 있지만 GPU 메모리를 많이 쓴다. 메모리 오류가 나면 가장 먼저 batch size를 줄인다. 다만 너무 작으면 loss가 심하게 흔들릴 수 있다.

시퀀스 길이는 정책이 한 번에 참고하는 시간 범위다. 로봇 작업은 현재 이미지 한 장만으로 결정되지 않는 경우가 많다. 예를 들어 그리퍼가 이미 물체를 잡았는지, 방금 미끄러졌는지는 시간 흐름을 봐야 알 수 있다. 시퀀스 길이가 길면 이런 정보를 더 잘 볼 수 있지만 계산량이 늘어난다.

ACT에서 자주 등장하는 action chunk는 앞으로 몇 step의 행동을 한꺼번에 예측할지와 관련된다. 짧은 chunk는 빠르게 반응하기 쉽고, 긴 chunk는 부드러운 동작을 만들 수 있다. 하지만 너무 길면 환경 변화에 둔해질 수 있다.

좋은 실험 규칙은 간단하다. 기준 실험을 하나 만든 뒤, 한 번에 하나의 설정만 바꾼다. 그리고 실험 이름에 바꾼 값을 남긴다. 예를 들어 act_bs32_lr1e-4_seq10처럼 적으면 나중에 비교하기 쉽다.

체크포인트를 저장하고 다시 평가한다

체크포인트는 특정 학습 시점의 모델 저장본이다. 학습이 끝난 마지막 모델만 중요한 것은 아니다. 어떤 정책은 중간 시점에서 가장 잘 동작하고, 더 오래 학습하면 오히려 특정 데이터에 과하게 맞춰질 수 있다. 이를 과적합이라고 한다.

실험할 때는 다음 정보를 함께 남긴다.

• 사용한 데이터셋 repo_id 또는 로컬 경로

• LeRobot 버전

• 정책 종류

• 주요 하이퍼파라미터

• 체크포인트 step

• 평가 환경과 태스크

• 평가 성공률과 실패 유형

평가는 항상 같은 조건으로 반복해야 한다. 체크포인트 A는 쉬운 초기 위치에서 평가하고, 체크포인트 B는 어려운 초기 위치에서 평가하면 비교가 불공정하다. 물체 위치, 조명, 카메라 시점, 초기 관절 상태, 평가 횟수를 가능한 한 고정한다.

특정 체크포인트를 다시 평가할 때는 policy.path에 해당 경로를 넣는다. Hub에 올린 모델이면 Hub ID를 넣고, 로컬 결과라면 로컬 체크포인트 디렉터리를 넣는다. 중요한 것은 "어떤 모델을 평가했는지"가 나중에도 정확히 재현되어야 한다는 점이다.

시뮬레이션 성공이 실제 성공은 아니다

시뮬레이션에서 성공률이 높아도 실제 로봇에서는 실패할 수 있다. 이것을 sim-to-real gap이라고 부른다. 시뮬레이션과 현실 사이의 차이라는 뜻이다.

대표적인 이유는 다섯 가지다.

첫째, 카메라 차이다. 시뮬레이션 이미지는 깨끗하고 조명이 일정하다. 실제 카메라는 노이즈, 반사, 그림자, 렌즈 왜곡이 있다. 카메라 위치가 몇 센티미터만 달라도 물체가 전혀 다르게 보인다.

둘째, 물리 차이다. 시뮬레이터의 마찰, 무게, 충돌 계산은 현실의 접촉을 완벽히 재현하지 못한다. 특히 물체를 집거나 밀 때 작은 차이가 큰 실패로 이어진다.

셋째, 보정 차이다. 실제 로봇의 관절 영점, 그리퍼 범위, 카메라 외부 파라미터가 시뮬레이션과 다르면 같은 action도 다른 위치로 간다.

넷째, 지연 시간 차이다. 시뮬레이션에서는 관찰, 추론, action 적용이 규칙적으로 진행된다. 실제 로봇에서는 카메라 캡처, USB 통신, 모터 응답, 모델 추론 시간이 모두 더해진다. 정책이 보는 장면은 이미 조금 과거일 수 있다.

다섯째, 데이터 분포 차이다. 시뮬레이션에서 본 물체 색, 배경, 초기 위치만 학습했다면 실제 책상 위의 작은 변화에도 흔들릴 수 있다.

그래서 시뮬레이션은 최종 검증이 아니라 안전한 예비 검증이다. NVIDIA의 sim-to-real 자료도 LeRobot을 데이터 수집, 학습, 배포, 평가, 반복을 하나로 연결하는 흐름으로 설명하며, 시뮬레이션 데이터와 실제 로봇 텔레오퍼레이션 데이터를 함께 활용하는 방식을 언급한다.² 현실 배포를 목표로 한다면 시뮬레이션에서 후보 정책을 고른 뒤, 실제 로봇에서 짧고 느린 평가를 수행하고, 실패 장면을 다시 데이터로 모아야 한다.

첫 실험의 성공 기준

이 장의 목표는 높은 성공률 하나가 아니다. 다음 다섯 가지가 확인되면 첫 실험은 성공이다.

1. 시뮬레이션 태스크의 관찰 공간과 행동 공간을 설명할 수 있다.

2. lerobot-train으로 정책 학습을 실행했다.

3. loss와 평가 성공률의 의미를 구분해 해석했다.

4. 저장된 체크포인트를 lerobot-eval로 다시 불러 평가했다.

5. 시뮬레이션 결과를 실제 로봇 성능으로 바로 믿지 않아야 하는 이유를 이해했다.

이제 학습 루프의 큰 틀은 통과했다. 다음 단계는 모방학습 정책들이 내부적으로 어떤 방식으로 행동을 예측하는지 이해하는 것이다. 모델의 이름을 외우는 것보다 중요한 것은 태스크, 데이터, 추론 속도에 맞는 정책을 고르는 기준을 갖는 일이다.

참고

¹GitHub - huggingface/lerobot

²LeRobot: Background and Community — Train an SO-101 Robot From Sim-to-Real With NVIDIA Isaac