RLM을 에이전트에 붙여본 이야기: 컨텍스트 윈도우의 한계를 우회하는 방법

시작점: 논문 하나를 던지다

어느 날 Discord에서 에이전트에게 링크 하나를 던졌습니다. arXiv 링크였고, 제목은 "Recursive Language Models". MIT OASYS Lab에서 나온 논문이었습니다.

에이전트가 논문을 읽고 분석해줬습니다. 핵심 내용은 이거였습니다. LLM이 컨텍스트 윈도우를 넘어서는 긴 프롬프트를 처리할 수 있게 하는 방법이라고. 그리고 그 방법이 꽤 우아하다고. 그런데 읽다가 든 생각이 있었습니다. "이거 우리 에이전트에 붙일 수 있지 않나?"

Hermes라는 에이전트를 운영하고 있습니다. 이 에이전트는 Discord, CLI 등 여러 환경에서 돌아가는데, 대화가 길어지면 컨텍스트 압축으로 대응하고 있습니다. 압축은 정보 손실이 불가피합니다. RLM이 정말로 이 문제를 해결할 수 있다면, 적어도 확인해볼 가치가 있었습니다.

RLM이 뭔가

Recursive Language Models, 줄여서 RLM은 한마디로 프롬프트를 모델 밖에 두고 코드로 쪼개서 처리하는 방법입니다.

기존 LLM은 프롬프트를 통째로 입에 넣고 씹어야 합니다. 컨텍스트 윈도우가 128K면 128K까지만 들어가고, 그 이상은 불가능합니다. 심지어 윈도우 안에서도 프롬프트가 길어지면 품질이 떨어집니다. 이 현상을 논문에서는 "context rot"이라고 부릅니다.

RLM은 이 문제를 프롬프트를 외부 변수로 만드는 것으로 해결합니다. 구체적으로는 이렇게 돌아갑니다.

프롬프트를 Python REPL 환경의 변수에 저장합니다. LLM은 프롬프트를 직접 읽지 않고, 길이나 앞부분 같은 메타데이터만 받습니다.
LLM이 코드를 작성해서 프롬프트를 조각냅니다. 예를 들면 context[:5000] 같은 코드로 앞부분을 확인합니다.
필요하면 sub-LLM을 재귀적으로 호출해서 각 조각을 처리합니다.
결과를 REPL에서 모아서 최종 응답을 반환합니다.

이게 왜 되는 걸까요. 핵심은 프롬프트가 모델의 컨텍스트 윈도우를 타지 않는다는 점입니다. 프롬프트는 항상 REPL 변수에 온전히 보존되어 있고, 모델은 필요한 부분만 그때그때 꺼내서 봅니다. 정보 손실이 없습니다.

기존 방식과 뭐가 다른가

현재 긴 컨텍스트를 처리하는 방법은 크게 세 가지가 있습니다.

Context Compaction(압축). 대화가 길어지면 이전 내용을 요약해서 공간을 만듭니다. Hermes도 현재 이 방식을 쓰고 있습니다. 문제는 압축 과정에서 디테일이 날아간다는 점입니다. "사용자가 3일 전에 A라고 했다"는 정보는 요약에 남을 수 있지만, "사용자가 말한 구체적인 설정 값"은 사라질 수 있습니다.

RAG(검색). 관련 부분만 검색해서 제공합니다. 지식베이스에서 정보를 찾을 때는 효과적이지만, 검색에 걸리지 않으면 놓치고, 키워드 기반 검색은 의미적 맥락을 놓치기 쉽습니다.

RLM은 이 두 방식의 한계를 다른 각도에서 공격합니다. 원본 전체가 REPL 변수에 살아있으니 압축할 필요가 없고, 코드로 의미적 분해가 가능하니 검색의 한계도 우회합니다.

논문의 결과는 인상적이었습니다. GPT-5의 컨텍스트 윈도우가 272K인데, RLM은 그 100배인 10M+ 토큰을 처리했습니다. 그러면서도 비용은 비슷한 수준이었습니다. 정보 밀집 태스크인 OOLONG에서는 GPT-5가 44점일 때 RLM은 72.4점이었습니다.

직접 테스트해보다

논문만 읽고 "되겠네"라고 할 수는 없었습니다. 직접 돌려봐야 했습니다.

설치

pip install rlms 한 방이면 끝이었습니다. 의존성이 많이 달려있긴 했지만 설치 자체는 깔끔했습니다.

첫 번째 테스트

백엔드는 현재 Hermes가 쓰는 GLM-5.1을 OpenAI 호환 API로 연결했습니다. "2 + 3은?"이라는 간단한 질문을 던졌습니다. 11.3초 만에 "5"라는 정답이 돌아왔습니다. RLM이 REPL을 띄우고, 코드를 작성하고, 모델을 호출하는 전체 과정이 정상 작동했습니다.

두 번째 테스트: Needle-in-Haystack

이번엔 본격적으로 테스트했습니다. 텍스트 안에 "APPLE"이라는 숨겨진 단어를 넣고 찾으라고 시켰습니다. 결과는 정답이었습니다. RLM이 세 번의 iteration으로 문제를 풀었습니다.

Iteration 1: print(context)         → 프롬프트 전체 확인
Iteration 2: llm_query("찾아줘")    → sub-LLM으로 검색
Iteration 3: FINAL(APPLE)           → 정답 반환

하지만 시간이 206.7초, 약 3.4분이 걸렸습니다. 간단한 질문도 11초인데 조금만 길어져도 3분이 넘습니다.

세 번째 테스트: 50K chars

5만 자짜리 긴 텍스트로 테스트했는데, 이번엔 5분이 넘어도 응답이 안 왔습니다. 결국 타임아웃이었습니다.

원인을 분석해보니, GLM-5.1이 RLM의 REPL 코드 작성 방식을 완벽히 따르지 못했습니다. RLM은 모델이 "프롬프트를 코드로 분해하라"는 지시를 잘 따라야 하는데, 논문에서도 이 부분을 언급하고 있었습니다. 프롬프팅만으로는 한계가 있고 파인튜닝이 필요하다고. 파인튜닝된 RLM-Qwen3-8B가 일반 Qwen3-8B보다 28.3% 좋았다는 결과가 이걸 뒷받침합니다.

즉, 모델이 충분히 똑똑해야 RLM이 제 역할을 한다는 것입니다. GPT-5나 Claude 급의 고성능 모델에서는 논문 결과처럼 잘 동작하겠지만, 가성비 모델에서는 한계가 있습니다.

에이전트에 어떻게 붙일까

테스트 결과를 보고 세 가지 적용 레벨을 고민했습니다.

레벨 1: 독립 도구로 등록. 가장 안전한 방법입니다. RLM을 하나의 도구로 만들어서, 에이전트가 긴 문서를 만나면 선택적으로 호출하게 하는 것입니다. 기존 동작에 영향이 없고, 실패해도 에이전트는 정상 작동합니다.

레벨 2: 컨텍스트 압축 대체. Hermes의 context_compressor.py가 현재 요약으로 컨텍스트를 관리하는데, 이걸 RLM 방식으로 바꾸는 것입니다. 에이전트가 긴 세션에서도 초반 대화를 잊지 않게 됩니다. 하지만 매 턴마다 오버헤드가 발생할 수 있습니다.

레벨 3: 에이전트 루프 자체를 RLM으로 재설계. 가장 근본적인 변경입니다. 프롬프트를 항상 외부 변수로 처리하고, 도구 호출도 코드로 생성하게 만드는 것입니다. 이론적으로 가장 강력하지만, Hermes 전체를 뜯어고쳐야 하고 안정성 리스크가 큽니다.

현재 상황에서 레벨 1이 현실적이라고 판단했습니다. 리스크가 없고, 즉시 사용 가능하고, 경험을 축적하면서 다음 단계를 고민할 수 있습니다.

레벨 1을 구현하다

구현 자체는 단순했습니다. Hermes의 도구 시스템이 깔끔하게 설계되어 있어서 세 파일만 건드리면 됐습니다.

tools/rlm_tool.py를 새로 만들었습니다. RLM 라이브러리를 래핑해서 Hermes의 도구 레지스트리에 등록하는 코드입니다. 백엔드 설정은 Hermes config에서 자동으로 읽어오게 했습니다. 에이전트가 rlm_query 도구를 호출하면, 프롬프트를 RLM에 넘기고 결과를 JSON으로 돌려받는 구조입니다.

model_tools.py에 import 한 줄을 추가하고, toolsets.py에 도구 이름을 추가했습니다. 총 3개 파일, 실제 변경은 10줄 남짓이었습니다.

테스트도 통과했습니다. 도구가 40개 등록된 Hermes에서 rlm_query가 정상적으로 인식되었고, 직접 호출했을 때도 정답을 반환했습니다.

아쉬운 점과 다음 단계

시간이 오래 걸립니다. 간단한 질문도 11초, 조금 복잡하면 3분입니다. 실시간 채팅에서 매번 이 시간을 기다리게 할 수는 없습니다. RLM은 긴 문서 분석 같은 특정 상황에서만 선택적으로 쓰는 게 맞습니다.

모델 의존성이 큽니다. GLM-5.1 같은 가성비 모델에서는 짧은 태스크까지만 잘 됩니다. 긴 태스크는 고성능 모델이 필요합니다. 이건 RLM의 문제라기보다, RLM이 "모델이 코드를 잘 작성할 수 있어야 한다"는 전제를 가지고 있기 때문입니다.

아직 자동이 아닙니다. 현재는 에이전트가 스스로 RLM을 선택해서 써야 하는데, "이 프롬프트는 길다 → RLM으로 처리하자"라는 판단을 에이전트가 잘 내릴지는 더 지켜봐야 합니다.

다음 단계는 이렇게 생각하고 있습니다. 레벨 1로 계속 쓰면서 어떤 상황에서 RLM이 효과적인지 데이터를 모으는 것. 그 데이터가 쌓이면 레벨 2로 갈지, 아니면 다른 방법을 찾을지 판단할 수 있을 것입니다.

참고 자료

Recursive Language Models (arXiv:2512.24601) — Alex L. Zhang, Tim Kraska, Omar Khattab. MIT OASYS Lab. 이 글의 모든 내용이 여기서 시작되었습니다.
GitHub: alexzhang13/rlm — RLM 라이브러리. pip install rlms로 설치 가능. 3.3K stars.
Hermes Agent — RLM 도구를 통합한 에이전트. 오픈소스.