"컨텍스트를 객체로 다룬다" — RLM이 기존 툴 호출과 다른 이유

마두라는 RLM을 "recursive language model"의 약자로 정의하며, 여기서 핵심 차이가 나온다고 짚었다. RLM은 컨텍스트를 자기 환경 안에서 기호적으로 상호작용할 수 있는 객체로 취급한다.

툴 호출과의 차이는 명확하다. 툴 호출은 JSON이나 문자열을 보내고 다른 곳에서 해석된 뒤 문자열로 돌려받는 방식이지만, RLM은 그 기호적 환경 자체에서 직접 작업한다. 이 기호적 환경은 보통 파이썬 REPL이다.

같은 모델을 쓸지 다른 모델을 쓸지 지정할 수 있으며, 이 하위 호출은 특정 파라미터를 갖고 역시 그 REPL 환경 안에 존재한다.

이 능력은 문제를 재귀적으로 분해할 수 있게 해준다. 메인 LLM이 논리를 어떻게 적용할지, 해석을 어떻게 할지, 자기 코드를 어떻게 쓸지를 스스로 결정한다.

하위 언어모델도 같은 방식으로 재귀할 수 있다. 자신이 무엇을 해야 한다고 판단했는지를 스스로 해석해 다시 위임을 반복하는 구조다.

마두라는 알렉스와 오마르의 논문 및 블로그 글을 근거로 제시했다. ULong 벤치마크는 지나치게 긴 컨텍스트에 대한 질문에 모델이 답하는 성능을 측정하고, BrowseComp는 모델이 대규모 텍스트 코퍼스를 반복 순회하며 특정 질문에 답해야 하는 과제다.

차트에서 맨 위 파란 선이 RLM이다. 가격 곡선에서는 보라색 선이 GPT-5로 BM25 툴을 호출하는 순수 툴 호출 방식인데, 이 방식이 RLM보다 오히려 더 비싸고 성능은 더 나쁘다.

마두라는 스스로를 "매우 DSPy에 물든(very DSPy pilled)" 사람이라고 소개하며 오마르와 그 그룹의 제자라고 말했다. 그의 멘탈 모델은 하고자 하는 작업 주변에 비교적 결정론적인 껍데기를 두는 것이다.

실제 과제는 입력과 출력, 그리고 모델에 줄 가이드나 프롬프트로 정의한다. "대략 이것을 달성하고 싶다, 가서 해봐"라는 패턴이며, 기대하는 입력과 원하는 출력을 함께 명시하는 방식이다. 그러면 구현 가운데가 어떻게 돌아가는지를 덜 걱정해도 된다.

입출력에 대한 보장은 그대로 유지하면서 나머지 부분은 모델이 알아서 풀게 하는 구조다. 마두라는 이것이 DSPy에도 적용되고 RLM에도 적용된다고 말했다.

마두라는 뉴욕시에서 열린 11월 행사에서 덱스(Dex)가 한 발표를 인용했다. 덱스는 더 넓은 컨텍스트 엔지니어링을 다룬 그 발표에서 "멍청한 구역(the dumb zone)"이라는 표현을 만들었고, 슬라이드 하단에 회색으로 표시된 이 구역을 마두라가 다시 꺼냈다.

컨텍스트 윈도가 어느 정도까지 채워지면 성능이 떨어지기 시작하는데, 마두라는 이것을 컨텍스트 로트라고 부른다. RLM에서는 전체 컨텍스트와 입력이 컨텍스트 윈도에 노출되지 않고 리플(REPL) 안의 변수로 존재한다. 메인 언어모델이 그 변수에 어떻게 접근할지 결정하고 하위 작업을 하위 언어모델로 넘길 수 있으며, 실제로 중요한 결과만 메인 모델로 돌아온다.

RAG는 컨텍스트 윈도를 채워 넣고 거기서 제한하려는 접근이다. 에이전트는 대체로 문자열을 되가져올 뿐이고, 논리와 실행, 결과 사이에 긴밀한 결합이 없다. 툴 호출과 CodeAct도 같은 문제에 부딪힌다.

RLM은 언어모델이 결과를 리플 안의 변수로 다루며 추가 연산을 할 수 있다. 컨텍스트 윈도에 있는 모든 토큰에 어텐션을 기울이는 대신 변수에 직접 손을 대는 방식이며, 마두라는 이것이 언어모델이 콘텐츠와 상호작용하는 의미 있게 다른 방식이라고 말했다.

마두라가 꼽은 가장 큰 차이는 툴 호출이 문자열을 주고받는다는 점이다. 앤스로픽이 최근 내놓은 워크플로는 상당히 비슷한 일을 한다.

CIS 컨퍼런스에서 타르(또는 비슷한 인물)가 RLM 논문을 워크플로의 핵심 동력이자 구현 근거로 언급한 것은 마두라의 설명이다. 워크플로에서도 중간 결과는 스크립트 변수, 즉 컨텍스트 안의 변수에 산다.

마두라의 요점은 연구소들의 기법이 이런 돌파구를 이끌고 있다는 것이다.

여러 과제에서 전체 정확도가 2.6%에서 45.4%로 뛰었다.

코드로 풀기 좋은 과제에서 특히 잘 작동한다. 논리 퍼즐, 체스, 화학이 그 예다. 코드를 동적으로 작성하고 컨텍스트에서 관련된 부분만 가져와 계산한 뒤 결과를 반환하는 메커니즘이다. 메인 모델은 직접 계산하려 들지 않고 하위 언어모델의 결과를 수확한다. 마두라는 발표 후 링크를 자료로 남기겠다고 말했다.

마두라는 이 예시들이 베이스 모델에 "다소 불공평하다"고 인정하면서도 요점은 전달된다고 말했다. 컨텍스트 윈도의 모든 토큰에 한꺼번에 어텐션을 기울여야 하는 과제는 베이스 모델이 스스로 감당하기 어렵다는 주장이다.

3만 토큰에 흩어진 숫자 12개를 더하는 데모가 제시됐다. 답을 추측하는 베이스 LLM은 정규식을 쓸 수 있는 방식만큼 잘 작동하지 않으며, 같은 논리가 데이터프레임에도 적용된다는 점을 마두라는 이어서 덧붙였다.

같은 실험을 코딩 에이전트로도 돌렸지만 마두라는 "너무 깊이 보지는 않았다"고 말했다. "아마 여기엔 좀 불공평한 계산이 들어가 있을 것"이라고도 인정했다.

그는 클로드 코드가 이 과제를 푸는 방식이 "완전히 부풀려져 있었다"고 표현했다. 베이스 모델과 RLM, 코딩 에이전트를 비교하는 실험은 더 필요한 열린 질문으로 남겨뒀다.

프로덕션 워크로드에 대해서는 프롬프트를 "클로드에 처박고" 좋은 결과를 기대할 게 아니라 입력과 출력에 구조화된 접근과 정의된 파이프라인이 필요하다는 것이 그의 판단이다. 그렇게 하면 비용과 복잡성, 부풀림이 줄어든다는 것이 그의 주장이다.

마두라는 "어제" 올라온 샘 호건(Sam Hogan)의 트윗을 거론했다. 샘 호건은 inference.net을 운영한다.

그는 RLM을 써서 특정 프로덕션 워크로드 트레이스에서 통찰을 추출하고, GLM 5.2 같은 모델로 넘기는 것이 합리적인 부분을 가려낸다. 트래픽이 흘러가는 동안 이 판단을 반복적이고 자동으로 수행한다.

RLM은 자기만의 REPL을 갖고 데이터프레임과 상호작용한다. 트레이스를 보면 "먼저 이걸 해야 한다"고 추론한 뒤 코드를 작성하는 순서가 그대로 드러난다.

데이터프레임과 같은 REPL에 살기 때문에 툴 호출이 오가는 부풀림이 없다. 마두라는 LLM이 자기 주피터 노트북에 타이핑하는 것과 같다고 비유했다. 이 사례에서는 하위 LLM으로 넘기지 않았지만 그럴 선택지도 있으며, 위임 경로는 데이터의 큰 부분집합을 하위 LLM에 넘기고 분석 결과를 요청하는 과정을 반복하는 식이다.

마두라는 컴파운드(Compound)라는 플랫폼을 RLM 및 DSPy 네이티브라고 소개했다. 추론 과정을 잘게 나눠 보여주고 생성되는 코드를 분리해 표시한다.

최종 출력에서는 핵심 발견과 권고 사항을 정리해 포맷한다. 마지막 제출 단계는 처음에 정의한 타입이 지정된 출력을 반환한다.

마두라는 추상화 수준을 계속 올려갈 수 있는 세계가 보인다고 말했다. 목표와 모델이 해주길 원하는 것을 정의할 수만 있다면 나머지는 모델이 알아서 푼다는 것이다. 그는 예시 코드에서 모델이 밟은 단계들을 하나씩 짚어 나갔다.

RLM을 쓰면 200페이지짜리 청구서나 계약서가 있어도 크게 걱정할 필요가 없다. RLM이 전체를 통째로 처리해 결과를 내놓게 하면 된다.

이것은 청킹과 임베딩, 그리고 컨텍스트 윈도 관리를 우회하기 위해 우리가 해왔던 여러 전략을 대체한다. 마두라가 든 이점은 컨텍스트 엔지니어링이 아니라 추상화와 실제로 하고 싶은 일에 집중할 수 있다는 것이다.

마두라는 이 주장을 검증할 실험을 하고 싶다고 말했다. 다만 퀸(Quinn) 같은 더 저렴한 모델이나 다른 모델들의 성능을 끌어올릴 것으로 본다고 그는 덧붙였다.

메커니즘은 입력과 출력을 지정하고 돌아오는 타입을 강제하는 것이다. 그러면 RLM이 정보를 처리하는 이점에 더해 중간에 구조가 더해지는 효과가 생긴다.

헤일로(Halo)라는 프로젝트는 RLM을 써서 여러 에이전트 과제의 트레이스를 들여다본다. 특정 워크플로나 DSPy, 다른 프레임워크 구조 자체를 최적화하는 대신 하네스를 반복 개선한다. 마두라는 이것을 메타 추상화, 혹은 하네스 자체의 메타 최적화라고 불렀다.

RLM을 쓰는 이유는 트레이싱이 매우 길고 복잡해지기 때문이다. RLM이 그 컨텍스트를 전부 받아들이고 트레이스의 구조를 활용해 더 나은 하네스를 권고한다.

컨텍스트 엔지니어링이 많이 필요하지 않다는 것이 마두라의 명시적 주장이다. 원하는 것을 달성하는 데 그것을 둘러싼 구조가 많이 필요하지도 않다.

임의 크기의 코드베이스를 넣고 어떤 형태의 통찰을 얻어낼 수 있다. 그는 이것이 다른 영역에도 일반화된다고 말했다.