요약
- 데이터브릭스가 AI 에이전트를 프로덕션에서 운영하는 방법을 다룬 「빅 북 오브 에이전트옵스」를 9월 2일 공개했어요
- DXC는 에이전트 3개를 이미 운영 중이고 8개는 파일럿 단계이며, 데이터브릭스 이전 후 플랫폼 총소유비용을 30% 줄였다고 밝혔어요
- 인터콘티넨탈 익스체인지(ICE)의 텍스트-투-SQL 에이전트는 약 50개 쿼리에서 구문 정확도 77%, 실행 일치율 96%를 기록했어요
- 발표
- 데이터브릭스 블로그, 2026년 9월 2일 「Big Book of AgentOps」 공개
- 책 구성
- 6개 챕터, 4가지 에이전트 아키텍처, 4가지 배포 패턴, 7단계 로드맵
- FactSet 사례
- 텍스트-투-코드 에이전트가 단일 파운데이션 모델에서 전체 에이전트 시스템으로 진화, 정확도 44% 개선
- DXC Technology 사례
- 프로덕션 에이전트 3개, 파일럿·개발 중 8개, 데이터브릭스 이전 후 플랫폼 TCO 30% 절감
- ICE(Intercontinental Exchange) 사례
- 거버넌스 적용 텍스트-투-SQL, 약 50개 쿼리에서 구문 정확도 77%·실행 일치율 96%
- Block 사례
- 판매자 운영용 AI 에이전트 시스템으로 생산성 이득 1,000만달러(데이터브릭스 발표 수치)
- 핵심 플랫폼 구성요소
- MLflow(평가·트레이싱), Unity Gateway(모델·도구 트래픽), Unity Catalog(권한·계보·접근제어)
기업들이 생성형 AI 파일럿을 실제 운영으로 옮기지 못하고 멈추는 지점은 대체로 비슷하다는 게 데이터브릭스(Databricks)의 진단이에요. 데이터브릭스는 블로그를 통해 AI 에이전트 운영 지침서 「빅 북 오브 에이전트옵스(Big Book of AgentOps)」를 공개했어요. 에이전트를 설계하는 단계까지는 어렵지 않게 가지만, 이 에이전트에 어떤 권한을 줄지, 실패했을 때 무슨 일이 벌어지는지, 비용은 누가 책임지는지 같은 운영 질문에서 대부분의 팀이 멈춘다고 짚었어요.
에이전트옵스가 필요해진 이유
데이터브릭스는 AI 에이전트를 단순히 응답을 내놓는 모델이 아니라, 실행 중에 도구를 고르고 기업 데이터를 끌어오고 API를 호출하며 여러 단계를 스스로 밟아나가는 시스템으로 정의했어요. 이 능력 하나하나가 잘못될 수 있는 지점이에요. 잘못된 도구 호출, 지나치게 넓은 권한, 예상 못 한 비용 급증이 그 예시로 제시됐어요.
풀어서 설명하면, 예전엔 예측 모델을 운영에 올리는 관행을 MLOps라 불렀고, 챗GPT 같은 언어모델이 나오면서 프롬프트·모델 버전 관리를 더한 LLMOps가 뒤를 이었어요. 이번에 나온 AgentOps는 그 다음 단계로, 스스로 도구를 고르고 여러 단계를 거쳐 작업을 실행하는 에이전트를 대상으로 한 운영 규율이에요.
파일럿이 멈추는 지점
데이터브릭스는 프로덕션에 도달하지 못하는 에이전트 프로젝트의 공통 패턴도 짚었어요. 처음부터 범위가 너무 넓은 사용 사례를 고르거나, 복잡도가 정당화되기 전에 멀티 에이전트 오케스트레이션부터 시도하거나, 불필요한 추론 루프를 넣거나, 평가를 뒤로 미루는 경우가 대표적이라고 밝혔어요. 기술적으로 잘 짜인 프로젝트도 이런 조직 내 정렬 문제 때문에 멈추는 일이 많다는 점도 짚었는데, 실행 스폰서·제품 책임자·주제 전문가·보안·컴플라이언스·재무 부서가 한 방향으로 맞춰져 있어야 한다는 이야기예요.
여섯 챕터로 구성된 실전 지침서
책은 개념에서 구현으로 순서대로 내려가는 여섯 챕터로 짜였어요. 에이전트 유형과 안티패턴을 정리한 뒤, 단일 워크스페이스부터 다중 계정·다중 에이전트 기업 토폴로지까지 네 가지 배포 아키텍처를 다루고요. 팀 구성부터 데이터 인프라, 평가 루프, 거버넌스까지 이어지는 일곱 단계 로드맵도 넣었어요. 여기서 비용 관리는 특히 강조된 대목인데, 요청 하나가 서브 에이전트·재시도·가드레일 점검을 거치며 여러 번의 모델 호출로 불어날 수 있어서 사용량 귀속과 한도 설정이 필수라고 짚었어요.
평가 부분에서는 『데브옵스 핸드북』에서 가져온 흐름·피드백·지속적 학습 원칙을 에이전트 시스템에 적용하는 방법을 소개했어요. 실제 실행 기록으로 골든 평가 데이터셋을 만들고, 주제 전문가의 판단에 맞춰 자동화된 평가자를 보정하는 방식이에요. 마지막 챕터는 이해관계자 정렬을 위한 RACI 매트릭스와 출시 전후 커뮤니케이션 주기를 다뤘어요.
숫자로 보는 도입 사례
책에는 실제 도입 기업들의 수치도 함께 실렸어요.
| 기업 | 에이전트 사례 | 확인된 성과 |
|---|---|---|
| FactSet | 텍스트-투-코드 지식 에이전트 | 단일 파운데이션 모델에서 전체 에이전트 시스템으로 전환, 정확도 44% 개선 |
| DXC Technology | 다수 에이전트 포트폴리오 | 프로덕션 3개, 파일럿·개발 8개, 플랫폼 TCO 30% 절감 |
| ICE | 거버넌스 적용 텍스트-투-SQL | 약 50개 쿼리에서 구문 정확도 77%, 실행 일치율 96% |
| Block | 판매자 운영용 AI 에이전트 | 생산성 이득 1,000만달러(데이터브릭스 발표) |
DXC는 데이터브릭스로 옮긴 뒤 AI 포트폴리오를 확장하는 중이고, Block은 Unity Catalog로 여러 사업부의 데이터 접근을 관리하면서 AI와 운영 업무 모두를 같은 환경에서 돌리고 있다고 데이터브릭스는 설명했어요.
데이터브릭스 플랫폼이 받쳐주는 것
에이전트 수가 늘어날수록 개별 애플리케이션 안에 흩어진 통제는 감사하기 어려워진다는 게 데이터브릭스의 설명이에요. 그 대안으로 제시한 게 플랫폼 접근 방식인데, 데이터 접근·모델과 도구 사용·트레이싱·평가·정책 집행을 한곳에서 관리하는 구조예요. 데이터브릭스에서는 평가와 트레이싱을 MLflow가, 모델·도구 트래픽을 Unity Gateway가, 데이터와 AI 자산에 대한 발견·권한·계보·접근제어를 Unity Catalog가 맡는다고 밝혔어요.
에디터의 시선
데이터브릭스가 이 시점에 운영 지침서를 내놓은 건 우연이 아니에요. 지난 8월 AWS가 Bedrock용 오픈소스 에이전트 스킬을 내놓고 로컬 MCP 브리지를 공개했고, 엔비디아는 하네스만 바꿔 같은 모델의 벤치마크 점수를 30%에서 100%로 끌어올리는 걸 보여줬어요. 모델 자체의 성능 경쟁은 이미 벌어질 만큼 벌어졌고, 지금 업계가 붙잡고 있는 문제는 「그 모델을 어떻게 안전하게, 예측 가능하게 굴리느냐」로 넘어갔다는 뜻이에요. 데이터브릭스처럼 자체 모델보다 데이터·거버넌스 계층에 무게를 둔 회사가 이 흐름에서 존재감을 키우는 건 자연스러운 선택이에요.
예전엔 AI 도입 사례를 소개할 때 정확도나 벤치마크 점수 하나로 끝내는 경우가 많았는데, 이번 책에 실린 DXC·ICE·Block 사례는 죄다 운영 지표예요. TCO 절감률, 프로덕션 대 파일럿 개수, 구문 정확도와 실행 일치율을 나란히 놓은 건, 에이전트를 만드는 것과 에이전트를 계속 믿고 쓰는 것이 다른 문제라는 걸 인정한 셈이에요. 실제로 이 크기의 에이전트 프로젝트를 실무에 붙여 보면 결론은 늘 비슷해요 — 모델을 바꾸는 것보다 권한 설계와 평가 루프를 먼저 잡아 두는 쪽이 나중에 드는 시간을 훨씬 줄여줘요.
국내 기업이라면 지금 당장 멀티 에이전트 오케스트레이션부터 설계하려 들기보다, 좁은 사용 사례 하나에 성공 지표를 명확히 걸고 실제 실행 기록으로 평가셋부터 쌓는 순서가 맞아요. 비용 귀속과 최소 권한 원칙을 먼저 세우지 않으면, 서브 에이전트와 재시도가 늘어나는 순간 비용과 리스크가 동시에 튀어 오르는 걸 막기 어려워요. 앞으로 몇 달 안에는 데이터브릭스뿐 아니라 다른 클라우드·플랫폼 업체들도 비슷한 운영 프레임워크를 잇달아 내놓으면서, AI 에이전트 경쟁의 무게중심이 모델 성능에서 운영 안정성 쪽으로 더 옮겨갈 걸로 보여요.
댓글