데이터 아키텍트처럼 생각하기
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 과정 1장의 학습 가이드입니다. 먼저 일곱 개 모듈을 읽으십시오. 이 페이지는 무엇이 남았는지 점검하도록 돕습니다.
이 학습 가이드에 대해. 이 과정 자체의 내용과 Salesforce가 공개한 시험 가이드의 목표 목록만으로 만들었습니다. 실제 시험 문제를 바탕으로 한 적은 결코 없으며, 시험에 무엇이 나오는지 안다고 주장하지도 않습니다. 시험을 치렀다면 문제를 보내지 말아 주십시오. 자격 인증 계약이 공유를 금지하며, 어차피 답을 외우는 것은 아키텍트가 되는 잘못된 방법입니다.
이 장은 시험에 나올 사실이 적은데, 의도된 것입니다. 이 장은 아키텍트가 어떻게 생각하는지를 다루며, 어떤 시험 목표도 이 장에만 속하지 않습니다. 하지만 시험은 시나리오로 구성됩니다. 하나의 비즈니스, 몇 가지 숫자, 하나의 제약, 그리고 모두 통할 수 있는 여러 답. 이 장의 습관이 그 시나리오를 읽는 방법입니다. 그래서 아래 체크리스트는 각 항목이 직접 출제된다고 주장하는 대신 어떤 목표를 뒷받침하는지 표시합니다.
시험 대비
섹션 제목: “시험 대비 ”하나씩 체크하십시오. 각 항목은 그것을 가르치는 곳으로 연결됩니다.
아키텍트처럼 시나리오 읽기 (모든 목표를 뒷받침)
- 나는 진짜 요구사항을 그것이 담겨 온 설계와 분리한다(“승인자 2와 승인자 3 필드가 필요하다”와 “모든 승인을 추적해야 한다”). (요구사항을 그냥 받아들이지 말라)
- 나는 아무도 말하지 않은 암묵적 요구사항을 찾는다: 소유권, 최신성, 실패, 보존, 접근. (암묵적 요구사항을 찾아라)
- 나는 숫자를 붙인다: 하루, 1년, 성장을 반영한 볼륨. 그리고 0 하나가 더 붙어 답이 바뀌는 순간을 알아차린다. (숫자를 알라)
- 작동하는 여러 답 중에서, 나는 주어진 요구사항과 제약에 비추어 각각이 얻는 것과 포기하는 것을 비교한다. (무엇을 내주는지 알라, 제약이 답을 바꾼다)
- 나는 비용, 라이선스, 한계를 나중의 문제가 아니라 도구가 맞는지의 일부로 본다. (아홉 가지 질문)
데이터 모델 (DM-1을 뒷받침)
- 나는 모델이 비즈니스를 지원하는지, 함께 성장할 수 있는지, 성능을 내는지로 판단할 수 있다. (지원. 성장. 성능.)
- 나는 너무 평평한 모델(필드 1, 필드 2, 필드 3), 과도하게 정규화된 모델, 잘못된 표준 개체 위에 세운 모델을 알아볼 수 있다. (너무 평평하거나, 너무 복잡하거나, 그냥 틀리거나)
- 나는 선택 목록이 짧고 안정적인 목록에, 조회 관계가 계속 늘어나거나 연동으로 들어오는 목록에 맞는 이유를 안다. (문제를 푸는 많은 방법)
- 나는 의미를 담은 키(예를 들어 이름의 일부)가 그 의미가 바뀌면 깨진다는 것을 안다. (어떤 결정은 바꾸는 비용이 적다)
이미 있는 것을 바꾸기 (DM-1과 SDM-2를 뒷받침)
- 나는 필드의 유형을 바꾸거나 기존 필드를 필수로 만드는 것이 왜 나중에 문제를 일으킬 수 있는지, 그리고 코드나 Flow가 필드를 참조하는 동안 플랫폼이 왜 유형 변경을 막는지 안다. (뼈대를 바꿀 때는 조심하라)
- 나는 바꾸기보다 추가하라, 놀라게 하기보다 폐기 예고를 하라라는 패턴을 알고, Field Usage로 필드를 폐기 후보로 표시할 수 있다는 것을 안다. (뼈대를 바꿀 때는 조심하라)
- 나는 가역성 테스트 뒤에 있는 마스터-세부 사항의 사실들을 안다: 세부 사항의 접근과 소유권은 마스터를 따르고, 마스터를 삭제하면 세부 사항도 삭제되며, 롤업 요약에는 마스터-세부 사항이 필요하고, 조회 관계는 모든 레코드에 값이 있을 때만 마스터-세부 사항으로 변환된다. (가역성 테스트, 더 알아보기)
라이선스와 공유 (SDM-1을 뒷받침)
- 나는 대량 커뮤니티 사용자(Customer Community 포함)에게 역할이 없고 공유 모델을 쓰지 않으므로, 접근이 공유 세트와 공유 그룹에서 오고 Apex 공유가 그들에게 닿지 못한다는 것을 안다. (풀이 예시: Apex 공유)
실패 (MIG-1과 연동 장들을 뒷받침)
- 나는 “작업 완료”가 데이터가 정확하다와 같지 않다는 것, 그리고 대사로 도착하지 못한 레코드를 찾는 방법을 안다. (부분적인 성공도 이해해야 할 실패다)
시험 너머
섹션 제목: “시험 너머 ”시험은 바닥이지 천장이 아닙니다. 이것들은 시험 문제가 묻든 말든 아키텍트에게 필요한, 이 장의 습관입니다.
- 누군가는 설계도를 쥐고 있어야 한다. 아키텍처는 불완전한 정보로 좋은 결정을 내리고 그 결과를 아는 것이다.
- 데이터 모델은 뼈대다. 나머지는 모두 그 위에 세워진다.
- 가역성 테스트: 되돌리기가 얼마나 어렵고, 얼마나 많은 것이 그것에 의존하게 될까?
- 아키텍처는 중력을 만든다. 변화 자체가 아니라 의존성이 변화를 비싸게 만든다.
- 폭발 반경을 생각하라. Salesforce 안에서도, 기업 전체에서도. 아키텍처는 양방향 통행이다.
- 이유를 기록하라: 맥락, 선택지, 결정, 결과, 책임자, 검토. 지우지 말고 대체하라.
- 무엇에서 최고인가? 알고 내린다면, 최적이 아닌 결정도 최적의 아키텍처의 일부일 수 있다.
- 최적의 그림을 갖고 다녀라. 그래야 어느 방향으로, 왜 멀어지는지 안다.
- Think Correct. Think Fast. 속도는 그 순간 이전에 해 둔 생각에서 나온다.
- 오늘을 위해 만들라. 내일을 계획하라. 실패를 계획하라. 그리고 아무도 숫자를 주지 않으면 30퍼센트 성장을 써라.
- 답만이 아니라 아홉 가지 질문을 배워라.
- AI는 로켓 부스터다. 생성은 판단이 아니고, 되돌릴 수 없는 것은 여전히 되돌릴 수 없으며, 인간의 검토는 의례가 아니다. 신뢰하되 검증하라.
알아야 할 용어
섹션 제목: “알아야 할 용어 ”| 용어 | 한 줄 설명 |
|---|---|
| 아키텍처적 결정 | 되돌리기 어렵고 많은 것이 의존하는 결정 |
| 가역성 테스트 | 되돌리기가 얼마나 어렵고, 얼마나 많은 것이 의존하게 될까? |
| 중력 | 시간이 지나며 결정 주위에 모여드는 의존성 |
| 폭발 반경 | 결정이 바뀔 때 함께 움직이는 다른 모든 것 |
| 의사결정 기록 | 맥락, 선택지, 결정, 결과, 책임자, 검토 시점을 짧게 담은 기록 |
| 트레이드오프 | 선택지가 얻는 것과, 그것을 얻으려고 포기하는 것 |
| 암묵적 요구사항 | 적재 실패 시 복구처럼, 비즈니스가 묻지 않고도 기대하는 것 |
| 스티브의 0의 개수 | 볼륨에 0 하나가 더 붙으면 아키텍처 전체가 바뀔 수 있다 |
| 대사(reconciliation) | 일어났어야 할 일과 실제로 일어난 일을 레코드 단위로 비교하기 |
| 폐기 예고(deprecate) | 무언가를 제자리에서 바꾸는 대신 퇴역 예정으로 표시한 뒤 신중하게 퇴역시키기 |
| 대량 사용자 | 역할이 없고 공유 모델 밖에 있는 커뮤니티 사용자(라이선스 중 Customer Community 포함) |
| 스키마 난립 | 만들기 싸다는 이유로 쌓여, 결국 아무도 설계하지 않은 모델이 된 개체와 필드 |
스스로 점검하기
섹션 제목: “스스로 점검하기 ”과정의 스타일로 쓴 짧은 시나리오입니다. 열어 보기 전에 답을 정하십시오.
1. 영업팀이 기회에 승인자 2와 승인자 3 필드를 각각 날짜와 함께 달라고 합니다. 무엇을 묻고, 무엇을 만들 수 있을까요?
왜인지, 그리고 승인이 몇 건까지 될 수 있는지 물으십시오. 두세 건보다 많아질 수 있다면 요구사항은 필드 추가가 아니라 모든 승인을 추적하는 것입니다. 승인 하나당 레코드 하나인 하위 개체입니다. 요구사항을 그냥 받아들이지 말라를 다시 읽으십시오.
2. 누군가는 필드 레이블 이름을 바꾸고 싶어 하고, 다른 누군가는 다섯 시스템이 이미 저장하고 있는 고객 식별자의 형식을 바꾸고 싶어 합니다. 어느 쪽에 더 주의를 기울여야 하며, 왜일까요?
식별자입니다. 레이블은 바꾸는 비용이 적습니다. 식별자는 가역성 테스트를 통과하지 못합니다. 되돌리기 어렵고, 이미 많은 것이 의존하고 있습니다. 틀렸을 때의 비용에 비례해 주의를 기울이십시오. 어떤 결정은 바꾸는 비용이 적다를 다시 읽으십시오.
3. 텍스트 필드 하나가 몇 년째 쓰이고 있습니다. 이제 비즈니스는 거기에 숫자를 담고 싶어 합니다. 어떻게 접근하겠습니까?
제자리에서 바꾸지 마십시오. 무엇이 그것에 의존하는지(Flow, Apex, 보고서, 연동, 에이전트)와 옛 데이터가 어떻게 되는지 찾으십시오. 보통은 새 필드를 추가하고, 신중하게 마이그레이션하고, 옛 필드를 폐기 예정으로 둡니다. 뼈대를 바꿀 때는 조심하라를 다시 읽으십시오.
4. 지점 1,200곳, 지점당 하루 예약 100건, 연간 약 305일, 예약당 레코드 2개, 5년 보관, 30퍼센트 성장. 레코드는 대략 몇 건이며, 그것이 왜 중요할까요?
첫해에 약 7,300만 건(예약 3,660만 건, 예약당 2건), 성장을 반영하면 5년 동안 6억 5,000만 건이 넘습니다. 같은 기능, 0이 두어 개 더, 전혀 다른 아키텍처. 숫자를 알라를 다시 읽으십시오.
5. 야간 적재가 레코드 100만 건에 대해 “완료”를 보고합니다. 제대로 됐는지 어떻게 알까요?
대사를 합니다. 받는 쪽이 저장한 레코드마다 확인을 보내고, 보내는 쪽이 보낸 것과 확인된 것을 비교합니다. 확인이 빠졌다면 작업 상태가 뭐라고 하든 제대로 된 것이 아니며, 어떤 레코드를 재시도하고, 사람에게 넘기고, 경고할지 알려 줍니다. 부분적인 성공도 이해해야 할 실패다를 다시 읽으십시오.
6. Customer Community 사용자 1,500만 명의 커뮤니티에 복잡한 레코드 접근이 필요합니다. 누군가 Apex 공유를 제안합니다. 무엇이 문제일까요?
그들은 대량 사용자입니다. 역할이 없고 공유 모델 밖에 있으므로, Apex가 쓸 공유 레코드가 없습니다. 접근은 공유 세트와 공유 그룹에서 옵니다. 어떤 공유 도구가 존재하는지는 라이선스가 정했습니다. 풀이 예시: Apex 공유를 다시 읽으십시오.
7. AI 도구가 새 앱을 위해 몇 분 만에 개체 스무 개를 생성합니다. 이제 아키텍트의 일은 무엇일까요?
다섯 개면 되는지 결정하는 것입니다. 모델을 변호할 수 있을 만큼 이해하는 것입니다. 왜 이 개체들과 관계들인지, 키와 마스터 데이터는 어디에 있는지, 규모가 커지면 어떻게 되는지. 그것이 의존한 사실을 검증하는 것입니다. 생성은 판단이 아닙니다. 값싼 구현은 가치를 옮긴다를 다시 읽으십시오.
더 알아보기
섹션 제목: “더 알아보기 ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-09-25): 공식 목표 목록과 그 비중. 시험을 예약하기 전에 항상 최신 버전을 확인하십시오.