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 Assistant | FAQ 답변, 매뉴얼 검색, 규정 조회 |
| 데이터를 분석하고 싶다 | Genie (SQL Agent) | 매출 조회, KPI 확인, 트렌드 분석 |
| 업무를 자동화하고 싶다 | Custom Agent (ChatAgent) | 주문 처리, 환불 신청, 보고서 생성 |
| 코드를 작성/리뷰하고 싶다 | Coding Assistant | 코드 생성, 디버깅, PR 리뷰 |
Knowledge Assistant
개념
Knowledge Assistant는 문서(PDF, 웹 페이지, 사내 위키 등)를 기반으로 질문에 답변하는 RAG(Retrieval-Augmented Generation) 챗봇 입니다. 내부적으로 Vector Search를 사용하여 관련 문서를 검색하고, LLM이 검색된 문서를 바탕으로 답변을 생성합니다. 답변 시 출처 문서를 인용 하여 신뢰성을 높이며, 사용자가 원본 문서를 직접 확인할 수 있는 링크도 제공합니다.| 단계 | 구성 요소 | 설명 |
|---|---|---|
| 1 | 사용자 질문 | 사용자가 질문을 입력합니다 |
| 2 | Knowledge Assistant | 질문을 받아 Vector Search로 문서를 검색합니다 |
| 3 | Vector Search | 관련 문서를 검색하여 Assistant에 반환합니다 |
| 4 | 최종 응답 | 답변 + 출처 인용을 사용자에게 제공합니다 |
생성 방법
Knowledge Assistant는 UI를 통해 코드 없이 생성할 수 있습니다. 각 단계에서 다양한 설정 옵션을 조정하여 에이전트의 동작을 맞춤화할 수 있습니다.- Playground→ Create Knowledge Assistant
- 이름 입력: 에이전트의 이름을 지정합니다 (예:
hr-policy-assistant) - LLM 선택: 사용할 LLM을 선택합니다 (예: Llama 3.3 70B, GPT-4o 등). 응답 품질, 속도, 비용을 고려하여 선택합니다
- 문서 소스 연결: Unity Catalog Volume 또는 Vector Search Index를 지정합니다. Volume을 선택하면 자동으로 인덱싱이 수행됩니다
- 시스템 프롬프트 작성(선택): “당신은 XX 분야 전문가입니다. 한국어로 답변하세요.” 등의 지침을 입력합니다
- 검색 설정: 검색할 문서 수, 유사도 임계값 등을 조정합니다
- 테스트: Playground에서 바로 질문하여 답변 품질을 확인합니다
- 배포: 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 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는 다음 단계로 동작합니다. 각 단계가 자동으로 수행되므로 사용자는 하위 에이전트의 존재를 알 필요가 없습니다.- 요청 분석: 사용자가 요청을 입력하면, Supervisor가 LLM을 사용하여 요청의 의도를 분석합니다
- 에이전트 선택: 분석 결과를 바탕으로 적절한 하위 에이전트를 선택합니다. 하나 또는 여러 에이전트를 선택할 수 있습니다
- 작업 위임: 선택된 하위 에이전트에게 질문을 전달하고, 각 에이전트가 독립적으로 작업을 수행합니다
- 결과 종합: 모든 하위 에이전트의 결과를 Supervisor가 수집하고, 하나의 통합된 답변으로 종합합니다
- 순차 호출: 필요한 경우 한 에이전트의 결과를 바탕으로 다른 에이전트를 추가로 호출 할 수도 있습니다
Supervisor Agent 구성
Supervisor Agent를 생성할 때는 하위 에이전트의 목록과 각 에이전트의 역할을 정의합니다.| 설정 항목 | 설명 |
|---|---|
| 하위 에이전트 목록 | 등록할 에이전트를 선택합니다. Knowledge Assistant, Genie, 커스텀 에이전트를 혼합할 수 있습니다 |
| 에이전트 설명 | 각 하위 에이전트의 역할을 상세히 기술합니다. Supervisor가 라우팅 결정 시 이 설명을 참고합니다 |
| Supervisor 프롬프트 | Supervisor의 전반적인 행동 지침을 정의합니다 |
| LLM 모델 | Supervisor가 라우팅 결정에 사용할 LLM을 선택합니다 |
활용 시나리오 상세
MAS(Multi-Agent System) 설계 모범 사례
| 원칙 | 설명 |
|---|---|
| 단일 책임 원칙 | 각 하위 에이전트는 하나의 전문 영역만 담당하도록 설계합니다. 범위가 넓으면 분할합니다 |
| 명확한 역할 기술 | 하위 에이전트의 설명을 구체적으로 작성합니다. “주문 관련”보다 “주문 상태 확인, 배송 추적, 주문 변경 처리”가 좋습니다 |
| 중복 방지 | 두 에이전트의 역할이 겹치면 Supervisor가 혼란스러워집니다. 역할 경계를 명확히 합니다 |
| 점진적 확장 | 처음에는 2~3개 에이전트로 시작하고, 필요에 따라 하위 에이전트를 추가합니다 |
현업 사례: Knowledge Assistant를 30분 만에 구축한 경험
🔥 실전 경험담 한 제조업 고객사에서 “사내 품질 관리 매뉴얼을 AI로 검색하고 싶다”는 요구사항을 받았습니다. 기존에는 500페이지 분량의 PDF를 사원들이 직접 검색하고 있었고, 평균 답변 찾기까지 15~20분이 걸렸습니다. 고객 미팅 시간이 1시간밖에 없었기 때문에, 미팅 도중에 라이브로 Knowledge Assistant를 구축 하기로 했습니다. 과정은 다음과 같았습니다:고객의 반응은 “이게 진짜 30분 만에 된 거예요?”였습니다. 이 데모 하나로 Databricks 도입이 결정 되었고, 이후 커스텀 에이전트로 확장하여 ERP 시스템과 연동하는 프로젝트로 발전했습니다.
- 5분: PDF 5개를 UC Volume에 업로드
- 10분: Playground에서 Knowledge Assistant 생성, LLM 선택(Llama 3.3 70B), 시스템 프롬프트 작성
- 5분: Vector Search 인덱싱 대기 (문서 분량이 적어 빠르게 완료)
- 10분: 고객이 직접 질문하며 테스트 (“FMEA 절차가 뭐야?”, “불량률 기준이 어떻게 돼?”)
각 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 없이 코드로 생성하고 테스트하는 예시입니다.정리
| 유형 | 용도 | 핵심 기능 | 시작 난이도 |
|---|---|---|---|
| Knowledge Assistant | 문서 기반 Q&A | RAG + 출처 인용 | 매우 쉬움 |
| Genie | 데이터 분석 | 자연어 → SQL | 쉬움 (테이블 설명 필요) |
| Supervisor | 멀티 에이전트 | 라우팅 + 오케스트레이션 | 보통 (하위 에이전트 설계 필요) |