싱가포르국립대 연구진이 내놓은 APPL(Agent Priors-guided Policy Learning)은 로봇 스킬을 훈련시킬 때 쓴 "설계 가정"을 버리지 않고, 나중에 스킬을 조합하는 단계에서 다시 쓴다. 각 스킬이 무엇을 하는지(이름)만 조합기에 넘기던 기존 방식과 달리, 그 스킬이 어디서 통하는지까지 언어로 적어 넘긴다. 이 한 가지 재사용으로 적은 시연만 가지고도 처음 보는 상황·처음 보는 조합을 더 잘 풀어냈다는 게 핵심이다.
집이나 창고에서 일하는 로봇은 배운 것보다 훨씬 많은 일을 요구받는다. 시연(demonstration)을 모으는 건 비싸서, 보통 몇 개 과제의 몇 번 시연만 보고 배운다. 그런데 현장에서는 새로운 목표, 익숙한 동작의 새로운 순서, 그리고 전과 다른 위치에 놓인 물건이 쏟아진다.
여기서 두 종류의 일반화가 동시에 필요하다. 하나는 조합 일반화(compositional generalization), 배운 스킬들을 다시 엮어 새 과제를 푸는 능력이다. 다른 하나는 스킬 일반화(skill generalization), 물건이 움직이거나 앞선 스킬이 남긴 낯선 상태에서 시작해도 각 스킬이 여전히 작동하는 능력이다.
문제는 이 둘이 서로 맞물려 있는데 정작 둘 사이에서 정보가 샌다는 점이다. 과제 수준(task level)의 판단은 "어떤 스킬을 어떤 순서로"를 고민하지만, 그 스킬이 실제로 물리적으로 어디까지 되는지는 모른다. 반대로 스킬은 몇 번의 시연에서 배웠을 뿐, 상위 판단이 기대는 구조를 알지 못한다. 저자들의 표현을 빌리면, 조합기는 스킬을 이름·지시문·기호 연산자 같은 "별도의 설명"을 통해서만 본다. 그 설명에는 스킬이 어떤 구조로 학습됐는지가 빠져 있다.
기존 접근들도 이 간극을 메우려 했다. 비전-언어-행동 모델(VLA)은 과제 의미와 저수준 제어를 한 모델에 합치지만, 어떤 조건에서 일반화되는지가 암묵적으로 남고 배치·물체 위치 변화에 약하다는 지적을 논문은 인용한다. 과제·동작 계획(TAMP) 계열은 기호적 전제조건·효과로 두 수준을 잇지만 그 구조를 손으로 정하거나 데이터로 배워야 한다. 에이전트 계열은 정책을 도구처럼 호출하며 언어를 인터페이스로 쓰는데, 이름이나 지시문은 "무엇을 위한 도구인가"는 알려줘도 "어떤 물리 조건에서 되는가"는 못 알려준다. 그래서 스킬과 스킬 사이 전환(handoff)이 흔한 실패 지점으로 남는다.
APPL의 발상은 단순하다. 스킬을 학습시킬 때 쓴 구조적 사전가정(structural prior)을 조합 단계의 인터페이스로 그대로 재활용하자는 것이다.
구조적 사전가정이란 "이 행동이 무엇에 의존하는가"를 명시한 것이다. 논문이 든 예시는 집기(grasp)다. 집기는 세계 좌표상의 절대 위치가 아니라 "물체에 대한 그리퍼의 상대 자세"에만 의존한다고 가정할 수 있다. 이 가정을 두 곳에서 쓴다. 첫째, 학습에 집어넣으면 정책이 어디로 일반화될지를 빚는다. 물체 상대 좌표로 배운 집기는 물체가 새로운 절대 위치에 나타나도 통한다. 둘째, 같은 가정을 언어로 적어 상위 에이전트에게 주면, 그 정책이 어디에 적용되는지를 알려준다.
요리에 비유하면, 레시피 카드에 "완성 요리 사진"만 붙여두는 대신 "이 조리법은 상온 재료를 전제로 함, 냉동이면 안 됨" 같은 적용 조건을 함께 적어두는 것과 비슷하다. 주방장(조합기)은 요리 이름만 보고 고르지 않고, 지금 재료 상태에서 이 레시피가 통할지를 판단할 수 있게 된다.
구체적으로 APPL은 두 에이전트로 돌아간다.
이 설계가 영리한 지점은 "정책 구조를 어떻게 잡을까"를 고정된 설계 결정이 아니라 스킬별 가설로 바꿨다는 데 있다. 가설은 제안되고, 구현되고, 검증되고, 런타임에 재사용된다. 학습을 빚은 정보가 나중에 그 정책을 고르고 엮을 때도 살아남는 셈이다.
논문은 좋은 인터페이스의 조건도 형식화한다. 정책이 실제로 성공하는 영역을 성공 영역(R), 인터페이스가 "여기서 된다"고 주장하는 영역을 적용 영역(A)이라 할 때, A가 R보다 넓으면 안 되는 곳에서 정책을 호출해 실패하고, A가 R보다 지나치게 좁으면 쓸 수 있는 호출을 포기하게 된다. 그래서 인터페이스는 충실하면서(A가 R 안에 있음) 동시에 정보가 많아야(A가 R을 넓게 덮음) 한다.
실험은 사전가정의 두 역할을 각각 겨눈다. 주의할 점은 아래 수치들이 서로 다른 두 실험에서 나온 값이라는 것이다.
첫 번째 실험은 스킬 일반화를 본다. MetaWorld 과제 6종에서, 에이전트가 설계한 사전가정은 적은 시연 조건의 분포 밖(OOD) 일반화를 바닐라 Diffusion Policy와 고정된 관계형 사전가정(fixed relational prior) 대비 크게 끌어올렸다. 논문이 밝힌 수치로는 시연 2개 조건에서 OOD 성공률이 89.6%로, 같은 조건의 고정 관계형 사전가정 37.9%와 대비된다.
두 번째 실험은 장기 과제의 조합을 본다. 시연 12개씩 주어진 ManiSkill 장기 과제 5종에서, APPL은 물체 배치가 바뀐 조건에서 50.0% 성공했고, 같은 조건에서 과제 전체를 하나로 학습한 full-task Diffusion Policy는 10.0%에 그쳤다. 중간 지점에서 시작하거나 조기 종료를 요청하는 과제 수준 변형에서는 92.5%를 기록했고, 처음 보는 스킬 조합 16개 중 8개를 풀었다.
가장 중요한 결과는 따로 있다. 학습된 정책 라이브러리는 그대로 두고 구축 시점의 인터페이스 정보만 런타임 에이전트에게서 가렸더니 성공률이 유의미하게 떨어졌다. 이것이 논문의 중심 가설을 뒷받침한다. 스킬을 일반화시키려고 쓴 구조적 가정이, 그 스킬을 언제·어떻게 쓸지 결정하는 데에도 유용한 정보라는 것이다. 즉 성능을 올린 건 정책 자체뿐 아니라 "그 정책이 어디서 통하는지"를 전달한 인터페이스였다.
저자들도 결론에서 한계를 인정한다. 몇 가지는 글의 사실 범위 안에서 짚어볼 만하다.
조합 일반화 결과는 아직 절대 수치가 높다고 보기 어렵다. 처음 보는 조합 16개 중 8개를 풀었다는 건 절반이다. 물체 배치가 바뀐 조건의 50.0%도 베이스라인(10.0%)보다 다섯 배지만 그 자체로는 절반의 성공이다. 어려운 설정이라는 방증이자, 갈 길이 남았다는 신호이기도 하다.
실험 무대가 MetaWorld와 ManiSkill이라는 점도 염두에 둘 대목이다. 두 벤치마크 모두 시뮬레이션 조작 과제이며, 실제 로봇·실제 가정 환경에서 같은 폭의 이득이 재현될지는 이 논문의 사실 범위를 넘어선다.
그리고 사전가정을 "여러 개 제안하고 가정마다 정책을 하나씩 학습·검증"하는 구조는, 스킬 하나에 여러 정책을 만들고 저장하는 비용을 수반한다. 라이브러리가 커질수록 런타임 에이전트가 올바른 후보를 고르는 선택 문제도 함께 커진다. 인터페이스가 충실성과 정보량을 동시에 지켜야 한다는 요구는 개념적으로 깔끔하지만, 에이전트가 만든 적용 영역 설명이 실제 성공 영역과 얼마나 어긋나는지는 과제마다 다를 것이다.
이 연구를 AI PM의 한 장면에 포개보면 시사점이 또렷해진다. 도구(스킬) 위임의 순간이다.
온틀의 AI PM은 고객 요청을 받으면 그 일을 여러 실행 도구와 하위 에이전트에 나눠 맡긴다. 지금 대부분의 에이전트 시스템이 그렇듯, PM이 도구를 아는 방식은 "이름과 설명"이다. 예컨대 "엑셀 표 미리보기 도구", "서브도메인 발행 도구" 같은 식이다. APPL이 로봇에서 지적한 문제가 여기서 그대로 반복된다. PM은 그 도구가 무엇을 하는지는 알아도, 그 도구가 어떤 조건에서 신뢰할 수 있게 작동하는지는 모른다. 표 미리보기 도구가 상위 200행·30열까지만 본다거나, 특정 연동이 프로젝트 전용 DB가 먼저 생성돼 있어야 한다거나 하는 "적용 영역"이 도구 이름에는 담기지 않는다.
APPL의 처방을 옮기면 이렇다. 각 실행 도구를 등록할 때 이름만이 아니라 "이 도구는 무엇에 의존하는가 / 어떤 입력 상태를 전제하는가 / 앞 단계가 어떤 상태를 남겨야 이어받을 수 있는가(전환 조건) / 과거 어떤 범위에서 성공이 검증됐는가"를 기계가 읽을 수 있는 인터페이스로 함께 적어두는 것이다. 그러면 PM이 작업을 분해해 위임할 때, 도구를 "되는 곳"에서만 호출하고 "안 되는 곳"에서는 다른 구현을 고르거나 선행 작업을 먼저 끼워 넣는 판단을 할 수 있다. 특히 단계와 단계 사이, 한 도구의 출력이 다음 도구의 입력 전제를 어기는 전환 지점이 온틀 같은 파이프라인에서도 흔한 실패 자리인데, 전환 조건을 인터페이스에 명시하는 발상이 바로 그 자리를 겨눈다.
여기엔 함정도 같이 보인다. APPL에서 인터페이스 정보를 가렸더니 성능이 떨어졌다는 결과는, 반대로 인터페이스가 부실하면 아무리 좋은 도구를 갖춰도 조합이 무너진다는 뜻이다. 도구 카탈로그를 "이름 + 한 줄 설명"으로만 관리하는 흔한 관행이 왜 위험한지를 실험으로 보여준 셈이다. 온틀 입장에서 당장 할 일은 로봇 정책을 흉내 내는 게 아니라, 도구·연동·하위 에이전트의 "적용 조건과 전환 조건"을 설명 메타데이터로 승격시키는 것이다. 그게 이 논문이 로봇 팔에서 보여준 이득을, 소프트웨어 에이전트의 위임 판단으로 옮기는 가장 곧은 길이다.
그 행동이 무엇에 의존하는지를 명시한 가정입니다. 논문 예시로는 "집기는 물체에 대한 그리퍼의 상대 자세에만 의존한다" 같은 진술입니다. 이걸 학습에 넣으면 정책이 어디로 일반화될지를 결정하고, 언어로 적어 두면 상위 에이전트에게 그 정책이 어디에 적용되는지를 알려줍니다.
구축 에이전트가 스킬마다 하나의 추상화에 못박지 않고 여러 사전가정을 제안하고, 가정마다 Diffusion Policy를 하나씩 학습시키기 때문입니다. 서로 다른 귀납 편향을 가진 구현들이 라이브러리에 공존하므로, 런타임 에이전트가 상황에 맞는 구현을 골라 쓸 수 있습니다.
아닙니다. 89.6%는 MetaWorld 6종에서 시연 2개 조건의 OOD 스킬 일반화 성공률(고정 관계형 사전가정 37.9% 대비)이고, 50.0%는 ManiSkill 장기 과제 5종에서 물체 배치가 바뀐 조건의 조합 성공률(full-task Diffusion Policy 10.0% 대비)입니다. 서로 다른 실험·조건의 수치라 하나로 합쳐 말하면 안 됩니다.
이 논문의 실험은 MetaWorld와 ManiSkill이라는 시뮬레이션 조작 벤치마크에서 이뤄졌습니다. 실제 로봇·실제 환경에서 같은 폭의 이득이 재현되는지는 본문에 제시된 사실 범위를 넘어서는 열린 질문입니다.