데이터 품질과 거버넌스
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 과정 5장의 학습 가이드입니다. 먼저 여섯 개 모듈을 읽으십시오. 이 페이지는 무엇이 남았는지 점검하도록 돕습니다.
이 학습 가이드에 대해. 이 과정 자체의 내용과 Salesforce가 공개한 시험 가이드의 목표 목록만으로 만들었습니다. 실제 시험 문제를 바탕으로 한 적은 결코 없으며, 시험에 무엇이 나오는지 안다고 주장하지도 않습니다. 시험을 치렀다면 문제를 보내지 말아 주십시오. 자격 인증 계약이 공유를 금지하며, 어차피 답을 외우는 것은 아키텍트가 되는 잘못된 방법입니다.
이 장은 시험의 Data Governance 영역(10%)과 Data Modeling(메타데이터), Salesforce Data Management(일관성)의 일부를 맡습니다. 개인정보 보호법이 데이터 모델을 만나는 곳이기도 합니다. 이것은 아키텍처이지 법률 자문이 아닙니다. 무엇이 적용되는지는 법무가 정하고, 아키텍트는 그것을 시행 가능하게 만듭니다. 플랫폼 숫자는 바뀌니, 기대기 전에 현재 숫자를 확인하십시오.
시험 대비
섹션 제목: “시험 대비 ”하나씩 체크하십시오. 각 항목은 그것을 가르치는 곳으로 연결됩니다.
GOV-2: 거버넌스 프로그램 설계하기
- 나는 레코드 소유자(접근을 위한 플랫폼 메커니즘)가 데이터 오너(데이터를 비즈니스 자산으로서 책임지는 사람)가 아니며, 필드마다 Data Owner를 기록할 수 있다는 것을 안다. (레코드 소유자는 데이터 오너가 아니다)
- 나는 데이터 오너(정책을 정함), 데이터 스튜어드(계속 작동하게 함), 관리 담당자(시스템을 운영함)를 구분할 수 있다. (오너, 스튜어드, 관리 담당자)
- 시험 포인트: 나는 거버넌스 프로그램을 운영하는 세 가지 방식, 중앙 집중형, 연합형(분산형), 하이브리드를 알고, 각각이 누가 정책을 정하고 공유 정의가 어디에 있는지에 어떤 의미인지 안다. (프로그램은 어떻게 운영되는가)
- 나는 RACI로 데이터가 어디서 만들어지고, 편집되고, 참조되는지에 답할 수 있다. (RACI가 제 몫을 하게 하라)
- 나는 교육만이 아니라 거버넌스 정책의 시행 지점(권한, 유효성 검사, 연동 전용 필드, 필드 기록)을 댈 수 있다. (거버넌스는 기계적이 되어야 한다)
- 나는 측정할 가치가 있는 품질 신호가 누군가 행동할 신호라는 것을 안다. (누군가 행동할 것을 측정하라)
SDM-2와 MDM-4: 나쁜 데이터 막기
- 나는 계정 생성을 열지 잠글지 정할 수 있고, ERP에서 마스터로 관리되는 계정에 대한 임시 레코드 유형 경로를 안다. (열 것인가, 잠글 것인가?, 중간 길)
- 나는 Salesforce 자체 필드는 편집 가능하게 두면서 관리되는 속성(ERP ID, 법적 이름)을 보호할 수 있다. 즉 하이브리드 골든 레코드다. 그리고 Dynamic Forms 페이지의 읽기 전용 필드는 시행이 아니며, 필드 수준 보안이나 유효성 규칙이 시행이라는 것을 안다. (관리되는 레코드를 보호하라, 흐름마다 레코드 유형 하나)
- 나는 양방향 흐름이 가장 어렵다는 것을 안다. ERP가 필드를 마스터로 관리한다면 Salesforce는 바꿔 달라고 요청하는 것이고, 충돌에는 규칙(ERP 우선, 값이 바뀌었으면 거부, 또는 사람이 해결)이 필요하다. (관리되는 레코드를 보호하라)
- 나는 필수 필드가 가짜 데이터(
N/A,999999)를 만들 수 있다는 것과 그 대안을 안다. (필수 필드가 가짜 데이터를 만들게 두지 마라) - 나는 검사를 통과하지 못한 유입 데이터를 어떻게 할지 정할 수 있다. 받기, 거부, 격리, 그리고 예외를 누가 책임지는지. (모든 데이터 경계에는 품질 결정이 필요하다)
- 나는 참조 데이터에도 메타데이터가 필요하다는 것을 안다. 정의, 오너, 원천, 시스템 간 매핑. (참조 데이터에도 메타데이터가 필요하다)
DM-3: 비즈니스·기술 메타데이터
- 시험 포인트: 나는 비즈니스 메타데이터(의미, 정의, 오너, 규칙, 민감도)와 기술 메타데이터(개체, 필드, 유형, API 이름, 스키마, 매핑, 계보)를 구분한다. (두 종류의 메타데이터)
- 나는 비즈니스 용어 사전(무엇을 뜻하는가), 계보(어디서 왔는가), 분류(어떻게 다뤄야 하는가)의 차이를 안다. (데이터를 알라)
- 나는 Salesforce의 분류 필드를 안다. 표준과 사용자 정의 필드의 Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization. (분류는 다른 질문에 답한다)
- 나는 모든 필드가 아니라 민감한 필드를 분류해야 하며, 시행 없는 분류는 장식이라는 것을 안다. (시행 없는 분류는 장식이다)
GOV-1: 개인정보와 민감 데이터
- 나는 주요 법(GDPR, CCPA/CPRA, PIPEDA, LGPD, 호주 Privacy Act, HIPAA, PCI DSS, SOX, COPPA)을 알아보며, GDPR이 EU 밖의 조직에도 미칠 수 있다는 것과 법들의 공통점, 즉 권리, 국외 이전, 침해 통지, 책임성을 안다. (알아봐야 할 규제들, 법은 국경에서 멈추지 않는다)
- 나는 암호화, 마스킹, 가명처리, 익명처리의 차이를 알고, 가명처리된 데이터가 여전히 개인정보라는 것을 안다. (익명처리, 가명처리, 암호화, 마스킹)
- 나는 덜 수집하는 것이 개인정보 통제이며, 보존은 미리 설계한다는 것을 안다. (덜 수집하는 것은 아키텍처 결정이다, 보존은 모델의 일부다)
- 나는 동의 데이터 모델을 안다. 개인에 대한 전체 동의, 참여 채널 동의, 연락 지점 동의, 데이터 사용 목적. (Salesforce가 이미 만든 모델을 써라)
- 나는 요청에 기한(GDPR: 1개월, 2개월 더 연장 가능)이 있으므로 사본 지도가 먼저 있어야 한다는 것을 안다. (시계가 돌고 있다)
- 나는 잊힐 권리가 모든 사본(기록, 아카이브, 분석, 로그, 파일, 자유 텍스트)을 찾는 것을 뜻하며, Privacy Center의 정책은 개체별로 고객 레코드에 대해 실행된다는 것을 안다. (이제 그 사람이 말한다. 저를 잊어 주세요, Privacy Center는 도구다)
- 나는 Shield Platform Encryption의 트레이드오프를 안다. 확률적으로 암호화된 필드는 SOQL에서 필터링, 그룹화, 정렬할 수 없고, 결정적 암호화는 필터링을 허용하며, 암호화된 필드는 조건 기반 공유를 이끌 수 없다. (암호화는 통제이지 규정 준수가 아니다)
- 나는 운영 환경의 민감 데이터를 샌드박스에 복사하지 말아야 하며, Data Mask가 Data Mask & Seed로 대체되고 있다는 것을 안다. (운영의 위험을 샌드박스로 복사하지 마라)
- 나는 필드 기록 추적(개체당 최대 20개 필드, 18개월, API로만 24개월, 긴 텍스트는 편집 사실만 기록)과 Field Audit Trail(최대 200개 필드, 삭제할 때까지 보관)의 차이를 안다. (이력도 데이터다)
- 나는 Event Monitoring 로그 보존 기간(추가 기능 없이 일부 이벤트 1일, 있으면 기본 30일, 연장 시 최대 365일)을 알고, 필요하기 전에 이벤트를 SIEM으로 내보내야 한다는 것을 안다. 유료 로그는 계약 시작 이전 기간의 것을 가져올 수 없다. (감사와 모니터링은 같지 않다)
시험 너머
섹션 제목: “시험 너머 ”시험은 바닥이지 천장이 아닙니다. 이것들은 시험 문제가 묻든 말든 아키텍트에게 필요한, 이 장의 습관입니다.
- 시행 지점이 없는 정책은 대개 희망 사항이다.
- 오너는 정책을 정하고, 아키텍트는 그것을 시행한다. 정책을 지어내지 말고, 변호사 흉내를 내지 마라.
- 거버넌스는 결코 끝나지 않는다. 밀물과 썰물처럼 오가니, 피드백을 설계하라.
- 좋은 행동에 기대지 마라. 통제를 만들어라. 사람, 연동, 에이전트 모두 실수한다.
- 모든 것이 아니라 충분히 관리하라.
- 비용이 큰 오류부터 막아라. 2년치 이력이 쌓인 중복은 큰 문제다.
- 사람이 읽는 것과 기계가 그것으로 결정하는 것을 구분하라.
- 문서화는 넓게, 분류는 신중하게.
- 관리하기 가장 싼 민감 데이터는 복사하지 않은 데이터다.
- 동의는 데이터이며, 데이터를 쓸 수 있는 허락은 데이터로 표현될 수 있어야 한다.
- 먼저 개인정보가 어디로 가는지 통제하라. 삭제는 드물고 어려우니까.
- 규정 준수는 제품이 아니다.
- 수집 → 분류 → 보호 → 사용 → 보존 → 삭제 → 감사.
- 누가 묻기 전에 증거를 수집하라.
알아야 할 용어
섹션 제목: “알아야 할 용어 ”| 용어 | 한 줄 설명 |
|---|---|
| 데이터 거버넌스 | 데이터에 관한 정책, 그리고 그것을 사실로 만드는 아키텍처 |
| 데이터 오너 | 한 종류의 데이터를 책임지는 사람이나 조직 |
| 데이터 스튜어드 | 데이터를 매일 건강하게 유지하는 사람 |
| 관리 담당자 | 데이터를 담은 시스템을 운영하는 팀 |
| RACI | 실행(Responsible), 책임(Accountable), 자문(Consulted), 통보(Informed) |
| 임시 레코드 | 권위 있는 시스템이 받아들이기 전에 만든 레코드 |
| 비즈니스 용어 사전 | 비즈니스의 중요한 용어에 대한 합의된 정의 |
| 계보 | 값이 어디서 왔고 그 과정에서 무슨 일이 있었는지 |
| 데이터 분류 | 데이터가 올바른 통제를 받도록 민감도와 규정 준수 범주로 표시하기 |
| 분류 체계 | 조직이 데이터를 분류하는 데 쓰는 레이블 묶음 |
| 개인정보 | 사람을 식별하거나 사람에게 다시 연결될 수 있는 정보 |
| 가명처리 | 되돌아갈 길이 남은 채로 식별자를 바꾸는 것. 여전히 개인정보 |
| 익명처리 | 그 사람을 식별할 합리적 가능성을 없애는 것 |
| 동의 데이터 모델 | 사람, 채널, 연락 지점, 목적별 동의를 위한 Salesforce 개체들 |
| 잊힐 권리 | 법이 인정하는 경우, 자기 개인정보를 삭제받을 권리 |
| 하이브리드 골든 레코드 | 마스터 시스템의 필드와 Salesforce 자체 필드를 함께 가진 레코드 하나. 필드마다 원천은 하나 |
| 비즈니스 / 기술 메타데이터 | 데이터가 무엇을 뜻하고 누가 소유하는가 / 어떻게 만들어지고 이동하는가 |
| Field Audit Trail | 더 긴 필드 기록: 개체당 최대 200개 필드, 삭제할 때까지 보관 |
| Event Monitoring | 로그인, 내보내기, API 호출, 조회 기록. 제한된 기간 보관 |
| SIEM | 이벤트 로그를 보관하고 분석하는 보안 저장소 |
스스로 점검하기
섹션 제목: “스스로 점검하기 ”과정의 스타일로 쓴 짧은 시나리오입니다. 열어 보기 전에 답을 정하십시오.
1. 정책은 고객의 법적 이름을 재무만 바꿀 수 있다고 합니다. 팀은 그것을 교육에서 다룰 계획입니다. 무엇이 빠졌을까요?
시행 지점입니다. 교육은 통제가 아닙니다. 필드 수준 접근, 연동만 쓰는 필드, 유효성 규칙, 또는 통제된 프로세스를 쓰십시오. 오너가 정책을 정하고, 아키텍트가 그것을 기계적으로 사실로 만듭니다. 거버넌스는 기계적이 되어야 한다를 다시 읽으십시오.
2. 고객은 ERP에서 마스터로 관리됩니다. 영업 담당자들은 새 잠재 고객에게 바로 판매를 시작해야 합니다. 두 시스템이 마스터 레코드를 만들지 않게 하면서 어떻게 허용할까요?
영업 담당자가 임시 레코드 유형으로 계정을 만들게 하고, 통제된 프로세스로 전환하십시오. 재무가 승인하거나, 연동이 ERP에 제출하고 ERP가 고객을 매칭하거나 만들어 권위 있는 ID를 돌려보냅니다. 중간 길을 다시 읽으십시오.
3. 새 필수 필드가 “N/A”와 “999999”로 채워집니다. 무슨 일이 있었고, 대신 무엇을 하겠습니까?
사용자가 알기 전에 답하도록 강요받았습니다. 프로세스 후반에 필수로 하거나, 다른 시스템이 공급하게 하거나, 임시 상태를 쓰거나, 정말 답이 될 수 있다면 명시적인 알 수 없음을 허용하십시오. 필수 필드가 가짜 데이터를 만들게 두지 마라를 다시 읽으십시오.
4. 팀이 이름을 토큰으로 바꾸고 데이터가 익명처리되었으니 삭제 요청이 끝났다고 합니다. 그럴까요?
토큰을 그 사람에게 다시 연결할 수 있다면 아닙니다. 그것은 가명처리이고, 데이터는 여전히 개인정보입니다. 시스템이 정확히 무엇을 하는지, 매핑이 어디 있는지 말하고, 그것이 요구사항을 충족하는지는 법무가 판단하게 하십시오. 익명처리, 가명처리, 암호화, 마스킹을 다시 읽으십시오.
5. 수령인이 배송 문자에는 동의하지만 마케팅에는 동의하지 않습니다. 모델은 그것을 어떻게 담아야 할까요?
체크박스 하나가 아니라 동의 데이터 모델로. 사람, 채널(SMS), 특정 번호, 데이터 사용 목적(마케팅이 아닌 배송 알림). 그리고 철회가 그것에 따라 행동하는 모든 시스템에 닿도록, 어느 시스템이 동의의 기준 시스템인지 정하십시오. Salesforce가 이미 만든 모델을 써라를 다시 읽으십시오.
6. 규정 준수 팀이 암호화된 사회보장번호 필드로 보고서를 필터링해야 합니다. 그 필드는 기본 암호화 방식을 씁니다. 무엇이 문제일까요?
확률적 암호화는 SOQL WHERE 절이나 데이터 관리 필터에서 필터링을 허용하지 않습니다. 결정적 암호화는 강도를 조금 대가로 치르고 필터링을 허용합니다. 암호화는 마지막에 체크하는 상자가 아니라 트레이드오프가 있는 설계 결정입니다. 암호화는 통제이지 규정 준수가 아니다를 다시 읽으십시오.
7. 사고 6개월 뒤 누군가 어떤 레코드들을 누가 내보냈는지 묻습니다. 아무도 Event Monitoring 저장소를 설정하지 않았습니다. 무엇을 말해 줄 수 있을까요?
아마 아무것도 없습니다. 이벤트 로그는 제한된 기간만(연장해도 최대 1년) 보관되니, 내보내지 않았다면 그보다 오래된 것은 사라집니다. 필요하기 전에 Event Monitoring을 설정하고 이벤트를 SIEM으로 보내십시오. 감사와 모니터링은 같지 않다를 다시 읽으십시오.
8. 영업 담당자가 ERP가 마스터로 관리하는 고객의 법적 이름을 바꿔 달라고 Salesforce에서 요청합니다. 같은 몇 분 사이에 누군가 ERP에서 그것을 바꿉니다. 설계는 무엇을 말해야 할까요?
Salesforce는 바꾼 것이 아니라 요청한 것입니다. 그 필드는 ERP가 마스터로 관리합니다. 충돌 규칙(ERP 우선, 값이 바뀌었으면 거부, 또는 사람이 해결)과 관련 필드를 함께 보낼지를 미리 정하십시오. 관리되는 레코드를 보호하라를 다시 읽으십시오.
9. 한 사람의 삭제 요청이 도착합니다. 팀은 그 사람의 데이터가 어디 있는지 지도를 그리기 시작하려 합니다. 무엇이 문제일까요?
시계는 이미 돌고 있습니다. GDPR에서는 1개월이고, 복잡한 요청은 2개월 더 연장할 수 있습니다. 사본 지도는 요청이 오기 전에 있어야 합니다. 시계가 돌고 있다를 다시 읽으십시오.
더 알아보기
섹션 제목: “더 알아보기 ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce 도움말(영어, 확인일 2026-09-25): 공식 목표 목록과 그 비중. 시험을 예약하기 전에 항상 최신 버전을 확인하십시오.
- 각 모듈의 더 알아보기 섹션에는 그 사실의 근거가 된 Salesforce 문서와 법이 확인 날짜와 함께 나와 있습니다.