고객 데이터는 AWS에 있습니다. 매출 정보는 SaaS 애플리케이션에 저장돼 있고, 주문·재고·장애 이력 같은 운영 기록은 온프레미스 시스템에 남아 있습니다. 이런 환경에서 AI agent가 “이번 분기 순매출이 왜 감소했는가?”라는 질문에 정확히 답하려면 어떻게 해야 할까요?
기존 방식이라면 데이터를 중앙 Cloud 데이터웨어하우스로 복사하는 작업부터 시작해야 했습니다. ETL 파이프라인을 만들고, 스키마를 맞추고, 데이터 품질을 점검한 뒤에야 AI가 분석할 수 있었습니다. 하지만 이 과정은 비용과 시간이 들고, 복제본이 원본보다 늦게 갱신되면서 운영 현황과 분석 결과가 어긋나는 문제도 만들었습니다.
Google Cloud가 2026년 11월 4일 공개한 Agentic Data Cloud는 이 순서를 바꿉니다. 핵심은 데이터를 한곳으로 강제로 옮기는 대신, AI agent가 데이터가 존재하는 위치에서 안전하게 조회하고 추론하도록 만드는 것입니다.
기존 방식
AWS · Azure · SaaS · 온프레미스
↓
복제 · ETL · 중앙 저장소
↓
AI 분석 및 agent
Agentic Data Cloud 방식
AWS · Azure · SaaS · 온프레미스
↓
사설 연결 · 연합 조회 · 캐싱
↓
비즈니스 컨텍스트와 권한 관리
↓
AI agent의 조회 · 추론 · 실행
이 구조에서 중요한 역할을 하는 것이 Cross-cloud Interconnect and Caching입니다. AWS나 Azure에 있는 데이터를 사설 연결로 조회하고, 필요한 데이터 블록은 Google Cloud에 캐시할 수 있습니다. 모든 데이터를 미리 복제하지 않아도 되므로 대규모 데이터 이동, 동기화 지연, 반복적인 ETL 운영 부담을 줄일 수 있습니다.
다만 “데이터를 옮기지 않는다”는 말이 데이터 이동 비용이 완전히 사라진다는 뜻은 아닙니다. 네트워크 연결, 캐시 저장소, 쿼리 처리, AI 모델 추론과 도구 호출에는 여전히 비용이 발생합니다. 따라서 기업은 단순히 egress 비용만 볼 것이 아니라, 전체 Cloud 운영 비용과 응답 지연을 함께 측정해야 합니다.
이 접근의 더 큰 가치는 단순한 연결성에 있지 않습니다. 서로 다른 시스템의 데이터를 AI가 찾을 수 있게 하는 것만으로는 충분하지 않습니다. agent는 “매출”이 무엇인지, 어떤 데이터가 공식 수치인지, 현재 사용자가 해당 고객 정보를 볼 권한이 있는지까지 이해해야 합니다.
예를 들어 영업 책임자가 다음과 같이 질문한다고 가정해 보겠습니다.
“이번 분기 순매출이 감소한 주요 원인과 영향을 받은 고객군을 알려줘.”
정확한 답변을 위해 agent는 여러 곳의 정보를 함께 확인해야 합니다.
- SaaS CRM의 고객군과 계약 정보
- AWS 데이터 레이크의 과거 매출·환불 이력
- 온프레미스 ERP의 주문·재고·출고 상태
- 기업이 승인한 ‘순매출’ 계산 기준
- 질문자의 데이터 접근 권한
Agentic Data Cloud는 이러한 데이터를 단순히 모으는 것이 아니라, 데이터 위치·의미·권한·업무 규칙을 함께 연결하는 Cloud 데이터 운영 계층을 지향합니다. 그 결과 AI agent는 임의의 테이블을 찾아 계산하는 대신, 기업이 정의한 공식 지표와 승인된 데이터 소스를 바탕으로 답변할 수 있습니다.
결국 기업용 AI의 핵심 질문은 “어떤 모델이 더 똑똑한가?”에서 “AI가 어떤 데이터와 규칙을 신뢰할 수 있는가?”로 이동하고 있습니다. Google의 Agentic Data Cloud는 멀티클라우드 현실을 전제로, 데이터를 중앙에 모으기보다 신뢰할 수 있는 컨텍스트를 중앙에 구축하려는 전략입니다.
Cloud Agent의 진짜 난제는 데이터가 아니라 ‘무슨 뜻인지’다
AI agent가 “이번 분기 순매출을 알려줘”라는 질문에 답했다고 가정해 보겠습니다. 숫자는 그럴듯합니다. 하지만 재무팀의 공식 보고서와 다르다면, 문제는 모델이 충분히 똑똑하지 않아서일까요?
대개는 아닙니다. 더 근본적인 문제는 ‘순매출’이라는 단어가 회사에서 정확히 무엇을 의미하는지 agent가 알지 못한다는 데 있습니다.
어떤 조직에서는 순매출을 총매출 - 환불로 계산합니다. 다른 조직에서는 여기에 할인, 판매 수수료, 세금, 취소 주문, 특정 회계 기준까지 반영합니다. 같은 단어라도 부서·국가·시스템마다 정의가 달라질 수 있습니다. 데이터가 Cloud 곳곳에 충분히 있어도, 그 의미와 규칙이 정리되어 있지 않다면 AI는 공식 숫자가 아닌 “그럴듯한 숫자”를 만들 위험이 있습니다.
이 문제를 해결하기 위해 Google Cloud가 이번 Agentic Data Cloud 업데이트에서 가장 중요하게 내세운 축이 Knowledge Catalog입니다.
데이터 카탈로그를 넘어, 업무 맥락을 제공하는 계층
기존 데이터 카탈로그는 주로 다음과 같은 질문에 답합니다.
- 어떤 테이블이 어디에 있는가?
- 컬럼 이름과 데이터 형식은 무엇인가?
- 누가 데이터를 소유하고 있는가?
- 마지막 업데이트는 언제였는가?
이는 사람과 분석가에게 유용합니다. 하지만 agent가 실제 비즈니스 질문에 신뢰할 수 있게 답하려면 더 많은 정보가 필요합니다.
Knowledge Catalog는 데이터의 위치와 스키마뿐 아니라, 기업이 사용하는 공식 용어·지표·업무 규칙·권한·문서 기반 지식을 함께 연결하는 것을 목표로 합니다.
| agent가 알아야 하는 정보 | 예시 |
|---|---|
| 공식 지표 정의 | 순매출은 총매출에서 환불·할인·취소 주문을 제외한 값 |
| 신뢰 가능한 데이터 소스 | 재무 확정 매출은 CRM이 아니라 회계 시스템의 월 마감 테이블 사용 |
| 데이터 관계 | 주문 테이블은 고객 ID와 주문 완료 일자를 기준으로 고객 테이블과 조인 |
| 업무 규칙 | 분기 매출은 결제 승인일이 아니라 회계 인식일 기준으로 집계 |
| 접근 권한 | 영업 담당자는 자신의 담당 계정만 조회 가능 |
| 비정형 근거 | 최신 환불 정책은 Confluence의 승인된 정책 문서 우선 적용 |
즉, Knowledge Catalog는 단순한 메타데이터 저장소가 아닙니다. Cloud 환경에 흩어진 데이터와 문서를 기업이 인정한 비즈니스 의미로 묶어, AI agent가 그 의미를 따라 질문하고 답하도록 만드는 컨텍스트 계층입니다.
“정답 같은 오답”을 줄이는 방식
예를 들어 영업 리더가 다음과 같이 묻는 상황을 생각해 볼 수 있습니다.
“이번 분기 순매출이 목표 대비 얼마나 부족한가?”
맥락이 없는 agent는 여러 시스템을 검색한 뒤, 매출 테이블에서 환불 금액을 빼는 SQL을 생성할 수 있습니다. 그러나 이 계산에는 중요한 오류가 숨어 있을 수 있습니다.
- 취소 주문이 이미 매출에서 제외됐는지 모른다.
- 환율 적용 기준일을 알지 못한다.
- 회계 마감 전 임시 데이터와 확정 데이터를 구분하지 못한다.
- 특정 파트너 채널의 매출 인식 규칙을 놓친다.
- 목표 수치가 조직 전체 기준인지, 담당 영업 조직 기준인지 판단하지 못한다.
Knowledge Catalog가 잘 구축돼 있다면 agent는 승인된 시맨틱 모델과 공식 지표 정의를 참조할 수 있습니다. 또한 사용자의 권한 범위 안에서만 데이터를 조회하고, 필요한 경우 “현재 수치는 잠정치이며, 회계 마감 후 확정될 수 있다”는 조건까지 답변에 반영할 수 있습니다.
이 과정에서 중요한 것은 모델이 임의로 의미를 추론하지 않도록 하는 것입니다. 기업 환경에서 신뢰할 수 있는 agent란 창의적으로 계산하는 agent가 아니라, 공식 정의와 검증된 근거를 재사용하는 agent에 가깝습니다.
시맨틱 모델이 AI의 공통 언어가 되는 이유
Google Cloud는 Looker, BigQuery뿐 아니라 Databricks, Snowflake, dbt, SAP 등 여러 플랫폼의 시맨틱 모델과 컨텍스트를 활용하는 방향을 제시했습니다.
시맨틱 모델은 기술적인 테이블 구조를 비즈니스가 이해할 수 있는 언어로 변환합니다. 예를 들어 데이터베이스에는 ord_hdr, txn_amt, cust_dim 같은 테이블과 컬럼이 있을 수 있습니다. 하지만 현업은 “주문”, “순매출”, “활성 고객”이라는 언어로 질문합니다.
이 간극을 메우는 것이 시맨틱 계층입니다.
현업 질문
“이번 분기 활성 고객당 순매출은?”
↓
공식 비즈니스 정의
활성 고객 = 최근 90일 내 구매 완료 고객
순매출 = 총매출 - 환불 - 할인 - 취소분
↓
승인된 데이터 관계와 권한 규칙
↓
Cloud·온프레미스·SaaS 데이터에 대한 안전한 쿼리
이 구조가 없다면 agent마다 다른 프롬프트, 다른 검색 결과, 다른 SQL 생성 방식으로 인해 동일한 질문에 서로 다른 답을 낼 수 있습니다. 반대로 공통 시맨틱 모델이 있으면 분석 대시보드, 보고서, AI agent가 같은 정의를 공유할 가능성이 높아집니다.
자동 보강은 유용하지만, 사람이 최종 승인해야 한다
Knowledge Catalog의 self-learning enrichment는 사용자 질문, agent 상호작용, Google Workspace, GitHub, Jira, Confluence, SharePoint 등의 자료를 분석해 부족한 컨텍스트를 찾아 보강하는 기능입니다.
가령 고객지원 agent가 반복적으로 “프리미엄 고객의 긴급 환불 기준”을 묻는다면, 시스템은 관련 정책 문서나 티켓 기록을 찾아 해당 업무 맥락을 연결하려 할 수 있습니다. 이는 모든 규칙을 데이터 엔지니어가 수동으로 태깅해야 하는 부담을 줄여 줍니다.
하지만 자동으로 발견한 지식이 항상 옳은 것은 아닙니다. 오래된 정책 문서, 예외적인 티켓 처리 사례, 개인 의견이 담긴 문서가 공식 규칙처럼 사용될 수 있기 때문입니다.
따라서 중요한 운영 원칙은 명확합니다.
- 자동 생성된 컨텍스트는 제안으로 취급한다.
- 업무 담당자가 공식성·최신성·적용 범위를 검토한다.
- 승인된 컨텍스트는 버전 관리한다.
- 오류가 발견되면 이전 버전으로 되돌릴 수 있어야 한다.
- agent 답변에 적용된 데이터와 규칙을 추적할 수 있어야 한다.
AI agent의 품질은 모델 선택만으로 결정되지 않습니다. 어떤 데이터를 읽었는지, 어떤 정의를 적용했는지, 누가 그 정의를 승인했는지를 설명할 수 있어야 합니다.
결국 Agentic Data Cloud가 겨냥하는 핵심은 데이터 이동 자체가 아닙니다. AWS, Azure, SaaS, 온프레미스에 데이터가 남아 있더라도, 그 데이터가 같은 비즈니스 언어와 권한 체계 아래 이해되도록 만드는 것입니다.
기업용 AI에서 가장 어려운 질문은 “무엇을 알고 있는가?”가 아닙니다.
더 어려운 질문은 이것입니다.
“그 데이터가 우리 회사에서 정확히 무엇을 뜻하는가?”
정확도 4배, 토큰 75% 감소—Cloud 벤치마크 숫자 뒤에 숨은 조건
Google은 Knowledge Catalog를 활용한 AI agent가 자체 벤치마크에서 정확도는 거의 4배, 지연 시간은 최대 33% 감소, 토큰 사용량은 최대 75% 감소했다고 발표했습니다. 숫자만 보면 멀티클라우드 환경의 데이터 문제를 단숨에 해결할 수 있을 듯합니다.
하지만 기업이 이 결과를 곧바로 비용 절감이나 운영 성과로 해석해서는 안 됩니다. 이 수치는 Google이 수행한 자체 평가 결과이며, 실제 Cloud 환경의 데이터 품질, 권한 구조, 질문 유형, 네트워크 조건에 따라 결과는 크게 달라질 수 있습니다.
왜 Knowledge Catalog가 정확도를 높일 수 있을까
일반적인 agent는 사용자의 질문을 받은 뒤 관련 테이블, 문서, API를 찾아 답을 구성합니다. 이 과정에서 “매출”, “활성 고객”, “환불 완료”처럼 기업마다 정의가 다른 용어를 잘못 해석하기 쉽습니다.
Knowledge Catalog는 단순한 메타데이터 목록이 아니라 다음과 같은 컨텍스트를 agent에 제공합니다.
- 공식 KPI와 비즈니스 용어 정의
- 테이블 간 조인 관계와 신뢰 가능한 데이터 소스
- 문서, 티켓, 업무 매뉴얼 등 비정형 지식
- 사용자별 데이터 접근 권한
- 승인된 업무 규칙과 시맨틱 모델
예를 들어 “이번 분기 순매출”을 묻는 질문에 agent가 임의로 매출 - 환불을 계산하는 대신, 기업이 승인한 순매출 정의와 공식 데이터 모델을 사용할 수 있습니다. 정확도 향상의 핵심은 모델이 갑자기 더 똑똑해졌기 때문이 아니라, 모델이 참고하는 업무 문맥이 더 정확해졌기 때문입니다.
토큰 75% 감소가 의미하는 것
토큰 사용량 감소 역시 중요한 지표입니다. agent가 방대한 문서와 데이터 스키마를 매번 프롬프트에 넣지 않고, Knowledge Catalog에서 필요한 정의·관계·정책만 찾아 활용한다면 LLM 입력량을 줄일 수 있습니다.
이는 다음과 같은 효과로 이어질 수 있습니다.
- LLM 입력·출력 비용 감소
- 응답 생성 시간 단축
- 불필요한 재질문과 도구 호출 감소
- 더 작은 모델 또는 더 적은 추론 횟수로 업무 처리
- 반복 보고 업무의 운영 비용 절감
특히 매일 반복되는 매출 현황, 재고 부족, 주문 상태, 고객 이력 조회에는 모든 질문을 생성형 AI로 새롭게 추론하는 방식보다 검증된 쿼리와 보고서를 재사용하는 편이 효율적입니다.
다만 토큰 비용이 전체 비용의 전부는 아닙니다. 실제 Cloud 운영 비용에는 원격 데이터 조회, 캐시 저장, 네트워크 연결, 쿼리 처리, 벡터 검색, 재시도, 모델 호출이 함께 포함됩니다.
실제 agent 운영 비용
= 네트워크·연결 비용
+ 원격 데이터 조회·캐시 비용
+ BigQuery·데이터베이스 쿼리 비용
+ 검색·임베딩 비용
+ LLM 토큰 비용
+ agent 재시도·도구 호출 비용
토큰이 75% 줄어도 쿼리 횟수나 원격 데이터 스캔량이 증가하면 전체 비용은 기대만큼 낮아지지 않을 수 있습니다.
“최대 33% 지연 감소”를 그대로 믿기 어려운 이유
지연 시간은 단순히 모델 응답 속도로 결정되지 않습니다. 멀티클라우드 환경에서는 특히 다음 요소가 중요합니다.
- AWS·Azure·온프레미스 데이터 원본까지의 네트워크 거리
- 원격 데이터의 캐시 적중률
- 쿼리 복잡도와 스캔 데이터량
- 권한 검사와 정책 적용 시간
- 동시 사용자 및 agent 수
- LLM 호출 횟수와 외부 도구 응답 시간
Cross-cloud Interconnect와 캐싱은 원격 데이터 접근의 부담을 낮추는 데 도움이 될 수 있습니다. 그러나 캐시에 데이터가 없는 첫 요청, 대규모 조인, 자주 변경되는 운영 데이터, 복잡한 권한 검사는 여전히 지연을 만들 수 있습니다.
따라서 “최대 33% 감소”는 가능한 최고 조건의 결과로 이해하는 편이 안전합니다. 기업은 평균 응답 시간뿐 아니라 P95·P99 지연 시간, 즉 느린 요청이 얼마나 오래 걸리는지도 함께 측정해야 합니다.
벤치마크보다 중요한 것은 자사 질문 세트다
Google의 수치는 기술 가능성을 보여주는 신호로는 의미가 있습니다. 그러나 도입 판단의 근거는 자체 벤치마크가 아니라 기업 내부의 실제 업무 질문이어야 합니다.
파일럿 단계에서는 최소한 다음 항목을 검증하는 것이 좋습니다.
| 검증 항목 | 확인할 질문 |
|---|---|
| 정확성 | 공식 KPI와 실제 보고서 값이 일치하는가? |
| 최신성 | 오래된 문서보다 최신 정책과 데이터가 우선 적용되는가? |
| 권한 | 행·열 수준 권한과 문서 접근 권한이 일관되게 적용되는가? |
| 비용 | 질문 1건당 네트워크·쿼리·캐시·모델 비용은 얼마인가? |
| 성능 | 평균뿐 아니라 P95, P99 응답 시간이 허용 범위인가? |
| 감사성 | agent가 어떤 데이터와 규칙을 근거로 답했는지 추적 가능한가? |
가장 현실적인 시작점은 고객 지원용 환불 실행이나 계약 변경처럼 위험한 자동화가 아닙니다. 먼저 표준 KPI 조회, 주문 상태 확인, 재고 현황, 장애 티켓 요약처럼 읽기 전용 업무에서 정확도와 비용을 비교하는 것이 바람직합니다.
결국 Knowledge Catalog의 가치는 “정확도 4배”라는 숫자 자체에 있지 않습니다. 기업의 데이터 정의, 권한, 문서, 업무 규칙을 하나의 컨텍스트 계층으로 정리해 agent가 일관된 답을 내도록 만드는 데 있습니다. Cloud 환경에서 이 기반이 제대로 구축될 때만, 토큰 절감과 응답 속도 개선이 실제 운영 성과로 이어질 수 있습니다.
Cloud에서 실시간 운영 데이터와 과거 기록을 한 질문에 묶다
고객지원 agent가 “이 고객의 환불 요청을 승인할 수 있나요?”라는 질문을 받았다고 가정해 보겠습니다. 정확한 판단을 위해서는 단순히 오늘의 주문 상태만 확인해서는 부족합니다.
- 주문이 실제로 배송되었는가
- 결제와 환불 상태는 무엇인가
- 고객이 최근에 반복 반품을 했는가
- 과거 구매 이력과 VIP 정책은 어떤가
- 같은 상품에서 품질 이슈가 반복됐는가
- 현재 적용되는 환불 정책은 무엇인가
문제는 이런 정보가 보통 한곳에 있지 않다는 점입니다. 주문·결제·재고 같은 실시간 운영 데이터는 PostgreSQL 계열 데이터베이스에 있고, 수년간의 구매·반품 이력은 데이터 레이크나 Apache Iceberg 테이블에 저장되는 경우가 많습니다.
Google Cloud가 발표한 AlloyDB의 Iceberg 직접 조회 기능은 이 간극을 줄이려는 시도입니다. ETL 파이프라인으로 데이터를 별도 복제하거나, 분석용 데이터를 운영 데이터베이스로 다시 적재하지 않아도 운영 데이터와 Iceberg 기반 과거 데이터를 하나의 쿼리에서 결합할 수 있습니다.
실시간 주문·결제·재고 데이터
+
데이터 레이크의 구매·반품·행동 이력
+
Knowledge Catalog의 정책·지표 정의
↓
고객지원 또는 운영 AI agent의 판단 근거
예를 들어 agent는 현재 주문의 배송 상태를 확인하면서, 동시에 최근 12개월의 반품 횟수와 동일 상품의 품질 이슈 통계를 조회할 수 있습니다. 여기에 Knowledge Catalog가 승인된 환불 정책과 고객 등급 정의를 제공하면, agent는 임의의 기준이 아니라 기업이 정한 규칙을 바탕으로 답변할 가능성이 높아집니다.
단순 조회를 넘어서는 활용 범위
이 구조는 고객지원 외에도 다양한 업무에 적용할 수 있습니다.
| 업무 영역 | 실시간 운영 데이터 | 과거 분석 데이터 | agent가 할 수 있는 일 |
|---|---|---|---|
| 고객지원 | 주문, 배송, 결제 상태 | 구매·반품·문의 이력 | 환불 가능 여부 안내, 대응 우선순위 추천 |
| 공급망 | 현재 재고, 입고 예정, 주문량 | 계절별 수요, 납기 지연 기록 | 재고 부족 위험 탐지, 발주 제안 |
| 금융 리스크 | 현재 거래, 계좌 상태 | 이상 거래 패턴, 과거 손실 사례 | 거래 검토 우선순위 결정 |
| 영업 | 최신 계약, 고객 활동 | 과거 구매, 이탈 패턴 | 갱신 위험 고객 식별, 다음 제안 추천 |
핵심은 agent가 “현재 무슨 일이 일어나고 있는가”와 “과거에 어떤 패턴이 있었는가”를 분리하지 않고 이해할 수 있다는 점입니다. 기존에는 운영팀과 분석팀이 서로 다른 데이터 환경을 사용하면서, 최신 상태와 분석 결과 사이에 시간차가 생기기 쉬웠습니다.
데이터 결합이 곧 자동 실행을 의미하지는 않는다
다만 더 많은 데이터를 한 번에 조회할 수 있다고 해서 agent에게 즉시 환불 승인이나 주문 변경 권한을 주어야 하는 것은 아닙니다. 데이터 조회와 업무 실행은 다른 수준의 위험을 갖습니다.
환불을 추천하는 agent는 비교적 낮은 위험의 보조 도구가 될 수 있습니다. 반면 실제 환불을 실행하려면 정책 검증, 권한 확인, 금액 한도, 중복 처리 방지, 실패 시 복구 절차가 필요합니다.
따라서 현실적인 도입 순서는 다음과 같습니다.
- 먼저 주문·고객·이력 데이터를 연결해 조회형 agent를 운영합니다.
- 답변의 정확성, 권한 적용, 지연 시간, 비용을 검증합니다.
- 이후 낮은 위험의 업무부터 사람 승인 기반으로 실행 기능을 추가합니다.
- 고액 환불, 계약 변경, 결제 처리처럼 민감한 작업은 별도 승인과 감사 체계를 유지합니다.
결국 Cloud 환경에서 운영 데이터와 과거 기록을 결합하는 기술의 가치는 단순히 쿼리를 편하게 만드는 데 있지 않습니다. agent가 현재 상황을 읽고, 과거 맥락을 비교하며, 기업의 공식 규칙 안에서 더 신뢰할 수 있는 판단을 내리도록 만드는 기반이라는 데 있습니다.
자율 실행의 문턱에서: Cloud Agent는 먼저 읽게 하고, 나중에 맡겨라
고객 이력을 읽고 “환불이 적절해 보입니다”라고 추천하는 agent와, 실제로 환불을 실행하고 실패한 결제를 복구하는 agent는 전혀 다릅니다.
전자는 정보를 조회하고 요약하는 역할에 가깝습니다. 반면 후자는 고객 계정, 결제 시스템, 재고, 회계 기록을 변경하는 업무 실행 주체가 됩니다. 이 차이를 무시하면 Cloud 기반 AI 도입은 편리한 자동화가 아니라, 통제되지 않는 운영 위험으로 바뀔 수 있습니다.
Agentic Data Cloud의 가치는 단순히 여러 데이터 소스를 연결하는 데 있지 않습니다. 핵심은 agent가 기업 데이터를 읽고, 판단하고, 행동하는 전 과정에서 권한·감사·비용·책임을 통제할 수 있는가에 있습니다.
읽기 권한과 실행 권한은 분리해야 한다
초기 도입 단계에서 agent는 가능한 한 읽기 전용(read-only) 으로 운영하는 것이 안전합니다. 예를 들어 다음과 같은 업무는 비교적 낮은 위험으로 시작할 수 있습니다.
- 고객의 주문·배송·문의 이력 요약
- 이번 분기 매출과 순매출 현황 조회
- 재고 부족 품목과 납기 지연 원인 분석
- 장애 티켓, Jira 이슈, 운영 문서 요약
- 계약서·정책 문서에서 관련 조항 검색
이 단계에서 Knowledge Catalog는 중요한 역할을 합니다. agent가 단순히 데이터베이스를 검색하는 것이 아니라, 승인된 지표 정의와 문서 우선순위, 사용자 권한을 함께 적용하도록 돕기 때문입니다.
예를 들어 “VIP 고객의 환불 현황을 보여 달라”는 요청은 단순 SQL 생성 문제가 아닙니다. agent는 다음을 구분해야 합니다.
- VIP 고객의 공식 정의는 무엇인가
- 환불 완료, 환불 요청, 환불 실패를 어떻게 구분하는가
- 사용자가 결제 정보와 고객 식별 정보를 볼 권한이 있는가
- 최신 환불 정책은 어느 문서에 있는가
- 개인정보를 결과에 어느 수준까지 노출할 수 있는가
이런 기반 없이 실행 권한부터 부여하면, agent는 빠르게 행동할 수는 있어도 기업의 규칙에 맞게 행동한다는 보장은 없습니다.
실행형 Cloud Agent에는 ‘행동 전 검증’이 필요하다
실행형 agent는 티켓 상태 변경, 할인 적용, 주문 수정, 환불 요청, 계정 잠금 해제처럼 실제 시스템 상태를 바꿉니다. 따라서 자연어 요청을 바로 API 호출로 연결해서는 안 됩니다.
안전한 실행 구조는 다음과 같이 설계하는 편이 바람직합니다.
사용자 요청
↓
의도 분석 및 정책 확인
↓
권한 검증·위험도 분류
↓
실행 계획 생성
↓
사람 승인 또는 자동 승인 규칙 적용
↓
업무 시스템 API 실행
↓
결과 검증·감사 로그 기록·실패 복구
특히 고위험 업무는 human-in-the-loop, 즉 사람의 최종 승인을 기본값으로 두어야 합니다. 예를 들어 agent가 환불 후보를 찾고 금액을 계산할 수는 있지만, 실제 환불 버튼을 누르기 전에는 담당자가 고객 정보, 정책 예외, 금액, 사유를 검토하도록 설계할 수 있습니다.
자동 실행은 다음처럼 위험도가 낮고 규칙이 명확한 업무부터 제한적으로 확대하는 것이 좋습니다.
| 업무 유형 | 권장 자동화 수준 |
|---|---|
| 주문·재고·KPI 조회 | 자동 응답 가능 |
| 티켓 분류 및 담당자 배정 | 규칙 기반 자동화 가능 |
| 고객 응답 초안 작성 | 사람 검토 후 발송 |
| 할인·환불 추천 | 사람 승인 필수 |
| 환불 실행·계약 변경·계정 권한 부여 | 엄격한 승인 및 정책 검증 필요 |
실패를 처리하지 못하면 자율 실행이 아니다
업무 실행에서 진짜 난제는 “성공적으로 호출하는 것”이 아니라 실패했을 때 일관성을 회복하는 것입니다.
가령 agent가 고객 환불을 처리하는 과정에서 다음과 같은 상황이 발생할 수 있습니다.
- 결제 게이트웨이에는 환불 요청이 접수됐다.
- 그러나 주문 관리 시스템의 상태 업데이트가 실패했다.
- 고객에게는 환불 완료 알림이 발송됐다.
- 회계 시스템에는 환불 전표가 아직 생성되지 않았다.
이 경우 agent는 단순히 오류 메시지를 남기는 데 그쳐서는 안 됩니다. 어떤 작업이 성공했고, 어떤 작업이 실패했는지 추적해야 하며, 필요하면 이전 상태를 되돌리거나 담당자에게 즉시 이관해야 합니다.
따라서 실행형 agent에는 다음 통제가 필요합니다.
- 멱등성(Idempotency): 같은 요청이 재시도되어도 환불이 중복 실행되지 않도록 보장
- 보상 트랜잭션: 일부 단계만 성공했을 때 원상 복구 또는 후속 정정 수행
- 실행 한도: agent별 금액, 건수, 호출 빈도 제한
- 정책 기반 차단: 민감정보 접근, 고액 결제, 예외 거래는 자동 중단
- 감사 로그: 요청자, 사용 데이터, 적용 규칙, 호출 도구, 실행 결과를 기록
- 승인 증적: 누가 어떤 근거로 실행을 승인했는지 보존
Agentic Data Cloud는 데이터와 컨텍스트를 연결하는 기반이 될 수 있습니다. 하지만 그 위에서 실행되는 agent가 신뢰를 얻으려면, 답변의 정확도만큼이나 행동의 추적 가능성이 중요합니다.
비용도 실행 통제의 일부다
자율 agent는 잘못된 실행뿐 아니라, 과도한 탐색과 재시도로 비용을 급증시킬 수 있습니다. 원격 데이터 조회, 캐시, 쿼리, 임베딩 검색, LLM 토큰, 도구 호출이 반복되면 한 번의 업무 요청도 예상보다 큰 비용을 만들 수 있습니다.
기업은 Cloud 환경에서 다음 질문에 답할 수 있어야 합니다.
- 이 응답은 어떤 데이터 소스와 모델을 사용했는가?
- 원격 조회와 캐시 비용은 얼마였는가?
- agent가 몇 번 재시도했는가?
- 사람 검토 없이 실행된 작업은 몇 건인가?
- 오류·정책 위반·권한 거부는 얼마나 발생했는가?
이런 관측 가능성 없이 agent를 확장하면, 비용 문제와 운영 문제를 사후에야 발견하게 됩니다.
결국 가장 현실적인 전략은 명확합니다. 먼저 읽게 하고, 충분히 검증한 뒤, 제한된 범위에서만 맡겨야 합니다. Agentic Data Cloud는 기업 AI의 강력한 토대가 될 수 있지만, 자율 실행의 신뢰는 모델 성능이 아니라 권한 설계, 승인 절차, 감사 기록, 실패 복구 체계에서 만들어집니다.
