통합과 데이터 이동
19개 언어로도 제공
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Data Architect 과정 9장의 학습 가이드입니다. 먼저 네 개 모듈을 읽으십시오. 이 페이지는 무엇이 남았는지 점검하도록 돕습니다.
이 학습 가이드에 대해. 이 과정 자체의 내용과 Salesforce가 공개한 시험 가이드의 목표 목록만으로 만들었습니다. 실제 시험 문제를 바탕으로 한 적은 결코 없으며, 시험에 무엇이 나오는지 안다고 주장하지도 않습니다. 시험을 치렀다면 문제를 보내지 말아 주십시오. 자격 인증 계약이 공유를 금지하며, 어차피 답을 외우는 것은 아키텍트가 되는 잘못된 방법입니다.
시험 가이드는 통합 도구 구성을 시험하지 않는다고 말하고, 이 장은 Integration Architect 과정이 아니라 데이터 아키텍트를 위한 맛보기입니다. 시험이 신경 쓰는 것은 통합이 데이터에 무엇을 하는지입니다. 키, 쓰기 권한, 볼륨과 완전성, 그리고 org 사이를 움직이는 데이터. 플랫폼 숫자는 바뀌니, 의지하기 전에 최신 값을 확인하십시오.
시험 대비
섹션 제목: “시험 대비 ”하나씩 체크하십시오. 각 항목은 그것을 가르치는 곳으로 연결됩니다.
화살표 이전에(LDV-1, SDM-2 뒷받침)
- I zoom out to the landscape, then zoom in on one arrow and ask its data questions: initiator, direction, freshness, volume and shape, key, write authority, and who proves it arrived. (Zoom In on One Arrow) ⟲
- 누가 개시하는지와 데이터가 어느 방향으로 흐르는지를 분리하고, 왕복 전체를 보는 것은 클라이언트뿐이라는 것을 압니다. (누가 시작하는지와 데이터 방향은 다릅니다)
- I treat freshness as a requirement, not a default, and match the timing to the mechanism: a synchronous call when the caller waits, platform events for fire and forget, Change Data Capture to keep another system in step, the Bulk API for large scheduled loads. (How Current Does It Need to Be?) ⟲
- I know a database stores; a process calls: polling needs a process, often middleware, and polling for nothing is waste. Change Data Capture has a daily delivery allocation, counted per subscriber. (Asking Every Minute) ⟲
- I know Salesforce’s guidance for pulling changes on a schedule:
getUpdated()andgetDeleted()for intervals over 5 minutes; more often than that, let Salesforce send the change. (Asking Every Minute) ⟲ - I know the three traffic shapes, singles, sets and bulk; that more than 2,000 records is a good candidate for Bulk API 2.0, fewer for bulkified synchronous calls such as Composite; and to send only the fields that changed. (The Number of Zeros Applies to Integrations Too) ⟲
- I know integration volume becomes data volume: ownership, automation, sharing and storage. (Integration Volume Becomes Data Volume) ⟲
키와 쓰기 권한(SDM-2, SDM-4, MDM-2 뒷받침)
- I carry an external system’s key in an External ID field marked Unique, one-to-one, and upsert on it: no match creates, one match updates, more than one fails. (One Record, One Key) ⟲
- When one customer has several external records, I add records, not fields (a hierarchy, peers or a child object), never a key field per ERP. (When the Customer Is in Two ERPs, chapter 6: One Customer, Two ERPs) ⟲
- I know one key field with the source in the value is still one key per record, and a new partner is a new value, not a new field. (Steve Trucking: One Field, the Source in the Value) ⟲
- 안정적인 키가 재시도를 안전하게 만든다는 것(멱등성의 시작)을 압니다. (키가 재시도를 안전하게 만듭니다)
- I know a key isn’t authority, and enforce write authority in the org: record types, read-only fields for users, and an integration user with only the access its contract needs. (A Key Isn’t Authority) ⟲
- I know two-way movement still has one owner per field, and how unclear authority causes loops. (Two-Way Movement, One Owner per Field) ⟲
- 한 Salesforce org의 레코드 ID는 다른 org에서 기업 키가 아니라는 것, 즉 org 둘은 시스템 둘이라는 것을 압니다. (키에도 수명 주기가 있습니다)
Proof of delivery (supports MIG-1 and MIG-2) ⟲
- I know the client owns the conversation, and whoever knows what should arrive proves that it did; the server keeps its own promises and reports what it received. (Who Proves It Arrived?) ⟲
- I know “no errors” isn’t completeness: reconcile counts and, where it matters, control totals. (“No Errors” Isn’t Completeness) ⟲
- I design for restart and safe retries, and log every call: request ID, endpoint, response code and duration. (Know Where You Are, and Restart Gracefully, Log Every Call, Retries Are Normal; Make Them Safe) ⟲
- I know platform events and Change Data Capture events stay on the bus for 72 hours, subscribers resume by Replay ID, duplicates can happen, and proof needs my own return receipt. (The Return Receipt) ⟲
- I know the soft landing for partial failure, and I send the increment, not the universe. (Partial Failure, and the Soft Landing, Send the Increment, Not the Universe) ⟲
- I know the four shapes: request and reply, fire and forget, batch and events, and where each recovers. (Four Shapes of Integration) ⟲
- I know outbound messaging is supported but gets no further investment, and since Spring ‘26 sends no session ID. (Outbound Messaging: Know It, Don’t Start There) ⟲
통합 데이터 계약(SDM-4 뒷받침)
- I can write an integration data contract for an arrow, eleven lines: initiator, direction, freshness, volume and shape, key, write authority, pattern, mechanism, proof of delivery, sensitivity and travel, and change. (An Arrow Needs More Than a Label) ⟲
- I go requirement, then pattern, then mechanism. (Requirements, Then Pattern, Then Mechanism) ⟲
- I know when to give another team a custom Apex REST endpoint instead of the standard APIs (one stable interface, my own logging and orchestration) and what it costs (code to maintain; API and Apex limits still apply). (A Contract Between Teams) ⟲
- I count every place the data rests on its way, logs and retry queues included, when it has to stay in a country. (Make Each Line Specific) ⟲
- For multiple orgs, I start with a contract per movement, and sometimes the contract says don’t move it (chapter 14). (Multiple Orgs, and “Don’t Move It”) ⟲
Where the rest lives. This chapter is about moving data. Not moving it (Salesforce Connect, mashups, data brought in on demand, zero copy: exam objective LDV-3) is chapter 14, Virtualization, Federation, and Zero-Copy (coming soon). Loading and extracting at volume is chapter 10, Migration and Synchronization. ⟲
시험 너머
섹션 제목: “시험 너머 ”시험은 바닥이지 천장이 아닙니다. 이것들은 시험 문제가 묻든 말든 아키텍트에게 필요한, 이 장의 습관입니다.
- Zoom out, then zoom in. Start with the landscape; then take one arrow at a time. ⟲
- 다가오는 트래픽을 이해하십시오, 다른 사람이 통합을 설계하더라도요.
- 이동을 이해한 뒤에 메커니즘을 고르십시오.
- A database stores; a process calls. Someone has to own the process. ⟲
- 데이터 이동은 공짜가 아닙니다. 모든 사본은 관리할 곳이 하나 더 생기는 것입니다.
- Add records, not fields. ⟲
- 레코드를 아십시오. 소유자를 아십시오. 그다음 통합이 쓰게 하십시오.
- Whoever knows what should arrive proves that it did. ⟲
- 조용히 실패할 수 있다면 완성된 것이 아닙니다. 멈춘 통합은 데이터 품질 문제입니다.
- 권한은 “할 수 있다”를 말하고, 아키텍처는 “해야 한다”를 말합니다.
- Decide the interface between teams in the first weeks: the standard API or a wrapper you own. ⟲
- 계약은 기술보다 오래 삽니다.
- 에이전트의 모든 행동을 통합으로 다루십시오, 키, 권한, 멱등성, 관측 가능성과 함께.
알아야 할 용어
섹션 제목: “알아야 할 용어 ”| 용어 | 한 줄 설명 |
|---|---|
| 개시자 | 대화를 시작하는 시스템(클라이언트) |
| 데이터 방향 | 누가 시작하든, 비즈니스 데이터가 움직이는 방향 |
| Freshness | How current the data must be |
| Polling | Asking on a schedule whether anything changed |
| 단건, 묶음, 대량 | 한 번에 레코드 하나, 작은 묶음, 또는 작업 하나에 담긴 큰 볼륨 |
| 외부 ID | Salesforce 레코드에 저장해 매칭에 쓰는 다른 시스템의 키 |
| Upsert | 맞는 레코드가 있으면 갱신하고, 없으면 생성하는 것 |
| 멱등성 | 의도하지 않은 추가 효과 없이 작업을 반복하는 것 |
| 워터마크 / 체크포인트 | 통합이 안전하게 어디까지 왔는지에 대한 기록 |
| 대사 | 의도한 것과 도착한 것을 비교하는 것 |
| Proof of delivery | Evidence, held by the side that knows what should arrive, that it did |
| Return receipt | An acknowledgment sent back to say a message was received and processed |
| Request and reply | The client sends and waits for the answer |
| Fire and forget | The client sends without waiting for the outcome |
| 플랫폼 이벤트 | 구독자를 위해 Salesforce 이벤트 버스에 게시되는 메시지 |
| Change Data Capture | 레코드가 바뀔 때 Salesforce가 게시하는 이벤트 |
| Replay ID | 구독자가 이벤트 읽기를 재개할 때 쓰는 위치 |
| Custom Apex REST | Your own REST endpoint in Salesforce, written in Apex, in front of your objects |
| 통합 데이터 계약 | 통합이 데이터에 무엇을 해도 되는지에 대한 짧은 기록 |
스스로 점검하기
섹션 제목: “스스로 점검하기 ”과정의 스타일로 쓴 짧은 시나리오입니다. 열어 보기 전에 답을 정하십시오.
1. Salesforce가 ERP를 호출해 고객의 신용 상태를 가져옵니다. 데이터는 어느 방향으로 흐르고, 누가 개시하나요?
Salesforce가 개시하고, 데이터는 ERP → Salesforce로 흐릅니다. 개시자와 방향은 별개의 질문이고, 왕복 전체를 보는 것은 개시자(클라이언트)입니다. 누가 시작하는지와 데이터 방향은 다릅니다를 다시 읽으십시오.
2. 팀이 GPS 판독값마다 Salesforce 레코드를 만들자고 제안합니다. 하루 20만 건입니다. 먼저 무엇을 묻겠습니까?
왜 1년에 판독값 7,300만 건을 트랜잭션 모델에 넣나요? 통합 결정이기 전에 데이터 아키텍처 결정입니다. org에는 최신 위치만 필요할 수 있습니다. 통합 볼륨이 데이터 볼륨이 됩니다를 다시 읽으십시오.
3. A warehouse team says, "Snowflake will just poll Salesforce every minute." What's missing?
⟲A database stores; a process calls. Something has to run the polling (usually an integration layer), with its own credentials, schedule and failures, and 1,440 calls a day mostly find nothing. Ask how current the data must be, then consider letting Salesforce send the changes (Change Data Capture), and count the events. Reread Asking Every Minute.
4. An external system needs Salesforce's changes about every hour, including deletions. What does Salesforce's own guidance suggest?
⟲For intervals over 5 minutes, the SOAP API’s getUpdated() and getDeleted() return what changed and what was deleted in a window, instead of a full extract. More often than that, let Salesforce send the change. Reread Asking Every Minute.
5. The ERP retries a "create customer" call after a timeout and Salesforce ends up with two accounts. How should it have been designed?
⟲Upsert on the ERP’s customer number in an External ID field marked unique, so a retry matches the existing record instead of inserting a duplicate. Reread Keys Make Retries Safe.
6. The customer exists in two ERPs, and someone proposes `NA_ERP_ID__c` and `EMEA_ERP_ID__c` on the Account. Your view?
⟲That’s a key field per ERP: an anti-pattern. It hides repeating structure in fields and turns every new ERP into a schema change. Add records, not fields: child accounts, peer accounts, or a child object per ERP record, each with one key. Reread When the Customer Is in Two ERPs.
7. The integration log shows zero errors, but finance totals don't match. What happened, and who should have caught it?
⟲Zero errors isn’t completeness: maybe fewer records were sent than intended, or values changed in transit. The side that knows what should have arrived proves it did: it reconciles counts and control totals against what it meant to send. Reread Who Proves It Arrived?.
8. A subscriber to platform events was down for a day. Can it catch up?
⟲Yes, within the 72-hour retention: it resumes from its last Replay ID. It must also handle duplicates, because the same event can arrive twice. Reread The Return Receipt.
9. The requirement says "we need a REST integration for credit holds." What's wrong with that?
⟲REST is a mechanism, not a requirement. The requirement is something like “agents see a credit hold within five minutes of the ERP change.” Start there, choose the pattern, then the mechanism, and write the contract. Reread Requirements, Then Pattern, Then Mechanism.
10. A partner's middleware team will send orders that touch four objects, and your data model changes every release. Standard API or custom Apex REST?
⟲It depends on the team. If they know Salesforce deeply and can change quickly, the standard APIs work. If not, a custom Apex REST endpoint gives them one stable interface, lets Salesforce orchestrate the four writes and log every call, and absorbs your changes inside. The cost is code you maintain, inside Salesforce’s API and Apex limits. Decide in the first weeks. Reread A Contract Between Teams.
더 알아보기
섹션 제목: “더 알아보기 ”- Salesforce Certified Platform Data Architect Exam Guide (새 탭에서 열림), Salesforce Help (checked 2026-11-01): the official list of objectives and their weights. Always check the current version before you book the exam. ⟲
- Salesforce, Best Practices for Deployments with Large Data Volumes (새 탭에서 열림), Winter ‘27 (last updated September 18, 2026), checked 2026-11-01: the guide behind the exam’s Large Data Volumes section. Its integration rules are in module 1; its mashups are in chapter 14. ⟲
- 각 모듈의 더 알아보기 섹션에는 그 사실의 근거가 된 Salesforce 문서가 확인 날짜와 함께 나와 있습니다.