1. 핵심 주장 (What)
RLM(Recursive Language Models)은 대형 코드베이스에서의 컨텍스트 문제를 해결하는 새로운 패러다임이다.
- MIT와 공동 연구자들이 발표한 논문 기반 개념
- 핵심 테제: 컨텍스트 관리를 프로그래밍 가능한 실행 환경으로 외부화(externalize)해야 한다
- 소형 레포에서는 코딩 에이전트가 잘 작동하지만, 모노레포나 대형 코드베이스에서는 컨텍스트가 커질수록 성능이 급격히 저하됨
- RLM은 이 문제를 해결하기 위한 컨텍스트 관리 기법이자 메모리 레이어 역할을 함
2. 근거와 맥락 (Why/How)
기존 접근법의 한계
현재 코딩 에이전트 하네스들이 취하는 4가지 주요 접근법:
- 검색 도구 (grep 계열): 파일 시스템에서 grep 등으로 검색 → 컨텍스트 큐레이션
- 시맨틱/로컬 서치: 코드 의미 기반 검색으로 관련 컨텍스트 수집
- 롱 컨텍스트 압축: 전체 컨텍스트를 요약본으로 압축하여 사용
- 메모리 솔루션: 외부 메모리 시스템으로 코딩 에이전트의 기억 지속
이 모든 방식은 컨텍스트가 무한정 커지는 모노레포 환경에서 성능 저하 문제를 근본적으로 해결하지 못함.
RLM의 작동 원리
레포지토리(데이터) → REPL 실행 환경 → LLM 쿼리(재귀 호출) → 최종 출력
- 전체 레포지토리를 모델이 연산할 수 있는 데이터로 취급
- **REPL(프로그래밍 가능한 실행 환경)**을 별도로 두고, 모델이 코드를 작성해 관련 컨텍스트 조각을 추출·계산
- 추출된 컨텍스트만 메인 컨텍스트 윈도우에 주입
- 추가 정보가 필요하면 **LLM 쿼리(재귀 호출)**로 다른 모델/시스템에 질의
- 응답을 받아 루프를 계속하다가 최종 결과 도달 시 종료
재귀(Recursion)의 핵심: 모델이 전문가(다른 LLM 또는 서브 모델)에게 질의하는 구조 자체가 재귀를 만들어냄.
3. 구체적 사례와 데이터
수석 개발자 비유 (Lead Engineer Analogy)
RLM의 개념을 이해하는 가장 좋은 방법:
- 수석 개발자가 새 모노레포 프로젝트에 투입됐다고 가정
- 그는 코드를 라인 바이 라인으로 읽지 않음
- 대신: 구조 파악 → 의존성 확인 → 메모(REPL 노트북 역할) → 스크립트 작성 → 모르면 동료/전문가에게 질문(LLM 쿼리)
- 이 과정이 RLM이 코드베이스를 탐색하는 방식과 동일함
RLM Code 라이브 데모 (Super Agentic 구현체)
- RLM Code: MIT RLM 페이퍼 기반의 오픈소스 참조 구현체
- 데모 타깃: RLM Code 소스 자체를 테스트 대상으로 사용
- Docker 샌드박스 환경에서 실행
- Gemini 모델 연결해 데모 진행
- 실행 흐름:
- 모델이 REPL 코드 작성 (컨텍스트 추출용 Python 코드)
- 증거(evidence) 구축
- LLM 쿼리 호출 (추가 컨텍스트 수집)
- 최종 답변 도출
- JSONL 형식 트레이스 생성 → 임의 옵저버빌리티 플랫폼에 임포트 가능
실제 사용 사례 확인된 RLM 패턴
- Codex 하네스: REPL에서 Python 코드 작성으로 컨텍스트 큐레이션 (RLM의 한 형태)
- Claude 관리형 에이전트 (Anthropic): Anthropic 엔지니어들이 X(트위터)에서 RLM 개념 사용 인정
- Gemini 관리형 에이전트: 유사한 개념 적용
- 다이나믹 워크플로우: 하나의 에이전트가 작업을 받아 각자 샌드박스를 가진 여러 에이전트로 분기 → 결과 통합 (RLM에서 파생된 아이디어)
구현 옵션
- 공식 구현체: MIT의 RLM, RLM Minimal (Omar 저자, DSPy 프레임워크 저자와 동일인)
- DSPy 내 RLM 구현: DSPy 프레임워크에 RLM 구현 내장
- RLM Code (Super Agentic): 오픈소스, 로컬/클라우드 모델 모두 지원, 임의 옵저버빌리티 프레임워크 연동, 임의 프레임워크(패딩티, Google ADK 등) 연동 가능
4. 시사점과 실행 포인트
코드베이스가 특별한 이유
코드베이스는 단순 텍스트가 아님:
- 디렉토리 구조, 테스트 파일, import, 의존성, 이미지, 설정 파일 등 구조화된 데이터
- 모델이 이해하고 추론해야 하는 복잡한 관계망
- 이 구조성 때문에 RLM 개념 증명에 가장 적합한 시나리오
실무 적용 시나리오
- Root Cause Analysis (RCA): 대형 코드베이스에서 버그 원인 추적
- 신규 레포 온보딩: 모노레포 신규 입사자 온보딩 자동화
- 낯선 레포 탐색: 처음 보는 코드베이스 빠른 이해
나만의 RLM 하네스 설계 시 포함할 요소
- 전체 트래젝토리 캡처: 플래닝 → 코딩 → 관찰 → 서브 콜 → 예산 → 최종 출력
- 예산(budget) 제한: 재귀 과다 방지용 최대 스텝/재귀 깊이 설정
- 옵저버빌리티: 모든 실행 흔적을 JSONL로 기록, 외부 모니터링 연동
RLM vs 기존 에이전트 패턴의 핵심 차이
| 구분 | 기존 RAG/검색 에이전트 | RLM |
|---|---|---|
| 컨텍스트 관리 | 모델 내부에서 처리 | 외부 실행 환경으로 분리 |
| 코드베이스 취급 | 검색 대상 텍스트 | 연산 가능한 구조화 데이터 |
| 전문가 질의 | 단일 모델 | 재귀적 LLM 호출 |
| 메모리 | 단기 컨텍스트 | 실행 환경이 지속적 상태 유지 |
핵심 요약 (20줄)
- RLM(Recursive Language Models)은 MIT 발표 논문 기반 개념으로, 대형 코드베이스 탐색에 특화된 컨텍스트 관리 패러다임이다.
- 핵심 테제: 컨텍스트 관리를 LLM 내부가 아닌 외부의 프로그래밍 가능한 실행 환경(REPL)으로 분리하라.
- 모노레포나 대형 코드베이스에서 기존 코딩 에이전트는 컨텍스트 증가에 따른 성능 저하 문제를 갖는다.
- RLM은 전체 레포지토리를 모델이 연산할 수 있는 데이터로 취급하고, 모델이 REPL에서 코드를 작성해 필요한 컨텍스트만 추출한다.
- 추출된 컨텍스트 조각만 메인 컨텍스트 윈도우에 주입하여 컨텍스트 블로트를 방지한다.
- 추가 정보가 필요하면 LLM 쿼리(재귀 호출)로 다른 모델에 질의하는 재귀 구조가 핵심이다.
- 수석 개발자 비유: 코드를 라인별로 읽지 않고, 구조 파악→메모→스크립트→동료 질문 순으로 탐색하는 방식이 RLM과 동일하다.
- RLM은 코딩 에이전트의 메모리 레이어로도 활용 가능하다.
- Super Agentic이 만든 오픈소스 참조 구현체 'RLM Code'는 로컬/클라우드 모델 모두 지원한다.
- DSPy 프레임워크 내에도 RLM 구현체가 내장되어 있으며, 저자 Omar가 두 프로젝트 모두 참여했다.
- 실제 프로덕션에서는 Anthropic의 Claude 에이전트, Gemini 관리형 에이전트, Codex 하네스 등이 RLM 개념을 사용하고 있음이 확인됐다.
- Codex 하네스는 REPL에서 Python 코드를 작성해 컨텍스트를 큐레이션하는 방식으로 RLM을 구현한다.
- 다이나믹 워크플로우(한 에이전트 → 다수 샌드박스 에이전트 분기)도 RLM에서 파생된 아이디어다.
- 코드베이스는 텍스트가 아닌 구조화된 데이터(디렉토리, 테스트, 의존성, 설정 파일 등)이기에 RLM 적용 효과가 크다.
- 나만의 하네스 설계 시: 예산(budget) 제한, 트래젝토리 캡처, JSONL 트레이스, 옵저버빌리티 연동이 필수 요소다.
- 실무 적용 시나리오: 대형 코드베이스 RCA, 신규 레포 온보딩, 낯선 레포 빠른 탐색.
- RLM은 특정 프레임워크가 아닌 패턴이므로, LangChain, Google ADK, 패딩티 등 어느 프레임워크에도 구현 가능하다.
- Docker 샌드박스 환경에서 REPL을 격리 실행하는 것이 보안과 안정성 측면에서 권장된다.
- 실행 결과는 모든 과정(REPL 코드, LLM 쿼리, 최종 출력)을 JSONL로 추적할 수 있어 디버깅과 최적화에 유리하다.
- RLM은 현재 AI 코딩 에이전트 시장에서 사실상 표준 컨텍스트 관리 패턴으로 자리잡아 가고 있으며, 대형 코드베이스 작업 시 필수 지식이다.
YouTube: https://www.youtube.com/watch?v=8oyalrfwgjw | Obsidian: Study/YouTube다이제스트/2026-07-13-aiDotEngineer-RLM-Recursive-Language-Models.md
