[2026-04-13] 지메일 모바일 앱에 ‘종단간 암호화’ 도입

 

 

 

오늘의 뉴스클리핑의 이슈는 바로 지메일 모바일 앱에 ‘종단간 암호화’ 도입 입니다 - !

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

- 지메일 모바일 앱에 ‘종단간 암호화’ 도입

 

구글이 Google의 이메일 서비스인 Gmail 모바일 앱에 종단간 암호화(E2EE) 기능을 도입하면서 기업용 이메일 보안 수준을 크게 강화했다. 이번 기능은 기존 서버 기반 암호화와 달리, 사용자의 단말기에서 직접 암호화가 이루어지고 복호화 키도 외부에 저장되기 때문에 구글조차 메일 내용을 확인할 수 없는 구조를 갖는다. 이를 통해 기업 데이터 유출 위험을 줄이고, 클라우드 환경에서도 높은 수준의 보안을 제공하려는 전략으로 해석된다.

 

종단간 암호화(E2EE) -> 데이터를 누가 볼 수 있는지에 대한 보안 개념
1) 송신자와 수신자만 데이터를 복호화할 수 있도록 하는 보안 모델
2) 중간에 있는 서버나 서비스 제공자는 암호화된 데이터만 전달할 뿐 복호화 키를 가지지 않기 때문에 내용을 확인할 수 없음

 

 

 

- 클라이언트 측 암호화 기반 E2EE 도입

이번 기능의 핵심은 클라이언트 측 암호화(CSE)를 기반으로 한 종단간 암호화 구조다. 기존 이메일 시스템은 서버에서 암호화와 복호화가 이루어졌기 때문에 서비스 제공자가 데이터에 접근할 가능성이 존재했다. 그러나 이번 방식은 메일이 전송되기 전에 사용자 단말기에서 먼저 암호화가 이루어지고, 암호 해독에 필요한 키 역시 구글 인프라 외부에서 관리된다. 이로 인해 구글 서버에는 암호화된 데이터만 저장되며, 서버가 해킹되더라도 실제 메일 내용은 보호된다. 이는 내부자 위협이나 클라우드 침해 사고까지 고려한 구조로, 기존 보안 방식의 한계를 보완하는 중요한 변화다.

 

클라이언트 측 암호화(CSE) -> 데이터를 어디서 암호화하는지에 대한 구현 방식
1) 사용자의 기기에서 데이터를 암호화한 뒤 서버로 전송하는 방식
2) 서버는 처음부터 암호화된 데이터만 받게 됨
3) 복호화 키를 누가 관리하느냐에 따라 보안 수준이 달라짐

 

 

-기업 중심 보안 통제권 강화

 

이번 종단간 암호화 기능은 특히 기업용 환경을 중심으로 적용되며, 데이터 보호 요구가 높은 조직을 주요 대상으로 한다. 기업 이메일에는 계약 정보, 고객 데이터 등 민감한 정보가 포함되기 때문에 보안 사고 발생 시 피해가 매우 크다. 이에 따라 구글은 암호화 키를 기업이 직접 관리하도록 지원함으로써 데이터 통제권을 사용자 측으로 이동시키고 있다. 또한 모바일 환경에서도 동일한 보안 수준을 제공해 원격근무나 BYOD 환경에서도 안전한 업무 수행이 가능하도록 했다. 이는 단순한 기능 추가가 아니라, 클라우드 보안의 중심을 서비스 제공자에서 사용자로 이동시키는 패러다임 전환으로 볼 수 있다.

BYOD(Bring Your Own Device) : 개인이 소유한 기기를 회사 업무에 사용하는 것

 

 

-개인의견

이번 사례는 클라우드 시대의 보안 전략이 어떻게 변화하고 있는지를 보여준다. 과거에는 서비스 제공자를 신뢰하는 구조가 중심이었다면, 이제는 서비스 제공자도 신뢰하지 않는 Zero Trust 기반 구조로 이동하고 있다. 특히 이메일처럼 핵심 업무 데이터가 오가는 서비스에서조차 플랫폼 사업자가 내용을 볼 수 없도록 설계하는 것은 데이터 주권과 프라이버시 보호가 그만큼 중요해졌다는 의미라고 생각한다. 앞으로 기업들은 단순히 보안 솔루션을 도입하는 수준을 넘어서, 암호화 키 관리, 접근 통제, 사용자 단말 보안까지 포함한 통합 보안 전략을 구축해야 할 필요성이 커질 것이다. 또한 이러한 흐름은 다른 SaaS 서비스로도 확산될 가능성이 높아, 향후 클라우드 보안의 기본 기준 자체가 한 단계 상향될 것으로 예상된다.

 

 

 

* 이전의 지메일 암호화 체계

1. 전송 구간 암호화 (TLS, Transport Layer Security)
: 사용자의 기기에서 구글 서버로 메일이 전송되는 과정, 그리고 구글 서버에서 수신자에게 전달되는 인터넷 통신 과정을 암호화 

-> 도청은 막지만 서버는 데이터를 볼 수 있음

2. 서버측 저장 데이터 암호화 (Data at Rest Encryption)
: 일이 구글의 데이터 센터(서버) 하드디스크에 저장될 때 데이터를 암호화하여 보관

3. 암호화하고 해독하는 '키(Key)'를 구글 서버가 관리
1) 외부 해커로부터는 데이터를 완벽하게 지켰지만, 서비스 제공자인 '구글' 자체는 시스템적으로 메일 내용을 해독하고 읽을 수 있는 상태
2) 구글은 이 키를 가지고 들어오는 메일의 악성코드 및 스팸 검사, 스마트 답장 추천, 메일함 내 빠른 검색, 캘린더 자동 연동등의 기능 구현

4. 전송 시에는 TLS(공개키+대칭키 하이브리드)로 보호하고, 구글 서버 저장 시에는 구글이 관리하는 AES(대칭키)로암호화

 

 

 

* 변화된 지메일 암호화 체계 

 

1. 클라이언트측 암호화 (CSE, Client-Side Encryption)
1) 메일 데이터가 사용자 기기를 떠나기 전(브라우저나 모바일 앱 내에서) 가장 먼저 암호화를 수행
2) 데이터가 인터넷으로 전송되기 전부터 이미 암호화되어 있으므로, 전송 구간은 물론 구글 서버에 도착한 후에도 데이터는 계속 암호화된 상태를 유지

2. 구글 서버 내 암호화된 블록보관
1) 구글의 데이터 센터 하드디스크에는 사용자가 보낸 원래의 메일 내용이 아닌, 해독이 불가능한'암호문이 저장됨
2) 구글 서버가 물리적으로 탈취당하거나 구글 내부자가 접근하더라도, 키가 없기 때문에 실제 내용은 절대 볼 수 없음

3. 암호화하고 해독하는 키(Key)를 사용자(기업)가 직접 관리
1) 암호화 키를 구글이 아닌 사용자(기업 고객) 또는 기업이 선택한 제3의 키 관리 서비스(KMS가 보유
2) 구글은 이 키에 접근할 수 있는 권한이 전혀 없으므로, 시스템적으로 메일 내용을 해독하는 것이 원천적으로 불가능 -> 구글에 대한 '제로 트러스트' 구현
3) 구글 서버가 내용을 읽지 못하게 됨에 따라, 이전 체계에서 누리던 스팸 및 악성코드 검사, 스마트 답장 추천, 메일 본문 검색, 캘린더 자동 연동 등의 기능을 서버 단에서 수행할 수 없게 됨

4. 기기에서 암호화할 때 AES(대칭키)를 쓰고, 그 대칭키를 안전하게 전달하기 위해 사용자(기업)가 직접 관리하는 RSA/ECC 기반의 공개키 암호를 추가로 입혀 구글의 접근을 원천 차단

 

 

 

 

Q1. 구글 대신 제3의 키 관리 서비스(KMS)를 신뢰해야 한다면, 결국 '아무도 믿지 않는다'는 제로 트러스트(Zero Trust)의 본질에 어긋나는 것 아닌가요?
A. 현실의 IT 환경에서 아무도 믿지 않는 것은 불가능에 가깝습니다. 따라서 실무적인 제로 트러스트는 맹목적인 불신이 아니라 신뢰의 분산과 단일 장애점(SPOF) 제거에 초점을 맞춥니다. 과거에는 구글이 데이터 보관, 사용자 인증, 키 관리를 모두 독점하여 구글 하나만 뚫리면 모든 보안이 무너지는 구조였습니다. 하지만 CSE(클라이언트측 암호화) 환경에서는 이 권한들을 철저히 분리합니다.또한, 이메일 서버는 본연의 역할인 데이터 전달 및 보관 권한만 가져야 합니다. 암호화 키를 분리하여 구글로부터 불필요한 메일 읽기 권한을 회수하는 것이야말로 제로 트러스트의 핵심인 최소 권한의 원칙(Least Privilege)에 정확히 부합하는 조치입니다.

 

 

Q2. 시스템을 여러 개로 쪼개어 신뢰를 분산하면, 하나만 뚫려도 전체가 무너지는 공급망 공격에 오히려 더 취약해지는 것 아닌가요?
A. 신뢰의 분산은 하나가 뚫리면 다 뚫리는 직렬구조가 아니라, 두 개의 열쇠가 모두 있어야 열리는 병렬구조를 만듭니다. 이는 해커에게 엄청난 딜레마를 안겨줍니다.

1) 상황 A (구글 서버 해킹 시): 해커가 막대한 양의 메일 데이터를 탈취하더라도, 이는 해독 불가능한 암호문입니다. 복호화 키가 없으므로 데이터는 안전합니다.
2) 상황 B (KMS 공급망 공격 시): 해커가 KMS를 뚫고 암호 해독 키를 얻더라도, 정작 풀어야 할 암호화된 데이터는 구글 서버에 있습니다. 키만으로는 어떤 정보도 얻을 수 없습니다.
3) 상황 C (실제 탈취 성공 조건): 결국 해커가 데이터를 탈취하려면 세계 최고 수준의 보안을 자랑하는 구글 인프라와 기업 내부망(또는 KMS)을 동시에 해킹해야 합니다. 이는 공격 난이도와 비용을 기하급수적으로 높입니다.

 

 

 

Q3. 구글 계정이 없는 외부 수신자가 별도의 가입 없이 암호화된 메일을 읽을 수 있는 기술적 원리는 무엇인가?
A. 1단계 (보안 URL 접속 및 암호문 로드): 사용자가 알림 메일을 통해 보안 URL에 접속하면, 웹 브라우저가 구글 서버로부터 복호화용 웹 애플리케이션(프론트엔드)을 로드합니다. 이와 동시에 서버에 저장된 암호화된 메일 데이터가 사용자 단말로 전송됩니다.

2단계 (신원 인증 - OTP 또는 IdP 연동): 브라우저에 로드된 애플리케이션은 사용자에게 인증을 요구합니다. 1회용 비밀번호(OTP)를 발송하여 검증하거나, 타사 식별자 제공자(IdP)의 API를 호출하여 OIDC/SAML 기반의 인증을 수행합니다.

3단계 (KMS 직접 통신 및 복호화 키 획득): 인증이 완료되면, 사용자의 브라우저는 기업이 구축해둔 키 관리 시스템(KMS)으로 직접 API 요청을 보냅니다. KMS는 브라우저가 제출한 인증 토큰을 검증한 후, 데이터를 복호화하는 데 필요한 복호화 키(Decryption Key)를 브라우저 세션으로 전송합니다.

4단계 (Web Crypto API 기반 브라우저 로컬 단말 복호화): 브라우저는 수신한 암호화된 데이터와 복호화 키를 모두 메모리에 적재합니다. 이후 웹 브라우저에 내장된 Web Crypto API를 호출하여 로컬 단말기의 메모리(RAM) 상에서 복호화 알고리즘(AES-GCM 등)을 연산하고, 암호문을 평문(Plaintext)으로 변환하여 DOM에 렌더링합니다. 세션 종료 시 메모리 상의 복호화 키와 평문 데이터는 즉시 소멸됩니다.

Web Crypto API : 웹 브라우저에 내장된 자바스크립트 기반 암호화 인터페이스로, 웹 애플리케이션이 암호화, 복호화, 해시, 전자서명, 키 생성 및 관리 등의 보안 기능을 클라이언트(브라우저)에서 직접 수행할 수 있도록 제공하는 API

 

 

 

기사 출처 : https://www.boannews.com/media/view.asp?idx=143130&page=1&kind=1