"암호화된 이메일"이라는 표현은 안심을 주지만, 실제로는 서로 다른 시점과 목적의 여러 기술이 뒤섞인 모호한 말이다. 이메일은 내 기기와 서버 사이, 서버와 서버 사이, 그리고 디스크에 저장된 상태에서 각기 다른 방식으로 보호되며, 각 방식이 막아주는 위협과 치르는 대가가 전혀 다르다. 따라서 의미 있는 선택을 하려면 먼저 자신에게 어떤 위협이 현실적인지부터 따져야 한다. 대다수 사용자에게 중요한 것은 네트워크 도청이나 계정 탈취 같은 일상적 위험이고, 기자나 활동가처럼 공급자 내부자나 정부의 법적 강제까지 경계해야 하는 사람은 소수다. 이 글은 이메일 암호화를 세 층위로 나눠, 각 층위가 무엇을 지키고 무엇을 지키지 못하는지 정리한다.
전송 구간: TLS와 신원 확인
내 기기와 이메일 서버 사이는 TLS(전송 계층 보안)가 모든 트래픽을 암호화한다. 이것만으로도 같은 와이파이의 도청자, ISP, 경로상의 감시자로부터 보호된다. 최신 버전인 TLS 1.3은 가장 강력한 암호 스위트를 강제하며 오늘날 안전한 인터넷의 기반이 됐다. 그러나 암호화만으로는 부족하고, 상대가 진짜 내 공급자인지 확인하는 절차가 필요하다. 여기서 공개키 기반구조(PKI)가 작동한다. 서버는 Let's Encrypt 같은 신뢰할 수 있는 인증기관(CA)이 서명한 인증서를 제시하고, 클라이언트는 내장된 CA 목록과 대조해 그 도메인에 정당하게 발급된 것인지 검증한다. 공격자가 트래픽을 가로채더라도 자신이 통제하지 않는 도메인의 유효한 인증서는 얻을 수 없다.
이 체계는 인증서 투명성(CT) 로그로 한층 강화됐다. CT 로그는 참여 CA가 발급한 모든 인증서를 공개적으로 기록하는 추가 전용 장부로, 도메인 소유자는 자기 도메인에 대한 부정 발급을 감지할 수 있고 브라우저는 로그에 기록되지 않은 인증서를 신뢰하지 않는다. CA가 침해되거나 속아 넘어간 사례가 간혹 있었지만, PKI와 CT의 결합은 암호화된 연결이 의도한 서버에서 끝난다는 실용적 보증을 제공한다. 공급자 차원에서는 HSTS로 브라우저가 TLS 없이 접속하지 않도록 하고, 암호화되지 않은 IMAP·POP·SMTP 포트를 닫아 STARTTLS보다 "암묵적" TLS를 선호하는 방식이 권장된다.
서버 간 전송: 기회적 TLS의 한계
더 까다로운 문제는 발신 서버에서 수신 서버로 넘어가는 구간이다. 서버 간 암호화는 "기회적(opportunistic) TLS"에 의존하는데, 이는 상대 서버가 암호화를 지원하면 쓰고 아니면 평문으로 전달하는 방식이다. 문제는 능동적 공격자가 중간에서 STARTTLS 명령을 제거해 평문 연결을 강제하는 중간자 공격이 가능하다는 점이다. 게다가 서버는 기본적으로 인증서를 검증하지 않는데, 어차피 공격자가 평문으로 되돌릴 수 있는 상황에서는 검증이 보안에 보탬이 되지 않기 때문이다. 암호화를 지원하지 않는 서버와 오가는 정상 메일이 아직 많아, 모두에게 암호화를 의무화하면 받아야 할 메일을 잃게 된다는 현실적 제약도 있다.
이 취약점을 보완하는 두 프로토콜이 MTA-STS와 DANE인데 둘 다 보급은 제한적이다. MTA-STS는 도메인이 유효한 인증서를 갖춘 암호화 연결을 요구한다고 선언하는 방식으로, DNS 레코드와 HTTPS로 제공되는 정책 파일만 있으면 되고 문제가 생겨도 최악의 경우 일부 수신 메일이 지연·반송될 뿐 웹사이트 등 다른 용도에는 영향이 없어 배포가 비교적 수월하다. DANE은 DNSSEC로 서명된 DNS 레코드에 인증서 정보를 직접 게시해 CA 의존성과 "최초 신뢰" 약점을 없애지만 운영 비용이 크다. DNSSEC은 모든 TLD가 지원하지 않고 배포가 복잡해 심각한 장애 가능성을 높인다. 라우팅 문제는 고치면 즉시 복구되지만 DNSSEC 오류는 깨진 레코드가 캐시에 수 시간에서 며칠씩 남는다는 점에서 유독 가혹하다. 2023년 10월 클라우드플레어의 1.1.1.1 리졸버가 캐시된 루트 존의 DNSSEC 서명 만료로 장시간 장애를 겪었고, 같은 해 5월 뉴질랜드 .nz 도메인은 통상적인 키 교체 중 며칠간 가용성 사고를 냈다. 이런 이유로 Fastmail은 DANE의 기밀성 이점이 가용성 위험을 감수할 만하지 않다고 보며, 구글과 야후도 MTA-STS를 택했다. 실무적 결론은, 주요 공급자 사이를 오가는 메일은 거의 확실히 전송 중 암호화되지만, 네트워크를 조작할 수 있는 국가급 공격자는 DANE·MTA-STS가 없을 때 연결을 강등시킬 여지가 남는다는 것이다.
저장 상태와 종단간 암호화의 딜레마
메일이 서버에 도착하면 저장 시 암호화가 디스크 위의 데이터를 보호한다. 대개 BitLocker, LUKS, ZFS 같은 전체 디스크 암호화로, 키는 공급자가 보유한다. 이 구조는 데이터센터에서 하드디스크를 물리적으로 탈취당하거나 폐기 드라이브가 제대로 지워지지 않은 경우를 막고 GDPR·HIPAA 같은 규정 준수에도 기여한다. 다만 공급자가 키를 쥐고 있으므로 유효한 법원 명령에는 복호화해 제출할 수밖에 없고, 공격자가 서버를 완전히 장악하면 키가 이미 메모리에 올라 있어 아무 보호도 되지 않는다. Proton Mail이나 Tuta가 제공하는 무접근(zero-access) 암호화는 키를 기기에서 비밀번호로 파생해 공급자조차 복호화할 수 없게 하는데, 내부자 위협이나 정부 강제를 경계하는 사람에게는 정당한 선택이지만 기능 면의 상당한 대가가 따른다.
발신자와 수신자만 읽을 수 있는 진짜 종단간 암호화는 1990년대부터 S/MIME과 OpenPGP로 존재했지만 수십 년간 대중화에 실패했다. S/MIME은 CA 인증서를 쓰며 내부 디렉터리로 공개키를 찾을 수 있는 기업 환경 밖에서는 거의 쓰이지 않는다. OpenPGP의 "신뢰의 웹"은 사실상 죽었다는 것이 보안 연구자들의 평가이며, 메타데이터 유출, 전방향 비밀성 부재, 키 교체의 비현실성 등 설계 문제가 많다. 1999년 "조니는 왜 암호화를 못 하나" 연구에서 참가자 12명 중 4명만이 90분 안에 제대로 암호화했고, 2006년과 2019년 후속 연구에서도 사용자들은 여전히 타인의 공개키를 찾고 검증하는 데 어려움을 겪었다. PGP 창시자 필 짐머만조차 2015년 버전 호환성 문제로 메일 복호화에 애를 먹었다.
근본 난제는 키 배포와 교체다. 상대에게 암호화 메일을 보내려면 먼저 그의 공개키를 구하고 그것이 진짜 그의 것임을 확신해야 하는데, 이를 위한 인프라도, 키를 주기적으로 교체할 수단도 아직 없다. 키 교체가 없으면 키나 비밀번호가 한 번 유출될 경우 과거에 가로챈 메일까지 모두 복호화된다. 시그널이나 왓츠앱이 자동으로 암호화를 처리하는 것은 한 조직이 앱 설치 시 키 생성부터 전화번호 기반 연락처 탐색, 프로토콜 일괄 갱신까지 전체 소프트웨어 스택을 통제하기 때문이다. 어떤 클라이언트든 어떤 서버와도 통신하는 이메일의 연합(federated) 구조에서는 이런 통합 방식이 불가능하다. 더구나 종단간 암호화는 서버가 내용을 읽지 못하면 서버 측 검색, 피싱·악성코드 탐지, 다기기 동기화가 모두 무너지고, To·From·Date 같은 헤더는 이메일의 기본 동작을 깨지 않고는 암호화할 수 없다는 구조적 한계와 정면으로 충돌한다. 결국 실무자가 기억할 점은, 이메일 암호화에 만능 해법은 없으며 자신의 위협 모델에 맞춰 기밀성과 가용성·기능성 사이의 균형을 의식적으로 선택해야 한다는 것이다.