Skip to main content

Agent Bricks란?

💡 Agent Bricks 는 Databricks가 제공하는 사전 구축된 에이전트 템플릿 입니다. 코드 없이 또는 최소 코드로 AI 에이전트를 빠르게 구축할 수 있습니다. 문서 Q&A, SQL 데이터 분석, 멀티 에이전트 오케스트레이션의 세 가지 유형을 제공합니다.
AI 에이전트를 처음부터 코드로 구축하려면 LLM 연동, 프롬프트 설계, RAG 파이프라인 구성, Tool 연결, 에러 처리 등 상당한 개발 노력이 필요합니다. Agent Bricks는 이러한 공통 패턴을 템플릿화 하여, 몇 번의 클릭과 설정만으로 프로덕션 수준의 에이전트를 만들 수 있게 해줍니다. 특히 PoC(개념 검증)나 빠른 프로토타이핑에 매우 효과적입니다.

Agent Bricks 유형

유형설명상태적합한 사용
Knowledge Assistant문서 기반 Q&A 챗봇입니다. PDF, 문서에서 답변을 찾아 인용과 함께 제공합니다GA사내 문서 검색, 고객 FAQ, 제품 매뉴얼
Genie (SQL Agent)자연어로 데이터에 질문하면 SQL을 생성 하여 답변합니다GA비즈니스 데이터 탐색, KPI 조회
Supervisor Agent여러 에이전트를 조율하는 멀티 에이전트 오케스트레이터 입니다GA복합 고객 지원 (주문+환불+기술지원)

어떤 유형을 선택해야 할까요?

에이전트 유형 선택은 사용자의 주요 요구사항에 따라 결정됩니다. 아래 의사결정 가이드를 참고하세요. 질문: “사용자가 주로 무엇을 원하나요?”
사용자 요구권장 에이전트예시
문서에서 정보를 찾고 싶다Knowledge AssistantFAQ 답변, 매뉴얼 검색, 규정 조회
데이터를 분석하고 싶다Genie (SQL Agent)매출 조회, KPI 확인, 트렌드 분석
업무를 자동화하고 싶다Custom Agent (ChatAgent)주문 처리, 환불 신청, 보고서 생성
코드를 작성/리뷰하고 싶다Coding Assistant코드 생성, 디버깅, PR 리뷰

Knowledge Assistant

개념

Knowledge Assistant는 문서(PDF, 웹 페이지, 사내 위키 등)를 기반으로 질문에 답변하는 RAG(Retrieval-Augmented Generation) 챗봇 입니다. 내부적으로 Vector Search를 사용하여 관련 문서를 검색하고, LLM이 검색된 문서를 바탕으로 답변을 생성합니다. 답변 시 출처 문서를 인용 하여 신뢰성을 높이며, 사용자가 원본 문서를 직접 확인할 수 있는 링크도 제공합니다.
단계구성 요소설명
1사용자 질문사용자가 질문을 입력합니다
2Knowledge Assistant질문을 받아 Vector Search로 문서를 검색합니다
3Vector Search관련 문서를 검색하여 Assistant에 반환합니다
4최종 응답답변 + 출처 인용을 사용자에게 제공합니다

생성 방법

Knowledge Assistant는 UI를 통해 코드 없이 생성할 수 있습니다. 각 단계에서 다양한 설정 옵션을 조정하여 에이전트의 동작을 맞춤화할 수 있습니다.
  1. PlaygroundCreate Knowledge Assistant
  2. 이름 입력: 에이전트의 이름을 지정합니다 (예: hr-policy-assistant)
  3. LLM 선택: 사용할 LLM을 선택합니다 (예: Llama 3.3 70B, GPT-4o 등). 응답 품질, 속도, 비용을 고려하여 선택합니다
  4. 문서 소스 연결: Unity Catalog Volume 또는 Vector Search Index를 지정합니다. Volume을 선택하면 자동으로 인덱싱이 수행됩니다
  5. 시스템 프롬프트 작성(선택): “당신은 XX 분야 전문가입니다. 한국어로 답변하세요.” 등의 지침을 입력합니다
  6. 검색 설정: 검색할 문서 수, 유사도 임계값 등을 조정합니다
  7. 테스트: Playground에서 바로 질문하여 답변 품질을 확인합니다
  8. 배포: Model Serving 엔드포인트로 배포합니다. 자동으로 REST API가 생성됩니다

주요 설정 옵션

설정 항목설명권장값
LLM 모델답변 생성에 사용할 LLM입니다품질 우선: GPT-4o / 비용 우선: Llama 3.3 70B
문서 소스검색 대상 문서가 저장된 위치입니다UC Volume 또는 Vector Search Index
시스템 프롬프트에이전트의 역할과 규칙을 정의합니다역할, 언어, 답변 스타일 명시
검색 문서 수답변 생성 시 참조할 최대 문서 수입니다3~5개
대화 이력멀티턴 대화에서 유지할 이전 대화 수입니다5~10턴

활용 시나리오

시나리오문서 소스시스템 프롬프트 예시
사내 IT 헬프데스크사내 IT 정책 문서, FAQ”당신은 사내 IT 지원 전문가입니다. IT 정책과 절차에 대해 안내합니다.”
고객 지원 챗봇제품 매뉴얼, 반품/배송 정책”당신은 친절한 고객 지원 상담사입니다. 항상 한국어로 답변하세요.”
신입사원 온보딩사내 규정, 프로세스 가이드”당신은 신입사원 멘토입니다. 회사 규정과 절차를 쉽게 설명해 주세요.”
법률/규정 검색계약서, 법률 문서”당신은 법률 리서치 보조입니다. 정확한 조항을 인용하여 답변하세요.”
제품 기술 문서API 문서, 개발 가이드”당신은 기술 문서 전문가입니다. 코드 예제와 함께 설명하세요.”

Genie (SQL Agent)

개념

Genie는 자연어 질문을 SQL 쿼리로 변환 하여 데이터에서 답변을 찾아주는 에이전트입니다. 비개발자도 “이번 달 서울 매출이 얼마야?”라고 물으면, 자동으로 SQL을 생성하고 실행하여 결과를 보여줍니다. Agent Bricks의 Genie는 08. AI/BI 섹션의 Genie와 동일한 기술을 에이전트 형태로 제공합니다.

동작 방식

👤: "이번 달 서울 지역 매출이 전월 대비 어떻게 됐어?"

🤖 Genie 내부 처리:
  1. 자연어 질문을 분석합니다
  2. 사용 가능한 테이블/컬럼 메타데이터를 확인합니다
  3. SQL 쿼리를 생성합니다:
     SELECT region, SUM(amount) AS total_sales, ...
  4. SQL을 실행하고 결과를 가져옵니다
  5. 결과를 자연어로 요약합니다

💬: "2025년 3월 서울 매출은 15.2억원으로, 전월(13.8억원) 대비 10.1% 증가했습니다."
    [차트: 월별 매출 추이]

Genie Space 설정

Genie를 Agent Brick으로 사용하려면 먼저 Genie Space 를 생성하고, 에이전트가 접근할 수 있는 테이블과 설명을 구성해야 합니다.
설정 항목설명중요도
테이블 선택Genie가 쿼리할 수 있는 테이블을 지정합니다필수
테이블 설명각 테이블과 컬럼에 대한 설명을 작성합니다. 설명이 자세할수록 SQL 생성 정확도가 높아집니다매우 중요
샘플 질문예상되는 질문과 정답 SQL을 등록합니다. Few-shot 예시로 활용됩니다권장
지침테이블 간 조인 조건, 비즈니스 용어 정의 등을 안내합니다권장
💡 : Genie의 SQL 생성 정확도를 높이려면 테이블과 컬럼에 상세한 설명(Comment) 을 추가하는 것이 가장 효과적입니다. 예를 들어, order_status 컬럼에 “주문 상태 코드 (1: 주문완료, 2: 배송중, 3: 배송완료, 4: 취소)“라고 설명을 달아두면 훨씬 정확한 SQL을 생성합니다.

Supervisor Agent (멀티 에이전트)

개념

💡 Supervisor Agent 는 사용자 요청을 분석하여 적절한 하위 에이전트에게 작업을 위임 하는 오케스트레이터입니다. 복잡한 요청을 여러 전문 에이전트가 협력하여 처리합니다.
실제 업무에서는 하나의 질문이 여러 영역에 걸치는 경우가 많습니다. 예를 들어, “주문 12345의 배송이 지연되고 있는데, 환불 가능한지 확인하고, 이 고객의 전체 구매 이력도 알려주세요”라는 요청은 주문 조회, 환불 정책, 데이터 분석 세 가지 영역을 동시에 다루어야 합니다. Supervisor Agent는 이런 복합 요청을 자동으로 분류하고, 적절한 하위 에이전트에게 위임합니다.
구성 요소유형담당 영역설명
Supervisor Agent오케스트레이터요청 분석 및 라우팅사용자 요청을 분석하여 적절한 하위 에이전트에 위임합니다
주문 에이전트Knowledge Assistant주문 관련주문 정책 문서 기반으로 주문 관련 질문에 답변합니다
환불 에이전트Knowledge Assistant환불 관련환불 정책 문서 기반으로 환불 관련 질문에 답변합니다
데이터 에이전트Genie데이터 조회매출/고객 테이블에서 SQL로 데이터를 조회합니다
기술지원 에이전트Knowledge Assistant기술 지원기술 문서 기반으로 기술 관련 질문에 답변합니다

동작 방식

Supervisor Agent는 다음 단계로 동작합니다. 각 단계가 자동으로 수행되므로 사용자는 하위 에이전트의 존재를 알 필요가 없습니다.
  1. 요청 분석: 사용자가 요청을 입력하면, Supervisor가 LLM을 사용하여 요청의 의도를 분석합니다
  2. 에이전트 선택: 분석 결과를 바탕으로 적절한 하위 에이전트를 선택합니다. 하나 또는 여러 에이전트를 선택할 수 있습니다
  3. 작업 위임: 선택된 하위 에이전트에게 질문을 전달하고, 각 에이전트가 독립적으로 작업을 수행합니다
  4. 결과 종합: 모든 하위 에이전트의 결과를 Supervisor가 수집하고, 하나의 통합된 답변으로 종합합니다
  5. 순차 호출: 필요한 경우 한 에이전트의 결과를 바탕으로 다른 에이전트를 추가로 호출 할 수도 있습니다

Supervisor Agent 구성

Supervisor Agent를 생성할 때는 하위 에이전트의 목록과 각 에이전트의 역할을 정의합니다.
설정 항목설명
하위 에이전트 목록등록할 에이전트를 선택합니다. Knowledge Assistant, Genie, 커스텀 에이전트를 혼합할 수 있습니다
에이전트 설명각 하위 에이전트의 역할을 상세히 기술합니다. Supervisor가 라우팅 결정 시 이 설명을 참고합니다
Supervisor 프롬프트Supervisor의 전반적인 행동 지침을 정의합니다
LLM 모델Supervisor가 라우팅 결정에 사용할 LLM을 선택합니다

활용 시나리오 상세

👤: "주문 12345의 배송이 지연되고 있는데, 환불 가능한지 확인하고,
     이 고객의 전체 구매 이력도 알려주세요."

🧑‍💼 Supervisor:
  1. 주문 에이전트에게 주문 12345 상태 확인 요청
  2. 환불 에이전트에게 환불 정책 확인 요청
  3. 데이터 에이전트에게 고객 구매 이력 조회 요청
  4. 세 결과를 종합하여 답변

💬: "주문 12345는 현재 배송 지연 상태(예상 도착: 3/25)입니다.
     배송 지연 시 환불이 가능하며, 환불 절차는...
     해당 고객의 전체 구매 이력: 총 23건, 누적 금액 580만원..."

MAS(Multi-Agent System) 설계 모범 사례

원칙설명
단일 책임 원칙각 하위 에이전트는 하나의 전문 영역만 담당하도록 설계합니다. 범위가 넓으면 분할합니다
명확한 역할 기술하위 에이전트의 설명을 구체적으로 작성합니다. “주문 관련”보다 “주문 상태 확인, 배송 추적, 주문 변경 처리”가 좋습니다
중복 방지두 에이전트의 역할이 겹치면 Supervisor가 혼란스러워집니다. 역할 경계를 명확히 합니다
점진적 확장처음에는 2~3개 에이전트로 시작하고, 필요에 따라 하위 에이전트를 추가합니다

현업 사례: Knowledge Assistant를 30분 만에 구축한 경험

🔥 실전 경험담 한 제조업 고객사에서 “사내 품질 관리 매뉴얼을 AI로 검색하고 싶다”는 요구사항을 받았습니다. 기존에는 500페이지 분량의 PDF를 사원들이 직접 검색하고 있었고, 평균 답변 찾기까지 15~20분이 걸렸습니다. 고객 미팅 시간이 1시간밖에 없었기 때문에, 미팅 도중에 라이브로 Knowledge Assistant를 구축 하기로 했습니다. 과정은 다음과 같았습니다:
  1. 5분: PDF 5개를 UC Volume에 업로드
  2. 10분: Playground에서 Knowledge Assistant 생성, LLM 선택(Llama 3.3 70B), 시스템 프롬프트 작성
  3. 5분: Vector Search 인덱싱 대기 (문서 분량이 적어 빠르게 완료)
  4. 10분: 고객이 직접 질문하며 테스트 (“FMEA 절차가 뭐야?”, “불량률 기준이 어떻게 돼?”)
고객의 반응은 “이게 진짜 30분 만에 된 거예요?”였습니다. 이 데모 하나로 Databricks 도입이 결정 되었고, 이후 커스텀 에이전트로 확장하여 ERP 시스템과 연동하는 프로젝트로 발전했습니다.

각 Brick의 실전 활용 시나리오

Knowledge Assistant — 현업에서 가장 많이 쓰는 시나리오

시나리오문서 규모구축 시간ROI 예상주의사항
사내 IT 헬프데스크50~200페이지1시간헬프데스크 문의 30~50% 감소FAQ 문서가 최신이어야 합니다
신입사원 온보딩100~500페이지2시간온보딩 기간 1주 단축부서별 문서 분리 필요
고객 FAQ 챗봇30~100페이지30분고객 지원 비용 20~40% 절감답변 정확도 검증 필수
법규/규정 검색1,000페이지+4시간규정 조회 시간 90% 단축Chunking 전략이 중요합니다
제품 기술 문서200~1,000페이지2시간엔지니어 자가 해결률 향상코드 예제 포함 시 정확도 주의
💡 현업 팁: Knowledge Assistant의 성능은 문서 품질에 80% 이상 의존 합니다. 아무리 좋은 LLM을 써도, 원본 문서가 스캔한 이미지 PDF이거나 구조가 없는 텍스트 파일이면 답변 품질이 떨어집니다. 구축 전에 반드시 원본 문서의 품질을 확인하세요.

Genie — 비개발자도 데이터를 분석할 수 있게

시나리오테이블 수핵심 설정현업 주의사항
경영진 KPI 대시보드3~5개비즈니스 용어 사전 등록”매출”이 gross인지 net인지 명시
마케팅 캠페인 분석5~10개샘플 질문 20개 이상 등록날짜 필터 기본값 설정 필요
재고 현황 조회2~3개실시간 데이터 연동집계 기준(일/주/월) 명시
HR 인력 현황3~5개민감 컬럼 접근 제한PII 데이터 마스킹 필수
🔥 이것을 안 하면: Genie에 테이블만 연결하고 컬럼 설명을 안 달아두면, “이번 달 매출이 얼마야?”라는 질문에 revenue, sales_amount, total_price 중 어떤 컬럼을 써야 할지 LLM이 혼란스러워합니다. 컬럼 Comment 작성에 전체 구축 시간의 50%를 투자하세요. 이 작업이 정확도를 결정합니다.

Supervisor Agent — 멀티 에이전트의 실전 설계

현업에서 Supervisor Agent를 성공적으로 운영하려면 하위 에이전트 3~5개가 최적 입니다. 10개 이상 연결하면 라우팅 정확도가 급격히 떨어집니다.
설계 패턴에이전트 구성설명
좋은 설계(에이전트 3개, 역할 명확)주문 에이전트주문 상태 확인, 배송 추적, 주문 변경
환불 에이전트환불 정책 안내, 환불 신청 처리
일반 문의 에이전트FAQ, 매장 안내, 기타
나쁜 설계(에이전트 1개, 모든 것 처리)통합 CS 에이전트주문+환불+문의+배송+결제+회원 → Tool 30개 → 혼란

Agent Bricks vs 커스텀 에이전트

비교Agent Bricks커스텀 (ChatAgent)
개발 시간수분~수시간수일~수주
코드 필요최소 (UI 중심)Python 코드 전체 작성
유연성제한적 (정해진 패턴)무한대 (자유 구현)
Tool 확장기본 제공 Tool만 사용커스텀 Tool 무제한 추가
비즈니스 로직단순 규칙만 가능복잡한 조건부 로직 구현 가능
배포/모니터링자동 (Model Serving 연동)동일하게 Model Serving 사용
적합한 경우표준 RAG/SQL 에이전트, 빠른 PoC복잡한 비즈니스 로직, 커스텀 Tool
월 운영 비용(예시)$200~500 (서빙 + LLM)$500~2,000 (개발 인건비 포함)
권장 접근먼저 Agent Bricks로 PoC→ 부족하면 커스텀 전환Agent Bricks로 충분하지 않은 경우

커스텀으로 전환해야 하는 신호

Agent Bricks로 시작한 후, 아래 상황이 발생하면 커스텀 에이전트로 전환을 검토합니다.
신호구체적 상황전환 방향
Tool 부족외부 API 호출, 이메일 발송 등이 필요합니다ChatAgent + UC Function Tools
복잡한 분기”VIP 고객이면 A, 일반이면 B” 같은 비즈니스 로직ChatAgent + 조건부 로직
멀티 모달이미지 인식, 음성 처리가 필요합니다ChatAgent + 전용 모델 연동
성능 최적화응답 시간 2초 이내, 특정 캐싱 전략이 필요합니다ChatAgent + Redis/캐시 계층
규제 준수답변 감사 로그, 특정 필터링 규칙이 필요합니다ChatAgent + 감사 미들웨어
💡 권장 전략: 대부분의 프로젝트에서 Agent Bricks로 먼저 PoC를 진행 하는 것을 권장합니다. 빠르게 동작하는 프로토타입을 만들어 비즈니스 가치를 검증한 후, 필요한 경우에만 커스텀 에이전트로 전환하면 개발 비용과 시간을 절약할 수 있습니다. Agent Bricks로 시작해도 나중에 커스텀 코드로 마이그레이션하는 것이 어렵지 않습니다. 실제로 현업에서는 PoC의 80%가 Agent Bricks로 충분 하고, 나머지 20%만 커스텀으로 전환합니다.

Agent Bricks 운영 시 주의사항

현업에서 Agent Bricks를 운영하면서 발견한 주의사항들입니다.
주의사항상세 설명대응 방법
LLM 비용 급증인기 있는 에이전트는 하루 수천 건 호출Model Serving의 Rate Limit 설정, 사용량 모니터링
문서 업데이트 미반영Volume에 파일을 추가해도 인덱스 자동 갱신 안 됨Vector Search Index 재구축 스케줄 설정 (일 1회 권장)
응답 지연Scale to Zero 상태에서 첫 요청 시 Cold Start (30초~2분)프로덕션에서는 최소 1개 인스턴스 유지 (Provisioned Throughput)
멀티턴 대화 제한대화가 길어지면 토큰 한도 초과시스템 프롬프트에 “최근 5턴만 참고” 지시
환각(Hallucination)문서에 없는 내용을 생성시스템 프롬프트에 “문서에 없으면 모른다고 답변하라” 명시
💡 현업 팁: Agent Bricks로 만든 에이전트도 프로덕션 배포 전에 반드시 Review App으로 테스트 해야 합니다. UI에서 10번 질문해 보는 것과, 실제 사용자 50명이 2주간 테스트하는 것은 완전히 다른 수준의 검증입니다. 자세한 내용은 Review App 문서를 참고하세요.

실습: Knowledge Assistant 빠른 시작

아래는 Knowledge Assistant를 UI 없이 코드로 생성하고 테스트하는 예시입니다.
# 1. 문서 업로드 (Unity Catalog Volume에)
# 사전에 Volume에 PDF, MD, TXT 파일을 업로드해 두세요
# databricks fs cp ./docs/ /Volumes/catalog/schema/docs/

# 2. Playground에서 Knowledge Assistant 생성
# - 이름: hr-policy-assistant
# - LLM: databricks-meta-llama-3-3-70b-instruct
# - 문서 소스: /Volumes/catalog/schema/docs/
# - 시스템 프롬프트: "당신은 HR 정책 전문가입니다. 한국어로 답변하세요."

# 3. 배포 후 API 호출 테스트
import requests

endpoint_url = "https://<workspace>.databricks.com/serving-endpoints/hr-policy-assistant/invocations"
headers = {"Authorization": "Bearer <token>", "Content-Type": "application/json"}

response = requests.post(endpoint_url, headers=headers, json={
    "messages": [
        {"role": "user", "content": "연차 사용 규정을 알려주세요"}
    ]
})

print(response.json()["choices"][0]["message"]["content"])

정리

유형용도핵심 기능시작 난이도
Knowledge Assistant문서 기반 Q&ARAG + 출처 인용매우 쉬움
Genie데이터 분석자연어 → SQL쉬움 (테이블 설명 필요)
Supervisor멀티 에이전트라우팅 + 오케스트레이션보통 (하위 에이전트 설계 필요)

참고 링크