Salesforce는 여러 시스템 중 하나다

🌐 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장인 기업 데이터 이해하기의 모듈 1/6. 각 모듈은 독립적으로 읽을 수 있습니다. 다음: 기업 데이터의 종류

이 모듈이 답하는 질문: 데이터 아키텍트는 왜 org를 설계하기 전에 org를 둘러싼 것을 그릴까요?

CTA 후보자들을 가르칠 때 첫날 숙제는 늘 같습니다. 시나리오를 읽으십시오. 빈 캔버스에서 시스템 랜드스케이프를 시작하십시오. 그다음에야 데이터 모델을 그려 보십시오. 개체도, 연동의 세부도 아닌, 랜드스케이프입니다. 무엇이 Salesforce 안에 속할지 정하기 전에 Salesforce를 둘러싼 것을 보고 싶습니다.

많은 Salesforce 전문가에게는 관점의 전환입니다. 관리자나 개발자로 경력을 쌓았다면 Salesforce는 자연스럽게 당신 세계의 중심입니다. 설정을 열고, 개체를 만들고, Flow를 짓고, Apex를 쓰고, 다른 시스템을 Salesforce 안으로 연동합니다. 모든 것이 org에서 시작하는 것처럼 보입니다. 아키텍트는 카메라를 뒤로 빼야 합니다. 기업에서 Salesforce는 여러 시스템 중 하나이고, 데이터를 소유한 쪽이 아닌 경우도 꽤 많기 때문입니다.

랜드스케이프를 먼저 그려라

2장은 논리 모델을 만들었고, 3장은 그것이 Salesforce에서 어떻게 사는지 물었습니다. 이제 문제를 더 키우겠습니다. Salesforce가 무엇을 소유해야 할지 정하기 전에, 그 주변의 기업을 이해하고 싶습니다. 어떤 시스템이 이미 있는가? 고객은 어디서 만들어지고, 제품은 어디서 정의되고, 주문은 어디서 시작되고, 청구서는 어디서 생성되는가? 정체성은 어디에 있는가? 분석은 어디서 이루어지고, 문서는 어디에 보관되고, 이력은 어디에 있는가? 어떤 시스템이 Salesforce의 데이터를 필요로 하고, Salesforce는 어떤 시스템에 의존하는가?

이 질문들이 아키텍처를 바꿉니다. 그래서 저는 빈 캔버스에서 시작해 가운데에 Salesforce를 놓고 그 주위의 모든 것을 그립니다. 정확히 어떻게 배치하는지는 모듈 4에서 보여 드립니다. 지금 교훈은 단순합니다. org가 살아야 할 세계를 이해하기 전에 org를 설계하지 마십시오.

Salesforce는 흔히 기록 시스템이 아니다

아주 흔한 기업을 보십시오. Salesforce에 ERP, 즉 SAP나 Oracle 같은 전사적 자원 관리 시스템이 더해져 재무, 제품, 재고, 구매, 주문 처리를 운영합니다. 이제 단순한 질문을 하십시오. 고객은 어디에 있는가?

Salesforce일 수도, ERP일 수도, 둘 다일 수도 있고, 거기서 흥미로워집니다. 영업 담당자는 잠재 고객을 Salesforce의 계정으로 다루고, 그들이 돈을 내는 고객이 되면 ERP가 공식 고객 번호를 발급할 수 있습니다. 제품과 가격은? 아마 ERP. 재고는? Salesforce인 경우는 거의 없습니다. 주문은 Salesforce에서 받고 ERP에서 처리할 수 있고, 청구서는 ERP에서 나오고, 서비스는 Salesforce에 있고, 분석은 Salesforce 보고서와 웨어하우스로 나뉩니다. 갑자기 우리의 멋진 Salesforce 데이터 모델은 기업 데이터 모델이 아닙니다. 그 일부입니다.

제가 거듭 보는 연동

제가 가장 흔히 보는 연동은 이렇습니다. 고객, 제품, 가격은 ERP에서 Salesforce로 들어오고, 주문은 나간다. SAP든 Oracle이든 다른 어떤 ERP로 바꿔 넣어도 모양은 같습니다. ERP가 고객과 제품의 골든 레코드를 소유하므로, 그 흐름은 오른쪽에서 Salesforce로 들어옵니다. 영업은 Salesforce에서 거래를 성사시키므로, 주문은 거기서 시작해 ERP로 돌아가 처리되고, 청구되고, 회계 처리됩니다.

그 흐름은 그냥 연동이 아닙니다. 기업이 진실이 어디에 있다고 믿는지 알려 줍니다.

한 방향 화살표는 저를 불안하게 한다

흐름이 하나뿐인 연동을 볼 때마다 저는 걱정하기 시작합니다. 높은 수준에서 누군가 화살표 하나를 그립니다. Salesforce에서 ERP로 가는 주문. 좋습니다. 이제 더 깊이 보십시오. ERP의 고객도, 제품도, 가격도 모르는데 어떻게 주문을 ERP로 보낼 수 있을까요? 주문은 ERP에 이미 있는 고객에 연결되어야 하고, 모든 품목은 ERP가 이미 판매하는 SKU여야 합니다. 반대편에 존재하지 않는 제품의 품목을 보낼 수는 없습니다. 그러니 그 주문 화살표가 작동하려면 먼저 반대 방향으로 흐르는 역방향 흐름이 있어야 합니다.

그것이 제가 모든 화살표에 던지는 질문입니다. 이 흐름은 무엇에 의존하는가? 눈에 보이는 높은 수준의 화살표에는 보통 아직 그리지 않은 역방향 흐름이 필요합니다.

더 깊이 보면 돌아오는 길이 보입니다. Salesforce가 주문을 보냅니다. 그다음은요? 수락됐나요, 거부됐나요? 출하됐나요, 일부만 출하됐나요, 취소됐나요? 청구됐나요? Salesforce의 누군가가 알아야 하나요? 알 필요가 없을 수도 있습니다. 하지만 누군가는 물었어야 합니다. 아무것도 돌아오지 않는다면 괜찮습니다. 이유를 말해 주십시오.

기업은 한꺼번에 오지 않았다

랜드스케이프가 복잡해지는 이유 중 하나는 아무도 그것을 한꺼번에 만들지 않았다는 것입니다. 데이터는 물결처럼 왔습니다. 먼저 파일. 고정 형식 레코드, 그다음 CSV 같은 구분자 파일. 그다음 운영 데이터를 위한 관계형 데이터베이스. 그다음 분석을 위해 그것을 모으는 데이터 웨어하우스. 그다음 테이블에 깔끔하게 들어가지 않는 문서, 키-값 쌍, 그래프를 위한 NoSQL 데이터베이스. 그다음 방대한 원시·반정형 데이터를 위한 데이터 레이크, 그리고 둘을 합친 레이크하우스. Kafka나 Salesforce 이벤트 버스 같은 이벤트 스트림은 데이터를 야간 배치가 아니라 일어나는 즉시 옮깁니다. 그리고 이제 연합, 즉 다른 플랫폼이 데이터를 쓰기 전에 한곳으로 복사할 필요가 없는 방식입니다.

아직 기술이 요점은 아닙니다. 요점은 이것입니다. 새 물결이 옛 물결을 사라지게 하는 일은 드물다. 큰 기업에 들어가면 그것들을 한꺼번에 만납니다. 관계형 데이터베이스, ERP, Salesforce, 웨어하우스, 레이크, SFTP 드롭, API, 이벤트 스트림, 누군가 매주 금요일 아직도 이메일로 보내는 스프레드시트, 그리고 만든 사람이 6년 전에 은퇴해서 모두가 건드리기 두려워하는 시스템 하나. 당신이 설계하는 기업은 제품 브로슈어 속 기업이 아니라 바로 그것입니다.

시스템마다 존재하는 이유가 다르다

그래서 저는 결코 “모든 데이터를 어떻게 Salesforce에 넣지?”로 시작하지 않습니다. 왜 그걸 전부 거기에 두고 싶을까요? Salesforce는 영업과 서비스 담당자가 고객과 일하기에 가장 좋은 곳일 수 있습니다. 그렇다고 재무 시스템, 전사 웨어하우스, 원격 측정 저장소, 문서 보관소, 혹은 회사가 만들어 낸 모든 클릭, GPS 읽기, 과거 트랜잭션의 집이 되는 건 아닙니다.

3장은 org 하나에 대해 **이 데이터는 어디에 있어야 하는가?**를 물었습니다. 기업 수준에서는 같은 질문이 더 커집니다. 때로는 Salesforce가 데이터를 소유하고, 때로는 사본을, 때로는 참조만 가지며, 때로는 아예 갖지 말아야 합니다.

코어, 오프코어, Hyperforce

이해해야 할 경계가 하나 더 있습니다. “Salesforce”조차 런타임 하나, 데이터베이스 하나가 아닙니다. 3장에서 코어 내는 데이터가 있는 곳을 뜻했습니다. 당신의 책상 위, org 자체의 개체 안. 여기서는 같은 말이 제품이 실행되는 곳을 가리킵니다. 아키텍트들은 두 가지 뜻으로 모두 씁니다.

역사적으로 Core 런타임이 플랫폼 대부분을 호스팅했습니다. 오늘 Salesforce는 수백 개의 독립적인 메타데이터 기반 서비스로 된 플랫폼을 설명하며, Core는 애플리케이션 메타데이터의 단일 기록 시스템으로 남아 있습니다(The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). 그래서 아키텍트들이 어떤 기능이 코어에서 또는 오프코어에서 돈다고 말하는 겁니다.

이것은 플랫폼이 서비스로 나뉘기 훨씬 전부터 중요했습니다. 수업에서 Salesforce가 견적용으로 왜 Apttus가 아니라 SteelBrick을 샀는지 물으면, 제가 기대하는 답은 간단합니다. SteelBrick은 100% 코어 위에 만들어졌기 때문입니다. Flow와 트리거는 코어에 있으므로, 거기서 만든 제품은 플랫폼의 메타데이터, 사용자 정의, 자동화를 함께 얻습니다. 그 견적 제품은 이후 Revenue Cloud에 자리를 내주었지만, 교훈은 그대로입니다. 그리고 **코어 인접(near-core)**이 있고, 제가 드는 예는 Data 360입니다. Data 360은 코어가 아닙니다. 그 테넌트는 오프코어입니다. 데이터와 그것을 처리하는 메커니즘은 org의 관계형 데이터베이스 안이 아니라 그 옆의 자체 레이크하우스에서 실행됩니다(The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)). 하지만 그것을 설정하고 제어하는 화면은 코어, 즉 org 안에 표시됩니다. 그래서 제가 할 수 있는 가장 정확한 표현은 이것입니다. 관리는 코어에서, 호스팅은 코어 밖에서. 데이터도 처리도 실제로는 Core에서 실행되지 않습니다. Core의 UI가 코어 밖의 테넌트를 제어할 뿐입니다. 그리고 물론, 아예 Salesforce가 아니어서 오프코어인 모든 것이 있습니다.

올해 어떤 제품이 어디서 도는지 외우는 것보다(그건 바뀌니까요) 습관이 더 중요합니다. 경계는 데이터 이동, 지연, 정체성, 연동, 레지던시에 영향을 줄 수 있습니다. 그러니 제품 이름에 Salesforce가 붙었다고 그 데이터가 당신의 계정 레코드 바로 옆에 있다고 가정하지 마십시오. 실제 아키텍처를 보십시오.

그리고 Hyperforce가 있습니다. 전통적인 자체 데이터 센터 대신 퍼블릭 클라우드용으로 만들고 코드로 정의한 Salesforce의 인프라이며, 고객에게 데이터가 있을 곳에 대한 선택권을 더 줍니다(Salesforce Hyperforce: General Information and FAQ (opens in a new tab)). 중요하고, 모듈 5에서 다시 다룹니다. 하지만 인프라 아키텍처는 기업 데이터 아키텍처가 아닙니다. org를 퍼블릭 클라우드로 옮긴다고 누가 고객을 소유하는지, 재고가 어디에 있는지, 분석이 어디서 도는지, 어떤 데이터가 국경을 넘어도 되는지 알게 되지는 않습니다. Hyperforce는 그런 결정 일부, 특히 레지던시를 형성할 수 있습니다. 랜드스케이프를 아는 것을 대신하지는 않습니다.

상자보다 랜드스케이프가 먼저다

그러니 습관은 이렇습니다. 누군가 시나리오를 건넵니다. Salesforce 해법을 만들기 시작하지 마십시오. 먼저 시스템을 찾으십시오. ERP, ID 공급자, 웨어하우스, 연동 플랫폼, 파트너 시스템, 고객 채널, 문서 저장소. 그다음 그 사이를 오가는 데이터를 찾으십시오. 고객, 제품, 주문, 청구서, 문서, 이벤트, 정체성. 그다음 각각을 누가 소유하는지 물으십시오. 그다음에야 무엇이 Salesforce에 속하는지 정하십시오. 그러지 않으면 무엇과 연결되는지도 모른 채 상자를 설계하는 것입니다.

Click to enlarge

3단계 중 1단계: 우리가 설계하는 org, 그것 하나뿐. 여기서 보면 그것이 온 세상처럼 보입니다.

Click to enlarge

3단계 중 2단계: 한 걸음 물러서 봅니다. Salesforce는 여러 시스템 중 하나입니다(이 배치는 모듈 4에서 배웁니다).

Click to enlarge

3단계 중 3단계: 첫 화살표들. 고객, 제품, 가격은 ERP에서 들어오고 주문은 나갑니다. 이 화살표들은 기업이 진실이 어디에 있다고 믿는지를 말해 줍니다.

랜드스케이프가 데이터 모델을 바꾼다

그래서 데이터 아키텍트에게 중요합니다. 2장은 고객이 중요한 엔터티라고 말합니다. 좋습니다. 그런데 랜드스케이프는 ERP가 고객에 대해 권위 있다고 말합니다. 그것이 물리 모델을 바꿉니다. 사람들이 매일 쓰니 Salesforce가 여전히 로컬 계정을 둘 수 있지만, 이제 ERP 식별자를 외부 ID로 두어야 하고, Salesforce가 어떤 필드를 바꿀 수 있는지 알아야 하며(모듈 3에서 보겠지만 저는 ERP의 필드에 erp_ 접두사를 붙입니다), ERP의 변경이 얼마나 빨리 오는지, ERP가 알기 전에 Salesforce가 고객을 만들 수 있는지, 둘이 다르면 어떻게 되는지 알아야 합니다. 나중을 위한 연동 질문이 아닙니다. 데이터 아키텍처 질문이고, 랜드스케이프가 그것을 드러냈습니다.

그중 하나가 어떻게 문제를 일으키는지 보겠습니다. 영업 담당자가 대형 음료 회사의 리드를 전환하고, 계정을 만들고, 거래를 성사시키고, 고객은 ERP로 넘어갑니다. 그런데 회사는 그 음료 회사와 몇 년째 거래해 왔고, ERP에는 이미 그 회사가 있습니다. 이제 둘이 됩니다. 영업 담당자가 애초에 그 계정을 만들 수 있었어야 할까요? 5장과 6장에서 다시 다룹니다. 그것이 다가오는 게 보이는 곳이 랜드스케이프입니다.

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

• 어떤 시스템이 Salesforce를 둘러싸고 있고, 각각 어떤 역할을 하는지.
• 중요한 각 종류의 데이터를 어떤 시스템이 소유하는지, Salesforce가 그중 얼마를 보관할지 정하기 전에.
• 무엇이 Salesforce로 들어오고, 무엇이 나가고, 무엇이 돌아오는지.
• Salesforce가 어떤 데이터를 소유하고, 복사하고, 참조하고, 연합하고, 보관하고, 내버려 둘지.
• Salesforce라는 이름이 붙은 모든 것이 한곳에 있다고 가정하지 않고, 어떤 플랫폼·인프라 경계가 중요한지.

개발자에서 아키텍트로의 전환은 대개 기능을 하나 더 배우는 게 아닙니다. 언제 Salesforce를 그만 볼지 배우는 것입니다. 카메라를 뒤로 빼고, 데이터를 따라가고, 누가 진실을 소유하는지 찾은 다음, 돌아와서 Salesforce의 일이 무엇이어야 하는지 정하십시오.

더 알아보기

• Salesforce Architects, The Salesforce Platform: Transformed for Tomorrow (opens in a new tab)(영어), 확인일 2026-10-14.
• Salesforce 도움말, Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab)(영어), 확인일 2026-10-14.