명령 한 줄로 로컬 서버를 외부에 여는 Cloudflare Quick Tunnels

출처: Cloudflare (제품 페이지 및 공식 문서)
원문: https://try.cloudflare.com/
작성자: 팔복소프트-김팔복

한눈에 보기

• cloudflared tunnel --url http://localhost:8000 한 줄이면 로컬에서 돌고 있는 서버가 공개 URL로 열린다.
• 계정 생성, DNS 설정, 설정 파일이 전부 필요 없다.
• 접속 주소는 trycloudflare.com 하위의 무작위 서브도메인으로 그때그때 생성된다.
• HTTPS가 자동으로 붙고, 내 PC의 포트를 외부에 직접 열지 않는다.
• 동시 처리 중인 요청이 200개를 넘으면 429를 반환하고, Server-Sent Events(SSE)는 아예 지원하지 않는다.
• Cloudflare는 SLA나 가동률을 보장하지 않으며, 테스트·개발 용도로만 쓰라고 명시한다.
• 즉 "데모와 웹훅 테스트용 임시 통로"이지, 운영 배포 수단이 아니다.

배경: 이게 왜 필요한 기능인가

로컬에서 개발 중인 서버를 외부에 잠깐 보여줘야 하는 상황은 생각보다 자주 생긴다. 결제사나 메신저 플랫폼의 웹훅(webhook)은 공인 인터넷 주소로만 콜백을 보내는데, 개발 PC는 사내망이나 공유기 뒤에 있어 그 주소가 없다. 기획자에게 작업 중인 화면을 보여주려고 브랜치를 스테이징 서버에 올리는 것도 번거롭다.

전통적인 해법은 공유기 포트포워딩이나 점프 서버 SSH 터널이었는데, 둘 다 네트워크 권한이 있어야 하고 HTTPS 인증서를 따로 챙겨야 한다. Quick Tunnels는 이 과정을 CLI 한 줄로 없앤 것이다.

어떻게 동작하나

cloudflared를 설치하고(구버전이라면 2020.5.1 이상으로 업데이트) 로컬 웹 서버를 띄운 뒤 터널 명령을 실행하면, cloudflared가 Cloudflare 네트워크에 붙으면서 무작위 서브도메인을 만들어 터미널에 출력한다. 그 주소로 들어온 트래픽이 Cloudflare 네트워크를 거쳐 localhost의 서버로 프록시된다.

# 1) 로컬 서버를 먼저 띄운다 (포트는 자유)
python3 -m http.server 8000
 
# 2) 다른 터미널에서 터널을 연다
cloudflared tunnel --url http://localhost:8000

연결은 내 PC에서 밖으로 나가는(outbound) 방향이라 방화벽에 인바운드 구멍을 뚫을 필요가 없다. 인증서 발급과 라우팅, DDoS 방어는 Cloudflare가 처리한다.

주의할 함정이 하나 있다. .cloudflared 디렉터리에 config.yaml이 있으면 Quick Tunnel이 동작하지 않는다. 이미 정식 터널을 설정해 둔 PC라면 이 파일을 잠시 다른 이름으로 바꿔야 한다. 예전에 Cloudflare Tunnel을 써본 적 있는 개발자가 가장 먼저 부딪히는 지점이다.

정식 Cloudflare Tunnel과 무엇이 다른가

표에서 실무적으로 가장 아픈 칸은 SSE다. Quick Tunnels는 Server-Sent Events를 지원하지 않는다. 요즘 LLM 응답 스트리밍은 대부분 SSE 기반이라, 챗봇이나 AI 기능을 로컬에서 띄워 데모하려는 순간 이 통로는 선택지에서 빠진다.

"왜 무료냐"에 대한 답도 그냥 홍보 문구가 아니라 읽어둘 가치가 있다.

무료 터널에서 Cloudflare Tunnel의 신규 기능과 개선 사항을 먼저 테스트할 계획입니다. 운영 사이트 배포용이 아니라 테스트·개발용입니다.
— Cloudflare Quick Tunnels 공식 문서

무료 터널이 신기능의 사실상 테스트베드라는 뜻이다. 어느 날 갑자기 동작이 달라져도 항의할 근거가 없다.

팔복소프트 관점

• 국내에서 가장 잘 맞는 자리는 웹훅 테스트다. 포트원·토스페이먼츠 결제 콜백, 카카오 비즈니스 채널 콜백, GitHub·Slack 웹훅처럼 외부에서 내 PC로 들어와야 하는 흐름을 개발 단계에서 확인할 때 가장 값어치가 있다. 사내 스테이징 서버를 잡고 브랜치를 올려 확인하던 루프를 통째로 없앨 수 있다.
• 반대로 URL이 매번 바뀌는 건 생각보다 큰 비용이다. 결제사나 메신저 플랫폼 콘솔에 콜백 URL을 등록해야 하는 구조라면, 터널을 재시작할 때마다 관리 콘솔에 다시 들어가 주소를 갈아끼워야 한다. 팀에서 상시로 쓸 거라면 계정을 만들고 정식 터널로 고정 서브도메인을 파는 편이 결국 싸게 먹힌다. Quick Tunnel은 "오늘 하루 쓰고 버릴 통로"로 볼 때 가장 잘 맞는다.
• ngrok을 쓰던 팀이라면 비교할 만하다. 계정 없이 시작할 수 있다는 점과 Cloudflare 엣지를 그대로 탄다는 점이 차별점이고, 대신 SSE 미지원과 200 동시 요청 제한이 값이다. 부하 테스트나 실시간 스트리밍 데모에는 처음부터 맞지 않는 도구라고 보면 된다.
• 보안 검토 없이 사내에서 쓰면 사고가 난다. 생성된 주소는 추측하기 어려울 뿐 인증이 붙어 있지 않은 공개 URL이다. 주소가 공유 채널에 한 번 흘러가면 그 시점부터 누구나 접근할 수 있다. 실제 고객 데이터가 담긴 로컬 DB에 붙은 서버를 그대로 열어두는 일은 피해야 하고, 금융·공공 SI처럼 망분리와 반출 규정이 있는 환경에서는 도구 사용 자체가 규정 위반이 될 수 있다. 도입 전에 보안 담당자 확인은 받는 게 맞다.
• 조직 프록시에서 trycloudflare.com이 차단돼 있을 가능성도 미리 확인하자. 팀원에게 링크를 공유했는데 아무도 못 여는 상황은 사내망에서 드물지 않다.
• 개인적으로는 "설치형 도구 없이 오늘 당장 시연 링크가 필요할 때"라는 딱 한 가지 용도에 한해 기본값으로 삼을 만하다고 본다. 그 이상 굴리려고 하면 제약이 하나씩 걸린다.

정리

Quick Tunnels는 새로 나온 기능이 아니라, 오래전부터 있던 무료 터널 기능을 Cloudflare가 전면에 다시 배치한 것이다. 기억할 건 세 가지다. 계정 없이 한 줄로 공개 URL이 생긴다는 것, 200 동시 요청과 SSE 미지원이라는 선이 분명하다는 것, 그리고 Cloudflare 스스로 운영용이 아니라고 못 박았다는 것. 웹훅 테스트와 짧은 시연에는 지금 바로 써도 되고, 팀 상시 인프라로 올리려면 그때는 계정을 만들어 정식 터널로 넘어가는 게 맞다.

• Cloudflare
• Tunnel
• cloudflared
• 로컬개발
• 웹훅