내 데이터로 정책 학습하기

공개 예제에서 내 태스크로 넘어가기

여기서부터는 LeRobot을 "따라 해보는 도구"가 아니라 "내 로봇을 학습시키는 실험 환경"으로 사용한다. 공개 데이터셋으로 정책을 학습할 때는 데이터 구조와 로봇 구성이 이미 맞춰져 있다. 하지만 직접 수집한 데이터셋을 쓰면 책임이 사용자에게 온다. 카메라 이름, 행동 차원, 로봇 상태의 의미, 데이터셋 경로, 출력 체크포인트 위치를 모두 확인해야 한다.

LeRobot은 실제 로봇 학습을 위한 PyTorch 기반의 모델, 데이터셋, 도구를 제공하며, 데이터셋과 사전학습 모델을 Hugging Face Hub와 함께 다루는 흐름을 중심에 둔다.¹ 따라서 내 데이터로 학습할 때도 기본 단위는 "데이터셋 repo_id + 정책 설정 + 실행 결과 디렉터리"다.

처음부터 복잡한 정책을 고르지 말자. 조작 태스크라면 ACT를 기준선으로 두는 것이 좋다. ACT는 LeRobot에서 초보자에게 먼저 권장되는 경량 모방학습 정책이며, 여러 카메라 이미지와 현재 관절 상태를 입력으로 받아 미래 행동 묶음을 예측한다.² 첫 실험의 목적은 최고 성능이 아니다. 내 데이터가 정책 학습 파이프라인을 제대로 통과하는지 확인하는 것이다.

AI 생성 이미지

학습 전에 데이터 특징을 다시 확인하기

학습 명령을 실행하기 전에 meta/info.json을 열어 다음 네 가지를 확인한다.

cat ./data/pick_cube_clean_v1/meta/info.json | jq '.features'

가장 먼저 볼 것은 카메라 키다. 예를 들어 데이터셋에 다음과 같은 키가 있다고 하자.

observation.images.front
observation.images.wrist
observation.state
action

이 이름은 단순한 라벨이 아니다. 모델이 학습할 입력 이름이다. 학습 때 front, wrist라는 이름으로 저장했다면, 나중에 실제 로봇에서 정책을 실행할 때도 카메라 이름을 같은 방식으로 맞춰야 한다. 배포 단계에서 카메라 장치는 바뀔 수 있지만, 정책이 기대하는 입력 키는 바뀌면 안 된다.

다음은 observation.state의 차원이다. 보통 관절 위치, 그리퍼 상태, 때로는 엔드이펙터 위치 같은 저차원 로봇 상태가 들어간다. 중요한 것은 숫자의 개수가 아니라 의미다. 6개 관절과 1개 그리퍼로 수집했다면 상태 차원은 7일 수 있다. 반대로 그리퍼를 행동에 넣지 않았다면 정책은 그리퍼를 제어할 방법을 배우지 못한다.

action 차원은 더 중요하다. 학습된 정책의 출력 크기는 action의 shape로 결정된다. 데이터셋의 action이 6차원인데 실제 로봇 제어기는 7차원 명령을 기대하면, 학습이 끝나도 배포에서 막힌다. 이 문제는 학습 옵션으로 고치는 것이 아니다. 수집 단계의 행동 정의를 고쳐 다시 기록해야 한다.

로봇 설정도 같은 맥락에서 본다. 학습 자체는 로봇 포트나 모터 ID에 직접 연결하지 않는다. GPU 서버에서 데이터만 보고 학습하기 때문이다. 그러나 데이터가 어떤 로봇 구성으로 만들어졌는지는 반드시 일관되어야 한다. 같은 so101이라도 그리퍼 축이 반대로 기록되었거나, 관절 순서가 다른 설정에서 수집한 데이터를 섞으면 정책은 평균적으로 이상한 행동을 배운다.

기본 학습 명령 만들기

Hub에 올린 정제 데이터셋을 사용한다면 기본 명령은 단순하다.

export HF_USER=your_huggingface_name
export DATASET_REPO_ID=${HF_USER}/pick_cube_clean_v1
export RUN_NAME=act_pick_cube_clean_v1_seed42

lerobot-train \
  --dataset.repo_id=${DATASET_REPO_ID} \
  --policy.type=act \
  --output_dir=outputs/train/${RUN_NAME} \
  --job_name=${RUN_NAME} \
  --policy.device=cuda \
  --wandb.enable=true \
  --policy.repo_id=${HF_USER}/${RUN_NAME}

공식 ACT 문서도 lerobot-train에서 dataset.repo_id, policy.type=act, output_dir, job_name, policy.device, wandb.enable, policy.repo_id를 지정하는 흐름을 예시로 든다.² GPU가 없다면 --policy.device=mps나 cpu를 사용할 수 있지만, 실제 이미지 기반 학습은 가능한 한 NVIDIA GPU에서 시작하는 편이 낫다.

로컬 데이터셋을 사용할 때는 두 가지 방식이 있다. 하나는 정제본을 Hub에 올려 repo_id로 불러오는 방식이다. 다른 하나는 로컬 루트 경로를 지정하는 방식이다.

lerobot-train \
  --dataset.repo_id=${HF_USER}/pick_cube_clean_v1 \
  --dataset.root=/data/lerobot \
  --policy.type=act \
  --output_dir=outputs/train/${RUN_NAME} \
  --job_name=${RUN_NAME} \
  --policy.device=cuda

설치한 LeRobot 버전에 따라 로컬 경로 옵션 이름이 조금 다를 수 있다. 실행 전에는 반드시 다음 명령으로 현재 버전의 인자를 확인한다.

lerobot-train --help

중요한 것은 "경로 문자열"이 아니라 같은 데이터셋을 안정적으로 다시 불러올 수 있는가다. 오늘 학습한 pick_cube_clean_v1이 다음 주에도 같은 에피소드, 같은 split, 같은 카메라 키로 로드되어야 한다.

단일 카메라와 다중 카메라의 차이

단일 카메라는 시작하기 쉽다. 설정이 단순하고 GPU 메모리를 적게 쓴다. 예를 들어 정면 카메라 하나만 있으면 모델은 한 시점의 외부 장면과 로봇 상태를 보고 행동을 예측한다. 큐브가 항상 잘 보이고 손이 가려지지 않는 단순 태스크라면 이 구성으로도 충분할 수 있다.

다중 카메라는 정보가 많다. 정면 카메라는 전체 작업 공간을 보여주고, 손목 카메라는 그리퍼와 물체의 접촉 순간을 자세히 보여준다. 문제는 비용이다. 카메라가 하나 늘 때마다 이미지 인코더가 처리해야 할 입력이 늘어난다. 해상도, 배치 크기, 카메라 수가 함께 커지면 GPU 메모리는 빠르게 부족해진다.

메모리가 부족하면 정책을 바꾸기 전에 다음 순서로 줄인다.

• 이미지 해상도를 낮춘다.

• 배치 크기를 줄인다.

• 카메라 수를 줄여 단일 카메라 기준선을 먼저 만든다.

• 불필요하게 긴 에피소드나 중복 프레임을 줄인다.

• 학습이 되는지 확인한 뒤 손목 카메라를 추가한다.

다중 카메라가 항상 좋은 것은 아니다. 두 번째 카메라가 흔들리거나 초점이 자주 나가면 정보가 아니라 노이즈가 된다. 성능이 낮을 때 "카메라를 더 붙이자"라고 바로 판단하지 말고, 현재 카메라가 태스크의 핵심 순간을 제대로 보고 있는지 먼저 확인한다.

로그는 손실 하나만 보지 않는다

학습이 시작되면 가장 먼저 보는 값은 손실이다. 손실이 내려간다는 것은 모델의 예측 행동이 데이터셋의 행동과 가까워지고 있다는 뜻이다. 하지만 손실 감소만으로 좋은 정책이라고 판단하면 안 된다.

세 가지를 함께 본다.

첫째, 학습 손실이다. 초반에 빠르게 내려가다가 완만해지는 것이 일반적이다. 처음부터 거의 내려가지 않으면 데이터 로딩, 행동 차원, 학습률, 정규화 문제를 의심한다.

둘째, 검증 손실이다. 학습 손실은 계속 내려가는데 검증 손실이 오르기 시작하면 과적합일 수 있다. 모델이 작업 원리를 배운 것이 아니라 학습 에피소드의 배경, 물체 위치, 조작자의 습관을 외우는 상태다.

셋째, 행동 예측 품질이다. 검증 배치에서 실제 행동과 예측 행동을 시간축으로 비교해 본다. 관절 값이 전체적으로 따라가지만 조금 부드럽게 늦는 정도는 흔하다. 그러나 그리퍼가 닫혀야 하는 순간에 계속 열림을 예측하거나, 특정 관절만 항상 0 근처에 머문다면 단순한 손실 문제가 아니다. 데이터 정의나 행동 스케일을 다시 봐야 한다.

Weights & Biases를 켜면 손실, 학습 속도, GPU 사용량을 대시보드에서 볼 수 있다. 다만 대시보드는 판단을 대신해 주지 않는다. 좋은 실험 기록은 숫자와 함께 "어떤 데이터셋을 썼는지", "카메라는 몇 개인지", "어떤 실패가 남았는지"를 적어 둔 기록이다.

체크포인트와 실험 이름을 관리하기

정책 학습은 한 번에 끝나지 않는다. 그래서 재현성이 중요하다. 최소한 다음 항목은 매 실험마다 고정하거나 기록한다.

• 데이터셋 이름과 버전: pick_cube_clean_v1

• 정책 종류: act

• 실험 이름: act_pick_cube_clean_v1_seed42

• 랜덤 시드: 42

• 총 학습 step 또는 epoch

• 체크포인트 저장 주기

• 사용한 LeRobot 버전과 Git commit

• 카메라 구성과 이미지 해상도

체크포인트는 너무 드물게 저장하지 않는다. 마지막 모델만 남기면 중간에 가장 좋았던 시점을 놓칠 수 있다.

lerobot-train \
  --dataset.repo_id=${DATASET_REPO_ID} \
  --policy.type=act \
  --output_dir=outputs/train/${RUN_NAME} \
  --job_name=${RUN_NAME} \
  --policy.device=cuda \
  --seed=42 \
  --steps=100000 \
  --save_checkpoint=true \
  --save_freq=10000

옵션 이름은 버전에 따라 달라질 수 있으므로 현재 설치본의 --help를 기준으로 맞춘다. 핵심은 1만 step마다 남기든, 일정 시간마다 남기든, 나중에 "어느 시점의 모델이 가장 좋았는지" 비교할 수 있게 하는 것이다.

설정 파일을 따로 관리하는 것도 좋다. CLI 명령이 길어지면 실수하기 쉽다. 실험 폴더 안에 command.txt, config.yaml, notes.md를 저장해 두면 나중에 같은 조건으로 다시 실행할 수 있다. 랜덤 시드를 고정해도 GPU 연산 특성 때문에 완전히 같은 숫자가 나오지 않을 수 있다. 그래도 시드를 기록하면 비교의 흔들림을 크게 줄일 수 있다.

실패 원인을 나누어 보기

학습이 실패했을 때 원인을 한꺼번에 생각하면 답이 안 보인다. 다음처럼 나누어 본다.

데이터 부족은 보통 "아는 상황에서는 잘하고 조금만 바뀌면 실패"로 나타난다. 물체가 훈련 때와 같은 위치에 있으면 성공하지만 3cm만 옆으로 가도 실패한다면 모델보다 데이터 분포가 좁은 것이다.

모델 용량 부족은 다르다. 데이터가 충분히 깨끗하고 반복해도 학습 손실 자체가 잘 내려가지 않는다. 이때는 모델 크기, 행동 horizon, 카메라 구성, 정책 종류를 조정할 수 있다. 하지만 작은 데이터셋에서 모델부터 키우면 과적합만 빨라질 수 있다.

하이퍼파라미터 문제는 학습 곡선이 불안정할 때 드러난다. 손실이 크게 출렁이거나 갑자기 NaN이 되면 학습률을 낮추고, 배치 크기와 정규화 설정을 확인한다. 한 번에 여러 값을 바꾸지 말고 하나씩 바꾼다. 그래야 무엇이 효과가 있었는지 알 수 있다.

첫 성공보다 반복 가능한 성공이 중요하다

내 데이터로 정책을 학습하는 단계의 목표는 "한 번 움직이는 모델"이 아니다. 같은 데이터셋과 같은 설정으로 다시 학습했을 때 비슷한 결과가 나오고, 실패했을 때 원인을 추적할 수 있는 실험 체계를 만드는 것이다.

처음에는 정제한 데이터셋 하나, ACT 하나, 단일 카메라 하나로 시작한다. 그다음 검증 손실과 실제 평가 결과를 보고 다중 카메라, 데이터 추가 수집, 정책 변경으로 확장한다. 좋은 로봇 정책은 명령어 한 줄에서 나오지 않는다. 데이터 정의, 학습 설정, 로그 해석, 체크포인트 관리가 맞물릴 때 나온다.

참고

¹LeRobot · Hugging Face

²ACT (Action Chunking with Transformers) · Hugging Face