에이전트 데이터 격차 해결: Airbyte Agents 소개

AI 에이전트가 단순한 채팅 인터페이스에서 실제 비즈니스 워크플로우로 이동하려면 Slack, Salesforce, Linear, Zendesk와 같은 곳에 저장된 운영 데이터에 접근할 수 있어야 합니다. 하지만 이러한 접근을 제공하는 것이 API를 연결하는 것만큼 간단한 경우는 거의 없습니다.

현재 대부분의 구현은 Model Context Protocol (MCP) 서버에 의존하는데, 이는 기존 API 위에 얇은 래퍼 역할을 합니다. 유용하지만, 이 접근 방식은 에이전트가 해당 API의 제한 사항—복잡한 인증, 페이지네이션, 고정된 스키마, 특정 Object ID 요구 등—을 그대로 물려받게 합니다. 그 결과 AI가 데이터를 실제로 추론하기보다 API 파이프라인을 탐색하는 데 더 많은 시간을 소비하는 "에이전트 루프"가 발생합니다.

문제: 47단계 추적

Airbyte의 공동 설립자이자 CEO인 Michel Tricot은 실제 사례를 통해 현재 에이전트 설계의 중요한 실패 지점을 강조합니다. *"이번 분기에 이탈할 위험이 있는 고객은 누구인가?"*라는 겉보기에 간단한 질문에 답하도록 지정된 에이전트는 47개의 개별 단계로 이루어진 추적을 만들었습니다.

대부분의 단계는 반복적인 API 호출이었습니다—계정을 찾고, 이를 고객에 매핑하고, 지원 티켓을 검색하는 과정이었습니다. 에이전트가 결론에 도달할 때까지 과정은 매우 느렸으며, 최종 답변은 틀렸습니다. 이는 에이전트가 런타임에 무엇이 중요한지 스스로 발견하도록 강요받기 때문에 발생하며, 토큰 소비가 크게 늘고 환각이나 오류가 발생할 확률이 높아집니다.

Airbyte Agents와 Context Store 소개

이를 해결하기 위해 Airbyte는 Airbyte Agents를 출시했습니다. 이는 에이전트가 추론을 시작하기 전에 필요한 컨텍스트를 제공하도록 설계된 통합 데이터 레이어입니다. 이 아키텍처의 핵심은 Context Store입니다.

실시간 API 호출과 달리 Context Store는 에이전트 검색에 최적화된 데이터 인덱스로, Airbyte의 기존 복제 커넥터 라이브러리로 채워집니다. 이는 데이터 발견의 부담을 에이전트 런타임에서 사전 인덱싱된 레이어로 옮깁니다.

이 아키텍처를 통해 에이전트는 다음을 수행할 수 있습니다:

  1. 데이터 효율적 발견: 구조화된 인덱스를 사용해 API 엔드포인트를 추측하지 않고도 관련 엔터티를 찾습니다.
  2. 지연 시간 감소: 컨텍스트를 조합하기 위해 수십 개의 순차 API 호출이 필요하지 않게 됩니다.
  3. 직접 접근 유지: 인덱스가 발견을 담당하더라도, 특정 작업이 필요할 때 에이전트는 여전히 상위 시스템에 직접 읽기·쓰기 할 수 있습니다.

성능 벤치마크: 토큰을 성공의 프록시로 사용

이 접근 방식을 검증하기 위해 Airbyte는 Airbyte Agent MCP와 다양한 벤더별 MCP를 비교하는 벤치마크 도구를 개발했습니다. 토큰 소비를 효율성의 프록시로 사용했을 때(일반적으로 토큰이 적을수록 정답에 더 직접적인 경로를 의미), 결과는 상당히 눈에 띄었습니다:

  • Zendesk: 최대 90% 적은 토큰.
  • Gong: 최대 80% 적은 토큰.
  • Linear: 최대 75% 적은 토큰.
  • Salesforce: 최대 16% 적은 토큰 (Salesforce의 기본 SOQL이 이미 매우 효율적임을 참고).

특히 Zendesk 사례에서 이러한 향상의 주요 원인은 데이터 필터링 능력입니다. 일부 커뮤니티 MCP는 전체 API 응답을 반환(레코드당 평균 9KB)하지만, Airbyte 구현은 에이전트가 작업에 필요한 최소 데이터만을 가져올 수 있게 합니다.

커뮤니티 관점 및 기술적 과제

이번 출시로 에이전트 데이터 접근의 미래에 대한 기술적 대화가 촉발되었습니다. 커뮤니티 논의에서 몇 가지 핵심 주제가 부각되었습니다:

"AI를 위한 ETL" 논쟁

일부 관찰자는 이 접근 방식이 사실상 데이터 엔지니어링을 AI의 전면에 다시 가져온다고 지적했습니다. 한 댓글자는 "ETL 파이프라인을 만들고 이를 에이전트라고 부른다"고 말했습니다. 이는 더 넓은 추세를 보여줍니다: AI 엔지니어들은 종종 ETL 파이프라인의 트레이드오프를 이해할 데이터 엔지니어링 배경이 부족하지만, 그들의 애플리케이션은 점점 더 많은 데이터를 요구하고 있습니다.

데이터 신선도와 동기화

반복적으로 제기되는 우려는 운영 데이터의 변동성입니다. 에이전트가 인덱스(Context Store)에 의존하면 데이터가 오래될 위험이 있습니다. 핵심 과제는 증분 복제와 실시간 정확성 요구 사이의 균형을 맞추는 것으로, 에이전트가 언제 인덱스를 신뢰하고 언제 실시간 API 읽기를 수행해야 하는지를 판단해야 합니다.

권한 부여와 보안

에이전트가 여러 시스템을 가로질러 쿼리할 수 있게 되면서 데이터 권한 부여의 복잡성이 증가합니다. 에이전트가 사용자가 서로 다른 시스템(예: Salesforce와 GitHub)에서 볼 수 있는 데이터만 접근하도록 보장하는 것은 통합 컨텍스트 레이어에게도 여전히 어려운 과제입니다.

최종 생각

Airbyte Agents는 "실시간 API 탐색"에서 "인덱싱된 컨텍스트 검색"으로의 전환을 의미합니다. 6년간 축적된 커넥터 전문성을 활용해 Airbyte는 다중 소스 데이터 검색의 혼란스러운 과정을 구조화되고 효율적인 작업으로 바꾸려 합니다. 에이전트를 구축하는 개발자에게 목표는 명확합니다: 질문과 데이터 사이의 거리를 줄여 "파이프라인"을 최소화하고 LLM이 추론에 집중하도록 하는 것입니다.

Sources