도메인을 붙인 다음 단계에서 보통 이 선택지를 만나게 됩니다.

서버를 그냥 인터넷에 직접 열까?
아니면 Cloudflare Tunnel로 우회해서 붙일까?

둘 다 정답이 될 수 있습니다.
중요한 건 “어느 쪽이 더 멋져 보이느냐”가 아니라, 공개 범위, 운영 복잡도, 실패 지점, 보안 표면이 어떻게 달라지는지 이해하는 것입니다.

이 글은 2026년 5월 4일 기준 Cloudflare와 Oracle 공식 문서를 바탕으로, 작은 사이트 운영자 기준에서 두 방식을 비교합니다.

DNS와 도메인 기초가 먼저 필요하다면 이 글부터 보는 편이 좋습니다.

1. 두 방식은 “공개 경로”부터 다릅니다

큰 그림만 보면 차이는 간단합니다.

직접 공개

사용자가 도메인으로 들어오면, DNS가 결국 공개 IP를 가리키고 요청이 그 서버로 들어옵니다.

Cloudflare Tunnel

서버 안의 cloudflared가 Cloudflare로 outbound 연결을 먼저 만들고, 사용자는 Cloudflare 쪽 공개 호스트명으로 접속합니다.
즉, 원본 서버는 인터넷에서 바로 보이는 공개 IP 없이도 HTTP 서비스를 내보낼 수 있습니다.

Cloudflare 공식 문서 표현대로, Tunnel은 outbound-only 연결이고 no open inbound ports, no public IPs를 핵심 가치로 둡니다.

2. 직접 공개는 생각보다 준비 항목이 많습니다

Oracle 공식 문서 기준으로 인스턴스를 인터넷에 직접 노출하려면 아래 조건이 같이 맞아야 합니다.

  • 인스턴스가 public subnet에 있어야 함
  • public IP가 있어야 함
  • VCN에 internet gateway가 있어야 함
  • 라우트 테이블과 보안 규칙이 맞아야 함

여기서 끝도 아닙니다.
Oracle 문서와 CLI 참고 자료는 보안 리스트나 NSG 외에도 인스턴스 내부 방화벽 규칙을 같이 확인해야 한다고 안내합니다.

즉, 직접 공개는 보통 이런 체크리스트가 따라옵니다.

  1. 공인 IP
  2. 인바운드 80/443 또는 필요한 포트
  3. 보안 리스트/NSG
  4. 서버 내부 방화벽
  5. TLS 인증서
  6. 원본 서버 패치와 접근 통제

작게 시작할 때도 결국 인터넷에 직접 보이는 서버를 하나 운영하는 셈입니다.

3. Tunnel은 인바운드를 없애는 대신 cloudflared를 운영 포인트로 둡니다

Cloudflare Tunnel은 cloudflared를 서버에 설치한 뒤, 그 프로세스가 Cloudflare와 장기 연결을 유지하는 방식입니다.
Cloudflare 문서 기준으로 이 연결은 포트 7844로 HTTP/2 또는 QUIC를 사용한 outbound-only 연결입니다.

실무적으로 보면 바뀌는 점은 이렇습니다.

  • 80/443 인바운드를 직접 열지 않아도 됨
  • 공개 IP 없이도 웹 호스트명을 붙일 수 있음
  • 호스트명과 로컬 서비스(http://localhost:8080 같은 값)를 매핑함
  • Cloudflare 대시보드에서 DNS 레코드가 같이 연결될 수 있음

즉, 공개 웹 트래픽 진입점을 내 서버가 아니라 Cloudflare 쪽으로 옮기는 구조입니다.

4. 직접 공개가 더 나은 경우도 분명 있습니다

Cloudflare Tunnel이 늘 우월한 것은 아닙니다.

직접 공개가 더 편한 경우는 보통 이런 때입니다.

1. 경로를 최대한 단순하게 두고 싶을 때

별도 터널 데몬 없이, DNS -> 공개 IP -> Nginx/App 한 줄로 끝납니다.

2. Cloudflare 의존도를 줄이고 싶을 때

Tunnel은 DNS만 Cloudflare에 두는 게 아니라, 실제 공개 경로도 Cloudflare에 의존합니다.
벤더 결합을 줄이고 싶다면 직접 공개가 더 직관적입니다.

3. HTTP가 아닌 서비스나 원본 IP 관찰이 중요한 경우

Cloudflare 문서 기준으로 Tunnel은 off-ramp only이고, 원본 서버는 non-HTTP 프로토콜에서 실제 클라이언트 원본 IP를 그대로 보지 못합니다.
HTTP는 CF-Connecting-IP 같은 헤더로 보완할 수 있지만, SSH/RDP/TCP는 성격이 다릅니다.

즉, 순수한 네트워크 서비스 운영 관점에서는 직접 공개가 더 단순할 수 있습니다.

5. 작은 공개 사이트에는 Tunnel이 더 실용적인 경우가 많습니다

반대로 작은 블로그, 관리자 화면, 내부 도구 공개에는 Tunnel이 꽤 잘 맞습니다.

이유는 간단합니다.

  • 공개 IP를 숨길 수 있음
  • 인바운드 포트 관리 부담이 줄어듦
  • Cloudflare를 거치며 캐시와 보안 기능을 붙이기 쉬움
  • 여러 서브도메인을 한 터널에 묶기 쉬움

Cloudflare 문서 기준으로 하나의 터널에 여러 published application을 둘 수 있고, 각 호스트명을 서로 다른 로컬 서비스로 연결할 수 있습니다.

작은 서버 운영자에게 이 말은 곧:

  • admin.example.com -> 관리자 앱
  • api.example.com -> API
  • brief.example.com -> 블로그

같은 구성을 공개 IP 하나 직접 노출 없이 운영할 수 있다는 뜻입니다.

6. Cloudflare를 쓴다고 해서 원본이 자동으로 안 숨겨지는 것은 아닙니다

많이 하는 착각이 여기입니다.

Cloudflare 쓰면 원본 IP는 무조건 숨겨지겠지

Cloudflare DNS 문서는 그렇지 않다고 분명히 설명합니다.
프록시된 레코드는 Cloudflare IP를 반환하지만, 같은 원본 IP를 가리키는 DNS-only 레코드가 있으면 그 레코드가 원본 IP를 드러낼 수 있습니다.

즉, 이런 상태는 위험할 수 있습니다.

  • 메인 웹은 proxied
  • 메일이나 다른 서브도메인은 DNS-only
  • 그런데 모두 같은 원본 서버를 가리킴

Tunnel도 마찬가지입니다.
별도 공인 IP 경로나 다른 DNS 레코드로 같은 서버를 다시 열어두면, “터널로 숨겼다”는 이점이 줄어듭니다.

7. 지금 같은 작은 블로그 구조라면 보통 이렇게 고르는 편이 현실적입니다

작은 정적 사이트 + 가벼운 API + 관리자 화면 조합이라면, 보통은 아래처럼 정리할 수 있습니다.

Tunnel이 더 잘 맞는 경우

  • 1코어 1GB처럼 작은 서버
  • 공개 웹과 관리자 화면이 중심
  • 공개 인바운드 포트를 최소화하고 싶음
  • 원본 IP를 가급적 숨기고 싶음

직접 공개가 더 잘 맞는 경우

  • Cloudflare 종속을 줄이고 싶음
  • 공개 IP와 네트워크 경로를 직접 제어하고 싶음
  • HTTP 외의 서비스 노출이 더 중요함
  • 내부 운영팀이 네트워크/방화벽 관리에 익숙함

즉, 작은 콘텐츠 사이트 운영자 기준으로는 공개 웹은 Tunnel, 운영용 SSH는 제한된 직접 접근 같은 혼합 구성이 오히려 현실적일 수 있습니다.

한 줄 결론

Cloudflare Tunnel은 인바운드를 줄이는 선택이고, 직접 공개는 경로를 단순하게 두는 선택입니다.
작은 서버 운영자라면 멋보다 어느 쪽이 내가 계속 유지할 수 있는 구조인가를 기준으로 고르는 편이 맞습니다.

이어 읽기

출처