> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sifi.life/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent Bricks — 사전 구축 에이전트

> 이 문서는 **[AI 에이전트](/training/10-agent-development/overview)** 섹션의 일부입니다.

> **참고**
> 이 페이지는 Agent Bricks의 기능 개요입니다. Knowledge Assistant, Genie Agent, Supervisor Agent의 상세 구성 및 평가 가이드는 **[Databricks 소개 → Agent Bricks](/blog/guides/agent-bricks/overview)** 를 참고하세요.

## 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를 통해 코드 없이 생성할 수 있습니다. 각 단계에서 다양한 설정 옵션을 조정하여 에이전트의 동작을 맞춤화할 수 있습니다.

1. **Playground**→ **Create 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](../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](./review-app) 문서를 참고하세요.

***

## 실습: Knowledge Assistant 빠른 시작

아래는 Knowledge Assistant를 UI 없이 코드로 생성하고 테스트하는 예시입니다.

```python theme={null}
# 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\&A | RAG + 출처 인용   | 매우 쉬움              |
| **Genie**               | 데이터 분석     | 자연어 → SQL     | 쉬움 (테이블 설명 필요)     |
| **Supervisor**          | 멀티 에이전트    | 라우팅 + 오케스트레이션 | 보통 (하위 에이전트 설계 필요) |

***

## 참고 링크

* [Databricks: Agent Bricks](https://docs.databricks.com/aws/en/generative-ai/agent-bricks/)
* [Databricks: Knowledge Assistant](https://docs.databricks.com/aws/en/generative-ai/agent-bricks/knowledge-assistant.html)
* [Databricks: Supervisor Agent](https://docs.databricks.com/aws/en/generative-ai/agent-bricks/supervisor-agent.html)
* [Databricks: Genie](https://docs.databricks.com/aws/en/genie/)