웹/클라우드/인프라로 돌아가기
웹/클라우드/인프라신윤섭·2026년 6월 15일

nginx도 ngrok도 다 프록시였다 — VPN vs 프록시 실전 정리

공유

nginx도 ngrok도 다 프록시였다 — VPN vs 프록시 실전 정리

당신은 이미 프록시를 쓰고 있었다

nginx 설정 파일 어딘가에 이런 줄이 있을 거다.

location / {
    proxy_pass http://localhost:3000;
}

proxy_pass. 뭔가를 대신 전달한다는 뜻이다. 이게 프록시다.

ngrok으로 로컬 서버를 외부에 공개해본 적 있다면, 그것도 프록시다. Cloudflare로 도메인을 연결했다면, Cloudflare 자체가 프록시 역할을 한다. 이름이 다르고 용도가 달라 보이지만, 구조는 같다. 트래픽이 어딘가를 경유해서 간다.

그런데 VPN이 뭔지 묻는 사람은 많아도 "프록시가 뭔지" 정확히 아는 사람은 드물다. VPN 광고는 넘치고, 프록시는 보안 우회 도구처럼 여겨진다. 둘을 혼용하는 경우도 많다. 실제로는 목적과 작동 방식이 꽤 다른 도구들이다.

스크래퍼를 만들다 IP 차단을 당했는데, VPN을 써야 할지 프록시를 써야 할지 모르겠다면 이 글이 답이다. nginx 설정에 proxy_pass가 보이는데 이게 뭔지 감이 안 온다면 이 글이 답이다.

이번 글에서는 이 둘을 분리해서 설명한다. 개발자 입장에서, 실제로 언제 어떤 걸 써야 하는지 중심으로.


방향이 핵심이다 — 포워드 프록시 vs 리버스 프록시

프록시라는 단어는 "대신 행동하는 것"이라는 뜻이다. 그런데 대신 행동하는 방향이 두 가지다.

포워드 프록시 — 클라이언트 측 대리인

백화점에 쇼핑하러 가는데 얼굴이 알려진 셀럽이라서 직접 가기 싫다고 하자. 대리인을 보낸다. 백화점은 대리인 얼굴만 본다. 셀럽이 뭘 샀는지 알 수 없다.

포워드 프록시가 이 구조다. 클라이언트(나)가 직접 서버로 요청을 보내는 게 아니라, 프록시가 대신 보낸다. 서버 입장에서는 프록시 IP만 보인다. 클라이언트가 누군지 모른다.

회사나 학교 네트워크에서 특정 사이트가 막혀 있을 때, IT 부서가 운영하는 것도 포워드 프록시다. 반대로, 규제가 있는 국가에서 우회 접속에 쓰는 것도 같은 원리다.

리버스 프록시 — 서버 측 경비원

이번엔 반대다. 대기업 본사에 민원을 넣으려면 담당자 직통 번호가 없다. 대표 번호로 전화하면, 상담원이 받아서 적절한 부서로 연결해준다. 외부에서는 어느 직원이 일을 처리하는지 알 수 없다.

리버스 프록시가 이 구조다. 클라이언트는 프록시 서버로 요청을 보낸다. 뒤에 실제 서버가 몇 개 있는지, 어디서 응답을 만드는지 클라이언트는 모른다.

nginx의 proxy_pass가 바로 이거다. 외부에서 오는 80포트 요청을 받아서, 내부의 Node.js 서버(3000포트)나 Python 서버(8000포트)로 넘겨준다.

정리하면 이렇다.

누가 숨는가대표 예시
포워드 프록시클라이언트회사 방화벽, 우회 접속 도구
리버스 프록시서버nginx, Cloudflare, AWS ALB

VPN은 뭐가 다른가

프록시는 특정 앱의 트래픽 하나를 중간에서 처리한다. nginx는 웹 트래픽만 다룬다. 브라우저에 프록시 설정을 하면 브라우저 요청만 그쪽으로 간다.

VPN은 다르다.

VPN(Virtual Private Network)을 켜면 내 컴퓨터의 모든 네트워크 트래픽이 VPN 서버를 통해서 나간다. 브라우저든, Slack이든, curl이든, 게임 클라이언트든. OS 레벨에서 가상 네트워크 인터페이스를 만들고 전부 그쪽으로 밀어 넣는다.

지하 터널에 비유하면 쉽다. 포워드 프록시는 우체부를 대신 보내는 거고, VPN은 내가 타는 모든 이동 수단이 지하 터널로 들어가는 거다. 터널 밖에서는 내가 어디서 나타났는지, 어디로 가는지 볼 수 없다. 내용도 암호화되어 있어서 터널 안에서 뭘 나르는지도 모른다.

개발자가 VPN을 쓰는 실제 이유는 따로 있다.

첫째, 회사 내부 시스템 접근이다. DB, 내부 API, 관리 콘솔이 외부 IP에서 접근하지 못하도록 막혀 있을 때, VPN으로 회사 네트워크에 붙어서 내부망 취급을 받는다.

둘째, 지역 제한 테스트다. 서비스가 특정 국가에서만 동작하는지 확인하거나, CDN이 지역별로 다른 응답을 주는지 보고 싶을 때 VPN으로 해당 국가 서버로 잡는다.

셋째, 오픈 와이파이에서 안전하게 작업하는 것이다. 카페 네트워크는 같은 공유기를 쓰는 누군가가 패킷을 들여다볼 수 있다. VPN을 쓰면 암호화된 채로 나가서 중간에 누가 봐도 내용을 알 수 없다.


실전 시나리오 4가지

이론은 여기까지다. 실제 개발 상황에서 어떤 걸 쓰는지 보자.

시나리오 A: nginx로 백엔드 연결, Cloudflare로 도메인 붙이기

가장 흔한 배포 구조다.

사용자 → Cloudflare → nginx → Node.js 앱 (3000)

Cloudflare는 내 도메인 앞에서 요청을 받는다. DDoS 방어, HTTPS 처리, 캐시를 담당하고, 내 서버 IP를 숨긴다. 전형적인 리버스 프록시다.

nginx는 그다음 단계에서 또 한 번 리버스 프록시 역할을 한다. 80/443 포트로 들어오는 요청을 받아서 내부 앱으로 넘긴다.

server {
    listen 80;
    server_name myapp.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

여기서 VPN이 필요한 건 아니다. 이건 서버 설정 문제고, 리버스 프록시로 충분히 해결된다.

시나리오 B: ngrok으로 로컬 서버 공개

Cursor나 Claude Code로 뭔가 만들고 있는데, 모바일에서 테스트하거나 고객에게 잠깐 보여줘야 할 때 ngrok을 쓴다.

ngrok http 3000
# → https://abc123.ngrok-free.app 같은 주소 생성

이게 어떻게 동작하는지 많은 사람이 헷갈린다. ngrok은 VPN이 아니다. 내 컴퓨터와 ngrok 서버 사이에 터널을 뚫는데, 외부에서 보면 ngrok 서버로 요청이 간다. ngrok 서버가 그걸 받아서 터널을 통해 내 로컬로 전달한다. 응답은 반대 방향으로 간다.

구조를 그리면 이렇다.

외부 사용자 → ngrok 서버 → (터널) → 내 로컬 3000포트

ngrok 서버가 리버스 프록시 역할을 한다. 차이는 그 프록시가 내 서버에 있는 게 아니라 ngrok 클라우드에 있다는 것뿐이다.

시나리오 C: 스크래퍼를 만들었는데 IP 차단을 당했다

API를 크롤링하거나 웹 데이터를 수집하다가 429 Too Many Requests403 Forbidden이 뜨기 시작했다면, IP 기반 차단이다.

이때 VPN을 켜면 될 것 같지만, VPN은 IP를 하나로 바꿔줄 뿐이다. 새 IP로 계속 요청하다 보면 그 IP도 차단된다.

실제 해법은 **로테이팅 프록시 풀(rotating proxy pool)**이다. 요청마다 다른 IP를 쓰도록 프록시 서버 목록을 계속 바꿔가며 사용하는 방식이다. ScrapingAnt나 Bright Data 같은 서비스가 이걸 제공한다.

Python에서 쓰는 방법은 간단하다.

import requests

proxies = {
    "http": "http://user:pass@proxy.example.com:8080",
    "https": "http://user:pass@proxy.example.com:8080",
}

response = requests.get("https://target-site.com", proxies=proxies)

이 경우 프록시는 포워드 프록시다. 내 요청을 프록시가 대신 보내고, 타깃 서버는 프록시 IP만 본다.

시나리오 D: 회사나 학교 네트워크에서 특정 요청이 막힌다

사내망에서 npm install이 안 되거나, 특정 외부 API 호출이 안 된다면, 회사 네트워크에 포워드 프록시가 있을 가능성이 높다. 모든 외부 트래픽이 IT 부서 프록시를 통해서만 나가도록 설정된 거다.

이때는 환경변수로 프록시를 설정하면 대부분 해결된다.

export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,.company.internal

npm, curl, pip, node-fetch 등 대부분의 도구가 이 환경변수를 자동으로 읽는다. 주소는 IT 부서에 문의하면 알려준다.


자주 하는 오해 3가지

오해 1: "ngrok은 VPN이랑 비슷한 거 아냐?"

아니다. VPN은 내 기기의 모든 트래픽을 암호화해서 VPN 서버로 보낸다. ngrok은 내 로컬 포트 하나를 외부에 노출하는 터널이다. 방향도 다르고 목적도 다르다. ngrok은 서버를 공개하는 도구고, VPN은 클라이언트 트래픽을 숨기는 도구다.

오해 2: "VPN 켜면 스크래퍼 IP 차단 우회할 수 있다"

VPN을 켜면 IP가 하나 바뀔 뿐이다. 그 새 IP로 빠르게 요청하면 또 차단된다. 차단 우회에는 IP를 계속 교체해주는 로테이팅 프록시가 필요하다. VPN과 로테이팅 프록시는 목적 자체가 다른 도구다.

오해 3: "Cloudflare 쓰면 서버 보안 다 된 거 아냐?"

Cloudflare는 DDoS 방어와 WAF(웹 방화벽)를 제공하지만, 서버 보안의 전부가 아니다. Cloudflare는 HTTP/HTTPS 트래픽만 다룬다. SSH 포트는 Cloudflare가 관리하지 않는다. 서버 방화벽 설정, 패키지 업데이트, 인증 방식은 따로 챙겨야 한다.


상황별 빠른 참고표

상황쓸 것이유
백엔드를 도메인에 연결하고 싶다nginx 리버스 프록시포트 라우팅 + 서버 내부 구조 숨김
로컬 서버를 일시적으로 외부에 공개ngrok / Cloudflare Tunnel로컬 포트를 외부 URL로 연결하는 터널
스크래퍼 IP 차단 우회로테이팅 프록시 풀요청마다 다른 IP 사용
회사 네트워크에서 외부 요청 막힘HTTP_PROXY 환경변수사내 포워드 프록시 경유
카페 와이파이에서 안전하게 작업VPNOS 레벨 전체 트래픽 암호화
회사 내부망 시스템에 원격 접속VPN내부 네트워크 참가자 취급
지역별 서비스 동작 테스트VPN특정 국가 IP로 전환

마치며 — 광고와 현실 사이

VPN 광고를 보면 마치 인터넷 보안의 만능 해결사처럼 묘사된다. 틀린 말은 아닌데, 그 광고가 겨냥하는 사용자는 일반 소비자다. 공공 와이파이 쓰는 여행자, 지역 제한 콘텐츠를 보고 싶은 사람.

개발자 입장에서 VPN은 훨씬 구체적인 도구다. 회사 내부망에 붙기 위해, 또는 지역별 동작을 테스트하기 위해 쓰는 것이다. 배포한 서비스의 보안은 VPN이 아니라 리버스 프록시, 방화벽 규칙, 적절한 인증으로 설계한다.

nginx를 처음 설정할 때 proxy_pass가 뭔지 몰라서 넘어갔다면, 이제는 알 거다. 그게 리버스 프록시다. 당신은 이미 인프라 개념을 실무에서 쓰고 있었다.

YS

신윤섭

데이너스 대표 | AI 교육 & AX 컨설팅

81개 이상의 AI/AX 교육 과정을 설계하고, 50여 기업과 기관에서 강의했습니다. 강남세브란스, 삼성전자, 현대자동차 등 다양한 조직의 AI 역량 강화를 지원하고 있습니다.

AI 교육이 필요하신가요?

조직에 맞는 맞춤형 AI/AX 교육 프로그램을 설계해드립니다. 커리큘럼 상담부터 시작해보세요.

같은 주제의 다른 글