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장인 기업 데이터 이해하기의 모듈 3/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 기업 데이터의 종류 · 다음: 시스템 랜드스케이프를 그려라

이 모듈이 답하는 질문: Salesforce를 둘러싼 것은 무엇이며, 각 시스템은 어떤 역할을 할까요?

지난 모듈에서 데이터를 분류했습니다. 이제 그것을 어딘가에 두고 싶은데, 여기서 Salesforce 아키텍트들이 곤란해집니다. 우리는 Salesforce를 아니까 고객 데이터는 계정, 주문 데이터는 주문, 문서는 파일, 분석은 보고서가 됩니다. 하지만 기업이 자기가 가진 다른 모든 것을 대체하려고 Salesforce를 산 것은 아닙니다. 재무와 주문 처리를 돌리는 ERP, 수년치 이력을 가진 웨어하우스, 연동 플랫폼, ID 공급자, 파트너 시스템, 이벤트 플랫폼, MDM 플랫폼, 그리고 그중 여럿을 잇는 Data 360이 있을 수 있습니다. 일은 기술을 외우는 것이 아닙니다. 각 시스템이 어떤 일을 맡고 있는지 이해하는 것입니다.

제품 이름에서 시작하지 마라

“SAP가 있어요”는 충분히 말해 주지 않습니다. Snowflake, MuleSoft, Tableau, Data 360도 마찬가지입니다. 저는 그 시스템이 이 아키텍처에서 무엇을 하는지 알고 싶습니다. 어떤 데이터를 소유하고, 무엇을 읽고, 무엇을 바꾸고, 누가 쓰고, 무엇이 그것에 의존하고, 다운되면 어떻게 되는지. 두 회사가 정확히 같은 제품을 갖고도 전혀 다른 아키텍처를 가질 수 있습니다.

그래서 저는 시스템에 역할로 레이블을 붙입니다. 네 가지 역할이 대부분을 다룹니다.

• 기록 시스템(system of record): 무언가의 권위 있는 버전이 유지되는 곳.
• 참여 시스템: 사람들이 일하는 곳.
• 참조 시스템: 한 시스템이 필요하지만 소유하지 않는 정보를 얻으러 가는 곳.
• 인사이트 시스템: 측정하고, 분석하고, 예측하려고 데이터가 모이는 곳.

플랫폼 하나가 여러 역할을 할 수 있고, 역할은 데이터마다 다릅니다. Salesforce는 케이스의 기록 시스템, 서비스 상담원의 참여 시스템, 그리고 ERP가 소유한 제품 데이터의 소비자일 수 있습니다. 그러니 누군가 “Salesforce가 우리의 기록 시스템이에요”라고 하면 문장을 끝맺으십시오. 무엇에 대한 기록 시스템인가?

ERP: 백오피스에는 중력이 있다

ERP는 Salesforce 옆에서 가장 자주 만나는 시스템으로, 재무, 재고, 구매, 주문 처리, 청구를 운영합니다. 모듈 1의 패턴(고객과 제품은 들어오고, 주문은 나간다)은 ERP가 제품을 소유하지만 영업 담당자는 여전히 Salesforce에서 그것이 필요하다는 뜻입니다. 좋습니다. 들여오십시오. 하지만 데이터를 복사한다고 소유권이 옮겨 가지는 않습니다. 사본은 권위가 아닙니다.

제 입장은 이렇습니다. ERP 소유 데이터는 로컬에서 읽고 통제 아래 쓴다. Salesforce 사용자는 일하는 곳에서 데이터를 얻지만, Salesforce가 ERP가 소유한 것을 바꿀 수는 없습니다. 그리고 저는 그것을 스키마에서 보이게 합니다. ERP의 필드에는 erp_Product_Number__c처럼 erp_ 접두사가 붙어, 개체를 읽는 누구나 각 필드의 소유자를 알고 바꿀 때 조심해야 한다는 걸 압니다. 접두사가 무언가를 강제하지는 않습니다. 그건 권한, 유효성 검사, 연동 패턴이 합니다. 의도를 전달하며, 기준 시스템 맵을 눈에 보이게 만든 것입니다.

웨어하우스, 레이크, 레이크하우스

운영 시스템은 비즈니스를 돌리고, 분석 시스템은 비즈니스를 이해하도록 돕습니다. “내 미결 기회를 보여 줘”는 Salesforce 보고서입니다. “모든 채널에 걸친 5년치 매출, 처리, 반품, 케이스, 재고, 재무를 보여 줘”는 다른 문제입니다.

분석 저장소는 세 종류를 만나게 됩니다. 데이터 웨어하우스는 분석을 위해 준비된 정형 데이터를 담습니다. 데이터 레이크는 훨씬 많은 데이터를 더 다양한 형태로, 흔히 원시 상태로 담습니다. 레이크하우스는 둘을 합칩니다. 레이크식 저장에 웨어하우스식 분석. 랜드스케이프에 나오니 알아 두십시오. 하지만 제 경험으로는 Salesforce 프로젝트에서 레이크하우스와 데이터 메시는 아직 틈새입니다. 전형적인 랜드스케이프는 CRM, ERP, 웨어하우스, 연동 층이고, 비즈니스가 정말 필요로 하는 곳에 다른 플랫폼이 있습니다. 아키텍처를 배우십시오. 어휘를 쫓지 마십시오.

분석은 데이터가 사는 곳에 산다

제 가장 확고한 입장 중 하나입니다. 분석이 사는 곳은 데이터가 사는 곳을 따른다. 보고서에 계정, 기회, 영업 담당자만 필요하다면 모두 코어 내에 있습니다. 표준 보고서와 대시보드. 그러다 비즈니스가 ERP 청구서를 추가해 달라고 합니다. 그다음 제품 원가. 그다음 웨어하우스의 5년치 주문. 그다음 웹사이트 활동. 어느 시점에 그 모든 것을 보고만을 위해 운영 CRM으로 끌어오는 것은 말이 안 됩니다. 다른 데이터 저장소가 얽히면 분석 플랫폼이 필요해집니다. Tableau(Data 360 위에 만든 Tableau Next 포함), 또는 이미 쓰고 있다면 CRM Analytics. Salesforce 데이터를 웨어하우스와 합칠 때는 필수입니다. 요구사항이 더 복잡해진 것만이 아닙니다. 랜드스케이프가 질문에 답해야 할 곳을 바꾼 것입니다. 그래서 저는 결코 “어떤 분석 도구?”로 시작하지 않습니다. **데이터가 어디에 있는가?**로 시작합니다.

CTA 후보자들에게도 같은 것을 묻습니다. “내 다이어그램 중 어느 것이 이걸 멋지게 풀어 주지? 랜드스케이프.” 모두 코어 내에 있다면 보고서를 쓰십시오. 다른 저장소에 데이터가 있다면 저는 분석 플랫폼을 보고 싶습니다. 랜드스케이프는 누가 보고서 빌더를 열기도 전에 보고 질문에 답합니다. (제품 이름은 바뀝니다. Salesforce의 분석이 오늘 어디에 있는지는 Data 360 장에서 다룹니다.)

MDM: 이 고객은 정말 누구인가?

이제 고객 정보가 Salesforce, ERP, 이커머스, 로열티 플랫폼, 파트너 시스템에 있고, 각자 고객이 누구인지 안다고 생각한다고 합시다. 여기서 마스터 데이터 관리가 등장합니다. 핵심 데이터의 권위 있는 정체성을 시스템 전반에서 확립하고 관리하는 것입니다. 하지만 MDM은 “마스터 고객 데이터베이스”가 아닙니다. 어려운 질문은 어느 시스템이 고객을 만들 수 있는지, 각 시스템이 어떤 속성을 소유하는지, 중복을 어떻게 찾는지, 어떤 식별자가 살아남는지, 시스템들이 다를 때 어떻게 되는지입니다. 6장이 전부 그 이야기입니다. 여기서는 역할을 알아보십시오. MDM 플랫폼이 있다면 그것이 Salesforce와 나머지 기업 사이의 중요한 권한 원천일 수 있습니다.

연동 층과 이벤트

모든 시스템을 다른 모든 시스템에 직접 연결하면 랜드스케이프는 금세 스파게티가 됩니다. 그래서 기업에는 연동 층이 있습니다. ESB(enterprise service bus)나 iPaaS(integration platform as a service). Salesforce 랜드스케이프에서 가장 많이 만나는 것은 MuleSoft입니다. 중재를 하므로, 각 애플리케이션이 다른 모든 애플리케이션을 이해할 필요가 없습니다.

하지만 가운데에 MuleSoft 상자가 있다고 연동이 좋아지지는 않습니다. 저는 여전히 무엇이 그것을 거치고 무엇이 거치지 않는지, 누가 데이터를 변환하는지, 누가 계약을 소유하는지, 목적지가 다운되면 어떻게 되는지, 동기인지 비동기인지, 메시지가 성공했는지 어떻게 아는지 알고 싶습니다. Integration Architect 과정이 깊이 다룹니다. 여기서는 그것을 별도의 역할로 알아보십시오.

그리고 모든 연동이 시스템 A가 시스템 B를 호출하는 것은 아닙니다. 때로는 무언가 일어나고(주문이 생성되고, 배송 상태가 바뀌고, 트럭이 어떤 지역에 들어가고), 이벤트가 발행되고, 관심 있는 쪽이 반응합니다. 움직이는 이벤트에도 인프라가 있습니다. Salesforce 자체 이벤트 기능, 전사 이벤트 버스, 기타 메시징. 데이터베이스만이 아니라 데이터를 나르는 메커니즘을 그리십시오.

개발자가 잊는 시스템: 정체성

랜드스케이프에 늘 두고 싶은데 개발자들이 거의 생각하지 않는 상자가 하나 있습니다. ID 공급자입니다. 개발자들은 사용자 이름과 비밀번호로 곧장 샌드박스에 로그인하니, 구축하는 동안 정체성은 보이지 않습니다. 그러다 UAT나 운영 환경이 오면 갑자기 직원용 회사 SSO, 어쩌면 파트너용 두 번째 공급자, 고객용 소셜 로그인이 있습니다. 정체성은 늘 아키텍처의 일부였습니다. 개발자가 아직 보지 못했을 뿐입니다.

ID 공급자(IdP)는 사용자를 인증하고 Salesforce가 신뢰하는 정체성을 확립하는 시스템입니다. 릴리스 파이프라인 후반에 구성되더라도 첫날부터 랜드스케이프에 있어야 합니다. 누가 들어올 수 있는지가 누가 데이터에 닿을 수 있는지를 정하기 때문입니다.

실무적인 함정도 있습니다. ID 구성은 배포할 수 있지만, 완전히는 아닙니다. SAML SSO 구성과 인증 공급자는 메타데이터 API 유형이라 파이프라인을 따라 이동합니다(SamlSsoConfig (opens in a new tab)). 하지만 인증 공급자의 consumer secret은 더 이상 메타데이터 API 응답에 포함되지 않으며(Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)), 인증서는 보통 환경마다 다릅니다. 이동하는 부분과 이동하지 않는 부분을 계획하십시오.

Click to enlarge

랜드스케이프를 로고가 아니라 역할로 읽으십시오. 각 시스템이 무엇을 소유하고, 무엇을 읽고, 무엇을 결정하는지.

Data 360은 어디에 두는가?

Data 360은 좋은 그리기 질문을 던집니다. 저는 그것을 오른쪽의 ESB나 MuleSoft 아래에 둡니다. 이유는 연결 관계입니다. 사용자는 결코 그것에 직접 연결하지 않고, 그것은 많은 백엔드 시스템에 직접 연결합니다. 그러니 사용자 쪽이 아니라, 그 선들이 짧게 유지되는 데이터 배관과 함께 있어야 합니다. 사람들이 로그인하는 또 하나의 화면처럼 그리면 잘못된 이야기를 하는 것입니다.

관리자와 데이터 팀이 Data 360의 화면을 열기는 하지만, 그 화면은 org 안, 즉 코어 내에 있습니다. 실제 일을 하는 테넌트, 그 데이터와 처리는 오프코어에서 실행됩니다. 그래서 저는 그것을 코어 인접(near-core): 관리는 코어에서, 호스팅은 코어 밖에서라고 부릅니다(용어는 모듈 1에서 설명합니다). 그림은 테넌트를 따릅니다. 배관과 함께 두고, 그것을 관리하는 org로 돌아가는 선 하나를 긋습니다.

Salesforce의 말로 하면, 그것이 하는 일에는 제로 카피가 포함됩니다. 기업이 데이터를 복사하지 않고 접근하고 조회하게 해 주는 데이터 연합 기술입니다(Zero Copy (opens in a new tab)). 기능과 커넥터가 빠르게 바뀌므로, 이 모듈을 제품 투어로 만들지 않고 Data 360 장에서 제대로 다룹니다.

랜드스케이프를 책임으로 읽어라

랜드스케이프를 볼 때 로고를 읽지 말고 책임을 읽으십시오. ERP: 무엇을 소유하는가? 웨어하우스: 어떤 질문에 답하는가? 연동 플랫폼: 무엇을 옮기는가? IdP: 누구를 인증하는가? MDM: 어떤 정체성을 관리하는가? Data 360: 무엇을 무엇을 위해 잇는가? Salesforce: 실제로 무엇을 책임지는가? 거기에 답할 수 있으면 상자가 의미를 갖고, 그 사이의 화살표가 훨씬 흥미로워집니다. 다음에는 그것들을 의도적으로 그립니다.

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

• 제품 이름을 넘어 각 시스템이 어떤 역할을 하는지.
• 중요한 각 데이터 세트에 대해 어느 시스템이 권위 있고, Salesforce가 어디서 로컬 사본만 갖는지.
• ERP 소유 데이터를 쓰기는 통제한 채 Salesforce에서 쓸 수 있게 할지, 그리고 그 소유권이 스키마에 어떻게 드러나는지.
• 데이터가 사는 곳에 따라 분석이 어디에 속하는지.
• 정체성, 연동, 이벤트, 마스터 데이터 권한이 랜드스케이프의 어디에 있는지.

사각형 열 개짜리 랜드스케이프는 아키텍처가 아니라 재고 목록입니다. 아키텍처는 모든 사각형을 가리키며 그것이 왜 거기 있는지, 무엇을 소유하는지, 누가 쓰는지, Salesforce가 그것에게서 무엇이 필요한지, 그 역할을 오해하면 무엇이 깨지는지 말할 수 있을 때 시작됩니다.

더 알아보기

• Salesforce Developers, Metadata API Developer Guide, SamlSsoConfig (opens in a new tab)(영어), 확인일 2026-10-14.
• Salesforce 도움말, Winter ‘23 Release Notes, Metadata API Responses No Longer Include Authentication Provider Consumer Secrets (opens in a new tab)(영어), 확인일 2026-10-14.
• Salesforce, Zero Copy (opens in a new tab)(제품 페이지, 영어), 확인일 2026-10-14.
• Zhamak Dehghani, How to Move Beyond a Monolithic Data Lake to a Distributed Data Mesh (opens in a new tab), martinfowler.com(영어), 2019.