설정 파일에 발신자 주소를 적어야 할 때가 있다. 답장을 받을 생각이 없는 알림 메일이라면 대충 noreply@로 시작하는 주소를 넣는다. 도메인 자리에는 회사 도메인 대신 noreply.net 같은 걸 적기도 한다. 어차피 아무도 안 읽는 주소니까.

문제는 그 도메인이 진짜로 존재한다는 것이다. 그리고 살 수 있다.

2026년 8월 10일, 매트 버지스가 WIRED에 보안 연구자 코리 솔로비에비츠의 사례를 썼다. Ars Technica에도 같은 글이 실렸다. 솔로비에비츠는 2020년에 noreply.us를, 2024년에 noreply.net을 샀다. 원래 자기 메일을 걸러 쓰려고 샀다. 어떤 주소로 오든 다 받게 해 두면 서비스마다 다른 주소를 만들어 쓸 수 있으니 프라이버시에 유리하다.

그런데 자기가 만든 적 없는 주소로 남의 메일이 들어오기 시작했다. 2024년 12월 이후 noreply.net 한 곳으로만 401,796통이 도착했다. 하루 평균 699.99통꼴이다. 그는 이렇게 표현했다.

나도 모르게 허니팟을 하나 만들어 버렸다.

40만 통이 한 사람 편지함에 쌓였다

첨부 파일이 붙은 메일만 28,365통이었다. 시청이 만든 부상 보고서, 수리 서비스 주문서, 어느 학교 플랫폼의 계정 개설 안내가 들어 있었다. 테스트용 플랫폼 자격 증명이 특히 많았고 남의 피자 주문 확인 메일까지 왔다. 숫자보다 내용이 문제였다.

첨부 파일이 특히 문제인 건 자동 발송 메일의 구조 때문이다. 본문은 대개 “아래 내용을 확인하세요” 정도로 짧고 실제 내용은 파일에 들어 있다. 사람이 직접 쓴 메일이라면 조심할 만한 자료도, 시스템이 매일 만들어 보내면 누구도 미리 걸러내지 않는다.

보낸 쪽도 한두 군데가 아니다. 발신 주소는 14,000개가 넘었고 이를 도메인 단위로 묶어도 6,200개다. 어느 한 회사가 설정을 잘못해서 벌어진 일이라기엔 범위가 너무 넓다.

연구자가 이 자료를 받은 건 그나마 다행이다. 그는 8월 데프콘 보안 컨퍼런스에서 이 문제를 발표하고 피해 기업들에 개별로 알리고 있다. 같은 도메인을 범죄 조직이나 국가 지원 해킹 그룹이 샀다면 어떻게 됐을까. 회사 이름과 부서, 실명, 회의 시간, 내부 시스템이 보내는 알림의 생김새가 매일 배달된다. 표적형 공격을 준비하는 쪽은 정찰 단계를 통째로 건너뛴다. 솔로비에비츠도 그 도메인이 하필 자기 손에 들어왔다는 사실에 안도한다.

401796통의 수신 메일 중 28365통에 첨부 파일이 있고, 발신 주소는 14000개, 도메인으로 묶으면 6200개라는 것을 단계별로 보여주는 그림
사고를 낸 곳이 6,200개 도메인에 흩어져 있다. 한 회사의 실수가 아니다.

자리 표시자가 진짜 주소가 되는 순간

원인은 단순하다. 누군가 설정 파일에 발신자나 수신자 주소를 적어야 했는데 회사가 실제로 가진 도메인 대신 그럴듯해 보이는 이름을 적었다.

왜 하필 noreply.net이었을까. 답장을 받지 않는 주소를 뜻하는 단어가 noreply이고 도메인 형태로 만들려면 뒤에 뭐라도 붙여야 한다. .com은 오래전에 팔렸을 테니 .net을 붙인다. 예제 코드에서 본 주소를 그대로 옮겨 적기도 한다. 아무도 실재하는 도메인을 적었다고 생각하지 않는다. 자기 머릿속에서는 그냥 “여기는 비워 두는 칸”이라는 뜻이었기 때문이다.

퇴사자 처리 과정에서도 같은 일이 벌어진다. 계정을 지우면 메일 시스템에 남은 주소가 비는데, 이때 빈칸을 채우려고 삭제된사용자@어딘가 형태의 주소를 넣어 두는 경우가 있다. 그 뒤에도 그 사람에게 오던 알림은 계속 그 주소로 흘러간다.

여기에 캐치올 설정이 겹치면 사고가 완성된다. 캐치올은 도메인 앞에 어떤 이름이 붙어 있든 일단 다 받는 설정이다. abc@noreply.net우리회사@noreply.net도 전부 한 편지함으로 들어온다. 도메인 주인은 상대가 무슨 주소를 지어냈는지 미리 알 필요가 없다.

설정 파일에 적힌 자리 표시자 주소가 메일 서버를 거쳐 외부 도메인 주인의 캐치올 편지함으로 도착하는 경로를 보여주는 그림
메일은 사라지지 않는다. 그 도메인을 가진 사람에게 배달된다.

메일은 없어지는 물건이 아니다. 주소에 적힌 도메인을 찾아가고 그 도메인에 주인이 있으면 주인에게 간다. 그게 전부다.

메일 서버가 하는 일도 딱 그만큼이다. 주소에서 @ 뒤를 떼어내 그 도메인의 메일 수신 서버를 찾은 다음 넘긴다. 도메인이 아예 없으면 배달에 실패하고 반송 메일이 돌아오는데, 이 반송이 유일한 경고 신호다. 도메인이 실재하면 반송도 오지 않는다. 발송은 성공으로 기록되고 로그에도 아무 표시가 남지 않는다.

그래서 이런 설정은 몇 년씩 방치된다. 시스템이 정상 동작한다는 사실 자체가 문제를 덮는다.

15달러짜리 도메인, 한 시간 만에 세 곳

같은 기사에 나온 마이크 셰워드의 사례는 더 짧고 선명하다. 전기차 충전 회사 Xeal의 보안 책임자인 그는 올해 초 deleteduser.com을 약 15달러에 샀다. 첫 한 시간 안에 세 개 조직의 메일이 도착했다. 그만큼 많은 회사가 계정을 지우는 대신 이메일 주소만 갈아 끼운다.

셰워드가 받은 메일의 내용은 더 험하다. 실명이 적힌 호텔 예약 확인서, 직원 휴가와 휴직 승인 요청, 영국 정부기관의 화상회의 초대장, 비아그라 주문 내역이 왔다. 사이버 보안 회사와 마이크로소프트 파트너사도 여럿 있었다. 가장 자주 보내오는 곳은 중동 산업 현장에서 작업자가 안전 수칙을 지키는지 영상으로 감시하는 AI 회사였다. 그쪽에서만 CCTV 정지 화면이 수천 장 날아왔다. 몇 주 전에는 샌프란시스코의 어느 회사가 여름 바비큐 파티 초대장을 보냈다. 받는 사람 이름은 “친애하는 삭제된 사용자님”이었다.

셰워드는 4월에 쓴 글에서 자기 처지를 이렇게 정리했다.

나는 인터넷 쓰레기통의 선량한 관리인 노릇을 하고 있다. 하지만 내가 나쁜 관리인이었다면, 얼굴에 던져지는 이 정보가 어떻게 악용될 수 있을지는 상상하기 어렵지 않다.

솔로비에비츠는 여기서 한 발 더 나갔다. 사람들이 자리 표시자로 쓸 법한 도메인 이름 7,136개를 추려 검사해 봤더니, 그중 328개가 캐치올로 열려 있었다. 지금 이 순간에도 누군가는 남의 회사 메일을 받고 있다.

328개 전부가 노리고 산 도메인은 아닐 것이다. 도메인을 사면 메일 서비스를 얹는 김에 캐치올을 켜 두는 사람이 많다. 주소를 하나하나 만들지 않아도 돼서 편하다. 그러다 보면 자기가 뭘 받고 있는지 모르는 채로 몇 년이 지난다. 앞의 두 사례도 원래 그런 편지함을 열어 보면서 시작됐다.

두 사람은 서로 따로 움직였지만 나쁜 사람이 먼저 사기 전에 사 두자는 같은 결론에 닿았다. 그렇게 둘이 합쳐 30개가 넘는 도메인을 확보했다.

이런 도메인은 대체로 싸다. 특별한 기술도, 침입도 필요 없다. 등록비를 내고 메일 서버를 열어 둔 채 기다린다. 공격이라고 부르기엔 하는 일이 없다.

보통 침입은 흔적을 남긴다. 실패한 로그인, 낯선 접속지, 튀는 트래픽 같은 것들이다. 여기엔 그런 게 없다. 상대는 우리 시스템을 건드린 적이 없다. 우리가 매일 자발적으로 보내 주고 있을 뿐이라 침입 탐지 장비가 잡아낼 대상도 아예 없다. 방어하는 쪽에서는 이게 더 곤란하다.

공격자는 애초에 어느 회사를 노릴지 정하지 않았다. 그럴듯한 이름의 도메인을 몇 개 사 두면 어느 회사가 걸릴지 미리 고를 필요도 없다. 이 방식에는 표적을 정하는 단계가 아예 없다.

20년 전에도 있었던 일

이런 사고가 새로운 건 아니다. 거의 20년 전에 보안 기자 브라이언 크렙스가 워싱턴포스트에서 같은 이야기를 썼다. 그때 문제의 도메인은 donotreply.com이었고 기업들이 그리로 보낸 메일이 수백만 통이었다. 이름만 donotreply에서 noreply로 바뀐 채 20년이 지났다.

이 기사를 다룬 해외 커뮤니티 lobste.rs에는 비슷한 경험담이 줄줄이 달렸다. 이름.성@gmail.com 같은 흔한 주소를 가진 사람들이 남의 의료 기록, 항공권, 청구서를 받는다는 이야기다. 어떤 사람은 테슬라 원격 제어 권한 확인 메일을 받았고 어떤 사람은 대학 조교로 등록되는 바람에 시험지 PDF를 받았다.

이 기사를 소개한 GeekNews 댓글에는 서울시 동사무소 통보가 자기 번호로 계속 온다는 국내 사례가 올라왔다. 여러 번 시정을 요청하고 민원을 넣고 정보공개청구까지 해서 겨우 멈췄는데 담당자가 바뀌자 다시 시작됐다고 한다.

받는 쪽이 알려 줘도 잘 안 고쳐진다는 문제도 있다. 잘못 받은 사람은 보낸 조직의 담당자가 누구인지 모른다. 조직 안에는 이런 신고를 받는 창구가 없고 겨우 연결돼서 고쳐도 담당자가 바뀌면 원래 설정이 돌아온다. 문제를 아는 사람은 밖에 있고 고칠 권한은 안에 있는 구조라 정보가 건너오지 못한다.

두 연구자도 같은 벽에 부딪혔다. 조용히 고친 곳도 있지만 답이 없는 곳이 더 많았다. 무엇보다 보내는 곳이 너무 많아서 다 알리는 게 불가능하다. 솔로비에비츠는 이걸 다 처리하려면 이제 본업을 그만둬야 할 지경이라고 했고 그래서 개별 통보 대신 공개 발표를 택했다.

같은 댓글에서 언급된 가장 극단적인 사례는 rentahitman.com이다. 밥 이니스가 2005년에 IT 회사를 차리려고 이 도메인을 샀다. hit는 웹 트래픽 집계 단위이고 man은 팀을 뜻하는, 말장난에 가까운 이름이었다. 회사는 안 됐고 도메인만 남았다.

2008년에 편지함을 열어 보니 청부살인을 의뢰하는 메일이 수백 통 쌓여 있었다. 대부분은 장난으로 보였다. 2010년에 다시 확인했을 때 캐나다에서 온 진지한 의뢰가 하나 있었고 그는 그 내용을 경찰에 넘겼다. 의뢰인은 살인교사로 유죄 판결을 받았다. 그 뒤로 이니스는 10년 동안 스무 건 남짓을 수사기관에 넘겼다. 도메인 하나 잘못 사서 20년째 남의 범죄 의뢰를 접수하고 있다.

그럼 뭘 적어야 하나

가장 간단한 답은 회사가 실제로 가진 도메인을 쓰는 것이다. noreply@우리회사.com처럼 적고 그 주소로 온 메일은 서버에서 버리면 된다. 통제권이 우리 손에 있다는 게 핵심이다.

밖으로 나가면 안 되는 주소가 필요하다면 .invalid가 있다. RFC 2606이 예약해 둔 최상위 도메인이라 누구도 등록할 수 없다. noreply@우리회사.invalid는 어디로도 배달되지 않고 배달될 수도 없다. 같은 문서가 .test, .example, .localhost도 함께 예약해 뒀다.

둘 중 어느 쪽을 고를지는 그 주소가 어떻게 쓰이는지에 달렸다. 사람이 실수로 답장할 여지가 있는 자리라면 회사 도메인이 낫고 답장이 우리 서버로 들어오니 필요하면 열어 볼 수도 있다. 반대로 절대 배달되면 안 되는 자리라면 .invalid가 확실하다. 다만 존재하지 않는 최상위 도메인을 거부하는 검증 로직에 걸릴 수 있으니 넣기 전에 그 값이 어디를 거쳐 가는지는 확인하는 게 좋다.

남이 등록할 수 있는 자리 표시자 도메인과 등록이 불가능하거나 회사가 소유한 도메인을 나란히 비교한 그림
기준은 하나다. 그 도메인을 남이 살 수 있는가.

기억해 둘 기준은 하나다. 내가 소유하지 않은 도메인은 언젠가 다른 사람이 소유한다. 지금 비어 있어도 상관없다. 도메인 등록은 사실상 임대라서 만료되면 누구나 가져갈 수 있다.

지금 쓰고 있는 코드에서는 세 군데를 확인한다. 발신자와 수신자 주소가 하드코딩된 곳, 계정 삭제 로직이 빈 이메일 칸을 채우는 방식, 테스트 환경에서 쓰는 더미 주소가 운영 설정에 섞여 들어갔는지. 이 셋만 훑어도 대부분 걸러진다.

이미 몇 년째 보내고 있었는지 확인하려면 나가는 메일 로그에서 수신 도메인만 뽑아 개수순으로 세어 보면 된다. 우리가 아는 고객사와 협력사 도메인 사이에 아무도 설명하지 못하는 이름이 섞여 있다면 그게 답이다. 조회 한 번이면 끝나는 일인데 지금까지 아무도 안 해 봤기 때문에 남아 있는 문제다.

메일 서버에서도 막을 수 있다. 허용된 수신 도메인 목록을 정해 두고 그 밖으로는 아예 못 나가게 막는다. 사내 알림처럼 나갈 곳이 뻔한 메일에는 특히 잘 맞는다. 코드 어딘가에 이상한 주소가 남아 있어도 서버 문턱에서 걸린다.

정리

이 사건에서 뚫린 것은 아무것도 없다. 취약점도, 침입도, 유출 사고 신고도 없었다. 회사들이 스스로 남의 편지함으로 자료를 보냈을 뿐이다.

기술적으로는 시시한 이야기다. 그래서 더 오래 간다. 심각한 취약점은 발표되고 패치되지만 설정 파일 한 줄에 잘못 적힌 도메인은 아무도 신고하지 않는다. 메일은 매일 정상적으로 발송되고 아무 오류도 나지 않는다.

밑에 깔린 착각은 하나다. 이름만 보고 그 주소가 어떻게 동작할지 정했다. noreply라고 썼으니 답장이 안 올 거라고, deleteduser라고 썼으니 지워진 사용자일 거라고 생각했다. 하지만 이름은 설명이지 설정이 아니다. 실제로 무슨 일이 벌어질지는 그 도메인의 등록 정보와 메일 서버 설정이 정한다. 이건 메일에만 해당하는 이야기도 아니다. 지어낸 이름으로 걸어 둔 콜백 주소나 예전 협력사 도메인을 그대로 둔 웹훅 URL도 같은 자리에 있다. 우리 통제 밖에 있는 이름으로 데이터를 내보내고 있다면 형태만 다를 뿐 같은 문제다.

noreply라고 적었다고 아무도 안 읽는 게 아니다. 읽을 수 있는 사람이 정해질 뿐이고 그게 우리가 아닐 수 있다.