How to Use RLMs in Deep Agents

🖼️ 인포그래픽

How to Use RLMs in Deep Agents 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Deep Agents는 RLM에서 영감을 받은 동적 서브에이전트와 코드 인터프리터를 통해 긴 컨텍스트 작업을 턴별 추론이 아니라 프로그래밍 가능한 재귀적 워크플로로 처리하려 한다.

📌 핵심 요약

글은 에이전트가 컨텍스트를 많이 축적할수록 성능이 떨어지는 ‘context rot’ 문제에서 출발하며, 이를 완화하기 위한 접근으로 재귀 언어 모델(RLM)을 소개한다.
RLM은 전체 입력을 한 번에 모델 컨텍스트에 밀어 넣거나 손실 있는 요약에 의존하지 않고, REPL 안에서 입력을 변수처럼 다루며 조각별로 분해하고 재귀적으로 모델 호출을 수행한다.
Deep Agents는 이 아이디어를 동적 서브에이전트와 가벼운 코드 인터프리터로 구현해, 모델이 짧은 스크립트를 작성하고 그 코드가 여러 서브에이전트를 병렬·순차·분기 방식으로 호출하게 한다.
OOLONG 기반 AgNews 실험에서는 긴 입력 전체를 훑어 분류·집계해야 하는 과제에서 REPL을 사용하는 RLM식 에이전트가 특히 128k 토큰 조건에서 일반 에이전트보다 높은 점수를 보였다.
글의 결론은 효과적인 에이전트 설계의 핵심이 ‘적절한 시점에 적절한 컨텍스트를 제공하는 것’이며, RLM식 워크플로는 에이전트가 스스로 컨텍스트를 조직하고 루프를 구성하게 해 준다는 것이다.

🧩 주요 포인트

글은 에이전트가 컨텍스트를 많이 축적할수록 성능이 떨어지는 ‘context rot’ 문제에서 출발하며, 이를 완화하기 위한 접근으로 재귀 언어 모델(RLM)을 소개한다.
RLM은 전체 입력을 한 번에 모델 컨텍스트에 밀어 넣거나 손실 있는 요약에 의존하지 않고, REPL 안에서 입력을 변수처럼 다루며 조각별로 분해하고 재귀적으로 모델 호출을 수행한다.
Deep Agents는 이 아이디어를 동적 서브에이전트와 가벼운 코드 인터프리터로 구현해, 모델이 짧은 스크립트를 작성하고 그 코드가 여러 서브에이전트를 병렬·순차·분기 방식으로 호출하게 한다.
OOLONG 기반 AgNews 실험에서는 긴 입력 전체를 훑어 분류·집계해야 하는 과제에서 REPL을 사용하는 RLM식 에이전트가 특히 128k 토큰 조건에서 일반 에이전트보다 높은 점수를 보였다.
글의 결론은 효과적인 에이전트 설계의 핵심이 ‘적절한 시점에 적절한 컨텍스트를 제공하는 것’이며, RLM식 워크플로는 에이전트가 스스로 컨텍스트를 조직하고 루프를 구성하게 해 준다는 것이다.

🧠 상세 정리

1. 문제의 출발점: context rot

글은 에이전트가 더 많은 컨텍스트를 쌓을수록 오히려 성능이 나빠지는 현상을 ‘context rot’이라고 부르며 출발한다. 예시로 10,000개의 영업 통화 transcript에서 평균 거래 규모를 찾는 에이전트가 제시된다. 턴별로 처리하는 모델은 누적 합계를 자신의 컨텍스트 안에서 계속 유지해야 하므로, 세는 과정이 길어질수록 값이 흔들리거나 흐려질 위험이 커진다. 반면 RLM식 에이전트는 오케스트레이션과 카운팅을 모델의 임시 컨텍스트가 아니라 코드 안에 두어, 긴 작업을 더 구조적으로 다루도록 한다.

2. RLM의 기본 아이디어

RLM은 최종 답을 내기 전에 자신 또는 다른 언어 모델을 재귀적으로 호출하는 언어 모델 접근이다. 핵심은 전체 프롬프트를 모델의 컨텍스트 창에 한꺼번에 넣는 대신, REPL 안의 변수처럼 로드하고 코드로 들여다보고 나누고 필요한 조각에 대해 다시 모델을 호출하는 것이다. 논문이 제시한 첫 가설은 context rot을 피하려면 일을 하나의 거대한 모델 호출에 몰아넣지 말고 여러 호출로 나누어야 한다는 것이다. 즉 두 개의 모델 호출로 컨텍스트를 분리해 처리하고, 세 번째 호출에서 합치는 식의 직관을 재귀적 구조로 확장한다.

3. 일반 서브에이전트의 한계

Deep Agents의 일반 서브에이전트도 이미 컨텍스트를 격리하고, 개별 작업 단위를 위임하며, 중간 결과를 메인 컨텍스트 창 밖에 둘 수 있다. 하지만 일반 서브에이전트는 여전히 다음에 무엇을 할지 모델이 한 추론 턴씩 결정하는 방식에 많이 의존한다. 이런 방식은 수백 번의 호출, 분기, 다단계 처리처럼 실제 구조가 필요한 오케스트레이션에서 약해진다. 글은 RLM이 이런 지점에서 grep, partition, map, reduce처럼 큰 데이터셋을 다룰 때 쓰는 프로그래밍적 원시 도구를 모델에게 제공한다고 설명한다.

4. 코드 기반 오케스트레이션의 장점

RLM식 프로그래밍 오케스트레이션은 일반 도구 호출 기반 진행이 안정적으로 제공하기 어려운 두 가지 장점을 준다. 첫째는 결정적 커버리지로, 예를 들어 배치 목록을 도는 for 루프는 모든 배치를 구조적으로 방문하지만 일반 모델은 대규모 반복을 판단에 맡기면 빠뜨릴 수 있다. 둘째는 맞춤형 오케스트레이션으로, 파이프라인이 코드이기 때문에 작업에 맞게 분기형, 병렬형, 순차형 등 원하는 형태를 취할 수 있다. 따라서 긴 입력 전체를 빠짐없이 훑거나 여러 단계의 집계가 필요한 문제에서 모델의 순간 판단보다 코드 구조가 더 강한 기반이 된다.

5. Deep Agents에서의 구현 방식

Deep Agents는 동적 서브에이전트와 가벼운 코드 인터프리터를 통해 프로그래밍 가능한 오케스트레이션을 지원한다. 모델이 매 턴 도구 호출로 서브에이전트를 하나씩 보내는 대신, 짧은 스크립트를 작성하면 코드 인터프리터가 이를 실행한다. 글의 대표 예시는 300페이지 문서에서 각 페이지마다 요약 서브에이전트를 하나씩 실행하고 Promise.all로 결과를 모으는 방식이다. 다만 저자는 이 구현이 논문 속 RLM을 그대로 복제한 것은 아니며, 실제로는 도구와 상태를 가진 서브에이전트를 코드에서 호출하는 ‘recursive agents’에 더 가깝다고 구분한다.

6. 동적 서브에이전트 패턴과 모델 선택

글은 RLM이 이런 실행 환경을 얻으면 컨텍스트를 작은 크기로 나누고, 여러 재귀적 호출을 통해 답을 추출하거나 의미적 매핑을 수행하는 패턴을 보인다고 설명한다. 함께 언급된 동적 워크플로 패턴에는 fan out and synthesize, classify and act, adversarial verification, generate and filter, tournament, loop until done이 있다. Deep Agents의 차별점은 오케스트레이터와 각 서브에이전트를 하나의 모델 계열에 묶지 않고, 사용자가 선택한 임의의 모델 또는 모델 조합으로 구성할 수 있다는 점이다. 예를 들어 고성능 모델을 오케스트레이터로 두고 오픈 웨이트 서브에이전트를 붙이거나, 반대로 오픈 웨이트 오케스트레이션에 고성능 서브에이전트를 붙이는 구성이 가능하다고 설명한다.

7. OOLONG 기반 실험 설계

저자들은 프로그래밍 오케스트레이션이 실제로 작동하는지 보기 위해 OOLONG 벤치마크에서 실험했다. OOLONG은 긴 컨텍스트 추론과 데이터 집계를 평가하는 벤치마크이며, 답을 얻으려면 입력의 거의 모든 행을 검사해야 하는 유형의 문제를 다룬다. 실험은 AgNews를 OOLONG 과제로 구성해 수천 개의 헤드라인, 날짜, 사용자 정보를 제공하고, 보이는 주제 라벨 없이 세계, 스포츠, 비즈니스, 과학·기술 중 하나로 분류한 뒤 전체 집계를 수행하게 했다. 질문 유형은 전체 행을 훑어 카테고리별로 세는 counting, 특정 사용자로 필터링한 뒤 세는 user, 특정 날짜 조건으로 필터링한 뒤 비교하는 temporal로 나뉘었다.

8. 실험 결과와 결론

실험은 포괄적 벤치마크가 아니라 proof of concept으로 제시되었다. 64k 토큰 조건에서는 REPL 없는 일반 에이전트가 0.58, REPL을 쓰는 RLM식 에이전트가 0.67을 기록해 두 방식이 아직 비슷한 범위에 있었고, 일반 에이전트의 지연 시간은 더 낮았다. 128k 토큰 조건에서는 일반 에이전트가 0.44로 떨어진 반면 RLM식 에이전트는 0.79에 도달했으며, 일반 에이전트는 미묘하게 틀리기보다 계산할 수 없다고 포기하는 양상을 보였다고 설명한다. RLM식 에이전트는 더 느리고 출력 토큰 비용 때문에 비용이 높았지만, 저자들은 작업별 최적화를 하지 않은 smoke test였으므로 이 수치가 RLM 잠재력을 오히려 낮게 보여줄 수 있다고 말한다.

9. 사용 방법과 최종 메시지

Deep Agents에서 동적 서브에이전트를 쓰려면 작업을 받을 서브에이전트와 모델이 오케스트레이션 코드를 쓰고 실행할 수 있는 보안성 있는 가벼운 코드 인터프리터가 필요하다. 글은 QuickJS 미들웨어를 설치하고 CodeInterpreterMiddleware를 create_deep_agent에 전달하는 예시를 제공한다. 또한 Deep Agents에는 범용 서브에이전트가 기본 포함되어 있지만, 특정 작업에 맞춘 이름, 설명, 시스템 프롬프트를 가진 커스텀 서브에이전트도 구성할 수 있다고 설명한다. 결론에서는 에이전트 설계의 핵심을 주어진 작업에 맞는 컨텍스트를 적절한 시점에 제공하는 것으로 정리하며, RLM은 루프와 컨텍스트 구조를 모델이 스스로 작성하게 하는 방식이라고 강조한다.

🧾 핵심 주장 / 시사점

이 글의 핵심은 긴 컨텍스트 문제를 단순히 더 큰 창이나 요약으로 해결하려 하지 않고, 코드가 보장하는 반복·분할·집계 구조로 바꾸려는 데 있다.
RLM식 접근은 모델의 추론 능력보다 오케스트레이션의 신뢰성이 병목이 되는 작업, 특히 전체 입력을 빠짐없이 훑어야 하는 집계형 문제에서 더 뚜렷한 장점을 보인다.
Deep Agents의 구현은 논문 속 RLM과 완전히 동일하지 않지만, 코드 인터프리터와 동적 서브에이전트를 결합해 모델이 자신의 작업 흐름을 프로그래밍하도록 만든다는 점에서 같은 문제의식 위에 있다.

✅ 액션 아이템

컨텍스트 누적으로 성능이 떨어지는 작업에서 context rot 완화를 위해 RLM식 REPL 분해·재귀 호출 방식을 도입하고 성능 회복 구간을 확인한다.
모델이 작성한 짧은 스크립트가 동적 서브에이전트를 병렬·순차·분기 호출하도록 구조를 설계해 긴 작업의 실행 흐름을 스스로 조직하게 한다.
OOLONG 기반 AgNews 실험의 128k 토큰 구간 우수 결과를 근거로, 유사한 긴 입력 분류·집계 과제에서 RLM 전환 임계점을 정한다.