개인정보를 필요한 만큼만 받고 제때 지우는 설계 순서

작은 서비스를 만들 때 회원가입 폼부터 이름, 생년월일, 전화번호, 주소를 모두 넣기 쉽습니다. 언젠가 마케팅이나 통계에 쓸 수 있을 것 같기 때문입니다. 하지만 쓰지 않는 정보도 유출과 오입력, 문의 대응, 삭제 요청의 책임을 함께 가져옵니다.

여행 가방에 필요할지 모르는 물건을 전부 넣으면 이동이 느리고 잃어버렸을 때 피해가 커집니다. 서비스가 받는 개인정보도 목적에 필요한 짐만 골라야 합니다. 무엇을 받을지보다 왜 필요한지, 언제 내려놓을지를 먼저 적는 순서가 중요합니다.

개인정보는 한 사람과 연결될 수 있는 정보다

personal data는 이름처럼 사람을 바로 알아보게 하거나 다른 정보와 합쳐 특정 사람을 알아볼 수 있는 정보입니다. 유럽연합 집행위원회는 이름과 주소뿐 아니라 IP 주소, 쿠키 ID, 광고 식별자도 개인정보 예시로 설명합니다. 가명으로 바꿔도 다시 연결할 수 있다면 여전히 개인정보일 수 있습니다.

processing은 개인정보 처리라는 뜻으로 수집, 저장, 조회, 전달, 수정, 삭제 같은 모든 동작을 포함합니다. 입력 폼으로 받는 순간만 보호하면 끝나는 것이 아닙니다. 로그, 분석 도구, 백업, 고객 지원 화면으로 복사되는 경로도 함께 봐야 합니다.

최소 수집은 목적에 필요한 항목만 받는 원칙이다

data minimisation은 개인정보 최소화 원칙으로, 정한 목적에 알맞고 관련 있으며 필요한 범위로 정보를 제한하는 생각입니다. GDPR 제5조도 이 원칙을 명시합니다. 이 글은 특정 국가의 법률 자문이 아니라 제품 설계의 기본 점검법을 설명하며 실제 적용 법과 고지 의무는 사업 지역과 서비스에 맞춰 전문가와 확인해야 합니다.

회원에게 글 저장 기능만 제공한다면 이메일 로그인으로 충분한지, 실명과 전화번호까지 꼭 필요한지 묻습니다. 배송 상품이 없는데 주소를 받거나 연령 제한이 없는데 생년월일을 요구하면 목적을 설명하기 어렵습니다.

항목마다 이유와 흐르는 경로를 한 줄로 적는다

수집표를 만들면 “일단 받자”는 결정을 눈으로 볼 수 있습니다. 항목마다 기능 목적, 필수 여부, 저장 위치, 접근자, 보관 기한, 삭제 방법을 적습니다.

항목: 이메일 주소
목적: 로그인 링크와 계정 복구
필수 여부: 계정 방식에 따라 필수
저장 위치: 회원 데이터베이스
접근자: 인증 서버와 제한된 지원 담당자
보관 기한: 계정 유지 중, 탈퇴 뒤 정책에 따른 삭제
삭제 방법: 탈퇴 작업과 백업 만료 절차

“서비스 개선”처럼 너무 넓은 목적은 실제 필요성을 판단하기 어렵습니다. 어떤 기능에서 어떤 결정을 위해 쓰는지 구체적으로 적고, 분석 목적이라면 개인을 다시 알아볼 필요가 있는지도 묻습니다.

필수와 선택을 화면에서 솔직하게 나눈다

필수 입력은 없으면 현재 요청을 처리할 수 없는 항목이어야 합니다. 선택 항목을 비워 두면 가입이나 기본 기능을 막지 않습니다. 동의를 받았다는 이유만으로 필요하지 않은 정보가 자동으로 최소 수집이 되지는 않습니다.

• 각 입력칸 가까이에 쓰는 이유를 설명합니다.
• 필수와 선택 표시를 글자로 구분합니다.
• 선택 항목을 비워도 기본 흐름을 완료하게 합니다.
• 미리 체크된 홍보 동의를 사용하지 않습니다.
• 목적이 다른 사용은 별도로 설명하고 선택하게 합니다.
• 어린이, 건강, 결제 정보는 추가 법적 기준을 확인합니다.

보관 기간은 나중이 아니라 수집 전에 정한다

storage limitation은 개인정보를 필요한 기간보다 오래 보관하지 않는 원칙입니다. “서비스 종료 때까지”라고만 적지 말고 기능과 법적 의무에 따라 보관 시작과 종료 조건을 정합니다. 계정 탈퇴, 문의 처리 완료, 계약 종료처럼 사건과 연결하면 자동 삭제 작업을 설계하기 쉽습니다.

즉시 삭제가 항상 가능한 것은 아닙니다. 거래 증빙처럼 법에서 일정 기간 보관해야 할 자료가 있을 수 있고 백업에서 제거되는 데 시간이 걸릴 수 있습니다. 이 경우 사용 목적을 제한하고 실제 보관 근거와 기간, 백업 만료 방식을 고지합니다. 근거 없는 기간을 이 글에서 만들지 않습니다.

삭제 버튼 하나로 모든 복사본이 사라진다고 가정하지 않는다

개인정보는 운영 데이터베이스 외에도 로그, 분석 도구, 이메일 발송 서비스, 파일 저장소, 백업에 남을 수 있습니다. 삭제 흐름은 이 복사본 목록을 따라가야 합니다. 외부 처리업체가 있다면 계약과 공식 삭제 기능, 처리 완료 확인 방법을 봅니다.

탈퇴 요청
→ 로그인 세션 무효화
→ 운영 자료 삭제 또는 법적 보관 영역 분리
→ 외부 서비스 삭제 요청
→ 백업 만료 일정 기록
→ 사용자에게 확인된 범위 안내

삭제 성공 화면만 띄우고 서버 작업이 실패하면 잘못된 약속이 됩니다. 각 단계의 성공과 실패를 기록하고, 다시 실행해도 이미 삭제된 자료가 되살아나지 않게 만듭니다.

접근 권한과 로그도 최소화한다

적게 모아도 모든 직원과 도구가 볼 수 있으면 위험합니다. 고객 지원에는 필요한 일부 항목만 보이고, 개발 로그에는 비밀번호와 인증 토큰, 전체 결제 정보를 남기지 않습니다. 오류를 조사하려고 사용자 입력 전문을 자동 저장하는 습관도 점검합니다.

새 분석 도구나 AI 서비스를 연결할 때 어떤 정보가 외부로 전달되는지 먼저 확인합니다. 개인정보를 테스트 데이터로 복사하거나 AI 채팅에 붙이지 않습니다. 실제 자료가 필요하다면 승인된 절차와 가명 처리, 접근 기록, 삭제 계획을 따릅니다.

오늘 바로 해볼 작은 실습

실제 회원 자료를 열지 않고 빈 수집표를 만듭니다.

1. 회원가입이나 문의 폼 한 개를 고릅니다.
2. 현재 보이는 입력 항목을 모두 적습니다.
3. 각 항목이 없으면 어떤 기능이 실패하는지 씁니다.
4. 이유를 설명하지 못한 항목은 “수집 보류”로 표시합니다.
5. 저장 위치와 볼 수 있는 역할을 한 칸씩 적습니다.
6. 보관 종료 사건과 삭제 확인 방법을 적습니다.

운영 데이터베이스에서 삭제 명령을 시험하지 마세요. 개인정보 원문, 비밀번호, API 키, 결제 자료를 문서나 AI 채팅에 옮기지 않습니다. 실제 적용 법률과 보관 의무, 백업 복구 영향을 확인하지 못했다면 기존 자료를 일괄 삭제하거나 새 민감정보 수집을 시작하지 말고 담당자와 법률 검토를 받습니다.