Proton 뉴스레터 스팸 논란, AI 동의는 왜 늘 뒷전일까?

“보안과 프라이버시를 중시한다”는 서비스에서 스팸성 뉴스레터를 받으면, 기분이 묘해집니다. 이번 글은 1월 14일 Proton이 사용자의 뉴스레터 선택 범주를 무시한 채 이메일을 발송한 사건을 출발점으로, 이것이 왜 ‘단순 실수’로 끝나기 어려운지(특히 GDPR·영국 데이터 보호 관점), 그리고 비슷한 일이 AI 기능 확산 속에서 더 자주 벌어지는 구조적 이유까지 한 번에 정리합니다. 마지막에는 개인이 당장 할 수 있는 현실적인 대응도 덧붙였습니다.

Proton 뉴스레터가 ‘스팸’으로 느껴진 진짜 이유

문제의 핵심은 “메일이 왔다”가 아니라 “원치 않는 범주에서 왔다”는 점입니다. 사용자는 Lumo 업데이트 이메일 수신을 명확히 거부했는데도 해당 메일을 받았습니다. 구독/수신 동의는 보통 범주 단위로 관리되는데, 그 경계를 넘는 발송은 사용자 입장에선 ‘설정 무시’로 체감됩니다.

더 찜찜한 대목은 대응 방식입니다. Proton 지원팀은 사용자가 수신 거부를 분명히 했음에도 불구하고, 해당 이메일을 ‘Proton for Business’ 뉴스레터로 설명하며 오류를 인정하지 않았습니다. 같은 메일을 “다른 범주라서 보냈다”라고 설명해버리면, 사용자 동의가 “내가 체크한 것”이 아니라 “그들이 분류한 것”으로 바뀌어 버리니까요.

물론 Proton 측은 내부 시스템 문제로 확인되었고 기술 팀이 오류 수정을 약속하며 커뮤니케이션 동의를 중요시한다고 답변했습니다. 다만 사용자 경험 관점에서 보면, “수정하겠다” 이전에 “왜 이런 일이 가능했는지”가 먼저 설명되어야 신뢰가 복구됩니다.

GDPR·영국 데이터 보호법 관점에서 왜 민감한가

GDPR이나 영국 데이터 보호 체계에서 뉴스레터 같은 직접 마케팅 커뮤니케이션은 특히 예민한 영역입니다. 규제 당국도 불법 다이렉트 마케팅(원치 않는 홍보 메일)을 지속적으로 주요 집행 포인트로 봅니다.¹

여기서 논점은 대체로 두 가지로 갈립니다. 첫째, 동의(또는 정당한 이익 등)라는 ‘보내도 되는 근거’가 있었는가. 둘째, 사용자가 거부 의사를 밝혔을 때 그 의사가 시스템에 제대로 반영되었는가입니다. 사용자가 특정 업데이트를 “안 받겠다”고 해둔 상태에서 그와 사실상 동일한 홍보 성격의 메일이 다른 라벨로 발송되면, 법리적으로도 ‘거부권을 무력화한 것’처럼 읽힐 여지가 생깁니다.

그리고 현실에서 더 큰 문제는, 이런 사고가 한 번 나면 사용자는 “내 동의는 믿을 만한가?”라는 질문을 서비스 전체로 확장한다는 점입니다. Proton은 원래 종단간 암호화와 ‘제로 액세스(서비스 운영자도 내용을 볼 수 없다는 설계)’를 강점으로 내세우며 프라이버시 브랜드를 구축해온 서비스입니다.² 그래서 커뮤니케이션 동의 문제는 단순 마케팅 실수보다 브랜드 타격이 더 큽니다.

‘AI 동의’가 자꾸 무시되는 산업의 버릇

이 사건이 더 크게 읽히는 이유는, 지금 기술 업계 전체가 비슷한 방향으로 가고 있기 때문입니다. AI 기능은 이제 특정 앱에만 붙는 옵션이 아니라, 검색·메일·코딩·문서·클라우드 등 “거의 모든 영역”에 스며들고 있습니다. 문제는 기능이 퍼지는 속도에 비해, 사용자의 동의 설계가 자주 뒷전이라는 겁니다.

글에서 언급된 Microsoft의 GitHub Copilot SDK 홍보 이메일 역시 “내가 요청하지 않았는데 홍보가 왔다”는 점에서 동일한 불쾌감을 줍니다. 게다가 GitHub의 사용자 경험이 점점 악화되고 있다는 체감까지 겹치면, 사용자는 결국 이렇게 결론 냅니다. “AI는 편리함이 아니라, 내 관심과 선택을 무시하는 방식으로 들어온다.”

이게 단지 감정 문제로 끝나지 않는 이유는 간단합니다. 동의(Consent)는 프라이버시의 ‘기술 스펙’이 아니라 ‘관계의 약속’이기 때문입니다. 암호화가 아무리 강력해도, 서비스가 내 설정을 가볍게 넘는 순간 그 약속은 금이 갑니다.

“내가 끄면 끝”이 아닌 이유: 시스템 설계의 함정

뉴스레터 동의는 보통 이런 구조로 돌아갑니다. 사용자가 ‘A는 받기, B는 거부’를 선택하고, 내부에서는 구독 테이블/태그/세그먼트로 분리해 발송합니다. 그런데 운영 과정에서 제품 런칭, 캠페인 전환, B2B 마케팅 전개 같은 이벤트가 생기면 “이건 A냐 B냐” 경계가 흐려지고, 한쪽 시스템에서만 수신거부가 반영되거나 라벨링이 꼬일 수 있습니다.

즉, 사용자가 뭘 잘못해서가 아니라 “동의가 한 군데가 아니라 여러 군데에 흩어져 관리되는 구조”일 때 문제가 발생합니다. 그래서 이번 Proton 케이스도 기술적 버그일 가능성은 충분하지만, 사용자 입장에선 결과가 더 중요합니다. 내 의사가 통합적으로 존중되지 않았다면, 그건 기능의 문제가 아니라 신뢰의 문제입니다.

스팸·동의 문제를 줄이기 위한 현실적인 대응법

서비스를 당장 떠나기 전에, 최소한의 방어선을 만들 수는 있습니다.

첫째, 구독 설정 화면에서 범주별 동의 상태를 캡처해 두세요. 나중에 문의할 때 “나는 거부했다”를 감정이 아니라 기록으로 보여줄 수 있습니다.

둘째, 메일 헤더나 하단 푸터를 확인해 “어느 리스트(또는 어떤 발신 시스템)에서 나갔는지” 단서를 모으세요. 같은 회사라도 리스트가 분리돼 있으면 수신거부가 한쪽에만 먹는 경우가 있습니다.

셋째, 특정 서비스의 홍보 메일은 폴더 룰로 자동 분리해 ‘받되 안 보이게’ 만들 수도 있습니다. 근본 해결은 아니지만, 업무 집중력을 지키는 데는 효과가 큽니다.

마지막으로, 반복된다면 공식 채널로 “마케팅 커뮤니케이션 거부권 행사”를 명확히 남기고, 답변을 문서로 받아두는 게 좋습니다. 규제 환경상 이런 기록은 생각보다 강력한 압박 카드가 됩니다.

시사점 내용 (핵심 포인트 정리 + 개인적인 생각 또는 실용적 조언)...

이번 Proton 뉴스레터 사건은 “프라이버시 서비스도 동의 관리에서 실수할 수 있다”는 교훈을 남겼습니다. 하지만 더 중요한 메시지는 따로 있습니다. AI가 제품 곳곳에 침투하는 시대일수록, 사용자가 ‘원치 않는다’고 말할 수 있는 통로와 그 의사가 정확히 반영되는 시스템이 더 중요해진다는 점입니다.

저는 앞으로 서비스 선택 기준이 “암호화가 되냐”에서 한 단계 올라가, “동의가 한 번에 정리되고, 거부가 즉시 먹히며, 실수했을 때 투명하게 인정하느냐”로 이동할 거라고 봅니다. 결국 신뢰는 기능이 아니라 태도에서 생기니까요.

참고

¹Data law | UK Regulatory Outlook January 2026 | Osborne Clarke

²Proton Mail Review: Is it the Most Secure Email Service in 2026?