Cloudflare로 공인 IP 없이 사내 서버를 외부에 노출하기: Private Origins 라우팅 뜯어보기
오늘 올라온 목록을 쭉 보면 AI 얘기가 절반이지만, 인프라 굴리는 입장에서 진짜 손에 잡히는 건 Cloudflare의 Application Services for Private Origins 발표다. "공인 IP 없이 사내 사설망 애플리케이션을 외부 트래픽으로 연결한다"는 한 줄이 꽤 묵직해서, 이걸 실무 맥락에서 풀어보려 한다. (참고: 현재 closed beta 단계라 GA 이후 동작이 달라질 수 있으니 도입 전 공식 문서 재확인 필요.)
왜 지금 이게 화제인가
사내에서 돌리는 내부 API, 어드민 페이지, 레거시 백오피스를 외부(혹은 다른 리전, 파트너사)에 열어줘야 하는 상황은 생각보다 자주 온다. 그동안 우리가 쓰던 방법은 대략 이랬다.
- 퍼블릭 IP 붙이고 NLB/ALB 앞에 두고 WAF 거는 방식 — 노출면이 늘고 방화벽 관리가 빡세진다.
- VPN으로 통째로 묶는 방식 — 클라이언트 배포·인증서 갱신·MTU 이슈가 끝없이 따라온다.
- 커넥터 데몬(예: cloudflared) 깔아서 아웃바운드 터널로 빼는 방식 — 서버마다 에이전트 깔아야 하고 버전 관리가 일이다.
이번 발표의 핵심은 "이미 깔려 있는 IPsec / GRE / CNI / Cloudflare Mesh 경로를 그대로 재활용해서, 공인 hostname을 사설 IP origin으로 라우팅한다"는 점이다. 즉 별도 커넥터 소프트웨어를 origin마다 새로 깔 필요가 없다는 게 차별점이다. 이미 Cloudflare로 사내망을 끌어다 쓰고 있는(Magic WAN 등) 조직이라면 추가 설치 없이 hostname만 매핑하면 된다는 그림이다.
동작 원리: 비유로 풀면
기존 Cloudflare Tunnel을 "건물마다 직원이 밖에서 안으로 케이블을 끌어다 꽂는 방식"이라고 하면, 이번 건 "이미 회사와 통신사 사이에 깔려 있는 전용 회선(IPsec/GRE)에 주소록만 한 줄 추가하는 방식"에 가깝다. 새 케이블(커넥터)을 까는 게 아니라 라우팅 테이블에 매핑을 얹는 개념이다.
흐름을 단순화하면 이렇다.
외부 사용자
│ HTTPS (app.example.com)
▼
Cloudflare Edge ── WAF / Access(인증) ──┐
│ │
│ 기존 IPsec/GRE/CNI 터널 재사용 │
▼ │
사설 origin (10.0.x.x:8080) ◄───────────┘
여기서 중요한 건 origin이 사설 IP인 채로 끝난다는 거다. 인터넷에서 직접 도달 가능한 경로가 없고, 오직 Cloudflare 엣지를 통한 트래픽만 터널을 타고 들어온다. 그래서 origin 쪽에 인바운드 포트를 열 필요가 없고, 노출면이 엣지로 통일된다.
개념상 매핑은 "이 hostname → 이 사설 IP:port, 이 경로(터널)로" 형태가 될 것으로 보인다. 정확한 설정 스키마(대시보드/API/Terraform)는 beta 문서 기준으로 봐야 한다. Terraform 프로바이더로 관리한다면 대략 이런 그림을 예상할 수 있는데, 실제 리소스 이름은 GA 시점에 확인이 필요하다.
# 예시 — 실제 리소스/속성명은 공식 문서 확인 필요
# 의사 구성: hostname을 사설 origin에 매핑
resource "cloudflare_xxx_route" "internal_admin" {
zone_id = var.zone_id
hostname = "admin.internal.example.com"
origin = "10.20.0.15:8080"
path = "ipsec-tunnel-seoul" # 기존 터널 경로 재사용
}
실무 관점: 도입 전에 따져볼 것들
좋아 보이지만 공짜 점심은 아니다. 실제로 굴린다고 생각하면 걸리는 지점이 몇 개 있다.
1. 락인(lock-in)을 각오해야 한다
이건 Cloudflare 생태계에 깊게 들어가는 결정이다. 이미 Magic WAN, Access, WAF를 쓰고 있다면 자연스러운 확장이지만, 단순히 "사내 서버 하나 열고 싶다" 수준이라면 오버킬이다. 그 경우는 그냥 Cloudflare Tunnel(cloudflared) 한 개 띄우는 게 훨씬 가볍고 빠르다.
2. 트래픽이 전부 엣지를 경유한다
모든 요청이 Cloudflare 엣지를 한 번 찍고 사설 origin으로 들어온다. 한국 리전 사용자가 한국 내부 서버에 붙는데 엣지를 경유하면 RTT가 늘 수 있다. 지연에 민감한 내부 API라면 실측이 필수다. "사내망인데 왜 느려졌지?" 하는 흔한 함정이 여기서 나온다.
3. 인증 레이어를 빼먹지 마라
hostname을 외부에 여는 순간, 라우팅만 했다고 끝이 아니다. 반드시 Cloudflare Access(또는 동등한 인증)를 앞단에 걸어야 한다. "사설 IP라 안전하다"는 착각이 가장 위험하다. 라우팅 매핑을 만든 그 순간부터 그 hostname은 공개 표면이 된다. 인증 미들웨어 없이 어드민 페이지를 노출했다가 사고 나는 패턴, 실무에서 정말 자주 본다.
4. 경로 중복과 IP 충돌
여러 터널(IPsec/GRE)을 동시에 운영하면서 사설 대역이 겹치면 라우팅이 꼬인다. 특히 인수합병이나 멀티 VPC 환경에서 10.0.0.0/8을 양쪽에서 막 쓰던 곳이라면 origin 매핑 시 어느 경로로 나갈지 명확히 잡아줘야 한다. 이건 Cloudflare 문제가 아니라 우리 네트워크 설계 숙제다.
대안 정리
- 서버 1~2개, 빠르게: Cloudflare Tunnel(cloudflared) 또는 Tailscale Funnel.
- 이미 Magic WAN/IPsec 운영 중, 커넥터 추가 설치가 싫다: 이번 Private Origins 라우팅이 맞다.
- 벤더 종속이 싫다: 자체 리버스 프록시(Nginx/Envoy) + WireGuard 조합으로 비슷하게 만들 수 있지만 운영 부담은 우리가 다 진다.
정리
한 줄 요약: 이미 Cloudflare로 사내망을 끌어다 쓰는 조직이, 공인 IP나 커넥터 추가 설치 없이 hostname만 매핑해서 사설 origin을 외부에 안전하게 여는 기능이다.
누가 언제 써야 하나 — Magic WAN/IPsec/GRE를 이미 운영 중이고, origin마다 cloudflared 깔고 버전 관리하는 게 지긋지긋한 팀. 반대로 서버 한두 대 가볍게 열 거라면 굳이 이쪽으로 갈 필요 없다. 그리고 무엇보다, closed beta라는 점과 엣지 경유로 인한 지연·인증 레이어 분리는 꼭 실측·검증하고 들어가자.