왜 이메일 보안에서 PPAP는 안 되는가. 올바른 방법은?

“비밀번호가 걸린 ZIP을 보내고, 그다음 다른 메일로 비밀번호를 보내는 운영은 정말 안전한가”. 이 질문은 지금도 자주 나옵니다. 겉보기에는 암호화하고 있으니 안전해 보이지만, 실무에서는 그 지점이 함정입니다.

이른바 PPAP는 도청 대책으로서 약하고, 잘못된 발송에 대한 대책으로도 충분하지 않으며, 게다가 메일 경로상의 검사를 방해하기 쉽기 때문에, 현재의 이메일 보안에서는 권하기 어려운 방식입니다.¹²³⁴

이 글에서는 2026년 4월 시점에서 확인할 수 있는 공식 자료와 1차 정보를 바탕으로, PPAP의 문제점과 실무에서 어떻게 바꾸는 것이 자연스러운지를 살펴봅니다.^12345678910

이 글의 대상 독자와 전제

이 글에서 쓰는 용어

3장 이후에서 설명 없이 나오는 말을 먼저 한 줄씩 정리해 둡니다.

1. 먼저 결론

PPAP를 그만두는 이야기는 암호화를 그만두는 이야기가 아닙니다. 그만두어야 할 것은 “첨부 파일을 ZIP으로 암호화하고, 같은 메일 경로로 나중에 비밀번호를 보내는” 설계입니다.

대신 생각할 것은 다음 세 가지입니다.

1. 일상 업무 메일은 TLS / STARTTLS 같은 전송로 보호를 전제로 한다.⁷¹⁰
2. 메일 자체의 진위나 암호화가 필요하면 S/MIME 같은 구조를 쓴다.³⁵⁶
3. 기밀 파일 전달은 첨부가 아니라 인증이 있는 다운로드나 접근 제어가 있는 공유로 옮긴다.⁴⁸⁹

요컨대, 메일의 문제를 ZIP 비밀번호로 전부 해결하려고 하지 않는 것이 중요합니다.

이 글의 지식 맵

PPAP는 비밀번호가 걸린 ZIP을 보낸 뒤 같은 메일 계통으로 비밀번호를 따로 보내는 운영이지만, 도청 대책으로서는 약하고, 오발송이 일어나면 비밀번호까지 같은 상대에게 도착해 사고가 완성되며, 암호화된 첨부는 멀웨어 검사를 우회하기 쉽고, 발신자의 진위성이나 접근 통제도 보장하지 않습니다. 대안으로, 일반적인 업무 메일은 TLS/STARTTLS로 통신로를 보호하는 것을 전제로 하고, 진위성이나 본문 암호화가 필요하면 S/MIME을 쓰며, 기밀 파일 전달은 권한 설정·기한·취소를 다룰 수 있는 인증 기반 다운로드나 OneDrive·Google 드라이브의 접근 제어가 있는 공유로 바꾸는 것이 실무상의 답이 됩니다. 어쩔 수 없이 첨부가 필요한 경우에 한해, 비밀번호를 다른 경로로 전하는 운영은 잠정 대책으로 둡니다.

flowchart LR
    accTitle: PPAP가 부적절한 이유와 대안의 지식 맵
    accDescr: PPAP가 도청 대책이나 오발송 대책으로는 약하고 멀웨어 검사도 우회하기 쉬우며, 일반 메일은 TLS나 S/MIME으로 보호하고 기밀 파일은 인증 기반 공유로 바꿔야 함을 보여주는 그림
    ppap["PPAP"]
    authenticated_file_sharing["인증 포함 다운로드/액세스 제어 공유"]
    password_protected_zip_attachment["비밀번호 있는 ZIP 첨부"]
    same_channel_password_delivery["동일 메일 계통의 비밀번호 별송"]
    email_confidentiality["메일 도청 대책(기밀성)"]
    misdirected_email_impact["오전송 시의 피해"]
    malware_scan_evasion["멀웨어 검사 우회"]
    emotet["Emotet"]
    sender_authenticity["발신자 진정성"]
    email_access_control["메일·파일 액세스 제어"]
    tls_email_transport["TLS/STARTTLS에 의한 통신로 보호"]
    normal_business_email["일반적인 업무 메일"]
    smime["S/MIME"]
    confidential_file_transfer["기밀 파일 전달"]
    link_revocation["링크·액세스 권한 취소"]
    access_expiration["공유 만료 기한"]
    onedrive_sharepoint_sharing["OneDrive/SharePoint 공유 기능"]
    google_drive_sharing["Google 드라이브 공유 기능"]
    manual_out_of_band_password_delivery["비밀번호의 별도 경로 수동 전달"]
    ppap -->|"이용한다"| password_protected_zip_attachment
    ppap -->|"이용한다"| same_channel_password_delivery
    ppap -->|"사용은 비권장"| email_confidentiality
    ppap -.->|"원인이 될 수 있다"| misdirected_email_impact
    ppap -->|"원인이 될 수 있다"| malware_scan_evasion
    emotet -->|"이용한다"| malware_scan_evasion
    ppap -->|"사용은 비권장"| sender_authenticity
    ppap -->|"사용은 비권장"| email_access_control
    tls_email_transport -->|"권장되는 대응"| normal_business_email
    smime -.->|"권장되는 대응"| normal_business_email
    smime -->|"구현을 담당한다"| sender_authenticity
    authenticated_file_sharing -->|"권장되는 대응"| confidential_file_transfer
    authenticated_file_sharing -->|"전제로 한다"| email_access_control
    authenticated_file_sharing -->|"전제로 한다"| link_revocation
    authenticated_file_sharing -->|"전제로 한다"| access_expiration
    ppap -->|"양립하지 않는다"| link_revocation
    onedrive_sharepoint_sharing -->|"구현을 담당한다"| authenticated_file_sharing
    google_drive_sharing -->|"구현을 담당한다"| authenticated_file_sharing
    onedrive_sharepoint_sharing -->|"에서 구성할 수 있다"| access_expiration
    google_drive_sharing -.->|"에서 구성할 수 있다"| access_expiration
    authenticated_file_sharing -->|"의 후속"| ppap
    manual_out_of_band_password_delivery -.->|"권장되는 대응"| confidential_file_transfer

그림의 실선은 항상 성립하는 관계, 점선은 조건이 붙는 관계입니다(성립 조건은 상세 페이지의 관계별 설명에 적혀 있습니다). 관계 전체 목록(총 22건, 근거와 확신도 포함)과 주요 개념의 정의는 지식 맵 상세 페이지에 정리되어 있습니다(일본어). 데이터: JSON-LD / Turtle

2. 애초에 PPAP란 무엇인가

여기서 말하는 PPAP는 일반적으로 다음 흐름을 가리킵니다.

1. 파일을 비밀번호가 걸린 ZIP으로 만든다
2. 첫 번째 메일로 ZIP을 보낸다
3. 두 번째 메일로 비밀번호를 보낸다

이 운영은 “평문으로 보내지 않으니 안전하다”고 이해되기 쉽습니다. 다만 실제로 보호되는 범위는 상당히 한정적입니다.

겉보기만큼 만능이 아니며, “왠지 안전해 보인다”에 비해 핵심을 지키지 못하고 있다는 것이 PPAP의 문제입니다.

3. 왜 PPAP는 안 되는가

3.1 도청 대책으로서 약하다

내각부는 ZIP 파일 전송과 같은 경로로 비밀번호를 자동 송신하는 방식은 적절하지 않다고 정리하고 있습니다.¹ 중요한 것은, 파일을 암호화했는지뿐 아니라, 키를 어떻게 전달할지까지 포함해 설계하지 않으면 실효가 떨어진다는 점입니다.

같은 메일 환경, 같은 받은편지함, 같은 상대에게 뒤이어 보내기만 해서는 ZIP을 볼 수 있는 사람과 비밀번호를 볼 수 있는 사람이 거의 같아지기 쉽기 때문입니다. 이래서는 “암호화하고 있다”는 사실만 남고, 실질적인 기밀성은 그다지 강하지 않습니다.

3.2 잘못된 발송에 대한 대책으로 충분하지 않다

PPAP를 잘못된 발송에 대한 대책이라고 생각하는 운영도 있지만, 그쪽도 약합니다.

IPA의 응용정보기술자시험 정답 예시에서는 PPAP의 문제점으로, 본문 메일을 잘못 보내면 복호화용 비밀번호도 잘못된 상대에게 도착해 버린다는 점이 꼽혀 있습니다.³ 디지털청 자료에서도 “별도의 메일로 상대에게 보내는 것은 같은 상대에게 보내는 것이 되어, 제어 수단으로 기능하지 않는다”는 취지의 정리가 나와 있습니다.⁴

즉, 잘못된 상대에게 ZIP을 보낸 뒤 습관적으로 비밀번호까지 보내 버리면, 사고는 그대로 성립한다는 이야기입니다. 정말로 필요한 것은 수신처 확인, 승인, 발송 전 검토, 발송 후의 취소나 회수가 가능한 전달 방식입니다.

3.3 멀웨어 검사를 방해한다

이것은 PPAP의 문제 가운데서도 놓치기 어려운 점입니다.

IPA는 비밀번호가 걸린 ZIP을 첨부한 Emotet 공격 메일에 대해, 첨부 파일이 암호화되어 있으므로 메일 전달 경로상의 보안 제품 탐지·격리를 빠져나가 수신자 손에 도착할 확률이 높다고 주의하고 있습니다.²

보내는 쪽은 “암호화해서 안전하게 했다”고 생각해도, 받는 쪽이나 중계 쪽에서 보면 내용을 검사하기 어려운 첨부 파일이 되어 버립니다. 이 점에서도 PPAP는 현재의 메일 방어와 잘 맞는 방식이라고 하기 어렵습니다.

3.4 진위와 접근 제어를 보장하지 않는다

PPAP는 발신자가 본인임을 증명하지 않습니다. 또한 누가 언제 다운로드했는지, 나중에 취소할 수 있는지, 상대별로 권한을 나눌 수 있는지와 같은 접근 제어도 거의 가지고 있지 않습니다.

한편 IPA는 S/MIME 같은 전자 서명이 있는 메일을 다루고 있으며, PPAP의 대체로서도 문맥상 이어져 있습니다.⁵⁶ 또한 IPA의 Web 보안 자료에서는, 비공개 정보를 다루는 Web에는 인증 기능과 접근 제어가 필요하다고 정리되어 있습니다.⁸

이 두 가지를 맞추어 생각하면 답은 꽤 분명합니다.

• 메일의 진위나 변조 탐지가 필요하면 S/MIME
• 파일의 열람 권한이나 취소 관리가 필요하면 인증이 있는 다운로드

ZIP 비밀번호를 따로 보내는 방식은, 그 어느 쪽에도 깔끔하게 답하지 않습니다.

4. 올바른 방법은 “목적별로 나누는 것”

“안전하게 보내고 싶다”는 요구는 실제로는 하나가 아닙니다. 여기를 나누지 않으면 전부 PPAP로 끝내려고 해서 설계가 무너집니다.

4.1 일상 업무 메일

일상 업무 메일이라면, 우선 TLS / STARTTLS 같은 전송로 보호가 전제입니다.⁷¹⁰ 그 위에서 발신자의 진위, 변조 탐지, 메일 본문 자체의 암호화가 필요하면 S/MIME를 검토하는 것이 순서입니다.³⁵⁶

4.2 기밀 파일 전달

상대 본인에게만 파일을 건네고 싶다, 열람 권한을 제어하고 싶다, 나중에 취소하고 싶다. 이 요건이라면 첨부보다 인증이 있는 다운로드나 접근 제어가 있는 공유가 더 자연스럽습니다.⁴⁸⁹

예를 들어 다음과 같은 요건은, 첨부보다 Web 쪽에서 관리하는 편이 다루기 쉬워집니다.

• 로그인 후에 다운로드할 수 있다
• 기한이 있는 링크로 만들 수 있다
• 상대별로 권한을 나눌 수 있다
• 필요하면 이력을 남길 수 있다

“무엇을 살까”보다 먼저, 충족할 조건을 정한다

제품명부터 들어가면 비교할 수 없어지므로, 먼저 조건을 늘어놓습니다. PPAP와의 차이는 이 6줄에 모입니다.

이 표의 왼쪽에서 오른쪽으로 옮기는 것이 “PPAP를 그만둔다”의 실체입니다. 반대로 말하면, 이 6줄을 충족하지 않는 대체 수단이라면 갈아탈 실효가 거의 없다는 이야기이기도 합니다.

많은 경우, 이미 계약한 범위에서 할 수 있다

새 제품을 사기 전에, 지금 계약으로 어디까지 되는지를 확인하는 편이 먼저입니다. 대표적인 곳은 다음과 같습니다.

우선순위는 “특정 상대를 지정한 공유”가 첫째, “비밀번호가 있는 링크”는 차선입니다. 상대가 계정을 준비할 수 없는 경우에 한해 비밀번호가 있는 링크를 쓰고, 그 비밀번호는 전화나 SMS 등 메일과 다른 경로로 전합니다. 여기서 같은 메일 경로로 흘리면, 바꿨다고 생각하고 PPAP와 같은 구조로 돌아갑니다.

직접 만들 때 최소한 갖출 것

자사 사이트에 다운로드 기능을 만드는 경우에도, 생각할 것은 달라지지 않습니다.

1. 상대를 식별하는 수단 전달 상대에게 계정을 발급하거나, 건별로 일회용 토큰이 붙은 URL을 발급합니다.
2. 기한 URL과 토큰 양쪽에 유효 기간을 둡니다. 기한 만료는 “보이지 않음”이 아니라 “취소되었습니다”라고 명시적으로 반환합니다.
3. 취소 조작 운영 담당이 관리 화면에서 즉시 무효화할 수 있어야 합니다. 여기가 없으면 잘못된 발송을 알아채도 할 수 있는 일이 없습니다.
4. 접근 로그 언제, 어느 IP에서, 어느 파일이 가져와졌는지를 남깁니다. 사고가 났을 때 “전달됐는지, 안 됐는지”에 답할 수 있는지가 갈림길입니다.
5. 파일 보관 장소의 보호 URL을 알면 누구나 가져갈 수 있는 상태로 두지 않는다는 뜻입니다. IPA도, 비공개 정보를 다루는 Web 사이트에는 인증 기능과 접근 제어가 필요하다고 정리하고 있습니다.⁸
6. 업로드 쪽의 취급 상대로부터 받을 때도 같은 구조로 모읍니다. 수신 전용 폼을 만드는 편이, 메일 첨부를 계속 받는 것보다 안전합니다.

이 6가지 가운데 2와 3이 PPAP와의 결정적인 차이입니다. 만들든 사든, 여기가 없는 것은 대체가 되지 않습니다.

4.3 첨부가 꼭 필요한 경우

상대 사정으로 첨부만 쓸 수 있는 장면은 있습니다. 그 경우에는 내각부의 정리에도 있듯이, 파일과 비밀번호를 전혀 다른 경로로 전하는 것이 최소한의 선이 됩니다.¹

다만 이것은 완성형이 아니라 임시 대책입니다. 매번 표준 운영으로 고정하기보다, 장기적으로는 인증이 있는 공유로 옮긴다는 전제로 생각하는 편이 낫습니다.

5. 중소기업에서의 전환 절차

중소기업에서 PPAP를 그만둘 때는, 처음부터 큰 구조를 넣기보다 먼저 분류를 분명히 하는 편이 효과가 있습니다.

5.1 먼저 그만둘 것

• 자동 ZIP 암호화
• 같은 메일 경로에서의 자동 비밀번호 따로 보내기
• “중요 파일은 전부 PPAP”라는 일률 규칙

5.2 다음에 정할 것

• 무엇을 일상 메일로 보내도 되는가
• 무엇을 첨부 금지로 하는가
• 무엇을 인증이 있는 다운로드로 돌리는가
• 예외적으로 첨부할 때의 승인 절차를 어떻게 하는가

5.3 최소 구성의 관점

처음에는 다음 두 갈래로 나누기만 해도 충분합니다.

1. 일상 메일
   • 업무 연락
   • 필요에 따라 S/MIME
2. 기밀 파일
   • 인증이 있는 다운로드
   • 권한 설정
   • 기한이 있는 공유

여기가 모호하면 현장은 결국 “일단 PPAP”로 돌아가기 쉬워집니다.

6. 판단 흐름

flowchart TD
    A[상대에게 무엇을 건네고 싶은가] --> B{기밀성이 높은 파일인가}
    B -- 아니오 --> C[일상 업무 메일]
    C --> C1[TLS / STARTTLS를 전제로 보낸다]
    C --> C2[진위나 암호화가 중요하면 S/MIME]

    B -- 예 --> D{상대가 로그인해서 받을 수 있는가}
    D -- 예 --> E[인증이 있는 다운로드 / 접근 제어가 있는 공유]
    E --> E1[필요에 따라 권한·기한·취소를 설정]

    D -- 아니오 --> F{첨부가 꼭 필요한가}
    F -- 예 --> G[암호화 파일 + 다른 경로의 수동 비밀번호]
    F -- 아니오 --> E

그림이 표시되지 않는 환경을 위해, 같은 판단을 표로도 둡니다. 위에서부터 보고, 처음 해당하는 행의 결론을 취합니다.

이 그림에서 중요한 것은, PPAP를 만능의 중간 해법으로 두지 않는 것입니다. 메일과 파일 전달은 나누어 생각하는 편이 설계하기 쉬워집니다.

7. 자주 있는 오해

7.1 “ZIP을 암호화하고 있으니 안전하다”

암호화하고 있어도, 키를 전하는 방식이 약하면 충분하지 않습니다. 게다가 비밀번호가 걸린 ZIP은 경로상 검사를 방해하는 경우가 있습니다.¹²

7.2 “다른 메일로 보내면 충분하다”

같은 상대, 같은 메일 경로로의 후속 송신은 강한 제어가 되지 않습니다.¹⁴

7.3 “PPAP를 그만두면 첨부할 수 없게 된다”

그렇지 않습니다. 일상 메일, S/MIME, 인증이 있는 다운로드, 예외 시의 다른 경로 비밀번호를 나누어 쓸 뿐입니다.

7.4 “S/MIME는 대기업용이라 현실적이지 않다”

상대 측의 대응 상황은 보지만, 적어도 PPAP보다는 무엇을 지키고 싶은지에 대해 논리가 맞습니다. 또한 S/MIME가 맞지 않는 상대에게는 인증이 있는 다운로드라는 다른 선택지가 있습니다.

8. 정리

PPAP가 안 되는 것은, 암호화하고 있는데 안전해진 느낌이 들기 쉽다는 점에 있습니다. 실제로는,

• 같은 메일 경로로 따로 보내면 기밀성이 약하다
• 잘못된 발송에 대한 대책으로 충분하지 않다
• 비밀번호가 걸린 ZIP은 경로상 검사를 방해한다
• 발신자의 진위나 접근 제어는 보장할 수 없다

는 문제가 남습니다.¹²³⁴

따라서 해야 할 일은 PPAP식 운영을 조금 바꿔 질질 끄는 것이 아닙니다. 메일은 메일로서 지키고, 파일 전달은 파일 전달로서 설계하는 것입니다.

한 줄로 정리하면 이렇습니다.

PPAP를 그만둔다는 것은 암호화를 그만두는 것이 아니라, 잘못된 제어를 그만두고 목적에 맞는 제어로 바꾸는 것입니다.

관련 글

• 중소기업용의 일제 메일 배포를, 특정 서비스에 얽매이지 않고 설계하는 방법
• 글과 서비스 페이지를 어떻게 잇는가 - 내부 링크 설계의 기본
• 서비스 페이지를 어떻게 만들 것인가 - 기술계·B2B용 정리 절차

참고 자료

관련 기사

같은 태그를 공유하는 최신 기사입니다. 더 가까운 주제로 지식을 넓힐 수 있습니다.

관련 토픽

이 기사와 가까운 토픽 페이지입니다. 기사를 출발점 삼아 관련 서비스와 다른 기사로 이어집니다.

이 주제와 연결되는 서비스

이 기사는 다음 서비스 페이지로 이어집니다. 가까운 입구부터 확인해 주세요.

자주 묻는 질문

이 기사 주제에 대해 상담 시 자주 나오는 질문을 모았습니다.

PPAP란 무엇인가요?

파일을 비밀번호가 걸린 ZIP으로 만들어 첫 번째 메일로 보내고, 두 번째 메일로 비밀번호를 보내는 운영입니다. 평문으로 보내지 않으니 안전해 보이지만, 실제로 보호되는 범위는 상당히 한정적입니다. 통신 경로상의 기밀성은 약하고, 잘못된 발송에 대한 대책으로도 충분하지 않으며, 발신자의 진위나 접근 제어도 보장하지 않습니다.

왜 PPAP는 위험한가요?

문제는 크게 네 가지입니다. 같은 메일 경로로 비밀번호를 따로 보내도 ZIP을 볼 수 있는 사람과 비밀번호를 볼 수 있는 사람이 거의 같아지므로 도청 대책으로서 약하다는 점. 수신처를 잘못 지정하면 복호화용 비밀번호도 같은 상대에게 도착해, 잘못된 발송에 대한 대책으로 충분하지 않다는 점. 비밀번호가 걸린 ZIP은 암호화되어 있어 메일 전달 경로상의 보안 제품 탐지·격리를 빠져나가기 쉽고, Emotet 같은 공격 메일에 악용된 실적이 있다는 점. 그리고 발신자의 진위나 접근 제어를 보장하지 않는다는 점입니다.

PPAP를 그만두면 무엇을 쓰면 되나요?

목적별로 세 가지로 나누는 것이 기본입니다. 일상 업무 메일은 TLS / STARTTLS 같은 전송로 보호를 전제로 하고, 메일 자체의 진위나 암호화가 필요하면 S/MIME를 씁니다. 기밀 파일 전달은 첨부가 아니라 인증이 있는 다운로드나 접근 제어가 있는 공유로 옮기면, 권한 설정·기한이 있는 링크·취소 관리까지 다룰 수 있습니다. 메일의 문제를 ZIP 비밀번호로 전부 해결하려고 하지 않는 것이 중요합니다.

첨부 파일로 보낼 수밖에 없을 때는 어떻게 하나요?

상대 사정으로 첨부만 쓸 수 있는 경우에는, 암호화한 파일과 비밀번호를 전혀 다른 경로로 전하는 것이 최소한의 선입니다. 다만 이것은 완성형이 아니라 임시 대책입니다. 매번 표준 운영으로 고정하지 말고, 장기적으로는 인증이 있는 공유로 옮긴다는 전제로 생각하는 편이 안전합니다.

저자 프로필

기사 저자의 프로필 페이지입니다.

Go Komura

합동회사 코무라소프트 대표

Windows 소프트웨어 개발, 기술 상담, 장애 조사를 중심으로 재현이 어려운 장애 조사와 기존 자산이 남아 있는 프로젝트에 강점이 있습니다.