※ 이 글은 Danny Driess 외, 「PaLM-E: An Embodied Multimodal Language Model」을 읽고, 제 방식대로 다시 정리한 글입니다.

PaLM-E는 이미지, 로봇 상태, 3D scene representation 같은 연속적인 센서 정보를 LLM의 입력 공간에 직접 넣어, 로봇 계획·시각 질의응답·언어 작업을 하나의 모델로 다루려는 embodied multimodal language model입니다.

한 줄 요약

PaLM-E는 LLM이 텍스트만 보고 계획하는 한계를 넘기 위해, 이미지와 로봇 센서 정보를 언어 토큰처럼 LLM 안에 넣어 로봇의 고수준 계획과 시각 기반 추론을 하게 만든 모델이다.

조금 더 쉽게 말하면 이렇다.

기존 LLM은 글을 정말 잘 이해한다.
하지만 로봇에게 필요한 것은 글만 이해하는 능력이 아니다.

로봇은 지금 눈앞에 뭐가 있는지 봐야 하고,
물체가 어디에 있는지 알아야 하고,
지금 잡을 수 있는지 판단해야 하고,
실패했으면 다시 계획해야 한다.

PaLM-E는 이 문제를 정면으로 다룬다.

“LLM이 로봇의 센서 정보를 직접 읽을 수 있다면, 단순한 텍스트 계획보다 더 현실적인 embodied reasoning을 할 수 있지 않을까?”

이 논문의 핵심은 로봇 행동값을 바로 출력하는 것이 아니다.
PaLM-E의 중심은 이미지와 상태 정보를 LLM의 입력으로 넣고, 그 결과로 고수준 계획이나 답변을 텍스트로 생성하는 것이다.

즉, PaLM-E는 “로봇 팔의 모터 명령을 바로 내는 모델”이라기보다는,
로봇이 지금 보고 있는 장면을 바탕으로 다음에 무엇을 해야 할지 말해주는 고수준 multimodal planner에 가깝다.

먼저 알아야 할 용어

PaLM-E는 이름부터 어렵다.
그래서 논문을 읽기 전에 최소한 아래 용어는 잡고 가는 게 좋다.

Embodied AI

Embodied AI는 AI가 단순히 텍스트나 이미지 안에서만 추론하는 것이 아니라, 몸을 가진 에이전트가 실제 환경을 보고 행동하는 문제를 다룬다.

로봇이 대표적이다.

예를 들어 ChatGPT에게 “컵을 가져와”라고 말하면 답변을 할 수는 있다.
하지만 로봇은 컵을 보고, 위치를 파악하고, 이동하고, 잡고, 가져와야 한다.

이처럼 언어 이해가 실제 물리 환경의 행동으로 이어지는 문제가 embodied AI의 핵심이다.

Grounding

Grounding은 단어와 실제 세계를 연결하는 것이다.

예를 들어 “파란 블록을 집어”라는 명령이 있을 때,
로봇은 “파란”이라는 단어와 실제 카메라 속 파란 물체를 연결해야 한다.

LLM은 텍스트 안에서는 “파란 블록”을 잘 이해한다.
하지만 실제 장면 속 어떤 물체가 파란 블록인지는 센서 정보와 연결되어야 한다.

PaLM-E는 이 grounding 문제를 풀기 위해, 이미지나 로봇 상태를 LLM의 입력으로 직접 넣는다.

Multimodal Sentence

PaLM-E에서 가장 중요한 개념 중 하나가 multimodal sentence다.

일반적인 LLM 입력은 텍스트 토큰의 나열이다.

Q: What is in the image?
A:

PaLM-E는 여기에 이미지나 상태 정보를 끼워 넣는다.

Q: What happened between <img1> and <img2>?
A:

여기서 <img1>, <img2>는 그냥 문자 그대로의 이미지 표시가 아니다.
이미지를 encoder가 embedding vector로 바꾼 뒤, LLM의 token embedding space에 넣는 자리다.

즉, PaLM-E는 텍스트와 이미지를 따로 처리하는 것이 아니라,
텍스트 토큰 사이에 이미지 embedding을 끼워 넣은 문장을 만든다.

이걸 논문에서는 multimodal sentence라고 부른다.

Low-level Policy

PaLM-E는 고수준 계획을 텍스트로 출력한다.

예를 들어 이런 식이다.

1. Go to the drawers.
2. Open the top drawer.
3. Pick the green rice chip bag.
4. Bring it to the user.

하지만 이 문장 자체가 로봇의 실제 모터 명령은 아니다.

로봇이 실제로 움직이려면 각 단계가 더 낮은 수준의 행동으로 바뀌어야 한다.

예를 들어 Open the top drawer라는 고수준 명령은 실제로는

로봇 베이스 이동
팔 위치 조정
손잡이 접근
그리퍼 닫기
팔 뒤로 당기기

같은 제어 행동으로 변환되어야 한다.

이 역할을 하는 것이 low-level policy다.
PaLM-E는 이 low-level policy를 새로 만드는 논문이라기보다는, 기존 low-level policy를 사용하고 그 위에서 어떤 skill을 어떤 순서로 실행할지 결정하는 모델에 가깝다.

Affordance

Affordance는 쉽게 말해 지금 이 상황에서 어떤 행동이 가능한가를 뜻한다.

예를 들어 로봇 앞에 서랍이 닫혀 있다면,

Pick the chips from the drawer

는 바로 가능하지 않을 수 있다.
먼저 서랍을 열어야 한다.

반대로 서랍이 이미 열려 있고 물체가 보인다면, 집기가 가능할 수 있다.

PaLM-E 논문에서는 mobile manipulation 환경에서 이런 질문을 VQA처럼 다룬다.

Given <img>. Q: Is it possible to <skill> here?

즉, 현재 이미지에서 특정 skill이 실행 가능한지 판단하는 문제로 affordance prediction을 평가한다.

Failure Detection

Failure detection은 로봇이 방금 한 행동이 성공했는지 실패했는지 판단하는 것이다.

예를 들어 로봇이 컵을 집으려고 했는데 실제로는 놓쳤다면,
다음 계획을 계속 진행하면 안 된다.

PaLM-E는 이런 질문도 이미지 기반 VQA처럼 다룬다.

Given <img>. Q: Was <skill> successful?

이게 중요한 이유는 로봇 계획이 한 번에 끝나지 않기 때문이다.
실패하면 다시 봐야 하고, 다시 계획해야 한다.

TAMP

TAMP는 Task and Motion Planning의 약자다.

Task Planning은 “무엇을 어떤 순서로 할 것인가”에 가깝고,
Motion Planning은 “그 행동을 실제 공간에서 어떻게 움직여서 할 것인가”에 가깝다.

예를 들어 “파란 블록을 잡으려면 먼저 노란 블록을 치워야 한다”는 task planning에 가깝다.
반면 팔이 충돌하지 않게 어느 경로로 움직일지는 motion planning에 가깝다.

PaLM-E는 TAMP 환경에서도 실험된다.
여기서 중요한 점은 단순히 물체 이름만 아는 게 아니라, 공간 관계와 실행 가능성을 이해해야 한다는 것이다.

OSRT

OSRT는 Object Scene Representation Transformer의 약자다.

이 논문에서 OSRT는 장면을 단순한 2D 이미지 grid로 보는 대신,
객체 중심의 3D-aware scene representation으로 표현하는 방법이다.

로봇에게는 “이미지 전체가 예쁘게 보이는가”보다
“어떤 물체가 어디에 있고, 무엇을 먼저 치워야 하는가”가 더 중요할 수 있다.

그래서 PaLM-E는 ViT 기반 이미지 표현뿐만 아니라, OSRT 같은 object-centric representation도 비교한다.

Catastrophic Forgetting

Catastrophic forgetting은 모델이 새로운 것을 학습하면서 기존 능력을 잃어버리는 현상이다.

PaLM-E는 원래 강력한 언어 모델인 PaLM을 기반으로 한다.
그런데 여기에 이미지와 로봇 데이터를 학습시키면, 언어 능력이 무너질 수 있다.

논문은 모델 크기가 커질수록 multimodal training 이후에도 기존 언어 능력을 더 잘 유지한다고 보고한다.

이 논문이 나온 이유

PaLM-E가 나온 이유는 크게 세 가지로 볼 수 있다.

1. LLM은 똑똑하지만, 실제 세계를 직접 보지 못한다

LLM은 텍스트 기반 추론을 잘한다.

예를 들어 “컵을 가져오려면 어떻게 해야 하나?”라고 물으면,
LLM은 대략 이런 계획을 만들 수 있다.

1. 컵이 있는 곳으로 간다.
2. 컵을 집는다.
3. 사용자에게 가져온다.

하지만 실제 로봇에게는 이 정도로 충분하지 않다.

로봇은 지금 컵이 보이는지,
컵 주변에 장애물이 있는지,
컵이 잡을 수 있는 위치에 있는지,
서랍이 닫혀 있는지,
이전 행동이 실패했는지 확인해야 한다.

텍스트만 보는 LLM은 이런 정보를 직접 알 수 없다.

2. 기존 LLM 기반 로봇 계획은 grounding이 약했다

PaLM-E 이전에도 LLM을 로봇 계획에 쓰려는 시도가 있었다.

대표적으로 SayCan 계열은 LLM이 가능한 행동 후보를 만들고, affordance function이 실제 가능성을 평가하는 방식이다.

이 방식은 중요한 방향을 열었다.
하지만 한계도 있다.

LLM 자체는 여전히 주로 텍스트만 본다.
장면의 기하 구조나 실제 시각 정보를 LLM 내부에서 직접 처리하는 것은 아니다.

PaLM-E는 여기서 한 걸음 더 들어간다.

LLM 바깥에 perception module을 붙이는 것이 아니라, LLM 입력 공간 안으로 센서 정보를 직접 넣는다.

3. 일반 VLM은 로봇 reasoning을 바로 잘하지 못한다

VLM은 이미지와 텍스트를 함께 다루는 모델이다.

그렇다면 이런 질문이 생긴다.

이미 좋은 VLM이 있는데, 그냥 그걸 로봇 계획에 쓰면 안 되나?

PaLM-E 논문은 그렇지 않다고 본다.

일반 VQA나 captioning으로 학습된 VLM은 이미지에 대한 질문에는 잘 답할 수 있어도,
로봇이 실제 행동을 하기 위해 필요한 embodied reasoning에는 부족할 수 있다.

예를 들어 로봇 계획에서는 이런 질문이 중요하다.

지금 이 skill을 실행할 수 있는가?
방금 행동은 성공했는가?
물체를 잡기 전에 무엇을 치워야 하는가?
여러 단계 중 다음 단계는 무엇인가?

이건 단순 이미지 설명과 다르다.

PaLM-E는 이 문제를 해결하기 위해 robot data, visual-language data, language data를 함께 학습한다.

PaLM-E가 푸는 문제

이 논문이 푸는 문제를 한 문장으로 정리하면 이렇다.

“LLM이 실제 세계의 시각·상태 정보를 직접 조건으로 받아, 로봇의 고수준 계획과 embodied question answering을 수행하게 만들 수 있는가?”

조금 더 나누면 네 가지 문제다.

1. 텍스트와 센서 정보를 하나의 입력으로 합치는 문제

기존 LLM은 텍스트 토큰만 받는다.
PaLM-E는 여기에 이미지, 상태 벡터, 3D scene representation을 넣고 싶어 한다.

그러려면 센서 정보를 LLM이 이해할 수 있는 embedding space로 바꿔야 한다.

PaLM-E의 핵심은 바로 이 지점이다.

이미지 / 상태 / 3D scene representation
        ↓
encoder
        ↓
LLM embedding space
        ↓
text token과 함께 입력

2. 로봇 계획을 텍스트 생성 문제로 바꾸는 문제

PaLM-E는 로봇의 최종 모터 명령을 직접 출력하지 않는다.

대신 고수준 계획을 텍스트로 출력한다.

1. Go to the drawer.
2. Open the top drawer.
3. Pick up the rice chips.
4. Bring them to the user.

이 텍스트는 low-level policy나 planner가 실행한다.

즉, PaLM-E는 로봇 계획을 text generation problem으로 바꾼다.

3. 여러 로봇과 여러 작업을 하나의 모델로 다루는 문제

PaLM-E는 특정 로봇 하나만을 위한 모델이 아니다.

논문은 다음과 같은 여러 환경을 다룬다.

Task and Motion Planning
Language-Table tabletop manipulation
Mobile manipulation
Visual Question Answering
Image Captioning
Language tasks

목표는 하나다.

여러 embodiment와 여러 task를 한 모델 안에서 함께 학습하면, 서로 지식이 전이될 수 있는가?

논문은 이를 transfer라고 부른다.

4. 로봇 데이터 부족 문제

로봇 데이터는 비싸다.

인터넷 텍스트나 이미지처럼 대규모로 쉽게 모으기 어렵다.
로봇이 실제로 움직이며 데이터를 모으려면 시간, 장비, 안전 문제가 모두 들어간다.

그래서 PaLM-E는 중요한 질문을 던진다.

“일반 vision-language 데이터와 언어 데이터를 함께 학습하면, 적은 로봇 데이터에서도 로봇 계획 성능이 좋아질까?”

논문의 주요 결과는 대체로 “그렇다”에 가깝다.

PaLM-E의 핵심 아이디어

PaLM-E의 핵심 아이디어는 생각보다 명확하다.

이미지나 로봇 상태 같은 연속적인 센서 정보를 LLM의 token embedding space에 넣는다.

일반 LLM은 이런 식으로 동작한다.

텍스트 토큰 → embedding → Transformer → 다음 토큰 예측

PaLM-E는 여기에 센서 정보를 끼워 넣는다.

텍스트 토큰 → embedding
이미지/상태 → encoder → embedding
        ↓
텍스트 embedding과 센서 embedding을 섞은 multimodal sentence
        ↓
PaLM
        ↓
텍스트 출력

여기서 중요한 점은 PaLM-E가 이미지를 단순히 별도 모듈에서 처리하고 끝내는 것이 아니라,
LLM의 자기회귀적 생성 과정 안에 이미지 정보를 직접 포함시킨다는 점이다.

모델 구조를 쉽게 보기

PaLM-E는 크게 세 부분으로 볼 수 있다.

1. Sensor Encoder
2. Pre-trained LLM, PaLM
3. Text output used for reasoning or high-level robot control

1. Sensor Encoder

Sensor Encoder는 이미지나 상태 정보를 LLM이 이해할 수 있는 벡터로 바꾼다.

PaLM-E는 여러 종류의 입력 표현을 실험한다.

state vector
ViT image feature
object-centric representation
OSRT 3D-aware scene representation

이 중에서 특히 OSRT가 흥미롭다.

OSRT는 장면을 객체 중심으로 표현하려고 한다.
로봇 작업에서는 단순히 이미지 전체를 보는 것보다, “어떤 객체가 어디에 있고 어떤 객체를 먼저 치워야 하는가”가 더 중요하기 때문이다.

2. PaLM LLM

PaLM-E는 PaLM이라는 대형 언어 모델을 기반으로 한다.

논문에서는 여러 크기의 모델을 다룬다.

가장 큰 모델은 562B 파라미터 규모다.

여기서 중요한 점은 단순히 모델이 크다는 것이 아니다.
모델이 커질수록 multimodal training 이후에도 기존 언어 능력을 덜 잃는 경향이 나타난다.

3. Text Output

PaLM-E의 출력은 텍스트다.

출력은 상황에 따라 달라진다.

시각 질문이면 답변을 낸다.

Q: What is in the image?
A: ...

로봇 계획이면 다음 행동이나 계획 단계를 낸다.

1. Go to the drawers.
2. Open the top drawer.
3. Pick the rice chips.

여기서 OpenVLA와 헷갈리면 안 된다.

PaLM-E는 기본적으로 7D robot action을 직접 출력하는 모델이 아니다.
PaLM-E는 고수준 텍스트 계획을 출력하고, 실제 제어는 low-level policy가 담당한다.

Multimodal Sentence: 이 논문의 핵심 구조

PaLM-E를 이해하려면 multimodal sentence를 꼭 이해해야 한다.

일반 텍스트 문장은 이런 식이다.

Q: What happened between the first image and the second image?
A:

PaLM-E에서는 이 문장 안에 이미지 embedding이 들어간다.

Q: What happened between <img1> and <img2>?
A:

또는 로봇 계획에서는 이런 식이 된다.

Human: Bring me the rice chips from the drawer.
Robot: 1. Go to the drawers.
2. Open the top drawer.
I see <img>.
Robot:

이때 <img>는 단순한 placeholder가 아니다.
실제 이미지를 encoder가 embedding vector sequence로 바꾼 것이다.

PaLM-E는 이 embedding을 텍스트 토큰들과 같은 transformer 입력으로 처리한다.

내가 이 부분에서 느낀 핵심은 이거다.

PaLM-E는 perception result를 텍스트로 바꿔서 LLM에게 설명하는 방식이 아니라, sensor embedding 자체를 LLM의 입력으로 넣는다.

이게 기존 prompt engineering 기반 로봇 계획과 가장 큰 차이다.

PaLM-E의 로봇 제어 루프

PaLM-E는 단발성 답변 모델로만 쓰이지 않는다.
로봇 제어 루프 안에 들어갈 수 있다.

흐름은 다음과 같다.

사용자 명령
        ↓
현재 이미지 / 상태 관측
        ↓
PaLM-E가 다음 고수준 step 생성
        ↓
low-level policy가 해당 step 실행
        ↓
환경이 바뀜
        ↓
새 이미지 관측
        ↓
PaLM-E가 다시 계획

논문에서는 PaLM-E를 high-level policy처럼 볼 수 있다고 설명한다.

즉, PaLM-E가 직접 모든 관절 제어를 하는 것이 아니라,
어떤 low-level skill을 어떤 순서로 실행할지 정한다.

이 점은 로봇 연구에서 매우 중요하다.

로봇이 실제 환경에서 실패하는 이유는 단순히 “계획을 못 세워서”만이 아니다.
실행 중 실패, 물체 위치 변화, 외부 방해, 관측 오류가 모두 생긴다.

그래서 PaLM-E처럼 현재 이미지를 다시 보고 다음 step을 생성하는 구조는 closed-loop planning에 더 가깝다.

입력 표현: PaLM-E는 장면을 어떻게 넣는가

PaLM-E는 입력 표현을 여러 방식으로 실험한다.

1. State Vector

가장 단순한 방식은 state vector다.

예를 들어 물체의 위치, 크기, 색상 같은 정보를 숫자 벡터로 만든다.

object pose
object size
object color
robot state

이 방식은 구조화되어 있어서 모델이 이해하기 쉽다.
하지만 실제 환경에서는 이런 state를 항상 정확히 얻기 어렵다.

2. ViT Image Feature

두 번째는 Vision Transformer를 이용해 이미지 feature를 뽑는 방식이다.

이미지를 patch 단위로 나누고, 이를 transformer가 처리해 token embedding으로 만든다.

이 방식은 일반적인 vision-language model에서 많이 사용된다.

하지만 로봇 계획에서는 한계가 있을 수 있다.

이미지가 grid 형태로 처리되면, 객체 단위의 구조가 명확하지 않을 수 있기 때문이다.
로봇은 단순히 “이미지 전체가 어떤 장면인가”보다 “어떤 객체를 어떤 순서로 조작해야 하는가”가 더 중요하다.

3. Object-centric Representation

그래서 PaLM-E는 object-centric representation도 실험한다.

이 방식은 장면을 객체 단위로 나눠서 표현하려는 시도다.

예를 들어 장면 안에 빨간 블록, 파란 블록, 노란 블록이 있다면,
각 객체를 별도의 token 그룹으로 표현한다.

이 방식은 로봇 계획에 자연스럽다.

로봇 작업은 결국 객체를 중심으로 돌아가기 때문이다.

어떤 객체를 잡을 것인가?
어떤 객체를 먼저 치워야 하는가?
어떤 객체 위에 어떤 객체를 올릴 것인가?

4. OSRT

OSRT는 object-centric하면서도 3D-aware한 scene representation을 제공한다.

논문에서는 TAMP 환경에서 OSRT가 좋은 결과를 보인다.

내가 보기엔 이 부분이 PaLM-E에서 가장 로보틱스다운 지점이다.

LLM이나 VLM만으로는 장면을 “말로” 이해할 수는 있어도,
로봇 계획에 필요한 공간 구조와 객체 관계를 충분히 잡기 어렵다.

OSRT는 이 부족한 부분을 보완하려는 방향이다.

5. Entity Referral

PaLM-E는 object-centric representation을 쓸 때, 객체를 특별한 token으로 참조할 수 있게 한다.

예를 들어 입력 prompt에 이런 식으로 넣는다.

Object 1 is <obj1>.
Object 2 is <obj2>.
Object 3 is <obj3>.

그러면 모델은 출력에서도 특정 객체를 <obj1> 같은 방식으로 지칭할 수 있다.

이게 중요한 이유는 현실의 물체가 항상 자연어로 쉽게 구분되지 않기 때문이다.

예를 들어 같은 색 블록이 여러 개 있으면 “빨간 블록”이라는 말만으로는 부족하다.
그럴 때 entity token으로 객체를 참조하면 계획이 더 명확해질 수 있다.

학습 방식

PaLM-E의 학습은 기본적으로 decoder-only language model의 next-token prediction 구조를 따른다.

다만 입력 prefix에는 텍스트뿐 아니라 이미지나 상태 embedding이 들어간다.

prefix:
Human instruction + image/state embeddings + previous steps

target:
next textual answer or next plan step

loss는 target text token에 대해 cross-entropy로 계산된다.

즉, 모델은 최종적으로 텍스트를 잘 생성하도록 학습된다.

Frozen LLM vs Finetuned LLM

논문은 두 가지 방향을 비교한다.

첫 번째는 LLM을 freeze하고, 입력 encoder나 projector만 학습하는 방식이다.
이 경우 기존 LLM의 언어 능력을 유지하기 쉽다.

두 번째는 LLM까지 함께 finetuning하는 방식이다.
이 경우 embodied task에는 더 잘 맞을 수 있지만, 기존 언어 능력을 잃는 catastrophic forgetting이 생길 수 있다.

논문 결과를 보면, task에 따라 다르지만
모델 크기가 커질수록 multimodal training 이후에도 언어 능력을 더 잘 유지한다.

Full Mixture Training

PaLM-E는 로봇 데이터만 학습하지 않는다.

논문에서 말하는 full mixture에는 다음이 섞인다.

internet-scale vision-language data
VQA data
COCO captioning
Wikipedia text
mobile manipulation robot data
Language-Table robot data
TAMP simulation data

흥미로운 점은 robot data의 비율이 10% 미만이라는 것이다.
Table 6 기준으로 mobile manipulator 3.1%, Language Table 4.2%, TAMP 1.6%로 합치면 약 8.9%다.

즉, PaLM-E의 핵심 주장은 이렇다.

로봇 데이터가 적더라도, 일반 vision-language data와 함께 학습하면 embodied reasoning 성능이 좋아질 수 있다.

실험 환경 전체 보기

PaLM-E는 크게 세 가지 로봇 환경에서 실험된다.

1. TAMP Environment
2. Language-Table Environment
3. Mobile Manipulation Environment

그리고 추가로 일반 vision-language task와 language task에서도 평가된다.

이 논문의 중요한 포인트는 단순히 “로봇 하나에서 잘했다”가 아니다.

여러 로봇 embodiment와 여러 task를 하나의 모델로 학습했을 때 transfer가 생기는가를 본다.

실험 1: TAMP Environment

TAMP 환경은 여러 물체를 잡고 쌓는 계획 문제다.

여기서는 단순히 물체 이름만 아는 것으로는 부족하다.
물체의 위치, 관계, 가능한 순서를 이해해야 한다.

예를 들어 파란 블록을 잡으려면 먼저 노란 블록을 치워야 할 수 있다.

Q: How to grasp the blue object?
A: First grasp the yellow object and place it on the table, then grasp the blue object.

Table 1은 TAMP 데이터가 전체 training data의 1%만 있는 low-data setting을 보여준다.
여기서 planning task는 p1, p2로 나뉜다.

대표 결과는 다음과 같다.

여기서 가장 중요한 건 두 가지다.

첫 번째, full mixture training이 ViT 기반 PaLM-E의 planning 성능을 크게 끌어올린다.
같은 ViT-4B라도 single robot data만 썼을 때보다 full mixture를 썼을 때 성능이 훨씬 좋아진다.

두 번째, OSRT 같은 3D-aware object-centric representation이 TAMP에 특히 강하다.
이는 로봇 planning에서 장면의 기하 구조와 객체 관계가 중요하다는 점을 보여준다.

실험 1-1: Full Mixture와 Pretraining의 효과

Figure 4는 PaLM-E-12B의 TAMP planning success를 비교한다.

이 결과는 꽤 강하다.

같은 1% TAMP data 조건에서도 full mixture를 쓰면 성능이 크게 좋아진다.
특히 full mixture + finetuning 조건은 single robot data만 쓴 경우보다 훨씬 높다.

내가 여기서 본 핵심은 이거다.

로봇 데이터만 많이 모으는 것보다, 이미 풍부한 시각·언어 지식을 가진 모델을 어떻게 로봇 데이터와 함께 학습시키는지가 중요하다.

실험 2: Language-Table Environment

Language-Table은 테이블 위 물체를 언어 지시에 따라 밀거나 정리하는 환경이다.

여기서 PaLM-E는 현재 이미지와 long-horizon instruction을 보고, low-level policy에게 줄 short-horizon instruction을 출력한다.

예를 들어 high-level goal이 다음과 같다고 하자.

Sort the blocks by colors into corners.

PaLM-E는 이를 바로 한 번에 끝내는 것이 아니라, 여러 subgoal로 나눠 출력한다.

Step 1. Push the green star to the bottom left.
Step 2. Push the green circle to the green star.
...

이 실험에서 중요한 점은 few-shot generalization이다.
PaLM-E는 10, 20, 40개 demo 같은 적은 데이터 조건에서도 평가된다.

대표적으로 PaLM-E-12B full mixture + LLM finetune 조건은 Task 1에서 10 demos만으로도 70.0%를 기록하고, 20~40 demos에서는 80.0%까지 오른다.

또한 real robot 결과에서는 PaLM-E가 long-horizon tabletop manipulation task를 수행하면서, 외부 방해가 있어도 다시 계획하는 모습을 보여준다.

이 부분은 로봇 연구에서 중요하다.

로봇은 한 번 계획하고 끝나는 시스템이 아니다.
실행 중 환경이 바뀌면 다시 봐야 하고, 다시 계획해야 한다.

PaLM-E는 이 점에서 closed-loop high-level planner로 볼 수 있다.

실험 3: Mobile Manipulation Environment

Mobile manipulation 환경은 이 논문에서 내 관심사와 가장 가까운 부분이다.

로봇은 주방 환경에서 사람의 지시를 받고, 이동과 조작을 함께 수행해야 한다.

예를 들어 이런 지시가 있을 수 있다.

I spilled my drink, can you bring me something to clean it up?

이 경우 로봇은 단순히 “sponge”라는 단어를 아는 것으로 끝나지 않는다.

1. Find a sponge.
2. Pick up the sponge.
3. Bring it to the user.
4. Put down the sponge.

처럼 긴 계획을 세워야 한다.

논문은 mobile manipulation에서 세 가지를 본다.

1. Affordance prediction
2. Failure detection
3. Long-horizon planning

3-1. Affordance Prediction

Affordance prediction은 현재 상황에서 어떤 skill이 가능한지 판단하는 문제다.

논문에서는 이를 VQA처럼 만든다.

Given <img>.
Q: Is it possible to <skill> here?

대표 결과는 다음과 같다.

여기서 중요한 점은 PaLM-E가 단순 VLM baseline이나 QT-OPT 기반 affordance보다 높은 결과를 낸다는 것이다.

특히 full mixture training의 효과가 다시 보인다.

3-2. Failure Detection

Failure detection은 방금 실행한 skill이 성공했는지 판단하는 문제다.

Given <img>.
Q: Was <skill> successful?

대표 결과는 다음과 같다.

여기서 재미있는 점은 full mixture unfrozen이 항상 좋은 것은 아니라는 점이다.
Failure detection에서는 frozen LLM 조건이 더 좋은 결과를 보인다.

이건 PaLM-E를 무조건 end-to-end로 다 fine-tuning하는 것이 정답은 아니라는 뜻이다.

로봇 task에 맞춰 학습하되, 기존 LLM의 언어·추론 능력을 유지하는 균형이 중요하다.

3-3. Long-horizon Planning

Mobile manipulation의 최종 실험은 long-horizon planning이다.

prompt 구조는 대략 다음과 같다.

Human: <instruction>
Robot: <step history>.
I see <img>.

PaLM-E는 현재까지 수행한 step history와 현재 이미지를 보고 다음 step을 생성한다.
그 step은 low-level policy로 실행된다.
이 과정을 terminate가 나올 때까지 반복한다.

논문은 Ahn et al.의 run data 2912 sequences를 사용해 학습했다고 설명한다.

여기서 low-level policy는 RT-1 기반이다.
즉, PaLM-E가 직접 end-effector control command를 내는 것이 아니라,
RT-1 계열 low-level policy가 실제 제어를 담당한다.

내가 여기서 중요하게 본 것은 이거다.

PaLM-E는 mobile manipulation에서 high-level planner 역할을 하고, RT-1 같은 low-level policy와 결합된다.

이 구조는 나중에 로봇 시스템을 설계할 때도 중요하다.

LLM / VLM planner
        ↓
skill selection
        ↓
low-level policy
        ↓
execution feedback
        ↓
replanning

실험 4: 일반 Vision-Language Task

PaLM-E는 로봇 task만 잘하는 모델을 목표로 하지 않는다.
논문은 PaLM-E가 일반 VQA와 captioning에서도 경쟁력이 있는지 평가한다.

대표 결과는 다음과 같다.

논문은 PaLM-E-562B가 OK-VQA에서 매우 강한 결과를 보였다고 설명한다.

여기서 핵심은 PaLM-E가 로봇 전용 모델만은 아니라는 점이다.

로봇 task를 하면서도 일반 vision-language task를 수행할 수 있는 generalist model을 목표로 한다.

실험 5: 일반 Language Task와 Catastrophic Forgetting

PaLM-E는 PaLM을 기반으로 multimodal training을 한다.

그런데 이렇게 하면 기존 언어 능력이 떨어질 수 있다.
이를 catastrophic forgetting이라고 한다.

논문에서 중요한 결과는 다음과 같다.

가장 작은 PaLM-E-12B는 multimodal training 이후 NLG 성능이 크게 떨어진다.
반면 가장 큰 PaLM-E-562B는 기존 PaLM의 언어 능력을 훨씬 더 잘 유지한다.

이 결과는 foundation model 연구에서 꽤 중요한 메시지를 준다.

모델 크기가 커질수록 새로운 modality를 붙여도 기존 능력을 덜 잃을 수 있다.

물론 이건 동시에 현실적인 한계도 의미한다.
가장 좋은 결과를 내려면 엄청나게 큰 모델이 필요하기 때문이다.

PaLM-E의 주요 기여

PaLM-E의 기여는 크게 다섯 가지로 볼 수 있다.

1. LLM에 embodied sensor input을 직접 넣었다

PaLM-E는 이미지나 상태 정보를 텍스트 설명으로 바꿔서 넣는 것이 아니라,
sensor encoder를 통해 LLM embedding space에 직접 넣는다.

이 점에서 단순 prompt engineering보다 더 깊은 multimodal integration이라고 볼 수 있다.

2. Multimodal Sentence라는 유연한 입력 형식을 보여줬다

PaLM-E는 이미지나 상태 정보를 문장 중간에 자유롭게 삽입할 수 있다.

Q: What happened between <img1> and <img2>?

이런 구조는 단일 이미지 질문뿐 아니라 multi-image reasoning, egocentric Q&A, robot planning에도 확장될 수 있다.

3. 로봇 계획과 VQA를 하나의 모델 안에서 다뤘다

PaLM-E는 로봇 계획만 하는 모델이 아니다.

robot planning
embodied VQA
scene understanding
image captioning
general language tasks

를 하나의 generalist model 안에서 다룬다.

이 점은 Gato나 RT 계열과도 연결되는 generalist agent 흐름 안에서 중요하다.

4. Full mixture training의 transfer 효과를 보였다

로봇 데이터는 전체 mixture의 10% 미만이지만,
일반 vision-language data와 함께 학습했을 때 로봇 planning 성능이 좋아진다.

이건 로봇 연구에서 매우 중요하다.

로봇 데이터는 적고 비싸다.
따라서 인터넷 규모의 vision-language knowledge를 어떻게 로봇 task에 전이할지가 핵심이다.

5. 모델 scale이 catastrophic forgetting을 줄일 수 있음을 보였다

PaLM-E-562B는 multimodal training 이후에도 기존 언어 능력을 비교적 잘 유지한다.

즉, 규모가 커질수록 새로운 modality와 task를 추가해도 기존 능력을 덜 잃을 가능성이 있다.

PaLM-E의 한계

PaLM-E는 매우 중요한 논문이지만, 그대로 완성형 로봇 지능이라고 보기는 어렵다.

1. 직접적인 low-level action policy는 아니다

PaLM-E는 고수준 텍스트 계획을 출력한다.

로봇이 실제로 움직이려면 low-level policy가 따로 필요하다.

즉, PaLM-E 하나만으로 로봇의 전체 제어 문제가 해결되는 것은 아니다.

이 점에서 OpenVLA와 다르다.

OpenVLA는 image + instruction을 받아 7D action을 출력하는 action policy에 가깝지만,
PaLM-E는 image/state + instruction을 받아 textual plan을 출력하는 high-level planner에 가깝다.

2. Low-level policy 품질에 강하게 의존한다

PaLM-E가 좋은 계획을 세워도, low-level policy가 실행을 못 하면 실패한다.

예를 들어 PaLM-E가 “open the drawer”라고 말해도,
실제 drawer opening skill이 약하면 전체 task는 실패한다.

따라서 PaLM-E의 성능은 planner 자체의 성능뿐 아니라,
사용 가능한 skill set과 low-level policy 품질에 의존한다.

3. 출력 제약이 강하게 걸려 있지 않다

논문은 PaLM-E가 어떤 skill이 가능한지 training data와 prompt를 통해 스스로 판단해야 하며,
출력을 별도 mechanism으로 constrain/filter하지 않는다고 설명한다.

이건 유연하다는 장점이 있지만, 위험도 있다.

로봇 시스템에서는 존재하지 않는 skill을 말하거나,
실행 불가능한 순서를 생성할 수 있다.

그래서 실제 시스템에서는 PaLM-E 같은 planner 뒤에 verification layer나 safety guardrail을 붙이는 것이 중요해 보인다.

4. 모델 규모와 접근성 문제가 크다

PaLM-E-562B는 엄청난 규모의 모델이다.

개인 연구자가 그대로 재현하거나 fine-tuning하기는 어렵다.
또한 PaLM과 대규모 ViT 자체가 완전히 자유롭게 다룰 수 있는 open-source 모델은 아니다.

따라서 PaLM-E는 아이디어와 방향성은 매우 중요하지만,
개인 프로젝트에서 그대로 구현하기보다는 구조를 이해하고 더 작은 open model로 재해석하는 쪽이 현실적이다.

5. Real-world long-horizon mobile manipulation은 정량 평가가 제한적이다

Mobile manipulation에서 PaLM-E는 실제 주방 환경에서 long-horizon task를 수행하는 예시를 보여준다.

하지만 이 부분은 주로 qualitative evaluation에 가깝다.
대규모 정량 rollout success로 완전히 검증된 형태는 아니다.

따라서 논문을 읽을 때 “PaLM-E가 모든 모바일 매니퓰레이션 문제를 안정적으로 해결했다”고 해석하면 안 된다.

더 정확한 해석은 이렇다.

PaLM-E는 multimodal LLM이 실제 로봇 planning loop 안에서 작동할 수 있음을 보여준 강력한 proof-of-concept이자 방향 제시 논문이다.

OpenVLA와 헷갈리면 안 되는 지점

내가 전에 정리했던 OpenVLA와 비교하면 차이가 더 선명해진다.

PaLM-E는 “로봇용 ChatGPT”에 가까운 느낌을 줄 수 있지만, 정확히는
sensor-grounded high-level planner라고 보는 것이 더 안전하다.

OpenVLA는 “이미지와 명령에서 바로 행동을 내는 policy”에 더 가깝다.

둘 다 VLA/Embodied AI 흐름에서 중요하지만, 연구 질문이 다르다.

내 연구 방향과 어떻게 연결할 것인가

내가 이 논문에서 가져갈 핵심은 “큰 모델” 자체가 아니다.

진짜 중요한 것은 구조다.

1. LLM Agent는 scene을 직접 봐야 한다

텍스트만 보는 LLM Agent는 로봇 task planning에서 위험하다.

예를 들어 사용자가 이렇게 말한다고 하자.

서랍 안의 과자를 가져와.

텍스트만 보면 계획은 쉽게 나온다.

1. 서랍으로 간다.
2. 서랍을 연다.
3. 과자를 집는다.
4. 사용자에게 가져온다.

하지만 실제 장면에서는 이런 문제가 생길 수 있다.

서랍이 이미 열려 있는가?
과자가 보이는가?
다른 물체가 앞을 막고 있는가?
집을 수 있는 위치인가?
방금 grasp가 성공했는가?

PaLM-E는 이 문제를 해결하기 위해 이미지와 상태 정보를 LLM 입력에 넣는다.

내가 LLM Agent / Task Planning을 공부할 때도 이 관점이 중요하다.

로봇에서 planning은 prompt만 잘 쓰는 문제가 아니라, scene grounding이 함께 들어가야 하는 문제다.

2. Verification과 Guardrail이 반드시 필요하다

PaLM-E는 고수준 계획을 생성한다.

하지만 생성된 계획이 항상 실행 가능한 것은 아니다.

그래서 내 관심사인 verification, guardrail, failure-aware planning과 연결된다.

내가 만들고 싶은 구조는 이런 방향에 가깝다.

Scene Observation
        ↓
LLM / Multimodal Planner
        ↓
Generated Plan
        ↓
Symbolic Verification
        ↓
Geometric / Feasibility Check
        ↓
Low-level Policy Execution
        ↓
Failure Detection
        ↓
Replanning

PaLM-E는 이 중에서 multimodal planner와 failure/affordance reasoning의 가능성을 보여준다.

하지만 verification layer까지 완성해주는 논문은 아니다.

그래서 오히려 내 연구 방향에는 여지가 있다.

3. Scene representation이 중요하다

PaLM-E에서 OSRT 결과가 인상적인 이유는 이것이다.

로봇 task는 단순히 이미지를 잘 보는 문제가 아니다.
객체, 관계, 위치, 가능성을 이해해야 한다.

내가 관심 있는 mobile manipulation, shelf retrieval, task planning에서도 마찬가지다.

예를 들어 반개방형 선반에서 물체를 꺼낼 때는 이런 판단이 필요하다.

목표 물체가 보이는가?
팔이 들어갈 공간이 있는가?
선반 프레임과 충돌하지 않는가?
주변 물체를 밀 가능성이 있는가?
베이스 위치를 바꿔야 하는가?

이건 단순 captioning이 아니다.
3D scene-aware feasibility reasoning에 가깝다.

PaLM-E는 이 방향을 직접 완성하지는 않지만,
LLM이 scene representation을 입력으로 받아 reasoning할 수 있다는 방향을 보여준다.

4. 로봇 데이터는 적으니 transfer가 중요하다

현실적으로 개인이나 석사 연구자가 대규모 real robot data를 모으기는 어렵다.

그래서 PaLM-E의 full mixture 전략은 중요하다.

로봇 데이터만으로 모든 걸 학습하기보다,
이미 풍부한 vision-language knowledge를 가진 모델을 활용하고,
작은 robot task data로 grounding과 planning을 맞추는 방향이 현실적이다.

나에게는 이게 다음 방향으로 이어진다.

1. LLM Agent / Task Planning 구조 이해
2. RAG, Tool Use, Memory로 plan context 관리
3. Verification / Guardrail로 실행 가능성 검증
4. Robot Task Planning으로 연결
5. 이후 Robot Learning / RL로 skill execution 보완

PaLM-E는 이 흐름에서
LLM Agent가 실제 scene과 연결될 때 어떤 형태가 되는지 보여주는 기준 논문으로 볼 수 있다.

내가 이 논문에서 남긴 핵심

1. PaLM-E는 action model이 아니라 embodied reasoning model에 가깝다

PaLM-E는 로봇의 모터 명령을 직접 뽑는 모델이 아니다.

이미지와 상태 정보를 보고, 다음 계획이나 답변을 텍스트로 생성한다.

그래서 PaLM-E를 이해할 때는 “로봇 행동 정책”보다
sensor-grounded planner로 보는 것이 더 정확하다.

2. LLM에 scene을 넣는 방식이 핵심이다

이 논문의 가장 중요한 아이디어는 이것이다.

센서 정보를 텍스트로 요약해서 넣는 것이 아니라,
센서 embedding을 LLM token embedding space에 직접 넣는다.

이 구조 덕분에 PaLM-E는 이미지, 상태, 3D scene representation을 텍스트와 함께 처리할 수 있다.

3. Full mixture training은 로봇 데이터 부족 문제의 힌트다

로봇 데이터는 적다.

그런데 PaLM-E는 일반 vision-language data와 robot data를 함께 학습하면 robot planning 성능이 좋아질 수 있음을 보여준다.

이건 앞으로 VLA, embodied AI, robot learning에서 계속 중요한 방향이 될 것 같다.

4. Scene representation은 로봇 계획의 성능을 크게 바꾼다

TAMP 결과에서 OSRT가 강하게 나온 것은 중요하다.

로봇 계획에서는 단순히 큰 VLM을 쓰는 것보다,
장면을 어떻게 표현할지가 성능에 큰 영향을 준다.

이건 내가 관심 있는 3D scene-aware planning, feasibility verification과 직접 연결된다.

5. PaLM-E 이후에도 검증과 실행 안정성 문제는 남아 있다

PaLM-E는 강력한 multimodal planner다.

하지만 실제 로봇 시스템에서는 다음 문제가 여전히 남는다.

생성된 계획이 실행 가능한가?
존재하지 않는 skill을 말하지 않는가?
실행 중 실패를 어떻게 복구할 것인가?
충돌과 교란을 어떻게 줄일 것인가?

그래서 PaLM-E를 읽고 나서 내가 가져갈 방향은 단순히 “더 큰 모델을 쓰자”가 아니다.

장면을 보고 계획하는 LLM 위에, 실행 가능성 검증과 failure-aware replanning을 붙이는 것이다.

결론 한 줄

PaLM-E는 LLM이 텍스트만 보고 계획하는 단계를 넘어, 이미지와 로봇 센서 정보를 직접 조건으로 받아 embodied reasoning과 고수준 로봇 계획을 수행할 수 있음을 보여준 기준점 같은 논문이다.

나에게 이 논문은 단순히 “큰 multimodal model이 나왔다”가 아니다.

이 논문은 LLM Agent, Task Planning, Verification, Robot Planning을 연결할 때 꼭 기억해야 할 구조를 보여준다.

텍스트만 보는 LLM Planner
        ↓
센서 정보를 직접 받는 Multimodal Planner
        ↓
Affordance / Failure Detection
        ↓
Low-level Policy Execution
        ↓
Replanning

PaLM-E가 모든 문제를 해결한 것은 아니다.
하지만 로봇이 언어 지시를 실제 환경에서 수행하려면, LLM이 결국 scene과 연결되어야 한다는 점을 매우 강하게 보여준다.

그리고 내 연구 방향에서 중요한 질문도 여기서 나온다.

“계획을 잘 생성하는 것에서 끝나지 않고, 그 계획이 실제 장면에서 실행 가능한지 어떻게 검증하고 고칠 것인가?”

이 질문이 PaLM-E 이후 내가 계속 가져가야 할 문제라고 느꼈다.

출처

• Danny Driess et al., PaLM-E: An Embodied Multimodal Language Model, arXiv:2303.03378, 2023.
• PaLM-E project page: https://palm-e.github.io/

※ 이 글은 아래 세 편의 논문을 읽고, 다시 정리한 글입니다.

• Daewon Choi 외, 「Task-Aware Semantic Map: Autonomous Robot Task Assignment Beyond Commands」
• Soojin Jeong 외, 「GNN-Transformer Task Planning Enhanced with Semantic-Driven Data Augmentation」
• Dongmin Yoon 외, 「LUOR: A Framework for Language Understanding in Object Retrieval and Grasping」

세 논문은 모두 조금씩 다른 문제를 다루지만, 크게 보면 하나의 흐름으로 이어집니다. 로봇이 사람의 말을 이해하고, 장면을 해석하고, 필요한 일을 판단하고, 실제 행동으로 옮기기 위해 무엇이 필요한가를 보여주는 논문들입니다.

한 줄 요약

이 세 편의 논문은 로봇이 단순히 명령을 듣고 움직이는 단계를 넘어, 장면을 이해하고, 필요한 일을 판단하고, 자연어와 실제 물체를 연결해 행동하는 방향을 보여준다.

조금 더 쉽게 말하면 이렇다.

• TASMap은 집 안 장면을 보고 “이 물체에는 어떤 일이 필요하지?”를 판단하는 논문이다.
• GTTP는 자연어 명령과 scene graph를 보고 “다음에 어떤 행동을 해야 하지?”를 예측하는 논문이다.
• LUOR는 사람이 물체 이름을 직접 말하지 않아도 “쓸 수 있는 물건”을 찾아서 집는 논문이다.

처음에는 세 논문이 따로 떨어져 보일 수 있다. 하지만 로봇의 실제 흐름으로 놓고 보면 꽤 자연스럽게 이어진다.

장면을 본다
→ 물체 상태와 필요한 일을 이해한다
→ 목표를 이루기 위한 subgoal을 계획한다
→ 자연어가 가리키는 물체를 찾는다
→ grasp pose를 잡고 실제로 집는다

내가 이 세 논문을 같이 본 이유도 여기에 있다. 요즘 VLA, Vision-Language-Action 연구를 보면 “이미지와 자연어를 넣으면 바로 action이 나온다”는 흐름이 많다. 그런데 실제 로봇은 바로 action을 내보내기 전에 더 많은 판단이 필요하다.

무엇을 보고 있는가?
어떤 물체가 중요한가?
이 장면에서 어떤 일이 필요한가?
사용자의 말이 정확히 어떤 물체를 뜻하는가?
지금 바로 행동해도 되는가?

이 질문에 대한 답을 단계별로 보여주는 논문이 바로 TASMap, GTTP, LUOR라고 느꼈다.

먼저 알아야 할 큰 그림

논문을 바로 읽으면 용어가 꽤 많다. Semantic Map, Task Assignment, Scene Graph, Subgoal Planning, Affordance, Implicit Command, Grasp Pose 같은 말이 한꺼번에 나온다. 그래서 먼저 아주 단순하게 정리해보면 좋다.

1. Semantic Map이란?

Semantic Map은 단순히 벽과 장애물 위치만 저장하는 지도가 아니다. 공간 안에 어떤 물체가 있고, 그 물체가 어디에 있으며, 어떤 의미를 갖는지까지 저장하는 지도다.

예를 들어 일반 지도는 이렇게 말한다.

여기에 벽이 있다.
여기에 빈 공간이 있다.
여기에 장애물이 있다.

Semantic Map은 조금 더 나아간다.

여기에 테이블이 있다.
테이블 위에 컵이 있다.
싱크대가 열려 있다.
바닥에 물이 있다.

로봇에게는 이 차이가 크다. 로봇이 청소하거나 정리하거나 물건을 집으려면 단순한 공간 정보만으로는 부족하다. “어디에 무엇이 있는지”를 알아야 하고, 더 나아가 “그 물체가 지금 어떤 상태인지”도 알아야 한다.

TASMap은 여기서 한 단계 더 간다.

물체 위치를 기록하는 지도를 넘어서, 그 물체에 어떤 task가 필요한지까지 저장하는 지도를 만든다.

2. Task Assignment란?

Task Assignment는 말 그대로 어떤 물체나 상황에 어떤 작업을 할당할지 정하는 문제다.

예를 들어 이런 장면이 있다고 하자.

바닥에 먼지가 있다.
책이 바닥에 떨어져 있다.
캐비닛 문이 열려 있다.
싱크대에 그릇이 쌓여 있다.

사람은 이걸 보면 자연스럽게 생각한다.

바닥은 청소해야겠네.
책은 제자리에 둬야겠네.
캐비닛은 닫아야겠네.
그릇은 씻어야겠네.

TASMap이 하려는 것도 이와 비슷하다. 사람이 일일이 “책을 정리해”, “그릇을 씻어”, “캐비닛을 닫아”라고 말하지 않아도, 로봇이 장면을 보고 필요한 일을 제안하는 것이다.

이게 중요한 이유는 간단하다. 미래의 홈 로봇에게 매번 모든 일을 명령하는 건 너무 번거롭다.

바닥 닦아줘.
저 컵 치워줘.
캐비닛 닫아줘.
빨래 접어줘.
쓰레기통 비워줘.

이걸 매번 사람이 말해야 한다면, 로봇이 편한 게 아니라 오히려 귀찮아질 수 있다. 그래서 로봇은 어느 정도 “상황을 보고 필요한 일을 아는 능력”이 필요하다.

3. Scene Graph란?

Scene Graph는 장면을 그래프 형태로 표현한 것이다. 그래프는 보통 node와 edge로 이루어진다.

node = 물체
edge = 물체 사이의 관계

예를 들어 이런 장면이 있다고 하자.

사과가 접시 위에 있다.
접시는 테이블 위에 있다.
로봇은 주방에 있다.
전자레인지는 닫혀 있다.

이걸 scene graph로 표현하면 이런 식이다.

apple --on--> plate
plate --on--> table
robot --inside--> kitchen
microwave --state--> closed

GTTP는 바로 이런 scene graph를 이용한다. 이미지 자체를 바로 넣는 대신, 장면을 구조화된 그래프로 바꾼 뒤, 자연어 명령과 함께 다음 subgoal을 예측한다.

이 구조가 중요한 이유는 로봇 task planning이 단순한 문장 생성이 아니기 때문이다. 로봇은 지금 물체가 어디 있는지, 손에 무엇을 들고 있는지, 문이 열려 있는지 닫혀 있는지 등을 알아야 한다.

4. Task Planning이란?

Task Planning은 목표를 이루기 위해 어떤 행동들을 어떤 순서로 해야 하는지 정하는 문제다.

예를 들어 목표가 이렇게 주어진다.

컵을 주방 캐비닛 안에 넣어라.

그러면 로봇은 대략 이런 순서를 만들어야 한다.

1. 컵을 찾는다.
2. 컵을 집는다.
3. 캐비닛 앞으로 이동한다.
4. 캐비닛을 연다.
5. 컵을 캐비닛 안에 넣는다.
6. 캐비닛을 닫는다.
7. 작업을 끝낸다.

여기서 중요한 건 행동 하나가 아니라 순서다. 캐비닛을 열기 전에 컵을 안에 넣을 수 없고, 컵을 집기 전에 컵이 어디 있는지 알아야 한다. 그래서 task planning은 자연어 이해, 상태 이해, 순서 추론이 모두 필요한 문제다.

GTTP는 이 문제를 LLM에만 맡기지 않고, scene graph와 GNN-Transformer 구조를 이용해 해결하려고 한다.

5. Implicit Command란?

Implicit Command는 물체 이름을 직접 말하지 않는 명령이다.

예를 들어 explicit command는 이렇다.

Give me an apple.
사과를 줘.

목표 물체가 “apple”이라고 명확히 들어 있다.

반면 implicit command는 이렇다.

Give me something to eat.
먹을 것을 줘.

여기서는 “apple”이라는 단어가 나오지 않는다. 하지만 로봇은 장면 속 여러 물체 중에서 먹을 수 있는 것을 찾아야 한다.

다른 예시도 있다.

Give me something to wipe.
닦을 수 있는 걸 줘.

Give me something to cut.
자를 수 있는 걸 줘.

Give me something to drink with.
마실 때 쓸 수 있는 걸 줘.

이런 명령은 실제 생활에서 굉장히 자연스럽다. 사람은 매번 정확한 물체 이름을 말하지 않는다. 상황과 용도만 말하는 경우가 많다.

LUOR는 이 문제를 다룬다. 사용자가 물체 이름을 직접 말하지 않아도, 물체의 용도와 자연어 명령을 연결해 적절한 물체를 찾고 grasp까지 연결한다.

논문 3편의 전체 흐름

내가 이해한 기준으로 세 논문을 순서대로 놓으면 이렇게 된다.

이 흐름은 VLA 관점에서도 중요하다. VLA는 보통 Vision, Language, Action을 하나로 연결하려 한다. 하지만 실제 로봇 시스템에서는 action 이전에 이런 단계들이 필요하다.

Vision
→ scene understanding
→ task-aware representation
→ language grounding
→ subgoal planning
→ object retrieval
→ grasp / action

그래서 나는 이 세 논문을 “VLA action 이전 단계의 구조를 이해하기 위한 논문”으로 봤다.

1. TASMap: Task-Aware Semantic Map

[이미지 첨부: TASMap 논문 Figure 1 - Task-Aware Semantic Map이 물체 상태와 상황 맥락에 따라 task를 제안하는 그림]

한 줄 요약

TASMap은 집 안 장면을 보고, 각 물체가 어떤 task를 필요로 하는지 저장하는 task-aware semantic map을 만드는 논문이다.

조금 더 쉽게 말하면 이렇다.

기존 semantic map이 “여기에 컵이 있다”를 저장했다면, TASMap은 한 단계 더 나아가 이렇게 저장한다.

컵이 싱크대에 있고 더럽다
→ Wash task가 필요하다.

캐비닛 문이 열려 있다
→ Close task가 필요하다.

바닥이 젖어 있다
→ Mop task가 필요하다.

옷이 구겨져 있다
→ Fold task가 필요하다.

즉, TASMap은 단순한 물체 지도가 아니라 로봇이 해야 할 일을 담은 지도다.

기본 정보

• 논문명: Task-Aware Semantic Map: Autonomous Robot Task Assignment Beyond Commands
• 연도 / 학회: 2025 / IEEE International Conference on Robotics and Automation, ICRA 2025
• 저자 / 기관: Daewon Choi, Hosung Lee, Soeun Hwang, Yoonseon Oh / Hanyang University
• 최신 VLA 내 분야
  • Grounding / Alignment: 장면 속 물체 상태와 task를 연결한다.
  • Reasoning / Planning: MM-LLM을 사용해 물체 상태에 맞는 task를 판단한다.
  • Action Representation: 12개 task label을 task-significant vector로 표현한다.
  • Long-horizon / Generalization: 여러 물체와 여러 task를 map 단위로 통합해 후속 planning의 기반을 만든다.
  • Mobile Manipulation: 홈 서비스 로봇이 실제 환경에서 필요한 일을 제안하는 방향과 연결된다.
  • Evaluation / Trustworthiness: 35개 disorder scene과 실제 환경에서 task proposal을 검증한다.

이 논문이 나온 이유

홈 로봇이 실제로 집에서 유용하려면, 사람이 모든 작업을 하나하나 지시하지 않아도 되어야 한다.

예를 들어 집이 어질러져 있다고 하자. 사람이 로봇에게 매번 이렇게 말해야 한다면 너무 불편하다.

바닥에 떨어진 옷 치워줘.
싱크대에 있는 그릇 씻어줘.
열려 있는 캐비닛 닫아줘.
젖은 바닥 닦아줘.
쓰레기통 비워줘.

로봇이 정말 집안일을 도와주는 존재가 되려면, 장면을 보고 스스로 이런 판단을 해야 한다.

이 물체는 제자리에 있다.
이 물체는 옮겨야 한다.
이 물체는 닦아야 한다.
이 물체는 씻어야 한다.
이 물체는 버려야 한다.

TASMap은 바로 이 문제에서 출발한다. 사람이 명령하지 않아도, 로봇이 장면을 이해하고 필요한 task를 제안할 수 있게 만드는 것이다.

TASMap이 푸는 문제

TASMap이 푸는 문제는 한 문장으로 정리하면 이렇다.

“로봇이 명시적인 명령 없이도, 집 안 장면을 보고 어떤 물체에 어떤 일이 필요한지 판단할 수 있을까?”

여기서 중요한 점은 두 가지다.

첫 번째는 object state다. 같은 물체라도 상태에 따라 필요한 일이 달라진다.

정상적으로 서 있는 램프
→ Leave

넘어진 램프
→ Reorient

깨끗한 책상
→ Leave

물이 쏟아진 책상
→ Wipe

닫힌 캐비닛
→ Leave

열린 캐비닛
→ Close

두 번째는 situational context다. 같은 장면이라도 상황 설명이 주어지면 task 우선순위가 달라질 수 있다.

"The house stinks."
→ 냄새와 관련된 그릇, 음식물, 바닥, 싱크대 쪽 task가 중요해짐

"The house is messy."
→ 떨어진 물건, 열린 캐비닛, 정리되지 않은 물건이 중요해짐

즉, TASMap은 물체 이름만 보는 것이 아니라, 물체의 상태와 상황 맥락을 함께 본다.

왜 지금 이 문제가 중요한가?

기존 로봇 task planning은 대체로 사람이 명령을 주는 상황을 전제로 한다. 예를 들어 “부엌에 가서 사과를 집어와”처럼 명확한 명령을 주면, 로봇은 그 명령을 해석하고 실행 계획을 만든다.

하지만 실제 집에서는 사람이 매번 모든 일을 말하기 어렵다. 집이 어질러져 있거나, 냄새가 나거나, 위험한 물체가 놓여 있거나, 문이 열려 있는 상황은 사람이 먼저 말하지 않아도 로봇이 어느 정도 감지해야 한다.

이 지점에서 TASMap은 중요하다. TASMap은 로봇이 단순히 “명령을 수행하는 기계”가 아니라, 환경을 보고 필요한 일을 제안하는 assistant로 가기 위한 중간 표현을 만든다.

입력 / 출력

TASMap의 입력과 출력은 다음처럼 정리할 수 있다.

조금 더 쉽게 말하면, 로봇이 카메라로 집 안을 보고, 물체와 task를 예측한 뒤, 그 정보를 3D map으로 저장하는 구조다.

TASMap의 핵심 아이디어

TASMap의 핵심은 task-significant vector다.

논문에서는 각 object entity가 다음과 같은 형태로 표현된다.

Object Entity = (Label, Sphere, Task-Significant Vector)

조금 쉽게 풀면 이렇다.

Label
→ 물체 이름

Sphere
→ 3D 공간에서 물체의 위치와 크기

Task-Significant Vector
→ 이 물체에 어떤 task가 얼마나 필요한지 나타내는 벡터

TASMap은 12개의 task를 정의한다.

Leave
Relocate
Reorient
Wipe
Vacuum
Mop
Dispose
Fold
Turn off
Wash
Close
Empty

예를 들어 어떤 물체의 task-significant vector에서 Wash 값이 크면, 그 물체는 씻어야 할 가능성이 높다. Close 값이 크면 닫아야 할 가능성이 높다. Relocate 값이 크면 제자리로 옮겨야 할 가능성이 높다.

내 식으로 이해하면 이렇다.

TASMap은 물체마다 “이 물체를 어떻게 해야 하는가”를 점수로 저장하는 지도다.

TASMap의 전체 구조

TASMap은 크게 두 단계로 만들어진다.

1. Task Generation
→ 이미지에서 물체를 찾고, 각 물체에 필요한 task를 예측한다.

2. Semantic Fusion
→ 여러 시점에서 본 물체와 task 정보를 하나의 3D map으로 합친다.

조금 더 자세히 보면 이렇다.

RGB image
→ Instance Segmentation
→ ROI Selection
→ Task Assignment
→ Depth + Camera Pose
→ Instance Segmentation Fusion
→ Task Fusion
→ TASMap

[이미지 첨부: TASMap 논문 Figure 2 - Task generation과 semantic fusion으로 TASMap을 만드는 전체 구조]

이 구조에서 중요한 건 한 장의 이미지만 보고 끝내지 않는다는 점이다. 로봇은 여러 시점에서 장면을 본다. 같은 물체도 가까이서 보면 오염이나 상태가 잘 보이고, 멀리서 보면 위치 관계가 더 잘 보일 수 있다.

그래서 TASMap은 여러 시점에서 얻은 정보를 fusion한다. 이게 실제 로봇 환경에서 중요하다.

주요 기여

TASMap의 기여는 크게 세 가지로 정리할 수 있다.

1. Task-aware semantic map을 제안했다

기존 semantic map이 물체 이름과 위치를 중심으로 했다면, TASMap은 각 물체에 필요한 task까지 표현한다. 이건 mapping과 task planning 사이를 연결하는 중요한 표현이다.

2. 명령 없이 task goal을 생성하는 방향을 제시했다

TASMap은 사람이 구체적 명령을 주지 않아도, 장면을 보고 필요한 task를 제안한다. 이 점에서 command-following 로봇을 넘어 autonomous assistance 방향으로 간다.

3. 실제로 어질러진 홈 환경 데이터와 실험을 제시했다

논문은 35개의 다양한 disorder scene을 만들고, simulation과 real-world 환경에서 TASMap의 효과를 검증한다.

대표 실험 / 벤치마크

논문은 35개의 현실적으로 어질러진 집 장면을 만들어 평가한다. Post-Cooking, Post-Shower, Post-Exercise, Odorous, Laundry-Filled 같은 다양한 상황 개념을 포함한다.

TASMap은 물체 상태를 고려해 적절한 task를 예측한다.

예를 들어 논문 Figure 4에서는 이런 식의 결과가 나온다.

정상적으로 서 있는 lamp
→ Leave

넘어진 lamp
→ Reorient

물이 묻은 desk
→ Wipe

열려 있는 sink
→ Turn off

구겨진 cloth
→ Fold 또는 Relocate

[이미지 첨부: TASMap 논문 Figure 4 - overhead view에서 object별 task가 할당된 TASMap 결과]

또 실제 환경에서도 실험한다. Jackal UGV, RealSense RGB-D camera, SLAM Toolbox, AMCL, SEEM segmentation을 이용해 실제로 TASMap을 만든다.

실제 환경에서 "The house is messy"라는 context가 주어졌을 때는 Relocate, Close, Dispose와 관련된 물체가 선택된다. "The house stinks"라는 context가 주어졌을 때는 Wipe, Wash, Mop과 관련된 물체가 선택된다.

[이미지 첨부: TASMap 논문 Figure 7 - 실제 환경에서 contextual task proposal 결과]

TASMap의 한계

TASMap은 흥미롭지만 한계도 있다.

1. Task set이 미리 정해져 있다

TASMap은 12개의 task를 기준으로 한다. 이건 홈 로봇에는 꽤 유용하지만, 모든 환경을 다 포함하지는 못한다. 예를 들어 요리, 조립, 수리, 사용자 맞춤 보조 같은 task로 확장하려면 task set을 다시 설계해야 한다.

2. MM-LLM 판단에 의존한다

Task assignment는 MM-LLM을 사용한다. 따라서 모델이 물체 상태를 잘못 이해하면 task도 틀릴 수 있다. 물체가 가려져 있거나, 오염이 작게 보이거나, 조명이 나쁘면 잘못 판단할 가능성이 있다.

3. Task proposal과 실제 실행 사이에는 간극이 있다

TASMap은 “무엇을 해야 하는가”를 잘 제안한다. 하지만 그 task를 어떻게 실제 행동으로 실행할지는 별도의 planning과 control 문제가 필요하다.

예를 들어 TASMap이 Wash를 제안했다고 해서, 로봇이 바로 그릇을 집고 싱크대에 가져가 씻을 수 있는 것은 아니다.

TASMap
→ task proposal

추가로 필요한 것
→ task planning
→ navigation
→ manipulation
→ grasping
→ execution monitoring

그래서 TASMap은 독립적인 완성형 로봇 시스템이라기보다, 로봇 task planning으로 넘어가기 위한 중요한 scene understanding 모듈에 가깝다.

TASMap에서 내가 가져간 핵심

TASMap에서 내가 가장 중요하게 본 건 이것이다.

로봇이 행동하기 전에, 장면을 task 관점으로 다시 표현해야 한다.

일반적인 perception은 이렇게 본다.

컵이 있다.
책상이 있다.
옷이 있다.
바닥이 있다.

하지만 홈 로봇에게 더 필요한 표현은 이거다.

컵은 씻어야 한다.
책상은 닦아야 한다.
옷은 접거나 옮겨야 한다.
바닥은 청소해야 한다.

이 차이가 크다. VLA에서도 단순히 object detection만으로는 부족하다. 로봇은 물체가 무엇인지뿐 아니라, 그 물체에 대해 어떤 행동이 적절한지 알아야 한다.

TASMap 결론 한 줄

TASMap은 로봇이 단순히 물체를 인식하는 것을 넘어, 장면 속 물체가 어떤 task를 요구하는지 이해하도록 만드는 task-aware scene representation 논문이다.

2. GTTP: GNN-Transformer Task Planning

[이미지 첨부: GTTP 논문 Figure 1 - semantic-driven data augmentation과 GTTP inference 전체 흐름]

한 줄 요약

GTTP는 자연어 명령과 scene graph history를 입력받아, 로봇이 다음에 수행해야 할 high-level subgoal을 예측하는 GNN-Transformer 기반 task planner다.

조금 더 쉽게 말하면 이렇다.

LLM에게 그냥 “계획 세워줘”라고 묻는 대신, GTTP는 장면을 scene graph로 표현하고, 그 graph의 변화를 보면서 다음 행동을 예측한다.

자연어 명령
+ 현재 장면 graph
+ 이전 상태 graph들
→ 다음 subgoal 예측

예를 들어 명령이 이렇다고 하자.

Put the chicken in the microwave.

그러면 로봇은 다음과 같은 subgoal들을 순서대로 만들어야 한다.

Walk to kitchen
Find chicken
Grab chicken
Open microwave
PutIn chicken microwave
Close microwave
Finish

GTTP는 이걸 LLM 프롬프트에만 맡기지 않고, 학습 가능한 planner로 만든다.

기본 정보

• 논문명: GNN-Transformer Task Planning Enhanced with Semantic-Driven Data Augmentation
• 연도 / 학회: 2025 / AAAI 2025
• 저자 / 기관: Soojin Jeong, Seongwan Byeon, Sangwoo Kim, HyeokJun Kwon, Yoonseon Oh / Hanyang University
• 최신 VLA 내 분야
  • Grounding / Alignment: instruction과 scene graph object를 연결한다.
  • Reasoning / Planning: GNN-Transformer 구조로 high-level subgoal을 예측한다.
  • Action Representation: action-object pair 형태의 subgoal을 출력한다.
  • Long-horizon / Generalization: state graph history를 사용해 긴 task 진행을 반영한다.
  • Mobile Manipulation: 실제 mobile manipulator에 배포해 sim-to-real 가능성을 보인다.
  • Evaluation / Trustworthiness: VirtualHome과 real-world task에서 실행 가능성과 성공률을 평가한다.

이 논문이 나온 이유

LLM은 task planning에 꽤 유용하다. 상식도 있고, 자연어 명령도 잘 이해한다. 하지만 로봇 task planning에서는 몇 가지 문제가 있다.

1. LLM은 실제 물리 환경 이해가 약할 수 있다

LLM은 문장으로는 그럴듯한 계획을 만든다. 하지만 로봇이 실제로 보는 환경과 맞지 않는 계획을 만들 수 있다.

예를 들어 이런 계획은 말로는 자연스럽다.

Open the microwave.
Put the mug inside.
Close the microwave.

하지만 실제 장면에 microwave가 없거나, mug가 다른 방에 있거나, 이미 손에 다른 물체를 들고 있다면 실행할 수 없다.

2. Prompt 예시에 성능이 크게 의존한다

LLM planner는 prompt에 어떤 예시를 넣느냐에 따라 성능이 달라진다. 이건 실험적으로도 불안정하고, 실제 시스템에 넣기에도 부담이 있다.

3. 비용이 크다

LLM을 매 단계 호출하면 비용과 시간이 커진다. 로봇은 매 순간 상태가 바뀌기 때문에, planning을 반복해야 할 수 있다. 그때마다 거대한 LLM을 부르는 건 비효율적이다.

4. Task planning 데이터가 부족하다

로봇 task planning 데이터는 만들기 어렵다. 사람이 일일이 plan을 작성하고 검증해야 하기 때문이다.

GTTP는 이 문제들을 해결하기 위해 두 가지를 제안한다.

1. GNN-Transformer 기반 task planner
2. LLM을 활용한 semantic-driven data augmentation

여기서 중요한 건 LLM을 버리는 게 아니라는 점이다. LLM은 데이터를 늘리고 검증하는 데 사용하고, 실제 planner는 GTTP라는 task-specific model로 만든다.

GTTP가 푸는 문제

GTTP가 푸는 문제는 한 문장으로 정리하면 이렇다.

“자연어 명령과 환경의 scene graph history가 주어졌을 때, 로봇이 다음에 수행해야 할 subgoal을 예측할 수 있을까?”

입력은 두 가지다.

1. Goal instruction I
2. State graph history g0:t

출력은 다음 subgoal이다.

πt+1 = (action, object)

논문에서 사용하는 action set은 다음과 같다.

Walk
Find
Open
Close
Grab
PutIn
PutBack
SwitchOn
SwitchOff
Finish

예를 들어 출력은 이런 식이 될 수 있다.

(Walk, kitchen)
(Find, mug)
(Grab, mug)
(Open, cabinet)
(PutIn, mug)
(Finish)

즉, GTTP는 low-level control을 직접 출력하는 모델은 아니다. 로봇 팔 각도나 모터 제어값을 출력하는 것이 아니라, high-level task action을 예측한다.

VLA 관점으로 보면 GTTP는 action policy 이전의 task-level planning 모듈에 가깝다.

왜 지금 이 문제가 중요한가?

LLM 기반 task planning은 최근 로봇 연구에서 많이 사용되고 있다. 하지만 LLM은 실제 환경을 직접 보는 모델이 아니기 때문에, scene state와 맞지 않는 계획을 만들 수 있다. 또한 prompt engineering에 많이 의존하고, 호출 비용도 크다.

GTTP는 이 문제를 task-specific planner로 푼다. 장면을 scene graph로 표현하고, GNN으로 구조를 읽고, Transformer로 task progress를 반영한다. 즉, 자연어 명령과 실제 환경 상태를 함께 고려하는 planner를 만드는 방향이다.

이건 VLA에서도 중요하다. action을 바로 출력하기 전에, 현재 장면에서 가능한 subgoal을 고르는 능력이 필요하기 때문이다.

입력 / 출력

GTTP의 입력과 출력은 다음처럼 정리할 수 있다.

GTTP의 핵심 아이디어

GTTP의 핵심은 scene graph와 instruction을 함께 보고, 시간에 따른 task progress를 이해하는 것이다.

전체 구조는 크게 세 부분으로 볼 수 있다.

1. Scene graph encoder / Instruction encoder
2. Graph feature extractor
3. Subgoal predictor + Subgoal selector

[이미지 첨부: GTTP 논문 Figure 2 - scene graph encoder, graph feature extractor, progress context fusion, subgoal predictor 구조]

1단계: Scene Graph와 Instruction Encoding

GTTP는 장면을 scene graph로 받는다.

각 node는 물체를 나타내고, 다음 정보를 가진다.

id
class name
category
properties
states

예를 들어 apple node는 이런 식으로 표현될 수 있다.

{
  "id": 215,
  "category": "Food",
  "class_name": "apple",
  "properties": ["GRABBABLE", "EATABLE"],
  "states": []
}

edge는 물체 사이 관계를 나타낸다.

apple --on--> plate
plate --inside--> kitchen
character --close--> table

GTTP는 이 graph 정보를 Sentence-BERT로 embedding한다. 자연어 instruction도 같은 embedding space로 바꾼다.

이게 중요한 이유는 scene graph와 instruction이 서로 연결되어야 하기 때문이다. “put the apple in the fridge”라는 명령이 들어오면, graph 안에서 apple과 fridge가 중요한 node가 된다.

2단계: GNN으로 장면 구조 이해하기

Scene graph는 graph 구조이기 때문에, GTTP는 GNN을 사용한다.

GNN은 주변 node와 edge 정보를 이용해 각 node representation을 업데이트한다. 쉽게 말하면, 각 물체가 혼자 존재하는 것이 아니라 주변 관계까지 반영되도록 만든다.

예를 들어 apple node는 단순히 apple 자체만 보면 부족하다.

apple이 어디에 있는가?
주변에 plate가 있는가?
robot과 가까운가?
fridge와 어떤 관계인가?

이런 정보가 task planning에 중요하다.

GTTP는 GNN layer를 통해 node, edge, global instruction feature를 함께 업데이트한다. 특히 instruction embedding을 graph update 과정에 넣어, 명령과 관련 있는 object feature가 더 잘 살아나도록 만든다.

내 식으로 이해하면 이렇다.

GNN은 장면 속 물체들이 서로 어떤 관계를 갖는지 읽는 역할을 한다.

3단계: Progress Context Fusion

Progress Context Fusion은 GTTP에서 꽤 중요한 부분이다.

로봇 task planning은 현재 상태만 보면 안 된다. 지금까지 무엇을 했는지 알아야 한다.

예를 들어 이런 명령이 있다.

Open the cabinet and put the mug inside.

초반에는 cabinet을 여는 게 중요하다. 하지만 cabinet을 이미 열었다면, 다음에는 mug를 넣는 게 중요하다.

즉, 같은 instruction이라도 진행 상황에 따라 다음 subgoal이 달라진다.

cabinet closed
→ Open cabinet

cabinet open + robot holding mug
→ PutIn mug cabinet

mug inside cabinet
→ Close cabinet or Finish

Progress Context Fusion은 state history와 instruction token을 연결해서, 현재 단계에서 어떤 instruction token이 중요한지 반영한다.

이 부분이 GTTP의 핵심이다. 단순히 명령 전체를 한 번 embedding하는 것이 아니라, task 진행 상황에 따라 instruction의 어느 부분을 봐야 하는지 조정한다.

4단계: Subgoal Predictor와 Selector

마지막으로 GTTP는 다음 action과 object 확률을 예측한다.

p(action)
p(object)

그리고 subgoal selector가 실행 가능한 subgoal 중 가장 확률이 높은 것을 고른다.

이 부분도 중요하다. 모델이 아무 action이나 고르면 안 된다. 현재 상태에서 실제로 가능한 행동이어야 한다.

예를 들어 로봇이 아직 mug를 들고 있지 않은데 PutIn mug cabinet을 선택하면 안 된다. 그래서 GTTP는 feasible subgoal을 고르는 selector를 둔다.

내가 이해한 핵심은 이렇다.

GTTP는 “그럴듯한 다음 행동”이 아니라 “현재 상태에서 가능한 다음 행동”을 고르려 한다.

Semantic-Driven Data Augmentation

GTTP에서 또 하나 중요한 부분은 데이터 생성이다.

로봇 task planning 데이터는 만들기 어렵다. 사람이 직접 task plan을 만들고, 그 plan이 말이 되는지 검증하고, 자연어 instruction까지 붙여야 한다.

GTTP는 작은 seed dataset에서 출발한다.

seed data: 45개

그리고 semantic-driven augmentation을 통해 데이터를 크게 늘린다.

augmented data: 14,666개

전체 흐름은 대략 이렇다.

작은 seed task dataset
→ object 의미를 고려해 task plan 변형
→ LLM으로 plan validity 검증
→ LLM으로 자연어 instruction 생성
→ 대규모 instruction-annotated task dataset 생성

이 부분이 흥미로운 이유는 LLM을 planner 자체로 쓰는 게 아니라는 점이다. LLM은 데이터를 만들고 검증하는 데 사용한다. 실제 inference에서는 GTTP가 scene graph와 instruction을 보고 subgoal을 예측한다.

내 식으로 정리하면 이렇다.

LLM은 선생님처럼 데이터를 만들어주고, GTTP는 그 데이터를 보고 실제 task planner로 학습된다.

주요 기여

GTTP의 기여는 크게 세 가지로 정리할 수 있다.

1. GNN-Transformer 기반 task planner를 제안했다

GTTP는 scene graph의 구조를 GNN으로 이해하고, Transformer로 task 진행 흐름을 반영한다. 이를 통해 자연어 명령과 환경 상태를 함께 고려한 high-level planning을 수행한다.

2. Semantic-driven data augmentation을 제안했다

작은 seed dataset에서 출발해 semantic augmentation, LLM 기반 plan verification, instruction generation을 통해 대규모 task planning 데이터를 만든다.

3. Real-world mobile manipulator에서 검증했다

GTTP는 simulation에서 학습된 뒤 실제 mobile manipulator에 배포되어 sim-to-real 가능성을 보인다.

대표 실험 / 벤치마크

GTTP는 VirtualHome 환경에서 평가된다. 논문은 seen environment와 unseen environment를 나누어 실험한다.

GTTP는 baseline보다 높은 성능을 보인다. 특히 GTTP는 seen environment에서 Executability 99.9, GCR 76.1, SR 62.9를 보였고, unseen environment에서도 Executability 100.0, GCR 75.8, SR 57.7을 보였다.

여기서 지표를 간단히 보면 이렇다.

Executability
→ 예측한 subgoal이 실행 가능한가?

GCR
→ 목표 조건을 얼마나 잘 달성하는가?

SR
→ 전체 task를 성공하는가?

GTTP의 Executability가 높은 이유는 subgoal selector가 실행 가능한 subgoal을 고르기 때문이다. 즉, GTTP는 단순히 확률이 높은 action만 고르는 게 아니라, 현재 상태에서 실행 가능한지를 함께 고려한다.

또 real-world experiment도 진행한다. 7가지 task를 goal instruction과 step-by-step instruction 두 형식으로 실험하고, 실제 mobile manipulator에서 sim-to-real transfer를 검증한다.

Ablation 결과도 중요하다. Progress Context Fusion을 제거하면 성능이 크게 떨어진다. Node dropout을 제거하면 real-world 성능이 크게 떨어진다.

이 결과는 꽤 의미 있다.

Progress Context Fusion
→ task 진행 상황과 instruction token의 관계를 이해하는 데 중요

Global update in GNN
→ instruction 정보를 graph node에 반영하는 데 중요

Node Dropout
→ 실제 환경처럼 object 수가 달라지는 상황에 적응하는 데 중요

특히 node dropout은 내 프로젝트 관점에서도 중요해 보인다. 실제 환경에서는 항상 완벽한 scene graph가 주어지지 않는다. object가 빠질 수도 있고, segmentation이 틀릴 수도 있고, 상태 인식이 불완전할 수 있다.

GTTP는 이런 불확실성에 대비하기 위해 학습 중 일부 background object를 drop한다. 이건 현실적인 robustness를 위한 설계라고 볼 수 있다.

GTTP의 한계

GTTP도 한계가 있다.

1. Scene graph 품질에 의존한다

GTTP는 scene graph를 입력으로 받는다. 따라서 scene graph가 틀리면 planning도 흔들릴 수 있다.

실제 로봇에서는 scene graph를 만드는 과정 자체가 어렵다.

물체 인식 오류
상태 인식 오류
관계 추론 오류
누락된 object
잘못된 edge

이런 오류가 있으면 GTTP가 좋은 구조를 가져도 성능이 떨어질 수 있다.

2. Long-horizon task에서는 여전히 어렵다

논문에서도 task plan이 길어질수록 성능이 떨어지는 경향이 나온다. 이건 당연한 문제다.

계획이 길어질수록 앞 단계의 작은 오류가 뒤 단계로 누적된다.

잘못된 Find
→ 잘못된 Grab
→ 잘못된 PutIn
→ 최종 goal 실패

그래서 long-horizon task에서는 planning뿐 아니라 error detection과 recovery가 필요하다.

3. Action skill set이 제한되어 있다

GTTP는 high-level action set을 미리 정의한다.

Walk, Find, Open, Close, Grab, PutIn, PutBack, SwitchOn, SwitchOff, Finish

이 구조는 VirtualHome과 household task에는 적합하지만, 더 복잡한 manipulation task로 확장하려면 action skill set을 다시 설계해야 한다.

GTTP에서 내가 가져간 핵심

GTTP에서 내가 가장 중요하게 본 건 두 가지다.

첫 번째는 scene graph 기반 planning이다. VLA를 바로 end-to-end action으로만 보면, 중간 reasoning 구조가 잘 보이지 않을 수 있다. GTTP는 장면을 구조화하고, 그 구조 위에서 next subgoal을 고르는 방식을 보여준다.

두 번째는 task progress 이해다. 로봇은 명령을 한 번 이해하고 끝내면 안 된다. 지금까지 어디까지 했는지 알아야 다음 행동이 나온다.

명령 이해
+ 현재 상태
+ 과거 상태
+ task 진행 정도
→ 다음 subgoal

이 흐름은 내가 만들고 싶은 VLA 탑다운 프로젝트와도 잘 맞는다. 처음부터 low-level action을 만들기보다, 먼저 scene representation과 subgoal decision을 잘 잡는 게 중요하다.

GTTP 결론 한 줄

GTTP는 LLM에게 planning을 전부 맡기는 대신, scene graph와 task history를 이용해 현재 상태에서 실행 가능한 다음 subgoal을 예측하는 구조를 보여준다.

3. LUOR: Language Understanding Object Retrieval and Grasping

[이미지 첨부: LUOR 논문 Figure 1 - explicit command와 implicit command에 따라 4-DoF grasp pose를 추정하는 예시]

한 줄 요약

LUOR는 사용자가 물체 이름을 직접 말하지 않아도, 물체의 용도를 기반으로 목표 물체를 찾고 grasp pose까지 연결하는 object retrieval and grasping framework다.

조금 더 쉽게 말하면 이렇다.

사용자가 이렇게 말하면 쉽다.

Give me an apple.
사과를 줘.

로봇은 apple을 찾으면 된다. 이건 explicit command다.

그런데 실제 사람은 이렇게 말할 때도 많다.

Give me something to eat.
먹을 것을 줘.

Give me something to wipe.
닦을 것을 줘.

Give me something to write.
쓸 것을 줘.

이 경우 목표 물체 이름이 명령 안에 없다. 로봇은 “eat”, “wipe”, “write” 같은 용도를 보고 물체를 추론해야 한다.

LUOR는 이 문제를 다룬다.

기본 정보

• 논문명: LUOR: A Framework for Language Understanding in Object Retrieval and Grasping
• 연도 / 학회: 2025 / International Journal of Control, Automation, and Systems
• 저자 / 기관: Dongmin Yoon, Seonghun Cha, Yoonseon Oh / Hanyang University
• 최신 VLA 내 분야
  • Grounding / Alignment: 명령과 object image를 embedding space에서 정렬한다.
  • Reasoning / Planning: implicit command에서 object affordance를 기반으로 target을 추론한다.
  • Action Representation: target object retrieval 뒤 grasp pose로 연결한다.
  • Long-horizon / Generalization: 다양한 ImageNet/ObjectNet class로 확장 가능성을 보인다.
  • Mobile Manipulation: Franka Panda manipulator로 실제 grasping을 수행한다.
  • Evaluation / Trustworthiness: explicit/implicit retrieval, classification preservation, real-world grasping을 평가한다.

이 논문이 나온 이유

기존 natural language object retrieval 연구는 주로 물체 이름이 명시된 명령을 다뤘다.

Bring me a cup.
Pick up the apple.
Give me the bottle.

하지만 실제 생활에서는 물체 이름을 정확히 말하지 않는 경우가 많다.

예를 들어 물을 쏟았을 때 사람은 이렇게 말할 수 있다.

Give me something to wipe.

이때 적절한 물체는 paper towel, tissue, towel 같은 것일 수 있다. 명령 안에 물체 이름은 없지만, 용도는 분명하다.

이걸 로봇이 이해하려면 object name만 보는 것이 아니라 affordance를 이해해야 한다.

wipe
→ paper towel, towel, tissue

cut
→ knife, scissors, cutter

drink
→ cup, mug, bottle

write
→ pen, pencil, marker

LUOR는 이 affordance 기반 implicit command 이해를 CLIP 구조 위에서 해결하려고 한다.

LUOR가 푸는 문제

LUOR가 푸는 문제는 한 문장으로 정리하면 이렇다.

“여러 물체가 있는 복잡한 장면에서, 명시적 또는 암시적 자연어 명령에 맞는 물체를 찾고 집을 수 있을까?”

LUOR의 입력은 다음과 같다.

1. 자연어 명령
2. 카메라 이미지
3. 이미지 안의 여러 object 후보

출력은 다음과 같다.

1. 명령에 맞는 target object
2. 해당 object의 grasp pose

예를 들어 입력이 이렇다.

Command: Give me something to write.
Objects: pen, cup, apple, tape, remote

LUOR는 pen을 골라야 한다. 그리고 MTD module이 예측한 grasp pose를 이용해 로봇이 실제로 pen을 집는다.

왜 지금 이 문제가 중요한가?

실제 사람의 명령은 항상 정확하지 않다. 사용자는 로봇이 이해하기 쉽게 object category를 말해주지 않을 수 있다. 오히려 상황과 목적만 말하는 경우가 많다.

닦을 것 줘.
먹을 것 줘.
자를 것 줘.
마실 때 쓸 것 줘.

이런 명령을 이해하려면 단순한 object name grounding을 넘어서, object affordance를 이해해야 한다. LUOR는 이 문제를 explicit command와 implicit command를 함께 다루는 object retrieval 문제로 정의한다.

VLA 관점에서도 중요하다. 로봇이 action을 수행하려면 먼저 target object를 정확히 골라야 한다. 특히 물체 이름이 직접 주어지지 않는 상황에서는 language understanding과 affordance grounding이 핵심이 된다.

입력 / 출력

LUOR의 입력과 출력은 다음처럼 정리할 수 있다.

LUOR의 핵심 아이디어

LUOR의 핵심은 CLIP의 text encoder만 fine-tuning한다는 점이다.

CLIP은 이미지와 텍스트를 같은 embedding space에 놓는 모델이다. 기본적으로 explicit command에는 강하다.

image: apple
text: apple
→ 잘 맞음

하지만 implicit command에는 약할 수 있다.

image: paper towel
text: something to wipe
→ 기본 CLIP은 이 관계를 충분히 잘 모를 수 있음

LUOR는 이 문제를 해결하기 위해 CLIP image encoder는 freeze하고, text encoder만 usage-focused로 fine-tuning한다.

CLIP image encoder
→ freeze

CLIP text encoder
→ fine-tuning

목표
→ 물체 이미지와 용도 기반 명령이 더 잘 맞도록 embedding space 조정

이 방식의 장점은 두 가지다.

첫째, image embedding space를 건드리지 않기 때문에 CLIP이 가진 일반적인 이미지 분류 능력을 크게 해치지 않는다.

둘째, text encoder만 학습하기 때문에 상대적으로 적은 데이터와 짧은 시간으로 학습할 수 있다.

LUOR의 전체 구조

LUOR 시스템은 크게 두 모듈로 구성된다.

1. LUOR module
→ 자연어 명령에 맞는 target object를 찾는다.

2. MTD module
→ object detection과 grasp detection을 동시에 수행한다.

[이미지 첨부: LUOR 논문 Figure 2 - MTD가 object bounding box와 grasp pose를 만들고, LUOR가 target object를 고르는 전체 구조]

전체 흐름은 이렇다.

RGB image
→ MTD module
→ object bounding boxes + grasp poses

각 object crop
→ CLIP image encoder
→ image embeddings

language command
→ fine-tuned CLIP text encoder
→ text embedding

cosine similarity 계산
→ 가장 유사한 object 선택

선택된 object의 grasp pose 사용
→ robot grasp execution

여기서 핵심은 object retrieval과 grasp detection이 분리되어 있다는 점이다.

LUOR
→ 어떤 물체를 집을지 결정

MTD
→ 어떻게 집을지 grasp pose 제공

이 구조가 실제 로봇 시스템스럽다. 언어 이해와 물리적 grasping은 서로 다른 문제이기 때문이다.

LUOR의 데이터셋

LUOR는 implicit command를 다루기 위해 새로운 verb-object pair dataset을 만든다.

논문에서 만든 데이터는 크게 두 부분이다.

ImageNet 기반
→ 712 verb-object pairs
→ 78 verbs
→ 244 ImageNet classes

ObjectNet 기반
→ 336 verb-object pairs
→ 54 verbs
→ 138 ObjectNet classes

예시는 이런 식이다.

wipe
→ paper towel, bath towel, dishrag, toilet tissue

drink
→ cup, goblet, coffee mug, beer glass

cut
→ letter opener, hatchet, cleaver

listen
→ cassette player, tape player, radio, iPod

이게 중요한 이유는 implicit command를 학습하려면 물체 이름만으로는 부족하기 때문이다. 물체와 행동/용도 사이의 연결이 필요하다.

object 중심 데이터
→ apple, cup, towel

usage 중심 데이터
→ eat, drink, wipe

LUOR는 이 usage 중심 관계를 학습한다.

LUOR의 학습 방식

LUOR는 contrastive loss를 사용한다.

쉽게 말하면, 같은 명령과 맞는 object image는 가깝게 만들고, 맞지 않는 object image는 멀게 만든다.

예를 들어 명령이 이렇다.

Give me something to wipe.

positive image는 towel일 수 있다. negative image는 apple, keyboard, bottle, shoe 같은 물체일 수 있다.

학습 목표는 이렇다.

text embedding("something to wipe")
→ towel image embedding과 가까워짐
→ apple image embedding과 멀어짐

이 방식이 CLIP의 기본 아이디어와 비슷하지만, LUOR는 로봇 object retrieval task에 맞게 text encoder를 조정한다는 점이 다르다.

MTD: Object Detection과 Grasp Detection

LUOR만으로는 물체를 고를 수는 있어도, 실제로 집을 수는 없다. 그래서 논문은 YOLOv3 기반 MTD module을 함께 사용한다.

MTD는 동시에 두 가지를 예측한다.

1. Object detection
→ 물체 bounding box

2. Grasp detection
→ grasp pose

논문은 class-agnostic 방식으로 MTD를 학습한다. 즉, object class를 꼭 맞히는 데 집중하기보다, 물체가 어디 있고 어떻게 잡을 수 있는지를 예측한다.

이게 LUOR와 잘 맞는다. 왜냐하면 LUOR가 언어 기준으로 target object를 고르고, MTD는 그 물체를 잡을 수 있는 pose를 제공하면 되기 때문이다.

내 식으로 정리하면 이렇다.

LUOR
→ 이 물체가 사용자의 명령에 맞다.

MTD
→ 이 물체는 이렇게 잡으면 된다.

주요 기여

LUOR의 기여는 크게 세 가지로 정리할 수 있다.

1. Explicit command와 implicit command를 함께 다루는 LUOR module을 제안했다

LUOR는 물체 이름이 명시된 명령뿐 아니라, object function만 주어진 암시적 명령도 처리한다.

2. CLIP text encoder fine-tuning 전략을 제안했다

CLIP image encoder는 freeze하고 text encoder만 fine-tuning하여, object retrieval 성능을 높이면서 classification 성능을 크게 해치지 않는다.

3. Object retrieval과 grasping을 실제 로봇 시스템으로 연결했다

LUOR는 YOLOv3 기반 MTD module과 결합되어 object detection, grasp pose detection, robot grasping까지 연결된다.

대표 실험 / 벤치마크

LUOR는 RNN-based model, CLIP, CLIP+GPT-4와 비교된다.

가장 중요한 결과는 implicit command에서 LUOR가 크게 앞선다는 점이다.

ImageNet-C에서 LUOR는 다음 성능을 보인다.

Implicit retrieval: 90.35%
Explicit retrieval: 95.98%

ObjectNet-C에서는 다음 성능을 보인다.

Implicit retrieval: 76.60%
Explicit retrieval: 88.88%

비교해보면 차이가 더 잘 보인다.

ImageNet-C implicit
CLIP: 49.21%
CLIP+GPT-4: 61.55%
LUOR: 90.35%

ObjectNet-C implicit
CLIP: 47.89%
CLIP+GPT-4: 54.56%
LUOR: 76.60%

이 결과는 꽤 명확하다. CLIP은 explicit command에는 강하지만, implicit command에는 약하다. 반면 LUOR는 usage-focused text encoder fine-tuning 덕분에 implicit command에서 강해진다.

LUOR의 효율성

LUOR의 또 다른 장점은 효율성이다.

논문에서는 text encoder만 학습하기 때문에 평균 학습 시간이 27.42분으로 짧다고 설명한다. 또 inference time도 빠르다.

LUOR inference time: 10.1ms
CLIP inference time: 10.6ms
CLIP+GPT method: 17.64s

CLIP+GPT 방식은 먼저 CLIP으로 object category를 예측하고, 다시 GPT-4에게 어떤 물체가 맞는지 물어보는 구조다. 이 방식은 느리고 비용도 든다.

반면 LUOR는 target object를 직접 embedding similarity로 고른다. 그래서 빠르다.

내가 여기서 중요하게 본 건 이것이다.

실제 로봇에서는 성능뿐 아니라 inference time도 중요하다.

로봇은 실시간으로 판단해야 한다. 모든 판단을 큰 LLM API에 맡기면 속도와 비용 면에서 부담이 커진다.

LUOR의 Classification 성능 보존

LUOR는 CLIP text encoder를 fine-tuning하기 때문에, 기존 CLIP의 일반적인 분류 능력이 망가질 수 있다는 걱정이 있다.

논문은 이를 확인하기 위해 classification 성능도 비교한다.

ImageNet
CLIP: 68.07%
LUOR: 66.63%

ObjectNet
CLIP: 47.08%
LUOR: 47.51%

ImageNet에서는 LUOR가 약간 낮아지고, ObjectNet에서는 오히려 조금 높다. 큰 차이는 아니다.

즉, LUOR는 object retrieval task에 맞게 text encoder를 조정하면서도, CLIP의 task-agnostic 특성을 어느 정도 유지한다.

이 점이 중요하다. 특정 task 성능을 올리려고 모델의 일반성이 크게 무너지면 실제 로봇에는 위험할 수 있다. LUOR는 그 균형을 비교적 잘 잡으려 한다.

LUOR의 실제 로봇 실험

LUOR는 실제 Franka Panda robot으로도 실험한다.

구성은 다음과 같다.

Robot: 7-DoF Franka Panda
Camera: D435 RealSense
Gripper: parallel jaw gripper

로봇은 12개 object category 중 5개를 랜덤으로 배치한 환경에서 명령을 받고, target object를 찾고, grasp를 수행한다.

결과는 다음과 같다.

Explicit command
Retrieval: 20/20
Plan: 18/20
Execution: 16/20

Implicit command
Retrieval: 19/20
Plan: 18/20
Execution: 15/20

이 결과에서 중요한 건 단계별로 성공률이 나뉜다는 점이다.

Retrieval 성공
→ target object를 잘 찾음

Plan 성공
→ object retrieval부터 plan module까지 성공

Execution 성공
→ 전체 시스템이 실제 grasp까지 성공

즉, object retrieval이 잘 되어도 최종 execution은 실패할 수 있다. 이건 로봇 시스템에서 항상 중요하다.

언어 이해 성공
→ 물체 선택 성공
→ grasp pose 성공
→ 실제 실행 성공

각 단계가 모두 연결되어야 최종 task가 성공한다.

LUOR의 한계

LUOR도 한계가 있다.

1. 후보 object crop이 필요하다

LUOR는 여러 object 후보 이미지 중에서 target object를 고른다. 따라서 object detection이 먼저 잘 되어야 한다.

만약 MTD가 물체를 놓치면 LUOR도 그 물체를 고를 수 없다.

2. Implicit command가 verb-object pair에 의존한다

LUOR는 affordance를 잘 다루지만, 학습 데이터는 verb-object pair 기반이다. 따라서 훨씬 복잡한 상황 추론까지 바로 해결한다고 보기는 어렵다.

예를 들어 이런 명령은 더 어렵다.

방금 쏟은 걸 치울 수 있는 걸 줘.
손에 묻은 걸 닦을 만한 걸 줘.
아이에게 위험하지 않은 걸로 줘.

이런 명령은 단순 verb-object matching을 넘어 context, safety, user state까지 봐야 한다.

3. Grasping은 4-DoF 중심이다

LUOR는 MTD를 통해 4-DoF grasp pose를 다룬다. 복잡한 6-DoF manipulation이나 cluttered scene에서의 정교한 grasp planning까지 다루는 것은 아니다.

그래도 object retrieval과 grasp pose detection을 연결했다는 점에서 의미가 있다.

LUOR에서 내가 가져간 핵심

LUOR에서 내가 가장 중요하게 본 건 이것이다.

로봇은 사람이 말한 단어를 그대로 찾는 것이 아니라, 사용자의 의도와 물체의 용도를 연결해야 한다.

사람은 항상 정확한 물체 이름을 말하지 않는다. 오히려 실제 생활에서는 이런 식의 명령이 더 자연스럽다.

먹을 것 줘.
닦을 것 줘.
자를 것 줘.
쓸 것 줘.
마실 때 쓸 것 줘.

이걸 이해하려면 object name grounding만으로는 부족하다. affordance grounding이 필요하다.

VLA 관점으로 보면 LUOR는 action 이전의 target grounding 문제와 연결된다.

language
→ intended function
→ target object
→ grasp pose
→ action

내 프로젝트에서도 이 흐름은 중요하다. 단순히 “빨간 컵”처럼 명확한 명령만 다루면 쉬울 수 있다. 하지만 실제 로봇은 “마실 것 좀 줘”, “닦을 것 좀 줘” 같은 표현도 다뤄야 한다.

LUOR 결론 한 줄

LUOR는 explicit object name을 찾는 수준을 넘어, 사용자의 암시적 의도와 object affordance를 연결해 target retrieval과 grasping으로 이어주는 논문이다.

세 논문을 같이 보면 보이는 흐름

TASMap, GTTP, LUOR를 같이 보면 하나의 큰 방향이 보인다.

TASMap
→ 장면을 보고 필요한 task를 지도에 저장한다.

GTTP
→ 명령과 scene graph history를 보고 다음 subgoal을 계획한다.

LUOR
→ 명령이 가리키는 target object를 찾고 grasp pose를 연결한다.

이걸 로봇 시스템으로 다시 쓰면 이런 구조가 된다.

[Scene Understanding]
TASMap
- 물체 상태 파악
- task-significant vector 생성
- contextual / spatial task proposal

[Task Planning]
GTTP
- instruction + scene graph history 입력
- next subgoal 예측
- feasible subgoal 선택

[Object Retrieval & Grasping]
LUOR
- explicit / implicit command 이해
- target object retrieval
- grasp pose detection
- robot execution

이 흐름은 내가 관심 있는 VLA 프로젝트와도 직접 연결된다.

VLA 관점에서 다시 보기

VLA는 Vision-Language-Action이다. 말 그대로 시각 정보와 언어 정보를 받아 행동으로 연결하는 모델이다.

하지만 세 논문을 보면, action을 바로 출력하기 전에 거쳐야 하는 중간 단계가 많다는 걸 알 수 있다.

Vision
→ scene parsing
→ object state understanding
→ task-aware representation
→ instruction grounding
→ subgoal planning
→ object retrieval
→ grasp execution

RT-2나 OpenVLA 같은 모델은 end-to-end action 출력에 가까운 방향을 보여준다. 하지만 실제 로봇 시스템에서는 이런 중간 표현이 매우 중요하다.

내가 지금 관심 있는 것도 결국 이 지점이다.

이미지를 보고
자연어 지시를 이해하고
어떤 물체가 대상인지 고르고
다음 행동 목표를 정하고
불확실하면 멈추거나 확인하는 구조

TASMap, GTTP, LUOR는 각각 이 구조의 한 부분을 잘 보여준다.

세 논문의 역할을 내 프로젝트 구조로 바꿔보면

내가 만들고 싶은 ScenePlan 또는 VLA 탑다운 프로젝트에 적용한다면 이런 식으로 나눌 수 있다.

1. Scene Representation Layer
- RGB image
- object candidates
- object state
- spatial relation
- task relevance

참고 논문: TASMap

2. Subgoal Planning Layer
- instruction
- scene graph
- state history
- feasible action set
- next subgoal prediction

참고 논문: GTTP

3. Target Grounding / Retrieval Layer
- explicit command
- implicit command
- affordance matching
- target object selection
- confidence score

참고 논문: LUOR

4. Execution Interface
- grasp pose
- action adapter
- simulator or real robot execution
- failure logging

이렇게 보면 내가 당장 OpenVLA 같은 거대한 모델을 완전히 구현하지 않아도 된다. 먼저 action 이전의 판단 구조를 만들 수 있다.

내가 이 세 논문에서 남긴 핵심

1. 로봇은 명령만 기다리면 부족하다

TASMap은 로봇이 명령 없이도 필요한 task를 제안할 수 있어야 한다고 본다. 이건 홈 로봇 관점에서 매우 중요하다.

진짜 유용한 로봇은 사람이 모든 걸 말해줘야 움직이는 로봇이 아니다. 장면을 보고 “지금 무엇이 필요한지” 어느 정도 판단할 수 있어야 한다.

2. Task planning은 LLM만으로 끝나지 않는다

GTTP는 LLM의 한계를 정확히 짚는다. LLM은 상식과 언어 이해에는 강하지만, 실제 환경 상태와 실행 가능성을 항상 잘 반영하는 것은 아니다.

그래서 scene graph, GNN, Transformer, feasible subgoal selector 같은 구조가 필요하다.

내가 보기엔 이게 굉장히 현실적이다. LLM을 planner로 바로 쓰는 것보다, LLM을 데이터 생성과 보조 추론에 쓰고, 실제 planner는 환경 구조를 보는 모델로 만드는 방향이 설득력 있다.

3. 사람은 항상 물체 이름을 정확히 말하지 않는다

LUOR는 이걸 잘 보여준다.

사람은 “paper towel을 줘”라고 말할 수도 있지만, 실제로는 “닦을 것 좀 줘”라고 말할 가능성이 높다. 로봇은 object name뿐 아니라 object function을 이해해야 한다.

이건 VLA에서 grounding 문제를 더 어렵게 만든다.

명시적 grounding
→ "apple"이라는 단어와 apple object 연결

암시적 grounding
→ "something to eat"과 apple object 연결

실제 로봇은 두 번째를 할 수 있어야 한다.

4. 단계별 실패를 기록해야 한다

세 논문 모두 직접적으로 또는 간접적으로 보여주는 점이 있다. 로봇 시스템은 한 단계만 잘한다고 성공하지 않는다.

scene understanding 실패
→ task proposal 실패

scene graph 오류
→ subgoal planning 실패

object retrieval 실패
→ grasp 대상 오류

grasp pose 오류
→ execution 실패

그래서 내 프로젝트에서도 단순히 최종 성공/실패만 보면 안 된다. 어디서 실패했는지를 기록해야 한다.

target grounding failure
task assignment failure
subgoal planning failure
affordance mismatch
low confidence but action selected
execution infeasible

이렇게 실패를 나눠야 연구형 프로젝트가 된다.

내 탑다운 프로젝트에 적용한다면

이 세 논문을 보고 내가 잡을 수 있는 프로젝트 방향은 다음과 같다.

목표:
자연어 지시와 장면 정보를 입력받아,
로봇이 어떤 물체를 대상으로 삼아야 하는지,
어떤 subgoal을 선택해야 하는지,
불확실하면 멈출 수 있는지 판단하는 scene-aware task planning 시스템 만들기

초기 버전은 이렇게 작게 시작할 수 있다.

Input
- single RGB image
- natural language instruction
- candidate objects
- object state / relation metadata

Output
- selected target object
- selected subgoal
- confidence score
- abstain 여부
- reasoning log

여기서 각 논문의 아이디어를 이렇게 가져올 수 있다.

TASMap에서 가져올 것
- object state 기반 task relevance
- task-significant vector 아이디어
- context에 따라 task 우선순위가 바뀐다는 관점

GTTP에서 가져올 것
- scene graph 기반 planning
- instruction + state history를 함께 보는 구조
- feasible subgoal selector 아이디어

LUOR에서 가져올 것
- explicit / implicit command 구분
- affordance 기반 target retrieval
- object retrieval과 grasp/action을 분리하는 구조

초기 구현에서는 실제 로봇 제어까지 가지 않아도 된다. 먼저 이런 구조를 만들 수 있다.

scene.json
→ objects, states, relations

instruction.txt
→ "Give me something to wipe"

grounding module
→ towel 선택

subgoal module
→ PREPARE_PICK 선택

confidence module
→ confidence 0.82

logger
→ 왜 towel을 골랐는지 기록

이렇게 하면 작은 toy project라도 연구 방향이 분명해진다.

세 논문을 한 문장으로 다시 정리하면

TASMap은 로봇이 장면 속에서 필요한 일을 알아차리게 만들고, GTTP는 그 일을 수행하기 위한 다음 subgoal을 계획하게 만들고, LUOR는 사람의 명령이 가리키는 실제 물체를 찾아 grasp로 연결하게 만든다.

조금 더 내 식으로 말하면 이렇다.

TASMap
→ 뭘 해야 하는지 알아차리는 지도

GTTP
→ 어떻게 해야 하는지 순서를 정하는 planner

LUOR
→ 무엇을 대상으로 해야 하는지 찾아주는 retriever

이 세 가지가 합쳐져야 로봇은 조금 더 실제 환경에 가까워진다.

결론 한 줄

로봇이 진짜 사람을 돕기 위해서는 단순히 명령을 action으로 바꾸는 것만으로는 부족하고, 장면을 task 관점으로 이해하고, 진행 상황에 맞게 계획하고, 사용자의 암시적 의도를 실제 물체와 연결할 수 있어야 한다.

TASMap, GTTP, LUOR는 각각 그 문제를 다른 각도에서 다룬다. 그래서 이 세 논문은 VLA를 공부할 때 action model 자체보다 그 이전 단계의 판단 구조를 이해하는 데 도움이 된다.

내가 앞으로 잡아야 할 방향도 조금 더 분명해졌다. 거대한 VLA 모델을 바로 따라 하려고 하기보다, 먼저 이런 질문에 답하는 작은 시스템을 만드는 것이 맞다.

로봇은 지금 무엇을 보고 있는가?
그 장면에서 어떤 일이 필요한가?
사용자의 말은 어떤 물체를 뜻하는가?
다음에 어떤 subgoal을 선택해야 하는가?
그 판단을 얼마나 확신할 수 있는가?
불확실하면 멈출 수 있는가?

결국 좋은 로봇 시스템은 action을 잘 내는 것만이 아니라, action을 내기 전에 충분히 잘 이해하고 판단하는 구조를 가져야 한다. 이 세 논문은 그 방향을 꽤 현실적으로 보여준다.

출처

• Daewon Choi, Hosung Lee, Soeun Hwang, Yoonseon Oh, Task-Aware Semantic Map: Autonomous Robot Task Assignment Beyond Commands, ICRA 2025.
• Soojin Jeong, Seongwan Byeon, Sangwoo Kim, HyeokJun Kwon, Yoonseon Oh, GNN-Transformer Task Planning Enhanced with Semantic-Driven Data Augmentation, AAAI 2025.
• Dongmin Yoon, Seonghun Cha, Yoonseon Oh, LUOR: A Framework for Language Understanding in Object Retrieval and Grasping, International Journal of Control, Automation, and Systems, 2025.

※ 이 글은 Peiqi Liu 외, 「OK-Robot: What Really Matters in Integrating Open-Knowledge Models for Robotics」를 읽고, 제 방식대로 다시 정리한 글입니다.
OK-Robot은 CLIP, OWL-ViT, Lang-SAM, AnyGrasp 같은 공개 데이터 기반 모델들을 조합해서, 새로운 집 환경에서 물체를 찾아 집고 원하는 위치에 놓는 Open-Knowledge 기반 로봇 시스템입니다.

한 줄 요약

OK-Robot은 하나의 거대한 로봇 모델을 새로 학습한 것이 아니라, 이미 공개된 시각-언어 모델과 로봇 모듈들을 잘 조립해서 실제 집 안에서 pick-and-drop을 수행한 시스템이다.

조금 더 쉽게 말하면 이렇다. RT-2나 OpenVLA는 “이미지와 자연어 명령을 보고 로봇 행동을 바로 출력하는 VLA 모델”에 가깝다. 반면 OK-Robot은 하나의 모델이 모든 걸 해결하려고 하지 않는다. 대신 집을 스캔하고, 물체를 찾고, 이동하고, 집고, 놓는 과정을 여러 모듈로 나눈다.

집 스캔
→ 물체 위치 찾기
→ 로봇이 이동하기
→ 물체 잡기
→ 목표 위치로 이동하기
→ 물체 내려놓기

이 논문의 핵심은 단순히 “성공률이 몇 퍼센트다”가 아니다. 중요한 건 이미 좋은 모델들이 많은데, 왜 로봇 시스템은 여전히 잘 안 될까?라는 질문이다. OK-Robot은 그 답을 “모델 하나의 성능”이 아니라 모듈을 어떻게 연결하느냐에서 찾는다.

Figure 1은 OK-Robot의 전체 메시지를 가장 잘 보여준다. 로봇이 방 안에서 사용자의 자연어 명령을 받고, 먼저 VoxelMap으로 물체 위치를 찾은 뒤, Lang-SAM과 AnyGrasp로 물체를 집고, 마지막으로 목표 위치에 내려놓는다. 이 그림을 보면 OK-Robot이 end-to-end VLA 모델이라기보다 여러 강한 모듈을 연결한 시스템이라는 점이 바로 보인다.

이 논문이 나온 이유

로봇 연구에서는 오래전부터 “집 안에서 사람을 도와주는 범용 로봇”을 꿈꿔왔다. 그런데 아직도 현실은 쉽지 않다. 실험실에서는 잘 되는 로봇이 실제 집에 들어가면 갑자기 약해진다. 집마다 구조가 다르고, 물건의 종류도 다르고, 조명도 다르고, 장애물도 많고, 사용자의 말도 매번 다르기 때문이다.

반면 시각-언어 모델 쪽은 빠르게 발전했다. CLIP 같은 모델은 이미지와 텍스트를 연결할 수 있고, OWL-ViT 같은 모델은 자연어로 물체를 찾을 수 있고, SAM 계열은 물체 영역을 꽤 잘 나눌 수 있다. 로봇 쪽에서도 navigation, grasping 같은 기본 기술은 어느 정도 성숙했다.

그럼 자연스럽게 이런 질문이 생긴다.

“시각-언어 모델도 좋아졌고, 로봇 모듈도 좋아졌는데, 왜 실제 집 안 로봇은 아직도 어렵지?”

OK-Robot은 이 질문에서 출발한다. 논문이 보는 문제는 아주 현실적이다. 각각의 모듈은 꽤 잘할 수 있다. 하지만 실제 로봇 시스템은 하나의 모듈만 잘한다고 성공하지 않는다. 물체를 잘못 찾으면 이후 모든 단계가 틀어진다. 로봇이 물체 근처까지 갔지만 팔이 닿지 않으면 실패한다. 물체는 찾았지만 grasp가 불안정하면 떨어뜨린다. 목표 위치를 잘 찾았지만 내려놓는 높이가 이상하면 부딪힌다.

즉, 실제 로봇에서는 작은 오차들이 단계마다 쌓인다. 이 논문은 그 지점을 아주 중요하게 본다.

물체 찾기에서 작은 실패
→ 이동 위치가 조금 어긋남
→ 집기 자세가 불안정해짐
→ 물체를 놓는 단계까지 실패

그래서 OK-Robot의 핵심은 “엄청난 새 모델 하나”가 아니라 이미 있는 open-knowledge 모델들을 어떻게 실제 로봇 시스템으로 조립할 것인가에 있다.

OK-Robot이 푸는 문제

OK-Robot이 푸는 문제는 한 문장으로 정리하면 이렇다.

“새로운 집 환경에서 추가 학습 없이, 사용자의 자연어 명령만으로 물체를 찾아 집고 원하는 위치에 놓을 수 있을까?”

여기서 중요한 조건은 세 가지다.

1. 새로운 집 환경이어야 한다

OK-Robot은 미리 학습된 특정 실험실 환경에서만 동작하는 시스템이 아니다. 논문은 실제 10개의 집 환경에서 실험한다. 즉, 로봇이 처음 보는 방, 처음 보는 물체, 처음 보는 배치에서 작동해야 한다.

이 점이 중요하다. 로봇이 연구실 책상 위에서만 잘하는 건 상대적으로 쉽다. 하지만 실제 집은 훨씬 지저분하고 예측하기 어렵다. 그래서 이 논문은 “home environment”라는 현실적인 환경을 중요하게 다룬다.

2. 자연어로 물체와 위치를 지정할 수 있어야 한다

사용자는 로봇에게 좌표를 주지 않는다. 이런 식으로 말한다.

Move the soda can to the box.
Move the purple shampoo to the red bag.
Move the white meds box to the trash bin.
Move the Takis on the desk to the nightstand.

로봇은 여기서 soda can, box, purple shampoo, red bag, white meds box, trash bin, Takis, nightstand 같은 표현을 이해해야 한다. 즉, 자연어를 실제 공간 속 물체와 연결해야 한다.

3. 추가 학습 없이 작동해야 한다

OK-Robot은 새로운 집마다 데이터를 모아서 다시 학습하지 않는다. 논문은 이를 zero-shot deployment에 가깝게 본다. 새로운 환경에 들어가면 iPhone으로 방을 스캔하고, 그 스캔을 기반으로 VoxelMap을 만든 뒤 바로 동작한다.

이 지점이 OK-Robot의 실용적인 강점이다. 매번 새로운 집마다 로봇 데이터를 수집하고 fine-tuning해야 한다면 현실성이 떨어진다. OK-Robot은 이미 공개된 모델과 간단한 스캔만으로 새로운 집에 적응하려고 한다.

Open Knowledge가 무엇인가

이 논문에서 말하는 Open Knowledge는 단순히 “오픈소스 코드”만 의미하지 않는다. 논문에서는 Open Knowledge를 공개적으로 이용 가능한 대규모 데이터로 학습된 모델들이 가진 지식에 가깝게 사용한다.

예를 들어 CLIP은 이미지와 텍스트를 연결하는 지식을 갖고 있다. OWL-ViT는 자연어로 물체를 찾는 능력을 갖고 있다. SAM이나 Lang-SAM은 특정 물체 영역을 분할하는 능력을 갖고 있다. AnyGrasp는 다양한 물체에 대한 grasp pose를 생성하는 능력을 갖고 있다.

OK-Robot은 이런 모델들을 새로 학습하지 않고 조합한다.

CLIP
→ 언어와 이미지 의미 연결

OWL-ViT
→ 자연어 기반 object detection

SAM / Lang-SAM
→ 물체 영역 segmentation

AnyGrasp
→ RGB-D 기반 grasp 후보 생성

A* Navigation
→ 로봇 이동 경로 계획

Drop heuristic
→ 물체를 목표 위치에 내려놓기

이 논문이 흥미로운 이유는 여기에 있다. 요즘 로봇 논문은 점점 거대한 end-to-end 모델을 이야기한다. 하지만 OK-Robot은 반대로 묻는다.

“이미 좋은 모듈이 있다면, 그것들을 잘 연결하는 것만으로도 실제 집 안 로봇이 어느 정도 가능하지 않을까?”

OK-Robot의 전체 구조

OK-Robot의 전체 구조는 크게 세 단계로 볼 수 있다.

1. Open-vocabulary object navigation
→ 자연어로 지정한 물체의 위치를 찾고, 로봇이 그 근처까지 이동한다.

2. Open-vocabulary RGB-D grasping
→ 로봇이 본 RGB-D 이미지에서 목표 물체를 분할하고, 가능한 grasp 후보 중 실행할 grasp를 고른다.

3. Dropping heuristic
→ 집은 물체를 목표 위치로 이동한 뒤, 상자, 가방, 침대 옆 협탁, 쓰레기통 같은 위치에 내려놓는다.

여기서 중요한 건 “open-vocabulary”다. 즉, 미리 정해진 몇 개의 물체만 다루는 게 아니라, 사용자가 자연어로 말한 다양한 물체와 위치를 다루려고 한다.

Figure 1은 이 세 단계를 실제 예시로 보여준다. 사용자가 move the Takis on the desk to the nightstand라고 말하면, 시스템은 먼저 Takis on the desk를 찾아 이동 계획을 만들고, 이후 Takis를 segmentation과 grasping으로 집은 뒤, 마지막에 nightstand 위치에 내려놓는다.

내가 이 그림에서 가져간 핵심은 이거다.

OK-Robot은 로봇 지능을 하나의 거대한 모델에 몰아넣지 않는다. 대신 문제를 나눠서, 각 단계에 가장 잘 맞는 모델을 붙인다.

1단계: 집을 스캔하고 VoxelMap 만들기

OK-Robot은 새로운 집에 들어가면 먼저 방을 스캔한다. 이때 특별한 고가 장비를 쓰는 것이 아니라 iPhone과 Record3D 앱을 사용한다. 사용자가 방을 1분 이내로 스캔하면, RGB-D 이미지와 카메라 pose 정보가 만들어진다.

이후 시스템은 이 스캔 데이터를 바탕으로 VoxelMap이라는 semantic memory를 만든다. 쉽게 말하면 방 안을 3D 격자로 나누고, 각 위치에 “이 근처에 어떤 물체가 있을 가능성이 높은지”를 저장하는 방식이다.

iPhone으로 방 스캔
→ RGB-D 이미지 + camera pose 획득
→ open-vocabulary detector로 물체 후보 찾기
→ SAM으로 물체 mask 정제
→ CLIP embedding 저장
→ 3D 공간에 voxel 단위 semantic memory 생성

여기서 VoxelMap이 중요한 이유는 로봇이 자연어 명령을 실제 위치로 바꿔야 하기 때문이다. 사용자가 “brown hat”이라고 말하면 로봇은 그 단어를 CLIP text embedding으로 바꾸고, VoxelMap 안에서 가장 비슷한 semantic embedding을 가진 위치를 찾는다.

Figure 2(a)는 VoxelMap이 어떤 역할을 하는지 보여준다. 방 안의 bed, brown hat, plant, red body spray 같은 물체가 3D 공간 위에 자연어 label로 연결되어 있다. 즉, 로봇은 단순히 픽셀 이미지만 보는 것이 아니라, 집 안 공간을 “언어로 검색 가능한 3D 메모리”처럼 갖게 된다.

내 식으로 이해하면 VoxelMap은 이런 역할이다.

“집 안을 로봇이 검색할 수 있는 3D 의미 지도처럼 만드는 것.”

2단계: 자연어로 물체 위치 찾기

VoxelMap이 만들어지면, 사용자는 자연어로 명령을 줄 수 있다.

Move the brown hat to the bed.
Move the purple shampoo to the red bag.
Move the soda can to the box.

이때 로봇은 먼저 목표 물체의 위치를 찾아야 한다. 예를 들어 brown hat이라는 query가 들어오면, CLIP text encoder로 이 문장을 embedding으로 바꾸고, VoxelMap 안의 voxel embedding들과 비교한다. 가장 비슷한 위치가 brown hat이 있을 가능성이 높은 위치가 된다.

조금 더 쉽게 말하면 이렇다.

사용자 명령: brown hat
→ CLIP text embedding
→ VoxelMap 안의 semantic embedding과 비교
→ 가장 비슷한 3D 위치 선택
→ 그 위치로 이동 계획 생성

이 과정이 중요한 이유는 로봇이 좌표를 직접 받지 않기 때문이다. 사람은 “저기 있는 갈색 모자”라고 말하지, “x=1.2, y=0.7 위치로 가라”고 말하지 않는다. 그래서 자연어를 실제 공간 좌표로 바꾸는 이 단계가 OK-Robot의 핵심이다.

3단계: 로봇이 물체 근처까지 이동하기

물체 위치를 찾았다고 끝이 아니다. 로봇은 그 물체를 잡을 수 있는 위치까지 이동해야 한다. 여기서 단순히 물체 바로 앞까지 가는 것만으로는 부족하다.

로봇이 물체를 집으려면 세 가지 조건이 필요하다.

1. 물체와 충분히 가까워야 한다.
2. 로봇 팔과 그리퍼가 움직일 공간이 있어야 한다.
3. 주변 장애물과 충돌하지 않아야 한다.

OK-Robot은 이를 위해 VoxelMap과 obstacle map을 만들고 A* 알고리즘을 사용한다. A*는 경로 탐색 알고리즘이다. 쉽게 말하면, 로봇이 갈 수 있는 공간과 갈 수 없는 공간을 나눈 뒤, 시작 위치에서 목표 위치까지 안전한 길을 찾는 방식이다. cabulary navigation planning. 로봇이 시작점에서 brown hat 근처로 이동하는 경로가 표시됨]

Figure 2(b)는 로봇이 실제로 어떻게 이동 경로를 계획하는지 보여준다. 목표 물체는 brown hat이고, 로봇은 침대와 여러 장애물을 피해 이동해야 한다. 이 그림에서 중요한 건 로봇이 단순히 목표 좌표로 직선 이동하지 않는다는 점이다. 실제 집에는 침대, 책상, 가방, 벽 같은 장애물이 있기 때문에 안전한 경로 계획이 필요하다.

내가 여기서 느낀 핵심은 이거다.

VLM이 물체를 찾아줘도, 로봇이 그 물체를 잡을 수 있는 위치까지 안전하게 가는 건 또 다른 문제다.

이게 로봇 시스템이 어려운 이유다. 인식, 이동, 조작이 모두 연결되어야 한다.

4단계: AnyGrasp로 grasp 후보 만들기

로봇이 물체 근처에 도착하면 이제 물체를 집어야 한다. OK-Robot은 이 단계에서 AnyGrasp를 사용한다. AnyGrasp는 RGB-D 이미지와 point cloud를 보고 가능한 grasp 후보들을 생성하는 모델이다.

하지만 AnyGrasp가 만든 grasp 후보가 모두 좋은 것은 아니다. 어떤 후보는 목표 물체가 아닌 주변 물체를 잡을 수도 있고, 어떤 후보는 로봇의 팔 구조상 실행하기 어려울 수도 있다. 그래서 OK-Robot은 grasp 후보를 한 번 더 걸러야 한다.

전체 흐름은 이렇다.

로봇 head camera로 RGB-D 이미지 촬영
→ depth image를 point cloud로 변환
→ AnyGrasp가 여러 grasp 후보 생성
→ Lang-SAM이 목표 물체 mask 생성
→ grasp point가 목표 mask 안에 들어가는 후보만 필터링
→ 가장 실행 가능성이 높은 grasp 선택

Figure 3은 OK-Robot의 grasping 과정을 아주 직관적으로 보여준다. 첫 번째 열은 로봇이 실제로 보는 RGB 이미지다. 두 번째 열에서는 AnyGrasp가 가능한 grasp 후보를 많이 만든다. 세 번째 열에서는 Lang-SAM이 사용자의 언어 query에 맞는 물체 mask를 만든다. 네 번째 열에서는 그 mask 안에 들어가는 grasp만 남긴다. 마지막 열에서는 실제로 실행할 최종 grasp가 선택된다.

이 부분이 꽤 중요하다. AnyGrasp는 “잡을 수 있을 것 같은 위치”를 많이 만든다. 하지만 “사용자가 말한 바로 그 물체”를 잡아야 한다. 그래서 Lang-SAM이 목표 물체를 분할하고, AnyGrasp 후보를 그 mask 기준으로 필터링한다.

내 식으로 정리하면 이렇다.

AnyGrasp
→ 어디를 잡을 수 있을지 제안한다.

Lang-SAM
→ 사용자가 말한 물체가 이미지에서 어디인지 알려준다.

Grasp filtering
→ 그 물체 위에 있는 grasp 후보만 남긴다.

즉, OK-Robot의 grasping은 “잡기 모델” 하나로 끝나지 않는다. 언어 기반 segmentation과 grasp generation을 조합해서 open-vocabulary grasping을 만든다.

5단계: Drop heuristic으로 목표 위치에 내려놓기

물체를 집었다면 이제 목표 위치에 내려놓아야 한다. 이 단계도 생각보다 어렵다. 단순히 평평한 테이블 위에 놓는다면 쉬울 수 있다. 하지만 실제 집에서는 목표 위치가 상자, 가방, 침대 옆 협탁, 쓰레기통, 세면대처럼 다양하다.

OK-Robot은 이를 위해 Drop heuristic을 사용한다. 목표 위치를 Lang-SAM으로 segmentation하고, 그 point cloud를 기준으로 물체를 내려놓을 위치와 높이를 계산한다. 논문에서는 특히 상자나 가방처럼 안쪽이 들어간 concave object도 다루려고 한다.

쉽게 말하면 이런 방식이다.

목표 위치를 자연어 query로 segmentation
→ segmented point cloud 정렬
→ 목표 영역의 중앙 근처 위치 계산
→ 충돌을 피하기 위해 약간 위쪽 높이 선택
→ 그 위치로 gripper를 이동
→ gripper를 열어 물체를 내려놓음

이 단계는 learning model이라기보다는 heuristic에 가깝다. 즉, 데이터를 많이 학습해서 내려놓는 위치를 예측하는 것이 아니라, point cloud의 형태를 보고 규칙 기반으로 내려놓는 위치를 정한다.

내가 보기엔 이 부분이 OK-Robot의 시스템적 성격을 잘 보여준다. 모든 것을 신경망으로 해결하려 하지 않는다. 학습 모델이 잘하는 부분은 학습 모델을 쓰고, 간단한 규칙으로 충분한 부분은 heuristic을 쓴다.

실제 집에서 배포하는 과정

OK-Robot은 새로운 집에서 바로 작동하기 위해 다음 과정을 거친다.

1. 새로운 방에 로봇을 가져간다.
2. iPhone으로 방을 1분 이내로 스캔한다.
3. 5분 이내로 VoxelMap을 만든다.
4. 로봇을 시작 위치에 둔다.
5. 사용자가 pick-and-drop 명령을 준다.
6. 로봇이 물체를 찾아 이동하고, 집고, 목표 위치에 내려놓는다.

논문에서는 새로운 환경에 도착한 뒤 첫 pick-and-drop task를 시작하기까지 평균 10분 이내가 걸린다고 설명한다. 이건 꽤 실용적인 설정이다. 물론 완전한 제품 수준은 아니지만, 매번 새 환경에서 재학습하지 않고도 실험을 시작할 수 있다는 점에서 의미가 있다.

다만 중요한 한계도 있다. OK-Robot은 error detection이나 correction을 적극적으로 구현하지 않는다. 즉, 상태 머신은 거의 선형 구조다.

navigate to object
→ grasp object
→ navigate to goal
→ drop object

중간에 실패하면 다시 판단하고 복구하는 기능이 약하다. 이 한계는 뒤에서 실패 분석과도 연결된다.

대표 실험 1: 실제 집 10곳에서의 pick-and-drop

OK-Robot의 가장 중요한 실험은 실제 집 10곳에서 진행한 home experiment다. 논문은 총 171개의 pick-and-drop 실험을 수행했다고 설명한다. 여기서 로봇은 각 집에서 임의로 선택된 물체를 집고, 지정된 위치에 내려놓아야 한다.

결과는 다음과 같다.

새로운 실제 집 환경 전체 성공률: 58.5%
정리된 cleaner / uncluttered 환경 성공률: 82.4%

이 수치만 보면 “58.5%면 아직 낮은 것 아닌가?”라고 볼 수 있다. 맞다. 아직 완벽하지 않다. 하지만 중요한 건 이 실험이 완전히 새로운 집, 새로운 물체, 복잡한 실제 환경에서 이루어졌다는 점이다. 논문은 NeurIPS 2023 OVMM challenge의 우승 솔루션 성공률이 33%였다는 점도 언급한다. 그 기준에서 보면 OK-Robot의 58.5%는 꽤 의미 있는 개선이다.

Figure 4는 OK-Robot이 어디서 성공하고 어디서 실패했는지 보여주는 핵심 그림이다. 전체 trial이 navigation success와 failure로 나뉘고, 이후 manipulation success와 failure, placing success와 failure로 이어진다. 이 그림을 보면 OK-Robot의 실패가 한 지점에서만 발생하는 게 아니라 navigation, manipulation, placing 단계마다 쌓인다는 것을 볼 수 있다.

내가 이 결과에서 가장 중요하게 본 건 성공률 자체보다 실패의 구조다.

navigation이 실패하면 뒤 단계는 시작도 못 한다.
navigation이 성공해도 manipulation이 실패할 수 있다.
manipulation이 성공해도 placing에서 실패할 수 있다.

즉, 로봇 시스템은 각 모듈의 성공률이 곱셈처럼 누적된다. 이게 논문에서 말하는 multiplicative error accumulation과 연결된다. 각 모듈이 80% 이상 잘해도, 전체 시스템 성공률은 60% 아래로 떨어질 수 있다.

대표 실험 2: 어떤 모듈이 더 좋은가

OK-Robot은 단순히 하나의 시스템만 보여주지 않는다. navigation과 grasping에 들어가는 여러 대안 모듈도 비교한다.

semantic memory / navigation 쪽에서는 VoxelMap, CLIP-Fields, USA-Net 등을 비교한다. grasping 쪽에서는 AnyGrasp, OpenGraspness, Contact-GraspNet, top-down grasp heuristic 등을 비교한다.

Figure 5는 어떤 모듈 조합이 더 안정적인지 보여준다. semantic memory 쪽에서는 VoxelMap이 다른 방법보다 약간 더 좋고 variance가 낮다. 즉, 엄청나게 압도적이라기보다는 더 안정적인 선택에 가깝다. 반면 grasping 쪽에서는 AnyGrasp가 다른 grasping 방법보다 훨씬 강하게 나온다.

여기서 중요한 해석은 두 가지다.

첫 번째, semantic memory는 성능 차이도 중요하지만 안정성이 중요하다. 실제 집에서는 환경이 매번 다르기 때문에 평균 성능만 높고 variance가 크면 위험하다.

두 번째, manipulation은 여전히 어렵다. AnyGrasp가 강하게 나오지만, 그럼에도 전체 시스템에서는 grasping과 manipulation failure가 큰 비중을 차지한다. 즉, 좋은 grasping model을 붙여도 실제 로봇 팔, 카메라, 장애물, 물체 형태까지 고려하면 여전히 실패가 많다.

내 식으로 정리하면 이렇다.

물체를 “찾는 것”도 어렵지만, 실제로 “집는 것”은 더 어렵다.

대표 실험 3: 집이 지저분하면 얼마나 어려워지는가

실제 집은 실험실처럼 깨끗하지 않다. 물체가 겹쳐 있고, 비슷하게 생긴 물건이 많고, 목표 물체가 팔이 닿기 어려운 위치에 있을 수 있다. 그래서 OK-Robot 논문은 cleanup level에 따른 성능 변화를 분석한다.

논문에서는 환경을 점점 정리하면서 성능이 어떻게 변하는지 본다.

cleanup 없음
→ 실제 집에 가까운 자연스러운 상태

cleanup 낮음
→ 일부 애매한 물체나 방해 요소 제거

cleanup 높음
→ 더 정리되고 접근 가능한 상태

Figure 6은 환경이 정리될수록 성공률이 올라가는 모습을 보여준다. cleanup이 없는 상태에서는 성공률이 58% 수준이고, cleanup level이 올라가면 71%, 82% 수준까지 증가한다. 동시에 navigation failure와 manipulation failure는 줄어든다.

이 결과는 굉장히 현실적이다. 로봇이 못하는 이유가 꼭 모델이 멍청해서만은 아니다. 집 환경 자체가 어렵다. 물체가 너무 붙어 있거나, 이름이 애매하거나, 잡기 어려운 방향에 있거나, 팔이 닿기 어려운 곳에 있으면 실패한다.

이 부분은 VLA 연구를 볼 때도 중요하다. 모델이 아무리 좋아도 실제 환경의 clutter, ambiguity, affordance 문제를 무시하면 성공률은 떨어진다.

clutter
→ 물체가 가려지거나 grasp가 어려워짐

ambiguity
→ 자연어 query가 의도한 물체와 다르게 매칭됨

affordance
→ 물체는 찾았지만 로봇이 실제로 집거나 접근하기 어려움

내가 이 논문에서 가장 현실적이라고 느낀 부분이 바로 여기다. 로봇은 단순히 “인식 성능”만으로 결정되지 않는다. 환경이 조금만 정리되어도 성공률이 크게 바뀐다.

실패 분석 1: 자연어 query가 애매하면 물체를 잘못 찾는다

OK-Robot의 중요한 실패 원인 중 하나는 자연어 query다. 사용자가 말한 단어가 semantic memory에서 의도한 물체를 정확히 찾아야 하는데, 이게 생각보다 어렵다.

Figure 7은 query 표현이 조금만 달라져도 결과가 달라질 수 있음을 보여준다. 예를 들어 사람이 보기에는 비슷한 물체 설명인데, 모델은 어떤 표현에는 잘 반응하고 어떤 표현에는 실패할 수 있다. 논문은 이를 LLM의 incantation 문제와 비슷하게 설명한다. 즉, 어떤 표현을 쓰느냐에 따라 모델이 갑자기 잘되거나 안 될 수 있다.

이건 굉장히 중요한 문제다. 실제 사용자는 모델이 좋아하는 정확한 단어를 골라서 말하지 않는다. 그냥 자기가 편한 방식으로 말한다.

저기 초록색 약통 옮겨줘.
저 작은 통 옮겨줘.
연고 같은 거 저기로 옮겨줘.
저 병을 가방에 넣어줘.

사람에게는 비슷한 말일 수 있지만, semantic memory 입장에서는 완전히 다른 query가 될 수 있다. 그래서 논문은 user confirmation 같은 상호작용이 필요하다고 말한다. 예를 들어 로봇이 “이 물체를 말하는 게 맞나요?”라고 확인하면 많은 실패를 줄일 수 있다.

내 프로젝트 관점에서도 이 부분은 중요하다. 내가 관심 있는 grounding / confidence / abstain 구조와 바로 연결된다.

query가 애매하다
→ confidence를 낮춘다
→ 바로 행동하지 않는다
→ 사용자에게 확인한다

이게 실제 로봇에서는 안전하고 현실적인 방향이다.

실패 분석 2: grasping은 여전히 어렵다

두 번째 큰 실패 원인은 grasping이다. AnyGrasp가 강력하다고 해도, 실제 집 안에서 모든 물체를 안정적으로 집기는 어렵다. 투명한 물체, 높은 카운터, 원통형 물체, 작은 물체, 둥근 물체, 납작한 물체에서 grasp가 실패하는 사례]

Figure 8은 OK-Robot이 어떤 물체에서 실패하는지 보여준다. 투명한 물체는 depth가 잘 나오지 않아 point cloud가 부정확해질 수 있다. 높은 카운터 위 물체는 로봇 팔이 닿기 어려울 수 있다. 원통형 물체는 대각선으로 잡으면 불안정하다. 작은 물체는 calibration error에 취약하다. 납작한 물체는 테이블과 충돌하기 쉽다.

이 그림은 로봇 manipulation이 왜 어려운지 잘 보여준다. 사람에게는 “그냥 집으면 되지”처럼 보이는 물체도 로봇에게는 어렵다.

투명한 물체
→ depth sensor가 정확히 인식하기 어려움

작은 물체
→ 손-눈 calibration 오차에 취약함

납작한 물체
→ 그리퍼가 테이블과 충돌하기 쉬움

둥근 물체
→ 정확히 중심을 잡지 못하면 미끄러짐

너무 무거운 물체
→ 로봇 팔 payload 한계에 걸림

이건 VLA 논문을 읽을 때도 꼭 기억해야 한다. 모델이 의미를 이해해도, 실제 물체를 잡는 건 물리 문제다. 의미 grounding과 physical manipulation은 연결되어 있지만 같은 문제가 아니다.

실패 분석 3: 하드웨어 한계도 성능을 크게 좌우한다

OK-Robot은 Hello Robot Stretch를 사용한다. 이 로봇은 집 안 실험에 적합한 플랫폼이지만, 당연히 한계가 있다. 팔이 닿는 범위가 제한되어 있고, payload 한계도 있으며, 카메라와 팔 사이 calibration이 틀어질 수 있다. 바퀴가 카펫과 바닥 사이를 지나갈 때 불안정해질 수도 있다.

논문은 하드웨어 문제가 단순한 부가 문제가 아니라 실제 성공률에 큰 영향을 준다고 본다. 이 점이 중요하다. 로봇 논문을 보면 모델 구조에만 집중하기 쉽지만, 실제 로봇은 하드웨어가 성능의 일부다.

예를 들어 semantic memory가 목표 물체를 잘 찾았고, AnyGrasp가 괜찮은 grasp를 만들었더라도, 로봇 팔이 그 위치까지 닿지 않으면 실패한다. 카메라 calibration이 조금 틀어지면 grasp 위치가 어긋날 수 있다. 물체가 너무 무거우면 들어올릴 수 없다.

내가 이 논문에서 배운 건 이거다.

로봇 시스템에서 실패는 모델만의 문제가 아니다. perception, planning, manipulation, hardware가 모두 연결되어 있다.

OK-Robot의 주요 기여

OK-Robot의 기여는 크게 다섯 가지로 볼 수 있다.

1. Open Knowledge 모델들을 실제 로봇 시스템으로 조립했다

OK-Robot은 새로운 거대 모델 하나를 제안하는 논문이 아니다. 오히려 이미 공개된 강력한 모델들을 실제 로봇 시스템에 어떻게 연결할지 보여준다.

이 점이 중요하다. 요즘은 모델 하나의 성능에 집중하기 쉽지만, 실제 서비스나 실제 로봇에서는 모델을 어떻게 묶고, 어떤 순서로 실행하고, 실패를 어떻게 줄일지가 더 중요할 때가 많다.

2. 새로운 집 환경에서 zero-shot pick-and-drop을 수행했다

OK-Robot은 10개의 실제 집 환경에서 실험했고, 전체 성공률 58.5%, 정리된 환경에서는 82.4%까지 성능을 보였다. 이건 완벽한 수치는 아니지만, 새로운 환경에서 추가 학습 없이 open-vocabulary mobile manipulation을 수행했다는 점에서 의미가 있다.

3. VoxelMap 기반 semantic memory를 실제 시스템에 연결했다

OK-Robot은 iPhone scan을 통해 집 안의 3D semantic memory를 만들고, 자연어 query로 물체 위치를 찾는다. 이 구조는 내 프로젝트의 scene memory, object grounding, target selection과도 연결된다.

4. Lang-SAM과 AnyGrasp를 조합해 open-vocabulary grasping을 구성했다

목표 물체를 언어로 지정하고, 그 물체 mask 안의 grasp 후보만 남기는 방식은 단순하지만 효과적이다. 이건 “언어로 지정한 물체를 실제로 잡는 과정”을 모듈식으로 구현한 좋은 예시다.

5. 실패 원인을 매우 현실적으로 분석했다

개인적으로 이 논문에서 가장 좋은 부분은 실패 분석이다. OK-Robot은 성공한 장면만 보여주지 않는다. query ambiguity, grasp failure, hardware limits, clutter, affordance 문제를 구체적으로 보여준다. 이건 연구 방향을 잡는 데 굉장히 중요하다.

OK-Robot의 한계

OK-Robot은 의미 있는 결과를 보여주지만, 한계도 분명하다.

1. Semantic memory가 정적이다

OK-Robot은 처음에 iPhone으로 방을 스캔하고 VoxelMap을 만든다. 하지만 집은 계속 변한다. 사람이 물건을 옮기고, 문이 열리고, 물건이 떨어지고, 새로운 장애물이 생긴다. 현재 구조는 이런 변화를 실시간으로 반영하지 못한다.

논문도 future work로 live semantic memory와 obstacle map을 언급한다. 실제 집에서 오래 동작하려면, 로봇은 처음 만든 지도만 믿으면 안 된다. 계속 보고, 업데이트하고, 바뀐 상황을 반영해야 한다.

2. Grasp pose만 있고 grasp plan은 부족하다

OK-Robot은 grasp pose를 생성하고, 정해진 방식으로 접근한다. 하지만 실제 집에서는 grasp pose만으로 부족하다. 그 위치까지 어떻게 접근할지, 주변 장애물을 어떻게 피할지, 손목 각도를 어떻게 바꿀지까지 계획해야 한다.

논문은 grasp proposal이 아니라 grasp plan이 필요하다고 말한다. 이건 굉장히 중요한 지점이다.

grasp pose
→ 어디를 잡을지

grasp plan
→ 어떻게 접근해서 잡을지

실제 로봇에서는 두 번째가 훨씬 중요해질 수 있다.

3. 사용자와의 상호작용이 부족하다

OK-Robot은 query가 애매해도 사용자에게 적극적으로 확인하지 않는다. 그래서 semantic memory가 잘못된 물체를 찾으면 그대로 실패할 수 있다.

실제 서비스형 로봇이라면 이렇게 해야 한다.

“초록색 병을 말하는 건가요?”
“왼쪽에 있는 가방이 맞나요?”
“이 물체는 잡기 어려워 보이는데 계속할까요?”

이런 상호작용은 단순한 UX 문제가 아니라 성공률과 안전성에 직접 연결된다.

4. 실패 감지와 복구가 약하다

OK-Robot은 기본적으로 linear state machine에 가깝다. 이동하고, 집고, 이동하고, 내려놓는다. 하지만 중간에 실패했을 때 다시 시도하거나, 다른 grasp를 선택하거나, 사용자에게 물어보는 구조가 약하다.

논문은 이 문제를 multiplicative error accumulation으로 설명한다. 각 모듈이 따로는 80% 이상 성공해도, 전체 task 성공률은 60% 아래로 떨어질 수 있다. 그래서 실패 감지와 복구는 반드시 필요하다.

5. 하드웨어 한계가 크다

Hello Robot Stretch는 좋은 연구 플랫폼이지만, 팔의 reach, payload, gripper 형태, camera calibration, 바퀴 이동성 등에 한계가 있다. 더 강한 하드웨어를 쓰면 성공률이 올라갈 수 있지만, 그만큼 비용과 시스템 복잡도도 커진다.

이건 Physical AI를 볼 때 중요한 지점이다. 소프트웨어가 좋아져도 하드웨어가 따라주지 않으면 실제 성능은 제한된다.

RT-2, OpenVLA와 OK-Robot은 어떻게 다르게 봐야 할까

RT-2와 OpenVLA를 읽은 뒤 OK-Robot을 보면 차이가 더 잘 보인다.

내 식으로 정리하면 이렇다.

RT-2는 “웹 지식이 로봇 행동으로 옮겨질 수 있다”는 가능성을 보여준다.

OpenVLA는 “그 가능성을 연구자가 직접 실험할 수 있게 열어준다.”

OK-Robot은 “좋은 모델들을 실제 로봇 시스템으로 조립하면 어디서 깨지는지”를 보여준다.

그래서 OK-Robot은 내 프로젝트에 아주 중요하다. 나는 지금 action policy 자체를 처음부터 만들려는 단계가 아니다. 오히려 scene grounding, target selection, subgoal decision, confidence, abstain 같은 action 이전의 판단 구조를 잡고 있다. OK-Robot은 이런 구조가 실제 시스템에서 왜 필요한지 보여준다.

내 탑다운 프로젝트와 어떻게 연결할 것인가

내가 지금 진행하려는 VLA 탑다운 프로젝트는 처음부터 RT-2나 OpenVLA급 모델을 완전히 재현하는 것이 아니다. 현실적으로 지금 단계에서는 그렇게 가면 너무 무겁다. 대신 내가 잡아야 하는 방향은 action 이전의 판단 구조다.

OK-Robot은 이 방향과 잘 맞는다. 이유는 세 가지다.

1. Object-centric memory가 중요하다

OK-Robot은 VoxelMap을 통해 집 안의 물체를 언어로 검색 가능한 3D memory로 만든다. 내 toy project에서도 candidate_objects, visibility, relation, notes 같은 구조를 두는 이유가 비슷하다.

scene
→ candidate_objects
→ target grounding
→ confidence
→ subgoal decision

이 흐름은 OK-Robot의 VoxelMap과 연결된다. 차이는 OK-Robot은 실제 3D voxel map이고, 내 초기 프로젝트는 더 작은 schema 기반 scene representation이라는 점이다.

2. 자연어 query는 반드시 ambiguity를 만든다

OK-Robot의 실패 분석을 보면 query ambiguity가 큰 문제다. 사용자가 어떤 단어를 쓰느냐에 따라 로봇이 다른 물체를 찾을 수 있다. 따라서 내 프로젝트에서도 단순히 target을 하나 고르는 것보다 confidence와 abstain이 중요하다.

명령이 명확하다
→ target 선택

명령이 애매하다
→ confidence 낮음

위험하거나 불확실하다
→ abstain 또는 clarification 필요

이건 실제 로봇에서 매우 중요한 안전장치가 될 수 있다.

3. 모듈식 시스템에서는 error propagation을 봐야 한다

OK-Robot은 navigation, manipulation, placing 단계가 순서대로 이어진다. 한 단계가 실패하면 뒤 단계도 영향을 받는다. 내 프로젝트도 마찬가지다.

object detection이 틀림
→ target grounding이 틀림
→ subgoal이 틀림
→ action policy가 틀린 행동을 실행함

그래서 처음부터 모델 하나의 accuracy만 보면 안 된다. 어디서 실패했는지 로그를 남기고, 단계별로 평가해야 한다.

내 프로젝트에 적용한다면

OK-Robot을 보고 내 프로젝트에 적용할 수 있는 구조는 이런 방향이다.

[Scene Input]
- RGB image
- instruction
- candidate_objects

[Grounding Layer]
- target object 후보 선택
- object-query matching score 계산
- ambiguity 판단

[Decision Layer]
- subgoal 선택
- confidence 계산
- abstain 여부 결정

[Policy Adapter]
- OpenVLA 또는 stub policy로 action 생성

[Evaluation / Logging]
- target match
- subgoal match
- abstain correctness
- failure mode 기록

여기서 중요한 건 마지막 logging이다. OK-Robot이 좋은 이유는 성공률만 말하지 않고 실패 원인을 나눠서 보여준다는 점이다. 내 프로젝트도 단순히 “맞았다/틀렸다”가 아니라 왜 틀렸는지를 기록해야 한다.

target grounding failure
query ambiguity
visibility failure
relation reasoning failure
unsafe manipulation candidate
low confidence but no abstain

이런 식으로 실패를 나누면, 프로젝트가 단순 구현이 아니라 연구형 프로젝트처럼 보일 수 있다.

내가 이 논문에서 남긴 핵심

OK-Robot을 읽고 내가 가져간 핵심은 네 가지다.

1. 로봇 지능은 모델 하나로 끝나지 않는다

OK-Robot은 하나의 거대한 VLA 모델보다 시스템 통합을 강조한다. 물체를 찾고, 이동하고, 집고, 내려놓는 과정이 모두 연결되어야 한다. 이건 AI 서비스 개발과도 비슷하다. 모델이 좋아도 서비스 구조가 약하면 실제 사용자 경험은 깨진다.

2. Open Knowledge 모델은 강력하지만, 조립 방식이 더 중요하다

CLIP, OWL-ViT, Lang-SAM, AnyGrasp는 각각 강한 모델이다. 하지만 이걸 그냥 붙인다고 자동으로 좋은 로봇이 되지는 않는다. query, memory, navigation target, grasp filtering, drop heuristic 같은 세부 설계가 성능을 좌우한다.

3. 실제 집 환경은 모델 성능보다 더 복잡하다

실제 집에는 clutter, ambiguity, affordance 문제가 있다. 물건은 겹쳐 있고, 이름은 애매하고, 잡기 어려운 위치에 있다. 이건 실험실 데이터셋만으로는 잘 보이지 않는 문제다. OK-Robot은 이 현실적인 어려움을 잘 보여준다.

4. 내 연구 방향은 confidence와 failure-aware decision으로 가는 게 맞다

OK-Robot의 실패 분석을 보면, 로봇은 모르면 멈추거나 물어봐야 한다. query가 애매하면 확인해야 하고, grasp가 불안정하면 다른 후보를 선택해야 하며, 실패하면 재시도해야 한다.

그래서 내 프로젝트에서 중요한 건 단순히 target을 맞히는 것이 아니다.

내가 왜 이 target을 골랐는가
얼마나 확신하는가
불확실할 때 멈출 수 있는가
실패 원인을 기록할 수 있는가

이 질문들이 내 VLA 탑다운 프로젝트의 핵심이 될 수 있다.

결론 한 줄

OK-Robot은 거대한 VLA 모델 하나보다, 공개된 시각-언어 모델과 로봇 모듈을 어떻게 조립하느냐가 실제 로봇 성능에 얼마나 중요한지 보여준 논문이다.

조금 더 내 식으로 말하면 이렇다. RT-2와 OpenVLA가 “로봇 행동을 출력하는 모델”의 가능성을 보여줬다면, OK-Robot은 “그런 모델과 모듈들이 실제 집 안에 들어갔을 때 어디서 깨지는지”를 보여준다.

이 논문은 화려한 end-to-end 모델 논문은 아니다. 하지만 오히려 그래서 중요하다. 실제 로봇은 하나의 모델만으로 움직이지 않는다. 물체를 찾고, 이동하고, 집고, 내려놓고, 실패를 감지하고, 다시 판단해야 한다.

결국 앞으로 중요한 건 단순히 더 큰 모델을 만드는 것만이 아니다. 로봇이 행동하기 전에 무엇을 보고 있는지, 명령이 충분히 명확한지, 지금 행동해도 안전한지, 실패하면 어떻게 복구할지를 판단하는 구조가 필요하다.

내가 VLA 탑다운 프로젝트에서 집중해야 할 부분도 바로 여기다. OK-Robot은 그 방향을 아주 현실적으로 보여주는 논문이다.

출처

• Peiqi Liu et al., OK-Robot: What Really Matters in Integrating Open-Knowledge Models for Robotics, 2024.
• Project page: https://ok-robot.github.io

※ 이 글은 LLM 기반 Robot Task Planning 논문 3편을 읽고, 진행중인 Isaac Sim 기반 Self-Corrective Robot Task Planner 프로젝트와 연결해서 정리한 글입니다.

정리한 논문은 다음 세 편입니다.

1. Task Planning for Long-Horizon Cooking Tasks Based on Large Language Models
2. Self-Corrective Task Planning by Inverse Prompting with Large Language Models
3. Contrastive In-Context Learning with Active Memory for Task Planning

한 줄 요약

이 세 편의 논문은 모두 조금씩 다른 문제를 다루지만, 하나로 묶으면 이런 질문으로 이어진다.

“LLM이 로봇의 긴 작업 계획을 만들고, 그 계획이 실제 상태에서 말이 되는지 검증하고, 틀리면 고치고, 성공과 실패 경험을 기억해서 다음 계획을 더 잘 만들 수 있는가?”

조금 더 쉽게 말하면 이렇다.

• Long-Horizon Cooking 논문은 LLM을 이용해 요리처럼 긴 순서가 필요한 작업 계획을 만드는 문제를 다룬다.
• InversePrompt 논문은 LLM이 만든 계획이 그럴듯하지만 틀릴 수 있으니, 행동을 거꾸로 되돌려보는 방식으로 계획을 검증하고 수정하는 문제를 다룬다.
• Active Memory 논문은 성공 사례만 보는 planner의 한계를 넘어서, 실패 사례까지 기억하고 다음 planning에서 피해야 할 패턴으로 활용하는 문제를 다룬다.

처음에는 세 논문이 따로 떨어진 것처럼 보였다.

하나는 요리 계획이고, 하나는 inverse action이고, 하나는 memory다.

그런데 정리해보면 내가 만들려는 프로젝트와 거의 그대로 이어진다.

내가 관심 있는 것은 결국 로봇이 자연어 지시를 받고, 현재 장면을 이해한 뒤, 어떤 행동을 어떤 순서로 해야 하는지 계획하는 문제다.

그런데 로봇이 바로 행동하기 전에 반드시 해결해야 하는 문제가 있다.

계획이 실제로 가능한가?
현재 장면의 상태와 맞는가?
중간 단계가 빠지지는 않았는가?
한 번 실패한 실수를 또 반복하지는 않는가?

이 세 편은 바로 그 질문들과 연결된다.

먼저 알아야 할 개념들

논문을 읽다 보면 용어가 꽤 많이 나온다.

Task Planning, Long-Horizon Task, State, Goal, Action, Precondition, Effect, PDDL, Self-Correction, Inverse Action, In-Context Learning, Active Memory 같은 말들이 한꺼번에 나온다.

그래서 논문을 보기 전에, 이 글에서 계속 나올 개념을 먼저 정리해보려고 한다.

1. Task Planning이란?

Task Planning은 로봇이 목표를 이루기 위해 어떤 행동들을 어떤 순서로 해야 하는지 계획하는 문제다.

예를 들어 목표가 이렇게 주어졌다고 하자.

“컵에 커피를 채워서 테이블 위에 놓아라.”

그러면 로봇은 단순히 “커피를 만든다”라고 생각하면 안 된다.

이 목표를 여러 단계로 쪼개야 한다.

예를 들면 이런 식이다.

1. 컵을 찾는다.
2. 컵을 집는다.
3. 컵을 커피머신에 놓는다.
4. 커피머신을 켠다.
5. 커피가 채워질 때까지 기다린다.
6. 커피머신을 끈다.
7. 컵을 다시 집는다.
8. 컵을 테이블 위에 놓는다.

여기서 중요한 건 행동 하나하나보다 순서다. 커피를 채우기 전에 컵이 커피머신에 있어야 하고, 컵을 집기 전에 컵이 실제로 존재해야 한다. 그래서 task planning은 단순한 문장 생성이 아니다.

현재 상태에서 출발해서 목표 상태까지 가는 행동 순서를 만드는 문제다.

2. Long-Horizon Task란?

Long-Horizon Task는 한두 번의 행동으로 끝나지 않는 긴 작업을 말한다.

짧은 작업은 이렇게 끝날 수 있다.

Pick the red cup.

하지만 긴 작업은 다르다.

예를 들어 이런 작업이 있다.

Open drawer
→ Find cup
→ Pick cup
→ Move to table
→ Place cup
→ Pick spoon
→ Place spoon next to cup

이런 작업은 중간에 하나만 틀려도 뒤의 모든 계획이 무너질 수 있다. 예를 들어 서랍을 열지 않았는데 컵을 집으려고 하면 실패한다. 컵을 잘못 집으면 이후에 테이블에 놓는 단계도 틀어진다.

즉, long-horizon task의 어려움은 단순히 길이가 길다는 데 있지 않다.

앞 단계의 작은 오류가 뒤쪽 전체 계획을 무너뜨린다는 점이 어렵다.

로봇에게는 이게 특히 중요하다. LLM이 보기에는 자연스러운 계획이어도, 실제 로봇 입장에서는 실행 불가능한 계획일 수 있기 때문이다.

3. State, Goal, Action이란?

로봇 task planning은 보통 세 가지로 생각하면 된다.

계획은 결국 이런 흐름이다.

현재 상태
→ action 1
→ 중간 상태
→ action 2
→ 중간 상태
→ ...
→ 목표 상태

조금 더 형식적으로 보면 이렇게 볼 수 있다.

s0 + a1 = s1
s1 + a2 = s2
s2 + a3 = s3
...
sT = goal

여기서 중요한 건 action이 단순한 단어가 아니라는 점이다. action은 반드시 state를 바꾼다.

예를 들어 PICK cup을 하면 손 상태가 바뀐다.

• 이전: hand is empty
• 이후: hand is holding cup

이런 상태 변화가 제대로 맞아야 진짜 실행 가능한 plan이라고 볼 수 있다.

4. Precondition과 Effect란?

Precondition은 어떤 행동을 하기 전에 반드시 만족되어야 하는 조건이다.
Effect는 그 행동을 한 뒤에 바뀌는 상태다.

예를 들어 PICK cup이라는 행동을 보자.

내 프로젝트에서 plan verifier를 만들 때 가장 중요한 것도 이 부분이다. LLM이 아무리 그럴듯한 plan을 만들었더라도, precondition이 맞지 않으면 실행하면 안 된다.

예를 들어 이런 상황을 생각해보자.

현재 상태:
drawer is closed
cup is inside drawer
robot hand is empty

그런데 LLM이 이렇게 계획했다.

PICK cup
PLACE cup on table

겉으로 보면 말이 되는 것처럼 보인다. 하지만 실제로는 틀렸다. 왜냐하면 cup이 closed drawer 안에 있기 때문이다. 먼저 drawer를 열어야 한다. 올바른 계획은 이렇게 되어야 한다.

OPEN drawer
PICK cup
PLACE cup on table

이게 바로 precondition/effect 검증이 중요한 이유다.

5. PDDL이란?

PDDL은 Planning Domain Definition Language의 약자다.

쉽게 말하면 로봇 planning 문제를 상태, 행동, 목표로 엄격하게 표현하는 언어다. 자연어는 유연하지만 모호하다.

반면 PDDL은 딱딱하지만 검증하기 좋다. 예를 들어 자연어로는 이렇게 말할 수 있다.

“컵을 집어서 커피머신에 놓아.” 이걸 planning 문제로 바꾸면 다음처럼 볼 수 있다.

Initial state:
(at cup table)
(handempty)

Goal state:
(at cup coffee-machine)

Actions:
(pick cup table)
(place cup coffee-machine)

이런 식으로 표현하면 좋은 점이 있다. LLM이 만든 계획이 현재 상태와 맞는지 확인할 수 있다.

즉, PDDL은 로봇에게 자연어 명령을 바로 던지는 것이 아니라, 검증 가능한 구조로 바꾸는 중간 표현이라고 볼 수 있다.

내가 만들려는 프로젝트에서도 꼭 완전한 PDDL을 구현할 필요는 없지만, 최소한 다음 정보는 구조화해야 한다.

{
  "action": "PICK",
  "target_object": "cup",
  "precondition": [
    "cup is visible",
    "robot hand is empty",
    "cup is reachable"
  ],
  "effect": [
    "robot hand is holding cup"
  ]
}

이렇게 해야 LLM plan을 그냥 믿지 않고 검증할 수 있다.

6. Self-Correction이란?

Self-Correction은 LLM이 자기가 만든 답을 다시 보고, 오류를 찾아 고치는 방식이다.

일반적인 LLM planning은 이렇게 끝날 수 있다.

Instruction → LLM → Plan → Execute

하지만 이 방식은 위험하다. LLM은 그럴듯한 plan을 잘 만든다. 문제는 그럴듯하다고 해서 실제로 맞는 건 아니라는 점이다. 그래서 self-correction은 중간에 검토 단계를 넣는다.

Instruction → LLM → Plan → Check Plan → Feedback → Re-plan → Execute

이 구조는 훨씬 안전해 보인다. 하지만 여기에도 문제가 있다.

LLM이 자기 계획을 다시 본다고 해서 항상 정확히 틀린 부분을 찾는 것은 아니다. 때로는 틀린 계획을 보고도 그럴듯한 피드백을 만들어낸다.

예를 들어 실제 문제는 “로봇이 room1에 있는데 room2의 공을 바로 집으려고 한 것”인데, LLM은 “공이 room2에 없어서 틀렸다”라고 잘못 말할 수 있다.

즉, self-correction도 검증 방식이 약하면 한계가 있다. 이 지점을 파고드는 논문이 바로 InversePrompt다.

7. Inverse Action이란?

Inverse Action은 어떤 행동을 되돌리는 반대 행동이다.

InversePrompt의 핵심 직관은 간단하다.

어떤 행동이 정말 말이 되는지 확인하려면, 그 행동을 한 뒤 반대 행동으로 되돌렸을 때 원래 상태로 돌아오는지 보면 된다.

수학으로 비유하면 이런 느낌이다.

13 + 9 = 22

이 계산이 맞는지 확인하려면 이렇게 되돌려보면 된다.

22 - 9 = 13

되돌렸을 때 원래 값이 나오면 계산 흐름이 맞을 가능성이 높다.

로봇 계획도 비슷하다.

PICK cup을 했다면, 다시 PLACE cup back을 했을 때 원래 상태와 일치해야 한다.

돌아오지 않는다면 중간 상태 변화가 말이 안 된다는 뜻이다.

8. In-Context Learning이란?

In-Context Learning은 모델을 새로 학습하지 않고, 프롬프트 안에 예시를 넣어서 모델이 그 패턴을 따라 하게 만드는 방식이다.

예를 들어 이렇게 넣는 것이다.

예시 1:
Goal A → 올바른 계획 A

예시 2:
Goal B → 올바른 계획 B

새로운 목표:
Goal C → ?

그러면 LLM은 앞의 예시를 참고해서 Goal C에 대한 계획을 만든다. 로봇 task planning에서는 보통 성공한 예시를 몇 개 넣고, LLM이 비슷한 방식으로 action sequence를 만들게 한다.

하지만 여기에도 문제가 있다. 성공 예시만 보면 “어떻게 해야 하는지”는 배울 수 있다.

그런데 “무엇을 하면 안 되는지”는 충분히 배우기 어렵다. 이 문제를 다루는 논문이 Active Memory 논문이다.

9. Positive Prompt와 Negative Prompt란?

Positive Prompt는 “이렇게 하면 된다”를 보여주는 예시다.
Negative Prompt는 “이렇게 하면 안 된다”를 보여주는 예시다.

Active Memory 논문은 이 둘을 같이 쓰는 것이 중요하다고 본다. 왜냐하면 성공만 보면 좋은 패턴은 배우지만, 어떤 실수를 피해야 하는지는 덜 배울 수 있기 때문이다. 사람도 비슷하다.

운전을 배울 때 좋은 주행 예시만 보는 것도 도움이 되지만, 사고 사례나 실수 사례를 보는 것도 중요하다. “이렇게 하면 위험하구나”를 배울 수 있기 때문이다. 로봇 task planning도 마찬가지다. 실패를 그냥 버리면 아깝다. 실패는 다음 계획에서 피해야 할 중요한 힌트가 될 수 있다.

10. Active Memory란?

Active Memory는 모든 경험을 무작정 저장하는 memory가 아니다. 제한된 용량 안에서 유용한 성공/실패 예시를 골라 저장하는 memory다. 로봇이 task를 계속 수행하면 경험이 쌓인다.

• 성공한 계획
• 실패한 계획
• 왜 실패했는지에 대한 피드백
• 수정된 계획

이런 것들을 전부 저장할 수 있다. 하지만 모든 경험을 다 저장하면 문제가 생긴다. memory가 계속 커지고, 검색 비용이 늘어나고, 프롬프트 길이도 길어진다. 그래서 Active Memory는 중요한 예시만 골라서 남긴다. 논문에서는 demonstration을 벡터화하고, clustering을 통해 대표적인 성공/실패 예시를 선택한다.

쉽게 말하면, 모든 경험을 다 기억하는 것이 아니라, 다음 planning에 도움이 되는 대표 경험만 기억하는 방식이다.

세 논문의 전체 흐름

이제 세 논문을 한 번에 놓고 보면 흐름이 보인다.

이 흐름은 내가 만들려는 프로젝트와 거의 그대로 연결된다.

• Long-Horizon Cooking: plan을 만드는 법
• InversePrompt: plan을 검증하고 고치는 법
• Active Memory: 검증과 실행에서 나온 성공/실패를 기억하는 법

결국 좋은 로봇 planner는 단순히 LLM에게 계획을 한 번 물어보는 구조가 아니어야 한다.

계획을 만들고,
그 계획을 의심하고,
틀리면 고치고,
실패를 기억해서 다음에는 덜 틀려야 한다.

이게 세 논문을 하나로 묶는 핵심이라고 생각한다.

1. Task Planning for Long-Horizon Cooking Tasks Based on Large Language Models

한 줄 요약

이 논문은 cooking처럼 긴 순서가 필요한 robot manipulation task에서, LLM을 이용해 환경과 객체의 의미를 해석하고 object-oriented subgoal sequence를 예측하려는 논문이다.

이 논문이 푸는 문제

요리 task는 로봇 task planning에서 대표적인 long-horizon 문제다.

단순히 물체 하나를 집는 것이 아니라, 여러 재료와 도구를 순서에 맞게 다뤄야 한다.

예를 들어 샐러드를 만든다고 하자.

Goal:
mushroom과 carrot이 들어간 salad를 만들어라.

가능한 계획은 이런 식이다.

1. carrot을 찾는다.
2. carrot을 bowl에 넣는다.
3. mushroom을 찾는다.
4. mushroom을 bowl에 넣는다.
5. 필요한 경우 dressing을 추가한다.

문제는 실제 환경에서는 객체가 고정되어 있지 않다는 점이다. 학습 때 본 object만 나오는 것이 아니라, 처음 보는 재료나 도구가 나올 수 있다.

예를 들어 로봇이 “basil”이라는 재료를 처음 본다고 하자. symbolic planner는 basil이 무엇인지 모를 수 있다.

하지만 LLM은 basil이 허브이고, 요리에 쓰이는 재료라는 상식적 의미를 알고 있을 가능성이 있다. 이 논문은 이런 LLM의 의미 지식을 task planning에 끌어오려는 시도라고 볼 수 있다.

왜 어려운가?

이 문제가 어려운 이유는 크게 다섯 가지다.

첫째, cooking task는 순서가 길다.
재료를 찾고, 도구를 사용하고, 조리 단계를 이어가야 한다.

둘째, 객체 이름이 달라도 의미가 비슷할 수 있다.
tomato, cherry tomato, vegetable, ingredient처럼 표현이 다양하다.

셋째, unseen object가 나올 수 있다.
학습 때 본 적 없는 재료라도 의미를 추론할 수 있어야 한다.

넷째, symbolic planner는 정확하지만 유연성이 낮다.
미리 정의되지 않은 물체나 상태가 나오면 약해질 수 있다.

다섯째, 자연어 recipe는 명확한 action sequence가 아니다.
“샐러드를 만들어라”라는 문장을 로봇이 실행 가능한 subgoal sequence로 바꿔야 한다.

핵심 아이디어

이 논문의 핵심은 LLM을 단순히 “계획을 말해주는 모델”로만 쓰는 것이 아니다. LLM을 환경과 객체의 의미를 해석하는 도구로 활용한다. 크게 보면 세 가지 아이디어로 볼 수 있다.

1) Pretrained LLM으로 환경을 해석한다

로봇 환경에는 여러 object가 있다.

예를 들어 이런 식이다.

{
  "objects": [
    {
      "name": "carrot",
      "type": "vegetable"
    },
    {
      "name": "mushroom",
      "type": "ingredient"
    },
    {
      "name": "bowl",
      "type": "container"
    }
  ]
}

LLM은 이런 객체들이 어떤 역할을 하는지 해석할 수 있다. carrot과 mushroom은 재료이고, bowl은 재료를 담는 container다. 이런 의미 정보는 task planning에 도움이 된다.

2) Object-oriented subgoal sequence를 만든다

“샐러드를 만들어라”라는 목표는 너무 크다. 그래서 객체 중심의 중간 목표로 쪼개야 한다. 예를 들면 이렇게 볼 수 있다.

Subgoal 1: carrot을 bowl에 넣기
Subgoal 2: mushroom을 bowl에 넣기
Subgoal 3: dressing을 bowl에 넣기

여기서 중요한 것은 action 자체보다 “어떤 object를 어떤 목표 상태로 보내야 하는가”다. 이 관점은 내 프로젝트와도 잘 맞는다. 내가 만들 plan schema도 결국 target object 중심이어야 한다.

{
  "step_id": 1,
  "action": "PLACE",
  "target_object": "carrot",
  "target_location": "bowl",
  "precondition": [
    "carrot is visible",
    "robot hand is holding carrot",
    "bowl is reachable"
  ],
  "effect": [
    "carrot is in bowl"
  ]
}

3) 자연어 설명에서 training data를 자동 생성한다

로봇 task planning 데이터는 만들기 비싸다. 모든 recipe와 object 조합에 대해 사람이 직접 plan label을 만들기는 어렵다.

이 논문은 LLM을 이용해 자연어 설명에서 object-oriented data를 자동 생성하는 방향을 제안한다. 이 부분이 중요한 이유는 명확하다. 로봇은 현실 세계에서 계속 새로운 물체와 새로운 조합을 만난다. 모든 상황을 사람이 직접 라벨링할 수 없다. 그래서 LLM의 상식 지식과 자동 데이터 생성 능력을 활용하는 것이 중요해진다.

내가 이해한 쉬운 비유

이 논문은 요리 초보에게 레시피를 행동 단위로 쪼개주는 조리 보조자와 비슷하다. 사람에게는 “파스타 만들어”라고 해도 어느 정도 알아듣는다.

하지만 로봇에게는 너무 추상적이다. 로봇에게는 이렇게 쪼개줘야 한다.

1. 냄비를 찾는다.
2. 물을 넣는다.
3. 면을 넣는다.
4. 소스를 준비한다.
5. 면과 소스를 섞는다.

여기서 LLM은 “파스타”라는 목표를 보고 필요한 재료와 도구의 의미를 해석한다. 그리고 그걸 로봇이 이해할 수 있는 subgoal sequence로 바꿔준다.

즉, 이 논문은 LLM을 이용해 자연어 목표와 로봇 행동 계획 사이의 간격을 줄이려는 논문이다.

실험 결과에서 봐야 할 부분

이 논문은 내가 확보한 자료 기준으로는 Abstract 중심으로 확인했다. 그래서 세부 구조와 실험표는 원문에서 추가 확인이 필요하다.

다만 Abstract 기준으로 보면 핵심 주장은 다음과 같다.

• unseen object가 포함된 test set에서 높은 success rate를 보였다.
• 자동 생성된 dataset을 제공했을 때 unknown target recipe에서 성능이 개선되었다.
• 실제 robot platform에 배포해 real-world viability를 보였다고 설명한다.

여기서 내가 봐야 할 포인트는 단순한 수치보다 이 질문이다.

LLM의 semantic feature가 실제로 unseen object planning에 얼마나 도움이 되는가?

이 질문이 내 프로젝트에도 중요하다.

Isaac Sim에서 처음 보는 object category가 나왔을 때, LLM이 그 물체의 역할을 어느 정도 추론할 수 있다면 planning 범위가 넓어진다.

내 연구 방향과 연결되는 지점

이 논문은 내 프로젝트의 Task Planner와 Scene Interpretation 부분에 연결된다.

내가 Isaac Sim에서 만들 scene metadata는 이런 식이 될 수 있다.

{
  "objects": [
    {
      "id": "cup_red_1",
      "category": "cup",
      "color": "red",
      "location": "table"
    },
    {
      "id": "drawer_1",
      "state": "closed",
      "contains": ["spoon_1"]
    }
  ],
  "robot": {
    "hand_state": "empty",
    "position": "near_table"
  }
}

이 metadata를 단순 symbolic label로만 쓰면 유연성이 낮다.

하지만 LLM을 이용해 object의 semantic role을 해석하면 조금 더 일반화된 planning이 가능하다.

내가 가져갈 핵심은 이것이다.

로봇 planning에서 LLM은 단순히 plan을 생성하는 모델이 아니라, object와 scene의 의미를 해석하는 semantic interpreter로도 사용할 수 있다.

한계

이 논문은 Abstract 기준으로 정리했기 때문에 한계를 단정할 수는 없다. 그래도 내가 읽을 때 주의해야 할 점은 있다.

첫째, LLM이 추출한 semantic feature의 품질에 의존한다.
LLM이 object 의미를 잘못 해석하면 planner도 흔들릴 수 있다.

둘째, cooking recipe 중심이기 때문에 다른 manipulation task로 일반화되는지는 확인해야 한다.

셋째, object-oriented subgoal sequence가 실제 low-level robot action으로 바로 연결되는 것은 아니다.

넷째, 자동 생성 dataset은 편리하지만, LLM이 만든 데이터 자체에 오류가 섞일 수 있다.

그래서 이 논문은 내 프로젝트에서 “계획 생성”의 출발점으로 참고하되, 반드시 verifier와 함께 써야 한다.

2. Self-Corrective Task Planning by Inverse Prompting with Large Language Models

한 줄 요약

이 논문은 LLM이 만든 로봇 task plan을 그냥 믿지 않고, 각 action의 inverse action을 만들어 원래 상태로 되돌아갈 수 있는지 확인함으로써 plan의 논리적 오류를 더 잘 검출하고 수정하려는 논문이다.

이 논문이 푸는 문제

LLM은 로봇 task planning에서 꽤 그럴듯한 action sequence를 만들 수 있다.

하지만 문제는 그럴듯하다고 해서 실제로 실행 가능한 것은 아니라는 점이다.

예를 들어 이런 상황이 있다고 하자.

현재 상태:
robot은 room1에 있음
ball1은 room2에 있음

생성된 행동:
PICK ball1 room2

겉으로 보면 ball1이 room2에 있으니 맞아 보인다.

하지만 robot이 room1에 있다면 room2의 ball1을 바로 집을 수 없다.

즉, object location만 보고 판단하면 놓치는 오류가 생긴다.

이런 오류는 실제 로봇에서는 치명적이다.

문장으로는 자연스러워 보이지만, 실제 로봇은 실행할 수 없기 때문이다.

왜 어려운가?

이 문제가 어려운 이유는 네 가지다.

첫째, 계획은 길다.
앞 단계의 작은 오류가 뒤쪽 action 전체를 무너뜨릴 수 있다.

둘째, 로봇 action은 상태 변화를 동반한다.
단순히 문장만 자연스러우면 되는 것이 아니라, action 전후 state가 맞아야 한다.

셋째, LLM의 self-correction도 완벽하지 않다.
틀린 계획을 틀렸다고 말하면서도 이유를 잘못 짚을 수 있다.

넷째, 외부 validator를 만들려면 사람이 rule, error type, feedback template을 많이 설계해야 한다.

결국 이 논문이 보는 핵심 병목은 이것이다.

LLM이 계획을 만들 수는 있지만, 그 계획의 논리적 일관성을 스스로 제대로 검증하기 어렵다.

핵심 아이디어

핵심 아이디어는 inverse prompting이다.

어떤 action이 정말 가능한지 확인하려면, 그 action을 수행한 뒤 inverse action으로 되돌렸을 때 원래 상태로 돌아오는지 보면 된다.

논문은 self-correction을 다음 세 단계로 바꾼다.

1. Generated state verification
   action을 수행한 뒤 생성된 state가 맞는지 확인한다.

2. Inverse action application
   해당 action의 반대 action을 만들어 적용한다.

3. Goal state verification
   최종 state가 goal state와 맞는지 확인한다.

예를 들어 PICK cup을 했다면 inverse action은 PLACE cup back이 될 수 있다.

STACK blockA blockB를 했다면 inverse action은 UNSTACK blockA blockB가 될 수 있다.

이 반대 행동을 적용했을 때 원래 state로 돌아오지 못하면, 그 action 또는 state transition에 문제가 있다는 뜻이다.

논문 속 예시를 쉽게 풀어보기

Ballmoving 예시. robot은 room1에 있고 ball1은 room2에 있는데, examined action이 pick ball1 room2로 주어진 상황.

이 예시는 InversePrompt의 직관을 잘 보여준다.

현재 상태는 이렇다.

robot: room1
ball1: room2

그런데 plan은 이렇게 말한다.

PICK ball1 room2

표준 prompting은 이 상황에서 잘못된 이유를 낼 수 있다.

예를 들어 이렇게 말할 수 있다.

ball1이 room2에 없어서 틀렸다.

하지만 실제 문제는 그게 아니다.

ball1은 room2에 있다.

진짜 문제는 robot이 room2에 없다는 점이다.

InversePrompt는 action 이후 inverse action인 DROP ball1 room2를 적용해보고, inverted state와 original state를 비교한다.

그 결과 robot 위치가 원래는 room1이어야 하는데, reasoning 과정에서는 room2에 있는 것처럼 처리된 차이를 발견한다.

그래서 더 정확한 피드백을 만든다.

잘못된 피드백:
ball1이 room2에 없어서 틀렸다.

더 정확한 피드백:
ball1은 room2에 있지만, robot은 room1에 있다.
따라서 robot이 room2로 이동하지 않고 pick하려 한 것이 문제다.

이 차이가 중요하다.

오류를 정확히 알아야 올바르게 고칠 수 있기 때문이다.

내가 이해한 쉬운 비유

이 논문은 수학 문제 검산과 비슷하다.

예를 들어 내가 이렇게 계산했다고 하자.

13 + 9 = 22

이 답이 맞는지 확인하려면 이렇게 되돌려보면 된다.

22 - 9 = 13

되돌렸을 때 원래 값이 나오면 계산 흐름이 맞을 가능성이 높다.

로봇 계획도 마찬가지다. PICK cup이라는 행동을 했다면, 반대로 내려놓았을 때 원래 상태로 돌아와야 한다. 돌아오지 않는다면 중간 상태 변화가 말이 안 된다는 뜻이다. 즉, InversePrompt는 LLM plan을 “검산”하는 방법에 가깝다.

방법을 구조로 정리하면

Natural language goal
 ↓
LLM translates goal into PDDL-like formulation
 ↓
LLM generates action sequence and intermediate states
 ↓
For each action:
 1. verify generated next state
 2. generate inverse action
 3. apply inverse action
 4. compare inverted state with original state
 ↓
If mismatch exists:
 generate feedback
 re-plan
 ↓
If feasible:
 execute or accept plan

이 구조에서 핵심은 LLM에게 단순히 이렇게 묻는 것이 아니라는 점이다.

이 계획 맞아?

그 대신 이렇게 묻는다.

이 action을 수행하고, 반대로 되돌렸을 때 원래 상태와 일치해?

이게 훨씬 강한 검증이다.

실험 결과에서 봐야 할 부분

Ballmoving, Blocksworld, Cooking benchmark에서 No Validator, External Validator, Self-correction without IP, InversePrompt를 비교한 표.

논문은 Ballmoving, Blocksworld, Cooking 세 benchmark에서 실험한다.

모델은 GPT-4o-mini와 Gemini-1.5-Flash를 사용했고, 다음 방법들과 비교한다.

• No Validator
• External Validator
• Self-correction without Inverse Prompting
• InversePrompt

핵심 결과는 InversePrompt를 붙였을 때 단순 self-correction보다 planning success rate가 더 높게 나온다는 점이다.

즉, LLM이 그냥 “다시 생각해봐”라고 하는 것보다, inverse action으로 되돌려보며 검증하는 방식이 더 강하다는 뜻이다.

실제 로봇 환경에서 Blocksworld와 Cooking task의 오류를 inverse reasoning으로 잡아내는 예시.

특히 real-world 실험도 중요하다.

Blocksworld에서는 잘못된 Unstack action을 잡아내고, Cooking에서는 robot arm이 이미 mushroom을 들고 있는데 granola를 pick하려는 오류를 잡아낸다.

이건 단순 텍스트 reasoning이 아니라 실제 실행 전 검증으로 이어질 수 있음을 보여준다.

내 연구 방향과 연결되는 지점

이 논문은 내 프로젝트의 Verification Layer와 Self-Correction Layer에 바로 연결된다.

내가 만들려는 구조는 다음과 같다.

LLM Planner가 plan 생성
 ↓
Plan Parser가 action / target / precondition / effect 추출
 ↓
Verifier가 현재 scene state와 비교
 ↓
오류가 있으면 feedback 생성
 ↓
Self-Corrector가 plan repair 또는 re-plan

여기서 InversePrompt의 아이디어를 적용하면, 각 action마다 inverse action을 정의할 수 있다.

내가 가져갈 핵심은 이것이다.

LLM plan을 바로 실행하지 말고, action마다 precondition/effect와 inverse action을 정의해서 “이 행동은 현재 장면에서 실제로 말이 되는가?”를 검증하는 구조를 만들 수 있다.

한계

이 논문에도 한계는 있다.

첫째, action이 symbolic하게 잘 정의되어 있어야 한다.
pick, place, stack, unstack처럼 inverse를 만들기 쉬운 행동에는 강하지만, 복잡한 연속 제어 행동에는 그대로 적용하기 어렵다.

둘째, LLM이 state를 잘못 표현하면 inverse verification도 흔들릴 수 있다.
즉, state representation의 품질이 중요하다.

셋째, inverse action이 항상 명확한 것은 아니다.
예를 들어 stir, pour, cut 같은 행동은 단순히 되돌리기 어렵다.

넷째, 실제 로봇 환경에서는 perception error와 execution error가 같이 생긴다.
논문이 real-world 실험을 보여주더라도, 모든 복잡한 환경까지 해결한 것은 아니다.

그래서 내 프로젝트에서는 처음부터 복잡한 조작 행동을 다루기보다, inverse가 명확한 discrete action부터 시작하는 것이 현실적이다.

3. Contrastive In-Context Learning with Active Memory for Task Planning

한 줄 요약

이 논문은 LLM 기반 robot task planner가 성공 예시만 보고 배우는 한계를 넘어서, 성공 사례는 따라 하고 실패 사례는 피하도록 positive/negative prompting을 함께 사용하며, 제한된 용량의 active memory로 유용한 경험만 저장하는 논문이다.

이 논문이 푸는 문제

기존 LLM task planning은 보통 in-context learning을 쓴다.

즉, 프롬프트 안에 성공한 예시 몇 개를 넣고, 모델이 그 패턴을 따라 새로운 task plan을 만들게 한다. 문제는 대부분 성공 예시만 사용한다는 점이다. 성공 예시는 “어떻게 해야 하는지”를 알려준다.

하지만 “어떤 실수를 피해야 하는지”는 충분히 알려주지 못한다. 예를 들어 커피 task에서 성공 예시만 보면 모델은 대략적인 순서를 배울 수 있다.

하지만 이런 실패는 충분히 배우지 못할 수 있다.

컵을 커피머신에 놓지 않고 커피머신을 켠다.
커피머신을 켜지 않고 커피가 완성된 것처럼 컵을 가져온다.
이미 다른 물체가 있는 위치에 컵을 놓는다.

이런 실패들은 실제 로봇 planning에서 중요하다.

성공만큼 실패도 다음 planning에 필요한 정보가 된다.

왜 어려운가?

이 문제가 어려운 이유는 세 가지다.

첫째, 실패 사례도 학습 신호가 되지만, LLM에게 실패를 그대로 보여주면 오히려 따라 할 위험이 있다.
그래서 “이건 실패니까 따라 하지 말라”는 방식으로 명확히 표시해야 한다.

둘째, task planning 실패는 단순 오타가 아니다.
대부분 temporal dependency나 causal dependency 오류다.

예를 들어 컵을 놓기 전에 집어야 하고, 커피머신을 끄기 전에 켜야 한다.

셋째, memory는 유용하지만 무한히 커지면 안 된다.
로봇 시스템에서는 retrieval 시간, API 비용, context length가 모두 제한된다.

결국 이 논문의 핵심 문제는 이것이다.

성공과 실패 경험을 모두 활용하되, memory를 무한히 키우지 않고, 다음 planning에 정말 도움이 되는 예시만 남길 수 있을까?

핵심 아이디어

핵심은 두 가지다.

1. Contrastive In-Context Learning
2. Active Memory

1) Contrastive In-Context Learning

Contrastive라는 말은 여기서 성공과 실패를 대비해서 보여준다는 뜻에 가깝다.

성공한 plan은 positive prompt로 넣는다.

This is a success and correct plan.
Learn this example and follow the pattern and logic demonstrated.

실패한 plan은 negative prompt로 넣는다.

This is a failure and incorrect plan.
Do not learn this example and avoid the pattern and logic shown.

즉, 모델에게 단순히 예시를 던지는 것이 아니다.

이 예시를 따라 해야 하는지, 피해야 하는지를 명확하게 알려준다.

이게 중요하다.

실패 사례를 그냥 넣으면 LLM이 그 실패 패턴을 따라 할 수도 있다.

그래서 negative prompt는 반드시 “따라 하지 말아야 할 예시”로 표시되어야 한다.

2) Active Memory

Active Memory는 성공/실패 demonstration을 모두 저장하되, 제한된 budget 안에서 대표적이고 다양한 예시만 남긴다.

구조는 대략 이렇다.

Generated demos
 ├─ successful demos
 └─ failed demos
 ↓
Sentence-BERT embedding
 ↓
k-means clustering
 ↓
select representative demos
 ↓
Active Memory with fixed budget

즉, 모든 경험을 무작정 저장하는 것이 아니라, 성공과 실패를 나누고, 그 안에서 대표적인 예시를 고른다.

이렇게 하면 memory를 작게 유지하면서도 다양한 유형의 경험을 보존할 수 있다.

논문 속 구조를 쉽게 풀어보기

기존 standard in-context learning, external success memory, external failure memory, 제안 방법을 비교한 구조 그림.

Figure 1은 기존 방법과 제안 방법을 비교한다.

• Standard in-context learning은 미리 정해진 성공 예시만 사용한다.
• External success memory는 성공한 demonstration을 계속 저장한다.
• External failure memory는 실패를 corrected example로 바꿔 저장한다.
• 제안 방법은 성공과 실패 demonstration을 모두 active memory에 넣고, fixed size로 관리한다.

Positive prompting과 negative prompting 예시.

Figure 3은 이 논문의 핵심 직관을 잘 보여준다.

성공한 계획은 따라 하게 하고, 실패한 계획은 피하게 한다. 커피 task를 예로 들면, 성공 plan은 coffee-machine을 켠 뒤 끄고 cup을 가져오는 순서다.

반면 실패 plan은 coffee-machine을 켜지 않고 끄는 등 논리적으로 빠진 action이 있다. 모델은 positive example은 따라 하고, negative example은 피해야 한다.

내가 이해한 쉬운 비유

이 논문은 운전 연습과 비슷하다.

운전을 배울 때 좋은 주행 예시만 보는 것도 도움이 된다.

하지만 사고 영상이나 실수 사례를 보는 것도 중요하다.

왜냐하면 “이렇게 하면 위험하다”를 배울 수 있기 때문이다. 다만 사고 영상을 너무 많이, 아무 기준 없이 보면 오히려 혼란스럽다.

그래서 대표적인 실수 유형만 정리해서 보는 것이 좋다. Active Memory는 바로 이 역할을 한다. 로봇에게 성공 경험만 주는 것이 아니라, 실패 경험도 정리해서 준다.

단, 실패를 무작정 많이 주는 게 아니라 대표적인 실패만 골라준다.

실험 결과에서 봐야 할 부분

Shelf, Coffee, Unpacking benchmark에서 Standard planning과 제안 방법의 success rate를 비교한 표.

논문은 Shelf, Coffee, Unpacking 세 benchmark에서 평가한다.

각 task는 다음 문제를 대표한다.

핵심 결과는 active memory와 contrastive prompting을 함께 쓰면 전반적으로 성공률이 오른다는 점이다.

Active memory, dual prompting, selector 각각의 ablation 결과.

Table 2는 중요한 ablation을 보여준다. 결과적으로 세 요소를 모두 사용했을 때 가장 높은 평균 성능이 나온다.

이 말은 단순히 memory만 붙인다고 되는 것이 아니라는 뜻이다.

• 성공/실패를 대비해서 넣는 dual prompting
• 유용한 예시를 고르는 selector
• fixed budget으로 관리되는 active memory

이 세 요소가 같이 필요하다.

Memory size와 success rate gain 비교. Figure 4는 “많이 저장하는 것”보다 “잘 고르는 것”이 중요하다는 메시지를 보여준다.

Negative prompt 비율 분석.

Table 3은 negative prompt 비율을 분석한다. 여기서 중요한 점은 실패 예시가 많다고 무조건 좋은 것은 아니라는 점이다. positive와 negative signal의 균형이 중요하다.

real-world Shelf 예시. 기존 planner가 collision을 반복하지만, 제안 방법은 실패 경험을 negative prompt로 활용해 collision을 피하는 사례.

Figure 5는 이 논문의 직관을 잘 보여준다. 기존 standard planning은 이전에 slot이 이미 차 있어서 collision이 났던 유형을 다시 반복한다.

반면 제안 방법은 실패 경험을 negative prompt로 활용해 비슷한 collision을 피한다. 즉, 실패를 기억하면 같은 실수를 줄일 수 있다.

내 연구 방향과 연결되는 지점

이 논문은 내 프로젝트의 Active Memory Module과 직접 연결된다.

내가 만들 수 있는 memory schema는 다음처럼 잡을 수 있다.

{
  "memory_id": "fail_0003",
  "instruction_pattern": "pick object inside closed drawer",
  "failure_type": "missing_precondition",
  "bad_plan": [
    "PICK cup"
  ],
  "feedback": "drawer is closed, so cup is not reachable",
  "corrected_plan": [
    "OPEN drawer",
    "PICK cup"
  ],
  "prompt_type": "negative"
}

이 memory는 다음 planning 때 이렇게 들어갈 수 있다.

Positive examples:
- 성공한 drawer task plan

Negative examples:
- drawer가 닫혀 있는데 바로 pick해서 실패한 plan
- 이미 점유된 slot에 place해서 collision이 난 plan

New instruction:
- Open the drawer and pick the red cup.

이렇게 하면 planner는 단순히 새 instruction만 보는 것이 아니라, 과거의 성공과 실패를 함께 참고한다.

내가 가져갈 핵심은 이것이다.

성공 사례만 저장하지 말고, 실패 사례를 “따라 하지 말아야 할 plan”으로 저장해야 한다.
다만 memory가 무한히 커지지 않도록 대표 실패 유형을 선택하는 전략이 필요하다.

한계

이 논문도 한계가 있다.

첫째, 실패 demonstration이 정확히 실패로 분류되어야 한다.
실패 판정 자체가 틀리면 negative prompt가 잘못된 학습 신호가 된다.

둘째, negative prompt가 너무 많으면 모델이 과도하게 보수적이 되거나, 좋은 plan까지 피할 수 있다.

셋째, memory selection은 semantic similarity 중심이다.
실제 로봇 물리 제약이나 scene geometry까지 깊게 반영한다고 보기는 어렵다.

넷째, task plan은 structured action sequence지만, low-level control이나 perception uncertainty까지 직접 해결하는 것은 아니다.

다섯째, benchmark task가 Shelf, Coffee, Unpacking에 한정되어 있으므로 더 복잡한 mobile manipulation으로 확장하려면 추가 설계가 필요하다.

세 논문을 하나의 시스템으로 연결해보기

이제 세 논문을 하나의 시스템으로 다시 보면 더 이해가 쉽다.

1단계: 계획을 만든다

Long-Horizon Cooking 논문은 LLM이 환경과 객체 의미를 해석하고, object-oriented subgoal sequence를 만들 수 있다는 방향을 보여준다.

Instruction + Environment description
→ LLM semantic interpretation
→ Object-oriented subgoal sequence

여기서 핵심은 plan generation이다.

즉,

“로봇이 목표를 이루기 위해 어떤 행동 순서를 만들어야 하는가?”

를 보는 것이다.

2단계: 계획을 의심한다

InversePrompt는 LLM이 만든 plan이 실제로 논리적으로 말이 되는지 inverse action으로 검산한다.

Generated plan
→ state transition check
→ inverse action generation
→ inverted state vs original state comparison
→ feedback / re-plan

여기서 핵심은 plan verification이다.

즉,

“이 plan은 현재 상태에서 진짜 실행 가능한가?”

를 보는 것이다.

3단계: 경험을 기억한다

Active Memory는 성공과 실패를 모두 기억하되, fixed memory budget 안에서 대표적이고 유용한 demonstration만 남긴다.

New success/failure demos
→ embedding
→ diversity-aware selection
→ active memory update
→ positive/negative prompting for next task

여기서 핵심은 memory-aware planning이다.

즉,

“같은 실수를 반복하지 않도록 과거 경험을 어떻게 활용할 것인가?”

를 보는 것이다.

이 흐름을 내 프로젝트로 바꾸면

내가 만들려는 프로젝트는 이런 구조가 될 수 있다.

[Isaac Sim Scene]
RGB image + object metadata + robot state proxy
 ↓
[Instruction]
"Open the drawer and pick the red cup"
 ↓
[Raw Planner]
LLM generates plan
 ↓
[Plan Verifier]
precondition/effect/inverse action check
 ↓
[Self-Corrector]
repair missing steps or re-plan
 ↓
[Active Memory]
store success/failure plans
 ↓
[Evaluation]
raw planner vs verified planner vs memory-aware planner

프로젝트 이름은 이렇게 잡을 수 있다.

Self-Corrective Robot Task Planner in Isaac Sim

조금 더 연구계획서스럽게 쓰면 이렇게도 가능하다.

Isaac Sim 기반 Self-Corrective Task Planning for Mobile-Manipulation-Oriented Robot Agents

내 프로젝트의 핵심 연구 질문

이 논문들을 기준으로 내 프로젝트의 핵심 질문은 이렇게 정리할 수 있다.

LLM/VLA 기반 로봇 task planner가 생성한 작업 계획에 대해, Isaac Sim 장면 상태를 기반으로 plan verification과 self-correction을 적용하면 잘못된 실행 계획을 줄일 수 있는가?

조금 더 구체적으로 나누면 다음과 같다.

1. LLM이 생성한 task plan에서 object grounding 오류, 순서 오류, precondition 오류는 얼마나 자주 발생하는가?
2. scene metadata와 action precondition/effect를 이용해 잘못된 plan step을 탐지할 수 있는가?
3. self-correction을 적용하면 raw planning 대비 plan success rate가 개선되는가?
4. 실패한 plan을 memory로 저장하면 같은 유형의 planning 오류를 줄일 수 있는가?
5. Isaac Sim 기반 hard case에서 verified planner가 raw planner보다 더 안전한 결정을 내리는가?

Baseline 구조

비교 구조는 세 단계로 잡는 것이 좋다.

Baseline A - Raw Planner

instruction + scene → LLM task plan → validation

가장 단순한 구조다.

LLM이 만든 plan을 그대로 검증한다.

이 baseline은 “LLM이 그냥 계획하면 얼마나 틀리는가?”를 보기 위한 기준선이다.

Baseline B - Verified Planner

instruction + scene → LLM task plan → verifier → corrected plan

여기서는 precondition/effect와 inverse action을 이용해 plan을 검증한다.

틀린 action이 있으면 feedback을 만들고 re-plan 또는 repair를 수행한다.

이 구조는 InversePrompt 논문과 연결된다.

Baseline C - Memory-Aware Verified Planner

instruction + scene
→ retrieve positive/negative memory
→ LLM task plan
→ verifier
→ corrected plan
→ update memory

여기서는 Active Memory를 추가한다.

성공 사례와 실패 사례를 memory로 저장하고, 다음 planning 때 positive/negative prompt로 활용한다.

이 구조가 내 프로젝트의 최종 목표에 가장 가깝다.

내가 만들 수 있는 Demo Scenario

처음부터 너무 복잡한 mobile manipulation을 다룰 필요는 없다.

처음에는 inverse action과 precondition이 명확한 task부터 시작하는 게 좋다.

Scenario 1. Closed Drawer

Instruction:
Pick the red cup inside the drawer.

Initial state:
drawer is closed
red cup is inside drawer
robot hand is empty

Raw planner가 만들 수 있는 잘못된 plan:

PICK red cup

Verifier가 잡아야 하는 오류:

red cup is not reachable because drawer is closed

Corrected plan:

OPEN drawer
PICK red cup

이 scenario는 precondition 검증을 보여주기 좋다.

닫힌 서랍 안의 물체는 바로 집을 수 없다.

따라서 PICK 이전에 OPEN drawer가 필요하다.

Scenario 2. Occupied Slot

Instruction:
Place the blue block on the shelf.

Initial state:
shelf slot A is occupied
blue block is on table
robot hand is empty

Raw planner가 만들 수 있는 잘못된 plan:

PICK blue block
PLACE blue block on slot A

Verifier가 잡아야 하는 오류:

slot A is already occupied

Corrected plan:

PICK blue block
PLACE blue block on empty slot B

이 scenario는 scene state 검증을 보여주기 좋다.

LLM은 “shelf에 놓아라”라는 명령만 보고 아무 slot이나 고를 수 있다.

하지만 실제로는 slot이 비어 있는지 확인해야 한다.

Scenario 3. Hand Already Occupied

Instruction:
Pick the granola.

Initial state:
robot hand is holding mushroom
granola is on table

Raw planner가 만들 수 있는 잘못된 plan:

PICK granola

Verifier가 잡아야 하는 오류:

robot hand is not empty

Corrected plan:

PLACE mushroom on table
PICK granola

이 scenario는 robot state 검증을 보여주기 좋다.

로봇 손이 이미 무언가를 들고 있다면 다른 물체를 바로 집을 수 없다.

먼저 들고 있는 물체를 내려놓아야 한다.

이 프로젝트에서 중요한 설계 포인트

이 논문들을 내 프로젝트로 가져오려면 무작정 LLM을 붙이면 안 된다.

중요한 건 LLM의 출력을 검증 가능한 구조로 바꾸는 것이다.

1. Scene State를 명확히 만들어야 한다

LLM에게 이미지만 던지는 것이 아니라, 최소한의 구조화된 scene state가 필요하다.

예를 들면 이런 정보다.

{
  "objects": [
    {
      "id": "red_cup",
      "category": "cup",
      "location": "inside_drawer",
      "visible": false,
      "reachable": false
    },
    {
      "id": "drawer",
      "state": "closed"
    }
  ],
  "robot": {
    "hand_state": "empty"
  }
}

이 정보가 있어야 verifier가 판단할 수 있다.

2. Plan을 구조화해야 한다

LLM이 자연어로 이렇게 말하면 검증하기 어렵다.

First, open the drawer and then pick the red cup.

그래서 plan을 구조화해야 한다.

[
  {
    "step_id": 1,
    "action": "OPEN",
    "target": "drawer"
  },
  {
    "step_id": 2,
    "action": "PICK",
    "target": "red_cup"
  }
]

이렇게 해야 action별 precondition/effect를 확인할 수 있다.

3. Verifier는 단순 문장 평가가 아니어야 한다

Verifier는 “이 계획 괜찮아 보여?”라고 묻는 구조가 아니어야 한다.

그 대신 다음을 확인해야 한다.

• action의 precondition이 현재 state에서 만족되는가?
• action 이후 effect가 올바르게 반영되는가?
• inverse action을 적용했을 때 원래 state와 일치하는가?
• 중간에 빠진 step은 없는가?
• 같은 실패 유형이 memory에 존재하는가?

즉, verifier는 LLM의 말투를 평가하는 것이 아니라, 상태 변화의 논리를 확인해야 한다.

4. Memory는 실패를 저장해야 한다

성공한 plan만 저장하면 부족하다.

실패한 plan도 저장해야 한다.

다만 실패를 그대로 따라 하지 않도록 negative prompt로 분명히 표시해야 한다.

예를 들어 이런 식이다.

This is a failed plan.
Do not follow this pattern.

Instruction:
Pick the red cup inside the drawer.

Failed plan:
PICK red cup

Reason:
The drawer was closed, so the red cup was not reachable.

Corrected plan:
OPEN drawer
PICK red cup

이렇게 저장하면 다음에 비슷한 상황이 나왔을 때 같은 실수를 줄일 수 있다.

내가 이 논문들에서 가져가야 할 관점

이 세 논문은 로봇 task planning을 세 단계로 나눠서 보게 해준다.

1. 계획 생성

LLM은 자연어 목표와 장면 정보를 보고 어느 정도 그럴듯한 plan을 만들 수 있다.

하지만 이 단계만으로는 부족하다.

LLM은 그럴듯한 문장을 만드는 데 강하지, 실제 로봇 상태를 항상 정확히 검증하는 데 강한 것은 아니다.

2. 계획 검증과 수정

로봇은 계획을 바로 실행하면 안 된다.

실행 전에 반드시 현재 scene state와 비교해야 한다.

특히 precondition/effect를 확인해야 한다.

그리고 가능하다면 inverse action으로 되돌려보며 state transition이 논리적으로 맞는지 확인해야 한다.

3. 성공과 실패 기억

로봇이 한 번 실패한 실수를 계속 반복하면 안 된다.

실패한 plan은 버릴 데이터가 아니라 중요한 학습 신호다.

다만 실패를 그대로 따라 하면 안 되기 때문에, negative prompt로 명확히 표시해야 한다.

그리고 memory는 무한히 커지면 안 되기 때문에 대표적인 성공/실패 예시만 골라야 한다.

내 관심 주제와의 연결

내가 지금 관심 있는 키워드는 다음과 같다.

• task planning
• self-correction
• plan verification
• precondition/effect
• active memory
• failure-aware planning
• mobile manipulation
• Isaac Sim validation

이 세 논문과 연결하면 이렇게 볼 수 있다.

이 논문들을 읽을 때 봐야 할 질문

논문을 읽을 때 모든 수식과 구조를 처음부터 완벽히 이해하려고 하면 너무 어렵다.

대신 지금 단계에서는 다음 질문을 중심으로 읽는 게 좋다.

Long-Horizon Cooking을 읽을 때

• LLM은 환경 attribute를 어떤 형식으로 추출하는가?
• object-oriented subgoal은 정확히 action label인가, object-state pair인가?
• unseen object를 어떻게 처리하는가?
• 자동 생성 dataset은 어떻게 만들어지고 검증되는가?
• 이 구조를 Isaac Sim object metadata에 적용할 수 있을까?

InversePrompt를 읽을 때

• inverse action은 어떻게 생성하는가?
• 어떤 action은 inverse가 쉽고, 어떤 action은 어려운가?
• original state와 inverted state를 어떤 기준으로 비교하는가?
• self-correction without inverse prompting보다 왜 성능이 좋아지는가?
• 이 구조를 내 프로젝트의 verifier로 옮기려면 어떤 action schema가 필요한가?

Active Memory를 읽을 때

• positive prompt와 negative prompt는 어떻게 구분되는가?
• 실패 plan을 LLM에게 보여줄 때 어떻게 “따라 하지 말라”고 명시하는가?
• active memory는 어떤 기준으로 대표 예시를 고르는가?
• negative prompt 비율이 너무 높으면 어떤 문제가 생기는가?
• 내 프로젝트에서는 failure_type을 어떻게 정의해야 하는가?

최종적으로 내가 만들고 싶은 구조

내가 지금 당장 거대한 VLA 모델을 학습하거나 실제 모바일 매니퓰레이터를 제어할 수는 없다.

하지만 Isaac Sim에서 다음 구조는 충분히 현실적인 출발점이 될 수 있다.

1. Scene State 만들기
- object list
- location
- visibility
- reachability
- container state
- robot hand state

2. LLM Planner 만들기
- instruction + scene을 입력으로 받음
- action sequence 생성

3. Plan Parser 만들기
- action
- target object
- target location
- precondition
- effect
- confidence

4. Verifier 만들기
- precondition 체크
- effect 체크
- inverse action 체크

5. Self-Corrector 만들기
- 오류 feedback 생성
- missing step 추가
- re-plan

6. Active Memory 만들기
- 성공 plan 저장
- 실패 plan 저장
- failure_type 분류
- positive/negative prompt로 재사용

7. Evaluation 만들기
- raw planner success rate
- verified planner success rate
- memory-aware planner success rate 비교

이렇게 하면 프로젝트가 단순한 LLM 호출 데모가 아니라, 로봇 task planning 시스템처럼 보일 수 있다.

마무리

처음에는 이 논문들이 전부 어렵게 느껴질 수 있다.

Task planning, PDDL, inverse action, active memory 같은 용어도 낯설고, 로봇 논문 특유의 구조도 익숙하지 않다.

그런데 크게 보면 하나의 흐름이다.

첫 번째는 계획을 만드는 문제다.
두 번째는 그 계획을 검증하고 고치는 문제다.
세 번째는 성공과 실패 경험을 기억해서 다음 계획에 활용하는 문제다.

이건 내가 하려는 프로젝트와 잘 맞는다.

내가 지금 당장 거대한 VLA 모델을 학습하거나 실제 모바일 매니퓰레이터를 제어할 수는 없다.

하지만 Isaac Sim에서 장면 상태를 만들고, LLM이 만든 plan을 구조화하고, precondition/effect와 inverse action으로 검증하고, 실패 memory를 쌓는 것은 충분히 현실적인 출발점이다.

최종적으로 내 프로젝트의 핵심은 이것이다.

“로봇이 계획을 만들 수 있는가?”가 아니라,
“로봇이 만든 계획을 실행하기 전에 의심하고, 틀리면 고치고, 같은 실수를 반복하지 않게 만들 수 있는가?”다.

이 관점이 세 논문을 하나로 묶는 핵심이고, 내가 AI & Robotics Lab 방향과 연결하기 좋은 포인트라고 생각한다.

한 줄 요약

이 네 편의 논문은 모두 조금씩 다른 문제를 다루지만, 크게 보면 하나의 흐름으로 이어진다.

“영상과 언어를 어떻게 정확히 맞추고, 그 정보를 바탕으로 어떻게 더 신뢰할 수 있는 판단을 할 것인가?”

조금 더 쉽게 말하면 이렇다.

• VLANet은 긴 영상에서 문장이 가리키는 순간을 찾는 문제를 다룬다.
• SCGA는 영상과 대화 맥락 속에서 “그것”, “그 사람”, “이전 상황” 같은 참조를 추적하는 문제를 다룬다.
• THAM은 모델이 영상을 제대로 보지 않고 그럴듯한 말을 지어내는 문제를 줄이려 한다.
• GranAlign은 영상과 문장이 서로 다른 세밀도로 표현될 때, 그 차이를 맞춰 더 잘 검색하는 방법을 다룬다.

처음에는 각각 따로 떨어진 논문처럼 보였는데, 정리해보면 내가 관심 있는 VLA 연구의 선행 단계와 연결된다.

내가 관심 있는 것은 결국 로봇이 이미지를 보고, 자연어 지시를 이해하고, 어떤 물체를 대상으로 삼아야 하는지, 다음에 어떤 행동을 해야 하는지 판단하는 문제다.

그런데 로봇이 바로 행동하기 전에 반드시 해결해야 하는 문제가 있다.

정확히 보고 있는가?
언어 지시와 장면을 제대로 연결했는가?
이전 맥락을 기억하고 있는가?
확실하지 않은데도 그럴듯하게 행동하려고 하지는 않는가?

이 네 편은 바로 그 질문들과 연결된다.

먼저 알아야 할 큰 그림

논문을 바로 읽으면 용어가 너무 많다.

Video Moment Retrieval, weak supervision, cross-modal attention, co-reference, hallucination, zero-shot retrieval 같은 말들이 한꺼번에 나온다.

그래서 먼저 아주 단순하게 정리하면 좋다.

1. Video-Language Alignment란?

Video-Language Alignment는 영상과 문장을 서로 맞추는 문제다.

예를 들어 이런 영상이 있다고 하자.

• 사람이 컵을 집는다.
• 컵을 테이블 위로 옮긴다.
• 물을 따른다.
• 다시 컵을 내려놓는다.

그리고 문장이 이렇게 주어진다.

“사람이 컵을 집는 순간”

그러면 모델은 긴 영상 전체 중에서 “컵을 집는 순간”이 어디인지 찾아야 한다.

이게 비디오-언어 정렬이다.

쉽게 말하면,

문장이 가리키는 장면을 영상 속에서 찾는 일이다.

로봇으로 연결하면 더 중요해진다.

로봇에게 “빨간 컵을 집어”라고 말했을 때, 로봇은 먼저 빨간 컵이 무엇인지, 어디 있는지, 지금 장면에서 어떤 대상이 명령과 맞는지 알아야 한다.

즉, 행동보다 먼저 정렬이 필요하다.

2. Video Moment Retrieval이란?

Video Moment Retrieval은 긴 영상에서 특정 문장과 맞는 시간 구간을 찾는 문제다.

예를 들어 문장이 이렇게 주어진다.

“남자가 문을 열고 방 안으로 들어간다.”

그러면 모델은 영상 전체 중에서 이 문장과 가장 잘 맞는 시작 시간과 끝 시간을 찾아야 한다.

즉,

긴 영상에서 문장이 설명하는 순간을 찾는 문제다.

VLA 관점에서 보면, 이 문제는 로봇이 자신의 관찰 기록 중에서 어떤 순간이 현재 지시와 관련 있는지 찾는 문제와 닮아 있다.

로봇이 계속 움직이며 관찰한다면, 현재 장면 하나만 보는 것이 아니라 이전에 본 장면까지 고려해야 할 수 있다.

그때 “어떤 관찰이 현재 지시와 관련 있는가?”를 찾는 능력이 중요해진다.

3. Grounded Dialogue란?

Grounded Dialogue는 그냥 대화하는 AI가 아니라, 영상이나 이미지 같은 실제 관측에 기반해서 대화하는 AI를 말한다.

예를 들어 영상이 있고, 사용자가 이렇게 물어본다.

“그 사람이 다음에 뭘 했어?”

여기서 “그 사람”이 누구인지 알아야 하고, “다음”이 어느 시점인지도 알아야 한다.

즉, 단순히 문장만 잘 만드는 것이 아니라, 영상과 이전 대화 맥락을 함께 이해해야 한다.

이게 어려운 이유는 사람의 대화가 보통 명확하지 않기 때문이다.

우리는 매번 “왼쪽에서 두 번째에 있는 파란 옷을 입은 남자”라고 말하지 않는다.

그냥 “그 사람”, “아까 그거”, “그 다음 장면”이라고 말한다.

모델은 이런 지칭을 영상과 대화 맥락 속에서 풀어야 한다.

4. Hallucination이란?

Hallucination은 모델이 근거 없이 그럴듯한 답을 만들어내는 현상이다.

멀티모달 모델에서는 더 위험하다.

왜냐하면 모델이 실제로 영상을 보고 답한 것처럼 보이지만, 사실은 입력 문장이나 데이터셋의 패턴만 보고 대답할 수 있기 때문이다.

예를 들어 질문이 이렇다.

“남자가 무엇을 들고 있나요?”

영상에는 아무것도 들고 있지 않은데, 학습 데이터에서 “남자 + 들고 있다”가 자주 “컵”과 연결되어 있었다면 모델은 “컵을 들고 있습니다”라고 답할 수 있다.

이건 그럴듯하지만 틀린 답이다.

로봇에서는 더 위험하다.

로봇이 실제로 보지 못한 물체를 있다고 판단하거나, 불확실한 상황에서 확신 있게 행동하면 실패로 이어질 수 있다.

그래서 hallucination 문제는 단순히 자연어 생성 품질 문제가 아니라, 나중에는 action decision의 신뢰성과도 연결된다.

5. Zero-shot이란?

Zero-shot은 특정 task에 맞게 추가 학습하지 않고 바로 문제를 푸는 것을 말한다.

예를 들어 모델이 “강아지가 걷는 장면 찾기”라는 작업에 대해 따로 학습하지 않았는데도, 기존에 알고 있는 시각-언어 지식을 이용해 해당 장면을 찾는 것이다.

요즘 LLM, VLM이 강력해지면서 zero-shot 방식이 중요해지고 있다.

특히 로봇이나 VLA 쪽에서는 모든 상황에 대해 데이터를 모으기 어렵다.

현실 세계는 너무 다양하기 때문이다.

그래서 학습 데이터가 부족한 상황에서도 어느 정도 일반화할 수 있는 방법이 중요해진다.

논문 4편의 전체 흐름

내가 이해한 기준으로 네 편을 순서대로 놓으면 이렇게 된다.

이 흐름은 내가 관심 있는 VLA 문제와도 연결된다.

VLA에서 로봇은 단순히 이미지를 보고 바로 행동하면 안 된다.

먼저 지시를 이해해야 하고, 장면과 연결해야 하고, 대상이 맞는지 확인해야 하고, 불확실하면 멈출 수 있어야 한다.

그래서 나는 이 네 편을 “로봇 행동 이전 단계의 이해, 정렬, 추론, 신뢰성”을 공부하기 위한 논문으로 보고 있다.

1. VLANet: Video-Language Alignment Network

한 줄 요약

VLANet은 긴 영상에서 자연어 문장이 가리키는 시간 구간을 찾기 위한 비디오-언어 정렬 논문이다.

이 논문이 푸는 문제

VLANet이 다루는 문제는 Video Moment Retrieval이다.

입력은 두 가지다.

• 긴 영상
• 자연어 질의

출력은 하나다.

• 그 질의와 가장 잘 맞는 영상 속 시간 구간

예를 들어 긴 영상이 있고, 질의가 이렇게 주어진다.

“여자가 냉장고 문을 여는 장면”

그러면 모델은 전체 영상 중에서 이 문장과 맞는 시작 시간과 끝 시간을 찾아야 한다.

왜 어려운가?

어려운 이유는 크게 세 가지다.

첫째, 영상은 길다.
문장 하나가 영상 전체와 관련 있는 것이 아니라, 아주 짧은 순간과만 관련 있을 수 있다.

둘째, 정답 시간 구간 라벨을 만드는 비용이 크다.
사람이 직접 “이 문장은 12.3초부터 15.8초까지에 해당한다”고 표시해야 하는데, 이건 많은 비용이 든다.

셋째, 후보 구간이 너무 많다.
영상을 여러 시간 구간으로 자르면 가능한 후보가 많아지고, 모델은 그중에서 진짜 관련 있는 구간을 찾아야 한다.

핵심 아이디어

VLANet의 핵심은 두 가지로 볼 수 있다.

1) Surrogate Proposal Selection

영상에서 가능한 모든 구간을 다 보지 않고, 의미 있어 보이는 후보를 먼저 고른다.

쉽게 말하면,

모든 장면을 다 뒤지는 것이 아니라, 문장과 관련 있어 보이는 후보를 먼저 추리는 과정이다.

이렇게 하면 모델이 쓸데없는 후보에 attention을 낭비하지 않는다.

2) Cascaded Cross-modal Attention

영상과 문장을 서로 여러 단계로 비교한다.

여기서 중요한 점은 단순히 영상과 문장을 한 번만 비교하는 것이 아니라는 점이다.

먼저 각자 내부 정보를 정리한다.

• 영상 안에서 중요한 장면끼리 관계를 본다.
• 문장 안에서 중요한 단어끼리 관계를 본다.

그 다음 영상과 문장을 서로 비교한다.

• 문장이 영상의 어느 부분을 봐야 하는지 본다.
• 영상이 문장의 어떤 단어와 관련 있는지 본다.

즉, 영상과 언어를 양방향으로 맞춘다.

내가 이해한 쉬운 비유

VLANet은 긴 강의 영상에서 내가 찾고 싶은 문장을 검색하는 상황과 비슷하다.

예를 들어 내가 강의 영상에서 “교수님이 attention을 설명한 부분”을 찾고 싶다고 하자.

그럼 전체 영상을 처음부터 끝까지 다 보는 것은 비효율적이다.

먼저 attention이라는 단어가 나왔거나, 관련 슬라이드가 나온 구간을 후보로 좁힌다.

그다음 그 후보들 중에서 진짜 내가 찾는 설명이 있는 구간을 고른다.

VLANet도 비슷하게 동작한다.

내 연구 방향과 연결되는 지점

내가 관심 있는 로봇/VLA 문제에서는 로봇이 “어디를 봐야 하는지”를 아는 것이 중요하다.

예를 들어 지시가 이렇게 주어진다.

“테이블 위의 빨간 컵을 집어.”

그러면 로봇은 먼저 빨간 컵이 어디 있는지 찾아야 한다.

또 만약 로봇이 이전에 여러 장면을 관찰했다면, 어느 시점의 관찰이 현재 지시와 관련 있는지도 알아야 한다.

이 점에서 VLANet은 action 자체를 다루지는 않지만, action 이전의 grounding과 alignment 문제를 이해하는 데 도움이 된다.

내가 가져가고 싶은 포인트는 이것이다.

행동을 잘하려면, 먼저 언어와 관찰을 정확히 맞춰야 한다.

한계

VLANet은 어디까지나 retrieval/localization 중심 논문이다.

즉, 문장이 가리키는 영상 구간을 찾는 데 초점이 있다.

로봇이 실제로 어떤 행동을 해야 하는지, 어떤 subgoal을 선택해야 하는지는 직접 다루지 않는다.

그래서 VLA로 연결하려면 한 단계 더 생각해야 한다.

video moment retrieval → observation grounding → target selection → subgoal decision

이런 식으로 확장해야 한다.

2. SCGA: Structured Co-reference Graph Attention

한 줄 요약

SCGA는 영상 기반 대화에서 “그것”, “그 사람”, “아까 한 행동” 같은 지칭 관계를 그래프로 풀어내는 논문이다.

이 논문이 푸는 문제

SCGA는 Video-grounded Dialogue 문제를 다룬다.

입력은 다음과 같다.

• 비디오
• 이전 대화 기록
• 현재 질문

출력은 다음과 같다.

• 현재 질문에 대한 답변

예를 들어 영상에 남자와 여자가 나오고, 이전 대화가 이렇게 진행됐다고 하자.

Q1. 남자가 무엇을 하고 있나요?
A1. 컵을 들고 있습니다.

Q2. 그 다음에 그는 무엇을 했나요?

여기서 “그”는 남자를 의미한다.

모델은 이걸 알아야 한다.

그리고 “그 다음”이 영상의 어느 시점을 말하는지도 알아야 한다.

즉, SCGA는 영상과 대화 맥락 속에서 참조 관계를 추적하는 문제를 다룬다.

왜 어려운가?

사람의 대화는 생각보다 불친절하다.

우리는 매번 정확한 이름이나 위치를 말하지 않는다.

그냥 이렇게 말한다.

• 그 사람
• 저 물건
• 아까 그것
• 방금 한 행동
• 그 다음 장면

사람은 문맥으로 이해하지만, 모델에게는 쉽지 않다.

특히 영상까지 함께 봐야 하면 더 어려워진다.

모델은 텍스트 안의 지칭 관계뿐 아니라, 영상 속 객체와 행동까지 함께 연결해야 한다.

핵심 아이디어

SCGA의 핵심은 지칭 관계를 그냥 attention으로 뭉개지 않고, 그래프 구조로 명시적으로 다루는 것이다.

1) Structured Co-reference Resolver

현재 질문과 이전 대화 사이의 관계를 찾는다.

예를 들어 현재 질문에 “그 사람”이 나오면, 이전 대화에서 그 사람이 누구였는지 찾아야 한다.

SCGA는 이런 관계를 그래프로 만들고, Graph Attention Network를 이용해 중요한 연결을 학습한다.

쉽게 말하면,

대화 속 인물, 물체, 표현 사이에 선을 그어서 관계를 추적하는 방식이다.

2) Spatio-temporal Video Reasoner

영상 속 객체들은 공간과 시간 안에서 움직인다.

예를 들어 컵은 테이블 위에 있다가, 사람이 집고, 다시 싱크대로 이동할 수 있다.

SCGA는 이런 영상 속 객체들의 관계도 그래프로 다룬다.

여기서 중요한 것은 단순히 한 프레임만 보는 것이 아니라, 시간에 따라 객체 관계가 어떻게 변하는지도 본다는 점이다.

3) Pointer-augmented Decoder

답변을 만들 때 질문이나 대화에 나온 단어를 그대로 가져올 수 있게 한다.

이건 대화의 일관성을 높이는 데 도움이 된다.

예를 들어 질문에 특정 물체 이름이 나왔으면, 답변에서도 그 표현을 자연스럽게 사용할 수 있다.

내가 이해한 쉬운 비유

SCGA는 사람들과 단체 채팅을 할 때 맥락을 따라가는 것과 비슷하다.

A: “민수가 컵을 가져갔어.”
B: “그거 어디에 뒀어?”
A: “책상 위에.”

여기서 “그거”는 컵이다.

사람은 쉽게 이해하지만, 모델은 “그거”가 컵인지, 민수인지, 책상인지 알아내야 한다.

SCGA는 이런 연결을 그래프로 정리한다.

내 연구 방향과 연결되는 지점

로봇에게도 이런 문제가 생긴다.

예를 들어 사용자가 로봇에게 이렇게 말할 수 있다.

“아까 본 컵을 가져와.”
“그 옆에 있던 물건은 치워.”
“방금 말한 것 말고, 오른쪽에 있는 걸 집어.”

이런 명령은 현재 이미지 하나만 보면 해결하기 어렵다.

이전 관찰, 이전 지시, 현재 장면을 함께 봐야 한다.

SCGA는 action을 직접 다루지는 않지만, multi-turn instruction이나 task history를 다루는 데 중요한 힌트를 준다.

내가 가져가고 싶은 포인트는 이것이다.

멀티모달 reasoning은 단순히 feature를 합치는 문제가 아니라, 관계를 구조화하는 문제일 수 있다.

한계

SCGA는 대화 응답 생성에 초점이 있다.

즉, 최종 출력은 로봇 행동이 아니라 자연어 답변이다.

그래서 manipulation이나 VLA로 연결하려면 다음과 같은 변환이 필요하다.

dialogue reference tracking → task history tracking → object reference tracking → action/subgoal decision

즉, 이 논문을 그대로 가져오는 것이 아니라, 구조적 지칭 추적이라는 아이디어를 로봇 관찰과 명령 이해에 맞게 바꿔야 한다.

3. THAM: Information-Theoretic Text Hallucination Reduction

한 줄 요약

THAM은 영상 기반 대화 모델이 실제 질문과 영상을 이해하지 않고 입력 텍스트를 복사하거나 그럴듯하게 말하는 문제를 줄이려는 논문이다.

이 논문이 푸는 문제

THAM이 다루는 핵심 문제는 text hallucination이다.

여기서 hallucination은 모델이 실제 근거 없이 답을 만드는 현상이다.

특히 THAM에서 보는 문제는 모델이 질문을 제대로 이해하지 않고, 입력 텍스트나 대화 기록에 나온 표현을 대충 복사해서 답하는 경우다.

예를 들어 입력에 “kitchen”, “cup”, “table” 같은 단어가 많이 등장했다고 하자.

모델이 실제 질문과 영상을 제대로 보지 않고도 “컵이 테이블 위에 있습니다”라고 답할 수 있다.

이 답은 그럴듯해 보이지만, 실제로는 grounded answer가 아닐 수 있다.

왜 어려운가?

모델 입장에서는 shortcut을 배우는 것이 쉽다.

데이터셋에 자주 나오는 패턴이 있으면, 모델은 실제로 이해하지 않아도 높은 점수를 받을 수 있다.

예를 들어 어떤 데이터셋에서 “What is the man holding?”이라는 질문에 “cup”이 자주 답이라면, 모델은 영상을 제대로 보지 않고도 cup이라고 답하는 경향을 배울 수 있다.

이건 자연어 생성에서는 점수가 좋아 보일 수 있지만, 실제 이해력은 낮다.

로봇으로 가면 더 위험하다.

로봇이 실제로 보지 않은 물체를 있다고 판단하거나, 잘못된 대상을 선택할 수 있기 때문이다.

핵심 아이디어

THAM은 모델이 얼마나 hallucination에 기대고 있는지를 정보이론적으로 줄이려고 한다.

구조를 아주 쉽게 말하면 세 종류의 모델을 둔다.

1) RLM

RLM은 일반적인 답변 생성 모델이다.

비디오, 대화 기록, 질문을 보고 답변을 만든다.

즉, 정상적인 모델이다.

2) HLM

HLM은 질문을 제거한 상태에서 답변을 예측하게 만든다.

즉, 질문 없이도 답을 맞히려고 하는 모델이다.

이 모델이 잘 맞힌다면, 그건 실제 질문 이해보다는 데이터셋 패턴이나 입력 텍스트 shortcut을 이용하고 있을 가능성이 있다.

3) LM

LM은 순수하게 답변 문장 자체의 언어 패턴만 학습한다.

이 모델은 영상이나 질문을 보지 않고, 언어적으로 그럴듯한 다음 단어를 예측한다.

THAM의 핵심 직관

THAM의 핵심은 이거다.

정상 모델이 답을 만들 때, 환각 모델이 쓰는 shortcut 정보에 너무 의존하지 않도록 하자.

즉, 모델이 단순히 입력 텍스트를 복사하거나, 데이터셋 패턴에 기대는 방향으로 답하지 않게 만드는 것이다.

조금 쉽게 표현하면,

“진짜 영상을 보고 질문에 답한 정보”와
“그냥 그럴듯하게 말하게 만드는 shortcut 정보”를 분리하려는 시도다.

내가 이해한 쉬운 비유

시험을 본다고 생각해보자.

어떤 학생은 문제를 읽고 이해해서 답한다.

다른 학생은 문제를 제대로 읽지 않고, 자주 나오는 답안 패턴을 외워서 쓴다.

둘 다 겉으로는 비슷한 답을 쓸 수 있다.

하지만 두 번째 학생은 진짜 이해한 것이 아니다.

THAM은 모델이 두 번째 학생처럼 행동하지 않도록 막으려는 논문이다.

내 연구 방향과 연결되는 지점

이 논문은 내가 관심 있는 trustworthy decision과 연결된다.

로봇이 행동하기 전에 판단을 한다고 생각해보자.

예를 들어 로봇이 “빨간 컵을 집어”라는 명령을 받았다.

그런데 실제 장면에는 빨간 컵이 없고 파란 컵만 있다.

이때 신뢰할 수 있는 모델이라면 이렇게 판단해야 한다.

“빨간 컵이 보이지 않으므로 실행을 보류해야 한다.”

하지만 hallucination이 있는 모델은 이렇게 말할 수 있다.

“빨간 컵을 집겠습니다.”

이건 위험하다.

그래서 THAM의 문제의식은 VLA에서도 중요하다.

내가 가져가고 싶은 포인트는 이것이다.

신뢰성은 느낌의 문제가 아니라, 모델이 어떤 shortcut에 의존하는지 측정하고 줄이는 문제일 수 있다.

한계

THAM은 grounded text generation을 다룬다.

즉, 최종 출력은 로봇 행동이 아니라 자연어 답변이다.

그래서 VLA로 직접 연결하려면 다음 질문이 필요하다.

• 텍스트 hallucination을 action hallucination으로 확장할 수 있을까?
• 모델이 실제 관측보다 언어 prior에 의존하는지를 어떻게 측정할 수 있을까?
• 불확실할 때 실행하지 않고 abstain하도록 만들 수 있을까?

이 질문들이 내가 관심 있는 verification 방향과 연결된다.

4. GranAlign: Granularity-Aware Alignment

한 줄 요약

GranAlign은 영상과 문장이 서로 다른 세밀도로 표현될 때 생기는 mismatch를 줄여, zero-shot video moment retrieval 성능을 높이는 논문이다.

이 논문이 푸는 문제

GranAlign도 Video Moment Retrieval 문제를 다룬다.

다만 VLANet과 다른 점은 zero-shot 상황을 본다는 것이다.

즉, 특정 데이터셋에 맞게 모델을 다시 학습하지 않고도, 주어진 문장에 맞는 영상 구간을 찾아야 한다.

여기서 GranAlign이 주목한 문제는 semantic granularity mismatch다.

쉽게 말하면,

영상과 문장이 같은 장면을 말하고 있는데, 표현의 세밀도가 서로 다른 문제다.

granularity mismatch가 뭔가?

예를 들어 문장이 이렇게 주어졌다고 하자.

“강아지가 걷고 있다.”

그런데 영상 캡션은 이렇게 표현될 수 있다.

“어린 골든 리트리버가 잔디 위를 천천히 걷고 있다.”

둘은 같은 장면을 말하지만 세밀도가 다르다.

하나는 단순하다.

• 강아지
• 걷는다

다른 하나는 더 구체적이다.

• 어린 골든 리트리버
• 잔디 위
• 천천히 걷는다

모델이 이 둘을 제대로 같은 의미로 맞추지 못하면 retrieval 성능이 떨어진다.

핵심 아이디어

GranAlign의 핵심은 크게 두 가지다.

1) Query Rewriting

원래 질의를 여러 수준으로 다시 쓴다.

예를 들어 원래 질의가 이렇다.

“어린 골든 리트리버가 잔디 위를 걷고 있다.”

이를 더 단순하게 바꿀 수 있다.

“강아지가 걷고 있다.”

또는 더 자세하게 바꿀 수도 있다.

“어린 골든 리트리버가 잔디밭 위를 천천히 돌아다니고 있다.”

즉, 하나의 질의를 여러 granularity로 바꾸는 것이다.

2) Query-aware Captioning

일반적인 영상 캡션은 영상만 보고 설명을 만든다.

하지만 GranAlign은 질의를 고려해서 캡션을 만든다.

예를 들어 사용자가 “강아지”를 찾고 있다면, 영상 캡션도 그 질의와 관련된 대상과 행동을 더 잘 드러내도록 만든다.

즉, 질의와 영상 설명이 서로 더 잘 맞도록 조정한다.

내가 이해한 쉬운 비유

검색어를 잘못 넣으면 원하는 결과가 안 나오는 경우가 있다.

예를 들어 내가 “운동화”라고 검색하면 너무 넓은 결과가 나오고, “브라운 뉴발란스 2002R 남성용”이라고 검색하면 너무 좁은 결과가 나올 수 있다.

상황에 따라 검색어를 적당히 단순하게 하거나 자세하게 바꿔야 한다.

GranAlign도 비슷하다.

영상과 문장이 서로 다른 표현 수준을 가질 때, 질의를 여러 세밀도로 바꿔서 더 잘 맞추려는 것이다.

내 연구 방향과 연결되는 지점

GranAlign은 내가 관심 있는 target grounding과 직접 연결된다.

로봇에게 사용자가 이렇게 말할 수 있다.

“저 컵 좀 치워줘.”

하지만 장면에는 여러 컵이 있을 수 있다.

• 빨간 컵
• 머그컵
• 플라스틱 컵
• 책 옆에 있는 컵
• 싱크대 근처의 컵

사용자의 표현은 단순한데, 실제 장면은 훨씬 구체적이다.

반대로 사용자는 아주 자세히 말했는데, 모델의 시각 표현은 단순할 수도 있다.

이때 instruction granularity와 scene granularity를 맞추는 것이 중요하다.

내가 가져가고 싶은 포인트는 이것이다.

grounding 문제는 단순히 “맞다/틀리다”가 아니라, 표현의 세밀도를 맞추는 문제일 수 있다.

한계

GranAlign은 retrieval 중심 논문이다.

즉, 영상에서 관련 구간을 찾는 데 초점이 있다.

로봇이 실제로 어떤 행동을 해야 하는지는 다루지 않는다.

또한 LLM/VLM을 활용한 query rewriting과 caption generation에 의존하기 때문에, 프롬프트나 생성 품질에 따라 결과가 흔들릴 수 있다.

그래서 VLA로 연결하려면 이런 질문이 필요하다.

• 로봇 instruction도 여러 granularity로 다시 쓸 수 있을까?
• 장면 설명을 instruction-aware하게 만들 수 있을까?
• target object와 subgoal 선택 전에 granularity mismatch를 줄일 수 있을까?
• 잘못된 재작성 때문에 오히려 잘못된 행동을 유도하지는 않을까?

네 편을 한 번에 연결해보기

이제 네 편을 하나의 흐름으로 다시 보면 더 이해가 쉽다.

1단계: 문장과 영상 구간을 맞춘다

VLANet은 문장이 영상의 어느 순간과 맞는지 찾는다.

여기서 핵심은 temporal alignment다.

즉,

“언어 지시가 관찰의 어느 부분과 연결되는가?”

를 보는 것이다.

2단계: 문맥과 참조를 추적한다

SCGA는 영상과 대화 속에서 지칭 관계를 추적한다.

여기서 핵심은 structured reasoning이다.

즉,

“그것, 그 사람, 아까 그 행동이 정확히 무엇을 가리키는가?”

를 보는 것이다.

3단계: 근거 없는 답변을 줄인다

THAM은 모델이 실제 근거 없이 그럴듯한 말을 하는 문제를 줄인다.

여기서 핵심은 trustworthiness다.

즉,

“모델이 진짜 보고 판단한 것인가, 아니면 shortcut에 기대고 있는가?”

를 보는 것이다.

4단계: 표현의 세밀도를 맞춘다

GranAlign은 문장과 영상 표현의 granularity mismatch를 줄인다.

여기서 핵심은 granularity-aware alignment다.

즉,

“같은 장면을 서로 다른 수준으로 표현할 때 어떻게 맞출 것인가?”

를 보는 것이다.

내가 이 논문들에서 가져가야 할 관점

내가 관심 있는 최종 방향은 VLA, 특히 모바일 매니퓰레이션과 연결되는 문제다.

하지만 지금 단계에서 바로 low-level control이나 trajectory planning으로 들어가는 것은 무리일 수 있다.

대신 이 네 편은 행동 이전 단계에서 필요한 문제를 보여준다.

내가 가져가야 할 핵심 관점

1. 로봇이 행동하기 전, 먼저 지시와 장면을 정확히 맞춰야 한다.
2. 현재 장면만 보는 것이 아니라, 이전 맥락과 지칭 관계도 이해해야 한다.
3. 모델이 그럴듯하게 말하거나 행동하는 것이 아니라, 실제 관측에 근거해야 한다.
4. 사용자 지시와 시각 장면은 서로 다른 세밀도로 표현될 수 있으므로, 그 차이를 맞추는 과정이 필요하다.
5. 확실하지 않은 경우에는 무리하게 실행하지 않고 보류하는 구조가 필요할 수 있다.

이걸 내 연구 관심으로 바꾸면 다음과 같다.

모바일 매니퓰레이션 전체를 바로 end-to-end로 풀기보다,
먼저 target grounding과 short-horizon subgoal selection이 instruction과 scene에 실제로 일치하는지 검증하는 문제에서 출발할 수 있다.

내 관심 주제와의 연결

내가 지금 관심 있는 키워드는 다음과 같다.

• target grounding
• temporal alignment
• multimodal reasoning
• trustworthy decision
• short-horizon subgoal selection
• abstention

이 네 편과 연결하면 이렇게 볼 수 있다.

내가 이해한 최종 그림

이 네 편을 읽으면서 가장 중요하게 느낀 점은 이것이다.

VLA에서 action은 마지막 단계다.

처음부터 로봇 행동을 바로 예측하려고 하면 너무 어렵다.

그 전에 해결해야 할 것들이 많다.

• 무엇을 봐야 하는가?
• 어떤 물체가 지시 대상인가?
• 이전 대화나 관찰과 어떻게 연결되는가?
• 지금 판단이 실제 관측에 근거한 것인가?
• 문장과 장면의 세밀도가 맞는가?
• 확실하지 않다면 멈출 수 있는가?

이 문제들이 제대로 해결되지 않으면, 아무리 좋은 action model이 있어도 잘못된 대상을 잡거나, 엉뚱한 행동을 할 수 있다.

그래서 나는 지금 단계에서 VLA를 볼 때, low-level control보다 그 이전의 understanding, alignment, reasoning, trustworthiness를 먼저 봐야 한다고 느꼈다.

앞으로 읽을 때의 기준

이 논문들을 다시 읽을 때는 모든 수식과 구조를 처음부터 완벽히 이해하려고 하기보다, 다음 질문을 기준으로 보면 좋을 것 같다.

VLANet을 읽을 때

• 이 논문은 어떻게 영상 후보 구간을 줄이는가?
• 왜 surrogate proposal selection이 필요한가?
• cross-modal attention은 영상과 문장을 어떤 방식으로 맞추는가?
• 이 구조를 robot observation grounding으로 바꾼다면 무엇이 달라질까?

SCGA를 읽을 때

• 이 논문은 co-reference를 왜 그래프로 푸는가?
• 대화 속 지칭 관계와 영상 속 객체 관계를 어떻게 연결하는가?
• 이 구조를 multi-turn robot instruction에 적용할 수 있을까?
• task history나 episodic memory로 확장할 수 있을까?

THAM을 읽을 때

• text hallucination을 어떻게 정의하는가?
• 모델이 shortcut에 의존한다는 것을 어떻게 측정하는가?
• THAM의 regularization은 무엇을 줄이려는가?
• 이 아이디어를 action hallucination이나 decision reliability로 확장할 수 있을까?

GranAlign을 읽을 때

• semantic granularity mismatch가 정확히 무엇인가?
• query rewriting은 왜 필요한가?
• query-aware captioning은 일반 captioning과 무엇이 다른가?
• robot instruction과 scene representation 사이에서도 granularity mismatch가 생길까?

마무리

처음에는 이 논문들이 전부 어렵게 느껴졌다.

각 논문마다 용어도 다르고, 문제 설정도 다르고, 모델 구조도 복잡했다.

그런데 크게 보면 하나의 흐름이 보인다.

영상과 언어를 정확히 맞추고, 맥락을 이해하고, 근거 없는 판단을 줄이고, 표현의 차이를 조정하는 것.

이건 결국 VLA에서 로봇이 행동하기 전에 필요한 선행 능력과 연결된다.

내가 지금 바로 거대한 VLA 모델을 학습하거나 로봇팔 제어를 다룰 수는 없더라도, 이 흐름을 이해하는 것은 중요하다.

왜냐하면 로봇이 행동을 잘하려면, 먼저 제대로 보고, 제대로 이해하고, 제대로 의심할 수 있어야 하기 때문이다.

그래서 나는 이 네 편을 단순한 비디오-언어 논문이 아니라, VLA로 가기 전 반드시 이해해야 할 “행동 이전 단계의 멀티모달 이해 논문”으로 보고 있다.

OpenAI가 2시간 전에 GPT-5.5를 공개했다. 이번 발표를 한 줄로 정리하면 이렇다.

GPT-5.5는 단순히 답변을 더 잘하는 모델이라기보다,
복잡한 일을 이해하고, 도구를 쓰고, 스스로 확인하면서 끝까지 수행하는 능력이 강화된 모델이다.

기존 모델들이 “질문에 답하는 AI”에 가까웠다면, GPT-5.5는 “일을 맡길 수 있는 AI”에 가까워졌다.

1. 핵심 변화: “답변 AI → 작업 수행 AI”

GPT-5.5는 단순 질의응답이 아니라, 실제 업무를 수행하는 능력이 강조되었다. 대표적으로 이런 작업들이다.

• 코드 작성 및 디버깅
• 리팩토링
• 리서치 및 데이터 분석
• 문서 / 스프레드시트 생성
• 여러 도구를 오가며 작업 완료

핵심은 이거다.

지능이 좋아진 것보다,
작업을 끝까지 끌고 가는 능력이 좋아졌다.

2. 코딩 능력: “코드 생성 → 시스템 이해”

GPT-5.5는 코딩에서 가장 큰 개선이 있었다.

주요 성능 변화

특히 중요한 건 Terminal-Bench다. 이건 단순 코드 생성이 아니라:

• 계획 세우기
• 반복 작업
• 도구 활용
• 문제 해결

까지 포함된 “실제 개발 작업” 평가다.

핵심 변화 요약

코드를 더 잘 쓰는 모델이 아니라
코드베이스를 이해하는 모델이 됐다.

3. 지식 작업: “Chat → 실제 업무 도구”

GPT-5.5는 일반 업무에서도 강해졌다.

가능한 작업

• 보고서 작성
• 스프레드시트 분석
• 비즈니스 데이터 정리
• 자동화 워크플로우 생성

성능 변화

특히 OSWorld는 “컴퓨터를 직접 다루는 능력” 평가다.

AI가 이제 채팅창 안이 아니라
컴퓨터 환경에서 직접 일하기 시작했다는 신호다.

4. 연구 능력: “답변 → 탐색 파트너”

GPT-5.5는 연구 작업에서도 개선되었다.

성능 변화

핵심 변화

이제 AI는:

• 아이디어 탐색
• 데이터 분석
• 가설 검증
• 결과 해석

까지 함께한다.

논문 요약 도구 → 연구 파트너

5. 효율성: “더 똑똑 + 더 효율”

보통 모델이 좋아지면 느려진다.

하지만 GPT-5.5는:

• GPT-5.4와 비슷한 속도 유지
• 더 적은 토큰으로 작업 수행

의미

더 똑똑하면서도
실제 서비스에 쓸 수 있는 수준으로 효율 개선

6. 안전성: 성능 상승 = 통제 강화

GPT-5.5는 보안 능력도 향상되었다.

• 사이버보안 능력 강화
• 생물/화학 관련 능력 상승
• 위험 요청에 대한 통제 강화

방향성

무조건 개방이 아니라
능력 + 통제 구조를 함께 설계

7. 한 줄 요약 (진짜 핵심)

GPT-5.5의 변화는 이거 하나다.

“똑똑한 답변”보다
“끝까지 수행하는 능력”이 더 중요해졌다

8. 개발자 관점에서 중요한 변화

이건 개인적으로 제일 중요한 포인트다.

이전:

사람이 단계별로 AI를 컨트롤

이제:

사람이 목표를 주고
AI가 실행을 담당

앞으로 중요한 능력

• AI에게 “문제 정의”하기
• 작업 흐름 설계하기
• 결과 검증하기
• 서비스 구조에 안전하게 연결하기

9. 주의할 점

1) 벤치마크 ≠ 실제 성능

• 연구 환경 기준
• 실제 사용과 차이 있음

2) 모든 영역 1등은 아님

• 일부 영역은 Claude / Gemini가 더 높음

3) 검증 중요성 증가

• 결과가 더 그럴듯해짐
• 오히려 검증 필요성 증가

결론

GPT-5.5는 단순히 더 똑똑한 모델이 아니다.

“일을 맡길 수 있는 AI”로 가는 과정의 모델이다

AI는 지금:

• 답변 생성 → 작업 수행
• 도구 → 협업 파트너

로 이동 중이다.

내 한 줄 정리

AI를 잘 쓰는 사람이 아니라,
AI로 결과를 만드는 사람이 살아남는 단계가 시작됐다

출처

• OpenAI, Introducing GPT-5.5

이 글은 내가 Physical AI와 VLA를 공부하면서, 바로 거대한 로봇 모델을 구현하기보다 작은 toy-project로 개념을 익혀간 7일 기록이다.
목표는 로봇을 직접 움직이는 것이 아니라, 로봇이 행동하기 전에 무엇을 목표로 삼고, 지금 진행해도 되는지 판단하는 구조를 이해하는 것이었다.

0. 시작점

처음에는 VLA, Physical AI, mobile manipulation이라는 말이 너무 크게 느껴졌다.

Vision-Language-Action이라고 하면 뭔가 이미지를 보고 문장을 이해해서 바로 로봇 행동을 내는 거대한 모델처럼 보였다.
하지만 막상 공부를 시작해보니, 실제 로봇이 행동하기 전에는 훨씬 많은 판단이 필요했다.

예를 들어 사람은 이렇게 말한다.

책 왼쪽의 파란 컵을 집어

사람에게는 쉬운 문장이지만, 로봇 입장에서는 이 문장을 바로 action으로 바꿀 수 없다.

로봇은 먼저 물어야 한다.

파란 컵이 보이는가?
컵이 여러 개인가?
책은 어디에 있는가?
책 왼쪽의 컵은 어떤 컵인가?
그 컵이 잘 보이는가?
지금 바로 집어도 되는가?
더 봐야 하는가?
확신이 없으면 멈춰야 하는가?

그래서 나는 처음부터 로봇팔 제어나 trajectory planning으로 가지 않고, action 이전의 decision layer를 작은 프로젝트로 만들어보기로 했다.

1. 프로젝트 한 줄 정의

이 toy-project는 다음과 같이 정의했다.

정적인 이미지와 언어 지시, candidate objects를 기반으로 target object를 고르고,
short-horizon subgoal을 선택한 뒤,
확신이 낮으면 abstain하는 grounded decision toy-project

즉, 이 프로젝트는 로봇을 실제로 움직이는 프로젝트가 아니다.

대신 로봇이 움직이기 전에 필요한 판단을 다룬다.

무엇을 target으로 볼 것인가?
지금 바로 진행해도 되는가?
더 봐야 하는가?
아예 보류해야 하는가?

2. 전체 범위

포함한 것

single RGB image
single natural language instruction
candidate object 기반 target selection
short-horizon subgoal prediction
consistency scoring
abstain
mobile-like scene
failure analysis

제외한 것

real robot control
low-level trajectory planning
object detector 학습
segmentation mask 예측
video / observation history
memory
re-grounding / replanning
Isaac Sim 실제 연동

처음부터 모든 것을 하려 하면 아무것도 제대로 이해하지 못할 것 같았다.
그래서 범위를 줄였다.

내가 먼저 알고 싶었던 것은 이것이었다.

로봇이 action을 내기 전에 target과 subgoal을 신뢰할 수 있게 판단할 수 있는가?

Day1. Physical AI와 문제 정의

1. Physical AI란 무엇인가?

Physical AI는 현실 세계를 보고, 이해하고, 판단하고, 실제 행동까지 하는 AI다.

챗봇은 틀리면 이상한 답을 한다.
하지만 로봇은 틀리면 잘못 움직인다.

이 차이가 크다.

일반 AI:
입력 → 답변

Physical AI:
현실 장면 입력 → 상황 이해 → 목표 해석 → 행동 판단 → 실제 행동

그래서 Physical AI에서는 단순히 “정답을 잘 맞힌다”보다 더 중요한 것이 있다.

틀릴 것 같을 때 멈출 수 있는가?
행동하기 전에 위험을 감지할 수 있는가?
지금 장면을 믿을 수 있는가?

Physical AI의 핵심은 똑똑하게 말하는 것이 아니라, 현실에서 틀린 행동을 줄이는 것이다.

2. 일반 AI와 Physical AI의 차이

일반 AI는 대부분 정보를 처리하고 답을 낸다.

예를 들면 다음과 같다.

챗봇:
질문을 받고 답변을 생성한다.

이미지 분류 모델:
이미지를 보고 고양이인지 강아지인지 분류한다.

음성 인식 모델:
음성을 텍스트로 변환한다.

반면 Physical AI는 답을 내는 데서 끝나지 않는다.
실제 현실 세계 안에서 몸을 움직인다.

예를 들면 다음과 같다.

자율주행:
도로를 보고, 차선을 이해하고, 다른 차와 보행자를 피하면서 운전한다.

로봇팔:
물체를 보고, 어떤 물체를 잡아야 하는지 판단하고, 실제로 팔을 움직인다.

모바일 매니퓰레이터:
이동하면서 물체를 찾고, 접근하고, 로봇팔로 조작한다.

이 차이 때문에 Physical AI는 더 어렵다.

왜냐하면 현실에서는 다음 문제가 생기기 때문이다.

센서가 완벽하지 않다.
시야가 가려질 수 있다.
물체가 겹쳐 있을 수 있다.
로봇의 팔 길이가 제한되어 있다.
잘못 움직이면 충돌할 수 있다.
행동 실패가 실제 물리적 실패로 이어진다.

그래서 Physical AI에서는 “많이 맞히는 모델”만으로는 부족하다.

중요한 것은 다음과 같다.

모를 때 멈출 수 있는가?
불확실한 상황을 알아차릴 수 있는가?
행동 전에 한 번 더 확인할 수 있는가?

3. Perception / Planning / Control

로봇 AI를 처음 이해할 때 가장 먼저 잡아야 하는 구조는 이것이다.

Perception → Planning / Reasoning → Control / Action

Perception

Perception은 현재 상황을 보는 단계다.

예를 들어 로봇이 테이블을 본다고 하자.
이때 로봇은 단순히 이미지를 보는 것이 아니라 다음 질문에 답해야 한다.

컵이 있는가?
컵이 어디에 있는가?
컵은 파란색인가?
컵이 책 왼쪽에 있는가?
컵이 잘 보이는가?
컵이 다른 물체에 가려져 있는가?

즉, perception은 행동을 위한 장면 이해다.

우리 프로젝트에서는 실제 vision model을 만들지 않았다.
대신 사람이 미리 작성한 candidate_objects가 perception 결과처럼 쓰였다.

예를 들면 다음과 같다.

{
  "obj_id": "cup_blue_left_01",
  "category": "cup",
  "color": "blue",
  "bbox": [12, 35, 88, 140],
  "visibility": "clear",
  "notes": "left_of_book"
}

이 정보는 실제 vision model이 봤다고 가정한 결과다.

Planning / Reasoning

Planning 또는 reasoning은 무엇을 할지 정하는 단계다.

로봇이 장면을 보고 나면 바로 움직이면 안 된다.
먼저 다음을 판단해야 한다.

instruction이 말하는 target은 무엇인가?
그 target이 충분히 명확한가?
비슷한 후보가 있는가?
지금 바로 pick 준비로 가도 되는가?
더 확인해야 하는가?
아예 보류해야 하는가?

우리 프로젝트에서 planning/reasoning에 해당하는 것은 다음과 같다.

target object 선택
subgoal label 선택
consistency score 계산
abstain 여부 판단

Control / Action

Control은 실제로 로봇을 움직이는 단계다.

예를 들면 다음과 같다.

팔을 앞으로 이동
그리퍼 닫기
joint angle 제어
trajectory 생성
end-effector를 목표 위치로 이동

하지만 이 프로젝트에서는 control을 하지 않았다.

내가 집중한 부분은 action 이전의 판단이었다.

즉, 이 프로젝트는 다음을 하지 않는다.

로봇팔 실제 제어
trajectory planning
gripper control
joint control

대신 다음을 한다.

무엇을 target으로 볼지 판단
지금 진행해도 되는지 판단
확신이 낮으면 보류

4. Day1에서 프로젝트로 녹인 것

Day1에는 프로젝트 범위를 정했다.

로봇팔 제어를 하지 않는다.
전체 mobile manipulation을 구현하지 않는다.
대신 action 이전의 target / subgoal / abstain 판단을 만든다.

이렇게 범위를 줄이니 공부해야 할 대상이 훨씬 명확해졌다.

Day1의 핵심 문장은 다음과 같다.

이 프로젝트는 로봇을 움직이는 프로젝트가 아니라,
로봇이 움직이기 전에 무엇을 해야 할지 판단하는 프로젝트다.

Day2. 입력과 출력 스키마 정의

1. 왜 스키마가 필요한가?

코드를 만들기 전에 먼저 정해야 할 것이 있었다.

입력은 무엇인가?
출력은 무엇인가?
정답은 무엇인가?

이게 없으면 나중에 코드가 전부 흔들린다.

예를 들어 어떤 사람은 이미지만 입력이라고 생각할 수 있고,
어떤 사람은 이미지와 instruction을 입력이라고 생각할 수 있다.
또 어떤 사람은 output이 target만 있으면 된다고 생각할 수 있고,
다른 사람은 subgoal과 confidence까지 있어야 한다고 생각할 수 있다.

그래서 Day2에는 입력과 출력 스키마를 정했다.

스키마는 단순한 형식이 아니다.
이 프로젝트가 어떤 문제를 푸는지 보여주는 계약이다.

2. 입력 구조

입력은 크게 세 가지다.

scene_id
instruction
candidate_objects

예를 들어 다음과 같다.

{
  "scene_id": "scene_101",
  "instruction": "책 왼쪽의 파란 컵을 집어",
  "candidate_objects": [
    {
      "obj_id": "cup_blue_left_01",
      "category": "cup",
      "color": "blue",
      "bbox": [12, 35, 88, 140],
      "visibility": "clear",
      "notes": "left_of_book"
    }
  ]
}

여기서 중요한 것은 candidate_objects다.

처음부터 object detector를 학습하지 않고,
이미지 속 후보 객체들이 있다고 가정했다.

즉, 프로젝트의 핵심을 detection이 아니라 grounding과 decision으로 좁힌 것이다.

3. candidate object의 의미

candidate object는 target이 될 수 있는 후보 객체다.

예를 들어 이미지에 다음 물체들이 있다고 하자.

파란 컵
빨간 병
흰 책

그러면 candidate object는 다음처럼 표현할 수 있다.

{
  "obj_id": "cup_blue_left_01",
  "category": "cup",
  "color": "blue",
  "bbox": [12, 35, 88, 140],
  "visibility": "clear",
  "notes": "left_of_book"
}

각 필드는 다음 의미를 가진다.

특히 obj_id가 중요하다.

로봇은 “컵”이라는 종류를 집는 것이 아니라,
장면 속 특정 컵 하나를 집어야 하기 때문이다.

4. 출력 구조

출력은 다음과 같이 정했다.

pred_target_obj_id
pred_subgoal_label
consistency_score
abstain
reason

예를 들면 다음과 같다.

{
  "pred_target_obj_id": "cup_blue_left_01",
  "pred_subgoal_label": "PREPARE_PICK",
  "consistency_score": 0.85,
  "abstain": false,
  "reason": "A clear candidate matches the instruction."
}

각 필드는 다음 의미를 가진다.

5. subgoal label

우리는 subgoal을 세 가지로 단순화했다.

PREPARE_PICK
REFINE_VIEW
ABSTAIN_DECISION

PREPARE_PICK

target이 비교적 명확하고 다음 단계로 진행 가능하다는 뜻이다.

REFINE_VIEW

target 후보는 있지만 ambiguity가 남아 있어 한 번 더 확인해야 한다는 뜻이다.

ABSTAIN_DECISION

현재 정보로는 진행하면 위험하므로 보류해야 한다는 뜻이다.

6. Day2에서 기억할 것

Day2에서 가장 중요했던 것은 스키마를 정하는 일이었다.

스키마는 단순한 데이터 형식이 아니라,
이 프로젝트의 문제 정의를 코드로 고정한 것이다.

Day2의 핵심 문장은 다음과 같다.

입력 = scene + instruction + candidate objects
출력 = target + subgoal + score + abstain + reason

이 구조가 있어야 이후 Day3, Day4, Day5가 쌓일 수 있었다.

Day3. Grounding과 Target Selection

1. Grounding이란?

Grounding은 언어가 가리키는 대상을 실제 장면 속 객체와 연결하는 과정이다.

예를 들어 다음 instruction이 있다고 하자.

책 왼쪽의 파란 컵을 집어

그리고 candidate objects가 다음과 같다고 하자.

cup_blue_left_01
bottle_red_right_01
book_center_01

이때 grounding 결과는 다음이어야 한다.

cup_blue_left_01

즉, grounding은 단순히 “컵이 있다”를 찾는 것이 아니다.

지시문이 말하는 바로 그 컵이 무엇인가?

를 찾는 것이다.

2. Detection과 Grounding 차이

Detection은 이미지 속에 뭐가 있는지 찾는 문제다.

cup
bottle
book

Grounding은 instruction이 말하는 특정 대상을 고르는 문제다.

책 왼쪽의 파란 컵 = cup_blue_left_01

이 둘은 다르다.

Detection이 “무엇이 있나?”라면,
Grounding은 “이 말이 가리키는 것은 무엇인가?”다.

3. Instance-level이 중요한 이유

로봇은 “컵”이라는 category를 집는 게 아니다.
로봇은 장면 속 특정 컵 하나를 집는다.

category-level: cup
instance-level: cup_blue_left_01

그래서 Day3에서는 obj_id가 중요했다.

만약 파란 컵이 두 개라면 어떻게 될까?

cup_blue_left_front_01
cup_blue_left_back_02

둘 다 category는 cup이고 color는 blue다.
하지만 로봇이 실제로 집어야 하는 것은 둘 중 하나다.

그래서 target은 category가 아니라 instance로 고정되어야 한다.

4. Day3 데이터

Day3에서는 candidate object와 ground truth를 만들었다.

예를 들면 다음과 같다.

{"scene_id":"scene_101","instruction":"책 왼쪽의 파란 컵을 집어","candidate_objects":[{"obj_id":"cup_blue_left_01","category":"cup","color":"blue","bbox":[12,35,88,140],"visibility":"clear","notes":"left_of_book"},{"obj_id":"bottle_red_right_01","category":"bottle","color":"red","bbox":[120,30,180,150],"visibility":"clear","notes":"right_of_book"},{"obj_id":"book_center_01","category":"book","color":"white","bbox":[70,60,130,160],"visibility":"clear","notes":"center"}]}

정답은 이렇게 붙였다.

{"scene_id":"scene_101","gt_target_obj_id":"cup_blue_left_01","gt_target_bbox":[12,35,88,140],"gt_subgoal_label":"PREPARE_PICK","gt_should_abstain":false}

여기서 중요한 것은 gt_target_obj_id다.
이 값이 instruction이 실제로 가리키는 정답 target이다.

5. Day3 baseline

Day3에서는 아주 단순한 baseline을 만들었다.

핵심 아이디어는 다음과 같다.

instruction과 candidate object를 비교해서 점수를 준다.
점수가 가장 높은 후보를 target으로 고른다.

점수는 대략 다음 정보를 사용했다.

category가 instruction에 있는가?
color가 instruction에 있는가?
notes가 instruction과 관련 있는가?
visibility가 clear인가?

예를 들어 cup_blue_left_01은 다음 이유로 높은 점수를 받을 수 있다.

category = cup
color = blue
notes = left_of_book
visibility = clear

반대로 bottle_red_right_01은 instruction과 덜 맞기 때문에 낮은 점수를 받는다.

이 baseline은 똑똑한 모델이 아니다.
하지만 데이터 구조가 실제 예측 흐름으로 이어지는지 확인하기에는 충분했다.

6. Day3에서 기억할 것

Day3에서 가장 중요했던 것은 grounding이다.

Grounding은 언어와 장면을 연결하는 과정이다.
Target object는 category가 아니라 instance로 정해야 한다.
candidate_objects는 vision 결과처럼 쓰였다.
Day3 baseline은 instruction과 후보를 비교해 target을 고르는 첫 번째 시도였다.

Day3의 핵심 문장은 다음과 같다.

로봇은 “컵”을 집는 것이 아니라,
instruction이 가리키는 장면 속 특정 컵 하나를 집어야 한다.

Day4. Subgoal과 Reasoning before Action

1. Subgoal이란?

Subgoal은 최종 목표 전에 필요한 중간 목표다.

예를 들어 최종 목표가 “컵을 집어라”라면,
그 전에 이런 판단이 필요하다.

target이 누구인가?
지금 장면이 충분히 명확한가?
바로 pick 준비로 가도 되는가?
더 봐야 하는가?
멈춰야 하는가?

즉, subgoal은 최종 action으로 바로 가기 전에 두는 중간 판단이다.

2. 우리 프로젝트의 subgoal label

우리는 subgoal을 세 가지로 단순화했다.

PREPARE_PICK

target이 비교적 명확하고 다음 단계로 진행 가능하다.

예를 들어 파란 컵이 하나만 분명히 보인다면 PREPARE_PICK이 자연스럽다.

REFINE_VIEW

target 후보는 있지만 ambiguity가 남아 있다.
한 번 더 확인이 필요하다.

예를 들어 파란 컵이 두 개라면, target 후보는 있지만 바로 집기에는 애매하다.

ABSTAIN_DECISION

현재 정보로는 진행하면 위험하다.
지금은 보류해야 한다.

예를 들어 instruction은 노란 컵을 말하는데 scene에는 노란 컵이 없다면 abstain해야 한다.

3. Reasoning before Action

Day4에서 가장 중요했던 개념은 reasoning before action이다.

이건 바로 행동하지 않고 먼저 판단하는 것이다.

target이 맞는가?
1등 후보와 2등 후보가 비슷한가?
visibility가 너무 낮은가?
confidence가 충분한가?

이 판단을 통해 action 이전에 위험한 결정을 줄일 수 있다.

로봇이 바로 움직이면 위험할 수 있다.
특히 target이 애매하거나 시야가 안 좋을 때는 더 그렇다.

그래서 Day4에서는 target을 고르는 것에서 끝나지 않고,
그 다음 상태가 무엇인지 해석했다.

4. Day4에서 프로젝트에 녹인 것

Day4에서는 새로운 거대한 모델을 만든 것이 아니다.

Day3 baseline 결과를 사람이 이해할 수 있도록 reasoning 설명을 붙였다.

예를 들어 prediction이 이렇게 나오면:

{
  "pred_target_obj_id": "cup_blue_left_front_01",
  "pred_subgoal_label": "REFINE_VIEW",
  "consistency_score": 0.55,
  "abstain": false
}

이걸 다음처럼 해석했다.

target 후보는 있지만 ambiguity가 남아서 한 번 더 확인 필요
score는 애매한 상태
abstain은 하지 않았지만 바로 action으로 가기엔 불안정함

5. Day4에서 기억할 것

Day4는 target을 고르는 것에서 끝나지 않는다.

지금 바로 진행할지
더 볼지
멈출지

를 판단하는 날이었다.

Day4의 핵심 문장은 다음과 같다.

로봇은 target을 고른 뒤에도 바로 움직이면 안 된다.
그 target 판단이 충분히 믿을 만한지 먼저 확인해야 한다.

Day5. Mobile-like Scene과 Mobile Manipulation의 어려움

1. 왜 Day5가 필요했나?

Day3~Day4는 tabletop scene에 가까웠다.

대상이 비교적 가까이 있음
장면이 단순함
target이 이미 후보 안에 있음

하지만 mobile manipulation에서는 다르다.

target이 멀리 있을 수 있음
처음부터 안 보일 수 있음
비슷한 target이 여러 위치에 있을 수 있음
기준 물체와 target이 함께 등장함
보이지만 닿지 않을 수 있음

그래서 Day5에서는 mobile-like scene을 추가했다.

2. Fixed-base manipulation과 Mobile manipulation

Fixed-base manipulation은 로봇 베이스가 고정된 상태에서 팔만 움직여 물체를 조작하는 문제다.

예를 들면 공장 로봇팔이 있다.

로봇팔은 고정되어 있음
앞에 테이블이 있음
테이블 위 물체를 집거나 옮김

반면 mobile manipulation은 로봇이 이동하면서 물체를 조작하는 문제다.

바퀴 달린 베이스
+
로봇팔
+
카메라 / 센서

예를 들면 다음과 같다.

주방으로 이동
→ 테이블 위 컵 찾기
→ 컵 앞까지 접근
→ 팔로 컵 집기

이때는 단순히 팔을 어떻게 움직일지만 보면 안 된다.

어디로 가야 하는가?
target이 보이는가?
팔이 닿는가?
현재 위치에서 조작 가능한가?
이동하면 시야가 어떻게 바뀌는가?

까지 봐야 한다.

3. Day5에서 만든 scene

Day5에서는 다음과 같은 scene을 만들었다.

scene_201: target이 멀고 잘 안 보임
scene_202: reference object와 target 분리
scene_203: target은 보이지만 unreachable 가능성
scene_204: 비슷한 target이 여러 위치에 있음
scene_205: target이 기준 물체 뒤에 숨어 있음

4. Day5 실험의 목적

Day5는 baseline을 잘 맞히게 만드는 날이 아니었다.

오히려 목적은 반대였다.

기존 Day3~4 baseline이 mobile-like scene에서 어디서 무너지는지 확인하기

결과는 예상대로 많이 틀렸다.

예를 들어:

scene_202:
instruction = 책장 옆의 빨간 병을 잡아
정답 = bottle_red_side_01
예측 = shelf_left_01

baseline은 기준 물체인 shelf를 target으로 착각했다.

5. Day5에서 드러난 한계

Day5 결과로 다음 한계를 확인했다.

reference object와 target object를 구분하지 못함
visibility가 낮은 target보다 잘 보이는 물체를 선호함
거리/깊이 정보를 이해하지 못함
reachable 여부를 판단하지 못함
틀렸는데도 높은 confidence를 줄 수 있음

6. Day5에서 기억할 것

Day5의 핵심은 다음과 같다.

Mobile-like scene에서는 단순 keyword baseline이 쉽게 무너진다.
이유는 target grounding이 단순 category/color matching 문제가 아니기 때문이다.

mobile manipulation에서는 target이 보이는가뿐 아니라,
어디에 있는가, 얼마나 보이는가, 기준 물체와 어떤 관계인가, 실제 접근 가능한가까지 중요해진다.

Day6. Failure Analysis

1. 왜 실패 분석이 필요한가?

Day5에서 baseline이 틀렸다는 것만으로는 부족하다.

중요한 것은 이것이다.

왜 틀렸는가?
어떤 종류의 실패인가?
그 실패는 mobile manipulation에서 왜 중요한가?

그래서 Day6에서는 failure taxonomy를 만들었다.

2. Failure Taxonomy

TARGET_MISMATCH

예측 target이 정답 target과 다른 경우다.

예를 들어 정답은 bottle_red_side_01인데 예측이 shelf_left_01이면 target mismatch다.

SUBGOAL_MISMATCH

예측 subgoal이 정답 subgoal과 다른 경우다.

예를 들어 정답은 ABSTAIN_DECISION인데 예측이 PREPARE_PICK이면 subgoal mismatch다.

MISSED_ABSTAIN

정답은 abstain해야 하는데 모델이 진행한 경우다.

로봇에서는 위험한 실패다.

예를 들어 target이 거의 보이지 않는데도 진행한다고 판단하면, 실제 action에서 위험할 수 있다.

WRONG_ABSTAIN

진행 가능한 상황인데 모델이 너무 보수적으로 abstain한 경우다.

이 경우는 안전할 수 있지만, 너무 자주 발생하면 로봇이 아무것도 하지 못하는 문제가 생길 수 있다.

OVERCONFIDENT_WRONG_DECISION

틀렸는데도 높은 confidence로 진행하는 경우다.

이건 신뢰성 측면에서 가장 위험하다.

예를 들어 틀린 target을 골랐는데 consistency_score = 0.85이고 abstain = false라면, 시스템은 틀렸는데도 자신 있게 진행하는 것이다.

VISIBILITY_BIAS

정답 target은 잘 안 보이는데, 모델이 잘 보이는 주변 물체를 고른 경우다.

모바일 환경에서는 target이 멀거나 가려질 수 있다.
이때 단순 baseline은 잘 보이는 물체를 과하게 선호할 수 있다.

REFERENCE_OBJECT_CONFUSION

기준 물체를 target으로 착각한 경우다.

예를 들어 다음 instruction이 있다고 하자.

책장 옆의 빨간 병을 잡아

여기서 책장은 기준 물체이고, 병이 target이다.

하지만 baseline은 책장을 target으로 잘못 고를 수 있다.

DISTANCE_OR_DEPTH_MISUNDERSTANDING

거리나 깊이 정보를 제대로 이해하지 못한 경우다.

예를 들어 다음 instruction이 있다고 하자.

왼쪽 복도 끝의 파란 컵을 집어

이때 가까운 파란 컵과 복도 끝의 파란 컵이 둘 다 있다면,
단순 baseline은 가까운 컵을 고를 수 있다.

REACHABILITY_BLINDNESS

target이 보여도 실제로 닿을 수 있는지 판단하지 못하는 경우다.

mobile manipulation에서는 target이 보인다고 끝이 아니다.

보임 ≠ 닿음
보임 ≠ 조작 가능

로봇의 현재 위치, 팔 길이, 장애물, 접근 각도까지 고려해야 한다.

3. Day6에서 기억할 것

Day6의 핵심은 모델을 더 좋게 만드는 것이 아니라,
모델의 실패를 읽는 눈을 만드는 것이었다.

틀렸다 → 끝

이 아니라,

어떤 종류로 틀렸는가?
왜 위험한가?
어떻게 개선할 수 있는가?

로 가야 한다.

Day6의 핵심 문장은 다음과 같다.

좋은 로봇 판단 시스템은 정답률만 보는 것이 아니라,
틀렸을 때 어떤 방식으로 틀리는지까지 분석해야 한다.

Day7. 프로젝트를 연구 이야기로 묶기

1. Day7이 필요한 이유

Day1~Day6는 각각 보면 작은 작업이다.

하지만 묶으면 하나의 연구 방향이 된다.

전체 이야기는 이렇게 정리할 수 있다.

mobile manipulation을 위한 VLA에 관심이 있다.
하지만 처음부터 full VLA나 low-level control을 구현하기에는 범위가 크다.
그래서 action 이전 단계의 grounded decision 문제로 줄였다.

2. 프로젝트의 최종 의미

이 프로젝트는 로봇을 움직인 프로젝트가 아니다.

하지만 로봇이 움직이기 전에 필요한 판단 구조를 만들었다.

instruction + candidate objects
→ target selection
→ subgoal decision
→ consistency scoring
→ abstention

즉, 이 프로젝트는 VLA action output 이전에 필요한 decision verification layer를 작게 검증한 것이다.

3. 연구 방향으로 연결하기

Day5~Day6에서 중요한 한계를 확인했다.

reference object와 target object 구분 실패
visibility bias
distance/depth 이해 부족
reachability blindness
overconfident wrong decision

이건 mobile manipulation에서 매우 중요한 문제다.

따라서 다음 연구 질문은 이렇게 잡을 수 있다.

VLA가 action을 내기 전에,
target grounding과 subgoal reasoning의 신뢰성을 어떻게 점검할 수 있을까?

또는 다음처럼 말할 수도 있다.

mobile manipulation에서 reference object, visibility, distance, reachability를 반영한 grounded decision layer를 만들 수 있을까?

4. 최종 정리 문장

이 프로젝트를 한 문장으로 정리하면 다음과 같다.

이 프로젝트는 mobile manipulation을 위한 VLA를 바로 구현하기보다,
action 이전 단계의 target grounding, short-horizon subgoal selection,
consistency scoring, abstention을 작게 검증한 grounded decision toy-project다.

전체 회고

처음에는 VLA를 “이미지와 문장을 넣으면 로봇 행동이 나오는 모델” 정도로 생각했다.

하지만 7일 동안 작은 toy-project를 만들면서,
진짜 중요한 것은 action 이전의 판단이라는 걸 알게 됐다.

로봇은 바로 움직이면 안 된다.

먼저 봐야 한다.

무엇을 target으로 볼 것인가?
그 target이 진짜 instruction이 말한 대상인가?
지금 장면이 충분히 명확한가?
더 봐야 하는가?
보류해야 하는가?

이 질문들이 해결되지 않으면,
action이 아무리 좋아도 로봇은 실패할 수 있다.

그래서 이번 toy-project는 작지만 의미가 있었다.

나는 실제 로봇팔을 움직이지 않았지만,
로봇이 행동하기 전에 필요한 판단 구조를 작게 만들어봤다.

그리고 mobile-like scene을 넣었을 때 baseline이 어떻게 무너지는지 확인했다.

이 결과를 바탕으로, 앞으로는 다음 방향을 더 보고 싶다.

target object와 reference object를 구분하는 grounding
visibility / distance / reachability를 반영한 consistency score
uncertainty-aware abstention
mobile manipulation을 위한 grounded decision verification layer

지금은 시작 단계지만,
적어도 VLA를 그냥 큰 모델로 보는 게 아니라
행동 이전의 판단 구조로 쪼개서 볼 수 있게 됐다.

이게 이번 7일의 가장 큰 수확이다.

``` https://github.com/jjongjjongR/grounded-decision-core

※ 이 글은 Moo Jin Kim 외, 「OpenVLA: An Open-Source Vision-Language-Action Model」을 읽고, 제 방식대로 다시 정리한 글입니다.
OpenVLA는 이미지와 자연어 명령을 입력받아 로봇의 행동을 출력하는 7B 규모의 오픈소스 Vision-Language-Action 모델입니다.

한 줄 요약

OpenVLA는 이미지를 보고, 자연어 명령을 이해한 뒤, 로봇이 실행할 7차원 행동을 출력하는 오픈소스 VLA 모델이다.

조금 더 쉽게 말하면 이렇다.

기존에는 RT-2처럼 강력한 VLA 모델들이 있었지만, 대부분 닫혀 있었다.
모델 구조를 자세히 보기 어렵고, 학습 방식도 제한적이고, 내가 가진 로봇 환경에 맞게 직접 실험하기도 쉽지 않았다.

OpenVLA는 이 문제를 정면으로 건드린다.

“로봇을 위한 거대 모델이 필요하다면, 적어도 연구자들이 직접 뜯어보고, 돌려보고, 고쳐볼 수 있어야 하지 않을까?”

이 논문의 핵심은 단순히 성능이 좋다는 게 아니다.
VLA 연구를 ‘닫힌 데모’에서 ‘실제로 실험 가능한 오픈소스 기반’으로 끌어내렸다는 점이 더 중요하다.

이 논문이 나온 이유

RT-2 같은 VLA 모델은 꽤 충격적이었다.

기존 로봇은 보통 정해진 환경에서, 정해진 물체를, 정해진 방식으로 다루는 데 강했다.
그런데 RT-2 계열은 인터넷 규모의 이미지·언어 지식을 가진 VLM을 로봇 행동까지 출력하도록 fine-tuning하면, 처음 보는 물체나 지시에도 어느 정도 대응할 수 있다는 가능성을 보여줬다.

하지만 문제가 있었다.

좋은 모델이 나왔는데, 대부분 닫혀 있었다.

OpenVLA 논문은 기존 VLA가 널리 쓰이기 어려웠던 이유를 크게 두 가지로 본다.

첫 번째, 기존 VLA 모델들이 대부분 closed-source였다.
모델 구조, 학습 절차, 데이터 구성, fine-tuning 방식이 충분히 공개되지 않으면 연구자가 직접 검증하거나 확장하기 어렵다.

두 번째, 새로운 로봇이나 새로운 작업에 맞게 효율적으로 fine-tuning하는 방법이 충분히 탐구되지 않았다.
로봇 연구에서 중요한 건 “데모 영상이 멋있다”가 아니다.
내가 가진 로봇, 내가 가진 카메라, 내가 만든 환경에서도 쓸 수 있어야 한다.

OpenVLA는 이 문제를 해결하기 위해 나온 모델이다.

이 논문이 푸는 문제

OpenVLA가 푸는 문제는 한 문장으로 정리하면 이거다.

“인터넷 규모의 시각-언어 지식을 가진 모델을 로봇 행동 정책으로 바꾸되, 연구자가 실제로 사용할 수 있을 만큼 열어두자.”

여기서 중요한 문제는 세 가지다.

1) 로봇 정책의 일반화 문제

로봇은 학습 데이터 안에서는 잘할 수 있다.

하지만 배경이 바뀌거나, 물체가 바뀌거나, 지시문이 조금 달라지면 성능이 크게 흔들린다.
예를 들어 학습 때는 빨간 컵만 봤는데 실제 환경에는 파란 컵이 있다거나, 물체 위치가 달라진다거나, 주변에 방해 물체가 생기면 실패할 수 있다.

OpenVLA는 이런 문제를 vision-language foundation model의 사전 지식으로 완화하려고 한다.

2) 기존 VLA의 접근성 문제

RT-2-X 같은 모델은 강력하지만, 연구자가 내부를 충분히 뜯어보기 어렵다.

모델이 닫혀 있으면 이런 질문을 직접 실험하기 힘들다.

• 어떤 vision encoder를 썼을 때 좋은가?
• action을 어떤 방식으로 tokenization했는가?
• 새로운 로봇에 fine-tuning하려면 어떻게 해야 하는가?
• 데이터 mixture를 바꾸면 성능이 어떻게 달라지는가?
• quantization이나 LoRA를 쓰면 어디까지 가벼워지는가?

OpenVLA는 이 지점에서 의미가 있다.
모델과 코드, 학습 흐름을 열어두면서 VLA 연구의 출발선을 낮췄다.

3) 새로운 로봇 환경에 적응하는 문제

현실에서 모든 연구자가 64개 A100 GPU를 가지고 처음부터 VLA를 학습할 수는 없다.

그래서 중요한 건 “처음부터 학습”이 아니라,
이미 학습된 VLA를 내 로봇과 내 작업에 맞게 얼마나 효율적으로 적응시킬 수 있느냐다.

OpenVLA는 이 부분을 위해 LoRA fine-tuning, quantization inference 같은 현실적인 전략도 함께 다룬다.

왜 지금 이 문제가 중요한가

요즘 로봇 연구의 흐름은 단순한 제어기 설계에서 점점 멀어지고 있다.

물론 제어도 중요하다.
하지만 더 큰 병목은 이제 이런 질문에 가깝다.

“로봇이 지금 보고 있는 장면에서 무엇이 중요한지 이해할 수 있는가?”

“사람의 자연어 명령을 물리적 행동으로 연결할 수 있는가?”

“처음 보는 물체나 환경에서도 어느 정도 버틸 수 있는가?”

기존 imitation learning은 특정 데이터셋 안에서는 강하다.
하지만 환경이 바뀌면 약해진다.

반면 CLIP, SigLIP, Llama 2 같은 foundation model은 인터넷 규모 데이터에서 학습한 시각·언어 지식을 갖고 있다. :OpenVLA는 이 지점을 기회로 봤다.

로봇 데이터는 아직 인터넷 데이터만큼 크지 않다.
그렇다면 이미 세상을 어느 정도 이해하는 vision-language model을 기반으로 쓰고, 그 위에 로봇 행동 능력을 붙이는 방식이 더 현실적일 수 있다.

내가 보기엔 이게 VLA의 핵심이다.

로봇이 똑똑해지는 방향이

모든 행동을 처음부터 많이 연습한다

에서

이미 세상을 어느 정도 이해하는 모델에 행동 능력을 붙인다

로 이동하고 있다.

OpenVLA의 핵심 아이디어

OpenVLA의 핵심 아이디어는 생각보다 단순하다.

VLM을 가져와서, 자연어 대신 로봇 행동 토큰을 출력하게 만든다.

OpenVLA는 Prismatic-7B VLM을 기반으로 한다.
구조적으로는 크게 세 부분으로 나뉜다.

1. DINOv2 + SigLIP vision encoder
2. visual feature를 LLM embedding space로 보내는 projector
3. Llama 2 7B language model backbone

흐름은 이렇다.

로봇 카메라 이미지 + 자연어 명령
        ↓
DINOv2 + SigLIP vision encoder
        ↓
MLP projector
        ↓
Llama 2 7B
        ↓
action token 예측
        ↓
action de-tokenizer
        ↓
7D robot action

예를 들어 사람이 이렇게 말한다고 해보자.

"가지를 그릇에 담으세요."

그러면 OpenVLA는 이미지를 보고, 명령을 이해한 뒤, 로봇이 실제로 움직일 수 있는 행동값을 출력한다.

즉, OpenVLA는 “답변 문장”을 생성하는 모델이 아니라,
로봇이 실행할 행동을 생성하는 모델이다.

입력과 출력

OpenVLA의 입력은 크게 두 가지다.

입력 1) 로봇이 보고 있는 이미지

로봇 카메라가 본 장면이다. 예를 들어 테이블 위에 컵, 접시, 냄비, 병, 장애물 등이 있을 수 있다.

입력 2) 자연어 명령

사람이 로봇에게 주는 지시다. 예시는 이런 식이다.

가지를 그릇에 넣으세요.
테이블을 닦으세요.
빨간 병을 그릇에 넣으세요.

출력) 7차원 로봇 행동

OpenVLA는 최종적으로 7D robot action을 출력한다. 논문 Figure 2 기준으로 출력은 대략 다음과 같은 형태다.

Δx, Δy, Δz, Δroll, Δpitch, Δyaw, Δgrip

쉽게 말하면 로봇 팔의 위치 변화, 회전 변화, 그리퍼 열기/닫기 같은 값이다.

여기서 중요한 점이 있다. OpenVLA는 기본적으로

target object
subgoal
reason
abstain flag

를 직접 출력하는 모델이 아니다. OpenVLA의 기본 출력은 어디까지나 로봇이 바로 실행할 action이다.

이게 내 탑다운 프로젝트와 연결할 때 정말 중요하다. 내 프로젝트에서 다루려는 건 단순 action output이 아니라,

어떤 물체를 잡아야 하는가?
지금 바로 잡아도 되는가?
시야를 더 조정해야 하는가?
불확실하면 멈춰야 하는가?

같은 행동 전 판단이다.

그래서 내 프로젝트에서는 OpenVLA를 그대로 끝까지 쓰는 게 아니라,
OpenVLA 앞뒤에 reasoning layer, safety gate, evaluation layer를 붙이는 방향이 더 맞다고 판단했다.

Action Tokenization: 왜 행동을 토큰으로 바꾸는가

이 논문에서 꼭 이해해야 하는 부분이 action tokenization이다.

로봇 행동은 원래 숫자다. 예를 들어 팔을 x축으로 얼마나 움직일지, y축으로 얼마나 움직일지, gripper를 열지 닫을지 같은 값이다.

그런데 Llama 2 같은 언어 모델은 기본적으로 “다음 토큰”을 예측하는 구조다.
즉, 연속적인 로봇 행동값을 그대로 출력하는 데 최적화된 모델이 아니다.

그래서 OpenVLA는 로봇 행동을 토큰처럼 바꾼다.

논문에서는 각 action dimension을 256개 bin으로 나눈다.
그리고 각 행동값을 그 bin 중 하나에 매핑한다.

쉽게 말하면 이런 느낌이다.

원래 행동값:
x축으로 0.034 이동

토큰화 후:
action_token_128

이렇게 하면 로봇 행동도 LLM이 다룰 수 있는 “단어”처럼 바뀐다.

그래서 OpenVLA는 문장을 생성하듯이 action token을 생성하고,
그 action token을 다시 실제 로봇 행동값으로 변환한다.

내가 이 부분에서 느낀 핵심은 이거다.

로봇 행동을 언어 모델이 다룰 수 있는 형태로 바꾸면, 기존 VLM/LLM 학습 인프라를 그대로 가져올 수 있다.

이게 VLA가 강력해지는 이유 중 하나다.

모델 구조를 조금 더 깊게 보기

OpenVLA는 크게 세 덩어리로 볼 수 있다.

1. Vision Encoder: DINOv2 + SigLIP

OpenVLA는 vision encoder로 DINOv2와 SigLIP을 같이 쓴다.

내 식으로 이해하면 역할이 조금 다르다.

SigLIP은 이미지와 언어의 의미적 연결에 강하다.
예를 들어 “이게 컵인지”, “이게 병인지”, “명령에서 말한 물체가 뭔지”를 잡는 데 도움이 된다.

DINOv2는 공간적·시각적 feature에 강하다.
로봇은 단순히 “컵이다”만 알면 안 된다.
컵이 어디에 있는지, 어느 쪽이 잡기 쉬운지, 주변 물체와 어떻게 떨어져 있는지도 중요하다.

그래서 OpenVLA는 두 vision encoder의 feature를 함께 사용한다.

이건 로봇 제어에서 꽤 중요한 선택이다.
로봇은 의미만 알아서는 안 되고, 위치와 공간 관계까지 이해해야 하기 때문이다.

2. Projector: 시각 정보를 언어 모델 공간으로 보내는 다리

vision encoder가 뽑은 feature는 그대로 Llama 2가 이해할 수 없다. 그래서 중간에 projector가 필요하다.

projector는 이미지 feature를 LLM이 이해할 수 있는 embedding space로 바꿔주는 다리 역할을 한다.

쉽게 말하면

이미지 쪽 언어 → Llama가 이해할 수 있는 언어

로 번역해주는 모듈이다.

3. Llama 2 7B: action token을 예측하는 backbone

마지막으로 Llama 2 7B가 action token을 예측한다. 여기서 헷갈리면 안 된다.

OpenVLA는 ChatGPT처럼 길게 reasoning text를 출력하는 모델이라기보다,
이미지와 명령을 조건으로 다음 행동을 바로 예측하는 정책 모델에 가깝다.

RT-2 리뷰에서는 CoT 이야기가 중요했다면,
OpenVLA에서는 중심이 조금 다르다.

OpenVLA의 핵심은

생각을 길게 말한다

가 아니라,

오픈소스 VLM을 action policy로 바꾸고, 실제 fine-tuning 가능한 형태로 공개했다

에 가깝다.

학습 데이터: 970K robot episodes

OpenVLA는 Open X-Embodiment 데이터셋을 기반으로 학습된다.

논문 기준으로 OpenVLA는 970K real-world robot demonstrations를 사용한다.
여기서 중요한 건 단순히 데이터가 많다는 게 아니다.

OpenVLA는 다양한

robot embodiment
scene
task

를 담으려고 한다.

그래야 특정 로봇 하나에만 맞는 정책이 아니라, 여러 로봇과 여러 환경에서 어느 정도 작동하는 generalist policy가 될 수 있기 때문이다.

다만 Open X-Embodiment 데이터를 전부 그대로 쓰는 건 아니다.
논문에서는 학습에 적합한 형태로 데이터를 filtering하고, 데이터 mixture를 조정한다.

여기서 내가 가져간 핵심은 이거다.

VLA 성능은 모델 구조만으로 결정되지 않는다.
어떤 데이터를 어떻게 섞었는지가 정말 중요하다.

OpenVLA가 7B 규모인데도 RT-2-X 55B와 경쟁하거나 일부 실험에서 더 강하게 나온 이유도 단순히 모델이 좋아서만은 아니다.
데이터 구성, cleaning, vision backbone, action representation이 함께 작용한 결과라고 보는 게 맞다.

학습 과정에서의 중요한 선택들

OpenVLA 논문은 단순히 “큰 모델을 학습했더니 잘 됐다”가 아니다.
중간중간 실용적인 선택들이 꽤 많다.

1. Backbone 선택

OpenVLA는 최종적으로 Prismatic-7B VLM을 사용한다.

초기에는 여러 VLM backbone을 비교했고, Prismatic이 더 좋은 성능을 보였다고 설명한다.
특히 DINOv2와 SigLIP을 함께 쓰는 fused vision encoder가 공간 이해에 도움이 된다고 본다.

내 프로젝트 관점에서는 이 부분이 중요하다.

나는 mobile manipulation을 보고 있다, 단순히 “물체 이름을 맞히는 능력”보다
따라서, 물체의 위치, 거리, 가려짐, 잡을 수 있는 상태를 이해하는 능력이 더 중요해진다.

2. 이미지 해상도

OpenVLA는 224×224와 384×384 입력을 비교했다.

흥미로운 건, 384×384가 더 크지만 평가 성능 차이가 크지 않았고 학습 비용은 훨씬 커졌다는 점이다.
그래서 최종 OpenVLA는 224×224 입력을 사용한다.

이건 나한테도 중요하다.

처음부터 고해상도에 집착할 필요가 없다.
먼저 interface, schema, evaluation을 고정하고, 해상도는 나중에 실험 변수로 둬도 된다.

3. Vision encoder를 freeze하지 않음

일반적인 VLM 학습에서는 vision encoder를 freeze하는 경우가 많다.

하지만 OpenVLA에서는 vision encoder까지 fine-tuning하는 것이 중요했다고 설명한다.
로봇 제어에는 일반 이미지 이해보다 더 세밀한 공간 정보가 필요하기 때문이다.

이건 꽤 설득력 있다.

“컵이 있다”를 아는 것과
“컵의 어느 지점을 어느 방향에서 잡아야 한다”를 아는 것은 다르다.

로봇은 후자가 필요하다.

4. 오래 학습함

일반 LLM/VLM은 한두 epoch만 도는 경우도 많다.

하지만 OpenVLA는 최종 학습에서 27 epoch를 돈다.
논문에서는 action token accuracy가 높아질 때까지 실제 로봇 성능도 계속 증가했다고 설명한다.

이 부분도 중요하다.

VLA는 단순한 언어 모델 fine-tuning과 다르다.
로봇 행동은 조금만 틀려도 실패할 수 있기 때문에, action token 예측 정확도가 매우 중요하다.

5. 학습 비용

OpenVLA를 처음부터 학습하는 비용은 개인 프로젝트 범위가 아니다.

논문 기준 최종 학습은 64개 A100 GPU에서 14일 동안 진행되었다.
이건 “내가 처음부터 OpenVLA를 재현하겠다”가 현실적인 목표가 아니라는 뜻이다.

대신 현실적인 방향은 이거다.

1. 논문과 README로 구조 이해
2. Hugging Face checkpoint 기반 inference 흐름 확인
3. stub 기반 프로젝트 skeleton 구축
4. adapter 구조 만들기
5. 나중에 GPU 환경에서 4-bit inference 또는 LoRA fine-tuning 시도

대표 실험 1: BridgeData V2 WidowX 평가

BridgeData V2 평가는 WidowX 로봇에서 진행된다.

평가 task는 여러 일반화 축을 포함한다.

visual generalization
motion generalization
physical generalization
semantic generalization
language grounding

비교 대상은 RT-1-X, Octo, RT-2-X, OpenVLA다.

논문에서 보고한 평균 성공률은 다음과 같다.

OpenVLA는 BridgeData V2 WidowX 평가에서 가장 높은 평균 성공률을 보였다.

여기서 중요한 건 OpenVLA가 7B 규모라는 점이다.
RT-2-X는 55B 규모인데, OpenVLA는 훨씬 작은 모델로도 강한 성능을 보였다.

내가 여기서 본 핵심은 이거다.

VLA 성능은 모델 크기 싸움만이 아니다.
데이터 mixture, preprocessing, action representation, vision backbone 선택이 모두 성능에 영향을 준다.

대표 실험 2: Google Robot 평가

Google Robot 평가는 RT-1, RT-2 계열에서 사용된 mobile manipulator 기반 평가다.

이 부분은 내 관심사와도 꽤 연결된다.
나는 장기적으로 wheeled mobile manipulator을 보고 있기 때문이다.

논문에서 보고한 평균 성공률은 다음과 같다.

여기서는 OpenVLA와 RT-2-X가 둘 다 강하게 나온다.
다만 평균 성공률은 OpenVLA가 더 높게 보고된다.

이 실험이 중요한 이유는 OpenVLA가 단일 arm만 본 게 아니라, mobile manipulation 쪽에서도 평가되었다는 점이다.

하지만 여기서 조심해야 한다.

OpenVLA가 “내가 가진 완전히 새로운 모바일 매니퓰레이터에 zero-shot으로 바로 된다”는 뜻은 아니다.
새로운 robot embodiment나 새로운 setup에서는 demonstration을 모으고 fine-tuning하는 과정이 필요할 수 있다.

대표 실험 3: 새로운 Franka 로봇 환경에 fine-tuning

이 실험은 OpenVLA 논문에서 정말 실용적인 부분이다.

기존 VLA 연구는 “out-of-the-box로 얼마나 잘하냐”에 집중하는 경우가 많았다.
하지만 실제 연구자는 보통 자기 로봇, 자기 카메라, 자기 task를 갖고 있다.

그래서 중요한 질문은 이거다.

“OpenVLA를 새로운 로봇 환경에 적은 demonstration으로 빠르게 적응시킬 수 있는가?”

논문은 Franka 환경에서 fine-tuning 실험을 진행한다.
비교 대상은 Diffusion Policy, Octo, OpenVLA scratch, fine-tuned OpenVLA 등이다.

결과적으로 OpenVLA는 평균적으로 가장 강한 성능을 보인다.

다만 여기서 중요한 해석이 있다.

Diffusion Policy는 좁고 명확한 single-instruction task에서는 강하다.
반대로 OpenVLA와 Octo 같은 generalist policy는 여러 물체가 있고, language grounding이 필요한 multi-instruction task에서 더 강하다.

즉, OpenVLA가 모든 문제에서 무조건 이긴다는 뜻은 아니다.

언어 지시와 시각 grounding이 중요한 복잡한 task에서 장점이 커진다고 보는 게 맞다.

대표 실험 4: LoRA fine-tuning

OpenVLA는 7B 모델이라 full fine-tuning은 무겁다.

그래서 논문은 더 가벼운 fine-tuning 전략도 비교한다.

대표 결과는 다음과 같다.

핵심은 LoRA다.

LoRA r=32는 전체 파라미터 중 일부만 학습하면서도 full fine-tuning과 거의 비슷한 성공률을 보인다.

내 프로젝트 기준으로는 이게 정말 중요하다.

나는 OpenVLA를 처음부터 학습할 필요가 없다.
오히려 현실적인 방향은 다음과 같다.

1. OpenVLA interface를 이해한다.
2. stub policy로 skeleton을 만든다.
3. 나중에 GPU 환경에서 lightweight inference를 붙인다.
4. demonstration data를 작게 구성해서 LoRA fine-tuning 가능성을 본다.

대표 실험 5: Quantization inference

OpenVLA는 inference도 가볍지는 않다. 그래서 논문은 bfloat16, int8, int4 quantization을 비교한다.

대표 결과는 다음과 같다.

결과만 보면 4-bit가 꽤 인상적이다.

4-bit quantization은 VRAM을 크게 낮추면서도 bfloat16과 비슷한 성공률을 보였다.
반면 int8은 성능이 떨어졌는데, 논문은 이를 모델 자체의 문제라기보다 inference speed 저하로 인한 control frequency mismatch 문제로 해석한다.

내 환경 기준으로 보면 RTX 3070 8GB에서 4-bit inference를 실험해볼 가능성은 있다.
하지만 실제 실행에서는 CUDA overhead, image processing, 라이브러리 메모리까지 들어간다.

그래서 원래는 안정적으로는 12GB 이상 GPU나 remote inference server 구조를 고려하는 게 맞다.

대표 실험 6: LIBERO simulation fine-tuning

Appendix에서는 LIBERO simulation benchmark도 다룬다.

이 부분은 내 탑다운 프로젝트와 꽤 연결된다.
나는 Isaac Sim이나 simulation 기반 실험도 고려하고 있기 때문이다.

OpenVLA는 실제 로봇 데이터로 pretraining되었지만, simulation task에도 fine-tuning될 수 있음을 보여준다.

다만 simulation에서 잘 된다고 바로 real robot으로 이어지는 건 아니다.
반대로 real-world 데이터로 학습된 모델을 simulation에 맞추는 것도 domain gap이 있다.

그래서 내 프로젝트도 처음부터 “시뮬레이션에서 완벽한 OpenVLA 재현”을 목표로 잡으면 안 된다.

먼저 해야 할 건 이거다.

interface
schema
adapter
evaluation
logging

이 구조를 먼저 세우고, 그 다음 simulation 연결을 붙이는 게 맞다.

OpenVLA의 주요 기여

OpenVLA의 기여는 크게 네 가지로 볼 수 있다.

1. 오픈소스 generalist VLA 공개

OpenVLA는 model checkpoint, PyTorch training pipeline, fine-tuning notebook, codebase를 공개한다.

이건 단순한 공개가 아니다.
로봇 VLA 연구에서 재현 가능성과 확장 가능성을 높였다는 점이 크다.

2. 7B 규모로 RT-2-X와 경쟁

OpenVLA는 7B 규모지만, 55B 규모의 RT-2-X와 경쟁하거나 일부 평가에서 더 좋은 성능을 보인다.

이건 모델 크기만 중요한 게 아니라는 걸 보여준다.

데이터 구성
vision backbone
action tokenization
fine-tuning 방식
평가 환경

이런 요소들이 모두 중요하다.

3. Fine-tuning 가능성을 본격적으로 다룸

OpenVLA는 “그냥 zero-shot으로 써보세요”에서 끝나지 않는다.

새로운 Franka 환경에서 fine-tuning 실험을 진행하고,
OpenVLA가 Diffusion Policy나 Octo와 비교해 어떤 상황에서 강한지 보여준다.

특히 language grounding이 필요한 multi-task 환경에서 장점이 드러난다.

4. LoRA와 quantization으로 접근성 개선

LoRA fine-tuning과 4-bit quantization은 OpenVLA를 연구자 개인이 다룰 수 있는 방향으로 끌어내린다.

물론 여전히 가볍진 않다.

하지만,'대형 연구소만 가능한 모델'에서 '개인도 구조를 이해하고 일부 실험은 해볼 수 있는 모델'에 가까워졌다.

OpenVLA의 한계

OpenVLA가 강력하다고 해서 완벽한 건 아니다.
논문에서도 한계를 꽤 분명하게 말한다.

1. Single-image observation만 지원

현재 OpenVLA는 single-image observation만 지원한다.

하지만 실제 로봇은 여러 카메라, wrist camera, proprioception, observation history 등을 쓸 수 있다.

즉, OpenVLA는 아직 현실의 모든 로봇 입력을 충분히 다루는 구조는 아니다.

내 프로젝트의 candidate_objects, visibility, relation, subgoal 같은 구조는 이 한계를 보완하는 wrapper로 설계할 수 있다.

2. 고주파 제어에는 inference speed가 부족

OpenVLA는 고주파 제어 환경에는 아직 부담이 있다.

예를 들어 ALOHA 같은 50Hz 제어 환경에서는 inference throughput이 매우 중요하다.

그래서 논문도 future work로 action chunking, speculative decoding 같은 방향을 언급한다.

3. 성공률이 아직 완전히 높지는 않음

OpenVLA가 기존 모델보다 강하긴 하지만, 모든 task에서 실사용 수준으로 안정적인 건 아니다.

논문에서도 tested task에서 보통 90% 미만의 성공률을 보인다고 말한다.

즉, OpenVLA는 “완성된 로봇 두뇌”라기보다
generalist manipulation policy의 강한 출발점에 가깝다.

4. 아직 열려 있는 설계 질문이 많음

OpenVLA는 많은 걸 열어놨지만, 동시에 아직 모르는 것도 많다.

예를 들면 이런 질문들이다.

base VLM 크기가 커지면 VLA 성능은 얼마나 좋아지는가?
robot data와 internet vision-language data를 같이 학습하면 더 좋아지는가?
VLA에 가장 적합한 visual feature는 무엇인가?
action tokenization 방식은 지금이 최선인가?

이건 한계이기도 하지만, 연구 기회이기도 하다.

OpenVLA가 모든 답을 끝낸 게 아니라,
“이제 여기서부터 제대로 실험해보자”라는 기준선을 제공한 것이다.

내 탑다운 프로젝트와 어떻게 연결할 것인가

내가 지금 진행하려는 탑다운 프로젝트의 목표는 OpenVLA를 완전히 재현하는 게 아니다. 지금 단계에서 그건 비현실적이다. 내 목표는 더 현실적이어야한다.

OpenVLA를 기준선으로 삼고, 구조를 읽고, interface를 모방하고, 나중에 MEM / RD-VLA / π 계열 아이디어를 붙일 수 있는 연구용 skeleton을 만드는 것.

즉, 처음부터 “OpenVLA 돌렸다”가 목표가 아니다.

먼저 이런 질문에 답해야 한다.

1. OpenVLA는 어떤 입력을 받는가?
2. 어떤 action을 출력하는가?
3. 내 toy-project의 target/subgoal/abstain 구조와 어디가 다른가?
4. OpenVLA 앞에 reasoning layer를 붙일 수 있는가?
5. OpenVLA 뒤에 evaluation/logging layer를 붙일 수 있는가?

내 프로젝트에서 OpenVLA는 어디에 들어가는가

현재 내 bottom-up toy project는 이런 구조에 가깝다.

scene_id
instruction
candidate_objects
  - obj_id
  - category
  - color
  - bbox
  - visibility
  - notes

output
  - pred_target_obj_id
  - subgoal_label
  - consistency_score
  - abstain_flag
  - reason

반면 OpenVLA의 기본 구조는 이렇다.

image + language instruction
        ↓
OpenVLA
        ↓
7D robot action

둘은 목적이 다르다.

내 toy project는 “행동 전 판단”에 가깝다.
OpenVLA는 “행동 출력 정책”에 가깝다.

그래서 연결 구조는 이렇게 간다.

[Scene / Instruction]
        ↓
[Grounding & Reasoning Gate]
- target object 후보 판단
- subgoal 판단
- consistency score 계산
- abstain 여부 결정
        ↓
[OpenVLA Adapter]
- image + instruction을 OpenVLA 입력 형식으로 변환
- predict_action 호출
        ↓
[Action Output]
- 7D action
        ↓
[Episode Logger / Evaluator]
- target match
- subgoal match
- abstain correctness
- action success

즉, 내 프로젝트에서 OpenVLA는 “전체 뇌”가 아니라,
행동을 실제로 뽑는 policy backbone으로 들어간다.

내가 관심 있는 grounding, alignment, reasoning-before-action은 OpenVLA 바깥의 wrapper에서 실험하는 게 더 현실적이다.

탑다운 프로젝트 Phase별 연결

Phase 1. Stub skeleton

처음에는 실제 OpenVLA를 넣지 않는다. 먼저 아래 흐름이 돌아가야 한다.

scene → stub policy → prediction → log → metric

이 단계의 목적은 모델 성능이 아니다. 내가 어떤 입력과 출력을 다룰지 계약을 고정하는 것이다.

최소한 내 schema에 이런 필드는 있어야 한다.

instruction
image_path 또는 image_tensor
robot_type
unnorm_key
action_space
predicted_action

Phase 2. OpenVLA readthrough

여기서 논문과 README를 본다.

순서는 이게 맞다.

1. GitHub README
   - AutoProcessor
   - AutoModelForVision2Seq
   - predict_action
   - lightweight inference
   - REST API serving

2. 논문 Section 1
   - 왜 OpenVLA가 필요한가
   - closed VLA의 문제
   - fine-tuning 필요성

3. 논문 Section 3
   - 모델 구조
   - action tokenization
   - training data
   - design decisions

4. 논문 Section 5
   - BridgeData V2
   - Google Robot
   - Franka fine-tuning
   - LoRA
   - quantization

5. 논문 Section 6
   - 한계
   - 내 프로젝트에서 보완할 지점

시작은 README로 한다.
연구 이해는 논문으로 한다.

Phase 3. Task schema 확장

OpenVLA는 image + instruction을 받지만, 내 프로젝트는 scene understanding을 더 명시적으로 다룬다.

그래서 schema는 OpenVLA보다 조금 더 연구용으로 가야 한다. 예를 들어 이런 필드가 필요하다.

object attributes
visibility
spatial relation
reachable
partially_visible
far
ambiguous_instruction
requires_refine_view

이건 OpenVLA를 대체하려는 게 아니다.

OpenVLA 앞에서 “이 장면에서 바로 행동해도 되는가?” 를 판단하는 안전장치가 된다.

Phase 4. OpenVLA adapter 분리

adapter는 나중에 실제 OpenVLA가 들어갈 자리다.

처음에는 이렇게 둔다.

OpenVLAAdapter.predict(scene, instruction)
→ stub action

나중에는 이렇게 바뀐다.

OpenVLAAdapter.predict(image, instruction, unnorm_key)
→ vla.predict_action(...)
→ 7D action

여기서 중요한 건 adapter를 빨리 만드는 것이다. 그래야 나중에 stub에서 real OpenVLA로 갈아끼울 때 전체 코드를 다시 갈아엎지 않는다.

Phase 5. Evaluation

OpenVLA 논문도 결국 rollout success rate로 말한다. 내 프로젝트도 감상문으로 끝나면 안 된다. 처음에는 단순한 metric이면 충분하다.

target_match
subgoal_match
abstain_correctness
action_available
episode_success

OpenVLA 논문을 보면 평가는 대부분 task success 중심이다.

하지만 내 프로젝트는 action 전 reasoning을 다루기 때문에
target, subgoal, abstain metric을 같이 둬야 한다.

Phase 6. MEM / RD-VLA / π 계열 확장

OpenVLA는 기본적으로 single image + instruction → action이다. 그러면 확장 아이디어는 다음 질문으로 나뉜다.

단, RD-VLA나 π 계열은 논문을 따로 읽기 전까지 기능을 단정하면 안 된다.

지금은 “OpenVLA 위에 바로 붙이는 기능”이 아니라,
OpenVLA와 비교하거나 wrapper로 얹을 수 있는 후보 track으로 두는 게 맞다.

내가 이 논문에서 남긴 핵심

1) OpenVLA는 “로봇용 ChatGPT”라기보다 “오픈소스 행동 정책 backbone”에 가깝다

OpenVLA는 멋진 reasoning 문장을 출력하는 모델이 아니다.

이미지와 명령을 받아 로봇 action을 출력한다.

그래서 내 프로젝트에서는 OpenVLA에게 모든 판단을 맡기기보다,
앞단에 grounding/reasoning/abstain layer를 두는 게 맞다.

2) 성능보다 중요한 건 실험 가능한 구조다

OpenVLA가 중요한 이유는 단순히 RT-2-X보다 어떤 실험에서 높았기 때문만은 아니다. 진짜 중요한 건 checkpoint, codebase, fine-tuning 흐름이 열려 있다는 점이다.

내가 직접 구조를 읽고, adapter를 만들고, fine-tuning 가능성을 실험할 수 있다.

3. VLA 연구의 핵심은 action 이전의 판단으로 확장될 수 있다

OpenVLA는 action을 출력한다. 하지만 실제 로봇은 무조건 action을 내면 안 된다.

장면이 애매하면 더 봐야 하고,
target이 불확실하면 멈춰야 하고,
instruction과 scene이 충돌하면 abstain해야 한다.

내 연구 방향은 바로 여기에 있다. OpenVLA를 그대로 따라가는 게 아니라, OpenVLA 앞에 “행동 전 판단 구조”를 붙이는 것.

이게 내가 말한 grounding · alignment · reasoning before action과 가장 잘 맞는다.

결론 한 줄

OpenVLA는 VLA 연구를 닫힌 모델 데모에서, 직접 실행하고 고치고 확장할 수 있는 연구 플랫폼으로 바꿔놓은 기준선 모델이다.

나에게 이 논문은 단순히 “좋은 로봇 모델 하나 더 나왔다”가 아니다. 내가 탑다운 프로젝트를 시작할 때 잡아야 할 기준선을 정리해준 논문이다.

1. README로 inference 흐름을 잡고
2. 논문으로 구조와 한계를 이해하고
3. stub 기반 skeleton을 만든 뒤
4. OpenVLA adapter를 분리하고
5. 나중에 GPU 환경에서 lightweight inference와 LoRA fine-tuning 가능성을 확인하는 것

OpenVLA는 내 프로젝트의 최종 목표가 아니다.
내 연구 방향을 실험 가능한 형태로 끌고 가기 위한 출발점이다.

출처

• Moo Jin Kim et al., OpenVLA: An Open-Source Vision-Language-Action Model, arXiv:2406.09246, 2024.
• OpenVLA 공식 프로젝트 페이지: https://openvla.github.io/
• OpenVLA 공식 GitHub repository: https://github.com/openvla/openvla
• OpenVLA Hugging Face model card: https://huggingface.co/openvla/openvla-7b

※ 이 글은 Anthony Brohan 외, 「RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control」를 읽고, 제 방식대로 다시 정리한 글입니다.

로봇의 팔에 '웹 지식'를 이식할 수 있을까

이번에 읽은 논문은 구글 딥마인드에서 발표한 RT-2(Robotics Transformer 2) 논문이다. 그동안 로봇 학습의 가장 큰 고민은 "로봇을 움직이는 데이터(Action)가 인터넷의 방대한 사진·글 데이터(Vision-Language)에 비해 턱없이 부족하다"는 것이었다. 이 논문은 로봇의 동작을 하나의 '언어 토큰'으로 취급하는 아주 단순한 발상으로 이 간극을 해결했다. 내가 이 논문을 읽으면서 가장 크게 느낀 점은 하나였다. “로봇이 똑똑해지려면 더 많은 동작을 연습하는 것보다, 이미 인류가 쌓아온 인터넷의 상식을 이해하는 것이 더 빠를 수 있다.”

VLA 모델: 동작을 '말'처럼 내뱉는 로봇

RT-2는 단순히 이미지를 보고 글을 쓰는 VLM을 넘어, 동작(Action)까지 직접 출력하는 VLA(Vision-Language-Action) 모델이다. 로봇의 관절 각도나 위치 이동 같은 물리적 수치들을 텍스트 토큰처럼 바꾼 뒤(Tokenization), 모델이 다음 단어를 맞히듯 "다음 동작"을 생성하게 만든 것이다. 예를 들어, 로봇에게 사과를 집으라고 하면 모델은 "1 128 91..." 같은 토큰을 내뱉고, 로봇은 이를 다시 물리적 동작으로 변환해 움직인다.

핵심은 Co-fine-tuning: '망각'을 막는 영리한 학습법

이 논문에서 가장 기술적으로 중요한 포인트는 바로 Co-fine-tuning 방식이다. 보통 사전 학습된 거대 모델을 특정 데이터(로봇 데이터)로만 미세 조정(Fine-tuning)하면, 모델이 원래 알고 있던 방대한 인터넷 지식을 잊어버리는 '파괴적 망각(Catastrophic forgetting)' 현상이 발생한다. RT-2는 이를 해결하기 위해 다음과 같은 전략을 썼다.

• 데이터 믹스: 로봇의 동작 데이터만 학습시키는 게 아니라, 원래 VLM이 학습하던 인터넷 규모의 VQA(시각적 질의응답) 데이터를 섞어서 동시에 학습시킨다.
• 샘플링 비중 조절: 각 학습 배치(Batch)에서 로봇 데이터의 비중을 높여서 밸런스를 맞춘다. (RT-2-PaLI-X는 약 50%, RT-2-PaLM-E는 약 66% 비중으로 로봇 데이터를 섞는다).
• 결과: 덕분에 모델은 "사과를 집는 법(로봇 지식)"을 배우면서도 "사과가 건강한 음식이라는 점(웹 지식)"을 잊지 않게 된다.

Chain-of-thought: 로봇이 '생각'하고 움직이기 시작했다

더 놀라운 점은 LLM에서 쓰이던 Chain-of-thought(CoT) 기법을 로봇 제어에 적용했다는 것이다. 동작 토큰을 내뱉기 전에 "왜 이 동작을 하는지"에 대한 계획(Plan)을 자연어로 먼저 출력하도록 유도했더니, 훨씬 복잡한 추론이 가능해졌다.

• 사례 1 (추론): "못을 박아야 하는데 어떤 물건이 필요할까?"라고 물으면, "망치 대용으로 쓸 돌을 집는다"라는 계획을 세우고 돌을 향해 팔을 뻗는다.
• 사례 2 (상황 이해): "배가고파"라고 하면, "초콜릿 바를 집는다"라는 계획을 먼저 말한 뒤 행동한다.
• 사례 3 (에너지 보충): "졸려, 도움이 될 만한 음료를 가져다줘"라고 하면, "핫식스를 집는다"라고 판단한다.

이건 로봇 학습 데이터에는 전혀 없던 내용이다. 오직 인터넷 데이터를 통해 배운 '상식'을 로봇의 물리적 팔과 연결한 결과다.

성능 비교: RT-1 vs RT-2

실제로 RT-2가 이전 모델(RT-1)에 비해 얼마나 좋아졌는지 수치로 확인해보면 그 차이가 극명하다. 특히 한 번도 본 적 없는 환경(Unseen)에서의 적응력이 압도적이다.

데이터 출처: 논문 22페이지 Table 4

결과를 보면 알 수 있듯이, 이미 아는 일을 할 때는 비슷하지만 낯선 상황에 던져졌을 때 RT-2는 기존 모델보다 약 2~3배 더 잘 해낸다.

내가 이 논문에서 남긴 핵심

이 논문을 읽고 내가 크게 남긴 건 세 가지였다.

1. 로봇에게 '눈'과 '팔'보다 중요한 건 '뇌'였다

단순히 팔을 흔드는 데이터를 백날 모으는 것보다, 세상의 이치를 아는 거대 모델에 팔을 달아주는 것이 일반화 성능(Generalization)을 올리는 데 훨씬 효율적이다.

2. '동작'도 결국 언어의 한 형태일 뿐이다

로봇의 수치 데이터를 텍스트 토큰으로 치환해버린 덕분에, 우리는 인류가 만든 가장 강력한 도구인 LLM/VLM의 혜택을 로봇 공학에서도 그대로 누릴 수 있게 됐다.

3. CoT는 로봇의 '실수'를 줄이는 열쇠다

단순히 "동작"만 출력할 때보다 "계획"을 거쳐 출력할 때 모델은 더 정교한 상식 추론을 보여준다. 이는 로봇이 인간의 복잡하고 모호한 명령을 이해하는 데 필수적인 요소가 될 것이다.

마무리

RT-2는 로봇 분야의 'ImageNet 모멘트' 혹은 'GPT 모멘트'에 가깝다는 생각이 들었다. 이전까지 로봇은 정해진 환경에서 정해진 일만 잘하는 '기계'였다면, 이제는 인터넷의 지식을 활용해 처음 보는 물건도 "이건 망치 대신 쓸 수 있겠네"라고 판단하는 '상식 있는 존재'로 진화하고 있다. 물론 아직 거대 모델을 실시간으로 돌리기 위한 비용 문제나 정교한 손동작 학습의 한계는 남아있지만, 로봇이 우리 삶 속으로 들어오는 속도가 이전과는 비교할 수 없이 빨라질 것임을 보여준 기념비적인 논문이라 느꼈다.

출처

• Anthony Brohan, et al., RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control, 2023.
• Project Website: https://robotics-transformer2.github.io

※ 이 글은 Vladimir Karpukhin 외, 「Dense Passage Retrieval for Open-Domain Question Answering」를 읽고, 제 방식대로 다시 정리한 글입니다.

BM25 다음에 왜 DPR이 중요해졌을까

이번에 읽은 논문은
Dense Passage Retrieval for Open-Domain Question Answering, 흔히 DPR 논문이라고 불리는 글이다.

지금 와서 보면
질문과 문단을 각각 벡터로 바꾸고,
서로 가까운 문단을 찾는 방식이 꽤 익숙하게 느껴질 수 있다.

그런데 이 논문이 중요했던 건
그 아이디어 자체가 완전히 새로워서라기보다,
오픈 도메인 질문답변에서 진짜 병목이 어디인지를 꽤 분명하게 보여줬기 때문이다.

내가 이 논문을 읽으면서 가장 크게 느낀 건 하나였다.

“답을 잘 읽는 것만큼, 아니 그보다 먼저 중요한 건 답이 들어 있는 문단을 잘 가져오는 일이다.”

오픈 도메인 QA는 결국 두 단계다

오픈 도메인 질문답변은 크게 두 단계로 움직인다.

1. 먼저 질문과 관련 있는 문단을 찾고
2. 그다음 그 문단 안에서 답을 뽑는다

처음에는 두 번째가 더 중요해 보일 수 있다.
문단 안에서 정답을 잘 추출해야 하니까.

그런데 조금만 생각해보면,
애초에 답이 들어 있는 문단을 못 가져오면
뒤에 있는 모델이 아무리 좋아도 답을 맞힐 수가 없다.

이 논문은 그 지점을 정면으로 다룬다.
질문답변 시스템에서 성능이 막히는 이유가
단순히 reader가 약해서가 아니라,
retriever가 정답 문단을 충분히 잘 못 가져와서일 수 있다는 것이다.

기존 방식은 왜 아쉬웠을까

이 논문 이전까지는
오픈 도메인 QA에서 BM25 같은 전통적인 검색 방식이 아주 강한 기준선이었다.

BM25는 쉽게 말하면
질문과 문단에 같은 단어가 얼마나 겹치는지를 중심으로 관련도를 계산하는 방식이다.

이 방식은 분명 강하다.
빠르고, 직관적이고,
특정 키워드가 정확히 들어 있을 때 잘 맞춘다.

하지만 한계도 있다.

예를 들어 질문에는 bad guy라고 적혀 있고,
문단에는 villain이라고 적혀 있다고 해보자.

사람은 둘이 비슷한 뜻이라는 걸 바로 이해한다.
그런데 단어 중심 검색은 이런 경우를 놓칠 수 있다.
즉, 표현은 다르지만 의미는 비슷한 경우에 약할 수 있다.

DPR 논문은 바로 이 지점을 건드린다.

“질문과 문단을 단어 겹침으로만 보지 말고,
의미를 담은 벡터로 바꿔 비교하면 더 잘 찾을 수 있지 않을까?”

DPR은 뭘 했나

아이디어는 생각보다 단순하다.

• 질문은 질문 인코더가 읽고
• 문단은 문단 인코더가 읽고
• 각각을 벡터로 만든 다음
• 질문 벡터와 문단 벡터가 얼마나 가까운지로 관련도를 판단한다

즉, 질문과 문단을 각각 따로 벡터화한 뒤
같은 의미 공간 안에서 얼마나 가까운지를 보는 구조다.

그리고 이 유사도는
아주 단순하게 dot product로 계산한다.

겉으로 보면
“생각보다 단순한데?”
싶을 수 있다.

나도 처음엔 그랬다.

그런데 이 논문의 포인트는
복잡한 구조를 새로 만든 게 아니라,
이 단순한 구조도 학습을 잘 시키면 꽤 강해진다는 걸 보여준 데 있다.

이 논문에서 더 중요했던 건 구조보다 학습 방식이었다

개인적으로 이 논문에서 제일 인상 깊었던 건
구조보다 학습 방식이었다.

질문 하나에 대해
정답 문단만 보여주면 모델은
“이 문단이 맞다” 정도는 배울 수 있다.

그런데 실제 검색은
수많은 오답 문단 사이에서
정답 문단을 골라내야 하는 문제다.

그래서 이 논문은
오답을 어떻게 보여주느냐를 굉장히 중요하게 본다.

여기서 핵심으로 나오는 게 두 가지다.

1. In-batch negatives

한 번에 여러 질문을 같이 학습할 때,
다른 질문의 정답 문단을
현재 질문 입장에서는 오답처럼 같이 활용하는 방식이다.

쉽게 말하면
배치 안에 이미 있는 예시들을 그냥 지나치지 않고,
추가 비교 대상으로 재활용하는 것에 가깝다.

이렇게 하면
굳이 새로운 오답 문단을 엄청 많이 따로 만들지 않아도,
한 번의 학습 안에서 훨씬 많은 비교가 가능해진다.

2. Hard negative

이건 그냥 아무 오답 문단이 아니다.
질문과 얼핏 보면 꽤 비슷해서
모델이 헷갈리기 쉬운 문단이다.

예를 들어
질문 단어와 많이 겹치는데
실제로는 정답이 없는 문단 같은 것들이다.

이런 오답을 같이 보여주면
모델은 더 빡세게 배운다.

결국 이 논문은
좋은 dense retriever를 만드는 데서 중요한 게
“모델 이름”보다도
어떤 오답을 어떻게 같이 보여주느냐일 수 있다는 걸 보여준다.

적은 데이터로도 가능하다는 점도 꽤 흥미로웠다

dense retrieval이라고 하면
처음엔 왠지 “이런 건 결국 데이터 엄청 많아야 되는 거 아니야?” 싶다.

그런데 이 논문은
그 부분에서도 꽤 흥미로운 결과를 보여준다.

Natural Questions 기준으로 보면,
학습 예제가 아주 많지 않아도 DPR이 BM25를 넘기기 시작한다.

즉,
좋은 사전학습 언어모델 위에서라면
생각보다 적은 질문-문단 쌍으로도 강한 retriever를 만들 수 있다는 걸 보여준다.

이건 지금 봐도 꽤 중요한 포인트라고 느꼈다.
dense retrieval이 무조건 거대한 라벨 데이터가 있어야만 가능한 건 아니라는 뜻이기 때문이다.

그래서 실제로 BM25보다 잘했나

결론부터 말하면,
이 논문은 대부분의 데이터셋에서 DPR이 BM25보다 더 잘 찾는다는 결과를 보여준다.

특히 retrieval 성능을 보는 Top-20 accuracy에서 차이가 크게 난다.

예를 들어 Natural Questions에서는
BM25보다 DPR이 훨씬 높은 수치를 보인다.
즉, 상위 20개 문단 안에
정답이 들어 있는 문단을 넣어둘 확률이 더 높다는 뜻이다.

이게 중요한 이유는 단순하다.

reader는 결국
retriever가 가져온 문단 안에서만 답을 찾을 수 있기 때문이다.
그러니까 상위 후보 안에 정답 문단을 더 자주 넣어줄수록,
뒤 모델도 더 자주 맞힐 수 있다.

이 논문이 좋았던 건 여기서 안 멈췄다는 점이다

검색 논문을 보다 보면
retrieval 점수는 올랐는데,
그래서 실제 질문답변 성능도 좋아졌는지는
조금 애매하게 끝나는 경우가 있다.

그런데 이 논문은
그 질문을 피하지 않는다.

저자들은 DPR로 가져온 문단을 reader에 넘겨서
실제 end-to-end QA 성능도 확인한다.
그리고 결과적으로
retrieval이 좋아지면 QA도 같이 좋아진다는 걸 보여준다.

이건 꽤 중요하다.

왜냐하면
정답 문단을 더 잘 가져왔다는 것과
최종 답변 정확도가 실제로 올라갔다는 건
같은 말이 아니기 때문이다.

그런데 이 논문은
그 둘이 실제로 연결된다는 걸
결과로 보여준다.

Natural Questions나 TriviaQA 같은 데이터셋에서는
DPR 기반 시스템이
이전의 강한 기준선보다 더 좋은 결과를 보였다.

작은 데이터셋에서는
여러 데이터셋을 함께 학습한 설정이 특히 더 잘 먹히는 모습도 보인다.

그렇다고 DPR이 모든 면에서 완벽한 건 아니었다

이 논문이 더 좋게 느껴졌던 이유 중 하나는
dense retrieval의 장점만 말하고 끝내지 않았다는 점이다.

부록의 qualitative analysis를 보면,
BM25와 DPR이 서로 잘하는 문제가 다르다는 것도 보여준다.

DPR은 표현이 다르지만 뜻이 비슷한 경우,
즉 semantic match가 필요한 경우에 더 강하다.

반대로 BM25는 드문 핵심 구절이나
질문과 문단 사이의 특정 키워드가 정확히 맞아떨어지는 경우 더 강할 수 있다.

이건 꽤 현실적으로 느껴졌다.

dense가 무조건 sparse를 완전히 밀어낸다기보다,
dense는 분명 강력하지만 sparse가 가진 장점도 여전히 남아 있다는 뜻이기 때문이다.

그래서 실제로 논문에서도 BM25 + DPR 조합을 같이 실험한다.

내가 이 논문에서 남긴 핵심

이 논문을 읽고 내가 크게 남긴 건 세 가지였다.

1. 오픈 도메인 QA의 병목은 생각보다 retrieval에 더 가까울 수 있다

답을 잘 읽는 것도 중요하지만, 그보다 먼저 답이 들어 있는 문단을 가져와야 한다.

2. Dense retrieval의 힘은 “비슷한 뜻”을 잡는 데 있다

질문과 문단이 같은 단어를 쓰지 않아도, 의미가 가까우면 연결할 수 있다는 점이 크다.

3. 성능을 만드는 건 모델 이름보다 학습 방식일 때가 많다

이 논문은 구조 자체보다 in-batch negatives, hard negatives, 학습 구성이 얼마나 중요한지 보여준다.

개인적으로는 세 번째가 제일 크게 남았다.

겉으로 보기엔 질문 인코더 하나, 문단 인코더 하나라서 단순해 보이는데,
정작 성능을 만든 건 그 안쪽의 학습 설계였기 때문이다.

마무리

지금 시점에서 보면 DPR은 너무 유명해서
당연한 방식처럼 느껴질 수 있다.

그런데 이 논문이 중요했던 이유는
단순히 “dense retrieval도 된다”를 말해서가 아니라,
오픈 도메인 QA에서 진짜 병목이 어디인지,
그리고 그 병목을 어떻게 단순하면서도 강하게 풀 수 있는지를 꽤 설득력 있게 보여줬다는 데 있다고 느꼈다.

짧게 정리하면 이렇게 기억하면 될 것 같다.

질문과 문단을 의미 벡터로 바꾸고,
정답 문단이 더 가까워지도록 잘 학습시키면,
전통적인 단어 기반 검색보다 더 잘 찾을 수 있다.
그리고 그 향상은 실제 QA 성능 향상으로도 이어진다.

dense retrieval을 처음 공부할 때
왜 DPR이 그렇게 자주 기준점처럼 언급되는지,
이번에 읽으면서 조금은 더 납득이 됐다.

출처

• Vladimir Karpukhin, Barlas Oguz, Sewon Min, Patrick Lewis, Ledell Wu, Sergey Edunov, Danqi Chen, Wen-tau Yih,
  Dense Passage Retrieval for Open-Domain Question Answering, 2020.
• Paper: https://arxiv.org/abs/2004.04906
• Code: https://github.com/facebookresearch/DPR

※ 이 글은 Karsten Roth 외, 「Towards Total Recall in Industrial Anomaly Detection」를 읽고, 제 방식대로 다시 정리한 글입니다.

공장 불량 탐지는 왜 이미지를 ‘전체’가 아니라 ‘작은 조각’으로 봐야 했을까

이번에 읽은 논문은
내가 처음으로 제대로 읽어본 컴퓨터 비전 논문이었다.

그 전까지 컴퓨터 비전은 막연하게만 알고 있었다.

이미지를 보고 분류하고, 객체를 찾고,
이상한 부분을 잡아내는 기술이라는 정도는 알았지만,
정작 논문 하나를 처음부터 끝까지 따라가면서
“이 문제를 왜 이런 방식으로 푸는지”를 본 적은 없었다.

그래서 처음에는 조금 걱정도 했다.
NLP나 LLM 쪽은 그래도 익숙한 편인데,
CV 논문은 괜히 수식과 구조만 복잡하게 느껴질까 봐 그랬다.

그런데 막상 읽어보니
이 논문은 생각보다 훨씬 명확했다.

PatchCore는 단순히
“성능 좋은 비전 모델 하나를 제안했다”는 느낌보다,
산업용 이상 탐지라는 문제를 어떤 단위로 보고, 정상 정보를 어떻게 저장하고, 테스트 때 무엇을 비교할 것인가를 굉장히 현실적으로 설계한 논문에 가까웠다.

그리고 그 점이 되게 좋았다.

1. 이 논문은 어떤 문제를 풀려고 했을까

정상 이미지만 보고도 불량을 찾을 수 있을까

PatchCore가 다루는 문제는 산업용 이상 탐지다.
조금 더 쉽게 말하면, 공장에서 제품 이미지를 보고
정상인지 불량인지, 그리고 어디가 이상한지를 찾아내는 문제다.

그런데 여기서 중요한 조건이 있다.

이 논문은 cold-start anomaly detection을 다룬다.
즉, 불량 이미지를 많이 모아놓고 학습하는 게 아니라
정상 이미지들만 가지고 시작해야 하는 상황이다.

왜 이게 어렵냐면,
산업 현장의 결함은 생각보다 종류가 많고 형태도 다양하기 때문이다.

어떤 이상은 부품이 아예 빠진 것처럼 눈에 띄지만,
어떤 건 아주 얇은 스크래치, 표면 질감의 미세한 변화, 혹은 구조의 사소한 어긋남처럼
정상과의 차이가 정말 작게 나타난다.

즉, 이 문제는
“이게 무슨 사물인가”보다
“평소와 어디가 얼마나 다른가”가 더 중요하다.

2. 기존 방식은 왜 아쉬웠을까

깊은 feature가 항상 답은 아니었다

기존에도 산업 이상 탐지를 잘 하려는 방법은 많았다.
오토인코더, GAN, normalizing flow 같은 방식도 있었고,
최근에는 ImageNet으로 미리 학습한 모델의 feature를 가져와
정상과의 차이를 보는 접근도 강한 성능을 보였다.

그런데 PatchCore는 여기서 두 가지 문제를 짚는다.

첫째,
이미지 전체를 너무 크게 보는 방식은 작은 결함에 약할 수 있다는 점이다.

이미지를 하나의 큰 표현으로 요약해버리면
아주 작은 흠집이나 구석의 미세한 이상은 그 안에 묻혀버릴 수 있다.
공장 불량은 이미지 전체보다 특정 부분에서 드러나는 경우가 훨씬 많기 때문에,
이건 생각보다 큰 한계다.

둘째,
너무 깊은 계층의 feature는 공장 결함 탐지와 잘 안 맞을 수 있다는 점이다.

ImageNet으로 학습된 깊은 feature는 원래 강아지, 자동차, 과일처럼
일반적인 자연 사진 분류에 잘 맞게 학습돼 있다.

즉, “이게 무슨 사물인가”를 구분하는 데 강하다.

그런데 산업용 이상 탐지는 “이게 병인가 캔인가”보다
“병 표면에 평소와 다른 작은 흠집이 있는가”가 더 중요하다.

그래서 논문은
너무 깊은 feature가 공장 데이터에는 과하게 추상적일 수 있고,
ImageNet 분류 편향이 강하게 남아 있을 수 있다고 본다.

이 부분이 꽤 인상적이었다.

깊은 feature가 무조건 더 좋은 게 아니라,
문제에 맞는 feature 깊이가 따로 있을 수 있다는 점이 분명하게 보였기 때문이다.

3. PatchCore의 핵심 아이디어

이미지를 전체로 보지 말고, 작은 조각으로 보자

이 논문의 핵심 아이디어를 한 줄로 줄이면 이렇다.

이미지 전체를 한 번에 보지 말고, 작은 조각 단위로 정상과 비교하자.

PatchCore는 정상 이미지들에서
patch-level feature, 즉 작은 조각 단위의 특징을 뽑아 저장해두고,
테스트 이미지가 들어오면
그 안의 각 조각이 정상 조각들과 얼마나 다른지를 본다.

그리고
조각 하나라도 충분히 이상하면 이미지 전체도 이상이라고 판단한다.

공장 불량이라는 문제를 생각해보면 이건 되게 자연스럽다.

불량은 이미지 전체가 망가지는 경우보다 대부분 특정 부분에서 나타나니까.

즉, 이 논문은 모델을 더 복잡하게 만들기보다
문제를 보는 단위를 더 잘게 바꾼 것에 가깝다.

4. 왜 하필 중간 계층 특징을 썼을까

너무 얕지도, 너무 깊지도 않은 지점

PatchCore는 마지막 feature 대신
중간 계층 특징(mid-level features) 을 사용한다.

이 선택은 꽤 중요하다.

너무 앞단 feature는
선, 점, 엣지처럼 너무 기초적인 정보만 담고 있어서 표현력이 약할 수 있다.

반대로 너무 깊은 feature는
“이게 어떤 사물인가”에 너무 맞춰져 있어서 미세한 결함을 잡는 데는 오히려 덜 적합할 수 있다.

중간 계층은 그 사이 어딘가에 있다.

• 어느 정도 의미 있는 패턴을 담고 있고
• 해상도도 아직 살아 있고
• ImageNet 분류 편향도 상대적으로 덜하다

즉, 산업용 이상 탐지처럼
작고 지역적인 차이를 봐야 하는 문제에 잘 맞는 지점이라는 거다.

처음에는
“깊은 feature가 더 좋은 거 아닌가?” 싶었는데,
이 논문을 읽고 나서는 무조건 깊은 게 답은 아니라는 걸 조금 더 분명히 느꼈다.

5. Locally aware patch features

패치 하나만 보지 않고, 주변도 같이 본다

여기서 PatchCore는 한 단계 더 들어간다.

패치 하나만 딱 떼어보는 게 아니라,
그 패치 주변 이웃 정보까지 같이 모아 하나의 표현을 만든다.
논문은 이를 locally aware patch features라고 부른다.

이 부분이 되게 중요했다.

왜냐하면 어떤 작은 점이나 자국이 그 자체만 보면 애매할 수 있기 때문이다.

그게 진짜 결함인지, 원래 있는 무늬의 일부인지, 빛 반사인지,
주변 질감과 연결된 정상 패턴인지 맥락이 있어야 더 잘 보인다.

즉,
한 점만 보면 놓칠 수 있고, 주변까지 보면 더 잘 보일 수 있다.

그래서 PatchCore는
패치 하나가 아니라 패치 + 주변 문맥을 같이 보려고 한다.

6. Adaptive Average Pooling은 여기서 왜 쓰일까

처음 보면 이 표현도 조금 딱딱하다.

나도 처음엔 그냥 “평균을 내는 건가?” 정도로만 봤는데,
논문 안에서의 역할은 더 분명했다.

PatchCore는 중심 패치 주변의 이웃 feature들을 모은다.
그런데 이걸 그대로 다 들고 가면 표현이 너무 커지고 비교하기가 어렵다.

그래서 필요한 게
주변 정보를 하나의 고정된 크기 표현으로 정리하는 과정이다.
여기서 adaptive average pooling이 쓰인다.

즉, 이 논문에서 adaptive average pooling은
단순히 “평균을 낸다” 수준보다 조금 더 구체적으로 보면,

• 주변 이웃 feature들을 모아서
• 일정한 크기의 하나의 벡터로 정리하고
• 중심 패치 표현에 문맥을 더하는 역할

에 가깝다.

깊은 계층으로 더 내려가지 않고도
중간 계층 feature를 유지한 채 receptive field를 넓히는 방식이라고 이해하면 좋다.

7. Memory Bank

정상의 기준을 저장해두는 방식

PatchCore를 이해할 때 가장 먼저 잡아야 하는 개념 중 하나가
Memory Bank다.

이건 말 그대로 정상 패치들의 저장소다.

정상 이미지들을 backbone에 통과시키고,
거기서 나온 패치 단위 feature를 모아서
정상 제품이 보통 어떤 패턴을 가지는지 저장해둔다.

테스트 때는
새로운 패치가 들어오면 이 Memory Bank 안의 정상 패치들과 비교한다.

쉽게 말하면
정상 조각 정답 모음집 같은 느낌이다.

개인적으로 이 부분이 좋았던 이유는,
정상 분포를 모델 파라미터 안에 흐릿하게만 담아두는 게 아니라
실제로 비교 가능한 형태로 들고 간다는 점 때문이다.

즉, PatchCore는
“정상을 학습했다”에서 멈추지 않고,
정상을 저장해두고 직접 비교한다는 점이 되게 선명하다.

8. 그런데 Memory Bank가 커지면 어떻게 될까

그래서 coreset이 필요해진다

여기까지 보면 구조가 좋아 보인다.

그런데 현실적인 문제가 바로 생긴다.

정상 이미지가 많아지면 패치 수는 훨씬 더 많아진다.
그러면 Memory Bank가 너무 커진다.

그 결과는 뻔하다.

• 저장공간이 커지고
• 테스트 때 비교 비용이 늘어나고
• 추론 속도가 느려진다

즉,
정확도만 볼 게 아니라
실제로 검색 가능한 크기로 줄이는 것도 중요해진다.

여기서 등장하는 게
이 논문의 또 다른 핵심인 Coreset Subsampling이다.

9. Coreset Subsampling

다 들고 가지 말고, 핵심만 남기자

코어셋은 쉽게 말하면
전체 데이터를 가장 잘 대표하는 요약본이다.

PatchCore는 메모리 뱅크에 있는 정상 패치를 전부 저장하지 않고,
그중에서 전체 feature 공간을 잘 대표하는 일부만 남긴다.

여기서 중요한 건
아무거나 랜덤으로 줄이는 게 아니라는 점이다.

랜덤으로 줄이면
어떤 정상 패턴 군집은 통째로 빠질 수 있다.
그러면 사실 정상인 테스트 패치도 근처에 참고할 정상 패치가 없어서
괜히 이상하다고 판단할 위험이 생긴다.

그래서 이 논문은 메모리 뱅크를 줄일 때도
“어떻게 줄이느냐”를 굉장히 중요하게 본다.

10. Minimax Facility Location은 대체 뭘까

이 이름은 처음 보면 진짜 어렵다.

나도 처음엔
“이건 그냥 이름부터 무섭다” 싶었다.

그런데 뜻을 풀면 생각보다 명확하다.

핵심은 이거다.

대표 패치들이 한쪽에 몰리지 않고, 전체 정상 feature 공간을 최대한 골고루 덮게 만들자.

즉,
원래 메모리 뱅크의 모든 점들 중에서 어떤 점을 보더라도
선택된 대표 패치와 너무 멀지 않게 만드는 방향으로
대표를 고르겠다는 뜻이다.

말은 어려워도 감각은 단순하다.

운동장 전체에 학생들이 흩어져 있고
선생님 몇 명만 배치해야 한다고 생각해보면 된다.

좋은 배치는
선생님들이 한쪽 구석에 몰려 있는 게 아니라,
운동장 전체를 골고루 커버해서 어떤 학생도 너무 멀리 떨어지지 않게 만드는 배치일 것이다.

PatchCore의 coreset도 비슷하다.

즉,
대표 패치를 넓고 고르게 뽑아서
전체 정상 분포를 잘 커버하려는 전략이다.

11. greedy selection과 Johnson-Lindenstrauss theorem

대표를 고르는 방식도 현실적으로 풀었다

문제는 이런 대표 집합을 정확히 찾는 게 쉽지 않다는 점이다.

그래서 논문은 정확한 최적해 대신 greedy 방식으로 근사한다.

greedy는 여기서 매 단계마다
“현재까지 뽑은 대표들과 가장 멀리 떨어진 점”을 하나씩 추가하는 방식으로 이해하면 된다.

이게 왜 좋냐면,
이미 잘 커버된 곳보다 아직 비어 있는 영역을 우선적으로 메우게 되기 때문이다.

즉,
대표들이 점점 전체 공간을 넓게 덮게 된다.

여기서 또 하나의 계산 문제가 생긴다.
패치 feature는 차원이 높다.
그 상태로 거리 계산을 반복하면 coreset selection도 느려진다.

그래서 논문은
random projection으로 차원을 줄인 뒤
그 공간에서 coreset을 고른다.

여기서 Johnson-Lindenstrauss theorem은
차원을 줄여도 점들 사이 거리 관계가 크게 망가지지 않을 수 있다는 이론적 근거를 준다.

즉, 정보량은 줄지만
“누가 누구와 가깝고 먼지”라는 구조는 어느 정도 유지될 수 있다는 뜻이다.

PatchCore 입장에서는
정확한 좌표 자체보다 전체 분포를 골고루 덮는 게 더 중요하니까, 이런 차원 축소가 꽤 실용적으로 쓰인다.

이 부분을 보면서
이 논문이 단순히 정확도만 올린 게 아니라,
실제로 돌아갈 수 있는 구조까지 같이 고민했다는 느낌을 받았다.

12. 테스트할 때는 어떻게 이상을 판단할까

가장 수상한 패치 하나가 이미지 전체 판단을 이끈다

테스트 이미지가 들어오면
PatchCore는 똑같이 패치 feature를 만든다.

그리고 각 테스트 패치마다
Memory Bank 안에서 가장 가까운 정상 패치를 찾는다.

여기서 핵심 아이디어는 되게 직관적이다.

정상 패치들과 가까우면 정상일 가능성이 크고,
멀리 떨어져 있으면 이상일 가능성이 크다.

PatchCore는
이 테스트 이미지 안의 패치들 중
가장 수상한 패치를 중심으로
이미지 전체의 anomaly score를 만든다.

즉,

• 이미지 전체를 한 번에 판단하는 게 아니라
• 패치별로 보고
• 그중 가장 이상한 패치가 전체 판단을 끌고 간다

는 구조다.

공장 불량이라는 문제 설정과 정말 잘 맞는 방식이라고 느껴졌다.

13. 실험 결과는 어떻게 봐야 할까

image-level AUROC, pixel AUROC, PRO

논문 리뷰에서 결국 중요한 건
“그래서 성능이 어땠는데?”다.

1) image-level AUROC

이건 이미지 한 장 단위로
정상과 이상을 얼마나 잘 구분하는지 보는 지표다.

값은 1에 가까울수록 좋고,
0.5에 가까우면 거의 랜덤 수준이다.

PatchCore는 MVTec AD에서
기본 설정만으로도 image-level AUROC 99%대를 기록했고,
더 큰 해상도와 앙상블 설정에서는 99.6까지 올라간다.

숫자만 보면 그냥 “높네” 하고 넘어갈 수도 있는데,
이 논문은 error 기준으로도 설명한다.

기존 강한 방법 대비 오류를 절반 이상 줄였다고 말하는데,
산업 현장에서는 이 차이가 꽤 중요하다.

즉, 이건 단순한 벤치마크 숫자 싸움이 아니라,
실제 검사 시스템에서 놓치는 불량과
헛되게 잡아내는 정상의 수를 많이 줄였다는 의미에 가깝다.

2) pixel-wise AUROC

이건 픽셀 단위로 이상 위치를 얼마나 잘 찾는지 보는 지표다.

즉, “이 이미지가 이상하냐”를 넘어서
“어디가 이상하냐”를 얼마나 정확히 잡는지를 본다.

3) PRO metric

이건 조금 더 결함 영역 중심의 지표다.

픽셀 수만 기준으로 보면 큰 결함이 점수에 더 큰 영향을 줄 수 있다.
그런데 실제로는 작은 결함 하나도 놓치면 안 된다.

PRO는 이상 영역 하나하나를 결함 덩어리 단위로 보고,
그걸 얼마나 잘 복원했는지를 더 잘 반영하는 지표다.

즉, 단순히 픽셀 수로만 보는 게 아니라
각 결함 영역을 얼마나 잘 찾아냈는지를 더 잘 보게 해준다.

산업용 이상 탐지처럼 작은 이상도 중요할 때 되게 실용적인 지표라는 생각이 들었다.

14. 속도까지 챙겼다는 점이 중요했다

이 논문이 더 인상적이었던 건 정확도만 올리고 끝나지 않았다는 점이다.

PatchCore는 coreset을 적용하면서 Memory Bank 크기를 크게 줄였고,
그 결과 추론 속도도 많이 줄였다.

즉, 그냥 “정확도가 높다”가 아니라 정확도와 실용성을 같이 챙겼다는 게 중요하다.

특히 좋았던 건
논문이 “많이 저장하는 것”보다 “잘 저장하는 것”이 더 중요할 수 있다는 점도 보여줬다는 것이다.

무조건 다 들고 가는 게 답이 아니라,
대표성을 유지하면서 압축하는 쪽이
오히려 더 현실적이라는 메시지가 꽤 분명했다.

15. 데이터가 적어도 꽤 잘 버틴다

low-shot에서도 강했다

현실에서는 정상 데이터조차 충분하지 않을 수 있다.

논문도 이걸 고려해서 low-shot setting을 따로 실험한다.

결과적으로 PatchCore는 정상 데이터가 적은 상황에서도 꽤 강한 성능을 보였다.

이건 실전에서 꽤 중요한 포인트다.

모델 구조 자체보다 “데이터가 적을 때도 버티는가”가 더 중요할 때가 많기 때문이다.

16. 이 논문의 장점과 한계

내가 이 논문을 읽고 좋다고 느낀 이유는 크게 세 가지였다.

1) 문제를 보는 단위가 맞다

이미지 전체가 아니라 패치 단위로 보기 때문에 작은 결함에 더 민감해질 수 있다.

2) 특징을 고르는 깊이가 좋다

너무 얕지도, 너무 깊지도 않은 중간 계층 특징을 써서 해상도와 표현력, 편향 사이에서 균형을 잡았다.

3) 저장과 검색 방식까지 같이 설계했다

Memory Bank를 그냥 크게 쓰는 대신 coreset으로 줄여 속도와 저장공간까지 현실적으로 챙겼다.

물론 한계도 분명하다.

논문도 마지막에 솔직하게 말한다.

PatchCore는 결국
사전학습된 feature의 전이 가능성에 의존한다.
즉, ImageNet에서 배운 feature가 해당 산업 데이터에도 꽤 잘 맞아야 한다는 전제가 있다.

도메인이 너무 다르다면 추가적인 adaptation이 더 필요할 수 있다. 이 부분까지 솔직하게 적어둔 점도 좋았다.

17. 첫 컴퓨터 비전 논문으로 읽고 나서 든 생각

처음 읽는 컴퓨터 비전 논문이라 솔직히 겁을 좀 먹고 들어갔다.

그런데 막상 끝까지 읽고 나니
오히려 CV 논문에 대한 이미지가 조금 달라졌다.

“수식이 많고 어렵다”기보다
문제를 어떤 방식으로 다시 정의하고, 그에 맞게 구조를 설계하는가가 더 먼저 보였다.

그리고 그 점에서 PatchCore는 꽤 인상적이었다.

• 이미지 전체를 보는 대신 패치로 바꾸고
• 깊은 feature 대신 중간 feature를 쓰고
• 정상 정보를 메모리 뱅크로 들고 가고
• 너무 커진 메모리는 coreset으로 줄인다

이 흐름이 너무 자연스러웠다.

읽고 나면
“아 그래서 성능이 잘 나왔구나”가 납득된다.

개인적으로는
이게 첫 CV 논문이었다는 게 오히려 좋았다.
막연했던 분야가 조금은 구체적인 문제와 구조로 보이기 시작했기 때문이다.

마무리

PatchCore는 결국
정상 제품 이미지를 작은 조각 단위로 기억해두고,
새 이미지의 각 조각이 정상과 얼마나 다른지를 비교해서
이상을 찾아내는 방법이다.

그런데 이 논문이 좋은 이유는 거기서 끝나지 않는다.

• 패치 단위로 문제를 보고
• 중간 계층 특징으로 균형을 잡고
• 주변 문맥까지 반영하고
• 메모리 뱅크를 대표 샘플만 남기도록 줄여서
• 정확도와 속도를 함께 챙겼다

이 전체 설계가 되게 깔끔하다.

처음 읽어본 컴퓨터 비전 논문으로서 이 논문은 나한테
“CV도 결국 문제를 잘 정의하고, 그 문제에 맞는 구조를 설계하는 싸움이구나” 라는 걸 보여준 논문이었다.

그리고 그래서 더 재밌었다.

참고

• Karsten Roth, Latha Pemula, Joaquin Zepeda, Bernhard Schölkopf, Thomas Brox, Peter Gehler
• Towards Total Recall in Industrial Anomaly Detection
• CVPR 2022

※ 이 글은 Lilian Weng의 「LLM Powered Autonomous Agents」를 읽고, 다시 정리한 글입니다.
원문: https://lilianweng.github.io/posts/2023-06-23-agent/

에이전트는 결국 ‘LLM 하나’가 아니라 ‘구조’였다

Lilian Weng의 글을 읽고 정리한 LLM Agent의 핵심

요즘 AI 이야기를 하다 보면
정말 자주 나오는 단어가 있다.

바로 Agent다.

처음에는 나도 이 단어를 조금 막연하게 받아들였던 것 같다.
그냥 LLM이 조금 더 똑똑해져서
스스로 판단하고, 도구도 쓰고, 알아서 일하는 느낌 정도로 생각했다.

그런데 Lilian Weng의 「LLM Powered Autonomous Agents」를 읽고 나서는
생각이 꽤 많이 정리됐다.

에이전트는 그냥
“LLM이 혼자 다 하는 무언가”가 아니었다.

오히려 반대에 가까웠다.

에이전트는 LLM 하나로 완성되는 게 아니라,
LLM 주위에 계획, 기억, 도구를 붙여서
문제를 풀 수 있는 구조를 만드는 일에 더 가까웠다.

이 글이 좋았던 이유도 바로 그 점이다.
에이전트를 막연한 미래 기술처럼 포장하지 않고,
무엇이 필요하고, 왜 필요한지를 구조적으로 보여준다.

1. 에이전트의 중심은 LLM이지만, LLM만으로는 부족하다

Lilian Weng는 LLM 기반 자율 에이전트 시스템을 설명하면서
핵심 구성요소를 크게 세 가지로 정리한다.

• Planning
• Memory
• Tool Use

이 구조를 보고 나는 되게 명확해졌다.
결국 에이전트라는 건 “똑똑한 모델 하나”가 아니라,
생각하고, 기억하고, 행동하는 시스템이어야 한다는 거다.

LLM은 여기서 뇌(Brain) 역할을 한다.
하지만 사람도 뇌만 있다고 일을 다 잘하는 건 아니다.
할 일을 나눌 줄 알아야 하고,
이전 경험을 기억해야 하고,
필요하면 계산기나 검색 같은 외부 도구도 써야 한다.

에이전트도 똑같다.

2. 첫 번째 축은 Planning이다

잘게 나누고, 스스로 점검하고, 다시 고치는 능력

복잡한 일은 한 번에 못 푼다.
이건 사람도 마찬가지고, 에이전트도 마찬가지다.

그래서 에이전트에게 제일 먼저 필요한 건
계획을 세우는 능력이다.

2-1. 큰 문제를 작은 문제로 쪼개는 것부터 시작된다

Lilian Weng가 정리한 첫 번째 핵심은 Task Decomposition이다.
쉽게 말하면, 큰 일을 작은 일로 나누는 능력이다.

여기서 바로 떠오르는 게
Chain of Thought(CoT) 다.

모델에게 “step by step으로 생각해”라고 하면
복잡한 문제를 더 잘 푸는 이유도 결국 여기에 있다.
한 번에 정답을 던지는 대신,
중간 단계를 만들면서 문제를 쪼개기 때문이다.

그다음으로 나오는 게 Tree of Thoughts(ToT) 인데,
이건 한 방향만 파는 게 아니라
각 단계에서 여러 가능성을 동시에 펼쳐놓고 탐색하는 방식이다.

즉,

• CoT는 한 줄로 생각을 이어가는 느낌이고
• ToT는 가지를 치면서 더 넓게 탐색하는 느낌이다

나는 이 부분이 되게 좋았다.
사실 사람도 어려운 문제를 풀 때
처음 떠오른 답 하나만 밀어붙이지 않는다.
이 방향도 보고, 저 방향도 보고,
틀리면 다시 돌아온다.

에이전트를 잘 만든다는 건
결국 이런 탐색 구조를 어떻게 설계하느냐와도 연결된다.

2-2. 생각만 하는 게 아니라, 행동도 같이 해야 한다

여기서 중요한 개념이 ReAct다.

ReAct는 말 그대로
Reasoning + Acting 이다.

즉,
생각만 하는 것도 아니고,
행동만 하는 것도 아니다.

보통 이런 식으로 흘러간다.

• Thought
• Action
• Observation

그리고 이 흐름을 반복한다.

이 구조가 좋은 이유는 명확하다.
에이전트가 그냥 머릿속으로 상상만 하는 게 아니라,
실제로 검색을 하거나, 환경과 상호작용하고,
그 결과를 보고 다시 생각할 수 있기 때문이다.

이건 그냥 “답변 잘하는 모델”과
“일을 처리하는 에이전트”를 가르는 꽤 큰 차이처럼 느껴진다.

2-3. 한 번 틀렸다고 끝이 아니라, 스스로 돌아봐야 한다

에이전트가 진짜 일을 하려면
결국 실수를 하게 된다.

문제는 실수를 하느냐가 아니라,
그 실수에서 무엇을 배우느냐다.

이 지점에서 나오는 게 Reflexion이다.

Reflexion은 에이전트가
이전 행동을 돌아보고,
왜 실패했는지 반성하고,
그걸 다음 시도에 반영하게 만든다.

나는 이 부분이 꽤 인상 깊었다.
왜냐하면 에이전트를 자율적으로 만든다는 건
단순히 “혼자 실행하게 한다”는 뜻이 아니라,
혼자 수정하게 한다는 뜻까지 포함해야 하기 때문이다.

그냥 시키는 대로 한 번 달리는 모델은
생각보다 금방 한계가 온다.
반면, 실패를 쌓고 거기서 방향을 바꾸는 구조는
훨씬 사람처럼 느껴진다.

Lilian Weng의 글에서도
이런 self-reflection이 real-world task에서 중요하다고 본다.
실제 세계는 trial and error가 기본이기 때문이다.

이건 정말 맞는 말 같다.
현실의 문제는 대부분 한 번에 안 풀린다.

3. 두 번째 축은 Memory다

결국 기억이 없으면 에이전트도 금방 막힌다

에이전트를 생각할 때
많은 사람들이 planning이나 tool use는 직관적으로 이해한다.
그런데 실제로는 memory도 정말 중요하다.

왜냐하면 에이전트가 일을 하다 보면
앞에서 했던 행동, 얻은 정보, 실패한 이유, 중요한 문맥을
계속 가지고 가야 하기 때문이다.

3-1. 단기 기억과 장기 기억은 다르다

이 글에서는 메모리를 크게 두 가지로 나눈다.

• Short-term memory
• Long-term memory

여기서 단기 기억은
현재 컨텍스트 안에 들어 있는 정보에 가깝다.
즉, 지금 대화창 안에서 모델이 보고 있는 것들이다.

하지만 이건 한계가 분명하다.
컨텍스트 윈도우는 유한하고,
길어질수록 중요한 정보가 밀려난다.

그래서 필요한 게 장기 기억이다.

장기 기억은 보통
외부 벡터 스토어(Vector Store) 같은 형태로 구현된다.
필요할 때 검색해서 다시 꺼내오는 방식이다.

이걸 보고 든 생각은 단순했다.

에이전트는 결국 “전부 기억하는 존재”가 아니라,
“필요할 때 잘 찾아오는 존재”여야 한다.

사람도 모든 걸 머릿속에 들고 살지 않는다.
대신 필요할 때 꺼내쓴다.
에이전트도 비슷하다.

3-2. 그래서 벡터 검색이 중요해진다

Lilian Weng의 글에서는
장기 기억을 구현하는 기술적 기반으로
MIPS(Maximum Inner Product Search) 와
여러 ANN 알고리즘들을 설명한다.

예를 들면,

• LSH
• ANNOY
• HNSW
• FAISS
• ScaNN

이 부분은 솔직히 읽을수록
“에이전트는 결국 LLM만의 문제가 아니구나”라는 생각이 더 강해진다.

많은 사람들이 에이전트를
프롬프트나 모델 성능의 문제로만 생각하는데,
실제로는 정보를 얼마나 빠르게 찾고, 다시 붙이고, 활용하느냐가 꽤 중요하다.

즉, 에이전트 성능은
모델만으로 결정되는 게 아니라
검색 구조와 메모리 구조에도 많이 걸려 있다.

이게 되게 현실적이었다.

4. 세 번째 축은 Tool Use다

도구를 쓸 줄 알아야, 진짜 할 수 있는 일이 늘어난다

도구 사용은 인간의 가장 큰 특징 중 하나다.
사람은 손만 쓰는 존재가 아니라,
계산기, 검색엔진, 달력, 현미경, 컴퓨터 같은
외부 도구를 이용해서 자기 한계를 넘는다.

LLM도 마찬가지다.

모델 파라미터 안에 없는 정보는
밖에서 가져와야 하고,
계산이 필요하면 계산기를 써야 하고,
실행이 필요하면 코드를 돌리거나 API를 호출해야 한다.

그래서 tool use는
에이전트에서 사실상 핵심이다.

4-1. LLM은 전문가가 아니라, 라우터에 가깝기도 하다

이 지점에서 나오는 개념이 MRKL이다.

MRKL은
여러 expert module이 있고,
LLM이 그중 적절한 모듈로 요청을 라우팅하는 구조다.

이 설명이 되게 좋았다.
왜냐하면 LLM을 “모든 걸 혼자 잘하는 존재”로 보는 게 아니라,
적절한 전문가를 연결하는 중심 라우터로 보는 시선이기 때문이다.

실제로 이게 더 맞는 방향 같기도 하다.

수학은 계산기로,
날씨는 API로,
현재 뉴스는 검색으로,
코드는 실행기로 해결하는 게 낫다.

LLM이 전부 다 암기하고 해결하려고 하는 것보다,
언제 어떤 도구를 써야 하는지 판단하는 것이 더 중요해진다.

4-2. 결국 중요한 건 ‘도구가 있느냐’가 아니라 ‘도구를 제대로 쓰느냐’다

글에서 반복해서 드러나는 포인트는 이거다.

도구 자체보다, 그 도구를 언제 어떻게 써야 하는지가 더 어렵다.

도구가 있어도,

• API를 호출해야 하는지 판단해야 하고
• 어떤 API가 맞는지 골라야 하고
• 입력값을 제대로 만들어야 하고
• 결과를 다시 해석해야 한다

그래서 API-Bank 같은 벤치마크도
단순 호출 여부만 보는 게 아니라,

• API가 필요한지
• 어떤 API를 써야 하는지
• 여러 API를 엮어 계획할 수 있는지

까지 본다.

이걸 보면 Agent는 진짜로
“도구를 달아놓은 챗봇”이 아니다.

오히려
계획 + 검색 + 선택 + 실행 + 해석이 연결된 시스템에 가깝다.

5. 사례들을 보면 더 명확해진다

Agent는 이미 여러 방향으로 실험되고 있었다

이 글이 좋은 또 하나의 이유는
그냥 개념만 말하는 게 아니라
여러 사례를 같이 보여준다는 점이다.

5-1. 과학 연구용 에이전트: ChemCrow

ChemCrow는 화학 도구들을 붙여서
유기합성, 신약, 재료 설계 같은 작업을 수행하는 에이전트다.

여기서 특히 흥미로웠던 건
LLM이 자기 성능을 평가했을 때와,
실제 전문가가 평가했을 때의 차이다.

LLM은 GPT-4와 ChemCrow가 비슷하다고 봤지만,
전문가 평가는 ChemCrow 쪽이 훨씬 좋았다.

이건 꽤 중요한 포인트다.

LLM은 자기 한계를 잘 모를 수도 있다.

깊은 전문성이 필요한 영역에서는
모델이 그럴듯하게 말한다고 해서
정확성까지 보장되지는 않는다.

이 부분은 Agent를 만들 때도 진짜 중요하다고 생각했다.
결국 실무에서는
“모델이 잘한다고 말하는 것”보다
도메인 전문가가 봤을 때 맞는 결과를 내는지가 훨씬 중요하니까.

5-2. Generative Agents: 사람처럼 살아가는 시뮬레이션

이 사례는 솔직히 되게 재밌다.

25명의 가상 캐릭터가
자기 기억, 계획, 반응 구조를 가지고
샌드박스 환경에서 살아가는 실험인데,
The Sims 같은 느낌에 가깝다.

여기서 핵심은

• 기억을 저장하고
• 관련 기억을 다시 꺼내오고
• 반성(reflection)을 만들고
• 그걸 바탕으로 행동한다는 점이다

그러다 보니 정보 전파, 관계 기억, 사회적 이벤트 같은
예상하지 못한 사회적 행동이 튀어나온다.

이 사례를 보면
에이전트는 단순히 “정답 맞히는 도구”가 아니라,
행동을 만들어내는 구조라는 점이 더 분명해진다.

5-3. AutoGPT와 GPT-Engineer가 보여준 것

AutoGPT는 한때 정말 많은 관심을 받았다.
이유는 단순했다.

“LLM이 메인 컨트롤러가 되어서, 스스로 목표를 향해 움직일 수 있지 않을까?”

이 가능성을 처음 강하게 보여줬기 때문이다.

물론 Lilian Weng도 지적하듯,
실제로는 format parsing 문제나 신뢰성 문제가 꽤 컸다.
자연어 인터페이스가 생각보다 불안정하기 때문이다.

GPT-Engineer도 비슷하게 흥미롭다.
자연어로 요구사항을 받고,
불명확한 부분은 되묻고,
그다음 전체 코드베이스를 생성하는 흐름을 보여줬다.

이 두 사례를 보고 느낀 건 하나였다.

초기 데모는 종종 투박하지만,
그 안에 미래 인터페이스의 방향이 먼저 숨어 있다.

6. 결국 Agent의 가장 큰 문제도 꽤 현실적이다

글 마지막에서 Lilian Weng는
에이전트의 공통 한계를 몇 가지 정리한다.

나는 이 부분이 특히 좋았다.
왜냐하면 Agent를 너무 낭만적으로 포장하지 않기 때문이다.

6-1. 컨텍스트는 여전히 유한하다

에이전트는 긴 히스토리, 툴 사용 기록, API 응답, 반성 결과를
계속 들고 가야 한다.

그런데 컨텍스트 윈도우는 한정적이다.

즉,
에이전트가 잘 일하려면 많은 정보를 가져야 하는데,
정작 그 정보를 계속 품고 가는 건 어렵다.

벡터 스토어와 retrieval이 이를 완화해주지만,
full attention을 완전히 대체하는 건 또 아니다.

이건 지금도 꽤 큰 한계다.

6-2. 긴 계획은 아직 어렵다

짧은 문제는 그럭저럭 푼다.
그런데 여러 단계를 거쳐야 하고,
중간에 오류가 나고,
계획을 수정해야 하는 긴 작업이 들어가면
LLM은 여전히 흔들린다.

이 부분은 나도 많이 공감했다.

사람은 하다가 틀리면
“아 이건 아닌데” 하고 방향을 바꾼다.
그런데 에이전트는 생각보다 그 전환이 매끄럽지 않다.

즉, planning이 있다고 해서
곧바로 robust한 long-horizon planning이 되는 건 아니다.

6-3. 자연어 인터페이스는 강력하지만, 동시에 불안정하다

지금 에이전트 시스템은
기억, 도구, 외부 시스템과 대부분 자연어로 연결된다.

문제는 자연어가 유연한 대신,
그만큼 불안정하다는 점이다.

모델은 포맷을 깨뜨릴 수도 있고,
엉뚱하게 거부할 수도 있고,
명령을 이상하게 해석할 수도 있다.

그래서 많은 에이전트 데모 코드가
실제로는 “얼마나 잘 파싱하느냐”에 많은 시간을 쓴다.

이 대목이 되게 현실적이었다.
겉으로 보기엔 엄청 똑똑해 보여도,
막상 시스템으로 묶으면
사소한 포맷 오류 하나가 전체 흐름을 깨버릴 수 있다.

7. 이 글을 읽고 나서 내가 정리한 한 줄

이 글을 읽고 나서 내 머릿속에는
에이전트가 이렇게 정리됐다.

에이전트는 LLM이 혼자 똑똑해진 결과가 아니라,
LLM이 계획하고, 기억하고, 도구를 쓰도록 시스템을 설계한 결과물이다.

이게 되게 중요하다고 느꼈다.

왜냐하면 Agent를 이야기할 때
자꾸 “어떤 모델이 더 좋냐”로만 흘러가기 쉬운데,
실제로는 그보다
어떤 구조로 묶었는지가 훨씬 중요할 수 있기 때문이다.

• 계획을 어떻게 나눴는지
• 실패를 어떻게 반영하는지
• 장기 기억을 어떻게 저장하고 꺼내는지
• 도구를 언제 어떻게 호출하는지
• 자연어 출력을 얼마나 안정적으로 다루는지

이런 게 다 Agent의 실력을 만든다.

마무리

Lilian Weng의 이 글은
에이전트를 막연한 유행어가 아니라
구성요소가 있는 시스템으로 보게 만들어준 글이었다.

나는 이 글이 특히 좋았다.
에이전트를 과장하지도 않았고,
반대로 단순한 데모 수준으로 축소하지도 않았다.

무엇이 가능했고,
어디서 막히고 있고,
왜 planning, memory, tool use가 다 필요한지
꽤 차분하게 보여준다.

결국 에이전트는
“LLM이 만능이 되는 순간”의 이야기가 아니라,
LLM이 혼자 못하는 걸 인정하고
그 주변 구조를 잘 짜는 이야기에 더 가깝다.

그리고 오히려 그래서 더 현실적이고,
더 재밌다.

진짜 중요한 건
모델 하나를 숭배하는 게 아니라,
문제를 풀 수 있는 구조를 설계하는 것이라는 점을
이 글이 되게 잘 보여줬다고 느꼈다.

참고

• Lilian Weng, LLM Powered Autonomous Agents
• 원문: https://lilianweng.github.io/posts/2023-06-23-agent/

엊그제 GPT를 켰는데, 낯선 숫자가 보였다

GPT-5.4는 뭐가 달라졌을까

엊그제도 어김없이 GPT를 켰다.
그런데 낯선 숫자가 눈에 들어왔다.

GPT-5.4

그래서 바로 찾아봤다.

결론부터 말하면, 이번 5.4는 그냥 “조금 더 좋아진 버전” 느낌은 아니었다.
OpenAI 공식 설명을 보면, GPT-5.4는 전문적인 작업을 위한 가장 성능 좋고 효율적인 프런티어 모델로 소개되고 있고, ChatGPT에서는 GPT-5.4 Thinking, API와 Codex에서는 GPT-5.4, 그리고 복잡한 작업용으로는 GPT-5.4 Pro까지 같이 나왔다.

내가 느낀 핵심은 이거다.

이제는 “어떤 모델을 골라야 하지?”보다, 그냥 5.4 하나로 밀어도 되는 구간이 훨씬 많아졌다는 것.

공식 설명도 비슷하다. GPT-5.4는 최근의 추론, 코딩, 에이전트 워크플로 개선을 하나의 프런티어 모델로 통합했다고 설명한다.
특히 GPT-5.3-Codex의 코딩 역량을 바탕으로, 문서·스프레드시트·프레젠테이션 같은 전문 업무 전반까지 끌어올린 느낌이다.

1. 제일 큰 변화는, 이제 모델을 덜 고민하게 된다는 점

이전에는 상황에 따라 모델을 꽤 의식하게 됐다.

• 문서 정리, 추론, 기획 쪽이면 GPT-5.2
• 코딩, 디버깅, 코드베이스 작업이면 Codex 계열

그런데 GPT-5.4는 이 둘의 장점을 한쪽으로 더 강하게 묶은 느낌이다.

OpenAI도 5.4를 agentic, coding, professional workflows를 위한 최상위 모델로 설명하고 있고,
5.2 대비 코딩, 문서 이해, 도구 사용, instruction following, 멀티스텝 워크플로, 웹 탐색 등에서 전반적으로 개선됐다고 안내한다.

그래서 체감상으로는 이렇다.

코드를 짜다가도 문서 정리로 넘어가고, 그다음엔 표를 만들고, 다시 브라우저를 열어 검증하는 흐름까지 한 모델로 이어지기 쉬워졌다.

이게 이번 5.4에서 제일 실무적으로 크게 느껴지는 부분이다.

2. 벤치마크로 보면 더 확실하다

숫자로 보면 왜 5.4가 “통합형 실무 모델”처럼 느껴지는지 더 잘 보인다.

• GDPval: GPT-5.4 83.0% / GPT-5.3-Codex 70.9% / GPT-5.2 70.9%
• SWE-Bench Pro (Public): GPT-5.4 57.7% / GPT-5.3-Codex 56.8% / GPT-5.2 55.6%
• OSWorld-Verified: GPT-5.4 75.0% / GPT-5.3-Codex 74.0% / GPT-5.2 47.3%
• Toolathlon: GPT-5.4 54.6% / GPT-5.3-Codex 51.9% / GPT-5.2 46.3%
• BrowseComp: GPT-5.4 82.7% / GPT-5.3-Codex 77.3% / GPT-5.2 65.8%

내가 보기엔 여기서 중요한 포인트가 두 개다.

첫째, 5.4는 코딩만 잘하는 모델로 끝나지 않는다.
SWE-Bench 쪽 성능도 높지만, GDPval처럼 실제 지식 업무 결과물을 만드는 평가에서도 확실히 올라갔다.

둘째, 에이전트형 작업에서 강하다.
OSWorld, Toolathlon, BrowseComp 같은 지표를 보면 단순 답변 생성보다, 실제로 도구를 쓰고 웹을 뒤지고 컴퓨터를 다루는 쪽에서 더 존재감이 크다.

그래서 이번 모델은
“말 잘하는 LLM”보다는
“실제로 일을 끝내는 모델” 쪽으로 더 가까워졌다고 보는 게 맞아 보인다.

3. 뭐가 결정적으로 다르냐면

1) 먼저 일의 흐름을 보여주고, 중간에 방향 수정이 가능해졌다

OpenAI 설명을 보면, GPT-5.4 Thinking은 복잡한 요청에서 작업을 시작할 때 preamble 형태로 접근 방식을 먼저 보여주고, 사용자는 응답 중간에도 방향을 수정할 수 있다.
이게 생각보다 크다.

예전에는 한참 생각한 뒤 결과만 받는 느낌이 강했다면,
이제는 “그 방향 말고 이쪽으로” 를 더 자연스럽게 넣을 수 있다.
처음부터 다시 치지 않아도 되는 경우가 많아진다.

이건 단순히 친절해진 게 아니라,
긴 작업을 같이 하는 느낌에 더 가까워졌다.

2) 이제는 진짜 컴퓨터를 다루는 에이전트에 가까워졌다

이번 5.4에서 제일 눈에 띄는 건 native computer-use capabilities다.
OpenAI는 GPT-5.4를 자사 첫 범용 general-purpose 모델 중 native computer use를 갖춘 모델이라고 설명한다.
스크린샷을 보고 마우스와 키보드 동작을 결정하거나, Playwright 같은 라이브러리로 컴퓨터를 조작하는 코드도 잘 다룬다고 소개한다.

벤치마크도 강하다.
OSWorld-Verified에서 GPT-5.4는 75.0%, 인간 전문가는 72.4%로 소개됐다.
GPT-5.2의 47.3%와 비교하면 격차가 꽤 크다.

이건 그냥 “코딩을 잘한다”를 넘어서,
화면을 보고 실제 워크플로를 수행하는 에이전트 쪽으로 한 단계 더 간 느낌이다.

3) 도구가 많을수록 더 빛난다

OpenAI가 5.4에서 강조한 또 하나가 tool search다.
도구나 커넥터가 많아질수록, 필요한 도구를 더 효율적으로 찾아 쓰게 돕는 기능이다.
공식 설명은 5.4가 large ecosystems of tools and connectors에서 더 잘 작동한다고 말한다.

원래 MCP나 복잡한 에이전트 환경은
도구가 많아질수록 프롬프트도 길어지고, 토큰도 많이 먹고, 관리도 귀찮아진다.

그런데 5.4는 이런 도구-heavy 환경에서 토큰 효율이 더 좋아졌고, OpenAI는 5.2 대비 훨씬 적은 토큰으로 문제를 해결한다고 설명한다.

정리하면 이렇다.

도구가 많아질수록 무거워지는 게 아니라, 오히려 이런 환경에서 5.4의 장점이 더 드러난다.

4. 좋아지기만 했을까?

그건 아니다.
좋아진 만큼, 분명히 같이 봐야 할 점도 있다.

1) 가격은 올랐다

API 기준으로 GPT-5.4는 입력 1M tokens당 $2.50, 출력 1M tokens당 $15다.
GPT-5.2는 입력 $1.75, 출력 $14였다.
즉, 입력 기준으로는 꽤 올랐다.

다만 여기서 끝은 아니다.
OpenAI는 5.4가 가장 token-efficient한 reasoning model이고, fewer iterations로 더 높은 품질을 낸다고 설명한다.
그래서 단순 단가만 보면 비싸 보이지만, 실제 총 사용량에서는 상쇄될 가능성이 있다.

즉,

단가는 올랐는데, 일은 더 빨리 끝낼 수도 있는 모델이라는 얘기다.

2) 더 명확하게 시켜야 할 가능성은 있다

공식 문서들을 보면 5.4는 long-running tasks, tool use, disciplined execution, stronger control over style and behavior 쪽으로 설계됐다고 설명한다.
또 시스템 카드에서는 5.4 Thinking이 고도화된 사이버 안전 완화 조치를 처음 적용한 범용 모델이라고 밝힌다.

이걸 내 식으로 풀면 이렇다.

예전보다
“대충 말해도 알아서 넘어가던 느낌” 보다는,
“명확하게 시키면 훨씬 잘하고, 애매하게 시키면 경계를 더 세우는 느낌” 에 가까워질 수 있다.

이건 공식 페이지에 “과도한 거절이 심해졌다”라고 적혀 있는 건 아니고,
안전성과 실행 규율이 강화된 방향을 보고 내가 해석한 체감 포인트다.

5. 그래서 누구한테 제일 체감될까?

GPT-5.2를 주로 쓰던 사람이라면

가장 먼저 느낄 건
답이 더 똑똑해졌다보다,
실제 결과물이 더 실무형으로 나온다는 점일 것 같다.

OpenAI도 5.4에서 스프레드시트, 문서, 프레젠테이션 쪽 성능 향상을 특히 강조했다.
내부 벤치마크에서 스프레드시트 모델링은 87.3% vs 68.4%, 프레젠테이션은 인간 평가자가 68.0% 비율로 5.4를 선호했다고 설명한다.

엑셀, PPT, 보고서, 문서 정리 많이 하는 사람은
체감이 꽤 클 것 같다.

Codex 계열을 주로 쓰던 사람이라면

이쪽은 더 재밌다.

기존에는 코딩이 강점이었다면,
이제는 거기에 문서 이해, 웹 탐색, 도구 검색, 컴퓨터 조작까지 더 붙었다.

즉, 그냥 코드만 짜는 모델이 아니라
직접 확인하고, 실행하고, 검증까지 이어가는 비서 느낌이 더 강해졌다.

마무리

내가 이번 5.4를 보고 든 생각은 단순했다.

이제 AI는
“말 잘하는 모델” 에서
“실제로 일하는 에이전트” 쪽으로 훨씬 더 가까워졌다.

물론 아직 완벽하다는 얘기는 아니다.
가격도 봐야 하고, 안전 경계도 봐야 하고, 여전히 사람의 방향 제시가 중요하다.

그래도 이번 5.4는
“코딩은 이 모델, 문서는 저 모델, 에이전트는 또 따로”
이런 식으로 쪼개 생각하던 흐름을 꽤 많이 밀어냈다.

적어도 지금 공식 설명과 벤치마크를 보면,

GPT-5.4는 OpenAI가 ‘통합형 실무 모델’을 어디까지 밀고 싶은지 보여주는 버전에 더 가깝다.

참고

• OpenAI - Introducing GPT-5.4
• OpenAI API Docs - Models
• OpenAI API Docs - GPT-5.4
• OpenAI - GPT-5.4 Thinking System Card

※ 이 글은 2026.01.26 14:36에 네이버 블로그에 작성했던 글을, 2026.03.14에 velog용으로 다시 다듬어 옮긴 글입니다.

AI는 ‘더 똑똑하게’가 아니라, 어쩌면 ‘더 게으르게’ 발전했다

챗GPT를 가능하게 만든 4번의 발상 전환

요즘은 AI가 너무 자연스럽다.
챗GPT랑 대화하고, 음성을 바로 글로 옮기고, 번역도 거의 실시간으로 쓴다.
이제는 신기한 기술이라기보다, 그냥 일상에 들어온 도구에 가깝다.

그런데 가만히 보면 AI가 좋아진 이유가 꼭
“데이터를 더 많이 넣어서”,
“GPU를 더 세게 써서”만은 아니었다.

오히려 정말 큰 변화는,
문제를 푸는 방식을 살짝 바꾼 아이디어에서 나왔다.

이 점이 나는 되게 흥미로웠다.
기술은 점점 거대해지는데, 정작 판을 뒤집은 건
엄청 복잡한 무언가가 아니라
“어? 이거 그냥 이렇게 바꾸면 되는 거 아니야?”
같은 발상의 전환이었던 거다.

이번 글에서는 현대 AI의 흐름을 크게 바꾼 네 가지 아이디어를 정리해보려고 한다.
하나하나 보면 다 논리적이지만, 처음 등장했을 때는 꽤 대담했고, 그만큼 판을 바꿨다.

1. 순서를 거꾸로 넣었더니 더 잘 배웠다

기계 번역은 대표적인 시퀀스-투-시퀀스(Sequence-to-Sequence) 문제다.
쉽게 말하면, 한 문장을 입력받아 다른 문장으로 바꾸는 문제다.

예를 들어 한국어 문장 “나는 학생입니다”를 입력받아
영어 문장 “I am a student”를 출력하는 식이다.

2014년 Sutskever 연구팀은 여기서 꽤 재밌는 아이디어를 꺼낸다.
입력 문장을 그냥 넣지 말고, 거꾸로 뒤집어서 넣자는 것이었다.

즉,

• 원래 입력: 나는 학생입니다
• 뒤집은 입력: 학생입니다 나는

이런 식이다.

처음 보면 좀 뜬금없다.
문장을 잘 이해하려면 원래 순서대로 넣는 게 더 맞아 보이는데,
실제로는 이 단순한 방법이 성능을 꽤 끌어올렸다.

왜 이런 일이 생겼을까?

그 당시 많이 쓰이던 순환 신경망(RNN)은
긴 문장을 처리할수록 앞부분 정보를 점점 잊어버리는 문제가 있었다.
쉽게 말하면, 기억력이 길게 못 갔던 거다.

원래 방식대로라면 모델은
입력 문장 앞쪽 정보와 출력 문장 앞쪽 정보를
상당히 먼 거리에서 연결해야 했다.

예를 들어 “나는 학생입니다” → “I am a student”라면,
출력의 시작인 “I am”을 만들 때
입력 문장 초반의 “나는” 정보가 중요하다.
그런데 문장을 순서대로 읽다 보면, 이 정보가 뒤로 갈수록 희미해질 수 있다.

반대로 입력을 “학생입니다 나는”처럼 뒤집어 넣으면,
출력 시작에 필요한 핵심 정보인 “나는”가 모델이 마지막에 본 정보가 된다.
즉, 기억이 가장 생생한 상태에서 바로 꺼내 쓸 수 있게 되는 셈이다.

결국 이 방식은 모델을 더 똑똑하게 만든 게 아니라,
모델이 덜 힘들게 학습하도록 문제를 바꾼 것에 가깝다.

“we found it extremely valuable to reverse the order of the words of the input sentence.”
(우리는 입력 문장의 단어 순서를 뒤집는 것이 매우 효과적이라는 점을 발견했다.)
— Sutskever et al. (2014)

나는 이 부분이 되게 인상적이었다.
거창한 구조 변경이 아니라,
입력 순서를 바꿨을 뿐인데 성능이 올라갔다.
결국 모델 성능은 “얼마나 복잡한 걸 넣었는가”보다
얼마나 학습하기 쉽게 문제를 재구성했는가와도 깊이 연결된다는 뜻이니까.

물론 이 방법이 모든 걸 해결한 건 아니었다.
입력을 뒤집는 건 분명 효과적이었지만,
깊은 네트워크 자체를 안정적으로 학습시키는 문제는 여전히 남아 있었다.

2. 정답을 직접 맞히지 말고, ‘차이’만 학습하자

신경망은 층(layer)을 더 깊게 쌓을수록 더 강력해질 것 같지만,
실제로는 어느 지점부터 이상한 일이 벌어졌다.

층을 더 쌓았는데도 성능이 안 오르는 정도가 아니라,
오히려 훈련 오류(training error) 자체가 더 높아지는 현상이 나타난 것이다.

이건 단순한 과적합 문제가 아니었다.
즉, 모델이 너무 복잡해서 시험을 못 보는 게 아니라,
애초에 훈련 자체가 잘 안 되는 상황이었다.

2015년 He 연구팀은 여기서
잔차 학습(Residual Learning) 이라는 아이디어를 제안한다.

기존 방식이 모델에게
“처음부터 완성된 정답 (H(x))를 직접 그려봐”
라고 요구하는 것에 가까웠다면,

잔차 학습은
“이미 입력 (x)는 있으니까,
거기서 뭘 얼마나 바꿔야 하는지만 배우면 되지 않나?”
라는 방향으로 문제를 바꿨다.

즉 모델이 직접 학습하는 건 최종 출력 (H(x))가 아니라,
그 차이값인 (F(x) = H(x) - x) 이다.

이게 왜 중요했냐면,
어떤 층이 사실상 “아무것도 안 바꾸는 것”이 최선일 때
기존 모델은 그걸 복잡한 비선형 연산으로 억지로 흉내 내야 했다.
반면 잔차 학습에서는 그냥 (F(x)=0) 이면 끝이다.

복잡한 그림을 똑같이 복제하는 것보다,
“수정할 게 없다”를 표현하는 게 훨씬 쉬운 것처럼 말이다.

이 차이가 엄청 컸다.
덕분에 연구자들은 이전보다 훨씬 더 깊은 네트워크를 안정적으로 학습시킬 수 있었고,
그 결과물이 바로 ResNet이다.

“We explicitly reformulate the layers as learning residual functions with reference to the layer inputs, instead of learning unreferenced functions.”
(우리는 층이 입력을 기준으로 잔차 함수를 학습하도록 명시적으로 재구성했다.)
— He et al. (2015)

이 아이디어를 보고 느낀 건 하나였다.
처음부터 전부 잘하려고 하지 말고, 바뀌는 부분만 보자.
이건 AI 모델 이야기인데도 이상하게 일하는 방식이랑도 닮아 있다.

전체를 다 통째로 해결하려 들면 막막한데,
지금 상태에서 뭐가 얼마나 달라져야 하는지만 보면
문제가 훨씬 풀기 쉬워진다.

3. 모든 정보를 하나에 욱여넣지 말고, 필요한 순간 다시 보자

초기 인코더-디코더 번역 모델에는 꽤 분명한 한계가 있었다.
아무리 긴 문장이라도, 인코더가 그 모든 정보를 하나의 고정 길이 벡터(Fixed-length vector) 에 압축해야 했기 때문이다.

쉽게 말하면 이런 느낌이다.
누군가가 긴 문장을 한 번만 들려주고,
“이제 이걸 머릿속에 통째로 넣어둔 채 바로 번역해봐”
라고 하는 것과 비슷하다.

짧은 문장은 어떻게든 가능할 수 있다.
그런데 문장이 길어질수록 중요한 정보가 빠지거나 섞이기 쉽다.
결국 구조적으로 병목 현상(Bottleneck) 이 생길 수밖에 없다.

2014년 Bahdanau 연구팀은 이 문제를 해결하기 위해
어텐션(Attention) 메커니즘을 제안했다.

핵심은 단순하다.

문장 전체를 한 번에 다 외우게 하지 말고,
지금 필요한 부분을 그때그때 다시 보게 하자.

이 아이디어가 인상적인 이유는
그 출발점이 단순히 복잡한 수식이 아니라,
사람 번역가의 실제 작업 방식과 닮아 있다는 점이다.

사람 번역가는 문장을 통째로 외운 뒤 번역하지 않는다.
지금 어떤 표현을 옮겨야 하는지에 따라
원문의 어느 부분이 중요한지 다시 보고,
필요한 문맥에 집중하면서 번역을 이어간다.

어텐션은 바로 이 방식과 닮아 있다.

기존 방식에서는 입력 전체를 하나의 벡터에 눌러 담아야 했다면,
어텐션에서는 각 단어의 정보를
벡터들의 시퀀스(Sequence of vectors) 형태로 유지한다.

그리고 디코더가 출력 단어를 하나씩 만들 때마다
이 정보들을 다시 살펴보면서,
지금 가장 관련 있는 부분에 더 큰 가중치를 둔다.

즉, 모든 걸 한 번에 외우는 구조가 아니라
필요한 순간 필요한 곳을 다시 참고하는 구조가 된 것이다.

“A potential issue with this encoder–decoder approach is that a neural network needs to be able to compress all the necessary information of a source sentence into a fixed-length vector.”
(이 인코더-디코더 방식의 잠재적 문제는, 소스 문장의 모든 필요한 정보를 고정 길이 벡터 하나에 압축해야 한다는 점이다.)
— Bahdanau et al. (2014)

결국 이 아이디어의 핵심은
“더 많이 외워라” 가 아니라,
“굳이 다 외우지 말고, 필요할 때 필요한 부분을 다시 보게 하자” 에 더 가깝다.

그런데 여기서 연구자들은 한 발 더 나아간다.

4. 그럼 그냥 어텐션만 쓰면 안 되나?

[ Attention Is All You Need ]

어텐션이 번역 문제에서 큰 효과를 내자,
연구자들은 더 과감한 질문을 던졌다.

“이 정도면, 아예 어텐션만으로도 충분한 거 아닌가?”

2017년 Vaswani 연구팀은 이 질문을 진짜 끝까지 밀고 갔다.
그리고 그 결과가 바로 트랜스포머(Transformer) 다.

트랜스포머는 기존의 순환 구조(RNN)나 합성곱 구조(CNN)에 크게 기대지 않고,
오직 어텐션 메커니즘 중심으로 작동하는 구조다.

왜 이게 그렇게 컸을까?

기존 RNN은 단어를 순서대로 하나씩 처리해야 했다.
즉, 앞 단어를 처리해야 다음 단어로 넘어갈 수 있었다.
이 구조는 병렬 처리에 불리했고,
멀리 떨어진 단어들 사이의 관계를 학습하는 데도 한계가 있었다.

반면 트랜스포머는
문장 전체를 한 번에 보면서
각 단어가 다른 단어와 어떤 관계를 가지는지 계산할 수 있다.

이 말은 곧,

• 병렬 처리가 쉬워지고
• 학습 속도가 빨라지고
• 멀리 떨어진 단어 간 관계도 더 잘 잡고
• 대규모 데이터 학습에도 훨씬 유리해진다는 뜻이다

그리고 이 구조는 결국
오늘날 우리가 쓰는 대부분의 대규모 언어 모델(LLM)의 기반이 됐다.
ChatGPT도 이 흐름 위에 있다.

“We propose a new simple network architecture, the Transformer, based solely on attention mechanisms, dispensing with recurrence and convolutions entirely.”
(우리는 순환과 합성곱을 완전히 배제하고, 오직 어텐션 메커니즘에만 기반한 새로운 네트워크 아키텍처인 트랜스포머를 제안한다.)
— Vaswani et al. (2017)

이 논문 제목이 왜 그렇게 강하게 남았는지도 알 것 같다.
Attention Is All You Need.
처음 보면 꽤 도발적이고 자신감도 넘친다.
그런데 결과적으로는 진짜 시대를 바꿨다.

개인적으로는 이 흐름이 참 멋있다고 느껴졌다.
처음에는 사람 번역가처럼 필요한 부분을 다시 보는 방식에서 힌트를 얻었고,
그다음에는 거기서 멈추지 않고
그 핵심 아이디어 자체를 모델의 중심 구조로 끝까지 밀어붙였다는 점이 인상적이었다.

그냥 성능만 올린 게 아니라,
사람이 실제로 문제를 푸는 방식에서 출발해
그걸 공학적으로 더 강한 구조로 발전시킨 팀이라는 점에서
정말 배울 게 많다고 느꼈다.

마무리: AI는 계산량만으로 크지 않았다

오늘 정리한 네 가지 아이디어는 결이 조금씩 다르다.

• 입력 순서를 뒤집는 발상
• 정답 전체가 아니라 차이만 학습하는 방식
• 필요한 순간 필요한 부분을 다시 보는 어텐션
• 그리고 그 어텐션을 끝까지 밀어붙인 트랜스포머

그런데 이걸 한 줄로 묶으면 결국 비슷한 방향을 본다.

문제를 더 복잡하게 푼 게 아니라, 더 잘 풀리게 바꿨다.

나는 이게 되게 중요하다고 느꼈다.
AI는 무조건 더 거대해지고 더 복잡해져서만 발전한 게 아니었다.
오히려 진짜 큰 점프는
병목을 줄이고, 구조를 바꾸고, 학습이 덜 힘들게 만드는 방식에서 나왔다.

그래서 이 글 제목처럼,
AI는 더 똑똑해졌다기보다
어쩌면 더 게으르게, 더 영리하게 배우는 법을 익혀왔다고 보는 게 더 맞을지도 모르겠다.

특히 인상 깊었던 건
어텐션이라는 아이디어가 그냥 뜬금없이 떨어진 게 아니라,
사람 번역가가 실제로 일하는 방식과 닿아 있었다는 점이다.

사람 번역가는 문장을 전부 머리에 욱여넣고 번역하지 않는다.
지금 문맥에서 중요한 부분이 어디인지 보고,
필요한 순간 다시 원문을 확인하면서
의미와 흐름을 함께 맞춘다.

그 방식을 보고
“그러면 모델도 필요한 순간에 필요한 부분을 다시 보게 만들면 되는 거 아닌가?”
라는 방향으로 나아간 팀이 있었다는 게 참 멋있었다.

그냥 성능만 올린 게 아니라,
사람이 실제로 문제를 잘 푸는 방식을 관찰하고, 그걸 공학적인 구조로 바꿔냈다는 점에서
정말 배울 게 많다고 느꼈다.

나도 이런 연구나 팀을 볼 때마다 느낀다.
기술은 결국 복잡한 걸 더 복잡하게 만드는 사람이 아니라,
본질을 보고, 어려운 문제를 더 잘 풀리는 구조로 바꾸는 사람들이 앞으로 끌고 가는 것 같다.

그게 참 멋있고,
진짜 배워야 할 태도라고 생각한다.