# 재귀적 언어 모델 (Recursive Language Models) > Clean Markdown view of GeekNews topic #25563. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=25563](https://news.hada.io/topic?id=25563) - GeekNews Markdown: [https://news.hada.io/topic/25563.md](https://news.hada.io/topic/25563.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-05T08:32:25+09:00 - Updated: 2026-01-05T08:32:25+09:00 - Original source: [arxiv.org](https://arxiv.org/abs/2512.24601) - Points: 2 - Comments: 1 ## Topic Body - **대규모 언어 모델(LLM)** 이 매우 긴 입력 프롬프트를 처리할 수 있도록 하는 **새로운 추론 전략 RLM(Recursive Language Model)** 이 제안됨 - RLM은 긴 프롬프트를 **외부 환경의 일부로 간주**하고, 모델이 이를 **프로그래밍적으로 탐색·분해·재귀 호출**할 수 있게 함 - 이 방식은 기존 **컨텍스트 윈도 한계를 초월**하여 최대 수천만 토큰 규모의 입력을 처리하며, **기존 LLM 대비 품질이 크게 향상**됨 - 실험 결과, GPT-5 및 Qwen3-Coder 기반 RLM은 **다양한 장문 과제에서 두 자릿수 성능 향상**을 보이며, 비용은 비슷하거나 더 낮음 - 긴 문맥 처리 한계를 극복하고 **LLM의 추론 능력을 대폭 확장할 수 있는 일반적 접근법**으로 평가됨 --- ### RLM 개요 - **Recursive Language Model(RLM)** 은 LLM이 긴 입력을 직접 신경망에 넣지 않고, 이를 **외부 환경의 변수로 취급**해 상호작용하도록 설계 - 입력 프롬프트 P를 Python **REPL 환경**의 변수로 로드하고, LLM이 코드로 이를 탐색·분해·재귀 호출하도록 함 - LLM은 REPL 환경의 상태(예: 문자열 길이)를 인식하고, 코드 실행의 부작용을 관찰하며 점진적으로 문제를 해결 - 이 구조는 기존의 **문맥 압축(compaction)** 이나 **요약 기반 접근법**이 세부 정보를 잃는 문제를 해결함 - RLM은 **입력과 출력 길이를 모두 확장**할 수 있는 일반적 추론 패러다임으로 제시됨 ### 기존 접근법의 한계 - 기존 LLM은 **컨텍스트 윈도우 한계**로 인해 긴 입력에서 성능이 급격히 저하되는 **context rot** 현상을 보임 - 문맥 압축(compaction) 기법은 일정 길이를 넘으면 요약을 반복하지만, **세밀한 정보 접근이 필요한 작업**에는 부적합 - RLM은 프롬프트를 외부 객체로 다루어 **입력 크기를 모델 한계 이상으로 확장**할 수 있음 ### 실험 설정 - 평가 모델: **GPT-5(OpenAI, 2025)** 와 **Qwen3-Coder-480B-A35B(Team, 2025)** - 비교 대상: - 기본 LLM 직접 호출 - **요약 에이전트(Summary agent)** - **CodeAct + BM25** 검색 기반 에이전트 - **RLM(REPL 환경 포함)** 및 **RLM(REPL, 재귀 호출 없음)** - GPT-5 실험에서는 **GPT-5-mini**를 재귀 호출용으로, **GPT-5**를 루트 모델로 사용해 성능과 비용의 균형 확보 ### 평가 과제 - **S-NIAH**: 단일 ‘needle-in-a-haystack’ 문제, 입력 길이에 관계없이 일정한 처리 비용 - **BrowseComp-Plus**: 여러 문서를 넘나드는 **multi-hop 질의응답** 과제, 1000개 문서 중 정답 포함 - **OOLONG**: 입력의 거의 모든 항목을 의미적으로 변환·통합해야 하는 **장문 추론 과제**, 처리 비용이 입력 길이에 선형 비례 - **OOLONG-Pairs**: OOLONG 변형으로, **쌍 단위 정보 결합**이 필요하며 처리 비용이 **입력 길이에 제곱 비례** - **LongBench-v2 CodeQA**: 코드 저장소 이해를 요구하는 **다중 선택형 과제**, 최신 모델에도 어려운 문제 ### 주요 결과 - **RLM은 GPT-5 대비 긴 문맥에서도 성능 저하가 거의 없음** - GPT-5는 입력 길이와 과제 복잡도 증가에 따라 급격히 성능 하락 - RLM은 **272K 토큰 한계를 초과하는 입력(최대 10M+ 토큰)** 도 효과적으로 처리 - **모든 장문 과제에서 RLM이 다른 방법 대비 두 자릿수 성능 향상**을 보임 - **비용 효율성**도 유지되어, 동일 쿼리당 비용이 기존 접근법과 유사하거나 더 낮음 ### 장문 과제의 복잡도 분석 - LLM의 **실질적 컨텍스트 윈도우**는 물리적 한계보다 **과제 복잡도에 따라 더 짧아질 수 있음** - 단순한 NIAH 문제는 1M+ 토큰에서도 해결 가능 - 복잡한 OOLONG류 과제는 훨씬 짧은 길이에서도 성능 저하 발생 - 따라서 과제의 **정보 밀도와 입력 길이의 상관관계**를 함께 고려해야 함 ### 결론 - RLM은 **LLM의 추론 능력을 재귀적으로 확장**하여, 기존 모델이 처리할 수 없는 **초장문 입력**을 다룰 수 있게 함 - **프롬프트를 환경 객체로 다루는 설계**가 핵심 혁신으로, 장문 처리의 구조적 한계를 해결 - 다양한 모델과 과제에서 **성능·비용·확장성의 균형을 달성한 일반적 추론 프레임워크**로 제시됨 ## Comments ### Comment 48667 - Author: neo - Created: 2026-01-05T08:32:25+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46475395) - 이건 그냥 **subagent** 개념처럼 보임 즉, 다른 LLM을 불러 파일을 읽고 필요한 정보를 추출하게 해서 메인 컨텍스트를 복잡하게 만들지 않으려는 방식임 아이디어는 괜찮지만 완전히 새로운 건 아님 - 나는 인간처럼 의인화된 subagent보다는 **컨텍스트 관리** 수단으로 보고 있음 현재 [Scope](https://github.com/adagradschool/scope) 프로젝트에서 관찰 가능한 subagent들이 작업을 재귀적으로 분해하도록 실험 중임 다만 이 **계획 단계 평가**를 어떻게 개선할지 모르겠음 마크다운 파일로 휴리스틱을 기록하지만 구조가 느슨해서 측정이 어려움 관련 문헌이나 프로젝트를 아는 사람이 있다면 알려주면 좋겠음 - 논문에서는 이렇게 말함 RLM은 에이전트도 요약도 아님 여러 LM 호출을 하나의 시스템에서 사용하는 건 새로운 개념이 아니며, 이는 대부분의 **agentic scaffold**가 하는 일임 가장 유사한 예로 **ROMA agent**가 문제를 분해해 여러 sub-agent로 해결하는 방식을 들 수 있음 또 **Cursor**나 **Claude Code** 같은 코드 어시스턴트도 컨텍스트가 길어질수록 요약하거나 가지치기함 이런 접근은 보통 작업 단위로 분해하지만, RLM은 **컨텍스트 단위 분해**를 강조하며 그 선택은 LM이 스스로 결정해야 한다고 봄 - 제목만 보면 전체 연산이 **differentiable**하고 하나의 모델로 학습된 것처럼 들리지만, 실제로는 단순히 모델을 반복 호출하는 수준으로 보임 - subagent가 또 다른 subagent를 무한히 호출할 수 없다면 그건 **재귀적**이라 할 수 없음 - 동일한 컨텍스트(파일 시스템이나 REPL 변수)에 접근하고 조작하는 sub-agent 개념을 말하는 것 같음 - 핵심 통찰은 긴 프롬프트를 신경망(Transformer)에 직접 넣지 말고, LLM이 **상징적으로 상호작용할 수 있는 환경**의 일부로 다뤄야 한다는 것임 그런데 이게 근본적으로 **RAG**와 어떻게 다른지 궁금함 그림 4를 보면, 차이는 사람이 아닌 LLM이 직접 retrieval 메커니즘을 구현한다는 점 같음 - 내가 보기엔 두 가지 차이가 있음 1️⃣ RAG는 **workflow**에 가깝고, 이건 좀 더 **agentic**함 2️⃣ **재귀적 구조**를 가짐 workflow에서는 사람이 단계별로 흐름을 짜지만, agentic 접근에서는 에이전트가 스스로 무엇을 검색하고 몇 번 호출할지, 언제 답변할지를 결정함 예를 들어 **Claude Code**나 **Codex**가 코드베이스를 탐색하며 파일을 읽고 ripgrep을 돌리는 식임 이런 재귀적 시도는 예전에도 있었지만 (예: babyagi, 2023년경) 당시 모델 성능이 부족해서 많은 **glue code**가 필요했음 이제는 모델이 충분히 강력해져서 이런 구조가 실제로 작동함 - “T̶u̶r̶t̶l̶e̶s̶ LLMs all the way down”이라는 농담처럼, 끝없이 LLM이 LLM을 호출하는 구조를 암시함 - “attention is all you need”를 반복적으로 적용하는 셈이며, 결국 우리가 추구해야 할 건 **정밀도(precision)** 임 - 더 읽기 쉬운 버전의 글이 있음: [alexzhang13 블로그 글](https://alexzhang13.github.io/blog/2025/rlm/) - 2026년에 바라는 점은 **Anthropic**이나 **OpenAI**가 CLI 플러그인 제작자에게 “compaction이 어떻게 실행되는지”를 공개하는 것임 이 기술은 **Claude Code**에 내장된 기능을 대체할 수도 있지만, 현재는 적절한 **hook**이나 기능이 노출되어 있지 않음 - **Codex**가 오픈소스라면 직접 읽어볼 수 있지 않나? 나는 **Gemini** 소스를 봤는데, 컨텍스트 윈도우가 가득 차면 전체를 요약하는 단순한 프롬프트 구조였음 - 이 논문과 유사해 보임: [arXiv:2510.14826](https://arxiv.org/abs/2510.14826)