CRM 데이터 모델 비교: Salesforce, HubSpot, Pipedrive, Attio는 왜 이렇게 다르게 생겼는가

"어느 CRM이 좋은가요?"

B2B 스타트업 대표, 세일즈 리더한테 가장 많이 받는 질문 중 하나입니다. 그리고 이 질문에 대한 기존 답변은 대부분 기능 체크리스트예요. "Salesforce는 커스터마이징이 강하고, HubSpot은 마케팅 연동이 좋고, Pipedrive는 UX가 직관적이고..." 이런 식이죠. 그런데 이 비교 방식에는 빠진 게 있습니다.

왜 이 CRM은 이런 구조로 만들어졌는가.

기능 목록은 결과물이에요. 원인은 창업자가 "누구의 어떤 질문에 답하려고" 이 제품을 만들었느냐에 있습니다.

Salesforce, HubSpot, Pipedrive, Attio - 4개의 CRM의 데이터 모델은 상당히 다릅니다. 그리고 그 차이는 기능 비교표에서는 절대 보이지 않아요. 데이터가 어떻게 연결되어 있느냐, 어떤 질문에 빠르게 답할 수 있느냐, AI 에이전트가 접근했을 때 어떤 경험을 하느냐 - 이 구조적 차이가 CRM 선택에서 진짜 중요한 변수입니다.

창업자의 질문이 CRM 데이터 모델을 결정한다

CRM의 구조를 이해하려면, 각 CRM이 태어난 맥락부터 봐야 합니다. 창업자의 배경과 철학이 데이터 모델을 결정했고, 그 구조는 20년이 지나도 쉽게 바뀌지 않거든요.

• Salesforce (1999) — Marc Benioff는 Oracle 출신입니다. 엔터프라이즈 소프트웨어 세계에서 온 사람이에요. 출발점은 "CEO나 VP of Sales가 '삼성전자와 우리 관계가 어떻게 되고 있지?'라고 물을 때 답할 수 있는 시스템"이었습니다. 그래서 Account(회사)가 데이터의 중심이 됐어요. Contact, Opportunity, Activity, Case — 모든 것이 Account 아래에 종속되는 트리 구조입니다.

• HubSpot (2006) — Brian Halligan과 Dharmesh Shah는 MIT 대학원 동기였어요. "사람들은 광고에 방해받기보다 유용한 정보를 원할 뿐"이라는 관찰에서 인바운드 마케팅 개념을 만들었습니다. 그래서 Contact(사람)이 중심이에요. 블로그를 읽고, 이북을 다운로드하고, 뉴스레터를 구독하는 개인의 행동 여정을 추적하는 게 핵심이었죠. 회사가 아니라 사람의 관심도와 행동이 출발점입니다.

• Pipedrive (2010) — 영업사원 출신들이 "Salesforce는 우리를 위한 게 아니라 관리자를 위한 거다"라는 불만에서 시작했습니다. 그래서 Deal(딜)이 중심이에요. "지금 내가 이 딜을 진행하는 데 뭐가 필요하지?"라는 질문에 가장 빠르게 답하는 구조. 파이프라인 보드에서 드래그 앤 드롭하는 UX가 핵심입니다.

• Attio (2019) — VC와 엔지니어링 배경의 창업팀이 "기존 CRM은 한 가지 프로세스에 데이터를 가둔다"는 문제의식에서 출발했어요. 그래서 Record(사실)와 List(맥락)가 분리됩니다. 같은 Company 레코드를 세일즈팀은 "Sales Pipeline" 리스트에서, CS팀은 "Onboarding" 리스트에서, 투자팀은 "Deal Flow" 리스트에서 각자의 관점으로 봐요. 기저의 진실은 하나이되, 그 위의 프로세스 레이어는 팀마다 다르게 구성됩니다.

HubSpot이 Sales Hub를 만들어도 여전히 Contact이 중심이고, Pipedrive가 마케팅 기능을 붙여도 여전히 Deal이 중심입니다. 20년간 굳어진 데이터 모델의 뿌리는 바뀌지 않습니다.

4가지 CRM 데이터 토폴로지: 조직도, 별자리, 네트워킹, 지도 앱

데이터 모델의 차이를 머리로 이해하는 것과 체감하는 건 다릅니다. 각 CRM의 데이터가 어떤 모양으로 연결되어 있는지를 일상적인 비유로 풀어볼게요.

Salesforce = 조직도

조직도를 떠올려보세요. 대표이사 아래에 부서장들이 있고, 그 아래 팀원들이 있습니다. "이 회사 전체를 알고 싶어"라고 하면? 대표이사(Account)만 찾으면 아래로 쭉 타고 내려가면서 전부 보여요. 위에서 아래로 가지가 뻗어나가는 나무 모양입니다.

한 점을 잡으면 전체가 딸려옵니다. 대신, 아래(Opportunity)에서 위(Account)로 올라가거나 옆(다른 Contact)으로 가려면 계층을 타고 이동해야 합니다.

Pipedrive = 별자리

동시에 5개 딜을 진행하고 있다고 생각해보세요. 각 딜이 각각의 미팅 노트, 이메일, 활동 기록을 가지고 있어요. 별 모양처럼 각 딜이 하나의 중심이고 거기서 정보가 방사형으로 뻗어나갑니다. 그런데 "이 회사랑 우리 전체 관계가 뭐야?"라고 물으면? 5개 별을 하나하나 모아서 퍼즐 맞추듯 합쳐야 합니다.

각 별(Deal) 안에서는 모든 게 한 곳에 있습니다. 대신, 회사 전체를 보려면 별을 모아서 조립해야 합니다.

HubSpot = 네트워킹 행사

네트워킹 행사에 갔다고 생각해보세요. 거기서 만난 사람들이 서로 아는 사이입니다. A가 B를 알고, B가 C를 알고, C가 다시 A를 아는 식으로 그물처럼 연결돼 있어요. 누구를 통해서든 다른 사람에게 도달할 수 있는데, "이 그룹 전체를 한눈에 봐"라고 하면? 한 사람 잡고 → "너 누구 알아?" 물어보고 → 그 사람 찾아가서 또 물어보고... 이런 식으로 그물을 탐색해야 합니다.

어떤 방향으로든 탐색이 가능합니다. 대신, 한 번에 전체 그림이 나오지 않습니다.

Attio = 지도 앱

지도 앱을 생각해보세요. 기본 지형(도로, 건물)은 하나인데, 그 위에 교통 레이어를 올리면 막히는 구간이 보이고, 맛집 레이어를 올리면 음식점이 보이고, 날씨 레이어를 올리면 비 오는 지역이 보입니다. 기저 지형(Record)은 하나의 진실이고, 각 레이어(List)가 같은 지형을 다른 관점으로 보여줍니다.

기저의 진실은 하나, 그 위의 관점은 여러 개입니다. 대신, 아직 에코시스템과 깊이가 다른 CRM에 비해 부족합니다.

토폴로지별 강점과 약점

같은 고객 데이터에 다른 질문을 하면, 조직에 맞는 CRM이 바뀐다

이제 실제로 같은 질문을 네 CRM에 던졌을 때 어떤 차이가 나는지 볼게요. CRM의 API를 통해 데이터를 꺼내는 상황입니다. 네 가지 유형의 질문으로 비교합니다.

질문 A: "이 회사와 우리의 전체 관계가 뭐야?" — CEO, VP of Sales, Account Manager가 가장 많이 하는 질문입니다. Salesforce는 자체 쿼리 언어(SOQL)의 relationship subquery로 Account + Contact + Opportunity + Activity를 API 1번 호출로 가져옵니다. 나머지 세 CRM은 3~6번 호출이 필요합니다. 조직도(Tree) 구조에서 꼭대기를 잡으면 전부 딸려오는 구조의 힘이죠.

질문 B: "이 딜의 모든 맥락을 보여줘" — 영업 담당자, 세일즈 매니저의 일상 질문입니다. Pipedrive는 Deal 하나를 조회하면 관련 Person, Organization, Activity 메타데이터가 1~2번 호출로 다 딸려와요. Salesforce도 Opportunity에서 SOQL 서브쿼리로 관련 Contact Role, Activity를 1번 호출로 가져올 수 있습니다. 다만 Pipedrive는 UI 자체가 딜 중심으로 설계되어 있어서, 영업사원의 일상 워크플로우에서 체감되는 접근성이 다릅니다.

질문 C: "이 사람의 우리와의 전체 인터랙션을 보여줘" — 마케터, CS 담당자, SDR의 관심사입니다. HubSpot은 Contact에 Lifecycle Stage(Subscriber → Lead → MQL → SQL → Customer)가 네이티브로 있고, 웹사이트 방문 기록, 이메일 오픈/클릭, 콘텐츠 다운로드가 Contact 타임라인에 자동으로 쌓여요. 2~3번 호출이면 이 사람의 마케팅+세일즈 통합 여정이 다 보입니다. Salesforce도 Contact에서 미팅·콜·이메일 같은 세일즈 인터랙션은 SOQL 1번으로 가져올 수 있지만, 마케팅 여정 데이터(웹 방문, 콘텐츠 소비)를 보려면 Marketing Cloud나 Pardot을 별도로 붙여야 합니다. 세일즈 인터랙션만 보면 Salesforce도 강하지만, "이 사람의 전체 여정"이라는 질문의 범위가 마케팅까지 포함되면 HubSpot이 유리합니다.

질문 D: "이 레코드가 어떤 프로세스들에 참여하고 있어?" — RevOps, 팀 리더의 질문입니다. Attio는 entries 엔드포인트 하나로 해당 레코드가 속한 모든 리스트(Sales Pipeline, Onboarding, Support 등)를 1번 호출로 반환합니다. 지도 앱(Layer) 구조에서 기본 지형 위에 어떤 레이어가 올라가 있는지 한 번에 보이는 겁니다.

각 CRM은 자기 홈 그라운드에서 강합니다. 어떤 CRM이든 자기 중심 축이 아닌 질문을 받으면 추가 작업이 필요해요. 자기 홈 그라운드에서는 누구나 강합니다.

다만, 4년간 엔터프라이즈 세일즈를 하면서 체감한 게 하나 있어요. 실무에서 던지는 질문은 결국 Account로 수렴합니다. "이 딜의 맥락이 뭐야?"라고 물어도, 근본적으로 묻고 있는 건 "이 회사가 우리 고객이 될 거냐"예요. 고객이 되고 나면 고객 관리를 해야 하니까, 다시 Account 중심으로 돌아옵니다.

또한 고객사 담당자는 이직을 합니다. 그런데 CRM에서 중요한 건 "누가 이직했다"가 아니라 "어느 회사로 이직했느냐", 즉 어떤 Account로 갔느냐입니다. 사람은 바뀌지만 Account에 대한 질문은 계속 남는 구조입니다.

그래서 저는 Salesforce의 UI가 다른 CRM에 비해 직관적이지 않다는 걸 알면서도 Salesforce를 쓰게 됐어요. Account-centric 데이터 모델이 B2B 세일즈의 현실과 가장 맞닿아 있었거든요. 실제로 저는 Salesforce UI에 로그인하지 않고 데이터 저장소로만 사용하는 방식으로 운영하고 있습니다. 이건 기능 비교표에서는 보이지 않는 차이입니다.

CRM API와 UI의 격차: AI 에이전트가 만나는 데이터 접근성 문제

저는 Salesforce 데이터를 AI 에이전트로 다루는 작업을 직접 해왔습니다. 그 과정에서 배운 게 하나 있습니다.

"좋은 CRM UI"와 "좋은 CRM API"는 같은 것이 아니다.

사람이 CRM을 쓸 때는 네 CRM 모두 괜찮아요. UI가 데이터 구조의 복잡함을 전부 숨겨주니까요. 문제는 AI 에이전트가 API로 직접 접근할 때 드러납니다.

Pipedrive의 커스텀 필드 해시 문제. 사람이 Pipedrive UI에서 딜을 보면 "계약 담당자", "예상 매출" 같은 읽기 쉬운 이름이 보입니다. 그런데 AI가 API로 같은 딜을 조회하면? 커스텀 필드가 dcf558aac1ae4e8c4f849ba5e668430d8df9be12 같은 40자 랜덤 해시로 돌아옵니다. AI는 이 해시가 뭔지 전혀 몰라요. 필드 이름 매핑 테이블을 먼저 구축해야 비로소 의미를 파악할 수 있습니다. UI가 자동으로 해주던 번역을, AI가 직접 해야 하는 겁니다.

HubSpot의 Search API와 Association 단절. 사람이 HubSpot UI에서 Company를 검색하면 관련 Deal과 Contact이 바로 보입니다. AI가 Search API로 같은 검색을 하면? Association으로 필터링하는 건 가능해졌지만(예: "이 Contact에 연결된 Deal을 찾아줘"), Search 응답에 관련 레코드의 상세 데이터를 함께 반환하는 건 여전히 안 됩니다. Search로 Company를 찾고 → 별도 API로 Association ID를 확인하고 → 또 다른 API로 실제 데이터를 가져오는 3단계를 거쳐야 해요. HubSpot 개발자 커뮤니티에서 오래 지적되어 온 문제입니다.

Salesforce는 이 격차가 상대적으로 작습니다. 자체 쿼리 언어(SOQL)에서 필요한 필드만 정확히 지정해서 가져올 수 있고, 서브쿼리로 관련 데이터를 1번 호출로 구조화된 형태로 반환하니까요. AI 입장에서 추가로 조립할 게 적습니다.

Attio도 격차가 비교적 작습니다. 4개 CRM 중 유일하게 MCP를 공식 문서화했어요. AI 에이전트가 접근하는 것 자체를 설계 단계에서 고려한 CRM이라는 뜻입니다. 커스텀 필드도 사람이 읽을 수 있는 이름으로 반환되고요.

직접 경험한 케이스가 있어요. 특정 SaaS의 REST API에 페이지네이션이 없어서 모든 데이터가 단일 응답으로 한꺼번에 쏟아지는 바람에, AI의 컨텍스트 윈도우가 터져버린 적이 있습니다. 사람이 UI로 쓸 때는 아무 문제 없었거든요 — UI가 lazy loading으로 필요한 만큼만 보여주니까. UI는 나쁜 API 설계를 숨길 수 있지만, AI는 API의 민낯을 그대로 만납니다.

SOQL과 REST API의 구조적 차이: 자체 쿼리 언어가 존재한다는 것의 의미

CRM 비교에서 잘 다뤄지지 않는 포인트가 하나 있습니다. Salesforce에는 SOQL(Salesforce Object Query Language)이라는 자체 쿼리 언어가 있어요. Pipedrive, HubSpot, Attio는 REST API를 사용하고요. 이 차이가 왜 중요한지를 이해하려면 순서를 거꾸로 가봐야 합니다.

Salesforce는 Oracle Database 위에 자체적인 멀티테넌트 데이터 추상화 계층을 만들었습니다. Account, Contact, Opportunity 같은 오브젝트들은 전통적인 데이터베이스 테이블이 아니라 메타데이터로 정의된 Salesforce 플랫폼만의 개념이에요. 이 구조에는 일반 SQL이 안 먹습니다. 그래서 자기 구조에 맞는 자기만의 쿼리 언어를 만들어야 했습니다.

SOQL은 Salesforce의 데이터 구조를 "아는" 언어입니다. "Account 아래에 Contact이 있고, Opportunity가 있고, Activity가 있다"는 관계를 언어 자체가 이해하고 있기 때문에, 한 번의 쿼리로 Account + 관련 Contact + Opportunity + Activity를 동시에 가져올 수 있는 거예요. 쿼리 언어가 데이터 구조를 알고 있으니까요.

SOQL도 만능은 아닙니다. 임의의 JOIN이 불가능하고, 미리 정의된 관계만 쿼리할 수 있어요. child subquery는 1단계만 가능합니다 — Account → Contacts는 되지만, Account → Contacts → 그 Contact의 Cases를 한 쿼리로 가져오는 건 안 돼요. 서브쿼리당 child record도 기본 200개로 제한되기 때문에, Contact이 500명인 대형 Account라면 페이지네이션이 필요합니다. SOQL의 강점은 "모든 쿼리를 다 잘한다"가 아니라 "Salesforce의 데이터 구조에 맞는 질문에 최적화되어 있다"는 겁니다.

비유로 풀면 이렇습니다.

Pipedrive, HubSpot, Attio는 백화점 안내 데스크예요. "삼성전자 관련 정보 주세요"라고 하면 직원이 "잠시만요, 세일즈 코너 가서 딜 정보 가져올게요... 이제 CS 코너 가서 활동 기록 가져올게요..."라고 코너마다 돌아다니면서 자료를 모아옵니다. 각 코너(API 엔드포인트)가 독립적으로 운영되고, 안내 데스크 직원(AI 에이전트)이 발로 뛰어서 조립하는 구조입니다.

Salesforce는 자체 분류 체계와 사서 시스템을 갖춘 대형 도서관입니다. "삼성전자 관련 모든 자료 주세요"라고 하면, 검색 시스템이 분류 체계를 이미 알고 있으니까 한 번의 검색으로 관련 서적(Contact), 논문(Opportunity), 대출 기록(Activity)을 한꺼번에 찾아서 구조화된 목록으로 내놓습니다. 검색 시스템과 분류 체계가 하나로 설계되었기 때문에 가능한 겁니다.

쿼리 언어만 놓고 보면 "아무 회사나 만들 수 있다"고 반박할 수 있습니다. 맞아요. HubSpot이 GraphQL API를 도입한 것도 "여러 관련 데이터를 한 번의 쿼리로 가져온다"는 같은 방향이에요. 하지만 Salesforce의 구조적 우위는 SOQL 단독이 아니라, 27년간 성숙한 오브젝트 모델 + 그 위에 구축된 에코시스템 + 데이터 모델에 최적화된 쿼리 언어, 이 세 가지의 조합에서 나옵니다. HubSpot의 GraphQL은 범용 쿼리 레이어이지, Salesforce처럼 자사 데이터 모델 전체에 최적화된 수준은 아직 아닙니다.

단, 이 우위에는 방향성이 있습니다. SOQL의 강점은 Account-centric 질문과 Deal-centric 질문 모두에서 발휘돼요 — Opportunity에서도 서브쿼리로 관련 데이터를 1번에 가져올 수 있으니까요. 반면 Contact-centric 질문에서는 HubSpot의 Lifecycle Stage + 인바운드 추적이 더 자연스럽고, Process-centric 질문에서는 Attio의 entries 엔드포인트가 1번 호출로 끝납니다. 모든 질문에서 Salesforce가 최고라는 뜻은 아닙니다.

Attio는 다른 방식으로 이 문제를 우회합니다. SOQL 같은 자체 쿼리 언어를 만드는 대신, 일일 API 호출 한도 자체를 없애버렸어요. REST API는 여러 번 호출해야 하는 구조적 약점이 있으니까, 호출 횟수 제한을 없애서 그 약점의 실무적 영향을 줄인 겁니다. SOQL만큼 효율적이지는 않지만, "API 한도 초과로 작업이 막힌다"는 최악의 시나리오는 피할 수 있어요. AI native 시대에 REST API 기반 CRM이 취할 수 있는 현실적으로 영리한 전략이라고 볼 수 있습니다.

Salesforce는 27년간 장서를 쌓은 도서관이에요. 사서(SOQL)가 뛰어나서 AI가 원하는 책을 빠르게 찾아줍니다. Attio는 처음부터 AI가 직접 책을 꺼내도록 설계된 셀프서비스 서점인데, 아직 서가에 책이 충분하지 않아요. 지금 당장 system of record가 필요하면 도서관이 답이지만, AI native CRM의 미래 방향은 셀프서비스 서점 쪽이 맞다고 봅니다.

조직 규모가 커질수록, API 효율 격차는 곱셈으로 벌어진다

REST API로 못 하는 건 없어요. SOQL로 할 수 있는 모든 것을 REST API 호출 조합으로 100% 재현 가능합니다. 결과물은 동일해요. 차이는 효율 — 콜 수, 속도, AI 컨텍스트 비용 — 에서만 발생합니다.

그리고 이 효율 차이가 실무에서 체감되려면 세 가지 조건이 동시에 필요해요. 세일즈팀 200명 이상의 조직 규모, AI가 사람이 안 하던 자동화까지 수행하는 수준, 그리고 실시간 CRM 조회가 요구되는 시나리오. 한국 B2B 시장에서 이 세 조건을 동시에 충족하는 회사는 아직 극소수입니다.

그럼에도 이 구조적 차이를 이해하는 건 의미가 있습니다. AI 자동화가 보편화될수록 이 격차가 체감되기 시작할 거고, 그때 가서 CRM을 바꾸는 건 데이터 마이그레이션 비용이 수반되니까요. "2~3년 후를 고려한 프레임워크"로 읽어주시면 됩니다.

규모별 시나리오를 계산해봤습니다. 아래 수치는 "팀원 1명당 하루 평균 조회 20~50건, AI 자동화 시 딜당 API 콜 1~5회"를 가정한 자체 추정치입니다.

소규모 팀 (50명, 하루 20건 조회)

네 CRM 모두 API 한도 내에서 충분히 여유 있습니다. SOQL이든 REST든 체감 차이가 거의 없어요. 이 규모에서는 CRM 선택의 기준은 UX와 가격이 되는 게 맞습니다.

중규모 팀 (200명, AI 자동화 시작)

AI 에이전트가 매일 아침 모든 활성 딜(500개)에 대해 자동으로 인사이트를 생성하는 워크플로우가 추가된 상황입니다.

Salesforce는 SOQL의 효율(1번 호출 vs 4~5번 호출) 덕분에 총 API 콜 수 자체가 적습니다. Attio는 REST API의 콜 수는 많지만 일일 한도가 없어서 실무적으로 막히지 않습니다.

대규모 조직 (500명, AI 에이전트 본격 운영)

AI 에이전트가 1,000개 Account에 대해 매일 전체 히스토리 스캔 + 인사이트 생성까지 하는 상황에서 격차가 폭발합니다.

Salesforce는 SOQL 덕분에 같은 작업을 1/5의 API 콜로 처리합니다. 같은 한도 안에서 5배 더 많은 AI 작업이 가능하다는 뜻입니다.

규모와 무관하게 항상 존재하는 차이

API 한도 외에도 세 가지 차이가 팀 규모와 관계없이 항상 있습니다.

응답 시간. 자체 측정 기준으로 SOQL 1번 호출은 약 200~500ms, REST API 4~5번 순차 호출은 800~2,500ms입니다. AI가 사용자에게 답하기까지의 체감 시간이 3~5배 차이 납니다.

AI 컨텍스트 윈도우 효율. 1번 호출의 구조화된 응답은 AI가 바로 해석합니다. 4~5번 호출의 개별 응답은 AI가 각각 파싱하고, 메모리에 올리고, 관계를 추론해서 조립해야 해요. 같은 정보를 얻는 데 AI 컨텍스트 윈도우를 2~3배 더 소모합니다.

데이터 일관성. 1번 호출은 그 시점의 스냅샷이 일관적입니다. 순차 호출은 첫 번째 콜과 네 번째 콜 사이에 데이터가 변경될 수 있어요. 치명적인 경우는 드물지만, 데이터 기반 의사결정의 정확도에 영향을 줄 수 있습니다.

AI 에이전트 시대 CRM 선택 가이드: 기능 체크리스트를 넘어서

기존 CRM 비교 글들은 "기능이 뭐가 있느냐"를 물었습니다. AI 에이전트가 CRM 데이터에 직접 접근하는 시대에는 세 가지 질문이 추가되어야 합니다.

• UI가 얼마나 예쁜가 → API가 얼마나 AI-friendly한가.

• 기능이 얼마나 많은가 → 자체 데이터 플랫폼(쿼리 언어)이 있는가.

• 가격이 얼마인가 → AI 에이전트가 쓸 때 규모별 비용 곡선이 어떻게 되는가.

그리고 하나 더 — 지금의 팀 규모가 아니라, 2~3년 후의 조직 크기로 골라야 합니다.

CRM 마이그레이션은 회사가 커지면서 겪는 사무실 이전보다 훨씬 고통스러워요. 데이터 구조가 다른 CRM으로 옮기면 필드 매핑, 관계 재설정, 히스토리 유실 문제가 생깁니다. 자주 옮길 수 없는 소프트웨어이기 때문에, 선택할 때 스케일 천장을 봐야 합니다.

각 CRM의 천장은 확연히 다릅니다. Salesforce는 AppExchange에 6,000개 이상의 앱이 있고, SAP·Oracle·Workday 같은 전사 시스템과 연결되어 세일즈 데이터가 재무·CS·마케팅 데이터와 합쳐집니다. 10명 팀에서 시작해도 1,000명 조직까지 구조를 바꿀 필요가 없어요. HubSpot은 Marketing·Sales·Service Hub 간 통합이 강점이고 마켓플레이스에 2,000개 이상의 앱이 있지만, 상위 플랜으로 올라갈수록 가격이 가파르게 올라갑니다. Pipedrive는 세일즈 팀 10~200명 규모에서 최적화되어 있지만, 세일즈 기능에 한정되어 있어서 회사가 커지면 마케팅·CS 도구를 별도로 붙여야 하고, 그 순간 데이터 사일로가 생깁니다. Attio는 커스텀 오브젝트로 유연하게 확장 가능하지만 에코시스템이 아직 초기 단계입니다.

회사가 성장하면 세일즈팀의 데이터는 세일즈팀만의 것으로 남지 않습니다. 경영진은 세일즈 파이프라인 데이터와 재무 데이터를 합쳐서 보고 싶어하고, CS팀은 세일즈 히스토리를 보면서 고객을 관리해야 해요. 세일즈 데이터가 조직의 다른 데이터와 얼마나 자연스럽게 연결되느냐가, 단순한 세일즈 도구 선택을 넘어서 조직 전체의 데이터 인프라 결정이 되는 이유입니다.

어느 CRM이 "더 좋다"는 건 없습니다.

여러분의 상황에 맞는 CRM이라는 질문을 하면 물론 더 좋은 CRM이 존재합니다. 조직이 매일 가장 많이 던지는 질문이 뭔지, 그리고 AI 에이전트가 그 질문에 답하는 데 어떤 구조가 가장 효율적인지를 봐야 합니다. 기능 체크리스트는 그 다음입니다.

여러분의 조직이 가장 자주 하는 질문은 무엇인가요?