1P by GN⁺ 5일전 | ★ favorite | 댓글 1개
  • HSBC가 고객의 이메일 수신 여부를 추적 픽셀로 판단한 결과, 실제로는 정상 수신 중인 고객에게 “메일이 반송됐다”는 잘못된 통지를 보냄
  • 은행은 고객이 이메일 주소를 업데이트해야 한다고 요구했으나, 고객 계정에는 이미 올바른 주소가 등록되어 있었음
  • 분석 결과 HSBC의 이메일에는 HTTP 기반 추적 픽셀이 삽입되어 있었으며, 이는 수신 시점·빈도·IP 주소 등 개인 정보를 노출할 위험이 있음
  • 추적 픽셀은 차단 설정 시 작동하지 않기 때문에, 은행이 이를 근거로 “메일 미수신”을 판단한 것은 기술적 오용으로 지적됨
  • HSBC는 비암호화 추적 중단·프라이버시 존중·명확한 고객 커뮤니케이션으로 전환해야 함

HSBC의 잘못된 이메일 반송 통보

  • HSBC는 고객에게 “이메일이 반송됐다”며 주소 갱신을 요청하는 우편 통지서를 발송
    • 고객은 실제로 HSBC의 이메일을 정상적으로 수신·열람 중이었음
    • 온라인 계정 확인 결과, 등록된 이메일 주소는 정확했음
  • 고객센터 채팅 상담에서는 “은행이 편지를 보냈다면 주소를 변경해야 한다”는 형식적 응답만 반복
    • 이후 전화 상담에서야 “주소가 올바르다면 편지를 무시해도 된다”는 답변을 받음
  • 작성자는 HSBC에 “조치 필요” 문구 대신 “주소 확인 필요”로 수정할 것을 제안

이메일 추적 픽셀의 구조와 문제점

  • HSBC의 이메일 하단에는 두 개의 1×1 픽셀 크기의 이미지 코드가 포함되어 있었음
    • 이 픽셀은 수신자가 메일을 열 때 서버에 접속해 열람 여부를 기록하는 추적 장치로 사용됨
  • HSBC는 이 픽셀을 HTTP 프로토콜로 전송하고 있었으며, 이는 네트워크 상의 제3자가 열람 사실을 알 수 있게 하는 보안 취약점을 초래
    • 공용 Wi-Fi 환경에서는 같은 네트워크 사용자가 해당 정보를 감지할 가능성 존재
  • 또한 공격자가 이메일 하단에 이미지를 삽입해 피싱 메시지로 위조할 위험도 언급됨

추적 픽셀의 비신뢰성과 오용

  • 작성자는 추적 픽셀 차단 설정을 사용해 이메일 열람 정보를 송신하지 않음
    • 이는 이메일이 설계된 본래 방식이며, 수신자가 열람 여부를 선택적으로 공개할 수 있음
  • HSBC는 픽셀 신호가 없자 이를 “메일 미수신”으로 오인하고 반송 처리한 것으로 보임
    • 이는 추적 픽셀을 통계적 분석이 아닌 개별 고객 판별 수단으로 오용한 사례
  • 결과적으로 HSBC는 “메일이 반송됐다”는 허위 통보를 발송한 셈이 됨

HSBC에 제시된 개선 제안

  • 비암호화(HTTP) 추적 중단: 이메일 열람 시 네트워크 노출을 방지하기 위해 HTTPS 사용 필요
  • 추적 차단을 수신 거부로 간주하지 말 것: 픽셀 작동 실패는 다양한 기술적 이유로 발생 가능
  • 고객 이메일 습관 감시 중단: 이미 충분한 개인정보를 보유한 은행이 추가 감시를 할 필요 없음
  • 이메일 유효성 검증은 직접 확인 방식으로 수행: “확인 링크 클릭” 등 명시적 동의 기반 절차 권장
  • 데이터 윤리 원칙 준수: HSBC가 공개한 ‘데이터와 AI의 윤리적 사용 원칙’에 따라 목적 적합성·투명성 확보 필요

결론

  • HSBC는 추적 픽셀의 신뢰성 한계를 오해해 고객 이메일을 잘못 판단함
  • 이 사례는 감시 자본주의적 데이터 수집 관행이 금융기관 운영에까지 침투했음을 보여줌
  • 작성자는 HSBC가 기술적 오류를 인정하고, 투명한 데이터 사용과 고객 프라이버시 보호를 강화해야 함을 강조함
Hacker News 의견들
  • 2026년에 아직도 HTTP로 콘텐츠를 제공했다는 점이 눈에 띄었음
    보안 검토만 제대로 했어도 걸렸을 텐데, 아예 그 단계를 생략한 듯함
    나는 은행 데이터를 다루는 일을 하는데, 내부 시스템도 마찬가지로 엉망
    같은 은행 내에서도 CSV 날짜 형식이 제각각이고, 거래 설명은 잘린 문자열로 표준화가 안 되어 있음
    규제 압박이 이렇게 심한데도 여전히 이런 상태인 건, 대부분의 은행이 디지털 인프라를 낡은 배관처럼 취급하기 때문임

    • 나도 은행 데이터를 다뤄봤는데, 실제로는 OFX라는 표준 포맷이 있음
      하지만 각 은행이 메모 길이를 다르게 자르거나, AMEX처럼 NAME과 MEMO 필드를 뒤바꾸는 등 엉망임
      그래도 최소한의 표준은 존재함
      관련 문서: Open Financial Exchange, Financial Data Exchange
    • 은행들이 온라인 뱅킹 UI에는 그렇게 신경 쓰지 않음
      ATM 화면조차도 마찬가지로 낡은 느낌임
    • 사실 HTTP를 의도적으로 사용하는 경우도 많음
      예를 들어 ACME HTTP-01 챌린지나 인증서 발급, CRL/OCSP 응답 등은 여전히 HTTP를 씀
      RFC8555, Let's Encrypt 문서 참고
      따라서 “HTTP는 이제 쓸모없다”는 식의 일반화는 틀린 주장임
    • 이 경우에 HTTP가 정말 문제인지 모르겠음
      HTTPS도 SNI를 교환하므로, 누가 HSBC와 통신 중인지 알 수 있음
      URL의 나머지는 익명화된 추적 ID일 뿐이라, 실제 위협은 크지 않아 보임
    • 아마도 이메일 추적을 담당하는 서드파티 서비스가 HTTP로 콘텐츠를 제공했을 가능성이 큼
      HTTPS를 쓰면 설정과 인증서 관리가 더 복잡해지기 때문임
  • 이런 일이 왜 벌어졌는지 궁금했음
    은행 IT에서는 이런 이메일 추적 기능 하나 도입하는 데도 수십 명이 관여하고 1년은 걸림
    그 과정에서 “2026년에 HTTP는 위험하다”는 말을 한 개발자가 분명 있었을 텐데, 결국 중간 관리자들이 무시했을 가능성이 큼

    • 나도 FAANG에서 이메일 콘텐츠 제작팀을 지원했는데, “오픈 트래킹은 신뢰할 수 없다”고 수없이 설명해도 아무도 안 들음
      경영진은 왜 어떤 사람은 열었는데 기록이 없냐고, 왜 안 열었는데 기록이 있냐고 계속 물음
      작성자들은 클릭률보다 오픈율이 높게 나오니 그걸 성과 지표로 삼음
      결국 모두가 자신이 잘하고 있다고 느끼기 위해 부정확한 지표를 사용함
    • 유능한 사람도 있겠지만, 대형 은행의 기술직은 대부분 동기부여가 사라진 상태
      경영진이 모든 결정을 내리고, 개발자는 그냥 시키는 대로 함
      나도 예전에 대형 은행에서 일했는데, 몇 년 만에 떠나는 사람 아니면 그냥 “버튼 누르고 월급 받는 사람”으로 남음
    • 그래도 최소한 이메일로 알림을 보내주는 게 낫다고 생각함
      “중요한 메시지가 있습니다, 로그인하세요” 식의 메일보다 훨씬 나음
    • 이런 현상은 ‘state of the practice’ 라고 생각함
      아파트 앱처럼 편의 기능이 점점 강제되고, 결국 모든 사용자가 따라야 하는 구조로 변함
      그 과정에서 개인의 통제권이 줄어듦
    • 솔직히 이런 조건에서 유능한 개발자가 은행에 남을 이유가 없음
      급여나 환경이 좋은 것도 아니고, 혁신의 여지도 거의 없음
  • NAB Australia도 똑같이 함
    이메일에서 원격 이미지를 불러오지 않으면, “이메일이 전달되지 않는다”며 종이 명세서로 전환했다고 우편을 보냄
    실제로 이메일은 잘 오고 있었음

    • 나도 Capital One에서 비슷한 일을 겪었음
      이메일을 읽지 않는다고 판단해 잔액 알림을 자동으로 비활성화했음
      읽음 확인을 끄고 원격 리소스를 차단했을 뿐인데 말임
      결국 은행을 옮겼음
    • 은행이 고객이 이메일을 받았는지 확인할 필요는 있지만, 종이 우편이 더 불안정
      아파트 우편함은 종종 잘못 배달되거나 도난당하고, 심지어 불에 타기도 함
  • 예전에 Bank of America에서 마케팅 스팸을 받았는데, 구독 해지 옵션이 없었음
    그래서 해당 이메일 주소를 비활성화했더니, “이메일이 반송된다”며 우편으로 수정 요청을 보냄
    결국 몇 년간 비활성화 상태로 두다가 나중에야 이메일 환경설정 기능이 생김
    아내는 아직도 Citi에서 스팸 우편을 받는데, 거기도 해지 방법이 없음
    이런 걸 보면 HSBC IT팀이 트래킹 픽셀을 근거로 “메일을 안 읽었다”고 판단한 건 정말 어리석은 일임
    요즘 대부분의 이메일 클라이언트는 이미지를 기본적으로 차단함

  • HSBC의 기술력은 정말 최악임
    온라인 뱅킹 앱은 2000년대 초반 수준이고, 가족 중 한 명이 아직 쓰고 있는데 계속 오류가 남
    사용자 실수가 아니라 시스템 문제임

  • 은행이 고객 말을 듣게 하려면 계좌를 해지하는 게 가장 효과적임
    물론 실제로 옮길 각오가 있어야 함

    • 하지만 요즘 은행은 계좌로 돈을 버는 구조가 아니라서, 해지해도 타격이 거의 없음
    • 대신 규제 기관에 신고하는 게 훨씬 효과적임
      문제를 공식적으로 기록해두면 반복될 때 조치가 가능함
    • 사실 HSBC는 스스로 정상 계좌를 닫은 사례도 있음
      The Guardian 기사 참고
      나도 그때 피해를 봤고, 이후 Wise로 옮겼음
  • Capital One도 비슷한 일을 함
    그래도 “최근 이메일을 열지 않았다”고 명확히 알려줘서 무슨 뜻인지 이해는 됨
    실제로는 이메일을 열었지만 트래킹 픽셀을 차단했을 뿐임

    • 나도 같은 문구가 보이면 Gmail 규칙으로 자동 삭제되게 해둠
      그들의 문제를 내가 해결해줄 이유는 없음
  • Gmail은 이미지를 미리 다운로드하므로, 실제로는 사용자가 열지 않아도 트래킹 픽셀이 호출됨

    • 나도 고등학생 대상 기술 윤리 수업에서 Gmail 계정으로 이걸 시연했는데, 실제로 작동하는 걸 보고 놀랐음
    • Apple Mail이나 대부분의 웹메일도 마찬가지라, 오픈 신호는 거의 무의미함
    • Gmail은 같은 이미지를 여러 사람에게 보낼 때 휴리스틱 필터링을 적용한다고 들었음
      직접 테스트해보진 않았지만, 다른 메일 서비스도 비슷할 듯함
    • Gmail이 이미지를 다운로드할 때는 GoogleImageProxy로 식별되고, GCP ASN에서 요청이 옴
      대부분의 이메일 서비스가 악성코드 검사를 위해 서버 측에서 이미지를 미리 불러오기 때문에
      실제로 픽셀 트래킹은 거의 항상 외부 이메일 서비스 제공자가 처리함
  • 나도 HSBC에서 똑같은 일을 겪었음
    디지털 신분증으로 10분 만에 계좌 개설하고, 하루 만에 Apple Pay 카드를 받았을 정도로 프로세스는 훌륭했음
    그런데 마케팅 메일 수신을 거부했더니, “환영 업셀” 메일을 보내고 그게 반송되자 계좌를 차단
    결국 OP와 같은 상황을 겪었음

  • Charles Schwab도 비슷함
    이메일이 잘 오는데도 “전달되지 않는다”며 종이 명세서로 전환함
    실제 문제는 트래킹 픽셀 차단

    • 나도 Fidelity에서 같은 문제를 겪는 듯함
      커스텀 도메인 이메일은 오류가 나는데, ProtonMail 주소는 잘 작동함
      아마 ProtonMail은 트래킹 픽셀을 차단하지 않기 때문일 것임
    • Capital One도 동일함
      이제는 그냥 신경 끄기로 했음
      종이 우편이 그들에게 돈이 드니, 언젠가 깨닫겠지 하는 마음임