MemEx: LLM 에이전트를 위한 프로그래밍 가능한 스크래치패드

1945년, 배너바 부시는 과학자의 기억을 확장할 수 있는 책상 크기의 기계를 상상했습니다. 이 기계는 모든 문서, 주석, 사고의 흐름을 저장하여 필요할 때 불러올 수 있게 해줄 것이었습니다. 그는 이를 MemEx라고 불렀습니다. 부시는 사람들이 손쉽게 다룰 수 없는 정보에 압도당하는 인간적인 문제를 해결하고자 했습니다. 80년이 지난 지금, LLM 에이전트들도 놀랍도록 비슷한 한계에 부딪히고 있습니다.

현재의 에이전트 도구 호출(Agentic Tool Calling) 패러다임에서 컨텍스트 창은 모델이 작동할 수 있는 유일한 영구적인 기반입니다. 이곳은 시스템 프롬프트, 사용자 쿼리, 모델의 추론, 도구 호출, 그리고 원시 도구 출력을 담는 공유 공간입니다. 도구 출력은 가장 큰 문제점입니다. 단일 SQL 쿼리가 수백만 개의 행을 반환할 수 있으며, 오늘날의 하네스에서는 단 하나의 셀만 중요하더라도 이 모든 행이 이후의 모든 턴에 함께 전달됩니다. 에이전트는 결과가 창을 넘치기 전에 결과를 분할하거나, 요약하거나, 저장할 방법이 없습니다.

Databricks에서는 이러한 한계에 끊임없이 부딪혔습니다. Genie부터 Agent Bricks에 이르는 당사의 프로덕션 에이전트들은 특정 시점에서 동일한 컨텍스트 제한에 직면합니다. Genie는 명확한 예시를 제공합니다. 단일 쿼리가 고객의 전체 작업 공간을 검색하며, 테이블, 벡터 인덱스, 대시보드에서 데이터를 가져오기 위해 여러 도구를 호출합니다. 이를 해결하기 위해 우리는 자체 MemEx를 구축했으며, 여러 프로덕션 및 내부 에이전트 내에서 이를 검증했습니다.

어려운 엔터프라이즈 구조화된 검색 작업에서 그림 1은 MemEx가 모든 모델에 대해 비용 대비 정확도 한계를 확장함을 보여줍니다. Opus 4.6 및 Sonnet 4.6과 같은 최첨단 모델은 25~30% 적은 토큰 비용으로 2~5%포인트의 성능 향상을 얻습니다. Qwen3.5-122B (18% → 36%) 및 Qwen3.5-397B (20% → 38%)와 같은 오픈 가중치 모델은 40~50% 적은 토큰 비용으로 정확도를 거의 두 배로 높입니다. MemEx는 임의로 긴 입력에 대해 작동할 수 있으므로, 일반적으로 단일 컨텍스트 창에 맞지 않는 MemEx 자체를 포함한 에이전트 궤적 감사와 여러 궤적에 걸친 병렬 사고라는 두 가지 추가 애플리케이션을 가능하게 합니다.

MemEx 작동 방식

">

MemEx는 LLM에 프로그래밍 가능한 스크래치패드를 제공합니다. 이는 도구 출력을 보관하고, 코드로 변환하며, 컨텍스트 내에서 print 문만 토큰으로 구체화하는 타입이 지정된 Python 커널입니다. 이 환경 내에서 롤아웃은 자체 확장 Python 프로그램이 됩니다. 각 턴 동안 에이전트는 새로운 블록을 작성하고, 커널은 상태를 유지하며, 다음 블록은 이전 블록을 기반으로 구축됩니다. 도구는 타입이 지정된 매개변수와 타입이 지정된 반환 값을 가진 타입이 지정된 Python 함수로 노출됩니다. 도구 출력은 MemEx의 스코프에 Python 객체로 저장되며, 턴을 넘어서도 지속됩니다. 에이전트는 코드로 이들을 구성하고, 패턴이 반복될 때 헬퍼 함수를 정의하며, 동일한 스코프에서 비동기 함수 호출로 서브 에이전트를 생성합니다.

MemEx는 CodeAct (Wang et al., 2024)가 소개한 코드-액션(code-as-action) 계열에 속하며, Anthropic의 Programmatic Tool Calling 및 Cloudflare Code Mode에 프로덕션 변형이 있습니다. MemEx는 영구적인 스코프, 서브 에이전트 프리미티브, 그리고 타입이 지정된 반환값이 연결된 기존 ReAct (Yao et al., 2022) 스타일의 에이전트 프레임워크에 통합되어 차별점을 둡니다. 이들은 함께 JSON/XML 도구 호출 패러다임에 없는 기능을 제공합니다.

• 임의로 큰 입력 처리: 문서, 데이터셋 및 기타 큰 객체는 Python 스코프에 변수로 유지될 수 있습니다.
• 타입이 지정된 객체 반환: 도구 출력은 모델이 매 턴마다 구체화하거나 다시 파싱해야 하는 문자열이 아니라 메모리에 유지되는 타입이 지정된 Python 객체입니다.
• 도구 호출 구성: 한 호출의 출력이 단일 코드 라인 내에서 다음 호출의 인수로 직접 전달됩니다. 중간 출력은 에이전트의 컨텍스트에 구체화될 필요가 없습니다.
• 도구 출력 분할: 출력은 모델이 보기 전에 코드에서 전처리, 필터링 또는 요약될 수 있습니다.
• 비동기 서브 에이전트 생성: 에이전트는 부모와 함께 실행되는 서브 에이전트를 프로그래밍 방식으로 생성하고, 메인 모델을 통해 왕복하지 않고도 결과를 집계할 수 있습니다.

MemEx를 사용한 LLM 에이전트 예시

세 가지 고객 세그먼트에 대한 가입-활성화 퍼널을 비교하고 가장 큰 이탈 지점을 식별하는 것과 같은 구체적인 엔터프라이즈 작업을 예로 들어 보겠습니다(그림 1). 워크플로우는 네 단계로 구성됩니다.

1. 데이터 웨어하우스에서 가입 및 활성화 이벤트 검색
2. 사용자별로 조인
3. 각 단계에서 세그먼트별 전환율 계산
4. 세그먼트 전반의 이탈률 순위 지정.

도구 호출(Tool Calling) 에이전트는 python_exec을 갖추고 한 번에 한 단계씩 작동합니다. 각 SQL 쿼리와 각 프로그래밍 방식 계산은 별도의 도구 호출이며, 중간 DataFrame은 텍스트로 직렬화되어 후속 턴에 다시 붙여넣어집니다. 이 추적은 토큰 소모가 많아 손실이 발생하기 쉽고, 느리며, 비용이 많이 들고, 다운스트림 작업에서 작은 연쇄 오류가 발생하기 쉽습니다.

MemEx 에이전트는 동일한 워크플로우를 단일 코드 블록으로 작성합니다. 쿼리는 스코프 내에서 네이티브 DataFrame을 반환하고, 헬퍼 함수가 이를 구성하며, 최종 답변은 submit()를 통해 타입이 지정된 유효성 검사 객체로 반환됩니다. 동일한 사고, 다른 행동 공간.

하위 문제로 분해되는 작업의 경우, 에이전트는 블록 내부에서 서브 에이전트를 생성할 수 있습니다. 서브 에이전트를 생성할 때, 부모 에이전트는 모든 객체에 대한 공유 접근 권한을 전달할 수 있습니다. 서브 에이전트는 부모와 병렬로 적극적으로 실행되며 완료 시 메인 에이전트에게 결과를 반환할 수 있습니다. 예를 들어:

재귀적 분해는 동일한 Python 프로그램 내에서 또 다른 표현이 됩니다.

MemEx는 Databricks의 에이전트 롤아웃 프레임워크인 aroll을 기반으로 개발되었습니다. aroll은 이미 Genie, Agent Bricks의 Supervisor Agent와 같은 프로덕션 시스템과 KARL과 같은 연구 노력을 지원하고 있습니다. MemEx는 aroll이 도구 호출(Tool Calling)에 이미 사용하는 동일한 에이전트 루프 및 도구에 연결됩니다.

MemEx는 엔터프라이즈 에이전트 작업에서 어떻게 작동할까요?

우리는 9개의 최첨단 모델에 걸쳐 병렬 구조화된 도구 호출(Tool Calling)과 Python 코드 블록(MemEx)을 비교하는 직접적인 평가를 수행했습니다. 프롬프트 튜닝이나 작업별 적응은 없었습니다. 우리는 두 가지 형태의 엔터프라이즈 에이전트 작업을 비교했습니다. 대규모 텍스트 코퍼스에 대한 기반 독해(OfficeQA)와 다양한 관계형 데이터의 대규모 작업 공간에 대한 구조화된 검색(Enterprise Structured Retrieval)입니다.

두 가지 작업 모두에서, MemEx 에이전트가 Tool Calling 에이전트보다 더 우수하고 비용 효율적입니다!

">

OfficeQA Pro는 에이전트에게 1939년부터 현재까지 약 89,000페이지에 달하는 미국 재무부 게시판 코퍼스에 대한 근거 있는 추론 질문에 답하도록 요청합니다. 일반적인 질문은 여러 문서에서 증거를 찾고, 중첩된 계층 및 병합된 셀이 있는 테이블을 탐색하고, 검색된 데이터에 대해 계산을 실행해야 합니다. 답변은 엄격한 일치 여부로 채점됩니다. 비용-정확도 파레토 프론티어의 5개 지점 중 4개는 MemEx 구성입니다. Gemini 3.1 Pro MemEx는 롤아웃당 0.62달러(정확도 52.9%)로 가장 저렴한 프론티어 지점이며, Sonnet 4.6 MemEx는 GPT-5.5 Tool Calling 정확도에 비용의 약 70%로 근접합니다. 9개 모델 전반에 걸쳐 MemEx는 모든 모델에서 동률을 이루거나 우위를 점합니다. Qwen 3.6 27B와 Gemini 3.1 Pro가 약 10%포인트 상승하며 중간 그룹에서 가장 큰 변화를 보였습니다.

">

엔터프라이즈 구조화된 검색은 에이전트에게 엔터프라이즈 관계형 데이터에 대한 자연어 질문에 답하도록 요청합니다. 에이전트는 스키마 검색 및 SQL 쿼리 실행과 관련된 도구를 제공받으며, 사용자가 요청한 데이터 분석 작업을 수행하기 위해 이러한 도구를 사용해야 합니다. 이때 다양한 작업 공간에서 관련 정보를 어디서 찾아야 하는지에 대한 정보는 거의 없는 경우가 많습니다. 에이전트의 답변은 결정론적 데이터 유효성 검사 및 LLM-as-a-judge를 사용하여 실제 응답과 비교하여 채점됩니다. 그림 1과 6에서 볼 수 있듯이, GPT 5.5를 제외한 모든 모델은 MemEx에서 강력한 성능 향상을 보였으며, GPT 5.5는 동등한 성능을 보였습니다. 비용 측면에서도 마찬가지로 강력한 결과를 보였습니다. Qwen 122B는 롤아웃당 도구 호출 수가 56회에서 28회로 줄어들면서 점수가 두 배로 증가했습니다. Sonnet은 28회에서 17회로, Opus는 33회에서 21회로 감소했습니다.¹ 이는 대부분의 모델에서 비용이 거의 절반으로 줄어드는 결과를 가져옵니다. 이 패턴은 OfficeQA Pro와 유사합니다. 작업이 어려울수록 네이티브 객체와 영구 상태가 그 가치를 발휘합니다.

각 비교는 프롬프트 튜닝, 작업별 적응, 모델별 조정 없이 실행되었습니다. 에이전트 루프, 시스템 프롬프트 및 도구는 두 하네스에서 동일합니다. 유일한 차이점은 JSON/XML 구조화된 도구 호출과 MemEx의 Python 코드 블록이라는 액션 공간입니다.

에이전트 트레이스에서 작동하는 MemEx

에이전트 궤적 자체는 부피가 큰 객체입니다. Tool Calling 패러다임에서 궤적을 분석하려면 일반적으로 손실이 많고 컨텍스트가 무거운 텍스트로 평탄화해야 하며, 여러 궤적을 한 번에 분석하는 것은 종종 불가능합니다. 궤적은 여러 컨텍스트 창에 걸쳐 있을 수도 있으며, 그 사이에 압축이 있을 수도 있습니다. LLM이 정의상 컨텍스트에 맞지 않는 트레이스를 어떻게 분석할 수 있을까요? 그러나 궤적은 또 다른 Python 객체이므로 MemEx는 이를 직접 범위로 로드하고 추론할 수 있습니다. 우리는 두 가지 응용 프로그램을 보여줍니다. 첫째, OfficeQA-Pro에서 Qwen 3.6-27B 궤적을 분석하여 MemEx가 Tool Calling보다 뛰어난 이유를 설명하는 MemEx 기반 감사 에이전트입니다. 둘째, OfficeQA-Pro에서 MemEx 에이전트가 동등한 Tool Calling 에이전트를 능가하는 테스트 시간 스케일링입니다.

MemEx가 MemEx를 감사합니다: 에이전트 트레이스 분석

Qwen 3.6-27B와 같은 오픈 소스 모델에서 MemEx로 전환했을 때 성능 향상이 발생한 이유를 분석하기 위해 MemEx를 통해 설명합니다. 특히, OfficeQA 질문, 해당 정답, 그리고 6개의 솔버 궤적(MemEx 에이전트 3개, Tool Calling 에이전트 3개)을 Python 범위로 직접 가져와 MemEx 기반 Sonnet 4.6 에이전트에게 실패 모드의 4가지 축 분류법에 따라 모든 잘못된 궤적을 분류하도록 요청하는 감사 에이전트를 인스턴스화합니다.

저희 분석은 66개의 OfficeQA Pro 질문에 초점을 맞추었으며, 이 질문들에서 6번의 시도 모두가 옳거나 그르지 않아 173개의 궤적이 생성되었습니다. 네 가지 축은 두 가지 큰 그룹으로 나뉩니다.

- 접지 오류(~83%): 모델이 수정된 수치 대신 예비 값을 검색하거나, 모호한 용어(예: 표본 분산 대 모집단 분산, 또는 "백분의 일"에 대한 반올림 정밀도)를 잘못 해석하거나, 유효한 테이블에서 잘못된 열을 추출하는 경우입니다.

- 검색 전략 및 실행 오류: 검색 시퀀스 계획 오류 또는 검색된 데이터를 최종 계산에 올바르게 통합하지 못한 경우입니다.

검색 전략 및 실행 오류의 경우, MemEx는 MemEx 에이전트가 Tool Calling에 비해 오류를 2배 감소시켰음을 발견했습니다. 이는 MemEx의 경우 검색이 Python 변수에 직접 저장될 수 있으므로, 모델이 한 도구의 출력에서 다음 도구 호출로 값을 복사하는 것을 피할 수 있고, 여러 도구 호출을 한 번에 일괄 처리할 수 있기 때문입니다. Tool Calling은 이러한 단축키가 없으며 항상 호출 간에 값을 전사해야 하는데, 이때 실수가 발생하기도 합니다. 예를 들어, 한 궤적에서 검색된 문서의 3,501이라는 값이 다음 호출에서 3531로 잘못 입력되었습니다.

MemEx를 사용한 에이전트 병렬 사고

테스트 시간 계산을 확장하는 일반적인 접근 방식은 병렬 사고이며, 여기서 작업의 여러 독립적인 롤아웃이 최종 답변으로 집계됩니다. KARL에서 사용된 접근 방식과 같은 에이전트 병렬 사고에서는 독립적인 시도의 요약이 집계 에이전트로 전달됩니다. 이 요약 단계는 손실이 있지만 표준 설정에서는 피할 수 없습니다. 여러 전체 궤적을 모델의 컨텍스트 창에 맞추는 것이 비실용적이기 때문입니다. MemEx를 사용하면 이러한 궤적을 범위 변수로 로드하여 손실이 있는 표현을 완전히 우회할 수 있습니다.

">

그림 7에 표시된 결과에서, 저희는 8개의 독립적으로 생성된 Qwen-3.6-27B 궤적에 대한 애그리게이터로 Claude Sonnet 4.6을 사용합니다. 애그리게이터가 단순히 문제를 자체적으로 다시 해결하지 않도록 하기 위해, 파일 검색 도구를 제거하고 검증 및 선택으로 제한했습니다. 전체 궤적을 입력으로 받는 MemEx 기반 에이전트는 요약만 받는 동등한 Tool Calling 에이전트보다 뛰어난 성능을 보입니다. 한 경우, 궤적 애그리게이터는 입력 궤적에서 원시 도구 출력을 읽어 이전 게시판의 중복 오류를 발견했습니다. Tool Calling 애그리게이터는 입력이 요약으로 제한되어 중복 데이터 주장을 확인할 수 없었고, 손상된 소스에 대한 다수결 투표로 회귀했습니다.

MemEx 아키텍처

Tool Calling 에이전트는 ReAct (Yao et al., 2022)에 의해 도입된 액션-관찰 루프에서 미리 정의된 도구 스키마를 따르는 하나 이상의 구조화된 도구 호출(JSON 또는 XML)을 턴마다 내보냅니다. CodeAct (Wang et al., 2024)는 해당 형식을 영구 Python 커널로 대체했습니다. 에이전트는 임의의 Python 코드를 내보내고, 변수와 함수 정의는 턴을 넘어 유지됩니다. 동일한 패러다임의 프로덕션 변형에는 Anthropic의 Programmatic Tool Calling (PTC)과 Cloudflare Code Mode가 있습니다. PTC는 동일한 컨테이너를 재사용하여 요청 간에 상태를 유지하는 반면, Code Mode는 그렇지 않습니다. MemEx는 이 패러다임을 다음 네 가지 추가 기능으로 확장합니다.

• 매개변수 스키마가 보존된 드롭인 도구 통합.
• 롤아웃 시작 시 라이브 Python 스코프.
• 구조화된 반환을 위한 유형화된 submit().
• 병렬 서브 에이전트를 위한 논블로킹 spawn_agent()으로, 재귀 언어 모델 (Zhang et al., 2025)을 일반화합니다.

구현은 세 가지 설계 선택에 기반합니다.

영구 REPL에서 코드를 액션으로

에이전트의 액션은 턴을 넘어 지속되는 네임스페이스에서 실행되는 임의의 Python 코드 블록입니다. 도구, 스코프 객체, 이전 결과는 모두 해당 네임스페이스에 존재합니다. 에이전트는 관찰(표준 출력, 반환 값, 오류)을 읽은 다음 더 많은 코드를 작성합니다. Tool Calling을 실행하는 것과 동일한 관찰-액션 루프가 MemEx를 실행합니다. 액션 공간만 변경됩니다.

Tool Calling을 위한 드롭인

기존 Tool Calling 도구는 매개변수 스키마 및 반환 유형 메타데이터를 포함하여 Python 함수로 자동 주입됩니다. 기존 에이전트를 Tool Calling에서 MemEx로 전환하는 것은 단일 구성 변경으로 이루어집니다.

백엔드에 구애받지 않는 실행

동일한 에이전트 코드는 구성 시점에 선택되는 세 가지 백엔드에서 실행됩니다.

• 연구 중 빠른 반복을 위한 인-프로세스.
• 평가 중 격리를 위한 서브프로세스.
• 고처리량 배치 생성(학습 데이터, 대규모 롤아웃)을 위한 풀.

프로덕션 배포의 경우, 커널은 Anthropic의 Managed Agents와 같은 호스팅된 샌드박스로 교체될 수 있습니다. 동일한 에이전트 코드가 파일 시스템 격리, 네트워크 송신 제어 및 호스트가 처리하는 리소스 제한과 함께 사용됩니다.

다음 단계는 무엇인가요?

MemEx가 여러분의 에이전트에 적용됩니다. 저희는 Databricks의 퍼스트 파티 에이전트와 Agent Bricks 전반에 걸쳐 이를 출시하고 있습니다. 오늘날 Databricks 에이전트를 기반으로 구축한다면, 곧 MemEx를 사용할 수 있게 될 것입니다.

MemEx 액션 공간을 위해 모델을 사후 학습하고 있습니다. MemEx 자체는 기반이 됩니다. 합성 데이터를 생성하고, 에이전트 검증기를 실행하며, 학습 루프에 공급합니다.

저자: Ashutosh Baheti, Shubham Toshniwal, Arnav Singhvi, Krista Opsahl-Ong, Sean Kulinski, Sam Havens, Jonathan Li, Marco Cusumano-Towner, Jonathan Chang, Wen Sun, Alexander Trott, Jonathan Frankle, Xing Chen, Matei Zaharia

---

¹ MemEx에서 도구 호출은 데이터 분석 또는 다른 도구를 비동기 함수로 호출할 수 있는 Python 코드 블록입니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)