[2026-03-04] VLA 모델은 왜 자꾸 머그컵을 떨어뜨릴까? 로봇의 '금붕어 기억력'을 테스트하는 RoboMME 벤치마크 해부
[Metadata]
- Paper: RoboMME: Benchmarking and Understanding Memory for Robotic Generalist Policies
- ID: 2603.04639
- Project Page: https://robomme.github.io
요즘 로보틱스 판을 보면 한숨부터 나옵니다. ROS2의 무거운 의존성과 씨름하다가 겨우 엔드투엔드(End-to-End) 학습으로 넘어왔더니, 이번엔 모델 지능이 발목을 잡네요. 수십억 파라미터짜리 거대한 VLA(Vision-Language-Action) 모델을 학습시켜서 올려놓으면 뭐하나요? 카메라 화각에서 타겟 물체가 3초만 사라져도 “어? 내 손에 있던 드라이버가 어디 갔지?” 하면서 허공에 삽질을 해대는 게 현재 씬의 냉혹한 현실이거든요.
우리가 LLM 세계에서 컨텍스트 윈도우를 1M, 2M씩 늘리며 환호할 때, 로봇 진영의 엣지(Edge) 단에서 구르는 엔지니어들은 카메라에 잠깐 가려진 물체(Occlusion)나 방금 전에 수행한 행동 이력(History)을 기억하지 못하는 모델의 치매 증상과 싸우느라 밤을 새우고 있습니다. 기존 VLA 모델들이 앞다투어 ‘메모리 메커니즘’을 도입했다고 홍보는 엄청 해대는데, 막상 까보면 자기들 유리한 좁은 환경에서만 테스트하고 끝내버리죠.
이런 답답하고 짜증 나는 상황에서 “너희들 진짜 기억력 좋은 거 맞아? 다 덤벼봐” 하고 판을 엎어버린 벤치마크가 등장했습니다. 바로 RoboMME입니다.
한 줄 요약: 로봇이 방금 전에 본 물체를 까먹는 ‘금붕어 지능’을 저격하기 위해, 16개의 하드코어 기억력 테스트와 14가지 메모리 아키텍처를 π0.5 모델 위에 때려 박고 비교한 벤치마크 끝판왕.
🧠 14개의 메모리 변형 모델들은 도대체 어떻게 돌아가는가?
단순히 프롬프트 텍스트에 과거 대화 내역을 우겨넣는 LLM과 달리, 물리 세계와 상호작용하는 로봇에게 ‘기억(Memory)’을 쥐여주는 건 차원이 다른 엔지니어링 지옥입니다. 시각 정보(RGB, Depth)와 고유 수용성 감각(Proprioception, 로봇 관절의 위치 값 등), 그리고 초당 수십 번씩 쏴야 하는 액션(Action) 텐서가 실시간 스트리밍으로 쏟아지는데 이걸 어떻게 압축해서 들고 갈 건가요?
RoboMME 팀은 현재 로보틱스 씬에서 가장 핫한 아키텍처 중 하나인 π0.5 백본을 베이스라인으로 가져왔습니다. 그리고 트랜스포머(Transformer) 레이어 사이사이에 무려 14가지의 서로 다른 메모리 증강(Memory-augmented) 통합 전략을 직접 깎아서 구현해 넣었죠. 이들이 테스트한 로봇의 기억력은 단순히 ‘과거 프레임 스태킹’ 수준이 아닙니다. 아래 네 가지 차원으로 메모리 구조를 박살 내듯 검증했습니다.
🔹 시간적 기억 (Temporal Memory): 방금 전까지 하던 동작의 리듬과 횟수를 기억하는가? 예를 들어 나사를 5번 돌려야 하는데, 지금 3번째인지 4번째인지 인지하는 능력을 봅니다. RNN 기반의 Hidden State를 모델 내부에 어떻게 유지하고 업데이트하느냐가 핵심 병목이 됩니다. 🔹 공간적 기억 (Spatial Memory): 카메라 프레임 밖으로 벗어난 물체의 3D 물리 좌표를 추적할 수 있는가? 이를 위해 과거의 시각적 특징(Visual Features)을 단순한 1D 토큰이 아니라 3D 공간 텐서로 매핑해 유지하는 구조를 설계했습니다. 🔹 객체 기억 (Object Memory): 타겟 컵이 다른 박스에 가려져 보이지 않더라도(Occlusion), “저 박스 뒤에 컵이 있다”는 객체 영속성을 인지하는 구조입니다. 크로스 어텐션(Cross-Attention) 메커니즘에서 특정 객체 토큰의 가중치를 보존하고 다음 프레임으로 넘겨주는 방식을 취합니다. 🔹 절차적 기억 (Procedural Memory): 긴 시퀀스의 작업(Long-horizon Task)을 수행할 때, 자신이 전체 파이프라인 중 어디쯤 위치해 있는지 파악하는 능력입니다.
재미있는 건 이 14가지 모델의 뼈대입니다. 어떤 녀석은 과거의 관측값을 단순히 토큰화해서 메인 컨텍스트 윈도우에 구겨 넣었고(Token-based), 어떤 녀석은 과거 상태를 고도로 압축된 잠재 벡터(Latent Vector)로 변환해 쿼리(Query)로 사용합니다. 코드를 뜯어보면, 각 프레임의 무거운 시각적 피처를 버퍼에 담아두는 방식이 VRAM을 얼마나 무자비하게 잡아먹는지 뼈저리게 느낄 수 있습니다.
로봇의 실시간 시각, 언어, 행동 데이터를 잠재 공간에서 융합해 메모리 버퍼로 넘기는 파이프라인 다이어그램. 여기서 메모리 I/O 병목이 발생하면 로봇의 팔은 허공에서 덜덜 떨며 멈춰버립니다.
⚔️ 무식한 프레임 스태킹 vs 정교한 잠재 메모리
기존의 SOTA 방식들은 보통 프레임 스태킹(Frame Stacking)을 썼습니다. 과거 N개의 이미지를 텐서 차원(Channel)으로 이어 붙여서 통째로 모델에 던져주는 무식하지만 확실한 방식이죠. 하지만 RoboMME가 파악한 새로운 패러다임(잠재 메모리 및 순환 신경망 결합 방식)과 비교해 보면 어떨까요?
| 평가 지표 | 기존 SOTA (Vanilla VLA + Frame Stacking) | 새로운 패러다임 (Latent/Token Memory VLA) |
|---|---|---|
| 메모리(VRAM) 사용량 | 🚨 매우 높음 (프레임 단위로 선형 증가, OOM 위험) | ✅ 중간 (압축된 잠재 벡터나 토큰만 버퍼에 저장) |
| 추론 속도 (Latency) | 🐢 프레임이 쌓일수록 어텐션 연산량 급증 (O(N^2)) | ⚡ 비교적 빠름 (고정 크기의 State 벡터를 유지할 경우) |
| 가려짐(Occlusion) 대응 | ❌ 카메라에서 사라지면 즉시 망각. 복구 불가. | ✅ 보이지 않아도 위치 정보를 잠재 공간에서 추론 유지 |
| 개발자 경험 (DX) | ✅ 구현이 단순하고 직관적 (파이토치 텐서 Concat 끝) | 🚨 개별 Task마다 메모리 아키텍처 튜닝 및 학습 필요 |
| 콜드 스타트 (Cold Start) | 즉시 과거 데이터 주입하여 시작 가능 | 초기 State 백터 형성을 위한 웜업(Warm-up) 프레임 필요 |
여기서 개발자로서 주목해야 할 수치가 있습니다. 프레임 스태킹은 당장 구현하기엔 꿀입니다. 하지만 태스크 길이가 길어지는 Long-horizon으로 넘어가면 VRAM이 터지거나 Latency가 치솟아서 로봇 팔이 버벅거립니다. 반면 RoboMME에서 보여준 정교한 메모리 모델들은 시스템 자원은 덜 먹지만, “모든 상황에 완벽한 단일 메모리 구조는 없다”는 끔찍하고 현실적인 결론을 냅니다. 공간 추론에 강한 아키텍처가 절차적 기억에서는 죽을 쑤는 식이죠. 결국 당분간은 배포하려는 특정 도메인에 맞춰 아키텍처를 깎아야 한다는 씁쓸한 소리입니다.
🚀 내일 당장 프로덕션에 쓸 수 있을까? (Use Cases)
이 벤치마크와 메모리 아키텍처들은 그저 논문 수를 채우기 위한 연구소 장난감이 아닙니다. 현업에서 당장 부딪히는 엣지 케이스들을 정확히 타겟팅하고 있습니다.
1. 스마트 물류 센터의 피킹 로봇 (Occlusion 지옥 극복) 로봇 팔이 빠르게 움직이는 컨베이어 벨트에서 특정 라벨이 붙은 물건을 집어 올리려는데, 커다란 박스가 지나가면서 타겟 물체를 2~3초간 완전히 가려버립니다. 기존 모델은 타겟을 잃고 에러를 뿜으며 정지하거나 엉뚱한 곳을 찌르겠죠. RoboMME의 ‘객체 기억(Object Memory)’에 특화된 VLA 모델을 도입하면, 객체가 가려진 동안에도 잠재 공간에서 이동 궤적을 추론해 박스가 지나간 직후 정확한 위치로 그리퍼를 뻗을 수 있습니다.
2. 복잡한 식음료(F&B) 조리 보조 로봇 (Long-horizon 상태 추적) “양파를 썰고, 냄비에 기름을 두른 뒤, 볶아줘”라는 명령을 생각해 봅시다. 로봇이 냄비에 기름을 두르는 데 집중하는 동안, 도마 위의 양파는 시야에서 사라집니다. 절차적 기억(Procedural Memory)과 공간적 기억이 강화된 모델은 자신이 방금 ‘양파 썰기’ 단계를 완료했다는 상태 벡터를 유지합니다. 덕분에 기름을 두른 뒤 엉뚱하게 다시 새 양파를 찾지 않고, 정확히 썰어둔 양파의 위치로 팔을 돌릴 수 있습니다.
🧐 Tech Lead’s Verdict
👍 Pros (좋은 점):
- “우리 모델은 장기 컨텍스트를 지원합니다”라는 식의 마케팅 헛소리를 객관적인 수치로 박살 내줄 통합된 기준점이 드디어 생겼습니다. Temporal, Spatial, Object, Procedural로 나눈 16개의 하드코어 태스크 분류는 정말 예술적입니다.
- 단순히 벤치마크 툴킷만 툭 던진 게 아니라, π0.5 백본을 뜯어고쳐 14개의 베이스라인 아키텍처를 직접 구현해 오픈소스로 풀었다는 점은 칭찬받아 마땅합니다. 당장 레포지토리를 클론(Clone)해서 우리 쪽 커스텀 데이터셋에 물려보기 좋습니다.
👎 Cons (아쉬운 점):
- 결론이 현업 엔지니어에게 너무 가혹합니다. “태스크마다 최적의 메모리 구조가 다름”이라니요? 이건 결국 “네가 배포할 환경에 맞춰서 알아서 아키텍처를 튜닝하고 새로 학습시켜라”라는 말과 같습니다. 단일 파운데이션 모델 하나로 다 해결될 줄 알았던 사람들에겐 절망적인 소식입니다.
- 여전히 메모리 읽기/쓰기 연산 때문에 발생하는 미세한 지연 시간(Latency) 오버헤드가 존재합니다. 180ms 이하의 빡빡한 리얼타임 루프가 돌아가야 하는 저사양 엣지 디바이스 환경에서는 이 메모리 오버헤드가 치명적인 발목을 잡을 수 있습니다.
🔥 Final Verdict: Wait for v2 (하지만 당장 코드는 뜯어봐라) 당장 내일 아침 사내 로봇의 프로덕션 제어 코드를 통째로 갈아엎을 수준의 ‘만능 실버 불렛’이 나온 건 아닙니다. 하지만 로봇 비전이나 VLA 모델 파이프라인을 구축하고 있다면 이 논문과 코드는 무조건 까봐야 합니다. 로봇이 왜 자꾸 바보 같은 짓을 반복하며 병목을 일으키는지, 그 근본적인 원인과 디버깅의 방향성을 잡는 데 이만한 가이드라인이 없습니다. 일단 깃허브 레포지토리에 별(Star)부터 박아두고, 여러분의 태스크에 맞는 메모리 모듈이 무엇인지 실험부터 시작해 보시길 권합니다.
