아마존 베드로크 에이전트코어로 컨텍스트 윈도우 장벽을 깨다

Recursive Language Models(RLM)은 LLM의 고정된 컨텍스트 윈도우 한계를 우회하기 위한 접근으로, 거대한 문서를 한 번에 프롬프트에 밀어 넣는 대신 메인 LLM이 샌드박스 환경에서 Python 코드를 작성·실행하며 문서를 청크 단위로 탐색하고, 필요할 때만 하위 LLM(sub-LLM)을 호출해 특정 섹션을 분석하도록 위임하는 구조다. Amazon Bedrock AgentCore Code Interpreter는 이 패턴의 실행 기반으로, 격리된 Python 런타임과 파일시스템을 세션 단위로 유지해 중간 분석 결과·요약·인덱스를 "지속 가능한 작업 메모리(working memory)"로 보존한다. Strands Agents SDK는 이 위에 에이전트의 도구 호출 루프를 얹어, 메인 에이전트가 코드 실행 도구를 통해 문서 길이에 무관하게 재귀적으로 정보를 추출·검증하도록 오케스트레이션한다.

엔지니어 입장에서 이 방식의 실질적 효과는, 200K~1M 토큰의 컨텍스트 윈도우조차 감당하지 못하는 수십~수백 MB 규모 로그, 법률 문서, 코드베이스, 트랜스크립트를 단일 에이전트 워크플로 안에서 처리할 수 있다는 점이다. 기존 RAG 파이프라인이 사전 임베딩·벡터 검색에 의존하며 청킹 전략에 결과 품질이 종속됐다면, RLM은 런타임에 LLM이 직접 grep, 슬라이싱, 정규식, 통계 집계 같은 코드를 작성해 동적으로 문서 구조를 파악하므로 "어떤 청크가 중요한가"를 사람이 미리 정의할 필요가 없다. 또한 sub-LLM 호출이 분리되어 있어 메인 컨텍스트가 오염되지 않고, 비용도 전체 문서를 매번 메인 모델에 주입하는 방식보다 선택적·점진적으로 발생한다.

다만 도입 시 주의할 지점이 있다. 첫째, Code Interpreter는 세션 비용·실행 시간 한도가 있고 sub-LLM 호출 수가 누적되면 레이턴시가 RAG 대비 훨씬 길어질 수 있으므로, 단순 QA처럼 짧은 검색이 충분한 시나리오에는 과한 도구다. 둘째, 에이전트가 작성하는 코드가 결과 정확도를 좌우하기 때문에 프롬프트에서 탐색 전략(예: 먼저 문서 구조 스캔 → 인덱스 작성 → 섹션별 위임)을 명시적으로 가이드하고, 중간 산출물을 파일로 저장·검증하는 패턴을 강제해야 한다. 셋째, 샌드박스라 해도 외부 데이터 반입과 PII 처리 정책은 AgentCore 세션 격리 모델을 기준으로 재점검해야 한다.

국내 개발자라면 우선 Strands Agents SDK와 Bedrock AgentCore Code Interpreter의 세션 수명·파일 영속성·네트워크 정책 문서를 확인하고, 사내 장문 문서 처리 케이스(보안 로그 분석, 컴플라이언스 감사, 대규모 PR 리뷰 등)에서 기존 RAG와 RLM의 토큰 비용·정확도·응답시간을 PoC로 비교해보는 것이 합리적이다. 특히 "전체 문서를 정독해야 답이 나오는" 종합형 질의에서 RLM의 이점이 두드러지므로, 검색형 질의는 RAG, 분석형 질의는 RLM으로 분기하는 하이브리드 아키텍처를 설계 옵션으로 고려할 만하다.