# 이메일 난독화: 2026년에 효과적인 방법은? > Clean Markdown view of GeekNews topic #28147. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28147](https://news.hada.io/topic?id=28147) - GeekNews Markdown: [https://news.hada.io/topic/28147.md](https://news.hada.io/topic/28147.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-04-03T09:59:14+09:00 - Updated: 2026-04-03T09:59:14+09:00 - Original source: [spencermortensen.com](https://spencermortensen.com/articles/email-obfuscation/) - Points: 5 - Comments: 1 ## Summary 이메일 주소를 **JS로 변환·암호화**해 노출을 막는 접근은, 서버 설정 없이도 적용 가능한 **클라이언트 사이드 보안 레이어**로 볼 수 있습니다. 특히 개인 블로그나 스타트업 랜딩페이지처럼 백엔드 제어권이 제한된 환경에서 실용성이 높습니다. 다만 JS 실행을 전제로 하므로 **정적 사이트 생성기나 AMP 페이지**에서는 적용 범위가 좁습니다. 접근성과 자동화 테스트를 함께 고려하면, 이 기법은 `.env` 대신 **런타임에서 복호화되는 이메일 변수**를 다루는 셈입니다. ## Topic Body - 이메일 주소를 **스팸 수집기**로부터 보호하기 위해 다양한 **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년 기준 가장 효과적인 선택임 ## Comments ### Comment 54528 - Author: neo - Created: 2026-04-03T09:59:15+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47609694) - 예전엔 이메일 수집에 신경 썼지만 이제는 그냥 내 웹사이트에 이메일을 공개해둠 스팸 필터링이 **충분히 괜찮음** 그래도 이런 기술 리뷰는 흥미로웠음. 단순한 방법도 꽤 효과적이라는 게 놀라웠음 - 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](https://www.projecthoneypot.org/)이 있음 - 좋은 내용이지만 제목은 ‘**Email address obfuscation**’이 더 적절하다고 생각함 다만 이런 글을 보면 스패머들도 배울 수 있을 듯함 - “email”을 “email address” 대신 쓰는 건 혼란스러움. 문맥상 “이메일 메시지”로 읽히는 경우가 많음 - [Greg Egan의 사이트](https://www.gregegan.net/)에 있는 연락처 표현은 너무 난해해서 해독 불가였음 - 예전에 “me at foobar dot com” 같은 표현이 여전히 효과가 있을까 궁금해서 테스트했음 LLM을 이용해 여러 **이메일 난독화 방식**을 풀어보니, CSS나 JS 기반이 아닌 건 대부분 해석 가능했음 그래도 요즘은 스팸 필터가 잘 작동해서 평문 이메일을 공개해도 큰 문제는 없었음 오히려 **서비스 알림 메일**이 더 성가심 - 더 나은 방법은 방문자가 CPU를 조금 써서 **고유 토큰 이메일**을 생성하는 방식임 abuse가 생기면 해당 주소만 폐기하면 됨 클라이언트와 메일 서버가 이런 API를 지원하면 이상적일 것임 - LLM 기반 수집기는 사람보다 **지시문 해석**을 더 잘할 수도 있음 그래서 단순한 regex 봇을 막는 **기초적 난독화**가 여전히 유효하다고 봄 - 관련된 [xkcd 1808](https://xkcd.com/1808/) 만화도 있음 - 올해 초 C로 **Brainfuck 인터프리터**를 만들다가 이메일 난독화에 써봤음 각 이메일을 Brainfuck 프로그램으로 저장하고, JS 인터프리터가 실행해 평문을 표시함 JS는 외부 도메인에서 로드되고, referer 검증 후 실제 코드를 전송함 물론 JS를 실행하는 수집기엔 무용지물이지만, **창의적인 난독화 실험**으로 흥미로웠음 - 이 방식은 단순히 JS에서 **XOR 암호화**하는 것과 어떤 차이가 있는지 궁금함 - 만약 수집기가 **스크린샷을 LLM이나 OCR에 입력**한다면 이 방법은 무력화될 듯함 - 이 글은 이메일 수집기를 **더 똑똑하게 만드는 가이드**처럼 보이기도 함 - 맞지만, JS나 CSS 실행, SVG 렌더링 등은 여전히 **비용이 큰 작업**이라 대규모 봇에게는 부담스러움