요즘 금융기관이나 통신사, 공공기관에서 청구서나 각종 증명서를 메일로 보낼 때 흔히 보는 것이 있다. 바로 HTML 형식의 소위 ‘보안 메일’이다. 주민등록번호 앞자리나 사업자등록번호 같은 걸 암호로 넣어야 열리는 이 첨부파일은, 얼핏 보면 개인정보 보호를 위한 조치처럼 보인다. 간혹 ZIP이나 PDF 형식으로 오기도 하지만, 대부분은 각 업체의 독자적인 HTML 파일 형태다. 하지만 실제로 이 방식은 보안에도 도움이 안 되고, 사용자 경험만 망가뜨리는 나쁜 관행이다.
보안 습관을 오히려 약화시킨다
가장 심각한 문제는 역설적이게도 ‘보안’이라는 이름으로 포장된 이 방식이 실제로는 보안 습관을 망친다는 점이다.
금융기관, 통신사, 공공기관처럼 ‘믿을만한’ 곳에서 온 메일의 첨부파일을 다운받아 실행하는 행위가 일상화되면 어떻게 될까? 사용자는 점차 “은행에서 온 메일이니까 괜찮겠지”, “국세청 메일이니까 안전하겠지” 하는 식으로 경계심이 약해진다. 문제는 피싱 공격이 바로 이런 신뢰를 노린다는 것이다.
실제로 최근 몇 년간 금융기관을 사칭한 피싱 메일이 크게 늘었다. 발신자 주소를 교묘하게 위장하고, 실제 기관과 똑같은 디자인의 HTML 첨부파일을 보내는 수법이다. 평소 진짜 은행 메일에서 첨부파일을 열어보는 데 익숙한 사용자라면 이런 피싱 메일을 구분하기가 훨씬 어려워진다.
보안의 기본 원칙은 “메일 첨부파일은 함부로 열지 않는다”인데, 정작 공공기관과 금융기관이 앞장서서 이 원칙을 무너뜨리고 있는 셈이다.
암호로서의 가치가 전혀 없다
보안 메일의 암호는 대부분 주민등록번호 앞 6자리나 사업자등록번호 10자리다. 이게 과연 ‘암호’라고 할 수 있을까?
6자리 숫자는 경우의 수가 100만 가지다. 10자리라 해도 100억 가지에 불과하다. 최신 컴퓨터로 무차별 대입 공격(brute force attack)을 시도하면 6자리 숫자는 1초도 안 걸려 뚫린다. 10자리도 적당한 GPU를 동원하면 몇 분이면 충분하다.
더 큰 문제는 이런 ‘암호’의 상당수가 이미 공개되어 있거나 추측 가능하다는 점이다. 주민등록번호 앞자리는 생년월일이다. SNS나 다른 경로로 생년월일을 알면 바로 암호를 알 수 있다. 사업자등록번호는 국세청 사업자등록상태 조회 사이트에서 상호명으로 검색하면 나온다.
결국 이 ‘보안 메일’은 보안이 아니라 그냥 번거로움만 추가한 것에 불과하다. 정말 중요한 문서를 보호하려면 제대로 된 암호화 방식이나 보안 메시징 시스템을 써야 한다.
AI 시대의 자동화를 가로막는다
요즘 이메일 관리를 자동화하는 도구들이 많이 나오고 있다. Claude의 MCP(Model Context Protocol)나 ChatGPT의 Actions, Gemini의 Extensions 같은 기술을 쓰면 메일을 읽고 중요한 정보를 추출하거나, 일정을 자동으로 등록하거나, 청구서를 분류하는 등의 작업을 AI가 대신 처리할 수 있다.
그런데 보안 메일은 이런 자동화를 완전히 불가능하게 만든다. 암호로 잠긴 첨부파일은 AI가 읽을 수 없다. 사람이 직접 다운로드 받고, 암호를 입력하고, 파일을 열어봐야 한다. 2020년대 중반에 메일 한 통 확인하는 데 이런 수작업이 필요하다는 게 말이 되는가?
현 정부에서도 AI 활용을 강조하면서 특정 문서 포맷의 개선을 주문하고 있다고 들었다. 보안 메일이야말로 AI 시대에 걸림돌이 되는 대표적인 관행이다. 디지털 혁신을 말하면서 한편으로는 1990년대식 파일 암호화에 매달리는 건 앞뒤가 맞지 않는다.
크로스 플랫폼은 포기했다
보안 메일의 또 다른 문제는 플랫폼 호환성이다. PC에서는 그나마 HTML 파일을 브라우저로 열 수 있어서 볼 수 있다. 하지만 모바일은 이야기가 다르다.
iPhone이나 Android 기본 메일 앱에서는 이런 독자 형식의 HTML 파일을 제대로 렌더링하지 못하는 경우가 많다. ZIP으로 온 경우는 별도의 압축 해제 앱을 설치해야 한다. 특정 업체의 전용 앱을 깔아야만 볼 수 있는 형식도 있다.
출장 중에 급하게 청구서를 확인해야 하는데 모바일에서 열리지 않는 경험을 해본 사람이라면 이 짜증을 이해할 것이다. 2026년에 메일 하나 확인하려고 앱을 새로 깔아야 한다는 게 말이나 되는가?
웹 표준이나 크로스 플랫폼 호환성은 현대 소프트웨어의 기본 중의 기본이다. 하지만 보안 메일은 이런 기본도 무시한 채 특정 플랫폼, 특정 프로그램에 종속된 방식을 강요한다.
결국은 그냥 귀찮다
기술적인 문제를 다 떠나서, 보안 메일은 그냥 쓰기 불편하다.
메일을 열면 첨부파일을 다운로드 받아야 한다. 그 파일을 열면 암호를 물어본다. 암호를 입력한다. 그래야 비로소 내용을 볼 수 있다. 단순히 청구서 금액 하나 확인하려는데 이 모든 과정을 거쳐야 한다.
일반 메일이라면 메일함에서 바로 내용을 확인하고 넘어갈 일을, 보안 메일은 최소 3~4단계의 추가 작업을 요구한다. 매달 받는 여러 청구서를 생각하면 1년에 소요되는 시간도 만만치 않다.
더군다나 암호를 잊어버리거나 잘못 입력하면 다시 처음부터 시작해야 한다. 누구 앞으로 온 메일이더라? 수신한 사업체의 사업자등록번호가 뭐였더라? 이런 걸 매번 고민해야 한다.
폐지되어야 한다
보안 메일은 실질적인 보안 효과는 거의 없으면서 사용자 경험만 크게 떨어뜨린다. 더 나쁜 것은 잘못된 보안 습관을 만들어 오히려 피싱 공격에 취약하게 만든다는 점이다.
만약 정말 개인정보를 보호해야 한다면 다른 방법을 고민해봐야 한다. 차라리 그냥 평문으로 된 메일을 보내는 것도 방법이다. 어차피 지금의 숫자 조합 암호는 보안 효과가 없으니 말이다. 정말 암호가 필요하다면 사용자가 미리 강력한 암호를 직접 설정하게 하는 것도 방법이겠다.
웹 포털에 로그인해서 확인하게 하는 방식을 제안할 수도 있겠지만, 이것도 문제가 있다. 메일에 링크를 넣어서 클릭을 유도하는 방식은 피싱 메일과 구분이 어렵다. “여기를 클릭해서 확인하세요”라는 메일에 익숙해지면, 가짜 링크를 클릭하는 것도 쉬워진다. 결국 이것도 보안 습관을 약화시키는 건 마찬가지다.
하지만 지금의 보안 메일은 ‘혹시 모를 책임 면피’용 이상의 가치가 없어 보인다. “우리는 암호를 걸어서 보냈으니 문제가 생겨도 우리 책임 아니다” 정도의 알리바이용이랄까.
사용자 편의성과 실제 보안, 그리고 AI 시대의 자동화를 생각한다면 보안 메일은 빠른 시일 내에 폐지되어야 한다. 2026년에도 여전히 이런 방식을 고집하는 기관이 있다면, 정말 사용자를 위한 서비스인지 다시 한번 돌아볼 필요가 있다.
