BrowserStack이 사용자 이메일 주소를 유출하고 있다
Someone at BrowserStack is leaking users' email addresses
TL;DR Highlight
BrowserStack이 보유한 사용자 이메일을 Apollo.io를 통해 제3자에게 유출했으나 응답을 거부했다.
Who Should Read
SaaS 서비스를 운영하며 외부 CRM이나 마케팅 도구를 연동하고 있는 개발자 또는 개인정보 보호에 관심 있는 개발자. 특히 BrowserStack을 사용 중이거나 Apollo.io 같은 영업 자동화 플랫폼을 도입 중인 팀.
Core Mechanics
- 글쓴이는 서비스마다 고유한 이메일 주소를 생성해서 사용하는 방식으로, 어느 서비스가 이메일을 유출했는지 바로 추적할 수 있다. BrowserStack에서만 사용한 고유 이메일로 제3자 스팸 메일을 받게 되었다.
- 스패머에게 출처를 물어봤더니 Apollo.io에서 얻었다고 했고, Apollo.io에 다시 문의하자 처음에는 '공개 정보와 기업 이메일 패턴(firstname.lastname@domain)을 조합하는 자체 알고리즘으로 도출했다'고 거짓말을 했다.
- 하지만 해당 이메일은 알고리즘으로 추론할 수 없는 완전히 고유한 형식이었기 때문에 글쓴이가 반박하자, Apollo.io는 결국 'BrowserStack이 자사의 고객 기여 네트워크(customer contributor network)를 통해 2026년 2월 25일에 해당 연락처를 공유했다'고 인정했다.
- Apollo.io의 '고객 기여 네트워크'는 Apollo를 사용하는 기업이 자신들의 고객 연락처 데이터를 Apollo 플랫폼에 공유하는 방식으로 운영된다. 이 기능은 기본적으로 활성화되어 있으며, 직접 opt-out(거부 설정)을 해야 비활성화된다.
- 글쓴이는 BrowserStack에 여러 차례 연락을 시도했지만 아무런 답변을 받지 못했다. 이메일에는 'No spam, we promise!'라는 문구가 있었다고 아이러니하게 언급하고 있다.
- 유출 경로로는 세 가지 가능성을 꼽았다: BrowserStack이 정기적으로 사용자 데이터를 판매하거나 제공하는 경우, BrowserStack이 사용하는 서드파티 서비스가 데이터를 수집해 유출하는 경우, BrowserStack 내부 직원이나 계약업체가 데이터를 빼돌리는 경우.
- GDPR 관점에서 볼 때, Apollo가 GDPR 준수를 주장하더라도 BrowserStack이 지원 데이터베이스에 있는 고객 이메일을 Apollo에 공유하려면 적절한 법적 근거가 필요한데, 이를 갖추지 않았을 가능성이 높다. 사실상 BrowserStack과 Apollo 양쪽 모두 위반 소지가 있다.
Evidence
- Apollo.io의 동작 방식을 잘 아는 댓글러가 '이건 데이터 해킹이 아니라 Apollo가 원래 그렇게 작동하는 것'이라고 지적했다. Apollo 고객사가 opt-out을 하지 않으면 자신의 고객 연락처 데이터가 자동으로 Apollo 네트워크에 공유되는 구조라고 설명했다. (https://knowledge.apollo.io/hc/en-us/articles/20727684184589 참고)
- BrowserStack 영업팀이 Apollo를 CRM 용도로 사용하면서 개인정보 보호 함의를 인지하지 못한 채 전체 고객 목록을 업로드했을 가능성이 높다는 의견도 있었다. 일반 영업 담당자 수준에서는 이런 데이터 공유가 어떤 결과를 낳는지 모르고 진행하는 경우가 많다는 것.
- GDPR 전문가 성격의 댓글에서는 Apollo가 '정당한 이익(Legitimate Interests)'을 법적 근거로 내세우고 있지만, BrowserStack의 지원 데이터베이스에 있는 이메일을 Apollo에 공유하는 것은 그 법적 근거에 해당하지 않는다고 분석했다. 결국 BrowserStack과 Apollo 모두 GDPR 위반을 신고하고 재발 방지 조치를 취해야 한다고 지적했다.
- '+태그' 방식의 이메일 별칭(예: name+browserstack@gmail.com)은 많은 서비스들이 이미 de-alias 처리를 해서 실제 이메일을 추출하기 때문에 더 이상 효과적이지 않다는 댓글이 있었다. 완전히 별개의 인박스로 고유 이메일을 만드는 것이 진짜 추적에 효과적이라고 언급되었다.
- BrightData(헤드리스 브라우저 서비스)도 최근 비슷한 개인정보 유출 사건이 있었다는 댓글이 있었다. 이 댓글러는 자신의 헤드리스 브라우저 핑거프린팅 프로젝트에서 BrightData로만 접근했던 URL들이 이후 Anthropic의 ClaudeBot에 의해 크롤링된 것을 발견했으며, 고객 데이터를 탈취한 공격자가 Claude를 이용해 데이터를 분석하고 있을 가능성을 제기했다.
- Seamless.io도 같은 방식으로 동작한다는 실사용 경험이 공유되었다. 한 댓글러가 Seamless.io 시스템에서 매우 개인적인 이메일 주소를 발견했으며, 직장 동료 중 누군가가 주소록을 유출하고 있다고 의심했지만 어떻게 막아야 할지 모르겠다고 토로했다.
- UK의 Compare The Market에서도 동일한 상황이 발생했다는 사례 공유가 있었다. 두 개의 고유 이메일을 서로 다른 도메인으로 사용했는데, 같은 날 동시에 스팸을 받기 시작했고 신고했지만 '증명할 수 없다'며 아무 조치도 취해지지 않았다고 했다.
How to Apply
- BrowserStack을 사용 중이고 Apollo.io 같은 영업 플랫폼도 함께 쓰고 있다면, Apollo 설정에서 'customer contributor network' 데이터 공유 opt-out을 즉시 확인하고 비활성화해야 한다. 기본값이 공유 활성화이므로 명시적으로 거부 설정을 하지 않으면 고객 연락처가 Apollo 네트워크에 자동 공유된다.
- 외부 CRM이나 영업 자동화 도구(Apollo, Seamless.io 등)를 도입하려는 팀이라면, 해당 플랫폼의 데이터 공유 정책과 opt-out 구조를 계약 전에 반드시 검토해야 한다. 특히 고객 연락처를 업로드하는 기능이 어떤 방식으로 플랫폼 네트워크에 공유되는지 약관을 확인할 것.
- 개인 차원에서 서비스별 고유 이메일로 유출 추적을 하고 싶다면, '+태그' 방식(name+site@gmail.com)보다 완전히 별개의 이메일 별칭(예: SimpleLogin, Fastmail aliases)을 사용해야 효과적이다. 많은 서비스들이 '+태그'를 자동으로 제거해 실제 이메일을 추출하기 때문이다.
- EU GDPR 적용 대상 서비스를 운영 중이라면, 고객 지원 데이터베이스에 있는 이메일 주소를 외부 마케팅/영업 플랫폼에 공유할 때 '정당한 이익'이 법적 근거가 될 수 없으며, 이를 허용하면 GDPR 위반 소지가 있다. 데이터 공유 전에 법무팀과 처리 근거를 명확히 확인해야 한다.
Terminology
관련 논문
Mindwalk – 코딩 에이전트 세션을 코드베이스 3D 맵 위에서 재생하는 시각화 도구
Claude Code나 Codex 같은 AI 코딩 에이전트가 세션 중 코드베이스의 어떤 파일을 탐색하고 수정했는지를 3D 지도 형태로 시각화해서 재생해주는 로컬 도구다. 에이전트가 작업을 어떻게 이해했는지 한눈에 파악할 수 있다.
Ghost Font: 사람은 읽을 수 있지만 AI는 읽기 어려운 안티-AI 폰트 실험
움직임(모션)을 이용해 글자를 표현해서 AI 모델이 정적 이미지 분석으로는 메시지를 해독하지 못하게 막는 실험적 프로젝트인데, 커뮤니티에서는 이미 GPT-5.6, Claude Opus 등으로 해독에 성공한 사례가 속출해 실효성 논쟁이 뜨겁다.
GPT-5.6, Grok 4.5, Claude, Muse Spark 등 12개 모델이 동일한 앱 4개를 빌드한 결과 비교
12개 LLM 모델에게 레이캐스터 미로, 루빅스 큐브, 계산기, Game of Life 앱을 각각 5번씩 만들게 해서 성공률·비용·속도를 비교한 실전 벤치마크다. GPT-5.6 Sol이 전반적으로 가장 일관된 결과를 냈고, Grok 4.5는 가성비 면에서 눈에 띄었다.
Databricks가 수백만 라인 실제 코드베이스로 Coding Agent를 벤치마킹한 결과
Databricks가 자사 실제 코드베이스를 기반으로 여러 AI 코딩 에이전트의 성능과 비용을 직접 측정했고, 모델 토큰 가격과 실제 태스크 비용이 전혀 다르다는 점, 그리고 오픈소스 모델이 이제 최상위 수준에 도달했다는 점을 확인했다.
Reasoning에서 Uncertainty 추정하기: LLM의 다국어 및 교차언어 MCQA 성능 대규모 연구
LLM이 저자원 언어 질문을 받을 때 영어로 추론하게 하면 불확실성 추정 성능이 고자원 언어 수준으로 올라온다.
LLM-as-a-Verifier: 범용 Verification 프레임워크
LLM의 토큰 확률 분포를 활용해 discrete 점수 대신 continuous 점수를 뽑아내면, 추가 학습 없이 코딩·로봇·의료 에이전트 평가 정확도를 SOTA로 끌어올릴 수 있다.