연구 질문: 같은 로봇(Unitree G1), 같은 알고리즘(PPO), 같은 시뮬레이터(Isaac Lab)인데 NVIDIA의 범용 환경으로 학습하면 잰걸음에 절뚝이고, Unitree의 공식 환경으로 학습하면 팔리는 로봇처럼 걷습니다. 이 차이는 어디서 오는가, 미리 알 수 있는가, 좁힐 수 있는가. 05~07편의 실측에서 출발해 두 설정의 코드를 항목별로 해부한 기록입니다.
나중에 알게 된 사실 (재검증 노트) — 이 노트의 7절에서 저는 “지금 이대로는 논문이 안 된다”고 적고 필요한 실험을 나열했습니다. 그 목록이 그대로 08~11편의 실험 설계가 됐고, 결론 중 하나(6절 1번, “스타일 항목만 라이브러리로 만들면 격차가 닫힌다”)는 실험에서 기각됩니다. 이 글은 당시 기록 그대로 둡니다. 무엇을 잘못 예상했는지가 남아야 채점이 되니까요.
작성일: 2026-09-04 · 근거 코드: Isaac Lab v2.3.2 G1 velocity 설정 vs unitree_rl_lab G1-29dof velocity 설정
1. 출발점 — 실측된 병리
내장 환경으로 얻은 정책은 넘어지지 않고 조종에도 응하지만(07편: 16초 완주, 회전 오차 ±10°), 걸음은 이랬습니다(06편).
- 걸음 빈도 2.85Hz, 보폭 13.5cm — 사람 보행의 두 배 빈도로 종종거림
- 발 들림 좌 10.6 / 우 7.7cm — 37% 비대칭, 전진 구간마다 왼쪽으로 6~9° 흐름
- 명령 속도 −22% 미달
중요한 건 이 병리들이 04편의 환경 해부 시점에 미리 예측됐다는 점입니다. “위상 클록이 없고 대칭 보상이 없다”는 관찰에서 “박자 없는 걸음과 비대칭이 나올 것”을 적었고 그대로 나왔어요. 이 노트의 질문 ②(예측 가능성)에 대한 첫 번째 데이터 포인트입니다.
2. 두 설정의 계보 — 같은 프레임워크, 다른 목적
| NVIDIA 내장 (isaaclab_tasks) | Unitree 공식 (unitree_rl_lab) | |
|---|---|---|
| 만든 주체 | Isaac Lab 팀 (프레임워크 벤더) | Unitree (로봇 제조사) |
| 계보 | Anymal 등 4족 velocity 환경의 상속 — G1이 물려받아 최소 수정 | G1 실기 이전을 전제한 기체 전용 설계 |
| 존재 이유 | 프레임워크 데모·벤치마크 — “여러 로봇에서 그럴듯하게 돌아야” | 제품 — “이 기체가 실물에서 안 부서지고 잘 걸어야” |
| 로봇 모델 | NVIDIA 배포 37관절 USD (손가락 포함) | Unitree 자체 29관절 USD (실기와 동일 구성) |
이 표가 이미 절반의 답입니다. 보상 함수는 진공에서 설계되지 않아요. 누가 무엇에 책임지는 설정인가가 항목 하나하나에 배어 있습니다.
3. 항목별 해부
3.1 과제 보상 — 여기는 거의 같습니다
속도 추종(지수형), 회전 추종, 수직 속도·기울기 벌점. 두 설정 모두 동일 계열입니다. 차이는 과제가 아니라 과제 “밖”에서 시작됩니다.
3.2 걸음 형태 보상 — 결정적 차이
| 항목 | NVIDIA 내장 | Unitree 공식 | 우리 병리와의 대응 |
|---|---|---|---|
| 걸음 박자 | feet_air_time — “체공이 0.4초에 가깝게”라는 통계적 압력 |
feet_gait +0.5 — 주기 0.8초의 전역 위상 클록에 좌(위상 0)·우(위상 0.5) 접촉을 맞추는 게이트 |
2.85Hz 잰걸음: 통계 압력만으로는 빈도가 밑에서 안 잡힘 |
| 발 들림 | 없음 | foot_clearance +1.0 — 스윙 발 목표 높이 10cm |
좌우 들림 불균형: 목표치가 없으니 발마다 제멋대로 |
| 좌우 교대의 강제 | 없음 (air_time이 발별 독립) | 위상 offset [0, 0.5]가 교대 자체를 명세 | 절뚝임: 교대가 명세되지 않으면 비대칭이 벌점 없이 통과 |
| 몸통 높이 | 없음 (간접) | base_height −10, 목표 0.78m |
우리 정책은 0.665m로 웅크림 |
| 정지 명령 처리 | 없음 | stand_still — 명령이 0이면 기본자세 복귀 채점 |
(미측정) |
| 생존 보너스 | 넘어짐 벌점 −200 (음의 강화) | alive +0.15 (양의 강화) + 자세·높이 기반 종료 |
학습 초반 탐색 안정성의 차이 |
시즌 1에서 셔플을 고칠 때 우리가 unitree_rl_gym에서 빌려온 항목들(위상 클록 contact, 발 들림 8cm, 미끄럼 금지)이 신형 unitree_rl_lab에도 그대로, 더 다듬어져 있습니다. 제조사는 이 항목들을 6년째 유지하고 있어요. 우연이 아니라 누적된 실기 경험의 코드화라는 방증입니다.
3.3 실기 지향 벌점 — 크기의 차이
| 항목 | NVIDIA (flat) | Unitree | 배율 |
|---|---|---|---|
| action_rate | −0.005 | −0.05 | 10× |
| 관절 한계 벌점 | −1.0 (발목만) | −5.0 (전 관절) | 5×+ |
| 에너지 | 없음 (토크² −2e-6) | energy Σ|τ·q̇| −2e-5 |
실측 전력 대응 |
| 관절 속도 벌점 | 없음 | −0.001 | — |
| 액션 스케일 | 0.5 | 0.25 | 절반 |
전부 한 방향을 가리킵니다. 모터를 실물처럼 아껴 쓰라. 부드러움은 미학이 아니라 모터 수명과 발열의 문제고, 그 비용을 아는 쪽이 가중치를 키웁니다.
3.4 보상 밖의 차이 — 그리고 이것이 절반입니다
보상만 비교하면 놓치는 것들이 있고, 우리 병리의 상당 부분은 여기서도 옵니다.
- 액추에이터가 실물 명세입니다. Unitree 설정은 액추에이터 그룹을 실제 모터 형번(“N7520-14.3”, “N7520-22.5”, “N5020-16”, “W4010-25”)으로 묶고, 토크 한계를 실물 값(88 / 139 / 25 / 5 N·m)까지 넣습니다. NVIDIA 설정은 다리·팔 일괄 300N·m — G1 무릎 실물(139N·m)의 두 배가 넘는 가공의 힘입니다. 가공의 토크로 배운 보행은 실물에서 재현되지 않아요.
- 관측 철학이 다릅니다. Unitree 정책은 몸통 선속도를 관측에서 뺍니다(실기에서 추정이 어려운 값 — 시즌 1도 같은 이유로 뺐습니다). 대신 5프레임 히스토리를 쌓고, critic에게만 선속도를 주는 비대칭 actor-critic을 씁니다. NVIDIA 설정은 선속도를 그냥 줍니다. 시뮬 안에서는 공짜지만 실기로 가면 없는 센서죠.
- 랜덤화 강도. NVIDIA G1 설정은 밀치기·질량 랜덤화를 명시적으로 꺼 뒀습니다. Unitree는 마찰 0.3~1.0, 몸통 질량 −1~+3kg, 5초마다 밀치기를 전부 켭니다. 제조사는 이 기체가 그 랜덤화를 버티며 학습되는 레시피를 이미 아는 겁니다.
- 명령 커리큘럼. Unitree는 명령 범위를 ±0.1부터 시작해 학습이 되는 만큼 넓힙니다. 걸음이 자리 잡기 전에 어려운 명령으로 정책을 흔들지 않아요.
- 종료 철학. NVIDIA는 몸통 접촉(넘어진 뒤에야 판정), Unitree는 높이 0.2m 미만 또는 기울기 0.8rad(넘어지는 중에 판정)입니다. 후자가 위험한 자세 자체를 더 일찍 학습에서 배제합니다.
4. 왜 이런 차이가 생기는가
보상은 명세(specification)이고, 학습은 명세의 빈틈을 찾는 최적화입니다. 속도 추종과 안정 벌점만으로는 “그 속도로 이동하는 무한히 많은 몸짓” 전부가 같은 점수를 받습니다. 해가 미결정 상태인 거죠. 그 자유도 위에서 PPO가 고르는 것은 사람 눈의 자연스러움이 아니라 최적화 지형에서 가장 오르기 쉬운 경사입니다.
잰걸음이 선택되는 데는 이유가 있습니다. 보폭이 작고 빈도가 높으면 순간 균형 마진이 크고, 넘어짐 벌점 −200을 피하기 쉬우며, 추종 오차도 완만하게 줄일 수 있어요. 즉 잰걸음은 버그가 아니라 그 명세의 합리적 최적해입니다.
차이의 근원을 한 문장으로 줄이면 이렇습니다. 범용 설정은 “과제”를 명세하고, 제조사 설정은 “과제 + 이 기체의 물리적·상업적 제약”을 명세한다. 후자의 추가 항목들은 전부 실기에서 지불한 수업료의 코드화입니다.
5. 미리 알 수 있는가 — 명세 감사라는 관점
이번 시리즈에서 실제로 작동한 절차가 있습니다. 04편에서 학습 전에 한 일이 사실상 이것이었어요.
- 보상·관측·이벤트 명세를 표로 덤프합니다 (도구:
04_dissect_env.py). - 각 “품질 축”에 대해 묻습니다 — 이 축을 채점하는 항목이 있는가? – 박자(빈도) → 없음 → 빈도는 방치됨 → 극단(잰걸음/셔플) 예측 – 좌우 대칭 → 없음 → 비대칭 방치 → 절뚝임 예측 – 발 들림 목표 → 없음 → 들쭉날쭉 예측
- 방치된 축의 목록이 곧 예상 병리 목록이 됩니다.
- 학습 후 걸음 지표로 축별 실측 → 예측 대조.
이번에 이 절차는 2/2 적중했습니다(잰걸음, 비대칭). 표본이 하나라 아직 일화지만, 절차 자체는 일반화 가능해 보입니다. “보상이 침묵하는 자유도는 최적화가 마음대로 쓴다”를 축 단위로 기계적으로 적용하는 거죠. 관건은 (a) 품질 축의 표준 목록화, (b) 축과 보상 항목의 대응을 자동 판별하는 방법입니다.
6. 범용이 제조사 보상에 근접할 수 있는가
방안을 실현 가능성 순으로 적습니다.
- 스타일 항목의 라이브러리화 (즉시 가능) —
feet_gait같은 항목은 사실 로봇 불문 재사용 가능하고, Isaac Lab 코드베이스에 유사 함수들이 이미 있습니다. 문제는 함수의 부재가 아니라 기본 설정이 그걸 안 쓰는 것이에요. “2족 보행 스타일 표준 팩”을 기본 켜짐으로 제공하는 것만으로 격차의 큰 부분이 닫힐 겁니다. → 08편에서 직접 검증합니다. - 하드웨어 명세의 자동 주입 (표준화 문제) — 모터 형번에서 토크·속도 한계로 가는 정보는 제조사가 유일하게 압니다. USD에 액추에이터 명세를 싣는 관행이 표준이 되면, 범용 프레임워크도 “가공의 300N·m”를 쓸 이유가 없어집니다.
- 스타일을 데이터로 대체 (AMP/mimic) — 보상 설계 대신 참조 동작과의 유사도를 판별기로 채점합니다. 보상 명세의 빈틈 문제를 정면 우회하지만, 데이터와 새 학습 구조가 필요해요.
- 지표 루프 자동 튜닝 — 걸음 지표를 목적 함수로 보상 가중치를 밖에서 탐색합니다. 계산 비용이 크지만 “품질 축의 실측”이 있으면 기계적으로 돌릴 수 있습니다.
7. 논문이 될 수 있는가 — 솔직한 평가
지금 이대로는 아닙니다. 현재 증거는 사례 1건(1 seed × 1 로봇 × 환경 쌍 1개, 그나마 Unitree 쪽은 코드 분석만)이에요. 블로그 연구 노트로는 충분하지만 논문 주장으로는 부족합니다. 그러나 씨앗은 있습니다.
| 형태 | 주장 | 필요한 실험 | 난이도 |
|---|---|---|---|
| (i) 실증 비교 연구 | “격차를 걸음 지표로 정량화하고, 절제로 어느 항목이 어느 병리를 막는지 인과 규명” | 두 환경 각 N-seed 학습 + 공식 항목을 하나씩 얹는 사다리 × 3~5 seeds | 중 — 가장 현실적 |
| (ii) 방법론: 명세 감사 | “방치된 품질 축을 학습 전에 식별하면 병리를 예측할 수 있다” | 축 목록 정의 + 자동 판별기 + 여러 환경에서 예측→실측 | 상 — 신규성은 가장 큼 |
| (iii) 포지션/서베이 | “제조사 보상은 실기 경험의 코드화다 — 공개 보상 설정들의 계보 분석” | 공개 설정들의 통시적 코드 분석 | 중 — 실험 부담은 적음 |
추천은 (i)을 뼈대로, 5절의 예측-검증을 부주장으로 얹는 하이브리드입니다. “격차의 분해” — 격차를 보상 항목·액추에이터 명세·관측 철학·랜덤화 네 성분으로 나누고 각각의 기여를 절제로 측정하는 것이죠.
정직한 리스크 하나. “제조사 보상이 더 낫다”는 주장 자체는 새롭지 않습니다(당연하다고 여겨질 거예요). 가치는 얼마나 나은지의 정량화와 왜, 어느 성분 때문인지의 분해, 그리고 학습 전 예측 가능성에서 나와야 합니다.
8. 다음 실험
이 노트의 주장을 코드로 시험합니다. 내장 환경에 Unitree 항목을 한 번에 하나씩 얹으며 학습하고 06편 지표로 축별 변화를 재는 절제 사다리입니다. 첫 번째는 당연히 feet_gait (위상 게이트)예요. 예측은 이렇습니다 — 빈도가 2.85Hz에서 1.25Hz(주기 0.8초의 발당 빈도) 부근으로 떨어지고 보폭이 늘 것.
예측을 먼저 적어 두고 학습을 돌립니다 → 08. 보상 절제 사다리
그 전에 이 현상이 학계에서 이미 알려진 것인지 확인하고 싶다면 → 연구 노트 R02. 문헌 지도
근거 소스: unitree_rl_lab · unitree_rl_gym · Isaac Lab · 이 저장소의 04~07편 실측.