# \#rlm

**URL:** https://discuss.pytorch.kr/tag/rlm/6283.md

[최신](https://discuss.pytorch.kr/latest.md) · [카테고리](https://discuss.pytorch.kr/categories.md) · [태그](https://discuss.pytorch.kr/tags.md)

---

## [Prime Intellect, 컨텍스트를 변수로 다루는 자기개선형 코딩 에이전트 Prime Agent 공개](https://discuss.pytorch.kr/t/prime-intellect-prime-agent/11544)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [8월 7, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/prime-intellect-prime-agent/11544 "2026-08-07T09:30:50Z")

</div>

Prime Agent 소개 Prime Intellect가 공개한 Prime Agent 는 코딩과 장시간 자율 작업을 위한 오픈소스 에이전트 하네스(harness)로, 재귀 언어 모델(Recursive Language Model, RLM) 과 지속 개선 하네스(Continual Harness) 라는 두 가지 추상화 위에 설계되었습니다. 여기서 하네스란 모델 자체가 아니라 모델을 감싸고 도구 호출, 컨텍스트 관리, 서브 에이전트 실행을 조율하는 실행 환경을 뜻합니다. 최근 코딩 에이전트의 성능이 모델만이 아니라 하네스 설계에 크게 좌우된다는 점이 여러 벤치마크에서 확인되면서, 하네스 자체가 독립적인 연구 대상이 되고 있습니다. Prime Intellect가 문제로 지목한 것은 현재 널리 쓰이는 하네스들이 이전 세대 모델의 능력을 전제로 만들어졌다는 점입니다. 고정된 도구 호출 스키마(tool-calling schema)와 컨텍스트 압축(compaction)은 모델이 자신을 둘러싼 보조 코드(Scaffolding)를 활용하는 대신 그것을 우회하도록 만들고, 손으로 설계한 서브 에이전트와 프롬프트, 스킬, 메모리는 설계 시점에 한 번 정해진 뒤 실행 중에 배운 것을 반영하지 못합니다. 원문은 하네스가 "현재 모델의 능력을 외삽하여 다음 세대의 추론 패턴을 향해 나아가야 한다" 는 관점을 제시합니다. 이러한 맥락에서 Prime Agent가 택한 접근은 단순합니다. 모델에게 주는 도구를 하나로 줄이되, 그 하나를 지속되는 IPython 커널로 삼는 것입니다. 파일 조작, 셸 명령, 서브 에이전트 실행, 컨텍스트 관리가 모두 코드로 이뤄지므로, 모델은 자기 자신의 대화 이력을 변수처럼 다루고 서브 에이전트를 함수처럼 호출할 수 있습니다. 여기에 하네스의 상태(프롬프트, 스킬, 메모리, 서브 에이전트 명세)를 에이전트가 직접 생성하고 수정할 수 있게 열어 두면, 실행 중에 배운 것이 다음 턴과 다음 세션으로 이어집니다. 저자들은 이 두 추상화를 모델의 능력을 끌어내…

---

## [Claude Code RLM: Claude Code에서 Recursive Language Model (RLM) 패턴을 사용할 수 있도록 하는 플러그인](https://discuss.pytorch.kr/t/claude-code-rlm-claude-code-recursive-language-model-rlm/8820)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [1월 26, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/claude-code-rlm-claude-code-recursive-language-model-rlm/8820 "2026-01-26T03:30:07Z")

</div>

Claude Code RLM 소개 Claude Code RLM은 Brainqub3가 구현한 프로젝트로, Recursive Language Models (RLM) 패턴을 Anthropic의 Claude Code 프레임워크 내에서 사용할 수 있도록 설계된 스캐폴딩(Scaffold)입니다. 이 프로젝트의 핵심은 단일 LLM이 한 번에 처리하기 힘든 방대한 양의 데이터나 문서를 '재귀적'인 방식으로 나누어 처리하고 요약하여, 최종적으로 모델의 물리적인 컨텍스트 윈도우(Context Window) 한계를 수십 배 이상 뛰어넘는 결과를 도출하는 데 있습니다. 이 기술이 중요한 이유는 현대의 소프트웨어 개발 환경이 수만 라인의 코드와 수백 페이지의 문서를 포함하기 때문입니다. 기존에는 RAG(Retrieval-Augmented Generation)를 통해 필요한 부분만 검색해 왔다면, RLM 방식은 전체 맥락을 유지하면서도 세부 사항을 놓치지 않도록 구조적으로 정보를 계층화합니다. 특히 MIT CSAIL의 최신 연구(arXiv:2512.24601)를 바탕으로 구현되어, 이론적 토대와 실용성을 모두 갖춘 도구로 평가받고 있습니다. 향후 이를 통해 긴 로그 파일 분석, 대규모 레포지토리의 전체 구조 파악, 그리고 복잡한 기술 사양서 기반의 코드 생성 등 기존 LLM 인터페이스로는 불가능했던 작업들을 수행할 수 있게 될 것으로 기대합니다. 또한, 단순히 정보를 찾는 수준을 넘어, 거대한 환경 자체를 LLM이 이해하고 조작할 수 있는 환경을 제공하는 것을 목표로 합니다. :pytorch::kr: RLM(Recursive Language Model)에 대한 더 상세한 내용은 다음 게시물을 참고해주세요: RLM vs. RAG 방식 비교 일반적으로 긴 문서를 처리하기 위해서 사용하는 RAG(Retrieval-Augmented Generation) 기법과 RLM 방식을 비교하면, RAG(Retrieval-Augmented Generation) 는 질문과 관련된 파편화된 정…

---

## [Recursive Language Models(RLM): LLM의 컨텍스트 길이 제한을 극복하기 위한 재귀 호출 아키텍처에 대한 연구](https://discuss.pytorch.kr/t/recursive-language-models-rlm-llm/8617)

<div class="topic-metadata">

**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\
**댓글:** 0\
**마지막 업데이트:** [1월 7, 2026, 9:30오후 UTC](https://discuss.pytorch.kr/t/recursive-language-models-rlm-llm/8617 "2026-01-07T21:30:11Z")

</div>

RLM(Recursive Language Models) 연구 소개 LLM 컨텍스트 크기의 한계 최근 GPT-4-128k, Claude 3-200k, Gemini 1.5-1M 등 LLM의 입력 문맥 길이(Context Window)는 기하급수적으로 늘어났습니다. 많은 개발자가 이를 "이제 모든 문서를 프롬프트에 넣으면 해결된다"는 신호로 받아들였지만, 실제 현업에서의 경험은 다릅니다. 문맥의 길이가 길어질수록 모델이 정보의 위치를 찾지 못하거나(Lost in the Middle), 상충하는 정보 간의 논리적 연결을 놓치는 현상이 종종 발생합니다. 연구자들은 이러한 현상을 문맥 부패(Context Rot) 라고 부릅니다. 이는 단순히 어텐션(Attention) 메커니즘의 산술적 한계 때문만이 아닙니다. 모델이 한 번의 순전파(Forward Pass)로 처리해야 할 정보의 밀도가 너무 높아지면서, 핵심 정보에 할당되어야 할 어텐션 스코어(Attention Score)가 희석되기 때문입니다. 지금까지는 이 문제를 해결하기 위해 크게 두 가지 접근법을 사용했습니다: 하나는 문맥 창 자체를 늘리는 초장문맥(Long-Context) 모델을 개발하는 것이고, 다른 하나는 필요한 정보만 검색해서 가져오는 RAG(Retrieval-Augmented Generation) 방법입니다. 하지만 Long-Context 모델은 앞서 언급한 문맥 부패(Context Rot) 문제와 더불어 추론 비용이 입력 길이의 제곱(O(N^2)) 또는 선형(O(N))으로 증가한다는 치명적인 단점이 있습니다. RAG 시스템 또한 한계가 명확합니다. RAG는 사전에 정의된 조각(Chunk) 단위로 검색을 수행하므로, 문서 전체에 흩어진 정보를 종합하거나(예. 이 책의 전반적인 논조가 어떻게 변하는가?), 복잡한 다단계 추론이 필요한 질문(예. A 사건이 B 사건에 미친 간접적 영향은?)에는 취약합니다. 그 외에도 문맥을 요약(Context Compaction/Summarization)과 같…
