덱 분석이 틀린 이유: 이메일 보안 봇이 조회수를 부풀리는 방법

잠재 고객에게 제안서 링크를 공유합니다. 2분 후, 트래킹 도구가 상대방이 링크를 열고, 6페이지를 스크롤하고, 각 페이지에 30초씩 머물렀다고 알려줍니다.

바로 후속 이메일을 보냅니다. 상대방은 무슨 이야기인지 전혀 모릅니다 — 아직 열어보지도 않았기 때문입니다.

무슨 일이 일어난 것일까요: 상대방 회사의 이메일 보안 스캐너가 링크를 먼저 열었습니다. 그 "조회"는 봇이었습니다. 분석 플랫폼이 이를 별도로 처리하지 않는 한, 차이를 구별할 수 없습니다.

이것은 드문 예외가 아닙니다. Microsoft 365나 Google Workspace를 사용하는 기업 수신자에게 보내는 거의 모든 이메일에서 발생합니다.

분석을 부풀리는 봇들

공유 덱 링크에 도달하는 자동화된 트래픽은 세 가지 범주로 나뉩니다:

링크 미리보기 봇

Slack, LinkedIn, Twitter, iMessage에 링크를 붙여넣으면, 봇이 즉시 페이지를 가져와 미리보기 카드를 생성합니다. 이러한 요청은 식별 가능한 유저 에이전트에서 옵니다 — Slackbot-LinkExpanding, LinkedInBot, Twitterbot. 감지하고 필터링하기 쉽습니다. 대부분의 트래킹 도구가 이를 올바르게 처리합니다.

검색 엔진 크롤러

Googlebot, Bingbot 및 그 변형들이 공개 콘텐츠를 정기적으로 인덱싱합니다. 이들도 자신을 공개적으로 식별하며 필터링이 간단합니다. 공유 링크가 인증 뒤에 있거나 고유한 슬러그를 사용한다면, 크롤러가 이를 발견하는 경우는 거의 없습니다.

이메일 보안 스캐너

분석을 망가뜨리는 범주가 바로 이것입니다.

Microsoft Defender SafeLinks, Proofpoint URL Defense, Mimecast, Google Safe Browsing은 수신자가 이메일을 보기 전에 모든 링크를 스캔합니다. 이들의 역할은 피싱 페이지와 악성코드를 탐지하는 것입니다. 실제로 링크를 열고, 페이지를 로드하며, 많은 경우 콘텐츠를 탐색하는 방식으로 이를 수행합니다.

이들을 실제 사용자와 구별하기 거의 불가능하게 만드는 요소:

• 위장된 유저 에이전트. SafeLinks는 자신을 봇이라고 밝히지 않습니다. 실제 브라우저 유저 에이전트를 사용합니다 — "Chrome 120 on Windows 11"이나 심지어 "itel A27 Android" 같은 모바일 기기 문자열까지. 서버에서 보기에는 정상적인 브라우저 방문처럼 보입니다.
• 페이지 탐색. SafeLinks는 첫 페이지만 로드하지 않습니다. 총 길이와 관계없이 덱의 약 6페이지를 탐색합니다. Proofpoint도 유사한 다중 페이지 스캔을 수행합니다.
• 현실적인 타이밍. 이러한 세션은 22~48초 동안 지속됩니다. 조잡한 스크래퍼처럼 순식간에 지나가지 않습니다 — 빠른 훑어보기에 그럴듯한 타이밍입니다.
• 합성 DOM 이벤트. 일부 스캐너는 JavaScript 이벤트를 실행합니다 — 프로그래밍된 스크롤, 시뮬레이션된 터치, 심지어 클릭 이벤트까지 — 사용자 상호작용 뒤에 숨겨진 악성 스크립트를 트리거하기 위해서입니다.

결과적으로: Microsoft 365를 사용하는 회사(대부분의 엔터프라이즈 잠재 고객이 여기에 해당)의 누군가에게 덱 링크를 이메일로 보낼 때마다 실제처럼 보이는 가짜 "조회"가 발생합니다. 때로는 두 건 — 발신자의 보안 스택에서 하나, 수신자의 보안 스택에서 하나.

SafeLinks 봇 세션과 실제 사용자 세션을 나란히 비교한 모습입니다:

URL 재작성이 문제를 악화시킵니다

일부 보안 도구는 링크를 사전 스캔하는 것에 그치지 않고 완전히 재작성합니다. SafeLinks는 이메일 본문의 모든 URL을 Microsoft 자체 서버를 통한 리다이렉트로 교체합니다 (https://nam02.safelinks.protection.outlook.com/...). Proofpoint도 URL Defense 재작성으로 동일하게 처리합니다 (https://urldefense.proofpoint.com/v2/...).

수신자가 마침내 이메일의 링크를 클릭할 때, 원래 URL을 직접 여는 것이 아닙니다. 재작성된 SafeLinks URL을 클릭하면 먼저 Microsoft의 프록시를 거치게 되고 — Microsoft의 프록시가 그 시점에 페이지를 다시 스캔합니다. 그런 다음 사용자의 브라우저를 실제 페이지로 리다이렉트합니다.

결과: 봇 스캔과 실제 방문이 동시에 발생합니다. 보안 스캐너가 데이터센터 IP에서 덱을 열고, 실제 사용자가 사무실에서 여는 것이 정확히 같은 초에 일어납니다. 하나는 봇, 하나는 사람 — 거의 동일한 타임스탬프를 가진 두 개의 동시 세션이 생깁니다. 분석 도구가 이를 구별하지 못하면, 둘 다 세는(부풀림) 것이거나 실제 세션을 필터링해 버리는(과소 집계) 위험이 있습니다.

이것이 올바르게 처리하기 가장 어려운 시나리오입니다. 사전 전달 스캔은 단독으로 식별하기 쉽습니다 — 누군가 클릭하기 몇 분 전에 도착합니다. 그러나 클릭 시점의 재스캔은 실제 사용자와 함께 도착하며, 다른 IP에서, 다른 유저 에이전트로, 정상 세션과 겹치는 별도의 세션을 생성합니다.

표준 봇 감지가 작동하지 않는 이유

표준 접근법 — 알려진 봇 목록과 유저 에이전트를 대조하는 것 — 은 링크 미리보기 봇과 크롤러는 잡지만 이메일 보안 스캐너는 완전히 놓칩니다. SafeLinks는 피싱 페이지가 봇을 감지하면 실제 사용자에게 보여주는 것과 다른 콘텐츠를 제공하기 때문에, 핑거프린팅을 피하기 위해 의도적으로 실제처럼 보이는 유저 에이전트를 사용합니다.

IP 기반 속도 제한도 도움이 되지 않습니다. SafeLinks는 Azure 데이터센터 IP 풀을 순환하므로 각 스캔이 다른 주소에서 옵니다. IP로 차단하면 기업 VPN의 정상 사용자까지 차단하게 됩니다.

브라우저 핑거프린팅(canvas, WebGL, 폰트 열거)도 작동하지 않습니다. SafeLinks가 완전한 Chromium 기반 브라우저를 실행하기 때문입니다. 핑거프린트가 실제 Chrome 설치와 구별할 수 없습니다.

해결 방법: 3단계 감지 시스템

이메일 보안 스캐너를 잡으면서도 기업 VPN과 프록시를 사용하는 정상 사용자를 차단하지 않는 감지 시스템을 구축했습니다.

트래픽이 3단계를 거치는 흐름입니다. 노드 위에 마우스를 올리면 경로를 추적할 수 있습니다:

1단계: 유저 에이전트 매칭

간단한 부분입니다. 수신 요청을 60개 이상의 알려진 봇 패턴 — 링크 미리보기 봇, 검색 크롤러, 헤드리스 브라우저, HTTP 클라이언트 라이브러리 — 과 대조합니다. 요청이 Slackbot이나 python-requests로 식별되면 즉시 거부합니다. 세션이 생성되지 않습니다.

이것으로 봇 트래픽의 약 40%를 잡습니다. 쉬운 40%입니다.

2단계: 데이터센터 IP 감지

이메일 보안 스캐너는 유저 에이전트를 위장하지만 실행 위치를 숨길 수는 없습니다. SafeLinks는 Azure 데이터센터에서 운영됩니다. Proofpoint는 AWS에서 실행됩니다. 이들은 알려진 호스팅 제공업체 IP 범위입니다.

뷰어가 공유 링크를 열면, IP를 해당 IP가 호스팅 제공업체에 속하는지 보고하는 지리적 위치 서비스와 대조합니다. 해당되면 세션을 봇으로 플래그합니다.

이것으로 대부분의 이메일 보안 스캐너 트래픽을 잡습니다. 새벽 2시에 Microsoft Azure IP에서 "Quincy, Washington"으로 접속하는 뷰어는 거의 확실히 귀하의 제안서를 읽는 잠재 고객이 아닙니다.

여기에 미묘한 점이 있습니다: 이러한 세션을 차단하지 않습니다. 조회 기록을 생성하되 봇으로 플래그하고, 분석에서 제외하며, 알림을 보내지 않습니다. 이를 통해 오탐을 감사할 수 있고, 사용자가 원한다면 봇 세션을 조사할 수 있는 옵션을 제공합니다.

3단계: 제스처 기반 사람 확인

핵심 단계입니다. 단순한 관찰에 기반합니다: 실제 사람은 페이지와 물리적으로 상호작용합니다. 봇은 그렇지 않거나 — 상호작용하더라도 그 패턴에 특유의 시그니처가 있습니다.

세션이 (2단계에서) 처음에 봇으로 플래그되면, 실제 조회로 집계하지 않습니다. 대신, 진짜 사람의 입력을 감시합니다:

모니터링하는 것: 마우스 움직임, 터치 이벤트, 키보드 입력, 스크롤 활동.

무시하는 것: 페이지 내비게이션, 링크 클릭, 다운로드. 이것은 직관에 반합니다 — 이들은 사람의 행동을 나타내는 강한 신호처럼 보입니다. 하지만 SafeLinks는 스캔하는 모든 덱에서 6페이지 이상을 탐색합니다. Puppeteer 같은 헤드리스 브라우저는 프로그래밍으로 버튼을 클릭하고 다운로드를 트리거할 수 있습니다. 이러한 동작은 쉽게 위조됩니다. 저수준 입력 장치 이벤트는 설득력 있게 합성하기 훨씬 어렵습니다.

3초 윈도우: 페이지 로드 후 첫 3초 동안의 모든 제스처를 무시합니다. SafeLinks와 Proofpoint는 페이지 로드 후 거의 즉시 — 500밀리초 이내에 — 합성 이벤트를 실행합니다. 실제 사람은 방향을 잡고 상호작용을 시작하는 데 최소 3초가 걸립니다. 이 단일 타이밍 임계값만으로 대부분의 합성 이벤트 노이즈를 제거합니다.

마우스 움직임 분석: 3초 윈도우 이후 마우스 움직임이 감지되면, 궤적을 기록합니다 — 최대 20개의 움직임 이벤트의 좌표와 타임스탬프. 봇이 생성한 마우스 움직임은 기하학적 경로(완벽한 직선, 정확한 원)를 따르거나 단일 이벤트만 발생시킵니다. 사람의 마우스 움직임에는 유기적인 가속과 감속, 약간의 곡선, 미세한 보정이 있습니다.

진짜 제스처가 감지되면, 세션은 원자적으로 봇에서 실제로 "승격"됩니다. 그 시점에서 — 오직 그 시점에서만 — 조회수가 증가하고 알림을 받게 됩니다.

타이밍이 중요합니다

전체 시스템은 특정 경합 조건을 중심으로 설계되었습니다: 실제 사용자가 링크를 열고, 마우스를 한 번 움직이고, 즉시 탭을 닫으면 어떻게 될까요?

확인 요청이 탭이 닫히기 전에 완료되지 않을 수 있습니다. 브라우저는 내비게이션 시 진행 중인 fetch() 요청을 취소합니다. 그래서 sendBeacon() — 페이지 언로드 후에도 생존하는 발사 후 잊기(fire-and-forget) 요청을 위해 특별히 설계된 브라우저 API — 을 백업으로 사용합니다. 최종 비콘은 세션의 참여 지표와 함께 확인 데이터를 전달합니다.

서버 측에서 승격은 원자적입니다: 세션이 이미 승격되지 않은 경우에만 성공하는 단일 SQL 업데이트입니다. 이를 통해 일반 확인과 비콘 백업이 모두 도착할 때 이중 집계를 방지합니다.

분석에 미치는 영향

실질적인 영향은 상당합니다. 엔터프라이즈 중심 영업 팀을 대상으로 한 테스트에서, 명목상 덱 조회의 15~40%가 봇 세션이었습니다 — 주로 SafeLinks와 Proofpoint에서 발생. 엄격한 이메일 보안 정책을 가진 대기업에 판매하는 팀의 경우 그 비율은 더 높았습니다.

필터링 없이:

• 조회수가 15~40% 부풀림
• "가장 참여도 높은" 잠재 고객이 실제로는 가장 공격적인 이메일 보안을 가진 고객일 수 있음
• 조회 시점이 신뢰할 수 없음 — 오후 2시에 덱을 봤다고 생각하지만 보안 스캐너가 오후 1시 58분에 열었음
• 후속 연락 신호가 노이즈

필터링 적용 시:

• 모든 조회가 실제로 콘텐츠를 본 실제 사람을 나타냄
• 참여 지표(체류 시간, 본 페이지, 완료율)가 진정한 관심을 반영
• 조회 알림이 봇의 사전 스캔이 아닌 사람이 적극적으로 참여할 때 트리거됨

더 넓은 교훈

이메일 보안 스캐닝은 사라지지 않습니다 — 더 철저해지고 있습니다. Microsoft와 Google은 피싱 공격이 정교해짐에 따라 자동화된 링크 스캐닝을 확대하고 있습니다. 페이지 로드를 사람의 조회를 나타내는 대리 지표로 사용하는 모든 분석 플랫폼은 점점 더 부정확해질 것입니다.

필요한 신호는 "내 링크가 열렸는가"가 아닙니다. "사람이 내 콘텐츠에 참여했는가"입니다. 이를 위해서는 차이를 감지해야 합니다 — 그리고 그 차이는 페이지 로드가 아닌 제스처에 있습니다.