플랫폼이 민감 콘텐츠 정책을 바꾸면 "이 사용자가 성인인가", "최근에 어떤 콘텐츠를 봤는가" 같은 판별 로직이 한꺼번에 늘어납니다. 기능 하나를 추가하는 것처럼 보이지만, 생년월일과 본인확인 결과, 이용 이력이 같은 파이프라인으로 모이기 시작하면 개인정보가 한곳에 쌓이는 구조가 됩니다.
이 글에서는 판별에 꼭 필요한 속성만 받고, 원본 대신 판별 결과만 남기며, 보관기간과 접근권한을 정하는 순서를 다룹니다. 법령 해석이나 정책의 세부 기준은 이 글에서 단정하지 않으니, 최종 기준은 법무·개인정보 담당 부서와 해당 기관의 공지에서 확인하셔야 합니다.
판별 질문을 먼저 한 문장으로 고정하세요
연령 판별 요구는 보통 "정확한 나이"로 시작하지만, 실제로 서비스가 필요한 답은 "기준 연령 이상인지 여부"인 경우가 대부분입니다. 질문을 먼저 고정하면 필요한 속성의 범위가 자연스럽게 줄어듭니다.
요구사항 문서에는 질문, 사용 목적, 결과 형식(참/거짓, 등급 등), 판단을 다시 하는 주기를 한 줄씩 적어 두세요. 이 네 줄이 이후 입력 스키마와 보관 기간을 정하는 기준이 됩니다.
필요한 속성만 받는 입력 설계
외부 본인확인이나 회원 프로필에서 받을 수 있는 값은 많지만, 서비스가 실제로 쓰는 값은 그보다 적습니다. 수신 단계에 필드 허용 목록을 두고, 목록에 없는 필드는 저장하기 전에 버리는 방식을 권장합니다.
필드별로 "없으면 판단이 안 되는가"를 물으세요
각 필드마다 이 값이 없으면 어떤 판단이 불가능한지 적어 봅니다. 답이 없는 필드는 수집하지 않는 쪽이 맞습니다. 전체 생년월일이 필요한지, 출생연도만으로 충분한지도 이 과정에서 같이 정리됩니다.
한 커머스 팀은 연령대별 노출 제한 기능을 만들면서 생년월일 전체와 주문 이력을 함께 가져왔습니다. 설계 검토에서 실제 필요한 값은 "제한 대상 여부 플래그 하나"였습니다. 질문을 먼저 고정하고 나서 입력 필드가 절반 이하로 줄었습니다.
그 뒤에 살펴볼 곳은 로그입니다. 같은 팀은 정책 변경 후 판별 API 호출이 늘었을 때 디버그 로그에 요청 본문이 그대로 찍히는 것을 발견했습니다. 로그 마스킹 규칙과 배포 전 점검 항목에 "개인정보 필드가 로그와 에러 리포트에 남는지"를 추가해 재발을 막았습니다.
원본 대신 판별 결과만 남기기
판별이 끝나면 생년월일과 이용 이력 원본은 지우고, 결과만 남기는 구조를 권장합니다. 예를 들어 age_gate = adult_verified, verified_at, policy_version 같은 형태로 저장하면 서비스는 원본 없이도 판단을 이어갈 수 있습니다.
정책 버전을 함께 저장하는 것도 중요합니다. 나중에 기준이 바뀌었을 때 과거 판단이 어떤 기준으로 이루어졌는지 설명할 수 있고, 재판별 대상도 버전 단위로 골라낼 수 있습니다.
보관기간은 목적이 끝나는 날로 정하기
보관기간을 "1년"처럼 숫자로 먼저 정하면 실제 목적과 어긋나기 쉽습니다. 판별 목적이 끝나는 시점을 기준으로 잡고, 그 기준에 맞춰 숫자를 채우는 순서가 안전합니다.
판별 결과에는 유효기간을 두고 기간이 지나면 다시 판별합니다. 원본 임시 값은 판별 직후 파기하며, 로그에 남는 값도 보관 기간을 별도로 정합니다. 구체적인 기간은 법령과 내부 규정에서 확정해야 합니다.
| 데이터 | 보관 방식 | 점검 기준 |
|---|---|---|
| 생년월일 원본 | 판별 직후 파기 | 임시 저장소와 캐시에도 남지 않는지 확인 |
| 판별 결과 플래그 | 유효기간 후 재판별 | 정책 버전과 판별 시각을 함께 저장 |
| 이용 이력 원본 | 집계 후 삭제 또는 가명처리 | 로그와 백업에 원본이 포함되는지 점검 |
| 판별 감사 로그 | 접근 기록 별도 보관 | 조회자, 시각, 사유를 함께 기록 |
접근권한은 최소로, 원본 조회는 예외 절차로
판별 결과를 읽는 권한과 원본을 다루는 권한은 분리해야 합니다. 서비스 서버는 결과 플래그만 읽고, 원본 테이블은 배치 작업 계정만 접근하도록 나누는 것이 기본입니다. 개발 환경과 분석 환경에 원본이 복제되지 않는지도 함께 확인하세요.
고객 문의 등으로 원본을 봐야 하는 상황은 예외 절차로 분리합니다. 요청자, 승인자, 사유, 조회 시각을 감사 로그에 남기고, 주기적으로 기록을 검토하면 권한이 조용히 넓어지는 것을 막을 수 있습니다.
바로 해 볼 순서
- 판별 질문을 한 문장으로 적고, 결과 형식과 재판별 주기를 함께 정합니다.
- 현재 입력 스키마의 필드를 나열하고, 없으면 판단이 안 되는 필드만 남깁니다.
- 애플리케이션 로그, 에러 리포트, 백업 대상에 원본 필드가 있는지 검색해 확인합니다.
- 판별 결과 테이블에 정책 버전, 판별 시각, 유효기간 컬럼을 추가하고 원본은 판별 직후 파기하도록 배치 작업을 정합니다.
- 원본 테이블과 결과 테이블의 접근 권한을 나누고, 예외 조회 절차와 감사 로그를 문서로 남깁니다.
자주 묻는 질문
나이 확인에 고유식별정보를 받아도 되나요?
받을 수 있는지는 법령 요건과 개인정보 처리방침, 내부 검토 결과에 따라 달라집니다. 기술 설계에서는 확인 결과만 받는 방식을 먼저 검토하고, 원본을 받아야 하는 경우에는 법무 또는 개인정보 담당 부서의 확인을 거친 뒤 수집 범위를 확정하세요.
판별 결과는 영구 보관해도 되나요?
판별 목적이 유지되는 기간과 유효기간을 기준으로 정하는 것이 일반적인 설계 방향입니다. 영구 보관이 꼭 필요하다면 그 목적과 근거를 문서로 남기고, 승인 절차를 거치도록 하세요.
정책 버전은 왜 같이 저장하나요?
정책이 바뀌면 과거 판별 결과가 지금 기준에서도 유효한지 판단해야 하는데, 버전이 없으면 재판별 대상을 골라낼 수 없습니다. 버전과 판별 시각이 있으면 "언제, 어떤 기준으로 판단했는지"를 감사 때 바로 설명할 수 있습니다.
정리
- 판별 질문을 먼저 고정하고, 없으면 판단이 안 되는 필드만 받습니다.
- 원본은 판별 직후 파기하고, 결과 플래그에는 정책 버전과 유효기간을 함께 둡니다.
- 원본 접근은 예외 절차와 감사 로그로 묶어 관리합니다.
오늘 할 일: 현재 판별 기능이 받는 입력 필드를 모두 적고, 필드마다 "없으면 판단이 안 되는가"를 표시해 보세요.
댓글