기업 데이터 이해하기
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)

Data Architect 과정 4장의 학습 가이드입니다. 먼저 여섯 개 모듈을 읽으십시오. 이 페이지는 무엇이 남았는지 점검하도록 돕습니다.
이 학습 가이드에 대해. 이 과정 자체의 내용과 Salesforce가 공개한 시험 가이드의 목표 목록만으로 만들었습니다. 실제 시험 문제를 바탕으로 한 적은 결코 없으며, 시험에 무엇이 나오는지 안다고 주장하지도 않습니다. 시험을 치렀다면 문제를 보내지 말아 주십시오. 자격 인증 계약이 공유를 금지하며, 어차피 답을 외우는 것은 아키텍트가 되는 잘못된 방법입니다.
시험 가이드는 Salesforce가 아닌 데이터베이스 개념은 출제하지 않는다고 하며, 이 장의 대부분은 Salesforce를 둘러싼 기업에 관한 것입니다. 그래서 1장처럼 이 체크리스트는 각 항목이 어떤 목표를 뒷받침하는지 표시합니다. 하지만 건너뛰지 마십시오. 많은 시험 시나리오가 ERP, 웨어하우스, 두 번째 org로 시작하며, 답은 누가 데이터를 소유하느냐에 달려 있습니다.
시험 대비
섹션 제목: “시험 대비 ”하나씩 체크하십시오. 각 항목은 그것을 가르치는 곳으로 연결됩니다.
누가 데이터를 소유하는가 (SDM-2, SDM-3, 마스터 데이터 장을 뒷받침)
- 나는 각 종류의 데이터에 대해 어느 시스템이 기록 시스템인지 말할 수 있고, 문장을 끝맺는다. 무엇에 대한 기록 시스템인가? (Salesforce는 흔히 기록 시스템이 아니다, 제품 이름에서 시작하지 마라)
- 나는 흔한 패턴을 안다. 고객, 제품, 가격은 ERP에서 들어오고, 주문은 나간다. 그리고 주문 화살표가 다른 화살표에 의존한다는 것을 안다. 그다음 돌아오는 길을 묻는다. (제가 거듭 보는 연동, 한 방향 화살표는 저를 불안하게 한다)
- 나는 마스터 데이터에 세 가지 질문을 던진다. 어디서 생성되는가, 어디서 편집되는가, 어디서 참조되는가? (범주 뒤의 네 가지 질문)
- 나는 사본은 권위가 아니라는 것을 안다. ERP 소유 데이터는 로컬에서 읽고 통제 아래 쓰며, ERP 식별자는 외부 ID로 둔다. (ERP: 백오피스에는 중력이 있다, 랜드스케이프가 데이터 모델을 바꾼다)
데이터의 종류와 워크로드 (DM-1, LDV-1, MDM-4를 뒷받침)
- 나는 마스터, 참조, 트랜잭션, 메타데이터, 분석, 비정형 데이터를 구분하고, 각각이 그 데이터가 있을 곳에 무엇을 뜻하는지 안다. (개체가 아니라 종류에서 시작하라)
- 나는 참조 데이터가 작지만 연동의 가정이 숨는 곳이라는 것을 안다(
Delivered,Complete,D). (참조 데이터) - 나는 운영(OLTP), 분석(OLAP), 스트리밍 워크로드를 구분할 수 있다. org는 비즈니스를 돌리고, 웨어하우스와 레이크는 그것을 분석한다. (종류는 질문의 절반일 뿐이다)
- 나는 동기(문 앞에서 기다리기), 비동기(계속 일하다 돌아오면 처리하기), 배치(매시간, 몇 시간마다, 매일)를 구분하고, 언제 배치로 충분한지, 그리고 실시간에는 비용이 있다는 것을 안다. (얼마나 빨리 움직여야 하는가?)
- 나는 모든 데이터 세트에 네 가지 질문을 던진다. 누가 소유하는가, 얼마나 빨리 변하는가, 얼마나 커지는가, 생명주기는 무엇인가. (범주 뒤의 네 가지 질문)
Salesforce를 둘러싼 시스템 (SDM-3, LDV-3, 연동 장들을 뒷받침)
- 나는 네 가지 시스템 역할을 안다. 기록, 참여, 참조, 인사이트. (제품 이름에서 시작하지 마라)
- 나는 분석이 사는 곳은 데이터가 사는 곳을 따른다는 것을 안다. 모두 Salesforce에 있으면 코어 보고서, 다른 저장소가 얽히면 분석 플랫폼(Tableau Next를 포함한 Tableau, 또는 이미 쓰고 있다면 CRM Analytics)이나 웨어하우스. (분석은 데이터가 사는 곳에 산다)
- 나는 웨어하우스, 레이크, 레이크하우스가 무엇인지, 그리고 MDM, ESB나 iPaaS, 이벤트의 역할을 안다. (웨어하우스, 레이크, 레이크하우스, 연동 층과 이벤트)
- 나는 첫날부터 랜드스케이프에 ID 공급자를 그리고, SSO 구성은 배포되지만 비밀 키와 인증서는 따라가지 않는다는 것을 안다. 랜드스케이프에서 그것은 호출이 아니라 공유 인증서(신뢰)다. 로그인은 브라우저를 거치기 때문이다. (개발자가 잊는 시스템: 정체성)
- 나는 Data 360이 코어 인접(near-core)(관리는 코어에서, 호스팅은 코어 밖에서)이라는 것, 그리고 그 제로 카피로 데이터를 복사하지 않고 조회할 수 있다는 것을 안다. (Data 360은 어디에 두는가?, 코어, 오프코어, Hyperforce)
org와 호스팅 (SDM-4를 뒷받침)
- 나는 org 하나로 시작하고, 또 하나를 더하기 전에 진짜 경계(레지던시, 규제, 법적 분리, 다른 운영 모델, 인수)를 찾는다. (org 하나로 시작하라, 진짜 경계를 찾아라)
- 나는 org가 여럿일 때의 비용을 안다. 글로벌 보고, 마스터 데이터, 연동, 정체성, 배포가 각각 곱해진다. (화살표를 다시 따라가라)
- 나는 Hyperforce가 org의 데이터가 있을 지역(클라우드 공급자가 아니라)을 고르게 해 주지만 모든 서비스가 거기 머문다고 약속하지는 않는다는 것을 안다. 그리고 GDPR 자체가 별도의 org를 요구하지는 않는다는 것도 안다. GDPR은 EU 밖으로 나가는 개인정보에 대한 규칙을 정하고, 회사는 그것을 충족하려고 유럽 org를 선택할 수 있다. (호스팅은 그림의 일부다, 유럽이 자체 org를 가질 때)
랜드스케이프 그리기와 읽기 (모든 시나리오를 뒷받침)
- 나는 랜드스케이프를 그릴 수 있다. 왼쪽에 사람, 가운데에 Salesforce와 그 아래에 맞닿은 커뮤니티, 위에 정체성, 오른쪽에 연동과 백오피스, 연동 층 아래에 Data 360, 아래에 채널, 오른쪽 아래에 데이터 입출력. (스티브의 랜드스케이프 배치)
- 랜드스케이프에서 화살표는 연결을 여는 시스템에서 시작하고, 레이블은 무엇이 어느 방향으로 움직이는지 말한다. 데이터 흐름 다이어그램에서는 화살표가 데이터를 따른다. 흐름 둘은 화살표 둘이다. (이제 화살표를 그려라)
- 나는 모든 화살표에 대해 클라이언트가 처리하는 것과 서버가 정의하는 것을 안다. 위치, 인증, 프로토콜과 계약, 페이로드, 타이밍, 추적, 오류. Salesforce가 호출해 나갈 때는 이름 지정된 자격 증명과 그 외부 자격 증명, 무언가가 Salesforce를 호출할 때는 외부 클라이언트 앱과 API 전용 연동 사용자. (모든 화살표에는 메커니즘이 필요하다)
- 나는 화살표를 그리기 전에 센다. 볼륨은 목록에 들어가 메커니즘을 이끌고, 화살표가 가리키는 방향까지 바꿀 수 있다. (0을 목록에 넣어라)
- 나는 프로세스에 주고받기가 한두 번보다 많을 때만 스윔 레인을 그린다. (랜드스케이프에는 화살표를, 대화는 스윔 레인에)
시험 너머
섹션 제목: “시험 너머 ”시험은 바닥이지 천장이 아닙니다. 이것들은 시험 문제가 묻든 말든 아키텍트에게 필요한, 이 장의 습관입니다.
- org를 설계하기 전에 랜드스케이프를 그려라. 빈 캔버스에서 시작하라.
- 카메라를 뒤로 빼라. Salesforce는 여러 시스템 중 하나다.
- 새 물결이 옛 물결을 사라지게 하는 일은 드물다. 브로슈어가 아니라 실재하는 기업을 설계하라.
- 랜드스케이프를 로고가 아니라 책임으로 읽어라.
- 한 방향 화살표는 저를 불안하게 한다. 이 흐름은 무엇에 의존하고, 무엇이 돌아오는가?
- 모든 화살표에는 메커니즘이 필요하다. “보내고 잊기”는 답이 아니다.
- 랜드스케이프에는 화살표를, 대화는 스윔 레인에.
- 화살표를 그리기 전에 세라. 0은 목록에 들어가고, 메커니즘을 고른다.
- 고치기 전에 현재 상태를 그려라: 스프레드시트, SFTP 드롭, “퇴역 중인” 시스템까지.
- 현재 상태를 정직하게 표시하라. 나쁜 프로세스는 빨간색, 손으로 하는 일은 파선, 빠진 것은 빨간 점선. 모든 빨간 선은 쓰이기를 기다리는 요구사항이다.
- 흐름 둘, 화살표 둘. 양쪽 화살표는 커넥터에만 쓴다.
- 변호사 흉내를 내지 마라. 정확히 어떤 요구사항을 충족하는지 묻고, 그것을 소유한 사람들과 함께 번역하라.
- 분리는 단순함과 같지 않다.
알아야 할 용어
섹션 제목: “알아야 할 용어 ”| 용어 | 한 줄 설명 |
|---|---|
| 시스템 랜드스케이프 | Salesforce를 둘러싼 시스템, 그것을 쓰는 사람들, 그리고 그 사이의 중요한 흐름 |
| 기록 시스템 | 한 종류의 데이터의 권위 있는 버전이 보관되는 곳 |
| 참여 시스템 | 사람들이 일하는 곳 |
| 참조 시스템 | 한 시스템이 필요하지만 소유하지 않는 정보를 찾아보는 곳 |
| 인사이트 시스템 | 측정하고, 분석하고, 예측하려고 데이터가 모이는 곳 |
| ERP | 재무, 제품, 재고, 구매, 주문 처리를 위한 백오피스 시스템 |
| 마스터 데이터 | 비즈니스가 그것을 중심으로 돌아가는 지속적인 것들: 고객, 제품, 장소 |
| 참조 데이터 | 다른 데이터를 분류하는 공유 어휘: 코드, 상태, 범주 |
| 트랜잭션 데이터 | 일어난 일의 기록: 주문, 배송, 결제, 케이스 |
| 분석 데이터 | 측정하고 비교하려고 다른 데이터에서 만든 데이터 |
| 비정형 데이터 | 문서, 이미지, 오디오, 동영상, 녹취록 |
| 데이터 웨어하우스 / 레이크 / 레이크하우스 | 정형 분석 저장소 / 대규모 원시 저장소 / 둘의 혼합 |
| ESB / iPaaS | 시스템 사이를 중재하는 연동 층 |
| OLTP / OLAP | 한 번에 몇 건의 레코드를 다루는 운영 작업 / 여러 레코드를 아우르는 분석 |
| 코어 인접(near-core) | 관리는 코어에서, 호스팅은 코어 밖에서: Data 360 |
| 이름 지정된 자격 증명 / 외부 자격 증명 | Salesforce가 나가는 엔드포인트를 보관하는 곳 / 그 인증 |
| 외부 클라이언트 앱 | 외부 시스템이 Salesforce를 호출하도록 권한을 받는 방식 |
| 현재 상태 | 설계 이전, 오늘 있는 그대로의 랜드스케이프. 무엇이 잘못됐는지 표시한다 |
| ID 공급자(IdP) | 사용자를 인증하고 Salesforce가 신뢰하는 정체성을 확립하는 시스템 |
| 동기 / 비동기 / 배치 | 답을 기다림 / 계속 일하다 답이 오면 처리함 / 일정에 따라 데이터를 묶음으로 옮김 |
| Hyperforce | 지역을 선택할 수 있는 퍼블릭 클라우드 인프라 위의 Salesforce |
| 제로 카피 | 데이터를 복사하지 않고 있는 곳에서 조회하기 |
스스로 점검하기
섹션 제목: “스스로 점검하기 ”과정의 스타일로 쓴 짧은 시나리오입니다. 열어 보기 전에 답을 정하십시오.
1. 영업 담당자는 Salesforce에서 계정을 다루지만, 고객이 구매하면 ERP가 공식 고객 번호를 발급합니다. Salesforce는 주문을 ERP에 보냅니다. 무엇을 설계해야 할까요?
각 단계에서 누가 고객을 소유하는지, 계정에 외부 ID로 둘 ERP 번호, Salesforce가 바꿀 수 있는 필드, ERP 변경이 오는 속도, 그리고 주문을 보낸 뒤 무엇이 돌아오는지(수락, 거부, 출하, 청구). 랜드스케이프가 데이터 모델을 바꾼다를 다시 읽으십시오.
2. 경영진이 재무와 결합한 5년치 지역별 정시 성과를 원합니다. Salesforce 보고서로 만들까요?
아마 아닙니다. 여러 저장소에 걸친 분석 워크로드이니, 데이터가 모이는 곳, 즉 그 위에 CRM Analytics나 Tableau를 얹은 웨어하우스에 속합니다. 분석이 사는 곳은 데이터가 사는 곳을 따릅니다. 분석은 데이터가 사는 곳에 산다를 다시 읽으십시오.
3. 30개국에서 사업하는 회사가 나라마다 org 하나를 요청합니다. 무엇을 묻겠습니까?
각 나라와 함께 어떤 요구사항이 오는지. 저장, 처리, 국외 이전, 계약, 다른 호스트. 진짜 경계가 없다면 org 하나로 시작하십시오. org가 하나 늘 때마다 보고, 마스터 데이터, 연동, 정체성, 배포가 곱해집니다. 지리가 자동으로 org 전략이 되지는 않는다를 다시 읽으십시오.
4. 트럭들이 하루에 GPS 데이터 20만 건을 보냅니다. Salesforce가 전부 저장해야 할까요?
아마 아닙니다. 스트리밍 데이터입니다. 배차 담당자에게는 현재 위치가 필요하고, 이력과 추세는 그 볼륨을 위해 만든 플랫폼에 속합니다. 0을 세고(1년에 7,000만 건 넘음), “지금 어디인가?”와 “지난 분기에 무슨 일이 있었나?”를 분리하십시오. 종류는 질문의 절반일 뿐이다를 다시 읽으십시오.
5. 배송팀은 Salesforce에서 정차지를 처리하지만, 경로는 레거시 배차 도구에서 만들어지고 둘을 잇는 것이 없습니다. 오늘을 어떻게 그리겠습니까?
있는 그대로, 현재 상태로 표시해서 그립니다. Salesforce로 다시 입력하는 경로와 되돌려 입력하는 완료된 정차지를, 사람이 하니 파선으로, 잘못됐으니 빨간색으로. 있었으면 하는 연동을 그리지 마십시오. 모든 빨간 선은 설계의 요구사항이 됩니다. 잘못된 것을 표시하라와 RouteDesk는 아직 거기 있다를 다시 읽으십시오.
6. 누군가 유럽 개인정보 보호법 때문에 org를 분리해야 한다고 말합니다. 어떻게 답하겠습니까?
그대로 받아들이지도, 뒤집지도 마십시오. GDPR 자체가 별도의 org를 요구하지는 않습니다. EU 밖으로의 이전을 포함해 개인정보에 대한 규칙을 정합니다. 그것이 정확히 어떤 요구사항(저장, 처리, 이전, 지원 접근, 계약, 정책)을 충족하는지 묻고, 개인정보, 법무, 보안과 함께 그것을 아키텍처로 바꾸십시오. 변호사 흉내를 내지 마라와 유럽이 자체 org를 가질 때를 다시 읽으십시오.
7. Salesforce가 ERP의 API로 주문을 보냅니다. 재시도는 어느 쪽이 처리하고, Salesforce는 비밀 키를 어디에 보관합니까?
Salesforce가 클라이언트입니다. 연결을 열고, 왕복 전체를 보며, 재시도할 수 있는 유일한 쪽입니다. 이름 지정된 자격 증명이 엔드포인트를, 그 외부 자격 증명이 인증을 보관합니다. 서버인 ERP는 계약을 정의하고 들어오는 것을 검증합니다. 모든 화살표에는 메커니즘이 필요하다를 다시 읽으십시오.
8. 어떤 연동이 오늘은 1분에 레코드 두어 건을 보내는데, 비즈니스는 내년에 한 시간에 수만 건을 예상합니다. 화살표가 바뀔까요?
메커니즘이, 어쩌면 방향까지 바뀔 수 있습니다. 1분에 몇 건이면 Salesforce의 콜아웃으로 충분합니다. 훨씬 더 많다면 다른 시스템이 구독하는 이벤트를 발행해야 할 수 있고, 그러면 화살표는 반대쪽 끝에서 시작합니다. 하룻밤에 수백만 건이면 배치입니다. 고르기 전에 수를 아십시오. 0을 목록에 넣어라를 다시 읽으십시오.
더 알아보기
섹션 제목: “더 알아보기 ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-09-25): 공식 목표 목록과 그 비중. 시험을 예약하기 전에 항상 최신 버전을 확인하십시오.
