종단간 암호화(E2EE, End-to-End Encryption)란 데이터가 내 기기를 떠나기 전에 암호화되고, 키를 가진 사람(받는 사람)만 풀 수 있으며, 중간에서 저장하고 전달하는 서비스는 풀 수 없는 방식을 말합니다. 「종단」은 보내는 쪽과 받는 쪽, 양 끝을 뜻합니다. 일반적인 「암호화 서비스」도 전송 구간과 디스크의 파일을 보호하지만 키를 서비스가 갖고 있고, 종단간 암호화에서는 서비스가 뒤섞인 데이터만 보게 됩니다.
기술적인 차이처럼 들리지만, 서버가 해킹되거나 내부 직원이 들여다보거나 수사기관의 요청이 왔을 때 누가 파일을 읽을 수 있는지를 가르는 차이입니다. 이 글은 서비스들이 광고하는 세 가지 암호화, 파일 전송에서 종단간 암호화가 작동하는 방식, 메신저와 SNS에서 보이는 「종단간 암호화」의 뜻, 그리고 실제 한계를 설명합니다.
세 가지 암호화 비교: 전송 중, 저장 시, 종단간
| 종류 | 지켜 주는 것 | 키를 가진 쪽 | 서비스가 파일을 읽을 수 있나 |
|---|---|---|---|
| 전송 중(TLS, 브라우저의 자물쇠) | 네트워크를 오가는 동안의 파일 | 브라우저와 서버(세션마다) | 예, 도착한 뒤에는 |
| 저장 시(예: 저장소의 AES-256) | 서비스 디스크에 저장된 파일 | 서비스 | 예 |
| 종단간 | 보내는 사람·받는 사람 기기 밖의 모든 구간 | 키를 가진 사람만 | 아니요 |
전송 중 암호화는 현재 TLS 1.3(RFC 8446)이 표준이며, 네트워크 도청을 막아 줍니다. 저장 시 암호화는 누군가 디스크를 훔쳐 가는 경우를 막습니다. 둘 다 기본이자 꼭 필요한 보호지만, 두 경우 모두 키를 서비스가 관리하므로 서비스는 파일을 복호화할 수 있습니다. 종단간 암호화는 그 위에 서비스가 벗길 수 없는 층을 하나 더 씌웁니다.
파일 전송에서 종단간 암호화가 작동하는 방식
1단계
브라우저에서 키 만들기
E2EE를 켜면 내 브라우저가 무작위 비밀 키를 만듭니다. 입력하거나 외울 필요는 없습니다.
2단계
업로드 전에 암호화
각 파일을 기기에서 그 키로 암호화합니다. GCM 모드의 AES처럼 변조까지 감지하는 최신 암호 방식을 씁니다.
3단계
암호문만 업로드
서비스는 자신이 읽을 수 없는 암호화된 데이터를 저장하고 전달할 뿐입니다.
4단계
키는 링크에 담겨 이동
키는 다운로드 링크의 # 기호 뒤에 붙습니다. URL의 이 부분은 브라우저 안에 머뭅니다.
5단계
받는 사람의 브라우저가 복호화
받는 사람이 전체 링크를 열면 그 브라우저가 암호화된 파일을 내려받아 키로 기기에서 복호화합니다.
# 뒤의 키가 서버로 가지 않는 이유
웹 주소는 # 기호 뒤에 프래그먼트라는 부분을 가질 수 있습니다. HTTP 표준(RFC 9110)은 프래그먼트가 클라이언트 쪽 처리용이며 요청에 담겨 보내지지 않는다고 정합니다. 받는 사람이 링크를 열면 브라우저는 프래그먼트를 뺀 주소로 서버에 페이지를 요청하고, 키는 브라우저 안에서 읽습니다. Mozilla가 운영했던 Firefox Send가 널리 알린 설계이고, Transfr의 종단간 암호화도 같은 방식으로 작동합니다.
페이스북·X(트위터)·카카오톡에서 말하는 종단간 암호화 뜻
SNS나 메신저 설정에서 「종단간 암호화」라는 말을 보면 뜻은 같습니다. 메시지가 보내는 기기에서 암호화되고 받는 기기에서만 풀리며, 중간의 회사 서버는 내용을 읽을 수 없다는 뜻입니다. 다만 어디까지 적용되는지는 서비스마다 다릅니다(2026년 10월 기준, 각 사 공식 안내).
- 페이스북·메신저: Meta는 2023년 12월 메신저와 페이스북의 개인 메시지와 통화에 기본 종단간 암호화를 적용하기 시작했다고 발표했습니다. 6자리 PIN 등으로 보호되는 보안 저장소를 설정하지 않으면 기기를 잃을 때 메시지도 잃을 수 있다고 안내합니다.
- X(트위터): X의 개발자 문서는 메시지 기능 Chat의 본문이 기기에서 암호화되고, X는 암호문을 전달할 뿐 평문을 읽을 수 없다고 설명합니다. 키 백업은 선택 사항이며 PIN으로 보호되므로, PIN을 가장 중요한 비밀처럼 관리해야 합니다.
- 카카오톡: 카카오 고객센터는 비밀채팅을 「종단간 암호화 기술을 적용하여 이용자 정보 보호를 강화한 기능」으로 안내합니다. 암호화된 대화는 개인 휴대 기기에만 저장되어 PC 버전 등 다른 기기에서는 볼 수 없고, 비밀채팅에서는 사진과 동영상만 보낼 수 있습니다.
- 왓츠앱: 메시지, 사진, 동영상, 파일, 음성 메시지, 그룹 대화가 기본으로 종단간 암호화됩니다.
- 텔레그램: 종단간 암호화는 비밀 대화(secret chat)에만 적용되고, 일반 클라우드 대화는 서버와 기기 사이 암호화입니다.
메신저의 종단간 암호화는 대화와 첨부를 지켜 주지만, 수십 GB짜리 영상이나 폴더를 보내는 용도는 아닙니다. 카카오톡 PC 버전은 파일당 300MB까지 보낼 수 있다고 안내합니다. 큰 파일에 같은 원리를 적용하려면 브라우저에서 암호화하는 파일 전송 서비스를 쓰면 됩니다.
종단간 암호화가 지켜 주는 것
- 서비스 서버 해킹: 도난당한 파일도 키 없이는 읽을 수 없습니다.
- 내부자 접근: 서비스 직원도 파일을 열 수 없습니다.
- 서비스에 대한 제출 요구: 서비스는 갖고 있지 않은 읽을 수 있는 내용을 넘겨줄 수 없습니다.
- 저장소 설정 실수: 저장소가 실수로 노출되더라도 내용은 암호문입니다.
규정 측면의 이점도 있습니다. 유럽 GDPR은 데이터가 「암호화처럼」 권한 없는 사람이 알아볼 수 없게 처리되었다면 침해 시 정보주체에게 통지하지 않아도 된다고 규정하며(제34조 제3항 (a)), 유럽정보보호이사회는 키가 유출되지 않은 제대로 된 암호화에만 해당한다고 덧붙입니다. 한국 개인정보 보호법에서 파일 전송과 관련된 의무는 「개인정보 파일 전송」에서 정리했습니다.
종단간 암호화로도 지킬 수 없는 것
- 유출된 링크: 전체 링크를 가진 사람은 키도 가진 것입니다.
- 감염된 기기: 보내는 사람이나 받는 사람 컴퓨터의 악성코드나 악성 브라우저 확장 프로그램은 암호화 전이나 복호화 후의 파일을 볼 수 있습니다. RFC 9110도 프래그먼트가 페이지의 스크립트에는 보인다고 적고 있습니다.
- 메타데이터: 서비스에 따라 파일 이름, 크기, 날짜, 메일 주소가 서비스에 보일 수 있습니다.
- 받은 뒤의 일: 복호화해서 저장한 파일은 평범한 파일입니다.
실제로 감수해야 하는 점
서비스가 파일을 읽을 수 없으니 파일로 할 수 있는 일도 줄어듭니다. 예를 들어 Transfr에서 종단간 암호화를 켜면 다음과 같습니다.
- 파일은 브라우저에서 AES-128-GCM으로 암호화되고, 키는 링크의 프래그먼트에 들어갑니다. 저장 시 암호화(AES-256)는 그 아래에서 그대로 적용됩니다.
- 미리보기는 복호화한 뒤 받는 사람의 브라우저에서 만들어지며, 링크에 키가 있을 때 2GB 이하 파일만 가능합니다. 더 큰 파일은 내려받아야 합니다.
- 폴더 구조는 유지되지 않고, 페이지를 새로 고친 뒤 중단된 업로드를 이어 올릴 수 없으며, Drime에서 가져온 파일은 Transfr가 대신 복사하므로 종단간 암호화할 수 없습니다.
- 키는 Transfr 서버에 저장되지 않습니다. 다만 Transfr가 링크를 메일로 보낼 때(받는 사람에게 보내는 메일, 로그인한 보낸 사람이 받는 확인 메일)는 메일에 넣기 위해 브라우저가 키를 포함한 전체 링크를 넘겨주며, 그 메일에만 쓰인 뒤 메일은 메일함에 남습니다. 가장 엄격하게 하려면 링크를 직접 복사해 믿을 수 있는 경로로 공유하세요.
이것들은 결함이 아니라 내용을 볼 수 없는 서비스의 당연한 결과입니다. 일상적인 전송이라면 비밀번호와 만료 기간으로 충분할 때가 많고, 기밀 자료라면 이 정도는 감수할 가치가 있습니다.
다음 전송을 종단간 암호화하세요
Transfr에서 무료이고, 원하면 비밀번호와 만료 기간도 함께. 1회 100GB까지.
종단간 암호화와 비밀번호는 무엇이 다른가요?
해결하는 문제가 다르고, 함께 쓰면 좋습니다. 비밀번호는 누가 다운로드 페이지를 열 수 있는지를 정합니다. 확인은 서비스가 하므로 서비스는 여전히 파일에 접근할 수 있습니다. 종단간 암호화는 서비스를 포함해 누가 내용을 읽을 수 있는지를 정합니다. 둘을 함께 쓰면 링크가 새어도 그것만으로는 부족하고, 서비스는 내용을 보지 못합니다. 비밀번호와 만료 기간을 고르는 법은 「링크 비밀번호 설정과 만료 기간」에서 설명합니다.
어떤 파일에 종단간 암호화를 써야 할까요?
| 상황 | E2EE 권장 여부 |
|---|---|
| 가족과 나누는 여행 사진 | 선택 |
| 고객 납품물(디자인, 영상) | 공개 전 작업물이라면 유용 |
| 계약서, 급여명세서, 신분증 사본 | 예 |
| 진료·법률·금융 기록 | 예, 비밀번호와 짧은 만료 기간과 함께 |
| 소스 코드, 제품 기획, 인수합병 자료 | 예 |
브라우저에서 업로드 전에 파일을 암호화하는 서비스로는 Proton Drive, Tresorit Send, Wormhole 등이 있고, 일반적인 클라우드 저장소는 보통 서비스가 관리하는 키로 전송 중·저장 시 암호화를 합니다. 「대용량 파일 전송 무료 사이트」에서 어떤 곳이 종단간 암호화를 무료로 제공하는지 비교했고, 「법률 사무소를 위한 안전한 파일 전송」에서는 전문직이 비밀번호, 짧은 만료 기간과 어떻게 조합하는지 소개합니다.
정말 종단간 암호화인지 확인하는 법
- 암호화가 「안전한 서버에서」가 아니라 업로드 전에 브라우저나 앱에서 이루어져야 합니다.
- 서비스가 키를 저장하지 않는다고 밝혀야 합니다. 키가 링크 프래그먼트에 있거나 나만 아는 비밀에서 만들어지는지, 서비스가 대신 링크를 메일로 보낼 때 어떻게 되는지 확인하세요.
- 키 없이도 암호화된 파일의 미리보기나 검사 결과를 서버에서 보여 준다면 종단간 암호화가 아닙니다.
- 「은행 수준 보안」 같은 문구가 아니라 암호 방식과 설계를 설명하는지 보세요.
비밀번호부터 받는 사람 관리까지 더 넓은 습관은 「파일 안전하게 보내기」 체크리스트와 「안전한 파일 전송」 페이지에서 볼 수 있습니다.