프록시
포워드 프록시
: 클라이언트 (사용자)를 대리하는 프록시다.
사용자가 인터넷(예 : google.com)에 직접 접속하는 것이 아니라, 중간에 있는 포워드 프록시 서버에게 요청을 보내면, 그 프록시 서버가 사용자를 대신해서 google.com에 접속하고 결과를 사용자에게 돌려주는 방식이다.
포워드 프록시 : 해외 직구를 대신해주는 '구매 대행' 업체 또는 심부름꾼
사용자 : 구매 대행을 요청한 고객
인터넷 서버 : 물건을 파는 해외 쇼핑몰
포워드 프록시의 주요 목적
보안 및 익명성 (Security & Anonymity):
내부 클라이언트(사용자)의 IP 주소를 감출 수 있다. 외부 서버는 오직 프록시 서버의 IP 주소만 볼 수 있기 때문에, 내부 사용자를 보호할 수 있다.
캐싱 (Caching):
여러 사용자가 동일한 웹사이트나 파일을 요청할 경우, 프록시 서버가 그 내용을 저장(캐싱)해 둔다. 그 후 다른 사용자가 같은 요청을 하면, 인터넷까지 나가지 않고 프록시 서버가 바로 응답해 주므로 속도가 향상되고 네트워크 트래픽이 감소한다.
접근 제어 및 필터링 (Access Control & Filtering):
회사나 학교에서 가장 많이 사용하는 목적이다. 프록시 서버에서 특정 사이트로의 접근을 막거나, 유해 콘텐츠를 필터링하는 정책을 적용할 수 있다.
우회 접속:
특정 국가에서 차단된 사이트에 접속하기 위해, 접속이 허용된 다른 국가에 있는 포워드 프록시를 통해 우회하는 용도로도 사용한다.
개인 사용자가 직접 설정하는 경우
개인이 익명성 확보나 우회 접속 등을 위해 프록시 서비스를 유료/무료로 구독하여 사용하는 경우입니다.
운영체제(OS) 설정:
Windows: 설정 > 네트워크 및 인터넷 > 프록시
macOS: 시스템 설정 > 네트워크 > Wi-Fi (또는 이더넷) > 세부사항 > 프록시
여기에 프록시 제공업체로부터 받은 서버 주소(IP 또는 도메인)와 포트 번호를 직접 입력합니다. 이렇게 하면 OS의 모든 네트워크 요청이 이 프록시를 통하게 됩니다.
웹 브라우저 설정:
Chrome, Edge, Firefox 등 웹 브라우저 자체에도 프록시를 설정하는 기능이 있습니다. OS 설정과 별개로 특정 브라우저의 트래픽만 프록시를 통하도록 할 수 있습니다.
회사/학교 등 조직에서 설정하는 경우 (가장 흔한 경우)
조직의 보안 정책이나 네트워크 효율을 위해 관리자가 내부 사용자들의 프록시 사용을 강제하거나 유도합니다.
수동 설정 안내: IT 관리자가 "모든 직원은 PC 네트워크 설정에서 프록시 서버 주소를 proxy.my-company.com, 포트는 8080으로 설정하세요" 와 같이 가이드를 제공합니다.
자동 설정 (PAC, WPAD):
사용자가 일일이 주소를 입력하는 것은 번거롭고 실수가 잦습니다.
그래서 관리자는 PAC (Proxy Auto-Config) 라는 스크립트 파일의 주소를 알려줍니다. (예: http://proxy.my-company.com/proxy.pac)
사용자는 이 스크립트 주소 하나만 설정에 입력하면, 스크립트 안에 있는 규칙(예: '내부망 접속은 프록시 없이 직접 연결', '외부 인터넷 접속은 프록시 경유')에 따라 브라우저가 알아서 최적의 경로를 선택합니다.
투명 프록시 (Transparent Proxy):
가장 발전된 방식으로, 사용자는 자신이 프록시를 쓰고 있다는 사실조차 모릅니다.
네트워크 게이트웨이(공유기, 방화벽 등)단에서 모든 웹 트래픽(80, 443 포트)을 강제로 프록시 서버로 돌려버립니다.
사용자 입장에서는 아무 설정도 하지 않았지만, 실제로는 포워드 프록시를 통해 인터넷을 사용하고 있는 것입니다.
리버스 프록시
리버스 프록시 (Nginx) : 회사의 대표 전화번호(ARS)나 안내 데스크 직원
내부 서버 (WAS) : 실제 업무를 처리하는 각 부서의 직원들 (개발팀, 인사팀, 회계팀)
고객(사용자)는 회사의 대표 번호로만 전화를 걸 뿐, 내부 직원들의 직통 번호를 알지도 못하고 알 필요도 없다. 안내 데스크 직원이 고객의 요청에 맞는 부서로 전화를 연결해주는 것과 같다.
로드 밸런싱 (Load Balancing) :
수많은 사용자 요청을 여러 대의 내부 서버(WAS)에 골고루 분산시켜준다. 한 서버에 트래픽이 몰려 다운되는 것을 막아 서비스 안정성을 높인다. (가장 중요한 기능)
보안 (Security) :
사용자는 실제 서버의 IP 주소나 포트 정보를 전혀 알 수 없고, 오직 Nginx의 주소만 알게 된다. 이로써 내부 서버를 외부에 숨기는 방화벽 역할을 수행한다.
SSL/TLS 암호화 처리 (SSL Termination) :
HTTPS 통신을 위한 복잡한 암호화/복호화 과정을 Nginx가 전담하고, 내부 서버와는 암호화되지 않은 HTTP 통신을 하게 할 수 있다. 이를 통해 내부 서버는 비즈니스 로직 처리에만 집중할 수 있어 부하가 줄어든다.
정적 파일 처리 (Serving Static Files) :
이미지 , CSS, JavaScript 파일 같은 정적 파일 (static Contents)은 내부 서버까지 요청을 보내지 않고, Nginx가 직접 매우 빠른 속도로 사용자에게 전달해준다. 이는 웹사이트의 로딩 속도를 크게 향상 시킨다.
캐싱 (Caching) :
자주 요청되는 콘텐츠를 Nginx 가 잠시 저장(캐싱) 해 두었다가, 동일한 요청이 오면 내부 서버에 묻지 않고 즉시 응답하여 속도를 높인다.
Nginx의 또 다른 역할 : 웹 서버 (Web Server)
Nginx는 리버스 프록시 기능 이전에 매우 가볍고 성능이 뛰어난 웹 서버로 시작했습니다. Apache와 같은 전통적인 웹 서버보다 적은 자원으로 더 많은 동시 접속을 처리할 수 있는 능력(이벤트 기반 구조) 덕분에 큰 인기를 얻었습니다.
결론부터 말씀드리면, Tomcat과 Nginx는 같은 모양이 아니며, 서로 다른 핵심 역할을 수행하는 파트너에 가깝습니다. 그리고 질문하신 "웹 서버와 WAS 두 계층이 존재하는가?"에 대한 답은 "네, Tomcat 안에 웹 서버 기능이 내장되어 있습니다" 입니다.
이 개념을 식당에 비유해서 설명해 드리겠습니다.
Nginx (웹 서버, 리버스 프록시): 식당의 안내 데스크 직원(또는 지배인)
Tomcat (WAS): 식당의 주방과 요리사
Spring Application: 요리사의 레시피
Tomcat은 무엇인가? (주방과 요리사)
Tomcat은 WAS(Web Application Server) 입니다. WAS의 핵심 역할은 동적인 콘텐츠(Dynamic Contents)를 생성하는 것입니다.
동적 콘텐츠란? 사용자의 요청에 따라, 데이터베이스 조회, 비즈니스 로직 수행 등 프로그램 코드를 실행해야만 만들어지는 결과물입니다. (예: 로그인 결과, 게시판 글 목록, 주문 내역 등)
Tomcat은 Java로 만든 웹 애플리케이션(Spring 등)을 실행시켜주는 환경, 즉 'Java 코드를 돌려서 동적인 웹페이지나 API 응답을 만들어내는 전문 서버' 입니다.
"웹 서버와 WAS 두 계층이 존재하나?" 라는 질문에 대한 답: 네, Tomcat 안에는 'Coyote'라는 웹 서버 기능이 내장되어 있습니다. 그래서 Tomcat은 스스로 HTTP 요청을 직접 받고 응답할 수 있습니다. 즉, Tomcat 하나만으로도 웹 서버와 WAS의 역할을 동시에 수행할 수 있습니다.
Nginx는 무엇인가? (안내 데스크 직원)
Nginx는 주로 웹 서버(Web Server) 또는 리버스 프록시(Reverse Proxy) 역할을 합니다.
웹 서버 역할: 이미지, CSS, JavaScript 파일처럼 미리 만들어져 있는 정적 파일(Static Contents)을 매우 빠르고 효율적으로 전달합니다. 주방까지 갈 필요 없이 안내 데스크에서 바로 처리할 수 있는 간단한 요청(물수건, 메뉴판 전달 등)과 같습니다.
리버스 프록시 역할: 손님(사용자)의 요청을 받아서, 어떤 주방(Tomcat 서버)이 가장 한가한지 보고 요청을 적절하게 분배(로드 밸런싱)해줍니다. 또한, 이상한 손님을 막아주는 보안(방화벽) 역할도 합니다.
왜 Nginx와 Tomcat을 함께 사용하는가? (역할 분담의 효율성)
개발할 때나 소규모 서비스에서는 Spring Boot에 내장된 Tomcat 하나만으로도 충분히 웹 서비스를 운영할 수 있습니다.
[개발 환경 / 소규모 서비스] 사용자 <---> Tomcat (웹서버 + WAS 역할 모두 수행)
하지만 트래픽이 많아지는 실제 운영 환경에서는 Nginx를 Tomcat 앞에 두어 역할을 분담하는 것이 훨씬 효율적이고 안정적입니다.
[운영 환경 / 표준 아키텍처] 사용자 <---> Nginx (웹 서버/프록시) <---> Tomcat (WAS)
이렇게 역할을 분담했을 때의 장점:
성능 향상 (부하 분산):
정적 파일: 모든 이미지, CSS, JS 요청은 Nginx가 초고속으로 처리합니다. 비싼 인력인 요리사(Tomcat)에게 이런 자잘한 심부름을 시키지 않아도 됩니다.
동적 파일: 동적인 API 요청만 Nginx가 Tomcat으로 전달합니다. Tomcat은 자신의 본업인 '요리(비즈니스 로직 처리)'에만 집중할 수 있어 전체적인 성능이 올라갑니다.
안정성 확보 (로드 밸런싱 & Failover):
Nginx가 여러 대의 Tomcat 서버에게 요청을 골고루 나눠줄 수 있습니다. (로드 밸런싱)
만약 Tomcat 서버 한 대가 갑자기 죽어도, Nginx가 알아서 살아있는 다른 Tomcat 서버로만 요청을 보내주기 때문에 서비스 중단을 막을 수 있습니다.
보안 강화:
사용자는 Nginx의 존재만 알 뿐, 실제 비즈니스 로직이 동작하는 Tomcat 서버의 IP나 포트는 알 수 없습니다. 외부 공격으로부터 내부 서버를 보호하는 방화벽 역할을 합니다.
유연한 배포:
서비스를 업데이트할 때, Nginx의 연결만 잠시 끊고 새로운 버전의 Tomcat을 배포한 뒤 다시 연결하는 '무중단 배포'가 가능해집니다.
Last updated