2025년 10월 03일·7분
마크 베니오프와 세일즈포스: SaaS CRM에서 구독형 유틸리티로
마크 베니오프와 세일즈포스가 SaaS CRM을 대중화하고 플랫폼 생태계를 구축해 엔터프라이즈 소프트웨어를 구독형 유틸리티로 바꾼 과정을 알아보세요.
마크 베니오프와 세일즈포스가 SaaS CRM을 대중화하고 플랫폼 생태계를 구축해 엔터프라이즈 소프트웨어를 구독형 유틸리티로 바꾼 과정을 알아보세요.
세일즈포스의 기원 이야기는 기업이 소프트웨어를 구매하고 운영하며 확장하는 방식에 있었던 구체적 전환을 보여준다는 점에서 유용합니다. 즉, 설치·유지하는 일회성 구매에서 구독하고 지속적으로 개선되는 서비스로의 변화입니다.
이 글은 CRM을 렌즈로 사용합니다. CRM이 화려해서가 아니라 매출과 가깝기 때문입니다. 리드·딜·고객 이력이 더 쉽게 도입되고 최신 상태로 유지되면 팀이 팔고, 서비스하고, 보고하는 속도가 바뀝니다.
마크 베니오프가 그 변화를 만든 것은 CRM을 발명해서가 아니라 몇 가지 초기 선택 덕분이었습니다 — CRM을 웹으로 제공하고, 구독으로 가격을 매기고, 업그레이드를 공급자가 중앙에서 처리하도록 한 점입니다. 타이밍도 중요했습니다: 인터넷 접속이 업무에서 보편화되고 있었고, 기업들은 비용이 많이 들고 느린 소프트웨어 롤아웃에 지쳐 있었습니다.
간단한 언어로 다음을 이해하게 될 것입니다:
구독형 유틸리티는 소프트웨어가 상자에 담긴 도구라기보다 전기처럼 동작한다는 뜻입니다. 소유하지 않고 안정적으로 접근합니다. 가용성, 보안, 시간이 지나도 개선되는 것을 기대하며, 공급자가 인프라·업데이트·스케일링을 배경에서 운영합니다.
고객관계관리(CRM) 소프트웨어는 회사가 고객 상호작용의 ‘살아 있는 기록’을 보관하는 곳입니다 — 고객이 누구인지, 무슨 대화가 있었는지, 무엇이 약속되었는지, 다음에 무엇을 해야 하는지. 사람들은 종종 CRM을 데이터베이스라고 하지만, 실제로 고객이 구매하는 것은 더 실용적인 것들입니다: 놓치는 업무 감소와 더 명확한 책임소재입니다.
영업팀은 CRM으로 파이프라인을 추적합니다: 리드, 딜, 단계, 다음 행동, 예상 종료일. 담당자는 계정을 보고 통화·이메일을 기록하고 후속 조치를 설정해 기억이나 흩어진 메모에 의존하지 않을 수 있습니다.
서비스팀은 CRM으로 케이스와 응답을 관리합니다. 고객이 연락하면 지원팀은 이전 이슈·구매·대화를 확인해 고객이 같은 내용을 반복하지 않도록 합니다.
마케팅팀은 CRM 데이터를 세분화하고 실제로 수익에 영향을 준 캠페인을 측정하는 데 사용합니다(단순 클릭이 아니라).
전통적 설치형 CRM은 서버 구매, 구현 일정, IT의 변경 지원 대기가 필요했습니다. 업그레이드는 큰 이벤트였고, 종종 커스터마이징을 깨뜨릴 위험 때문에 지연되곤 했습니다. 시간이 지나며 팀은 구버전에 갇히게 되고 데이터 품질 문제와 일관성 없는 프로세스가 생겼습니다.
리더십은 가시성을 원합니다: 믿을 수 있는 정확한 예측, 전환율, 보고서.
현장 영업은 사용 편의성을 원합니다: 빠른 데이터 입력, 필수 필드 최소화, 명확한 일일 할 일 목록.
관리자와 IT는 통제를 원합니다: 예측 가능한 권한, 깨끗한 데이터 규칙, 시스템이 최신을 유지하기 위해 계속 유지관리될 필요가 없는 것.
좋은 CRM은 이들 업무를 더 쉽게 만들어 ‘CRM을 업데이트하는 것’ 자체가 일이 되지 않게 해야 성공합니다.
SaaS(Software as a Service)는 공급자가 서버·스토리지·보안 패치·업그레이드를 운영하는 동안 브라우저나 앱을 통해 접속하는 소프트웨어입니다. 로그인해서 사용하면 제공자가 과거에 사무실이나 호스팅 계약에서 관리하던 뒷단 작업을 처리합니다.
설치형 소프트웨어(구 모델)는 DVD 플레이어를 사는 것과 비슷합니다: 버전별로 선불 지불하고 기계에 설치하며 업그레이드는 별도 구매나 프로젝트입니다. 많은 기업은 여기에 하드웨어, 백업, IT 시간을 추가로 구매해 유지했습니다.
구독형 소프트웨어는 전기나 헬스클럽 회원권을 내는 것과 비슷합니다: 정기적으로 지불하고 항상 최신 서비스를 이용합니다. 가격은 일반적으로 사용자당 월/연 단위로 매겨지며, 기능이나 저장공간에 따라 계층이 존재합니다.
SaaS는 보통 며칠 내에 가동될 수 있습니다 — 몇 달이 아닌 경우가 많습니다. 비용은 분산되어 예측 가능해지고, 대규모 ‘업그레이드 주말’ 없이 업데이트가 지속적으로 도착합니다. 팀은 어디서든 로그인할 수 있어 외근 영업과 서비스 업무에 유리합니다.
SaaS가 마찰이 전혀 없는 것은 아닙니다. 인터넷 연결에 의존해야 하고 일부 산업은 데이터 거주 요구사항 때문에 저장 위치가 제한될 수 있습니다. 또한 벤더 종속(lock-in) 위험이 있습니다: 데이터·워크플로·통합이 한 시스템에 들어가면 전환 비용이 커질 수 있으므로 내보내기, API, 계약 조건을 초기에 확인하는 것이 중요합니다.
세일즈포스는 더 넓은 변화와 함께 성장했습니다: 기업들이 단순한 ‘있으면 좋은’ 도구가 아니라 중요한 업무에 호스팅된 웹 애플리케이션을 신뢰하기 시작했습니다. 박스에 담긴 소프트웨어를 사서 서버에 설치하고 수년마다 업그레이드하는 대신, 브라우저로 로그인해 빠르게 가치를 얻을 수 있게 된 것입니다.
유명한 ‘노 소프트웨어’ 메시지는 단지 마케팅을 위한 것이 아니었습니다 — 일상적 고통을 말해줬습니다. 전통적 CRM 프로젝트는 종종 긴 설치 주기, IT 티켓, 버전 충돌, 출시 시 이미 구식으로 느껴지는 시스템에 대한 교육을 의미했습니다. 웹 기반 CRM은 더 간단한 경로를 약속했습니다:
이는 CRM이 다개월에 걸친 IT 이니셔티브가 되는 것을 원치 않는 리더들에게 중요했습니다. 분기 중에도 도입할 수 있는 도구를 원했습니다.
초기 세일즈포스는 영업팀이 즉시 인식할 수 있는 영역에 CRM을 포지셔닝했습니다: 리드 관리, 기회 추적, 후속 조치 유지, 예측 보고. 영업 자동화에 먼저 집중하고 배포를 가볍게 유지함으로써 ‘첫 성과까지의 시간’을 줄였습니다. 담당자는 활동을 기록할 수 있고 관리자는 긴 구현을 기다리지 않고 파이프라인 보고서를 볼 수 있었습니다.
이 초기 웹 기반 CRM에 대한 베팅은 비즈니스 소프트웨어가 제품보다 서비스처럼 동작할 수 있다는 기대를 만들었습니다: 어디서나 접근 가능하고 빨리 시작하며 최신 상태 유지가 더 쉬운 서비스.
세일즈포스는 단순히 CRM을 인터넷에 올린 것이 아니라 소프트웨어의 설계와 운영 방식을 바꿨습니다. 핵심 아이디어는 멀티테넌시와 업데이트를 정상적이고 계속되는 서비스로 다루는 릴리스 프로세스입니다.
멀티테넌트 클라우드에서는 많은 고객이 같은 기반 인프라(같은 ‘건물’) 위에서 실행되지만 각 고객의 정보는 분리된 ‘잠긴 아파트’처럼 보관됩니다. 배관과 전선은 공유하지만 파일은 공유하지 않습니다.
이 설계가 중요한 이유는 공급자가 수천 개의 약간씩 다른 설치를 운영하는 대신 하나의 표준화된 시스템을 운영할 수 있게 해주기 때문입니다.
공급자가 단일 핵심 시스템을 운영하면 다음을 할 수 있습니다:
이 효율성은 고객당 운영비용을 낮추는 경향이 있습니다. 더 중요하게는 기능 배포가 빨라집니다: 새 기능을 각 회사가 업그레이드를 예약하고 수행할 때까지 기다릴 필요 없이 서비스 전반에 롤아웃할 수 있습니다.
전통적 설치형 소프트웨어는 종종 고통스러운 업그레이드를 의미했습니다: 다운타임 계획, IT 프로젝트, 호환성 점검, 재교육. 연속 업데이트와 함께 고객은 더 이상 ‘버전 구매’가 아니라 점진적 개선을 받습니다. CRM은 내부 이주 없이 최신 상태를 유지합니다.
멀티테넌시는 보안이 내장되어 있어야만 작동합니다: 고객 간 강력한 격리, 조직 내부의 세분화된 권한, 누가 데이터를 보고 변경하거나 내보낼 수 있는지에 대한 명확한 관리자 통제가 필요합니다. 공유 환경에서는 신뢰가 기능이 아니라 기반입니다.
세일즈포스는 단순히 CRM 소프트웨어를 판매한 것이 아니라 지속적인 서비스를 판매했습니다. 이 전환은 예측 가능성 때문에 구독을 매력적으로 만들었습니다. 매월·매년 갱신되는 수익이 있으면 회사는 채용·인프라·제품 투자를 훨씬 덜 추측적으로 계획할 수 있습니다.
고객 입장에서도 구독은 구매 대화를 바꿨습니다. 큰 초기 자본 구매 대신 CRM이 운영비로 전환되어 예산 편성·정당화가 쉬워지고, 가치가 없으면 중단하기도 쉬워졌습니다. 웹 제공과 표준화된 배포 덕분에 팀은 분기가 아니라 몇 주 만에 라이브할 수 있었습니다.
구독 비즈니스는 갱신으로 생존하거나 사라집니다. 이는 공급자가 계약 체결 후에 무엇이 일어나는지에 집중하게 만듭니다:
플라이휠을 네 가지 연결된 움직임으로 생각하세요:
활성화가 개선되면 갱신이 쉬워지고, 갱신이 강하면 확장은 자연스럽게 증가합니다. 이렇게 소프트웨어는 항상 켜져 있고 정기적으로 업데이트되며 가치에 따라 비용을 지불하는 유틸리티처럼 느껴집니다.
‘제품’ CRM은 계정·연락처·기회·리포트 같은 고정된 기능을 줍니다. ‘플랫폼’ CRM은 더 큰 것을 제공합니다: 새로운 프로세스가 필요할 때마다 처음부터 시작하지 않고도 공유 서비스를 기반으로 자체 앱을 만들 수 있는 방법을 제공합니다.
사무실 한 칸을 빌리는 대신 건물을 임대하는 것으로 생각하세요. 표준 CRM 공간은 여전히 있지만 새로운 방을 추가할 때 배관·보안·유지관리를 함께 제공받습니다. 커스텀 앱은 CRM 데이터, UI, 권한과 동일한 환경 안에 존재합니다.
현대적 유사 사례로는 채팅 인터페이스로 웹·백엔드·모바일 앱을 만들게 해주는 빌드-바이-챗 도구들이 있습니다. 예를 들어 Koder.ai는 React(웹), Go + PostgreSQL(백엔드), Flutter(모바일)를 사용해 채팅으로 앱을 생성하는 비브-코딩 플랫폼입니다. 기본적으로 CRM 대체품은 아니지만, Intake 폼, 승인 도구, 경량 포털, 통합 헬퍼 같은 CRM 주변 워크플로용 앱을 빠르게 만들고 소스 코드 내보내기가 가능할 때 특히 유용합니다.
대부분의 CRM 플랫폼은 몇 가지 반복 가능한 원시 기능을 제공합니다:
요점은 새로움이 아니라 일관성입니다. 이 빌딩 블록이 공유되면 커스텀 앱은 핵심 CRM과 동일한 로그인, 리포팅, 모바일 접근, 관리자 통제를 상속합니다.
표준 CRM 기능은 판매를 처리합니다. 플랫폼 기능은 회사가 실제로 운영되는 방식을 처리합니다: 파트너 프로그램, 규정 준수 단계, 서비스 에스컬레이션, 갱신, 온보딩, 내부 요청 등. 모든 프로세스를 ‘기회’나 스프레드시트에 억지로 끼워 넣는 대신 비즈니스 운영 방식을 모델링합니다.
리셀러를 온보딩해야 한다고 가정해 보세요. Partner Application이라는 커스텀 객체를 만들어 회사 이름, 영토, 사업자 번호, 위험 점수, 상태 같은 필드를 추가합니다.
그런 다음 승인 흐름을 추가합니다: Status = “Submitted”이면 법무→재무→파트너 매니저로 라우팅됩니다. 승인되면 ERP에 파트너를 생성하는 API 호출을 트리거하고 CRM은 교육을 위한 후속 작업을 자동으로 생성합니다.
이것이 플랫폼 약속입니다: CRM은 단순히 사용하는 도구가 아니라 그 위에 구축하는 기반입니다.
CRM은 ‘그저 소프트웨어’일 수도 있고 다른 기업들(그리고 고객 스스로)이 기능을 확장할 수 있는 허브가 될 수도 있습니다. 후자의 경로가 바로 생태계입니다.
세일즈포스의 경우 생태계는 다음을 포함합니다:
이 집단들은 관객이 아니라 재사용 가능한 솔루션을 만들어 여러 회사가 채택할 수 있게 만듭니다.
고객은 더 빠른 판매 사이클, 깨끗한 데이터, 더 나은 리포팅 같은 결과를 원합니다 — 긴 빌드 프로젝트가 아니라요. 마켓플레이스 모델은 검증된 애드온을 선택하게 함으로써 이들을 빨리 도달하게 합니다.
파트너는 분명한 upside를 얻습니다: 배포 채널. 각 거래를 처음부터 찾는 대신 플랫폼에 이미 투자한 구매자들에게 도달할 수 있고, 결제·트라이얼·리뷰가 구매 결정을 돕습니다.
AppExchange는 비즈니스 소프트웨어의 ‘앱 스토어’와 같습니다. 기업은 CPQ, 전자서명, 지원 도구, 산업별 워크플로 같은 애드온을 찾아 더 적은 마찰로 설치하고 CRM 데이터와 연결해 유지할 수 있습니다.
마켓플레이스가 잘 작동하면 보통 다음을 느낍니다:
결과적으로 CRM은 단일 벤더가 모든 기능을 개발할 때까지 기다릴 필요 없이 비즈니스와 함께 성장합니다.
CRM은 그 안의 정보만큼 유용합니다. 문제는 고객 데이터가 한 곳에만 있지 않다는 것입니다: 영업 이메일은 Outlook/Gmail에, 인보이스는 ERP나 회계 도구에, 지원 이력은 헬프데스크에, 마케팅 활동은 다른 곳에 있습니다. 도구들이 업데이트를 공유하지 않으면 팀은 어떤 숫자가 ‘정답’인지 두고 논쟁하게 되고 고객은 단절을 느낍니다.
대부분의 회사는 우연히 ‘여러 버전의 진실’을 만듭니다. 영업 담당자가 CRM에서 전화번호를 업데이트하면 지원은 티켓 시스템에 다른 번호가 있고, 재무는 청구와 연결된 또 다른 연락처를 가지고 있는 식입니다. 그 결과는 중복 작업, 놓친 전달, 신뢰할 수 없는 보고서입니다.
통합은 시스템들이 통제된 방식으로 서로 말하게 해줍니다. API는 한 앱이 다른 앱이 정보를 읽거나 쓸 수 있도록 노출하는 문과 규칙의 집합입니다 — 예: “리드 생성”, “계정 업데이트”, “최신 인보이스 상태 가져오기”. 커넥터는 그 작업을 기성품으로 패키징해 처음부터 시작하지 않게 해줍니다.
잘 설정된 통합은 CRM을 신뢰하는 시스템 오브 레코드로 만듭니다: 다른 도구들은 각자의 전문 작업을 계속하지만 현재 고객 프로필은 CRM에서 볼 수 있습니다.
CRM이 이메일·청구·지원·분석과 연결되면 더 이상 ‘영업 도구’가 아니라 워크플로 허브가 됩니다. 전환하려면 연결을 다시 구성하고 데이터를 마이그레이션하며 팀을 재교육하고 다운타임 위험을 감수해야 합니다 — 그래서 CRM 교체 비용이 커지고 고객의 사용 기간은 길어지는 경향이 있습니다.
사람들이 SaaS 제품을 “엔터프라이즈급”이라고 말할 때 보통 한 가지를 의미합니다: 수천 명의 사용자, 민감한 데이터, 엄격한 내부 규칙을 안전하게 운영할 수 있으며, 모든 변경이 맞춤형 프로젝트가 되지 않는다는 것.
우선 보안은 일상적 사용을 위해 설계되어야 합니다. 즉 강력한 인증 옵션, 명확한 권한 모델, 우발적 데이터 노출을 줄이는 안전장치가 필요합니다.
둘째, 컴플라이언스 요구는 로고 문제가 아니라 반복 가능한 통제에 관한 것입니다: 누가 접근 가능한지, 접근을 어떻게 부여하는지, 나중에 이를 증명할 수 있는지.
대규모에서 “관리자 통제”가 제품입니다. 역할기반 접근 제어(RBAC)는 권한을 영업 담당·관리자·지원 담당·계약업체 같은 직무 기능에 매핑해 사람들이 필요한 것만 보게 합니다.
감사는 실수와 분쟁이 발생하기 때문에 중요합니다. 좋은 시스템은 로그인·권한 변경·데이터 내보내기·구성 수정 같은 주요 이벤트를 기록해 팀이 문제를 신속히 조사하고 이해관계자에게 설명할 수 있게 합니다.
연속 업데이트 뒤에 있는 조용한 요구는 변경 관리입니다. 엔터프라이즈는 변경을 테스트하고, 누가 구성을 수정할 수 있는지 제한하며, 자체 프로세스에 맞는 일정으로 새 기능을 배포하는 방법이 필요합니다.
구독형 유틸리티는 가동되어야 합니다. 가동시간을 넘어 엔터프라이즈 구매자는 명확한 사고 커뮤니케이션을 원합니다: 무슨 일이 있었는지, 누가 영향을 받는지, 현재 상태는 어떤지, 재발 방지를 위해 무엇을 할 것인지. 투명한 업데이트는 혼란을 줄이고 신뢰를 보호하며 고객이 자체 대응을 조정하는 데 도움이 됩니다.
세일즈포스는 단지 CRM 소프트웨어를 판매한 것이 아니라 다른 기업들이 그것을 확장하도록 하는 장소를 만들었습니다. 생태계는 참여가 늘어날수록 가치가 복리로 쌓이기 때문에 버티는 힘(모트)이 될 수 있습니다.
건강한 마켓플레이스는 간단한 루프를 만듭니다: 더 많은 앱과 파트너가 제품을 더 유용하게 만들고, 더 많은 고객을 끌어들이고, 더 많은 빌더들이 더 많은 앱을 만들게 합니다. 시간이 지나면서 구매자는 ‘어떤 CRM’ 대신 ‘이 CRM으로 무엇을 할 수 있는가’를 평가합니다.
플랫폼의 깊이는 관계를 변화시킵니다. 회사의 영업 프로세스, 고객 데이터, 자동화, 대시보드, 서드파티 도구들이 모두 하나의 환경에 있으면 교체는 주말 프로젝트가 아닙니다. 비용은 단지 라이선스가 아니라 재교육, 통합 재배선, 수년간의 조직 지식 마이그레이션입니다. 이는 전환 비용을 높이고 고객의 수명을 연장시키는 경향이 있습니다.
생태계는 확장을 자연스럽게 만듭니다. 팀은 핵심 CRM으로 시작한 뒤 마케팅·서비스·분석·산업별 패키지를 추가할 수 있습니다. 또는 CPQ, 계약 관리, 데이터 보강, 고객 지원 애드온 같은 전문 앱을 더할 수 있습니다. 플랫폼은 메뉴가 되고 업셀은 추가 제품과 앱을 통해 발생합니다.
생태계는 역효과를 낼 수 있습니다. 조직이 앱을 쌓을수록 관리자 작업은 증가하고 성능이 저하될 수 있으며 사용자 경험이 일관되지 않게 됩니다. 앱 품질은 천차만별입니다: 보안 관행, 지원, 장기 유지보수가 벤더마다 다릅니다.
신뢰를 유지하려면 플랫폼 소유자는 강력한 거버넌스가 필요합니다 — 명확한 인증 기준, 검토 프로세스, 권한 통제, 문제 있는 행위자에 대한 제재 — 그렇지 않으면 모트가 복잡성 증가로 바뀌어 고객의 반감을 살 수 있습니다.
CRM은 ‘단지 소프트웨어’처럼 느껴질 수 있지만 결국 매출 예측, 고객 이력, 워크플로 의사결정이 살아있는 장소가 됩니다. 잘 선택하는 것은 브랜드보다 적합성에 관한 문제입니다.
다음 네 가지 질문으로 시작하세요:
그런 다음 라이선스 가격 이상의 예산을 압박 테스트하세요: 관리자 시간, 교육, 통합, 유료 마켓플레이스 앱.
여러 커스텀 워크플로를 만들 계획이면 “빌드 표면적(build surface area)”도 평가하세요: CRM 플랫폼 내부를 확장할 것인지, 앱을 구매할 것인지, 별도 내부 도구를 빌드할 것인지? 빌드하는 팀은 보통 빠른 반복과 통제를 찾습니다 — 예: 소스 코드 내보내기, 안정적 배포, 롤백 가능성. (예: Koder.ai는 소스 코드 내보내기, 배포/호스팅, 커스텀 도메인, 스냅샷, 롤백을 지원해 CRM 생태계에 커스텀 동반 앱이 포함될 때 유용합니다.)
사내 제품 출시처럼 롤아웃을 다루세요:
AppExchange 스타일의 마켓플레이스에서 앱을 선택할 때 확인하세요:
모든 옛 스프레드시트를 재현하고 싶은 유혹이 있습니다. 먼저 핵심 워크플로(리드 → 기회 → 고객)로 시작하고 사람들이 기본을 일관되게 사용한 뒤에 복잡도를 추가하세요.
세일즈포스의 이야기는 세 가지 레버가 함께 작동한 것으로 기억하기 쉽습니다: SaaS 제공, 명확한 CRM 카테고리 집중, 플랫폼 생태계. SaaS는 배포와 업그레이드를 마찰 없이 만들었고, CRM은 제품에 구체적인 ‘해야 할 일’을 주었으며(관계 관리, 매출 예측, 판매 조정), 플랫폼과 마켓플레이스는 고객과 파트너가 핵심을 기다리지 않고 확장할 수 있게 해 가치를 배가시켰습니다.
모델이 건강하면 소프트웨어는 일회성 구매가 아니라 신뢰할 수 있는 서비스처럼 동작합니다: 구독하고 계속 개선되며 다른 시스템과 연결되고 예측 가능한 통제로 관리됩니다. 공급자는 반복 수익을 확보해 지속적 업데이트에 투자하고, 고객은 최신 상태를 유지하는 시스템을 얻고, 파트너는 엣지 케이스를 채우며 통합은 중복된 데이터 입력을 줄입니다. 시간이 지나면 제품은 단순한 앱이 아니라 일상 운영의 한 층이 됩니다.
결정 전에 청사진을 압박 테스트하세요:
추가로 실용적인 질문 하나: CRM 주변의 ‘엣지 워크플로’를 얼마나 빨리 구축(또는 재구축)할 수 있는가? 플랫폼 내부에서 확장할지, 마켓플레이스에서 구매할지, 아니면 Koder.ai 같은 도구로 커스텀 앱을 만들지 여부는 속도(솔루션 실현 속도)와 거버넌스(내보내기, 배포, 롤백)가 CRM 기능 목록만큼 중요할 때가 많습니다.
계속 탐색하고 싶다면 /blog에서 심층 비교를 살펴보거나 /pricing에서 구독 설계가 총비용에 미치는 영향을 확인하세요.
“구독형 유틸리티”는 소유하는 소프트웨어가 아니라 안정적으로 접근하는 서비스입니다. 정기적으로 요금을 지불하고, 높은 가용성과 보안을 기대하며, 공급자가 인프라 운영·패치·확장을 담당하는 가운데 지속적인 개선을 받습니다.
CRM은 고객 상호작용과 다음 행동을 기록하는 ‘살아 있는 기록’입니다. 팀은 이를 통해 이관 실수(작업 누락)를 줄이고 책임 소재를 명확히 하며 파이프라인 추적, 케이스 이력, 리포팅을 통해 매출 활동을 가시화하려고 CRM을 사용합니다.
온프레미스 CRM은 서버 구축, 긴 구현 기간, 변경 시 IT 의존을 불러옵니다. 업그레이드는 커스터마이징을 망가뜨릴 위험이 있어 대형 프로젝트가 되고, 결과적으로 팀은 오래된 버전에 묶여 데이터 품질과 프로세스 일관성에 문제가 생기기 쉽습니다.
SaaS는 공급자가 호스팅, 보안 패치, 업그레이드를 관리하는 브라우저/앱을 통한 접근 방식입니다.
주요 차이점:
멀티테넌시는 여러 고객이 동일한 기반 인프라를 공유하되 각 고객의 데이터는 논리적으로 분리되는 구조입니다. 공급자는 하나의 표준 시스템을 유지하면서 버그를 한 번에 고치고 기능을 모두에게 동시에 배포할 수 있어 비용과 속도에서 이점이 생깁니다.
연속적인 업데이트는 고객에게 ‘업그레이드 시즌’을 없앱니다. 즉, 예정된 마이그레이션이나 다운타임 계획이 줄고 새 기능을 더 빨리 이용할 수 있게 됩니다. 다만 업데이트가 내부 워크플로를 방해하지 않도록 테스트, 권한, 릴리스 제어 같은 변경관리 역량이 필요합니다.
제품형 CRM은 계정·연락처·기회·리포트 같은 정해진 기능을 제공합니다. 플랫폼형 CRM은 재사용 가능한 빌딩 블록(커스텀 객체, 자동화, 보안 모델, API)을 더해 고유한 업무 프로세스를 동일한 시스템 안에서 모델링하고 실행할 수 있게 합니다.
마켓플레이스는 검증된 애드온과 구현 전문성을 제공해 가치를 높입니다.
앱을 설치하기 전 확인 사항:
통합은 시스템들이 통제된 방식으로 서로 대화하게 해 ‘여러 버전의 진실’ 문제를 줄입니다. CRM이 레코드의 소스가 되면 회계·지원·마케팅 도구는 각자의 전문 작업을 계속하면서도 일관된 고객 프로필을 유지합니다.
실용 체크리스트:
결정은 브랜드가 아니라 적합성에 달려 있습니다.
실행 가능한 접근법:
비교는 /blog에서, 비용 고려는 /pricing에서 추가로 확인하세요.