자동차를 조립하는 로봇 팔의 소프트웨어를, 사람 대신 AI가 짤 수 있을까요? 답부터 말하면 절반만 됩니다. 지금의 코딩 AI는 코드를 짜고, 테스트를 돌리고, 틀린 데를 고치는 일은 제법 합니다. 그런데 자기가 설계한 구조물이 쇳덩어리가 되어 하중을 받을 때 어떻게 버틸지는 거의 못 내다봅니다.
하버드와 조지아텍 연구진이 내놓은 RLE-Bench가 그 경계선을 숫자로 그었습니다. 풀어 쓰면 '로봇 학습 엔지니어 자격시험'입니다. 시험을 뜯어보면 한 가지 패턴이 계속 반복됩니다. AI는 점수로 또렷하게 매겨지는 목표는 잘 맞춥니다. 반대로 채점 기준을 숨겨두면, 여러 조건이 얽혀 뒤늦게 드러나는 결과를 놓칩니다. 이 글은 그 한 줄을 세 장면으로 따라갑니다.
지금까지 코딩 AI의 실력을 재는 시험은 대부분 모니터 안에서 끝났습니다. 저장소의 버그 이슈를 패치로 고치거나, 긴 터미널 작업을 시키거나, 머신러닝 모델을 훈련시키는 식이었죠. 반대로 로봇 쪽 시험은 물리 세계를 다루긴 해도, 보통 '정책 하나'의 성능만 쟀습니다. 정책(policy)이란 '이 상황에선 이렇게 움직여라'를 정해둔 로봇의 행동 규칙입니다. 신입을 뽑으면서 "로봇 팔이 컵을 집는 성공률"만 보고 끝내는 셈입니다.
현장 엔지니어의 일은 그 앞에 훨씬 많습니다. 장비를 조립하고, 센서를 보정하고, 고장을 진단하고, 하드웨어 한계 안에서 제어기를 짜고, 안 되면 모델을 다시 훈련시킵니다. RLE-Bench는 이 과정 전체를 한 시험장에 올렸습니다. '코딩 능력'과 '로봇 동작'을 따로 재던 기존 방식을 묶어, '로봇을 만들어내는 코딩 능력'이라는 새 시험지를 편 것입니다.
이 시험의 가장 영리한 설계는 개발과 채점을 분리한 데 있습니다. AI는 정해진 예산(시간·상호작용 횟수·연산 자원) 안에서 작업공간을 주무르며 산출물을 만들어 제출합니다. 그러면 그 산출물이 채점관 전용 환경으로 넘어가 평가받습니다.
이때 채점에 쓰는 세 가지를 AI에게 숨깁니다. 매번 상황을 조금씩 바꾸는 무작위 설정값(시드), 물체의 실제 위치처럼 채점관만 아는 정답 정보(특권 상태), 그리고 채점 기준이 되는 정답 파일입니다. 개발 중엔 본 적 없는 장면·로봇 몸체로 채점하니, 외운 답이 아니라 일반화된 실력이 드러납니다. 이 '숨김'이 뒤에서 세 번이나 결정적인 역할을 합니다.
51개 과제는 비슷한 성격끼리 9개 묶음(패밀리)으로, 다시 네 갈래 일로 정리됩니다. 각 갈래가 무엇을 보는지 대표 과제 하나씩으로 짚겠습니다.
최종 점수(RLE Index)는 이 네 갈래에 똑같은 가중치를 걸어 평균 냅니다. 한 분야만 잘해서는 순위를 끌어올릴 수 없는 구조입니다.
시험대에 오른 선수들 평가 대상은 11개 '모델-하네스' 조합입니다. 여기서 하네스(harness)란, AI 모델에게 파일 읽기·쓰기, 터미널 명령 실행 같은 '손발'을 쥐여주는 도구 모음이자 작업 환경입니다. 모델이 두뇌라면 하네스는 몸인 셈이죠. - 상용 선두 모델들은 각자의 제작사가 만든 전용 하네스(코딩 에이전트 CLI) 위에서 돌았습니다. - 전용 하네스가 없는 오픈소스 모델들은 범용 코딩 하네스의 맥락 관리 전략을 빌려 평가됐습니다. - 생각을 오래 하게 하는 '추론 강도'는 전부 high로 맞추고, 웹 검색은 막았습니다. 검색으로 정답을 베끼는 게 아니라 '주어진 환경에서 추론하는가'를 재기 위해서입니다.
선두는 상용 최상위 모델 두 종이었습니다. 둘을 가른 건 코드 실력이 아니라 시각 그라운딩, 화면 속 사물이 무엇이고 어디 있는지 읽어내는 능력이었습니다. 우위는 조종하기와 알아맞히기에서 가장 크게 벌어졌습니다. 둘 다 여러 감각 신호를 읽고 반응해야 하는 일입니다.
반대로 훈련시키기 같은 전통적인 머신러닝 과제에서는 모델 간 격차가 눈에 띄게 좁았습니다. 코드 짜고 모델 훈련하는 기본기는 상위 모델끼리 비슷해졌다는 신호로 읽을 만합니다. 다만 이 데이터 하나로 "코딩·ML은 끝난 문제"라고 단정하긴 이릅니다. 어디까지나 이 시험 안에서의 관찰입니다.
같은 결이 자세 추정 과제에서도 보입니다. 대부분 모델이 색만 담은 영상(RGB)보다 깊이 정보까지 담은 영상(RGB-D)에서 점수가 올랐습니다. 하지만 진짜 차이는 '가림'을 다루는 방식에서 났습니다. 물체가 가려 안 보일 때, 잘하는 모델은 깊이로 3D 위치를 억지로 복원하려 들지 않고 "가려졌나, 아닌가"라는 단순한 판단에 그 정보를 썼습니다. 특히 한 최상위 에이전트는 깊이를 못 믿을 상황에 대비해 작은 신경망을 직접 훈련시켰고, 방법을 가리지 않는 과제에서 실제로 GPU를 꺼내 쓴 유일한 에이전트였습니다. 단순한 자세 추정조차 가림이 끼면, 최상위 모델만이 믿을 만한 지각 시스템을 세웠다는 뜻입니다.
개발 중 받는 평가 피드백은 분명 실력을 끌어올렸습니다. 정책 개발 과제에서 AI는 개발 도중 예비 점수를 받아볼 수 있는데, 36개 세션 중 29개에서 최종 제출본이 첫 점수보다 나아졌습니다.
문제는 그 개선이 딱 피드백이 보는 선에서 멈췄다는 점입니다. 평가 세트를 미리 돌려볼 수 있던 과제에서는 개발 중 성적이 공식 점수를 5점 안쪽으로 맞혔습니다. 그런데 시험 시점의 교란(흔들어 보는 돌발 변수)을 끝까지 숨긴 강건성 과제에서는 공식 점수가 개발 점수보다 LIBERO에서 19점, RoboTwin에서 41점이나 아래로 떨어졌습니다. 몇몇 AI는 숨은 교란을 짐작해 스스로 모의 시험을 만들기도 했지만, 이 간극을 메운 경우는 없었습니다.
여기서 눈에 띄는 역설이 하나 더 나옵니다. 보조 도구가 늘 도움이 되는 건 아니라는 점입니다. 한 과제의 하네스는 세 단계였습니다. L1은 기본 명령(API, 로봇에게 쓸 수 있게 미리 만들어둔 함수 묶음)만, L2는 물체를 보고 집을 자리를 계산하는 파지(집기) 계획 모듈까지, L3는 물체 위치 같은 정답 정보까지 줍니다. 대부분 모델은 지원이 많아질수록 점수가 오르고 비용이 줄었습니다. 그런데 가장 센 모델 하나는 L1만으로도 강했고, 지원을 더해도 오르지 않거나 되레 떨어졌습니다. 어느 선을 넘은 모델에겐 외부 모듈이 자기 판단과 충돌할 수 있다는 신호입니다. 다만 이건 가장 센 모델 하나에서 나온 패턴이라, 일반 법칙으로 받기엔 사례가 아직 얇습니다.
가장 뼈아픈 장면은 설계하기에서 나왔습니다.
여러 로봇 팔을 얹을 이동 베이스를 설계하는 과제는 구조적 타당성·효율·안정성·과제 완수로 채점됐습니다. 대부분 모델이 구조적 타당성은 통과했습니다. 기계적으로 그럴듯한 설계를 내놓긴 했다는 뜻입니다. 그런데 같은 설계가 물리 평가에서 자주 무너졌고, 아홉 모델 전부가 '최악 조건의 팔에 대한 정적 안정성 마진'에서 0점을 받았습니다. 정적 안정성 마진이란 로봇이 가만히 있을 때 쓰러지지 않고 버티는 여유를 말합니다.
이유는 다시 '숨김'에 있습니다. 지시문은 요구 속성을 다 알려줬지만, 채점관이 어떤 하중을 걸고 어떤 동작을 시켜 통과·탈락을 가르는지(검증 프로토콜)는 숨겼습니다. 그러자 AI들은 눈에 보이는 설계 목표는 채우면서, 하중 아래의 불안정이나 동작 중 충돌처럼 여러 힘이 얽혀 나오는 결과는 통째로 놓쳤습니다.
한마디로 AI는 나무(부품 하나하나가 그럴듯한지)는 잘 보지만, 숲(그 부품들이 하중·관성·접촉을 주고받을 때 전체가 어떻게 되는지)은 보지 못하는 셈입니다. 기계 설계에서 모델 간 격차가 작았던 것도, 잘해서가 아니라 다 같이 못해서였습니다.
저자들이 직접 인정한 한계가 셋입니다. 전부 시뮬레이션 안의 측정이라 실세계의 안전을 보장하지 않고, 네 갈래 워크플로우는 엔지니어 일의 일부만 담으며, 시험을 공개하면 나중에 훈련 데이터로 새어 들어가 평가의 타당성이 흔들릴 수 있습니다. 그래서 배포 전 독립 검증과 사람의 감독을 권합니다.
여기에 날 선 질문 둘을 더하고 싶습니다. 하나, 강건성 과제의 41점짜리 추락은 정말 '모델이 약해서'일까요, 아니면 현실의 엔지니어도 못 맞힐 억지 변수까지 숨긴 '불공정한 시험'은 아닐까요? 이 데이터만으론 둘을 가를 수 없습니다. 둘, 네 갈래를 똑같이 쳐서 평균 낸 점수 한 줄은, "제어는 덜 중요하고 지각이 전부"인 조직에선 순위를 뒤집어 버립니다. 종합 점수보다 갈래별 프로필을 봐야 하는 이유입니다.
이 논문을 렌즈 삼아 우리 일을 다시 보면, '숨은 물리 법칙'에 해당하는 기술 부채가 소프트웨어에도 그대로 있습니다. 한 장면을 끝까지 따라가 보겠습니다.
고객이 "주문 데이터 연동 대시보드를 붙여달라"고 합니다. AI PM이 명세를 읽고 만듭니다. 화면이 뜨고, 숫자가 채워지고, "응답 200, DB 행 수 일치"는 가뿐히 통과합니다. 이동 베이스 과제에서 대부분 모델이 구조적 타당성은 통과한 바로 그 그림입니다. 겉보기엔 완료입니다.
문제는 숨은 쪽에 있습니다. 피크 시간대 동시 접속에서 쿼리가 무너지는지, 연동 토큰이 만료되면 조용히 빈 값으로 떨어지는지, 환율·시차 때문에 합계가 어긋나는지. 전부 뒤늦게, 간접적으로 드러나는 결과입니다. 논문대로, 지시문에 요구가 다 적혀 있어도 채점 방식이 숨겨져 있으면 AI는 이런 얽힌 결과를 놓칩니다.
그래서 우리가 바꾼 건 완료의 정의입니다. 완료는 '개발을 맡은 AI PM이 자기 테스트를 통과한 상태'가 아니라, 운영에 가까운 조건으로 돌리는 별도 검증을 통과한 상태로 둡니다. 개발자가 자기 시험만 믿고 완료를 보고하면, 강건성 과제에서 봤던 그 간극을 운영에서 그대로 밟기 때문입니다. 대신 피드백은 재는 범위 안에선 확실히 실력을 키우니, 그 별도 검증에 실제 실패 모드(동시성·토큰 만료·단위 불일치)를 집어넣습니다. 숨겨둔 시험을 통과해야 비로소 완료입니다.
모델은 생각을 오래 할수록 성적이 달라집니다. 조합마다 이 조건이 제각각이면, 하네스나 모델 자체의 능력이 아니라 '얼마나 오래 생각하게 뒀나'를 비교하게 됩니다. 그래서 연구진은 추론 강도를 전부 'high'로 맞췄습니다. 다만 이 'high'가 최대치는 아닙니다 — 일부 평가 대상 모델은 그보다 높은 강도도 지원합니다. 또 설정값의 이름을 통일했다고 해서 모델마다 실제로 들인 추론량이나 하네스가 미치는 영향까지 똑같이 통제됐다고 보기는 어렵습니다.
코딩 시험은 화면 안에서 끝나고 틀리면 되돌릴 수 있습니다. 로봇은 다릅니다. 결과가 물리로 나타나고, 되돌릴 수 없으며, 하중·관성·접촉 같은 힘이 서로 얽힙니다. 부품 하나하나를 그럴듯하게 짜는 능력과, 그것들이 얽혔을 때의 결과를 내다보는 능력은 전혀 다른 근육입니다.
장담할 수 없습니다. 모든 측정이 시뮬레이션 안에서 이뤄졌고, 저자들도 실세계 성능과 안전은 별개라며 배포 전 독립 검증과 사람의 감독을 못 박았습니다. 게다가 종합 1등이 내 조직에 중요한 축에서도 1등이라는 보장이 없으니, 점수 한 줄이 아니라 갈래별 프로필을 보고 판단해야 합니다.