데이터 최소화와 프라이버시 실천

데이터 최소화란

데이터 최소화(data minimization) 는 서비스에 꼭 필요한 개인정보만, 필요한 정밀도로, 필요한 기간 동안만 갖는 원칙이다. 갖지 않은 데이터는 유출될 수도, 오용될 수도 없다. 보호 의무와 규제 부담도 그만큼 줄어든다.

프라이버시는 기획·법무만의 일이 아니다. 개발자는 두 방식으로 기여한다.

방식	뜻
설계 단계의 프라이버시(privacy by design)	기술·설계 결정을 내릴 때 처음부터 데이터 흐름을 고려한다
다른 사람을 돕기	기술 지식으로 동료·리더가 프라이버시 영향을 알고 결정하게 한다

GDPR(유럽), CCPA(캘리포니아), APPI(일본) 같은 법이 생기고 브라우저도 추적을 막고 있어(서드파티 쿠키와 브라우저 추적 방지) 최소화는 규제 대응이자 신뢰를 얻는 방법이다. 이 노트는 법률 자문이나 체크리스트가 아니라 엔지니어링 원칙이다.

네 단계: 효과가 큰 순서

순서	방법	핵심 질문
1	수집하지 않기	이 데이터가 없어도 기능이 되는가
2	뭉개서 모으기(fuzzing)	개인 값이 필요한가, 집계만 필요한가
3	쓰고 지우기(보존 기한)	언제, 무엇을 계기로 지우는가
4	이유를 설명하기	사용자에게 공개적으로 설명할 수 있는가

1. 수집하지 않기

필요해 보이는 수집도 다시 보면 없어도 되는 경우가 많다. 대표 예가 비회원 구매(guest checkout) 다. 구매에 회원 가입을 강제하면 개인정보가 쌓이고 장바구니 이탈도 늘어난다. 가입 없이 사게 하면 고객과 데이터 보호 부담을 함께 덜어 낸다.

2. 뭉개서 모으기

집단에 대한 결정에는 집계 속성만 있으면 된다.

기법	방법	예
구간화(bucketing)	정확한 값 대신 범주를 고르게 한다	생년월일 대신 `18–34 / 35–49 / 50–64 / 65+` 선택
무작위 응답(randomized response)	정해진 비율의 응답을 일부러 무작위로 바꾼다. 비율을 알므로 집계는 보정되고 개인 응답은 믿을 수 없게 된다	민감한 설문, 클라이언트가 전송 전에 일정 비율을 뒤바꿈
차등 프라이버시(differential privacy)	수학적 잡음을 더해 집계는 유지하되 특정 개인이 데이터에 들어 있는지 알 수 없게 한다	사용 통계

차등 프라이버시를 서버에서 적용하면 원본 데이터가 서버에 잠시 존재한다. 원본을 보호하고 처리 뒤 지우는 정책이 따로 필요하다.
"혹시 몰라서" 모으는 투기적 수집(speculative collection) 이 가장 흔한 함정이다. 세밀한 데이터를 실제로 몇 번 썼는지 확인해 보면 대개 구간으로 충분하다.

3. 쓰고 지우기

데이터에는 수집 → 특정 목적에 사용 → 삭제라는 수명이 있다. 데이터마다 지우는 계기를 정해 둔다: 사용자 요청, 로그아웃, 기간 만료, 특정 사건.

사용자가 계정과 데이터를 스스로 지울 수 있게 한다. 동의는 쉽게 철회할 수 있어야 한다(철회 가능성 원칙).
로그아웃할 때 브라우저에 남은 데이터를 지운다. Clear-Site-Data 응답 헤더는 JavaScript 없이 그 출처의 클라이언트 데이터를 지운다.

Clear-Site-Data: "cache", "cookies", "storage"

값	지우는 것
`"cookies"`	등록 도메인(서브도메인 포함)의 쿠키와 HTTP 인증 정보
`"storage"`	localStorage·sessionStorage·IndexedDB·서비스 워커 등록 등
`"cache"`	HTTP 캐시. 브라우저에 따라 bfcache·사전 렌더링 페이지도
`"executionContexts"`	그 출처의 열린 탭을 새로고침
`"*"`	앞으로 추가될 종류까지 전부

값은 반드시 큰따옴표로 감싼다. Clear-Site-Data: cookies는 무효다.
HTTPS에서만 동작한다. Baseline이지만 지시어별 지원은 브라우저마다 다르므로 서버 쪽 세션 무효화를 대신하지 않는다.
"cache"는 캐시가 큰 기기에서 오래 걸려 페이지를 막을 수 있다. 로그아웃 페이지 응답 자체보다 그 페이지가 따로 부르는 요청의 응답에 붙이는 편이 안전하다.

4. 이유를 설명하기

데이터마다 어떤 질문에 답하고, 어떤 결정에 쓰이고, 언제 지워지는지 정한다. 그다음 개인정보 처리방침뿐 아니라 수집하는 그 자리에서 설명한다. 공개적으로 설명하기 꺼려지는 용도라면 그 데이터는 필요 없을 가능성이 높다.

<label for="email">이메일</label>
<input id="email" type="email" required aria-describedby="why-email">
<a href="#why-email">왜 필요한가요?</a>
<aside id="why-email">
  주문 확인 메일을 보내는 데만 쓰고, 배송이 끝나면 30일 뒤 삭제합니다.
</aside>

aria-describedby로 설명을 입력과 연결해 스크린 리더도 읽게 한다(더 나은 폼을 만드는 팁).
비밀번호처럼 이유가 뻔한 칸은 설명하지 않아도 된다. 연락처·인적 사항은 설명한다.
가입이 쉬운 만큼 탈퇴도 쉬워야 한다.

조직에서 유지하기

데이터 목록 문서화

사용자와 연결된 데이터마다 다음을 적어 둔다. 적다 보면 모르던 수집과 쓰지 않는 수집이 드러난다.

항목	내용
목적	어떤 질문에 답하려고 모으나
수집 방법	어디서 어떻게 들어오나(폼, 로그, 서드파티)
정밀도	그 질문에 필요한 최소 단위
삭제	언제 지우나, 사용자가 스스로 지울 수 있나

문서는 API 문서처럼 개발 과정에서 함께 고친다. 쉬운 말로 다듬어 처리방침에서 링크하면 신뢰를 얻는다.

정기 감사

큰 기능이 바뀔 때와 정해진 주기마다 수집 데이터와 서드파티를 다시 감사한다(서드파티와 프라이버시).
새 사용자 입장에서 처음부터 가입·사용해 보고 무엇을 요구하는지 확인한다.
프라이버시 동향을 챙길 담당자를 정한다. 브라우저 블로그(webkit.org/blog, developer.chrome.com/blog, hacks.mozilla.org)와 표준 입장 페이지(WebKit·Mozilla standards-positions, chromestatus.com)가 1차 자료다. 쿠키 SameSite 기본값이 Lax로 바뀐 것처럼 브라우저 정책 변경은 앱 수정을 요구한다.

목적 외 사용 막기

선언한 목적 밖으로 기존 데이터를 재활용하지 않는다. 예: 구매 분석용으로 연령 구간을 모았다면 "25세 미만 전원에게 메일"에 쓰지 않는다. 대신 구매 이력으로 메일을 고른다.
사용자 데이터 접근에는 이름 있는 담당자의 짧은 서면 사유를 요구한다. 아무도 읽지 않는 형식적 체크박스는 만들지 않는다.
문서에 적은 삭제 기한을 실제로 집행한다.
거절보다 대안을 제시한다. 목표를 프라이버시를 해치지 않고 이루는 길을 함께 찾는다.

정리

가장 좋은 보호는 갖지 않는 것이다. 다음이 정밀도를 낮추는 것, 그다음이 빨리 지우는 것이다.
데이터마다 목적·정밀도·삭제 시점을 정하고, 그 이유를 수집하는 자리에서 설명한다.
로그아웃 때는 서버 세션 무효화와 함께 Clear-Site-Data로 브라우저 쪽 흔적을 지운다.
데이터 목록 문서와 정기 감사로 수집이 슬그머니 늘어나는 것을 막는다.

버그 제보