A Query Engine for the Agents

기술 요약: 에이전트를 위한 쿼리 엔진

문제 정의
현재 생산 환경에서 가장 빠르게 증가하는 데이터는 에이전트 추적, 채팅 로그, 추론 체인, 모델 출력 등을 포함한 비정형 텍스트입니다. 이러한 데이터를 분석하려면 SQL 만으로는 답변할 수 없는 질문 (예: "에이전트가 어디서 혼란을 겪었는지 보여줘") 이 필요하며, 이는 대규모 언어 모델 (LLM) 을 쿼리 경로에 직접 통합해야 함을 의미합니다. 그러나 기존 데이터 인프라 (Spark, Trino, 관리형 웨어하우스) 는 서버 측 실행을 위해 설계되어 있어, 클라이언트 측에서 실행되는 새로운 유형의 AI 애플리케이션 (예: Claude Code, Cursor, 브라우저 기반 에이전트) 에는 적합하지 않습니다. 이러한 애플리케이션은 인간 사용자와 LLM 에이전트를 동일한 프로세스 (Node, Deno, Web Workers 와 같은 JavaScript 런타임) 에서 호스팅하며, 백엔드 쿼리 게이트웨이의 오버헤드 없이 데이터에 즉시적이고 저지연으로 접근할 수 있어야 합니다. 또한, 기존 엔진은 고비용이고 과금 대상이 되는 LLM 추론 호출과 분석 연산자를 교차시키는 데 따르는 비용과 지연 시간 문제를 처리하는 데 어려움을 겪습니다.

방법론 및 아키텍처
저자들은 에이전트가 작동하는 JavaScript 런타임 내에서 완전히 실행되도록 설계된 브라우저 네이티브 레이크하우스 클라이언트인 Hyperparam을 제시합니다. 이 시스템은 총 70KB 미만 (압축 기준) 의 세 가지 오픈 소스 JavaScript 라이브러리로 구성됩니다:

1. Hyparquet (14 KB): 범위 효율적 읽기를 수행하는 Parquet 리더입니다. 최소/최대 통계를 사용하여 관련 없는 행 그룹을 건너뛰면서 병렬 HTTP 범위 요청을 통해 필요한 열 조각만 가져옵니다. 중첩된 타입 (LLM 추적 스키마에 필수적) 을 지원하며 전체 파일 다운로드를 방지합니다.
2. Icebird (32 KB): 클라이언트 측 Apache Iceberg 클라이언트로, 스냅샷을 해결하고 위치/동일성 삭제를 로컬에서 적용합니다. 각 요청마다 자격 증명 (예: AWS SigV4, GCS HMAC) 을 주입하기 위해 custom-fetch 후크를 활용하여 엔진을 자격 증명과 무관하게 유지하고 백엔드 프록시 없이 객체 저장소에 직접 접근할 수 있게 합니다.
3. Squirreling (22 KB): 처음부터 구축된 비동기 네이티브 SQL 엔진입니다. 이 엔진의 핵심 혁신은 셀 단위, 지연 실행입니다. 행을 배치로 처리하는 벡터화 엔진과 달리 Squirreling 은 모든 셀을 지연된 계산 (Promise) 으로 취급합니다.
   • 지연 물리화: 하류 연산자가 명시적으로 요구할 때까지 열은 가져오지, 압축을 풀지, 또는 평가되지 않습니다.
   • 비동기 네이티브 연산자: 모든 연산자는 JavaScript AsyncGenerator로 구현됩니다. 이를 통해 엔진은 I/O 와 LLM 추론 호출을 중첩하여 파이프라인화할 수 있습니다.
   • LLM 통합: 엔진은 llm() 을 1 급 사용자 정의 함수 (UDF) 로 지원합니다. 지연 실행 모델 덕분에 llm() 호출은 행이 모든 이전 필터를 통과하고 출력 한도에 도달했을 때만 트리거됩니다.

주요 기여

• JS 네이티브 배포: 엔진은 애플리케이션의 기존 JavaScript 런타임에 직접 배포되어 두 번째 런타임, 외부 함수 인터페이스 (FFI), 또는 서버 측 조정자의 필요성을 제거합니다.
• 극단적인 번들 크기: 전체 스택이 70KB 미만으로, 콜드 브라우저 탭 또는 턴별 에이전트 샌드박스에서 즉시 로딩이 가능하며, DuckDB-WASM 의 약 8MB (압축 기준) 코어에 비해 현저히 감소했습니다.
• 비용 인식 실행: 네트워크 페치, LLM 추론과 같은 고비용 작업을 절대적으로 필요할 때까지 지연시킴으로써 비용을 수요에 맞춥니다. 예를 들어, LIMIT 5가 포함된 쿼리는 전역 정렬 또는 집계 요구 사항이 없다면 필터에 일치하는 행 수와 상관없이 LLM 호출을 다섯 번만 트리거합니다.
• 직접 저장소 접근: 시스템은 클라이언트 측 자격 증명을 사용하여 객체 저장소 (S3, GCS, Azure) 에서 Parquet 과 Iceberg 를 직접 읽음으로써 쿼리 게이트웨이의 지연 시간과 복잡성을 제거합니다.

결과
이 논문은 가장 가까운 이전 작업인 DuckDB-WASM 에 대한 경험적 비교를 제공합니다:

• 지연 시간: "콜드 스타트" 시나리오 (40GB 에이전트 추적 Iceberg 테이블 로드) 에서 Hyperparam 은 첫 번째 행을 0.6 초에 반환하는 반면, DuckDB-WASM 은 19 초, 서버 측 클러스터 (Trino/Spark) 는 수 분이 소요됩니다.
• LLM 효율성: 필터로 제한된 쿼리 (예: WHERE llm(...) = 1 LIMIT N) 에서 Squirreling 은 DuckDB-WASM 보다 300 배 빠릅니다. 이는 DuckDB-WASM 이 행을 벡터화된 배치 (모르셀) 로 평가하며 생성된 열에 대한 필터 너머로 LIMIT 를 푸시할 수 없어 수천 개의 불필요한 LLM 호출을 평가하기 때문입니다. Squirreling 은 한계에서 단축 회로를 겁니다.
• 에이전트 비용: 50,000 행 데이터셋에서 Anthropic Haiku 에이전트가 10 개의 분석가 스타일 질문에 답하는 벤치마크에서 두 엔진 모두 100% 정확도를 달성했습니다. 그러나 Squirreling 은 비용을 3 분의 2 낮춘 수준 ($0.203 대비$0.067) 에서 이를 달성했습니다. 비용 감소는 Squirreling 의 "의미하는 바가 무엇입니까" 힌트와 오류 처리가 에이전트가 더 적은 라운드에서 쿼리를 해결하고 대화 기록과 관련된 입력 토큰 비용의 2 차적 성장을 방지하여 입력 토큰이 3.67 배 감소했기 때문입니다.
• 파이프라이닝: 호출 횟수가 유사한 경우 (예: 정렬로 제한된 쿼리) 에도 Squirreling 은 최대 256 개의 동시 비동기 호출을 파이프라인화할 수 있어 벽시계 시간 기준으로 192 배 더 빨랐으며, 반면 DuckDB-WASM 의 동기 WASM 경계는 동시성을 하나로 고정했습니다.

의의 및 주장
이 논문은 데이터 엔지니어링이라는 학문이 "AI 네이티브" 클라이언트 애플리케이션을 지원하도록 진화해야 한다고 주장합니다. 소비자와 데이터 사이에 무거운 인프라를 두는 기존 읽기 경로는 에이전트에 필요한 "선별 - 검토 - 실행" 루프를 무너뜨립니다. Hyperparam 은 분석 연산자와 모델 기반 해석을 교차시킴으로써 경량 클라이언트 측 엔진이 비정형 텍스트 분석을 효과적으로 처리할 수 있음을 보여줍니다. 저자들은 이를 대규모 조인이나 디스크 스킬 (spill-to-disk) 작업 부하에 대한 서버 측 클러스터의 대체품이 아니라, 에이전트 워크플로우에서 발생하는 데이터와 쿼리의 특정 형태에 필요한 솔루션으로 위치시킵니다. 여기서 엔진은 소비자에게 도달하여 엄격한 비용 범위와 빠른 반복을 가능하게 해야 합니다.