Airbyte Agents – 여러 데이터 소스를 아우르는 Agent용 Context Layer
Show HN: Airbyte Agents – context for agents across multiple data sources
TL;DR Highlight
Airbyte가 Slack, Salesforce, Linear 등 여러 SaaS 시스템의 데이터를 미리 인덱싱해서 Agent가 API를 일일이 뒤지지 않아도 되는 Context Store를 출시했다. 기존 MCP 방식보다 토큰을 최대 90%까지 줄이는 효과를 확인했다.
Who Should Read
Slack, Salesforce, Zendesk, Linear 같은 여러 SaaS 도구를 연동해서 Agent를 만들고 있는 백엔드/AI 개발자. 특히 Agent가 여러 시스템 간 데이터를 조합해야 하는데 API 호출이 너무 많아 느리고 비용이 많이 드는 문제를 겪고 있는 팀.
Core Mechanics
- Agent가 실제 업무 워크플로우에 투입되면 Slack, Salesforce, Linear 같은 여러 SaaS 시스템에 동시에 접근해야 하는데, 각 API마다 인증, 페이지네이션, 스키마 파싱, 엔티티 매핑 처리를 따로 해야 해서 구현 난이도가 급격히 높아진다.
- 기존 MCP(Model Context Protocol, AI 모델이 외부 도구를 호출하기 위한 표준)는 대부분 API를 얇게 감싼 래퍼 수준이라, Agent가 여러 시스템에 걸쳐 작업할 때 여전히 수십 번의 API 호출을 반복하게 된다. 실제로 '이번 분기에 이탈할 고객은 누구인가?'라는 질문 하나에 47단계 API 호출이 발생했고, 최종 답변은 틀렸다.
- API는 개발자가 이미 어떤 엔드포인트, Object ID, 필드를 조회해야 하는지 알고 있다고 가정한다. 반면 Agent는 무엇을 조회할지 먼저 발견(discover)하는 단계부터 시작하기 때문에 API 구조와 Agent의 작동 방식이 근본적으로 맞지 않는다.
- Airbyte Agents의 핵심은 'Context Store'라는 데이터 인덱스다. Airbyte가 6년간 개발한 데이터 커넥터로 외부 SaaS 시스템의 데이터를 미리 복제(replicate)해서 인덱싱해두고, Agent가 런타임에 API를 뒤지는 대신 이 인덱스에서 검색하도록 한다.
- 토큰 소비량을 성능 지표로 사용한 벤치마크 결과, 각 벤치마크에서 직접 벤더 MCP 대비 Gong 80%, Zendesk 90%, Linear 75%, Salesforce 16% 적은 토큰을 사용했다. Salesforce만 차이가 작은 이유는 Salesforce가 SOQL이라는 강력한 자체 쿼리 언어를 이미 제공하기 때문이다.
- Zendesk의 차이가 극단적으로 큰 이유는 커뮤니티 MCP가 검색 결과로 전체 API 응답을 그대로 반환하는데, 실제 프로덕션 계정 기준 레코드당 평균 9KB가 쏟아지기 때문이다. Airbyte Agents는 필터링을 통해 필요한 최소 데이터만 반환한다.
- 벤치마크 공정성을 위해 Gong, Zendesk는 공식 MCP가 없어서 가장 인기 있는 커뮤니티 구현체를 사용했고, 테스트 하네스 전체를 GitHub에 공개했다(https://github.com/airbytehq/airbyte-agents-benchmarks). 자체 빌더가 측정했다는 편향을 인정하고 외부 검증을 요청하고 있다.
- Agent는 필요하면 Context Store를 통한 구조화된 검색 외에도 원본 시스템에 직접 읽기/쓰기가 가능하다. 즉, 인덱스 검색과 라이브 API 호출을 조합해서 사용하는 구조다.
Evidence
- 전 Airbyte 직원이 댓글을 달면서 'AI 엔지니어들은 데이터가 엄청나게 필요한데 ETL 파이프라인 트레이드오프를 이해하는 데이터 엔지니어링 배경지식이 없는 경우가 많다'는 점을 지적했다. Airbyte Agents가 MCP 게이트웨이 역할을 할 수 있고, Anthropic이 내부 앱에 실제로 이 방식으로 MCP를 쓴다는 정보도 공유했다.
- 비슷한 방식으로 A/B 테스트 프레임워크를 만든 Unblocked 팀이 댓글로 자신들의 하네스(https://github.com/unblocked/unblocked-harness-compare)를 소개했다. Claude Code, Codex, Cursor, GitHub Copilot 등 Agent CLI를 MCP 서버 유무로 나눠 토큰 절약량, 실행 시간, 툴 호출 횟수, 턴 수를 측정하는 방식이라고 밝혔다.
- Context Store의 인덱싱이 어떤 필드를 선택하는지, 가이드 인덱싱이나 메타데이터 레이어를 테스트해봤는지 묻는 댓글이 있었다. 댓글 작성자는 비슷한 작업을 해본 경험에서 '데이터를 Agent 앞에 가져다 놓는 것만으로는 충분하지 않고, 무엇을 인덱싱하고 어떻게 시그널을 주느냐가 결정적으로 중요하다'고 지적했다.
- PyAirbyte를 이미 쓰고 있던 팀이 자신들의 경험을 공유했는데, 화이트레이블 플랫폼이 deprecated 예정이라는 안내를 받았다고 했다. 이 댓글은 데이터 접근 모델의 명확성이 얼마나 중요한지를 방증한다는 반응이 함께 달렸다.
- 'ETL 파이프라인 만들어놓고 Agent라고 부르는 것 아니냐'는 냉소적인 댓글도 있었다. 또한 '인덱싱된 데이터가 오래된(stale) 데이터가 아닌지 어떻게 알 수 있느냐'는 현실적인 우려도 제기됐는데, SaaS 플랫폼들이 점점 Agent API 호출에 새로운 요금 장벽을 만들면 로컬 복제 자체가 어려워질 것이라는 우려도 함께 나왔다.
How to Apply
- Agent가 '이번 달 클로징 예정인 엔터프라이즈 딜 중 오픈된 지원 티켓이 있는 건은?'처럼 Salesforce + Zendesk를 동시에 조합해야 하는 쿼리를 자주 받는다면, 각 MCP를 따로 연결하는 대신 Airbyte Agents의 Context Store로 두 시스템 데이터를 미리 인덱싱해두면 런타임 API 호출 횟수와 토큰을 대폭 줄일 수 있다.
- Agent가 수십 번의 API 호출을 반복하면서 느리고 비용이 많이 드는 문제를 겪고 있다면, 공개된 벤치마크 하네스(https://github.com/airbytehq/airbyte-agents-benchmarks)를 클론해서 자신의 데이터 소스와 쿼리 패턴으로 직접 Airbyte Agents MCP vs 기존 벤더 MCP 토큰 소비량을 비교 측정해볼 수 있다.
- PyAirbyte를 이미 사용 중이라면 Airbyte Agents의 Context Store 기능을 데이터 소스 연결 레이어로 확장해서 적용할 수 있다. 다만 화이트레이블 플랫폼 deprecated 이슈가 있으므로 마이그레이션 경로를 Airbyte 팀에 미리 확인하는 것이 좋다.
- 여러 SaaS 시스템 간 엔티티 매핑(예: Salesforce 고객 ID와 Zendesk 티켓의 연결)이 Agent 구현의 병목이라면, Airbyte Agents 문서(https://docs.airbyte.com/ai-agents/)를 참고해서 Context Store가 이 매핑을 어떻게 추상화하는지 확인하고 직접 API 연동 코드를 교체하는 것을 검토할 수 있다.
Terminology
관련 논문
성경을 RAG Database로 구축한 프로젝트: Cross Canon
성경 전체를 RAG(검색 증강 생성) 데이터베이스로 인덱싱해 주제나 키워드로 관련 성경 구절을 의미론적으로 검색할 수 있는 웹 서비스다. 종교 텍스트에 RAG를 적용한 실용적 예시로, 유사한 프로젝트를 만들려는 개발자에게 참고가 된다.
Haystack: 프로덕션 수준의 AI Agent와 RAG를 위한 오픈소스 프레임워크
deepset이 만든 오픈소스 AI 오케스트레이션 프레임워크로, LangChain의 대안으로 주목받고 있으며 모듈형 파이프라인 방식으로 RAG·Agent·멀티모달 앱을 프로덕션까지 구축할 수 있다.
Elasticsearch로 만든 Agent 영구 메모리 레이어 - R@10 0.89 달성기
AI 에이전트가 세션이 끝나도 사용자 정보를 기억할 수 있도록 Elasticsearch 위에 구축한 멀티테넌트 장기 메모리 시스템 아키텍처 공개. 168개 질문 기준 R@10 0.89, 테넌트 간 데이터 누출 0건을 달성한 구체적인 구현 방법을 담았다.
TAHOE: 경험 기반 자동 Hint 최적화를 통한 Text-to-SQL 시스템
LLM이 SQL 생성 실패에서 배운 힌트를 재사용 가능한 Hint Bank로 쌓아, 모델 재학습 없이 Snowflake 방언 SQL 정확도를 대폭 끌어올리는 시스템.
FAISS 내부 동작 원리: 10억 개 벡터 유사도 검색
FAISS가 수십억 개 벡터를 빠르게 검색하는 핵심 알고리즘인 IVF(파티셔닝)와 Product Quantization(압축)을 시각적으로 설명한 글로, RAG나 벡터 검색 시스템을 구축하는 개발자에게 내부 동작 원리를 이해시켜 준다.
Polynomial Autoencoder가 Transformer Embedding에서 PCA를 능가하는 방법
PCA 인코더에 2차 다항식 디코더를 붙여서 닫힌 형태(closed-form)로 embedding 압축 품질을 크게 개선하는 기법으로, SGD 없이 numpy만으로 구현 가능하다.