Salesforce org를 하나로 둘지 여러 개로 나눌지는 대개 기술 설계 문제로 논의되지만, 실제로는 거버넌스로 결정됩니다. 이 질문은 인수합병, 규제 감사, 또는 한 사업부가 자체 환경을 요구할 때 불거지는 경우가 많고, 계획된 검토에서 나오는 경우는 드뭅니다. 결정을 좌우하는 질문은 운영 모델에 속합니다. 공유 데이터 정의를 누가 책임지는지, 누가 언제 릴리스할 수 있는지, 어떤 객체의 기준 시스템이 어느 org인지입니다. 이 질문에 먼저 답하면 org 구성은 따라옵니다.
단일 org가 전제하는 조건
단일 org는 조직 전체가 Account의 정의 하나, Opportunity 단계 하나, 수명 주기 규칙 하나에 합의할 수 있고, 거버넌스 조직이 현지 변형을 거부할 수 있다는 전제 위에 섭니다. 릴리스 조율도 전제합니다. org에 배포하는 모든 팀이 sandbox, 배포 시간대, 회귀 테스트를 함께 씁니다.
업무가 균질하다면 이 거래는 가치가 있습니다. 데이터 모델 하나, 릴리스 프로세스 하나, 연동 없는 보고가 가능합니다. 균질하지 않다면 비용은 권한 모델, 늘어나는 페이지 레이아웃, 사실상 서로 다른 프로세스를 처리하려고 갈라지는 자동화에서 드러납니다. 간단한 점검 방법이 있습니다. Account 계층, 공유 모델, 자동화 가운데 사업부가 다르다는 이유만으로 존재하는 조건 분기를 목록으로 만들어 봅니다. 이 목록이 계속 길어진다면 그 org는 데이터베이스 하나에서 여러 시스템을 돌리는 셈입니다.
Sanofi(Cognizant 고객사, 2021-2022)는 통합 사례입니다. 여섯 개 시스템이 하나의 Salesforce org로 이관됐습니다. 이런 통합은 정의 문제를 앞당깁니다. 소스마다 고객이나 제품의 정의가 따로 있고, 단일 org는 그중 하나만 받아들입니다. 이 협상이 레코드 이관보다 먼저이고, 레코드 이관은 마지막 단계입니다. 컷오버 전에 입증할 항목은 Salesforce 데이터 마이그레이션 노트에서 다룹니다.
단일 org에도 책임자가 필요합니다. 커스텀 객체, Flow, Apex 클래스의 책임자가 지정되지 않으면 의존성이 보이지 않게 되고, 각 팀은 회귀 없이 테스트할 자신이 없는 구성 요소를 건드리지 않게 됩니다. org는 기술적으로 하나이지만 실제 운영은 쪼개집니다. 이 책임을 담는 조직은 Salesforce CoE 노트에서 설명합니다.
org 분리가 정당한 경우
org 분리는 격리가 필수 요건일 때 정당합니다. 다른 규제 체계를 따르는 법인에는, 공용 org 안의 공유 모델보다 감사인에게 입증하기 쉬운 데이터·접근 분리가 필요할 수 있습니다. 최근 인수한 회사에는 전환 기간 동안 자체 org가 필요할 수 있습니다. 인수 직후 몇 달 안에 강제로 이관하기는 현실적으로 어렵기 때문입니다. 릴리스 주기가 맞지 않는 사업부는 가장 빠른 팀이 가장 느린 팀의 일정에 묶이지 않도록 org를 나눌 수 있습니다.
피해야 할 패턴은 거버넌스를 피하려고 multi-org를 택하는 경우입니다. 공통 데이터 모델에 합의하지 못해서 org를 여러 개 두는 식입니다. 이렇게 하면 이견은 미뤄지고, 상시 연동 계층, 별도 릴리스 프로세스, 별도 권한 감사, 두 번째 관리자 팀이 더해집니다. 인수나 파일럿을 위해 만든 ‘임시’ org도, 누군가 날짜가 정해진 종료 결정을 세우지 않으면 그대로 영구 org가 됩니다.
org 간 데이터 계약
org를 하나 더 만든다고 공유 정의가 사라지지는 않습니다. Lacoste의 다중 시장 Customer 360 프로그램(2023)은 여섯 개 사업부에 걸쳐 있었습니다. 이런 사업부가 org 하나를 함께 쓰든 여러 org로 데이터를 보내든, 고객을 누가 정의하고 그 정의를 누가 바꿀 수 있는지에는 같은 답이 필요합니다. 단일 org에서는 그 답이 거버넌스에 있습니다. 여러 org 사이에서는 데이터 계약으로 문서화해야 합니다.
multi-org 구성이 API가 없어서 실패하는 경우는 드뭅니다. 두 팀이 각자 다른 정의로 같은 값을 바꾸는데 둘 사이를 판정할 규칙이 없을 때 실패합니다. 계약은 기술 인터페이스가 아니라 업무 객체 단위로 관리합니다. 공유 속성마다 기준 시스템, 읽을 수 있는 시스템, 직접 쓰지 않고 수정을 제안할 수 있는 시스템, 소스 값이 없거나 잘못됐거나 충돌할 때 적용할 규칙을 적습니다.
전화번호를 예로 들어 보겠습니다. 서비스 org가 고객과 통화한 뒤 번호를 고칠 수 있다면, 영업 org가 다음 동기화 때 예전 값을 다시 보내서는 안 됩니다. 수정 사항을 배포 전에 기준 시스템으로 먼저 보내거나, 감사 기록을 남기는 우선순위 규칙을 계약에 명시해야 합니다. 연동이 기술적으로 성공했다는 이유로 조용한 덮어쓰기를 받아들이는 쪽이 최악의 선택입니다.
계약에는 공유 정의를 누가 바꿀 수 있는지도 적습니다. 선택 필드 추가는 대개 아무것도 깨뜨리지 않고 배포할 수 있습니다. 필드를 필수로 바꾸거나, 식별자를 변경하거나, 선택 목록 값을 교체하면 모든 소비 org와의 호환성 검토, 새 버전, 대체되는 항목의 폐기 날짜가 따라와야 합니다. 인터페이스마다 소스를 고치는 생산 측 책임자와, 변경이 반영됐음을 확인하는 소비 측 책임자를 지정합니다.
중앙 데이터 계층이 생겨도 이 작업은 남습니다. Salesforce는 Data Cloud 데이터를 여러 org와 공유하도록 2024년 10월 Data Cloud One을 정식 출시했습니다. 공유 기능일 뿐, 중앙 계층을 운영상의 기준 시스템으로 만들어 주지 않고 이메일 주소의 책임자를 정해 주지도 않습니다.
방향을 바꿀 때
선택을 되돌리는 일은 어느 방향이든 비용이 큽니다. 기술 작업은 오히려 다룰 만한 부분입니다. 무엇을 어디에 둘지, 기준 데이터의 책임자가 누구인지, 공통 프로세스를 어떻게 나눌지 합의하는 단계에서 이런 프로그램이 멈춥니다.
분리할 때는 구성보다 데이터에서 시작합니다. 모든 객체와 연동 의존성을 목록화하고, 분리 이후 공유 객체마다 책임자를 지정하고, 분리 뒤가 아니라 기존 org와 나란히 연동을 구축합니다. 정해진 기간 동안 두 환경을 병행 운영하며 데이터 무결성을 확인한 뒤 전환합니다.
통합할 때는 데이터 모델 협상이 먼저입니다. 공통 Account 모델 없이 두 org를 합치면 원래 두 org보다 못한 org가 나옵니다.
임시 org는 만들 때 종료 기준을 정합니다. 통합할지 유지할지 결정하는 날짜와, 그 결정을 내릴 사람입니다.
확인할 항목
- 공유 객체마다 기준 시스템과 정의 책임자가 지정되어 있습니다.
- 분리된 org마다 그 이유가 문서로 남아 있습니다. 규제상 격리, 인수 후 전환, 릴리스 독립성 가운데 하나입니다.
- 임시 org에는 날짜와 결정권자가 정해진 종료 결정이 있습니다.
- 공유 정의 변경은 소비 org와의 호환성 검토를 거칩니다.
- 단일 org라면 Account나 Opportunity 단계의 현지 변형을 거부할 수 있는 조직이 있습니다.