3,000개 이상 리테일 접점의 통합 거버넌스

상황

L’Occitane은 90개 이상 국가에 3,000개가 넘는 매장을 둔 럭셔리 리테일 네트워크를 운영하며, 그 뒤에는 세 개의 Salesforce 클라우드가 연결돼 있습니다. Sales Cloud는 도매 계정을, Service Cloud는 지역 전반의 지원을, Marketing Cloud는 멤버십과 CRM을 맡았습니다. 각 클라우드는 10년에 걸친 인수, 지역별 구축, 그리고 그 시점에는 현지 기준으로 옳았던 플랫폼 결정을 거치며 저마다의 형태로 자라났습니다.

눈에 보이는 결과는 동일 인물에 대한 세 개의 아이덴티티였습니다. 파리 매장에서 구매하고, 도쿄에서 온라인 주문을 넣고, 뉴욕에서 지원을 요청한 고객은 서로 다른 ID와 부분적인 이력, 공유되지 않는 맥락을 가진 세 개의 분리된 레코드로 존재했습니다. 마케팅 캠페인은 가용 고객 데이터의 30~40% 위에서 만들어졌습니다. 매장 직원은 온라인 구매 이력을 볼 수 없었습니다. 서비스 상담원은 고객의 제품 포트폴리오를 모른 채 케이스를 처리했습니다.

12개 APAC 시장에서는 그림이 더 빡빡하고 더 고통스러웠습니다. 지역 Salesforce 구현은 글로벌 아키텍처에서 분기했습니다. 각 시장은 자체 통합 패턴, 필드 커스터마이징, 데이터 모델을 발전시켰습니다. 그 결과는 기술적으로는 연결됐지만 운영상으로는 분절된 멀티클라우드 환경이었습니다.

과제

클라우드끼리는 서로 대화했습니다. 정작 고객 레코드는 그렇지 않았습니다. Sales Cloud는 계정 ID를, Service Cloud는 케이스 컨택을, Marketing Cloud는 이메일을 키로 삼았습니다. 그 사이에 체계적인 Identity Resolution이 자리 잡지 않아서, 어떤 “단일 뷰”든 리포트마다 손으로 다시 조립해야 했습니다.

통합은 야간 배치이자 점대점 방식이었습니다. Marketing Cloud는 밤사이 Sales Cloud에서 동기화했습니다. Service Cloud는 커스텀 REST API로 케이스를 Sales Cloud에 밀어 넣었습니다. 커머스는 Salesforce 환경 바깥에 완전히 따로 있었습니다. 지연은 24~48시간에 달했고, 모든 의존성이 향후 장애가 시작될 수 있는 지점이었으며, 어떤 표면도 고객이 그날 아침에 한 행동에 대해 활성화할 수 없었습니다.

데이터 모델은 그 위에 수년간의 불일치를 떠안고 있었습니다. 필드 명명 규칙이 클라우드마다 달랐습니다. “고객”이 세 가지 방식으로 모델링됐습니다. 표준 데이터 사전도, 엔티티별 소유자도, 변경 관리 프로세스도 없었습니다. 이미 경영진 로드맵에 올라 있던 Agentforce 프로그램에게 그 기반은 충분하지 않았습니다. 지능형 에이전트는 완전하고, 최신이며, 통합된 고객 뷰가 필요합니다. 24시간 배치 윈도로 분리된 파편 위에서는 추론할 수 없습니다.

3주 차에 운영 위원회에 전한 말

에이전트는 결국 안착합니다. 어려운 문제는 에이전트가 아닙니다. 그 에이전트가 작동해야 할 고객 레코드가 아직 존재하지 않는다는 점입니다.

실행

아키텍처 결정은 클라우드 사이에 또 하나의 통합을 짓는 대신, Salesforce Data Cloud를 전체 네트워크의 고객 데이터 레이어로 자리 잡게 하는 것이었습니다. Data Cloud는 Sales, Service, Marketing과 이커머스 플랫폼에서 데이터를 인제스트하고, 아이덴티티를 해소하며, 표준 모델을 담고, 단일 공급원에서 각 표면으로 되활성화해야 했습니다.

데이터 기반이 자리 잡자, 활성화는 세 개 표면에서 다시 구축됐습니다. Marketing Cloud는 실시간 세그멘테이션을 위해 Data Cloud에 다시 연결됐고, 세그먼트는 24시간 지난 컨택 리스트에서 살아 있는 통합 프로필로 옮겨갔습니다. Experience Cloud는 매장 직원용 새 모바일 앱을 구동해, 판매 시점에 Customer 360 뷰를 띄웠습니다. Service Cloud는 Data Cloud 컨텍스트 카드를 받아, 구매 이력과 제품 보유 현황을 케이스 관리 화면에 바로 표시했습니다.

거버넌스 레이어가 이 전체를 시장 전반에 걸쳐 유지시킨 요소였습니다. 표준 데이터 사전이 공유 엔티티마다 정의를 내리고, 소유자를 지정하고, 변경 관리 규칙을 세웠습니다. 품질 대시보드가 클라우드별 완전성, 정확성, 최신성을 측정했습니다. 12개 APAC 시장을 위해서는, 정렬 프로세스가 지역 커스터마이징을 글로벌 모델에 맞췄고, 지역 데이터 스튜어드를 지정했으며, 이탈 모니터링을 설치해 분기가 다음 마이그레이션이 아니라 며칠 안에 드러나게 했습니다.

성과

이제 네트워크는 매장과 디지털을 합쳐 3,000개 이상 접점에 걸쳐 하나의 고객 레코드 위에서 운영됩니다. Identity Resolution은 중복을 85% 줄였고, 모든 활성화가 의지하는 단일 고객 그래프를 만들어냈습니다.

마케팅이 먼저 체감했습니다. 2.5배 더 완전한 데이터와 거의 실시간 세그멘테이션 덕분에, 타깃 캠페인은 첫 두 분기에 전환율을 40% 끌어올렸습니다. 세그먼트 구축 시간은 몇 시간에서 몇 분으로 줄었고, 팀은 주간 배치 발송을 멈추고 일 단위 발송으로 전환했습니다.

매장 직원은 Customer 360 앱을 빠르게 받아들였습니다. 완전한 고객 이력을 손에 쥔 직원은 적절한 추천을 통해 추가 매출을 15% 더 올립니다. 서비스 케이스 해결 시간은 25% 줄었습니다. 상담원이 이제 케이스 화면에 바로 있는 맥락을 찾으려고 에스컬레이션하는 일을 멈췄기 때문입니다.

이 기반에 의존하던 Agentforce 프로그램은 일정대로 도착했습니다. 파일럿 3건이 통합 프로필 위에서, 완전한 이력과 실시간 활성화, 그리고 네트워크 나머지가 운영하는 것과 동일한 거버넌스를 갖추고 시작됐습니다. 고객 레코드는 Agentforce가 늘 드러내는 제약이며, L’Occitane은 에이전트가 가동되기 전에, 그 이후가 아니라, 그 제약을 넘었습니다.

돌아보며

이 패턴은 세 개 이상의 클라우드가 고객 엔티티를 공유할 때, 활성화 지연이 중요할 때, 그리고 다음 레이어가 출시되기 전에 기반이 먼저 안착해야 한다는 점을 경영진이 받아들일 때 통합니다. Agentforce나 Customer 360 프로그램이 이미 로드맵에 있다면 옳은 선택입니다. 어느 쪽이든 데이터 레이어가 결국 구속 제약이기 때문입니다.

조직에 클라우드 하나와 시장 하나만 운영 중일 때는 효과가 덜합니다. 표준 모델은 여전히 도움이 되지만, 그 규모에서는 두 번째 시장이나 두 번째 클라우드가 임박하기 전까지 Data Cloud의 비용을 그 편익에 견줘 정당화하기가 더 어렵습니다.

더 일찍 해두면 좋은 것은 거버넌스 레이어입니다. 시장은 지역 출시 후 첫 18개월 안에 가장 빠르게 분기합니다. 3개월 차의 표준 사전, 지정된 소유자, 품질 모니터링이 30개월 차의 정렬 프로젝트를 덜어줍니다.