사용자 데이터를 다룰 때 코드보다 먼저 정할 것
개인정보 관련 기능은 나중에 붙이기 매우 어렵습니다. 시작할 때 정해두면 비용이 거의 안 듭니다.
처음에 정해야 할 네 가지
- 무엇을 받을 것인가 — 최소한만
- 얼마나 보관할 것인가 — 기한을 필드로 저장
- 누가 볼 수 있는가 — 권한과 접근 기록
- 어떻게 내보내고 지울 것인가 — 요청이 오면 처리 가능해야
민감한 것은 분리해서 저장
신원 정보와 내용을 같은 테이블에 두면 나중에 분리하기 어렵습니다. 익명 처리나 부분 공개가 필요해질 때 구조를 못 바꿉니다.
처음부터 나눠두면 선택지가 남습니다.
삭제는 진짜 삭제여야 합니다
deleted_at만 채우는 소프트 삭제는 실제로는 남아 있는 것입니다. 파기 요청에 대응하려면 물리적 삭제 경로가 있어야 합니다.
백업에 남은 것까지 고려해야 하므로, 백업 보관 주기와 함께 설계해야 합니다.
로그에 찍히지 않게
가장 흔한 실수입니다. 요청 본문을 통째로 로그에 남기면 비밀번호·주민번호·토큰이 그대로 기록됩니다. 마스킹 규칙을 먼저 정하세요.
설계 단계에서 정할 것
| 질문 | 결정 | 나중에 바꾸면 |
|---|---|---|
| 무엇을 받는가 | 수집 항목 | 추가는 쉬움, 제거는 어려움 |
| 어디에 저장하는가 | 테이블 구조 | 매우 어려움 |
| 얼마나 보관하는가 | 보관 기간 필드 | 소급 적용 불가 |
| 누가 보는가 | 권한 모델 | 전면 수정 필요 |
| 어떻게 지우는가 | 삭제 방식 | 구조 변경 필요 |
테이블 구조가 가장 바꾸기 어렵습니다. 신원 정보와 내용을 처음부터 나눠두면 나중에 익명화나 부분 공개가 가능해집니다.
소프트 삭제와 실제 삭제
deleted_at만 채우는 방식은 편리하지만, 파기 요청에 대응할 수 없습니다. 데이터가 그대로 남아 있기 때문입니다.
- 소프트 삭제로 즉시 화면에서 제거
- 일정 기간(예: 30일) 후 실제 삭제
- 백업에서도 보관 주기가 지나면 자연 소멸
- 삭제 요청 시 즉시 실제 삭제 경로 별도 제공
백업 안의 데이터를 어떻게 처리할지가 자주 빠지는 부분입니다. 백업 보관 주기를 명시하고, 그 기간이 지나면 자연히 사라지는 구조가 현실적입니다.
로그 마스킹 규칙
| 대상 | 처리 |
|---|---|
| 비밀번호 | 절대 기록 안 함 |
| 토큰·API 키 | 앞 4자만 또는 완전 제외 |
| 주민등록번호 | 기록 금지 |
| 카드번호 | 앞 6·뒤 4만 |
| 이메일 | 부분 마스킹 |
| 전화번호 | 부분 마스킹 |
요청 본문 전체를 로그에 남기는 코드는 이 모든 것을 한 번에 위반합니다. 프레임워크 기본 설정을 그대로 두면 이런 경우가 많으니 확인하세요.
접근 기록을 남기는 이유
사고가 났을 때 범위를 특정할 수 있습니다. 기록이 없으면 전체가 유출됐다고 가정해야 합니다.
그리고 내부자에 의한 문제도 억제됩니다. 누가 봤는지 남는다는 사실 자체가 예방 효과를 냅니다.
- 누가(계정)
- 언제(시각)
- 무엇을(대상)
- 어떤 행위(조회·수정·삭제·내보내기)
데이터 내보내기 기능
이용자가 자기 데이터를 받아갈 수 있어야 합니다. 이건 권리이기도 하고, 서비스 신뢰의 문제이기도 합니다.
그리고 서비스를 종료할 때도 필요합니다. 미리 만들어 두면 급할 때 곤란하지 않습니다.
- 기계가 읽을 수 있는 형식으로 (CSV·JSON)
- 본인 확인 후 제공
- 대용량이면 비동기 처리 후 링크 발급
- 링크는 만료 시간을 두기
자주 묻는 질문
암호화를 어디까지 해야 하나요?
전송 구간은 기본이고, 저장 시 암호화는 데이터 성격에 따라 결정합니다. 민감정보일수록 강하게 적용해야 합니다.
개인정보 처리방침에 무엇을 적어야 하나요?
실제 처리 내용과 일치해야 합니다. 수집 항목·목적·보유기간·위탁·이용자 권리가 기본입니다.
해외 서버에 저장해도 되나요?
가능하지만 국외 이전에 대한 고지·동의 요건이 있을 수 있습니다. 확인이 필요합니다.
같이 보면 좋은 글
서버를 열어두면 바로 시작되는 공격들실제 로그에서 관찰되는 스캔 유형과 최소한의 방어. 서버를 인터넷에 열면 몇 분 안에 스캔이 시작됩니다. 유명하지 않아도 상관…백업, 복구해 본 적 없으면 백업이 아닙니다무엇을 어디에 얼마나 자주. 그리고 반드시 해봐야 하는 것. 백업이 돌고 있다는 사실만으로는 아무것도 보장되지 않습니다. 복구…도메인을 여러 개 갖고 있을 때 생기는 일만료·방치·중복. 도메인이 늘어날 때 실제로 생기는 문제와 정리 기준. 도메인은 사기 쉽고 관리하기 어렵습니다. 특히 쓰지 않…검색엔진이 들어오게 만드는 최소 설정콘텐츠를 아무리 써도 이게 없으면 발견되지 않습니다. 검색엔진은 발견 → 크롤 → 색인 순서로 움직입니다. 첫 단계에서 막히면…검색에서 읽히는 글의 구조잘 쓴 글과 검색에서 잘 읽히는 글은 구조가 다릅니다. 검색으로 들어온 사람은 답을 찾으러 온 것입니다. 서론이 길면…혼자 만든 서비스가 조용히 죽는 이유기술 문제가 아니라 운영 문제로 멈춥니다. 실제로 자주 보는 원인들. 서비스는 대개 극적으로 망하지 않습니다. 조용히 방치되다…