집 서버를 포트포워딩 없이 공개하는 방법

집에 남는 데스크톱을 활용해 개인 프로젝트 서버를 운영하려고 했습니다.

Ubuntu를 설치하고 웹 애플리케이션까지 실행한 뒤, 휴대폰과 외부 노트북에서도 관리자 화면을 확인하고 싶었습니다.

예를 들어 주소는 다음과 같습니다.

dashboard.example.com

그런데 외부 접속 방법을 알아보다 보니 공유기 포트포워딩이 먼저 나왔습니다.

공유기 443 포트
→ 집 서버 Nginx

공유기 8080 포트
→ 애플리케이션

기술적으로는 가능하지만 마음에 걸리는 부분이 있었습니다.

인터넷에 포트를 직접 열면
주소나 IP를 알아낸 누구나 서버에 접속을 시도할 수 있는 것 아닌가?

이 고민을 하다가 알게 된 것이 Cloudflare Tunnel과 Cloudflare Access였습니다.

---

Cloudflare Access는 온라인 출입문 경비원이다

Cloudflare Access를 가장 쉽게 표현하면 다음과 같습니다.

집 서버 앞에 서 있는 온라인 출입문 경비원

Cloudflare Access가 없다면 사용자는 바로 애플리케이션 로그인 화면이나 서버로 접근을 시도합니다.

사용자
↓
집 서버
↓
관리자 화면

Access를 적용하면 중간에 신원 확인 과정이 추가됩니다.

사용자
↓
Cloudflare 로그인
↓
허용된 사용자인지 확인
↓
집 서버
↓
관리자 화면

허용한 이메일이면 관리자 화면으로 연결하고, 허용되지 않은 사용자는 집 서버에 도달하기 전에 차단합니다.

이메일, 로그인 제공자, 사용자 그룹, 기기 조건 등을 이용해 애플리케이션별 접근 정책을 만들 수 있습니다.

혼자 사용하는 서버라면 본인의 이메일 주소 하나만 허용하는 방식으로도 시작할 수 있습니다.

---

Tunnel과 Access는 역할이 다르다

처음에는 Tunnel과 Access가 비슷한 서비스라고 생각했습니다.

하지만 둘은 역할이 완전히 다릅니다.

Cloudflare Tunnel

집 서버까지 연결되는 전용 지하 통로

집 서버에서 실행되는 cloudflared가 Cloudflare 쪽으로 연결을 만듭니다.

외부 사용자가 집 서버의 공개 IP와 포트로 직접 들어오는 구조가 아닙니다.

집 서버
↓ 외부 방향 연결
Cloudflare

따라서 일반적인 웹 애플리케이션 공개를 위해 공유기에 80·443 포트포워딩을 설정하거나, 애플리케이션의 8080 포트를 직접 열 필요가 없습니다.

Cloudflare Access

지하 통로 입구에 있는 신분증 검사대

Tunnel이 연결 경로를 만든다면 Access는 누가 그 경로를 이용할 수 있는지 판단합니다.

사용자
↓
Cloudflare Access
↓
Cloudflare Tunnel
↓
집 서버

보통 두 서비스를 함께 사용합니다.

---

개인 프로젝트 관리자 화면에 적용하면

제가 이해한 구조를 개인 프로젝트 관리자 화면에 적용하면 다음과 같습니다.

휴대폰·노트북
↓
https://dashboard.example.com
↓
Cloudflare Access
  허용한 이메일만 통과
↓
Cloudflare Tunnel
↓
집 Ubuntu 서버
↓
Nginx
├─ 웹 관리자 화면
└─ /api → 백엔드 애플리케이션

사용자가 dashboard.example.com에 접속하면 바로 집 서버에 연결되지 않습니다.

먼저 Cloudflare 로그인 화면이 나타납니다.

이메일 일회용 인증번호 방식을 사용한다면 대략 다음 순서로 진행됩니다.

1. dashboard.example.com 접속
2. Cloudflare 로그인 화면 표시
3. 허용된 이메일 입력
4. 이메일로 일회용 인증번호 수신
5. 인증번호 입력
6. 관리자 화면 접속

별도의 VPN 애플리케이션 없이 브라우저에서 인증할 수 있다는 점이 개인용 웹 관리자 화면에 잘 맞았습니다.

---

공유기 포트포워딩을 열지 않아도 된다

Cloudflare Tunnel을 사용하는 핵심 이유 중 하나는 외부에서 집 서버로 직접 들어오는 포트를 열지 않아도 된다는 점입니다.

예를 들어 집 서버에 다음 서비스가 실행되고 있다고 가정해보겠습니다.

Nginx        80·443
Backend      8080
PostgreSQL   5432
SSH          22

이 포트들을 공유기에서 모두 외부로 공개해서는 안 됩니다.

특히 데이터베이스와 백엔드 애플리케이션 포트는 인터넷에서 직접 접근할 수 없도록 구성하는 것이 좋습니다.

PostgreSQL
→ localhost 또는 Docker 내부 네트워크만 허용

Backend
→ Nginx 또는 내부 네트워크에서만 접근

웹 접점
→ Cloudflare Tunnel을 통한 주소만 사용

Cloudflare를 통한 주소를 보호해놓고 공인 IP:8080으로도 접근할 수 있게 열어두면 Access를 우회할 수 있습니다.

따라서 Tunnel을 사용한다면 기존 포트포워딩도 함께 닫아야 합니다.

---

Access가 해결하는 것

Cloudflare Access와 Tunnel을 함께 사용하면 다음 부분을 해결할 수 있습니다.

1. 허용된 사람만 접근

등록한 이메일이나 로그인 정책에 맞는 사람만 관리자 화면에 들어올 수 있습니다.

2. 원본 서버를 직접 공개하지 않음

사용자가 집 서버의 공인 IP와 애플리케이션 포트로 직접 접근하지 않고 Cloudflare를 통해 접속합니다.

3. 애플리케이션별 접근 정책

관리자 화면, 테스트 화면, 내부 도구마다 다른 접근 정책을 적용할 수 있습니다.

4. 인증 기록 확인

누가 인증을 시도했고 허용 또는 차단됐는지 확인할 수 있습니다.

---

Access가 해결하지 않는 것

Cloudflare Access를 붙였다고 애플리케이션 보안이 모두 끝나는 것은 아닙니다.

Access는 외부 출입문 역할입니다.

집 안에 들어온 사용자가 어떤 데이터에 접근할 수 있는지는 애플리케이션이 계속 확인해야 합니다.

Cloudflare Access
→ 서버에 접근할 사용자 확인

애플리케이션 인증·권한
→ 사용자별 기능과 데이터 접근 통제

암호화
→ 비밀번호, 토큰, API Key 보호

데이터베이스 권한
→ 애플리케이션에 필요한 최소 권한만 제공

예를 들어 관리자와 일반 사용자가 함께 사용하는 서비스라면 Access 인증을 통과한 뒤에도 애플리케이션 내부 권한 검사가 필요합니다.

또한 서버가 Cloudflare를 우회해 직접 노출되지 않았는지도 계속 확인해야 합니다.

---

이메일 OTP 설정 시 주의할 점

이메일 일회용 인증번호는 혼자 사용하는 서버에서 간단하게 시작하기 좋습니다.

다만 정책을 잘못 설정하면 누구나 자기 이메일로 인증번호를 받아 접속할 수 있습니다.

따라서 다음처럼 설정해야 합니다.

잘못된 예
→ 이메일 OTP를 사용할 수 있는 모든 사용자 허용

권장 예
→ 지정한 이메일 주소만 허용

예를 들면 다음과 같습니다.

Allow
→ Email
→ owner@example.com

가족이나 팀원에게 접근을 열어야 할 때만 허용 목록을 추가합니다.

---

제가 개인 서버에 적용한다면

개인 프로젝트 관리자 화면이라면 처음부터 복잡하게 구성하지 않을 생각입니다.

대상 주소
dashboard.example.com/*

접근 허용
내 이메일 주소 1개

인증 방식
이메일 일회용 인증번호

서버 연결
Cloudflare Tunnel

공유기 포트포워딩
없음

cloudflared 실행
Ubuntu systemd 서비스

웹 서버
Nginx

백엔드
내부 포트에서만 실행

데이터베이스
localhost 또는 Docker 내부망만 허용

추가로 외부 네트워크에서 다음 두 가지를 테스트해야 합니다.

허용된 이메일
→ 정상 접속

허용되지 않은 이메일
→ 서버 도달 전 차단

공인 IP와 애플리케이션 포트를 이용한 직접 접근도 불가능한지 확인합니다.

---

Cloudflare Access도 애플리케이션 검증이 필요하다

조금 더 안전하게 운영하려면 애플리케이션이 Cloudflare Access에서 전달한 인증 정보도 검증하는 것이 좋습니다.

Cloudflare Access는 인증된 요청에 토큰을 전달할 수 있습니다.

백엔드에서는 해당 토큰이 실제 Cloudflare에서 발급됐는지 확인해, 우회 요청을 한 번 더 차단할 수 있습니다.

특히 서버가 다른 경로로 노출될 가능성이 있거나 중요한 관리자 기능을 제공한다면 방어 단계를 하나 더 두는 편이 안전합니다.

---

비용은 어떻게 될까?

현재 Cloudflare 문서에서는 Zero Trust 무료 플랜을 소규모 사용자 환경에서 시작할 수 있도록 제공하고 있습니다.

혼자 사용하거나 소수 인원만 접근하는 개인 서버라면 우선 무료 범위에서 기능을 검증한 뒤, 필요한 기능이 생겼을 때 유료 플랜을 검토하는 방식이 적합해 보입니다.

다만 플랜과 제공 범위는 변경될 수 있으므로 실제 적용 시점에는 공식 요금제와 제한을 다시 확인해야 합니다.

---

마치며

Cloudflare Access가 처음에는 복잡한 기업용 보안 서비스처럼 느껴졌습니다.

하지만 집 서버에 대입해서 이해하니 역할이 명확했습니다.

Cloudflare Tunnel
= 집 서버까지 이어지는 전용 통로

Cloudflare Access
= 통로 입구에서 사용자를 확인하는 경비원

두 서비스를 함께 사용하면 집 서버를 인터넷에 직접 내놓지 않고, 허용한 사람만 웹 관리자 화면에 접근하도록 구성할 수 있습니다.

물론 Access 하나만 붙인다고 모든 보안이 끝나지는 않습니다.

애플리케이션 내부 권한, 중요 정보 암호화, 데이터베이스 접근 통제도 계속 필요합니다.

그래도 외부 접점을 줄이고 서버에 도달하기 전에 사용자를 확인하는 구조만으로도, 공유기 포트를 직접 여는 방식보다 훨씬 마음 편하게 개인 서버를 운영할 수 있을 것 같습니다.

집 서버 보안은 로그인 화면부터 시작하는 것이 아니라,

서버까지 누가 도달할 수 있는지 제한하는 것부터 시작했습니다.