Cloudflare Tunnel 도입기 : 포트 포워딩 없이 다중 내부망 극복기

최근 회사 프로젝트를 진행하면서 예상치 못한 네트워크 장벽을 마주하게 되었습니다. 내부에서 개발 중인 서비스 (WAS, DB, Git 등)을 외부 협력사와 공유해야 하는 상황이었습니다. 처음에는 아주 간단한 작업이라고 생각했습니다. 회사에는 공인 IP도 존재하고 내부 서버도 이미 어느 정도 구축이 되어 있었기에 포트포워딩 몇 개만 설정해 주면 금방 끝날 줄 알았습니다.

하지만 현실은 전혀 달랐습니다. 이번 글은 Cloudflare Tunnel의 구체적인 구축 방법 보다는 인프라 담당자로서 왜 이 기술을 도입할 수밖에 없었는지 도입 배경과 삽질의 기록입니다.

 

회사 공인 IP

처음 요구사항을 전달받았을 때 단순하게 생각했습니다. "공인 IP가 있으니 포트만 열어주면 되겠네"

일반적인 소규모 개발 환경이라면 구조가 매우 직관적입니다. 인터넷 → 공인IP → 공유기 → PC 또는 서버로 이어지는 단순한 흐름입니다. 그렇기에 저 역시 자연스럽게 포트 포워딩(Port Forwarding), DDNS(ipTime 등), 혹은 사내 방화벽 설정 정도만 만지면 해결될 것으로 판단했었습니다. 그런데... 현재 프로젝트의 네트워크는 제 생각보다 복잡한 구조였습니다.

 

다중 내부망의 장벽

프로젝트의 네트워크를 확인헸는데 현재 개발 서버가 단순한 사설망이 아니라 '다중 내부망(Multi-layered NAT)' 환경의 가장 깊숙한 안쪽에 위치해 있다는 점이었습니다. 외부 인터넷 망과 우리 개발서버 사이에는 건물 메인 라우터, 사내 보안 방화벽, 팀 내부 공유기 등 수많은 네트워크 장비 계층이 겹겹이 샌드위치처럼 쌓여 있었습니다. 게다가 그중 상당수는 제가 권한을 가지고 직접 제어할 수 없는 영역이었습니다. 결국 인바운드(외부에서 내부로 들어오는) 트래픽을 허용하기 위한 단순한 포트 포워딩이나 DDNS 방식으로는 통신을 뚫을 수 없는 구조였습니다.

 

서버실 장비 이동

장비를 전용 서버실로 이전하는 방안도 검토했습니다. 서버실에는 외부 공개가 가능한 독립된 네트워크 라인과 방화벽 환경이 이미 구축되어 있었기 때문입니다. 하지만 여기서 또 다른 트레이드오프가 발생했습니다. 현재 프로젝트 개발팀과 DB팀은 내부망 환경에서 개발 서버에 접속하며 쾌적하게 작업하고 있는데, 장비를 서버실로 이전하면 정작 매일 코드를 고치는 내부 직원들이 외부망을 돌거나 VPN을 사용해 접근해야하므로 개발 환경이 되려 불편해질 수 있었습니다.

외부 협력사 공유를 위해 내부 직원들의 생산성을 희생하는 것이 과연 맞는 선택인가? 쉽게 결론을 내리기 쉽지 않았습니다.

 

터널(Tunnel)

내부 생산성도 지키고 외부망도 열어줄 수 있는 다른 방법을 찾던 중 "터널(Tunnel)" 방식의 네트워크 접근법을 활용한 솔루션을 찾게되었습니다. 외부에서 내부로 들어오는 포트를 열지않고(Inbound) 내부 서버가 신뢰할 수 있는 외부 클라우드 서비스와 먼저 안전한 연결(Outbound)을 맺고 외부 사용자는 그 중계 서버를 타고 역으로 들어오는 방식입니다.

이 구조라면 다중 내무망에 갇혀 있어도 아웃바운드 인터넷만 작동한다면 포트 개방 없이 완벽하게 서비스를 제공할 수 있겠다는 확신이 들었습니다. 많은 제품들이 있지만 세 가지 솔루션을 검토했습니다.

• Pinggy
• Ngrok
• Cloudflare Tunnel

 

최종 선택은 Cloudflare Tunnel

처음에는 별도의 설치 과정 없이 CLI 명령어 한줄로 작동하는 Pinggy를 가장 유력하게 검토했습니다. 사용법이 정말 극도로 단순했기 때문입니다. 또한 설치를 하지 않아도 된다는 것이 보안적으로는 조금 더 좋다고 판단했습니다. 하지만 무료 버전에서는 세션이 끊길 때마다 접속 URL이 무작위로 바뀌어 고정된 주소가 필요한 프로젝트 환경에는 치명적인 결격 사유가 있었습니다. 가장 대중적인 Ngrok 역시 무료 플랜에서의 도메인 제약이 아쉬웠습니다. 결국 기업용 인프라로서의 안정성, 비용, 그리고 결정적으로 개인도메인만 있다면 서브도메인 기반의 고정 라우팅을 개수 제한 없이 무료로 제공하는 Cloudflare Tunnel을 최종 선택하게 되었습니다.

 

 현재 진행 상황 / 앞으로의 계획 그리고 보너스

✔️ 가비아 도메인 구매부터 Cloudflare 네임서버 이관

✔️ 내부 서버에 cloudflare 설치

✔️ Cloudflare Tunnel 대시보드 구성

✔️ 내부 WAS(Tomcat) 서버 외부 공개

❔ 다중 네트워크 이해하기 글 작성

❔ 외부 연결 솔루션 3종 비교

❔ 도메인 구매부터 네임서버 이관 가이드

❔ Cloudflare Tunnel 실전 : 대시보드 설정 및 로컬 서버

🎁 내부 DB(PostgreSQL) 서버 외부 공개

🎁 내부 DB Zero Trust(Cloudflare 기능) 적용

 

삽질도 해본 사람이 잘한다
직접 부딪히고 깨지는 과장이야말로 개발자가 가장 빠르게 성장하는 지름길이라 믿습니다.
다만 그 삽질이 시간이 걸립니다. 비즈니스의 속도를 맞춰야 하는 실무 환경에서 마냥 삽질만 하고 있을 수가 없습니다. 그래서 제 작은 삽질의 기록들을 이곳에 남겨두려고 합니다. 지금 이 순간에도 복잡한 네트워크 환경이라는 벽 앞에서 모니터를 붙잡고 씨름하고 계실 수많은 동료 개발자분들께 
이 글이 길을 찾아주는 따뜻한 이정표가 되기를 바랍니다.