들어가며
안녕하세요! 카카오VX 마케터 장창명입니다. 오늘은 CRM 자체 솔루션 구축 vs Braze 유료 솔루션, 두 가지 방법을 모두 직접 리드해 본 경험을 바탕으로 각각의 장단점을 솔직하게 비교해 보려고 합니다.
2년여 전, 저는 홈쇼핑모아에서 유료 솔루션 없이 개발자분과 함께 푸시 자동화/개인화 솔루션을 자체 구축했고, 그 결과 푸시 클릭률을 2배로 끌어올리면서, 전반적인 푸시 성과를 개선시켰습니다. 구축 및 고도화 과정은 아래 1·2편에서 마케터 관점과 개발자 관점으로 나눠 소개해 드렸는데요.
1편 (마케터 관점) :
2편 (개발자 관점) :
스타트업에서 CRM 푸시 자동화/개인화 자체 개발한 방법
그리고 이번에는 반대편에 섰습니다. 카카오골프예약 플랫폼의 Braze 기반 CRM 고도화 프로젝트의 PM을 맡으면서 데이터 파이프라인부터 이벤트·어트리뷰트 설계, API 명세, 캠페인 구조까지 전체 설계를 리드하게 되었습니다. "돈 안 들이고 직접 만드는 CRM"과 "돈 내고 쓰는 유료 CRM 솔루션", 과연 무엇이 어떻게 다를까요? 지금부터 톺아보는 시간을 가져보겠습니다.
PART1. 두 번의 CRM 구축, 무엇을 리드했나
두 프로젝트 모두 제 역할은 "마케팅에서 원하는 시나리오를 구체화하고 개발과 브레이즈 언어를 번역해 설계하는 사람"이었습니다. 다만 도구가 달랐기 때문에 설계해야 하는 범위도 꽤 달랐는데요.
1) 2년 전 : 홈쇼핑모아 자체 CRM 솔루션 0->1 구축
사용자 시나리오 기반 트리거 포인트 설계 (예: 장바구니 담고 1~2시간 내 미구매 시 리마인드)
일·주·월 단위 / 행동 기반 등 푸시 다양한 유형을 정의하고, 로우코드 툴(Budibase)로 마케터용 푸시 어드민 구축
커스텀 CDP 설계 : 푸시 데이터가 MongoDB에 일별로 쌓이도록 구조를 잡고, 개발자분과 Redash에서 SQL·Python으로 발송·도달·클릭·CTR·전환 수치 등의 대시보드 구축
2) 지금 : 카카오골프예약 Braze CRM 0->1 구축 및 고도화
데이터 파이프라인 설계 : 앱·서버 → Braze로 보낼 커스텀 이벤트·어트리뷰트 택소노미를 정의하고, 기존 DB 필드명과 최대한 맞춰 정합성 확보
발송 방식 설계 : 푸시 개인화 방식과 내부 개발 여건에 따라 Connected Content와 API 트리거 중 어느 쪽이 맞는지 판단
API 명세·역할 분리 : 요청·응답 JSON, 인증 방식, 예외 처리, 재시도 정책 등을 개발팀과 논의·합의해 기획서로 작성
푸시 개인화 설계 : Liquid 문구, 딥링크, 빈도 제한, 재수신 규칙, 전환 이벤트 설정
흥미로운 점은, 2년 전 자체 솔루션을 만들 때도 사실 Braze 같은 유료 솔루션의 기능을 많이 벤치마킹했다는 것입니다. 그때 "이 기능을 흉내 내려면 개발이 얼마나 들까"를 고민했던 경험 덕분에, 이번에는 Braze의 각 기능이 왜 그렇게 생겨났는지가 훨씬 잘 보였습니다.
솔직히 말씀드리면 쉬운 길은 아니었습니다. 보통 Braze를 도입할 때는 마티니 같은 해당 분야의 전문 컨설팅사·대행사와 함께 구축하는 경우가 많은데요. 저희는 초기 도입이기도 하고 비용 이슈로 파트너사 없이 혼자서 데이터 설계부터 캠페인 세팅까지 모든 걸 떠맡아 진행해야 했습니다. 그래서 초반에 계약된 짧은 온보딩 서비스 기간 동안 궁금한 것들을 압축해서 쏟아내며 Braze 매니저님을 꽤나 괴롭혔던 기억이 납니다. (이 자리를 빌려 감사드립니다!) 또 Braze의 AI 오퍼레이터는 도입 초기라 DEMO에서 정해진 토큰 안에서만 질문할 수 있어 많이 묻지는 못했지만.. ㅠ 세팅 구조를 검증하고 Liquid로 렌더링한 푸시 결과를 테스트하는 데 엄청 큰 도움을 받았습니다.
돌이켜 보면, 그동안 해왔던 자그마한 개발 경험과 홈쇼핑모아에서 개발자분들과 부딪히며 익힌 다양한 데이터 언어(SQL, 스키마, API JSON, NoSQL) 활용 경험이 이번에 전체 판을 짜는 데 큰 밑천이 되어 주었습니다.
PART2. 한눈에 비교하기
결론부터 말씀드리면, 자체 구축은 "처음 정한 규격 안에서" 강력하고, Braze는 "규격 밖의 것을 개발 없이" 해낼 수 있다는 점이 가장 큰 차이였습니다. 또 A/B 테스트부터 Control Group(대조군) 설정까지, 캠페인 성과를 분석하기에도 Braze가 마케터에게 더 편한 환경이었습니다. 표로 정리해보면 아래와 같다고 생각합니다. (가볍게만 봐주세요!)
PART3. 장단점 자세히 톺아보기
1) 메시지 개인화 : Liquid vs 고정 템플릿
가장 체감이 컸던 부분입니다. Braze는 Liquid라는 템플릿 문법을 쓰는데요. 데이터만 잘 설계해 두면, 그 뒤로는 개발 없이 딥링크를 포함한 모든 메시지를 유연하게 개인화할 수 있습니다. 포인트는 데이터가 어디에 있느냐에 따라 Liquid 문법이 달라진다는 점인데요. 실제로 제가 설계하며 사용한 5가지 유형을 정리해 보겠습니다.
① 커스텀 어트리뷰트 : 유저 프로필에 저장된 값
유저 프로필에 저장된 "현재 값"을 가져옵니다. 예를 들어 닉네임(nickname)을 호칭으로 쓰고, 값이 없으면 고객님으로 대체합니다.
{{custom_attribute.${nickname} | default: '고객'}}님
② 커스텀 이벤트 · 구매 이벤트 : 유저가 방금 한 행동의 속성
유저가 특정 행동을 했을 때, 그 행동과 함께 전달된 속성을 가져옵니다. 예를 들어 특정 행동 완료 이벤트에 골프장명(golfInfoname)이 담겨 있다면, 이 이벤트를 트리거로 하는 액션 기반 캠페인에서 이렇게 씁니다.
{{event_properties.${golfInfoname}}}
구매 이벤트도 같은 방식으로 속성을 꺼낼 수 있고, 속성 이름은 앱·서버가 실제로 보내는 이름과 정확히 같아야 합니다. 캔버스에서는 범위가 조금 다른데요. 진입 이벤트의 속성은 context로, 여정 중 Action Path에서 발생한 이벤트 속성은 그 경로의 첫 번째 메시지에서 event_properties로 꺼냅니다.
③ API 트리거 : 서버가 담아 보낸 값
서버가 캠페인을 호출하면서 trigger_properties에 담은 값을 가져옵니다. 뒤에서 소개할, 현재 준비 중인 리워드 알림이 이 방식입니다.
{{api_trigger_properties.${golfInfoname}}}
{{api_trigger_properties.${reward_amount} | number_with_delimiter}}
{{api_trigger_properties.${reward_type}}}
발송 시점과 값을 서버가 정할 때 적합합니다. 단, Liquid는 받은 값을 보여줄 뿐 리워드를 지급하지는 않습니다. 지급 판단은 언제나 서버의 몫입니다.
④ 커넥티드 콘텐츠 : 발송 순간 외부 API에서 조회한 값
반대로 Braze가 메시지를 만들 때 우리 서버를 호출해 응답을 가져오는 방식입니다. (아래 주소와 필드는 설명용 예시입니다.)
{% connected_content https://YOUR_API_ENDPOINT :save response %}
{{response.golfInfoname}}
API 오류나 필수 값 누락 시에는 abort_message로 발송을 멈추도록 처리해야 안전합니다. 한 줄로 정리하면 API 트리거는 "서버 → Braze로 값을 밀어주는" 방식, 커넥티드 콘텐츠는 "Braze → 서버에 값을 물어보는" 방식입니다.
⑤ 카탈로그 : Braze에 저장해 둔 공통 데이터
상품이나 골프장 정보처럼 여러 유저가 공통으로 쓰는 데이터를 Braze 카탈로그에 올려두고, 아이템 ID로 조회합니다. (카탈로그명과 ID는 예시입니다.)
{% catalog_items golf_teetime_catalog prodcutid_yyyymmdd_00:00 %}
{% if items[0].golfInfoname == blank %} {% abort_message('카탈로그 정보 누락') %}
{% endif %}
{{items[0].golfInfoname}}
실제 발송에서는 유저별로 해당하는 아이템 ID를 연결해야 합니다.
사실 뒤에서 소개할 가격하락 알림도 처음에는 카탈로그 방식으로 먼저 설계했습니다. {상품(골프장)}{날짜}{시각} 형태의 복합키를 유저 어트리뷰트(마지막으로 본 티타임)와 카탈로그 ID 양쪽에 똑같이 넣어두고, Liquid로 엑셀의 VLOOKUP처럼 1:1 매칭하는 구조였는데요.
개발팀이 정해진 주기로 가격 정보를 카탈로그에 배치 갱신만 해두면, 그 뒤 세그먼트·문구·발송은 마케터가 개발 없이 운영할 수 있는 그림이었습니다.
특히 카탈로그에는 Price Drop(가격 하락) 알림 기능이 따로 있어서, 카탈로그의 가격 값이 내려가면 해당 상품에 관심을 보였던 유저에게 자동으로 알림을 보낼 수 있었습니다. 가격하락 알림이라는 목적에는 기능적으로 정말 막강했고, 설정도 편했습니다.
다만 카탈로그는 별도 비용이 드는 유료 기능이라, 테스트 환경에서 설계와 기능 검증까지만 진행했습니다. 직접 테스트해 보며 느낀 커넥티드 콘텐츠와의 차이는 이렇습니다.
결국 가격처럼 수시로 바뀌는 값에는 발송 순간에 물어보는 커넥티드 콘텐츠가 더 맞다고 판단해, 가격하락 알림은 최종적으로 커넥티드 콘텐츠로 구조를 확정했습니다. 카탈로그는 상품·골프장처럼 자주 바뀌지 않는 공통 데이터를 여러 캠페인에서 돌려 쓸 때 빛을 발할 것 같아, 추후 활용을 검토하고 있습니다.
더 자세한 문법은 Braze 공식 문서를 참고해 주세요 : 커스텀 이벤트 속성 · API 트리거 캠페인 · 커넥티드 콘텐츠 · 카탈로그 사용
반면 자체 구축 때는 최초에 정한 규격의 템플릿 외에 새로운 템플릿이 필요할 때마다 개발자분의 여러 번의 배포가 필요했습니다. 위 5가지 유형을 하나씩 따로 개발해야 했던 셈이죠. "골프장명 대신 지역명을 넣어볼까?" 같은 작은 실험 하나에도 개발 일정을 기다려야 했습니다.
2) 실시간 데이터 : Connected Content
발송하는 순간 Braze가 우리 서버에 "지금 값"을 물어보는 기능입니다. 가격·재고처럼 자주 바뀌는 값을 매일 배치로 쌓을 필요 없이, 조회용 API 하나만 있으면 됩니다. 조건이 맞지 않는 유저는
abort_message 기능으로 그 사람에게만 발송을 취소할 수도 있습니다. 자체 구축 때는 배치 주기 때문에 "이미 낡은 값"이 나갈 수 있는 구조였습니다.
3) 이벤트 기반 즉시 발송 : API 트리거
결제 승인, 리워드 지급처럼 Braze는 모르고 우리 서버만 아는 사건이 생기면, 서버가 Braze API를 한 번 호출하는 것만으로 개인화된 푸시가 나갑니다. 자체 구축 때는 이 "발송 큐 + 스케줄러 + 통계"를 모두 직접 만들어야 했습니다.
4) 발송 안전장치
수신동의 확인, 빈도 제한(Frequency Capping), 야간 발송 금지 시간대가 기본으로 들어 있습니다. 1편에서 말씀드렸듯 푸시는 수신거부(Opt-out)라는 가드레일 지표를 항상 같이 봐야 하는데요. 자체 구축에서는 이 안전장치를 하나하나 설계하고 검증해야 했습니다.
5) 성과 측정 · 대시보드 : 커스텀 CDP + Redash vs Braze 리포트
2년 전 자체 구축 때는 성과를 보기 위한 판부터 직접 깔아야 했습니다. 제가 설계한 흐름은 이렇습니다.
1.푸시 ID 규칙 설계 : 푸시 종류 + 날짜 + 요소를 조합해, ID만 봐도 언제 어떤 푸시인지 알 수 있게 정의
2.커스텀 CDP 설계 : 발송·도달·클릭 데이터가 매일 새벽 MongoDB에 일별로 적재되도록 구조 설계
3.대시보드 구축 : 개발자분과 함께 Redash(BI)에서 SQL과 Python으로 쿼리를 짜서 발송 수, 도달 수, 클릭 수, CTR 대시보드 구축
4.모니터링 : Slack Webhook으로 주요 지표를 실시간 알림
덕분에 매일 Kibana에 들어가 푸시 ID를 하나하나 쿼리하던 수작업이 사라졌지만, 지표 하나를 추가하려 해도 스키마와 쿼리를 다시 손봐야 했습니다.
Braze에서는 발송·오픈·전환(예: 예약 완료)이 캠페인 리포트에 바로 잡히고, A/B 테스트도 문구만 나눠 넣으면 됩니다. "A/B 테스트는 마케터의 숙명"이라고 말씀드렸던 만큼, 실험 한 번의 비용이 낮아지는 건 생각보다 큰 차이였습니다.
6) 2년 전과 가장 달라진 점 : AI와 MCP
사실 2년 전과 지금의 가장 큰 차이는 도구보다 AI입니다. 지금은 Claude 같은 뛰어난 AI가 있고, MCP(Model Context Protocol)라는 연결 방식이 생겼습니다. MCP는 쉽게 말해 AI가 Braze 같은 외부 서비스의 데이터에 직접 접근할 수 있게 해주는 표준 연결 통로인데요.
7) 그럼에도 자체 구축이 나은 점이 있다면?!
물론 Braze가 정답만은 아닙니다.
비용 : 라이선스 비용이 적지 않아, 초기 스타트업에는 부담이 될 수 있습니다.
완전한 커스터마이징 : 우리 서비스 흐름에 100% 맞춘 구조를 만들 수 있고, 벤더 스펙에 묶이지 않습니다.
데이터 소유 : 모든 발송·반응 데이터가 우리 DB에 바로 쌓입니다.
팀의 역량 : 직접 만들어 본 팀은 "CRM이 어떻게 돌아가는지"를 속속들이 이해하게 됩니다.
반대로 Braze도 "잘 설계해야" 빛을 발합니다. 이벤트·어트리뷰트 구조를 대충 잡으면 아무리 비싼 솔루션이라도 쓸 수 있는 제한이나 제약도 너무 많고 개인화가 금방 바닥나지 않을까 싶네요.
PART4. 실제 사례로 보는 Braze 설계
사례에 앞서, 제가 설계할 때 기준으로 삼는 가이드를 간단히 정리하면 이렇습니다. (부족하지만, 어쩄든 제 험 바탕으로 공유드리니 단순하게 참고만 해주세요!)
커넥티드 콘텐츠 : 누구에게, 언제 보낼지는 Braze(세그먼트·스케줄)가 정하고, 발송 순간 우리 API를 호출해 메시지를 개인화하는 것이 주기능입니다. 조건이 맞지 않으면 그 유저만 발송에서 빼는 것도 가능합니다.
API 트리거 : 누구에게(유저 ID), 언제, 무엇을 보낼지 서버가 발송 대상까지 직접 정해 더 긴밀하게 컨트롤합니다. 다만 수신동의·빈도 제한 같은 마지막 관문은 여전히 Braze가 지킵니다.
이런 기준을 두고, 캠페인마다 내부적으로 어떤 방식이 더 효과적이고 효율적인지 고민해본 뒤 방식을 결정하고 있습니다.
사례 1. 가격하락 알림 푸시 — Connected Content
결제화면까지 들어왔다 나간 유저에게, 그 티타임(상품)의 가격이 내려가면 알려주는 캠페인입니다. 가격은 내부 서버에서 실시간으로 바뀌기 때문에 Braze는 이를 알 수 없습니다. 그래서 발송 대상, 시각, 빈도 제한 같은 기본 설정은 Braze가 맡고, 발송 순간 우리 서버에 유저별로 조회했던 상품의 현재 가격을 물어봐 가격이 내려간 유저에게만 개인화 메시지를 보내는 구조로 설계했습니다.
Braze가 최근 N일 내 결제화면 진입자를 대상으로 매일 정해진 시간에 발송 시작
유저별로 가격조회 API 호출 (마지막으로 본 티타임(상품) PK 키 등)
서버가 하락 여부·할인금액·할인율을 응답
하락이 없으면 그 유저만 발송 취소, 있으면 골프장명·할인금액을 넣어 발송
광고 푸시 형태기 때문에 기존 정보성 푸시로 똑같은 가격 푸시를 받았다면 Abort 처리(서버판단)
발송 시각도 감이 아닌 데이터로 정하려고 합니다. 일정 기간의 가격 하락 시각을 분석해, 하락분을 가장 많이 포착하면서도 가장 효과적이고 효율적인 시간대를 찾고 있고, 그 시간대를 발송 시각으로 잡기 위해 테스트를 이어가고 있습니다.
사례 2. 재예약 유도 리워드 알림 — API 트리거 (현재 준비 중)
API 트리거는 지금 한창 테스트해보고 활용을 준비 하고 잇는 방식입니다. 특히 서버가 직접 판단해서 유저 ID를 실어 보내야 하는 자동화 푸시라면 이 방식이 맞다고 보고 있는데요. 예를 들어 첫 번째 시나리오로 유저가 특정 행동을 한 뒤 재예약하지 않은 경우 리워드를 지급하고, 지급 즉시 재예약을 유도하는 캠페인을 설계하는 방식으로도 활용해볼수 있습니다. "지급이 성공했다"는 사실과 금액은 네부 쿠폰&리워드 시스템에서만 알고 있기 때문에, 행동 직후를 정확히 타겟팅 하기에는 API 트리거가 가장 효과적인 방법인것 같습니다.
아직은 러프한 단계지만, 내부에서 이런저런 시나리오를 그려보며 커넥티드 콘텐츠보다 더 깊은 개인화가 필요한 구간부터 API 트리거를 적용해 보려고 합니다. 여러 테스트를 준비하고 있고, 결과가 나오면 다음 글에서 공유드리겠습니다.
PART5. 도입 6개월, 운영하며 생긴 변화
Braze를 도입하고 고도화를 이어가다 보니, 제 역할도 자연스럽게 넓어졌습니다. 캠페인 설계와 운영은 물론이고, 사업팀뿐 아니라 부서별 Braze 내부 교육까지 말 그대로 맥시멀하게 맡게 되었는데요. 도입한 지 6개월이 지난 지금은 Braze를 다루는 담당자분들이 꽤 많아졌습니다. 혼자 모든 걸 떠맡아 시작했던 초반을 생각하면 꽤 뿌듯한 변화입니다.
물론 모든 캠페인이 성공한 건 아닙니다. 기대만큼 반응이 없어 접었던 실패한 캠페인도 분명히 있었습니다. 하지만 대부분의 캠페인은 "가설 수립 → 개인화 → 실험 → 고도화"의 사이클을 돌리며 점차 성과를 내고 있습니다. 1편에서 "A/B 테스트는 마케터의 숙명"이라고 말씀드렸던 것처럼, 실패도 다음 가설을 위한 데이터가 된다는 마음으로 계속 디벨롭해 나가고 있습니다.
PART6. 그래서, 우리 회사는 뭘 골라야 할까?
앞서 말씀드렸듯 마케팅에 절대적인 정답이 없는 것처럼, CRM 도구도 회사의 단계와 상황에 따라 답이 달라집니다. 제 경험상 이렇게 나눠 볼 수 있을 것 같습니다.
다만 어느 쪽을 고르든 공통점은 하나인 것 같습니다. 유료 솔루션을 쓰든 자체적으로 구축하든, "어떤 데이터를, 어떻게, 언제 보낼지" 시나리오를 설계하려면 서비스 전반에 대한 이해와 유저에 대한 깊은 이해를 바탕으로 A부터 Z까지 꿰뚫고 있어야 된다는 사실..(당연한 말이지만요!) 그래야 비로소 어떤 도구를 쓰든 더 좋은 결과로 이어지는 것 같습니다.
마무리하며
비록 두 프로젝트 사이에는 2년이 넘는 시간이 흘렀지만, 그럼에도 불구하고 두 번의 경험은 저에게 굉장히 의미 있었습니다. 자체 솔루션을 구축할 때 Braze의 기능을 벤치마킹했던 경험이 있었기에, 이번에 CRM 개발 PM으로서 전체 설계를 리드하며 "왜 이 기능이 이렇게 생겼는지"를 훨씬 빨리 이해할 수 있었습니다.
결국 자체 구축과 유료 솔루션, 두 가지 방법을 모두 거치며 각각의 장단점을 머리가 아닌 손으로 익힐 수 있었던 좋은 경험이었다고 생각합니다. 저의 이 '경험'과 '노하우'가 CRM 도입을 고민하는 마케터와 스타트업 유관자분들께 조금이나마 도움이 되길 바라며, '마케터의 비밀서재 인사이트편' 마무리하도록 하겠습니다.
같이 읽어보면 도움되는 글↓↓
↓↓ 1편 보러가기 (마케터 관점) 스타트업에서 유료 솔루션 없이 푸시클릭율 2배 만들기
↓↓ 2편 보러가기 (개발자 관점) 스타트업에서 CRM 푸시 자동화/개인화 자체 개발한 방법