Airbyte 공동 창업자가 여러 데이터 소스 간 에이전트의 컨텍스트를 통합하고 발견 능력을 향상시키는 새로운 레이어인 Airbyte Agents를 출시했습니다. 기존 에이전트는 복잡한 API 파이프라인과 시스템 간 엔티티 매칭 문제에 직면하며, 특히 다단계 추론 과정에서 비효율적이고 부정확할 수 있습니다. Airbyte Agents는 'Context Store'라는 데이터 인덱스를 활용하여 구조화된 방식으로 데이터를 발견하고, 에이전트가 필요한 컨텍스트를 효율적으로 확보하도록 돕습니다.
핵심 포인트
Airbyte Agents는 여러 도구(Slack, Salesforce 등)에 걸쳐 정보를 찾고 행동하는 통합 데이터 레이어 역할을 합니다.
기존 에이전트의 한계점은 복잡한 API 파이프라인 관리와 시스템 간 엔티티 매칭 부족입니다. Airbyte Agents는 이를 해결합니다.
핵심 기술인 'Context Store'는 기존 데이터 커넥터 작업에서 얻은 지식을 활용하여, 에이전트 검색을 최적화한 데이터 인덱스를 제공합니다.
벤치마킹 결과, Airbyte Agents가 자체 MCP보다 훨씬 적은 토큰(예: Gong 80%, Zendesk 90%)으로 복잡한 질문에 답할 수 있어 효율성과 정확성이 크게 향상됨을 입증했습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 HN AI Posts의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
Michel 입니다 (Airbyte 공동 창업자 및 CEO). 우리는 지난 6 년간 데이터 커넥터 (data connectors) 를 구축해 왔습니다. 오늘 우리는 에이전트가 운영 시스템 전반에 걸쳐 정보를 발견하고 행동을 취할 수 있도록 하는 통합 데이터 레이어인 Airbyte Agents (https://docs.airbyte.com/ai-agents/) 를 출시합니다.
여기서는 빠른 설명을 드립니다:
에이전트가 실제 워크플로우로 이동함에 따라, 그들은 더 많은 도구에 접근할 필요가 있습니다 (예: Slack, Salesforce, Linear). 이는 엄청난 API 파이프라인 (API plumbing) 을 의미합니다: 인증, 페이징, 필터링, 스키마 처리, 그리고 시스템 간 엔티티 매칭 등.
대부분의 MCP 는 이를 해결하지 않습니다. 그들은 API 의 얇은 래퍼일 뿐이며, 에이전트는 여전히 약한 원시 (primitives) 를 상속받으며 대부분의 경우 잘못 작동합니다, 특히 여러 도구를 사용할 때.
더 깊은 문제는 API 가 이미 무엇을 조회할지 알고 있다고 가정한다는 점입니다 (엔드포인트, Object ID, 필드 등을 생각해보세요). 반면 에이전트는 보통 한 단계 앞선 곳에서 시작합니다: 추론을 시작하기 전에 먼저 무엇이 중요한지 발견해야 합니다.
따라서 우리는 Airbyte Agents 를 데이터와 당신의 에이전트 사이의 컨텍스트 레이어로 구축했습니다. 핵심은 우리가 Context Store 라고 부르는 것입니다: Our replication connectors 로 채워진 에이전트 검색을 최적화한 데이터 인덱스입니다. 지난 6 년간 데이터 커넥터 작업이 여기서 유용하게 쓰입니다!
이는 에이전트가 데이터를 구조화된 방식으로 발견할 수 있게 해주며, 필요시 상류 시스템으로 직접 읽기 및 작성을 허용합니다.
우리가 이 작업을 시작하게 된 계기는 우리 SDK 로 마이그레이션하는 과정에서 겪은 비정상적인 trace (추적) 입니다. 그 질문은 "이번 분기에 이탈 위험이 있는 고객은 누구인가?"였습니다. trace 는 47 단계로 이루어져 있었습니다. 대부분 API 호출이었습니다. 에이전트는 먼저 여러 계정을 찾아야 했고, 이를 올바른 고객으로 매핑해야 했고, 티켓을 찾아야 했으며... 그리고 에이전트가 최종 응답을 할 때, 대답은 괜찮아 보였지만 옳지 않았습니다. 그것뿐만 아니라, 그 속도는 끔찍하게 느렸습니다. 그래서 우리는 무언가를 해야 했습니다.
그 47 단계의 에이전트는 Airbyte Agents 가 특히 잘 작동하는 질문 중 하나입니다. 다른 예시들: - "이번 달에 닫히는 모든 엔터프라이즈 거래를 보여주세요 (Open support tickets 포함)." - "Github 이슈가 열린 지원 티켓을 모두 찾아주세요"
이것들은 단순해 보일 수 있지만, 에이전트가 런타임에 모든 컨텍스트를 조립할 필요가 없을 때 답변의 품질은 크게 달라집니다.
우리가 제품의 초기 버전을 갖게 된 후, 저는 주말 동안 벤치마킹 하르ネス (벤치마크 테스트 도구) 를 구축하여 그것이 작동하는지 확인했습니다. 또한 재미로, 저는 벤치마크 작성을 좋아합니다 :). Airbyte Agent MCP 를 호출 vs 여러 벤더 MCP 를 직접 호출을 비교했습니다. 검색과 검색 (retrieval, search) 을 테스트했습니다.
간단함을 위해, 저는 토큰 소비를 측정 단위로 사용했습니다. 저는 그것이 에이전트가 얼마나 잘 작동하는지 나타내는 좋은 대안이라고 생각합니다. 실패한 에이전트 (예: 47 단계가 걸린 에이전트) 는 어디에도 도달하지 못한 채 많은 토큰을 소비하며, 성공한 에이전트는 바로 핵심에 도달합니다.
측정할 때 발견한 내용은 다음과 같습니다: Gong 은 자체 MCP 보다 최대 80% 적은 토큰을 사용했고, Zendesk 는 최대 90%, Linear 는 최대 75%, Salesforce 는 최대 16% (Salesforce 의 자체 SOQL 이 여기서는 잘 작동함).