Agent.ai 종료가 보여준 것: AI 에이전트는 ‘앱’에서 ‘업무 시스템’으로 흡수된다

AI 에이전트를 찾아 쓰고 직접 만들어보는 서비스였던 Agent.ai가 2026년 8월 22일 독립 플랫폼 운영을 종료했습니다. 서비스가 사라지는 대신, 그 아이디어와 기능은 HubSpot의 새로운 Agent Builder 안으로 들어갑니다.

Agent.ai 공식 안내에 따르면 지난 2년 동안 300만 명 이상이 플랫폼을 사용했고, 수천 명의 빌더가 에이전트를 만들었습니다. 기존 에이전트를 HubSpot에서 다시 만드는 과정을 안내하는 마이그레이션 도구와 데이터 내보내기 기능도 제공됩니다. Agent.ai 공식 전환 안내

이 소식은 “AI 에이전트 서비스 하나가 종료됐다”는 뉴스로만 보기 아쉽습니다. 오히려 에이전트 시장의 중심이 어디로 이동하고 있는지 보여주는 사건에 가깝습니다.

AI 에이전트의 다음 경쟁은 더 많은 에이전트를 나열하는 것이 아니라, 실제 데이터와 권한을 가진 업무 시스템 안에서 일을 끝내는 것입니다.

Agent.ai는 무엇을 바꾸려 했나

기존 소프트웨어의 출발점은 앱이었습니다. 이메일 앱, 캘린더 앱, 검색 앱을 각각 열고 사람이 직접 작업을 연결했습니다. Agent.ai는 이 연결의 주인공을 앱이 아니라 에이전트로 바꾸려 했습니다.

사용자는 에이전트를 발견하고, 필요한 작업을 실행하고, 직접 만든 에이전트를 공유할 수 있었습니다. 웹사이트를 만드는 것처럼 에이전트를 만드는 경험을 대중화하겠다는 접근입니다.

하지만 에이전트가 “쓸 만한 앱”을 넘어 “업무를 맡길 동료”가 되려면 발견성과 생성 편의성만으로는 부족합니다. 에이전트가 읽어야 할 고객 기록, 호출할 API, 수정할 데이터, 승인을 받아야 하는 행동이 필요합니다. 결국 에이전트는 독립된 섬보다 데이터와 권한이 이미 있는 업무 시스템 안에서 더 강하게 작동합니다.

챗봇과 업무 에이전트의 차이

챗봇의 기본 흐름은 비교적 단순합니다.

1
사용자 질문 → 모델 호출 → 답변

업무 에이전트는 다음과 같은 실행 루프를 가집니다.

1
2
3
4
5
6
7
사용자 목표
   ↓
컨텍스트 확인 → 계획 수립 → 도구·데이터 호출
   ↓             ↓
권한 검사    사람 승인 또는 정책 확인
   ↓
시스템 업데이트 → 결과 기록·검증

예를 들어 고객 문의에 답하는 에이전트라면 회사 정책 문서를 읽고, 고객의 최근 대화와 주문 상태를 확인하고, 답변 초안을 만든 뒤, 환불이나 계정 변경처럼 위험한 행동에는 승인을 요청해야 합니다. 마지막에는 처리 결과를 CRM이나 티켓 시스템에 남겨야 합니다.

이 과정에서 모델은 중요한 부품이지만 전체 제품은 아닙니다. 데이터 연결, 도구 호출, 권한, 승인, 감사 로그가 함께 있어야 에이전트가 실제로 일을 끝낼 수 있습니다.

왜 HubSpot Agent Builder인가

HubSpot은 Agent Builder를 “한 캔버스에서 에이전트, 액션, 핸드오프를 연결하는 도구”로 소개합니다. 별도 도구를 옮기거나 코드를 작성하지 않고, CRM에 이미 있는 연락처·거래·대화 데이터와 자체 지침·리소스를 이용해 에이전트를 만들 수 있다는 설명입니다. HubSpot Agent Builder 소개

핵심은 에이전트를 CRM 바깥의 별도 실행기로 두지 않는다는 데 있습니다.

독립 에이전트 플랫폼	업무 시스템 내 에이전트
에이전트를 찾아 실행	특정 레코드와 워크플로우에서 실행
사용자가 컨텍스트를 전달	CRM·문서·대화에서 컨텍스트를 불러옴
도구 연결을 별도로 구성	시스템에 연결된 액션을 재사용
결과를 대화창에서 확인	결과를 데이터와 프로세스에 기록
에이전트 사용량 중심	완료한 업무와 자동화 범위 중심

HubSpot 페이지에는 액션을 빌드 단계에서 승인하도록 설정하고, 신뢰가 쌓이면 자동 실행으로 전환할 수 있다고 적혀 있습니다. 한 건의 레코드에서 즉시 실행할 수도 있고, 전체 팀의 워크플로우에 반복 적용할 수도 있습니다. 이 기능들이 실제로 어떤 품질을 내는지는 각 조직의 데이터와 정책에 달려 있지만, 에이전트의 핵심 기능이 “답변 생성”에서 “통제된 실행”으로 이동하고 있다는 점은 분명합니다.

플랫폼 통합이 개발자에게 보내는 신호

Agent.ai의 전환은 에이전트가 실패했다는 뜻으로 단정하기 어렵습니다. Agent.ai가 공식적으로 밝힌 것은 아이디어가 HubSpot Agent Builder로 이어진다는 사실이지, 독립 플랫폼을 종료한 단일 원인까지는 아닙니다. 아래 해석은 이 공지와 Agent Builder의 기능을 바탕으로 한 시장 관찰입니다.

1. 모델보다 컨텍스트가 제품을 구분한다

같은 언어 모델을 사용해도 어떤 고객 기록과 내부 문서를 읽는지, 어느 시점의 데이터를 믿는지에 따라 결과는 달라집니다. 업무 시스템에 붙은 에이전트는 질문을 잘 만드는 것보다 올바른 컨텍스트를 안정적으로 전달하는 일이 중요합니다.

개발자는 모델 선택과 함께 다음을 설계해야 합니다.

어떤 데이터가 실시간으로 필요한가
검색 결과의 출처와 최신성을 어떻게 확인할 것인가
고객·직원·관리자별로 어떤 정보가 보이는가
도구 결과를 다음 단계에 어떤 구조로 전달할 것인가

2. 권한과 승인이 에이전트 UX가 된다

에이전트가 이메일 초안을 만드는 것과 실제로 발송하는 것은 전혀 다른 행동입니다. 고객 정보 조회와 환불 처리는 위험도가 다릅니다. 따라서 “자율성”을 한 번에 켜고 끄는 대신 행동별로 경계를 설정해야 합니다.

1
2
3
4
읽기: 자동 실행
초안 작성: 자동 실행 + 검토 가능
외부 발송: 사람 승인
금액·계정 변경: 정책 검사 + 사람 승인

이 구조는 에이전트가 느려지는 장치가 아니라, 어느 행동까지 믿을 수 있는지 제품 안에서 설명하는 방법입니다.

3. 에이전트의 가격은 토큰에서 ‘완료한 일’로 이동한다

HubSpot은 커스텀 에이전트가 설정한 액션을 완료할 때 HubSpot Credits를 사용한다고 안내합니다. 모든 제품이 같은 과금 방식을 택한다는 의미는 아니지만, 시장이 단순한 모델 호출량보다 “업무 한 건을 처리하는 데 얼마가 들었는가”를 보려 한다는 신호로 읽을 수 있습니다.

개발자가 측정해야 할 지표도 달라집니다.

성공한 업무 1건당 비용
업무 1건을 끝내기까지의 모델·도구 호출 수
사람 승인으로 넘어간 비율
실패 후 재시도 횟수
처리 결과가 원 시스템에 정확히 기록된 비율

에이전트가 토큰을 적게 썼더라도 업무를 끝내지 못하면 제품 비용은 줄지 않습니다. 반대로 몇 번 더 호출하더라도 한 번에 정확히 처리하면 실제 운영비가 낮아질 수 있습니다.

4. 마이그레이션과 데이터 이동성이 경쟁력이 된다

Agent.ai는 기존 에이전트를 HubSpot Agent Builder에서 다시 만드는 단계별 가이드와 데이터 내보내기 기능을 제공합니다. 이는 플랫폼이 바뀔 때 사용자가 자신의 프롬프트·지식·구성·기록을 얼마나 가져갈 수 있는지가 중요해졌다는 뜻이기도 합니다.

에이전트를 설계하는 개발자라면 특정 UI에만 종속된 설정을 최소화하고, 다음 자산을 버전 관리하는 편이 안전합니다.

시스템 지침과 정책 문서
도구 스키마와 권한 목록
입력·출력 JSON 계약
평가용 테스트 케이스와 실패 사례
모델·프롬프트·워크플로우 변경 이력

지금 에이전트를 만드는 팀을 위한 체크리스트

독립 플랫폼을 선택할지 CRM·헬프데스크·개발 도구 안에 에이전트를 넣을지는 조직마다 다릅니다. 어느 쪽이든 다음 질문에 답할 수 있어야 합니다.

에이전트가 읽을 수 있는 데이터의 범위는 어디까지인가?
자동 실행 가능한 액션과 승인이 필요한 액션을 분리했는가?
실패·재시도·타임아웃·사람 인계 조건을 정의했는가?
결과와 근거를 원 시스템에 남기는가?
품질을 답변의 자연스러움이 아니라 업무 완료율로 평가하는가?
프롬프트와 도구 구성을 다른 런타임으로 옮길 수 있는가?
한 업무가 끝날 때까지 발생한 모델·검색·도구 비용을 계산하는가?

이 체크리스트는 특정 제품을 선택하기 위한 점수표가 아닙니다. 에이전트를 데모가 아니라 운영 가능한 소프트웨어로 다루기 위한 최소 조건에 가깝습니다.

결론: 에이전트는 사라지는 것이 아니라 자리를 옮긴다

Agent.ai의 독립 플랫폼 종료는 에이전트 열풍의 끝이라기보다, 에이전트가 자리 잡을 곳이 바뀌고 있다는 신호입니다. 에이전트 디렉터리와 생성 도구에서 시작한 경험이 CRM, 헬프데스크, 개발 환경, 데이터 플랫폼 안으로 흡수되고 있습니다.

앞으로의 경쟁은 “누가 가장 똑똑하게 말하는가”만으로 결정되지 않을 것입니다. 누가 더 정확한 컨텍스트를 가져오고, 누가 행동의 권한을 안전하게 제한하며, 누가 한 업무를 끝까지 추적하고 비용까지 설명할 수 있는지가 중요해집니다.

개발자에게 남는 질문은 하나입니다.

우리의 에이전트는 답을 잘하는가, 아니면 실제 시스템을 안전하게 바꾸고 그 결과를 증명하는가?