서버 방문 측정, 개인정보 수집 최소화 4단계

서버 방문 측정에서 개인정보를 줄이려면 수집 최소화 순서를 따릅니다. 먼저 측정 목적을 정하고, 목적에 없는 항목은 로그 형식에서 뺍니다. IP 주소처럼 개인정보가 될 수 있는 값은 요청을 받을 때 확인 결과로 바꾸고, 원래 값은 저장하지 않습니다.

AI·검색 봇의 수집 신호는 누가, 어느 페이지를, 언제, 어떤 응답으로 가져갔는지로 읽습니다. 실무에서는 이 네 가지를 채우는 항목만 남기는 것이 적합합니다. 사람 방문자의 상세 기록은 측정 기록과 분리합니다.

서버 기록에서 개인정보가 섞이는 지점은 어디인가요?

웹 서버는 따로 설정하지 않아도 기본 형식으로 접속 기록을 남깁니다. nginx 공식 문서에 따르면 기본 접속 기록은 combined 형식입니다. 이 형식에는 접속 IP, 원격 사용자, 시각, 요청 줄, 상태 코드, 전송 바이트가 들어갑니다. 리퍼러(어느 페이지에서 왔는지 알려 주는 값)와 사용자 에이전트(접속 프로그램이 스스로 밝힌 이름)도 함께 남습니다.

스크립트 분석 도구에 IP가 남지 않아도 서버 기록에는 기본으로 남습니다. Google 애널리틱스 도움말은 GA4가 IP 주소를 기록하거나 저장하지 않는다고 설명합니다. 서버 측정을 시작하면 개인정보 관리 범위도 함께 넓어집니다.

개인정보 보호법 제2조는 그 정보만으로 개인을 알아볼 수 없더라도, 다른 정보와 쉽게 결합하여 알아볼 수 있으면 개인정보로 정의합니다. 실무에서는 아래 항목을 개인정보가 될 수 있는 값으로 보고, 처리 방법을 하나씩 정하는 방법을 권합니다.

1단계: 측정 목적과 남길 항목은 어떻게 정하나요?

개인정보 보호법 제3조 제1항은 처리 목적을 명확하게 하고, 목적에 필요한 범위에서 최소한의 개인정보만 수집하도록 정합니다. 서버 측정도 이 원칙에서 출발합니다. 목적이 없으면 어떤 항목을 빼도 되는지 판단할 기준도 없습니다.

목적은 한두 문장의 기술서로 씁니다. 예를 들어 가상의 B2B 제조 기업이라면 다음처럼 적을 수 있습니다.

• 목적: 공개 페이지별로 AI·검색 봇의 수집 요청 횟수와 응답 상태를 주 단위로 파악한다.
• 필요한 항목: 요청 시각, 경로, 상태 코드, 봇 이름, 봇 신원 확인 결과.
• 필요하지 않은 항목: 사람 방문자의 IP, 계정, 이전 페이지 주소, 질의 문자열.
• 사용 범위: 페이지 개선 우선순위 판단. 개인 단위 분석·광고 활용에는 쓰지 않는다.

마지막 줄이 중요합니다. 같은 법 제3조 제2항은 목적 외 용도로 활용하지 않을 것을 요구합니다. 사용 범위를 미리 문서에 적으면 다른 부서가 로그 재활용을 요청할 때 판단 근거가 됩니다.

끝났다고 보는 기준: 목적 기술서가 문서로 있고, 표의 모든 항목이 유지·변환·제외 중 하나로 분류되어 있습니다.

2단계: 로그 형식에서 무엇을 빼고 무엇을 바꾸나요?

분류가 끝나면 서버의 기록 형식을 직접 바꿉니다. nginx 공식 문서는 log_format 지시어로 이름 붙인 기록 형식을 새로 정의할 수 있다고 설명합니다. 측정 전용 형식을 새로 만들고, 기본 combined 기록은 아래 절의 운영 점검 기록으로 바꿉니다.

바꿀 때는 세 가지를 우선합니다.

1. 원격 사용자 칸을 형식에서 지웁니다. 공개 페이지 측정에는 계정 정보가 필요하지 않습니다.
2. 요청 줄 전체 대신 질의 문자열을 뺀 경로만 남깁니다. 비밀번호 재설정 링크나 검색 결과 주소에는 이메일·토큰이 붙을 수 있습니다.
3. 리퍼러는 지우거나 도메인만 남깁니다. 봇 수집 신호를 판단할 때 리퍼러를 쓰지 않는 경우가 많아, 제외해도 판단에 지장이 적습니다.

측정 전용 형식은 다음 항목으로 구성할 수 있습니다. 괄호 안은 nginx 공식 문서에 나온 변수 이름입니다.

• 요청 시각: ISO 8601 형식의 시각($time_iso8601)
• 요청 방식: GET·POST 등($request_method)
• 경로: 질의 문자열이 없는 정규화된 주소($uri)
• 상태 코드: 응답 상태($status)
• 전송 바이트: 본문 전송량($body_bytes_sent)
• 사용자 에이전트: 접속 프로그램 이름($http_user_agent)
• 신원 확인 결과: 3단계에서 만드는 별도 변수

nginx 문서는 $request_uri가 인자를 포함한 원래 주소라고 설명합니다. 따라서 경로에는 $request_uri 대신 $uri를 씁니다. 같은 문서는 $uri가 내부 이동 중 바뀔 수 있다고도 적습니다. 색인 파일로 넘어가는 주소는 집계할 때 대표 경로로 맞춥니다.

nginx 문서는 기록 형식에 escape=json 옵션을 두면 JSON 문자열에 쓸 수 없는 문자를 이스케이프(특수 문자를 안전한 표기로 바꾸는 처리)한다고 설명합니다. 집계 단계에서 항목을 나누기 쉬워 측정 전용 형식에 함께 쓰기 좋습니다.

기본 접속 기록도 함께 줄입니다

측정 전용 형식만 추가하면 기본 combined 기록이 같은 서버에 계속 쌓입니다. nginx 문서에 따르면 기록 지시어를 지정하지 않으면 기본 경로에 combined 형식으로 기록됩니다. 따라서 기본 지시어를 지우고, 측정 전용 기록과 운영 점검 기록 두 개만 직접 지정합니다. 기록이 필요 없는 위치는 문서 설명대로 access_log off로 끕니다.

운영 점검 기록에는 요청 시각·요청 방식·경로·상태 코드·전송 바이트만 남기고, IP·계정·리퍼러·질의 문자열은 넣지 않습니다. 보안 대응 때문에 IP가 필요하다면 별도 파일로 분리하고 보관 기간을 측정 원본보다 짧게 정합니다. 이 판단은 4단계의 담당 부서 질문으로 확인합니다. 실무에서는 오류 기록(error_log)에도 접속 주소가 남을 수 있으므로 함께 점검합니다.

끝났다고 보는 기준: 새 형식을 적용한 뒤 서버의 모든 접속 기록 파일에서 하루치를 열었을 때 IP, 계정 이름, 물음표 뒤 문자열이 한 줄도 보이지 않습니다. 예외로 둔 IP 파일과 오류 기록의 보관 기간도 문서로 정해져 있습니다.

3단계: IP를 저장하지 않고 봇 신원은 어떻게 확인하나요?

IP를 모두 지우면 봇 이름을 사칭한 요청을 구분할 수 없습니다. 두 요구를 함께 맞추려면 확인을 요청 시점으로 옮깁니다. 저장은 확인 결과만 합니다.

공개 IP 범위 파일과 요청 시점에 대조합니다

Google 검색 센터 문서는 Google 크롤러 확인 방법으로 역방향 DNS 조회(IP로 도메인 이름을 찾는 조회)와 공개 IP 범위 파일 대조 두 가지를 안내합니다. OpenAI 공식 문서도 OAI-SearchBot, OAI-AdsBot, GPTBot, ChatGPT-User 네 봇마다 별도의 IP 주소 파일을 공개합니다.

실무에서는 갱신 주기를 운영자가 정해(예: 주 1회) 대조 파일을 내려받습니다. 갱신 뒤에는 새 범위가 반영됐는지, none 비율이 갑자기 늘지 않았는지 확인합니다. 봇 이름과 파일 목록도 문서 개정으로 바뀔 수 있어 함께 확인합니다.

IP를 저장하지 않는 구조에서는 사후 DNS 조회를 할 수 없습니다. 실무에서는 공개 IP 범위 파일과 요청 시점에 대조하는 방법이 적합합니다.

nginx 공식 문서는 geo 지시어가 접속 IP에 따라 값이 정해지는 변수를 만든다고 설명합니다. CIDR 표기(IP 범위를 묶어 적는 방식)와 IPv6 범위를 지원하고, 주소 목록을 별도 파일로 불러올 수 있습니다. 공개 JSON 파일을 이 목록 형식으로 바꿔 불러오면, 요청마다 출처 값이 정해집니다. 예를 들어 Google 범위는 google, GPTBot 범위는 gptbot, 어디에도 없으면 none으로 둡니다.

측정 전용 형식에는 IP 대신 이 출처 값만 넣습니다. 사용자 에이전트가 GPTBot이라고 밝혔는데 출처 값이 none이면 사칭으로 분류합니다. 이 비교는 집계 단계에서 합니다. 서버가 CDN이나 프록시 뒤에 있으면 geo 지시어가 원래 방문자 IP를 담은 변수를 읽도록 설정해야 합니다.

대조가 끝난 IP는 디스크에 쓰지 않습니다

Google 애널리틱스 도움말의 IP 마스킹 설명은 지원이 종료된 유니버설 애널리틱스 기준이지만, 원칙은 참고가 됩니다. 주소를 기술적으로 가능한 가장 이른 시점에 자르고, 전체 IP 주소는 디스크에 쓰지 않는다는 것입니다. 서버 측정에서는 한 단계 더 나아가, 대조가 끝난 IP를 버리고 확인 결과만 저장합니다.

사람 방문은 측정 기록에서 분리합니다

nginx 문서는 access_log 지시어의 if 조건으로 조건부 기록이 가능하다고 설명합니다. 조건 값이 0이거나 비어 있으면 그 요청은 기록되지 않습니다. 같은 수준에 기록 지시어를 여러 개 둘 수도 있습니다.

조건 값은 map 지시어로 만듭니다. nginx 문서는 map이 원본 변수 값에 따라 새 변수를 만들고, 원본 값을 정규식(문자 패턴 규칙)으로 맞출 수 있다고 설명합니다. 사용자 에이전트가 Googlebot·GPTBot·OAI-SearchBot·ChatGPT-User 같은 봇 이름과 맞으면 1, 아니면 0이 되는 변수를 만듭니다. OpenAI 문서는 OAI-AdsBot을 ChatGPT 광고로 제출된 페이지의 안전성 검증용으로 설명하므로, 수집 신호 목적과 맞지 않으면 제외합니다. 이 변수를 측정 전용 기록의 if 조건에 넣으면 봇 요청만 그 파일에 남습니다. 이 방식에서는 사용자 에이전트에 봇 이름을 밝힌 요청만 측정 기록에 남고, 이름을 밝히지 않은 수집 요청은 측정 범위 밖입니다. 사람 요청은 2단계에서 정한 운영 점검 기록으로 보내며, 이 기록에는 시각·방식·경로·상태 코드·전송 바이트만 남습니다.

끝났다고 보는 기준: 측정 전용 기록과 운영 점검 기록 모두에 IP가 없고, 봇 요청마다 출처 값이 채워져 있습니다.

4단계: 보관 기간·파기·외부 전송은 어떻게 정하나요?

항목을 줄여도 오래 쌓으면 결합 위험은 다시 커집니다. 개인정보 보호법 제21조는 개인정보가 불필요하게 되었을 때 지체 없이 파기하도록 정합니다. 다만 다른 법령에 보존 의무가 있으면 예외로 둡니다. 보관 기간은 측정 목적과 다른 법령상 보존 의무를 함께 보고 정합니다.

실무에서는 원본 기록과 집계표의 보관 기간을 따로 두는 방법을 권합니다. 원본은 집계에 필요한 짧은 기간만 보관합니다. 예를 들어 가상의 ○○ 기업이라면 주 단위 집계를 마친 뒤 그 주의 원본을 파기하는 식으로 정할 수 있습니다. 이후에는 페이지·봇·주 단위로 합친 표만 남깁니다. 집계표에는 개인을 알아볼 수 있는 값이 없어 추세 비교용으로 오래 보관할 수 있습니다.

외부 도구로 데이터를 보낸다면 보내기 전에 정리합니다. Google 태그 관리자 서버 측 태그 문서는 서버에 들어온 데이터를 다른 곳으로 보내기 전까지 운영자만 접근할 수 있고, 형태와 전송 경로도 운영자가 정한다고 설명합니다. 줄이는 작업은 서버에서 끝내고 외부로는 결과만 보내는 구조가 맞습니다.

개인정보 보호법 제30조는 처리방침에 처리 목적, 보유 기간, 파기 절차를 적도록 정합니다. 설정을 바꾼 뒤에는 개인정보 담당 부서에 다음 질문을 보내 확인합니다.

1. 서버 접속 기록이 현재 처리방침의 처리 목적과 보유 기간 안에 포함되어 있습니까?
2. 다른 법령에 따라 별도로 보존해야 하는 접속 기록이 있습니까? 있다면 측정 전용 기록과 분리되어 있습니까?
3. 원본 기록의 파기 주기와 방법을 정한 문서가 있습니까?
4. 앞부분만 남긴 IP를 보관해야 할 운영상 이유가 있습니까? 있다면 다른 정보와 결합해 식별될 가능성을 검토했습니까?
5. 측정 데이터를 외부 도구로 보낼 때 위탁에 해당하는지 검토가 필요합니까?

끝났다고 보는 기준: 원본과 집계표의 파기 주기가 문서로 있고, 담당 부서가 처리방침과 일치한다고 회신했습니다.

정리

봇 수집 신호는 페이지, 시각, 응답, 봇 신원 확인 결과로 읽습니다. 나머지 항목을 줄이면 이 기록으로 사람 방문이나 유입 경로를 분석할 수는 없습니다. 대신 봇 수집 신호를 읽는 목적에는 영향이 적고, 관리할 위험을 줄여 줍니다.

1. 측정 목적 기술서를 쓰고 기본 기록 항목을 분류합니다.
2. IP·계정·질의 문자열을 뺀 측정 전용 기록 형식을 만들고, 기본 접속 기록도 운영 점검용 최소 형식으로 바꿉니다.
3. 공개 IP 범위 파일로 출처 값을 만들고, 봇 요청만 측정 기록에 남깁니다.
4. 원본과 집계표의 보관 기간을 나누고 파기 주기를 문서로 정합니다.
5. 개인정보 담당 부서에 다섯 가지 질문을 보내 회신을 받습니다.

참고 자료

• Verifying Googlebot and other Google crawlers (Google Search Central, 확인일 2026-10-20)
• Overview of OpenAI Crawlers (OpenAI, 확인일 2026-10-23)
• IP masking in Google Analytics (Google 애널리틱스 고객센터, 확인일 2026-10-20)
• Module ngx_http_log_module (nginx, 확인일 2026-10-20)
• Module ngx_http_core_module (nginx, 확인일 2026-10-20)
• Module ngx_http_map_module (nginx, 확인일 2026-10-20)
• Module ngx_http_geo_module (nginx, 확인일 2026-10-20)
• An introduction to server-side tagging (Google 태그 플랫폼, 확인일 2026-10-20)
• 개인정보 보호법 (국가법령정보센터, 확인일 2026-10-23)
• 개인정보 보호법 국문·영문 법령, 번역 참고용 (한국법제연구원, 확인일 2026-10-20)