통제 기구로 설계한 Salesforce Center of Excellence(CoE)는 사업부가 피해 다니는 대기열이 됩니다. CoE가 자리를 잡으려면 우회하는 것보다 CoE를 거치는 편이 빨라야 합니다. 그 조건은 접수 양식이 불어나기 전에 내리는 두 가지 결정에 달려 있습니다. CoE가 무엇을 검토하는지, 그리고 프로젝트 팀에 무엇을 돌려주는지입니다.
CoE가 대기열이 되는 과정
흔한 실패 방식은 익숙합니다. 거버넌스를 중앙에 모으고, 접수 양식을 만들고, 리뷰 보드를 세우고, 표준을 발표한 뒤, 팀이 그 표준을 쓸 수 있는지는 한 번도 측정하지 않습니다. 보드는 분기에 한 번 모여 이미 배포된 변경을 추인하고, 딜리버리는 보드를 비켜 갑니다.
이런 결과를 낳는 설계 오류는 세 가지입니다. 첫째, CoE가 좋은 결정을 앞당기기보다 나쁜 결정을 막는 데 맞춰져 있어, 압박을 받는 팀일수록 피할 이유가 생깁니다. 둘째, 표준을 발표할 권한은 있지만 릴리스를 멈출 권한은 없어, 실제 규칙은 파이프라인과 SI의 릴리스 일정이 정합니다. 셋째, 핵심 구성원이 특정 사업부 목표에 묶여 있어, 그 사업부의 요구가 CoE 우선순위를 사실상 결정합니다. CoE가 중립을 지키려면 핵심 결정을 내리는 사람을 한 사업부의 KPI가 아니라 플랫폼 안정성과 표준 준수로 평가해야 합니다.
세 개의 층, 그리고 대부분이 먼저 만드는 층
| 층 | 담당 | 산출물 |
|---|---|---|
| 플랫폼 | 릴리스 관리, 환경 전략, 보안 기준선, 데이터 표준, 기술 부채 대장 | 제약 조건(작은 시니어 조직, 거절 권한 보유) |
| 딜리버리 | 솔루션 설계 패턴, Flow와 에이전트 거버넌스, 연동 계약 | 프로젝트 팀을 빠르게 만드는 재사용 자산과 참조 설계 |
| 수요 | 요청 접수, 우선순위, 비즈니스 케이스, 가용 인력, 벤더 관리, 프로젝트 충돌 시 에스컬레이션 | 먼저 처리할 작업 결정 |
가장 흔한 실수는 경영진 눈에 가장 잘 보인다는 이유로 수요 층부터 만드는 일입니다. 결과는 역량 없는 절차입니다. 사업부는 접수 절차의 마찰만 겪고 재사용할 패턴은 하나도 받지 못하니, CoE를 우회하는 편이 위험을 감수할 만하다고 판단합니다. CoE의 노력은 대부분 딜리버리 층에 들어가야 합니다.
org 규모에 맞는 모델
- Sales Cloud와 Service Cloud org 하나, 내부 관리자 팀 하나. CoE는 과합니다. 결정 기록, 릴리스 캘린더, 주요 변경을 검토하는 설계 책임자 한 명이면 충분합니다.
- 여러 클라우드, 여러 사업부, 내부와 외부가 섞인 딜리버리. 연합형 모델이 맞습니다. 중앙 플랫폼 팀이 표준을 정하고 org 기준선을 관리하며, 사업부마다 사업부와 중앙 팀 양쪽에 책임을 지는 Salesforce 담당자를 둡니다. 팀 규모와 검토 주기는 실제 변경량과 위험에 맞춥니다.
- 많은 클라우드, 많은 팀이나 벤더. 서비스 수준, 강제할 수 있는 결정 권한, 예산 계획에 반영되는 기술 부채 대장을 갖춘 공식 운영 모델이 필요합니다. 대장을 관리하는 방법은 기술 부채 노트에서 다룹니다.
완전 중앙집중형은 병목을 만들고, 완전 분산형은 무분별한 확장과 일관성 없는 데이터를 낳습니다. 기본값으로 정하지 말고 결정 지연, 공유 플랫폼 위험, 현장 책임을 기준으로 고릅니다.
리뷰 보드가 검토하는 대상
2019년부터 2021년까지 TotalEnergies의 Salesforce Center of Excellence를 이끌었습니다. 당시 TotalEnergies는 Cognizant의 고객이었고, 연간 약 100만 유로 규모의 계정이었습니다. Salesforce는 그룹 안 여러 부문에서 쓰였고 다른 시스템과 데이터를 주고받았기 때문에, 모든 변경을 릴리스 전에 그 데이터 흐름과 대조해 확인해야 했습니다. 이런 위치의 CoE는 모든 변경을 같은 깊이로 검토할 수 없습니다. 검토 범위를 명시적으로 정하지 않으면 대기열이 대신 정합니다.
모든 변경을 검토하는 보드는 어느 변경도 제대로 검토하지 못합니다. 검토 대상은 네 가지이고, 그 밖에는 없습니다.
- 데이터 모델 변경: 둘 이상의 클라우드에 영향을 주거나 공유 오브젝트 사이에 새 관계를 추가하는 변경입니다.
- 연동 계약: 외부 의존성을 새로 만들거나 기존 API 계약을 바꾸는 변경입니다.
- 에이전트와 AI 설정: 새 토픽, 액션, 프롬프트 템플릿을 프로덕션에 올리는 변경입니다.
- 보안·공유 변경: Org-wide defaults, 대규모 프로파일 할당, 데이터 보관 위치를 바꾸는 변경입니다. 서류상으로는 되돌릴 수 있지만 실제로는 거의 되돌리지 못합니다.
나머지는 표준 릴리스 관리를 따릅니다. 자주 일어나는 저위험 변경은 사업부가 맡는 경량 승인 트랙으로 보내고 사후에 감사합니다. 보드의 결정을 실제로 지키게 하는 규칙은 두 가지입니다. 승인 번호가 없는 변경은 릴리스 파이프라인에 들어가지 못하게 해서 승인과 배포가 따로 놀지 않게 합니다. 그리고 SI가 구축을 맡는 경우 CoE 표준과 관문 통과를 계약의 검수 조건에 넣습니다. 그렇지 않으면 표준은 슬라이드 속 문구로 남습니다.
CoE 예산을 지키는 자산과 지표
CoE는 승인보다 자산 라이브러리로 예산을 정당화합니다. 최소한의 라이브러리에는 흔한 사례용 승인 Flow 패턴(케이스 에스컬레이션, 리드 라우팅, 승인 체인), org가 자주 연결하는 외부 시스템용 연동 패턴, 승인된 프롬프트 템플릿, 클라우드별 체크리스트가 들어갑니다. 자산을 넣을지 판단하는 기준은 실용적입니다. 이해하고 고쳐 쓰는 데 다시 만드는 쪽보다 오래 걸리면 아무도 쓰지 않습니다.
더 어려운 쪽은 유지보수입니다. Salesforce 릴리스가 플랫폼을 바꿨는데 갱신되지 않은 자산은 팀을 잘못된 방향으로 이끌기 시작합니다. 자산 유형마다 릴리스 때마다 검토하고 지원 종료 예정 항목을 알리는 담당자를 지정해야 합니다.
티켓 수와 검토 소요 시간은 절차를 설명할 뿐 가치를 보여 주지 않습니다. CoE가 비용만큼 가치가 있는지는 분기마다 경영진 스폰서와 함께 보는 세 가지 비교로 드러납니다. 처음부터 새로 만들지 않고 CoE 자산을 쓴 프로젝트의 비율, 검토를 거친 프로젝트와 검토를 건너뛴 프로젝트의 결함률, CoE 안과 밖의 프로덕션 반영 소요 기간입니다. CoE 프로젝트가 더 느리다면 거버넌스 부담이 효과보다 크다는 뜻이고, 모델을 바꿔야 합니다.
확인할 항목
- 팀 리더가 문서를 열지 않고 org의 양보할 수 없는 규칙을 말할 수 있습니까?
- CoE가 릴리스를 멈출 수 있습니까, 아니면 표준을 발표하기만 합니까?
- 리뷰 보드의 검토 범위가 문서로 정해져 있고, 한 사업부 안에서 끝나는 변경은 빠져 있습니까?
- 모든 자산에 릴리스마다 검토하는 담당자가 지정되어 있습니까?
- 스폰서가 분기마다 재사용, 결함, 소요 기간 비교를 보고받습니까?