• 목록

구성도에서 로드밸런서와 리버스 프록시가 모두 서버 앞에 놓여 있으면 같은 장비인지 궁금해집니다. 두 용어는 겹칠 수 있지만 설명하는 역할이 다릅니다.

요청을 대신 받아 전달하는 위치와 여러 대상 중 하나를 고르는 기능을 나누어 이해하면 구성이 한결 명확해집니다.

AI 생성 삽화 · 로드밸런서와 리버스 프록시, 요청이 지나가는 위치 이해하기 주제를 설명하는 이미지입니다.

핵심 정리
리버스 프록시는 서버 쪽에서 요청을 받아 뒤의 서버로 전달하는 역할을 설명합니다. 로드밸런싱은 여러 처리 대상에 트래픽을 분배하는 기능이며 하나의 구성 요소가 두 역할을 수행할 수 있습니다.

1. 장비 이름보다 요청 경로를 먼저 그립니다

브라우저가 접속한 주소와 실제 애플리케이션이 실행되는 서버가 같을 필요는 없습니다. 앞단에서 요청을 받은 구성 요소가 뒤의 서버로 전달하고 응답을 돌려줄 수 있습니다.

NGINX의 리버스 프록시 문서는 이러한 전달을 설정하는 방법을 설명합니다. 구성도를 볼 때는 사용자가 어느 주소에 접속하는지와 다음 연결이 어디로 향하는지를 먼저 표시합니다.

제품 로고만 나열하면 같은 제품이 서로 다른 역할로 쓰이는 상황을 구분하기 어렵습니다. 학습용 그림에는 사용자, 앞단, 애플리케이션처럼 역할 이름을 붙여도 충분합니다.

실제 운영 구성에는 캐시나 추가 게이트웨이가 있을 수 있지만 첫 설명부터 모두 한 상자로 합칠 필요는 없습니다. 요청 하나를 따라가며 각 지점이 무엇을 받았고 어디로 보냈는지를 확인하는 방식으로 범위를 넓혀 갑니다.

2. 리버스 프록시는 전달 역할을 설명합니다

리버스 프록시 뒤에 서버가 한 대만 있어도 요청을 받아 전달하는 역할은 성립합니다. 따라서 뒤에 서버가 여러 대인지 여부만으로 리버스 프록시를 정의하기는 어렵습니다.

NGINX 문서에서는 특정 주소로 전달하는 구성과 서버 그룹으로 전달하는 구성을 모두 설명합니다. 앞단이 어떤 요청을 어떤 대상으로 보낼지는 설정에 달려 있습니다.

학습할 때는 프록시가 있다는 사실과 적용된 라우팅 규칙을 나누어 기록하면 좋습니다. 가상 서비스에서 소개 페이지는 한 서버로, 내부 API는 다른 서버로 보내는 구성을 생각해 볼 수 있습니다.

이 예시는 가능한 역할 분리를 설명하는 것이며 특정 설정을 그대로 적용하라는 안내는 아닙니다. 실제 경로와 헤더 처리 방식은 사용하는 서버의 문서를 확인해야 합니다.

앞단을 추가했다고 모든 애플리케이션 설정이 자동으로 맞춰지는 것은 아닙니다.

3. 로드밸런싱은 대상 선택의 기준이 중요합니다

같은 역할을 수행하는 서버가 여러 대라면 어떤 서버로 요청을 보낼지 정하는 기능이 필요합니다. NGINX의 HTTP 로드밸런싱 문서는 순환 분배나 연결 수 등을 고려하는 방법을 설명합니다.

어떤 방법을 쓴다고 모든 서버의 CPU 사용률이 항상 같아지는 것은 아닙니다. 요청마다 처리 비용이 다를 수 있으므로 무엇을 기준으로 분배하는지 이해해야 합니다.

가상으로 짧은 조회와 오래 걸리는 보고서 요청이 섞인 서비스를 생각해 볼 수 있습니다. 요청 개수가 같아도 실제 처리 부담이 같다고 단정하기 어렵습니다.

구성 검토에서는 분배 규칙과 관찰 지표를 함께 적습니다. 장비가 로드밸런서라는 이름으로 배치되어 있다는 사실보다 어떤 대상 그룹과 규칙을 사용하는지가 실제 동작을 설명합니다.

특정 방법이 항상 최선이라고 외우기보다 서비스의 요청 특성과 맞춰 봅니다.

4. 한 구성 요소가 두 역할을 맡을 수 있습니다

리버스 프록시가 서버 그룹으로 요청을 전달하면서 그 안에서 대상을 고르면 로드밸런싱 기능도 수행하는 구성이 됩니다. 따라서 두 용어를 서로 배타적인 제품 종류로 이해하면 같은 구성 요소를 설명하는 문서가 모순처럼 보일 수 있습니다.

NGINX 문서도 리버스 프록시의 활용 중 하나로 로드밸런싱을 연결합니다. 반대로 로드밸런싱은 HTTP만의 기능은 아닙니다.

공식 문서에는 TCP와 UDP 트래픽을 대상으로 하는 전송 계층의 구성도 있습니다. 이 경우 HTTP 경로를 기준으로 분기하는 설명을 그대로 적용하면 안 됩니다.

학습 노트에는 처리하는 프로토콜과 대상 선택 기준을 함께 적으면 좋습니다. 같은 앞단이라는 위치만 보고 모든 기능을 가정하지 않고 실제 지원 기능과 설정을 확인하는 습관이 필요합니다.

5. 추가 기능은 별도 설정으로 확인합니다

앞단 구성 요소가 있다고 암호화 종료나 인증, 캐시, 장애 대응이 모두 활성화되는 것은 아닙니다. 설계 문서에는 현재 어떤 기능을 어느 지점이 담당하는지 따로 적는 편이 좋습니다.

이 글은 특정 제품의 모든 기본값을 설명하는 내용이 아니므로 실제 설정과 해당 버전의 문서를 확인해야 합니다. 가상 구성에서 앞단은 전달만 하고 인증은 애플리케이션이 맡을 수 있습니다.

다른 구성에서는 별도 인증 계층을 둘 수도 있습니다. 이런 차이를 제품 이름 하나로 숨기지 않는 것이 중요합니다.

장애 상황을 검토할 때도 대상 서버를 제외하는 조건이 무엇인지 질문합니다. 로드밸런서가 있으니 고장 난 서버를 언제나 즉시 알아낸다고 추측하지 않습니다.

연결과 응답을 어디서 어떻게 관찰하는지, 실패한 요청을 어떤 정책으로 다루는지가 실제 검토 대상입니다.

6. 가상 요청 하나로 구성도를 점검합니다

가령 사용자가 상품 목록을 조회하고 앞단이 두 애플리케이션 서버 중 하나로 전달하는 상황을 가정합니다. 사용자에게 보이는 주소, 앞단에서 선택한 서버, 응답이 돌아오는 경로를 차례로 적습니다.

다음에는 관리 페이지 요청도 같은 경로를 쓰는지 살펴봅니다. 이는 실제 서비스 구조나 성능 수치를 제시하는 예가 아닙니다.

그림에 있는 화살표마다 프로토콜과 담당 역할을 적어 보면 빠진 설명이 드러납니다. 서버가 한 대 더 추가되었을 때 대상 그룹을 누가 갱신하는지도 질문할 수 있습니다.

한 요청이 실패했을 때 어느 구간에서 문제가 났는지 알려면 각 단계의 기록을 연결할 방법이 필요합니다. 구성도를 발표할 때는 제품을 설치했다는 설명에서 끝내지 말고 요청이 어떤 규칙으로 이동하는지 보여 주는 것이 이해에 도움이 됩니다.

7. 운영 기록은 역할별로 나누어 읽습니다

앞단의 응답 시간과 애플리케이션 내부 처리 시간은 같은 구간을 측정한 값인지 먼저 확인합니다. 서로 다른 구간의 숫자를 바로 비교해 어느 서버가 느리다고 단정하지 않습니다.

어느 대상에 요청이 전달되었는지와 그 대상의 결과를 연결하면 문제를 좁히기 쉽습니다. 학습 단계에서는 정상 요청과 실패 요청을 각각 한 개씩 가상으로 따라가 보는 연습이 유용합니다.

앞단까지 도달하지 못한 경우와 뒤의 서버에서 실패한 경우를 구분해 설명해 봅니다. 설정 변경 전후에는 대상 그룹과 라우팅 규칙이 어떻게 달라졌는지도 남깁니다.

로드밸런서와 리버스 프록시를 이해했다는 것은 용어의 차이를 말하는 것뿐 아니라 같은 구성 요소가 어떤 역할을 맡고 있는지 설명할 수 있다는 뜻입니다. 실제 운영에서는 제품 문서와 현재 설정을 함께 읽어 이 설명을 검증합니다.

8. 자주 묻는 질문

Q1. 뒤에 서버가 한 대여도 리버스 프록시인가요?

요청을 받아 뒤의 서버로 전달하는 역할은 한 대를 대상으로도 구성할 수 있습니다. 여러 서버에 분배하는 기능이 있는지는 별도로 확인합니다.

Q2. NGINX는 프록시인가요, 로드밸런서인가요?

설정에 따라 두 역할을 함께 수행할 수 있습니다. 제품 이름보다 요청 전달 대상과 분배 규칙을 보면 해당 구성의 역할을 알기 쉽습니다.

Q3. 로드밸런서는 모두 URL을 보고 분배하나요?

그렇지 않습니다. 전송 계층의 트래픽 분배도 있으므로 처리 프로토콜과 적용된 규칙을 확인해야 합니다.

Q4. 로드밸런서를 두면 장애가 자동으로 해결되나요?

이름만으로 장애 대응을 보장할 수는 없습니다. 상태 확인과 대상 제외, 실패 요청 처리 정책이 어떻게 구성되어 있는지 살펴봐야 합니다.

참고 자료

• NGINX: Reverse Proxy
• NGINX: HTTP Load Balancing
• NGINX: TCP and UDP Load Balancing