보호하고, 보존하고, 증명하라
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장인 데이터 품질과 거버넌스의 모듈 6/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 동의와 잊힐 권리 · 다음: 다음 장, 마스터 데이터와 정체성
이 모듈이 답하는 질문: 데이터를 어떻게 보호하고, 필요한 기간 동안 보관하고, 그것을 증명할까요?
오너와 정책을 정했고, 나쁜 데이터를 막았고, 용어 사전을 썼고, 계보를 추적했고, 중요한 것을 분류했고, 법을 배웠고, 동의를 모델링했습니다. 이제 그것을 운영해야 합니다. 데이터는 들어오고, 쓰이고, 복사되고, 바뀌고, 낡고, 결국 일부는 사라져야 합니다. 그리고 언젠가 누군가 묻습니다. 무슨 일이 있었는지 증명하라.
거버넌스는 데이터를 따라간다
섹션 제목: “거버넌스는 데이터를 따라간다 ”저는 거버넌스를 기능 하나로 생각하지 않습니다. 데이터가 들어온 순간부터 우리가 그것을 다 쓸 때까지 무슨 일이 일어나는지 생각합니다.
수집 → 분류 → 보호 → 사용 → 보존 → 삭제 → 감사
기술 프로세스 일곱 개가 아니라, 아키텍처가 답해야 할 질문 일곱 개입니다. 수집과 분류는 다뤘습니다. 비용이 큰 오류를 막기(모듈 2), 그리고 어떤 데이터가 민감한지 알기(모듈 3). 분류가 이후 모든 단계에서 무슨 일이 일어날지 정하므로, 이 모듈은 거기서 이어 갑니다.
데이터의 일생에 걸친 일곱 가지 질문. 도구는 정책을 뒷받침할 뿐, 정책을 정하지 않습니다.
보호: 통제를 데이터에 맞춰라
섹션 제목: “보호: 통제를 데이터에 맞춰라 ”누가 그것을 보고, 바꾸고, 받을 수 있나? 암호화해야 하나, 운영 밖에서는 마스킹해야 하나, 내보낼 수 있어야 하나, 에이전트가 닿을 수 있어야 하나? 여기서 Salesforce 보안이 데이터 거버넌스의 일부가 됩니다. 공유, 개체·필드 권한, 암호화, 마스킹, 연동 접근. 그 주제들은 과정 하나를 통째로 채우니 다시 가르치지 않겠습니다. 거버넌스 요점은 이것입니다. 보호는 분류와 정책을 따른다. 모든 필드에 같은 보호가 필요하지 않고, 모든 사용자에게 같은 접근이 필요하지 않고, 모든 하류 시스템에 모든 필드가 필요하지 않습니다.
암호화는 통제이지 규정 준수가 아니다
섹션 제목: “암호화는 통제이지 규정 준수가 아니다 ”규제 대상 데이터라면 저장 데이터 암호화가 요구될 수 있고, 제 입장은 Shield가 그런 핵심 규제 요건의 답이다입니다. Shield Platform Encryption은 저장된 필드와 파일을 암호화합니다. 하지만 “암호화했으니 규정을 준수한다”는 두 번 틀렸습니다. 암호화는 접근, 보존, 감사, 동의, 모니터링, 최소화, 삭제와 나란히 있는 통제 하나일 뿐입니다. 그리고 미리 설계로 감당해야 할 기능상의 트레이드오프가 있습니다. 기본 확률적 방식에서는 암호화된 필드를 SOQL WHERE, GROUP BY, ORDER BY 절이나 데이터 관리 필터에 쓸 수 없고, 결정적 암호화는 강도를 조금 포기하는 대신 그 필드로 필터링하게 해 줍니다. 암호화된 필드는 조건 기반 공유 규칙을 이끌 수 없고, 목록 보기를 그것으로 정렬할 수도 없습니다(General Shield Platform Encryption Considerations (opens in a new tab), Filter Encrypted Data with Deterministic Encryption (opens in a new tab)). 그러니 암호화는 마지막에 체크하는 상자가 아닙니다. 아키텍처 결정입니다. 데이터 보안 장에서 더 깊이 다룹니다.
운영의 위험을 샌드박스로 복사하지 마라
섹션 제목: “운영의 위험을 샌드박스로 복사하지 마라 ”운영 환경은 단단히 잠겨 있습니다. 그러다 누군가 전체 샌드박스를 새로 고치고, 이제 개발자, 테스터, 외주 인력, 테스트 연동이 전혀 필요하지 않았던 실제 개인정보 사본을 갖게 됩니다. 환경은 바뀌었지만 데이터의 민감도는 바뀌지 않았습니다. Salesforce의 마스킹 도구가 바로 이것을 위해 있습니다. 변화 하나에 주목하십시오. Data Mask 관리 패키지는 2026년 12월 31일에 서비스가 종료되고, 후속 제품은 Data Mask & Seed입니다(Data Mask (Legacy) (opens in a new tab)). 하지만 도구는 정책을 뒷받침할 뿐이고, 질문이 먼저입니다. 이 환경에 실제 민감 데이터가 정말 필요한가? 사실적이지만 민감하지 않은 데이터로 테스트할 수 있다면, 그것이 더 나은 답입니다.
사용: 허락은 사람만의 문제가 아니다
섹션 제목: “사용: 허락은 사람만의 문제가 아니다 ”사용자, 연동, 분석, 파트너, 자동화, 에이전트가 모두 데이터를 씁니다. 동의(모듈 5), 소유권(모듈 1), 분류(모듈 3)가 런타임에 여기서 만납니다. 이 사용자가 수령인의 전화번호를 봐야 하나? 이 연동이, Snowflake가, 이 에이전트가 그라운딩으로 그것을 받아야 하나? 답이 “음, 기술적으로는 가능해요”여서는 안 됩니다. 그것이 능력과 거버넌스의 차이입니다. 아키텍처는 그래야 하는지를 정합니다.
보존: 모든 것을 영원히 보관하는 것은 중립이 아니다
섹션 제목: “보존: 모든 것을 영원히 보관하는 것은 중립이 아니다 ”많은 조직에 우연한 보존 정책이 있습니다. 영원히. 아무도 정하지 않았고, 저장 공간이 있었으니 데이터가 남았습니다. 하지만 데이터를 보관하는 데는 저장 공간과 성능이 들고, 개인정보와 보안 노출이 넓어지고, 소송 등의 증거 개시 의무가 늘고, 누군가 잊어 달라고 할 때 찾아봐야 할 곳이 늘어납니다. 중요한 범주마다: 왜 보관하나, 얼마나 오래, 무엇이 시계를 시작하나, 법적 최소 기간이나 개인정보 최대 기간이 있나, 끝에는 어떻게 되나. 보관, 삭제, 비식별화?
그리고 보관했다고 보존 문제가 풀린 것은 아닙니다. “보관했어요.” 보존 요구사항이 사라졌나요? 개인정보 요구사항은요? 보안은요? 데이터가 있는 곳을 바꿨을 뿐, 그것이 무엇인지는 바꾸지 않았습니다. 아카이브에도 접근 통제, 보존·삭제 규칙, 검색, 감사가 필요합니다. 개인정보를 모두가 잊어버리는 아카이브로 옮기면 거버넌스는 오히려 나빠집니다.
삭제: 생명주기에는 출구가 필요하다
섹션 제목: “삭제: 생명주기에는 출구가 필요하다 ”삭제는 개인의 개인정보 요청만을 위한 것이 아닙니다. 데이터는 보존 기간의 끝에 이르고, 임시 레코드는 쓸모보다 오래 살고, 아카이브는 만료되고, 프로세스는 정해진 시간 뒤 비식별화합니다. 정책이 무엇이라 하든 아키텍처에는 출구가 필요합니다. 수집 → 저장 → 더 저장 → 영원히 저장이 아니라요. 그리고 모듈 5에서 봤듯이 사본이 다른 곳에 있다면 Salesforce 레코드를 지우는 것으로는 부족합니다.
이력도 데이터다
섹션 제목: “이력도 데이터다 ”때로는 현재 값으로 부족합니다. 파트너의 법적 이름, 고객의 분류, 동의 상태, 재무 속성. 비즈니스나 규제 기관이 이전 값이 무엇이었는지, 언제 바뀌었는지, 누가 바꿨는지 알아야 할 수 있습니다. 그 이력은 데이터이고, 자기 보존 결정이 필요합니다.
표준 필드 기록 추적은 개체당 최대 20개 필드를 추적하고 변경을 최대 18개월 보관하며, 24개월까지는 API를 통해서만, Data Loader나 queryAll()로 볼 수 있습니다(Field History Tracking Overview (opens in a new tab)). 그리고 긴 텍스트 필드는 무엇이 적혀 있었는지가 아니라 필드가 편집되었다는 사실만 기록합니다. 그것이 증거라면 공백입니다. Shield의 일부이거나 별도로 구매하는 Field Audit Trail은 개체당 최대 200개 필드를 추적하고, API로 접근하는 아카이브에 이력을 삭제할 때까지 보관합니다(Field Audit Trail (opens in a new tab)). 제 입장은 이렇습니다. 기본은 표준 필드 기록이다. 규제나 규정 준수 의무가 더 길고 증명 가능한 이력을 요구할 때 Field Audit Trail을 써라. “감사라는 말이 좋게 들려서”가 아니라요.
감사와 모니터링은 같지 않다
섹션 제목: “감사와 모니터링은 같지 않다 ”필드 기록은 선택한 필드의 변경에 관한 질문에 답합니다. 더 넓은 질문(누가 로그인했나, 누가 데이터를 내보냈나, 어떤 API가 호출됐나, 누가 무엇을 봤나)은 모니터링이고, 그것이 Event Monitoring입니다. 제 경험으로는 규제가 더 강한 고객에게 흔히 필요하고, 이 장에서 제 가장 강한 입장이 여기 있습니다. 필요하기 전에 설정하고, 이벤트를 Splunk나 다른 SIEM 같은 저장소로 미리 보내라.
이유는 이렇습니다. 이벤트 로그 파일은 추가 기능이 없으면 일부 이벤트 유형에 대해서만 1일 보관되고, Shield나 Event Monitoring 추가 기능이 있으면 기본 30일, 보존을 연장하면 최대 365일 보관됩니다(Event Monitoring FAQ (opens in a new tab)). 그보다 오래된 것은 내보내지 않았다면 사라집니다. 그리고 유료 로그는 계약이 시작되기 이전 기간의 것은 가져올 수 없습니다(같은 FAQ). 사고가 난 뒤에 추가 기능을 사도 과거는 돌아오지 않습니다. 그래서 아키텍트가 할 수 있는 최악의 대화 중 하나는 이렇게 흘러갑니다. “6개월 전에 무슨 일이 있었는지 볼 수 있나요?” “아니요.” “왜요?” “수집하고 있지 않았거든요.” 문제가 터진 뒤에야 그 이벤트를 수집하고 저장하고 있지 않았다는 걸 알게 되어서는 안 됩니다. 그때는 답이 그냥 사라지고 없습니다.
필요하기 전에 설정하십시오.
하지만 “전부 기록하라”로 치우치지도 마십시오. 무엇을 증명하려는 건가요? 어떤 이벤트가 중요하고, 누가 필요로 하고, 얼마나 오래, 누가 로그를 읽을 수 있고, 로그 자체에 민감 데이터가 담길 수 있나요? 기록은 데이터를 만들고, 그 데이터에도 거버넌스가 필요합니다. 그리고 증거에는 오너가 필요합니다. 저장소는 누가 소유하고, 경보를 검토하고, 보존이 작동하는지 확인하고, 피드가 석 달 전에 조용히 멈췄다는 걸 알아차리나요? 오너 없는 기술은 거버넌스가 아닙니다. 모듈 1의 오너, 스튜어드, 관리 담당자로 돌아왔습니다.
구성이 아니라 통제를 증명하라
섹션 제목: “구성이 아니라 통제를 증명하라 ”“수령인 데이터는 그 정차지에 배정된 배송팀만 볼 수 있다.” 어떻게 압니까? 보안 구성은 무슨 일이 일어나야 하는지 보여 줍니다. 운영 증거(실제로 누가 접근했나, 이상한 내보내기, 그것을 가져가는 연동, 바뀐 접근 통제)는 실제로 무슨 일이 일어났는지 보여 줍니다. 좋은 거버넌스에는 흔히 둘 다 필요합니다.
시험 너머: AI가 바꾸는 것. 에이전트가 답하는 것에서 행동하는 것으로 옮겨 가면서, 거버넌스에는 에이전트가 무엇을 봤는지, 무엇을 결정하거나 생성했는지, 무엇을 했는지, 그리고 누가 또는 무엇이 어떤 정책 아래서 그것을 시작했는지에 대한 증거가 필요합니다. 기록 메커니즘은 바뀌겠지만 요구사항은 바뀌지 않습니다. 자율적인 행동이 중요하다면, 나중에 그것을 어떻게 재구성할지 지금 설계하십시오.
Steve Trucking: 필드 하나의 생명주기
섹션 제목: “Steve Trucking: 필드 하나의 생명주기 ”수령인의 전화번호를 보십시오. 수집: 파트너의 배송 목록과 함께 들어옵니다. 프로세스가 필요로 하는 곳에서 쓸 수 있는지 확인하십시오. 분류: 개인정보. 보호: 운영상 필요가 있는 사람과 시스템만 받고, 배송팀은 자기 정차지에 대해서만, 그날에만 봅니다. 사용: 배송팀이 배송을 조율하고, 메시징은 승인된 목적에 쓰고, 에이전트는 정책이 허락할 때만 씁니다. 보존: 승인된 비즈니스·개인정보 정책이 정한 기간 동안. 삭제 또는 비식별화: 그 기간이 끝나거나 유효한 요청이 오면, 랜드스케이프의 모든 사본에서. 감사: 통제와 조치가 있었다는 증거를 보관합니다.
이제 물류 센터 코드를 보십시오. 정확하게 수집하고, 민감하지 않은 참조 데이터로 분류하고, 일반적인 운영 접근으로 보호하고, 널리 쓰고, 비즈니스가 필요한 만큼 보존하고, 중요하다면 변경을 감사하십시오. 같은 생명주기, 다른 통제. 그것이 분류의 용도입니다.
거버넌스는 결코 끝나지 않는다
섹션 제목: “거버넌스는 결코 끝나지 않는다 ”새 규제가 나옵니다. 새 시스템이나 연동이 또 하나의 사본을 만듭니다. 한 팀이 또 다른 필드를 발명합니다. 새 플랫폼이 가동됩니다. 에이전트가 접근 권한을 얻습니다. 보존 규칙이 바뀝니다. 새 리테일 파트너가 옵니다. 아키텍처가 움직이고, 거버넌스도 함께 움직입니다. 목표는 완벽한 데이터도, 끝없는 통제도, 아무도 읽지 않는 거버넌스 문서도 아닙니다. 데이터에 대한 의도적인 결정을 아키텍처 안에 구축하는 것입니다.
아키텍트가 여기서 결정하는 것
섹션 제목: “아키텍트가 여기서 결정하는 것 ”- 분류, 정책, 실제 사용에 따라 각 데이터 범주가 어떤 보호 통제를 받는지, 암호화의 트레이드오프를 포함해서.
- 데이터와 그 이력을 얼마나 오래 보관하는지, 무엇이 시계를 시작하는지, 끝에는 어떻게 되는지.
- 표준 필드 기록으로 충분한 때와 규제가 Field Audit Trail을 요구하는 때.
- 어떤 이벤트를 수집하고, 플랫폼의 보존 기간 너머로 증거를 어디에 저장하며, 누가 그것을 소유하는지.
- 아키텍처가 사람, 연동, 에이전트의 중요한 행동을 사후에 어떻게 증명하는지.
이 장은 하나의 생각에서 시작했습니다. 거버넌스는 org 옆에 쓰는 것이 아니라 org 안에 설계하는 것이다. 오너는 정책을 정하고 아키텍트는 그것을 시행합니다. 중요한 곳에서 나쁜 데이터를 막으십시오. 데이터가 무엇을 뜻하는지, 어디서 왔는지, 얼마나 민감한지 아십시오. 법을 존중하고, 동의를 모델링하고, 개인정보가 어디로 가는지 통제하십시오. 정책에 따라 보호하고, 보존하고, 삭제하십시오. 그리고 누가 묻기 전에 증거를 수집하십시오. 사고 6개월 뒤는 증거가 30일 동안만 존재했다는 걸 알게 되기에 끔찍한 때이니까요.
더 알아보기
섹션 제목: “더 알아보기 ”- Salesforce 도움말, General Shield Platform Encryption Considerations (opens in a new tab), Filter Encrypted Data with Deterministic Encryption (opens in a new tab)(영어), 확인일 2026-10-14.
- Salesforce 도움말, Field History Tracking Overview (opens in a new tab)(영어), 확인일 2026-10-14.
- Salesforce 도움말, Field Audit Trail (opens in a new tab)(영어), 확인일 2026-10-14.
- Salesforce 도움말, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab)(영어), 확인일 2026-10-14.
- Salesforce 도움말, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab)(영어), 확인일 2026-10-14.