팀에 초대도 안 한 유저에게 5일째 같은 메일이 가는 이유

Customer.io와 ActiveCampaign은 한 가지 일을 잘하라고 만들어진 도구예요. 리스트를 올리고, 기본 필터로 오디언스를 잡고, drip 시퀀스를 설계하는 것. 안정된 청중에게 일관된 메시지를 보내는 브로드캐스트 이메일이죠. 뉴스레터·제품 공지·캠페인엔 지금도 잘 맞아요.

그런데 PLG(Product-Led Growth, 제품이 자체로 유저 확보·확장을 끌어가는 모델) 라이프사이클 메시징은 완전히 다른 종류의 일이에요. 행동의 “순서”에 대해 추론해야 하거든요. “이 유저가 온보딩을 마쳤고, 그 뒤에 조용해졌는가?”, “feature wall에 부딪히기 전에 팀원을 초대했는가?”, “업그레이드를 했는가, 아니면 paywall에 세 번 부딪힌 뒤 떠났는가?”

이런 로직은 “유저가 무엇을 했고 안 했는지를 시계열·실시간으로 임의로 깊게 묻는” 능력이 필요해요. 메시징 도구는 이런 질문에 답하라고 설계된 게 아니에요. 리스트에 메일을 쏘라고 설계된 거죠.

그래서 많은 팀은 자기 제품 데이터보다 더 멍청한 트리거 로직을 갖게 돼요. 라이프사이클 마케팅을 잘못 해서가 아니라, 행동 기반 작업에 브로드캐스트 도구를 쓰고 있어서.

PostHog 팀이 You're doing lifecycle emails wrong 라는 글에서 이 문제를 정면으로 다뤘는데, 메시징 스택을 깔아본 사람이라면 본인 얘기처럼 들릴 거예요. Grantable, Croissant 같은 PostHog 고객사의 실제 운영 코멘트가 같이 인용돼 있고요.

아무도 설계하지 않은 하이브리드가 만들어진다

대부분의 팀은 이벤트 추적이 아직 빈약할 때 메시징 스택을 일찍 깐대요. signup 이벤트 하나, key action 한두 개 정도. 그래서 시퀀스를 시간 기반으로 짤 수밖에 없었어요. 신뢰할 수 있게 트리거 걸 수 있는 게 그것뿐이었으니까. Day 1 환영, Day 3 nudge, Day 7 체크인. 출시했고, 돌아갔고, 그걸로 충분했어요.

그러다 제품 계측이 깊어져요. 기능 사용, 활성화 마일스톤, 플랜 변경. 이 모든 게 분석 도구로 흘러들어가요. 그런데 시퀀스는 옛 아키텍처 그대로 돌아가요. open rate가 그럭저럭 봐줄 만하고, 더 급한 일이 항상 있었거든요.

결과는 “아무도 설계하지 않은 하이브리드”예요. 행동 로직을 대신하는 시간 기반 트리거, 진짜 순간이 아니라 sync 시점에 평가되는 오디언스 정의, 각 유저의 라이브 피드가 아니라 “초상화(portrait)”만 보고 일하는 메시징 도구.

구체적으로는 이런 식이에요. “팀원을 초대하지 않은 유저”에게 day 5에 발사되는 이메일이 있어요. 만들 당시엔 팀원 초대 이벤트를 안정적으로 트리거 걸 방법이 없었거든요. 지금은 가능한데, 시퀀스가 업데이트되지 않았어요. 그래서 day 2에 이미 팀원을 초대한 유저한테도 day 5에 같은 메일이 가요.

잘못된 사람에게 잘못된 시점에 메일을 보내는 시퀀스의 낮은 전환율은, 약한 제목줄 때문에 낮은 전환율과 정확히 똑같이 보여요. 둘의 차이는 “메시징 도구가 유저에 대해 사실이라고 믿는 것”과 “분석 도구가 실제로 보여주는 것”을 교차 검증해야 비로소 드러나요.

sync 문제는 증상이지 원인이 아니다

본능적으로 떠오르는 처방은 데이터 파이프라인을 조이는 거예요. sync 간격을 짧게, property 매핑을 더 잘, 정기적으로 무엇이 건너간 건지 감사. 할 만한 일이긴 한데, 증상을 치료하는 거예요.

더 깊은 문제는, 행동 로직을 그것을 제대로 평가할 데이터가 없는 도구 안에서 돌리고 있다는 거예요. Zapier·Make로 복잡한 프로덕션 자동화를 다시 깔아본 적 있는 Grantable의 Evan Rallis가 이렇게 말했어요.

“그 위에 올라가는 핵심 데이터셋이 따로 없어요. 수동으로 계속 데이터를 밀어넣지 않는 한.” 그게 예쁜 과정이 아니거든요. 그리고 제품이 바뀔 때마다, 그걸 전부 다시 배선해야 해요.

속도의 한계는 sync가 얼마나 빠르냐가 아니에요. 무엇을 sync 하기로 기억했느냐예요. 메시징 도구는 우리가 명시적으로 밀어넣은 property에 대해서만 질문할 수 있어요. 제품이 이미 만들어내고 있는 이벤트 스트림 전체에 대해서가 아니라.

Zapier, Windmill 등 대안 대부분을 써본 Croissant의 Jorge López도 같은 얘기를 다른 각도로 했어요.

“도구들 사이에 데이터를 sync 하는 건 항상 hit-or-miss고, 비싸요. 이제 다 한 곳에 있어서, 우리는 훨씬 빠르게 iterate해요.”

그 속도 차이는 결국, 누가 2년 전 깔아둔 sync 스키마에 묶인 트리거 로직과, 제품이 지금 이 유저에 대해 아는 모든 것에 대해 추론할 수 있는 트리거 로직의 차이예요.

처방은 네 갈래로 갈린다

저성과 라이프사이클 이메일의 올바른 처방은, 이게 “매핑 문제”인지 “sync 문제”인지 “아키텍처 문제”인지에 따라 달라요. 표면적으로는 비슷해 보여요. 낮은 전환, 잘못된 사람에게 가는 메일. 그런데 해법은 달라요.

1. 다른 거 손대기 전에 시퀀스를 감사하라

가장 중요한 시퀀스 다섯 개를 훑어요. 각 트리거에 대해 물어봐요. 이게 시간 기반인 게 시간이 실제로 합리적이어서인지, 아니면 “행동 기반 트리거를 깔기 어려웠던 시절의 잔재”인지. 분석 도구에서 그 오디언스를 교차 검증해요. 이미 행동을 한 유저에게 그 행동을 권하는 메일이 가고 있는 건 아닌지.

대부분의 팀은 적어도 한 시퀀스가 보내지 말아야 할 유저에게 보내고 있고, 분석에 추적되는 행동 시그널 중 메시징 로직으로 절대 건너가지 못한 게 하나쯤은 있다는 걸 발견해요.

명백한 불일치부터 고치는 것만으로도 바늘이 움직여요. 그리고 그 작업이 구조적 한계가 정확히 어디에 있는지를 알려줘요.

2. 데이터 파이프라인을 조여라

시퀀스가 논리적으로 옳은데 여전히 잘못 발사된다면, 문제는 sync에 있을 거예요.

sync 간격을 짧게, 실제로 검증한 명시적인 property 매핑을 만들고, 메시징 도구 안의 값과 분석 도구 안의 값을 정기적으로 비교해요. 여기서 silent failure가 흔해요. property 매핑 하나 깨졌는데 아무도 못 보고, 시퀀스가 stale data 위에서 몇 달째 발사돼요.

가장 안 흥미로운 처방인데, 가장 저평가된 처방이기도 해요. 많은 성능 문제가, 기저 데이터가 정확하고 신선해지는 순간 사라져요.

3. 분석 도구에서 오디언스를 미리 자격화하라

메시징 도구 안에서 오디언스를 정의하지 말고, 데이터가 가장 신선한 곳에서 오디언스를 빌드한 뒤 cohort를 sync 해 트리거 거는 방법이에요. 더 수동적이지만, 신뢰하는 소스에서 일하는 거지 sync가 제때 따라잡았기를 비는 게 아니에요. 트리거 로직이 문제고 시퀀스 자체는 견고할 때 좋은 선택지예요.

4. 트리거 로직을 데이터가 사는 곳으로 옮겨라

가장 구조적인 처방은 “로직이 어디서 도는가”를 다시 생각하는 것이에요. 자동화가 별도의 도구 안에 사는 한, 우리는 “무엇을 sync 하기로 기억했느냐”에 묶여요 — 파이프라인을 건넌 property에 대해서만 질문할 수 있죠. 자동화가 풀 이벤트 스트림 위에서 직접 돌면, 진짜로 원하는 행동 로직을 표현할 수 있어요.

우리가 진짜로 쓰고 싶었던 시퀀스, 즉 “이 유저가 X를 할 때까지 기다리거나, 안 하면 7일 뒤에 발사” 같은 문장 는, 그걸 돌리는 도구가 모든 것을 볼 수 있어야 비로소 표현 가능한 문장이에요.

데이터와 로직이 한 자리에 있을 때 바뀌는 것

트리거 로직과 데이터가 같은 곳에 있을 때, 직접 겪어보지 않으면 진가를 모르는 몇 가지가 달라져요.

시간 기반 시퀀스를 행동 기반의 대용품으로 쓰던 걸 그만두게 돼요. “Day 5 nudge” 대신, “이 유저가 가입 후 5일 안에 팀원을 초대하지 않았을 때 이 메일을 보내라”라고 쓰고, 그 문장 그대로 의도해요. 시퀀스가 발사되는 순간에 유저에 대해 우리가 실제로 아는 것을 반영해요.

시퀀스가 짧아져요. 전형적인 온보딩 플로 안 이메일 상당수는 불확실성을 덮으려고 존재해요. 유저가 활성화됐는지 모르니까, 만약을 위해 nudge를 한 번 더 보내요. 진짜 행동 상태로 분기할 수 있으면, 필요 없는 사람에게 메일 보내는 걸 그만두게 돼요.

그리고 드디어 시퀀스가 작동하는지를 측정할 수 있어요. open rate·클릭이 아니라, 플로에 진입한 유저가 그 행동을 실제로 했는지를. 측정에 필요한 데이터가 트리거를 건 데이터와 같은 곳에 살기 때문이에요.

결국 이 글의 무게는 한 문장으로 압축돼요. “속도의 한계는 sync가 얼마나 빠르냐가 아니라, 무엇을 sync 하기로 기억했느냐다.”

본 글은 PostHog Blog에서 발행한 원문 You’re doing lifecycle emails wrong을 번역한 것입니다. 원문의 의도와 다를 수 있으며, 정확한 내용은 원문을 참고하세요.