RL 정책이든 cuMotion이든 같은 구멍에 꽂힌다

로봇팔을 움직이는 "두뇌"는 한 종류가 아닙니다. 경로 계획은 cuMotion으로, 정밀 삽입은 강화학습 정책으로, 협동 동작은 RMPFlow로, AI 파지는 파운데이션 모델로 — 작업마다 최적의 방법이 다릅니다. 문제는, 이 제각각인 두뇌들을 어떻게 같은 시스템에 꽂느냐입니다.

하나의 인터페이스, 여러 구현

해법은 공통 약속(Protocol) 을 정하는 것입니다. 모든 정책은 "관측을 받아 행동을 낸다"는 같은 모양의 인터페이스만 지키면 됩니다.

도식 렌더링 중…

다섯 가지 전혀 다른 두뇌가, 같은 구멍에 꽂힙니다. 러너 입장에선 "PolicyAdapter에 관측을 주면 행동이 나온다"만 알면 됩니다 — 그 안이 RL이든 플래너든 신경 쓰지 않습니다.

💡 이건 전략 패턴이다 — "알고리즘을 갈아 끼울 수 있게 인터페이스로 캡슐화"하는 고전적 전략 패턴입니다. 새 정책(예: 새 RL 체크포인트, 새 파운데이션 모델)이 나와도, 그 인터페이스만 구현하면 코드 변경 없이 꽂힙니다 — 매니페스트로 로봇을 추가하는 철학의 정책판입니다.

왜 이게 중요한가

⚠️ 정책마다 러너를 분기하면 지옥이 된다 — "RL이면 이 경로, 플래너면 저 경로"로 러너에 if를 쌓으면, 정책이 늘 때마다 러너가 복잡해지고 회귀가 터집니다. 정책 종류를 러너가 알면 결합도가 폭발합니다. 어댑터 뒤로 숨기면, 러너는 정책의 종류를 영영 모른 채 일합니다.

이 분리 덕분에 같은 작업을 여러 정책으로 비교하기도 쉽습니다 — 같은 관측에 cuMotion과 RL을 각각 꽂아 KPI를 견줘 보는 식으로요. 검증 플랫폼엔 이 "정책 교체 가능성"이 핵심 가치입니다.

한 줄 정리

📌 로봇의 두뇌는 RL·모션플래너·파운데이션 모델 등 제각각이지만, PolicyAdapter Protocol(관측→행동의 공통 인터페이스)로 같은 구멍에 꽂힌다. 러너는 정책의 종류를 모른 채 일하고(결합도 ↓), 새 정책은 인터페이스만 구현하면 코드 0으로 추가되며, 같은 작업을 여러 정책으로 비교하기도 쉬워진다.