실전 예제: KA + Genie + Supervisor 조합
시나리오
“고객 지원팀을 위한 AI 어시스턴트를 만들자.
- 제품 매뉴얼/FAQ는 Knowledge Assistant로 처리
- 주문/매출 데이터 조회는 Genie Space로 처리
- 두 에이전트를 Supervisor Agent로 통합”
구축 순서
제한사항
- 영어만 지원
- Supervisor당 최대 20개 서브 에이전트
- Agent Endpoints는 Knowledge Assistant만 지원
- Enhanced Security and Compliance 워크스페이스 미지원
- 에이전트 삭제 시 임시 저장 데이터도 함께 삭제
오케스트레이션 메커니즘 심층 분석
Supervisor Agent의 핵심은 “올바른 서브 에이전트에게 올바른 작업을 위임하는 것” 입니다. 이 오케스트레이션이 내부적으로 어떻게 작동하는지 이해하면, 라우팅 오류를 예방하고 복잡한 멀티 에이전트 시스템을 안정적으로 운영할 수 있습니다.오케스트레이션 루프 상세
단일 질문 vs 복합 질문 처리
| 질문 유형 | 예시 | 처리 방식 |
|---|---|---|
| 단일 도메인 | ”연차 정책 알려줘” | KA 하나에 직접 라우팅 → 응답 반환 |
| 단일 도메인 (데이터) | “이번 달 매출은?” | Genie 하나에 직접 라우팅 → SQL 실행 → 응답 반환 |
| 복합 질문 | ”VIP 고객 리스트를 뽑아서, 각 고객에게 보낼 맞춤 제안서를 작성해줘” | Genie(VIP 고객 조회) → KA(제안서 템플릿) → 종합 응답 |
| 모호한 질문 | ”우리 회사 현황 알려줘” | Supervisor가 가장 관련성 높은 에이전트를 추론하여 라우팅 |
라우팅 전략: 키워드 vs LLM 판단
Supervisor의 라우팅은 Description 기반의 LLM 추론 으로 작동합니다. 이 과정에서 키워드 매칭과 의미론적 판단이 모두 활용됩니다.Description이 라우팅에 미치는 영향
Supervisor는 라우팅 시 각 서브 에이전트의 Description 을 LLM의 컨텍스트로 제공하고, “이 질문을 어떤 에이전트에 위임해야 하는가?”를 LLM에게 판단하게 합니다. 따라서 Description의 품질이 라우팅 정확도를 직접 결정합니다. Description 작성 수준별 비교:| 수준 | Description 예시 | 라우팅 정확도 |
|---|---|---|
| 나쁨 | ”HR 관련 처리” | 50% 이하 — “HR”이 포함된 모든 질문이 여기로 라우팅 |
| 보통 | ”사내 HR 정책 문서에 대한 Q&A를 처리합니다” | 70% — 정책 질문은 잘 라우팅되나, 데이터 요청도 잘못 라우팅 |
| 좋음 | ”사내 HR 정책(연차, 복리후생, 채용, 평가) 관련 문서 기반 질문에 답변합니다. 정책 규정, 절차, 기준 등 텍스트 정보를 제공하며, 수치 데이터 조회는 처리하지 않습니다.” | 90%+ — 역할이 명확하여 데이터 질문과 정확히 구분 |
겹치는 도메인 처리 전략
서브 에이전트 간 도메인이 부분적으로 겹칠 때, 라우팅 혼란을 방지하는 전략입니다.| 문제 상황 | 해결 전략 | Description 작성 예시 |
|---|---|---|
| KA와 Genie가 동일 도메인 | ”문서 기반” vs “데이터 기반” 으로 명확히 구분 | KA: ”…텍스트 정보 제공” / Genie: ”…수치 데이터 조회” |
| 두 KA의 문서 범위가 겹침 | 담당 문서 유형을 구체적으로 나열 | KA1: “제품 A 매뉴얼” / KA2: “제품 B 매뉴얼” |
| 모호한 질문이 빈번 | Supervisor Instructions에 라우팅 규칙 명시 | ”매출, 수량 등 숫자가 포함된 질문은 반드시 Genie로 라우팅” |
Supervisor Instructions를 활용한 라우팅 제어
Supervisor의 Instructions 필드는 전체 시스템의 동작 규칙을 정의합니다. 여기에 라우팅 규칙을 명시하면 LLM 판단의 정확도를 높일 수 있습니다. 좋은 Instructions 예시:하위 Agent 간 컨텍스트 전달 방식
Supervisor Agent에서 서브 에이전트 간 데이터와 컨텍스트가 어떻게 전달되는지 이해하는 것은 복합 태스크 처리의 핵심입니다.컨텍스트 전달 모델
컨텍스트 전달 시 주의사항
| 항목 | 설명 | 대응 방법 |
|---|---|---|
| 토큰 제한 | 서브 에이전트 응답이 길면 다음 호출의 컨텍스트가 넘칠 수 있음 | Instructions에 “간결하게 응답” 지시 |
| 정보 손실 | Supervisor가 응답을 요약할 때 핵심 정보가 누락될 수 있음 | 서브 에이전트에 구조화된 출력 요청 (테이블, JSON) |
| 순서 의존성 | 2차 호출이 1차 결과에 의존하는 경우 순차 실행 필요 | Long-Running Task Mode 활용 |
| 에러 전파 | 1차 서브 에이전트가 실패하면 2차도 실패 | Instructions에 에러 시 대체 동작 정의 |
디버깅 방법
Supervisor Agent는 여러 컴포넌트가 연결되어 있어 디버깅이 복잡합니다. 체계적인 디버깅 방법을 알아봅니다.MLflow Trace를 활용한 디버깅
Supervisor Agent의 Trace는 전체 오케스트레이션 과정을 시각적으로 보여줍니다.일반적인 문제와 진단 방법
| 문제 증상 | 원인 진단 (Trace 확인 포인트) | 해결 방법 |
|---|---|---|
| 잘못된 에이전트로 라우팅 | Phase 2에서 LLM의 판단 근거 확인 | Description을 더 구체적으로 수정 |
| 서브 에이전트 응답이 빈 값 | Phase 3에서 서브 에이전트의 에러 확인 | 서브 에이전트를 단독으로 테스트 |
| ”권한 없음” 에러 | Phase 1에서 권한 확인 결과 | 사용자에게 서브 에이전트 접근 권한 부여 |
| 타임아웃 | 각 Phase의 소요 시간 확인 | Long-Running Task Mode 활성화 또는 서브 에이전트 최적화 |
| 복합 질문에 일부만 답변 | Phase 5에서 추가 호출 판단 확인 | Instructions에 복합 질문 처리 규칙 명시 |
| 응답 언어가 일관되지 않음 | Phase 4에서 종합 프롬프트 확인 | Instructions에 “반드시 한국어로 응답” 명시 |
단계별 디버깅 체크리스트
Supervisor Agent 아키텍처 패턴
실제 프로덕션 환경에서 자주 사용되는 Supervisor 아키텍처 패턴을 정리합니다.패턴 1: 문서 + 데이터 통합
가장 기본적이고 흔한 패턴입니다.패턴 2: 도메인별 전문 에이전트
여러 전문 도메인을 하나의 인터페이스로 통합합니다.패턴 3: 외부 시스템 연동
MCP Servers와 UC Functions를 활용하여 외부 시스템과 연동합니다.패턴 4: 계층적 Supervisor (Nested)
복잡한 조직 구조에 맞춰 Supervisor를 계층적으로 구성합니다.주의 계층적 Supervisor 주의사항: 현재 Agent Bricks의 Supervisor는 다른 Supervisor를 직접 서브 에이전트로 등록할 수 없습니다. 이 패턴을 구현하려면 하위 Supervisor를 Agent Framework(코드 기반) 으로 구축하고, Model Serving Endpoint로 배포한 후 연결해야 합니다. 다만 Agent Endpoints는 KA만 지원하므로, 이 패턴은 현재 UC Function 또는 MCP 를 통한 간접 연결로만 가능합니다.