클라우드플레어 퀵 터널 --allowed-mail 사용법

클라우드플레어(Cloudflare) **퀵 터널(Quick Tunnel)**은 cloudflared 명령 한 줄로 내 컴퓨터의 로컬 서버를 임의의 trycloudflare.com 주소로 인터넷에 여는 기능이다. 계정도 도메인도 필요 없다. 대신 링크만 알면 누구나 들어올 수 있었는데, 클라우드플레어가 10월 2일 공식 블로그에서 이 빈틈을 메우는 **보호된 퀵 터널(Protected Quick Tunnels)**을 발표했다. cloudflared 2026.9.3부터 --allowed-mail 옵션을 붙이면 내가 지정한 이메일 주소·도메인만 들어올 수 있고, 방문자는 메일로 받은 일회용 PIN으로 본인임을 증명한다. 터널을 연 사람도, 들어오는 사람도 클라우드플레어 계정이 필요 없다는 점은 그대로다.

퀵 터널, 원래는 어떤 물건이었나

퀵 터널은 2021년에 나왔다. 로컬에서 띄운 개발 서버를 남에게 잠깐 보여 주고 싶을 때 쓰라는 용도다. 공식 문서도 "테스트와 개발용"이라고 못 박고, 운영 트래픽에는 정식 Cloudflare Tunnel을 만들라고 안내한다.

쓰는 법은 단순하다. cloudflared tunnel --url http://localhost:8080을 실행하면 cloudflared가 임의의 하위 도메인이 붙은 trycloudflare.com 주소를 출력하고, 그 주소로 들어온 요청이 내 로컬 서버까지 전달된다. 프로세스를 끄면 주소도 죽는다. 공유기 포트를 열 필요도 없다.

요즘 이 기능이 다시 주목받는 이유는 코딩 에이전트다. 클라우드플레어 블로그는 에이전트가 기능을 다 만들고 나서 "휴대폰으로 확인해 보라"며 스스로 퀵 터널을 열어 링크를 건네는 장면을 예로 들고, 에이전트가 쓰기 시작한 뒤로 사용량이 급격히 늘었다고 밝혔다. 가입 절차가 없으니 에이전트가 중간에 막힐 곳도 없다. 9월 18일에는 퀵 터널 문서 링크가 해커뉴스 1위에 올라 800점 넘게 받았다고 한다. 클라우드플레어는 이번 발표가 그 스레드에 달린 질문 하나에 대한 답이라고 소개했다 — 누군가의 에이전트가 민감한 작업물을 세상에 공개해 버리는 건 시간문제 아니냐는 것.

새로 생긴 건 그래서 '누가 들어올 수 있는가'를 정하는 장치다. 여기서 두 개념을 구분해 두면 설계가 잘 보인다. **인증(authentication)**은 방문자가 누구인지 확인하는 단계이고, **인가(authorization)**는 그 사람을 들여보낼지 정하는 단계다. 보호된 퀵 터널에서 인증은 클라우드플레어 액세스(Cloudflare Access)가 맡고, 인가는 내 컴퓨터에서 돌고 있는 cloudflared가 직접 한다.

--allowed-mail, 어떻게 쓰나

먼저 내 cloudflared에 옵션이 있는지부터 볼 차례다. 2026년 10월 9일, macOS 26.4.1(Apple Silicon)에 Homebrew로 설치된 cloudflared에서 cloudflared --version과 cloudflared tunnel --help를 실행한 결과는 이렇다(실제 터널은 열지 않았다).

$ cloudflared --version
cloudflared version 2026.9.3 (built 2026-09-24T15:31:10Z)

$ cloudflared tunnel --help | grep allowed-mail
   --allowed-mail value    Email addresses or wildcard domains allowed to access a protected Quick Tunnel. May be repeated or comma-separated.  (accepts multiple inputs)

도움말 설명 그대로, 주소를 반복해서 넘겨도 되고 쉼표로 묶어도 된다. 2026.9.3보다 낮은 버전이면 이 줄이 없으니 업데이트가 먼저다.

로컬 서버를 띄운다(예: http://localhost:8080).
허용할 주소를 붙여 터널을 연다.

# 한 명만
cloudflared tunnel --url http://localhost:8080 --allowed-mail [email protected]

# 여러 명 + 회사 도메인 전체
cloudflared tunnel --url http://localhost:8080 \
  --allowed-mail [email protected] \
  --allowed-mail [email protected] \
  --allowed-mail '*@example.com'

# 쉼표로 묶기
cloudflared tunnel --url http://localhost:8080 \
  --allowed-mail '[email protected],[email protected]'

출력된 trycloudflare.com 주소를 상대에게 보낸다.
상대는 주소를 열고 이메일을 입력한 뒤, 메일로 온 일회용 PIN을 넣으면 들어온다.

*@example.com 같은 와일드카드는 따옴표로 감싸야 한다. 셸이 *를 파일 이름으로 펼쳐 버리는 걸 막으려는 것으로, 문서에도 같은 주의가 적혀 있다. --allowed-mail을 빼면 예전과 똑같은 공개 터널이 된다.

허용 목록을 바꾸는 명령은 따로 없다. cloudflared를 끄고 새 터널을 여는 게 유일한 방법이고, 프로세스가 끝나는 순간 모든 사람의 접근도 같이 끝난다. 새 터널을 열면 주소도 바뀌니 링크를 다시 보내야 한다.

워커스(Workers)로 개발한다면 npx wrangler tunnel quick-start http://localhost:8080 --allowed-mail [email protected]으로도 같은 터널을 열 수 있다. 블로그는 "최신 wrangler"라고만 적었을 뿐 몇 버전부터인지는 밝히지 않았다.

방문자 한 명이 들어오기까지

클라우드플레어 블로그가 공개한 흐름을 순서대로 옮기면 이렇다.

세션 없이 들어온 요청을 cloudflared가 login.trycloudflare.com으로 돌려보낸다. 이때 그 브라우저에 묶인 일회용 상태값이 같이 가는데, 유효 시간은 10분이다.
클라우드플레어 액세스가 방문자 메일로 일회용 PIN을 보내고 확인한다.
워커스 위에서 도는 작은 인증 중개 서비스(broker)가 터널 주소와 상태값에 묶인 짧은 수명의 서명된 확인서를 돌려준다. 폼 POST로 전달돼 URL이나 브라우저 기록에 남지 않는다.
cloudflared가 확인서를 검증하고, 이메일을 내가 입력한 규칙과 대조한다. 맞으면 로컬 세션을 만들고, 아니면 목록에 대해 아무것도 드러내지 않는 일반 응답을 보낸다.

한 번 통과하면 최대 4시간 동안 그 세션으로 드나든다. 액세스 로그인이 더 일찍 끝나거나 내가 cloudflared를 끄면 그 전에 끝난다.

눈여겨볼 부분은 허용 목록이 어디에 있느냐다. 중개 서비스는 터널 정책도, 방문자 세션도 저장하지 않고 터널의 허용 목록을 보지도 않는다. 클라우드플레어가 아는 건 "이 터널은 이메일 인증을 요구한다"는 사실까지다. 다만 방문자가 PIN을 받으려고 입력한 이메일은 당연히 액세스를 거친다 — 비밀로 남는 건 '내가 누구를 초대했는가' 쪽이다.

실패했을 때의 동작도 보수적으로 짜여 있다. 서비스가 인증 모드를 확인해 주지 않으면 cloudflared는 공개 주소를 내주는 대신 아예 시작을 거부하고, 검사 중 하나라도 실패한 요청은 로컬 서비스에 닿지 않는다. 보호 모드가 공개 모드로 슬쩍 바뀌는 일은 없다고 블로그는 설명한다. 인증 정보는 cloudflared가 떼어 내고 전달하므로 내 앱에 로그인 기능을 따로 만들 필요도 없다.

넘을 수 없는 선 — 공식 문서의 제한 사항

퀵 터널 문서에 적힌 제한은 다섯 가지다.

가동 시간 보장이 없다.
터널 하나당 동시에 처리 중인 요청은 200개까지다. 넘치면 429가 돌아간다.
서버 전송 이벤트(SSE)를 지원하지 않는다.
이메일 인증은 브라우저로 직접 들어오는 사람만 통과할 수 있다. 비대화형 클라이언트는 지원하지 않는다.
터널을 만들 때마다 주소가 바뀐다.

실무에서 가장 크게 걸리는 건 네 번째다. 블로그는 퀵 터널의 쓰임새로 "노트북에서 돌리는 MCP 서버를 호스팅된 AI 어시스턴트가 부르게 하는 경우"를 들었는데, 그런 호출은 사람이 브라우저로 PIN을 넣는 구조가 아니다. 문서 제한대로라면 그 용도에는 이메일 보호를 걸 수 없다. 웹훅 수신 테스트나 curl로 때리는 API 확인도 마찬가지다. SSE 미지원도 의외로 자주 부딪힌다. 스트리밍 응답을 SSE로 흘리는 AI 채팅 화면을 데모하려면 다른 방법을 찾아야 한다.

고정 주소나 신원 공급자(IdP) 그룹 같은 세밀한 규칙이 필요하면 정식 Cloudflare Tunnel에 액세스를 붙이라는 게 클라우드플레어의 안내다.

trycloudflare가 보안 보고서에 단골로 나오는 이유

계정 없이 몇 초 만에 HTTPS 주소를 만들 수 있다는 장점은 공격자에게도 똑같이 쓸모가 있다. 보안 업체 프루프포인트(Proofpoint)는 2024년 7월 보고서에서 TryCloudflare 터널을 악용해 원격 접속 트로이목마(RAT)를 퍼뜨리는 범죄 활동을 추적 중이라고 밝혔다. 2024년 2월에 처음 관측됐고 5~7월에 활동이 늘었는데, 송장·세금 같은 업무 메일로 유인해 Xworm, AsyncRAT, VenomRAT, GuLoader, Remcos 같은 악성코드를 깔게 하는 수법이었다. 캠페인 규모는 메일 수백 통에서 수만 통, 메일을 받은 조직은 수십 곳에서 수천 곳까지였다고 한다.

2025년 6월에는 시큐로닉스(Securonix)가 'SERPENTINE#CLOUD'라는 캠페인을 분석하면서 trycloudflare 하위 도메인에서 WebDAV로 악성 스크립트를 내려받는 과정을 공개했다. 이 보고서가 꼽은 이유가 흥미롭다. 도메인 등록이나 서버 임대가 필요 없어 차단과 추적이 어렵고, trycloudflare가 정상적인 개발·테스트용이라 많은 조직이 이 트래픽을 따로 막거나 들여다보지 않는다는 것이다.

이번 기능은 이 문제와는 결이 다르다. --allowed-mail은 내가 연 터널에 누가 들어올지를 정하는 장치일 뿐, 악성 터널이 만들어지는 것 자체를 막지는 않는다. 회사 보안 담당자 입장에서는 trycloudflare 트래픽을 어떻게 볼지가 여전히 따로 정할 문제로 남는다.

cloudflared 자체의 취약점 이력도 찾아봤다. 깃허브 보안 권고(GitHub Security Advisories)에 올라온 건 두 건이다. 2020.8.1 미만 버전의 로컬 권한 상승(CVE-2020-24356, 중간 등급)과 2023년 3월 공개된 CVE-2023-1314(높음 등급)인데, 후자는 32비트 윈도용 설치 프로그램(2023.3.0 이하)의 문제로 cloudflared 클라이언트 자체는 영향이 없다고 NVD에 적혀 있다. 이번에 확인한 2026.9.3은 두 범위 모두에서 한참 떨어진 버전이다.

데모와 로컬 공유에 쓴다면

개인적으로 가장 먼저 해 둘 일은 에이전트 지시 파일에 한 줄을 넣는 것이다. 클라우드플레어가 블로그에서 직접 권하는 방법이기도 하다.

When you start a Quick Tunnel, always add --allowed-mail [email protected].

AGENTS.md나 CLAUDE.md처럼 에이전트가 읽는 파일에 넣어 두면, 에이전트가 미리보기 링크를 만들 때마다 나만 들어갈 수 있게 된다. 문제는 에이전트가 지시를 늘 따르지는 않는다는 점이다. 블로그도 그 점을 인정하면서, cloudflared가 이메일 인증 사용 여부와 규칙 개수를 출력하니(주소 자체는 찍지 않는다) 실행 로그를 확인하라고 안내한다. 에이전트가 터널을 열었다는 말이 나오면 로그 한 줄을 보는 습관이 생각보다 중요하다.

상황별로 정리하면 이렇다.

휴대폰으로 내 화면 확인 — 내 이메일 하나만 허용하면 끝이다.
클라이언트·팀원 데모 — 회사 도메인을 '*@회사도메인'으로 열면 개인 주소를 일일이 모으지 않아도 된다. 외부 협력사 한두 명은 주소를 따로 추가한다.
웹훅·MCP·API 연결 테스트 — 비대화형 클라이언트라 이메일 보호가 통하지 않는다. 공개 터널로 잠깐 열고 바로 닫거나, 정식 터널과 액세스 쪽으로 가는 게 맞다.
사용자가 꽤 몰리는 시연 — 동시 요청 200개 제한과 가동 보장 없음을 감안하면 퀵 터널을 고를 자리가 아니다.

하나 더. cloudflared의 --loglevel debug는 요청·응답 헤더를 전부 로그에 남긴다고 도움말에 경고가 붙어 있다. 문제를 추적하려고 디버그 로그를 켠 채 터널을 공유하면 그 로그가 새로운 유출 지점이 된다. 반대로 에이전트가 터널 주소를 기계적으로 읽어야 한다면 --output json으로 로그를 JSON 줄로 받는 쪽이 깔끔하다.

이메일 보호도 퀵 터널과 마찬가지로 무료다. 결국 바뀐 건 옵션 하나지만, "링크만 알면 누구나"였던 기본 전제가 "내가 고른 사람만"으로 바뀐다는 점에서 에이전트에게 터널을 맡기던 사람들에겐 체감이 꽤 큰 변화다.

클라우드플레어 퀵 터널(trycloudflare)에 이메일 인증 — cloudflared --allowed-mail 사용법과 제한, 악용 이력