Cloudflare Tunnel 후기: 포트포워딩 없이 개발 서버를 안전하게 열어보니

Cloudflare Tunnel은 로컬 서버나 사내 서비스를 외부에서 접근 가능하게 만들 때 꽤 편한 선택지다. 우리 회사도 아직은 공유기에서 포트포워딩을 해서 쓰는 경우가 있고, 최근 Microsoft Teams 개발을 할 때는 Microsoft가 지원하는 Dev Tunnels 방식으로 로컬 봇 서버를 열어본 적이 있다. 둘 다 당장 문제를 해결해주지만, 개발 서버나 내부 도구를 자주 보여줘야 하는 상황이면 방식별 장단점이 꽤 다르게 느껴진다.

내가 Cloudflare Tunnel을 좋게 본 이유는 단순하다. 서버가 외부에서 직접 들어오는 연결을 받는 구조가 아니라, cloudflared가 Cloudflare 쪽으로 outbound 연결을 만들고 그 통로로 요청이 들어온다. 공인 IP를 노출하지 않아도 되고, 공유기 설정을 바꾸지 않아도 된다. 개발 카테고리에 적어두기 좋은 주제라고 생각한 것도 이 지점 때문이다.

연관 글

• 🔗 Docker 개념과 설치 방법: 컨테이너 기초부터 Ubuntu 설치까지
• 🔗 Grafana Loki 최신 가이드: Docker Compose로 로그 수집 시스템 구축하기

요약

Cloudflare Tunnel은 cloudflared라는 클라이언트를 통해 내 서버와 Cloudflare 네트워크 사이에 터널을 만들고, 외부 사용자는 Cloudflare를 통해 내 서비스에 접근하게 하는 방식이다. 포트포워딩을 열지 않아도 되고, 도메인과 연결하면 고정된 URL로 개발 서버나 내부 도구를 공유할 수 있다. Microsoft Teams 개발에서 쓰는 Dev Tunnels는 Teams/봇 로컬 디버깅에는 편하지만, 회사 공통 터널 운영이나 도메인 기반 접근 제어까지 생각하면 Cloudflare Tunnel 쪽이 더 운영형에 가깝다.

목차

Cloudflare Tunnel이 뭔가

Cloudflare 공식 문서의 설명을 줄이면, Cloudflare Tunnel은 공개 IP 없이도 내 리소스를 Cloudflare에 안전하게 연결하는 방법이다. 핵심은 cloudflared다. 이 작은 데몬이 내 서버에서 실행되면서 Cloudflare 글로벌 네트워크로 outbound 연결을 만든다.

그래서 외부 요청 흐름은 대략 이렇게 된다.

사용자 → Cloudflare → Tunnel → 내 로컬/서버 서비스

내 서버 입장에서는 외부에서 직접 TCP 연결이 들어오는 것이 아니라, 이미 열어둔 터널을 통해 요청을 받는다. HTTP 웹 서버뿐 아니라 SSH, RDP, private network 접근 같은 Zero Trust 시나리오에도 사용할 수 있다. 다만 이 글에서는 개발자가 가장 자주 만나는 “로컬 웹 서비스나 내부 웹 도구를 도메인으로 열어보기” 관점으로 정리한다.

기존 방식과 비교

Cloudflare Tunnel을 이해하려면 기존 방식과 비교하는 게 빠르다.

방식	장점	아쉬운 점	어울리는 상황
포트포워딩	추가 서비스 없이 직접 연결 가능	공유기/방화벽 설정 필요, origin IP 노출 가능	개인 서버를 직접 운영할 때
VPN	내부망 전체 접근에 강함	사용자 설정이 번거롭고 외부 공유에는 무거움	사내망 접근, 운영자용 접속
ngrok류 터널	빠른 임시 공유가 쉬움	무료/유료 정책, 고정 도메인, 운영 지속성 확인 필요	짧은 데모, 웹훅 테스트
Microsoft Dev Tunnels	Teams/봇 로컬 디버깅과 Microsoft 개발 도구 흐름에 잘 맞음	범용 운영 도메인·회사 공통 접근 제어 관점에서는 제한적	Teams 앱, Bot Framework, 로컬 디버깅
Cloudflare Tunnel	포트포워딩 없이 도메인 연결, Cloudflare 보안 기능과 연동	Cloudflare 계정·도메인·DNS 이해 필요	개발 서버 공유, 내부 도구 공개, Zero Trust 접근 제어

내 기준에서 Cloudflare Tunnel은 “잠깐 보여주기”와 “계속 운영하기” 사이에 있다. ngrok처럼 빨리 열 수 있으면서도, 도메인·DNS·Access 정책까지 묶으면 사내 도구나 개인 서버 운영에도 꽤 안정적으로 쓸 수 있다.

Microsoft Dev Tunnels와 비교

최근 Microsoft Teams 개발을 하면서는 Microsoft가 지원하는 Dev Tunnels를 써본 적이 있다. Teams 앱이나 봇을 로컬에서 디버깅할 때 외부 HTTPS endpoint가 필요하고, Microsoft 문서에서도 devtunnel host -p 3978 --protocol http --allow-anonymous 같은 흐름을 안내한다. Teams 개발 맥락에서는 이게 꽤 자연스럽다. 로컬 봇 서버를 띄우고, Teams 쪽에서 접근할 수 있는 URL을 만들어주기 때문이다.

다만 내 느낌에는 Microsoft Dev Tunnels는 “Microsoft 개발 도구 안에서 로컬 디버깅을 편하게 해주는 도구”에 가깝다. Teams, Bot Framework, Visual Studio/Agents Toolkit 같은 흐름 안에서는 장점이 크다. 반대로 회사의 여러 내부 도구, 별도 도메인, 접근 정책, 장기 운영까지 생각하면 Cloudflare Tunnel이 더 범용적이다.

비교 항목	Microsoft Dev Tunnels	Cloudflare Tunnel
주 용도	로컬 개발/디버깅, 특히 Microsoft 개발 흐름	로컬·서버 서비스를 Cloudflare 네트워크에 연결
Teams 개발	매우 잘 맞음	가능은 하지만 Teams 전용 흐름은 아님
도메인 운영	devtunnels.ms 기반 임시/개발 URL 중심	내 도메인과 DNS route 연결이 자연스러움
접근 제어	터널 옵션과 Microsoft 계정 흐름 중심	Cloudflare Access, SSO, 이메일, 정책과 결합 가능
장기 운영	개발 터널 성격이 강함	서비스 등록, 다중 connector, Zero Trust 구성이 가능
내가 보는 위치	개발 중 임시 외부 노출	개발 공유와 내부 도구 운영 사이

그래서 둘 중 하나만 정답이라고 보기는 어렵다. Teams 앱을 만들고 있다면 Microsoft Dev Tunnels가 빠르다. 이미 그 생태계 안에 있기 때문이다. 하지만 회사 내부 도구를 도메인으로 묶고, 권한을 붙이고, 포트포워딩을 줄이는 방향이라면 Cloudflare Tunnel을 별도로 볼 만하다.

실무에서는 어떤 방식을 많이 쓰나

실무에서는 여전히 포트포워딩, VPN, 임시 터널, 클라우드 로드밸런서가 섞여 쓰인다. 오래된 사내 환경에서는 공유기나 방화벽에서 포트포워딩을 열어두는 방식이 아직 남아 있다. 설정이 단순하고 익숙하기 때문이다. 하지만 보안 관점에서는 열어둔 포트와 origin IP를 계속 관리해야 한다는 부담이 있다.

개발 단계에서는 ngrok, Microsoft Dev Tunnels 같은 임시 터널 도구가 많이 쓰인다. 웹훅 테스트, Teams 봇 디버깅, 모바일 앱 콜백 테스트처럼 “지금 로컬을 잠깐 외부에서 봐야 하는” 상황에 잘 맞는다.

운영이나 준운영에 가까워질수록 선택 기준이 달라진다. URL이 자주 바뀌면 곤란하고, 누가 접근할 수 있는지 정책으로 관리해야 하며, 서버 재부팅 후에도 살아나야 한다. 이때는 Cloudflare Tunnel, VPN, 클라우드 네이티브 로드밸런서, Zero Trust 접근 제어를 같이 검토하는 편이 맞다. Cloudflare Tunnel은 그중에서 “공개 포트를 줄이면서 웹 기반 내부 도구를 노출하는” 쪽에 강점이 있다.

기본 사용 흐름

공식 문서 기준으로 로컬 관리형 터널의 기본 흐름은 아래와 같다. 실제 운영에서는 Cloudflare 대시보드에서 만드는 remote-managed tunnel도 많이 쓰지만, 개념을 이해하려면 CLI 흐름이 가장 직관적이다.

1. Cloudflare에 도메인 연결

먼저 Cloudflare 계정에 사이트를 추가하고, 도메인의 nameserver를 Cloudflare로 바꿔야 한다. 이 부분이 되어 있어야 dev.example.com 같은 호스트명을 터널에 연결하기 쉽다.

2. cloudflared 설치

macOS라면 Homebrew로 설치할 수 있다.

brew install cloudflared

Ubuntu/Debian은 Cloudflare 패키지 저장소를 추가해 설치하는 방식이 공식 문서에 정리되어 있다. 운영 서버라면 배포판과 CPU 아키텍처에 맞는 설치 방법을 확인하는 게 좋다.

3. 로그인과 터널 생성

cloudflared tunnel login
cloudflared tunnel create my-dev-tunnel
cloudflared tunnel list

로그인하면 Cloudflare 계정 인증이 진행되고, 터널을 만들면 UUID와 credentials 파일이 생성된다. 여기서부터는 “터널이라는 논리적 통로”가 생긴 상태라고 보면 된다.

4. 로컬 서비스와 호스트명 연결

예를 들어 로컬에서 http://localhost:8000으로 개발 서버가 떠 있다면 config.yml은 이런 식으로 잡을 수 있다.

tunnel: <Tunnel-UUID>
credentials-file: /Users/me/.cloudflared/<Tunnel-UUID>.json

ingress:
  - hostname: dev.example.com
    service: http://localhost:8000
  - service: http_status:404

그리고 DNS route를 연결한다.

cloudflared tunnel route dns my-dev-tunnel dev.example.com
cloudflared tunnel run my-dev-tunnel

이러면 dev.example.com으로 들어온 요청이 Cloudflare를 거쳐 내 로컬 localhost:8000으로 전달된다.

5. 계속 쓸 거면 서비스로 등록

잠깐 테스트라면 터미널에서 cloudflared tunnel run으로 충분하다. 하지만 서버에서 계속 돌릴 거라면 system service나 macOS launch agent로 등록하는 게 낫다. 공식 문서도 대부분의 경우 서비스 실행을 권장한다. 서버 재부팅 후에도 터널이 살아나야 운영이 편하기 때문이다.

실제로 써보며 좋았던 점

제일 좋은 점은 공유기나 방화벽을 건드리지 않아도 된다는 것이다. 로컬에서 만든 작은 웹 서비스, 관리자 페이지, 테스트용 API를 외부에서 확인해야 할 때 매번 네트워크 설정을 만지는 건 피곤하다. Cloudflare Tunnel은 그 부분을 많이 줄여준다.

두 번째는 도메인으로 고정해두기 쉽다는 점이다. 테스트 URL이 매번 바뀌면 문서나 웹훅 설정을 다시 고쳐야 한다. Cloudflare Tunnel은 dev.example.com처럼 익숙한 주소로 붙일 수 있어서, 테스트하는 사람에게도 설명하기 쉽다.

세 번째는 Cloudflare Access와 묶을 수 있다는 점이다. 그냥 공개 URL로 열어두는 것이 부담스럽다면 이메일, SSO, OTP 같은 접근 제어를 붙일 수 있다. 개인 개발 서버를 잠깐 여는 수준에서는 과해 보일 수 있지만, 회사 내부 도구라면 이 차이가 꽤 크다.

보안 관점과 베스트 프랙티스

Cloudflare Tunnel을 쓴다고 해서 자동으로 안전해지는 것은 아니다. 포트포워딩보다 나은 출발점이 될 수는 있지만, 결국 어떤 서비스를 누구에게 열었는지가 중요하다.

내가 실무에서 본다면 최소한 아래 기준은 잡고 싶다.

항목	권장 방향	이유
공개 범위	개발 서버라도 기본은 비공개 또는 인증 뒤에 두기	URL을 아는 사람이 접근 가능한 상태를 피하기 위해
접근 제어	Cloudflare Access로 이메일/SSO/OTP 정책 적용	회사 내부 도구는 사용자 단위 통제가 필요함
터널 토큰	credentials 파일과 tunnel token을 시크릿처럼 관리	이 값이 유출되면 의도치 않은 connector가 붙을 수 있음
서비스 계정	운영 서버에서는 개인 계정보다 관리 가능한 계정 사용	퇴사/권한 변경/감사 대응이 쉬움
ingress 규칙	마지막에 http_status:404 같은 catch-all 두기	예상하지 않은 서비스 노출을 줄임
실행 방식	장기 운영은 service/launch agent로 등록	재부팅 후 터널 누락을 줄임
로그 확인	cloudflared 로그와 Access 로그를 같이 보기	접속 실패 원인과 비정상 접근을 추적하기 위해

특히 조심할 부분은 “개발 서버니까 괜찮겠지”라는 생각이다. 개발 서버에도 테스트 계정, 내부 API 응답, 샘플 데이터, 관리자 화면이 섞일 수 있다. Cloudflare Tunnel로 포트를 숨겼더라도, URL이 공개되어 있고 인증이 없다면 결국 외부에 열린 서비스다.

그래서 개인 테스트는 짧게, 회사 내부 도구는 Access 뒤에, 계속 쓰는 터널은 서비스로 등록하고 담당자와 목적을 문서에 남기는 식이 좋다. 터널은 편의를 위한 도구이지만, 편의가 보안의 예외가 되면 안 된다.

처음에는 헷갈렸던 점

처음 헷갈리는 건 “터널을 만들었다”와 “서비스가 외부에서 열린다”가 같은 말이 아니라는 점이다. 터널 생성은 UUID와 credentials를 만드는 단계이고, 실제 호스트명 연결과 ingress 설정은 따로 해야 한다.

또 하나는 DNS다. Cloudflare에 도메인이 연결되어 있지 않거나, 호스트명이 터널로 route되지 않으면 브라우저에서는 당연히 안 열린다. 이때 로컬 서비스 문제인지, cloudflared 문제인지, DNS 문제인지 구분해야 한다.

확인 순서는 보통 이렇게 잡으면 덜 헤맨다.

cloudflared tunnel list
cloudflared tunnel info my-dev-tunnel
cloudflared tunnel run my-dev-tunnel

그리고 로컬 서비스 자체가 먼저 떠 있는지도 확인해야 한다. localhost:8000이 로컬에서 안 열리는데 Cloudflare Tunnel만 붙잡고 있으면 시간이 아깝다.

이런 상황에서 유용하겠다

Cloudflare Tunnel은 특히 이런 상황에서 좋다.

• 로컬 개발 서버를 외부 사람에게 잠깐 보여줘야 할 때
• 웹훅 테스트용 고정 URL이 필요할 때
• Microsoft Dev Tunnels가 Teams 개발에는 맞지만, 회사 공통 도메인/Access 정책까지는 부족하게 느껴질 때
• 공유기 포트포워딩을 열기 싫을 때
• 사내 관리자 도구를 Cloudflare Access 뒤에 두고 싶을 때
• SSH/RDP 같은 내부 접속을 Zero Trust 방식으로 관리하고 싶을 때
• 개인 홈서버나 작은 VPS의 origin IP 노출을 줄이고 싶을 때

나는 이 도구를 “개발자가 네트워크 설정 때문에 흐름이 끊기는 순간”을 줄여주는 도구로 본다. 엄청 새로운 개념이라기보다는, 기존에 귀찮았던 공개·접속·보안 설정을 Cloudflare 쪽으로 잘 모아둔 느낌이다.

결론

Cloudflare Tunnel은 포트포워딩 없이 개발 서버나 내부 서비스를 외부에 노출하고 싶을 때 꽤 현실적인 선택지다. 우리 회사처럼 아직 공유기 포트포워딩이 남아 있고, 특정 개발에서는 Microsoft Dev Tunnels 같은 도구를 쓰는 환경이라면 더 비교해볼 만하다. cloudflared가 outbound 연결을 만들기 때문에 origin IP를 직접 드러내지 않아도 되고, 도메인과 Access 정책을 붙이면 개발용 공유부터 사내 도구 접근까지 확장하기 쉽다.

물론 모든 상황의 정답은 아니다. Cloudflare 의존성이 생기고, 도메인/DNS/Zero Trust 개념을 조금은 알아야 한다. 그래도 한 번 구조를 이해해두면 “이거 잠깐 외부에서 봐야 하는데?”라는 상황에서 훨씬 편하다.

개발 환경에서는 작은 편의가 반복되면 꽤 큰 차이가 난다. Cloudflare Tunnel은 딱 그런 종류의 도구다. 처음 설정은 조금 낯설지만, 포트포워딩을 열지 않고도 안정적인 URL로 서비스를 보여줄 수 있다는 점만으로도 충분히 써볼 만하다.

참고 자료

• 🔗 Cloudflare Tunnel 공식 문서
• 🔗 Create a locally-managed tunnel
• 🔗 Configure a tunnel
• 🔗 Run as a service
• 🔗 cloudflare/cloudflared GitHub 저장소
• 🔗 Microsoft Dev Tunnels 개요
• 🔗 Microsoft Dev Tunnels 보안 문서
• 🔗 Teams 앱 로컬 디버깅 문서