[#1] Nginx 리버스 프록시(reverse proxy)

계기

 

배포 흐름에 대한 공부를 하는데

내가 한 배포 과정에서 http->https로 보안 설정을 해주기 위해서 도메인을 구매했고, 도메인을 구매한 후 이를 통해 SSL(?) 인증서를 발급받아 Nginx 엔진이라는것을 다운받았다고 기억한다.(아닐 수 있다 용어에 대한 정리와 공부가 진행 중이다.)

 

그런 과정을 지피티는 아래와 같이 표현했다.

 

GitHub → Actions 빌드/푸시 → EC2 Docker run → Nginx 리버스 프록시

 

 

근데 여기서 Nginx 리버스 프록시가 뭔지 모르겠어서 알아보았다.

---

1, 프록시란?

 

 

• 프록시 서버는 클라이언트(사용자)와 실제 서버(백엔드) 사이에 중간에서 요청과 응답을 대신 처리하는 서버예요.
• 프록시에는 두 가지가 있어요:
  1. Forward Proxy (순방향 프록시)
     → 클라이언트가 직접 서버에 접근하지 않고, 프록시가 대신 요청을 보냄. (예: 회사 내부망에서 인터넷 접속할 때 보안·검열용 프록시)
  2. Reverse Proxy (역방향 프록시)
     → 클라이언트는 프록시만 보고 실제 서버는 숨겨짐. 프록시가 내부 여러 서버로 요청을 분배하거나 보안·캐싱을 담당.

이렇다고 하는데 확 와닿지 않았다.

그래서 이미지를 검색해봤는데 아래와 같았다.

출처: https://www.cloudflare.com/ko-kr/learning/cdn/glossary/reverse-proxy/

 

여기서 궁금했던 점은 이거다.

 

요청과 응답을 왜 대신 처리하지?
데이터 요청 응답이면 네트워크 7계층이랑 관련이 있는건가?

 

 

(리버스)프록시가 직접 요청을 받아서 내부 서버로 전달하고, 응답을 다시 클라이언트에 주는 구조를 쓰틑 이유는 크게 4가지가 있었다.

1. 보안
   • 클라이언트는 실제 서버 IP/포트를 몰라요. 외부에 노출되는 건 프록시뿐이므로 내부 서버 보호 효과.
   • SSL/TLS(HTTPS) 인증서도 프록시 한 곳에만 설치 → 관리 효율↑.
2. 부하 분산(로드 밸런싱)
   • 하나의 도메인으로 요청을 받고, 여러 애플리케이션 서버에 분산시켜 성능 개선.
3. 캐싱/속도 개선
   • 이미지, CSS 같은 정적 자원은 Nginx가 대신 제공 → 백엔드 서버 부담 감소.
4. 단일 진입점
   • 여러 서버(API 서버, 파일 서버 등)를 하나의 도메인으로 통합해 외부엔 일관된 서비스처럼 보이게 함.

즉, 클라이언트 입장에서는 오직 프록시만 바라보면 되고, 내부 서버들은 뒤에서만 일하는 구조였다.

 

---

또한 리버스 프록시는 L7 프록시에 속하고 이는 애클리케이션 계측에 속한다고 한다.

왜냐하면 HTTP/HTTPS 같은 애플리케이션 계층 프로토콜을 이해하고, 그 내용을 바탕으로 라우팅·필터링하기 때문이다.

 

L7 프록시 (애플리케이션 계층, HTTP 기반)

• URL, 헤더, 쿠키 같은 HTTP 정보를 보고 라우팅 결정 가능
• Nginx 리버스 프록시는 바로 이 역할을 함.

👉 그래서 Nginx 리버스 프록시는 HTTP 요청을 해석하고, 어디로 보낼지 정한 뒤 응답도 대신 클라이언트로 반환하는 구조이다.

[클라이언트 브라우저] 
        ↓ (HTTP 요청)
[Nginx Reverse Proxy]  ← (보안, 로드밸런싱, 캐싱)
        ↓ (내부 전달)
[백엔드 서버 (예: Spring Boot)]
        ↑ (응답)
[Nginx Reverse Proxy]
        ↑ (응답 전달)
[클라이언트 브라우저]

 

---

2, Nginx 리버스 프록시의 역할

 

Nginx는 웹 서버이자 리버스 프록시 역할을 자주 맡는다.

대표적인 기능은 아래와 같다.

🔹 요청 분배 (Load Balancing)

• 클라이언트가 www.example.com으로 요청을 보내면,
• Nginx가 이를 받아 내부의 여러 애플리케이션 서버(:8080, :8081 등)로 나눠 전달.

🔹 보안 강화

• 클라이언트는 실제 서버 주소(IP, 포트)를 알 수 없고 오직 Nginx만 보게 됨 → 서버 보호 효과.
• SSL/TLS(HTTPS) 인증서도 Nginx에만 설치하면 됨 → 백엔드 서버는 단순 HTTP로 운영 가능.

🔹 캐싱 & 성능 향상

• 정적 파일(css, js, 이미지)을 Nginx가 직접 제공 → 애플리케이션 서버 부하 감소.
• 자주 요청되는 데이터를 캐싱해서 응답 속도 향상.

🔹 단일 진입점 (Gateway)

• 여러 서비스(API 서버, 웹 서버, 마이크로서비스)를 하나의 도메인으로 묶어서 노출.
  예:
  • api.example.com → Spring Boot 서버
  • static.example.com → 정적 리소스 서버

 

---

server {
    listen 80;

    server_name example.com;

    location / {
        proxy_pass http://localhost:8080;   # 실제 백엔드(Spring Boot)로 요청 전달
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

여기서 example.com으로 들어온 요청은 Nginx가 받아서 localhost:8080으로 넘겨준다.
그렇기에 사용자는 8080 포트를 전혀 몰라도 문제가 없다.

 

---

위 내용을 공부하며 알게 된 점을 정리하자면

 

1, 프록시는 어느 서버로 보낼지를 결정하지만 요청을 실제로 실행하는것은 톰캣(스프링 부트 코드 구동)이다.

톰캣은 스프링부트 코드를 웹 서버처럼 실행시켜주는 자바 기반 애플리케이션 서버이고,

이는 즉 톰캣이 스프링 부트 코드가 웹 서버로 동작할 수 있도록 실행 환경을 제공한다는 것이다.

프록시는 톰캣 앞단에서 외부 트래픽을 정리-보안-분배하는 역할을 한다.

[클라이언트 브라우저]
       ↓
   (리버스 프록시)
   [Nginx]  ← 요청을 받아 "어느 서버로 보낼지" 결정
       ↓
   [Tomcat] ← 요청을 실제 실행 (스프링 부트 코드 구동)
       ↓
[Spring Controller / Service / Repository ...]

 

2, 일반적으로 인텔리제이가 스프링 부트 애플리케이션을 직접 실행한다.

프록시 역할을 대신하는게 아니라 단순하게 http://localhost:8080로 바로 접근이 가능하게 된다.

자연스럽게 중간에서 트래픽을 받아주는 프록시가 필요가 없어지는 것이다.

 

EC2 같은 클라우드 서버 환경에서는 도커 컨테이너가 여러 개 뜨고, 각각 다른 포트에서 동작한다.

외부 사용자는 이 내부 구조를 알 수 없으니, Nginx 같은 리버스 프록시가 앞단에서 요청을 받아 내부 컨테이너로 라우팅해줘야 한다.

그 역할을 맡는 다양한 리버스 프록시 중 하나가 nginx이고 이는 대표적인 선택지일 뿐, Apache, HAProxy, Traefik 같은 다른 리버스 프록시도 같은 역할을 할 수 있다.

 

---

마지막으로 좀 더 들어가보면, 다음과 같은 질문이 생긴다.

 

그럼 Apache, HAProxy, Traefik 같은 다른 리버스 프록시도 같은 역할을 할 수 있는데
왜 Nginx 를 쓰는 거지?

 

 

이에 대한 답은

1. 성능 (가장 큰 이유)

• 이벤트 기반, 비동기 처리 모델을 사용 → 동시에 수만 개의 연결을 처리할 수 있음.
• Apache는 전통적으로 스레드/프로세스 기반이라 연결이 많아지면 메모리 사용량이 급격히 늘어남.
• 결과적으로 가볍고 빠르며 메모리 효율이 좋아서 트래픽이 많은 서비스에서 선호됨.

---

2. 설정과 사용 편의성

• proxy_pass, server_name, location 같은 직관적인 설정 문법 → 러닝커브가 낮음.
• 리버스 프록시 + 정적 파일 서버 + SSL 적용까지 짧은 설정 파일로 가능.
• Apache는 기능은 풍부하지만 설정이 복잡하고 무겁다는 단점.

---

3. 정적 리소스 처리 강점

• 이미지, CSS, JS 같은 파일은 Nginx가 직접 캐싱 후 서빙 → 애플리케이션 서버 부하 줄여줌.
• CDN 비슷하게 동작할 수 있어서 웹 성능 개선에 유리.

---

4. 생태계 & 커뮤니티

• Nginx는 전 세계에서 가장 많이 쓰이는 웹 서버/리버스 프록시 (특히 클라우드/컨테이너 환경).
• 구글링하면 해결책이 넘쳐남 → 학습·문제 해결 속도가 빠름.
• Docker, Kubernetes 등 최신 DevOps 환경에서도 표준처럼 쓰임.

---

5. 대안들과 비교

리버스 프록시장점단점

Nginx	가볍고 빠름, 설정 간단, 정적 파일/SSL에 최적	동적 모듈 로딩 불가(재컴파일 필요, 최근엔 Nginx Unit이 보완)
Apache	오래된 전통, 모듈 많음, 유연성 ↑	메모리 사용량 높음, 설정 복잡
HAProxy	고성능 L4/L7 로드밸런서, 트래픽 분산 특화	정적 파일 처리 불가, 웹서버 기능 없음
Traefik	도커/K8s와 자동 연동, 마이크로서비스에 적합	학습 자료는 Nginx보다 적음

👉 즉, 범용성 + 성능 + 쉬운 설정 때문에 “기본값”처럼 Nginx가 많이 쓰이는 거예요.

 

 

이번 글에서 잘 모랐던 단어는 다음과 같다.

DevOps 환경

비동기 처리 모델

러닝커브

SSL

CDN

동적 모듈 로딩 불가

로드밸런서

마이크로서비스

스레드/프로세스