Salesforce COE 운영 모델을 도입한 조직 중 상당수는 조직도만 그려 놓고 실제 의사결정 구조는 손대지 않습니다. COE(Center of Excellence)라는 이름의 팀이 생기고 역할과 책임(RACI)이 문서화되지만, 릴리스 우선순위는 여전히 가장 목소리 큰 사업부가 정하고, 아키텍처 결정은 SI 파트너의 제안서를 그대로 승인하는 방식으로 이루어집니다. 이런 상태에서는 COE가 존재해도 거버넌스 공백은 그대로 남습니다.
문제는 이름이 아니라 운영 체계입니다. Salesforce COE 운영 모델이 실제로 작동하려면 조직도가 아니라 의사결정 흐름, 릴리스 케이던스, 역량 배분 규칙이 하나로 맞물려야 합니다. 이 글에서는 COE가 형식적 기구로 전락하는 구조적 원인과, 그것을 다시 작동시키는 재설계 원칙을 다룹니다.
Salesforce COE가 조직도에만 머무는 이유
가장 흔한 패턴은 COE를 승인 기구로만 설계하는 것입니다. 아키텍처 리뷰 보드가 분기에 한 번 소집되고, 그 사이에는 각 사업부와 SI 파트너가 독립적으로 변경을 진행합니다. 승인은 사후 추인에 가까워지고, 이미 배포된 커스터마이징을 되돌릴 방법은 없습니다.
컨설턴트 200명, 사업부 15개 규모의 조직에서 관찰되는 패턴은 명확합니다. 거버넌스 보드가 분기별로만 소집되는 구조에서는 우선순위 결정까지 평균 6주에서 8주가 걸리고, 그 지연을 견디지 못한 사업부는 별도 예산으로 로컬 SI를 고용해 우회 개발을 진행합니다. 결과적으로 같은 오브젝트에 대해 서로 다른 자동화 로직이 세 벌씩 쌓이고, COE는 존재하지만 실제 변경의 70% 이상은 COE 밖에서 일어납니다.
두 번째 원인은 COE에 실행 권한이 없다는 것입니다. 표준을 정의할 권한은 있지만 릴리스를 막을 권한은 없는 구조가 많습니다. 이 경우 COE는 문서를 만드는 조직이 되고, 실제 배포 파이프라인은 CI/CD 도구와 SI 파트너의 릴리스 캘린더가 좌우합니다. 표준과 실행이 분리되면 표준은 곧 무력화됩니다.
세 번째는 역량 배분 문제입니다. COE 구성원 대부분이 특정 사업부 소속을 겸직하고 있으면, 그 사업부의 요구가 COE 전체 우선순위를 사실상 결정합니다. COE가 중립적 판단 기구로 기능하려면 최소한 핵심 의사결정 인력은 특정 사업부 KPI에서 분리되어야 하는데, 이 구조를 갖춘 조직은 생각보다 적습니다.
운영 모델 재설계의 세 가지 축
Salesforce COE 운영 모델을 다시 설계할 때는 조직도를 손보는 것이 아니라 세 가지 축을 동시에 재구성해야 합니다. 거버넌스 의사결정, 릴리스 오케스트레이션, 역량 배분입니다. 이 세 축이 따로 움직이면 COE는 다시 형식적 기구로 되돌아갑니다.
거버넌스 의사결정 축은 승인 빈도와 승인 범위를 먼저 재정의합니다. 분기 단위 리뷰 보드는 전략적 아키텍처 결정에만 남기고, 일상적인 Flow 변경이나 Prompt Builder 템플릿 수정처럼 빈도 높은 변경에는 경량 승인 트랙을 별도로 둡니다. 이렇게 이원화하면 COE가 병목이 아니라 흐름을 관리하는 조직으로 바뀝니다.
릴리스 오케스트레이션 축은 사업부별로 흩어진 배포 주기를 하나의 릴리스 트레인으로 통합하는 작업입니다. Data Cloud의 Data Streams 변경, Agentforce의 Topics와 Actions 수정, 기존 Flow 자동화 변경이 서로 다른 팀에서 조율 없이 배포되면 충돌은 필연입니다. 릴리스 트레인을 도입하면 변경 유형별로 정해진 창구와 검증 절차를 거치게 되고, Agentforce Testing Center 같은 검증 단계를 릴리스 게이트에 강제로 편입시킬 수 있습니다. 이 부분은 Agentforce 프로덕션 준비 체크리스트에서 다룬 릴리스 게이트 설계와 맞물립니다.
역량 배분 축은 COE 인력의 소속과 평가 기준을 분리하는 작업입니다. COE 핵심 인력은 사업부 KPI가 아니라 플랫폼 안정성과 표준 준수율로 평가받아야 하고, 사업부 파견 인력은 순환 배치를 통해 특정 부서의 이해관계에 고착되지 않도록 관리해야 합니다.
세 축을 도식으로 정리하면 다음과 같습니다.
[거버넌스 보드] --우선순위 결정--> [릴리스 트레인] --배포 승인--> [프로덕션]
| |
경량 승인 트랙 Testing Center 게이트
| |
[사업부 요구사항] <----------- [역량 풀: COE 겸직/전담 구분]이 구조에서 핵심은 화살표 방향입니다. 사업부 요구가 거버넌스 보드로 직접 올라가고, 보드의 결정이 릴리스 트레인을 통해서만 프로덕션에 도달합니다. 사업부가 릴리스 트레인을 우회할 수 있는 경로가 하나라도 남아 있으면 전체 모델은 무의미해집니다.
거버넌스 보드와 릴리스 트레인을 연결하는 방법
거버넌스 보드가 내린 결정이 실제 배포로 이어지지 않는 경우가 많습니다. 원인은 보드와 릴리스 파이프라인 사이에 번역 계층이 없기 때문입니다. 보드는 “이 변경을 승인한다”고 말하지만, 그것이 어떤 스프린트에 편입되고 어떤 검증 절차를 거치는지는 각 팀의 재량에 맡겨집니다.
이 문제는 릴리스 트레인에 승인 메타데이터를 강제로 태깅하는 방식으로 해결합니다. 모든 변경 요청은 거버넌스 승인 ID를 갖고 있어야 릴리스 파이프라인에 진입할 수 있도록 하고, 승인 ID가 없는 변경은 자동으로 반려되는 규칙을 CI/CD 단계에 심습니다. 이렇게 하면 승인과 배포가 물리적으로 분리될 수 없는 구조가 됩니다.
Identity Resolution 룰셋 변경이나 Data Graphs 재정의처럼 여러 사업부에 걸쳐 영향을 미치는 변경은 별도의 영향도 분석 단계를 거치게 하는 것이 좋습니다. 이런 변경은 Data Cloud 아키텍처 자체와 직결되므로, 조직 내 데이터 모델 표준을 관리하는 COE 하위 워킹그룹이 사전 검토를 맡는 구조가 필요합니다. 이 부분은 Data Cloud Identity Resolution이 중복을 처리하는 방식에서 다룬 매칭 로직 설계와도 직접 연결됩니다.
대부분의 COE가 반복하는 실패 패턴
COE 재설계 프로젝트에서 반복적으로 나타나는 실패 패턴이 몇 가지 있습니다.
첫째, 표준 문서만 만들고 강제 메커니즘을 만들지 않는 경우입니다. 아키텍처 표준 문서가 아무리 정교해도 CI/CD 파이프라인에 강제 검증 규칙으로 내장되지 않으면 준수율은 시간이 지날수록 떨어집니다. 문서는 참고 자료일 뿐, 실행을 강제하는 것은 파이프라인입니다.
둘째, COE를 만들면서 기존 SI 종속 구조를 그대로 둔 경우입니다. COE가 표준을 정해도 실제 구현은 여전히 외부 SI 파트너가 담당하고, 그 SI가 COE 표준을 따를 유인이 없으면 표준은 계약서상의 문구로만 남습니다. 이 구조적 문제는 SI 종속과 거버넌스 공백에서 다룬 패턴과 정확히 일치합니다. COE 운영 모델을 설계할 때는 SI 계약 조건에 표준 준수와 검증 통과를 명시적 대금 지급 조건으로 넣어야 실효성이 생깁니다.
셋째, COE 출범 초기에 모든 변경을 중앙집중화하려다 실패하는 경우입니다. 규모가 큰 조직일수록 모든 변경을 COE가 직접 승인하는 방식은 처리 속도를 오히려 떨어뜨립니다. 위험도 기반으로 변경을 분류하고, 낮은 위험군은 사업부 자율 승인에 맡기되 사후 감사 대상으로 편입하는 방식이 현실적입니다. COE가 모든 것을 통제하려는 순간, 다시 병목이 되고 우회 경로가 생깁니다.
넷째, Agentforce 도입 이후 새로운 거버넌스 범주가 생겼는데 기존 COE 구조에 편입하지 않은 경우입니다. Topics와 Actions 설계, Atlas Reasoning Engine의 프롬프트 변경은 기존 Flow 거버넌스와는 다른 리스크 프로파일을 가집니다. 에이전트가 잘못된 Action을 호출하면 데이터 오염이나 잘못된 고객 응대로 이어질 수 있으므로, COE 안에 AI 거버넌스 전담 트랙을 별도로 두는 것이 필요합니다. 이 부분에 대한 아키텍처적 접근은 Agentforce 도입 아키텍처 페이지에서 다루는 범위와 겹칩니다.
핵심 정리
- Salesforce COE 운영 모델이 실패하는 핵심 원인은 조직도 부재가 아니라 거버넌스, 릴리스, 역량 배분이 서로 분리되어 있다는 점입니다.
- 거버넌스 보드가 분기별로만 소집되는 구조에서는 우선순위 결정까지 평균 6~8주가 걸리며, 이 지연이 우회 개발을 유발합니다.
- 릴리스 트레인에 거버넌스 승인 메타데이터를 강제로 태깅하면 승인과 배포가 분리될 수 없는 구조를 만들 수 있습니다.
- COE에 실행 권한이 없으면 표준은 문서로만 남으므로, CI/CD 파이프라인에 검증 규칙을 강제로 내장하는 것이 필수입니다.
- Agentforce 도입 이후에는 Topics·Actions·프롬프트 변경을 위한 별도 AI 거버넌스 트랙을 COE 안에 신설해야 합니다.
Salesforce COE 운영 모델을 재설계하는 작업은 조직도를 다시 그리는 일이 아니라, 의사결정과 실행 사이의 물리적 강제력을 만드는 일입니다. 지금 COE가 승인만 하고 배포를 통제하지 못하는 구조라면, 다음 분기 릴리스 계획을 세우기 전에 승인 메타데이터를 파이프라인에 강제로 편입하는 작업부터 시작하는 것이 현실적인 첫걸음입니다.
