옴니채널 오케스트레이션은 정확히 무엇을 자동화하는가

같은 유저에게 채널마다 다른 담당자가 따로따로 메시지를 기획·발송하면, 하루에 앱 푸시·이메일·문자가 겹쳐서 나가 오히려 이탈을 부추기는 경우가 실무에서 자주 발생합니다. 옴니채널 오케스트레이션은 이 문제를 채널별로 흩어진 발송 판단을 하나의 시나리오로 통합해 해결하는 접근입니다.

세그먼트(4강)가 "누구에게 보낼 것인가"를 정의한다면, 옴니채널 오케스트레이션은 "그 사람에게 어떤 순서로, 어떤 채널로 보낼 것인가"를 자동화하는 계층입니다. Braze는 이 기능을 Canvas라는 저니 빌더로 제공하며, 공식 문서에 따르면 Canvas는 푸시·이메일·SMS·인앱·WhatsApp·RCS는 물론 광고 오디언스 목적지까지 하나의 시나리오 안에서 크로스채널로 오케스트레이션합니다. 즉 마케터가 매번 "이 세그먼트에게 이메일 보내기"를 수동으로 실행하는 대신, "조건 A를 만족하면 저니에 진입 → 1단계 앱 푸시 발송 → 24시간 내 미반응 시 2단계 이메일 발송 → 다시 미반응 시 3단계 카카오 친구톡 발송"이라는 시나리오를 한 번 설계해두면 이후 조건을 만족하는 모든 유저에게 자동으로 반복 적용됩니다.

채널 순서는 어떤 기준으로 정하나

실무에서 채널 순서를 정하는 가장 일반적인 원칙은 "저비용·고빈도 채널을 먼저 쓰고, 반응이 없을 때만 상대적으로 비용이 높거나 침투력이 강한 채널로 넘어간다"는 것입니다. 앱 푸시는 발송 비용이 사실상 없고 즉시 도달하지만 오픈율이 낮을 수 있고, 이메일은 도달률은 높지만 확인까지 시간이 걸릴 수 있으며, 카카오 친구톡·알림톡 같은 메시징 채널은 국내 소비자 반응률이 높은 대신 발송당 과금이 발생합니다. 이 비용·반응 구조를 고려해 앱 푸시 → 이메일 → 친구톡 순서로 단계를 쌓고, 각 단계에서 목표한 반응(예: 앱 열기, 이메일 클릭)이 확인되면 다음 단계로 넘어가지 않고 저니를 종료하는 방식이 일반적입니다.

저니 설계에서 미리 정의해야 할 두 가지

저니가 의도대로 작동하려면 설계 단계에서 두 가지를 반드시 미리 정의해야 합니다. 첫째는 각 단계 사이의 대기시간입니다—"몇 시간(또는 며칠) 동안 반응이 없으면 다음 채널로 넘어갈 것인가"를 정하지 않으면, 실시간으로 반응한 유저에게까지 다음 단계 메시지가 중복으로 나가는 사고가 생깁니다. 둘째는 "반응"의 판정 기준입니다—앱 푸시의 반응을 단순히 "알림 노출"로 볼지 "앱 실행까지"로 볼지에 따라 저니의 다음 단계 진입 여부가 완전히 달라집니다. 이 두 기준은 채널·목표(구매 유도, 재방문 유도)에 따라 달라지므로, 저니를 만들기 전에 팀 내에서 명시적으로 합의해두는 절차가 필요합니다.

세그먼트-저니 연결에서 자주 생기는 설계 오류

가장 흔한 설계 오류는 세그먼트 조건과 저니 진입 조건을 다르게 해석하는 것입니다. 예를 들어 4강의 "장바구니 5만 원 이상" 세그먼트가 실시간으로 갱신되는 조건이라면, 유저가 저니 1단계(앱 푸시)를 받은 뒤 장바구니를 비워도 여전히 세그먼트에 남아있는지, 아니면 즉시 이탈해 2단계(이메일) 발송 대상에서 제외되는지를 미리 확인해야 합니다. 이 확인 없이 저니를 설계하면, 이미 결제까지 완료한 유저에게 계속 장바구니 독촉 메시지가 나가는 사고로 이어질 수 있습니다—이 문제는 다음 강(7강)에서 실패 사례로 자세히 다룹니다.

저니 성과는 채널별로 어떻게 나눠서 봐야 하나

옴니채널 저니를 돌리기 시작하면 "이 저니 전체가 몇 건의 구매를 만들었는가"만 보는 데서 그치지 않고, 각 단계에서 몇 명이 반응해 이탈했는지를 퍼널로 쪼개서 봐야 합니다. 1단계 앱 푸시에서 반응률이 낮은데 2단계 이메일에서 반응률이 갑자기 높다면, 애초에 1단계를 이메일로 바꾸는 편이 전체 저니 완주 시간을 단축시킬 수 있습니다. 반대로 3단계(친구톡)까지 가서야 반응하는 유저가 많다면, 비용이 높은 채널을 뒤에 배치한 순서 설계가 맞았다는 뜻입니다. 이 단계별 퍼널 데이터는 대부분의 저니 빌더가 기본 리포트로 제공하므로, 저니를 만든 뒤 최소 1~2주는 이 리포트를 보며 순서·대기시간을 조정하는 튜닝 기간을 갖는 것이 좋습니다.