판단의 출발점

CRM 이전을 준비할 때 먼저 정해야 할 것은 “누가 언제부터 발송하는가”입니다. 같은 고객이 두 도구에 동시에 등록돼 있는 기간에도, 같은 업무 메시지를 보내는 책임은 한쪽에만 있어야 합니다.

이 글에서는 고객 식별이 맞고, 수신 판단이 보존되며 캠페인별 발송 책임과 중단·복귀 조건이 확인된 상태를 전환 완료 기준으로 제안합니다. 가져온 행 수가 같다는 이유로 캠페인을 켜지 않습니다. 이전할 데이터와 실제로 발송할 수 있는 대상을 분리하고 작은 시험 집단부터 책임을 넘기는 방식입니다.

범위는 영업 파이프라인이나 상담 기록 전체가 아니라 푸시·이메일·문자와 자동 캠페인을 운영하는 CRM·메시징 환경입니다. 구체적인 기능 차이는 기존 앱을 유지하면서 Braze에서 OneSignal로 옮기는 경우로 설명합니다. 특정 제품을 추천하거나 실제 고객의 이전 결과를 소개하는 사례는 아닙니다. 제품 문서는 2026년 9월 26일 기준으로 확인했습니다.

잔류·업그레이드·이전 중 선택이 남아 있다면 OneSignal 유료 플랜 전환 안내서의 판단 항목을 먼저 검토합니다. 여기서는 이전을 결정한 다음의 기술적 전환을 다룹니다.

옮길 대상을 여덟 가지로 나눕니다

OneSignal은 고객을 나타내는 User와 채널 접점을 나타내는 Subscription을 구분합니다. 한 고객에게 여러 기기와 채널의 구독이 연결될 수 있습니다. 자체 고객 ID인 external_id, OneSignal이 부여하는 사용자 ID, 개별 Subscription ID를 같은 값으로 취급하면 안 됩니다. OneSignal Users[1] · Subscriptions[2].

다음 표는 이전 작업을 나누기 위한 설계 예시입니다. ‘유지’는 원래 값이나 의미를 보존한다는 뜻이지, 원본 파일을 그대로 넣으면 된다는 뜻은 아닙니다.

이전 대상원본에서 확인할 것목표 환경의 처리완료를 판단할 증거
고객 식별내부 고객 ID, Braze ID, 익명 ID, 기기 연결유지·변환. 내부 고객 ID를 기준으로 목표 ID와 대응표 작성다른 사람이 합쳐지지 않고, 한 사람의 기기들이 의도대로 연결됨
채널별 구독·토큰앱·플랫폼·기기별 토큰, 이메일, 전화번호조건부 유지·재등록. 모바일과 웹의 전환 경로를 분리주소나 토큰의 존재뿐 아니라 해당 채널의 발송 준비가 확인됨
권한·동의·수신 거부기기 권한, 채널 상태, 목적별 동의·거부와 변경 근거의미 보존. 서로 다른 상태를 별도 필드로 유지거부·미확인 상태가 가져오기 기본값 때문에 허용으로 바뀌지 않음
이벤트·고객 속성이벤트 이름, 자료형, 단위, 시간대, 최신 변경 시점변환. 필요한 속성과 앞으로 들어올 이벤트 경로를 재정의같은 업무 사실이 같은 의미로 해석되고 과거 이벤트가 새 발송을 만들지 않음
세그먼트조건식, 제외 조건, 고객·기기 중 평가 단위재구축. 현재 명단과 이후 적용할 조건식을 별도로 검증같은 시점의 대상 집합과 이후 진입·이탈 조건이 설명됨
캠페인 규칙메시지, 일정, 대기 단계, 재진입, 빈도 제한, 종료 조건재구축. 진행 중인 대상을 어떻게 이어갈지 별도 결정이미 처리한 단계는 반복하지 않고, 남은 단계의 담당 도구가 정해짐
이력·성과 데이터제공되는 내보내기 범위, 집계 정의, 보존 조건가능 범위 보관. 새 도구의 실행 상태로 직접 옮긴다고 가정하지 않음원본 이력의 위치와 한계, 전후 지표를 비교할 수 있는 범위가 기록됨
운영 권한·자격 증명관리자, API 권한, 앱·발신자 설정, 예약 작업재설정. 필요한 권한만 부여하고 종료 대상을 구분운영자가 발송·중단·조사할 수 있고, 옛 경로의 무단 발송이 차단됨

식별 기준으로는 도구를 바꿔도 유지할 수 있는 내부 고객 ID를 권합니다. 이메일 주소나 전화번호가 같다는 이유만으로 사람을 합치지 않습니다. 익명 사용자의 연결 근거가 없으면 익명으로 남기거나 발송 대상에서 보류합니다. 빈 ID를 모두 같은 대체 값으로 채우는 방식도 피해야 합니다.

특히 공유 기기에서는 A가 로그아웃하고 B가 로그인하는 상황을 시험해야 합니다. OneSignal의 로그인 처리는 구독이 연결되는 사용자를 바꿀 수 있기 때문입니다. “첫 로그인 때 연결됐다”만 확인하지 말고 계정 전환 후 소유자와 속성을 다시 확인합니다. OneSignal Users[1].

서비스 작동 방식

기능과 수신 동의를 확인하며 전환 — 사용 중인 캠페인을 새 환경에 맞춰 검증하고 구독자 이전과 병행 운영으로 전환 조건을 확인합니다.

‘수신 가능’이라는 필드 하나로는 부족합니다

OS·브라우저 권한은 해당 기기에서 알림을 허용하는 상태입니다. 기술적 채널 구독은 특정 토큰·주소를 대상으로 채널을 이용할 수 있는 상태입니다. 마케팅 동의와 수신 거부는 어떤 목적과 채널의 메시지를 받겠다는 의사에 관한 기록입니다. 이전 설계에서는 이 세 축을 합치지 않습니다.

Braze에서도 기기의 푸시 활성화 상태와 사용자 프로필의 푸시 구독 상태는 구분됩니다. 프로필의 Subscribed는 기본 상태이며 Opted-In은 OS 알림 권한을 수락한 흐름에서 설정될 수 있습니다. 따라서 이 값 하나를 목적별 마케팅 동의의 증빙으로 해석해서는 안 됩니다. Braze Push subscription states[3].

이메일·문자 구독 그룹도 별도로 확인해야 합니다. Braze의 구독 그룹 조회 API는 상태 변경 이력이 있는 그룹을 반환하므로, 응답에 그룹이 없다는 사실을 수신 허용으로 바꿔 읽지 않습니다. 또한 OneSignal의 푸시 구독 해지는 모든 채널의 해지와 같은 동작이 아닙니다. Braze 구독 그룹 조회[4] · OneSignal Subscriptions[2].

권하는 설계는 고객 ID·채널·목적별로 상태, 변경 시각, 출처, 버전을 남기는 기준 기록을 두는 것입니다. 두 도구의 값이 충돌하거나 근거가 빠졌다면 자동 발송을 보류합니다. 검증 가능한 이후의 재동의는 별도로 반영할 수 있지만 CSV 재업로드나 SDK 초기화를 재동의로 취급하지 않습니다. 이는 상태 보존을 위한 기술 설계이며 개별 메시지의 법적 발송 요건을 확정하는 기준은 아닙니다.

예를 들어 어제 만든 내보내기 파일에는 ‘허용’이지만 오늘 사용자가 거부한 상황을 시험할 수 있습니다. 설계 예시로, 내일 그 파일을 다시 가져오거나 앱이 구독을 새로 등록하더라도 오늘의 거부가 발송 차단에 남아 있어야 합니다. 삭제한 고객이 오래된 파일에서 되살아나는 경우도 같은 방식으로 막습니다.

동의 기록을 무조건 영구 보관하자는 뜻은 아닙니다. 필요한 최소 정보와 접근 권한, 보존·삭제 정책을 먼저 정하고 그 범위 안에서 이전 중 상태가 역전되지 않도록 해야 합니다.

토큰을 옮길 수 있는 조건은 채널마다 다릅니다

모바일은 앱과 발송 자격을 함께 봅니다

Apple의 APNs 토큰은 기기와 앱의 조합에 대응합니다. 다른 앱의 토큰처럼 재사용할 수 없습니다. 앱 식별, 개발·운영 환경, APNs 인증 설정이 맞는지 확인해야 합니다. Firebase도 인증된 발신자와 토큰의 발신자 조건이 맞지 않으면 SENDER_ID_MISMATCH를 반환합니다. 토큰 문자열 복사만으로 발송 경로가 이어진다고 판단하지 않는 이유입니다. Apple APNs 등록[5] · APNs 연결 조건(Apple 보관 문서)[6] · FCM 오류 코드[7].

OneSignal로 가져올 때도 차이가 있습니다. iOS의 유효한 구독은 조건이 맞으면 SDK 활성화 전에도 푸시를 받을 수 있지만 확인된 수신과 클릭 추적에는 활성 SDK가 필요합니다. Android는 OneSignal SDK가 기기에서 활성화돼 있어야 정상적인 수신 경로가 성립합니다. iOS의 원시 APNs 토큰과 FCM 등록 토큰도 구분해야 합니다. OneSignal 이전 가이드[8].

같은 앱의 메시징 도구를 교체하는 일과 앱 식별·Firebase 프로젝트까지 바꾸는 일을 하나의 작업으로 묶지 않는 편이 좋습니다. 조건이 바뀌는 집단은 토큰 재수집과 앱 배포가 필요한 별도 전환 대상으로 분리합니다.

SDK 병행 설치를 기본값으로 잡지 않습니다

OneSignal은 한 앱 릴리스에서 기존 SDK를 교체하는 방식을 우선 안내합니다. 불가피하게 두 SDK를 함께 유지한다면 토큰 수명주기 관리와 알림 처리기가 충돌하지 않도록 해야 합니다. 단말 안에서 토큰을 관리하는 책임과 서버에서 캠페인을 보내는 책임은 별도로 정해야 합니다. OneSignal 이전 가이드[8].

앱 버전으로 구·신 대상을 나누더라도 실제 발송 대상이 그 경계를 지키는지 확인합니다. 사용자 단위 여정에 여러 기기가 연결돼 있다면, 한 기기의 업데이트만으로 고객 전체의 발송 책임을 옮겨도 되는지 별도 판단이 필요합니다.

웹은 권한 유지와 구독 이전을 구분합니다

OneSignal은 기존 웹 푸시 구독의 직접 가져오기를 지원하지 않습니다. 같은 HTTPS origin에서 이미 알림 권한이 허용돼 있다면, 사용자가 다시 방문할 때 새 구독을 등록하는 경로를 안내합니다. 재방문하지 않은 사용자를 완료 대상으로 세면 안 됩니다. OneSignal 이전 가이드[8].

웹 푸시는 origin, 구독 endpoint와 키, Service Worker 배치를 함께 살펴야 합니다. 기존 푸시용 워커를 교체할 때 PWA 캐시나 오프라인 기능까지 맡는 워커를 무작정 모두 해제하지 않습니다. origin이 달라지는 경우에는 기존 권한이 그대로 따라온다고 가정하지 않고 새 환경의 권한·구독 절차를 검토합니다. W3C Push API Working Draft[9].

이메일과 문자도 수신 주소 이전과 발신 환경 준비를 분리해야 합니다. CSV에는 이메일·전화번호와 관련 상태를 매핑할 수 있지만 이메일 발신 도메인 설정이나 문자 발신자 전환까지 완료됐다는 뜻은 아닙니다. 해당 범위를 확인하지 못했다면 그 채널은 개통 전 상태로 남겨 둡니다. OneSignal Import[10] · Email setup[11] · SMS setup[12].

내보내기 파일은 현재 상태의 일부일 수 있습니다

Braze의 사용자 내보내기 API는 식별자, 구독 상태, 푸시 토큰과 속성을 제공하지만 사용자 프로필의 custom_events·purchases는 최근 90일의 요약 정보입니다. 이를 전체 원시 이벤트 로그나 진행 중인 Canvas의 실행 위치로 취급하지 않습니다. 무엇을 보관할 수 있고 무엇을 재구성해야 하는지 먼저 구분해야 합니다. Braze 사용자 내보내기[13].

목표 쪽에서는 모바일 구독을 Create user API 모델에 맞춰 변환하고 CSV 가져오기는 문서가 지원하는 식별자·주소·속성·상태에 맞춰 사용합니다. 특히 구독 상태를 바꾸는 CSV 작업에는 해당 구독을 식별할 이메일·전화번호·Subscription ID 등이 필요하며 external_id만으로 모든 채널의 상태를 변경한다고 가정하지 않습니다. Create user[14] · Import[10].

OneSignal에서 나중에 다시 내보내거나 전환 결과를 검수할 때도 함정이 있습니다. 구독 CSV를 세그먼트로 제한하면 기본적으로 수신 중인 구독만 포함됩니다. 거부 상태까지 확인하려면 include_unsubscribed=true 조건을 확인해야 합니다. 이 옵션은 세그먼트 지정이 없는 요청에서는 효과가 없습니다. 내보내기의 id는 Subscription ID이므로 고객 ID와도 구별합니다. Export subscriptions CSV[15].

권하는 방식은 기준 시점의 전체 상태와 그 이후의 변경을 따로 관리하는 것입니다. 최초 내보내기 이후 발생한 수신 거부, 삭제, 계정 연결 변경, 신규 구독을 최종 전환 시점까지 반영합니다. API가 ‘최근 활동 사용자’를 골라 준다고 해서 모든 상태 변경을 빠짐없이 잡아 주는 것은 아닙니다. OneSignal의 last_active_since도 활동 시각 필터이지 전체 변경 이력 내보내기라는 약속은 아닙니다. Export subscriptions CSV[15].

변경분을 신뢰성 있게 확보할 수 없다면, 무리한 실시간 병행보다 통제 가능한 변경 중지 구간과 최종 재대조를 설계하는 편이 낫습니다. 다만 수신 거부 접수 자체를 막아서는 안 됩니다. 접수한 변경을 기준 기록에 남기고 양쪽 발송 차단에 반영할 경로가 필요합니다.

전환 실행 절차: 들어갈 조건과 멈출 조건을 같이 정합니다

다음은 특정 제품의 자동 기능이 아니라 여러 공식 문서의 제약을 반영한 전환 실행 절차(Runbook) 설계 예시입니다. 실제 코호트 크기와 관찰 기간은 캠페인의 대기 시간, 앱 업데이트 분포, 메시지 유효기간에 맞춰 정합니다.

단계진입 조건완료 기준과 담당즉시 중단할 조건
1. 시험 코호트ID·상태 매핑, 앱·발신 자격, 시험 계정과 기기 준비. 새 자동 캠페인은 비활성개발 담당이 로그인 전환·기기별 구독을 확인하고 CRM 담당이 허용·거부·보류 결과와 메시지 동작 확인다른 고객으로 연결됨, 거부가 허용으로 바뀜, 예상하지 않은 자동 발송
2. 매핑·정합성 대조기준 시점과 원본 추출 범위 기록. 변경분 수집 또는 최종 재대조 경로 확보데이터 담당이 대상별 결과와 누락 이유를 분류. 거부·삭제 변경을 발송 차단에 반영한 시점까지 확인설명되지 않는 누락·병합, 오래된 상태의 덮어쓰기, 변경분 반영 지연이 허용 범위 초과
3. 캠페인 발송권 전환원본의 신규 진입·예약·대기 대상 처리 방안, 단일 발송 책임, 중단 권한 확보전환 책임자가 원본 차단과 목표 허용 순서를 승인. 같은 업무 메시지의 양쪽 발송 가능 상태가 없음을 확인두 도구가 같은 발송 건을 소유함, 처리 여부 불명인 이전 발송을 새 도구가 재발송하려 함
4. 대상 확대앞 단계 통과와 복귀 조건 유지. 구버전·미방문·미확인 상태를 별도 집단으로 관리개발·CRM 담당이 집단별 수신 경로, 거부 반영, 캠페인 단계·빈도·지표를 확인한 뒤 다음 집단 승인새 집단에서 식별·거부·소유권 문제가 발견되거나, 합의한 실패·지연 기준 초과
5. 원본 시스템 종료남은 고객·기기·대기 메시지의 처리 결정, 필요한 이력 보관, 복귀 종료 시점 승인운영 책임자가 예약·연동·계정을 정리하고 미사용 권한 회수. 계약 종료는 별도 담당이 확인구버전 사용자나 미처리 캠페인이 담당자 없이 남음, 공유 자격 증명 영향이 불명확함

‘양쪽 고객 수가 비슷하다’ 대신 집합이 맞는지 대조해야 합니다. 같은 기준으로 정규화한 발송 건에 대해 원본 담당과 목표 담당이 겹치는지, 어느 쪽에도 속하지 않는 대상이 있는지 확인합니다. 다기기 전체 발송이 의도된 캠페인이라면 그 기기별 발송을 처음부터 예상 범위에 넣어야 합니다.

수치 설계 예시. 고객별로 같은 캠페인 단계의 푸시를 한 번 보낼 후보 1,000건이 있다고 가정합니다. 수신 거부 80건은 제외하고 SDK 미준비 100건과 식별 미확인 20건은 보류하면 발송 가능 집합은 800건입니다.

전체 후보 1,000 = 거부 제외 80 + 보류 120 + 발송 가능 800

원본 담당 500 + 목표 담당 310 - 양쪽 중복 10 = 서로 다른 발송 건 800

대상 800건을 모두 포함해도 중복 10건이 있으면 통과가 아닙니다. 중복된 10건의 목표 발송권을 제거한 뒤에는 원본 500건, 목표 300건, 중복 0건으로 나뉩니다. 이 숫자는 실제 이전 성과가 아니라 검산 가능한 집합 대조 예시입니다. 실제 판정에서는 합계만 맞추지 말고 각 발송 건의 식별자를 비교해야 합니다.

서비스 작동 방식

캠페인에 필요한 데이터부터 연결 — 캠페인에서 역산한 이벤트와 속성을 정의하고 식별자와 전송 시점, 측정 도구의 역할을 맞춥니다.

진행 중인 캠페인은 ‘다시 켜기’로 넘기지 않습니다

세그먼트와 자동 여정은 고객 명단만 복사해서 이어지지 않습니다. OneSignal의 세그먼트에는 구독 단위와 사용자 단위 평가가 있으며, 사용자 단위 조건은 그 사용자의 여러 구독을 대상으로 만들 수 있습니다. 따라서 앱 버전으로 기기를 나눠 놓고 사용자 단위 여정을 양쪽에서 실행하면 의도한 경계를 벗어날 수 있습니다. OneSignal Segments[16].

이전 계획에서는 고객·캠페인·채널·단계마다 발송을 소유하는 도구를 하나로 고정하는 기록을 두는 방식을 권합니다. 어떤 구매나 가입에서 발생한 메시지인지 식별할 업무 이벤트 ID, 캠페인 버전, 단계도 함께 둡니다. 고객 단위 빈도 제한과 기기 단위 전달은 별도 항목으로 관리합니다.

발송권 전환은 원본의 새 발송 차단 → 처리 중·처리 불명 요청 대조 → 최신 수신 상태 반영 → 발송권 버전 갱신 → 목표 발송 허용 순서로 설계합니다. 담당 도구 이름을 표에서 바꾸는 것만으로는 부족합니다. 자체 발송 서버를 쓰는 경로는 발송 직전에 현재 발송권과 처리 기록을 확인하도록 하고 도구 내부에서 직접 실행하는 경로는 실제 예약·여정·권한 설정으로 경계를 적용해야 합니다. 같은 발송 건을 양쪽이 동시에 처리할 수 있는 틈이 남는다면 목표를 켜지 않습니다.

진행 중인 여정에는 두 가지 정리 방식이 있습니다. 기존 여정을 끝까지 처리하는 방식이라면 원본의 신규 진입을 닫고, 남은 대상·단계는 원본이 맡으며 목표 도구에서 제외합니다. 목표 환경에서 남은 단계를 재구성하는 방식이라면 원본의 예약·대기를 정리한 뒤 마지막 처리 단계, 다음 발송 예정 시각, 빈도 제한, 유효기간을 근거로 미처리 부분만 만듭니다. 어느 쪽이 가능한지는 실제 내보내기·중단·조회 기능으로 확인해야 합니다.

과거 이벤트를 분석 목적으로 보관하는 경로와 새 캠페인을 시작시키는 경로도 분리합니다. 지난 구매 이력을 새 구매 이벤트처럼 다시 넣거나, 과거 웰컴 캠페인을 새 환경에서 전원에게 시작시키지 않습니다.

OneSignal에서도 재진입과 종료 설정을 그대로 복사한 것으로 끝내면 안 됩니다. Custom Event 기반 Journey는 같은 사용자의 여러 인스턴스를 허용할 수 있고, 진입과 종료 조건을 동시에 만족해도 첫 단계가 먼저 실행될 수 있습니다. 발송하면 안 되는 대상은 종료 조건만 믿지 말고 진입 전 제외 조건까지 확인합니다. Journey settings[17].

서버의 발송 기록에 중복 방지 키를 두더라도 운영자가 원본 대시보드에서 직접 발송하거나 기본 Journey가 우회 실행하면 효과가 없습니다. API, 자동 여정, 예약 발송, 수동 발송을 모두 같은 책임 경계 안에 넣을 수 있어야 합니다. 이를 보장할 수 없다면 두 도구를 동시에 켜 두는 대신 명시적인 발송 중지 구간을 두는 편이 안전합니다.

OneSignal의 알림 생성 API에는 재시도에 사용하는 idempotency_key가 있고 알림 요청 키는 30일간 유지됩니다. 그러나 이것은 같은 도구 안의 요청 재처리를 제어하는 기능입니다. Braze에서 별도로 보낸 메시지까지 막는 공통 중복 방지 장치로 취급할 수는 없습니다. Idempotent API requests[18].

또한 원본 캠페인을 중단해도 이미 전달 서비스가 받아 대기 중인 알림을 없앴다고 단정할 수 없습니다. FCM은 단말이 연결되지 않았을 때 메시지를 보관했다가 유효기간 안에 전달할 수 있습니다. 이전 요청의 처리 여부가 불명확하면 새 도구에서 즉시 다시 보내기보다 조회·만료·보류 중 어떤 처리를 할지 정해야 합니다. FCM 메시지 수명[19].

Go/No-go는 건수보다 먼저 적용합니다

이 가이드에서 권하는 중단 기준은 명확합니다. 잘못된 고객 병합, 거부 대상의 발송 허용, 같은 발송 건의 이중 소유 중 하나라도 발견하면 해당 범위의 새 발송을 양쪽에서 우선 차단하고 확대를 멈춥니다. 원인을 설명하지 못한 누락과 최신 거부 상태의 반영 여부가 불명확한 상황도 다음 단계로 넘기지 않습니다. 여기서 ‘0건’은 검수의 통과 조건이지 실제 이전 과정의 무손실을 보증하는 수치가 아닙니다.

그다음 실제 수신 경로와 캠페인 결과를 확인합니다. OneSignal의 Delivered는 APNs·FCM에 인계한 상태를, Confirmed는 지원 조건 아래 단말 수신을 나타냅니다. 확인된 수신은 유료 플랜·지원 플랫폼·SDK 설정이 필요하고 Safari 웹 푸시 등 미지원 경우도 있으므로, 값이 없다고 곧바로 미수신으로 판정하지 않습니다. 둘 다 구매나 메시지 열람 완료와 같은 뜻은 아닙니다. Confirmed receipt[20].

실패율·지연·관찰 기간은 앱과 캠페인별로 시험 전에 합의해야 합니다. 단말·앱 버전·채널·동의 상태가 다른 집단을 섞은 평균 하나로 판단하지 않습니다. 이전에 성공한 시험 코호트가 새로 확대하는 집단까지 검증해 주는 것도 아닙니다.

복귀 가능성은 단계마다 다릅니다.

현재 단계가능한 대응되돌릴 수 있다고 가정하면 안 되는 것
원본을 유지한 채 내보내기·매핑·비활성 캠페인을 준비한 단계목표 작업 중단, 잘못된 매핑 수정, 원본 운영 유지잘못된 식별 병합이 이미 다른 데이터에 전파됐다면 단순 파일 재업로드로 해결되지 않음
일부 대상의 발송 책임을 목표로 넘긴 단계원본 경로가 여전히 동작하고 최신 거부·발송 기록이 반영돼 있을 때만 제한적으로 책임 복귀이미 보낸 메시지, 처리 여부 불명인 요청, 사용자가 설치한 앱 버전을 서버 설정만으로 되돌리는 것
기존 SDK·구독 경로를 제거하거나 권한·계약을 종료한 단계새 환경의 발송을 멈추고 수정 배포·재등록 등 앞으로 복구하는 경로 검토해제된 웹 구독, 사라진 원본 접근권, 종료한 계약이 즉시 복원되는 것

복귀 시에도 새 환경에서 발생한 수신 거부와 이미 처리한 캠페인 단계를 잃어서는 안 됩니다. 오래된 원본 상태로 돌아가 ‘아직 안 보낸 고객’으로 재분류하면 복귀 자체가 중복 발송의 원인이 됩니다. 코드·설정·DB의 복귀 조건은 롤백 가능한 배포 가이드와 함께 검토합니다.

이전 완료는 남은 대상까지 설명할 수 있을 때입니다

앱 하나, 안정적인 고객 ID, 적은 수의 캠페인을 운영하고 개발·CRM 담당자가 함께 검수할 수 있다면 별도 마이그레이션 제품부터 도입할 필요는 없습니다. 필요한 내보내기, 명시적인 매핑, 발송 차단과 소규모 검수만으로 절차를 구성할 수 있는지 먼저 살펴봅니다.

반대로 여러 앱·계정이 섞여 있거나, 공유 기기의 식별 문제가 있거나, 긴 대기 여정과 여러 채널을 동시에 넘겨야 한다면 데이터 담당·앱 개발·CRM 운영·권한 관리자의 공동 작업이 필요합니다. 파일 변환 작업만 맡기고 캠페인 책임자를 비워 두어서는 안 됩니다.

마지막에 남는 구버전 사용자, 웹 미방문자, 동의 미확인 대상을 숨기지 않는 것이 중요합니다. 원본에서 계속 맡을지, 명시적으로 보류할지, 이전 범위에서 제외할지를 결정하고 책임자를 남깁니다. ‘모두 가져왔다’보다 ‘누구에게 무엇을 보낼 수 있고, 누가 책임지며, 아직 못 옮긴 대상은 어떻게 처리할지 설명할 수 있다’가 완료 여부를 판단하는 데 더 유용합니다.

기존 메시징 환경에서 OneSignal로 옮기면서 이전 범위와 유지할 캠페인을 외부와 함께 점검해야 한다면, IXC의 CRM 마이그레이션·전환 지원 범위를 확인할 수 있습니다.