기존 CRM은 그대로 두고, 카카오톡 자동화만 다시 연결한 방법

CRM 자동화가 대부분 잘 작동하는데 카카오톡 발송만 멈췄다면, 전체 퍼널을 새로 만들어야 할까요? 웹핏은 이미 운영 중이던 FluentCRM을 그대로 두고, 단종된 연동 서비스가 맡았던 카카오톡 연결만 WordPress REST API와 직접 만든 HTTP 요청으로 복구했습니다. 새 도구로 갈아타는 것보다 고객이 익숙하게 쓰던 운영 방식을 지키는 편이 더 중요하다고 판단했기 때문입니다.

자동화는 있었지만 카카오톡만 보낼 수 없었습니다

이 프로젝트는 아무것도 없는 상태에서 자동화를 새로 만드는 일이 아니었습니다. 고객은 FluentCRM으로 고객마다 다른 마케팅 퍼널을 구성하고 있었습니다. 조건에 따라 고객을 나누고, 필요한 메시지가 이어지도록 만드는 기본 흐름도 이미 사용하고 있었습니다.

문제는 카카오톡이었습니다. FluentCRM과 카카오톡 발송을 연결해주던 외부 서비스가 종료되면서 기존 방식으로는 알림톡을 보낼 수 없게 됐습니다. CRM 안의 퍼널이 움직여도 마지막 전달 채널이 끊기면 고객이 실제로 받는 메시지는 완성되지 않습니다.

겉으로 보면 ‘카카오톡 발송 기능 하나를 추가하는 일’처럼 보입니다. 그러나 실제로는 다음 경계를 차례로 확인해야 했습니다.

• FluentCRM 안의 기존 조건과 퍼널은 정상적으로 실행되는가
• 발송에 필요한 고객 정보와 메시지 값이 다음 단계로 전달되는가
• WordPress가 외부 발송 요청을 안전하게 받을 수 있는가
• 카카오톡 발송 API가 인증된 요청으로 처리되는가
• 실패했을 때 어느 구간에서 멈췄는지 구분할 수 있는가

웹핏은 카카오톡이 오지 않는다는 현상만 보지 않고, 이미 작동하는 구간과 새로 연결해야 하는 구간을 먼저 나눴습니다.

전체 퍼널을 다시 만드는 선택도 가능했습니다

n8n이나 Make에서 처음부터 새로운 자동화를 만드는 방법도 있었습니다. 웹핏은 두 도구에서 제공하는 전용 모듈 없이도 HTTP 요청을 직접 구성해 여러 서비스를 연결해본 경험이 있었습니다. 기술적으로는 전체 흐름을 다른 도구로 옮기는 선택도 가능했습니다.

하지만 새로 만들 수 있다는 것과 새로 만들어야 한다는 것은 다릅니다. 고객은 이미 FluentCRM을 중심으로 고객별 퍼널을 설치하고 관리하고 있었습니다. 전체를 옮기면 카카오톡 연결뿐 아니라 기존 조건, 관리 화면, 운영 방법까지 함께 달라집니다. 작동하던 구조를 다시 검증해야 하고 고객도 새로운 사용법을 익혀야 합니다.

그래서 웹핏의 판단은 단순했습니다.

정상적으로 작동하는 FluentCRM 퍼널은 남기고, 사라진 카카오톡 연결만 다시 만든다.

이 결정으로 프로젝트의 범위도 선명해졌습니다. CRM을 교체하는 프로젝트가 아니라, FluentCRM이 만든 신호를 WordPress REST API가 받아 카카오톡 발송 요청으로 바꾸는 연결 프로젝트가 됐습니다.

전용 모듈 대신 HTTP 요청을 직접 설계했습니다

자동화 서비스의 전용 모듈은 편리하지만, 원하는 서비스가 목록에 없거나 기존 연동이 종료되면 그대로 사용할 수 없습니다. 이때 필요한 것은 또 다른 도구를 찾는 일이 아니라 각 서비스가 어떤 데이터를 주고받는지 이해하는 일입니다.

웹핏은 FluentCRM에서 발생한 정보를 REST API로 받을 수 있도록 WordPress 쪽 연결 지점을 구성했습니다. 그다음 발송에 필요한 값을 카카오톡 API가 요구하는 형식으로 정리하고, 인증 정보와 함께 HTTP 요청을 보내도록 설계했습니다.

공개 사례에서는 실제 API 주소, 인증 헤더, 고객 정보, 템플릿 식별값과 내부 함수 코드를 노출하지 않습니다. 핵심은 특정 코드 한 줄이 아니라 `FluentCRM → REST API → 카카오톡 발송`이라는 경계를 다시 연결한 방식입니다.

오류를 한 번에 보지 않고 단계별로 분리했습니다

연결을 만들었다고 바로 메시지가 도착한 것은 아니었습니다. 테스트 과정에서는 외부 발송 서비스가 요청을 거부하는 문제도 확인됐습니다. 웹핏은 테스트 데이터를 직접 보내면서 WordPress가 요청을 받는지, 인증이 통과하는지, 발송 서비스가 요청을 허용하는지를 구간별로 살폈습니다.

그 과정에서 발송 요청 IP의 허용 설정이 필요한 것을 확인했습니다. 요청 IP를 허용 목록에 반영한 뒤 테스트 알림톡이 정상적으로 도착하는 것까지 검증했습니다. ‘발송 실패’라는 하나의 현상을 API 수신, 인증, 외부 서비스 요청으로 나눴기 때문에 원인을 좁힐 수 있었습니다.

사람이 관리할 부분과 자동으로 움직일 부분을 나눴습니다

자동화가 완성돼도 고객이 직접 관리해야 할 영역은 남습니다. 고객은 FluentCRM에서 고객별 퍼널과 실행 조건을 구성합니다. 웹핏이 만든 연결은 그 조건이 실행된 뒤 필요한 데이터를 받아 카카오톡 발송으로 넘기는 역할을 합니다.

고객이 계속 담당하는 영역

• 고객마다 필요한 FluentCRM 퍼널 구성
• 메시지를 보낼 조건과 시점 결정
• 고객에게 전달할 메시지와 마케팅 과정 관리
• 실제 운영 중 발송 대상과 내용 확인

웹핏이 담당한 영역

• 기존 FluentCRM 구조와 끊어진 연결 구간 파악
• WordPress REST API 수신 구조 설계
• 발송 서비스에 맞는 HTTP 요청 구성
• 인증과 요청 IP 허용 문제 점검
• 테스트 메시지의 실제 도착 확인
• 고객이 직접 운영할 수 있도록 Zoom으로 사용법 안내

사용법 안내까지 포함한 이유는 자동화가 개발자의 화면에서만 작동해서는 운영 도구가 될 수 없기 때문입니다. 고객은 이후에도 자신의 고객에 맞춰 퍼널을 구성해야 합니다. 어디에서 조건을 만들고, 카카오톡 연결이 어느 지점에서 이어지는지 알아야 기존 운영 방식 안에서 사용할 수 있습니다.

바뀐 것은 CRM이 아니라 마지막 전달 방식이었습니다

이번 프로젝트는 FluentCRM을 더 큰 시스템으로 교체한 사례가 아닙니다. 이미 고객이 사용하던 CRM과 퍼널을 보존하면서 끊어진 카카오톡 채널을 다시 사용할 수 있게 만든 사례입니다.

고객은 카카오톡 연결이 가능해지면서 자신이 만드는 고객별 마케팅 퍼널에 이 채널을 활용할 수 있을 것 같다는 의견을 전했습니다. 이는 고객이 밝힌 활용 기대이며, 매출이나 전환율이 증가했다는 측정 결과를 뜻하지 않습니다.

현재 확인된 결과는 테스트 알림톡이 정상적으로 발송됐고, 기존 FluentCRM 구조를 유지한 채 새로운 연결을 사용할 수 있게 됐다는 점입니다. 발송률, 운영 시간 절감, 문의 또는 구매 전환 변화는 별도 측정 자료가 없어 이 사례의 성과로 표현하지 않습니다.

자동화에서 중요한 것은 새로 만드는 능력만이 아닙니다

자동화 도구가 바뀌거나 연동 서비스가 종료되면 전체 시스템을 다시 만들어야 한다고 생각하기 쉽습니다. 하지만 운영 중인 구조에는 고객이 익숙한 관리 방식과 이미 검증된 조건이 함께 들어 있습니다. 이를 모두 교체하는 일은 기술적인 제작 범위를 넘어 운영 방식까지 바꾸는 결정입니다.

웹핏은 이번 프로젝트를 통해 다시 확인했습니다. 자동화의 원리는 도구 이름보다 `어떤 사건이 시작점인지`, `어떤 데이터가 다음 단계로 가는지`, `실패를 어디에서 확인할지`에 있습니다. 이 세 가지가 분명하면 전용 모듈이 없어도 HTTP 요청으로 연결할 수 있고, 기존 시스템을 살려야 할지 교체해야 할지도 판단할 수 있습니다.

사용 중인 CRM은 잘 작동하지만 특정 메시지나 외부 서비스 연결만 멈췄다면, 전체를 갈아엎기 전에 먼저 물어볼 질문이 있습니다.

지금 정말 고장 난 것은 전체 자동화인가요, 아니면 마지막으로 데이터를 넘기는 연결 한 구간인가요?

웹핏의 업무 자동화 구축 서비스는 현재 사용 중인 도구와 운영 방식을 먼저 살펴보고, 유지할 부분과 새로 연결할 부분을 구분해 자동화를 설계합니다.