이메일의 미래

 (fastmail.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • AI가 받은편지함을 읽고 요약하며 작업까지 수행하는 환경에서는 발신자 검증이 이메일 신뢰의 핵심 조건이 됨
  • SPF, DKIM, DMARC는 서버 권한, 메시지 무결성, 실패 시 처리 방침을 결합해 이메일 인증의 기본 구조를 이룸
  • AI 필터와 AI 보조 도구가 이메일 경험의 표준 기능이 되면서, 인증 결과는 스팸·피싱 판단과 자동 작업의 중요한 입력값이 됨
  • Google과 Yahoo가 2024년 초 대량 발송자에게 DMARC 구성을 요구하면서, 인증 인프라는 안정적 전달의 기본 전제가 됨
  • 인증은 도메인 신원을 확인하지만 의도까지 보장하지는 못하며, 자동화된 이메일 환경에서 사칭의 비용과 복잡성을 높이는 역할을 함

이메일 인증: 이메일의 미래가 의존하는 신뢰 계층

  • 이메일은 오랫동안 스푸핑 문제를 안고 있었으며, 누구나 이메일의 “From” 필드에 무엇이든 넣을 수 있었음
  • 과거에는 주의 깊은 사용자가 미묘하게 다른 도메인명, 비현실적인 긴급성, 어색한 문구 같은 단서를 보고 문제를 알아차릴 수 있었음
  • AI 사용이 널리 퍼지면서 사용자가 이메일을 다루는 방식이 변하고 있으며, 메시지가 도착했는지보다 출처를 실제로 검증할 수 있는지가 더 중요해짐
  • 대부분의 이메일 사용자가 생각할 필요가 없었던 표준들이 이메일 경험의 기반으로 조용히 자리 잡고 있음

이메일 인증이란 무엇인가

  • 이메일 인증은 SPF, DKIM, DMARC라는 세 가지 맞물린 표준으로 구성됨
  • SPF는 메시지를 보낸 서버가 해당 도메인을 대신해 발송할 권한을 가졌는지 확인함
  • DKIM은 각 메시지에 암호화 서명을 붙여 수신 서버가 전송 중 변경 여부를 확인할 수 있게 함
  • DMARC는 SPF와 DKIM을 묶고, 검사에 실패한 메시지를 거부할지, 격리할지, 통과시킬지 수신 서버에 지시함
  • 이 세 표준은 은행이나 고용주가 보낸 것처럼 보이는 메시지가 실제로 해당 도메인에서 왔는지 받은편지함이 판단할 수 있게 함
  • 인증이 없으면 스푸핑된 메시지와 정상 메시지를 구분할 수 없으며, 이메일 상호작용 방식이 바뀌면서 이 문제가 더 커짐

AI가 이메일에 관여하는 방식

  • 이메일 경험에서 두 종류의 AI가 표준 기능으로 자리 잡고 있음
  • 첫째는 스팸, 피싱, 주목할 만한 메시지를 판단하는 AI 필터링임
    • 이런 시스템은 수년간 존재했지만, 현대 버전은 훨씬 더 강력해졌음
    • 인증 결과는 AI 필터가 결정을 내릴 때 점점 더 핵심 입력값이 되고 있음
  • 둘째는 받은편지함을 요약하고, 작업 항목을 드러내고, 답장을 초안으로 만들며, 경우에 따라 사용자를 대신해 행동하는 AI 보조 도구임
  • Fastmail은 받은편지함에 AI를 통합하지 않았고, 사용자 메일은 백그라운드에서 모델로 처리되지 않음
    • MCP 서버는 사용자가 명시적으로 승인한 경우 선택한 AI 클라이언트와 연결할 수 있는 API 엔드포인트임
    • 사용자가 연결하지 않으면 아무것도 달라지지 않음
  • 더 넓은 이메일 환경에서는 받은편지함에서 자율적으로 행동하는 AI 보조 도구가 점점 더 흔해지고 있음
  • 사람이 의심스러운 이메일을 읽을 때는 발신자 도메인에 추가 문자가 있거나 요청이 어색하다는 점을 알아차릴 수 있음
  • AI 보조 도구는 작업이 필요한 항목을 찾으며 콘텐츠와 긴급성을 읽고 그에 맞게 행동할 수 있음
  • 설득력 있는 스푸핑 메시지라면, 이메일이 받은편지함에 도달하기 전에 인증이 이를 막아야 함

인증은 인프라가 되고 있음

  • Google과 Yahoo는 2024년 초 대량 발송자가 안정적으로 이메일을 전달하려면 DMARC를 올바르게 구성하도록 요구하기 시작함
  • 이 변화로 인증은 발송자가 우선순위를 낮출 수 있는 항목에서 받은편지함에 도달하기 위한 기본 전제 조건으로 바뀜
  • 이메일 인증은 웹에서 HTTPS가 거친 경로와 같은 방향으로 가고 있음
    • HTTPS는 모범 사례에서 기대사항으로, 다시 인프라로 자리 잡았음
    • 브라우저 주소창의 자물쇠가 정확히 무엇을 뜻하는지 몰라도, 웹사이트에서 자물쇠가 없으면 무시할 수 없는 경고 신호가 됨
  • 새로운 표준들은 이 인증 기반 위에서 만들어지고 있음
  • BIMI는 검증된 발신자가 지원되는 받은편지함에 로고를 직접 표시할 수 있게 함
    • 콘텐츠만으로 AI 생성 피싱을 알아보기 더 어려운 시점에 작은 시각적 신뢰 신호가 됨
  • DKIM 설계는 실험적 ARC 명세에서 얻은 교훈을 바탕으로 다시 검토되고 있음
    • 복잡한 이메일 흐름에서 변경 사항을 추적하고 귀속해 필터링 시스템이 악성 콘텐츠의 출처를 판단할 수 있게 함
    • 잘못된 주체의 평판이 손상되는 일을 피하는 데 도움이 됨

인증만으로는 충분하지 않음

  • 인증은 도메인 신원을 확인하지만, 의도를 확인하지는 못함
  • 그럴듯한 유사 도메인과 올바르게 구성된 DMARC 레코드를 가진 사기꾼은 발신자 인증 검사를 통과할 수 있음
  • 인증은 사칭의 비용과 복잡성을 크게 높이며, 이메일의 미래가 더 자동화될수록 이 점이 더 중요해짐
  • 미래의 받은편지함은 오늘날 대부분의 사용자가 쓰는 것보다 더 빠르고, 더 똑똑하고, 더 많은 기능을 갖추게 됨
  • 인증은 그 미래가 단지 편리한 데 그치지 않고 신뢰할 수 있게 만드는 요소임
  • 표준은 수년 동안 성숙해왔으며, 이메일이 더 자동화되는 과정에서 이 기반 위에 계속 구축하는 일이 필요함

이메일은 사라지지 않음

  • 모두에게 이메일이 필요하며, 은행은 명세서를 보내고 의사는 예약 정보를 보내며 다른 사이트들은 비밀번호 재설정을 보냄
  • 모두가 이메일을 가지고 있음
  • 기술의 장수 가능성을 보여주는 가장 좋은 지표는 이미 얼마나 오래 존재했는지이며, 이메일은 오랫동안 존재해 왔음
  • Fastmail은 미래 이메일을 뒷받침할 표준 개발의 최전선에 있으며, 모두에게 더 나은 이메일을 만들기 위해 이메일과 함께 계속 진화할 것임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이게 실제로 얼마나 도움이 될지는 판단하기 어렵지만, 이메일이 더 안전해져서 조직들, 특히 은행·정부·보험사가 폐쇄형 보안 메시지함 같은 대안을 만들지 않게 되는 방향은 환영함
    “보안 메시지 센터에 로그인하세요”라고 해놓고, 거기서는 형식도 엉망인 메시지를 짧은 기간만 볼 수 있다가 영구 삭제되는 식임
    내 받은편지함은 어느 정도 검색 가능한 삶의 기록인데, 이런 대안들은 그걸 깨뜨림

    • 그런 “메시지 센터”는 보안뿐 아니라 컴플라이언스 때문이기도 함
      예를 들어 보험사는 HIPAA를 따라야 하고, 건강 관련 정보는 HIPAA를 준수하는 다른 시스템에만 보낼 수 있음
      그러려면 그 시스템과 BAA라는 계약을 맺어야 하는데, 이메일로는 현실적으로 불가능함
      보험사가 전 세계 모든 이메일 호스트와 계약할 수도 없고, 메일을 보낸 뒤 최종적으로 어디에 도달할지도 알 수 없기 때문임
      건강 정보가 들어간 이메일과 아닌 이메일을 정확히 가르는 것도 매우 어렵고, 사람 이름이나 IP 주소조차 문맥에 따라 해당될 수 있음
      그래서 그냥 모든 걸 메시지 센터로 보내는 쪽을 기본값으로 삼으며, 이메일 보안이 아무리 좋아져도 이 부분은 바뀌기 어려움
    • 안전한 이메일을 만들려면 이메일에서 HTML/CSS 지원을 빼고, 받은편지함은 초대 기반으로 동작해야 한다고 봄
      소셜 네트워크에서 친구 추가하듯 발신자를 미리 승인하는 방식이어야 함
    • 그런 보안 메시지 플랫폼은 백업을 거의 불가능하게 만듦
      의료 클리닉이 법정에서 불리해질 수 있는 메시지를 삭제하는 것도 봤음
      그래서 그런 걸 보내는 사람에게는 진짜 이메일로 보내라고 말함
    • 내 은행은 “중요한 메시지를 읽으려면 앱에 로그인하세요”라는 푸시 알림을 보내는데, 대개 월간 명세서 같은 것임
      그리고 이메일도 따로 보내서, 가끔 또 다른 메시지인 줄 알고 다시 로그인하게 됨
      “이 메시지를 PDF로 다운로드” 버튼도 있는데, 실제로는 웹브라우저 래퍼로 이동할 뿐임
    • 최근 은행에 정보를 문의했는데 이메일로는 못 보내지만 우편으로는 보낼 수 있다고 했음
      다음 주쯤 도착할 거라 함
      분명 여러 컴플라이언스 이유가 있겠지만, 전혀 말이 안 된다고 느껴짐

  • 글을 읽다가 끝에 도달하고 놀랐음. 전체가 뭔가 발표나 새로운 것을 위한 서론처럼 느껴졌는데 아무것도 나오지 않았음
    내가 둔한 걸 수도 있지만, 그래서 핵심 결론이 뭐였는지 모르겠음

    • Fastmail 사용자로서 발표가 없어서 오히려 다행임
      회사가 밝은 미래를 말하기 시작할 때마다 보통 내 사용자 경험이 곧 나빠진다는 뜻이었음
    • “Fastmail이 말하는 이메일의 미래”라길래 바로 큰 발표를 예상했음
      실제로는 “이제 DMARC를 통과해야 한다”는 얘기인데, 그건 이미 2년 전부터 사실이었음
      인증이 위조 도메인을 막는 데 도움이 된다는 내용도 맞긴 하지만, 가장 큰 문제는 위조 도메인이 아니라고 봄
      공격자는 PayPal, Stripe 같은 결제 플랫폼이 이메일을 보내게 만드는 방법을 찾아냄
      생성되는 이메일에 어떤 정보가 들어가는지 파악한 뒤, 회사명을 “문제가 있으니 이 번호로 전화하세요” 같은 식으로 설정함
      그러면 실제 PayPal에서 온, 모든 인증을 통과하는 정상 이메일의 제목이나 본문에 그 회사명이 들어가 긴급해 보이게 됨
      이런 메일은 실제 회사에서 발송되고 인증도 모두 통과하므로 DMARC로 잡을 수 없으며, 최근 공격자들이 바로 이런 식으로 움직이는 걸 보고 있음
      Fastmail이 이 문제를 다룰 뭔가를 내놓길 진심으로 기대했음
    • “미래의 받은편지함은 오늘날 대부분이 쓰는 것보다 더 빠르고, 더 똑똑하고, 더 많은 일을 할 수 있을 것이다”
      요약하면 이 정도임. 거기에 어떻게 도달할지는 모르지만 이메일은 더 빠르고 똑똑해질 거라는 얘기임
    • 나도 비슷했음. 뭔가 결정적인 내용이 나오길 기다렸는데 결국 “이메일은 사라지지 않는다”였음
      솔직히 왜 이 글이 올라오고 추천을 받는지 궁금함

  • Fastmail을 좋아함. 몇 년 전 Proton에서 옮겼는데, 암호화 이메일의 절충점이 그만한 가치가 없다고 판단했기 때문임
    Proton을 완전히 신뢰하더라도 대부분의 이메일은 어차피 AWS, Outlook, Gmail에서 오가게 됨
    Fastmail 서비스에는 매우 만족하고 있음. 가격도 적절하고, 큰 받은편지함에서도 아주 빠르며, 불필요한 기능이나 비대함을 추가하지 않음
    원래는 운영체제 기본 메일 앱을 쓰려 했지만 Fastmail 앱과 웹사이트가 좋아서 그냥 그것만 쓰게 됨

    • Fastmail을 9년 넘게 쓰고 있음. 특히 앱에 오프라인 지원이 추가된 뒤로는 떠날 이유가 전혀 없어짐
    • Proton에서 어떤 절충점이 있었는지 궁금함
    • Fastmail 데스크톱 앱은 말 그대로 웹사이트를 감싼 것인데, 추가된 기능이 하필 뒤로 가기 버튼 없음임
      30년 동안 웹메일을 쓰며 쌓인 근육 기억이 이 “앱” 때문에 무용지물이 됨
      어떤 웹 개발자가 데스크톱 앱 개발자 흉내를 내고 싶었던 모양임
      실수도 아니고, 이전 페이지로 돌아가는 키보드 단축키를 일부러 넣지 않은 선택이라고 함
      고객지원 담당자는 이를 “기능 요청”으로 추가하겠다고 했음

  • 우리는 사실상 이메일 판단을 AI에 외주화하면서, SPF/DKIM을 강화해 보완하려는 중임
    자물쇠를 더 튼튼하게 만들면서 마스터키는 더 많이 나눠주는 느낌임

    • 이 영역에는 여러 일이 동시에 벌어지고 있다고 봄. Fastmail은 자기들에게 유리한 방식으로 그중 하나를 말로 표현한 것뿐임
      Fastmail이 이메일에 대해 절대적 권위를 가진 것처럼 말할 수는 없음
      Fastmail은 이메일 그 자체가 아니라, 이메일에 종속된 서비스이기 때문임

  • 받은편지함을 옮기고 원하는 제공자로 라우팅할 수 있기 전까지, 이런 인증 체계는 대규모에서 실제 가치를 갖기 어려워 보임
    전화번호를 이동할 수 있다면 이론적으로 이메일 주소도 옮길 수 있어야 함
    여기 나온 인증 시스템들은 그런 이동성을 가능하게 할 만큼 충분히 도움이 되지 않음
    어떤 제공자를 쓰든, 이메일 도메인명이 아니라 사람 자체를 인증할 유효한 방법이 필요함
    즉 호스팅 제공자 자체를 대신해 서명할 수 있는 표준이 발전해야 함

  • 2026년에도 이메일 서명과 암호화가 기본이 아니라는 건 말이 안 됨
    하지만 대형 이메일 업체들의 사업 모델이 우리가 그걸 쓰지 않는 데 의존하는 한, 아마 계속 그렇게 될 것 같음

    • 이메일이 암호화되면 그 모델은 말 그대로 작동할 수 없음
      받은편지함을 실제로 쓸 만하게 만들려면 모든 머신러닝 처리가 돌아야 하고, 그러려면 이메일이 암호화되지 않아야 함
    • 대형 제공자들은 아무도 그걸 원하지 않음
      그렇지 않았다면 Microsoft가 Outlook 데이터를 1000개 파트너와 공유하기 훨씬 어려웠을 것임
    • 2026년에 이메일 암호화를 밀어붙이는 건 실제 보안 관행보다 체크박스 요구사항을 더 중시한다는 신호에 가까움
      암호화 이메일은 그럴듯하게 들리지만, 실제 위협을 따져 보면 현재 상태와 비교해 보호해 주는 것이 많지 않고 기능도 많이 잃음
      기본 전제부터 보면 이메일은 내 컴퓨터에서 메일 서버까지, 내 메일 서버에서 수신자 메일 서버까지, 수신자 메일 서버에서 수신자 컴퓨터까지 이미 암호화됨
      나와 수신자 외에 볼 수 있는 주체는 중간의 메일 서버들뿐이고, 암호화 이메일로 얻을 수 있는 최선도 이 과정에서 핵심 역할을 하는 일부 주체를 빼는 정도임
      특히 이메일 헤더는 계속 공개되므로 최선의 경우조차 아주 사적인 통신이 되지는 않음
      반면 암호화 이메일은 서버 측 필터 같은 처리를 깨뜨림. 스팸 처리도 마찬가지인데, 특히 스팸 폴더에도 도달하지 않는 막대한 양의 스팸을 생각하면 실용적 해법이 없음
      사용자는 웹메일에 로그인해 바로 메일을 읽을 수 있기를 기대하고, 웹메일은 지배적인 이메일 클라이언트임
      이를 해결하려고 서버에 키를 주면, 서버가 다시 이메일을 읽을 수 있는 주체가 되어 현재 상태와 다를 게 없어짐
      더 큰 문제는 키 배포임. 메일을 보내려면 수신자의 키를 찾아야 하는데, 대규모에서 가장 실용적인 방식은 메일 서버에 사용자 공개키를 물어보는 것임
      그런데 그 서버는 해당 사용자에게 가는 모든 메시지를 가로챌 수 있는 유일한 주체이므로, 자기 키를 내주고 암호화를 벗긴 뒤 다시 사용자에게 암호화해도 들키기 어려움
      PGP 키서버 같은 대안도 통하지 않음. PGP 암호화에 관심 있는 사용자가 백만 명도 안 되던 시절에도 PGP 키서버 생태계는 몇 년 전 무너졌고, 수십억 이메일 사용자 규모와는 비교가 안 됨
      암호화 이메일은 이메일 업체의 사업 모델 때문이 아니라, 이메일 아키텍처가 이미 충분히 괜찮은 보안을 제공해서 추가 암호화의 이점을 살리기 매우 어렵기 때문에 실현성 낮은 꿈에 가깝다고 봄
    • 새로운 이메일은 이메일이 아니라 Matrix나, 중앙화를 감수한다면 Signal 같은 것에 가까울 것임
      좋은 사용자 경험과 훌륭한 암호화를 갖춘 시스템이어야 함

  • 글에서 DKIM이 이메일 전달에서 깨지지 않도록 하려던 실패한 ARC 제안을 언급함
    https://www.ietf.org/archive/id/draft-adams-arc-experiment-c...
    Google이 ARC에서 다른 방식으로 옮겨가도록 설득될 수 있을지 흥미로움
    요즘 Gmail은 이메일 서버 평판을 매우 중시해서, 마음에 들지 않는 메일 서버를 안정적으로 나쁘게 취급할 수 있음

  • “두 번째는 AI 지원이다. 받은편지함을 요약하고, 실행 항목을 띄우고, 답장을 초안으로 만들고, 경우에 따라 사용자를 대신해 행동하는 도구들”
    이 부분이 가장 사악함. 결국 봇이 봇과 대화하고, 사람은 빠지는 구조가 됨
    모든 이메일 문제는 GPG로 해결할 수 있지만, 그러면 Fastmail 같은 이메일 서비스의 사업이 망가짐
    사용자 이메일을 읽고 분석할 수 없고, 광고도 못 하고, 사용자 프로필을 광고 회사에 팔 수도 없고, 사용자 데이터로 AI를 학습시킬 수도 없기 때문임
    내가 보고 싶은 이메일의 미래는 그런 쪽임. 안타깝게도 아무도 GPG를 쓰지 않고, 사람들에게 가르치기도 꽤 어려움

    • 결국 우리는 이 길로 몰리게 될 테니 인내심을 가지면 됨
      통신이 진짜임을 증명하는 유일한 방법은 대면으로 미리 키 교환을 하는 방식이 될 것임
      GPG는 그중 한 길일 뿐이고, 누군가 조직 수준에서 쉽게 만들 방법을 내놓을 것임
    • Fastmail이 사용자 이메일을 읽거나 분석해서 광고를 팔고 있나? Fastmail이 사용자 이메일로 AI 모델을 학습시키나?
      분석에는 메시지 내용보다 메타데이터가 더 가치 있음. GPG가 그건 어떻게 해결하나?

  • 이 글이 JMAP에 관한 내용이길 기대했음

    • 이 글에서 SPF, DKIM, DMARC를 알게 됐고, 꽤 괜찮은 기술적 개선처럼 보였음
      본문 암호화는 아니지만 기본 이메일 환경에도 아직 개선 여지가 있다는 걸 보여줌
    • JMAP이 뭔지 몰랐는데 찾아보고 나니 동의하게 됨

  • 취미 프로젝트에서 모든 규칙을 지키고 올바른 헤더를 넣어도 이메일을 보낼 수 없다는 게 답답함
    jeremyevans의 자체 이메일 호스팅 글은 재미있게 읽었지만, 수신에 관한 내용일 뿐 발신은 다루지 않음
    https://code.jeremyevans.net/2021-07-29-running-my-own-email...

답변달기