2026년 9월 13일 Have I Been Pwned에 Chess.com (2026) 기록이 나타났습니다: 730만 개의 항목, 460만 개의 고유 이메일 주소. 덤프에는 비밀번호가 없고, 해시도 없으며, 결제 정보도 없습니다. 그리고 해킹도 없었던 것으로 보입니다: 데이터는 9일 동안 일반 요청을 통해 수집되었습니다. 이는 "유출"과 "시스템 침입"이 다른 것이라는 점을 이해해야 할 경우입니다.
공개된 내용은 무엇인가
아카이브는 2026년 8월 12일 사이버 범죄 포럼에 등장했으며, Telegram을 통해 퍼졌습니다. 압축 해제된 파일 크기는 15.5GB(7-Zip으로 744MB)이며, 내부에는 7,337,395개의 기록이 각 38개의 필드로 구성되어 있습니다.
- 이메일 주소 — 약 75%의 기록(460만 개의 고유 주소).
- 사용자 이름, 실제 이름, 사용자 ID 및 UUID.
- 국가, 위치, 인터페이스 언어.
- 랭킹, 타이틀, 게임 수준, 프리미엄 구독 상태.
- 등록 날짜 및 마지막 로그인 날짜 — 2026년 8월까지.
- Google Ad Manager 광고 세그먼트 — gam_audiences 및 audiences_member_of 필드.
마지막 항목은 가장 예상치 못한 것입니다. 이는 "체험판에 적합", "이탈한 사용자", 랭킹 범위, 코치 팁 실험 참여와 같은 내부 마케팅 태그입니다. 사용자에게는 보이지 않으며, 공개 API에도 없습니다. "자신의 세그먼트를 보고 수정하기" 설정도 존재하지 않습니다. 즉, 덤프에는 프로필뿐만 아니라 플랫폼이 광고를 위해 플레이어를 어떻게 태그하는지도 포함되었습니다.
왜 이것이 스크래핑이고 해킹이 아닌가: 세 가지 증거
덤프를 분석한 분석가들은 판매자의 말이 아니라 데이터 구조에 의존했습니다.
- 수집 리듬. 기록은 2026년 7월 26일부터 8월 3일까지 9일 동안 날짜가 매겨져 있으며, 하루에 72,000에서 267,000개까지 불균형적으로 수집되었습니다. 단일 시점에서의 데이터베이스 내보내기는 이렇게 보이지 않습니다: 해킹된 저장소의 덤프는 특정 시점의 단일 샘플입니다.
- 중복. 7.4%의 기록이 중복됩니다: 동일한 계정이 다른 날에 내보내기에 포함되었습니다. 이는 테이블 내보내기가 아니라 슬라이딩 윈도우를 통한 자동화된 탐색의 징후입니다.
- 첫 번째 버전의 UUID. Chess.com의 식별자는 내장된 타임스탬프를 포함합니다. 샘플 검사는 169,289개의 UUID 중 169,287개가 계정 등록 날짜와 3초 이내로 일치함을 보여주었습니다. 수백만 개의 기록에서 이러한 상관관계를 위조하는 것은 불가능합니다 — 데이터는 진짜이며, 합법적인 요청을 통해 수집되었습니다.
HIBP는 또 다른 주장을 추가했습니다: 덤프의 99% 이메일 주소는 이미 이전 유출에서 발견되었습니다. 프로덕션에서 직접 가져온 데이터베이스라면 비율이 달라야 했습니다 — 여기서는 주소가 외부에서 왔고 매칭되었다는 것이 분명합니다.
메커니즘: 친구 찾기 기능이 검색 인덱스 역할을 함
이 벡터는 2023년 사건에서도 알려졌습니다. 당시 Chess.com에서 828,000개, 그 후 약 476,000개의 동일한 필드 구조를 가진 기록이 유출되었습니다. 당시 회사는 분명히 말했습니다: "이것은 데이터 유출이 아닙니다. 우리의 인프라, 계정 및 비밀번호와 같은 데이터는 안전합니다." 형식적으로는 사실입니다.
구조는 간단합니다. 플랫폼에는 지인 검색 기능이 있습니다: 이메일 주소를 업로드하면 서비스가 해당 사용자가 있는지 확인하고 그의 프로필을 보여줍니다. 다른 사람의 이메일 데이터베이스를 가져와(공개된 데이터가 수십억 개 있으므로 그로 인해 99%의 일치가 발생합니다) 이 기능을 통해 실행하면, 풍부한 프로필이 생성됩니다: 이름, 국가, 랭킹, 마지막 로그인 날짜, 광고 세그먼트.
여기서 어떤 개별 작업도 공격처럼 보이지 않습니다. 이는 수백만 번 반복될 때 공격이 됩니다. 덤프를 분석한 전문가들은 범인을 분명히 지목했습니다: 과소평가된 열거 저항, 속도 제한 및 느린 광범위 수집 모니터링. 즉, 해킹에 대한 보호는 있지만 인내심을 가지고 탐색하는 것에 대한 보호는 없습니다.
이것은 단일 사건이 아니라 문제의 한 종류입니다
같은 종류의 가장 큰 사례는 비엔나 대학교의 WhatsApp 연구입니다. 팀은 API 연락처 발견을 역설계하여 시간당 1억 개 이상의 전화번호를 조사했습니다. 하나의 대학 서버와 다섯 개의 인증된 계정을 사용했습니다. 결과적으로 35억 개의 활성 계정이 나열되었습니다: 번호, 프로필 사진, 공개 키. 속도 제한은 한 번도 작동하지 않았습니다. 실험은 2024년 12월부터 2025년 4월까지 진행되었으며, Meta는 2025년 10월에 조용히 구멍을 막았습니다. 작업은 NDSS 2026에서 발표되었습니다.
같은 연구의 주목할 만한 세부 사항: 2021년 Facebook의 이전 유출에서 58%의 전화번호가 여전히 WhatsApp에서 활성 상태였습니다. 한 번 수집된 데이터는 오래되지 않으며, 다음 탐색을 위한 입력 자료가 됩니다. Chess.com은 2026년에 바로 이러한 이유로 피해를 입었습니다: 누군가가 이전에 수집한 목록으로 공격을 받았습니다.
합법적으로 데이터를 수집하는 사람들에게 이것이 의미하는 바
이런 사건은 범죄자에게 타격을 주는 것이 아니라 공개 데이터를 다루는 모든 사람에게 타격을 줍니다. 플랫폼의 반응은 예측 가능합니다: 공개 후 제한이 강화되고, 행동 분석이 도입되며, 검색 및 발견 엔드포인트가 인증 및 CAPTCHA 뒤에 숨겨집니다. 당신의 정교한 공개 상품 카드 파서는 이메일 탐색과는 관계가 없지만, 새로운 규칙에 따라 모든 사람과 함께 포함될 것입니다. 이 문제에 대한 일반적인 접근 방식에 대해서는 API 제한 및 작업에 대한 분석에서 다루었습니다.
따라서 경계를 명확히 하는 것이 중요합니다 — 이는 기술이 아니라 사람들의 식별자에 대해 무엇을 하는지에 따라 달라집니다.
- 공개 데이터 — 서비스가 익명의 방문자에게 직접 링크를 통해 보여주는 것: 상품 카드, 가격, 공개 프로필, 공개 게시물. 수집하는 것은 정상입니다.
- Enumeration — 외부 이메일, 전화번호 또는 ID 목록을 검색 기능에 삽입하여 그 소유자를 알아내는 것입니다. 이는 더 이상 공개 데이터 수집이 아니라 개인 식별자를 매칭하는 것이며, GDPR과 유사한 규제를 가진 관할권에서는 적절하게 분류됩니다 — 엔드포인트가 열려 있더라도 마찬가지입니다.
- 숨겨진 필드. Chess.com의 광고 세그먼트는 어떤 형태로도 공개되지 않았습니다. API 응답에서 인터페이스에 없는 것이 오면, 이는 "보너스"가 아니라 멈추라는 신호입니다.
양심적인 수집을 위한 실용적인 체크리스트: 검색 및 발견 기능에 다른 사람의 연락처를 삽입하지 마십시오; 서비스가 저하되지 않고 견딜 수 있는 속도를 유지하십시오; robots.txt 및 공개 제안을 존중하십시오; 인터페이스에서 볼 수 있는 필드만 수집하십시오; 불필요한 것을 저장하지 마십시오. 법적 측면에 대해서는 프록시를 통해 데이터를 합법적으로 수집하는 방법에 대한 자료에서 자세히 다루었습니다.
이 덤프에 당신의 주소가 포함된 경우 어떻게 해야 하나
덤프에는 비밀번호가 없으므로, 단순히 유출된 사실 때문에 비밀번호를 변경하는 것은 큰 의미가 없습니다 — 하지만 위험은 제로가 아니며, 특정합니다.
- Have I Been Pwned에서 주소를 확인하십시오. 기록은 Chess.com (2026)으로, 2026년 9월 13일에 업로드되었으며, 460만 개의 주소가 포함되어 있습니다.
- 타겟 피싱을 기다리십시오. "이메일 + 실제 이름 + 국가 + 랭킹 + 마지막 로그인 날짜 + 구독 상태"의 조합은 플랫폼에서 온 것처럼 보이는 설득력 있는 이메일을 위한 준비된 자료입니다. 일반적인 메일링은 이렇게 보이지 않으며; 당신의 랭킹을 아는 이메일은 그렇게 보입니다.
- 이 주소가 다른 곳에서 어떻게 사용되었는지 확인하십시오. 99%의 주소는 이미 이전 유출에서 발견되었습니다 — 즉, 당신의 이메일은 오래전부터 다른 목록에 있었고 다음 플랫폼에서 열린 검색 기능을 통해 다시 사용될 것입니다.
- 가능한 경우 공개 프로필에서 이메일을 분리하십시오. 서비스가 이메일이나 전화번호로 자신을 검색하는 것을 금지할 수 있도록 허용한다면 — 이는 당신을 위해 설명된 벡터를 끄는 바로 그 스위치입니다.
자신의 서비스를 구축하는 사람들에게는 이 사건의 간단한 결론이 더 간단합니다: 외부 식별자에 대해 "이 사용자가 있습니다, 그의 카드입니다"라고 응답하는 모든 기능은 외부에서 접근할 수 있는 검색 인덱스입니다. 이는 계정 및 IP 서브넷에 대한 속도 제한을 요구하며, 단일 주소에 대해서만이 아니라, 느린 광범위 샘플을 모니터링해야 하며, 이는 시간당 메트릭에서 정상적인 배경처럼 보입니다.
프록시의 역할 — 그리고 그것이 결코 아닌 것
매번 이런 사건이 발생할 때마다 "모든 것이 프록시를 통해 이루어진다"는 주장이 떠오르기 때문에 명확히 말할 필요가 있습니다. 프록시는 세 가지 작업을 수행합니다: IP 주소의 평판 및 ASN, 요청의 지리적 위치, 합법적인 수집량에서 하나의 주소의 한계를 초과하지 않도록 부하를 분산합니다. 주거용 프록시는 웹사이트가 지역에 따라 다른 콘텐츠를 제공하거나 데이터 센터 서브넷을 차단할 때 필요합니다 — 예를 들어 가격 모니터링 및 다른 국가에서의 결과를 위해서입니다.
프록시가 하지 않는 것은 다른 사람의 이메일을 탐색하는 것을 합법적인 수집으로 변환하지 않으며, 결과로부터 보호하지도 않습니다. Chess.com 사건에서 주소에 대한 분산이 아마도 9일 동안 데이터를 눈치채지 못하게 하는 데 기여했지만, 이는 플랫폼의 약한 보호 특성이지 그러한 시나리오를 지지하는 논거가 아닙니다. 기술적으로 열거는 정상 트래픽과 구별할 수 없으며, 누군가가 양을 로그와 비교할 때까지는 — 그 이후에는 제한이 아니라 규제 기관에 대한 대화가 시작됩니다.
결론
Chess.com의 이야기는 3년 동안 동일한 공격 표면에서 세 번째 에피소드이며 단 하나의 해킹도 없었습니다. 플랫폼에 대한 엄격한 교훈: 인프라에 대한 침입만을 사건으로 간주하는 보호 경계는 데이터베이스가 기능을 통해 부분적으로 유출되는 것을 보지 못합니다. 전문적으로 데이터를 수집하는 사람들에게도 실용적인 교훈이 있습니다: 제한은 가격을 높이지 않으며, 가격은 이러한 사건들로 인해 높아지며, 각 새로운 파동의 비용은 데이터 수집 산업 전체에 부과됩니다. 공개 수집과 개인 식별자 탐색을 구분하는 것은 예의가 아니라, 공개 데이터가 전혀 접근 가능할 것인지에 대한 문제입니다.