벤더 락인을 피하는 CRM 아키텍처 설계법

"GHL 쓰다가 HubSpot으로 옮기려는데, 데이터 이전에 6개월 걸린다고 합니다." 작년에 받은 상담 중 가장 마음 아팠던 한마디입니다. 처음 한 선택이 5년이 지나 발목을 잡는 가장 흔한 패턴, 벤더 락인입니다.

이 글은 처음부터 벤더에 묶이지 않으면서도 그 도구의 기능을 다 쓰는 CRM 아키텍처 설계법을 정리한 글입니다.

벤더 락인이 문제가 되는 순간

처음 HubSpot이나 GHL을 쓸 때는 장점만 보입니다.

빠른 설치
잘 테스트된 기능
상세한 교육 자료
한국어 지원

그런데 2~3년이 지나면 구조적 문제가 드러납니다.

고객 데이터가 벤더 서버에만 존재한다
가격 정책이 바뀌어도 이전이 사실상 불가능하다
필요한 기능이 없는데 우회로도 막혀 있다
API 제한 때문에 자체 확장이 어렵다

저희 한 클라이언트는 5년째 HubSpot을 쓰면서 월 250만 원 가까이 내고 있었습니다. 다른 도구로 옮기려고 했더니 "고객 데이터 이전에만 6~12개월" 견적이 나왔습니다. 그 시점에 락인은 이미 끝난 게임입니다.

우리가 제안하는 4-레이어 아키텍처

핵심 원칙은 한 줄로 정리됩니다.

데이터는 내가 소유, 도구는 교체 가능.

이 원칙을 네 개의 레이어로 풀어냅니다.

레이어 1: 데이터 저장소 (내가 소유)

Supabase 또는 PostgreSQL 기반 DB. 고객 정보·구매 이력·태그·메모·이벤트 로그를 명확한 스키마로 저장합니다. 모든 진실의 출처(Source of Truth)는 여기입니다. 외부 도구가 들고 있는 데이터는 사본일 뿐입니다.

레이어 2: 이벤트 버스 (결합 분리)

고객이 무언가를 했을 때(구매, 문의, 방문, 이탈 신호 등) 이벤트를 발행합니다. 어떤 도구가 그 이벤트를 받아서 처리할지는 언제든 바꿀 수 있습니다. 이벤트 버스가 있으면 "이 일이 일어났다"와 "그래서 어떻게 한다"가 분리됩니다.

레이어 3: 외부 도구 (교체 가능)

메시지 발송은 GHL이 해도 되고, Resend가 해도 되고, 자체 구축해도 됩니다. 레이어 2와 레이어 3 사이의 어댑터에서만 특정 도구의 API 포맷으로 변환합니다. 도구를 바꿀 때 손대는 곳이 어댑터 하나로 줄어듭니다.

레이어 4: AI 레이어

Claude나 OpenAI 같은 모델은 레이어 2의 이벤트를 보고, 메시지를 어떤 톤으로 쓸지, 보낼지 말지를 맥락 기반으로 판단합니다. AI도 결국 갈아끼울 수 있는 부품의 하나입니다.

구현 시 주의점

1. 이벤트 스키마는 초기에 못 박는다

이벤트 이름·필드·타입 표준을 프로젝트 초기에 정해두면 1~2년 뒤 유지보수 비용이 1/10이 됩니다. purchase.completed, customer.churned, message.sent 같은 이벤트가 어떤 필드를 담는지 한 문서에 정리해 두는 일이 가장 중요합니다.

2. 다이렉트 API 호출과 메시지 큐를 구분한다

"고객에게 메시지 보내기"를 코드 곳곳에 직접 박아두면, 도구를 바꿀 때 수십 군데를 다 고쳐야 합니다. 큐에 넣고 워커 하나가 처리하게 만들면 워커만 바꾸면 됩니다.

3. PII는 가능한 한 엄격하게 보호한다

고객 이메일, 전화번호, 결제 정보는 암호화하고 접근 권한을 분리합니다. 벤더 락인을 푼다고 해도 내가 관리하는 DB에서 유출되면 의미가 없습니다. 데이터 소유의 책임은 항상 양면입니다.

4. 모든 외부 통신은 어댑터를 통한다

GHL을 직접 호출하는 코드, Resend를 직접 호출하는 코드, 카카오 API를 직접 호출하는 코드—이걸 다 한 곳에 두면 안 됩니다. EmailSender, KakaoSender 같은 인터페이스를 만들고 실제 구현체만 갈아끼웁니다.

축적되는 자산

이 아키텍처로 2~3년 운영하면 클라이언트는 결정적인 자산을 갖게 됩니다. 고객 데이터 그 자체가 축적되는 자산입니다.

도구 교체 비용이 6개월에서 몇 주로 줄어든다
새로운 AI 모델이 나오면 다음 날 적용할 수 있다
벤더 가격 협상에서 우위에 선다(언제든 옮길 수 있으니)
가장 중요한 건, 우리 회사가 우리 고객을 어떻게 다룰지를 우리가 결정한다

벤더는 결국 메시지 발송이라는 기능 하나를 제공합니다. 데이터는 그보다 훨씬 큰 가치입니다.

시작은 작게

처음부터 4-레이어를 다 깔 필요는 없습니다. 보통은 이렇게 시작합니다.

첫 달: Supabase에 고객 테이블과 이벤트 테이블만 만든다
둘째 달: 기존 도구(GHL 등)에서 매일 데이터를 동기화해 가져온다
셋째 달: 새 메시지 발송 한 종류를 어댑터 패턴으로 만든다
이후: 나머지 발송을 하나씩 옮긴다

작게 시작하고, 도구가 아니라 데이터를 먼저 자기 자리에 둡니다. 그게 락인을 피하는 가장 단단한 방법입니다.