데이터브릭스, 에이전트 인프라를 DB 하나로 압축했다

회계법인이 왜 DB 얘기를 하나

데이터브릭스가 8월 10일 자사 X 계정을 통해 회계·자문 법인 CLA(CLAconnect)의 AI 에이전트 운영 사례를 소개했다. 눈에 띄는 건 CLA가 채택한 방식이다. 새로운 AI 모델이나 벤치마크 얘기가 아니라, '에이전트를 어떻게 오래 돌아가게 만들 것인가'라는 인프라 문제를 다뤘다.

데이터브릭스에 따르면 장시간 실행되는 AI 에이전트는 대개 큐, 스케줄러, 캐시, 모니터링 도구가 계속 늘어나는 스택을 필요로 한다. 챗봇처럼 질문 하나에 답 하나를 내놓는 게 아니라, 여러 단계의 작업을 몇 분에서 몇 시간씩 이어가며 실패하면 재시도하고 외부 API 호출 빈도도 조절해야 하기 때문이다. CLA는 이 문제를 데이터브릭스 네이티브 방식으로, 즉 Lakebase Postgres를 오케스트레이션 백본으로 써서 풀었다고 알려졌다.

Lakebase가 하는 일

Lakebase는 데이터브릭스가 제공하는 Postgres 기반 데이터베이스 서비스다. CLA는 이를 통해 내구성 있는 작업 큐(작업이 중간에 끊겨도 상태가 유지되는 대기열), 실패 시 재시도 로직, API 호출 한도를 인식하는 스케줄링, 실시간 모니터링을 구현했다고 발표 내용에 나온다. 별도의 메시지 큐 시스템이나 워크플로 관리 도구, 캐시 서버를 각각 붙이는 대신 하나의 데이터베이스 계층에서 이 기능들을 처리한 셈이다.

구성 요소	전형적인 스택	CLA의 Lakebase 기반 접근
작업 큐	별도 메시지 큐 시스템	Lakebase Postgres 테이블
재시도 처리	워크플로 관리 도구	DB 내 재시도 로직
스케줄링	별도 스케줄러	레이트리밋 인식 스케줄링
모니터링	별도 대시보드	실시간 모니터링 통합

왜 '롱러닝 에이전트'가 문제인가

AI 에이전트가 사람 대신 문서를 조사하고, 여러 시스템을 오가며 작업을 완수하는 방향으로 발전하면서, 하나의 작업이 몇 초가 아니라 몇 시간씩 걸리는 경우가 늘고 있다. 이런 에이전트는 중간에 실패해도 처음부터 다시 시작하지 않고 이어서 진행해야 하고, 외부 API를 과도하게 호출해 차단당하지 않도록 속도를 조절해야 하며, 지금 어디까지 진행됐는지 사람이 실시간으로 확인할 수 있어야 한다. 이 세 가지 요구가 겹치면서 개발팀은 결국 큐·스케줄러·캐시·모니터링을 따로따로 조합하는 스택을 쌓게 된다.

비슷한 문제를 AWS도 다루고 있다. 지난 8월 초 AWS ML Blog는 Bedrock AgentCore에서 실행되는 에이전트가 사용자 로컬 컴퓨터의 MCP 서버에 접근하도록 브리지를 구축한 사례를 공개했는데, 이때 소개된 내부 재무 어시스턴트는 출시 후 1년간 41,000건 이상의 대화를 처리한 것으로 알려졌다. 클라우드 업체마다 표현은 다르지만, 결국 '오래 도는 에이전트를 안정적으로 관리하는 인프라'가 공통 화두로 떠오른 모양새다.

데이터브릭스의 최근 행보와 겹쳐 읽으면

데이터브릭스는 최근 20개 도시를 순회하는 'Data + AI World Tour'를 재개하며 4만 명 규모의 참석자를 결집하겠다고 밝힌 바 있다. 이번 CLA 사례는 그 흐름과 맞닿아 있다. 데이터브릭스가 단순 데이터 플랫폼을 넘어 에이전트 운영 인프라까지 자사 생태계 안에서 해결할 수 있다는 걸 실제 고객 사례로 보여주려는 것으로 읽힌다.

그래서 무엇이 달라지나

지금까지 롱러닝 AI 에이전트를 운영하려면 개발팀이 큐 시스템, 스케줄러, 캐시, 모니터링 도구를 따로 골라 조합해야 했다. CLA 사례는 이 조합을 하나의 Postgres 기반 서비스로 압축할 수 있다는 걸 보여준다. 이미 데이터브릭스를 쓰고 있는 조직이라면 별도 인프라 팀을 꾸리지 않고도 에이전트 운영 체계를 갖출 수 있다는 뜻이다. 다만 이는 데이터브릭스가 제시한 단일 사례이며, 다른 규모나 업종의 에이전트 워크로드에도 동일하게 적용될지는 더 지켜봐야 할 대목이다.