2026년 7월 1일, Salesforce는 Summer 26 릴리스에 Slack First Sales를 포함했습니다. 핵심을 한 문장으로 요약하자면, 영업 사원이 리드(Lead) 및 거래(Deal)와 관련된 업무의 일부를 매번 작은 작업을 위해 CRM에 접속하는 대신, Slack의 대화형 인터페이스(Dialog Interface)에서 직접 수행하도록 제안하는 것입니다. 이는 단순히 연락처 카드의 디자인을 바꾸는 수준이 아니라, 영업 사원의 루틴이 머무는 주요 장소를 바꾸겠다는 선언입니다.

만약 당신이 거래 단계를 변경하거나, 메모를 남기거나, 리드의 상태를 확인하기 위해 수년간 Salesforce를 열어왔다면 익숙한 고통을 느끼고 있을 것입니다. 영업 사원이 CRM에서 많은 시간을 보내는 이유는 그곳이 편리해서가 아니라, 그곳이 '진실의 원천(Source of Truth)'이기 때문입니다. Slack First Sales는 이를 뒤집으려 시도합니다. 즉, 대화가 진입점(Point of Entry)이 되고, CRM은 백엔드에서 기록을 담당하는 시스템으로 남는 것입니다.

차분하고 실질적으로 분석해 보겠습니다. 무엇이 실제로 영업 사원의 일상을 바꾸는지, 무엇이 아직 벤더의 약속으로 남아 있는지, 그리고 당신의 팀이 이를 검토할 가치가 있는지 결정하는 방법을 알아보겠습니다. 팀이 이미 여러 명의 어시스턴트(Assistant)와 함께 생활하고 있을 때는, 어디서 하나의 채팅 인터페이스가 끝나고 모델과 직접 작업하는 것이 시작되는지를 미리 이해하는 것이 유용합니다. 인터페이스와 데이터 소스를 혼동하지 않기 위해서 말입니다.

Summer 26에서 정확히 무엇을 발표했나요?

Salesforce의 발표에 따르면, Slack First Sales는 분기별 릴리스인 Summer 26의 구성 요소로 포함됩니다. 여기서 즉시 주의해야 할 점은, 7월은 배포(Rollout) 기간을 의미하며 유일한 공개일이 아니라는 것입니다. Salesforce 릴리스의 기능은 파도처럼 순차적으로 도입되며, 에디션(Edition)과 지역(Region)에 따라 달라집니다. 따라서 이 글을 읽은 후 가장 먼저 해야 할 일은 환호하는 것이 아니라, 귀하의 에디션과 지역에서 사용 가능한지 확인하는 것입니다.

편집자적 관점에서 제안의 핵심은 이렇습니다. 영업 담당자는 Slack 내에서 리드(Lead) 및 거래(Deal)와 관련된 작업 시나리오를 받게 됩니다. 즉, 사소한 변화가 생길 때마다 별도의 CRM 창으로 전환할 필요 없이, Slack 안에서 맥락을 확인하고, 변경 사항을 기록하며, 업무를 다음 단계로 진행할 수 있다는 것입니다. Salesforce는 영업 담당자들이 이미 많은 시간을 보내는 Slack을 하나의 '표면(Surface)'으로 포지셔닝하고 있으며, 단순히 알림만 보내는 것이 아니라 실제 작업 자체를 그곳으로 끌어오는 것이 논리적이라고 보고 있습니다.

여기서 우리는 두 가지 층위를 엄격히 구분해야 합니다. 첫 번째는 벤더(Vendor)의 발표입니다. 'Slack First Sales'가 존재하며 Summer 26에 포함된다는 것은 1차 출처에서 확인된 사실입니다. 두 번째는 이것이 실제 현장에서 어떻게 느껴지는지, 그리고 실제로 어떤 작업 세트가 사용 가능한가 하는 점입니다. 이는 구성(Configuration)에 따라 달라지므로, 정확한 목록은 개요 기사가 아닌 소속 조직의 릴리스 노트(Release Notes)를 통해 확인해야 합니다. 아래에서 저는 이 경계를 유지하며, 어디까지가 사실이고 어디서부터가 합리적인 추론인지를 명확히 표시하겠습니다.

벤더가 아닌 커뮤니티로부터도 별도의 신호가 오고 있습니다. r/salesforce에서는 더 넓은 질문, 즉 Slack이 전반적인 기업용 AI 인터페이스(AI Interface)로 변모하고 있는 것은 아닌지에 대해 논의하고 있습니다. Slack First Sales는 이러한 트렌드의 개별적이면서도 주목할 만한 사례입니다. 즉, 업무가 전문화된 화면에서 대화(Dialogue)로 이동하고 있다는 것입니다. 이는 제조사의 약속이 아닌 독립적인 관찰이며, 시장의 분위기로 받아들여야 합니다.

어떤 작업이 실제로 채팅으로 이동하고, 어떤 작업이 CRM에 남는가?

여기서 "이제 모든 것이 Slack에 있다"라는 마케팅적 충동에 휩쓸리지 않는 것이 중요합니다. 현실적인 모습은 더 복잡하며, 기능 목록이 아닌 기준, 즉 어떤 작업이 대화 속에서 수행하는 것이 의미가 있는가라는 기준으로 생각하는 것이 더 올바릅니다.

짧고, 빈번하며, 리스크가 낮은 작업들은 채팅에 잘 어울립니다. 전화하기 전 딜(deal)의 맥락을 빠르게 훑어보는 것, 대화 결과를 메모로 남기는 것, 명확한 다음 단계로 진행하는 것 등이 이에 해당합니다. 이전에는 CRM에서 한 번의 화면 전환과 세 번의 클릭이 필요했던 모든 작업이, 대화 속에서는 맥락 전환(context switching)을 줄여줍니다. 그리고 이 맥락 전환이야말로 영업 사원의 주의력에 부과되는 가장 큰 세금입니다.

반면, 촘촘한 필드 그리드(grid), 대량 편집(mass editing), 수십 개의 레코드 대조, 복잡한 권한 및 감사(audit)가 필요한 작업은 채팅에 적합하지 않습니다. 파이프라인(funnel) 설정, 중복 데이터 정리, 프로세스 구성, 포트폴리오 보고서 작성 등은 CRM의 넓은 화면에서 수행해야 하는 작업이며, 이를 좁은 대화창으로 몰아넣는 것은 부자연스럽습니다. 대화는 200행짜리 표가 아니라, 하나의 객체(object)에 집중할 때 유용합니다.

여기서 간단한 규칙이 도출됩니다. Slack First Sales는 Salesforce를 대체하는 것이 아니라, 동일한 데이터에 접근하는 또 다른 입구입니다. 진실의 원천(Source of truth)은 여전히 CRM에 있습니다. 대화는 단지 가장 빈번한 마이크로 액션(micro-actions)에서 발생하는 마찰을 제거할 뿐입니다. 만약 팀에게 이를 "이제 CRM은 필요 없습니다"라고 판매한다면, 누군가 제대로 된 보고서를 요청하는 바로 그 순간 실망을 맛보게 될 것입니다.

이러한 접근 방식을 CRM 외부에서 이미 어시스턴트(assistant)를 사용하는 방식과 비교해 보는 것이 유용합니다. 만약 팀이 모델을 통해 이메일 초안을 작성하고, 대화 내용을 요약하며, 딜에 대한 논거를 준비하고 있다면, 이러한 모델들이 다섯 개의 분산된 구독 서비스가 아니라 한 곳에서 접근 가능하고 하나의 결제 잔액으로 관리될 때 매우 편리할 것입니다. provod.ai는 여기서 Claude, GPT, Gemini, DeepSeek, Qwen에 대한 접근을 하나의 채팅과 하나의 API로 통합하는 역할을 수행하며, CRM이나 자동화 플랫폼의 역할을 자처하지 않습니다. 이는 서로 다른 계층의 과제입니다.

CRM 옆에 있는 엔지니어에게는 이것이 어떻게 보일까요?

핵심적인 기술적 질문은 이것입니다: '신뢰할 수 있는 단일 원천(Source of Truth)'은 어디에 남으며, 어떻게 로직이 두 곳으로 분산되는 것을 방지할 것인가? 발표된 내용에 따른 답변은 다음과 같습니다. Salesforce는 기록 시스템(System of Record)으로 남고, Slack은 상호작용 계층(Surface of Interaction)이 됩니다. 즉, 모든 통합(Integration)은 계속해서 CRM 데이터로 향하며, 대화가 상태를 저장하는 두 번째 병렬 저장소가 되지 않습니다.

만약 당신이 거래(Deal)를 중심으로 자동화를 구축하고 있다면, 대화 계층을 새로운 데이터베이스가 아닌 동일한 API의 또 다른 클라이언트로 취급하는 것이 합리적입니다. 아래는 원리를 보여주는 예시적인 안전한 의사코드(Pseudocode)입니다. 이는 Slack First Sales의 내부 동작을 설명하는 것이 아니라, 대화에서의 동작이 여전히 유일한 신뢰할 수 있는 원천으로서 CRM에 기록된다는 원칙을 보여줍니다.

# 원리 예시: 대화 -> 동작 -> 기록 시스템 (CRM)
def handle_dialog_action(event):
    intent = classify(event.text)        # "메모 남기기", "단계 변경"
...

이러한 프레임워크는 그 어떤 마케팅 문구보다 정직합니다. 경계를 명확히 코드로 구현하기 때문입니다. 위험도가 낮은 짧은 동작은 대화에서 실행되어 CRM에 기록됩니다. 범위가 넓은 작업은 명확하게 전체 인터페이스로 돌아갑니다. 로직을 이렇게 구축한다면, "두 개의 진실이 존재하고 서로 일치하지 않는다"는 전형적인 재앙을 피할 수 있습니다.

그리고 생성형 계층(Generative Layer)은 별도로 염두에 두어야 합니다. 고객에 대한 답변 작성, 통화 요약, 제안서 초안 작성 등은 CRM의 역할이 아니라 언어 모델(Language Model)의 작업입니다. 이때 OpenAI 및 Anthropic의 SDK와 호환되면서 키(Key)와 base_url만 변경하면 되는 단일 API를 통해 모델에 접근할 수 있다면 편리합니다:

from openai import OpenAI

client = OpenAI(
...

이렇게 하면 책임이 분리됩니다. Salesforce는 거래의 상태를 책임지고, 대화 계층은 편리한 입력 창구를 책임지며, 생성형 모델은 텍스트를 책임집니다. 세 가지 역할, 세 가지 영역, 혼란은 없습니다.

이것이 실패하는 지점과 해결하지 못하는 것은 무엇인가?

첫 번째이자 가장 큰 리스크는 개념의 혼동입니다. 대화형 인터페이스는 사소한 부분에서의 마찰(friction)을 아름답게 제거해주지만, 이로 인해 CRM이 더 이상 필요하지 않다고 선언하고 싶은 유혹에 빠지게 만듭니다. 세 번의 클릭을 하는 데에는 필요 없을지 모릅니다. 하지만 보고(reporting), 권한(permissions), 감사(audit), 대량 작업(mass operations) 등 그 외의 모든 것에는 여전히 필요합니다. Slack First Sales는 Salesforce를 폐지하는 것이 아니라, 가장 빈번한 작업들의 진입점(entry point)을 바꾸는 것입니다.

두 번째 리스크는 가용성(availability)입니다. 다시 한번 주의사항을 말씀드리자면, 7월은 Summer 26의 윈도우(window)일 뿐, 모든 사용자에게 보장된 GA(General Availability) 날짜가 아닙니다. 본인의 릴리스 노트(release notes)를 통해 에디션(edition)과 지역(region)을 확인하십시오. 아직 본인의 에디션에 없는 기능을 바탕으로 프로세스를 계획하는 것은 팀을 실망시키는 확실한 방법입니다.

세 번째 리스크는 진실의 파편화(fragmentation of truth)입니다. 만약 대화 계층(dialogue layer)이 CRM과 별개로 자체적인 상태(state)를 유지하기 시작한다면, 결국 머지않아 서로 어긋나게 될 두 개의 소스를 갖게 될 것입니다. 유일한 방어책은 규율(discipline)입니다. CRM은 기록 시스템(system of record)으로 남아야 하며, 대화는 오직 CRM에 쓰고 읽기만 해야 합니다.

Slack First Sales가 확실히 해결해주지 못하는 것들입니다. 이 기능은 당신을 대신해 파이프라인(funnel)과 프로세스를 구축해주지 않습니다. 그것은 CRM 설정의 영역입니다. 또한 자동화 플랫폼, 프라이빗(private) 또는 온프레미스(on-prem) 인프라, 산업별 통합(industry integrations), 그리고 모든 구축(implementation) 작업을 대체하지 않습니다. 그리고 제대로 설정되지 않은 CRM 위에 편리한 대화창을 얹는다고 해서, 그것이 '제대로 설정되지 않은 CRM 위의 편리한 대화창'이라는 사실이 변하지는 않습니다. 도구는 마찰을 줄여줄 뿐, 당신을 대신해 데이터의 질서를 잡아주지는 않습니다.

환상을 방지하기 위해 생성형(generative) 부분에 대해 별도로 언급하겠습니다. provod.ai는 Claude, GPT, Gemini, DeepSeek, Qwen을 하나의 채팅창에 통합하여 단일 API를 제공하며, VPN이나 해외 카드 없이도 러시아 카드, SBP 또는 계좌 이체를 통해 결제하고 계약서, 송장, 영수증 등의 증빙 서류를 받을 수 있습니다. 하지만 이것이 자동화 플랫폼, 프라이빗 인프라, 그리고 벤더(vendor)들의 구독형 기능을 대체하는 것은 아닙니다. 이것은 모델에 대한 접근이지, CRM도 구축도 아닙니다.

당신의 팀이 지금 참여할 가치가 있을까?

세 가지 질문으로 결정하세요. 해당 기능이 귀하의 에디션 (edition) 및 지역에 있습니까? 팀이 이미 Slack에서 충분히 활동하고 있어 대화를 통한 진입이 실제로 컨텍스트 스위칭 (context switching)을 줄여줄 수 있습니까? CRM을 유일한 진실 공급원 (single source of truth)으로 유지할 준비가 되었습니까, 아니면 데이터가 두 저장소로 분산되는 것을 방치하게 될까요? 세 가지 모두 "예"라면, 메모 작성이나 단계 변경과 같은 좁은 시나리오에 대해서만 파일럿 (pilot)을 시도해 보세요. 단 하나라도 "아니오"라면, 기다리면서 릴리스 노트 (release notes)와 r/salesforce에서의 논의를 지켜보세요.

말싸움을 피하기 위해 간결한 결정 테이블을 아래에 정리했습니다.

이 테이블은 의도적으로 지루하게 작성되었습니다. 여기에는 "전환율이 몇 퍼센트 상승할 것"이라는 식의 약속은 없습니다. 원문에 그런 수치가 없으며, 저는 이를 지어내지 않을 것입니다. 오직 적용 범위(boundaries of applicability)만이 존재하며, 바로 이것이 도입 비용을 절감해 주는 핵심입니다.

FAQ

Slack First Sales가 Salesforce를 대체하나요?
아니요. Salesforce의 발표에 따르면 Salesforce는 기록 시스템 (system of record)으로 남습니다. 대화는 빈번한 작업에 대한 진입점 (entry point)을 바꾸는 것이지만, 보고서, 권한, 대량 편집 및 프로세스 설정은 CRM에 그대로 유지됩니다.

언제부터 모두가 사용할 수 있나요?
원문은 정확한 단일 GA (General Availability) 날짜를 제공하지 않습니다. 2026년 7월은 Summer 26 릴리스 윈도우입니다. 가용성은 에디션 (edition)과 지역에 따라 다르므로, 귀하의 릴리스 노트를 통해 확인하십시오.

제3자의 의견은 어떠한가요?
r/salesforce에서는 Slack이 주요 기업용 AI 인터페이스가 될 것인지에 대해 논의하고 있습니다. 이는 커뮤니티의 분위기이자 트렌드에 대한 관찰일 뿐, 벤더 (vendor)의 약속이 아닙니다.

어떤 작업들을 먼저 대화형으로 전환하는 것이 좋을까요?
짧고, 빈번하며, 리스크가 낮은 작업들입니다: 빠른 메모 작성, 통화 전 컨텍스트 확인, 명확한 단계 변경 등입니다. 범위가 넓고 리스크가 큰 모든 작업은 CRM에 남겨두세요.

어떻게 하면 두 개의 진실의 원천 (two sources of truth)을 방지할 수 있을까요?
경계를 명확하게 코딩하세요: 대화는 오직 CRM에 기록하고 CRM으로부터 읽어오기만 하며, 별도의 자체 상태 (state)를 유지하지 않습니다. CRM이 유일한 기록 시스템 (system of record)입니다.