[2단계] Cloudflared란?

 

Cloudflare Tunnel 학습 시리즈 2단계

cloudflared란 무엇일까? 서버와 Cloudflare를 연결하는 핵심 프로그램

 

Cloudflare Tunnel 1단계에서는 가장 중요한 개념 하나를 배웠습니다.

Cloudflare Tunnel은

“내부 서버가 Cloudflare와 먼저 연결 통로를 만들어 놓고, 그 통로를 통해 내부 서비스를 연결하는 기술”

이라고 설명했습니다.

그런데 여기서 궁금한 것이 하나 생깁니다.

도대체 내부 서버와 Cloudflare를 누가 연결하는 걸까요?

그 역할을 담당하는 프로그램이 바로

cloudflared

입니다.

 

📚 앞으로 진행할 Cloudflare Tunnel 학습 시리즈

1단계. Cloudflare Tunnel이란?

• Tunnel의 기본 개념과 사용하는 이유

2단계. cloudflared란?

• 서버에 설치되는 cloudflared의 역할

3단계. Cloudflare Tunnel 통신 구조

• 사용자 → Cloudflare → 서버까지 통신 흐름

4단계. 기존 공인 IP 방식과 Tunnel 방식 비교

• 공인 IP, NAT, 방화벽, Port Forwarding과 차이점

5단계. Cloudflare Tunnel 직접 만들어보기

• 간단한 테스트 환경 구축

6단계. Kubernetes에서 Cloudflare Tunnel 사용하기

• Pod, Service, cloudflared 연결 구조

7단계. Cloudflare Zero Trust와 Tunnel

• 인증받은 사용자만 내부 서비스에 접근시키는 방법

8단계. 방화벽과 네트워크 포트 이해하기

• Inbound, Outbound, QUIC 등의 기본 개념

9단계. Cloudflare Tunnel 이중화와 장애 대응

• Replica와 고가용성 구성 이해

10단계. 운영자가 알아야 할 점검 방법

• 서버와 Kubernetes에서 Tunnel 사용 여부 확인하기

1. cloudflared는 무엇일까?

cloudflared는 Cloudflare가 제공하는 프로그램입니다.

Cloudflare 공식 문서에서는 cloudflared를 Cloudflare Tunnel을 구성하기 위해 설치하는 가벼운 daemon으로 설명하고 있습니다.

쉽게 말하면,

“내부 서버와 Cloudflare 사이에서 Tunnel 연결을 만들어주는 프로그램”

입니다.

내부 서버
↓
cloudflared
↓
Cloudflare

여기서 cloudflared가 없다면 일반적인 Cloudflare Tunnel 연결도 만들어질 수 없습니다.

그래서 Cloudflare Tunnel을 공부할 때 cloudflared는 반드시 알아야 하는 핵심 구성요소입니다.

POINT.

Cloudflare Tunnel = 전체적인 Tunnel 기술

cloudflared = 실제로 Tunnel 연결을 만들어주는 프로그램

이라고 구분하면 쉽습니다.

2. cloudflared 이름부터 이해해보자

이름을 나눠보면 이해가 쉽습니다.

cloudflare + d

입니다.

Linux를 공부하다 보면 이름 뒤에 d가 붙은 프로그램을 자주 볼 수 있습니다.

예를 들어

sshd

httpd

dockerd

등이 있습니다.

여기서 d는 일반적으로 daemon을 의미합니다.

Daemon은 백그라운드에서 계속 실행되는 프로그램을 말합니다.

즉 cloudflared를 아주 단순하게 표현하면

“Cloudflare 연결을 담당하면서 백그라운드에서 계속 실행되는 프로그램”

이라고 이해하면 됩니다.

3. Daemon이 뭐야?

초보자라면 Daemon이라는 말도 생소할 수 있습니다.

일반 프로그램은 사용자가 직접 실행하고 종료하는 경우가 많습니다.

예를 들어

메모장 실행
↓
작업
↓
메모장 종료

형태입니다.

Daemon은 조금 다릅니다.

서버가 켜져 있는 동안 백그라운드에서 계속 동작하면서 특정 작업을 담당합니다.

예를 들어 SSH 서버에서는 sshd가 실행됩니다.

사용자
↓
SSH 접속
↓
sshd
↓
Linux Server

Cloudflare Tunnel에서도 비슷합니다.

Cloudflare
↓
Tunnel
↓
cloudflared
↓
내부 Service

POINT.

cloudflared는 사용자가 필요할 때마다 잠깐 실행하는 프로그램이라기보다,

운영 환경에서는 서버와 함께 계속 실행되는 형태로 사용하는 경우가 일반적입니다.

4. cloudflared는 어디에 설치될까?

cloudflared는 여러 형태로 실행할 수 있습니다.

대표적으로 다음과 같습니다.

Linux Server

Windows Server

macOS

Docker Container

Kubernetes Pod

즉 반드시 물리 서버에 직접 설치해야 하는 것은 아닙니다.

Cloudflare 공식 문서에서도 Linux와 Windows에서는 시스템 서비스로 실행할 수 있고, Kubernetes 클러스터 내부에는 cloudflared daemon을 배포할 수 있다고 설명합니다.

5. Linux 서버에서는 어떻게 보일까?

Linux 서버에 cloudflared가 설치되어 있고 서비스로 운영된다면 대략 이런 구조입니다.

Linux Server

├─ sshd
├─ containerd
├─ kubelet
└─ cloudflared
↓
Cloudflare

운영 환경에서는 systemd 서비스로 등록해서 사용할 수 있습니다.

예를 들어 다음 명령으로 상태를 확인할 수 있습니다.

systemctl status cloudflared

Cloudflare 공식 문서 기준 Linux 환경에서 기본 서비스 이름은 일반적으로

cloudflared.service

입니다.

6. 왜 서비스로 실행할까?

서버가 재부팅되었다고 생각해보겠습니다.

cloudflared를 매번 사람이 직접 실행해야 한다면 운영하기 불편합니다.

그래서 서비스로 등록합니다.

Server Boot
↓
systemd
↓
cloudflared.service 시작
↓
Cloudflare 연결
↓
Tunnel 활성화

이렇게 구성하면 서버가 부팅될 때 cloudflared가 자동으로 실행되도록 구성할 수 있습니다.

Cloudflare 역시 운영 환경에서는 cloudflared를 서비스로 실행하는 방식을 권장하고 있습니다.

7. cloudflared가 실제로 하는 일

cloudflared의 핵심 역할은 크게 세 가지로 보면 이해하기 쉽습니다.

① Cloudflare와 연결한다.

cloudflared가 Cloudflare 네트워크 방향으로 연결을 생성합니다.

② Tunnel을 유지한다.

연결이 끊어지지 않도록 Tunnel 연결을 유지합니다.

③ Cloudflare에서 들어온 요청을 내부 서비스로 전달한다.

예를 들어 내부 서비스가

localhost:8080

에서 실행되고 있다고 가정해보겠습니다.

사용자
↓
Cloudflare
↓
Tunnel
↓
cloudflared
↓
localhost:8080

이런 흐름으로 요청을 전달합니다.

8. cloudflared는 웹서버일까?

아닙니다.

이 부분도 중요합니다.

cloudflared 자체가 웹사이트를 제공하는 프로그램은 아닙니다.

예를 들어 Nginx가 있다고 가정하겠습니다.

Nginx는 실제 웹서비스를 제공합니다.

cloudflared는 Cloudflare에서 받은 요청을 Nginx 같은 실제 서비스까지 전달해주는 역할을 합니다.

사용자
↓
Cloudflare
↓
cloudflared
↓
Nginx
↓
Web Application

즉 역할을 구분하면 다음과 같습니다.

Nginx

실제 웹 요청을 처리하는 서버

cloudflared

Cloudflare와 내부 서비스를 연결해주는 연결 프로그램

POINT.

cloudflared는 애플리케이션 자체가 아닙니다.

Cloudflare와 애플리케이션 사이의 연결 역할을 합니다.

9. 예를 들어 Grafana가 있다면?

내부 서버에 Grafana가 있다고 해보겠습니다.

Grafana가

localhost:3000

에서 실행되고 있습니다.

구조는 다음과 같습니다.

Grafana
localhost:3000
↑
cloudflared
↑
Cloudflare Tunnel
↑
Cloudflare
↑
사용자

cloudflared 설정에서

grafana.example.com

이라는 주소를 Grafana의

http://localhost:3000

으로 연결할 수 있습니다.

사용자

grafana.example.com 접속

↓

Cloudflare

↓

Tunnel

↓

cloudflared

↓

localhost:3000

↓

Grafana

즉 cloudflared는

“이 요청은 Grafana로 전달해.”

라는 연결 역할을 수행합니다.

10. cloudflared에는 무엇을 알려줘야 할까?

cloudflared가 아무것도 모르는 상태에서는 어느 서비스로 요청을 전달해야 하는지 알 수 없습니다.

그래서 설정이 필요합니다.

예를 들어 개념적으로 다음 정보를 가질 수 있습니다.

Tunnel 정보

어떤 Tunnel을 사용할 것인가?

서비스 정보

어느 내부 서비스로 요청을 전달할 것인가?

예를 들어

app.example.com
↓
http://localhost:8080

처럼 연결할 수 있습니다.

Locally-managed Tunnel에서는 이러한 설정을 config.yml 파일에 정의할 수 있습니다. Cloudflare는 하나의 cloudflared에서 여러 서비스 연결이 필요한 경우 구성 파일을 활용할 수 있다고 설명합니다.

11. config.yml은 무엇일까?

Linux를 사용하다 보면

config.yml

이라는 파일을 볼 수 있습니다.

이것은 cloudflared의 설정 파일로 사용할 수 있습니다.

쉽게 말하면 cloudflared에게

“어떤 Tunnel을 사용하고”

“어디로 요청을 보내야 하는지”

알려주는 설정서입니다.

개념적으로는 다음과 같습니다.

Cloudflare
↓
Tunnel A
↓
cloudflared
↓
config.yml
↓
Web Service

Cloudflare 공식 문서에서는 locally-managed Tunnel의 경우 기본 cloudflared 디렉터리에서 설정 파일과 credentials 정보를 찾을 수 있다고 설명합니다.

12. Tunnel을 만들었다고 바로 통신이 시작될까?

이 부분도 매우 중요합니다.

Tunnel을 생성하는 것과 실제 cloudflared가 실행되어 연결되는 것은 별개의 과정입니다.

예를 들어 다음 명령으로 Tunnel을 만들 수 있습니다.

cloudflared tunnel create my-tunnel

하지만 Tunnel을 생성했다고 해서 그 순간 실제 연결이 계속 유지되는 것은 아닙니다.

cloudflared를 실행해야 실제 Tunnel 연결이 시작됩니다.

예를 들어

cloudflared tunnel run my-tunnel

구조는 이렇게 이해하면 됩니다.

Tunnel 생성
↓
Tunnel ID 생성
↓
cloudflared 실행
↓
Cloudflare와 연결
↓
Tunnel 활성

POINT.

Tunnel 생성과 Tunnel 실행은 다릅니다.

create

Tunnel 정보를 만든다.

run

cloudflared가 실제 Tunnel 연결을 실행한다.

Cloudflare 공식 문서도 tunnel create 단계에서는 Tunnel과 UUID의 관계가 만들어지지만 아직 연결은 활성화되지 않으며, tunnel run 명령을 통해 실제 연결을 실행한다고 설명합니다.

13. Kubernetes에서는 cloudflared가 어떻게 보일까?

Kubernetes에서는 cloudflared를 Pod 형태로 실행할 수 있습니다.

구조를 보면 쉽습니다.

Kubernetes Cluster

├─ Application Pod
├─ Grafana Pod
├─ API Pod
└─ cloudflared Pod
↓
Cloudflare

외부에서 요청이 들어오면 예를 들어 다음과 같이 전달될 수 있습니다.

사용자
↓
Cloudflare
↓
Tunnel
↓
cloudflared Pod
↓
Kubernetes Service
↓
Application Pod

Cloudflare 공식 Kubernetes 가이드에서도 클러스터 내부에 cloudflared daemon을 설치하여 클러스터 내부 애플리케이션을 Cloudflare 네트워크에 연결하는 구조를 설명하고 있습니다.

14. cloudflared Pod가 GPU Node에 있어야 할까?

반드시 그렇지는 않습니다.

예를 들어 Kubernetes 클러스터가 있다고 생각해보겠습니다.

Control Plane

Worker Node 01

Worker Node 02

GPU Node 01

GPU Node 02

cloudflared는 설계에 따라 특정 Worker Node에서 동작할 수도 있습니다.

cloudflared Pod
↓
Kubernetes Service
↓
Application Pod

즉 애플리케이션이 GPU Node에서 실행된다고 해서 cloudflared 역시 반드시 같은 GPU Node에서 실행되어야 한다는 뜻은 아닙니다.

Kubernetes의 Service 네트워크를 통해 다른 Node에 있는 Pod로 연결할 수 있기 때문입니다.

POINT.

Cloudflare Tunnel과 GPU 통신은 별개의 개념입니다.

cloudflared가 존재한다고 해서 NCCL이나 GPU 간 통신이 Cloudflare Tunnel을 사용하는 것은 아닙니다.

15. cloudflared가 실행 중인지 확인하는 방법

Linux 서버에서는 다음과 같이 확인할 수 있습니다.

프로세스 확인

ps -ef | grep cloudflared

서비스 확인

systemctl status cloudflared

설치 위치 확인

which cloudflared

버전 확인

cloudflared --version

Kubernetes에서는 다음처럼 확인할 수 있습니다.

kubectl get pods -A | grep -i cloudflared

Deployment 확인

kubectl get deploy -A | grep -i cloudflared

이 명령들은

“cloudflared가 존재하는가?”

를 확인하는 가장 기본적인 방법입니다.

16. 프로세스가 있다고 무조건 Tunnel을 사용하는 것일까?

여기서는 한 단계 더 확인해야 합니다.

프로세스만 발견했다고 해서 어떤 서비스와 연결되어 있는지까지 알 수 있는 것은 아닙니다.

다음 단계로 확인해야 하는 것은

cloudflared가 어떤 설정으로 실행되고 있는가?

입니다.

예를 들면

어떤 Tunnel을 사용하는가?

어떤 hostname을 사용하는가?

어떤 내부 Service로 연결되는가?

어떤 방식으로 실행되는가?

를 확인해야 합니다.

즉,

cloudflared 발견

↓

Tunnel 설정 확인

↓

연결 대상 Service 확인

순서로 보는 것이 좋습니다.

17. cloudflared 로그에서는 무엇을 볼 수 있을까?

운영 중 장애가 발생하면 로그도 중요합니다.

cloudflared 로그에는

cloudflared ↔ Cloudflare

통신과

cloudflared ↔ 내부 Origin Server

사이의 동작 정보가 기록될 수 있습니다.

따라서 Tunnel 연결 장애나 내부 서비스 연결 문제를 분석할 때 활용할 수 있습니다.

예를 들어 개념적으로는

cloudflared
↓
Cloudflare 연결 성공/실패

또는

cloudflared
↓
Origin Service 연결 성공/실패

같은 내용을 확인할 수 있습니다.

18. Prometheus로도 모니터링할 수 있을까?

가능합니다.

cloudflared는 Prometheus 형식의 Metrics Endpoint를 제공할 수 있습니다.

Cloudflare 공식 문서 기준으로 일반적인 비컨테이너 환경에서는 사용 가능한 포트를 선택해 metrics endpoint를 실행하며, Kubernetes 같은 컨테이너 환경에서도 metrics를 노출할 수 있습니다.

구조는 대략 다음과 같습니다.

cloudflared
↓
Metrics
↓
Prometheus
↓
Grafana

따라서 운영 환경에서는 Tunnel 상태와 트래픽 등을 모니터링하는 구성도 가능합니다.

19. cloudflared가 죽으면 어떻게 될까?

이것도 매우 중요합니다.

구조를 다시 보겠습니다.

사용자
↓
Cloudflare
↓
Tunnel
↓
cloudflared
↓
Application

여기서 cloudflared가 완전히 종료된다면

Cloudflare와 내부 서비스 사이의 Tunnel 연결이 유지되지 않습니다.

즉 해당 Tunnel을 통한 서비스 접근에 문제가 발생할 수 있습니다.

그래서 운영 환경에서는 cloudflared를 Service나 Kubernetes Deployment 형태로 지속 실행하고, 필요하면 여러 Replica를 배치하여 가용성을 높일 수 있습니다.

Cloudflare 역시 여러 cloudflared replica를 배치하여 고가용성과 Failover를 구성할 수 있도록 지원합니다.

이 내용은 9단계에서 자세히 다룰 예정입니다.

20. 초보자가 헷갈리는 관계 한번에 정리

가장 중요한 관계를 정리해보겠습니다.

Cloudflare

인터넷 앞단에서 요청을 받는 Cloudflare 네트워크

↓

Cloudflare Tunnel

Cloudflare와 내부 환경을 연결하는 논리적인 통신 경로

↓

cloudflared

Tunnel 연결을 실제로 만들고 유지하는 프로그램

↓

Service

실제로 사용자가 접근하려는 내부 서비스

↓

Application

Grafana, Web, API 등 실제 애플리케이션

즉 전체 구조는

사용자
↓
Cloudflare
↓
Cloudflare Tunnel
↓
cloudflared
↓
Service
↓
Application

입니다.

21. Cloudflare Tunnel과 cloudflared의 차이

이 둘을 헷갈리지 않는 것이 중요합니다.

Cloudflare Tunnel

“연결 구조 또는 통신 경로”

cloudflared

“그 Tunnel을 실제로 연결하고 유지하는 프로그램”

비유하면,

Cloudflare Tunnel이 도로라면

cloudflared는 그 도로를 실제로 연결하고 관리하는 역할을 한다고 생각하면 됩니다.

22. 오늘 꼭 기억해야 할 핵심 6가지

① cloudflared는 Cloudflare Tunnel 연결을 담당하는 프로그램이다.

② 서버나 컨테이너에서 백그라운드 daemon 형태로 실행될 수 있다.

③ Linux에서는 systemd 서비스 형태로 운영할 수 있다.

④ Kubernetes에서는 Pod 또는 Deployment 형태로 실행할 수 있다.

⑤ cloudflared는 Cloudflare와 내부 Service 사이에서 요청을 전달한다.

⑥ cloudflared가 있다고 해서 서버의 모든 네트워크 통신이 Cloudflare Tunnel을 통과하는 것은 아니다.

한 줄 요약

cloudflared는

“내부 서버 또는 Kubernetes 환경에서 실행되면서 Cloudflare와 Tunnel 연결을 만들고 유지하며, Cloudflare에서 전달된 요청을 내부 서비스로 전달하는 프로그램”

입니다.

초보자는 이것만 기억하면 됩니다

Cloudflare Tunnel을 공부하면서 가장 먼저 기억해야 할 구조는 이것입니다.

사용자
↓
Cloudflare
↓
Tunnel
↓
cloudflared
↓
내부 Service

그리고 가장 중요한 구분은

Cloudflare Tunnel = 통신 경로

cloudflared = 그 경로를 연결하는 프로그램

입니다.

이 두 가지를 구분할 수 있다면 Cloudflare Tunnel의 기본 구조를 절반 이상 이해했다고 볼 수 있습니다.

다음 3단계에서는

“사용자가 웹사이트에 접속했을 때 실제 패킷과 요청이 어떤 순서로 이동하는가?”

를 중심으로

사용자
→ DNS
→ Cloudflare
→ Tunnel
→ cloudflared
→ Service
→ Application

전체 통신 흐름을 처음부터 끝까지 자세히 알아보겠습니다.

3단계에서는 통신 흐름이 핵심입니다. 특히 DNS → Cloudflare Edge → Tunnel → cloudflared → Kubernetes Service → Pod를 한 요청이 이동하는 순서대로 풀어보면, 이후 방화벽·포트·Kubernetes 구조까지 훨씬 쉽게 연결됩니다.