인터넷으로 파일을 보내도 안전할까요?

마지막 업데이트: 2026-08-06

"이 파일을 보내도 안전할까?"는 잠시 멈춰 생각해볼 만한 합리적인 질문입니다. 세금 신고서든, 계약서든, 그냥 남에게 보이고 싶지 않은 사진이든 말이죠. 이 글은 흔히 쓰는 도구들을 겁주려는 것이 아닙니다. 이메일로 파일을 보낼 때, 클라우드 폴더에 넣을 때, USB 드라이브에 담아 다닐 때 실제로 무슨 일이 일어나는지, "종단간 암호화"와 "영지식"이라는 말이 실제로 무엇을 약속하는지, 그리고 소중한 것을 어떤 도구에 맡기기 전에 무엇을 확인해야 하는지를 담담하게 짚어보려는 것입니다.

기술적인 배경지식은 전혀 필요하지 않습니다. 다 읽고 나면, 어떤 전송 방식에든——이 글에서 소개하는 방식을 포함해서——어떤 질문을 던져야 할지 알게 될 것입니다.

파일이 실제로 새는 지점: 일상적인 위험들

이메일 첨부파일은 발신자와 수신자 각각의 메일 서버를 거치는데, 두 서버 모두 스팸 필터링과 재해 복구를 위해 메시지를 일상적으로 스캔하고 색인하고 백업합니다——그 파일을 보냈다는 사실조차 잊어버린 훨씬 뒤에도요. 이메일이 한 번이라도 전달되면, 파일은 의도하지 않은 사람 앞에 놓이게 되고, 모든 사본이 사라졌는지 확인할 방법은 없습니다.

클라우드 저장소 링크는 편리하지만, 보통 취소해야겠다고 떠올리기 전까지는 계속 작동합니다. "링크를 가진 누구나"라는 말의 프라이버시 수준은 그 URL을 추측하기 얼마나 어려운가에 달려 있으며, 단축 링크나 부주의한 전달 한 번으로 그 조건이 깨질 수 있습니다. 파일은 그 공유 자체뿐 아니라 그것이 속한 계정 전체의 보안 수준도 물려받습니다.

USB 드라이브는 오프라인이라 안전하게 느껴지지만, 바로 그 지점이 함정입니다. 대부분의 드라이브는 기본적으로 암호화되어 있지 않아서, 노트북 가방이나 렌터카에 두고 내리면 발견한 사람이 비밀번호 없이 평문 그대로를 손에 넣게 됩니다.

무료 공개 업로드 사이트는 당장 눈앞의 문제——파일을 A에서 B로 옮기는 것——는 해결해주지만, 그다음에 무슨 일이 일어나는지는 거의 설명하지 않습니다. 얼마나 보관되는지, 스캔되는지, 누군가 우연히 발견할 수 있는지, 그 사이트가 어떻게 운영비를 충당하는지(광고로 운영되는 파일 호스팅 사이트들은 트래커나 그보다 더한 것을 끼워 넣어온 전례가 있습니다).

• 이메일: 메일 서버에 보관·스캔되며, 통제할 수 없는 범위로 쉽게 전달됨
• 클라우드 링크: 취소하기 전까지 계속 작동하며, 계정 전체의 보안 수준을 물려받음
• USB 드라이브: 기본적으로 암호화되어 있지 않고 분실하거나 두고 오기 쉬움
• 무료 업로드 사이트: 보관 및 스캔 방침이 대체로 불투명함

"종단간 암호화"와 "영지식"이 실제로 의미하는 것

많은 서비스가 "암호화됨"이라고 말하지만, 실제로는 서버로의 연결만 암호화되어 있다는 뜻일 때가 많습니다——은행 사이트에서 보는 것과 같은 자물쇠 아이콘, 즉 표준 HTTPS/TLS입니다. 이는 네트워크 상의 도청을 막는 실질적인 보호이지만, 서버에서 멈춥니다. 파일이 도착하는 순간, 서비스 자체는 그것을 읽을 수 있습니다. 키를 가지고 있으니까요. 많은 일상적인 도구들이 정확히 이 지점에서 멈춥니다.

종단간 암호화는 더 강한 것을 의미합니다. 파일은 기기를 떠나기 전에 암호화되고, 그 키는 오직 발신자와 의도된 수신자만 갖습니다. 그것을 나르는 서비스——서버, 릴레이, 그 사이의 무엇이든——는 그 키를 한 번도 갖지 않으므로, 어떻게 요구받든 평문을 가질 수 없습니다.

"영지식"은 관련된 개념으로, 보통 실시간으로 보내는 것이 아니라 저장되는 것에 적용됩니다. 서버에 조용히 놓여 있는 데이터조차, 그것을 암호화하는 데 쓰인 키는 서버 자신에게 한 번도 주어지지 않았습니다. 그래서 운영자는 데이터가 얼마나 오래 놓여 있든 그것을 읽을 방법이 전혀 없습니다.

• 그냥 "암호화됨"이라는 말은 흔히 서버까지의 TLS만을 뜻하며, 제공업체는 여전히 파일을 읽을 수 있습니다.
• "종단간 암호화"는 발신자와 수신자만이 키를 가진다는 뜻입니다.
• "영지식"은 서버가 보관 중에도 구조적으로 복호화할 수 없는 데이터만 갖고 있다는 뜻입니다.

전송 도구를 신뢰하기 전에 실제로 확인해야 할 것

웹사이트의 마케팅 문구보다 몇 가지 구체적인 질문이 훨씬 더 값어치가 있습니다.

1. "내 파일을 읽을 수 있느냐"에 대한 공급자 자신의 답을 요금 페이지가 아니라 소스에서 찾으세요. 소스가 없다면 그것 자체가 이미 답입니다.

   https://github.com/relayium/relayium

2. 라이선스를 확인하고, 그 저장소가 실제로 배포된 것과 대응하는지 보세요. 직접 살펴볼 수 있는 주장과 받아들이라고 요구되는 주장은 종류가 다릅니다.

3. 실시간 전송에서 두 화면의 검증 코드를 대조하세요. 「종단간 암호화」를 한 문장에서, 바로 이 두 종단 사이에 실제로 적용되고 있는 것으로 바꾸는 단계가 이것입니다.

   https://relayium.com/

4. 그 전송이 도는 동안 브라우저 개발자 도구를 열고 네트워크 패널을 보세요. 올라가는 내용에서 자기 파일의 내용을 찾아보세요. 찾지 못하는 것이 핵심이고, 찾는다면 그것이 결론입니다.

5. 끝난 뒤에 무엇이 남는지 확인하세요. 링크가 스스로 만료되는지, 그리고 나중에 누군가 요구하면 서비스가 그 파일을 다시 내놓을 수 있는지.

• "암호화됨"이라고만 말하는지(단순 TLS일 수 있음), 아니면 명확히 "종단간 암호화"라고 말하는지(발신자와 수신자만 키를 가짐)?
• 연결이 변조되지 않았는지 확인할 방법이 있는지——그냥 믿어야 하는 자물쇠 아이콘이 아니라, 직접 대조할 수 있는 코드가 있는지?
• 파일의 무결성이 검증되어, 손상되거나 변조된 파일이 아무 문제 없어 보이게 조용히 도착하지 않는지?
• 코드가 오픈 소스이고 감사 가능한지, 아니면 그 주장들이 그냥 믿을 수밖에 없는 마케팅 문구인지?
• 보내거나 받을 때, 그 전송에 실제로 필요한 것보다 더 많은 신원 정보를 요구받지는 않는지?
• 무언가가 저장된다면, 그것이 명확하고 한정된 수명——만료 기한이나 다운로드 후 삭제——을 가지는지, 아니면 무기한 그대로 남아 있는지?

Relayium이 이 각각에 답하는 방식

양쪽이 동시에 온라인 상태인 실시간 전송에서, Relayium은 각 기기에서 새로운 X25519 키 쌍을 만들고, 두 브라우저 내부에만 존재하는 공유 AES-256-GCM 키를 도출합니다——이 키는 Relayium 자체 서버로 전송되는 일이 없습니다. 선택적인 짧은 검증 코드(SAS)——기본값이 꺼짐인 고급 검증을 켜면 표시됩니다——를 통해 양쪽 모두 중간의 부정직한 서버가 키를 바꿔치기하지 않았음을 확인할 수 있고, 각 파일의 SHA-256 해시가 종단간으로 대조되므로 손상된 전송이 문제없어 보이게 도착하는 일이 없습니다. 이 원리가 정확히 어떻게 작동하는지 더 깊이 알고 싶다면 "Relayium이 파일을 종단간 암호화하는 방식"에서 더 자세히 다룹니다.

수신자가 아직 온라인이 아닐 때, 저장형 다운로드 링크는 진짜로 다른 영지식 방식을 사용합니다. 브라우저는 무작위 AES-256-GCM 키를 생성하고, 무언가 업로드되기 전에 그것으로 파일을 암호화합니다. 이 키는 서버로 전혀 전송되지 않습니다——링크의 URL 프래그먼트, 즉 # 뒤의 부분에만 존재하며, 브라우저는 이 부분을 절대 전송하지 않습니다. 결국 서버가 갖게 되는 것은 복호화할 방법이 없는 암호문과, 직접 선택한 만료 기한(1시간, 1일, 3일, 7일, 요금제에 따라 최대 14일, 또는 첫 다운로드 완료 후 삭제)뿐입니다.

네트워크를 넘을 때 Relayium 브라우저 앱은 설계상 TURN을 사용합니다. 릴레이는 종단간 암호문을 운반하지만 키를 받지 않으므로 파일을 읽거나 복호화할 수 없습니다.

이 중 어느 것도 주장을 그냥 믿으라고 요구하지 않습니다. Relayium의 클라이언트와 서버 코드는 AGPL-3.0 라이선스로 공개되어 있어, 홍보 문구를 믿는 대신 누구나 읽고 감사할 수 있습니다.

• 같은 네트워크 내의 전송은 계정이 전혀 필요 없습니다.
• 페어링 코드로 네트워크를 넘어 보내거나 저장 링크를 만들 때는 발신자의 로그인이 필요합니다——수신자는 어떤 경우든 계정이 전혀 필요 없습니다.

암호화가 전부는 아닙니다 — 여전히 중요한 몇 가지 습관

강력한 암호화는 전송 중과 저장 중인 파일을 보호하지만, 링크를 잘못된 주소로 보내는 것까지 막아주지는 못합니다. 공유 링크를 파일 그 자체처럼 다루고, 어딘가 공개된 곳에 게시하지 마세요.

정말로 민감한 내용에 대해서는 고급 검증을 켠 다음, 몇 초를 더 들여 통화로 검증 코드를 소리 내어 읽어 대조하거나 직접 만나서 확인하세요. 나란히 놓인 두 화면이 둘 다 속지 않았을 것이라고 그냥 믿는 것만으로는 부족합니다.

그리고 아무리 암호화가 잘 되어 있어도, 이미 손상된 기기에서 노출된 파일을 어떤 전송 도구도 보호해줄 수는 없습니다. 좋은 암호화는 양쪽 끝 자체가 신뢰할 수 있다는 것을 전제로 합니다. 이것이 파일을 보내는 일 자체에 대해 지나치게 예민해질 이유는 아닙니다. 다만 암호화가 어디까지 커버하고 어디부터는 커버하지 않는지 알아둘 가치가 있다는 것입니다.

확인이 깔끔한 답을 주지 않을 때

막히는 지점은 세 군데입니다. 어느 경우든 그 모호함 자체가 정보를 담고 있습니다.

자주 묻는 질문

민감한 파일을 이메일로 보내도 안전한가요?

이메일은 기밀 파일 전송을 위해 설계된 것이 아닙니다. 첨부파일은 양쪽 메일 서버에 일상적으로 보관·스캔·백업되며, 전달된 메시지는 의도하지 않은 사람 앞에 놓일 수 있습니다. 중요하지 않은 파일이라면 괜찮지만, 민감한 내용이라면 종단간 암호화를 갖춘 도구가 이런 노출을 없애줍니다.

"영지식"이 실제로 무엇을 의미하나요?

내 데이터를 저장하는 쪽이 그것을 읽을 수 있는 키를 한 번도 받은 적이 없다는 뜻입니다. 암호화는 업로드되기 전에 내 기기에서 이루어지며, 키는 서버가 절대 보지 못하는 곳——예를 들어 URL 프래그먼트——에만 존재합니다. 그래서 서버에 있는 것은 구조적으로 복호화할 수 없는 암호문일 뿐, 단순히 '보지 않겠다고 약속한' 데이터가 아닙니다.

비밀번호로 보호된 압축 파일이면 충분한가요?

아예 안 하는 것보다는 낫지만, 그 비밀번호가 흔히 파일과 같은 경로로——예를 들어 같은 이메일 스레드로——전달되어 보호 효과가 사라지는 경우가 많고, 압축 파일의 암호화 구현 강도도 제품마다 크게 다릅니다. 종단간 암호화를 기반으로 한 도구는 애초에 공유 비밀번호가 필요 없어서 이런 약점 자체를 없애줍니다.

Relayium이 제 파일 사본을 보관하나요?

실시간 모드에서 Relayium은 서버 측 복사본이나 전송 기록을 보관하지 않습니다. 같은 LAN에서는 WebRTC로 직접 연결하고, 네트워크를 넘는 브라우저 세션은 설계상 TURN으로 릴레이가 읽거나 복호화할 수 없는 종단간 암호문을 운반합니다. 저장 링크의 경우, 서버는 읽을 수 없는 암호문만 가지고 있으며, 링크가 만료되거나 '열람 후 삭제'를 선택했다면 한 번 다운로드된 후까지만 보관합니다.

파일을 보내거나 받으려면 계정이 필요한가요?

같은 네트워크 안에서는 양쪽 다 계정이 필요 없습니다. 페어링 코드로 네트워크를 넘어 보내거나 저장 링크를 만들 때는 발신자의 로그인이 필요하지만, 어느 방식이든 수신자는 계정이 전혀 필요 없습니다.

계속 읽기

• Relayium이 파일을 종단간 암호화하는 방식
• 만료되는 안전한 다운로드 링크로 파일 공유하기
• P2P(피어투피어) 파일 전송이란?
• 클라우드 없이 대용량 파일 보내는 방법
• Relayium