Skip to main content
이 문서는 GenAI 개념 섹션의 일부입니다.
Databricks의 Agent 전략은 다른 벤더와 근본적으로 다릅니다. AWS/Microsoft/Google이 “Agent 인프라/모델을 제공하는” 포지션인 반면, Databricks는 “데이터와 Agent의 통합 거버넌스” 를 핵심 가치로 제시합니다.
참고 학습 목표
  • Databricks Agent 전략의 핵심 차별점(“데이터 중심 Agent”)을 설명할 수 있다
  • Agent Bricks, Supervisor Agent, Mosaic AI Gateway, MLflow 3.0의 역할을 이해한다
  • TAO/ALHF 자동 최적화가 기존 Agent 개발과 어떻게 다른지 설명할 수 있다
  • 멀티클라우드 환경에서 Databricks Agent 아키텍처를 설계할 수 있다
성공 핵심 메시지: “Agent의 품질은 데이터의 품질에 의해 결정된다. Databricks는 데이터 준비에서 Agent 배포, 모니터링까지 전체 라이프사이클을 하나의 플랫폼에서 관리한다.”

​
1. 전략 개요 — 데이터 중심 Agent

Databricks의 근본적인 차별화:

​
전략 스택

​
2. Agent Bricks — 자동 최적화 Agent 빌더

Agent Bricks는 Databricks의 노코드 Agent 빌더 로, 2025년 6월 Data+AI Summit에서 GA되었습니다. 가장 혁신적인 기능은 TAO 와 ALHF 입니다.

​
제품 구성

​
TAO (Tool-Augmented Optimization)

기존 Agent 프레임워크에서 Agent의 Tool 선택 정확도를 높이려면 프롬프트를 수동으로 조정해야 합니다. TAO는 이를 자동화 합니다:
  1. Agent가 도구를 호출할 때마다 성공/실패를 추적
  2. Tool 선택 패턴을 분석하여 전략을 자동 조정
  3. 도메인 특화 합성 데이터를 자동 생성하여 벤치마크 구축
참고 비유: TAO는 “Agent의 자동 코치”입니다. 매 경기(Tool 호출)를 분석하고, 전략(프롬프트)을 자동 개선합니다. 코치(프롬프트 엔지니어)가 직접 개입할 필요가 없습니다.

​
ALHF (Automated Learning from Human Feedback)

최종 사용자가 Agent 응답에 “좋아요/싫어요” 피드백을 남기면:
  • 좋아요: 해당 추론 경로(Tool 선택 → 응답 생성)가 강화
  • 싫어요: 해당 추론 경로가 약화
성공 핵심 가치: 별도 Fine-tuning 파이프라인 없이, 프로덕션에서 Agent가 자동으로 개선 됩니다. RLHF의 엔터프라이즈 버전이라고 볼 수 있습니다.

​
3. Supervisor Agent — 노코드 멀티에이전트

Supervisor Agent는 Agent Bricks 내에서 코드 없이 멀티에이전트 시스템을 구축 할 수 있는 기능입니다.

​
설정 과정

  1. 하위 Agent(Knowledge Assistant, Genie Agent 등)를 각각 생성
  2. Supervisor Agent 생성 시 하위 Agent를 “도구”로 등록
  3. 라우팅 규칙(자동/수동) 설정
  4. 평가 세트로 전체 시스템 품질 검증
  5. Model Serving Endpoint로 배포

​
연결 가능한 도구 유형

​
4. Mosaic AI Gateway — 멀티모델 관리

Mosaic AI Gateway는 Databricks의 중앙집중형 AI 모델 관리 계층 입니다.
주의 왜 Gateway가 중요한가?
멀티에이전트 시스템에서 각 Agent가 서로 다른 모델을 사용할 수 있습니다. Gateway 없이는:
  • 비용 추적이 불가능 (어떤 Agent가 얼마나 소비하는지?)
  • 모델 교체가 어려움 (코드 변경 필요)
  • 거버넌스 사각지대 (어떤 데이터가 어떤 모델로 흘러갔는지?)
Gateway는 이 모든 문제를 인프라 계층에서 해결 합니다.

​
5. MLflow 3.0 — GenAI Observability

MLflow 3.0은 기존 ML 실험 추적 도구에서 GenAI/Agent 전문 관측 도구 로 진화했습니다.
참고 MLflow 3.0의 Agent 추적 예시: Agent가 “지난 분기 매출 분석해줘”라는 요청을 처리할 때, Trace에서 다음을 확인할 수 있습니다:
  1. LLM이 요청을 분석한 추론 과정
  2. SQL 도구를 선택한 이유
  3. 실행된 SQL 쿼리와 결과
  4. 최종 응답 생성 과정
  5. 각 단계의 토큰 사용량과 지연시간

​
6. 멀티에이전트 아키텍처

Databricks의 멀티에이전트 전략은 “데이터 중심 오케스트레이션” 입니다.

​
다른 벤더와의 통합 패턴

Databricks는 모델 중립적이므로, 다른 벤더의 모델/서비스와 자연스럽게 결합됩니다:

​
7. 차별점 요약 — 왜 Databricks인가?

​
8. 고객 시나리오별 권장 아키텍처

​
9. 고객이 자주 묻는 질문

​
Q1: “Agent Bricks vs Agent Framework — 뭘 써야 하나요?”

참고
  • Agent Bricks: 노코드, 빠른 구현, RAG/SQL/멀티에이전트의 표준 패턴에 적합. 대부분의 사용 사례는 여기서 해결.
  • Agent Framework (ChatAgent): 코드 기반, 커스텀 로직이 필요한 경우. LangGraph 통합, 복잡한 조건 분기, 외부 API 연동.
  • 권장: Agent Bricks로 시작 → 한계가 느껴지면 Agent Framework로 전환.

​
Q2: “Databricks가 모델도 만드나요? DBRX는?”

참고 DBRX는 Databricks가 만든 오픈웨이트 모델이지만, Databricks의 Agent 전략은 모델 중립 입니다. GPT-4.1, Claude, Gemini, Llama 4 등 어떤 모델이든 Gateway를 통해 사용할 수 있습니다.
Databricks의 핵심 가치는 “최고의 모델을 만드는 것”이 아니라, “어떤 모델을 쓰든 데이터 거버넌스와 Agent 품질을 보장하는 것”입니다.

​
Q3: “MLflow 3.0은 LangSmith와 뭐가 다른가요?”

참고 | 비교 | MLflow 3.0 | LangSmith | |------|-----------|-----------| | 라이선스 | 오픈소스 | 상용 | | 프레임워크 | 프레임워크 무관 | LangChain/LangGraph 최적화 | | 데이터 거버넌스 | Unity Catalog 통합 | 없음 | | 실험 추적 | ML + GenAI 통합 | GenAI 전용 | | 모델 레지스트리 | 포함 | 없음 |
LangGraph를 사용하더라도, Databricks 환경에서는 MLflow 3.0을 권장 합니다. Unity Catalog와의 통합으로 데이터 리니지까지 추적할 수 있습니다.

​
Q4: “타 벤더 Agent 플랫폼과 비교했을 때 Databricks를 선택해야 하는 결정적 이유는?”

참고 한 문장 요약: “Agent가 아무리 잘 만들어져도, 사용하는 데이터가 잘못되면 쓸모없다.”
Databricks만이 데이터 준비(ETL) → 임베딩/벡터화 → Agent 개발 → 평가 → 배포 → 모니터링 → 거버넌스 전체를 하나의 플랫폼에서 관리합니다. 다른 벤더는 각 단계마다 다른 서비스를 조합해야 합니다. 특히 Unity Catalog 하나로 데이터 접근 제어, 모델 거버넌스, Agent 감사가 통합되는 것은 규제 환경(금융, 의료, 공공)에서 결정적 장점입니다.

​
10. 참고 자료

​
다음 단계