Center of Excellence: 15개 사업부, 하나의 아키텍처

상황

TotalEnergies는 지난 5년에 걸쳐 여러 사업부에서 Salesforce를 도입해 왔습니다. 유럽의 B2B 에너지 영업은 Sales Cloud 위에서 돌아갔습니다. 윤활유 사업은 유통사 관리를 위해 별도의 Salesforce org를 사용했습니다. 재생에너지는 자체 구현을 구축했습니다. 코퍼레이트 서비스는 또 다른 하나를 운영했습니다. 각 사업부는 별도 계약, 별도 관리자, 별도 아키텍처 결정으로 자사의 Salesforce 구현을 독립적으로 도입하고, 구축하고, 유지했습니다.

그 결과는 뚜렷이 다른 네 개 org, 충돌하는 데이터 모델, 팀 간 지식 공유 전무, 그리고 Salesforce 관련 지표를 그룹 차원에서 리포팅할 능력이 전혀 없는 Salesforce 자산이었습니다. “TotalEnergies는 전 세계에 Salesforce 사용자가 몇 명입니까?”라는 단순한 질문조차, 네 개 개별 시스템의 데이터를 수작업으로 집계하지 않고는 답할 수 없었습니다.

이 전략적 과제는 계획된 확장으로 더욱 커졌습니다. TotalEnergies는 이후 18개월에 걸쳐 다섯 개 신규 사업부를 Salesforce에 추가하고 있었습니다. 개입이 없으면, 파편화된 아키텍처는 추가될 때마다 함께 확장될 것이었습니다. 더 많은 사일로, 더 많은 기술 부채, 더 많은 거버넌스 공백. 사업부장들은 다른 부서가 무엇을 구축했는지 전혀 알지 못했습니다. 팀들은 같은 아키텍처 문제를 각자 풀고, 같은 통합 작업을 여러 번 청구하고 있었습니다.

경영진은 기존 자산을 거버넌스하고, 가능한 곳을 정리하며, 신규 구현이 공통 표준을 충족하도록 보장하는 거버넌스 프레임워크를 만들기 위해 Salesforce Center of Excellence를 수립하기로 결정했습니다.

과제

기존 네 개 org 전체에 대한 기술 평가가 문제의 규모를 드러냈습니다. 네 개 구현은 400+ 활성 Apex 클래스, 1,200+ 커스텀 필드, 200개 이상의 활성 flow를 org 간 상당한 중복과 함께 쌓아 왔습니다. 두 org는 같은 SI가 구축해 기술 컴포넌트의 60%를 공유했지만, 3년간의 병행 유지보수를 거치며 분기된 별도의 코드베이스를 유지하고 있었습니다.

데이터 거버넌스는 부재했습니다. 강제되는 명명 규칙도, 필드 단위 문서화 표준도, 테스트 커버리지 요건도, 배포 프로세스도 없었습니다. 네 개 중 두 org에서는 설정 변경을 운영 환경에 직접 적용했습니다. 한 org는 18개월간 백업되지 않았습니다.

자산 전반의 800만+ 고객 및 파트너 레코드는 일관성 없이 모델링돼 있었습니다. 윤활유 org에서 “유통사”는 Account였고, 재생에너지 org에서는 커스텀 오브젝트였습니다. 마스터 데이터 관리 전략도, 중복 제거 프로세스도, 어떤 엔터티 유형에 대해서도 단일 진실의 기준이 없었습니다.

향후 Agentforce 및 Data Cloud 배포를 지원하는 데 필요한 데이터 기반, 곧 TotalEnergies의 Salesforce 로드맵에 명시된 우선순위에 비추어 이 아키텍처는 부적합했습니다. 지능형 사업부 간 자동화는 네 개의 파편화된 데이터 모델 위에서 돌아갈 수 없습니다.

진단 결과를 보고하며 CIO에게 한 말

18개월 안에 다섯 개 사업부가 더 들어옵니다. 지금 프레임워크를 구축해 그 안에서 온보딩하든지, 아니면 3년 뒤에도 여전히 이걸 정리하고 있을 것입니다.

실행

Center of Excellence는 세 개 기둥으로 설계했습니다. 거버넌스, 아키텍처 합리화, 역량 강화. 각 기둥은 다섯 개 신규 사업부가 도착하기 전에 자리 잡아야 했고, 그러지 못하면 프레임워크는 통제가 아니라 문서에 그쳤을 것입니다.

자산의 모든 컴포넌트에 대해 아키텍처 문서를 작성했습니다. 데이터 사전, 통합 카탈로그, 기술 부채 레지스터, 그리고 중요한 변경마다 갱신되는 살아 있는 아키텍처 다이어그램. TotalEnergies는 처음으로 자사 Salesforce 자산의 완전한 전경을, 그것을 최신으로 유지할 권한을 가진 기능이 소유한 형태로 갖추게 됐습니다.

성과

TotalEnergies는 15개 사업부를 통합 Salesforce 거버넌스 프레임워크 아래로 모았고, 처음으로 800만+ 레코드를 일관된 데이터 품질 표준 아래 거버넌스했습니다. 파편화되고 독립적으로 유지되던 자산은 관리되고, 문서화되고, 지속적으로 모니터링되는 플랫폼이 됐습니다.

개발 효율이 실질적으로 개선됐습니다. 공유 컴포넌트가 중복을 줄였습니다. 공통 Apex 라이브러리와 공유 Lightning Web Component가 자산 전반에서 약 6만 줄의 중복 코드를 제거했습니다. 들어오는 사업부의 신규 구현 프로젝트는 임시방편 구축에 비해 표준 템플릿 위에서 40% 더 빠르게 배포됐습니다.

아키텍처 합리화는 또한 자산을 다음 계층에 맞게 준비시켰습니다. 표준 데이터 모델, 일관된 거버넌스 프로세스, 깨끗한 마스터 데이터 기반을 갖추면서, TotalEnergies의 Salesforce 환경은 사업부 전반에 걸친 Data Cloud에 맞게 자리 잡았고, 사업부 간 고객 분석, 통합 파트너 데이터, 그리고 엔터프라이즈 규모 AI를 지원할 수 있는 기반 위에서의 Agentforce 배포로 이어집니다.

CoE 모델 자체는 TotalEnergies의 더 넓은 디지털 전환 프로그램 안에서 참조 아키텍처가 됐고, 거버넌스 프레임워크와 역량 강화 접근은 다른 엔터프라이즈 플랫폼에도 적용됐습니다.

돌아보며

이 패턴은 한 조직이 같은 Salesforce 플랫폼에 세 개 이상의 사업부를 두고, 성장이 임박했으며, 다음 온보딩이 출시되기 전에 프레임워크가 자리 잡아야 한다는 점을 경영진이 받아들일 때 작동합니다. AI나 Data Cloud가 로드맵에 있고 데이터 기반이 사업부별이 아니라 그룹 전체 차원이어야 할 때 올바른 선택입니다.

단 하나의 사업부만 운영 중이고 가까운 확장 계획이 없을 때는 잘 작동하지 않습니다. 프레임워크는 여전히 도움이 되지만, 두 번째 사업부가 들어오기 전에는 ARB와 공유 컴포넌트 라이브러리의 부담을 정당화하기 어렵습니다.

더 일찍 했어야 할 것은 표준 Account 모델과 데이터 사전입니다. 둘 다 한두 개 사업부가 운영 중일 때는 적은 비용으로 세울 수 있고, 자산이 커질수록 점점 비싸집니다.

사용 기술: Salesforce Sales Cloud (멀티 org), Salesforce CLI, Git (버전 관리), 관리 패키지, Lightning Web Component, Apex, 커스텀 메타데이터 유형, Salesforce DX 배포 파이프라인