데이터 에이전트 비교: BigQuery·Snowflake·Agentforce가 노리는 것

무슨 일이 일어나고 있나

최근 며칠 사이 데이터·AI 인프라 진영에서 나온 발표들을 따로 떼어 보면 그저 평범한 제품 업데이트처럼 보여요. 그런데 한 줄로 꿰어 보면 같은 방향을 가리키고 있어요. 바로 'AI 에이전트가 데이터에 직접 접근해 일을 처리하는' 자동화 패권 경쟁입니다.

먼저 Google Cloud는 BigQuery를 중심으로 데이터 에이전트를 대폭 확대했어요. Conversational Analytics와 여러 데이터 에이전트를 새로 선보였는데요. BigQuery, Looker, AlloyDB, Spanner, Cloud SQL 같은 데이터베이스에 자연어로 질문하면 AI가 SQL을 자동 생성하고 인사이트까지 제공하는 방식이에요. 여기에 MCP 서버와 Data Agent Kit 같은 개발자 도구를 공개해 써드파티 에이전트 플랫폼과의 연동까지 열어뒀습니다.

같은 시기 Snowflake는 Dynamic Tables의 성능을 끌어올렸어요. 집계 함수·조인·QUALIFY 같은 일반 패턴에서 최대 2.8배 빠른 새로고침을 달성했고, PRIMARY KEY RELY 제약, 적응형 새로고침 모드(Adaptive Refresh Mode), 프로즌 영역(Frozen Regions) 같은 기능으로 파이프라인의 비용 효율성과 안정성을 높였습니다. Apache Iceberg 호환성과 dbt 통합도 강화했고요.

그리고 Salesforce는 고객지원 AI 에이전트 플랫폼 Fin(옛 Intercom)을 약 36억 달러에 인수했어요. Fin은 채팅·이메일·WhatsApp·SMS 등 여러 채널에서 고객 문제를 자동으로 해결하는 Apex라는 자체 AI 모델을 보유하고 있는데요. 이번 인수는 Salesforce의 Agentforce 사업이 전년 대비 20% 성장해 12억 달러 ARR을 달성한 직후 이뤄졌어요.

왜 중요한가

세 회사의 행보를 인과로 연결하면 '에이전트가 일하려면 무엇이 필요한가'라는 질문의 답이 보여요.

에이전트가 사람을 대신해 분석하고 응대하려면, 그 밑에 신뢰할 수 있는 데이터가 빠르게 갱신되고 있어야 해요. Snowflake가 Dynamic Tables의 새로고침을 2.8배 빨라지게 만든 건 단순한 성능 자랑이 아니에요. 에이전트가 최신 데이터를 근거로 판단하려면 파이프라인이 적은 비용으로 자주 갱신돼야 하거든요. 적응형 새로고침과 프로즌 영역은 '필요한 만큼만 다시 계산한다'는 발상인데, 에이전트 시대의 비용 통제와 정확히 맞물립니다.

Google Cloud의 데이터 에이전트는 그 위에 올라가는 '두뇌'에 해당해요. 자연어 질문을 SQL로 바꿔주는 건 분석가의 진입 장벽을 낮추는 동시에, 에이전트가 데이터베이스를 스스로 탐색하게 만드는 토대예요. 특히 MCP 서버와 Data Agent Kit를 개방한 건 중요한 신호인데요. 한 회사의 폐쇄 생태계가 아니라 표준 프로토콜로 에이전트를 연결하겠다는 거예요.

Salesforce의 Fin 인수는 이 흐름의 '출구'를 보여줘요. 데이터가 빨라지고(인프라), 자연어로 다룰 수 있게 되면(분석), 최종적으로는 고객 응대 같은 실제 업무를 에이전트가 끝까지 처리(실행)하는 단계로 갑니다. Agentforce가 20% 성장하며 12억 달러 ARR을 찍은 상황에서 자체 AI 모델을 가진 회사를 통째로 사들인 건, 실행 단계의 역량을 돈으로 사서 시간을 벌겠다는 판단이에요.

정리하면 인프라(Snowflake)→분석 에이전트(BigQuery)→실행 에이전트(Agentforce/Fin)로 이어지는 가치사슬 전체에서 동시다발적으로 자동화 투자가 일어나고 있는 거예요.

실무에 주는 함의

실무자 입장에서 세 가지를 준비하면 좋아요.

첫째, 파이프라인을 '에이전트가 읽을 수 있는 상태'로 정돈하세요. 에이전트가 자연어로 질문해도 데이터 정의가 엉켜 있으면 엉뚱한 SQL이 나와요. Dynamic Tables처럼 선언형으로 갱신을 관리하고, dbt 같은 도구로 변환 로직을 문서화해두면 에이전트가 신뢰할 근거가 생깁니다. PRIMARY KEY 같은 제약을 명시하는 작은 습관이 에이전트 정확도로 이어져요.

둘째, 자연어 분석을 '분석가 대체'가 아니라 '병목 제거'로 접근하세요. Conversational Analytics는 비전문가의 단순 질의를 흡수해 분석가가 복잡한 문제에 집중하게 해줘요. 마케팅 실무에서는 대시보드 요청 처리에 쓰던 시간을 캠페인 가설 검증으로 돌릴 수 있어요.

셋째, 고객 접점 자동화는 측정 가능한 범위부터 시작하세요. Fin이 보여주듯 채팅·이메일·메신저의 반복 문의는 에이전트로 옮길 여지가 큰데요. 해결률과 에스컬레이션 비율을 지표로 잡고 단계적으로 위임 범위를 넓히는 게 안전해요.

그리고 한 가지 더, 개방형 표준을 눈여겨보세요. MCP 서버나 Data Agent Kit 같은 연동 표준은 특정 벤더 종속을 줄여줘요. 도구를 고를 때 '우리 데이터를 외부 에이전트와도 연결할 수 있는가'를 체크리스트에 넣으면 좋아요.

리스크·한계

장밋빛만 있는 건 아니에요. 가장 큰 리스크는 신뢰와 통제예요.

에이전트가 자동 생성한 SQL이나 응대가 틀렸을 때 책임 소재가 모호해져요. 자연어 분석은 질문이 모호하면 그럴듯하지만 틀린 답을 내놓기 쉽고, 사용자는 그걸 검증하기 어려워요. 갱신이 빨라진 데이터라도 정의가 잘못돼 있으면 빠르게 틀리는 셈이고요.

또 하나는 외부 환경 변수예요. 같은 시기 미국 정부가 Anthropic의 모델을 수출통제로 갑자기 오프라인 조치한 사례는, AI 모델이 정책·규제 리스크에 얼마나 취약한지 보여줘요. 핵심 워크플로를 특정 모델에 전적으로 의존하면, 모델 공급이 끊겼을 때 업무 전체가 멈출 수 있어요. 멀티 모델 전략과 폴백 설계가 필요한 이유예요.

마지막으로 '내러티브 중력' 문제도 곱씹어볼 만해요. AI 검색이 과거 데이터에 갇혀 옛 이야기를 현재처럼 반복한다는 연구처럼, 에이전트도 오래된 학습이나 갱신 안 된 데이터에 갇히면 낡은 판단을 반복할 수 있어요. 결국 빠른 인프라, 정돈된 데이터, 그리고 사람의 감독이라는 삼박자가 갖춰져야 에이전트 자동화가 진짜 자산이 됩니다.

자주 묻는 질문

데이터 에이전트가 무엇이고 왜 중요한가요?

자연어로 질문하면 AI가 SQL을 자동 생성해 데이터베이스를 직접 탐색·분석하는 에이전트예요. 분석가의 진입 장벽을 낮추고, 인프라→분석→실행으로 이어지는 자동화의 두뇌 역할을 해요.

에이전트를 위해 데이터 파이프라인을 어떻게 정돈하나요?

에이전트가 읽을 수 있는 상태로 만들어야 해요. 선언형 갱신(Dynamic Tables), dbt로 변환 로직 문서화, PRIMARY KEY 같은 제약 명시 — 정의가 엉키면 엉뚱한 SQL이 나와요.

특정 벤더 종속을 피하려면 어떻게 하나요?

MCP 서버나 Data Agent Kit 같은 개방형 연동 표준을 눈여겨보세요. 도구 선택 시 '우리 데이터를 외부 에이전트와도 연결할 수 있는가'를 체크리스트에 넣고, 멀티 모델·폴백 설계로 정책·수출통제 리스크에 대비하세요.