세일즈 에이전트가 전화 걸던 그 주에, 서비스 에이전트는 같은 고객의 불만을 처리하고 있었어

허브스팟이 2026년 7월 23일 Agent Hub와 Agent Builder를 퍼블릭 베타로 풀었어. 대상은 Professional·Enterprise 등급을 쓰는 전 고객이야. 별도 신청 대기열이나 초대 코드 같은 것 없이, 해당 등급이면 그날부터 계정에서 켤 수 있는 구조로 나왔어.

허브스팟이 이번 발표에서 제일 앞세운 건 기능 목록이 아니라 하나의 장면이야. 세일즈 프로스펙팅 에이전트가 어떤 고객사에 신규 제안 메일을 보내는 바로 그 주에, 컨택센터의 서비스 에이전트는 같은 계정에서 아직 해결되지 않은 불만 티켓을 붙잡고 있어. 두 에이전트는 서로의 존재를 몰라. 고객 입장에서는 "내 문제도 아직 못 고쳤는데 무슨 신규 제안이냐"가 되는 거고, 회사 입장에서는 자동화를 늘릴수록 고객 경험이 더 나빠지는 역설이 생기는 거야.

허브스팟의 최고제품·기술책임자(CPTO) 던컨 레녹스(Duncan Lennox)는 공식 발표문에서 이걸 이렇게 정리했어. "문제는 에이전트 하나를 따로 관리하는 게 아니야. 에이전트가 여러 개가 되는 순간 그것들이 파편화되고, 저마다 다른 고객 그림을 보고 일하거나, 더 나쁘게는 아무 그림도 없이 일하게 된다는 거지." 그리고 Agent Hub가 그걸 고친다고 덧붙였어. "한 곳에서 에이전트 성과를 보고, 모두가 공유된 컨텍스트로 함께 일하는 것"이 목표라는 거야.

그러니까 이번 발표의 요점은 "허브스팟도 에이전트를 만들 수 있다"가 아니야. 그건 2024년부터 Breeze라는 이름으로 이미 하던 일이거든. 이번엔 여러 에이전트를 하나의 고객 뷰 위에 세워 두고, 관리자가 그 위에서 켜고 끄고 감사(audit)하게 만든 것이 달라진 지점이야. 2025~2026년 SaaS 업계의 실제 전장이 "에이전트를 만들 수 있느냐"에서 "여러 에이전트를 조율할 수 있느냐"로 옮겨갔다는 걸, 허브스팟이 제품 구조로 인정한 셈이지.

허브스팟은 왜 여기서 이걸 꺼냈나

허브스팟은 원래 중소·중견기업(SMB) CRM의 대표 주자야. 세일즈포스가 대기업 쪽을 장악한 사이, 허브스팟은 "IT 인력 없는 회사도 쓸 수 있는 마케팅·영업·서비스 올인원"이라는 포지션으로 자랐어. 이 회사의 자산은 알고리즘이 아니라 고객 데이터야. 마케팅 캠페인 기록, 딜 히스토리, 컨택 레코드, 통화 녹취록, 티켓, 구매 신호 같은 게 Smart CRM이라는 이름 아래 한 덩어리로 쌓여 있어.

에이전트 시대에 이 축적이 갑자기 무기가 됐어. 에이전트가 쓸모 있으려면 모델이 똑똑한 것보다 그 고객에 대해 뭘 알고 있느냐가 더 중요하거든. 프론티어 모델은 API로 누구나 살 수 있지만, "이 계정은 3주 전에 환불 요청을 했고, 담당자가 두 번 바뀌었고, 마지막 미팅에서 가격 얘기가 나왔다"는 맥락은 CRM 안에만 있어. 허브스팟이 이번에 파는 건 모델이 아니라 그 맥락이야.

Agent Hub는 그 맥락 위에 올라가는 관제탑이야. 허브스팟의 공식 제품 문서를 보면 Agent Hub는 사전 제작 에이전트, 고객이 만든 커스텀 에이전트, 그리고 에이전틱 워크플로를 한 곳에 모아 두는 화면으로 설명돼 있어. 각 에이전트 카드에 실시간 상태와 최근 결과가 뜨고, 에이전트를 기능별이 아니라 "어떤 성과를 내는가"(수요 창출, 딜 클로징, 고객 만족, 성장 확장) 기준으로 묶어 보여줘. 문서에 열거된 기본 에이전트는 AEO(AI 검색 노출 최적화), 데이터 에이전트(CRM 데이터 품질·보강), 프로스펙팅 에이전트, 딜 프로그레션, 커스터머 에이전트야.

Agent Builder는 그 옆에 붙은 제작소야. 노코드 캔버스에서 자연어로 지시하면서, 이미 CRM에 있는 데이터를 재료로 커스텀 에이전트를 조립해. 공식 문서 기준으로 캔버스에서 쓸 수 있는 액션은 세 갈래야. 허브스팟 액션(데이터 가져오기, 생성하기, 실행하기), 기본 액션(웹 브라우징, CRM 레코드 읽기·쓰기), 그리고 MCP(Model Context Protocol, 외부 시스템 연결 규약)를 통한 외부 연동. 마지막 MCP 항목이 중요한데, 허브스팟 울타리 밖의 시스템까지 에이전트가 손을 뻗을 수 있는 통로를 열어 뒀다는 뜻이거든.

관리자 쪽 기능도 같이 나왔어. 실행 로그(execution logs)를 뒤져 에이전트가 무슨 판단으로 뭘 했는지 확인하고, 팀별 성능을 추적하고, 에이전트가 회사 가이드라인 안에서 움직이는지 한 워크스페이스에서 본다는 게 허브스팟 설명이야. 자율 실행 전에 승인 단계를 거치도록 설정할 수도 있어. 다만 Agent Builder를 열려면 슈퍼 어드민이 계정의 AI 설정을 먼저 켜줘야 해서, 아무나 조직 몰래 에이전트를 만들어 돌리는 건 기본값에서 막혀 있어.

크레딧이 켜지는 순간, 계산기도 같이 켜져

숫자로 보면 이번 베타의 성격이 더 선명해져. Agent Hub와 Agent Builder 자체는 Professional·Enterprise 구독에 포함돼 있어서 새 SKU를 사야 하는 건 아니야. 대신 Agent Builder로 만든 커스텀 에이전트가 실제로 설정된 액션을 수행할 때마다 HubSpot Credits가 깎여. 해당 등급에 크레딧이 기본 포함돼 있고, 모자라면 추가로 사는 구조야. 반대로 기존 자동화·워크플로는 종전대로 크레딧을 먹지 않아.

허브스팟이 비용 공포를 줄이려고 넣어 둔 장치가 두 개 있어. 첫째, 테스트 실행은 크레딧을 소모하지 않아. 에이전트가 원하는 포맷으로 답하는지, 올바른 데이터 소스를 쓰는지 배포 전에 마음껏 돌려볼 수 있어. 둘째, 월 단위 실행 한도(run limit) 를 걸 수 있어. 에이전트 하나가 폭주해서 크레딧을 태워버리는 사고를 상한선으로 막는 거지. 다만 허브스팟 문서도 테스트 실행을 근거로 산출한 예상 크레딧 소요는 어디까지나 추정이고 "실제 비용은 달라질 수 있다"고 명시해 뒀어.

항목 내용
발표일 2026년 7월 23일 (퍼블릭 베타)
대상 Professional·Enterprise 전 고객
적용 제품 Marketing / Sales / Service / Data / Content Hub + Smart CRM (Pro·Enterprise)
Agent Hub 사전 제작 + 커스텀 에이전트 통합 콘솔, 실시간 상태·최근 결과, 성과 기준 그룹핑
기본 에이전트 AEO, 데이터, 프로스펙팅, 딜 프로그레션, 커스터머 에이전트
Agent Builder 노코드 캔버스, 자연어 + Smart CRM 컨텍스트로 커스텀 에이전트 조립
사용 가능 액션 허브스팟 액션(가져오기·생성·실행), 기본 액션(웹 브라우징·CRM 읽기/쓰기), MCP 외부 연동
과금 커스텀 에이전트 액션 수행 시 HubSpot Credits 차감, 등급에 포함 + 추가 구매
비용 통제 테스트 실행 무료, 월 실행 한도 설정, 자율 실행 전 승인 단계
접근 조건 슈퍼 어드민이 계정 AI 설정을 먼저 활성화
초기 사례 Ignite Reading — 25개 주 이상, 연 350시간 이상 절감

이 표에서 제일 논쟁적인 줄은 과금이야. 시트(seat) 기반 SaaS는 예측이 쉬웠어. 사람 수 곱하기 단가, 끝. 소비(consumption) 기반은 다르지. 에이전트가 잘 돌수록 청구서가 커지고, 성과가 좋은 팀이 비용도 많이 내. "성과와 비용이 연동된다"는 말은 판매자 입장에서는 정합적으로 들리지만, 예산을 연초에 확정해야 하는 구매자 입장에서는 예측 불가능성이야. 특히 퍼블릭 베타에서 액션 단가나 크레딧 소모율 같은 세부 수치가 공개되지 않았다는 점을 PPC Land도 미결 과제로 짚었어.

참고로 허브스팟이 소비·성과 과금으로 기울어 온 흐름은 이번이 처음이 아니야. CMSWire는 허브스팟이 2026년 4월 일부 Breeze 에이전트를 성과 기반(pay-per-result) 과금으로 옮겼다고 보도했고, PPC Land는 같은 해 4월 14일 출시된 AEO 도구가 월 50달러로 책정됐다고 전했어. 즉 Agent Hub의 크레딧 모델은 갑자기 튀어나온 게 아니라, 지난 몇 분기 동안 조금씩 밀어 온 방향의 연장선이야.

첫 성과 사례로 제시된 건 Ignite Reading이야. 25개 주 이상에서 온라인 문해력 튜터링을 운영하는 조직인데, 학군(school district)마다 흩어진 학사 일정을 찾아 파싱하는 작업을 커스텀 에이전트에 맡겼어. 학군 하나당 15~20분 걸리던 수작업이 몇 초로 줄었고, 연간 350시간 이상을 회수했다는 게 허브스팟과 PPC Land 보도의 내용이야. 화려한 매출 증대 사례가 아니라 지루한 데이터 수집 자동화라는 점이 오히려 신뢰를 주는 대목인데, 동시에 "에이전트가 지금 확실히 잘하는 일의 범위"를 정직하게 보여주기도 해.

각자가 챙기는 것, 그리고 아무도 안 챙기는 리스크

허브스팟이 챙기는 건 락인이야. 에이전트가 Smart CRM의 컨텍스트를 먹고 자라는 구조라면, 고객이 CRM을 갈아타는 순간 그동안 만들어 둔 커스텀 에이전트와 워크플로가 통째로 무의미해져. 데이터 이관은 어떻게든 되지만, "이 조직이 어떤 순서로 어떤 판단을 하는지"를 캔버스에 새겨 넣은 자산은 이관이 안 되거든. 지금까지 CRM 락인의 핵심이 데이터였다면, 앞으로는 운영 로직이 그 자리를 대체하는 거야. 허브스팟은 새 SKU를 팔지 않고도 크레딧이라는 이름으로 계정당 매출을 늘릴 여지를 얻고.

중소기업 고객이 챙기는 건 인력이야. 전담 개발자나 AI 엔지니어 없이 마케팅 담당자가 자연어로 에이전트를 조립할 수 있다는 건, 지금까지 컨설팅 회사에 수천만 원을 주고 맡기던 종류의 자동화를 내부에서 시도해 볼 수 있다는 뜻이야. Ignite Reading 사례가 정확히 그 형태고. 게다가 테스트가 무료라 실패 비용도 낮아. 이 조합은 실제로 SMB 쪽에서 도입 속도를 밀어 올릴 가능성이 커.

기존 파트너·에이전시도 나쁘지 않아. 노코드라고 해서 아무나 잘 만드는 건 아니거든. 어떤 액션에 승인을 걸지, 어떤 데이터를 에이전트에게 보여줄지, 실행 한도를 얼마로 잡을지는 결국 설계 역량이야. 허브스팟 생태계의 구현 파트너들에게는 "에이전트 설계·거버넌스"라는 새 청구 항목이 생기는 셈이지.

리스크는 세 갈래로 나뉘어. 첫째는 책임이야. 에이전트가 잘못된 고객에게, 잘못된 타이밍에 연락했을 때 그 책임은 누구 것일까. 자동화가 사람 대신 판단하는 폭이 넓어질수록 "설정을 그렇게 한 고객사 책임"과 "그렇게 동작하게 만든 플랫폼 책임" 사이 경계가 흐려져. 마케팅 발송 규제, 개인정보 처리, 금융·의료 같은 규제 산업의 커뮤니케이션 규칙이 걸리면 이건 이론적인 논쟁이 아니라 실제 과징금 문제가 돼.

둘째는 감사 로그의 실효성이야. 실행 로그가 있다는 것과 그 로그로 사후에 무슨 일이 있었는지 재구성할 수 있다는 건 다른 얘기야. LLM 기반 에이전트는 같은 입력에도 다르게 반응할 수 있어서, "왜 이렇게 판단했는가"를 로그만으로 설명하기 어려운 경우가 많아. 퍼블릭 베타 단계에서 거버넌스와 승인 워크플로의 깊이가 어디까지인지는 아직 충분히 공개되지 않았고, CMSWire와 PPC Land 모두 이 부분을 미확인 영역으로 남겨 뒀어.

셋째는 비용 쇼크야. 크레딧 상한을 걸어 두면 폭주는 막지만, 상한에 걸린 에이전트는 그냥 멈춰. 고객 응대 에이전트가 월말에 크레딧 한도를 다 써서 멈추는 상황은 비용 사고보다 더 나쁜 서비스 사고가 될 수 있어. 소비 기반 과금은 이렇게 "돈 아끼기"와 "서비스 끊기지 않기"가 정면으로 충돌하는 구간을 만들어.

과거 유사 사례 — 성공과 실패

가장 직접적인 선례는 세일즈포스 Agentforce야. 2024년 9월 출시 당시 과금은 대화 1건당 2달러였어. 그런데 "대화"의 정의가 문제였지. 한 번 묻고 끝나는 단순 질의도, 열 번 주고받는 복잡한 상담도 똑같이 2달러였거든. 비용이 실제 가치와 연동되지 않으니 예산을 잡기도 어렵고, 그래서 대규모 배포로 넘어가지 못하는 조직이 속출했어. 판매자는 "성과 기반"이라고 말했지만 구매자가 체감한 건 "예측 불가능한 청구서"였던 거야.

세일즈포스는 결국 방향을 틀었어. 2025년 5월 15일 공식 보도자료로 Flex Credits를 발표했는데, 대화 단위가 아니라 액션 단위 과금으로 바꾼 게 핵심이야. 액션 1회에 20 Flex Credits, 대략 0.10달러 수준이고, 크레딧은 10만 개 묶음에 500달러로 팔았어. 사용자 라이선스와 디지털 노동(크레딧) 사이에서 예산을 옮길 수 있게 하는 Flex Agreement도 같이 나왔고. 초기 가격 모델이 도입을 막았다는 걸 사실상 인정한 조정이었어. 이후 Agentforce를 확대 적용하는 고객이 분기 대비 늘었다는 보고가 나왔지만, 계약에 파일럿·시딩 라이선스가 섞여 있어 실제 유료 확산 규모는 여전히 논쟁 중이야.

여기서 허브스팟이 배운 티가 나. 허브스팟은 처음부터 액션 단위 크레딧으로 시작했고, 테스트 무료와 월 실행 한도라는 안전장치를 기본 탑재했어. 세일즈포스가 8개월 걸려 도달한 지점에서 출발한 거지. 새 SKU를 만들지 않고 기존 Professional·Enterprise 구독 안에 넣은 것도 "일단 써 보게 하고 소비로 회수한다"는 계산이야.

성공 사례 쪽에서 참고할 만한 건 젠데스크와 인터콤이 밀어붙인 해결 건당 과금(per-resolution) 모델이야. 고객 문의가 실제로 해결됐을 때만 돈을 받는 구조라, 구매자가 "AI가 일을 안 하면 돈도 안 낸다"고 안심할 수 있었어. 성과 정의가 명확한 고객 지원 영역이었기 때문에 가능했던 설계인데, 반대로 말하면 성과를 딱 떨어지게 정의할 수 없는 영역에서는 이 모델이 성립하지 않아. 마케팅 콘텐츠 생성이나 세일즈 리서치처럼 "결과가 좋았는지"를 즉시 판정할 수 없는 작업에는 결국 액션 기반 크레딧으로 갈 수밖에 없고, 허브스팟이 서 있는 자리도 거기야.

마이크로소프트 Copilot Studio는 또 다른 교훈을 남겼어. 메시지·크레딧 팩을 사서 쓰는 소비 모델인데, 기능마다 소모량이 달라(스크립트 응답은 적게, 생성형 응답과 에이전트 액션은 더 많이, 추론 모델은 훨씬 많이). 계산은 정교하지만 구매 담당자가 청구서를 예측하기는 오히려 더 어려워졌다는 불만이 반복됐어. 정교한 미터링이 반드시 좋은 구매 경험을 만들지는 않는다는 얘기고, 허브스팟이 크레딧 소모율 세부를 아직 공개하지 않은 상태로 베타를 연 건 이 지점에서 부담으로 남아.

경쟁자 카운터 플레이

세일즈포스 Agentforce는 여전히 가장 직접적인 상대야. 강점은 대기업 침투력과 Data Cloud를 통한 대규모 데이터 통합이고, 약점은 복잡성과 총소유비용이야. 허브스팟의 이번 카드는 정확히 그 약점을 겨냥해. "관리자 한 명이 오후 반나절에 켤 수 있는 에이전트 콘솔"이라는 포지션은, 전담 아키텍트가 필요한 Agentforce 도입기와 대조를 이루거든. 다만 조직이 커질수록 세일즈포스의 데이터 통합 폭이 다시 유리해지는 구간이 오고, 그 경계선이 어디냐가 앞으로 몇 분기의 승부처야.

마이크로소프트 Dynamics 365 + Copilot Studio는 다른 축에서 압박해. 세일즈·서비스 등 Dynamics 앱 계열의 Copilot은 2026년 기준 해당 SKU에 포함돼 별도 라이선스 없이 쓰는 방향으로 정리됐고, 외부 대면 에이전트만 Copilot Studio 라이선스와 크레딧 소모가 붙어. 마이크로소프트의 무기는 CRM 컨텍스트가 아니라 오피스·팀즈·엔트라(ID)까지 아우르는 업무 컨텍스트야. 허브스팟이 "고객에 대해 아는 것"으로 싸운다면 마이크로소프트는 "직원이 하는 일 전부를 아는 것"으로 싸우는 거지. 이미 M365를 쓰는 조직에서 이 논리는 강력해.

**조호(Zoho)**는 가격으로 밑을 파. 올인원 스위트를 훨씬 낮은 단가로 제공해 온 회사라, 에이전트도 "추가 비용 최소화"를 앞세울 가능성이 커. 크레딧 소모율이 불투명한 상태에서 예산에 민감한 SMB가 이탈할 여지가 여기 있어. 인터콤 Fin과 시에라(Sierra) 는 반대편에서 좁고 깊게 들어와. 고객 지원 한 영역에 집중해 해결률 자체를 성과 지표로 걸고, 성과 기반 과금으로 구매 저항을 낮춰. 허브스팟의 커스터머 에이전트가 이들과 정면으로 만나는 구간인데, "여러 에이전트를 조율한다"는 허브스팟의 장점이 단일 지원 영역에서는 그리 큰 차별점이 아니야.

같은 주에 나온 뉴스 하나가 또 다른 방향의 카운터를 보여줘. Ushur가 2026년 7월 22일 Ushur Agentic Platform(UAP) 출시를 발표했는데, 보험·은행·헬스케어 같은 규제 산업 전용으로 거버넌스를 처음부터 내장한 게 특징이야. 보험 보장 내용 변경, 클레임 진행, 은행 온보딩, 환자 케어 안내 같은 프로세스를 대화로 끝내는 게 아니라 실제 완결까지 밀어붙이는 걸 내세웠어. 허브스팟이 수평(모든 산업, 얕게)으로 넓히는 동안, 수직 플레이어들은 "규제 산업에서 감사 가능한 에이전트"라는 조건으로 파고들어. 규제가 빡센 업종에서는 범용 콘솔의 실행 로그로는 부족하다는 게 이들의 논리고, 이건 꽤 설득력 있는 반박이야.

젠데스크는 이미 확보한 티켓 데이터와 지식베이스를 방어선으로 써. 고객 지원만 놓고 보면 대화 이력의 깊이가 허브스팟보다 두꺼운 계정이 많거든. 결국 이 시장은 "누가 제일 좋은 에이전트를 만드느냐"가 아니라 "누구의 데이터 위에서 에이전트가 돌 것이냐"의 싸움으로 수렴하고 있어. 허브스팟의 답이 Smart CRM인 거고.

그래서 뭐가 달라지는데

개발자·기술 담당자 입장에서 제일 눈여겨볼 건 MCP 연동이야. 캔버스에서 MCP로 외부 시스템을 붙일 수 있다는 건, 허브스팟 안에서만 도는 자동화가 아니라 사내 시스템까지 건드리는 에이전트를 노코드 툴로 만들 수 있다는 뜻이거든. 편리한 만큼 위험해. 어떤 MCP 서버를 허용할지, 쓰기 권한을 어디까지 열지에 대한 정책을 지금 미리 정해 두지 않으면, 몇 달 뒤에 누가 언제 만들었는지 모를 에이전트가 프로덕션 데이터를 건드리고 있는 상황이 와. 슈퍼 어드민 활성화가 기본 게이트라는 점을 활용해서, 활성화 전에 승인·로깅 정책부터 문서화해 두는 게 순서야.

기업 담당자·운영 리더라면 계산기부터 꺼내야 해. 지금 계정에 크레딧이 얼마나 포함돼 있는지, 우리가 돌리려는 에이전트가 한 건 처리에 액션을 몇 번 쓰는지를 테스트 실행으로 먼저 측정해. 테스트가 무료라는 건 마케팅 문구가 아니라 실무적으로 제일 쓸모 있는 기능이야. 그리고 실행 한도를 걸 때는 "비용 상한"이 아니라 "이 에이전트가 멈추면 어떤 고객 경험이 깨지는가"를 기준으로 잡아. 고객 대면 에이전트와 내부 데이터 정리 에이전트의 한도 정책은 달라야 해.

투자자 관점에서는 매출 인식 구조의 변화가 포인트야. 시트 기반 SaaS는 예측 가능한 반복 매출이 강점이었고, 그래서 높은 배수를 받았어. 소비 기반 비중이 커지면 매출은 위로 열리지만 변동성도 같이 커져. 허브스팟이 새 SKU 없이 기존 등급에 크레딧을 얹는 방식을 택한 건, 도입 마찰을 줄이는 대신 "얼마나 실제로 소비되느냐"에 매출 성장을 거는 베팅이야. 앞으로 몇 분기 실적에서 봐야 할 건 에이전트 활성화 계정 수가 아니라 계정당 크레딧 소비 증가율이고, 그 수치를 회사가 공개하는지 여부 자체가 신호야.

일반 사용자 — 그러니까 어느 회사의 고객으로서 메일과 채팅을 받는 우리 입장에서는 두 가지가 갈려. 잘 굴러가면 "내가 어제 넣은 문의를 아는 상태로" 응대가 오게 돼. 지금처럼 부서마다 딴소리하는 경험이 줄어드는 거지. 반대로 잘못 굴러가면 전보다 훨씬 빠른 속도로, 훨씬 많은 양의 자동 연락을 받게 돼. 에이전트가 늘어난다고 커뮤니케이션이 정중해지는 건 아니거든. 결국 차이를 만드는 건 도구가 아니라 그 도구에 승인 단계를 걸어 둔 사람이야.

마지막으로 하나. 이번 발표에서 허브스팟이 성능 자랑을 거의 하지 않았다는 점이 흥미로워. 어떤 모델을 쓰는지, 벤치마크가 얼마인지 같은 얘기가 전면에 없어. 대신 "파편화", "공유된 컨텍스트", "한 워크스페이스"라는 단어가 반복돼. 에이전트 경쟁의 무게중심이 모델 성능에서 운영·거버넌스로 이동했다는 걸, 마케팅 카피 수준에서까지 확인할 수 있는 셈이야.

🥄 남은 궁금증 세 가지

— 그래서 나랑 무슨 상관이야? 지금 허브스팟을 안 쓰면 직접적인 영향은 없어. 다만 네 회사가 CRM 위에서 자동화를 굴리고 있다면, 앞으로 몇 분기 안에 "에이전트 몇 개를 어떤 규칙으로 조율할 거냐"는 질문을 받게 될 거야. 그때 필요한 건 도구 선택이 아니라 승인·로그 정책이라는 걸 미리 알아두면 편해.

— 크레딧 때문에 결국 더 비싸지는 거 아냐? 그럴 수도 있고 아닐 수도 있어. 액션 단가와 크레딧 소모율이 공개되지 않아서 지금 총액을 계산하는 건 불가능해. 다행히 테스트 실행은 크레딧을 안 먹으니까, 실제 시나리오를 돌려보고 소요량을 재본 다음에 판단하는 게 순서야. 단정하긴 일러.

— 에이전트가 사고 치면 누가 책임져? 설정한 쪽 책임이라는 게 계약서상 일반적인 답이지만, 실제로 규제 위반이 터졌을 때 실행 로그만으로 판단 경위를 재구성할 수 있을지는 아직 검증되지 않았어. 퍼블릭 베타 단계라 거버넌스 깊이에 대한 정보도 부족해. 고객 대면 액션에는 승인 단계를 걸어 두는 게 지금으로선 제일 현실적인 방어야.

참고 자료

수치는 발표 시점 기준이라 바뀔 수 있어.