Salesforce가 AI 로드맵을 사실상 고객과 함께 만들고 있다. 일부 고객과는 주 단위로 만나고, 그 피드백을 바탕으로 Agentforce, 음성 AI, Slack 연계 기능 같은 제품을 빠르게 다듬는 방식이다.1 중요한 건 "다음에 무엇이 나오나"보다, 이 로드맵이 각 AI 기능의 성숙도와 위험도를 어떻게 드러내느냐다.
지금 이게 중요한 이유는 간단하다. 엔터프라이즈 AI는 출시 속도보다 운영 가능성이 더 중요해졌기 때문이다. Salesforce는 이미 생성형 AI에서 에이전트형 AI로 무게중심을 옮겼고, 그 과정에서 Trust Layer, Data Cloud, 관찰 가능성, 결정론적 제어 같은 요소를 전면에 내세우고 있다.23 즉, 로드맵은 홍보 자료가 아니라 "어떤 AI가 플랫폼 기본값이 되어가고 있는가"를 읽는 지도에 가깝다.
이제 로드맵은 출시 일정표가 아니라 '확신 지도'다
확인된 사실부터 보자. Salesforce는 제품 일정보다 테마 중심으로 AI를 전개하고 있다고 밝혔다. 핵심 테마는 agent context, observability, deterministic controls 같은 운영 레이어다.1 이건 단순한 기능 추가가 아니다. LLM만으로는 안 되는 마지막 1마일을 플랫폼이 메우겠다는 뜻이다.
이 변화는 왜 중요할까. 과거의 Salesforce AI는 이메일 작성, 요약, 추천 답변처럼 화면 안에서 생산성을 높이는 보조 기능이 많았다. 실제로 2023년 AI Cloud 로드맵도 이메일 생성, 케이스 요약, 세그먼트 생성처럼 비교적 좁고 워크플로우에 붙는 기능이 중심이었다.2 반면 지금의 방향은 "도와주는 AI"에서 "실행하는 AI"로 이동했다. Salesforce 공식 메시지도 2024년 이후 Agentforce와 에이전트형 운영을 전면에 배치한다.3
실무적으로는 이렇게 읽는 편이 낫다. 기존 CRM 데이터와 프로세스 가까이에 붙은 AI는 비교적 안정적인 투자 신호다. 반대로 여러 시스템을 넘나들며 자율 실행해야 하는 기능은 아직 데이터 품질, 권한, 책임 경계가 더 중요하다. 로드맵에 있다고 해서 같은 무게로 보면 안 된다.
파일럿, 보류, 우회: Salesforce AI를 고르는 현실적 기준
구매자나 운영팀은 각 기능을 세 갈래로 보면 된다.
먼저 바로 써볼 만한 것은 요약, 답변 추천, 영업 메일 초안처럼 이미 있는 CRM 워크플로우에 얹히는 기능이다. 필요한 데이터 소스가 비교적 명확하고, 사람 검토를 끼워 넣기 쉽다. 이런 영역은 실패 비용도 낮다.2
둘째, 보류가 필요한 것은 에이전트형 자동화다. 특히 음성, 서비스 오케스트레이션, 부서 간 작업 실행처럼 여러 시스템과 정책을 건드리는 기능이 여기에 들어간다. Salesforce가 observability와 deterministic controls를 강조하는 이유도 이 구간의 리스크가 크기 때문이다.1 기술보다 운영 소유권이 먼저 정리돼야 한다.
셋째, 우회가 더 나은 경우도 있다. 특정 팀의 국소 문제를 푸는 데는 Salesforce 기본 기능보다 전문 SaaS나 독립형 AI 도구가 더 빠를 수 있다. Salesforce 안에서 모든 AI를 해결하려는 생각은 비용과 속도 모두에서 비효율적일 수 있다. 특히 데이터가 아직 Data Cloud 수준으로 정리되지 않았다면 더 그렇다.3
핵심은 "신기한가"가 아니라 "우리 데이터와 책임 구조 안에서 굴러가나"다.
관리자, 아키텍트, RevOps가 달라져야 하는 지점
관리자에게 가장 큰 변화는 설정 자체보다 가드레일이다. 예전에는 필드, 권한, 자동화 규칙이 중심이었다면 이제는 어떤 프롬프트와 데이터 접근이 허용되는지, 인간 검토 단계를 어디에 둘지가 더 중요해진다.
아키텍트는 더 복잡해진다. 에이전트형 AI는 UI 기능이 아니라 데이터 계층, 통합, 정책 집행, 로그 추적이 얽힌 시스템 문제다. Salesforce가 Data Cloud와 Trust Layer, 외부 모델 연동, MCP 같은 상호운용성을 함께 말하는 이유도 여기에 있다.3
RevOps는 경계를 다시 그어야 한다. 워크플로우 자동화는 "정해진 규칙 실행"이었지만, AI 의사결정은 예외와 불확실성을 품는다. 따라서 KPI도 달라진다. 단순 처리량보다 승인율, 수정률, 에이전트 개입 후 전환율 같은 지표가 중요해진다.
물론 반론도 있다. 고객 피드백 중심 개발은 단기 수요에 과적합될 위험이 있다. 베타 고객이 원하는 것이 곧 장기 플랫폼 표준은 아닐 수 있다. TechCrunch 보도도 이 한계를 짚었다.1 그래서 로드맵을 읽을 때는 "얼마나 자주 언급되는가"보다 "Salesforce가 이를 공통 플랫폼 레이어로 승격시키는가"를 봐야 한다.
먼저 켜는 회사보다, 제대로 붙이는 회사가 이긴다
가장 역설적인 결론은 여기 있다. Salesforce AI 시대의 승자는 얼리어답터가 아니라 통합을 잘하는 조직일 가능성이 높다.
Engine처럼 주간 피드백 루프에 들어가 기능을 다듬는 고객도 있고, PenFed처럼 내부에서 만든 Agentforce 워크플로우가 제품화된 사례도 있다.1 하지만 이런 성공은 기능 접근 권한 때문만이 아니라, 문제 정의와 운영 맥락이 분명했기 때문에 가능했다.
그래서 지금 신경 써야 할 사람은 두 부류다. Salesforce를 이미 깊게 쓰는 기업의 관리자·아키텍트·RevOps 리더, 그리고 새 AI 예산을 잡아야 하는 IT 의사결정자다. 이들이 봐야 할 것은 로드맵의 화려함이 아니다. 각 기능이 기존 CRM 데이터에 얼마나 가깝고, 통제 가능한 운영 구조 안에 들어오는지다. Salesforce AI 로드맵은 미래 예고편이 아니라, 무엇을 지금 파일럿하고 무엇을 아직 기다려야 하는지 알려주는 위험 신호 체계에 더 가깝다.
참고
1Salesforce is crowdsourcing its AI roadmap -- with customers
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.