2026년 7월 19일 현재 G1 작업은 M160a 오른팔 독립 excitation의 CPU 계약 7/7 통과까지 진행됐습니다. Isaac runtime capture, PPO, actor 선택, checkpoint 승격, router/WBC 연결은 아직 승인되지 않았습니다.
현재의 워크스페이스 구조는 처음부터 한 번에 만든 설계도가 아닙니다. Git 기록을 다시 보면, 6월 12일에는 H1 WBC와 보행 환경, RL 스크립트를 우선 붙였고, 이후 H1 보상과 재생 문제를 고치며 평가 계층을 추가했습니다. G1과 라우터, 이론 지도, 환경 handoff 규칙은 그 다음에 생겼습니다. 폴더를 예쁘게 나누는 과정이 아니라, 다음 실험을 막는 문제를 하나씩 줄인 결과입니다.
첫 단계: H1이 실제로 돌아가는 최소 경로
6월 12일의 22dc2aa 커밋은 WBC stack, H1 walk environment, RL scripts를 함께 추가했습니다. 이 시점의 질문은 “어떤 foundation model을 쓸까”보다 H1이 Isaac Lab에서 관측·행동·보상 루프를 갖고 실행될 수 있는가였습니다. 같은 날 Bezier 발 높이와 CoM 안정성 점검을 고친 90f5d2e가 나온 것도, 보행의 모양을 논하기 전에 궤적과 안정성 계산의 기본 조건부터 맞춰야 했기 때문입니다.
이 단계에서 만든 것은 완성된 보행 정책이 아니라 실험이 들어갈 자리를 만드는 일이었습니다. H1 환경, WBC 모듈, 학습 진입점이 분리돼 있어야 이후 보상이나 평가를 바꿔도 어디에서 변화가 일어났는지 알 수 있습니다.
이때 WBC와 RL을 함께 추가했지만 같은 성공 기준으로 묶지 않은 것도 이후 구조에 영향을 줬습니다. WBC는 scheduler·CoM planner·QP처럼 설명 가능한 컴포넌트 계약을 검사할 수 있고, RL은 보상과 rollout에서 나온 정책을 시나리오별로 평가해야 합니다. 두 경로가 같은 로봇 관절 명령으로 끝나더라도 실패를 되돌아갈 위치가 다르므로 모듈과 결과 파일을 분리했습니다.
두 번째 단계: 학습이 됐다는 말의 범위를 좁혔습니다
6월 14일에는 H1Walk-v0 PPO 실행, 재생 스크립트, reset 자세, GUI 관련 오류를 다루는 변경이 이어졌습니다. 이어서 71c1c38과 b67704e에서 CoM 높이·발 접촉·hip yaw·체공 시간·발 미끄럼과 관련된 보상 항목을 조정했습니다. 이 변경들은 모두 자연스러운 보행을 얻기 위한 시도였지만, 그 자체가 성공 증명은 아니었습니다.
그래서 6월 15일에는 165f91d에서 locomotion evaluation framework를 따로 추가했습니다. 정책이 넘어지지 않는 시간, 이동 거리, 속도 추종, 높이 안정성은 같은 질문이 아닙니다. 학습 코드 안에서 한 숫자만 보는 대신 평가 시나리오와 결과 파일을 분리한 이유가 여기에 있습니다.
평가 계층을 추가하면서 3,000 iteration이라는 학습 이력도 다시 해석됐습니다. 실행과 checkpoint 저장은 확인됐지만 평균 episode length 743만으로 자연스러운 보행을 승인할 수 없었습니다. 그 결과 reward v2의 항목 변경과 재학습이 다음 작업으로 남았습니다. 구조가 바뀐 계기는 새 기능을 넣고 싶어서가 아니라, 기존 숫자가 제목의 질문에 답하지 못했기 때문입니다.
세 번째 단계: 한 로봇·한 백엔드에 묶이지 않게 만들었습니다
같은 날 G1Walk-v0와 rough terrain 설정, G1용 WbcQP, rsl_rl checkpoint loading, router의 WBC 연결이 순서대로 들어왔습니다. 이 변화는 H1 코드의 복사가 아니라, 29 DOF G1과 여러 실행 백엔드를 같은 프로젝트 안에서 다룰 수 있게 하는 경계 작업이었습니다. 이후 G1은 후보 정책을 반복 비교하는 단계로 넘어갔고, M157–M159 중단과 M160a CPU 계약처럼 설계·실행·검토·승인을 분리하는 증거 게이트가 구조의 중심이 됐습니다.
G1에서 이 분리가 필요했던 장면은 M158d였습니다. 접촉 횟수와 충격량은 좋아졌지만 최소 clearance와 washout gate가 실패했습니다. 한 지표가 좋아진 후보를 자동으로 승격하는 구조였다면 이 분기는 계속 학습됐을 것입니다. 이어진 M159가 rank 27/44와 8.72×1017의 조건수를 보이자 teacher-overlay를 중단했고, M160a는 비학습 CPU 자극 설계로 질문을 줄였습니다. 이 과정에서 ‘코드–학습–평가’의 세 폴더보다 ‘설계–실행–적대검토–승인’의 상태 전이가 더 중요한 운영 구조가 됐습니다.
이 과정에서 데이터와 모델을 Git에서 제외하고, 실험 repo를 분리한 2ec07f0도 중요했습니다. 코드 변경과 대용량 산출물의 수명 주기가 다르다는 사실을 구조에 반영한 선택입니다.
마지막으로 문서도 구현의 일부가 됐습니다
6월 16일에는 Theory.md와 상세 이론 노트, MCP orchestration, 학습 라이프사이클 노트가 추가됐습니다. FLAM 재현 셋업과 H1 reward v2를 문서 흐름에 연결한 뒤, 6월 18일에는 환경을 옮길 때 읽고 쓰는 handoff 규칙도 넣었습니다. 이 기록들은 구현과 별개로 붙인 설명이 아닙니다. 새 논문·실험·보상 변경이 생겼을 때 어느 문서를 같이 고쳐야 하는지 정한 작업 규칙입니다.
이 변천사에서 남는 결론은 단순합니다. 현재 구조는 “최종 아키텍처”라서 생긴 것이 아니라, H1 보행 품질, G1 확장, 데이터 계보, 환경 전환처럼 실제로 반복된 문제를 더 작은 질문으로 나누기 위해 생겼습니다. 다음 구조 변경도 새 기술의 이름이 아니라, 어떤 연결이 다시 추적 불가능해졌는지를 기준으로 결정할 생각입니다.
함께 읽기: 현재 워크스페이스 구성도 · 실험을 멈추는 기준