개인정보 보호법이 설계를 형성한다

🌐 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)

AI로 생성한 이미지

AI로 번역했습니다. 아직 커뮤니티의 검토를 거치지 않았습니다. 영어로 읽기

Data Architect 과정 5장인 데이터 품질과 거버넌스의 모듈 4/6. 각 모듈은 독립적으로 읽을 수 있습니다. 이전: 데이터를 알라 · 다음: 동의와 잊힐 권리

이 모듈이 답하는 질문: 개인정보 보호법과 산업 규제는 Salesforce 설계에 무엇을 요구할까요?

호주에서 일할 때 GDPR을 들어 본 적 없는 예비 아키텍트를 많이 만났습니다. 유럽 사람들은 캘리포니아나 캐나다나 브라질의 개인정보 보호법을 들어 본 적이 없는 경우가 많습니다. 자연스러운 일입니다. 일하는 곳의 규칙을 알게 되니까요. 하지만 이 법들은 국경을 넘어 닿고, 어느 것도 Salesforce에 관한 법이 아닌데도 시스템 설계를 형성합니다. 그래서 데이터 아키텍처 과정에 속합니다.

변호사가 될 필요는 없습니다. 하지만 규제가 데이터가 저장되는 곳, 수집하는 것, 보는 사람, 쓸 수 있는 이유, 보관 기간, 보내는 곳, 삭제할 수 있는지, 어떤 이력을 남기는지, 나중에 무엇을 증명할 수 있는지를 바꿀 수 있다는 것은 봐야 합니다. 법적 질문만이 아닙니다. 데이터 아키텍처 질문입니다.

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

법은 국경에서 멈추지 않는다

가장 큰 오해부터. “우린 유럽에 있지 않으니 GDPR은 적용되지 않아요.” 그럴 수도, 아닐 수도 있습니다. GDPR의 지역적 적용 범위는 EU 안의 사람들에게 재화나 서비스를 제공하거나 그곳에서 그들의 행동을 모니터링하는 EU 밖의 조직에까지 미칩니다(제3조, Regulation (EU) 2016/679 (opens in a new tab)). 그러니 회사 본사가 어디인지가 질문의 끝이 아닙니다. 고객, 직원, 데이터를 보유한 사람들, 시스템, 처리자는 어디에 있습니까? 데이터는 어디로 이동합니까? 다시 4장의 랜드스케이프입니다. 데이터가 어디로 가는지 모르면 좋은 개인정보 결정을 내릴 수 없습니다.

알아봐야 할 규제들

아키텍트가 알아야 할 이름들과 각각이 다루는 것입니다. 알아보기 위한 표이지 적용 여부 매트릭스가 아닙니다. 이것을 읽고 “캘리포니아에 고객이 있으니 요구사항 X가 적용된다”고 정하지 마십시오. 그건 법무가 판단할 일입니다. 당신의 일은 시스템이 만들어지기 전에 질문을 던질 만큼 아는 것입니다.

법 또는 표준	지역 또는 대상	아키텍트가 알아봐야 하는 이유
GDPR (opens in a new tab)	유럽연합	개인정보, 적법한 처리, 개인의 권리, 보존, 이전, 설계 단계부터의 개인정보 보호
CCPA, CPRA로 개정 (opens in a new tab)	캘리포니아	기업이 수집한 개인 정보에 대한 소비자의 권리
PIPEDA (opens in a new tab)	캐나다	민간 부문 조직의 개인 정보 처리
LGPD (opens in a new tab)	브라질	브라질의 일반 개인정보 보호법
Privacy Act 1988 (opens in a new tab)	호주	호주 개인정보 보호 원칙에 따른 조직의 개인 정보 처리
HIPAA (opens in a new tab)	미국 의료	해당 맥락에서의 보호 대상 건강 정보
PCI DSS (opens in a new tab)	결제 카드	결제 카드 계정 데이터 보호
Sarbanes-Oxley(SOX) (opens in a new tab)	미국 상장 기업	재무 보고를 뒷받침하는 통제와 증거
COPPA (opens in a new tab)	미국, 온라인 아동	아동에게서 온라인으로 수집하는 개인 정보

목록은 늘어나고(자체 법을 가진 미국 주가 늘고 있습니다), 법은 바뀝니다. 그래서 표를 외우고 개인정보 아키텍처를 배웠다고 생각하지 않기를 바랍니다. 이름을 배우고, 그다음 그 이름들보다 오래 남는 질문을 배우십시오.

법들의 공통점

세부는 다르지만, 큰 개인정보 보호법들은 같은 몇 가지로 계속 돌아오고, 그 하나하나가 아키텍처에 떨어집니다.

권리. 사람들은 자기 데이터를 보고, 정정하고, 삭제하고, 가져가겠다고 요청할 수 있습니다. 캘리포니아와 브라질의 법에서는 데이터 판매를 거부(옵트아웃)할 수도 있습니다. 그 요청 하나하나가 그 사람의 데이터를, 전부 찾아야 한다는 뜻입니다.

국외 이전. GDPR과 LGPD는 개인정보가 관할 지역 밖으로 나가는 것을 통제하고, 가는 곳에서 적절한 보호를 요구합니다. PIPEDA는 제3자가 데이터를 처리할 때, 그곳이 어디든 같은 수준의 보호를 기대합니다. 다시 랜드스케이프입니다. 어느 화살표가 국경을 넘습니까?

침해 통지. 개인정보가 노출되면, 법은 법마다 다른 기한 안에 당국에, 때로는 영향을 받은 사람들에게도 알리기를 기대합니다. 가진 줄도 몰랐던 데이터에 대해서는 통지할 수 없고, 사본을 찾지 못하면 무엇이 노출됐는지 말할 수 없습니다.

책임성. 규정 준수를 보여 줄 수 있어야 합니다. 무엇을 왜 처리하는지에 대한 기록, 고위험 처리에 대한 영향 평가, 그리고 GDPR과 LGPD에서는 데이터 보호 책임자(DPO). 아키텍처가 그 기록을 만들어 내야 합니다.

무엇이 개인정보인지에서 시작하라

개인정보를 보호하기 전에 찾으십시오. 어떤 것은 분명합니다. 이름, 집 주소, 전화, 이메일. 어떤 것은 그렇지 않습니다. 위치, 기기 식별자, IP 주소, 이미지, 행동 데이터, 사람에게 다시 연결될 수 있는 모든 것. 그리고 맥락이 중요합니다. Steve Trucking의 배송에는 수령인의 이름, 주소, 전화번호, 배송 메모, 사진이 담깁니다. 사진은 현관 앞 상자일 수도, 사람일 수도, 집 안일 수도 있습니다. 배송은 운영 데이터이지만 그 속성 일부는 개인정보입니다. 그래서 모듈 3에서 필드를 분류했습니다. 개인정보 보호는 무엇을 가졌는지 아는 데서 시작합니다.

어디에 있는가?

“Salesforce요.” 아마 Salesforce만은 아닙니다. 리테일 파트너에게서 왔나요? Snowflake에 복사됐나요, Data 360에 수집됐나요, 연동 로그에 쓰였나요, 사용자가 내보냈나요, 필드 기록에 남았나요, 보관됐나요, 샌드박스에 복사됐나요, 파트너에게 넘어갔나요, 에이전트의 대화에 쓰였나요? 개인정보는 퍼집니다. 그래서 법무가 “이 사람의 정보를 어디에 보관하고 있나요?”라고 물을 때 “현재 값이 어디 있는지는 압니다”는 답이 아닙니다. 저는 랜드스케이프와 계보, 즉 사본이 어디로 갔는지를 원합니다.

Click to enlarge

전화번호 하나, 사본 여럿. 개인정보 보호는 사본에도 적용됩니다.

왜 그것을 써도 되는가?

데이터를 가진 것과 그것을 써도 되는 것은 같지 않습니다. Steve Trucking은 오늘의 배송을 조율하려고 수령인의 전화번호를 가지고 있습니다. 그게 마케팅 목록이 된다는 뜻일까요? 아닙니다. 법적 근거는 관할과 상황에 따라 다르고 그건 법무가 이끌지만, 아키텍처는 그 답을 담아야 합니다. 왜 수집했는지, 어떤 사용이 허가됐는지, 동의가 필요했는지, 주어졌는지, 철회됐는지, 어떤 채널, 주소, 목적에 대해서인지. 데이터를 쓸 수 있는 허락은 데이터로 표현될 수 있어야 합니다. 정책 문서는 런타임에 결정을 내릴 수 없으니까요. 다음 모듈이 그것을 모델링합니다.

덜 수집하는 것은 아키텍처 결정이다

가장 강한 개인정보 통제 중 하나는 데이터를 수집하지 않는 것, 또는 필요 없는 곳에 복사하지 않는 것입니다. Snowflake에 수령인의 전화번호가 필요할까요? 분석에 전체 도로명 주소가 필요할까요? 샌드박스에 진짜 배송 사진이 필요할까요? 에이전트가 이 질문에 답하려고 수령인의 개인 정보가 필요할까요? 필요 없다면 가장 강한 통제는 거기에 두지 않는 것일 수 있습니다. 만들지 않은 사본 하나하나는 보호하고, 보존하고, 삭제하고, 동의를 추적하고, 감사하고, 침해 시 신고할 필요가 없는 사본입니다. 관리하기 가장 싼 민감 데이터는 복사하지 않은 데이터입니다.

보존은 모델의 일부다

“일단 다 보관하죠”도 보존 정책입니다. 나쁜 정책일 뿐입니다. 중요한 데이터에 대해 저는 설계 시점에 알고 싶습니다. 얼마나 오래, 왜 필요한가, 어떤 규제가 최소 기간을 정하거나 다른 규제가 최대 기간을 정하는가, 시계는 언제 시작하는가, 그리고 끝에는 어떻게 되는가. 삭제, 보관, 비식별화, 그리고 사본은 어디에 있는가? 재무 기록은 정해진 기간 남아 있어야 할 수 있습니다. 수령인의 대문 비밀번호는 배송 몇 년 뒤엔 아무 목적이 없습니다. 이런 결정은 데이터베이스가 커질 때까지 기다리지 않습니다.

익명처리, 가명처리, 암호화, 마스킹

“Jane Smith”를 7F92A1로 바꿉니다. Jane은 익명처리되었을까요? 다른 테이블에 여전히 7F92A1 = Jane Smith가 있다면 아닙니다. 그것은 가명처리입니다. 직접 식별자는 바뀌었지만 별도로 보관한 정보로 데이터를 다시 연결할 수 있고, GDPR에서 가명처리된 데이터는 여전히 개인정보입니다(제4조 제5호). 익명처리는 더 나아갑니다. 데이터를 더 이상 합리적으로 그 사람에게 연결할 수 없습니다(전문 제26항). 그러니 누군가 “삭제할 필요 없어요, 이름만 지우면 돼요”라고 하면 조심하십시오. 그 사람을 여전히 합리적으로 식별할 수 있다면 그 선을 넘지 않은 것입니다. 결과가 법을 충족하는지는 법무가 판단하고, 아키텍트의 일은 시스템이 정확히 무엇을 하는지 말하는 것입니다. 다시 연결할 수 있나, 어떤 키가 남았나, 매핑은 어디 있나?

단어를 정확히 쓰십시오. 서로 다른 문제를 풀기 때문입니다. 암호화는 무단 공개로부터 데이터를 보호하며, 권한 있는 사용자는 여전히 복호화할 수 있습니다. 마스킹은 특정 사용자나 환경이 보는 것을 바꿉니다. 가명처리는 되돌아갈 길을 남긴 채 직접 정체성을 분리합니다. 익명처리는 그 사람을 식별할 합리적 가능성을 없앱니다. 데이터를 “개인정보”에서 벗어나게 하는 것은 마지막 것뿐입니다.

규제는 요구사항이 된다

법무가 저에게 권한 집합을 만들라고 말할 필요는 없습니다. 그건 제 쪽 일입니다. 법무는 “정당한 업무상 필요가 있는 직원만 이 범주의 개인 정보에 접근할 수 있다”고 말할 수 있습니다. 그러면 저는 번역합니다. 그들은 누구인가, 그 범주를 어떻게 식별하나, 접근은 어떻게 부여하나, 누군가 직무를 바꾸면 어떻게 되나, 연동이 읽을 수 있나, 에이전트는, 내보낼 수 있나, 누가 봤는지 어떻게 증명하나? 오너는 정책을 정하고, 아키텍트는 그것을 시행한다. 법무와 규정 준수가 의무를 정하고, 데이터 오너가 비즈니스 정책을 정하고, 아키텍트가 시행을 설계합니다.

Click to enlarge

규제에서 증거까지: 법무는 해석하고, 오너는 정책을 정하고, 아키텍트는 그것을 작동하고 증명할 수 있게 만듭니다.

그리고 규정 준수는 제품이 아닙니다. “규정 준수: 켜기”를 살 수는 없습니다. 암호화는 요구사항을 뒷받침할 수 있고, 감사 기능은 증거를 주고, 보존 도구는 정책을 실행하고, 동의 데이터는 허용된 사용을 뒷받침하지만, 기능 라이선스를 산다고 아키텍처가 규정을 준수하게 되지는 않습니다. 규정 준수는 설계 전체에서 나옵니다. 사람, 정책, 프로세스, 데이터, 통제, 증거. Salesforce는 그 일부이지 전부가 아닙니다. 그리고 정책이 시행할 만큼 중요하다면 증명할 만큼 중요한지도 물으십시오. 3월 17일에 누가 이 레코드에 접근했나, 누가 이 필드를 바꿨나, 그 내보내기에는 무엇이 들어 있었나? 증거는 모듈 6에서 다룹니다.

개인정보 보호가 랜드스케이프를 바꾼다

Steve Trucking에서 수령인의 개인정보는 파트너 연동 세 개를 통해 들어옵니다. Salesforce는 배송을 운영하려고 그것이 필요하고, 배송팀은 그 일부가 필요하지만 자기 정차지에 대해서만, 그날에만 필요합니다. Snowflake는 배송 분석을 원하고, 재무는 청구에 충분한 만큼은 필요하지만 배송팀이 보는 것은 필요 없습니다. 그리고 한 리테일 파트너는 다른 파트너의 수령인을 절대 봐서는 안 됩니다. 개인정보 보호가 화살표를 바꿉니다. 어떤 필드는 Snowflake로 가지 않고, 분석은 덜 식별 가능한 버전을 받고, 배송팀은 자기 정차지만 보고, 하류의 보존은 운영 보존과 다릅니다. 개인정보 요구사항은 랜드스케이프 다이어그램 옆에 놓이는 게 아닙니다. 그것을 바꿉니다.

규제보다 오래 남는 질문들

규제는 바뀌니, 민감하거나 규제 대상인 모든 데이터에 대해 오래가는 질문 묶음을 갖고 다니십시오.

• 무엇인가? 개인, 민감, 재무, 건강, 결제, 아동, 또는 기타 규제 대상?
• 어디에 있는가? 모든 사본: 연동, 기록, 분석, 아카이브, 샌드박스, 로그, AI 사용.
• 왜 써도 되는가? 어떤 목적과 법적 근거가 적용되는가? 동의가 관련되는가?
• 누가 써도 되는가? 사람, 시스템, 파트너, 연동, 에이전트.
• 얼마나 오래 보관하는가, 그리고 끝에는 어떻게 되는가?
• 그 사람이 그것에 대한 권리를 행사할 수 있는가? 법이 정하는 대로 열람, 정정, 삭제, 이동, 이의 제기.
• 무슨 일이 있었는지 증명할 수 있는가? 접근, 변경, 내보내기, 동의, 삭제, 보존.

AI 거버넌스가 법이 되고 있다

AI는 관리되는 데이터의 소비자를 하나 더합니다. AI 시스템이 이 데이터를 쓸 수 있나, 어떤 목적으로, 그라운딩으로, 무엇과 결합해서, 출력에서 되풀이해서, 어디에 얼마나 오래 기록되나? AI 거버넌스는 회사 정책에서 법으로 옮겨 가고 있습니다. 유럽연합의 인공지능법(Regulation (EU) 2024/1689 (opens in a new tab))이 첫 포괄적 사례입니다. 무엇을 요구하는지는 시스템과 용도에 따라 다릅니다. 아키텍트에게 방향은 분명합니다. AI는 거버넌스 밖에 있지 않습니다. 관리되는 데이터의 또 다른 소비자입니다.

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

• 규제 대상이거나 민감한 데이터가 랜드스케이프 전반에서 어디로 들어오고, 머물고, 이동하고, 복사되는지.
• 아키텍트가 법을 해석하지 않으면서, 법무와 규정 준수 정책이 어떻게 시행 가능한 요구사항이 되는지.
• 민감 데이터를 받는 각 시스템이 정말 그것이 필요한지, 덜 식별 가능한 버전으로 충분한지.
• 보존, 삭제, 익명처리, 가명처리, 보호, 증거가 데이터의 생명주기를 어떻게 형성하는지.
• 중요한 통제가 실제로 작동했음을 보여 줄 어떤 증거가 있어야 하는지.

규제는 이름을 슬라이드에 올린다고 아키텍처가 되지 않습니다. 데이터를 수집하고, 분류하고, 옮기고, 보호하고, 보존하고, 삭제하고, 증명하는 방식을 바꿀 때 아키텍처가 됩니다.

더 알아보기

• 규제의 공식 출처는 위 표에 연결되어 있습니다(영어 또는 원어), 확인일 2026-10-14.
• Regulation (EU) 2016/679 (GDPR) (opens in a new tab): 제3조(지역적 적용 범위), 제4조 제5호(가명처리), 전문 제26항(익명 정보).
• Regulation (EU) 2024/1689 (인공지능법) (opens in a new tab), EUR-Lex.