로봇이 걷는다는 말은 아직 부족합니다

로봇 데모 영상은 쉽게 설득합니다. 네 발 로봇이 걷고, 방향을 바꾸고, 작은 장애물을 넘습니다. 카메라가 잘 잡히면 이미 제품처럼 보입니다. 다만 피지컬 AI에서 "걷는다"는 말은 너무 넓습니다. 어떤 바닥에서 걷는지, 몇 번 중 몇 번 성공하는지, 넘어졌을 때 다시 일어나는지, 속도와 안정성이 동시에 유지되는지까지 봐야 합니다.

소프트웨어 데모는 실패해도 새로고침하면 됩니다. 로봇 데모는 다릅니다. 물리 세계에는 마찰과 관성이 들어옵니다. 센서 지연, 배터리, 바닥 재질도 영향을 줍니다. 예기치 않은 충돌도 피할 수 없습니다. 시뮬레이션에서 매끄럽게 걷던 정책이 실제 하드웨어에서는 한쪽 다리를 끌거나, 회전할 때 미끄러지거나, 작은 턱 앞에서 멈출 수 있습니다.

이 때문에 피지컬 AI의 핵심 질문은 "움직였나"에서 멈추면 안 됩니다. "어떤 조건에서 움직였고, 어떤 조건에서 무너졌고, 그 차이를 다시 재현할 수 있나"로 내려가야 합니다. 데모 이후의 QA가 없으면 로봇은 제품이 아니라 영상에 머뭅니다.

핵심 정리

1. 01로봇이 걷는다는 말은 속도, 안정성, 방향 전환, 복구, 반복 성공률을 포함해야 의미가 있습니다.
2. 02피지컬 AI 검증은 시뮬레이션 점수와 실제 하드웨어 로그를 연결해야 합니다.
3. 03좋은 데모는 성공 장면만 보여주지 않고 실패 조건과 복구 경로까지 남깁니다.
4. 04브라우저 기반 QA나 자동화된 리포트는 로봇 실험을 영상 감상이 아니라 운영 가능한 검증으로 바꾸는 출발점입니다.

용어 정리

보행 정책

로봇의 센서 입력을 받아 다음 관절 명령이나 움직임을 결정하는 제어 모델입니다.

policy

Sim-to-real

시뮬레이션에서 학습한 정책을 실제 하드웨어로 옮기는 과정입니다. 물리 차이 때문에 성능이 흔들릴 수 있습니다.

transfer

복구 행동

미끄러짐, 충돌, 넘어짐 직전 같은 상태에서 다시 안정 자세로 돌아오는 능력입니다.

recovery

조건 매트릭스

속도, 바닥, 경사, 장애물, 배터리 상태처럼 테스트 조건을 조합한 표입니다.

QA

데모는 평균이 아니라 최고 장면을 보여줍니다

로봇 영상은 대부분 성공 장면으로 편집됩니다. 이 자체가 나쁘다는 뜻은 아닙니다. 연구와 제품을 설명하려면 잘된 장면이 필요합니다. 문제는 우리가 그 장면을 평균 성능으로 착각할 때 생깁니다. 한 번 성공한 보행과 100번 중 95번 성공하는 보행은 전혀 다릅니다.

피지컬 AI에서는 분산이 중요합니다. 같은 명령을 줘도 바닥 마찰이 조금 달라지고, 관절 온도가 달라지고, 센서 노이즈가 달라집니다. 로봇은 매번 거의 같은 세계를 만나는 것 같지만 실제로는 조금씩 다른 세계를 밟습니다. 이 작은 차이가 누적되면 데모에서는 보이지 않던 실패가 나옵니다.

이 때문에 테스트는 성공 여부를 하나의 숫자로 줄이면 안 됩니다. 앞으로 1m 이동했는지, 회전 중 몸통 기울기가 얼마나 커졌는지, 발 미끄러짐이 어느 구간에서 발생했는지, 명령과 실제 속도의 차이가 얼마나 되는지 봐야 합니다. "걸었다"는 말은 여러 지표의 묶음이어야 합니다.

이 관점은 모델 선택에도 영향을 줍니다. 가장 빠른 정책이 항상 좋은 정책은 아닙니다. 실제 제품에서는 조금 느려도 덜 넘어지고, 배터리를 덜 쓰고, 예외 상황에서 멈출 줄 아는 정책이 더 낫습니다. 데모는 속도를 좋아하지만 운영은 안정성을 요구합니다.

시뮬레이션 점수와 실제 로그를 이어야 합니다

로봇 개발에서 시뮬레이션은 필수입니다. 실제 하드웨어를 매번 넘어뜨리며 학습할 수 없고, 다양한 조건을 빠르게 만들기도 어렵습니다. 시뮬레이션은 수천 번의 실험을 싸게 돌릴 수 있게 해줍니다. 다만 시뮬레이션 점수만으로 제품성을 말하기는 어렵습니다.

시뮬레이션은 세계를 단순화합니다. 마찰 모델과 접촉 모델은 실제와 완전히 같을 수 없습니다. 센서 지연과 모터 응답도 차이를 만듭니다. 이 차이를 줄이기 위해 domain randomization이나 system identification을 쓰지만, 마지막 검증은 실제 하드웨어에서 해야 합니다. 실험실 바닥에서 되는 정책이 사무실 카펫에서 안 될 수도 있습니다.

이 때문에 필요한 것은 두 세계를 잇는 로그입니다. 시뮬레이션에서 어떤 조건으로 성공했는지, 실제 하드웨어에서 어떤 조건으로 실패했는지를 같은 축으로 기록해야 합니다. 바닥과 속도는 같은 리포트 안에서 비교하게 둡니다. 방향 전환과 장애물도 봐야 합니다. 배터리 상태와 센서 이상 여부도 함께 봅니다.

이 연결이 없으면 실패 원인을 추측하게 됩니다. 모델이 나쁜지, 시뮬레이션 물리가 틀렸는지, 센서 캘리브레이션이 문제인지, 명령 인터페이스가 흔들린 것인지 알기 어렵습니다. 피지컬 AI의 QA는 단순히 결과를 보는 일이 아니라 실패를 분해하는 일입니다.

1. 01시뮬레이션 조건
2. 02정책 실행
3. 03하드웨어 재현
4. 04센서 로그
5. 05실패 분류
6. 06다음 실험 설계

브라우저 QA는 로봇 실험을 운영으로 바꾸는 작은 입구입니다

로봇 검증이라고 하면 거대한 실험실과 복잡한 계측 장비를 떠올리기 쉽습니다. 물론 실제 하드웨어 검증에는 장비가 필요합니다. 다만 작은 팀이 처음부터 갖춰야 할 것은 모든 장비가 아니라 반복 가능한 실험 기록입니다. 어떤 명령을 보냈고, 어떤 결과가 나왔고, 어떤 로그를 남겼는지 브라우저에서 확인할 수 있어야 합니다.

브라우저 기반 QA의 장점은 공유입니다. 시뮬레이션 결과와 하드웨어 영상을 한 화면에 모으면 팀이 같은 장면을 봅니다. 센서 그래프와 실패 분류도 함께 놓을 수 있습니다. "잘 걷던데요"라는 감상 대신 "회전 속도 0.6 이상에서 왼쪽 발 미끄러짐이 반복됩니다"라고 말할 수 있습니다. 대화가 감상에서 조건으로 이동합니다.

또 하나의 장점은 자동화입니다. 테스트 조건 매트릭스를 만들고, 각 조건의 결과를 저장하고, 실패를 태깅하면 다음 실험이 쉬워집니다. 에이전트가 실패 로그를 읽고 다음 조건을 제안할 수도 있습니다. 이때 AI는 로봇을 직접 제어하는 모델만이 아니라 실험 운영을 돕는 도구가 됩니다.

물론 브라우저 QA가 실제 안전 검증을 대체하지는 않습니다. 로봇은 물리적 손상을 만들 수 있고, 사람 주변에서 움직이면 더 엄격한 기준이 필요합니다. 다만 초기 개발 단계에서 실험을 재현 가능하게 만드는 것만으로도 큰 차이가 생깁니다. 영상 폴더가 아니라 실험 장부가 생깁니다.

피지컬 AI의 제품성은 실패를 다루는 방식에서 나옵니다

좋은 로봇 데모를 보는 것은 즐겁습니다. 다만 제품으로 이어지는 팀은 실패를 더 많이 봅니다. 넘어지는 장면을 지우지 않고, 조건을 기록하고, 다시 재현하고, 정책과 하드웨어와 환경 중 어디가 문제인지 나눕니다. 피지컬 AI에서 실패는 부끄러운 장면이 아니라 데이터입니다.

이 관점은 과장도 줄여줍니다. 로봇이 한 번 걸었다고 해서 모든 환경에서 쓸 수 있는 것은 아닙니다. 반대로 자주 실패한다고 해서 가치가 없는 것도 아닙니다. 실패가 재현 가능하고, 원인이 분류되고, 다음 실험으로 이어진다면 개발은 앞으로 갑니다. 실패가 영상 밖으로 사라질 때가 더 위험합니다.

이 때문에 "로봇이 걷는다"는 말은 앞으로 더 구체적이어야 합니다. 어떤 표면에서 어떤 속도로 움직였는지 먼저 봅니다. 어떤 장애물에서 몇 번 중 몇 번 성공했는지도 기록합니다. 실패 후 어떻게 멈추거나 회복했는지도 함께 봐야 합니다. 피지컬 AI의 진짜 진전은 멋진 한 장면보다 실패를 운영 가능한 정보로 바꾸는 능력에 있습니다.