원문: Designing effective Genie Agents from a single prompt 저자: Megan Tupper 게시일: 2026년 8월 19일
요약
- Genie Agents는 신뢰할 수 있는 비즈니스 컨텍스트를 단일 프롬프트만으로 도메인 특화 AI 에이전트로 바꿔 줍니다. 정형 데이터는 물론 Unity Catalog 로 거버넌스되는 문서와 파일까지 함께 추론합니다.
- 약하거나 일관성 없는 에이전트 답변은 대부분 프롬프트가 아니라 빠진 컨텍스트 때문입니다. 신뢰할 수 있는 데이터·정의·문서에 에이전트를 기반(grounding)시키면 끊임없는 프롬프트 튜닝이 필요 없어집니다.
- 하나의 좁은 사용 사례로 시작하면 에이전트를 테스트하고 신뢰하기가 쉬워집니다. 첫 버전을 명확히 범위 짓고 벤치마킹해 두면, 이후 더 많은 지식·도구·반복 워크플로로 확장할 수 있는 믿을 만한 기반이 됩니다.
일반적인 에이전트에게 매출(revenue)을 물어보면, 재무팀이 실제로 관리하는 테이블이 아니라 눈에 처음 띄는 매출 테이블을 집어 올 가능성이 큽니다. 처음에는 프롬프트를 고쳐야겠다는 생각이 들 것입니다. 하지만 진짜 문제는 프롬프트 자체가 아니라, 요청을 해석하는 데 필요한 비즈니스 컨텍스트를 에이전트가 갖고 있지 않다는 데 있습니다. Databricks Genie Agents는 바로 이 컨텍스트 문제를 해결합니다. 정형 데이터뿐 아니라 문서와 파일까지 추론해 업무를 자동화하는, 도메인 특화 에이전트를 큐레이션할 수 있게 해 주기 때문입니다. Sales Opportunity Data 에이전트는 거버넌스된 CRM 테이블에서 파이프라인 리스크를 드러내고, Logistics Management 에이전트는 공급망 데이터 전반에서 배송을 추적하며 지연을 표시하고, Product Line Lookup 에이전트는 내부 카탈로그에서 상세한 제품 질문에 답할 수 있습니다. 예전에는 Genie Agent 를 만들려면 수동 구성이 필요했습니다. 이제는 Genie One 또는 Genie Code 를 사용해, Unity Catalog 의 컨텍스트와 사용자의 대화를 활용하여 단일 프롬프트만으로 효과적인 Genie Agent 를 띄울 수 있습니다.
간단한 프롬프트가 정확한 출발점을 만드는 방식
첫 에이전트는 단일 프롬프트에서 시작해 몇 분 만에 만들 수 있습니다. 많은 경우 프롬프트는 에이전트가 내야 할 결과를 설명하고, 관련 정보 출처를 Genie 에게 알려 주기만 하면 됩니다. 다음 예를 봅시다. “우리의 인시던트 런북(incident runbook)과 서비스 상태(service-health) 데이터를 사용해, 지원 엔지니어가 프로덕션 인시던트를 조사하도록 돕는 에이전트를 만들어 줘.” 프롬프트는 단순하지만, Genie 가 시작하기에 충분한 정보를 담고 있습니다. 해결할 문제를 특정하고, 에이전트가 사용해야 할 출처를 가리키기 때문입니다. 물론 에이전트의 품질은 그 컨텍스트의 품질에 달려 있습니다. Genie Agents 는 이미 Unity Catalog 에서 거버넌스해 둔 데이터·문서·파일을 추론하므로, 진짜 작업은 그 신뢰할 수 있는 출처들을 큐레이션하는 일입니다. 출처가 갖춰지면 Genie 가 이를 조립해 에이전트를 만들어 줍니다. IT 에이전트라면 그 컨텍스트에 FAQ, 지원 문서, 인시던트 런북, 시스템 인벤토리, 서비스 데이터 등이 포함될 수 있습니다. 데이터 에이전트라면 거버넌스된 테이블, 지표(metric) 정의, 대시보드, 데이터 품질 규칙, 내부 문서 등이 포함될 수 있습니다. 컨텍스트는 정형 데이터에만 국한되지 않습니다. Genie Agents 는 Unity Catalog 볼륨에 저장된 PDF, Word 문서, 프레젠테이션, 이미지 같은 비정형 데이터도 추론할 수 있습니다. 누군가 질문하면 에이전트는 가장 관련성 높은 파일 내용을 검색해 거버넌스된 테이블과 함께 추론해서 답을 만들어 내며, 이때 항상 질문한 사람의 권한을 사용합니다. 즉 Incident Investigation 에이전트는 실제 런북 PDF 를 활용할 수 있고, Product Line Lookup 에이전트는 실제 제품 문서에서 내용을 끌어올 수 있습니다.좁게 시작하고 확장하기
Genie Agents 는 복잡한 다단계 워크플로를 지원할 수 있지만, 가장 좋은 출발점은 대개 반복적인 분석이나 작업이 필요한, 명확히 알아볼 수 있는 좁은 문제입니다. 사용 사례가 좁으면 에이전트가 올바른 출처에 기반하고 있는지, 기대대로 동작하는지 확인하기가 쉽고, 범위 설정과 벤치마킹도 더 의미 있어집니다. 앞서 든 Incident Investigation 에이전트를 예로 들어 봅시다. 배포하기 전에, 근본 원인을 이미 알고 있는 과거 인시던트 몇 건을 대상으로 에이전트를 돌려 보세요. 그리고 올바른 결론에 도달하는지뿐 아니라, 그 결론에 이르기까지 올바른 런북과 서비스 상태 데이터를 인용하는지도 확인하세요. 만약 에이전트가 오래된 런북이나 잘못된 서비스에 의존한다면, 그것은 다시 써야 할 프롬프트가 아니라 큐레이션이 필요한 컨텍스트를 가리키는 신호입니다. Genie Agents 에는 이를 위한 벤치마크가 내장되어 있습니다. 각각 기대 답변이 딸린 테스트 질문 세트를 정의하고 실행하면, 에이전트의 정확도 점수를 얻을 수 있습니다. 변경할 때마다 이 벤치마크를 다시 돌리면, 에이전트가 “나아진 것 같다”는 막연한 느낌이 추적 가능한 측정값으로 바뀝니다. 또한 monitor 탭은 사용자가 실제로 제출한 질문과 피드백을 드러내 주므로, 확장하면서 새로 발견된 빈틈을 다시 벤치마크에 반영할 수 있습니다. 첫 사용 사례가 운영에 들어가면, 지식과 데이터 출처를 더 추가할 수 있으며 각 확장은 이미 검증된 버전 위에 쌓입니다. Sales Opportunity Data 에이전트는 파이프라인 리스크를 드러내는 데서 시작해 딜 요약을 작성하거나 세그먼트별 수주율(win rate) 질문에 답하는 데까지 자랄 수 있습니다. Logistics Management 에이전트는 지연을 표시하는 데서 시작해 우회 경로를 추천하거나 시간 경과에 따른 운송사 성과를 모니터링하는 데까지 확장될 수 있습니다. Product Line Lookup 에이전트는 카탈로그 질문에 답하는 데서 시작해 제품을 비교하거나 문서가 빠진 부분을 표시하는 데까지 나아갈 수 있습니다. 좋은 출발점으로는 제품 FAQ 질문에 답하기, 흔한 유형의 프로덕션 인시던트 조사하기, 클라우드 비용 변동 설명하기, 정해진 데이터 파이프라인 세트 모니터링하기 등이 있습니다. 사용 사례와 부서를 관통하는 공통점은, 각 에이전트가 명확히 알아볼 수 있는 하나의 업무에서 시작한다는 것입니다.진짜 자산은 컨텍스트다
단일 프롬프트 기반 에이전트 생성이 문서화나 도메인 전문성을 대체하는 것은 아닙니다. 그저 그런 투자를 사람들이 셀프서비스로 활용할 수 있는 무언가로 더 빠르게 바꿔 줄 뿐입니다. 기반이 좋을수록 에이전트도 좋아집니다. 지표 뷰(metric view), 도메인, 인증(certification) 같은 큐레이션된 Unity Catalog 시맨틱이야말로, 프롬프트가 일관되고 신뢰할 수 있는 답을 만들어 내기 위해 실제로 근거로 삼는 것입니다. 프롬프트는 과정을 시작할 뿐, 에이전트의 품질은 여전히 그 뒤에 있는 지식과 시스템에 달려 있습니다. 바로 여기서 데이터·IT 리더가 차이를 만듭니다. 거버넌스되고 잘 정의된 컨텍스트에 들인 투자가 곧바로 에이전트 품질로 돌아옵니다.첫 Genie Agent 만들기
효과적인 에이전트는 명확한 비즈니스 니즈와, 그것을 해결하는 데 필요한 신뢰할 수 있는 컨텍스트에서 시작합니다. 가장 빨리 확인하는 방법은 하나의 좁은 사용 사례로 시작하는 것입니다. 예를 들면 다음과 같습니다.- “우리의 거버넌스된 CRM 테이블을 사용해, 파이프라인 리스크를 드러내는 Sales Opportunity Data 에이전트를 만들어 줘.”
- “우리의 공급망 데이터를 사용해, 배송을 추적하고 지연을 표시하는 Logistics Management 에이전트를 만들어 줘.”
- “우리의 제품 카탈로그를 사용해, 상세한 제품 질문에 답하는 Product Line Lookup 에이전트를 만들어 줘.”