Org 전략은 랜드스케이프 결정이다

🌐 28개 언어로도 제공

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

AI로 생성한 이미지

AI로 번역했습니다. 아직 커뮤니티의 검토를 거치지 않았습니다. 영어로 읽기

Data Architect 과정 4장인 기업 데이터 이해하기의 모듈 5/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 시스템 랜드스케이프를 그려라 · 다음: Steve Trucking의 랜드스케이프

이 모듈이 답하는 질문: org 하나인가 여럿인가, 그리고 어디서 실행되는가?

CTA 후보자들을 가르칠 때 저는 시나리오의 가장 큰 결정이 처음 5~10분 안에 온다고 말합니다. Salesforce org를 몇 개 다루고 있는가? 큰 org 하나? 북미, EMEA, APAC 지역 org? 사업부마다 별도 org? 고유한 규칙이 있는 국가를 위한 특별한 org? 그리고 바로 이어서, 그 org들은 어디서 실행되는가?

관리상의 세부가 아닙니다. 데이터가 있는 곳, 연동, 보고, 정체성, 그리고 전 세계 사람들이 시스템에 닿는 방식을 바꿉니다. 그래서 저는 org 전략을 랜드스케이프 결정으로 다루고, 가장 먼저 정합니다.

org 하나로 시작하라

제 출발점은 단순합니다. org 하나로 시작하라. org 하나가 늘 옳아서가 아니라, 하나를 더하려면 이유가 필요하기 때문입니다. org 하나는 공유 고객 데이터를 위한 한 곳, 보안 모델 하나, 배포할 곳 하나, 연동 묶음 하나, 보고할 곳 하나를 줍니다. 그리고 org 하나로도 서로 다른 사업부, 국가, 프로세스, 레코드 유형, 앱, 공유 모델, 경험을 지원할 수 있습니다.

그래서 유럽이 일을 조금 다르게 한다고, 어떤 사업부에 자기 영업 프로세스가 있다고, 사업부들이 서로 사이가 나쁘다고 org를 더하지 않습니다. 그것들은 요구사항이지 org 경계가 아닙니다. 질문은 이것입니다. 또 하나의 org를 정당화할 만큼 강한 힘은 무엇인가?

org가 여럿이면 비용이 든다

org 하나를 셋(북미, 유럽, 아시아태평양)으로 나누면 깔끔한 상자 세 개를 그린 게 아니라 새 질문을 만든 것입니다. 글로벌 고객은 어디에 있는가? 두 지역에서 영업한다면 사본 두 개, 그리고 어느 쪽이 소유하는가? 글로벌 보고는 어떻게 하는가? ERP는 셋 모두와 연동하고, 웨어하우스는 피드 세 개를 받고, ID 공급자는 셋 모두에 연결하는가? 같은 기능을 세 번 배포하고 데이터 모델 세 개를 맞춰 두는가? 에이전트에게 고객의 글로벌 뷰가 필요하다면 어느 org에 묻는가?

모듈 4의 랜드스케이프로 돌아가십시오. Salesforce 상자 하나가 셋이 되고, 모든 화살표를 다시 그려야 합니다. 다중 org가 틀린 건 아닙니다. 결코 공짜가 아닐 뿐입니다.

진짜 경계를 찾아라

무엇이 또 하나의 org를 정당화할 수 있을까요? 아키텍처를 형성할 만큼 진짜인 경계입니다. 데이터 레지던시, 규제, 법적 분리, 정말로 다른 운영 모델, 아직 통합되지 않은 인수, 지역 호스팅 제약, 매우 다른 거버넌스, 때로는 규모나 격리. 목록이 완전하지는 않습니다. 요점은 **“이 집단들은 다르다”**와 **“이 집단들에는 아키텍처 경계가 필요하다”**를 구분하는 것입니다. 두 번째 기준이 훨씬 높습니다.

지리가 자동으로 org 전략이 되지는 않는다

“30개국에서 영업하니 org가 30개 필요해요.” 아닙니다. 지리는 아키텍처 요구사항을 가져올 때 중요합니다. 회사는 전 세계에 사용자를 두고도 하나의 공통 아키텍처를 쓸 수 있습니다. 그래서 저는 국가를 세지 않고, 그것과 함께 무엇이 오는지 묻습니다. 데이터는 어디에 저장해도 되는가? 어디서 처리해도 되는가? 개인정보의 국외 이전에 제한이 있는가? 레지던시에 대한 계약상 약속이 있는가? 어떤 지역에 다른 Salesforce 서비스나 호스트가 필요한가? “독일에 사무실이 있어요” 하나만으로는 부족합니다.

호스팅은 그림의 일부다

여기서 현대 플랫폼이 랜드스케이프를 더 흥미롭게 만듭니다. Hyperforce는 전 세계 지역의 퍼블릭 클라우드 인프라에서 Salesforce를 실행해, 고객에게 데이터가 있을 곳에 대한 선택과 통제를 더 줍니다(Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). 그래서 상자에 “Salesforce, 유럽”이라고 붙일 때 그 위치가 중요할 수 있습니다.

하지만 정확해야 합니다. org가 있을 곳을 고르는 것이 모든 서비스의 모든 바이트가 거기 머문다는 약속은 아닙니다. Salesforce는 고객에게 구매하는 서비스의 추가 하위 처리자를 포함해 Hyperforce의 신뢰·규정 준수 문서를 검토하라고 말합니다(같은 출처). 그러니 “X국 Hyperforce에 있으니 모든 게 X국에 머문다”고 말하지 마십시오. 실제로 어떤 서비스를 쓰는지, 어떤 요구사항을 충족하는지 아십시오. 그리고 무엇을 고르는지 주목하십시오. 고르는 것은 지역이지, 그 밑의 클라우드가 아닙니다. Hyperforce는 AWS에서 실행되고 2026년 말부터는 Google Cloud에서도 실행되며, org가 어느 공급자에 놓일지는 Salesforce가 정합니다. 특정 공급자를 피해야 할 문서화된 규제상의 이유가 있는 고객은 자기 계정 팀과 상의합니다(같은 출처).

변호사 흉내를 내지 마라

아키텍트가 자기 역할을 알아야 하는 곳도 여기입니다. 누군가 “유럽 개인정보 보호법 때문에 org를 분리해야 해요”라고 하면 저는 그대로 받아들이지 않습니다. 그렇다고 회사의 변호사를 자처해 그럴 필요 없다고 선언하지도 않습니다. 묻겠습니다. 우리는 정확히 어떤 요구사항을 충족하려는 건가? 데이터가 저장되는 곳, 처리되는 곳, 국외 이전, 지원을 위해 누가 접근할 수 있는지, 계약, 내부 정책? 그다음 개인정보, 보안, 규정 준수, 법무와 함께 그 요구사항을 아키텍처로 바꿉니다. 법적 요구사항을 지어내지도, 무시하지도 마십시오. 번역하십시오.

유럽이 자체 org를 가질 때

실제 시나리오에서 보는 경계가 있습니다. 어떤 회사가 미국에도 유럽에도 크게 진출해 있습니다. 큰 고객층이 둘, 영업과 서비스 조직이 둘이고, 유럽에는 GDPR을 중심으로 짠 개인정보 보호 프로그램이 있습니다. GDPR은 “별도의 Salesforce org가 필요하다”고 말하지 않습니다. 개인정보에 대한 규칙을 정하며, 그것이 EU 밖으로 이전될 수 있는 경우도 포함합니다(GDPR, 제5장 (opens in a new tab)). 하지만 이 회사는 개인정보 보호팀, 법무팀과 함께 일한 끝에, 유럽 고객의 개인정보는 유럽에서 호스팅되고, 유럽 팀이 운영하고, 유럽의 거버넌스 아래 있는 org에 있어야 한다고 결정합니다. 그것은 진짜 요구사항이고, 제 것이 아니라 그들의 것입니다.

이제 “하나의 큰 글로벌 org”는 더 이상 선호의 문제가 아닙니다. 랜드스케이프에 경계, Salesforce AMER과 Salesforce EMEA가 생기고, 저는 그것을 그려야 합니다. 그리고 두 번째 org는 결코 상자 하나 더가 아닙니다.

Click to enlarge

AMER과 EMEA, 두 org. 호박색이 두 번째 org가 더하는 것입니다. 상자 하나 더가 아니라, 모든 화살표가 다시.

화살표를 다시 따라가라

org가 둘 이상이면 랜드스케이프를 다시 따라가십시오. ERP가 모든 org에 제품을 보내는가? 각 org가 주문을 돌려보내는가? 고객은 어디서 마스터로 관리되며, 그 데이터가 지역을 넘어도 되는가? 연동 층은 글로벌인가 지역별인가? 어떤 ID 공급자가 어떤 사용자를 로그인시키는가? 분석 데이터는 어디로 가는가?

비용이 가장 빨리 드러나는 곳이 세 군데 있습니다.

보고. CEO가 글로벌 파이프라인을 원합니다. org 하나라면 Salesforce 보고서입니다. 셋이라면 기업 보고 문제입니다. 복제할까, 웨어하우스로 보낼까, 연합할까? 얼마나 최신이어야 하고, org들이 “파이프라인”을 같은 뜻으로 정의하기는 하는가? 분석이 사는 곳은 데이터가 사는 곳을 따릅니다. 운영 데이터를 일부러 나눴다면 인사이트가 어떻게 다시 합쳐질지 설계해야 합니다.

마스터 데이터. 글로벌 고객이 미국, 독일, 일본에서 구매합니다. org 셋이니 계정도 아마 셋입니다. 그것들이 같은 회사라는 걸 어떻게 알까요? 글로벌 식별자는 무엇이고 누가 소유하는가? 한 지역이 주소를 바꾸면 퍼져야 하는가? 어떤 속성이 글로벌이고 어떤 것이 지역별인가? org 전략은 정체성을 풀지 않습니다. 정체성 문제를 바꿉니다. 그것이 6장입니다.

연동. org 하나: Salesforce, 연동 층, ERP. org 셋: 연동 층으로의 연결 셋, 어쩌면 하나는 자기 호스트와 연결성을 가지며, 일부 흐름은 공유되고 일부는 지역별이고, 일부 데이터는 넘어가도 되고 일부는 안 됩니다. 네트워크도 바뀔 수 있습니다. 기업이 Hyperforce로의 전용 사설 연결이 필요하다면(AWS에서는 Salesforce가 AWS Direct Connect를 권장합니다, 같은 Hyperforce FAQ), 그림의 org와 호스트 하나하나가 계획해야 할 또 하나의 연결입니다. org가 실행되는 곳이 기업의 나머지가 그것에 닿는 방식을 바꿀 수 있습니다.

org 하나인가 여럿인가는 지금 내리는 결정이다. 처음에, 랜드스케이프 위에서. 그다음 org들이 데이터를 어떻게 공유하는지(org 간 Salesforce Connect, org 사이의 연동, Data 360)는 메커니즘의 문제이고, 14장 org 하나인가 여럿인가? *(coming soon)*에서 다룹니다.

데이터 모델과 연동 아키텍처를 다 설계한 뒤에야 “참, 이거 org 세 개여야 해요”라는 말을 듣는다면, 작은 조정을 한 게 아닙니다. 아키텍처를 바꾼 것입니다. 그래서 이 결정이 먼저입니다.

상자를 작게 하려고 나누지 마라

큰 org는 복잡하게 느껴집니다. 단위, 개체, 사용자, 연동이 많습니다. 누군가 “각자 자기 org를 가지면 더 깔끔하지 않을까요?”라고 말합니다. 그림은 더 깔끔해질 수 있습니다. 기업은 아닐 수 있습니다. 내부 복잡성을 분산된 복잡성과 맞바꾼 것입니다. 동기화, 중복 데이터, org 간 정체성, 글로벌 보고, 여러 릴리스 파이프라인, 중복된 연동과 자동화, 그리고 그 모든 것의 거버넌스. 그래도 그것이 옳은 맞바꿈일 때가 있습니다. 하지만 분리는 단순함과 같지 않습니다.

org 하나도 공짜는 아닙니다. 공유 거버넌스가 더 중요해지고, 팀들이 서로에게 영향을 줄 수 있고, 보안 경계를 신중하게 설계해야 하고, 데이터 모델이 여러 집단을 섬겨야 하고, 릴리스에 조율이 필요하며, 지역 규칙이 모두를 제약할 수 있습니다. 그러니 “Steve는 늘 org 하나라고 말한다”가 아닙니다. 제 출발 기울기는 org 하나이고, 그다음 저를 거기서 움직일 만큼 강한 요구사항을 찾습니다.

결정을 보이게 하라

org 전략이 중요하다면 일반적인 Salesforce 구름을 그리지 마십시오. org들을 그리고 레이블을 붙이고(AMER, EMEA, 무엇이든 실제인 것), 각각 뒤의 호스팅이나 레지던시 요구사항을 적고, 연결을 따라가십시오. 다른 아키텍트가 각 경계가 왜 존재하는지 볼 수 있어야 합니다. Salesforce 상자가 왜 셋인지 설명할 수 없다면 결정을 끝내지 않은 것입니다.

Steve Trucking은 미국에서 org 하나를 운영하며, 브리프에는 또 하나를 요구하는 것이 없습니다. 하지만 캡스톤을 위해 이 모듈을 기억해 두십시오. 자기 org를 가지고 오는 인수는 바로 이런 질문들을 시험하는 경계입니다.

시험 너머: AI가 바꾸는 것. 에이전트는 사용자에게 org 경계를 보이지 않게 만들 수 있습니다. 그 아래에서 아키텍처는 여전히 에이전트가 어느 org나 시스템에 물어도 되는지, 어떤 데이터가 지역을 넘어도 되는지, 어느 답이 권위 있는지 정해야 합니다. AI는 경험 속에 복잡성을 숨길 수 있지만, 거버넌스나 경계를 없애지는 않습니다.

아키텍트가 여기서 결정하는 것

• org 하나 안에서 차이를 푸는 대신 org를 둘 이상 둘 진짜 아키텍처적 이유가 있는지.
• 각 org가 어디서 실행되며, 어떤 레지던시, 규제, 계약, 비즈니스 요구사항이 그것을 거기 두는지.
• 어떤 데이터가 org와 지역 경계를 넘어도 되는지, 마스터 데이터는 어디서 권위를 가지는지, 글로벌 정체성은 어떻게 작동하는지.
• Salesforce 상자 하나가 여럿이 될 때 연동, 정체성, 분석, 보고가 어떻게 바뀌는지.
• 분리의 이점이 그것이 만드는 분산 아키텍처의 비용을 감수할 가치가 있는지.

시나리오를 읽을 때 저는 이 결정을 가장 먼저 찾습니다. org 하나인가 여럿인가, 어디에 호스팅되는가, 무엇 때문에 그래야 하는가? 그 답이 나오면 랜드스케이프의 나머지가 모양을 갖추기 시작합니다.

더 알아보기

• Salesforce 도움말, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab)(영어), 확인일 2026-10-14.
• EUR-Lex, Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab), 제5장(제3국으로의 개인정보 이전)(영어), 확인일 2026-10-14.