AWS 로드밸런서 실습을 하면서 볼 수 있었던 NGINX 화면.
문득 내가 지금까지 이론과 실습을 공부하긴 했는데 과연 내가 이걸 정말 알고 있는 것일까 라는 생각이 들면서
시간적으로 여유가 있는 상황에서 다시 한번 재정립을 해볼 필요가 있다고 결정을 내렸다.
현재 IT 비즈니스 자체 솔루션을 개발하는 것을 넘어, 검증된 다양한 기술들을 유기적으로 엮어 고객에게 최적의 솔루션을 제안하고
이를 통해 비즈니스 가치를 창출하는 것이 핵심이다.
따라서, 이번 기회를 통해 지금까지는 간단한 이론 설명과 실습위주로 진행 했다면 이제는 확실하게 정의를 내릴 수 있게 정리를 해볼려고 한다.
NGINX 란 무엇인가?
가볍고 높은 성능을 자랑하는 오픈소스 웹서버 이자, 백엔드 시스템을 보호하고 트래픽을 지휘하는 리버스 프록시 및 로드밸러스 이다.
단순히 HTML 화면을 띄워주는 것을 넘어 현대의 복잡한 멀티 티어 웹 인프라에서 트래픽을 가장 먼저 맞이하는 '최전방 문지기' 역할을 수행한다.
높은 성능과 안정성을 가지고 있기에 당연히 현재 가장 많이 사용되고 있는 웹서버이다.
아파치(Apache) 같은 웹 서버와 비교하면 더 빠르고 가볍고, 대규모 애플리케이션 처리에 적합하다는 장점이 있다.
먼저 NGINX를 더 완벽하게 이해하기 위해 관련된 4가지의 용어를 알아보자.
클라이언트 " 요청하는 손님 "
식당에 들어가서 손님이 음식을 주문한다. 여기서 손님은 클라이언트 이다.
IT 네트워크 환경에서 서비스를 이용하기 위해 네트워크 너머로 요청을 보내는 주체를 뜻한다.
크롬과 사파리.
위와 같은 웹 브라우저들이 바로 웹 생태계에서의 가장 대표적인 손님( 클라이언트 ) 들이다.
우리가 스마트폰으로 켜는 배달의민족 앱, 카카오톡 앱도 모두 클라이언트의 일종이라고 볼 수 있다.
웹서버 " 응답하는 제공자 "
클라이언트의 요청을 받아주는 웹 서버이다.
NGINX가 바로 이 웹 서버 생태계의 대장이라고 볼 수 있다.
손님( 클라이언트 )가 무언가를 요청하면, 그에 맞는 정적 파일(HTML 문서, css, 이미지 ) 등을 찾아서 응답 해주는 소프트웨어 입니다.
식당으로 치면 주문을 받고 만들어진 요리를 손님 테이블에 내어주는 안내데스크 직원, 홀서빙 직원과 같다.
현재 시장을 양분하고 있는 NGINX와 Apache가 있다. 이 외에도 마이크로소프트의 IIS , Lighttpd 등이 있다.
동작 흐름
요청: 사용자가 클라이언트( 크롬 , 사파리 ) 를 열고 리눅스/AWS의 IP 주소를 입력한 뒤 엔터를 친다.
클라이언트가 웹페이지 보여줘 라며 HTTP 통신을 보내게 된다.
수신 및 탐색: 인스턴스에 설치되어 있던 웹서버(NGINX)가 그 요청을 문 앞에서 받아낸다.
그리고 서버 내부 창고에 있던 index.html 파일을 꺼낸다.
응답: 웹서버(NGINX가 다시 클라이언트( 크롬 , 사파리 ) 에게 그 파일을 포장해서 던진다.
출력: 클라이언트 ( 크롬, 사파리 )가 받은 파일을 해석해서 우리 눈앞에 화면을 띄워준다.
WAS ( Web Application Server ) " 요리하는 주방장 "
웹서버 ( NGINX ) 가 만들어져 있는 정적 파일( HTML, 이미지 ) 을 가져다 주는 홀서빙 직원 이라면,
WAS는 고객의 주문에 맞춰 그때그때 지지고 볶아서 새로운 결과물을 만들어내는 주방장 이다.
사용자가 " 내 장바구니 목록 보여줘 " 또는 " 아이디와 비밀번호로 로그인해줘 " 라고 요청하면, 이건 미리 만들어둘 수 없는 데이터이다.
이때 WAS가 나서서 뒷단의 데이터베이스를 뒤지고, 비즈니스로직을 연산한 뒤 그 결과를 동적으로 만들어서 웹 서버에게 넘겨준다.
왜 웹서버와 WAS를 분리해서 사용해야할까?
1. 서버 부하 방지 : 무거운 비즈니스 로직을 처리해야하는 WAS가 단순 이미지 파일까지 서빙하게 두면 비효율적이다.
정적 서빙은 가벼운 NGINX에게 맡겨 역할을 분담하면 처리 속도가 훨씬 빨라진다.
2. 보안 강화 : 데이터베이스와 직접 연결된 WAS의 실제 IP를 외부에 노출하지 않고, 앞단의 NGINX가 대리인으로 트패픽을 받아줌으로써 보안을 크게 높일 수 있다.
DB ( Database ) " 핵심 식자재 창고 겸 금고 "
주방장 ( WAS )가 아무리 요리를 잘해도, 요리할 '식재료'와 '비법 레시피'가 없다면 아무것도 만들 수 없을 것이다.
웹서버(NGINX)와 WAS(톰캣)은 기본적으로 데이터를 영구적으로 기억하지 않는 휘발성 일꾼들이다.
반면, DB는 서비스에 필요한 모든 핵심 데이터가 영구적으로 안전하게 보관되는 단 하나의 거대한 창고이자 금고이다.
사용자가 "내 장바구니 목록 보여줘"라고 요청하면, 주방장(WAS)은 가장 먼저 창고(DB)로 달려가 해당 고객의 장바구니 데이터를 꺼내 온 뒤 요리를 시작하는 구조이다.
대표적인 DB로는 MySQL, Oracle 그리고 클라우드 환경에서 널리 쓰이는 AWS RDS 등이 있다.
기업 인프라에서 DB는 서비스의 명운이 달린 가장 소중한 자산이다.
그렇기 때문에 무중단 서비스를 위해 클라우드 리전 간 데이터베이스 마이그레이션 작업을 꼼꼼히 수행하는 등 가장 공들여 관리하는 곳이기도 하다.
DB는 가장 민감한 정보가 담긴 '심장'이다. 절대 외부 인터넷과 직접 맞닿게 두어서는 안된다.
현대 아키텍처는 Web(NGINX) - WAS - DB라는 3중 방어선(3-Tier)을 구축합니다.
- 1선: NGINX가 맨 앞단에서 최전방 문지기(리버스 프록시) 역할을 하며 트래픽을 선별합니다.
- 2선: WAS는 외부에서 직접 접근할 수 없는 내부망에서 안전하게 비즈니스 로직을 처리합니다.
- 3선: DB는 가장 깊고 안전한 곳에서 오직 인증된 WAS하고만 소통하도록 철저히 격리해 둡니다.
1선: NGINX (Public Zone / 최전방 문지기)
가장 바깥쪽에서 인터넷과 직접 맞닿아 있는 구역입니다. 클라우드 환경에서는 외부와 통신이 가능한 퍼블릭 서브넷(Public Subnet)에 위치합니다.
- 진짜 주소 숨기기 (Reverse Proxy): 외부의 모든 사용자는 NGINX의 공인 IP(Public IP)로만 접속합니다. 해커가 아무리 스캔을 돌려도 뒤에 있는 WAS나 DB의 진짜 주소(Private IP)는 절대 알 수 없습니다. NGINX가 철저하게 내부망을 캡슐화하여 숨겨주기 때문입니다.
- SSL 암호화 해독 (SSL Termination): 우리가 웹사이트에 접속할 때 쓰는 안전한 HTTPS(자물쇠 마크) 트래픽의 암호를 NGINX가 맨 앞단에서 풀어서 확인합니다. 뒷단의 WAS는 암호 해독에 힘을 뺄 필요 없이 비즈니스 로직에만 집중할 수 있습니다.
- 불량 손님 차단: 비정상적인 트래픽이나 과도한 요청이 들어오면, 뒷단으로 넘기기 전에 NGINX 선에서 연결을 끊어버립니다(Drop).
2선: WAS (Private Zone / 내부망의 브레인)
여기서부터는 외부 인터넷에서 절대 직접 들어올 수 없는 닫힌 공간, 즉 프라이빗 서브넷(Private Subnet)입니다.
- 엄격한 출입 통제: WAS 서버의 방화벽(Security Group 등)은 "오직 앞단의 NGINX가 보내는 트래픽만 허용한다"라는 규칙이 걸려 있습니다. 해커가 NGINX를 우회해서 WAS로 직접 침투하려는 시도 자체를 네트워크 단에서 원천 차단합니다.
- 비즈니스 로직의 격리: 로그인 처리, 장바구니 결제 등 복잡한 연산이 일어나는 공간입니다. 만약 최전방의 NGINX가 뚫리거나 디도스 공격으로 마비되더라도, 2선인 WAS가 분리되어 있기 때문에 내부 시스템 전체가 장악당하는 시간을 벌거나 피해를 최소화할 수 있습니다.
3선: DB (Deep Private Zone / 최심부의 금고)
인프라 아키텍처에서 가장 깊고, 가장 폐쇄적인 공간입니다.
- 오직 WAS와만 소통: DB의 방화벽은 "오직 인증된 WAS 서버의 특정 포트(예: MySQL의 3306 포트)에서 오는 쿼리 요청만 허용한다"라고 설정되어 있습니다. 앞단의 NGINX조차도 DB에는 직접 접근할 수 없습니다.
- 망 분리의 완성: 이처럼 Web, WAS, DB를 각각 다른 네트워크 망(서브넷)에 쪼개어 배치하는 것을 '망 분리(Network Segmentation)'라고 합니다. 해커가 1선(Web)을 뚫고 들어오더라도, 2선(WAS)과 3선(DB)으로 넘어가기 위해(횡적 이동, Lateral Movement) 또 다른 네트워크 방화벽과 인증을 계속 뚫어야 하는 험난한 성벽 구조를 만드는 것입니다.
요약!
Web-WAS-DB를 3계층으로 분리하는 것은 단순히 서버의 역할을 나누는 것을 넘어, 망 분리를 통해 보안의 깊이를 더하는 심층 방어 전략이다. 인터넷에 노출된 퍼블릭 망에는 NGINX만 배치하여 리버스 프록시로 활용하고, 실제 데이터가 처리되고 저장되는 WAS와 DB는 외부 접근이 철저히 차단된 프라이빗 망에 겹겹히 숨겨둠으로써 기업의 핵심 자산을 안전하게 보호 한다.
조금 더 쉽게!
왜 우리는 굳이 식당을 3구역으로 나눌까
지금까지 살펴본 NGINX와 3-Tier 아키텍처를 한마디로 정의하자면, '소중한 금고를 지키기 위해 겹겹이 성벽을 쌓는 과정' 이라고 할 수 있다.
1. NGINX는 '유능한 문지기' 입니다. 손님을 가장 먼저 맞이하며, 불량 손님을 걸러내고 복잡한 길 안내(리버스프록시)를 도맡는다.
덕분에 뒤에 있는 일꾼들은 자기 업무에만 집중할 수 있다.
2. 역할을 나누면 '안전' 해진다. 손님이 보는 앞에 주방장(WAS)과 금고(DB)를 두지 않는 것과 같다. 문지기 뒤로 주방을 숨기고, 그보다 더 깊숙한 곳에 금고를 숨겨서 외부 사람이 함부로 접근할 수 없게 만드는 것이 핵심이다.
3. 효율과 보안, 두마리 토끼를 잡는다. 가벼운 일(이미지 전달)은 문지기가 처리하고, 복잡한 요리(비즈니스 로직)는 주방장이 전담하니 속도가 빨라진다. 또한, 설령 문 앞이 시끄러워져도(디도스 공격 등) 안쪽의 주방과 금고는 안전하게 보호받을 수 있다.
결국 NGINX란 단순히 화면을 보여주는 도구를 넘어, 우리 서비스라는 거대한 성을 지키는 가장 든든한 '최전방 파수꾼'인 셈이다.