베이징대·싱가포르국립대·NVIDIA 등 연구진이 로봇을 움직이는 AI 에이전트의 인터페이스를 바꿔 성공률과 비용을 동시에 개선했다. 모델에게 동작을 하나씩 고르게 하는 대신 짧은 파이썬 코드를 쓰게 했더니, 같은 모델(GPT-6 Astra)과 같은 로봇 동작을 쓰고도 성공률은 63.1%에서 71.7%로 오르고, 두 방식이 모두 푼 작업 기준으로 입력 토큰은 65% 적게 들었다. 핵심은 "더 똑똑한 모델"이 아니라 "모델에게 일을 시키는 창구"를 바꾼 데 있다.
로봇을 움직이는 요즘 방식 하나는 시각 언어 모델(VLM, 이미지와 글을 함께 이해하는 모델)에게 카메라 화면과 로봇 상태를 보여주고 "집어라" "옮겨라" 같은 동작 명령(primitive)을 고르게 하는 것이다. 문제는 비용이다. 도구 호출(tool-calling) 방식에서는 앞 동작의 결과에 따라 다음이 갈리는 작업일수록 모델을 반복해서 불러야 한다. 집으려고 접근한 뒤 "잘 잡혔나"를 확인하고, 안 잡혔으면 다시 시도하는 이 짧은 판단 하나하나가 전부 모델 호출 한 번이 된다.
여기에 관찰 데이터까지 쌓인다. 저자들이 비교 기준으로 삼은 RPent 시스템에서는 동작 하나가 끝날 때마다 카메라 이미지 여러 장과 상태 값이 자동으로 모델 대화에 딸려 들어온다. 매 턴 이미지가 붙으니 맥락은 금세 불어나고, 그 불어난 맥락은 다음 호출에서 또 토큰으로 계산된다.
비유하자면 요리사가 양파 한 번 썰 때마다 주방장에게 전화해 "썰었습니다, 다음은요"를 묻고, 그때마다 조리대 사진을 통째로 첨부해 보내는 꼴이다. 판단이 필요 없는 자잘한 단계까지 전부 상부 보고로 처리하니 전화비(토큰)가 폭증한다.
PyRUA-Lean(Python for Lean Robot-Use Agents)의 발상은 단순하다. 모델에게 동작을 하나씩 고르게 하지 말고, 짧은 파이썬 코드 조각(cell)을 쓰게 하자는 것이다.
로봇은 robo라는 파이썬 객체로 노출되고, 모델은 python(code) 도구로 코드를 던진다. 이 코드 안에서 여러 동작을 이어 붙이고(compose), if로 중간 결과를 점검하고, 실패하면 그 자리에서 다시 시도한다. 이 모든 조건 분기와 재시도가 코드 한 셀 안에서 끝나므로 모델을 다시 부르지 않는다. 셀이 끝날 때, 모델이 다음 계획을 세우는 데 필요한 것만 돌려준다.
두 번째 축이 선택적 관찰(selective observation)이다. 코드가 실행되는 동안 생긴 중간 결과는 런타임 안에 남아 있을 뿐, 자동으로 대화에 끼어들지 않는다. 모델이 장면을 보고 싶으면 robo.show를 명시적으로 호출해야만 그 이미지가 맥락에 들어온다. 변수와 헬퍼 함수는 한 에피소드 안에서 셀을 넘어 계속 살아 있어서(persistent namespace), 중간 데이터를 대화에 쌓지 않고도 다음 셀에서 다시 쓸 수 있다.
논문이 든 장면(Figure 2c)이 이 구조를 잘 보여준다. 그릇을 내려놓는 작업에서, 도구 호출 방식이라면 14~17번 네 번의 모델 턴이 필요한 구간을 PyRUA-Lean은 셀 하나로 처리한다. 그 셀은 장면의 좌표 정보로 그릇을 놓을 높이를 직접 계산하고(어떤 동작 명령도 그 값을 바로 주지 않는다), 조건에 맞으면 내려놓고 손을 펴며, 작업이 아직 안 끝났을 때만 이미지를 요청한다. 성공했을 때 돌아온 것은 다섯 줄의 텍스트뿐, 이미지는 없다. 네 번의 왕복이 한 번으로 줄었다.
영리한 지점은 이게 완전히 새로운 로봇 능력을 만든 게 아니라는 데 있다. PyRUA-Lean은 RPent의 로봇 스택과 동작 구현을 그대로 쓰고, 계획을 세우는 모델도 똑같이 GPT-6 Astra다. 바뀐 건 오직 그 능력을 모델에게 내주는 인터페이스뿐이다. 그래서 이 연구는 "더 센 모델"이 아니라 "같은 모델에게 더 나은 대화 창구"를 준 실험으로 읽힌다.
평가는 시뮬레이션 700개 작업 인스턴스에서 이뤄졌다. LIBERO-PRO의 교란(perturbed) 4개 스위트에서 40개 작업, RoboTwin 2.0의 양팔 작업 50개, RoboCasa365의 Target50에서 50개 작업을 각각 5개 환경 시드로 돌려 700쌍, 두 에이전트를 합쳐 1,400개 에피소드를 얻었다.
핵심 수치는 두 가지다. 같은 LLM 호출 예산 아래에서 전체 성공률이 63.1%에서 71.7%로 올랐다(절대 8.6%p, 상대적으로 약 14% — 제목의 "14%"가 이 상대값이다). 그리고 두 에이전트가 모두 풀어낸 인스턴스만 놓고 보면 PyRUA-Lean이 LLM 호출을 49%, 입력 토큰을 65% 적게 썼다. 성공률은 올리고 비용은 내린 셈인데, 보통 이 둘은 맞바꾸는 관계라는 점에서 눈에 띈다.
저자들이 추적한 바로, 토큰 절감의 주된 출처는 모델 호출 횟수 자체가 줄어든 것이다. 호출이 줄면 매번 딸려가던 맥락과 이미지도 따라 줄기 때문이다. 풀어낸 에피소드당 비용(달러)도 모든 벤치마크에서 더 낮았다고 보고한다. 흥미로운 건 이 효율이 VLA 정책(학습된 시각-언어-행동 모델)이나 작업 안내문(operating guide)이 없는 조건에서도 유지됐다는 점이다(RoboCasa365에는 안내문이 아예 없다). 절감 효과가 특정 보조 장치 덕이 아니라 인터페이스 자체에서 나온다는 뜻이다.
솔직하게 짚을 것들이 있다. 첫째, 전부 시뮬레이션이다. 700개가 가상 환경의 작업 인스턴스이고, 실제 로봇 팔에서 같은 격차가 날지는 이 결과만으로 단정할 수 없다.
둘째, 효율 이득이 어디서나 같은 크기는 아니다. 저자들 스스로 VLA가 작업을 주도하는(VLA-dominated) 과제에서는 절감 폭이 줄어든다고 밝힌다. 동작 대부분을 학습된 정책이 한 번에 처리해 버리면, 코드로 묶어 아낄 왕복 자체가 적어지기 때문으로 읽힌다.
셋째, 이 인터페이스는 모델이 코드를 제대로 쓸 수 있다는 전제에 기댄다. 좌표를 계산하고 조건 분기를 짜는 부담이 모델 쪽으로 옮겨가는데, 코드가 틀리면 예외가 나고 그 자리에서 다시 짜야 한다. 논문은 예외가 나도 직전까지 할당된 변수는 네임스페이스에 남아 복구할 수 있게 설계했지만, 이는 성패가 모델의 코딩 역량에 얹힌다는 뜻이기도 하다.
넷째, 비교는 에피소드 간 기억(cross-episode memory)을 양쪽 다 끈 상태에서 이뤄졌다. 공정한 인터페이스 비교를 위한 선택이지만, 반대로 "경험을 쌓아 재사용하면 어느 쪽이 더 유리한가"는 이 실험의 범위 밖이다. (공개된 발췌는 실패 사례의 구체 수치까지는 담고 있지 않아, 그 부분은 원문 4.5절을 확인해야 한다.)
온틀의 AI PM이 고객 요청 하나를 처리하는 장면을 떠올려 보자. "연동해 둔 재고 시스템에서 품절 임박 품목만 뽑아 요약해 줘." 작아 보여도 의존 단계가 줄줄이 엮여 있다. 연동이 살아 있는지 확인하고, 데이터를 당겨오고, 비었으면 한 번 더 시도하고, 기준선 밑으로 떨어진 품목만 거르고, 그걸 사람이 읽을 요약으로 바꾼다.
도구 호출식으로 짜면 이 단계마다 모델을 다시 부르게 되기 쉽다. "연동 확인했습니다, 다음은요" "데이터 왔습니다, 다음은요." 그리고 그 사이사이 응답 원문(수백 행짜리 재고 테이블 같은)이 대화에 그대로 쌓여, 다음 호출의 토큰과 비용을 밀어 올린다. 요청 하나가 멀쩡히 처리돼도 맥락은 지저분해지고 비싸진다.
이 논문이 가리키는 방향은 분명하다. "연동 확인 → 조회 → 재시도 → 필터"처럼 결정이 뻔한 구간은 모델에게 한 단계씩 묻지 말고, 서버에서 결정론적으로 실행되는 코드 한 덩어리로 묶어라. 그리고 그 덩어리가 끝나면 수백 행 원본이 아니라 "품절 임박 7건, 목록은 이것" 같은, PM이 다음 판단에 바로 쓸 결과만 맥락에 올려라. 온틀이 박서아 PM을 다시 설계하면서 "말과 행동이 어긋나는 넓은 재량"을 걷어내고 공통 액션 서비스 위에서 서버가 결정론적으로 실행하도록 돌린 선택이, 바로 이 논문이 로봇에서 수치로 보여준 그 방향이다. 모델은 무엇을 할지 판단하는 데만 쓰고, 어떻게 실행할지는 코드로 내린다. 그러면 성공률을 지키면서 호출과 토큰을 함께 깎을 여지가 생긴다.
다만 교훈 하나가 붙는다. 효율이 인터페이스에서 나온다는 말은, 토큰을 아끼려고 더 센 모델을 사는 게 1순위가 아니라는 뜻이다. PM이 고객 요청을 어떤 창구로 처리하도록 설계했는지가 먼저다.
아닙니다. 로봇 동작 구현과 계획 모델(GPT-6 Astra)은 비교 대상인 RPent와 동일하게 두고, 그 능력을 모델에게 노출하는 인터페이스만 도구 호출에서 파이썬 코드 실행으로 바꾼 것입니다. 같은 재료로 창구만 바꿨을 때 성공률과 비용이 어떻게 달라지는지를 재는 실험에 가깝습니다.
저자들의 추적으로는 모델 호출 횟수가 줄어든 것이 토큰 절감의 주된 출처입니다. 조건 점검과 재시도를 코드 안에서 끝내 모델을 덜 부르고, 호출이 줄면 매 호출에 딸려가던 이미지와 중간 결과도 함께 줄기 때문입니다. 두 에이전트가 모두 푼 인스턴스 기준으로 호출 49%, 입력 토큰 65% 감소였습니다.
아닙니다. 학습된 VLA 정책이 작업을 주도하는 과제에서는 절감 폭이 줄어든다고 논문이 밝힙니다. 코드로 묶어 아낄 왕복이 애초에 적은 상황이기 때문입니다. 반대로 위치 확인·이동·복구를 반복해야 하는 작업일수록 이득이 큽니다.
논문 자체가 CodeAct 등 일반 에이전트 연구의 "코드로 도구를 조합하면 맥락이 효율적"이라는 흐름을 로봇으로 가져온 것입니다. 관찰이 이미지라 실패가 잦은 로봇에서도 같은 원리가 성립했다는 점이, 여러 API를 엮어 일하는 업무 에이전트 설계에도 그대로 참고가 됩니다.