에이전트 토큰 소비량을 최대 90%까지 줄여주는 컨텍스트 레이어 개발

저는 Airbyte의 공동 창업자이자 CEO인 Michel입니다. 저희는 지난 6년 동안 데이터 커넥터를 구축해 왔습니다. 오늘 저희는 에이전트가 운영 시스템 전반에서 정보를 발견하고 조치를 취할 수 있도록 하는 통합 데이터 레이어인 Airbyte Agents를 출시합니다.

수정 - 요약(피드백 주셔서 감사합니다 😃): Airbyte Agents는 에이전트와 비즈니스 데이터(Salesforce, Zendesk, Slack 등) 사이에 위치하는 컨텍스트 레이어입니다. 에이전트가 어떤 데이터가 존재하는지 파악하기 위해 수십 번의 API 호출을 하며 토큰을 낭비하는 대신, 저희의 컨텍스트 스토어(Context Store)가 데이터를 미리 인덱싱하여 에이전트가 한 번에 발견하고 쿼리할 수 있게 합니다. 벤더 MCP와 비교했을 때 Gong은 최대 80%, Zendesk는 90%, Linear는 75%, Salesforce는 16% 더 적은 토큰을 사용합니다. MCP, Python SDK, 노코드 빌더 등 세 가지 방식으로 사용할 수 있습니다. 아직 초기 단계지만 실질적인 도구입니다. 데모 단계를 넘어 에이전트를 배포 중인 분들의 피드백을 기다립니다. 벤치마크 도구는 공개 저장소로 제공되니 직접 테스트해 보실 수 있습니다.

에이전트가 실제 워크플로우로 이동함에 따라 Slack, Salesforce, Linear와 같은 더 많은 도구에 대한 접근 권한이 필요해졌습니다. 이는 인증, 페이지네이션, 필터링, 스키마 처리, 시스템 간 엔티티 매칭 등 수많은 API 작업이 필요함을 의미합니다.

대부분의 MCP는 이 문제를 해결하지 못합니다. MCP는 API를 감싸는 얇은 래퍼에 불과하기 때문에, 에이전트는 여전히 API의 약한 기본 기능을 그대로 물려받아 특히 여러 도구를 함께 사용할 때 오류를 범하게 됩니다.

더 근본적인 문제는 API는 이미 무엇을 쿼리해야 할지(엔드포인트, 객체 ID, 필드 등) 알고 있다고 가정하지만, 에이전트는 보통 그보다 한 단계 앞서서 시작한다는 점입니다. 에이전트는 추론을 시작하기 전에 무엇이 중요한지 먼저 발견해야 합니다.

그래서 저희는 에이전트와 모든 데이터 사이의 컨텍스트 레이어로서 Airbyte Agents를 구축했습니다. 이 핵심에는 저희가 컨텍스트 스토어라고 부르는 것이 있는데, 이는 복제 커넥터에 의해 채워지는 에이전트 검색 최적화 데이터 인덱스입니다. 지난 6년 동안 데이터 커넥터에 쏟은 모든 노력이 여기서 빛을 발합니다!

이를 통해 에이전트는 데이터를 구조적으로 발견할 수 있는 방법을 얻게 되며, 필요할 때 상위 시스템을 직접 읽고 쓸 수도 있습니다.

저희가 이 작업을 시작하게 된 계기는 새로운 SDK로 마이그레이션하던 에이전트의 비정상적인 추적 기록 때문이었습니다. 그 에이전트는 "이번 분기에 이탈 위험이 있는 고객은 누구인가?"라는 질문에 답해야 했습니다. 추적 기록에는 47단계가 있었습니다. 대부분은 API 호출이었습니다. 에이전트는 먼저 수많은 계정을 찾고, 그 다음 올바른 고객에게 매핑하고, 티켓을 찾고... 이런 식이었죠. 결국 에이전트가 응답했을 때 답변은 그럴듯했지만 틀렸습니다. 뿐만 아니라 속도도 매우 느렸습니다. 그래서 무언가 조치를 취해야 했습니다.

그 47단계 에이전트는 Airbyte Agents가 특히 잘 작동하는 질문의 한 예입니다. 다른 예시들은 다음과 같습니다:

• "이번 달에 마감되는 모든 엔터프라이즈 거래 중 열려 있는 지원 티켓이 있는 건을 보여줘."
• "Github 이슈가 생성되지 않은 모든 지원 티켓을 찾아줘."
• "우리 갱신 파이프라인에 있는 기업들과의 가장 최근 Gong 통화 10개를 나열해줘."

이 중 일부는 간단하게 들릴지 모르지만, 에이전트가 런타임에 모든 컨텍스트를 직접 조립할 필요가 없을 때 답변의 품질은 극적으로 달라집니다.

제품의 초기 버전을 만든 후, 저는 주말을 투자해 제대로 작동하는지 확인하기 위한 벤치마크 도구를 만들었습니다. 저는 벤치마크 작성을 좋아하기도 하니까요. 저는 Airbyte Agent MCP를 호출하는 것과 여러 벤더 MCP를 직접 호출하는 것을 비교했습니다. 검색과 탐색 성능을 테스트했습니다.

단순함을 위해 토큰 소비량을 측정 단위로 사용했습니다. 이것이 에이전트가 얼마나 잘 작동하는지를 보여주는 좋은 지표라고 생각합니다. 실패하는 에이전트(47단계가 걸렸던 것과 같은)는 아무런 성과 없이 많은 토큰을 소모하는 반면, 성공적인 에이전트는 바로 핵심에 도달합니다.