BT-Agent는 행동트리로 온보드 로봇 에이전트의 실행을 통제한다

무엇인가

모바일 로봇은 이제 "약통을 찾아 사진 찍어라" 같은 상위 수준 목표를 받아 여러 개의 물리적 행동을 순서대로 수행해야 한다. 이런 추론을 원격 컴퓨트에 의존하지 않고 온보드에서 돌리려면 인식·제어와 한정된 메모리·연산을 나눠 써야 한다. 기존 언어모델 로봇 에이전트 연구는 주로 "다음에 무엇을 할지"에 집중했고, 선택된 스킬이 실행 상태를 어떻게 노출하고 어떤 조건을 강제하며 어떻게 중단을 지원하는지에 대한 공통 인터페이스는 없었다. 저자들은 행동트리(BT)가 그 인터페이스의 모듈식 로보틱스 네이티브 기반이 될 수 있다고 본다.

어떻게 동작하나

BT-Agent는 과제 수준 선택과 실행을 분리한다. LLM Actor가 과제·상태·이전 관측을 보고 스킬과 인자를 고르면, 슈퍼바이저 BT가 한 번에 하나의 스킬을 실행하고 상태와 결과를 돌려준 뒤 다음 Actor 호출로 넘어가는 ReAct 루프를 만든다. Actor의 완료 주장은 슈퍼바이저가 종료 제출로 변환한다. 컨텍스트를 줄이려고 이력을 요약하고, 스킬 결과는 타입이 지정된 객체 저장소에 남겨 재사용한다. 각 로봇 스킬은 미리 정의된 행동트리로 구현되어 이름 있는 도구로 노출되며, 개발자는 모델 선택과 무관하게 그 고정된 실행 로직을 검토할 수 있다. 물리 스킬을 시작하기 전에는 사전조건을 검사한다. 내비게이션은 알려진 목표 위치가 있어야 하고, 프레임워크가 인자를 검증하고 객체 참조를 해석하며 필요한 사전 관측을 확인한다. 실행 중에는 가드가 매 틱마다 취소, 경과 시간, 스킬별 조건을 다시 검사하고, 가드가 실패하면 분기를 중단하고 컨트롤러에 정지를 요청한다. 이 검사는 추가 Actor 호출 없이 돌아가고, Actor는 스킬 인자로 이 검사를 끌 수 없다. 실패한 가드나 리프는 가능한 경우 진단 피드백을 제공하며, 이 역시 별도 모델 호출 없이 이루어진다.

무엇과 다른가

평가를 위해 저자들은 Habitat와 Isaac 장면에서 파생된 161개 텍스트 과제를 만들고, 과제 목표와 스킬 인터페이스를 시뮬레이터 실행과 공유시켰다. 장면 구성은 같은 집의 실내 Habitat 구성 두 개, 실외 Isaac 장면, 추가 HSSD 주택 하나로 네 가지다. 독립 평가팀이 앞의 세 구성에 32개 과제(실내 21, 실외 11)를 제공했고, 참조 모호성·목표 개수·상호작용 의존성·불가능성을 변화시킨 실내 과제 18개를 더해 50개 1차 스위트(Habitat 파생 39, Isaac 파생 11)를 구성했다. 추가 주택에는 모델 가중치를 바꾸지 않고 111개 전이 과제를 저자가 작성했으며, 37개 과제군 각각에 직접 이름·바꿔 말하기·용도 기반 지시 세 가지 변형을 둔다. 텍스트 실행은 장면 기억 레코드로 로봇 위치·가시성·상호작용 상태를 갱신하고, Habitat에서는 VLM 인식과 CMU의 깊이 기반 로컬 플래닝 스택이 내비게이션을 수행한다. 텍스트 백엔드는 내비게이션 타임아웃이나 관측 실패 같은 반복 가능한 결함을 적격 스킬 호출에 주입하는데, 어떤 결함은 실패를 명시적으로 보고하고 어떤 결함은 실행이 불완전한데도 성공을 보고해 에이전트가 반환된 상태 이상을 확인하는지 시험한다. 비교 대상은 Act, ReAct, 그리고 각색한 CaP-X이며, 모델은 Qwen3.5 NVFP4 4B·9B·27B·122B-A10B, 과제당 짝지은 시드 3개를 쓴다.

어떻게 쓰나

결과에서 BT-Agent는 통합 스위트의 모든 크기에서 가장 강한 Act/ReAct 베이스라인과 같거나 앞섰고, 4B와 9B에서 각각 10.1%p, 5.0%p로 격차가 가장 컸다. 전이 과제 이득은 모든 크기에서 양수였고 9B에서 ReAct 대비 4.8%p로 가장 컸으며, 4B의 큰 이득은 주로 1차 스위트에서 나왔다. 절제 실험에서 구조화된 도구 호출을 텍스트 명령으로 바꾸면 모든 크기에서 성공률이 떨어졌고 4B·9B에서 가장 심했으며, 중앙값 출력 토큰은 각각 1.9배, 1.7배로 늘었다. 실패 피드백을 스킬 이름과 상태만으로 줄이면 크기 전반에서 명목 성공률이 2~6%p 하락했고, 캡처 관련 안내를 제거한 효과는 거의 없었다. 비용 측면에서 Act가 중앙값 출력이 가장 낮았고, 4B에서 BT-Agent는 161개 과제 전체에서 ReAct의 P99 출력을 42% 줄였다. 다만 27B에서는 ReAct가 더 낮은 중앙값·P99 출력으로 BT-Agent의 명목 성공률에 맞섰다. 결함 주입 조건에서는 BT-Agent가 모든 크기에서 관측 성공률이 가장 높았고, 27B에서 명목 동률이던 관계가 결함 조건에서 BT-Agent 우위로 바뀌었다. 선택적 응답 워치독(반복된 무용 출력, 동등 질의·실패 스킬 결과 반복, 16,384 출력 토큰 또는 128 모델 호출 도달 시 종료)은 모든 크기에서 P99를 낮추면서 성공률 영향은 작았다.

전제와 한계

텍스트와 시뮬레이터의 정합성도 측정했다. 같은 집의 두 구성에서 39개 1차 과제를 9B 모델의 네 가지 에이전트 구성으로 과제당 짝지은 시드 3개로 비교했을 때 방법 간 순위는 두 백엔드에서 일치했고, 39개 과제 평균 사이의 스피어만 상관계수는 0.61이었다. Habitat 성공 188회 중 168회가 텍스트에서도 성공했지만, 텍스트 성공 중 Habitat에서 성공한 비율은 57.3%에 그쳤다. 즉 기호적 성공이 센싱과 모션을 포함한 완료를 보장하지 않는다. 평가 비용은 모델 추론 없는 오라클 기준 텍스트가 에피소드당 평균 0.245초, 정답 인식을 쓴 Habitat이 57.7초였다. 공유 9B 모델을 RTX PRO 6000에 올리고 워커 8개를 돌리면 텍스트는 시간당 950 에피소드, Habitat은 RTX 5090 한 대에서 87.3 에피소드로 10.9배 차이가 났다.

조작 과제 전이 실험은 Robosuite에서 CaP-X의 참조 과제 6개와 정렬·쌓기·재배치 확장 8개를 4B·9B·27B에서 과제당 20회 반복해 비교했다. BT-Agent는 확장 과제에서의 우위 덕분에 세 크기 모두 통합 성공률 1위였지만, 참조 스위트에서는 공유 스킬 CaP-X가 9B와 27B에서 앞섰다. 27B raw-API 단일 턴 정책은 44.2%로, 원 논문이 열두 모델에서 보고한 31.2~65.7% 범위(20B 51%, 사람 작성 프로그램 94%) 안에 들어왔다. 정규 격자 경로를 도는 닦기 과제에서는 27B 공유 스킬 다중 턴 CaP-X가 20회 중 14회 성공한 반면 BT-Agent는 시간 예산 안에 한 번도 끝내지 못했고, 관측된 스택 순서에 반응해야 하는 큐브 3개 재쌓기에서는 BT-Agent가 20회 중 15회, 공유 스킬 CaP-X가 4회 성공했다. 실제 로봇에서는 Boston Dynamics Spot에 NVIDIA Jetson Thor를 달고 9B 모델 Actor와 시각 스킬을 올려, FARM 장면 그래프와 온보드 Qwen3-Embedding-0.6B 검색, CMU 지형 분석·로컬 플래닝·경로 추종 모듈로 다섯 과제를 세 번씩 수행해 15회 중 11회를 완료했다. 보고 과제에서는 디스플레이를 찾아 촬영했지만 작은 시계 문자판을 잘못 읽어 틀린 시각을 보고했다.

반응적 실행은 별도로 검증했다. 각 가드와 개입 조건을 세 번씩 시험했는데, 서베이 없이 누르기를 거부하는 가드가 걸리자 Actor가 주변을 서베이하고 재시도했고, 배터리 잔량 9%를 시뮬레이션하자 내비게이션이 거부되고 Actor가 제약을 보고한 뒤 과제를 포기했다. 운영자 개입과 주입된 타임아웃은 내비게이션을 멈추되 에이전트는 살려 두었고, Actor는 타임아웃을 평범한 스킬 실패로 받아 재시도해 모든 타임아웃 시행이 완료됐다. 내비게이션 중 배터리 5% 시뮬레이션은 지속적 모션 홀드와 내장 앉기 명령을 유발했고 Actor는 재시도 없이 제약을 보고했다. 모션 중 9회 개입에서 명령 속도는 로컬 수용 후 중앙값 19ms 만에 0이 된 반면, 다음 모델 선택 행동은 개입·타임아웃 시행에서 3.2~3.9초 뒤에 나왔다.

실무 관점에서 이 논문이 주는 시사점은 명확하다. 온보드 로봇에 LLM을 붙일 때 모델 추론 지연과 안전 정지를 같은 계층에 두면 위험하므로, 스킬 실행 계층을 행동트리로 고정하고 매 틱 조건을 재검사하는 가드를 두며 실패를 구조화된 피드백으로 되돌리는 설계가 유효하다는 것이다. 특히 4B·9B 같은 소형 모델일수록 구조화된 도구 호출 인터페이스와 정보성 있는 실패 피드백의 효과가 크고, 명목 성공률만 보면 드러나지 않는 실패 처리 능력 차이는 결함 주입 평가로 확인해야 한다. 또한 텍스트 백엔드로 오케스트레이션을 싸게 반복 개발하고 시뮬레이터 짝지은 시행으로 인식·모션 실패를 걸러내는 다중 충실도 파이프라인은 그대로 차용할 만하다. 다만 정규 반복 작업에는 프로그램 생성이, 관측이 다음 행동을 결정하는 작업에는 단계별 스킬 선택이 낫다는 트레이드오프도 함께 봐야 한다.

저자들이 밝힌 한계도 분명하다. Actor는 사용 가능한 스킬을 순서화하고 인자를 채울 수 있을 뿐, 스킬 구현과 가드는 런타임에 고정되어 있다. 이는 배포 전 검토와 테스트를 가능하게 하지만 새 능력을 추가하려면 스킬을 새로 작성하고 플랫폼별 통합을 해야 한다. 관측이 불완전하거나 모호할 때 과제에 필요한 증거를 안정적으로 전달하는 문제도 미해결로 남는다. 향후 과제로는 진행 중인 스킬에 대한 BT 감독과 나란히 과제 수준 추론을 돌리는 것, 엣지 모델이 트리 구조와 실패한 리프를 명시적으로 추론해 복구 행동을 고르는 것, 같은 아키텍처에서 프런티어 모델을 평가해 모델 한계와 스킬 인터페이스 한계를 구분하는 것, 실행 가능한 텍스트 환경으로 과제 수준 정책을 강화학습한 뒤 시뮬레이션과 로봇에서 평가하는 것을 제시한다. 저자들은 BT-Agent 구현과 벤치마크 코드를 Apache-2.0 라이선스로 공개하겠다고 밝혔지만, 본문에 저장소 URL은 제시되지 않았다.