개인정보 처리방침 작성법: 실제 데이터 흐름과 어긋나는 6곳

개인정보 처리방침은 템플릿을 고쳐 쓰는 문서가 아닙니다. 지금 서비스 코드와 인프라가 실제로 하는 일을 받아 적는 문서입니다. 그래서 순서도 반대로 가야 합니다. 먼저 저장소와 클라우드 콘솔에서 개인정보가 어디로 흘러가는지 목록을 만들고, 그 목록을 처리방침 항목(수집 항목, 보유 기간, 위탁, 국외이전, 쿠키 등)에 옮겨 적은 뒤에 문장을 다듬습니다.

템플릿을 그대로 쓰면 생기는 문제는 대개 두 가지입니다. 실제로 쓰는 SaaS나 해외 리전이 빠지는 것, 그리고 "탈퇴 시 지체 없이 파기" 같은 문장과 달리 로그와 백업이 몇 년씩 남는 것입니다. 이 글에서는 점검 현장에서 처리방침과 실제 데이터 흐름이 자주 어긋나는 6곳을 골라, 각각을 코드와 인프라에서 찾는 방법과 고치는 방법을 정리했습니다.

참고로 개인정보보호위원회는 2025년 4월 「개인정보 처리방침 작성지침」을 개정하면서 법령상 필수 사항과 권장 사항을 나눠 정리했습니다. 2026년 4월에는 생성형 AI와 온디바이스 처리를 다룬 내용을 더해 다시 개정했습니다. 해마다 업종을 골라 처리방침을 평가하고 개선을 권고하기도 합니다. 문구를 확정하기 전에는 위원회가 공개한 최신 지침 원문을 꼭 대조하시기 바랍니다.

시작 전에: 데이터 흐름 인벤토리부터 만든다

처리방침을 열기 전에 한 페이지짜리 인벤토리를 먼저 만듭니다. 형식은 상관없지만 저장소에 파일로 두면 코드 리뷰에서 함께 갱신하기 좋습니다.

# privacy/data-inventory.yaml (가상의 예시)
- name: 회원 DB
  items: [email, name, phone, hashed_password, signup_ip]
  location: aws/ap-northeast-2/rds
  retention: 탈퇴 시 삭제, 백업 35일
- name: 에러 모니터링
  vendor: Sentry
  items: [user_id, ip, request_url]
  location: 미국
  purpose: 장애 분석
  retention: 90일
- name: 트랜잭션 메일
  vendor: 메일 발송 SaaS
  items: [email, name]
  location: 미국
  purpose: 가입 인증·비밀번호 재설정 메일

처음 목록을 채울 때는 저장소에서 외부 SDK와 엔드포인트부터 훑으면 빠릅니다.

# 의존성에서 외부 서비스 SDK 후보 찾기
grep -E '"(@sentry|mixpanel|amplitude|@amplitude|posthog|@segment|firebase|@sendgrid|twilio|intercom|channel)' package.json

# 코드와 설정에 박힌 외부 도메인 찾기
grep -rhoE 'https://[a-zA-Z0-9.-]+\.(com|io|net|co)' src/ config/ | sort | uniq -c | sort -rn | head -50

# 환경변수 이름은 연동 서비스 목록 그 자체다
grep -oE '^[A-Z_]+(_API_KEY|_DSN|_TOKEN|_SECRET)' .env.example

이렇게 나온 결과를 앞으로 볼 6곳에 하나씩 대입하면 됩니다.

1. 수집 항목: 가입 폼이 아니라 DB 스키마와 로그를 본다

템플릿의 수집 항목은 보통 "이메일, 비밀번호, 이름, 휴대전화번호"에서 끝납니다. 실제로는 이보다 많이 모읍니다. 가입 시 IP, 기기 식별자, 푸시 토큰, 앱 버전, 결제 시 카드사 응답값, 고객센터 채팅 내용 같은 것들입니다.

확인 방법은 단순합니다.

• 마이그레이션 파일이나 ORM 모델에서 users와 관련 테이블의 컬럼을 전부 뽑습니다.
• 요청 로그 포맷을 확인합니다. 액세스 로그에 IP, User-Agent, 쿼리스트링이 남는다면 그것도 수집 항목입니다.
• 모바일 앱이면 광고 식별자(ADID/IDFA)와 위치 권한을 쓰는지 확인합니다.

# 가상의 Django 모델: 처리방침에 없는 컬럼이 숨어 있는 예
class User(AbstractUser):
    phone = models.CharField(max_length=20)
    signup_ip = models.GenericIPAddressField()      # 처리방침 누락 1
    device_id = models.CharField(max_length=64)     # 처리방침 누락 2
    marketing_agreed_at = models.DateTimeField(null=True)

판단 기준은 이렇습니다. 서비스 이용 과정에서 자동으로 생성되어 수집되는 정보(IP, 쿠키, 접속 일시, 기기 정보)도 따로 적습니다. 필수와 선택도 실제 폼의 required 여부와 일치해야 합니다. 로그에 쓸데없이 많은 항목이 남고 있다면 처리방침에 적기 전에 줄이는 편이 낫습니다. 로그에서 개인정보를 줄이는 방법은 개인정보 마스킹 체크리스트에 정리해 두었습니다.

2. 처리위탁: package.json에 있는 SaaS가 곧 수탁자 후보다

처리방침의 위탁 표에 결제대행사와 본인인증 업체만 있고, 실제로 쓰는 이메일 발송, SMS, 고객 채팅, 에러 모니터링, 데이터 분석 SaaS는 빠져 있는 경우가 가장 흔합니다. 외부 업체가 우리 서비스를 위해 이용자 개인정보를 받아 처리한다면 위탁으로 보고 검토해야 합니다.

에러 모니터링은 특히 놓치기 쉽습니다. 설정에 따라 IP, 쿠키, 요청 본문까지 함께 전송되기 때문입니다.

// 수정 전: 기본 PII 전송을 켜 두고, 요청 본문도 그대로 보냄
Sentry.init({
  dsn: process.env.SENTRY_DSN,
  sendDefaultPii: true,
});

// 수정 후: 필요한 식별자만 남기고 민감 필드는 지운 뒤 전송
Sentry.init({
  dsn: process.env.SENTRY_DSN,
  sendDefaultPii: false,
  beforeSend(event) {
    if (event.request) {
      delete event.request.cookies;
      delete event.request.data;
    }
    if (event.user) {
      event.user = { id: event.user.id }; // 내부 ID만
    }
    return event;
  },
});

고친 뒤에도 내부 사용자 ID가 넘어간다면 처리방침의 위탁 항목에 업체명과 위탁 업무를 적습니다. 점검할 때 보는 기준은 세 가지입니다.

• 이용자 정보가 업체 서버로 넘어가는가 (넘어가지 않는 순수 인프라 도구인지)
• 그 업체가 우리 목적을 위해 처리하는가, 아니면 자기 목적으로도 쓰는가 (후자라면 제3자 제공 여부를 따로 검토)
• 위탁 계약(DPA 등)을 맺었고, 처리방침의 업체명이 실제 계약 법인명과 일치하는가

3. 국외이전: 리전과 SaaS 서버 위치를 확인한다

국내 리전에 서버를 두었다고 국외이전이 없는 것은 아닙니다. 메일 발송, 분석, 에러 모니터링, 고객 지원 SaaS 상당수는 해외 데이터센터에 데이터를 저장합니다. 반대로 메인 DB는 서울 리전인데, 누군가 테스트로 만든 S3 버킷이 다른 리전에 남아 있는 경우도 있습니다.

# 모든 리전에서 리소스 위치 확인 (읽기 전용 명령)
aws s3api list-buckets --query 'Buckets[].Name' --output text \
  | xargs -n1 -I{} sh -c 'echo "{} $(aws s3api get-bucket-location --bucket {} --output text)"'

for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "$r: $(aws rds describe-db-instances --region $r --query 'length(DBInstances)')"
done

SaaS는 각 업체의 데이터 저장 위치 안내나 DPA 부속서(서브프로세서 목록)를 확인하고, 가능하면 EU나 국내 리전 옵션이 있는지도 봅니다. 국외이전 사실이 있으면 처리방침에 적을 내용이 늘어납니다. 보통 이전되는 항목, 이전 국가, 이전 시기와 방법, 이전받는 자(업체명과 연락처), 이용 목적과 보유 기간, 거부 방법과 거부 시 효과를 적는데, 구체적인 기재 요건은 작성지침 원문으로 확인합니다. 인벤토리에 location 필드를 처음부터 넣어 두라고 한 이유가 이것입니다.

4. 보유 기간: "지체 없이 파기"와 무기한 로그

처리방침의 보유 기간 문구와 인프라 설정이 가장 크게 어긋나는 곳입니다. 애플리케이션 DB에서는 탈퇴 회원을 지워도, 로그 그룹 보존 기간은 "만료 없음", S3 로그 버킷에는 수명주기 규칙이 없고, 분석 도구에는 기본 보존 기간이 그대로 적용되어 있는 식입니다.

# 수정 전: 보존 기간을 지정하지 않으면 로그가 무기한 쌓인다
resource "aws_cloudwatch_log_group" "api" {
  name = "/example/api"
}

# 수정 후: 처리방침에 적은 기간과 같은 값을 코드로 고정
resource "aws_cloudwatch_log_group" "api" {
  name              = "/example/api"
  retention_in_days = 90
}

resource "aws_s3_bucket_lifecycle_configuration" "access_logs" {
  bucket = aws_s3_bucket.access_logs.id
  rule {
    id     = "expire-access-logs"
    status = "Enabled"
    filter {}
    expiration { days = 90 }
  }
}

반대로 최소 기간이 정해진 기록도 있습니다. 「개인정보의 안전성 확보조치 기준」은 개인정보처리시스템 접속기록(직원·운영자가 시스템에 접속해 개인정보를 처리한 기록)을 1년 이상, 5만 명 이상의 정보주체를 처리하거나 고유식별정보·민감정보를 처리하는 시스템은 2년 이상 보관하도록 정하고 있습니다. 이 접속기록과 일반 이용자 액세스 로그는 성격이 다르므로 섞지 말고 따로 관리합니다.

점검 기준은 "처리방침의 기간 = 설정 파일에 적힌 기간"입니다. 백업 보존 기간(RDS 자동 백업, 스냅샷)과 분석 SaaS의 데이터 보존 설정까지 함께 봅니다. 탈퇴 이후 DB, 백업, 로그를 어떻게 처리할지는 개인정보 파기 방법에서 자세히 다뤘습니다.

5. 쿠키와 행태정보: 태그 관리자 안을 들여다본다

템플릿에는 "쿠키는 이용자 식별과 로그인 유지를 위해 사용하며, 브라우저 설정으로 거부할 수 있습니다" 정도만 적혀 있는 경우가 많습니다. 하지만 실제 페이지에는 웹 분석 스크립트, 광고 픽셀, A/B 테스트 도구가 태그 관리자를 통해 붙어 있고, 마케팅팀이 코드 배포 없이 추가하기 때문에 개발팀은 모르는 경우가 많습니다.

확인 방법은 이렇습니다.

• 브라우저 개발자 도구의 Application 탭에서 쿠키와 localStorage 목록을 확인하고, Network 탭에서 제3자 도메인 요청을 봅니다.
• 태그 관리자 컨테이너를 내보내기(export)해서 실제로 활성화된 태그를 확인합니다.
• 모바일 앱이라면 광고·분석 SDK와 광고 식별자 사용 여부를 확인합니다.

<!-- 수정 전: 페이지 로드 즉시 광고 픽셀과 분석 스크립트 실행 -->
<script src="https://ads.example.com/pixel.js"></script>

// 수정 후: 이용자가 선택한 범주에 따라서만 로드
function loadTrackers(consent) {
  if (consent.analytics) loadScript("https://analytics.example.com/tag.js");
  if (consent.ads) loadScript("https://ads.example.com/pixel.js");
}
loadTrackers(getStoredConsent() ?? { analytics: false, ads: false });

개인정보보호위원회는 2024년 1월 맞춤형 광고용 행태정보 보호 정책 방안을 발표하면서, 자사 맞춤형 광고를 위해 행태정보를 처리하는 웹·앱 사업자에게도 광고 사업자와 같은 기준을 적용하겠다는 방향을 밝혔습니다. 2025년 개정 작성지침도 쿠키와 맞춤형 광고 거부 방법을 안내하도록 했습니다. 따라서 처리방침에는 사용하는 행태정보 수집 도구, 수집 목적, 거부 방법을 실제 구성에 맞게 적고, 동의를 받는 범위가 어디까지인지는 서비스 구조에 맞춰 검토합니다.

6. 생성형 AI API: 사용자 입력이 외부 모델로 나간다

최근 가장 빠르게 늘어난 데이터 흐름입니다. 상담 요약, 리뷰 분류, 챗봇 기능을 붙이면서 사용자가 입력한 텍스트나 업로드한 파일이 외부 LLM API로 전송되는데, 처리방침에는 반영되지 않는 경우가 많습니다. 2026년 4월 개정 작성지침은 생성형 AI 서비스용 부록을 새로 두고 입력 정보의 수집·저장 여부, 학습 활용 여부, 거부 절차 등을 안내하도록 했습니다(필수와 권장의 구분은 원문으로 확인하시기 바랍니다).

# 수정 전: 상담 원문을 그대로 외부 API에 전송
summary = llm.summarize(ticket.body)

# 수정 후: 전송 전에 식별 정보를 치환하고, 전송 사실을 인벤토리에 기록
redacted = redact(ticket.body, patterns=[PHONE, EMAIL, RRN, CARD])
summary = llm.summarize(redacted)

점검할 때는 다음을 확인합니다. API 제공자가 입력 데이터를 얼마나 보관하는지, 학습에 쓰는지, 서버가 어느 국가에 있는지입니다. 이 답은 2번(위탁)과 3번(국외이전) 항목에 그대로 이어집니다. 기능이 단말기 안에서만 동작하더라도 결과가 서버에 저장된다면 처리방침 대상이라는 점도 기억해 두면 좋습니다.

처리방침을 코드와 함께 유지하는 방법

한 번 맞춰 놓아도 다음 스프린트에 새 SDK가 들어오면 다시 어긋납니다. 운영 체크리스트로 묶어 두는 것이 현실적입니다.

• data-inventory.yaml을 저장소에 두고, 외부 SDK 추가 PR에서는 인벤토리 수정을 필수로 한다
• CI에서 package.json의 신규 의존성이 허용 목록에 없으면 경고한다
• Terraform에서 로그 그룹 retention_in_days 미지정 리소스를 정적 분석으로 막는다
• 분기마다 태그 관리자 컨테이너와 쿠키 목록을 처리방침과 대조한다
• 위탁·국외이전 업체가 바뀌면 처리방침 변경 이력과 시행일을 갱신한다
• 처리방침 문구 변경은 법무·개인정보 담당자가, 인벤토리는 개발팀이 책임지는 식으로 역할을 나눈다

자주 묻는 질문

다른 회사 처리방침을 참고해서 써도 되나요?

구조와 표현은 참고해도 됩니다. 다만 수집 항목, 위탁 업체, 국외이전, 보유 기간, 쿠키 내역은 회사마다 다르므로 반드시 자사 인벤토리로 채워야 합니다. 남의 처리방침을 그대로 옮기면 실제와 다른 내용을 공개하는 셈이 됩니다.

AWS 서울 리전만 쓰면 국외이전 항목은 비워도 되나요?

메인 인프라만 보고 판단하면 안 됩니다. 메일 발송, 에러 모니터링, 분석, 고객 지원, AI API처럼 이용자 정보를 받는 SaaS의 저장 위치를 하나씩 확인한 뒤에 판단해야 합니다. 실제로는 이쪽에서 국외이전이 생기는 경우가 많습니다.

개발팀이 처리방침까지 책임져야 하나요?

문구와 법적 판단은 개인정보 보호책임자나 법무가 맡는 것이 맞습니다. 하지만 "무엇이 어디로 얼마 동안 가는가"라는 사실관계는 개발팀만 정확히 압니다. 인벤토리를 개발팀이 유지하고 담당자가 이를 문서로 옮기는 분업이 가장 현실적입니다.

정리

• 처리방침은 템플릿에서 출발하지 말고 코드·인프라에서 뽑은 데이터 흐름 인벤토리에서 출발합니다.
• 자주 어긋나는 곳은 숨은 수집 항목, SaaS 위탁, 해외 저장 위치, 로그·백업 보존 기간, 태그 관리자 속 쿠키, 생성형 AI API 전송입니다.
• 보유 기간은 문장이 아니라 retention_in_days와 수명주기 규칙 같은 설정값으로 지키고, 처리방침과 같은 숫자인지 대조합니다.
• 인벤토리를 PR과 CI에 묶어 두어야 처리방침이 계속 실제와 맞게 유지됩니다. 직접 점검하기 어렵다면 무료 분석 신청으로 현재 구성을 함께 살펴볼 수 있습니다.