엔터프라이즈 Salesforce org는 완벽하지 않은 코드로도 몇 년을 버팁니다. 멈추는 때는 누가 결정하는지 아무도 말하지 못할 때입니다. RACI 표와 분기에 한 번 열리는 변경 위원회로는 이 문제가 풀리지 않습니다. 거버넌스는 권한이 어디에 있는지, 변경을 어떻게 분류하는지, 두 책임자가 부딪힐 때 누가 결정하는지를 정해야 합니다.
이것이 빠지면 표류가 시작됩니다. 비공식 설정, 문서 없는 연동, 서로의 메타데이터를 덮어쓰는 사업부가 쌓이고, 플랫폼은 릴리스마다 바꾸기 어려워집니다.
세 단계의 결정 권한
권한은 세 단계에서 명시해야 합니다.
- 플랫폼 단계: org 전략, 릴리스 주기, 표준, 보안·공유 모델을 정합니다. 작은 그룹이 맡고, 반대할 수 있는 책임자를 한 명 지명합니다.
- 도메인 단계: 클라우드 하나 또는 사업부 하나의 설정을 책임집니다.
- 변경 단계: 변경 유형별로 누가 어느 기한 안에 승인하는지 정합니다.
세 단계를 하나의 승인 대기열로 합치면 병목이 생기고, 팀은 그 병목을 우회하는 법을 익힙니다. 비공식 개발은 거기서 시작됩니다. 거절하려고만 존재하는 거버넌스는 우회당합니다. 안전한 길을 가장 짧은 길로 만드는 거버넌스는 지켜집니다.
에스컬레이션 경로도 단계만큼 중요합니다. 공유 오브젝트를 두고 두 도메인 책임자가 부딪히면 플랫폼 단계가 결정하고, 그 결정 기한을 문서로 남깁니다.
L’Occitane Group의 일본·프랑스 Service Cloud 딜리버리(2023-2024)에서는 본사와 APAC 팀에서 들어오는 변경이 하나의 검증 절차를 거쳤습니다. 원리는 단순합니다. 절차가 하나면 본사 요청과 APAC 팀 요청이 같은 질문으로 분류되고 같은 릴리스로 나갑니다. 절차가 둘이면 양쪽 모두 공유 오브젝트를 자기 것이라 여기고, 충돌은 프로덕션에서 드러납니다.
영향 범위에 따른 변경 등급
변경은 무엇을 망가뜨릴 수 있는지로 분류합니다. 누가 요청했는지, 얼마나 급해 보이는지는 기준이 아닙니다.
| 등급 | 범위 | 예시 | 승인 |
|---|---|---|---|
| 플랫폼 위험 | 공유 인프라, org 간 연동, 보안·공유 모델 | Org-wide defaults, 여러 클라우드에 걸친 신규 연동 | 어느 환경에 들어가기 전이든 리뷰 보드 승인. 설계 책임자, 보안 책임자, 사업부 전체에 권한이 있는 현업 책임자. 열두 명이 아니라 세 명 |
| 도메인 위험 | 클라우드 하나 또는 사업부 하나, 인접 시스템에 영향 가능 | 공유 오브젝트의 Flow, 여러 팀이 쓰는 프롬프트 템플릿, API 계약 변경 | 도메인 책임자 승인과 문서화된 롤백 계획 |
| 독립 변경 | 시스템 간 의존성 없음 | 공유하지 않는 오브젝트의 필드, 리포트, 대시보드, 한 그룹 안의 Permission Set | 승인자 한 명, 간단한 검토 |
등급 자체도 관리해야 합니다. 무거운 절차를 피하는 가장 쉬운 방법은 자기 변경을 독립 변경이라고 신고하는 일입니다. 해법은 평이한 질문으로 구성한 필수 영향도 평가입니다. 공유 오브젝트를 건드립니까? API 계약을 바꿉니까? 누가 어떤 레코드를 보고 수정할 수 있는지가 달라집니까? 에이전트가 할 수 있는 일이 달라집니까? 등급은 이 답변이 정합니다. 요청자의 선호는 등급을 정하지 못합니다.
환경과 자동 관문으로 하는 릴리스 거버넌스
모든 배포를 매주 검토하는 변경 위원회는 납기 압박을 받는 첫 팀이 우회합니다. 오래가는 거버넌스는 환경 안에 들어가 있습니다.
기본 형태는 이렇습니다. 프로덕션을 그대로 반영한 Full sandbox를 두고, 배포 경로의 관문에서 자동 점검을 돌립니다. 점검을 통과하고 위험 기준선 아래에 있는 변경은 정해진 주기대로 나갑니다. 경고가 뜬 변경은 사람에게 넘어갑니다. 사람의 검토는 예외가 됩니다.
점검 항목은 평범한 엔지니어링 관행입니다. Apex 정적 분석, 일정 복잡도를 넘는 Flow는 설계 검토를 거치게 하는 규칙, API 버전 점검, 그리고 팀이 정하고 강제하는 테스트 커버리지 기준입니다. 스폰서가 이것을 직접 설정할 필요는 없습니다. 스폰서는 어떤 점검이 도는지, 무엇이 사람의 검토를 부르는지, 실패한 관문을 누가 통과시킬 수 있는지를 알아야 합니다.
릴리스 주기도 거버넌스 결정입니다. 고정된 릴리스 창과 그 직전의 짧은 동결 기간을 두면 플랫폼이 예측 가능해지고 감사 기록이 남습니다. 릴리스에 들어간 모든 변경은 문서화되고, 테스트되고, 책임자가 분명합니다.
AI 변경도 같은 문을 지납니다
Agentforce(에이전트포스)는 설정처럼 보이지만 비즈니스 로직처럼 작동하는 변경 지점을 더합니다. 에이전트의 범위(토픽)는 에이전트에게 무엇을 물을 수 있는지 정합니다. 액션은 에이전트가 할 수 있는 일, 즉 Opportunity 수정, 이메일 발송, 외부 시스템 호출을 정합니다. 지침(instructions)은 행동 방식을 정합니다. Prompt Builder의 프롬프트 템플릿은 에이전트가 쓰는 문장을 만듭니다. 문서 없이 바꾼 지침은 Flow 안에 문서 없이 넣은 규칙과 같습니다.
그래서 같은 변경 통제를 따릅니다. 빌드 전에 에이전트 범위를 문서로 적습니다. 프로덕션 전에 미리 정한 통과·실패 기준으로 에이전트를 테스트합니다. 재무 레코드를 수정하거나 외부로 메시지를 보내는 액션에는 사람의 확인 단계를 둡니다. 프롬프트 템플릿은 다른 변경과 같은 릴리스 주기로 검토하고, 레코드를 쓰는 액션은 절대 독립 변경으로 분류하지 않습니다. 템플릿은 Prompt Builder 거버넌스 노트에서 더 자세히 다룹니다.
거버넌스는 고객사에 남아야 합니다
SI는 구축을 맡을 수 있습니다. 결정 권한까지 쥐어서는 안 됩니다. 오픈 이후에도 관리자 권한, 변경 승인, 릴리스 관리가 SI 쪽에 남아 있으면 작은 변경 하나도 견적과 일정 협의 대상이 되고, org가 왜 그렇게 설정됐는지 내부에서는 아무도 모르게 됩니다.
내부에 남겨야 할 대상은 세 가지입니다. 권한 모델(누가 무엇을 보고 바꿀 수 있는지), 변경 승인 규칙, 릴리스 관리입니다. 대규모 신규 구축과 단기 전문 작업은 파트너에게 맡겨도 되지만 조건이 두 가지 붙습니다. 설계 의도를 고객사 자체 표준 문서에 기록해야 하고, 프로젝트가 끝나면 관리자 권한이 내부로 돌아와야 합니다. 어떤 계약 조항도 반대할 수 있는 내부 책임자를 대신하지 못합니다.
확인할 항목
- 플랫폼, 도메인, 변경 각 단계에서 결정하는 사람과 에스컬레이션 기한을 말할 수 있습니까?
- 변경 등급은 요청자가 정합니까, 영향도 평가가 정합니까?
- 릴리스 관문에서 어떤 점검이 돌고, 실패한 점검은 누가 통과시킬 수 있습니까?
- 에이전트 범위, 액션, 지침, 프롬프트 템플릿이 Flow와 같은 변경 기록에 들어갑니까?
- 오픈 이후 관리자 권한과 릴리스 관리는 내부 팀과 SI 중 어느 쪽에 있습니까?