Head of Business가 CS 자동화를 직접 만들기로 한 이유
B2B SaaS를 운영하다 보면, 고객 이탈의 가장 결정적 신호가 구조화된 지표가 아닌 대화의 흐름 속에 있다는 걸 알게 됩니다.
고객 이탈은 대시보드가 아니라 채널 사이에서 벌어진다
B2B SaaS를 운영하다 보면, 고객 이탈의 가장 결정적 신호가 구조화된 지표가 아닌 대화의 흐름 속에 있다는 걸 알게 됩니다.
라플라스의 고객 접점은 최소 네 곳으로 나뉘어 있습니다. VIP 고객과는 카카오톡으로 일상 대화를 나누고, 주요 고객사와는 슬랙 전용 채널에서 실시간 협업을 하며, 채널톡으로 일반 문의를 받고, 오프라인 미팅 기록은 또 별도로 쌓입니다. 여기에 결제·구독 이벤트 알림이 또 다른 슬랙 채널로 쏟아집니다.
이런 구조에서 가장 자주 발생하는 문제는 이렇습니다.
고객이 카카오톡으로 "기능이 이상한데요" 문의 → 담당자가 슬랙 VOC 채널에 이슈 등록 → 개발팀이 PM 채널에서 디버깅 논의 → 고객사 전용 채널로 안내 → 다시 카카오톡으로 마무리
한 이슈가 네다섯 채널에 걸쳐 전개됩니다. 담당자가 회의에 들어가는 순간 이 흐름을 이어받을 방법이 없고, "요즘 자주 사용하지 않아요" 같은 결정적 이탈 신호는 그 사이 어딘가에 묻힙니다.
Head of Business로서 저는 이 문제를 프로세스 문제가 아니라 데이터 구조 문제로 정의했습니다.
의사결정: CRM을 사지 않기로 한 이유
가장 쉬운 선택지는 Salesforce나 HubSpot 같은 범용 CRM을 도입하는 것이었습니다. 하지만 세 가지 이유로 이 길을 가지 않기로 했습니다.
첫째, 도입 비용 대비 효용이 애매했습니다. 우리 팀 규모에서 범용 CRM 도입은 연간 수천만 원의 라이선스 비용과 최소 2~3개월의 이관·교육 기간이 필요합니다. 그런데 우리가 정말 해결하고 싶은 문제는 "고객 데이터를 담을 그릇"이 아니라 "여러 채널에 흩어진 대화를 한 고객의 타임라인으로 연결하는 것"이었습니다.
둘째, 우리 팀만 아는 이탈 신호 규칙을 범용 툴이 학습할 수 없습니다. "VIP 고객이 3일 이상 무응답" "플랜 취소 알림이 같은 사용자에게 3회 이상" 같은 규칙은 우리 비즈니스 맥락에서만 의미가 있습니다. 이걸 범용 CRM의 자동화 워크플로에 우겨넣는 것보다, 우리 맥락에 맞게 직접 설계하는 편이 빠르다고 판단했습니다.
셋째, 팀이 이미 Notion과 Slack에 완전히 정착해 있었습니다. 새 툴을 도입하면 팀은 처음엔 따르지만 2~3주 지나면 원래 쓰던 곳으로 돌아갑니다. 새 CRM에 데이터를 넣는 습관을 만드는 것보다, 이미 하루 종일 머무는 Slack/Notion 위에 시스템을 얹는 편이 훨씬 지속 가능합니다.
그래서 방향을 바꿨습니다.
새 툴을 사지 말고, 지금 쓰는 툴을 연결하자.
왜 Claude Code + MCP였나
이 방향을 실행할 수 있게 만든 결정적 변수는 MCP(Model Context Protocol) 의 등장이었습니다.
1년 전이었다면 이 프로젝트는 개발자 없이는 불가능했습니다. Slack Bot Token 발급, Notion Integration 토큰 관리, .env 파일 세팅, SDK 설치, OAuth 처리… 비개발자인 제가 막힐 포인트가 너무 많았습니다.
MCP 기반으로 가면 이 과정이 이렇게 줄어듭니다.
명령어 두 줄이면 끝입니다. OAuth 인증 한 번 거치면 Claude Code가 Slack과 Notion을 직접 읽고 쓸 수 있습니다. API 키 발급·관리 자체가 사라집니다.
더 중요한 건 코드를 거의 쓰지 않아도 된다는 점이었습니다. Claude Code는 프로젝트 루트의 CLAUDE.md 파일을 읽고 자연어 지시대로 MCP 도구를 호출합니다. "슬랙 billing 채널에서 어제 이후 메시지를 가져와서 Notion 고객 DB에 매칭시켜줘" 같은 지시를 문서로 써두면 그대로 실행됩니다.
제가 Python이나 TypeScript를 쓰지 않고도 자동화 파이프라인을 설계하고 운영할 수 있게 된 것이 이 프로젝트의 첫 번째 전환점이었습니다.
시스템 구조: 3개 레이어
처음엔 단순히 "슬랙 메시지를 Notion에 붙여넣기" 수준으로 시작했습니다. 하지만 실제 데이터를 굴려보니 금방 한계가 보였습니다. 앞서 말한 "한 이슈가 네다섯 채널에 걸쳐 전개되는 문제"를 해결하려면 구조를 처음부터 제대로 잡아야 했습니다.
최종적으로 정착한 구조는 3개 레이어입니다.
Raw Layer는 손대지 않습니다. 카카오톡 CSV, 슬랙 스레드, 채널톡 문의를 원본 그대로 저장합니다. 나중에 "그때 고객이 정확히 뭐라고 했지?"를 역추적할 수 있어야 하기 때문입니다.
Issue Layer가 이 프로젝트의 핵심 아이디어입니다. "카카오톡 문의 → 슬랙 VOC → PM 채널 디버깅 → 전용 채널 응답 → 카카오톡 마무리"를 하나의 이슈 ID로 묶습니다. 담당자가 회의 중이어도 다른 팀원이 이슈 페이지 하나만 열면 전체 흐름이 시간순으로 보입니다.
CS Interaction Layer에서 Claude가 요약과 위험도 판단을 붙입니다. 여기가 실제로 "이번 주 이탈 위험 고객이 누구인지"를 묻게 될 종착지입니다.
Notion에는 기존 고객사 리스트 DB를 중앙 허브로 두고, CS 인터랙션 DB를 Relation으로 연결했습니다. 필드는 고객사, 채널, 발생일·해결일, 위험도(🔴🟠🟡⚪), Claude 요약, 해결 여부, 원본 링크로 구성했습니다.
실행 중 마주친 두 가지 문제
문제 1. 고객사 이름이 제각각이다
사람이 직접 친 메시지에는 같은 회사를 이렇게 부릅니다.
라플리스, 라플라스 애널리틱스, (주)라플라스, 라플라스애널리틱스
단순 문자열 매칭으로는 절반 이상이 매칭에 실패합니다. 여기서 퍼지 매칭이 필요했는데, 다행히 Claude 자체에게 매칭을 맡기면 됩니다.
단, confidence가 낮은 경우(0.7 이하)는 자동 매칭하지 않고 사람이 확인하는 단계를 두었습니다. 잘못된 매칭이 쌓이면 고객 히스토리 자체가 오염됩니다. 자동화에서 "자동으로 틀리는 것"보다 "사람에게 물어보는 것"이 훨씬 비용이 쌉니다.
문제 2. 한 이슈가 여러 채널에 퍼져 있다
앞서 언급한 핵심 문제입니다. 처음엔 "채널별로 요약하면 되겠지" 라고 안일하게 생각했는데, 실제로 돌려보니 같은 이슈가 세 곳에 중복으로 들어가거나, 반대로 PM 채널 논의만 남고 고객 측 반응은 누락되는 식이었습니다.
그래서 Issue Layer가 필요했던 겁니다. Claude에게 "이 메시지가 기존 이슈의 연장선인지, 새 이슈인지 판단해달라"고 요청하는 파이프라인을 붙였습니다.
원본 raw 데이터를 전부 Notion에 올리면 용량 문제가 생기므로, 원본은 로컬에 두고 관계만 Notion에 저장하는 하이브리드 구조로 갔습니다.
이탈 위험 스코어링: 비즈니스 룰의 코드화
자동화의 최종 목적은 결국 이탈 방지입니다. 그래서 위험도 판단 규칙을 비즈니스 관점에서 명확히 정의했습니다.
| 조건 | 위험도 |
|---|---|
| VIP 또는 이탈 이력 고객의 VOC가 1일 이상 미응답 | 🔴 긴급 |
| 일반 고객의 VOC가 3일 이상 미응답 | 🟠 높음 |
| 같은 사용자의 플랜 취소 알림이 3회 이상 | 🔴 긴급 |
| 해지, 환불, 실망, 최악, 탈퇴, 그만 등 부정 키워드 | 🟠 높음 |
중요한 건 "미응답 기간"이라는 객관 지표와 "부정 감성"이라는 정성 지표를 함께 본다는 점입니다. 응답은 빨랐지만 고객 반응이 냉랭한 경우도, 응답은 늦었지만 고객이 기다려주는 경우도 있기 때문입니다.
규칙을 한 번에 완벽하게 만들려는 욕심을 버린 게 오히려 빠른 진전으로 이어졌습니다. 2~3주 돌려보며 "실제 이탈로 이어진 케이스"와 "거짓 경보"의 비율을 보면서 계속 조정하고 있습니다.
사람의 워크플로우에 데이터를 연결하기
데이터를 아무리 잘 쌓아도 보러 들어가지 않으면 쓸모가 없습니다. Notion을 매일 아침 여는 습관은 일정 시간이 지나면 반드시 무너집니다.
그래서 모인 데이터의 접점을 사람이 이미 있는 공간 — 슬랙 으로 끌어냈습니다. #product-manage 채널에서 Slack Bot을 @멘션으로 호출하면 Notion CS 인터랙션 DB를 조회해 답합니다.
담당자 부재 시 다른 팀원이 이 명령 하나로 컨텍스트를 파악할 수 있다는 것이 프로젝트의 원래 목표였고, 지금 실제로 작동하고 있습니다.
리더가 직접 만들어보며 배운 세 가지
1. 문제는 '데이터가 없어서'가 아니라 '데이터 사이에 관계가 없어서' 생긴다
초반의 가장 큰 실수는 자동화부터 짜려 한 것이었습니다. "슬랙 메시지를 Notion에 밀어넣자"로 시작했더니 데이터는 쌓이는데 쓸모가 없었습니다. 같은 이슈가 중복되고, 고객사별 히스토리가 끊겨 있었습니다.
멈춰서 온톨로지(Raw → Issue → Interaction) 부터 설계한 후 다시 시작했을 때 비로소 시스템이 작동했습니다. "데이터를 모으는 것"과 "데이터 간 관계를 설정하는 것"은 완전히 다른 문제입니다.
이건 라플라스가 매일 고객사에 하는 말이기도 합니다. 주문·광고·CS·물류 데이터를 각각 쌓는다고 해서 AI가 의미 있는 답을 주지 않습니다. 데이터 사이의 관계가 설정된 토대 위에서만 AI가 제대로 일합니다. 고객에게 하는 말을 저희 내부에서 직접 증명한 셈입니다.
2. AI 시대의 'Build vs Buy' 기준이 바뀌었다
과거의 Build vs Buy 판단은 "개발 리소스가 있느냐 없느냐"에 달려 있었습니다. 대부분의 스타트업은 리소스가 없으니 사는 쪽이 답이었죠.
MCP가 이 전제를 흔들었습니다. 이제 기준은 "우리만 아는 업무 맥락이 얼마나 중요한가" 입니다. 현장 맥락이 무기인 영역 — 예컨대 B2B 고객 성공, 전문직 워크플로우, 업계 특수 규칙 — 에서는 범용 SaaS가 아무리 뛰어나도 현장 맥락을 따라올 수 없습니다. 그리고 이제는 리소스 없이도 현장이 직접 만들 수 있습니다.
리더로서 이 변화를 체감한 것이 이 프로젝트의 가장 큰 수확이었습니다. 앞으로 "이건 외부 툴을 사자"를 말하기 전에, 먼저 "우리 맥락을 아는 사람이 직접 만들면 얼마나 걸릴까"를 묻게 됐습니다.
3. "우리가 직접 씁니다"는 가장 강한 세일즈 메시지다
B2B SaaS 시장에서 "AI로 업무 자동화가 가능합니다"라고 말하는 회사는 많습니다. 하지만 그 회사가 자기 내부 업무를 실제로 AI로 자동화하고 있는지는 완전히 별개 문제입니다.
라플라스는 고객사의 주문·광고·상품·CS 데이터에 관계를 설정해 AI가 분석할 수 있게 만드는 인프라를 파는 회사입니다. 같은 철학을 내부에 적용하지 않으면 설득력이 없습니다. 이 프로젝트는 단순한 생산성 향상을 넘어, 라플라스 팀이 일하는 방식 자체가 프로덕트의 가장 좋은 데모가 되는 지점을 만들어줬습니다.
다음 단계
현재는 1차 버전이 사내에서 돌아가는 단계이고, 확장 방향은 세 가지입니다.
-
데이터 볼륨 증가에 따른 저장소 이관 — Notion이 느려지는 임계점이 오면 SQLite 또는 Supabase로 Raw Layer 이관
-
미팅 로그 연동 — 오프라인 미팅 녹취·노트까지 Issue Layer에 엮기
-
이탈 예측 정교화 — 단순 규칙 기반을 넘어, 라플라스 본 프로덕트의 이탈 예측 로직과 내부 CS 데이터를 결합
마치며
비슷한 고민을 하는 B2B SaaS 리더들에게 권하고 싶은 것은 하나입니다.
새 CRM을 사기 전에, 이미 쓰고 있는 툴을 MCP로 연결해보십시오. 들어가는 시간은 예상보다 훨씬 적고, 얻는 통찰은 예상보다 훨씬 큽니다. 그리고 그 통찰은 외주 개발사나 컨설팅 보고서에서는 절대 나오지 않습니다. 현장을 아는 사람이 직접 손을 대봐야만 보이는 종류의 것들입니다.
AI 시대의 경쟁력은 더 좋은 AI를 쓰는 데서 오지 않습니다. AI가 제대로 일할 수 있는 데이터 환경을 먼저 갖춘 팀, 그리고 그 환경을 직접 설계할 수 있는 리더십을 가진 조직에서 옵니다.
이 글이 비슷한 결정을 앞둔 분들에게 하나의 참고점이 되기를 바랍니다.
라플라스는 D2C 커머스 브랜드를 위한 데이터 분석 인프라입니다. 흩어진 주문·광고·상품·CS 데이터에 관계를 설정하고, AI가 바로 이해할 수 있는 형태로 제공합니다.