Qoder 엔지니어링 실천 시리즈: 에이전트의 경계가 '도구 호출(Tool Calling)'이라면, 클라우드 활용(Cloud Use)의 경계는 '클라우드 네이티브 실행(Cloud-Native Execution)'입니다. 전자는 AI가 인간의 소프트웨어 조작을 지원하지만, 후자는 에이전트를 일종의 새로운 클라우드 워크로드로 변모시킵니다. 이 글을 읽을 무렵에는 '클라우드 활용'과 '일반적인 도구 이용'의 차이가 단순히 에이전트가 API를 호출할 수 있는지 여부가 아니라, 관리되는 ID(Identity), 자격 증명(Credential), 실행 환경(Execution Environment), 라이프사이클(Lifecycle), 감사 로그(Audit Log)를 동반하여 실제로 클라우드 프로덕션 환경에 '진입'할 수 있는가인지를 통해 명확해질 것입니다.
새벽 2시—한 국경 간 이커머스 판매업체의 신상품이 갑자기 주문 급증을 겪었습니다. 아무도 잠에서 깨기 전에 이미 에이전트가 작동하기 시작합니다. 임시 사일로(Sandbox)를 생성하고, 재고 및 결제 데이터를 가져오며, 이상 주문을 감지하고, 여러 물류 옵션을 시뮬레이션하며, 관세 영향을 계산하고, 고객 지원용 응답안을 작성하며, 광고 추천을 조정하고, 고위험 주문을 인간의 최종 확인으로 라우팅합니다. 콘솔에 접속하거나 서버에 로그인할 필요는 없지만, 말 그대로 '클라우드를 사용'하는 것입니다.
그 순간, 다음과 같은 질문이 긴급하고 피할 수 없게 떠오릅니다:
- 이 에이전트는 재고 시스템에 접근할 때, 누구의 ID를 사용하는가?
- 에이전트가 열람한 결제 데이터는 적절하게 마스킹되어 있는가?
- 클라우드 API 호출에 사용되는 자격 증명(Credentials)은 어디에 보관되어 있는가?
- 리소스의 사양을 변경했을 경우, 누가 이를 승인했는가?
- 40분간 실행된 후 작업이 실패했을 경우, 그 상태는 복원 가능한가?
- 모든 조작은 감사(Audit)가 가능한가?
에이전트가 클라우드 API를 한 번 호출하는 것은 어렵지 않습니다. 어려운 점은 그것이 매일 심야 시간대에 여러 시스템을 넘나들며, 허가된 권한 범위 내에서 지속적으로 호출되며, 게다가 그 모든 호출에 대해 '누가 승인했는지', '어떤 자격 증명을 사용했는지', '어떤 조작을 했는지', '위험 제어가 발동했는지', '결과가 재현 가능한지'를 확실하게 파악할 수 있다는 것입니다. 이것이야말로 클라우드 활용(Cloud Use)이 진정으로 답해야 할 질문들입니다.
20년 이상 동안, 클라우드 컴퓨팅의 주요 상호작용 모델은 인간 운영자와 결정론적 자동화 프로그램이라는 두 가지 액터(Actor)를 중심으로 구축되어 왔습니다. 인간은 콘솔에 로그인하여 Elastic Compute Service (ECS) 인스턴스를 생성하고, 데이터베이스를 설정하며, 로그를 읽고, 알림에 대응합니다. 한편, CI/CD, Terraform, Kubernetes 컨트롤러, 주기적 실행 스크립트 등은 미리 정의된 규칙을 실행합니다. 이후 CLI, SDK, Infrastructure as Code (IaC), 그리고 기타 자동화 플랫폼이 등장하여 인간의 작업 부하를 크게 줄였지만, 근본적인 전제는 일관되게 명확했습니다: 시스템을 조작하는 것은 인간이거나, 혹은 결정론적 프로그램 중 하나였습니다. 이 모델은 안정적이었습니다. 클라우드 플랫폼은 계정 시스템, 권한 모델, 감사 로그, 콘솔 조작, 티켓 워크플로우를 이 전제에 기반하여 구축해 왔습니다. Resource Access Management (RAM) 사용자, AccessKey, 또는 작업 기록은 보통 특정 개인, 팀, 또는 시스템으로 추적 가능했습니다.
에이전트의 등장으로 이 양극단 사이에 '중간 영역'이 생겨났습니다. 에이전트는 더 이상
클라우드 컴퓨팅은 오랫동안 인간 운영자와 결정론적 자동화 프로그램을 중심으로 설계되어 왔습니다. 에이전트는 이 프레임워크에 새로운 변수를 도입합니다. 바로 추론하고, 도구를 호출하며, 여러 시스템을 가로질러 행동할 수 있는 소프트웨어 주체입니다.
그 영향은 '또 다른 AI 어시스턴트' 수준을 훨씬 뛰어넘습니다. 사용자가 인간이라면, 콘솔(console), CLI, SDK, IaC는 모두 사람이 클라우드를 조작하는 노력을 줄여줍니다. 결정론적 프로그램이 작업을 수행할 경우, 클라우드 플랫폼은 서비스 계정(service account), 역할(role), 정책(policy), 로그를 관리합니다. 에이전트는 이 둘의 중간에 위치합니다. 인간의 목표 이해 능력과 프로그램의 실행 속도 및 호출 빈도를 겸비하고 있는 것입니다. 에이전트에게는 콘솔, 마우스, 데스크톱은 필요하지 않지만, **아이덴티티(identity), 권한(permission), 도구(tool), 데이터(data), 런타임 환경(runtime environment), 상태 관리(state management), 비용 기록(cost recording), 장애 복구(disaster recovery), 감사 로그(audit log)**가 필요합니다. 이 세 가지 유형의 사용자를 한 장의 다이어그램에 나열하면 경계가 더욱 명확해집니다.
이 다이어그램에서 인간과 결정론적 프로그램은 클라우드가 20년 이상 걸쳐 정교화해 온 '알려진 사용자(known user)'입니다. 반면, 에이전트는 그 사이에 새롭게 등장한 '변수'입니다. 사람처럼 매번 마우스 클릭마다 조작하는 것도 아니고, 스크립트처럼 미리 정해진 경로만을 따르는 것도 아닙니다. 에이전트는 추론을 수행하고 여러 시스템을 가로질러 액션을 연결합니다. 이를 수용하려면 클라우드 플랫폼이 동일한 거버넌스 레이어(governance layer) 내에 에이전트 전용 실행 경로를 제공해야 합니다. 실제로 많은 도구 이용(Tool Use) 기능만을 가진 에이전트는 데모에서는 작동하는 것처럼 보여도, 실제 운영 환경 도입 단계에서 막히곤 합니다. 도구는 호출할 수 있지만, 클라우드 플랫폼은 아직 이를 '관리 가능한 소프트웨어 주체'로 받아들이지 못한 것입니다.
우리는 이미 문제의 본질이 '모델의 능력 부족'이 아니라, '오늘날 에이전트가 클라우드에 의해 진정으로 수용되지 못했다'는 것을 인지하고 있습니다. 데모에서는 화려해 보여도, 실제 운영 환경에서는 그 한계가 드러납니다. 클라우드 에이전트의 데모는 쉽게 구축할 수 있습니다. AccessKey ID와 AccessKey Secret(AK/SK)을 전달하고, 몇 가지 클라우드 API를 도구로 래핑(wrap)한 다음, 프롬프트를 작성하여 '어제 청구서의 이상을 확인해 주세요'라고 지시하기만 하면 됩니다. 충분한 능력을 가진 모델과 잘 래핑된 도구가 있다면 확실히 훌륭한 결과를 낼 수 있습니다. 첫날은 모든 것이 순조로워 보이지만, 이틀째가 되면 의문이 생깁니다.
- 이 AK/SK는 누구의 것인가? - 권한은 너무 넓지 않은가? - 키가 모델의 컨텍스트에 들어가 버린 것은 아닌가? - 도구 호출 로그는 어디에 저장되는가? - 리소스를 잘못 삭제했을 경우, 누가 책임을 지는가? - 사용자가 컴퓨터 전원을 끄더라도, 작업은 계속 실행되는가? - 다른 팀원이 인계받았을 때, 자격 증명과 컨텍스트는 어떻게 재사용되는가? - 보안팀은 어떻게 감사할 것인가?
이것들은 주변적인 우려 사항이 아닙니다. 이것들이 에이전트를 '데모'에서 '운영(production)'으로 전환시킬지 말지를 결정하는 열쇠입니다.
도구 이용(Tool Use)만을 가진 에이전트는 일반적으로 대화, 몇 개의 도구, 그리고 결과라는 구성으로 이루어집니다. 종종 그것은 '사람의 그림자'처럼 작동합니다. 사람의 컴퓨터 위에서 실행되고, 사람의 계정으로 로그인하며, 사람의 AK/SK로 API를 호출하고, 사람의 온라인 상태에 의존하여 작업을 유지합니다. 이는 단시간 작업이나 탐색적 분석에는 유효하지만, 아이덴티티, 자격 증명, 런타임, 감사를 위한 시스템이 갖춰지지 않는 한, 에이전트는 안정적인 클라우드 워크로드(cloud workload)가 될 수 없습니다. 클라우드 이용(Cloud Use)이란 '에이전트가 도구를 호출할 수 있는지'를 묻는 것이 아닙니다. 도구 이용, 함수 호출(function call), Model Context Protocol (MCP) 등은 이미 그 일부를 해결했습니다. 클라우드 이용은 다른 질문에 답합니다. 클라우드가 에이전트를 식별 가능하고(identifiable), 승인 가능하며(approvable), 감사 가능하고(auditable), 플랫폼 관리 가능한 형태로 어떻게 수용하는가입니다.
도구 활용(Tool Use)에만 의존하는 에이전트는 '모델이 도구를 어떻게 호출할지'를 다룹니다. 클라우드 활용(Cloud Use)은 '클라우드가, 거버넌스된 사용자로서 에이전트를 어떻게 수용할지'를 다룹니다.
이 구분이 바로 분수령입니다. 논의의 초점을 '에이전트가 어떤 도구에 접근할 수 있는가'에서 '어디서 실행되는지, 어떤 아이덴티티로 실행되는지, 자격 증명을 어떻게 사용하는지, 작업은 얼마나 오래 지속 가능한지, 장애로부터 복구 가능한지, 누가 감사할 수 있는지'로 옮기는 것입니다.
| 측면 | 도구 활용만 (클라우드 플랫폼의 거버넌스 없음) | 클라우드 활용 (Cloud Use) |
|---|---|
| 실행 장소 | 로컬 프로세스, 브라우저 세션 또는 단일 채팅 컨텍스트 | 클라우드 세션. 작업은 지속적 실행/복구/예약 가능 |
| 아이덴티티 모델 | 사람의 계정을 빌리거나 고정 키 사용 | 거버넌스된 머신 아이덴티티와, 작업 단위의 승인 |
| 자격 증명 사용 | AK/SK 또는 토큰이 프롬프트/스크립트/로그에 쉽게 유출 | Vault를 통해 참조로 자격 증명 사용. 모델 컨텍스트에는 일절 포함하지 않음 |
| 도구 경계 | 개별 API를 래핑. 거버넌스는 구현마다 다름 | MCP 또는 유사한 도구 프로토콜로 기능 공개. 권한/감사/확인 메커니즘이 플랫폼 계층에서 통합 |
| 운영 리스크 | 자격 증명 유출, 과도한 권한, 작업 중단, 책임 소재 불분명 | 저위험 작업은 자동 실행. 고위험 작업은 확인 필수. 모든 프로세스가 추적 가능 (traceable) |
도구 활용에만 의존하는 에이전트는 당신 옆에 앉아 도와주는 일시적인 비서와 같습니다. 클라우드 활용은, 에이전트에게 사원증을 발급하고 클라우드라는 직장으로 공식적으로 받아들이는 것과 같습니다—그 과정에서 모든 접근 확인, 증거 수집 단계, 각 액션이 기록됩니다.
이론은 여기까지 하고, 구체적인 시나리오로 살펴보겠습니다. 이를 통해 클라우드 활용이 실제로 채우는 '운영 환경의 격차'가 명확해집니다.
이는 몇 분의 절약 이상의 의미를 지니며, 책임 조직화 방식 자체를 변화시킵니다. 이전에는 '누군가 매일 잊지 않고 해야 할 필요'가 있었다면, 이제는 '위임된 작업이 스케줄대로 실행되고, 사람은 예외 대응과 의사결정만 담당하는' 방식으로 바뀌었습니다. 앞서 언급한 사례에서는 하나의 BI 분석 작업이 111회의 도구 호출을 수행하여 약 21.5분(21분 32초)에 실행되었으며, 중간에 인간 개입은 0회 있었습니다. 또한, 하나의 ETL 작업은 116건의 이벤트를 생성하고 cron 트리거 후 13분 만에 완료되었습니다. 이러한 수치는 특정 샘플 작업에서 나온 것이며, 모든 시나리오에서 보장되는 SLA는 아닙니다. 목적은 호출 횟수를 과시하는 것이 아니라, 에이전트가 채팅 창 내의 '답변자'에 머무르지 않고—수명 주기(lifecycle)를 가진 클라우드 작업을 수행할 수 있음을 보여주는 것입니다.
CI 실패, 느린 쿼리, 프로덕션 알림은 또 다른 전형적인 작업 범주입니다. 이전에는 MR(Merge Request)에 대한 CI가 실패했을 경우, 개발자는 파이프라인 로그를 열어 테스트 실패를 검사하고, 최근의 종속성 변경을 조사하며, 빌드 이미지를 검증하고, 나아가 클라우드상의 빌드 머신, 캐시, 네트워크, 권한 설정을 확인할 필요가 있었습니다. 문제 자체는 반드시 깊지 않으며, 단지 컨텍스트가 너무 많은 시스템에 흩어져 있을 뿐입니다. 일반적인 에이전트도 여기에서 유용합니다: 로그를 붙여넣으면 오류를 요약하고, 설정을 붙여넣으면 원인을 추정할 수 있습니다. 그러나 이것은 여전히 '자료를 에이전트에게 가져다주는' 행위에 불과합니다. 에이전트 스스로가 환경에 들어가 증거의 사슬을 추적할 수는 없습니다. 주어진 단편만을 분석하는 것에 그칩니다.
클라우드 활용은 진단 작업의 실행 방식을 혁신합니다. CI 실패 이벤트가 발생하면, 클라우드 상에서 직접 에이전트 API가 트리거됩니다. 에이전트는 클라우드 아이덴티티를 사용하여 파이프라인 로그를 읽고, 관련 MR을 검색하며, 종속성 변경을 검사하고, 빌드 환경 상태에 접근합니다. 필요에 따라 로그/모니터링 시스템을 호출하여 증거들을 연결하고, 그 소견을 MR 코멘트, IM 그룹 또는 티켓에 다시 작성합니다. 이는 단순한 '로그 요약'을 넘어 '적극적인 증거 수집'입니다.
진단 작업에서 진정한 변화는 단순히 오류 설명이 좋아지는 것이 아닙니다. 에이전트가 클라우드라는 업무 환경 자체로 들어가서, 컨텍스트를 수집하고, 증거의 사슬을 구축할 수 있다는 점입니다.
ELK를 통한 느린 쿼리 진단이나 CI 실패 진단과 같은 시나리오에서는 이 차이가 특히 명확합니다. 앞서 언급한 사례에서, 느린 쿼리 진단은 2~5분 이내에 엔드투엔드 소견을 제시할 수 있었고, CI 진단은 3~8분 이내에 분석 결과를 MR에 게시할 수 있었습니다. 실제 소요 시간은 시스템 규모, 도구의 응답 시간, 컨텍스트의 복잡성에 따라 달라집니다. 분 단위의 숫자는 그 자체로 의미가 없습니다. 중요한 것은 에이전트가 누군가가 자료를 복사하기를 기다리는 것이 아니라, 이벤트를 기점으로 능동적으로 증거 수집을 시작한다는 점입니다.
실행 작업은 가장 오해하기 쉬운 분야입니다. 에이전트가 문제를 진단했다면, 그것을 직접 수정할 수 있을까요? 프리뷰 환경을 생성하고, 파이프라인을 트리거하고, 임시 리소스를 정리하며, 설정을 조정할 수 있을까요? 국경 간 전자상거래 판매업자의 사례에서는, 에이전트가 자동으로 재고 보충 제안을 생성하고 물류 옵션을 시뮬레이션할 수 있습니다. 하지만 광고 예산 변경, 풀필먼트 전략 변경, 고위험 주문 처리에 대해서는 반드시 멈추고 인간의 확인을 기다려야 합니다. 기술적으로는 충분한 권한이 있다면 실행 가능하지만, 바로 그곳에 진정한 위험이 도사리고 있습니다.
많은 팀들이 이미 스크립트를 통한 자동화를 도입하고 있습니다. 스크립트에는 키, 권한, 스케줄 작업, 로그가 있습니다. 그러나 일반적으로 동적인 판단력이나 교차적 컨텍스트(cross-cutting context)가 부족하고, 결과 설명도 서툽니다. 일반적인 에이전트는 판단력을 더하지만, 동시에 위험도 확대합니다: 컨텍스트에 기반하여 행동할 수 있지만, 아이덴티티/자격 증명/권한/감사가 따라가지 못하면, 강력한 자동화일수록 '폭발 반경(Blast Radius)'이 커집니다.
클라우드 활용은 에이전트에게 무제한의 자동 실행을 허용하는 것을 목표로 하지 않습니다. 오히려, 실행을 안전하게 위임할 수 있도록 하는 것을 목표로 합니다. 낮은 위험도의 작업(로그 읽기, 보고서 생성, 임시 샌드박스 생성, 만료된 리소스 정리 등)은 자동으로 실행 가능합니다. 높은 위험도의 작업(운영(Production) 리소스 삭제, 권한 확장, 운영 설정 변경, 사용자에게 영향을 미치는 릴리스 트리거 등)은 반드시 확인 과정을 거쳐야 합니다. 에이전트는 제안과 증거를 제공할 수 있지만, 이러한 경계를 넘어서는 안 됩니다.
실행 작업에서의 진정한 변화는 낮은 위험도의 자동화, 높은 위험도 작업의 승인, 엔드투엔드 추적성—즉, 인간을 완전히 대체하는 자동화가 아닙니다.
정기 작업, 진단 작업, 실행 작업을 종합해 볼 때, 에이전트는 더 이상 채팅 창 내의 어시스턴트가 아니라, 아이덴티티(Identity), 경계(Boundary), 라이프사이클(Lifecycle)을 가진 소프트웨어 주체라는 새로운 역할을 맡고 있습니다. 일반적인 에이전트에 의한 자동화는 종종 '신뢰'에 의존합니다: 프롬프트를 신뢰하고, 모델을 신뢰하며, 툴래퍼(Tool Wrapper)를 신뢰하는 것입니다. 클라우드 활용은 '거버넌스(Governance)'에 의존합니다: 에이전트의 아이덴티티는 확립 가능하고, 자격 증명 정보는 에이전트에게 보이지 않으며, 권한은 취소 가능하고, 액션은 승인 대상이며, 프로세스는 감사 가능하고, 장애는 복구 가능하다는 점입니다.
이론이 명확해졌다면, 그것을 실제 사례에서 검증하여 정말로 작동하는지 확인해야 합니다. 이 섹션에서는 위 모델을 한 커피 체인의 비즈니스 리뷰 회의에 적용합니다.
월요일 아침 9시, 커피 체인의 비즈니스 리뷰 회의가 시작됩니다. CEO는 '전반적으로 양호하다'라는 주간 보고서를 원하지 않습니다. 그가 원하는 것은 세 가지 답변입니다:
- 제곱미터당 일평균 매출이 가장 높은 매장 형태는 무엇인가?
- 다음 성장 동력으로 부상하고 있는 카테고리는 무엇인가?
- 다음 분기에 신규 출점을 우선해야 할 도시는 어디인가?
항저우, 선전, 청두, 광저우의 15개 매장 데이터가 4개의 테이블과 320행의 팩트 데이터에 분산되어 있습니다. 대규모 과제는 아니지만, 충분히 까다롭습니다. 기존 워크플로우는 익숙합니다: 사업 부문이 요청을 제출 → 데이터 분석가가 일정을 조정 → 지표 정의를 합의 → SQL을 작성 → MaxCompute나 데이터 웨어하우스에서 쿼리 실행 → 테이블 정리 → 비즈니스 보고서 작성. 최소 며칠, 최악의 경우 1~2주가 걸립니다. 분석가의 노력 부족이 아닙니다. 문제는 이러한 작업들이 항상 누군가의 캘린더 위에서 '대기열'에 놓여야 한다는 것입니다.
클라우드 활용의 매력은 '에이전트가 SQL도 작성할 수 있다'는 점에 있지 않습니다. 그것은 특별한 일이 아닙니다. 진정한 변화는 이 작업을 클라우드 작업으로 위임할 수 있다는 점에 있습니다. 에이전트는 채팅 창 내의 Q&A 파트너에서, 아이덴티티, 자격 증명 정보의 경계, 런타임, 이벤트 전송, 수용 기준을 가진 소프트웨어 주체로 진화합니다.
커피 비즈니스 인텔리전스(BI) 사례의 가치는 단순히 보고서를 생성했다는 것이 아니라, 비즈니스 질문 → 데이터 접근 → 쿼리 실행 → 장애 복구 → 결과 전송 → 수용 증명이라는 완전한 체인을 구동했다는 데 있습니다.
이 체인은 6가지 엔지니어링 질문에 매핑될 수 있습니다. 이것들은 제품 모듈의 분해가 아니라, 실제 작업이 진행되는 과정에서 극복해야 하는 6가지 허들입니다:
작업 시작 시 첫 번째 장애물은 모델도 SQL도 아닙니다. **자격 증명 정보(Credential)**입니다. 에이전트는 데이터 웨어하우스를 쿼리해야 하지만, 가장 거친 방법은 AK/SK를 프롬프트에 직접 삽입하는 것입니다. 빠르지만 위험합니다. 키는 모델 컨텍스트에 들어가고, 툴 로그에 표시되며, 중간 결과에 의해 Webhook 페이로드로 운반될 수 있습니다. 실제 운영 환경에서는 이것이 보안 검토를 통과하지 못할 것입니다.
그래서 자격 증명 정보는 먼저 Vault에 저장됩니다. 에이전트는 평문(Plain Text) 키가 아니라 vault_credential_id
이러한 참조를 받게 됩니다. 런타임이 DataWorks, MaxCompute 및 기타 클라우드 서비스에 접근할 때, 플랫폼 또는 도구 계층이 자격 증명 교환과 제어된 주입을 처리합니다. 이 구분은 매우 중요합니다: 에이전트는 클라우드를 사용할 수 있지만, 복사 가능한 마스터 키를 소유해서는 안 됩니다.
자격 증명 문제가 해결되면 다음 과제가 나타납니다: 에이전트는 어떤 경로를 선택해야 할까요? MaxCompute 데이터를 분석할 필요가 있다는 것은 알지만, 실제 기업 환경에서는 ODPS SQL을 DataWorks를 통해 전송해야 한다는 것을 알지 못합니다. 에이전트는 겉보기에는 직접적인 인터페이스를 찾거나 적용할 수 없는 API를 반복적으로 시도할 수 있습니다. '똑똑한' 모델일수록 겉보기에 그럴듯해 보이지만 실제로는 작동하지 않는 경로를 즉시 발명합니다. 여기서 '스킬(Skill)'의 가치가 발휘됩니다. 이는 단순한 프롬프트 템플릿이 아니라, 조직이 피와 땀을 흘려 얻은 교훈의 기록입니다: 사용해서는 안 될 API, 주의해야 할 ODPS SQL 구문의 함정, 리소스 그룹이 중단되었을 때 가장 먼저 확인해야 할 항목, 보고서에 포함해야 할 필드 등. 이 사례에서는 스킬이 약 13분의 잘못된 경로 탐색을 회피했습니다. 이 수치는 특정 작업에서 나온 것이며 일반론을 보장하는 것은 아닙니다. 클라우드 활용이 재사용해야 하는 것은 검증된 실행 경로이며, 단발성 프롬프트가 아니라는 것을 보여줍니다.
경로가 확정되면 논의는 역할 경계로 넘어갑니다. '당신은 데이터 분석가입니다'라는 지시는 너무 모호합니다—너무 모호해서 에이전트에게 세련되었지만 추적 불가능한 보고서를 작성할 여지를 줍니다. 클라우드에서 실행하기 전에, 에이전트의 범위를 명확하게 좁혀야 합니다: 사용 가능한 도구, 따라야 할 지표 정의, 자체 복구가 가능한 오류, 중단을 요하는 작업 등입니다.
단순화된 작업 계약은 다음과 같습니다:
당신은 시니어 데이터 분석가입니다.
DataWorks를 통해 ODPS SQL을 실행하고 MaxCompute 데이터를 분석합니다.
각 분석 차원에 대해 다음을 제공해 주세요:
...
이것은 프롬프트 트릭의 데모가 아닙니다. 오히려 작은 작업 계약과 같습니다: 결론에는 수치를 포함해야 하고, 그 수치는 쿼리 결과에서 추적 가능해야 하며, 오류 처리는 허용된 권한을 초과해서는 안 된다는 점입니다.
작업이 실제로 실행되기 시작하면 런타임이 시험대에 오릅니다. 이 사례에서는 21분 32초의 실행 시간 동안 111회의 도구 호출과 312건의 이벤트가 발생했으며, 중간에 0회의 인간 개입이 있었습니다. 이러한 수치는 플랫폼의 SLA나 모든 BI 작업에 대한 성능 보증도 아닙니다. 보여주고 싶은 것은 클라우드 활용이 일반적인 채팅 턴보다 긴 멀티 스텝 작업을 지원할 수 있으며, 그 과정은 추적 및 재생, 업무 시스템과의 통합이 가능하다는 점입니다. 이는 '에이전트를 로컬에서 실행하는 것'과 '작업을 클라우드에 위임하는 것'의 분기점입니다. 사용자가 작업을 시작한 후, 에이전트는 클라우드 세션 내에서 지속적으로 실행됩니다. 브라우저를 닫거나 PC가 절전 모드로 들어가거나 채팅 창 연결이 끊어져도 작업 수명 주기에는 영향을 미치지 않습니다.
보고서가 생성된 후, 종종 간과되는 또 다른 과제가 있습니다: 결과를 어떻게 업무 시스템으로 되돌릴 것인가? 최종 출력이 채팅 창 내의 텍스트에 머무른다면, BI 디지털 워커는 아직 업무 워크플로우에 진입하지 못한 것입니다. 더 신뢰할 수 있는 접근 방식은 업무 시스템이 작업 종료 이벤트를 구독하는 것입니다—예를 들어, session.thread_idled가 발생한 후에 완전한 결과를 얻습니다. 너무 빠르면 미완성된 결과를 얻게 되고, 스레드가 유휴 상태가 된 후 가져오면 결과는 안정적입니다.
실용적인 코드 예제가 설명보다 더 명확합니다:
import hmac
import hashlib
import time
...
코드는 짧지만 경계는 명확합니다: 웹훅은 신뢰할 수 있는 소스에서 온 것인지 검증 가능해야 하며, 작업 완료는 이벤트 기반이어야 하고, 보고서 가져오기는 비동기적으로 처리되어야 합니다. 그렇지 않으면 에이전트가 작업을 마친 후에도 결과가 도중에 손실될 가능성이 있고, 체인이 불완전해집니다.
마지막으로, 에이전트가 '완료'를 선언했다고 해서 작업이 완료된 것은 아닙니다. BI 작업이 완료되었는지 여부는 마지막에 보고서 형태의 텍스트 블록이 존재하는지 여부가 아니라, 비즈니스 질문에 답했는지로 결정됩니다:
- 제곱미터당 일평균 매출이 가장 높은 매장 형식은 무엇인가?
- 성장률이 가장 높은 카테고리는 무엇인가?
- 신규 출점을 우선해야 할 도시는 어디인가?
- 모든 결론에 수치가 포함되어 있는가?
- 그 수치는 SQL 쿼리 결과로 추적 가능한가?
| 처리 항목 | 평가 기준 |
|---|
| 데이터 소스 접근성 | 제어된 자격 증명을 사용하고, 일반 텍스트 키는 전혀 사용하지 않았는가? |
| 쿼리 실행 | 추적 가능한 SQL 문과 쿼리 결과가 생성되었는가? |
| 분석의 완전성 | 제곱미터당 일 매출, GMV, 도시 점수 등 작업 요구 사항이 모두 다루어졌는가? |
| 결론의 품질 | 모든 결론에 수치가 포함되어 있으며, 그것들이 추적 가능한가? |
| 권장 사항의 구체성 | 권장 사항은 추상적인 일반론이 아니라 실행 가능한 비즈니스 단계로 번역될 수 있는가? |
| 결과 전달 | Webhook이나 업무 API를 통해 결과가 하위 시스템에 도달했는가? |
| 장애 복구 | 오류, 재시도, 자체 복구 경로가 기록되었는가? |
| 감사 가능성 | 이벤트 스트림에서 프로세스의 주요 부분을 재생할 수 있는가? |
최종 출력은 단순히 '분석 완료'라는 선언이 아니라, 검증 가능한 비즈니스 평가입니다. 피크업 매장의 제곱미터당 일평균 매출은 약 ¥85+/m²이고, 플래그십 매장은 약 ¥38/m²로 약 2.2배 높습니다. GMV 중 커피가 81.3%를 차지하고, 차 음료는 전년 대비 18.5%, 잡화는 45.0% 증가했습니다. 도시 확장 점수는 항저우가 0.92, 선전이 0.85, 청두가 0.78, 광저우가 0.70입니다. 바로 이러한 수치들이 BI 에이전트를 '보고서를 생성할 수 있는' 단계에서 '비즈니스 질문에 답할 수 있는' 단계로 진화시키는 것입니다.
