Mode 01 ~45% 전체 사례 중
모델 붕괴
진실의 원천이 Confluence 페이지 하나입니다. 오픈 첫날부터 아이덴티티 규칙이 어긋납니다. 가장 흔합니다.
Path B · Data 360 신규 구축
Data 360은 초기의 결정을 용서하지 않습니다. 구매 부서가 서명하기 전에 아키텍처를 잡습니다.
Salesforce 클라우드 셋, 같은 고객의 버전 셋, 그리고 데이터 모델을 문서로 정리하기 전까지 계속 오르는 라이선스 청구서. 이 작업은 코드 한 줄을 넘기기 전에 Data Graph, 아이덴티티 규칙, 활성화 계획을 설계합니다. 3주, 구축 준비 완료.
3,400만 원~
비용
3주
기간
아키텍트 1명
팀
24시간 이내
회신 기준
왜 멈추는가
멈춰 있는 프로젝트는 대개 다음 네 가지 유형 중 하나입니다.
이 진단이 작동하는 운영 이론입니다. 빈도순으로 정리한 네 가지 실패 유형이며, 늦어도 2주차 금요일이면 어느 쪽인지 알게 됩니다.
Mode 02 ~25% 전체 사례 중
라이선스 팽창
아무도 실제로 쓰지 않는 수집 레코드를 기준으로 Data Cloud 규모를 잡았습니다. 청구서가 조직의 잠을 빼앗습니다.
Mode 03 ~20% 전체 사례 중
활성화 막힘
세그먼트는 깔끔하게 만들어지는데, 매출을 일으키는 채널까지 끝내 닿지 못합니다.
Mode 04 ~10% 전체 사례 중
거버넌스 부채
동의·공유 결정이 "2단계"로 미뤄진 채 끝내 내려지지 않습니다. GDPR(개인정보 보호 규정) 리스크가 쌓입니다.
이 중 어느 것에도 해당하지 않는다면, 병목은 아키텍처가 아닐 가능성이 큽니다. 계약서에 서명하기 전, 상담 자리에서 솔직하게 말씀드립니다.
받게 되는 것
서면 산출물 네 가지. 모두 고객의 것입니다.
이 진단이 남기는 문서입니다. 계속 보관하기 위해 리테이너를 유지할 필요는 없습니다. 설계상 어떤 종속도 만들지 않습니다.
- D1
표준 데이터 모델
엔티티, 속성, 소유 관계. 앞으로 3년간 조직 전체가 참조할 사전입니다.
- D2
아이덴티티 규칙
결정적·확률적 해소 규칙. 데모 조직이 아니라 실제 소스 추출본으로 검증합니다.
- D3
구매 준비 범위
규모를 잡은 Data Cloud 라이선스 형태. 수집하는 각 레코드마다 근거를 답니다. 벤더의 열의가 아니라 모델에 맞춰 산정합니다.
- D4
실행 가능한 아키텍처 문서
역량 있는 연동 엔지니어가 전체를 다시 설계하지 않고도 구현할 수 있는 25~40페이지 문서.
진행 일정
단계마다 바로 내놓을 수 있는 산출물이 있습니다.
일정은 고정입니다. 발견 단계에서 더 긴 작업이 필요하다고 판단되면, SoW는 1주차에 수정합니다. 막판에 갑자기가 아니라요.
- 1주차 소스 점검
모든 시스템, 모든 담당자, 모든 계약. 수집 우선순위는 벤더의 열의가 아니라 ROI로 정렬합니다.
→ 소스 인벤토리와 ROI 순위 - 2주차 모델 설계
표준 스키마. Identity Resolution 규칙. 세그먼트·활성화 전략.
→ Data Graph와 아이덴티티 규칙 - 3주차 구매 준비
규모를 잡은 라이선스 범위. 벤더 질문 목록. 구축 대 설정 판단.
→ 실행 가능한 아키텍처 문서 - 4주차~ 구축 감리
선택 사항. 구축 단계의 아키텍처 책임. 고객 팀 또는 SI와 함께.
→ 요청 시 SoW 작성
방법론
작업이 이런 형태를 띠는 이유.
독립적
되팔 라이선스도, 먹여 살릴 구축 조직도 없습니다. 그래서 ‘중단하십시오’도 유효한 권고가 됩니다.
아키텍처 우선
프롬프트는 누구나 손볼 수 있습니다. 데이터 접근 모델은 직접 구축해 본 사람만 바로잡을 수 있습니다. 전혀 다른 문제입니다.
발표가 아니라 서면
CTO가 직접 주석을 달고 이사회에 가져갈 수 있는 리포트는 다음 팀 개편에도 살아남습니다. 슬라이드 덱은 그렇지 못합니다.
고객의 평가
“그의 통찰은 언제나 정확합니다. 누구보다 먼저 아키텍처 문제를 짚어내고, Salesforce를 모르는 CTO도 바로 실행에 옮길 수 있는 언어로 권고를 정리해 줍니다.”
Juno Noh · 시니어 IT 매니저, L'Occitane Korea
고객 사례 전체 보기 → 적합한 경우 · 아닌 경우
솔직한 적합성 판단.
이 진단이 설계된 대상의 짧은 목록과, 그렇지 않은 대상의 더 짧은 목록입니다.
적합한 경우
- Salesforce 클라우드를 셋 이상 운영하는데 고객이 조각나 있습니다.
- Agentforce를 준비하고 있어, 데이터 기반부터 먼저 세워야 합니다.
- 구매 부서가 아직 방어하지 못할 Data Cloud 견적에 서명하려 합니다.
- Marketing Cloud 사일로를 물려받아 Sales·Service와 잇고 싶습니다.
적합하지 않은 경우
- 단일 클라우드만 운영하며 멀티 소스 수집이 필요 없습니다.
- 라이선스 점검만 원합니다. 그것은 Salesforce 영업 담당자가 무료로 해 줍니다.
- 파이프라인 운영·유지보수를 원합니다. 다른 종류의 일입니다.
- Salesforce가 다음 분기에 무엇을 내놓을지 두고 보자는 쪽으로 결정이 났습니다.
SI 감사와의 차이
Big Four 프로젝트와 무엇이 다른가.
독립 아키텍트
Big Four 감사
3,400만 원 · 3주
1.4억+ · 12~16주
라이선스 재판매와 무관
Salesforce 리셀러 마진에 묶임
실행 가능한 아키텍처 문서
옵션이 딸린 슬라이드
고객 데이터로 검증한 아이덴티티 규칙
데모 조직으로 검증한 아이덴티티 규칙
근거를 붙여 규모를 잡은 라이선스 범위
과대 산정 자체가 수익 모델
3주 안에 의사결정
3개월에 걸친 의사결정
자주 묻는 질문
구매 부서에서 자주 나오는 질문.
여기에 없는 질문이라면 상담 때 물어봐 주십시오. 정확히 답해 드립니다.
Q01 Data 360은 구체적으로 무엇을 해결합니까?
Data 360은 Salesforce 클라우드와 외부 소스에 흩어진 고객 데이터를 단일 프로필로 통합한 뒤, Identity Resolution, 실시간 세그먼트, 활성화를 구동합니다. 이것이 없으면 클라우드마다 같은 고객의 서로 다른 버전을 두고, 어느 쪽도 완전하지 않습니다.
Q02 라이선스 점검에 그치는 작업입니까?
아닙니다. 라이선스 규모 산정은 작업 막바지의 한 장짜리 부록입니다. 산출물은 구축 팀이 실행할 수 있는 아키텍처 문서입니다.
Q03 구매 부서가 Data Cloud SKU에 서명하기 전에 진행할 수 있습니까?
가능합니다. 가장 흔한 시점입니다. SKU의 형태를 아키텍처가 정합니다. 그 반대가 아닙니다. 데이터 모델이 실제 수집 대상을 정직하게 반영하고 나면, 대부분의 고객이 최초 라이선스 견적에서 20~40%를 절감합니다.
Q04 Data 360을 구매하지 않는 게 맞다는 결론이 나오면 어떻게 합니까?
그렇다면 리포트가 그렇게 말합니다. 다섯 건 중 한 건쯤은 "두 분기는 MuleSoft에 더 머무르십시오. 그것을 버틸 수 있게 하는 아키텍처는 이렇습니다"로 끝납니다. 그 답이 산출물입니다.
Q05 MuleSoft 기반 연동과는 무엇이 다릅니까?
MuleSoft는 API로 시스템 간 데이터를 옮깁니다. Data 360은 아이덴티티를 통합하고 Salesforce 안에서 세그먼트를 네이티브로 활성화합니다. 둘은 서로 다른 문제를 풉니다. 이 작업은 지금 상황에 실제로 필요한 쪽을 짚어 줍니다.
Q06 수집 파이프라인을 직접 작성합니까?
이 작업은 파이프라인을 명세합니다. 구축은 명세를 기준으로 고객 팀이나 SI가 진행합니다. 아키텍처 문서가 충분히 정밀해, 역량 있는 연동 엔지니어라면 전체를 다시 설계하지 않고도 실행할 수 있습니다.
Q07 어디에 근거지를 두고 있습니까?
파리와 서울입니다. 작업은 원격으로 진행하며, 팀이 EMEA에 있는 경우 1주차에 이틀간 현장 방문을 합니다.
Q08 어떤 언어로 일합니까?
영어와 프랑스어로 문서를 작성하고 말합니다. 한국어로는 일상 대화가 가능합니다.
떠나기 전에
AI 준비도 진단 시작하기 → 귀사의 Salesforce 조직은 AI에 얼마나 준비되어 있습니까?
9개 문항, 2분, 즉시 결과 확인. 가입 불필요.