nginx가 뭔지 — 요청을 받아 나눠주는 웹 서버

웹 서비스를 배포하면 브라우저의 요청이 가장 먼저 닿는 문이 필요하다. 그 문 역할을 가장 많이 맡는 소프트웨어가 nginx(엔진엑스)다. 한 줄로 말하면, 들어오는 HTTP 요청을 받아 정적 파일을 직접 내주거나, 뒤에 있는 애플리케이션으로 넘겨주는 웹 서버다.

nginx가 하는 세 가지 일

1. 정적 파일 서빙

HTML·CSS·이미지·JS 같은 이미 만들어진 파일은 앱을 거칠 필요 없이 nginx가 디스크에서 바로 읽어 응답한다. 이게 가장 기본이자 nginx가 가장 잘하는 일이다.

server {
    listen 80;
    server_name example.com;

    root /var/www/blog;   # 이 폴더의 파일을 그대로 내준다
    index index.html;
}

Astro 같은 정적 사이트(SSG) 결과물을 배포할 때는 사실상 이 설정 하나면 충분하다.

2. 리버스 프록시

Node·Django 같은 앱 서버는 보통 localhost:3000 같은 내부 포트에서 돈다. 이걸 외부에 직접 열지 않고, nginx가 대신 요청을 받아 뒤쪽 앱으로 전달한다. 이 구조를 리버스 프록시(reverse proxy)라 한다.

location /api/ {
    proxy_pass http://localhost:3000;
    proxy_set_header Host $host;
}

왜 앞에 두는가? nginx가 앞단에서 HTTPS 처리(SSL 종료), 정적 파일 응답, 압축, 캐싱을 떠맡고, 앱은 순수한 로직만 담당하게 나누기 위해서다. 앱 서버를 외부에 직접 노출하지 않으니 보안에도 유리하다.

3. 로드 밸런싱

앱 서버가 여러 대라면, nginx가 요청을 여러 서버에 나눠 보낸다. 한 대가 죽어도 나머지가 받아낸다.

upstream app {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
}
server {
    location / { proxy_pass http://app; }
}

upstream에 서버를 나열하면 기본적으로 순번대로(라운드 로빈) 분배한다.

왜 많은 연결을 견디나 — 이벤트 기반 구조

nginx가 널리 쓰이는 핵심 이유는 성능이다. 전통적인 웹 서버(예: 옛 Apache의 기본 방식)는 연결 하나에 프로세스나 스레드 하나를 붙였다. 동시 접속이 1만 개면 그만큼의 무거운 실행 단위가 필요해 메모리가 폭발한다.

nginx는 다르다. 소수의 워커 프로세스가 이벤트 루프를 돌며 수많은 연결을 비동기로 처리한다. 각 연결이 “데이터 왔다”, “보낼 준비 됐다” 같은 이벤트를 던지면 워커가 그때그때 처리하는 식이라, 연결 수가 늘어도 실행 단위가 비례해 늘지 않는다. 이 구조 덕에 적은 자원으로 많은 동시 연결(C10K 문제)을 감당한다.

정리

nginx는 요청이 가장 먼저 닿는 웹 서버다.
세 가지 역할: 정적 파일 서빙 · 리버스 프록시 · 로드 밸런싱.
앱 앞단에 두어 HTTPS·정적 응답·캐싱을 떠맡기고, 앱은 로직만 담당하게 나눈다.
이벤트 기반 구조라 적은 자원으로 많은 동시 연결을 견딘다.

정적 블로그라면 nginx 하나로 끝나지만, Node 앱을 띄운다면 그 앱을 죽지 않게 지켜 굴려주는 도구가 따로 필요하다. 그게 pm2다.