문구를 복사하기 전에 한 기능의 데이터가 어디로 가는지 그려봅니다. 댓글 인증과 DB 저장은 같은 정보가 같은 방식으로 남는 과정이 아닙니다.
개인정보처리방침을 쓰려고 템플릿을 열었는데 “어떤 정보를 보관하나요?”에서 멈춘다면 코드와 DB를 먼저 봐야 합니다. 사용자 화면의 입력 항목만으로는 인증 서비스, 알림 메일과 로그의 처리를 알기 어렵습니다.
이 홈페이지의 댓글 한 건을 따라가 봤습니다
2026년 10월 23일 서버 코드를 확인했습니다. Google 인증 정보를 검증해 이메일을 확인한 뒤, 댓글 DB에는 일부를 가린 이메일을 이름으로 저장합니다. 원본 이메일과 Google 인증 토큰을 comments 테이블에 저장하는 구조는 아닙니다.
| 단계 | 확인한 정보 | 문서에 반영할 구분 |
| 인증 | 브라우저의 Google 인증 정보 | 사용자 확인 과정과 외부 서비스 |
| 저장 | post_slug, name, body, status, created_at | 댓글 DB에 실제 남는 항목 |
| 공개 | 가린 아이디와 댓글 | 다른 방문자에게 보이는 정보 |
| 운영 | 관리자 댓글 관리 | 삭제 요청과 권한 확인 절차 |
가린 이메일만 같다고 동일인임을 확정할 수는 없습니다. 삭제 요청의 권한 확인도 별도 운영 절차입니다. 또한 comments 테이블에 원본이 없다는 사실만으로 모든 외부 서비스·접속 로그에 정보가 전혀 없다고 결론 내리지 않습니다.
하나의 필드에 저장 위치와 삭제 기준을 붙입니다
데이터 흐름 조사표에는 기능, 필드, 출처, 목적, 저장·전달 대상, 삭제 조건과 미결정 상태를 나눴습니다. 홈페이지의 댓글 동작과 가상의 확장 예시가 섞여 있으므로 decision_status를 읽고 자신의 서비스에 맞게 편집합니다.
필드: reply_email
목적: 문의 회신
저장 위치: 문의 DB / 알림 메일함을 각각 확인
보관 기간: 운영자 결정 필요
삭제 경로: 요청자 확인 후 DB와 관련 사본 검토보관 기간이 정해지지 않았다면 미정이라고 조사표에 남기고 결정할 사람을 정합니다. “일정 기간 후 파기”라고 문서만 적어 실제 삭제 기능이 없는 상태를 덮지 않습니다. 이 사이트 역시 자동 보관기한 삭제가 적용돼 있지 않아 기간과 사본 처리 기준은 운영자 결정이 남아 있습니다.
앱 문서로 옮길 때는 SDK도 같은 방식으로 봅니다
Google Play 사용자 데이터 정책는 앱과 서드파티 코드의 처리를 투명하게 공개하도록 안내합니다. 앱에 분석·광고·인증 SDK가 있다면 제공업체 문서와 실제 전송을 조사해 같은 표에 넣습니다. 홈페이지의 처리방침을 앱에 그대로 복사하지 않습니다.
조사표가 채워지면 방침의 항목과 앱스토어 공개 내용에 연결하고, 실제 화면의 연락·삭제 경로가 작동하는지 확인합니다. 법적 필수 항목과 국외 이전 등의 검토는 개인정보보호포털의 최신 안내와 필요한 전문 검토를 따릅니다. 이 사례 조사만으로 개별 서비스의 법적 적합성이 완성되는 것은 아닙니다.
댓글
0개아직 표시된 댓글이 없습니다.