Salesforce, '에이전트 알버트'로 AI가 기업 소프트웨어를 끝내지 않을 것이라고 주장

세일즈포스가 공개한 "Agent Albert"는 기업용 CRM/마케팅 워크플로우에 특화된 에이전트 기반 AI 제품이다. 기존 SaaS가 사람이 UI를 클릭해 데이터를 입력·조회하는 구조였다면, Agent Albert는 LLM 기반 에이전트가 세일즈포스 플랫폼(Data Cloud, Sales Cloud, Marketing Cloud)의 API와 메타데이터에 직접 접근해 캠페인 생성·리드 스코어링·고객 세그먼트 분석 같은 작업을 자동 실행한다. 핵심은 "agentic workflow"로, ReAct 유형의 추론-도구 호출 루프 위에 RAG(세일즈포스 Data Cloud 기반 고객 데이터 검색)와 가드레일(권한·데이터 접근 정책)이 결합된 형태다. 벤치오프가 함께 도입한 자체 지표는 "에이전트가 실행한 작업량"을 시트 수가 아닌 "처리된 대화/작업 수" 기반으로 측정하려는 시도로, 시트 단위 SaaS 과금 모델이 에이전트 시대에 더 이상 유효하지 않다는 업계 인식을 반영한다.

월가의 우려는 단순하다. "고객이 LLM 위에 직접 에이전트를 만들면 세일즈포스 같은 미들웨어가 왜 필요한가?"라는 질문이다. Benioff의 응답은 "데이터 그래비티"다. 20년치 고객 데이터, 권한 모델, 감사 로그, 수천 개의 통합(integration)은 단순히 GPT-5나 Claude를 붙인다고 재현되지 않는다. 개발자 관점에서 이는 두 가지 실질적 변화를 의미한다. 첫째, Apex/LWC 같은 전통적 세일즈포스 개발보다 Agentforce SDK, Prompt Builder, Atlas Reasoning Engine을 활용한 에이전트 설정·튜닝 역량이 더 중요해진다. 둘째, 기업 내부 시스템과 연동할 때 MCP(Model Context Protocol) 유사 도구 스펙, 함수 호출 스키마 설계, 에이전트 실패 시 롤백 전략 같은 "에이전트 엔지니어링" 스킬이 신규 요구사항으로 떠오른다.

한국 개발자에게 주는 시사점은 명확하다. 국내 SaaS·SI 업계도 동일한 압박을 곧 받게 된다. 자체 서비스에 에이전트를 얹을 때 반드시 확보해야 할 것은 ① 구조화된 도메인 데이터(벡터 DB만으로는 부족하며 관계형·그래프 구조 필요), ② 세밀한 RBAC/ABAC 권한 체계(에이전트가 사용자 권한을 넘어서 데이터에 접근하지 못하도록), ③ 작업 단위 계측·과금 인프라(세일즈포스의 "Conversation" 기반 지표처럼 자사도 에이전트 작업량 정의 필요)다. 또한 에이전트가 사이드이펙트를 만드는 작업(이메일 발송, 결제, DB 쓰기)을 수행할 때는 반드시 human-in-the-loop 체크포인트나 dry-run 모드를 제공해야 한다.

실무적으로 지금 당장 확인할 액션은 세 가지다. 첫째, 자사 제품의 API가 에이전트 친화적인지 점검하라 — 대부분의 REST API는 사람용으로 설계되어 있어 LLM이 호출하기엔 파라미터가 모호하거나 멱등성 보장이 없다. 둘째, OpenAI Function Calling, Anthropic Tool Use, MCP 중 최소 한 가지 표준을 기준으로 자사 도구 스펙을 작성해두라. 셋째, 세일즈포스가 내놓은 "소비 기반(consumption-based) 과금 지표"의 정의 방식을 추적하라 — Agentforce의 Conversation당 $2 모델이 업계 표준이 된다면, 국내 B2B SaaS의 per-seat 모델도 1~2년 내 재설계가 불가피하다.