AI Sparkup

최신 AI 쉽게 깊게 따라잡기⚡

긴 컨텍스트 LLM의 숨겨진 함정, Context Rot 현상과 RLM 해결책

LLM이 100만 토큰을 처리할 수 있다고 해서, 실제로 그만큼을 잘 처리한다는 뜻은 아닙니다. Gemini 2.5가 포켓몬 게임을 플레이하다가 10만 토큰만 넘어도 성능이 급격히 떨어졌던 것처럼요. 이 현상을 Context Rot(컨텍스트 부패)이라고 부릅니다.

개발자 Drew Breunig은 이 문제와 Recursive Language Model(RLM)이라는 새로운 해결책을 소개하는 글을 발표했습니다. RLM은 단순히 긴 컨텍스트를 처리하는 것을 넘어, 에이전트 설계를 자동으로 발견하는 메커니즘으로 발전할 수 있다는 게 핵심입니다.

Screenshot

출처: The Potential of RLMs – Drew Breunig

Context Rot, 가장 골치 아픈 컨텍스트 문제

Context Rot은 LLM에 주어지는 컨텍스트가 길어질수록 모델의 성능이 저하되는 현상입니다. Gemini 2.5 논문에서 처음 보고되었고, Chroma 팀이 본격적으로 연구하면서 이름이 붙었죠.

진짜 문제는 이게 단순한 용량 부족이 아니라는 점입니다. 모델은 컨텍스트가 한계를 넘어서도 계속 답을 내놓는데, 정확도만 슬금슬금 떨어집니다. 에이전트를 오래 실행할수록 모르는 사이에 성능이 악화되는 거죠.

RLM, 컨텍스트 문제를 코딩 문제로 바꾸다

Alex Zhang과 Omar Khattab이 제안한 Recursive Language Model(RLM)은 이 문제를 영리하게 우회합니다. 방식은 놀라울 정도로 간단합니다.

긴 컨텍스트를 REPL(코드 실행 환경)에 변수로 저장합니다. 그런 다음 LLM이 이 환경에서 코드를 작성해 필요한 부분만 골라서 분석하게 하죠. 여기서 핵심은 컨텍스트를 두 개의 공간으로 분리한다는 점입니다.

하나는 토큰화된 컨텍스트(LLM의 컨텍스트 윈도우를 채우는 부분), 다른 하나는 프로그래밍 컨텍스트(코드 환경에 저장된 정보). LLM은 거대한 데이터 전체를 토큰 공간에 밀어넣는 대신, REPL을 통해 필요한 조각만 꺼내 씁니다. 마치 도서관에서 책장 전체를 들고 오는 대신 필요한 책만 골라오는 것과 비슷하죠.

그리고 이 작업을 최신 LLM들은 놀랍도록 잘 해냅니다. 지난 18개월간 수백억 달러를 쏟아부어 코딩 능력을 강화한 덕분입니다. RLM은 Context Rot이라는 컨텍스트 문제를 코딩 문제로 전환시켜서, LLM의 강력한 코딩 추론 능력을 활용합니다.

결과는 인상적입니다. 저자는 400MB가 넘는 로그파일도 문제없이 처리했고, Alex Zhang의 논문에서는 1천만 토큰 이상에서도 성능 저하가 거의 없었습니다. 일반 GPT-4가 26만 토큰에서 완전히 실패한 것과 대조적이죠.

실제로 어떻게 작동하나

저자는 200만 개의 Stable Diffusion 프롬프트에서 가장 많이 언급된 유명인을 찾는 작업을 RLM에게 맡겼습니다. 이 데이터는 어떤 LLM의 최대 윈도우보다도 큽니다.

RLM은 5번의 반복을 거쳐 문제를 해결했습니다. 먼저 작은 샘플로 데이터 구조를 파악하고, 추출 전략을 개발해 테스트한 뒤, 전체 데이터로 확장해서 결과를 종합했죠. 이 과정에서 print로 정보를 토큰 공간으로 가져오고, llm_query로 서브 작업을 다른 LLM에 위임했습니다.

마치 숙련된 개발자가 문제를 푸는 것처럼, RLM은 코드를 쓰고 실행하고 검증하는 과정을 반복했습니다.

진짜 잠재력은 따로 있다

Context Rot 완화도 인상적이지만, 저자가 가장 흥미롭게 본 점은 다릅니다. RLM이 문제를 해결하는 과정 자체가 에이전트 설계의 청사진이 된다는 것이죠.

같은 작업을 RLM에게 여러 번 시키면 비슷한 패턴이 반복됩니다. 예를 들어 위 사례에서 “유명인”을 “차량”이나 “미적 스타일”로 바꿔도, RLM은 비슷한 방식으로 문제에 접근합니다. 샘플링하고, 전략 세우고, 테스트하고, 확장하고, 종합하는 패턴 말이죠.

이 패턴들을 식별하고 명시적인 에이전트로 최적화하면 어떻게 될까요? 더 빠르고 안정적인 에이전트를 만들 수 있습니다. RLM은 단순히 긴 컨텍스트를 처리하는 도구가 아니라, 최적의 문제 해결 방법을 자동으로 탐색하고 발견하는 메커니즘이 될 수 있습니다.

Chain of Thought가 “단계별로 생각하세요”라는 간단한 프롬프트로 시작해서 추론 모델로 발전한 것처럼, RLM도 지금은 느리고 동기적이지만 앞으로 엄청난 잠재력을 펼칠 수 있습니다.

현재의 한계

물론 지금 당장은 한계가 분명합니다. 위 예시에서 RLM은 수십 번의 LLM 호출과 몇 분의 시간이 걸렸습니다. Groq의 Kimi K2로도 이 정도인데, GPT-4나 Claude Opus로 돌리면 훨씬 더 오래 걸리겠죠. 또한 강력한 모델이 필요합니다. Qwen3-30B-A3B 같은 작은 모델은 중간에 헤매다가 답을 제출하지도 못했으니까요.

작은 컨텍스트 문제에는 오히려 비효율적입니다. 프롬프트로 한 번에 처리할 수 있는 걸 굳이 여러 번 탐색할 필요가 없으니까요. 하지만 거대한 코드베이스나 방대한 데이터셋을 다뤄야 할 때, 그리고 무엇보다 에이전트 설계를 자동으로 발견하고 싶을 때, RLM은 지금 당장 실험해볼 만한 가치가 있습니다.

참고자료:


AI Sparkup 구독하기

최신 게시물 요약과 더 심층적인 정보를 이메일로 받아 보세요! (무료)

Comments

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다