먼저 개인정보가 뭔지 정확히 알아야 합니다. 이름, 전화번호, 이메일처럼 그 자체로 누구인지 알 수 있는 정보만 개인정보가 아닙니다. 특정 데이터를 조합해서 그 사람까지 연결될 수 있다면 그것도 개인정보입니다. 예를 들어 기기 ID + 접속 위치 + 구매 이력을 합치면 특정 개인을 식별할 수 있고, 이런 데이터도 개인정보보호법의 적용을 받습니다.

개인정보보호법 위반 시 전체 매출의 최대 3%에 해당하는 과징금이 부과될 수 있습니다. 벌금 문제를 떠나서, 서비스 런칭 후 개인정보 처리 구조를 변경하려면 데이터베이스 재설계까지 필요할 수 있어 비용이 기하급수적으로 증가합니다.

그래서 개인정보 보호는 개발 단계에서부터 설계에 반영되어야 합니다. 프로덕트 메이커가 모든 프로젝트에 기본으로 적용하는 보안 원칙들을 정리합니다.

비밀번호는 반드시 bcrypt로 해싱하라

비밀번호를 평문이나 단순 해시(MD5, SHA-1)로 저장하는 것은 가장 심각한 보안 실수입니다. 비밀번호 보안에는 단방향 해싱(복호화 불가), 솔트(같은 비밀번호도 DB에 다른 값으로 저장), 키 스트레칭(무차별 대입 속도를 극도로 느리게), 페퍼(서버만 아는 추가 비밀 값) 등의 기법이 사용됩니다. (자세한 내용은 "로그인 기능, 생각보다 복잡한 이유" 포스트에서 다루고 있습니다.)

중요한 것은 비밀번호를 절대로 복호화 가능한 형태로 저장하지 않는 것입니다. 비밀번호 찾기 기능은 기존 비밀번호를 알려주는 것이 아니라 새 비밀번호를 설정하도록 해야 합니다.

최소 수집 원칙을 지켜라

개인정보보호법의 핵심 원칙은 목적에 필요한 최소한의 정보만 수집하는 것입니다. 회원가입 시 주민등록번호, 상세 주소, 직업 등을 필수로 요구하는 서비스가 여전히 있지만, 서비스 제공에 실제로 필요하지 않은 정보는 수집해서는 안 됩니다.

최악의 케이스를 많이 봅니다. "나중에 필요할 것 같아서"라는 이유로 실명 인증부터 시작해서 주민등록번호, 상세 주소, 직업, 소득 수준까지 회원가입에 전부 넣어두는 경우입니다. 필요할 때 추가 수집하면 되는데, 처음부터 모든 개인정보를 저장해버립니다. 결국 쓰지도 않는 데이터가 DB에 쌓이고, 유출 사고가 나면 피해 범위가 불필요하게 커집니다. 수집하지 않은 데이터는 유출될 수도 없다는 사실을 기억하세요.

데이터베이스 스키마 설계 단계에서 각 필드가 정말 필요한지 검토하고, 선택 항목과 필수 항목을 명확히 구분합니다. 서비스 초기에는 이메일과 비밀번호만으로 가입을 받고, 이름이나 전화번호는 실제 필요한 시점(예: 배송, 본인 확인)에 추가 수집하는 것이 바람직합니다.

암호화와 리스트 조회 성능 문제

개인정보를 암호화해서 저장하는 것은 당연합니다. 문제는 암호화된 데이터를 리스트로 조회할 때 발생하는 성능 문제입니다. 관리자 페이지에서 회원 목록을 조회할 때, 이름이나 전화번호가 암호화되어 있으면 매 건마다 복호화를 해야 화면에 표시할 수 있습니다.

회원이 100명이면 100번, 10,000명이면 10,000번 복호화 연산이 발생합니다. 검색은 더 문제입니다. "김철수"라는 이름으로 검색하려면 DB에 저장된 모든 암호화된 이름을 복호화해서 비교해야 하는데, 인덱스를 태울 수 없으니 풀스캔이 됩니다. 회원 수가 많아질수록 관리자 페이지가 점점 느려지고, 결국 "회원 검색이 30초 걸린다"는 문제가 터집니다.

이 문제를 해결하려면 설계 단계에서 고려가 필요합니다. 검색에 사용되는 필드는 단방향 해시 인덱스를 별도로 유지하거나, 부분 검색이 필요한 경우 앞 몇 자리만 별도 컬럼에 저장하는 방식 등을 사용합니다. 암호화는 보안을 위해 필수이지만, 운영 편의와 성능 사이의 균형을 설계 초기에 잡아야 나중에 전면 재설계를 피할 수 있습니다.

SSL/HTTPS는 기본 중의 기본

2026년 현재 HTTPS가 아닌 사이트는 브라우저에서 경고를 표시합니다. 모든 통신은 SSL/TLS로 암호화되어야 하며, HTTP 요청은 자동으로 HTTPS로 리다이렉트해야 합니다. Let's Encrypt를 사용하면 무료로 SSL 인증서를 발급받을 수 있고, Google Cloud Load Balancer나 Cloudflare를 통해 자동 갱신까지 가능합니다.

API 통신뿐 아니라 관리자 페이지, 내부 도구까지 모두 HTTPS를 적용해야 합니다.

놀랍게도 저희에게 프로젝트 이관을 요청하시는 클라이언트 중 HTTPS가 적용되지 않은 사이트가 간헐적으로 있습니다. 매월 유지보수 비용을 받아가면서 SSL 인증서조차 적용하지 않은 개발사가 있다는 뜻입니다. 2026년에 HTTP 사이트는 브라우저가 안전하지 않음을 표시하고, 검색엔진 순위에서도 불이익을 받습니다. 무료 인증서로 10분이면 되는 작업입니다.

회원 탈퇴 시 데이터 삭제

사용자가 회원 탈퇴를 요청하면 개인정보를 지체 없이 파기해야 합니다. 다만 전자상거래법에 따라 거래 기록은 5년간 보관 의무가 있으므로, 개인 식별 정보와 거래 기록을 분리하여 관리하는 설계가 필요합니다. 프로덕트 메이커는 탈퇴 시 이름, 이메일, 전화번호를 비가역적으로 마스킹 처리하고, 거래 기록은 익명화된 상태로 법정 보관 기간만큼 유지하는 구조를 적용합니다.

이를 위해 개인정보 테이블과 트랜잭션 테이블을 처음부터 분리하여 설계합니다.

GDPR과 글로벌 서비스

해외 사용자를 대상으로 하는 서비스라면 EU의 GDPR도 고려해야 합니다. GDPR은 데이터 처리 동의의 명시성, 잊힐 권리(Right to be Forgotten), 데이터 이동권(Data Portability)을 요구합니다.

쿠키 배너에서 사전 동의를 받아야 하고, 사용자가 자신의 데이터를 JSON 형태로 다운로드할 수 있어야 합니다. 프로덕트 메이커는 모든 프로젝트에서 HTTPS 적용, 비밀번호 암호화, 적절한 인증 체계, 데이터 생명주기 관리를 기본 보안 요소로 포함합니다.

보안은 부가 기능이 아니라 아키텍처의 일부여야 합니다.

개인정보 처리방침 페이지

법적으로 개인정보 처리방침 페이지를 반드시 제공해야 하며, 수집 항목, 수집 목적, 보관 기간, 제3자 제공 여부, 파기 절차를 명시해야 합니다. 이 페이지는 회원가입 과정에서 동의 체크박스와 연결되어야 하고, 내용이 변경될 때마다 사용자에게 재동의를 받아야 합니다.

프로덕트 메이커는 프로젝트 초기 기획 단계에서 개인정보 처리방침을 함께 검토하고, 이를 기반으로 데이터 수집 범위와 DB 스키마를 결정합니다.

로그 관리와 접근 통제

개인정보에 접근한 이력을 기록하는 접근 로그는 법적 의무이자 보안 사고 대응의 핵심입니다. 관리자 페이지에서 회원 정보를 조회할 때마다 누가, 언제, 어떤 정보를 열람했는지 기록해야 합니다. Django에서는 미들웨어를 통해 관리자 API 호출을 자동으로 로깅할 수 있습니다.

또한 관리자 권한도 역할별로 세분화하여 전체 회원 목록 조회, 개별 회원 상세 조회, 개인정보 다운로드 등 각 기능에 별도 권한을 부여해야 합니다. 프로덕트 메이커는 모든 프로젝트에서 역할 기반 접근 제어(RBAC)를 기본으로 구현하며, 개인정보 관련 API에는 반드시 감사 로그를 남기는 것을 원칙으로 합니다.