동의와 잊힐 권리
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장인 데이터 품질과 거버넌스의 모듈 5/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 개인정보 보호법이 설계를 형성한다 · 다음: 보호하고, 보존하고, 증명하라
이 모듈이 답하는 질문: 동의를 위해, 그리고 한 사람을 지우기 위해 어떻게 설계할까요?
Steve Trucking에는 수령인의 전화번호가 있습니다. 단순한 질문. 문자를 보내도 될까요? 아마도요. 오늘 배송에 대해? 내일 배송에 대해? 그 번호를 프로모션에 써도 될까요? 문자는 싫다고 했거나, 배송 알림은 좋지만 마케팅은 싫다고 했다가, 마음을 바꿨다면요?
이제 반대 방향입니다. 수령인이 말합니다. 제 개인 정보를 지워 주세요. 어디에 있을까요? 아마 Salesforce에 있겠지만, 그게 답의 전부가 아니라는 걸 배웠습니다. 리테일 파트너에게서 왔습니다. 고객 데이터 플랫폼, 필드 기록, 아카이브, 배송 메모, 내보내기, 연동 로그, 에이전트의 대화에 있을 수 있습니다. 동의와 삭제는 정책 질문처럼 들리지만, 결국 시스템이 답해야 합니다. 그것이 아키텍처입니다.
동의는 데이터다
섹션 제목: “동의는 데이터다 ”첫 번째 원칙. 동의는 데이터다. Has_Opted_In__c = true로 줄이지 마십시오. 진짜 질문은 결코 “동의했나?”만이 아닙니다. **무엇에, 어느 채널로, 어느 주소나 번호로, 어떤 목적으로, 언제 동의했고, 바뀌었으며, 증명할 수 있는가?**입니다. 비즈니스가 그 답으로 결정을 내린다면 정형 데이터로 저장해야 합니다. 개인정보 처리방침의 한 문단으로는 부족하고, 웹 양식의 체크박스로도 부족합니다. 체크박스는 이벤트를 포착하고, 아키텍처는 그 이벤트가 뜻하는 것을 보관해야 합니다.
Salesforce가 이미 만든 모델을 써라
섹션 제목: “Salesforce가 이미 만든 모델을 써라 ”제 입장은 이렇습니다. 가능하면 기본 제공 동의 모델을 써라. 같은 것을 사용자 정의 필드로 다시 만들지 말고요. Salesforce의 동의 데이터 모델은 네 수준에서 동의를 관리하며, 각각 더 구체적인 질문입니다(Understand the Salesforce Consent Data Model (opens in a new tab)).
- 개인(Individual)에 대한 전체 동의: 이 사람은 누구이며, 모든 것을 거부했는가?
- 참여 채널 동의(Contact Point Type Consent): SMS나 이메일 같은 이런 종류의 채널을 써도 되는가?
- 연락 지점 동의: 이 특정 전화번호나 이메일 주소는?
- 데이터 사용 목적: 어떤 이유로? 배송 알림, 서비스, 마케팅?
이것들을 합치면 아키텍처는 **“이 사람의 정보를, 이 연락 지점으로, 이 목적에 써도 되는가?”**에 답할 수 있고, “동의 = 예”보다 훨씬 유용합니다. 개인과 관련된 모든 레코드가 참여할 수 있습니다. 리드, 연락처, 개인 계정, 사용자.
네 가지 질문, 갈수록 좁아집니다. 옵트인 플래그 하나는 그중 어느 것에도 제대로 답하지 못합니다.
목적이 중요하다
섹션 제목: “목적이 중요하다 ”리테일 파트너는 배송팀이 배송을 조율할 수 있도록 Steve Trucking에 수령인의 번호를 보냅니다. 그렇다고 수령인이 마케팅 리드가 되지는 않습니다. 같은 데이터에 허용되는 용도가 여럿일 수 있습니다. 배송 조율, 서비스 후속 조치, 마케팅, AI 개인화. 정책이나 법이 그것들을 다르게 다룬다면 모델은 그것들을 구분해야 합니다. 질문은 **전화번호가 있는가?**가 아닙니다. **그것으로 무엇을 해도 되는가?**입니다.
그리고 동의가 늘 법적 근거인 것은 아닙니다. 어떤 용도는 법이 정한 다른 근거에 기대며, 그건 법무가 판단합니다. 모든 개인정보 결정이 수신 동의 체크박스라고 가정하는 아키텍처를 만들지 마십시오. 정책이 말하는 것을 지원하십시오. 용도가 동의에 달려 있다면 동의를 모델링하고 시행하고, 다른 근거가 적용된다면 그래도 그 용도가 허용되는지 판단하는 데 필요한 것을 저장하십시오.
동의에는 생명주기와 권한 원천이 있다
섹션 제목: “동의에는 생명주기와 권한 원천이 있다 ”사람들은 동의하고, 철회하고, 선호를 바꾸고, 번호를 바꿉니다. 비즈니스는 새 목적을 더하고, 법은 바뀝니다. 그러니 생명주기를 설계하십시오. 무엇을, 언제, 어떻게, 어떤 목적으로 골랐는지, 그리고 철회하면 어떻게 되는지. 그리고 여기서 흥미로워집니다. 수령인이 동의를 철회하면 Salesforce는 압니다. 메시징 플랫폼도 알까요? 분석은? 에이전트는? 한 시스템에만 있고 다른 시스템들은 오래된 허락으로 행동하는 동의는 별로 통제가 아닙니다.
그래서 어느 시스템이 동의의 기준 시스템인가를 물어야 합니다. Salesforce인가, 선호 관리 플랫폼인가, 다른 곳인가? 답이 무엇이든, 같은 사람이 같은 용도에 동의했는지를 다섯 시스템이 각자 판단하게 두지 마십시오. 동의에는 모든 관리되는 데이터가 필요로 하는 것이 필요합니다. 오너, 권위 있는 레코드, 동기화하는 방법, 그리고 시행.
이제 그 사람이 말한다. 저를 잊어 주세요
섹션 제목: “이제 그 사람이 말한다. 저를 잊어 주세요 ”첫 본능은 연락처를 지우고 끝내는 것입니다. 하지만 그 사람의 데이터는 연락처, 배송, 배송 메모, 케이스, 사진, 필드 기록, Snowflake, 아카이브, 연동 로그, 검색 인덱스, 에이전트의 대화 이력에 있을 수 있습니다. 그래서 삭제에 대한 제 입장은 더 일찍 시작합니다. 실제로 삭제는 드물고 어려우니, 먼저 개인정보가 어디로 가는지 통제하라. 가능한 한 적은 곳에 닿도록 설계하십시오. 그다음 요청이 오면, 정책을 충족하는 범위에서 난독화하거나 연결을 끊고, 모든 사본을 찾아내십시오. 필드 기록, 아카이브, Data 360, 그리고 이제는 검색 인덱스와 에이전트 대화까지.
요청이 왔을 때 사냥을 시작하지 마십시오. 그때는 랜드스케이프를 이해하기 시작하기엔 너무 늦습니다. 모듈 3의 용어 사전, 계보, 분류는 서류 작업이 아니었습니다. 이것을 가능하게 하는 것들입니다. 어떤 필드에 개인정보가 있고 사본이 어디로 갔는지 이미 압니다.
“저를 잊어 주세요” 요청은 사본마다 내리는 결정입니다.
시계가 돌고 있다
섹션 제목: “시계가 돌고 있다 ”이런 요청에는 기한이 있습니다. GDPR에서 조직은 사람의 요청을 받은 날부터 부당한 지체 없이, 1개월 안에 조치해야 합니다. 복잡하거나 요청이 많으면 2개월 더 연장할 수 있지만, 첫 1개월 안에 그 사람에게 이유와 함께 알려야 합니다(제12조 제3항, Regulation (EU) 2016/679 (opens in a new tab)). 다른 법은 저마다 기한을 정합니다. 어느 것이 적용되는지는 법무가 알려 줄 것입니다. 어느 쪽이든 한 달은 랜드스케이프를 알아내기에 충분히 길지 않습니다. 사본 지도가 이겨야 하는 기한이 바로 이것입니다.
삭제할까, 비식별화할까, 보존할까?
섹션 제목: “삭제할까, 비식별화할까, 보존할까? ”요청이 있다고 모든 곳의 모든 것이 반드시 사라지는 것은 아닙니다. 어떤 레코드는 보관해야 하거나 보관해도 되고, 어떤 운영 레코드는 남되 그 사람을 식별하지 않게 될 수 있으며, 어떤 데이터는 비식별화할 수 있습니다. 적용되는 정책과 법이 정하고, 아키텍처는 위치마다 각 결과를 지원합니다. 삭제하거나, 비식별화하거나, 승인된 요구사항에 따라 보관하거나(그렇다면 누가, 얼마나 오래, 왜 볼 수 있는가?).
모듈 4의 구분을 기억하십시오. 연결을 끊는 것은 그 사람을 합리적으로 다시 식별할 수 없을 때만 잊는 것으로 칩니다. 가명처리된 데이터는 여전히 개인정보입니다. 난독화를 법적 요구사항을 피하는 지름길로 쓰지 마십시오.
찾을 수 없는 것은 지울 수 없다
섹션 제목: “찾을 수 없는 것은 지울 수 없다 ”누군가를 지우려면 먼저 찾아야 합니다. 요청은 이메일 주소로 옵니다. 한 리테일 파트너는 “Jane Smith”를, 다른 파트너는 “J. Smith”를 보냈고, 전화번호는 바뀌었습니다. 수령인은 연락처도 아니고, 그 정보는 배송마다 붙어 있습니다. 같은 사람이 서로 다른 두 파트너를 위한 배송을 받았습니다. 한 시스템은 그 사람을 이메일로, 다른 시스템은 외부 ID로 압니다. 삭제는 정체성에 달려 있고, 매칭이 너무 공격적이어서 다른 사람의 데이터를 지우고 싶지는 않을 겁니다. 정체성 아키텍처는 개인정보 아키텍처의 일부입니다.
Steve Trucking은 이를 더 어렵게 만듭니다. 한 리테일 파트너는 다른 파트너의 배송이나 수령인을 절대 봐서는 안 됩니다. 같은 사람이 두 파트너를 위한 배송을 받았다면 운영은 그 관계들을 분리해 두어야 하지만, 개인정보 처리에서는 두 쪽 모두에서 그 사람을 찾아야 할 수 있습니다. 보안 경계를 깨서 개인정보 문제를 풀지 말고, 개인정보 요청을 불가능하게 만들어 경계를 지키지도 마십시오. 아키텍처는 둘 다 해야 합니다.
사진과 자유 텍스트도 데이터다
섹션 제목: “사진과 자유 텍스트도 데이터다 ”개인정보를 필드로만 생각하기 쉽습니다. 이름, 이메일, 전화, 주소. 하지만 Steve Trucking은 1년에 배송 사진을 수백만 장 찍고, 일부에는 사람이나 집 안이 찍혀 있습니다. 정형 필드만 보는 보존·삭제 정책은 불완전하고, 파일, 문서, 녹취록, 로그, AI 프롬프트와 응답을 무시하는 정책도 그렇습니다.
그리고 자유 텍스트는 위험합니다. 이름, 전화, 주소를 지웠는데 이런 배송 메모를 발견합니다. “Jane에게 602-555-0198로 전화. 대문 비밀번호 4821. 마당에 개 있음.” 거기 있습니다. 배송 메모를 민감하다고 분류하면 문제가 있을 수 있다는 건 알려 주지만, 텍스트 안의 개인정보를 찾아 지워 주지는 않습니다. 때로 최선의 답은 불필요한 개인 정보가 애초에 거기 들어가지 않게 하는 것입니다. 먼저 개인정보가 어디로 가는지 통제하십시오.
Privacy Center는 도구이지 아키텍처 전체가 아니다
섹션 제목: “Privacy Center는 도구이지 아키텍처 전체가 아니다 ”Salesforce Privacy Center는 이런 프로세스를 돌리는 데 도움이 됩니다. 잊힐 권리 정책은 지우고 싶은 모든 것을 담도록 개체별로 만들고, 특정 고객 레코드에 대해 실행합니다(Delete Data with Right to Be Forgotten Policies (opens in a new tab)). 유용합니다. 하지만 “Privacy Center를 샀으니 끝”은 아키텍처가 아닙니다. 그 사람의 데이터는 어느 한 도구가 닿지 않는 곳에 있을 수 있습니다. Data 360, 웨어하우스, 파트너 시스템, 아카이브, 로그, 검색, 파일, 에이전트 대화. 기업에는 여전히 기업 차원의 답이 필요하고, 각 도구가 실제로 무엇을 다루는지 기대기 전에 확인해야 합니다.
이동권과 증명
섹션 제목: “이동권과 증명 ”어떤 법은 사람들에게 자기 데이터의 사본을 받을 권리도 줍니다. 같은 발견 문제라는 데 주목하십시오. 삭제는 이 사람의 데이터가 어디 있는지, 그래서 조치할 수 있는지를 묻습니다. 이동권은 어디 있는지, 그래서 제공할 수 있는지를 묻습니다. 둘 다 정체성, 분류, 계보, 시스템 목록, 소유권에 기댑니다.
그다음은, 그렇게 했다는 걸 어떻게 증명할까요? 요청 접수, 신원 확인, 시스템 검색, 조치, 예외 기록, 보관한 데이터의 정당화, 완료 기록. 여기엔 진짜 긴장이 있습니다. 누군가의 개인정보를 지우면서 요청을 제대로 처리했다는 걸 보여 줄 증거는 충분히 남겨야 합니다. 그래서 아키텍트가 혼자 보존 규칙을 지어내서는 안 됩니다. 어떤 증거가 남아야 하는지는 법무와 규정 준수가 정하고, 아키텍처는 지워야 할 데이터는 남기지 않고 그 증거를 보관합니다.
시험 너머: AI가 바꾸는 것. AI는 새 목적과 새 사본을 만듭니다. 서비스를 제공하려고 데이터를 써도 된다는 허락이 에이전트 그라운딩, 개인화, 학습까지 자동으로 덮지는 않습니다. 데이터 사용 목적(Data Use Purpose)이 그것들을 구분하기에 자연스러운 곳입니다. 그리고 개인정보는 프롬프트, 그라운딩 맥락, 대화, 요약, 검색·벡터 인덱스, 로그에 살아남을 수 있습니다. AI 층이 여전히 기억한다면 “원천 레코드를 지웠어요”는 완전한 답이 아닙니다.
아키텍트가 여기서 결정하는 것
섹션 제목: “아키텍트가 여기서 결정하는 것 ”- 시스템이 누구, 어느 채널, 어느 연락 지점, 어떤 목적에 답할 수 있도록 동의와 허용된 사용을 어떻게 모델링할지.
- 어느 시스템이 동의의 기준 시스템이며, 철회가 그것에 따라 행동하는 모든 시스템에 어떻게 닿는지.
- 개인정보가 어디로 퍼질 수 있는지: 필드, 자유 텍스트, 파일, 기록, 분석, 아카이브, 연동, 검색, AI.
- 요청이 어떻게 올바른 사람을 찾고, 각 위치에서 삭제, 비식별화, 승인된 보존을 이끄는지.
- 동의와 개인정보 요청이 처리되었음을 증명하기 위해 어떤 증거가 남는지.
동의와 삭제는 반대처럼 보입니다(이 데이터를 써도 되나? 멈추고 지울 수 있나?). 하지만 같은 기반에 서 있습니다. 정체성, 목적, 분류, 계보, 소유권, 시행, 증거. 표준 동의 모델을 쓰고, 개인정보가 어디로 가는지 통제하고, 사본이 어디 있는지 알고, 첫 요청이 오기 전에 삭제 프로세스를 설계하십시오. 누군가 “저를 잊어 줄 수 있나요?”라고 물을 때 아키텍처에는 “그런 것 같아요”보다 나은 답이 필요합니다.
더 알아보기
섹션 제목: “더 알아보기 ”- Salesforce 도움말, Understand the Salesforce Consent Data Model (opens in a new tab)(영어), 확인일 2026-10-14.
- Regulation (EU) 2016/679 (GDPR) (opens in a new tab), 제12조 제3항, 요청에 대한 조치 기한, 확인일 2026-10-14.
- Salesforce 도움말, Delete Data with Right to Be Forgotten Policies (opens in a new tab)(Privacy Center, 영어), 확인일 2026-10-14.