2026-09-05

파일은 암호화했습니다. 그 암호는 어떻게 보내야 할까요?

민감한 파일을 보내는 방법을 설명하는 글은 하나같이 같은 자리에서 멈춥니다. "먼저 암호화하세요." 그리고 문장이 끝납니다. 정작 나머지 절반 — 그 암호를 받아야 할 한 사람에게만 전달하고, 같은 메일함을 들여다볼 수 있는 나머지 모두에게는 주지 않는 일 — 은 독자의 숙제로 남습니다. 대부분은 그 숙제를 "두 번째 메일에 비밀번호를 적어 보내기"로 풉니다. 이 글은 바로 그 방식이 지난 5년간 한 나라의 정부·인증기관·통신사·은행에 의해 차례로 폐기돼 온 이야기이고, 그 폐기를 주도한 사람들이 대신 무엇을 하라고 말했는지에 관한 이야기입니다.

이름이 붙어 버린 관행

이 습관에 이름을 붙이고, 문제를 따지고, 없애기 시작한 나라는 일본입니다. 이름은 PPAP — 2016년 유행가 제목을 비튼 농담 섞인 약칭으로, "비밀번호 걸린 ZIP을 보내고, 그다음 비밀번호를 보낸다"는 뜻입니다. 오랫동안 일본 업무 이메일의 기본 예절이었고, 지금도 큰 조직부터 하나씩 풀어내는 중입니다. 2026년 6월 8일 ITmedia 보도에 따르면 미쓰비시UFJ은행은 이 관행을 원칙적으로 폐지하고 2026년 7월 18일부터 단계적으로, 메일 본문에 전용 다운로드 사이트 URL을 적고 비밀번호는 따로 전달하는 방식으로 바꿉니다. 은행이 밝힌 이유가 흥미로운데, 뒤에서 다시 다룹니다. 파일이 암호화돼 있어서 메일을 받는 시점에 악성코드 검사가 어렵다는 것입니다.

이 이야기를 처음 접하면 "그러니까 파일 암호화는 하지 말라는 거네"로 읽히기 쉽습니다. 정반대입니다. 당사자들이 실제로 뭐라고 했는지 보면 됩니다.

일본 정부가 없앤 것과, 없애지 않은 것

분기점은 평범한 장관 정례 기자회견이었습니다. 2020년 11월 24일 내각부 공식 회견 요지에서 당시 디지털개혁담당 히라이 다쿠야 장관은 내각부와 내각관방이 이틀 뒤부터, 암호화 ZIP과 같은 경로로 비밀번호를 자동 발송하는 방식을 폐지한다고 확인합니다. 그 방식에 대한 평가는 이렇습니다. 「セキュリティ対策の観点からも、受け取る側の利便性の観点からも、 適切なものではない」 — 보안 대책의 관점에서도, 받는 쪽의 편의라는 관점에서도 적절하지 않다.

그리고 이 이야기의 요약본들이 거의 항상 빠뜨리는 문장이 이어집니다. 그럼 어떻게 해야 하느냐는 질문에 장관은, 파일에 비밀번호를 걸되 「とともに、全く別の経路でパスワードを知らせる」 — 그와 함께, 완전히 다른 경로로 비밀번호를 알린다 — 라고 답하며 구체적인 예로 「電話で教える」, 전화로 알려 주는 것을 듭니다. 당시 ITmedia 보도에 따르면 외부 파일 송신은 스토리지 서비스로 옮기고 비밀번호는 별도로 처리하기로 했습니다.

파일을 보호하지 말라는 이야기가 아닙니다. 보호는 애초에 문제가 아니었고, 문제는 두 번째 메일이었다는 이야기입니다. 며칠 앞서 다른 방향에서도 같은 지적이 나왔습니다. 2020년 11월 19일, 일본의 프라이버시마크 인증을 운영하는 JIPDEC은 — 많은 기업이 바로 그 인증 때문에 PPAP를 해야 한다고 믿고 있었는데 — 개인정보가 담긴 파일을 비밀번호로 암호화해 메일에 첨부하고 비밀번호를 다른 메일로 보내는 방식은 「以前から推奨していない」, 예전부터 권장한 적이 없다고 분명히 밝혔습니다.

두 번째 메일은 두 번째 경로가 아니다

판별 기준은 하나고, 짧습니다. 한 번의 침해로 양쪽이 동시에 드러나는가? 그렇다면 경로를 두 개 쓴 게 아니라 한 경로를 두 번 쓴 것입니다.

정직하게 대입해 보면 두 번째 메일은 거의 모든 방향에서 이 기준을 통과하지 못합니다. 누군가 수신자의 메일함에 접근할 수 있다면 — 업무용 이메일 침해(BEC)의 전제 그대로입니다 — 두 메일은 몇 줄 간격으로 나란히 놓여 있습니다. 자동완성이 엉뚱한 김 과장을 골라 잘못 발송된 경우라면, 30초 뒤 비밀번호를 보낼 때도 자동완성은 똑같은 실수를 반복하고, 둘 다 같은 낯선 사람의 받은편지함에 도착합니다. 나중에 그 스레드가 더 넓은 그룹으로 전달되거나, 담당자가 퇴사해 메일함이 후임에게 넘어가거나, 메일함이 어딘가에 백업된다면, 두 메일은 한 세트로 함께 움직입니다. 암호는 파일이 지나가지 않는 곳에 있을 때만 일을 합니다.

공격자들이 먼저 알아차렸다

불편한 대목이자, 큰 조직들이 이 첨부파일을 "권장하지 않는다"를 넘어 아예 삭제하기 시작한 이유입니다. 범죄자들이 똑같은 절차를 그대로 가져다 썼습니다. 그들에게는 잘 작동했기 때문입니다.

트렌드마이크로가 2019년 4월 6일 기록한 스팸 캠페인에서는 청구서를 가장한 메일이 비밀번호 걸린 ZIP을 달고 왔고, 네 자리 비밀번호는 메일 본문에 적혀 있었습니다. 압축 안에는 EMOTET을 내려받는 트로이목마 다운로더가 들어 있었습니다. 본문에 비밀번호를 적은 건 허술해서가 아니라 그것이 설계의 핵심이기 때문입니다. 메일 게이트웨이는 열 수 없는 것을 검사할 수 없으므로 암호화된 압축파일은 검사를 그대로 통과하고, 열쇠는 친절하게도 사람이 직접 넣어 줍니다.

IIJ가 공지한 판단도 정확히 같은 논리였습니다. 2022년 1월 26일부터 IIJ로 오는 비밀번호 걸린 .zip 첨부는 삭제되고 본문만 전달됩니다. 회사는 미국 사이버보안·인프라보안국(CISA)이 이런 첨부파일을 차단하도록 권고해 왔다는 점 — 바이러스 검사를 빠져나가는 경우가 많기 때문에 — 과, 이 방식이 악성코드 유포에 악용될 수 있다는 점을 이유로 들었습니다. 2026년 미쓰비시UFJ의 설명은 같은 문장을 다른 옷으로 입힌 것입니다.

파일을 암호화해 보내는 사람에게 이 사실이 주는 결론은 "그러니 하지 마라"가 아닙니다. 첨부파일을 암호화하는 순간 받는 사람에게 비용이 넘어간다는 것입니다. 그 파일에 한해 상대의 검사 장치를 꺼 버린 셈이니까요. 미리 약속하고 주고받는 두 사람 사이라면 괜찮습니다. 어렴풋이 아는 주소에서 예고 없이 날아온 경우라면 괜찮지 않고, 암호화 품질과 무관하게 요즘 암호화 첨부파일이 링크보다 나쁜 전달 수단이 되어 가는 이유이기도 합니다.

전화로 불러 줘야 하는 암호 고르기

현재 기준선은 2025년 8월 26일 발행된 NIST 특별간행물 800-63B-4이고, 그 내용은 대부분의 예상보다 단호합니다. 단일 인증수단으로 쓰이는 비밀번호는 "최소 15자 이상이어야 한다(SHALL)". 서로 다른 문자 종류를 섞으라는 식의 "다른 구성 규칙을 부과해서는 안 된다(SHALL NOT)". 출력 가능한 모든 ASCII 문자와 공백 문자를 받아들여야 하고(SHOULD), 최소 64자까지는 허용해야 합니다(SHOULD). 그리고 흔하거나 이미 유출된 비밀번호 목록과 대조해야 합니다.

지금 상황에 맞게 옮기면, 길이가 특수문자를 이깁니다. 서로 상관없는 단어 여러 개를 공백으로 이어 붙인 쪽이 달러 기호 하나 끼워 넣은 짧은 문자열보다 오래 버티고, 전화로 한 글자씩 불러 주지 않아도 된다는 실용적 장점까지 있습니다. 표준이 아니라 상황에서 나오는 규칙 두 가지를 덧붙입니다. 암호를 파일이나 거래에서 유추할 수 있게 만들지 마세요 — "세금계산서-김-2026!" 같은 형태는 그 메일을 가로챈 사람이 가장 먼저 떠올릴 문자열입니다. 그리고 1년 내내 같은 사람에게 보내는 모든 파일에 같은 암호를 재사용하지 마세요. 한 번 새면 그동안 보낸 것 전부가 열립니다.

암호화 첨부파일은 아예 도착하지 않을 수도 있다

사람들이 가장 많이 놀라는 실패입니다. 상대방 메일 시스템이 그냥 거부할 수 있습니다. IIJ는 비밀번호 걸린 ZIP 첨부를 삭제하고, 미쓰비시UFJ는 링크로 옮겨 가고 있습니다. 흐름은 수치로도 보입니다. 2024년 12월 실시된 디지털아츠 조사(IT Leaders 2025년 1월 30일 보도)에 따르면 ZIP 첨부가 붙은 메일 비율은 5년 사이 25%에서 12%로 반토막 났고, 남은 ZIP 중 56%가 비밀번호로 보호돼 있었습니다. 다만 습관은 천천히 사라집니다. JIPDEC의 기업 IT 이용동향조사 2024에서는 2024년 1월 기준으로 응답 기업의 27.1%가 여전히 PPAP만을 파일 전송 수단으로 쓰고 있었는데, 이 수치는 ASCII.jp가 인용한 것으로, 금융청이 2025년 5월 업계 단체 의견교환회에서 금융기관에 이 관행을 그만두라고 요구했다는 보도와 함께 소개됐습니다. (금융청 문서 자체를 직접 확인하지는 못했으므로, 의견교환회 부분은 규정 인용이 아니라 보도로 받아들이시기 바랍니다.)

실무적으로는 결론이 단순합니다. 보내기 전에 물어보세요. 상대 게이트웨이가 암호화 첨부를 걷어낸다면, 통하는 방식은 미쓰비시UFJ가 택한 그 방식입니다. 암호화된 파일은 상대가 가져갈 수 있는 곳에 두고, 암호는 진짜로 다른 경로로 보내는 것. 암호화가 되어 있기 때문에 파일을 어디에 두는지가 덜 중요해집니다.

그대로 따라 할 수 있는 다섯 단계

하나, 경로부터 한 문장으로 합의합니다. "암호화한 파일은 메일로 보내고, 암호는 전화로 알려 드릴게요." 보내기 전에 이 말을 해 두면 첨부가 온다는 예고도 되는데, 그 예고가 위의 EMOTET 캠페인처럼 보이지 않게 해 주는 최소한의 예의입니다. 둘, 파일을 암호화하고, 암호는 만든 그 순간 비밀번호 관리자에 적습니다 — 나중에 기억나겠지 싶을 때가 아니라 그 순간에. 셋, 파일을 보냅니다. 넷, 암호는 다른 경로로 전달하고, "찾기 쉽게" 스레드에 붙여 넣지 않습니다. 다섯, 상대가 열었다고 확인해 줄 때까지 원본 평문 사본을 갖고 있다가 그 뒤에 정리합니다. 마지막 단계는 과민함이 아니라, 존재하는 유일한 복구 수단입니다. 이유는 다음 절에 있습니다.

이 모든 게 해결해 주지 않는 것

다섯 가지 한계를 그대로 적습니다. 첫째, 암호화는 전송 중과 보관 중의 파일을 지킬 뿐, 상대가 연 뒤에 무엇을 하는지에는 아무 영향이 없습니다. 동기화되는 바탕화면에 풀어 놓고 평문 그대로 다른 곳에 전달하면 공들인 경로 분리는 거기서 끝납니다. 둘째, 상대의 메일함을 안전하게 만들어 주지 않고, 상대가 누구인지 확인해 주지도 않습니다. 답장하고 있는 주소가 위조됐거나 스레드가 탈취된 상태라면, 파일은 완벽하게 암호화한 채 서명란에 적힌 전화번호로 공격자에게 암호를 불러 주게 됩니다. 경로는 메일에 적힌 연락처가 아니라 원래 갖고 있던 연락처로 확인하세요. 셋째, 그 파일에 한해 상대의 악성코드 검사를 무력화합니다. 상대가 실제로 치르는 비용이고, 예고 없는 암호화 첨부가 보안상으로도 예의상으로도 좋지 않은 이유입니다. 넷째, 메타데이터는 여전히 남습니다. 파일명, 크기, 제목, 그리고 오늘 두 사람이 무언가를 주고받았다는 사실은 내용과 무관하게 보입니다. 다섯째, 그리고 가장 중요하게, 복구 수단이 전혀 없습니다. 암호로 암호화한 파일에는 재설정 링크도, 고객센터도, 보낸 사람이나 저희를 위한 뒷문도 없습니다. 받는 사람이 암호를 잃어버리면 그 파일은 누구도 열 수 없습니다. 확인을 받을 때까지 원본을 갖고 있으라는 이유가 그것이고, 암호가 누군가의 기억이 아니라 양쪽 비밀번호 관리자에 들어 있어야 하는 이유도 그것입니다.

NearSeal이 놓인 자리

NearSeal은 이 일의 앞쪽 절반을 하고, 뒤쪽 절반은 의도적으로 하지 못합니다. 암호화는 전부 브라우저 안에서 돌아갑니다. 파일도 암호도 기기를 떠나지 않고, 계정도 업로드도 없으며, 네트워크 탭을 열어 아무것도 전송되지 않는다는 것을 직접 확인할 수 있습니다. "상대에게 보내기" 버튼도, 링크 생성도, 암호 전달 기능도 없습니다. 빠진 기능이라서가 아니라, 파일을 쥔 서비스가 암호 경로까지 운영하면 두 경로가 다시 하나로 합쳐지기 때문입니다. 이 글이 처음부터 끝까지 이야기한 그 실수입니다. 기본 형식은 AES-256-GCM이고 키는 PBKDF2-SHA256을 2²⁰회 반복해 암호에서 유도하며, 컨테이너 헤더가 인증 태그에 묶여 있어 변조된 파일은 복호화 시점에 조용히 다른 내용을 건네는 대신 요란하게 실패합니다. 받는 사람이 어떤 웹사이트에도 의존하고 싶지 않다면 옵트인 age-encryption.org 형식이 있습니다. age 파일은 scrypt와 ChaCha20-Poly1305를 쓰며 공식 age CLI와 rage를 비롯한 모든 age 호환 도구에서 열리므로, 상대는 이 사이트에 들어올 필요조차 없습니다. 복호화할 때는 파일 이름이 아니라 실제 바이트로 어느 형식인지 알아냅니다. 암호를 상대에게 가져가는 일은 여전히 당신 몫입니다 — 전화로든, 직접 만나서든, 파일과 독립적으로 실패하는 무엇으로든.