콘텐츠로 이동

오너는 정책을 정하고, 아키텍트는 그것을 시행한다

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장, 파트 1: 데이터 아키텍트 되기. 이전: 기업 데이터 이해하기.

“데이터 거버넌스”라고 하면 사람들은 회의를 떠올립니다. 위원회, 정책, 아무도 읽지 않는 문서. 저는 매번 다른 질문을 합니다. 그 정책은 어디서 시행되는가?

정책이 법적 고객명은 재무만 바꿀 수 있다고 한다면, 다른 사람이 바꾸는 것을 무엇이 막습니까? 배송팀은 수령인의 주소를 자기 정차지에 대해서만, 그날에만 본다고 한다면, 무엇이 그것을 사실로 만듭니까? 7년간 보관하라고 한다면, 7년 뒤 무엇이 그것을 지웁니까? 시행 지점이 없는 정책은 대개 희망 사항입니다. 제 입장은 단순합니다. 오너는 정책을 정하고, 아키텍트는 그것을 시행한다. 데이터 오너가 결정하고, 아키텍트가 설계한 시스템이 그것을 기계적으로 사실로 만듭니다.

그리고 끝날 거라고 기대하지 마십시오. 거버넌스는 결코 끝나지 않습니다. 밀물과 썰물처럼 오가며 최악의 나쁜 데이터를 막아 냅니다. Salesforce가 혼자 있을 때는 단순하고, 4장에서 그린 랜드스케이프의 한 노드일 때는 더 어렵고 더 필요합니다. 그래서 그 장이 먼저 왔습니다. 랜드스케이프가 거버넌스가 얼마나 멀리 닿아야 하는지 알려 줍니다.

재무 책임자가 데이터 정책을 설명하는 동안 아키텍트가 각 정책을 시행하는 수단, 즉 유효성 검사, 공유, 보존을 핀으로 꽂고 있다

AI로 생성한 이미지입니다.

  • 회사가 일하는 방식대로 프로그램을 운영하라: 중앙 집중형, 연합형, 하이브리드. 아키텍트는 누가 정책을 승인하는지 알아야 한다.
  • 레코드 소유자는 데이터 오너가 아니다. 소유자 필드는 배정과 접근을 이끌고, 데이터에 대한 책임은 비즈니스에 있다.
  • 생성을 열지 잠글지는 데이터를 둘러싼 거버넌스에 달려 있다. 대부분의 중소 org는 열어 두어도 괜찮고, 계정이 ERP에서 마스터로 관리되거나 ERP와 동기화된다면 잠근다. 중간 길은 관리되는 유형으로 통제된 전환을 거치는 임시 레코드 유형이다.
  • ERP가 필드를 마스터로 관리한다면, 그것을 바꾸는 게 아니라 바꿔 달라고 요청하는 것이다. 골든 레코드는 하이브리드다. ERP의 마스터 필드는 들어오고, Salesforce 자체 필드는 절대 돌아가지 않으며, 양방향 흐름에는 충돌 규칙이 필요하다.
  • 모든 필드가 아니라 민감한 필드를 분류하라. 문서화는 넓게, 분류는 신중하게. 비즈니스 메타데이터와 기술 메타데이터를 모두 유지하라.
  • 규제를 가르쳐라. 많은 아키텍트가 자기 지역 밖의 법을 들어 본 적이 없고, 그 법들이 시스템 설계를 형성한다.
  • 가능하면 기본 제공 동의 모델을 써라. 다시 만들지 말고.
  • 잊힐 권리를 위해 먼저 개인정보가 어디로 가는지 통제하라. 삭제는 드물고 어렵다. 개인정보가 적은 곳에만 닿도록 설계한 다음, 기한이 끝나기 전에 모든 사본을 찾아내라. 필드 기록, 아카이브, 분석용 사본, 검색 인덱스, 에이전트 대화.
  • Shield는 저장 데이터 암호화 같은 핵심 규제 요건의 답이다. 설계로 감당할 트레이드오프와 함께.
  • 규제 대상이면 Field Audit Trail. 기본은 표준 필드 기록이다.
  • Event Monitoring은 필요하기 전에 설정하고, 이벤트를 Splunk 같은 저장소로 스트리밍하라. 문제가 터진 뒤에야 그것을 수집하고 있지 않았다는 걸 알게 되어서는 안 된다.
관리되는 데이터 생명주기 관리되는 데이터 생명주기의 일곱 단계와 단계마다의 질문, Salesforce 메커니즘 예시. 수집: 들여도 될 만큼 좋은가? 유효성 규칙, 중복 규칙, 필수 필드, 품질 관문. 모듈 2. 분류: 얼마나 민감한가? 민감도, 규정 준수, 오너를 위한 데이터 분류 필드. 모듈 3. 보호: 누가 보고 바꿀 수 있는가? 공유, 권한, 필드 접근, Shield 암호화, 샌드박스 마스킹. 모듈 6. 사용: 이 사용은 허용되는가? 동의 모델, 데이터 사용 목적, 연동과 에이전트의 접근. 모듈 5. 보존: 얼마나 오래 보관하는가? 보존 정책, 아카이브, 빅 개체. 모듈 6. 삭제: 끝에는 어떻게 되는가? Privacy Center, 삭제 작업, 비식별화. 모듈 5. 감사: 증명할 수 있는가? 필드 기록, Field Audit Trail, SIEM으로 보내는 Event Monitoring. 모듈 6. 아래: 도구는 정책을 뒷받침할 뿐, 정책을 정하지 않는다. 단계 질문 SALESFORCE 메커니즘 예시 다루는 곳 1 · 수집 들여도 될 만큼 좋은가? 유효성 규칙, 중복 규칙, 필수 필드, 품질 관문 모듈 2 2 · 분류 얼마나 민감한가? 데이터 분류 필드: 민감도, 규정 준수, 오너 모듈 3 3 · 보호 누가 보고 바꿀 수 있는가? 공유, 권한, 필드 접근, Shield 암호화, 샌드박스 마스킹 모듈 6 4 · 사용 이 사용은 허용되는가? 동의 모델, 데이터 사용 목적, 연동과 에이전트의 접근 모듈 5 5 · 보존 얼마나 오래 보관하는가? 보존 정책, 아카이브, 빅 개체 모듈 6 6 · 삭제 끝에는 어떻게 되는가? Privacy Center, 삭제 작업, 비식별화 모듈 5 7 · 감사 증명할 수 있는가? 필드 기록, Field Audit Trail, SIEM으로 보내는 Event Monitoring 모듈 6 도구는 정책을 뒷받침할 뿐, 정책을 정하지 않습니다. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

데이터의 일생에 걸친 일곱 가지 질문. 도구는 정책을 뒷받침할 뿐, 정책을 정하지 않습니다.

여섯 개 모듈, 각각 독립적으로 읽을 수 있습니다.

  1. 거버넌스는 org 안에 설계된다. 오너, 스튜어드, 관리 담당자. 중앙 집중형, 연합형, 하이브리드. 레코드 소유자와 데이터 오너. 모든 정책을 시행 지점으로 바꾸기.
  2. 나쁜 데이터 막기. 비즈니스가 정의하는 ‘충분히 좋음’. 열린 생성과 잠긴 생성, 임시 레코드, 흐름마다의 레코드 유형. 하이브리드 골든 레코드와 양방향 연동. 모든 데이터 경계에서의 품질 결정.
  3. 데이터를 알라: 용어 사전, 계보, 분류. 비즈니스 메타데이터와 기술 메타데이터. 무엇을 뜻하는지, 어디서 왔는지, 어떻게 다뤄야 하는지, 그리고 시행 없는 분류가 장식인 이유.
  4. 개인정보 보호법이 설계를 형성한다. 알아봐야 할 법들, 그 법들의 공통점(권리, 국외 이전, 침해 통지, 책임성), 그리고 그보다 오래 남는 질문들. 익명처리와 가명처리. 규정 준수는 제품이 아니다.
  5. 동의와 잊힐 권리. 데이터로서의 동의, 표준 동의 모델, 모든 요청에 걸린 기한, 그리고 첫 요청이 오기 전에 삭제를 설계하기.
  6. 보호하고, 보존하고, 증명하라. 암호화의 트레이드오프, 샌드박스, 보존, 필드 기록과 Field Audit Trail, 그리고 필요하기 전에 설정하는 Event Monitoring.

다 읽었다면 장 학습 가이드로 스스로 점검하십시오. 시험 대비 체크리스트, 시험 너머의 습관, 알아야 할 용어, 그리고 몇 가지 질문이 있습니다.

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

섹션 제목: “아키텍트가 여기서 결정하는 것 ”
  • 중요한 각 데이터 영역의 오너가 누구인지, 그리고 각 오너의 정책을 무엇이 시행하는지.
  • 어떤 나쁜 데이터를 막을지, 그리고 무엇을 잡아서 격리했다가 나중에 고칠지.
  • 어떤 필드가 민감한지, 그리고 그 분류가 무엇을 바꾸는지.
  • 개인정보가 어디로 가는지, 무엇에 쓰여도 되는지, 모든 사본에서 어떻게 지워지는지.
  • 데이터와 그 이력을 얼마나 오래 보관할지, 그리고 무슨 일이 있었는지 증명할 어떤 증거가 있는지.

이 장은 아키텍처 지침이지 법률 자문이 아닙니다. 어떤 법이 적용되고 무엇을 요구하는지는 법무와 규정 준수 팀이 정하고, 아키텍트는 그 요구사항을 설계로 바꿉니다.

시험 너머: 거버넌스에 새로운 소비자, 에이전트가 생겼습니다. 분류는 에이전트가 무엇을 가져와도 되는지, 동의는 그 데이터를 무엇에 써도 되는지 정하고, 계보와 감사는 에이전트가 무엇을 말하고 했는지까지 닿아야 합니다. 각 모듈은 생명주기의 자기 부분에 대해 AI가 바꾸는 것으로 끝납니다.

다음: 마스터 데이터와 정체성