▲

이메일 난독화: 2026년에 효과적인 방법은?

 (spencermortensen.com)
5P by GN⁺ 17시간전 | ★ favorite | 댓글 1개
  • 이메일 주소를 스팸 수집기로부터 보호하기 위해 다양한 HTML·CSS·JavaScript 난독화 기법을 실험해 차단율을 비교함
  • 426개 텍스트·399개 링크 표본을 대상으로 테스트한 결과, 대부분의 JS 기반·CSS·SVG 기법이 100% 차단율을 기록함
  • HTML 엔티티·URL 인코딩 같은 오래된 방식도 여전히 높은 차단 효과를 보였음
  • 반면 이미지 표시·기호 치환·텍스트 방향 반전 등은 접근성과 사용성을 심각하게 저해함
  • 2026년 기준으로는 JS 변환·AES 암호화·사용자 상호작용 방식이 가장 안전하고 실용적인 이메일 보호 수단으로 평가됨

이메일 주소 난독화 기법 비교 (2026년 기준)

  • 이메일 주소를 스팸 수집기(하베스터) 로부터 숨기기 위한 다양한 난독화 기법과 각 기법의 실제 효과를 통계로 제시
  • 각각의 이메일 주소를 다른 방식으로 보호한 뒤, 426개(텍스트) 및 399개(링크) 표본을 대상으로 하베스터 접근 여부를 측정해 차단율 산출
  • 대부분의 JavaScript 기반 기법과 일부 CSS·SVG 기법이 100% 차단율을 기록
  • HTML 엔티티·URL 인코딩 같은 오래된 방식도 여전히 높은 차단율 유지
  • 일부 기법은 접근성이나 사용성을 심각하게 저해해 실사용에는 부적합

1. 일반 텍스트 이메일 보호 기법

  • 이메일 주소를 페이지에 직접 표시하되, 다양한 HTML·CSS·JS 기법으로 하베스터가 읽지 못하게 하는 방식
  • 여러 기법을 조합해 세그먼트별로 보호하면 효과 극대화 가능

  • 보호 없음 (No protection)

    • 차단율 0% (426명 중 0명 차단)
    • 이메일 주소가 그대로 노출되어 모든 하베스터에게 수집됨

  • HTML 엔티티 (HTML Entities)

    • 차단율 95%
    • 서버 측 라이브러리가 자동으로 디코딩하지만, 실제로는 대부분의 하베스터 차단

  • HTML 주석 (HTML Comments)

    • 차단율 99%
    • HTML 태그 해석이 약한 기본형 하베스터만 차단 가능
    • 단순하지만 여전히 높은 차단 효과 유지

  • HTML SVG

    • 차단율 100%
    • 이메일 주소를 SVG 객체 내부 텍스트로 숨김
    • 시각장애인용 스크린리더 접근 가능
    • <object> 요소 사용 필수, <img>나 인라인 SVG는 소스 노출 위험
    • 폰트 의존성이 있어 웹 폰트 지정 필요

  • CSS display:none

    • 차단율 100%
    • 스타일 규칙을 적용하지 못하는 하베스터의 한계를 이용
    • 접근성 유지 가능하며, 시각적 숨김 대신 display:none 사용 권장

  • JS 문자열 연결 (Concatenation)

    • 차단율 100%
    • 외부 의존성 없이 간단히 구현 가능
    • 이메일 전체가 HTML 소스에 존재하므로 보안상 취약

  • JS Rot18

    • 차단율 100%
    • ROT13과 유사한 문자 회전 암호 사용
    • 단순한 하베스터는 해독 불가하지만, JS를 무시하는 수집기에는 취약

  • JS 변환 (Conversion)

    • 차단율 100%
    • HTML에는 의미 없는 문자열만 포함하고, JS 함수가 이를 실제 이메일로 변환
    • 대부분의 하베스터는 DOM·JS 실행 불가로 복원 불가능
    • 간단하면서도 매우 효과적인 기법

  • JS AES 암호화

    • 차단율 100%
    • AES-256 암호화를 이용해 이메일 보호
    • 브라우저의 SubtleCrypto API 사용, HTTPS 환경에서만 작동
    • JS 파일 없이는 복호화 불가능

  • JS 사용자 상호작용 (User interaction)

    • 차단율 100%
    • 사용자가 페이지와 상호작용할 때만 이메일 표시
    • 하베스터는 DOM 실행 + 사용자 이벤트 시뮬레이션이 필요해 사실상 불가능

  • HTML 기호 치환 (Symbol substitution)

    • 차단율 96%
    • “AT”, “DOT” 등으로 치환
    • 사용자가 직접 수정해야 하므로 사용성 저하

  • HTML 지시문 (Instructions)

    • 차단율 100%
    • 이메일에 “remove the .fluff” 같은 수동 지시 포함
    • 사람이나 AI만 해석 가능하지만 사용자 불편 큼

  • HTML 이미지

    • 차단율 100%
    • 이메일 주소를 이미지로 표시
    • 시각장애인 접근 불가, 복사 불가 등 사용성 붕괴

  • CSS content

    • 차단율 100%
    • ::after 가상요소로 이메일 표시
    • 시각적으로는 보이지만 복사 불가, HTML만으로도 복원 가능
    • 무용한 기법으로 평가

  • CSS 텍스트 방향 (Text direction)

    • 차단율 100%
    • direction: rtl로 문자열 반전
    • 하베스터가 CSS를 무시하면 쉽게 해독 가능
    • 텍스트가 거꾸로 복사되어 사용성 저하

2. 클릭 가능한 링크 보호 기법

  • mailto: 링크의 href 속성을 보호하는 방식
  • 링크 텍스트에 이메일이 포함될 경우, 별도의 텍스트 난독화 기법 병행 필요

  • 보호 없음

    • 차단율 0% (399명 중 0명 차단)
    • 이메일 주소 완전 노출

  • HTML 엔티티

    • 차단율 100%
    • 서버 측 자동 디코딩에도 불구하고 대부분의 하베스터 차단

  • URL 인코딩

    • 차단율 95%
    • 디코딩이 쉬우나 실제로는 대부분의 하베스터 차단

  • HTTP 리다이렉트

    • 차단율 100%
    • mailto: 링크를 일반 링크처럼 보이게 숨김
    • .htaccess에서 302 또는 301 리다이렉트 설정
    • nofollow, noindex로 검색엔진 인덱싱 방지
    • 메일 필드 자동 채움 시 QSA 플래그 필요

  • HTML SVG

    • 차단율 100%
    • 이메일 링크를 SVG 내부에 숨김
    • 접근성 유지, <object> 사용 필수
    • 폰트 지정 필요

  • JS 문자열 연결

    • 차단율 100%
    • 외부 의존성 없이 구현 가능
    • 이메일이 HTML에 직접 포함되어 안전하지 않음

  • JS Rot18

    • 차단율 99%
    • ROT13과 유사한 문자 회전
    • 단순한 하베스터는 해독 불가

  • JS 변환 (Conversion)

    • 차단율 100%
    • HTML에는 가짜 링크만 존재하고 JS가 이를 실제 mailto:로 변환
    • 하베스터는 HTML만 접근 가능하므로 복원 불가
    • 간단하면서도 매우 효과적인 기법

  • JS AES 암호화

    • 차단율 100%
    • AES-256으로 암호화된 이메일 링크
    • 브라우저의 SubtleCrypto API 사용, HTTPS 필요

  • JS 사용자 상호작용

    • 차단율 100%
    • 사용자가 페이지와 상호작용해야만 링크 활성화
    • 하베스터가 이를 재현하기 어려움

3. 비판 및 반론

  • “스패머는 웹을 긁지 않고 유출 데이터베이스를 구매한다”는 주장에 대해
    • 이 페이지의 이메일 주소들은 이 페이지에만 공개되었음에도 수천 건의 스팸을 받음
  • “보호 필요 없다”는 주장에 대해
    • 인기 콘텐츠는 집중적으로 수집되므로 바이럴 가능성을 고려하면 보호 필요
  • “스팸 필터만 있으면 된다”는 주장에 대해
    • 이 기법들은 오탐 없이 무료로 구현 가능, 필터와 병행 사용이 바람직
  • “기법이 알려지면 무용하다”는 주장에 대해
    • 수십 년간 동일한 기법이 여전히 유효함이 통계로 확인됨

4. 실험 방법론

  • 각 난독화 기법으로 보호된 이메일 주소를 실제로 공개해 하베스터용 허니팟으로 운영
  • 스팸이 도착하면 해당 주소의 보호 기법이 뚫린 것으로 간주
  • 스패머별로 메시지를 그룹화해 발신자 수 기준 통계 산출
  • 스팸 필터링이 통계를 왜곡하지 않도록 직접 메일 서버와 클라이언트 구축
  • 텍스트 기반과 링크 기반 하베스터가 다르므로 별도 통계로 분리
  • 표본 수는 아직 작지만, 링크가 늘어날수록 통계 신뢰도 향상 예상

결론

  • JS 기반 변환·암호화·사용자 상호작용 기법이 가장 높은 보안성과 접근성 제공
  • CSS display:none과 SVG 객체 기법도 접근성과 차단율 측면에서 우수
  • 기호 치환, 이미지, 텍스트 방향 반전 등은 사용성을 심각하게 해치므로 비추천
  • 이메일 공개가 필요한 경우, 간단한 JS 변환 또는 AES 암호화 방식이 2026년 기준 가장 효과적인 선택임

함께 보면 좋은 글 β

▲
GN⁺ 17시간전  [-]
Hacker News 의견들

  • 예전엔 이메일 수집에 신경 썼지만 이제는 그냥 내 웹사이트에 이메일을 공개해둠
    스팸 필터링이 충분히 괜찮음
    그래도 이런 기술 리뷰는 흥미로웠음. 단순한 방법도 꽤 효과적이라는 게 놀라웠음

    • 2000년대 초부터 내 블로그에 mailto: 링크로 이메일을 평문으로 올려놨는데, 스팸은 하루에 몇 통 정도뿐임
      아마 Zoho의 필터링이 잘 되는 걸 수도 있지만, 대형 서비스보다 특별히 낫다고 생각하진 않음
    • 수집 봇들은 대부분 이미 수백만 개의 주소를 모으기 때문에, 몇 개의 희귀한 이메일은 신경 쓰지 않음
      그래서 자신만의 간단한 방식을 써도 괜찮지만, 그걸 공개하면 바로 무력화될 수 있음
    • 내 회사 웹사이트에 이메일을 올려둔 이후 한 달에 1,500통 이상의 스팸을 받음
    • 나도 비슷하게 이메일을 공개해왔지만, HTML 엔티티나 display:none 같은 간단한 방법으로 90% 이상 막을 수 있다면 다시 고려해볼 만함
    • 이메일은 결국 유출된다고 생각함. 다만 LLM 기반 스팸은 점점 필터를 회피할 가능성이 높다고 봄

  • 내 이메일은 GitHub의 인기 오픈소스 저장소 커밋에 평문으로 90번 이상 포함되어 있음
    그런데 8년 동안 스팸을 거의 받은 적이 없음
    <와 >로 감싸진 형식이 수집기를 혼란스럽게 하는 걸지도 모름
    요즘은 직접 수집보다 이메일 리스트 구매가 더 흔한 듯함

    • 내 도메인에는 와일드카드 주소를 설정해둠
      git@, contact@, admin@ 같은 주소로 스팸이 자주 옴
      최근엔 finance@ 같은 가짜 주소로 CEO 사칭 메일이 오기도 함
      아이러니하게도 HN 프로필에 평문으로 올려둔 이메일은 스팸이 거의 없음

  • 내 가설은 이메일 수집기가 HTML을 파싱하지 않고, 단순히 @ 문자 주변의 문자열만 찾는다는 것임
    HTML 파싱은 비용이 크기 때문에 이런 단순한 방식이 효율적일 수 있음
    그래서 HTML 엔티티가 효과적인 듯함

    • 수집기가 난독화된 주소로 보낸 스팸은 반응률이 낮다는 걸 학습했을 수도 있음
      그래서 그런 주소는 아예 무시하는 걸지도 모름
    • 맞음, 대부분은 단순한 바이트 검색을 하지만, 블랙햇 마케팅 쪽에는 다양한 스크래핑 기법이 존재함
    • 결국 상대가 얼마나 집요하냐의 문제임. 비합리적인 공격자는 끝까지 물고 늘어짐
    • @ 주변 토큰 기반 추출도 약간의 변형으로 충분히 작동함

  • 이 글이 잘 쓰였지만, 도메인 전체를 소유해서 각 수신자에게 고유 이메일을 주는 방법이 언급되지 않아 아쉬움
    스팸이 오면 해당 주소만 차단하면 됨
    아니면 아예 이메일을 쓰지 않는 삶도 있음. 요즘은 임시 이메일로 대부분 해결 가능함

    • 나도 20년째 그런 방식으로 운영 중임
      하지만 스팸의 대부분은 친구나 가족이 내 주소를 앱에 공유해서 생김
      공개된 이메일은 간단한 JavaScript 연결 방식으로 100% 막을 수 있었음
    • 예전에 각 사람마다 고유 이메일을 생성하려 했지만, 결국 화이트리스트 기반 단일 주소로 단순화했음
      효과는 비슷하고 훨씬 관리가 쉬움

  • 웹사이트에 tarpit 이메일 주소를 숨겨두는 방법이 있음
    CSS로 숨겨서 사람은 못 보고, 봇이 메일을 보내면 해당 IP를 24시간 차단함

    • 하지만 이건 Google 같은 주요 메일 서버까지 차단할 위험이 있음
      Gmail 계정에서 오는 스팸도 있기 때문에 부작용이 큼
    • 비슷한 개념으로 Project Honey Pot이 있음

  • 좋은 내용이지만 제목은 ‘Email address obfuscation’이 더 적절하다고 생각함
    다만 이런 글을 보면 스패머들도 배울 수 있을 듯함

    • “email”을 “email address” 대신 쓰는 건 혼란스러움. 문맥상 “이메일 메시지”로 읽히는 경우가 많음
    • Greg Egan의 사이트에 있는 연락처 표현은 너무 난해해서 해독 불가였음

  • 예전에 “me at foobar dot com” 같은 표현이 여전히 효과가 있을까 궁금해서 테스트했음
    LLM을 이용해 여러 이메일 난독화 방식을 풀어보니, CSS나 JS 기반이 아닌 건 대부분 해석 가능했음
    그래도 요즘은 스팸 필터가 잘 작동해서 평문 이메일을 공개해도 큰 문제는 없었음
    오히려 서비스 알림 메일이 더 성가심

    • 더 나은 방법은 방문자가 CPU를 조금 써서 고유 토큰 이메일을 생성하는 방식임
      abuse가 생기면 해당 주소만 폐기하면 됨
      클라이언트와 메일 서버가 이런 API를 지원하면 이상적일 것임
    • LLM 기반 수집기는 사람보다 지시문 해석을 더 잘할 수도 있음
      그래서 단순한 regex 봇을 막는 기초적 난독화가 여전히 유효하다고 봄
    • 관련된 xkcd 1808 만화도 있음

  • 올해 초 C로 Brainfuck 인터프리터를 만들다가 이메일 난독화에 써봤음
    각 이메일을 Brainfuck 프로그램으로 저장하고, JS 인터프리터가 실행해 평문을 표시함
    JS는 외부 도메인에서 로드되고, referer 검증 후 실제 코드를 전송함
    물론 JS를 실행하는 수집기엔 무용지물이지만, 창의적인 난독화 실험으로 흥미로웠음

    • 이 방식은 단순히 JS에서 XOR 암호화하는 것과 어떤 차이가 있는지 궁금함
    • 만약 수집기가 스크린샷을 LLM이나 OCR에 입력한다면 이 방법은 무력화될 듯함

  • 이 글은 이메일 수집기를 더 똑똑하게 만드는 가이드처럼 보이기도 함

    • 맞지만, JS나 CSS 실행, SVG 렌더링 등은 여전히 비용이 큰 작업이라 대규모 봇에게는 부담스러움
답변달기