Nginx 실전 프로젝트 완벽 가이드

실무에서 바로 사용할 수 있는 Nginx 프로젝트 구성부터 배포까지, 초급 개발자도 쉽게 따라할 수 있는 실전 가이드입니다. 리버스 프록시, 로드 밸런싱, SSL 인증서 설정 등 핵심 기능을 실습합니다.

Nginx 기본 설정과 프로젝트 구조
정적 파일 서빙과 SPA 라우팅
리버스 프록시로 Node.js 앱 배포하기
SSL/TLS 인증서 설정과 HTTPS 적용
로드 밸런싱으로 트래픽 분산하기
Gzip 압축으로 성능 최적화
접근 제어와 보안 헤더 설정
캐싱 전략으로 서버 부하 줄이기
로그 분석과 모니터링 설정
무중단 배포와 버전 관리

1. Nginx 기본 설정과 프로젝트 구조

시작하며

여러분이 웹 애플리케이션을 개발하고 나서 서버에 배포하려고 할 때, 어디서부터 시작해야 할지 막막했던 경험이 있나요? Apache도 있고, Nginx도 있고, 클라우드 서비스도 있는데 무엇을 선택해야 할지 고민되셨을 겁니다.

이런 문제는 많은 초급 개발자들이 겪는 첫 번째 관문입니다. 특히 Nginx는 설정 파일의 구조가 낯설고, 어떤 디렉토리에 무엇을 넣어야 하는지 헷갈리기 쉽습니다.

바로 이럴 때 필요한 것이 체계적인 Nginx 프로젝트 구조입니다. 올바른 디렉토리 구조와 기본 설정을 이해하면, 어떤 프로젝트든 빠르게 배포할 수 있습니다.

개요

간단히 말해서, Nginx 프로젝트 구조는 웹 서버를 효율적으로 관리하기 위한 파일과 디렉토리의 체계적인 배치입니다. 실무에서는 하나의 서버에 여러 개의 웹사이트나 애플리케이션을 운영하는 경우가 많습니다.

예를 들어, 메인 웹사이트, API 서버, 관리자 페이지를 모두 하나의 서버에서 운영해야 하는 경우, 각각을 독립적으로 관리할 수 있는 구조가 필요합니다. 기존에는 설정 파일 하나에 모든 것을 작성했다면, 이제는 sites-available과 sites-enabled 디렉토리를 활용하여 각 사이트를 모듈화하여 관리할 수 있습니다.

Nginx의 핵심 구조는 크게 세 가지로 나뉩니다: 메인 설정 파일(nginx.conf), 사이트별 설정 파일(sites-available), 그리고 실제 웹 콘텐츠가 위치하는 디렉토리(/var/www)입니다. 이러한 구조를 이해하면 프로젝트 관리가 훨씬 수월해집니다.

코드 예제

# Nginx 기본 프로젝트 구조
/etc/nginx/
├── nginx.conf              # 메인 설정 파일
├── sites-available/        # 사용 가능한 사이트 설정들
│   ├── default
│   ├── myapp.conf         # 여러분의 앱 설정
│   └── api.conf           # API 서버 설정
├── sites-enabled/          # 실제 활성화된 사이트들 (심볼릭 링크)
│   └── myapp.conf -> ../sites-available/myapp.conf
└── conf.d/                 # 추가 설정 파일들
    └── ssl.conf           # SSL 관련 설정

/var/www/
├── myapp/                  # 여러분의 앱 파일들
│   └── index.html
└── api/                    # API 서버 파일들

설명

이것이 하는 일: Nginx는 계층적인 디렉토리 구조를 통해 여러 웹사이트와 애플리케이션을 효율적으로 관리합니다. 각 설정은 독립적으로 작성되고, 필요에 따라 활성화하거나 비활성화할 수 있습니다.

첫 번째로, /etc/nginx/nginx.conf 파일은 Nginx의 전체 동작을 제어하는 마스터 설정 파일입니다. 여기에는 워커 프로세스 수, 연결 제한, 로그 파일 위치 등 글로벌 설정이 들어갑니다.

이 파일을 직접 수정하기보다는, include 디렉티브를 통해 다른 설정 파일들을 불러오는 방식을 사용합니다. 그 다음으로, sites-available 디렉토리에는 여러분이 관리하는 모든 사이트의 설정 파일이 저장됩니다.

각 파일은 server 블록을 포함하며, 도메인, 포트, 루트 디렉토리 등을 정의합니다. 이곳에 파일이 있다고 해서 바로 활성화되는 것은 아닙니다.

세 번째로, sites-enabled 디렉토리에 심볼릭 링크를 생성해야 실제로 사이트가 활성화됩니다. 이는 "ln -s /etc/nginx/sites-available/myapp.conf /etc/nginx/sites-enabled/" 명령으로 만들 수 있습니다.

이렇게 분리함으로써, 설정 파일을 삭제하지 않고도 사이트를 임시로 비활성화할 수 있습니다. 마지막으로, /var/www 디렉토리는 실제 웹 콘텐츠가 위치하는 곳입니다.

각 사이트별로 하위 디렉토리를 만들어 관리하면, 파일이 섞이지 않고 깔끔하게 유지됩니다. 여러분이 이 구조를 사용하면 프로젝트 추가, 수정, 삭제가 매우 간단해집니다.

새 프로젝트를 추가할 때는 sites-available에 설정 파일만 만들고 심볼릭 링크를 생성하면 되고, 삭제할 때는 링크만 제거하면 됩니다. 또한 설정 파일을 버전 관리 시스템에 포함시켜 팀원들과 공유할 수도 있습니다.

실전 팁

💡 새 사이트를 추가할 때는 먼저 sites-available에 설정을 작성하고, "nginx -t" 명령으로 문법 오류를 확인한 후 심볼릭 링크를 만드세요. 이렇게 하면 잘못된 설정으로 인한 서버 중단을 방지할 수 있습니다.

💡 sites-available의 설정 파일 이름은 도메인 이름이나 프로젝트 이름을 사용하면 관리가 쉽습니다. 예를 들어 "api.example.com.conf" 처럼 명확한 이름을 사용하세요.

💡 /var/www 디렉토리의 파일 권한을 적절히 설정하세요. "chown -R www-data:www-data /var/www/myapp"로 Nginx가 파일에 접근할 수 있도록 해야 합니다.

💡 설정 변경 후에는 "sudo systemctl reload nginx" 명령으로 설정을 다시 로드하세요. restart 대신 reload를 사용하면 기존 연결을 끊지 않고 새 설정을 적용할 수 있습니다.

💡 conf.d 디렉토리는 공통 설정(SSL, 보안 헤더 등)을 모듈화하는 데 활용하세요. 모든 사이트에서 include 디렉티브로 불러올 수 있어 중복을 줄일 수 있습니다.

2. 정적 파일 서빙과 SPA 라우팅

시작하며

여러분이 React나 Vue로 만든 싱글 페이지 애플리케이션(SPA)을 Nginx로 배포했는데, 메인 페이지는 잘 뜨는데 /about이나 /products 같은 하위 경로로 직접 접근하면 404 에러가 나는 경험을 해보셨나요? 새로고침할 때마다 페이지를 찾을 수 없다는 메시지가 뜨면 정말 답답합니다.

이런 문제는 SPA의 클라이언트 사이드 라우팅과 서버의 파일 시스템 라우팅이 충돌하기 때문에 발생합니다. Nginx는 /about 경로에 실제 about.html 파일이 있을 것으로 기대하지만, SPA는 모든 경로를 index.html로 처리하기 때문입니다.

바로 이럴 때 필요한 것이 Nginx의 try_files 디렉티브입니다. 이를 올바르게 설정하면 SPA 라우팅이 완벽하게 작동하고, 정적 파일도 효율적으로 서빙할 수 있습니다.

개요

간단히 말해서, 정적 파일 서빙은 HTML, CSS, JavaScript, 이미지 같은 파일들을 사용자에게 직접 전달하는 것이고, SPA 라우팅 설정은 모든 경로 요청을 index.html로 보내 클라이언트 측에서 라우팅을 처리하도록 하는 것입니다. 실무에서는 React, Vue, Angular 같은 프레임워크로 만든 애플리케이션을 배포할 때 이 설정이 반드시 필요합니다.

예를 들어, 사용자가 https://example.com/dashboard 링크를 북마크했다가 나중에 다시 방문하면, Nginx가 이를 올바르게 처리해야 합니다. 기존에는 Apache의 .htaccess 파일로 리다이렉트 규칙을 작성했다면, Nginx에서는 try_files와 location 블록을 조합하여 더 빠르고 효율적으로 처리할 수 있습니다.

핵심 특징은 두 가지입니다: 첫째, 실제 파일이 존재하면 그것을 서빙하고, 둘째, 파일이 없으면 index.html로 폴백하여 클라이언트 라우터가 처리하도록 합니다. 이를 통해 직접 URL 접근과 새로고침이 모두 정상적으로 작동합니다.

코드 예제

server {
    listen 80;
    server_name myapp.com;
    root /var/www/myapp/dist;
    index index.html;

    # SPA 라우팅을 위한 설정
    location / {
        # 1. 요청된 파일이 존재하면 그것을 서빙
        # 2. 디렉토리가 존재하면 그것을 서빙
        # 3. 둘 다 없으면 index.html로 폴백
        try_files $uri $uri/ /index.html;
    }

    # 정적 파일 캐싱 설정
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # API 요청은 백엔드로 프록시
    location /api {
        proxy_pass http://localhost:3000;
    }
}

설명

이것이 하는 일: 이 설정은 Nginx가 정적 파일을 효율적으로 서빙하면서도, SPA의 클라이언트 사이드 라우팅을 완벽하게 지원하도록 만듭니다. 모든 경로 요청을 적절히 처리하여 사용자 경험을 해치지 않습니다.

첫 번째로, root 디렉티브는 웹 콘텐츠의 루트 디렉토리를 지정합니다. React나 Vue를 빌드하면 보통 dist나 build 디렉토리가 생성되는데, 이 경로를 정확히 지정해야 합니다.

index 디렉티브는 디렉토리 요청 시 기본적으로 제공할 파일을 지정합니다. 그 다음으로, location / 블록에서 try_files 디렉티브가 핵심적인 역할을 합니다.

$uri는 요청된 경로에 실제 파일이 있는지 확인하고, $uri/는 디렉토리인지 확인합니다. 둘 다 존재하지 않으면 마지막 인자인 /index.html을 반환합니다.

예를 들어, /about 요청이 오면 about 파일이나 about 디렉토리를 찾고, 없으면 index.html을 반환하여 React Router가 /about 경로를 처리하도록 합니다. 세 번째로, 정규표현식 location 블록은 이미지, CSS, JavaScript 같은 정적 자산의 캐싱을 설정합니다.

expires 1y는 1년 동안 브라우저 캐시에 저장하라는 의미이고, Cache-Control 헤더는 추가적인 캐싱 정책을 지정합니다. immutable 플래그는 파일이 절대 변경되지 않음을 브라우저에 알려 재검증 요청을 방지합니다.

네 번째로, /api로 시작하는 요청은 백엔드 서버로 프록시됩니다. proxy_pass는 요청을 다른 서버로 전달하는 디렉티브입니다.

이렇게 하면 프론트엔드와 백엔드를 같은 도메인에서 운영하면서도 CORS 문제를 피할 수 있습니다. 여러분이 이 설정을 사용하면 SPA가 완벽하게 작동하고, 정적 파일은 효율적으로 캐싱되며, API 요청은 백엔드로 깔끔하게 전달됩니다.

특히 캐싱 설정으로 인해 반복 방문자의 페이지 로딩 속도가 크게 향상되고, 서버 부하도 줄어듭니다. 또한 웹팩이나 Vite의 해시된 파일명과 함께 사용하면 캐시 무효화도 자동으로 처리됩니다.

실전 팁

💡 빌드 도구(webpack, Vite 등)가 생성하는 파일명에 해시를 포함시키면, 코드 변경 시 자동으로 캐시가 갱신됩니다. 예: main.a3f2c1.js처럼 해시가 포함되면 파일이 바뀔 때마다 이름이 달라져 브라우저가 새 파일을 받습니다.

💡 개발 환경에서는 캐싱을 끄고 테스트하세요. "expires -1" 또는 "add_header Cache-Control no-cache"로 설정하면 항상 최신 파일을 받을 수 있습니다.

💡 try_files의 순서가 중요합니다. $uri를 먼저 확인하지 않으면 실제 파일(robots.txt, favicon.ico 등)도 index.html로 응답하게 되어 문제가 발생할 수 있습니다.

💡 location /api 블록에는 추가로 proxy_set_header 디렉티브를 사용해 원본 IP와 호스트 정보를 전달하세요. 백엔드에서 클라이언트 정보가 필요할 때 유용합니다.

💡 gzip 압축을 활성화하면 JavaScript와 CSS 파일 크기를 70% 이상 줄일 수 있습니다. nginx.conf에 "gzip on; gzip_types text/css application/javascript;"를 추가하세요.

3. 리버스 프록시로 Node.js 앱 배포하기

시작하며

여러분이 Express나 Nest.js로 백엔드 API를 만들고 "node app.js"로 실행했는데, 포트 번호를 붙여야만 접속할 수 있어서 불편했던 경험이 있나요? http://example.com:3000 대신 http://example.com/api로 깔끔하게 접근하고 싶으셨을 겁니다.

이런 문제는 Node.js 애플리케이션을 직접 80번 포트에 바인딩하기 어렵고, 여러 앱을 동시에 운영하기도 까다롭기 때문에 발생합니다. 또한 SSL 인증서 관리, 정적 파일 서빙, 로드 밸런싱 같은 기능을 Node.js 코드에 직접 구현하는 것은 비효율적입니다.

바로 이럴 때 필요한 것이 Nginx 리버스 프록시입니다. Nginx를 프론트에 두고 Node.js 앱을 백엔드로 돌리면, 포트 관리, SSL, 캐싱, 보안을 모두 Nginx가 처리해줍니다.

개요

간단히 말해서, 리버스 프록시는 클라이언트의 요청을 받아 백엔드 서버로 전달하고, 그 응답을 다시 클라이언트에게 돌려주는 중간 서버입니다. 실무에서는 대부분의 프로덕션 환경에서 Node.js 앱을 직접 노출시키지 않고 Nginx 뒤에 둡니다.

예를 들어, React 프론트엔드는 정적 파일로 서빙하고, /api 경로는 Express 백엔드로 프록시하는 구조가 매우 흔합니다. 이렇게 하면 하나의 도메인에서 모든 것을 처리할 수 있습니다.

기존에는 Node.js 앱에서 직접 HTTPS를 설정하고 정적 파일을 서빙했다면, 이제는 Nginx가 이런 역할을 대신하고 Node.js는 순수하게 비즈니스 로직에만 집중할 수 있습니다. 리버스 프록시의 핵심 이점은 세 가지입니다: 보안(백엔드 서버를 숨김), 성능(정적 파일 캐싱과 압축), 유연성(여러 백엔드 서버로 로드 밸런싱).

이를 통해 안정적이고 확장 가능한 아키텍처를 구축할 수 있습니다.

코드 예제

server {
    listen 80;
    server_name api.example.com;

    # 요청 크기 제한 (파일 업로드 고려)
    client_max_body_size 10M;

    # 로깅 설정
    access_log /var/log/nginx/api.access.log;
    error_log /var/log/nginx/api.error.log;

    # Node.js 앱으로 프록시
    location / {
        proxy_pass http://localhost:3000;

        # 원본 요청 정보 전달
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # WebSocket 지원
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";

        # 타임아웃 설정
        proxy_connect_timeout 60s;
        proxy_read_timeout 60s;
    }
}

설명

이것이 하는 일: 리버스 프록시 설정은 클라이언트와 백엔드 서버 사이에서 중개자 역할을 하며, 요청을 전달하고 응답을 반환하는 동시에 다양한 부가 기능을 제공합니다. 첫 번째로, client_max_body_size는 클라이언트가 전송할 수 있는 최대 요청 크기를 지정합니다.

기본값은 1MB인데, 파일 업로드 기능이 있다면 이를 늘려야 합니다. 10M은 10메가바이트를 의미하며, 프로필 사진이나 문서 업로드에 충분한 크기입니다.

너무 크게 설정하면 DDoS 공격에 취약해질 수 있으니 적절한 값을 선택해야 합니다. 그 다음으로, proxy_pass 디렉티브가 실제 프록시 동작을 수행합니다.

http://localhost:3000은 Node.js 앱이 실행되는 주소입니다. 이 주소는 외부에 노출되지 않고 Nginx만 접근할 수 있습니다.

클라이언트는 80번 포트로 요청하지만, 실제로는 3000번 포트의 앱이 응답하는 것입니다. 세 번째로, proxy_set_header 디렉티브들은 원본 요청 정보를 백엔드로 전달합니다.

Host 헤더는 클라이언트가 요청한 도메인을 유지하고, X-Real-IP는 클라이언트의 실제 IP 주소를 전달하며, X-Forwarded-For는 프록시 체인을 추적합니다. 이 정보가 없으면 Node.js 앱은 모든 요청이 localhost에서 온 것으로 인식하여 IP 기반 제한이나 로깅이 제대로 작동하지 않습니다.

네 번째로, WebSocket 지원을 위한 설정이 포함되어 있습니다. proxy_http_version 1.1은 HTTP/1.1 프로토콜을 사용하도록 하고, Upgrade와 Connection 헤더는 WebSocket 연결 업그레이드를 처리합니다.

이 설정이 없으면 Socket.io 같은 실시간 통신 라이브러리가 작동하지 않습니다. 마지막으로, 타임아웃 설정으로 연결과 읽기 시간을 제어합니다.

proxy_connect_timeout은 백엔드 서버 연결 시도 시간이고, proxy_read_timeout은 응답 대기 시간입니다. 무거운 처리가 필요한 API가 있다면 이 값을 늘려야 하고, 일반적인 API라면 60초면 충분합니다.

여러분이 이 설정을 사용하면 Node.js 앱을 포트 번호 없이 깔끔하게 서비스할 수 있고, SSL 인증서를 Nginx 레벨에서 한 번만 설정하면 됩니다. 또한 PM2나 systemd로 Node.js 앱이 재시작되어도 Nginx가 버퍼링하여 클라이언트 연결을 유지하고, 여러 백엔드 인스턴스로 로드 밸런싱도 쉽게 구성할 수 있습니다.

로그 파일도 Nginx와 Node.js 각각에서 관리하여 문제 발생 시 추적이 용이합니다.

실전 팁

💡 Node.js 앱은 절대 root 권한으로 실행하지 마세요. 일반 사용자로 1024 이상의 포트(3000, 4000 등)에서 실행하고, Nginx가 80/443 포트로 받아 프록시하는 것이 안전합니다.

💡 proxy_buffering을 활용하면 느린 클라이언트로 인한 백엔드 블로킹을 방지할 수 있습니다. Nginx가 백엔드 응답을 빠르게 받아 버퍼에 저장한 후 천천히 클라이언트에게 전송합니다.

💡 여러 Node.js 인스턴스를 운영한다면 upstream 블록을 사용하세요. "upstream backend { server localhost:3000; server localhost:3001; }"로 정의하고 "proxy_pass http://backend"로 사용하면 자동으로 로드 밸런싱됩니다.

💡 health check를 위해 특정 경로(/health)는 Nginx에서 직접 응답하도록 설정할 수 있습니다. "location /health { return 200 'OK'; }"처럼 설정하면 Node.js를 거치지 않고 빠르게 응답합니다.

💡 에러 페이지를 커스터마이징하려면 "error_page 502 503 504 /50x.html"을 추가하고, location = /50x.html 블록에서 친절한 에러 페이지를 제공하세요. 백엔드가 다운되어도 사용자에게 깔끔한 메시지를 보여줄 수 있습니다.

4. SSL/TLS 인증서 설정과 HTTPS 적용

시작하며

여러분이 웹사이트를 만들었는데 브라우저 주소창에 "안전하지 않음"이라는 경고가 뜨는 것을 보신 적 있나요? 특히 로그인이나 결제 기능이 있는 사이트에서는 이런 경고가 치명적입니다.

사용자들이 신뢰하지 않고 떠나버릴 수 있습니다. 이런 문제는 HTTPS를 사용하지 않아서 발생합니다.

HTTP는 데이터가 평문으로 전송되어 중간에 누구나 볼 수 있지만, HTTPS는 암호화하여 보안을 보장합니다. 요즘은 HTTPS가 선택이 아닌 필수이며, 검색 엔진 순위에도 영향을 미칩니다.

바로 이럴 때 필요한 것이 Let's Encrypt 같은 무료 SSL 인증서와 Nginx의 SSL 설정입니다. 몇 가지 명령어만으로 무료로 HTTPS를 적용할 수 있고, 자동 갱신까지 설정할 수 있습니다.

개요

간단히 말해서, SSL/TLS는 클라이언트와 서버 간의 통신을 암호화하는 프로토콜이고, 인증서는 서버의 신원을 증명하는 디지털 문서입니다. 실무에서는 Let's Encrypt를 이용해 무료로 인증서를 발급받는 것이 표준입니다.

예를 들어, 개인 블로그부터 중소기업 웹사이트까지 대부분 Let's Encrypt를 사용하며, Certbot이라는 도구로 자동화할 수 있습니다. 기존에는 인증서를 구매하고 수동으로 갱신해야 했다면, 이제는 Certbot이 발급부터 설치, 갱신까지 모두 자동으로 처리합니다.

3개월마다 자동으로 갱신되므로 만료 걱정도 없습니다. SSL 설정의 핵심은 세 가지입니다: 인증서와 개인키 파일 경로 지정, 강력한 암호화 프로토콜 사용, HTTP에서 HTTPS로 자동 리다이렉트.

이를 통해 완벽한 보안 등급(A+)을 받을 수 있습니다.

코드 예제

# Certbot으로 인증서 발급 (명령줄에서 실행)
# sudo certbot --nginx -d example.com -d www.example.com

server {
    listen 80;
    server_name example.com www.example.com;

    # HTTP를 HTTPS로 강제 리다이렉트
    return 301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    # SSL 인증서 경로 (Certbot이 자동 생성)
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # 강력한 SSL 설정
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers off;

    # HSTS 설정 (브라우저가 항상 HTTPS 사용하도록)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    root /var/www/example;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }
}

설명

이것이 하는 일: SSL/TLS 설정은 클라이언트와 서버 간의 모든 데이터를 암호화하여 도청과 변조를 방지하고, 서버의 신원을 인증하여 피싱 공격을 차단합니다. 첫 번째로, Certbot 명령어를 실행하면 Let's Encrypt가 도메인 소유권을 검증하고 인증서를 발급합니다.

--nginx 옵션은 Nginx 설정 파일을 자동으로 수정해주고, -d 옵션으로 여러 도메인을 한 번에 등록할 수 있습니다. 검증 과정에서 Certbot은 웹 서버에 임시 파일을 생성하여 도메인 소유권을 확인하므로, 포트 80이 열려있어야 합니다.

그 다음으로, 첫 번째 server 블록은 HTTP(80번 포트) 요청을 모두 HTTPS로 리다이렉트합니다. return 301은 영구 리다이렉트를 의미하며, $server_name과 $request_uri 변수로 원래 요청했던 도메인과 경로를 유지합니다.

예를 들어, http://example.com/about 요청은 https://example.com/about으로 자동 전환됩니다. 세 번째로, HTTPS server 블록에서 listen 443 ssl http2는 443번 포트에서 SSL과 HTTP/2를 활성화합니다.

HTTP/2는 여러 요청을 동시에 처리하여 페이지 로딩 속도를 크게 향상시킵니다. ssl_certificate와 ssl_certificate_key는 Certbot이 생성한 인증서 파일을 가리킵니다.

네 번째로, ssl_protocols는 사용할 TLS 버전을 지정합니다. TLSv1.0과 1.1은 보안 취약점이 있어 제외하고, 1.2와 1.3만 허용합니다.

ssl_ciphers는 암호화 알고리즘 목록인데, ECDHE는 완전 순방향 비밀성(Perfect Forward Secrecy)을 제공하여 과거 통신 내용을 보호합니다. 마지막으로, HSTS(HTTP Strict Transport Security) 헤더는 브라우저에게 항상 HTTPS만 사용하라고 지시합니다.

max-age=31536000은 1년(초 단위)을 의미하며, includeSubDomains는 모든 하위 도메인에도 적용됩니다. 이렇게 하면 사용자가 실수로 http://로 접근해도 브라우저가 자동으로 https://로 바꿔줍니다.

여러분이 이 설정을 사용하면 브라우저 주소창에 자물쇠 아이콘이 표시되고, SSL Labs 테스트에서 A 등급 이상을 받을 수 있습니다. 사용자 데이터가 암호화되어 중간자 공격을 방지하고, SEO 순위도 향상됩니다.

또한 Certbot의 자동 갱신 기능으로 인증서 만료 걱정 없이 운영할 수 있으며, 서브도메인도 쉽게 추가할 수 있습니다.

실전 팁

💡 Certbot 자동 갱신이 제대로 작동하는지 "sudo certbot renew --dry-run"으로 테스트하세요. 실제 갱신 없이 시뮬레이션만 해서 문제를 미리 발견할 수 있습니다.

💡 와일드카드 인증서(*.example.com)를 발급받으려면 DNS 인증이 필요합니다. "certbot --manual --preferred-challenges=dns -d *.example.com"을 사용하고, DNS TXT 레코드를 추가해야 합니다.

💡 SSL Labs(ssllabs.com/ssltest)에서 여러분의 사이트를 테스트하여 보안 등급을 확인하세요. A+ 등급을 받으면 매우 안전한 설정입니다.

💡 여러 도메인에 대한 인증서를 관리할 때는 각각 별도의 server 블록을 만들고, 같은 certbot 명령으로 한 번에 발급받을 수 있습니다. 하나의 인증서로 여러 도메인을 커버합니다.

💡 개발 환경에서는 mkcert 도구로 로컬 인증서를 만들어 사용하세요. Let's Encrypt는 공개 도메인이 필요하지만, mkcert는 localhost에서도 작동합니다.

5. 로드 밸런싱으로 트래픽 분산하기

시작하며

여러분의 웹 애플리케이션이 인기를 얻어 사용자가 급증했는데, 서버 하나로는 감당이 안 되어 응답 시간이 느려지고 간혹 타임아웃이 발생하는 경험을 해보셨나요? 서버를 추가로 구매했지만, 어떻게 트래픽을 나눠야 할지 막막했을 겁니다.

이런 문제는 단일 서버의 처리 능력 한계 때문에 발생합니다. 한 서버에 모든 요청이 몰리면 CPU와 메모리가 포화 상태가 되고, 일부 사용자는 서비스를 이용하지 못합니다.

또한 서버가 다운되면 전체 서비스가 중단되는 단일 장애점(Single Point of Failure) 문제도 있습니다. 바로 이럴 때 필요한 것이 Nginx의 로드 밸런싱 기능입니다.

여러 백엔드 서버를 upstream으로 등록하고, Nginx가 똑똑하게 요청을 분산시켜 성능과 가용성을 모두 확보할 수 있습니다.

개요

간단히 말해서, 로드 밸런싱은 들어오는 트래픽을 여러 서버에 균등하게 분배하여 각 서버의 부하를 줄이고, 전체 시스템의 처리량과 안정성을 높이는 기술입니다. 실무에서는 수평 확장(Scale-out) 전략의 핵심입니다.

예를 들어, Black Friday 같은 트래픽 폭증 시기에 서버를 여러 대 추가하고 로드 밸런서로 분산시켜 안정적으로 서비스합니다. AWS의 ELB나 Google Cloud의 Load Balancer도 같은 원리로 작동합니다.

기존에는 값비싼 전용 하드웨어 로드 밸런서를 구매했다면, 이제는 Nginx를 소프트웨어 로드 밸런서로 사용하여 비용을 절감하고 유연하게 설정할 수 있습니다. 로드 밸런싱의 핵심 기능은 네 가지입니다: 다양한 분산 알고리즘(라운드 로빈, least_conn, ip_hash), 헬스 체크로 장애 서버 자동 제외, 가중치 설정으로 서버별 비율 조절, 세션 유지(sticky session).

이를 통해 고가용성 시스템을 구축할 수 있습니다.

코드 예제

# upstream 블록에서 백엔드 서버들 정의
upstream backend_servers {
    # 로드 밸런싱 알고리즘 (기본은 라운드 로빈)
    least_conn;  # 연결 수가 가장 적은 서버로 전달

    # 백엔드 서버 목록
    server 192.168.1.101:3000 weight=3;  # 가중치 3 (더 많은 요청 처리)
    server 192.168.1.102:3000 weight=2;
    server 192.168.1.103:3000 weight=1 backup;  # 백업 서버 (다른 서버 실패 시만 사용)

    # 헬스 체크 설정
    server 192.168.1.104:3000 max_fails=3 fail_timeout=30s;

    # 같은 클라이언트는 같은 서버로 (세션 유지)
    ip_hash;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://backend_servers;

        # 백엔드 서버 정보 헤더 추가
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # 실패 시 다음 서버로 재시도
        proxy_next_upstream error timeout http_500 http_502 http_503;
    }
}

설명

이것이 하는 일: 로드 밸런싱 설정은 클라이언트 요청을 여러 백엔드 서버에 지능적으로 분산시키고, 장애가 발생한 서버를 자동으로 제외하여 무중단 서비스를 제공합니다. 첫 번째로, upstream 블록에서 backend_servers라는 이름으로 서버 그룹을 정의합니다.

이 이름은 proxy_pass에서 사용되며, 여러 upstream을 정의하여 용도별로 다른 서버 그룹을 만들 수 있습니다. 예를 들어, api_servers와 web_servers를 따로 만들어 관리할 수 있습니다.

그 다음으로, least_conn 디렉티브는 현재 활성 연결 수가 가장 적은 서버로 새 요청을 보냅니다. 라운드 로빈(기본값)은 순서대로 돌아가며 분배하지만, 요청 처리 시간이 다를 경우 불균형이 생깁니다.

least_conn은 실제 부하를 고려하여 더 효율적입니다. 다른 옵션으로는 random(무작위), ip_hash(IP 기반 해싱) 등이 있습니다.

세 번째로, server 디렉티브의 weight 파라미터는 서버별 가중치를 지정합니다. weight=3인 서버는 weight=1인 서버보다 3배 많은 요청을 처리합니다.

이는 서버 성능이 다를 때 유용하며, 예를 들어 CPU가 4코어인 서버에 weight=2, 8코어인 서버에 weight=4를 주면 효율적입니다. backup 파라미터는 평상시엔 사용하지 않고, 다른 모든 서버가 실패했을 때만 사용하는 예비 서버를 지정합니다.

네 번째로, max_fails와 fail_timeout은 헬스 체크 로직을 정의합니다. max_fails=3은 3번 연속 실패하면 해당 서버를 비활성화하고, fail_timeout=30s는 30초 후 다시 시도합니다.

이를 통해 장애가 발생한 서버로 요청이 가지 않아 사용자 경험이 나빠지는 것을 방지합니다. 다섯 번째로, ip_hash 디렉티브는 클라이언트 IP 주소를 해시하여 항상 같은 서버로 보냅니다.

이는 세션 정보가 서버에 저장되는 경우 필수적입니다. 예를 들어, 로그인 세션이 메모리에 있다면, 같은 사용자가 다른 서버로 가면 다시 로그인해야 합니다.

단, ip_hash와 weight를 함께 사용할 수 없다는 제약이 있습니다. 마지막으로, proxy_next_upstream은 백엔드 서버가 에러를 반환하거나 타임아웃이 발생하면 자동으로 다음 서버로 재시도합니다.

http_500, http_502, http_503은 서버 에러 상태 코드이며, 이런 에러가 발생하면 즉시 다른 서버로 전환하여 사용자는 에러를 보지 않습니다. 여러분이 이 설정을 사용하면 트래픽이 증가해도 서버를 추가하기만 하면 자동으로 분산되고, 한 서버가 다운되어도 나머지 서버가 계속 서비스를 제공합니다.

Docker Swarm이나 Kubernetes 없이도 간단한 고가용성 시스템을 구축할 수 있으며, PM2 클러스터 모드와 함께 사용하면 프로세스 레벨과 서버 레벨 모두에서 부하 분산이 이루어집니다. 또한 A/B 테스팅을 위해 일부 트래픽만 새 버전 서버로 보내는 카나리 배포도 가능합니다.

실전 팁

💡 실제 프로덕션에서는 upstream 서버들이 같은 코드와 데이터베이스를 공유해야 합니다. 세션은 Redis 같은 중앙 저장소에 두어 어느 서버에서든 접근 가능하게 하세요.

💡 Active Health Check를 위해 Nginx Plus(유료)를 사용하거나, 무료 대안으로 각 백엔드에 /health 엔드포인트를 만들고 모니터링 도구로 주기적으로 체크하세요.

💡 로드 밸런서 자체가 단일 장애점이 되지 않도록, keepalived나 HAProxy를 사용해 Nginx 로드 밸런서를 이중화하는 것이 좋습니다.

💡 성능 테스트 도구(Apache Bench, wrk, k6)로 부하 테스트를 해보세요. 서버 추가 시 실제로 처리량이 증가하는지 확인할 수 있습니다.

💡 로그에 $upstream_addr 변수를 추가하면 어느 백엔드 서버가 요청을 처리했는지 기록됩니다. "log_format upstreamlog '$remote_addr - $upstream_addr';"처럼 사용하세요.

6. Gzip 압축으로 성능 최적화

시작하며

여러분의 웹사이트를 만들고 배포했는데, 사용자들이 페이지 로딩이 너무 느리다고 불평하는 경험을 해보셨나요? 개발자 도구의 Network 탭을 열어보니 JavaScript 파일 하나가 2MB나 되고, 다운로드하는 데 수 초가 걸리는 것을 발견했을 겁니다.

이런 문제는 번들 크기가 크고 압축되지 않은 채로 전송되기 때문에 발생합니다. 특히 모바일 네트워크나 느린 인터넷 환경에서는 치명적입니다.

사용자는 흰 화면만 보다가 이탈할 수 있고, 데이터 요금도 많이 나옵니다. 바로 이럴 때 필요한 것이 Gzip 압축입니다.

Nginx에서 몇 줄의 설정만으로 텍스트 기반 파일을 70-90% 압축하여 전송할 수 있고, 페이지 로딩 속도를 극적으로 개선할 수 있습니다.

개요

간단히 말해서, Gzip 압축은 서버가 파일을 압축하여 전송하고, 브라우저가 압축을 풀어 사용하는 기술로, 네트워크 대역폭을 크게 절약합니다. 실무에서는 거의 모든 프로덕션 웹 서버에서 Gzip 압축을 활성화합니다.

예를 들어, 500KB짜리 JavaScript 파일이 압축되면 100KB 정도로 줄어들어 5배 빠르게 다운로드됩니다. 모든 모던 브라우저가 Gzip을 지원하므로 호환성 걱정도 없습니다.

기존에는 빌드 타임에 미리 압축 파일을 생성하거나, CDN에서 압축을 처리했다면, Nginx는 런타임에 동적으로 압축하거나 사전 압축된 파일을 서빙할 수 있습니다. Gzip 압축의 핵심은 세 가지입니다: 적절한 파일 타입 선택(HTML, CSS, JS, JSON), 압축 레벨 조정(1-9, 기본 6), 최소 파일 크기 설정(너무 작은 파일은 압축 안 함).

이를 통해 성능과 CPU 사용량의 균형을 맞출 수 있습니다.

코드 예제

http {
    # Gzip 압축 활성화
    gzip on;

    # 압축 레벨 (1-9, 6이 적절한 균형점)
    gzip_comp_level 6;

    # 압축할 파일 타입 지정
    gzip_types
        text/plain
        text/css
        text/xml
        text/javascript
        application/javascript
        application/x-javascript
        application/json
        application/xml
        application/xml+rss
        application/rss+xml
        font/truetype
        font/opentype
        application/vnd.ms-fontobject
        image/svg+xml;

    # 최소 압축 파일 크기 (1KB 미만은 압축 안 함)
    gzip_min_length 1000;

    # 프록시된 요청도 압축
    gzip_proxied any;

    # IE6에서는 압축 비활성화 (버그 있음)
    gzip_disable "msie6";

    # Vary 헤더 추가 (캐시 프록시를 위해)
    gzip_vary on;

    # 압축 버퍼 크기
    gzip_buffers 16 8k;
}

설명

이것이 하는 일: Gzip 압축 설정은 서버가 응답 파일을 압축하여 네트워크 전송량을 줄이고, 브라우저는 압축을 풀어 원본 파일을 사용하게 합니다. 이를 통해 대역폭을 절약하고 페이지 로딩 속도를 향상시킵니다.

첫 번째로, gzip on 디렉티브가 압축 기능을 활성화합니다. 기본값은 off이므로 반드시 명시해야 합니다.

이 설정만으로도 기본 파일 타입(text/html)은 압축되지만, JavaScript나 CSS를 압축하려면 추가 설정이 필요합니다. 그 다음으로, gzip_comp_level은 압축 강도를 지정합니다.

레벨 1은 가장 빠르지만 압축률이 낮고, 레벨 9는 최대 압축이지만 CPU를 많이 씁니다. 실무에서는 레벨 6이 가장 많이 사용되며, 레벨 9와 비교해도 파일 크기 차이는 5% 미만이지만 CPU 사용량은 훨씬 적습니다.

세 번째로, gzip_types는 압축할 MIME 타입을 나열합니다. 텍스트 기반 파일(HTML, CSS, JavaScript, JSON, XML)은 압축률이 70-90%로 매우 높지만, 이미지(JPEG, PNG)나 비디오는 이미 압축되어 있어 효과가 없습니다.

오히려 압축 시도로 CPU만 낭비하므로 제외해야 합니다. SVG는 XML 기반이므로 압축하면 좋고, 폰트 파일도 상황에 따라 압축할 수 있습니다.

네 번째로, gzip_min_length는 압축할 최소 파일 크기를 바이트 단위로 지정합니다. 1000(1KB)은 일반적인 값이며, 너무 작은 파일을 압축하면 헤더 오버헤드 때문에 오히려 커질 수 있습니다.

예를 들어, 100바이트짜리 HTML을 압축하면 Gzip 헤더와 푸터 때문에 더 커집니다. 다섯 번째로, gzip_proxied any는 프록시된 요청에 대한 응답도 압축합니다.

Nginx가 리버스 프록시로 사용될 때 중요하며, any는 모든 프록시 응답을 압축하라는 의미입니다. 다른 옵션으로는 expired, no-cache 등이 있어 캐시 정책에 따라 선택적으로 압축할 수 있습니다.

여섯 번째로, gzip_vary on은 Vary: Accept-Encoding 헤더를 추가합니다. 이는 CDN이나 프록시 캐시에게 압축 버전과 비압축 버전을 별도로 캐시하라고 알려줍니다.

이 설정이 없으면 압축을 지원하지 않는 오래된 브라우저가 압축된 파일을 받아 깨질 수 있습니다. 마지막으로, gzip_disable은 특정 브라우저에서 압축을 비활성화합니다.

IE6는 Gzip에 버그가 있어 제외하며, 정규표현식으로 User-Agent를 매칭합니다. 현대 웹에서는 IE6 사용자가 거의 없으므로 큰 영향은 없습니다.

여러분이 이 설정을 사용하면 JavaScript 번들이 500KB에서 100KB로 줄어들어 로딩 시간이 5배 빨라집니다. 특히 모바일 사용자에게 큰 혜택을 주며, 서버 대역폭 비용도 절감됩니다.

Google PageSpeed Insights나 WebPageTest 같은 도구로 측정하면 성능 점수가 크게 향상되는 것을 볼 수 있습니다. 또한 webpack이나 Vite에서 gzip-webpack-plugin을 사용해 빌드 타임에 .gz 파일을 미리 생성하고, Nginx의 gzip_static on으로 서빙하면 런타임 CPU 부하를 0으로 만들 수 있습니다.

실전 팁

💡 Brotli 압축을 추가로 사용하면 Gzip보다 15-25% 더 압축됩니다. ngx_brotli 모듈을 설치하고 "brotli on; brotli_types ..."로 활성화하세요. 모던 브라우저는 대부분 지원합니다.

💡 개발 환경에서 압축을 테스트하려면 "curl -H 'Accept-Encoding: gzip' -I http://localhost"로 응답 헤더에 Content-Encoding: gzip이 있는지 확인하세요.

💡 압축률을 확인하려면 "gzip_comp_level 1"과 "9"를 각각 테스트하고 파일 크기를 비교해보세요. 대부분의 경우 6이 최적이지만, 트래픽이 매우 많다면 레벨을 높여 대역폭을 더 절약할 수 있습니다.

💡 이미 압축된 파일(JPEG, PNG, MP4, ZIP)은 gzip_types에 포함시키지 마세요. 압축 효과가 없고 CPU만 낭비합니다. 오히려 원본 그대로 전송하는 게 빠릅니다.

💡 CDN을 사용한다면 CDN 자체의 압축 기능을 활용하세요. Cloudflare, AWS CloudFront 등은 자동으로 압축하므로 Nginx에서 중복 압축할 필요가 없습니다.

7. 접근 제어와 보안 헤더 설정

시작하며

여러분의 웹 애플리케이션이 공개되었는데, 관리자 페이지(/admin)에 누구나 접근할 수 있어서 걱정되는 경험을 해보셨나요? 또는 XSS 공격이나 클릭재킹 같은 보안 취약점에 대해 들었지만 어떻게 방어해야 할지 몰라 답답했을 겁니다.

이런 문제는 적절한 접근 제어와 보안 헤더가 없어서 발생합니다. 민감한 경로를 모두에게 공개하면 브루트 포스 공격이나 무단 접근의 대상이 되고, 보안 헤더가 없으면 브라우저가 악성 스크립트를 막을 수 없습니다.

바로 이럴 때 필요한 것이 Nginx의 접근 제어 디렉티브와 보안 헤더입니다. IP 기반 차단, HTTP 인증, 그리고 CSP 같은 보안 헤더로 다층 방어를 구축할 수 있습니다.

개요

간단히 말해서, 접근 제어는 특정 경로나 리소스에 대한 접근을 IP 주소나 인증 정보로 제한하는 것이고, 보안 헤더는 브라우저에게 보안 정책을 알려주는 HTTP 응답 헤더입니다. 실무에서는 관리자 페이지, 데이터베이스 관리 도구(phpMyAdmin 등), 내부 API를 특정 IP에서만 접근 가능하게 합니다.

예를 들어, 회사 사무실 IP나 VPN IP만 허용하고 나머지는 차단하여 외부 공격을 원천 차단합니다. 기존에는 애플리케이션 코드에서 권한 체크를 했다면, Nginx 레벨에서 먼저 필터링하면 애플리케이션까지 도달하지 않아 더 안전하고 효율적입니다.

보안 설정의 핵심은 네 가지입니다: IP 화이트리스트/블랙리스트, HTTP Basic 인증, 중요 보안 헤더(CSP, X-Frame-Options, HSTS), rate limiting. 이를 통해 OWASP Top 10 취약점 대부분을 방어할 수 있습니다.

코드 예제

server {
    listen 443 ssl http2;
    server_name example.com;

    # 보안 헤더 설정
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';" always;

    # 일반 사용자 접근 가능 영역
    location / {
        root /var/www/html;
        try_files $uri $uri/ /index.html;
    }

    # 관리자 페이지 - IP 제한
    location /admin {
        # 허용할 IP만 나열
        allow 192.168.1.0/24;    # 회사 네트워크
        allow 10.0.0.5;           # VPN IP
        deny all;                 # 나머지 모두 차단

        # HTTP Basic 인증 추가 (2중 보안)
        auth_basic "Admin Area";
        auth_basic_user_file /etc/nginx/.htpasswd;

        proxy_pass http://localhost:3000;
    }

    # API Rate Limiting
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

    location /api {
        limit_req zone=api_limit burst=20 nodelay;
        limit_req_status 429;

        proxy_pass http://localhost:3000;
    }
}

설명

이것이 하는 일: 접근 제어와 보안 헤더 설정은 여러 계층에서 웹 애플리케이션을 보호하며, 무단 접근을 차단하고 브라우저의 보안 기능을 활성화하여 다양한 공격을 방어합니다. 첫 번째로, 보안 헤더 블록에서 여러 중요한 헤더를 추가합니다.

X-Frame-Options: SAMEORIGIN은 같은 도메인에서만 iframe으로 삽입할 수 있게 하여 클릭재킹 공격을 방지합니다. X-Content-Type-Options: nosniff는 브라우저가 MIME 타입을 추측하지 못하게 하여 악성 파일 실행을 막습니다.

X-XSS-Protection은 XSS 공격 감지 시 페이지 로딩을 차단합니다. always 플래그는 4xx, 5xx 에러 응답에도 헤더를 추가합니다.

그 다음으로, Content-Security-Policy(CSP) 헤더가 가장 강력한 보안 기능을 제공합니다. default-src 'self'는 모든 리소스를 같은 도메인에서만 로드하고, script-src는 JavaScript 출처를 제한하며, style-src는 CSS 출처를 제한합니다.

'unsafe-inline'은 인라인 스크립트/스타일을 허용하는데, 보안상 좋지 않지만 기존 코드 때문에 필요할 수 있습니다. 실무에서는 nonce나 hash를 사용해 특정 인라인 코드만 허용하는 게 좋습니다.

세 번째로, location /admin 블록에서 IP 기반 접근 제어를 설정합니다. allow 디렉티브는 허용할 IP나 CIDR 범위를 지정하고, deny all은 나머지 모든 IP를 차단합니다.

순서가 중요하며, Nginx는 위에서 아래로 평가하여 첫 번째 매칭되는 규칙을 적용합니다. 예를 들어, 192.168.1.0/24는 192.168.1.1부터 192.168.1.254까지 모두 허용합니다.

네 번째로, auth_basic 디렉티브는 HTTP Basic 인증을 활성화합니다. 사용자 이름과 비밀번호를 입력해야 접근할 수 있으며, auth_basic_user_file은 인증 정보가 저장된 파일 경로입니다.

이 파일은 "htpasswd -c /etc/nginx/.htpasswd admin" 명령으로 생성하며, 비밀번호가 암호화되어 저장됩니다. IP 제한과 함께 사용하면 이중 보안이 됩니다.

다섯 번째로, limit_req_zone은 rate limiting을 설정합니다. $binary_remote_addr는 클라이언트 IP를 바이너리 형식으로 저장하여 메모리를 절약하고, zone=api_limit:10m은 10MB 크기의 공유 메모리 영역을 생성하며(약 16만 개 IP 추적 가능), rate=10r/s는 초당 10개 요청으로 제한합니다.

마지막으로, location /api에서 실제 rate limiting을 적용합니다. limit_req는 정의한 zone을 사용하고, burst=20은 일시적으로 20개까지 버스트를 허용하며, nodelay는 버스트 요청을 즉시 처리합니다.

limit_req_status 429는 제한 초과 시 429(Too Many Requests) 상태 코드를 반환합니다. 이를 통해 DDoS나 브루트 포스 공격을 효과적으로 차단합니다.

여러분이 이 설정을 사용하면 관리자 페이지가 외부 공격으로부터 안전하고, XSS나 클릭재킹 같은 일반적인 공격도 브라우저 레벨에서 차단됩니다. API는 과도한 요청으로부터 보호되어 서버 과부하를 방지하고, 보안 감사 도구(Security Headers, Mozilla Observatory)에서 높은 점수를 받을 수 있습니다.

또한 GDPR이나 개인정보보호법 준수에도 도움이 되며, 사용자 신뢰도가 향상됩니다.

실전 팁

💡 CSP 헤더는 처음에는 report-only 모드로 테스트하세요. "Content-Security-Policy-Report-Only"로 설정하면 위반 사항을 로그로만 기록하고 차단하지 않아 안전하게 테스트할 수 있습니다.

💡 .htpasswd 파일을 생성할 때는 bcrypt 알고리즘을 사용하세요. "htpasswd -B -c /etc/nginx/.htpasswd admin"으로 더 강력한 암호화를 사용합니다.

💡 cloudflare 같은 CDN을 사용한다면 실제 클라이언트 IP는 X-Forwarded-For나 CF-Connecting-IP 헤더에 있습니다. limit_req_zone에서 $http_x_forwarded_for를 사용하세요.

💡 보안 헤더가 제대로 적용되는지 securityheaders.com에서 테스트하세요. A+ 등급을 목표로 하고, 부족한 헤더를 추가하면 됩니다.

💡 geo 모듈을 사용하면 국가별 접근 제어도 가능합니다. "geo $country { default no; KR yes; }" 같이 설정하고 "if ($country = no) { return 403; }"로 특정 국가만 허용할 수 있습니다.

8. 캐싱 전략으로 서버 부하 줄이기

시작하며

여러분의 블로그나 뉴스 사이트가 인기를 얻어 방문자가 늘었는데, 같은 페이지를 요청할 때마다 데이터베이스를 조회하고 HTML을 렌더링해서 서버 CPU가 100%를 찍는 경험을 해보셨나요? 특히 트렌드에 오르면 서버가 다운될 수도 있습니다.

이런 문제는 매번 동적으로 콘텐츠를 생성하기 때문에 발생합니다. 블로그 글은 한 번 작성되면 거의 변하지 않는데, 방문자 1000명이 같은 글을 보면 1000번 똑같은 작업을 반복합니다.

이는 엄청난 리소스 낭비입니다. 바로 이럴 때 필요한 것이 Nginx의 캐싱 기능입니다.

한 번 생성된 응답을 메모리나 디스크에 저장했다가 재사용하면, 백엔드 서버 부하를 90% 이상 줄이고 응답 속도도 10배 빨라집니다.

개요

간단히 말해서, 캐싱은 자주 요청되는 응답을 임시 저장소에 보관했다가 같은 요청이 오면 백엔드를 거치지 않고 바로 응답하는 기술입니다. 실무에서는 프록시 캐싱과 브라우저 캐싱을 조합하여 사용합니다.

예를 들어, WordPress 같은 CMS는 페이지 생성에 수백 ms가 걸리지만, Nginx 캐시를 사용하면 1-2ms로 응답할 수 있습니다. 또한 API 응답도 캐싱하여 데이터베이스 부하를 크게 줄입니다.

기존에는 Redis나 Memcached 같은 별도의 캐시 서버를 운영했다면, Nginx 내장 캐싱만으로도 대부분의 사용 사례를 커버할 수 있어 인프라가 단순해집니다. 캐싱 전략의 핵심은 네 가지입니다: 무엇을 캐싱할지(정적 vs 동적), 얼마나 오래 보관할지(TTL), 언제 무효화할지(purge), 어떤 조건에서 캐싱할지(query string, cookie).

이를 통해 최신성과 성능의 균형을 맞출 수 있습니다.

코드 예제

# http 블록에 캐시 경로 정의
proxy_cache_path /var/cache/nginx/proxy
                 levels=1:2
                 keys_zone=my_cache:10m
                 max_size=1g
                 inactive=60m
                 use_temp_path=off;

server {
    listen 80;
    server_name blog.example.com;

    # 정적 파일 브라우저 캐싱
    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # 동적 콘텐츠 프록시 캐싱
    location / {
        proxy_pass http://localhost:3000;

        # 캐시 활성화
        proxy_cache my_cache;
        proxy_cache_valid 200 10m;      # 성공 응답은 10분
        proxy_cache_valid 404 1m;       # 404는 1분
        proxy_cache_use_stale error timeout http_500 http_502 http_503;

        # 캐시 상태를 응답 헤더에 추가 (디버깅용)
        add_header X-Cache-Status $upstream_cache_status;

        # 특정 조건에서는 캐싱 건너뛰기
        proxy_cache_bypass $http_pragma $http_authorization;
        proxy_no_cache $http_pragma $http_authorization;

        # 캐시 키 정의
        proxy_cache_key "$scheme$request_method$host$request_uri";

        # 동시 요청 시 하나만 백엔드로 전달
        proxy_cache_lock on;
        proxy_cache_lock_timeout 5s;
    }

    # 관리자는 캐싱하지 않음
    location /admin {
        proxy_pass http://localhost:3000;
        proxy_cache_bypass 1;
    }
}

설명

이것이 하는 일: 캐싱 설정은 자주 요청되는 응답을 디스크나 메모리에 저장하여 백엔드 서버 호출을 최소화하고, 응답 시간을 극적으로 단축하며, 서버 장애 시에도 서비스를 유지합니다. 첫 번째로, proxy_cache_path는 캐시 저장 위치와 동작 방식을 정의합니다.

/var/cache/nginx/proxy는 캐시 파일이 저장될 디렉토리이고, levels=1:2는 하위 디렉토리 구조를 2단계로 만들어 많은 파일을 효율적으로 관리합니다. keys_zone=my_cache:10m은 캐시 키를 저장할 공유 메모리 영역(10MB, 약 8만 개 키 저장 가능)을 만들고, max_size=1g은 최대 캐시 크기를 1GB로 제한합니다.

그 다음으로, inactive=60m은 60분 동안 접근되지 않은 캐시를 삭제하여 공간을 확보합니다. 인기 있는 페이지는 계속 캐시에 남고, 오래된 페이지는 자동으로 정리됩니다.

use_temp_path=off는 임시 파일을 캐시 디렉토리에 직접 쓰도록 하여 디스크 I/O를 줄입니다. 세 번째로, location / 블록에서 proxy_cache my_cache로 앞서 정의한 캐시 영역을 사용합니다.

proxy_cache_valid는 HTTP 상태 코드별로 캐시 유지 시간을 지정하는데, 200(성공)은 10분, 404(없음)는 1분만 캐싱합니다. 이렇게 하면 존재하지 않는 페이지에 대한 반복 요청도 백엔드를 거치지 않습니다.

네 번째로, proxy_cache_use_stale은 백엔드 서버가 에러를 반환하거나 응답하지 않을 때 오래된 캐시를 제공합니다. error, timeout, http_500, http_502, http_503 조건에서 작동하며, 이를 통해 백엔드가 다운되어도 사용자는 이전 콘텐츠를 볼 수 있어 서비스 가용성이 높아집니다.

"stale-while-revalidate" 개념과 유사합니다. 다섯 번째로, X-Cache-Status 헤더는 캐시 상태를 응답에 추가합니다.

값으로는 HIT(캐시에서 제공), MISS(백엔드에서 가져옴), BYPASS(캐싱 건너뜀), EXPIRED(만료되어 재검증) 등이 있습니다. 개발자 도구에서 이 헤더를 확인하여 캐싱이 제대로 작동하는지 검증할 수 있습니다.

여섯 번째로, proxy_cache_bypass와 proxy_no_cache는 특정 조건에서 캐싱을 건너뜁니다. $http_pragma는 Pragma: no-cache 헤더가 있을 때, $http_authorization은 Authorization 헤더가 있을 때 캐싱하지 않습니다.

로그인한 사용자나 관리자의 요청은 개인화된 콘텐츠를 보아야 하므로 캐싱하면 안 됩니다. 일곱 번째로, proxy_cache_key는 캐시를 식별하는 키를 정의합니다.

$scheme(http/https), $request_method(GET/POST), $host(도메인), $request_uri(경로와 query string)를 조합하여 고유한 키를 만듭니다. 같은 URL이라도 쿼리 파라미터가 다르면 별도로 캐싱됩니다.

마지막으로, proxy_cache_lock은 동일한 요청이 동시에 여러 개 들어올 때, 첫 번째 요청만 백엔드로 전달하고 나머지는 대기시킵니다. 예를 들어, 인기 기사가 캐시에 없을 때 1000명이 동시에 요청하면 1번만 백엔드로 가고 나머지는 캐시가 생성될 때까지 기다렸다가 모두 캐시된 응답을 받습니다.

이를 "cache stampede" 방지라고 합니다. 여러분이 이 설정을 사용하면 같은 페이지를 1000번 요청해도 백엔드는 1번만 처리하고, 응답 시간이 200ms에서 2ms로 줄어듭니다.

데이터베이스 부하가 극적으로 감소하여 더 많은 사용자를 수용할 수 있고, 트래픽 급증 시에도 안정적으로 서비스할 수 있습니다. CloudFlare 같은 CDN과 함께 사용하면 전 세계 사용자에게 밀리초 단위로 응답할 수 있으며, 서버 비용도 크게 절감됩니다.

또한 캐시 통계를 모니터링하여 히트율을 추적하고 최적화할 수 있습니다.

실전 팁

💡 캐시를 수동으로 삭제하려면 proxy_cache_purge 모듈을 사용하거나, 간단히 "rm -rf /var/cache/nginx/proxy/*"로 전체 캐시를 비울 수 있습니다. 콘텐츠 배포 후 캐시 갱신이 필요할 때 유용합니다.

💡 캐시 히트율을 모니터링하려면 access_log에 $upstream_cache_status를 추가하고, AWK나 분석 도구로 HIT/MISS 비율을 계산하세요. 80% 이상이면 효과적으로 작동하는 것입니다.

💡 API 응답을 캐싱할 때는 Cache-Control 헤더를 존중하세요. "proxy_cache_valid any 5m" 대신 "proxy_cache_revalidate on"으로 설정하면 백엔드의 ETag/Last-Modified를 활용하여 변경된 콘텐츠만 다시 받습니다.

💡 로그인한 사용자별로 다른 콘텐츠를 보여준다면 쿠키를 캐시 키에 포함시키세요. "proxy_cache_key $cookie_sessionid$request_uri"처럼 설정하면 사용자별로 캐시를 분리할 수 있습니다.

💡 메모리 캐시(tmpfs)를 사용하면 더 빠릅니다. "/dev/shm/nginx-cache"처럼 RAM 디스크에 캐시를 두면 디스크 I/O가 제거되어 응답 시간이 더 줄어듭니다.

9. 로그 분석과 모니터링 설정

시작하며

여러분의 웹사이트가 운영 중인데, 갑자기 에러가 발생하거나 성능이 느려졌을 때 어디서부터 문제를 찾아야 할지 막막했던 경험이 있나요? 또는 얼마나 많은 사용자가 방문하는지, 어떤 페이지가 인기 있는지 알고 싶었지만 방법을 몰라 답답했을 겁니다.

이런 문제는 적절한 로깅과 모니터링이 없어서 발생합니다. 로그가 없으면 장애 원인을 찾을 수 없고, 사용자 행동을 분석할 수도 없으며, 공격을 탐지할 수도 없습니다.

운영은 가시성(observability)에서 시작됩니다. 바로 이럴 때 필요한 것이 Nginx의 로그 설정과 모니터링 도구입니다.

커스텀 로그 포맷으로 필요한 정보를 정확히 기록하고, 실시간으로 분석하여 문제를 조기에 발견할 수 있습니다.

개요

간단히 말해서, 로그는 서버에서 발생하는 모든 이벤트(요청, 에러, 접근 등)를 시간순으로 기록한 파일이고, 모니터링은 이를 분석하여 시스템 상태를 추적하는 것입니다. 실무에서는 access log로 모든 요청을 기록하고, error log로 문제를 추적하며, ELK Stack(Elasticsearch, Logstash, Kibana)이나 Grafana로 시각화합니다.

예를 들어, 404 에러가 급증하면 알람을 받아 즉시 대응할 수 있습니다. 기존에는 로그 파일을 직접 열어 grep으로 검색했다면, 이제는 로그 수집기가 자동으로 파싱하고 대시보드에 실시간으로 표시하여 인사이트를 얻을 수 있습니다.

로그 전략의 핵심은 네 가지입니다: 커스텀 로그 포맷(JSON 등), 적절한 로그 레벨(error, warn, info), 로그 로테이션(디스크 공간 관리), 중앙 집중식 수집. 이를 통해 대규모 시스템도 효과적으로 관리할 수 있습니다.

코드 예제

# JSON 형식의 커스텀 로그 포맷 정의
log_format json_combined escape=json
'{'
  '"time_local":"$time_local",'
  '"remote_addr":"$remote_addr",'
  '"request":"$request",'
  '"status":$status,'
  '"body_bytes_sent":$body_bytes_sent,'
  '"request_time":$request_time,'
  '"upstream_response_time":"$upstream_response_time",'
  '"http_referer":"$http_referer",'
  '"http_user_agent":"$http_user_agent",'
  '"http_x_forwarded_for":"$http_x_forwarded_for"'
'}';

server {
    listen 80;
    server_name example.com;

    # Access Log (JSON 포맷)
    access_log /var/log/nginx/access.log json_combined;

    # Error Log (레벨 지정)
    error_log /var/log/nginx/error.log warn;

    # 특정 경로만 별도 로그
    location /api {
        access_log /var/log/nginx/api.log json_combined;
        proxy_pass http://localhost:3000;
    }

    # 정적 파일은 로깅 제외 (선택적)
    location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
        access_log off;
        expires 1y;
    }

    # Health check는 로깅 안 함
    location /health {
        access_log off;
        return 200 "OK\n";
        add_header Content-Type text/plain;
    }
}

# 로그 로테이션 (/etc/logrotate.d/nginx)
# /var/log/nginx/*.log {
#     daily
#     rotate 14
#     compress
#     delaycompress
#     notifempty
#     create 0640 www-data adm
#     sharedscripts
#     postrotate
#         [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid`
#     endscript
# }

설명

이것이 하는 일: 로그 설정은 서버에서 발생하는 모든 이벤트를 체계적으로 기록하여 문제 해결, 성능 분석, 보안 감사, 사용자 행동 분석을 가능하게 합니다. 첫 번째로, log_format 디렉티브는 로그에 기록할 정보의 형식을 정의합니다.

json_combined라는 이름으로 JSON 형식을 만들었는데, 이는 Elasticsearch나 Logstash 같은 도구가 쉽게 파싱할 수 있습니다. escape=json은 특수 문자를 JSON 규격에 맞게 이스케이프합니다.

기본 combined 포맷은 사람이 읽기 편하지만 파싱이 어려워 자동화에는 JSON이 더 좋습니다. 그 다음으로, 로그 포맷에 포함된 변수들을 살펴보면, $time_local은 요청 시간, $remote_addr은 클라이언트 IP, $request는 HTTP 메서드와 경로, $status는 응답 코드입니다.

$request_time은 요청 처리 전체 시간이고, $upstream_response_time은 백엔드 서버 응답 시간입니다. 이 둘을 비교하면 Nginx와 백엔드 중 어디가 느린지 알 수 있습니다.

세 번째로, access_log 디렉티브는 모든 HTTP 요청을 기록합니다. /var/log/nginx/access.log 경로에 json_combined 포맷으로 저장되며, 하루에 수만 개의 요청이 쌓입니다.

이 로그를 분석하면 가장 많이 방문한 페이지, 트래픽 패턴, 응답 시간 분포 등을 알 수 있습니다. buffer=32k 옵션을 추가하면 메모리에 모았다가 한 번에 쓰여 I/O를 줄일 수 있습니다.

네 번째로, error_log는 문제가 발생했을 때만 기록합니다. 레벨은 debug, info, notice, warn, error, crit, alert, emerg 순으로 심각도가 높아지며, warn으로 설정하면 경고 이상만 기록됩니다.

debug는 개발 환경에서 유용하지만 프로덕션에서는 로그가 너무 많아 디스크를 채우므로 warn이나 error가 적절합니다. 다섯 번째로, location 블록마다 다른 로그 파일을 사용할 수 있습니다.

/api 경로는 별도의 api.log에 기록하여 API 전용 분석을 할 수 있습니다. 반대로 정적 파일이나 health check는 access_log off로 로깅을 끄면 불필요한 로그를 줄일 수 있습니다.

health check는 모니터링 도구가 매초 요청하므로 로깅하면 쓸모없는 로그가 대부분을 차지합니다. 여섯 번째로, 로그 로테이션 설정은 logrotate 도구로 관리됩니다.

daily는 매일 자정에 로테이션하고, rotate 14는 14일치를 보관하며, compress는 오래된 로그를 gzip으로 압축합니다. delaycompress는 최신 로그는 압축하지 않아 분석 도구가 바로 읽을 수 있게 하고, notifempty는 빈 로그는 로테이션하지 않습니다.

마지막으로, postrotate 스크립트는 로테이션 후 Nginx에게 USR1 시그널을 보내 로그 파일을 다시 엽니다. 이 과정이 없으면 Nginx가 계속 rotated된 파일에 쓰려고 해서 로그가 기록되지 않습니다.

sharedscripts는 여러 로그 파일이 있어도 스크립트를 한 번만 실행하도록 합니다. 여러분이 이 설정을 사용하면 모든 요청과 에러가 체계적으로 기록되어, 장애가 발생하면 로그를 통해 원인을 빠르게 찾을 수 있습니다.

JSON 포맷으로 기록하면 Filebeat나 Fluentd로 수집하여 Elasticsearch에 저장하고, Kibana로 대시보드를 만들어 실시간 모니터링할 수 있습니다. 또한 GoAccess 같은 도구로 로그를 분석하면 실시간 HTML 리포트를 생성하여 트래픽 패턴을 시각적으로 파악할 수 있습니다.

보안 측면에서는 비정상적인 접근 패턴(브루트 포스, SQL injection 시도 등)을 탐지하여 차단할 수도 있습니다.

실전 팁

💡 GoAccess를 사용하면 터미널에서 실시간 로그 분석이 가능합니다. "goaccess /var/log/nginx/access.log -c"로 실행하면 방문자, 요청 수, 인기 페이지 등을 즉시 볼 수 있습니다.

💡 로그에 $request_id를 추가하면 요청을 고유하게 식별할 수 있습니다. 백엔드 로그와 Nginx 로그를 같은 request_id로 연결하여 end-to-end 추적이 가능해집니다.

💡 민감한 정보(비밀번호, 토큰)가 URL에 포함되지 않도록 주의하세요. 만약 포함된다면 map 디렉티브로 마스킹할 수 있습니다. 예: $request_uri에서 password 파라미터를 ***로 치환.

💡 CloudWatch, Datadog, New Relic 같은 APM 도구와 통합하려면 에이전트를 설치하거나, 로그를 S3에 업로드하여 중앙 집중식으로 관리하세요.

💡 에러 로그에서 자주 나오는 패턴을 찾아 수정하세요. "awk '{print $9}' /var/log/nginx/error.log | sort | uniq -c | sort -rn"으로 가장 많이 발생한 에러를 찾을 수 있습니다.

10. 무중단 배포와 버전 관리

시작하며

여러분이 웹 애플리케이션을 업데이트하려고 서버를 재시작했는데, 그 사이에 접속한 사용자들이 에러 페이지를 보거나 연결이 끊기는 경험을 해보셨나요? 특히 결제 중이던 사용자가 있다면 큰 문제가 될 수 있습니다.

이런 문제는 다운타임이 발생하는 배포 방식 때문입니다. 기존 서버를 내리고 새 버전을 올리는 동안 서비스가 중단되어 사용자 경험이 나빠지고, 매출 손실도 발생할 수 있습니다.

24/7 운영이 필수인 현대 웹 서비스에서는 용납할 수 없습니다. 바로 이럴 때 필요한 것이 Nginx를 활용한 무중단 배포(Blue-Green Deployment 또는 Rolling Update)입니다.

새 버전을 준비한 후 트래픽을 점진적으로 전환하면, 사용자는 서비스 중단을 전혀 느끼지 못합니다.

개요

간단히 말해서, 무중단 배포는 서비스를 중단하지 않고 새 버전으로 업데이트하는 기술로, 이전 버전과 새 버전을 동시에 실행하며 트래픽을 전환합니다. 실무에서는 Blue-Green 배포나 Canary 배포를 많이 사용합니다.

예를 들어, Blue 환경(현재 버전)에서 서비스하다가 Green 환경(새 버전)을 준비하고, 테스트 후 Nginx 설정을 바꿔 트래픽을 Green으로 전환합니다. 문제가 있으면 즉시 Blue로 되돌릴 수 있습니다.

기존에는 메인터넌스 모드를 띄우고 서버를 재시작했다면, 이제는 upstream 서버를 하나씩 교체하여 사용자는 평소와 다름없이 서비스를 이용할 수 있습니다. 무중단 배포의 핵심은 네 가지입니다: 여러 버전 동시 실행, upstream 동적 전환, 헬스 체크로 안전성 확보, 빠른 롤백 메커니즘.

이를 통해 배포 위험을 최소화하고 빈번한 릴리스가 가능해집니다.

코드 예제

# Blue-Green 배포 설정
upstream backend_blue {
    server 192.168.1.101:3000;  # 현재 운영 버전 (Blue)
    server 192.168.1.102:3000;
}

upstream backend_green {
    server 192.168.1.103:3000;  # 새 버전 (Green)
    server 192.168.1.104:3000;
}

# 심볼릭 링크로 활성 upstream 전환
# ln -sf /etc/nginx/sites-available/green /etc/nginx/conf.d/active-backend.conf

map $cookie_version $backend_upstream {
    "green" backend_green;
    default backend_blue;
}

server {
    listen 80;
    server_name app.example.com;

    location / {
        # Canary 배포: 10%만 Green으로
        split_clients "${remote_addr}${http_user_agent}" $upstream_variant {
            10%     backend_green;
            *       backend_blue;
        }

        proxy_pass http://$upstream_variant;

        # 연결 유지 설정 (무중단 reload를 위해)
        proxy_http_version 1.1;
        proxy_set_header Connection "";

        # 헬스 체크 (Nginx Plus 또는 별도 모듈 필요)
        # health_check interval=5s fails=3 passes=2;
    }

    # 버전 정보 엔드포인트
    location /version {
        default_type application/json;
        return 200 '{"version":"blue","timestamp":"2024-01-15"}';
    }
}

# Graceful reload 스크립트
# nginx -t && nginx -s reload

설명

이것이 하는 일: 무중단 배포 설정은 여러 버전의 애플리케이션을 동시에 실행하고, 트래픽을 점진적으로 새 버전으로 전환하며, 문제 발생 시 즉시 이전 버전으로 롤백할 수 있게 합니다. 첫 번째로, upstream 블록에서 backend_blue와 backend_green 두 환경을 정의합니다.

Blue는 현재 안정적으로 운영 중인 버전이고, Green은 새로 배포할 버전입니다. 각 환경은 독립적인 서버나 포트에서 실행되며, 같은 코드베이스의 다른 버전입니다.

예를 들어, Blue는 v1.5.0, Green은 v1.6.0입니다. 그 다음으로, map 디렉티브를 사용해 쿠키 기반으로 버전을 선택할 수 있습니다.

$cookie_version이 "green"이면 backend_green으로, 그렇지 않으면 backend_blue로 라우팅합니다. 이를 활용하면 테스트 팀이나 베타 사용자에게만 쿠키를 설정하여 새 버전을 미리 체험하게 할 수 있습니다.

세 번째로, split_clients 디렉티브는 Canary 배포를 구현합니다. 클라이언트 IP와 User-Agent를 해시하여 10%는 Green, 90%는 Blue로 보냅니다.

이렇게 일부 사용자에게만 새 버전을 노출하고, 에러율이나 성능을 모니터링한 후 점진적으로 비율을 늘립니다(10% → 50% → 100%). 문제가 발견되면 비율을 0%로 줄여 즉시 롤백합니다.

네 번째로, proxy_http_version 1.1과 Connection "" 설정은 keep-alive 연결을 활성화합니다. 이는 Nginx 재시작 시에도 기존 연결을 유지하여 사용자 세션이 끊기지 않게 합니다.

Nginx는 "nginx -s reload" 명령으로 graceful reload를 지원하는데, 기존 워커 프로세스는 현재 요청을 처리 완료한 후 종료하고, 새 워커가 새 요청을 받습니다. 다섯 번째로, /version 엔드포인트는 현재 어느 버전이 실행 중인지 확인할 수 있게 합니다.

배포 스크립트나 모니터링 도구가 이 엔드포인트를 호출하여 배포가 정상적으로 완료되었는지 검증합니다. JSON 형식으로 버전 번호와 배포 시간을 반환합니다.

여섯 번째로, 헬스 체크는 백엔드 서버가 정상인지 주기적으로 확인합니다. Nginx Plus(유료)는 내장 health_check를 지원하지만, 오픈소스 버전은 외부 모듈이나 스크립트를 사용해야 합니다.

interval=5s는 5초마다 체크하고, fails=3은 3번 연속 실패 시 서버를 제외하며, passes=2는 2번 연속 성공 시 다시 포함시킵니다. 실제 배포 프로세스는 다음과 같습니다: (1) Green 환경에 새 버전 배포, (2) /version 엔드포인트로 Green 정상 확인, (3) split_clients 비율을 10%로 설정하여 일부 트래픽 전환, (4) 에러 로그와 메트릭 모니터링, (5) 문제 없으면 50%, 100%로 증가, (6) 완전 전환 후 Blue 환경 종료.

문제가 발견되면 즉시 비율을 0%로 돌려 롤백합니다. 여러분이 이 설정을 사용하면 하루에도 여러 번 배포할 수 있고, 사용자는 서비스 중단을 전혀 느끼지 못합니다.

DevOps 문화에서 강조하는 CI/CD 파이프라인의 핵심 요소이며, 배포 공포증(deployment fear)을 없애줍니다. 또한 A/B 테스트에도 활용할 수 있어, 새 기능의 효과를 측정한 후 전체 출시를 결정할 수 있습니다.

Docker나 Kubernetes와 함께 사용하면 더욱 강력한 배포 자동화가 가능합니다.

실전 팁

💡 배포 전에 반드시 "nginx -t"로 설정 파일 문법을 검증하세요. 잘못된 설정으로 reload하면 Nginx가 시작하지 않아 서비스 전체가 중단될 수 있습니다.

💡 Blue와 Green 환경을 완전히 동일하게 유지하세요(같은 OS, 라이브러리, 데이터베이스 스키마). 환경 차이 때문에 Green에서만 버그가 발생하면 무중단 배포의 의미가 없습니다.

💡 데이터베이스 마이그레이션은 backward compatible하게 작성하세요. 예를 들어, 컬럼을 삭제하는 대신 deprecated로 표시하고 다음 배포 때 삭제하면, Blue 버전도 계속 작동합니다.

💡 심볼릭 링크를 활용하면 설정 전환이 간단합니다. "/etc/nginx/conf.d/active.conf -> blue.conf"처럼 링크를 만들고, 배포 시 "ln -sf green.conf active.conf && nginx -s reload"로 전환합니다.

💡 모니터링 대시보드에 Blue/Green 비율을 표시하고, 에러율과 응답 시간을 버전별로 분리하여 추적하세요. Grafana 같은 도구로 실시간으로 비교할 수 있습니다.

#Nginx#ReverseProxy#LoadBalancing#SSL#Configuration#Nginx,프로젝트,실전

Nginx 실전 프로젝트 완벽 가이드

# Nginx 실전 프로젝트 완벽 가이드 실무에서 바로 사용할 수 있는 Nginx 프로젝트 구성부터 배포까지, 초급 개발자도 쉽게 따라할 수 있는 실전 가이드입니다. 리버스 프록시, 로드 밸런싱, SSL 인증서 설정 등 핵심 기능을 실습합니다. --- ## 목차 1. [Nginx 기본 설정과 프로젝트 구조](#nginx-기본-설정과-프로젝트-구조) 2. [정적 파일 서빙과 SPA 라우팅](#정적-파일-서빙과-spa-라우팅) 3. [리버스 프록시로 Node.js 앱 배포하기](#리버스-프록시로-node.js-앱-배포하기) 4. [SSL/TLS 인증서 설정과 HTTPS 적용](#ssl/tls-인증서-설정과-https-적용) 5. [로드 밸런싱으로 트래픽 분산하기](#로드-밸런싱으로-트래픽-분산하기) 6. [Gzip 압축으로 성능 최적화](#gzip-압축으로-성능-최적화) 7. [접근 제어와 보안 헤더 설정](#접근-제어와-보안-헤더-설정) 8. [캐싱 전략으로 서버 부하 줄이기](#캐싱-전략으로-서버-부하-줄이기) 9. [로그 분석과 모니터링 설정](#로그-분석과-모니터링-설정) 10. [무중단 배포와 버전 관리](#무중단-배포와-버전-관리) --- ## 1. Nginx 기본 설정과 프로젝트 구조 ### 시작하며 여러분이 웹 애플리케이션을 개발하고 나서 서버에 배포하려고 할 때, 어디서부터 시작해야 할지 막막했던 경험이 있나요? Apache도 있고, Nginx도 있고, 클라우드 서비스도 있는데 무엇을 선택해야 할지 고민되셨을 겁니다. 이런 문제는 많은 초급 개발자들이 겪는 첫 번째 관문입니다. 특히 Nginx는 설정 파일의 구조가 낯설고, 어떤 디렉토리에 무엇을 넣어야 하는지 헷갈리기 쉽습니다. 바로 이럴 때 필요한 것이 체계적인 Nginx 프로젝트 구조입니다. 올바른 디렉토리 구조와 기본 설정을 이해하면, 어떤 프로젝트든 빠르게 배포할 수 있습니다. ### 개요 간단히 말해서, Nginx 프로젝트 구조는 웹 서버를 효율적으로 관리하기 위한 파일과 디렉토리의 체계적인 배치입니다. 실무에서는 하나의 서버에 여러 개의 웹사이트나 애플리케이션을 운영하는 경우가 많습니다. 예를 들어, 메인 웹사이트, API 서버, 관리자 페이지를 모두 하나의 서버에서 운영해야 하는 경우, 각각을 독립적으로 관리할 수 있는 구조가 필요합니다. 기존에는 설정 파일 하나에 모든 것을 작성했다면, 이제는 sites-available과 sites-enabled 디렉토리를 활용하여 각 사이트를 모듈화하여 관리할 수 있습니다. Nginx의 핵심 구조는 크게 세 가지로 나뉩니다: 메인 설정 파일(nginx.conf), 사이트별 설정 파일(sites-available), 그리고 실제 웹 콘텐츠가 위치하는 디렉토리(/var/www)입니다. 이러한 구조를 이해하면 프로젝트 관리가 훨씬 수월해집니다. ### 코드 예제 ```javascript # Nginx 기본 프로젝트 구조 /etc/nginx/ ├── nginx.conf # 메인 설정 파일 ├── sites-available/ # 사용 가능한 사이트 설정들 │ ├── default │ ├── myapp.conf # 여러분의 앱 설정 │ └── api.conf # API 서버 설정 ├── sites-enabled/ # 실제 활성화된 사이트들 (심볼릭 링크) │ └── myapp.conf -> ../sites-available/myapp.conf └── conf.d/ # 추가 설정 파일들 └── ssl.conf # SSL 관련 설정 /var/www/ ├── myapp/ # 여러분의 앱 파일들 │ └── index.html └── api/ # API 서버 파일들 ``` ### 설명 이것이 하는 일: Nginx는 계층적인 디렉토리 구조를 통해 여러 웹사이트와 애플리케이션을 효율적으로 관리합니다. 각 설정은 독립적으로 작성되고, 필요에 따라 활성화하거나 비활성화할 수 있습니다. 첫 번째로, /etc/nginx/nginx.conf 파일은 Nginx의 전체 동작을 제어하는 마스터 설정 파일입니다. 여기에는 워커 프로세스 수, 연결 제한, 로그 파일 위치 등 글로벌 설정이 들어갑니다. 이 파일을 직접 수정하기보다는, include 디렉티브를 통해 다른 설정 파일들을 불러오는 방식을 사용합니다. 그 다음으로, sites-available 디렉토리에는 여러분이 관리하는 모든 사이트의 설정 파일이 저장됩니다. 각 파일은 server 블록을 포함하며, 도메인, 포트, 루트 디렉토리 등을 정의합니다. 이곳에 파일이 있다고 해서 바로 활성화되는 것은 아닙니다. 세 번째로, sites-enabled 디렉토리에 심볼릭 링크를 생성해야 실제로 사이트가 활성화됩니다. 이는 "ln -s /etc/nginx/sites-available/myapp.conf /etc/nginx/sites-enabled/" 명령으로 만들 수 있습니다. 이렇게 분리함으로써, 설정 파일을 삭제하지 않고도 사이트를 임시로 비활성화할 수 있습니다. 마지막으로, /var/www 디렉토리는 실제 웹 콘텐츠가 위치하는 곳입니다. 각 사이트별로 하위 디렉토리를 만들어 관리하면, 파일이 섞이지 않고 깔끔하게 유지됩니다. 여러분이 이 구조를 사용하면 프로젝트 추가, 수정, 삭제가 매우 간단해집니다. 새 프로젝트를 추가할 때는 sites-available에 설정 파일만 만들고 심볼릭 링크를 생성하면 되고, 삭제할 때는 링크만 제거하면 됩니다. 또한 설정 파일을 버전 관리 시스템에 포함시켜 팀원들과 공유할 수도 있습니다. ### 실전 팁 💡 새 사이트를 추가할 때는 먼저 sites-available에 설정을 작성하고, "nginx -t" 명령으로 문법 오류를 확인한 후 심볼릭 링크를 만드세요. 이렇게 하면 잘못된 설정으로 인한 서버 중단을 방지할 수 있습니다. 💡 sites-available의 설정 파일 이름은 도메인 이름이나 프로젝트 이름을 사용하면 관리가 쉽습니다. 예를 들어 "api.example.com.conf" 처럼 명확한 이름을 사용하세요. 💡 /var/www 디렉토리의 파일 권한을 적절히 설정하세요. "chown -R www-data:www-data /var/www/myapp"로 Nginx가 파일에 접근할 수 있도록 해야 합니다. 💡 설정 변경 후에는 "sudo systemctl reload nginx" 명령으로 설정을 다시 로드하세요. restart 대신 reload를 사용하면 기존 연결을 끊지 않고 새 설정을 적용할 수 있습니다. 💡 conf.d 디렉토리는 공통 설정(SSL, 보안 헤더 등)을 모듈화하는 데 활용하세요. 모든 사이트에서 include 디렉티브로 불러올 수 있어 중복을 줄일 수 있습니다. --- ## 2. 정적 파일 서빙과 SPA 라우팅 ### 시작하며 여러분이 React나 Vue로 만든 싱글 페이지 애플리케이션(SPA)을 Nginx로 배포했는데, 메인 페이지는 잘 뜨는데 /about이나 /products 같은 하위 경로로 직접 접근하면 404 에러가 나는 경험을 해보셨나요? 새로고침할 때마다 페이지를 찾을 수 없다는 메시지가 뜨면 정말 답답합니다. 이런 문제는 SPA의 클라이언트 사이드 라우팅과 서버의 파일 시스템 라우팅이 충돌하기 때문에 발생합니다. Nginx는 /about 경로에 실제 about.html 파일이 있을 것으로 기대하지만, SPA는 모든 경로를 index.html로 처리하기 때문입니다. 바로 이럴 때 필요한 것이 Nginx의 try_files 디렉티브입니다. 이를 올바르게 설정하면 SPA 라우팅이 완벽하게 작동하고, 정적 파일도 효율적으로 서빙할 수 있습니다. ### 개요 간단히 말해서, 정적 파일 서빙은 HTML, CSS, JavaScript, 이미지 같은 파일들을 사용자에게 직접 전달하는 것이고, SPA 라우팅 설정은 모든 경로 요청을 index.html로 보내 클라이언트 측에서 라우팅을 처리하도록 하는 것입니다. 실무에서는 React, Vue, Angular 같은 프레임워크로 만든 애플리케이션을 배포할 때 이 설정이 반드시 필요합니다. 예를 들어, 사용자가 https://example.com/dashboard 링크를 북마크했다가 나중에 다시 방문하면, Nginx가 이를 올바르게 처리해야 합니다. 기존에는 Apache의 .htaccess 파일로 리다이렉트 규칙을 작성했다면, Nginx에서는 try_files와 location 블록을 조합하여 더 빠르고 효율적으로 처리할 수 있습니다. 핵심 특징은 두 가지입니다: 첫째, 실제 파일이 존재하면 그것을 서빙하고, 둘째, 파일이 없으면 index.html로 폴백하여 클라이언트 라우터가 처리하도록 합니다. 이를 통해 직접 URL 접근과 새로고침이 모두 정상적으로 작동합니다. ### 코드 예제 ```javascript server { listen 80; server_name myapp.com; root /var/www/myapp/dist; index index.html; # SPA 라우팅을 위한 설정 location / { # 1. 요청된 파일이 존재하면 그것을 서빙 # 2. 디렉토리가 존재하면 그것을 서빙 # 3. 둘 다 없으면 index.html로 폴백 try_files $uri $uri/ /index.html; } # 정적 파일 캐싱 설정 location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2)$ { expires 1y; add_header Cache-Control "public, immutable"; } # API 요청은 백엔드로 프록시 location /api { proxy_pass http://localhost:3000; } } ``` ### 설명 이것이 하는 일: 이 설정은 Nginx가 정적 파일을 효율적으로 서빙하면서도, SPA의 클라이언트 사이드 라우팅을 완벽하게 지원하도록 만듭니다. 모든 경로 요청을 적절히 처리하여 사용자 경험을 해치지 않습니다. 첫 번째로, root 디렉티브는 웹 콘텐츠의 루트 디렉토리를 지정합니다. React나 Vue를 빌드하면 보통 dist나 build 디렉토리가 생성되는데, 이 경로를 정확히 지정해야 합니다. index 디렉티브는 디렉토리 요청 시 기본적으로 제공할 파일을 지정합니다. 그 다음으로, location / 블록에서 try_files 디렉티브가 핵심적인 역할을 합니다. $uri는 요청된 경로에 실제 파일이 있는지 확인하고, $uri/는 디렉토리인지 확인합니다. 둘 다 존재하지 않으면 마지막 인자인 /index.html을 반환합니다. 예를 들어, /about 요청이 오면 about 파일이나 about 디렉토리를 찾고, 없으면 index.html을 반환하여 React Router가 /about 경로를 처리하도록 합니다. 세 번째로, 정규표현식 location 블록은 이미지, CSS, JavaScript 같은 정적 자산의 캐싱을 설정합니다. expires 1y는 1년 동안 브라우저 캐시에 저장하라는 의미이고, Cache-Control 헤더는 추가적인 캐싱 정책을 지정합니다. immutable 플래그는 파일이 절대 변경되지 않음을 브라우저에 알려 재검증 요청을 방지합니다. 네 번째로, /api로 시작하는 요청은 백엔드 서버로 프록시됩니다. proxy_pass는 요청을 다른 서버로 전달하는 디렉티브입니다. 이렇게 하면 프론트엔드와 백엔드를 같은 도메인에서 운영하면서도 CORS 문제를 피할 수 있습니다. 여러분이 이 설정을 사용하면 SPA가 완벽하게 작동하고, 정적 파일은 효율적으로 캐싱되며, API 요청은 백엔드로 깔끔하게 전달됩니다. 특히 캐싱 설정으로 인해 반복 방문자의 페이지 로딩 속도가 크게 향상되고, 서버 부하도 줄어듭니다. 또한 웹팩이나 Vite의 해시된 파일명과 함께 사용하면 캐시 무효화도 자동으로 처리됩니다. ### 실전 팁 💡 빌드 도구(webpack, Vite 등)가 생성하는 파일명에 해시를 포함시키면, 코드 변경 시 자동으로 캐시가 갱신됩니다. 예: main.a3f2c1.js처럼 해시가 포함되면 파일이 바뀔 때마다 이름이 달라져 브라우저가 새 파일을 받습니다. 💡 개발 환경에서는 캐싱을 끄고 테스트하세요. "expires -1" 또는 "add_header Cache-Control no-cache"로 설정하면 항상 최신 파일을 받을 수 있습니다. 💡 try_files의 순서가 중요합니다. $uri를 먼저 확인하지 않으면 실제 파일(robots.txt, favicon.ico 등)도 index.html로 응답하게 되어 문제가 발생할 수 있습니다. 💡 location /api 블록에는 추가로 proxy_set_header 디렉티브를 사용해 원본 IP와 호스트 정보를 전달하세요. 백엔드에서 클라이언트 정보가 필요할 때 유용합니다. 💡 gzip 압축을 활성화하면 JavaScript와 CSS 파일 크기를 70% 이상 줄일 수 있습니다. nginx.conf에 "gzip on; gzip_types text/css application/javascript;"를 추가하세요. --- ## 3. 리버스 프록시로 Node.js 앱 배포하기 ### 시작하며 여러분이 Express나 Nest.js로 백엔드 API를 만들고 "node app.js"로 실행했는데, 포트 번호를 붙여야만 접속할 수 있어서 불편했던 경험이 있나요? http://example.com:3000 대신 http://example.com/api로 깔끔하게 접근하고 싶으셨을 겁니다. 이런 문제는 Node.js 애플리케이션을 직접 80번 포트에 바인딩하기 어렵고, 여러 앱을 동시에 운영하기도 까다롭기 때문에 발생합니다. 또한 SSL 인증서 관리, 정적 파일 서빙, 로드 밸런싱 같은 기능을 Node.js 코드에 직접 구현하는 것은 비효율적입니다. 바로 이럴 때 필요한 것이 Nginx 리버스 프록시입니다. Nginx를 프론트에 두고 Node.js 앱을 백엔드로 돌리면, 포트 관리, SSL, 캐싱, 보안을 모두 Nginx가 처리해줍니다. ### 개요 간단히 말해서, 리버스 프록시는 클라이언트의 요청을 받아 백엔드 서버로 전달하고, 그 응답을 다시 클라이언트에게 돌려주는 중간 서버입니다. 실무에서는 대부분의 프로덕션 환경에서 Node.js 앱을 직접 노출시키지 않고 Nginx 뒤에 둡니다. 예를 들어, React 프론트엔드는 정적 파일로 서빙하고, /api 경로는 Express 백엔드로 프록시하는 구조가 매우 흔합니다. 이렇게 하면 하나의 도메인에서 모든 것을 처리할 수 있습니다. 기존에는 Node.js 앱에서 직접 HTTPS를 설정하고 정적 파일을 서빙했다면, 이제는 Nginx가 이런 역할을 대신하고 Node.js는 순수하게 비즈니스 로직에만 집중할 수 있습니다. 리버스 프록시의 핵심 이점은 세 가지입니다: 보안(백엔드 서버를 숨김), 성능(정적 파일 캐싱과 압축), 유연성(여러 백엔드 서버로 로드 밸런싱). 이를 통해 안정적이고 확장 가능한 아키텍처를 구축할 수 있습니다. ### 코드 예제 ```javascript server { listen 80; server_name api.example.com; # 요청 크기 제한 (파일 업로드 고려) client_max_body_size 10M; # 로깅 설정 access_log /var/log/nginx/api.access.log; error_log /var/log/nginx/api.error.log; # Node.js 앱으로 프록시 location / { proxy_pass http://localhost:3000; # 원본 요청 정보 전달 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # WebSocket 지원 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; # 타임아웃 설정 proxy_connect_timeout 60s; proxy_read_timeout 60s; } } ``` ### 설명 이것이 하는 일: 리버스 프록시 설정은 클라이언트와 백엔드 서버 사이에서 중개자 역할을 하며, 요청을 전달하고 응답을 반환하는 동시에 다양한 부가 기능을 제공합니다. 첫 번째로, client_max_body_size는 클라이언트가 전송할 수 있는 최대 요청 크기를 지정합니다. 기본값은 1MB인데, 파일 업로드 기능이 있다면 이를 늘려야 합니다. 10M은 10메가바이트를 의미하며, 프로필 사진이나 문서 업로드에 충분한 크기입니다. 너무 크게 설정하면 DDoS 공격에 취약해질 수 있으니 적절한 값을 선택해야 합니다. 그 다음으로, proxy_pass 디렉티브가 실제 프록시 동작을 수행합니다. http://localhost:3000은 Node.js 앱이 실행되는 주소입니다. 이 주소는 외부에 노출되지 않고 Nginx만 접근할 수 있습니다. 클라이언트는 80번 포트로 요청하지만, 실제로는 3000번 포트의 앱이 응답하는 것입니다. 세 번째로, proxy_set_header 디렉티브들은 원본 요청 정보를 백엔드로 전달합니다. Host 헤더는 클라이언트가 요청한 도메인을 유지하고, X-Real-IP는 클라이언트의 실제 IP 주소를 전달하며, X-Forwarded-For는 프록시 체인을 추적합니다. 이 정보가 없으면 Node.js 앱은 모든 요청이 localhost에서 온 것으로 인식하여 IP 기반 제한이나 로깅이 제대로 작동하지 않습니다. 네 번째로, WebSocket 지원을 위한 설정이 포함되어 있습니다. proxy_http_version 1.1은 HTTP/1.1 프로토콜을 사용하도록 하고, Upgrade와 Connection 헤더는 WebSocket 연결 업그레이드를 처리합니다. 이 설정이 없으면 Socket.io 같은 실시간 통신 라이브러리가 작동하지 않습니다. 마지막으로, 타임아웃 설정으로 연결과 읽기 시간을 제어합니다. proxy_connect_timeout은 백엔드 서버 연결 시도 시간이고, proxy_read_timeout은 응답 대기 시간입니다. 무거운 처리가 필요한 API가 있다면 이 값을 늘려야 하고, 일반적인 API라면 60초면 충분합니다. 여러분이 이 설정을 사용하면 Node.js 앱을 포트 번호 없이 깔끔하게 서비스할 수 있고, SSL 인증서를 Nginx 레벨에서 한 번만 설정하면 됩니다. 또한 PM2나 systemd로 Node.js 앱이 재시작되어도 Nginx가 버퍼링하여 클라이언트 연결을 유지하고, 여러 백엔드 인스턴스로 로드 밸런싱도 쉽게 구성할 수 있습니다. 로그 파일도 Nginx와 Node.js 각각에서 관리하여 문제 발생 시 추적이 용이합니다. ### 실전 팁 💡 Node.js 앱은 절대 root 권한으로 실행하지 마세요. 일반 사용자로 1024 이상의 포트(3000, 4000 등)에서 실행하고, Nginx가 80/443 포트로 받아 프록시하는 것이 안전합니다. 💡 proxy_buffering을 활용하면 느린 클라이언트로 인한 백엔드 블로킹을 방지할 수 있습니다. Nginx가 백엔드 응답을 빠르게 받아 버퍼에 저장한 후 천천히 클라이언트에게 전송합니다. 💡 여러 Node.js 인스턴스를 운영한다면 upstream 블록을 사용하세요. "upstream backend { server localhost:3000; server localhost:3001; }"로 정의하고 "proxy_pass http://backend"로 사용하면 자동으로 로드 밸런싱됩니다. 💡 health check를 위해 특정 경로(/health)는 Nginx에서 직접 응답하도록 설정할 수 있습니다. "location /health { return 200 'OK'; }"처럼 설정하면 Node.js를 거치지 않고 빠르게 응답합니다. 💡 에러 페이지를 커스터마이징하려면 "error_page 502 503 504 /50x.html"을 추가하고, location = /50x.html 블록에서 친절한 에러 페이지를 제공하세요. 백엔드가 다운되어도 사용자에게 깔끔한 메시지를 보여줄 수 있습니다. --- ## 4. SSL/TLS 인증서 설정과 HTTPS 적용 ### 시작하며 여러분이 웹사이트를 만들었는데 브라우저 주소창에 "안전하지 않음"이라는 경고가 뜨는 것을 보신 적 있나요? 특히 로그인이나 결제 기능이 있는 사이트에서는 이런 경고가 치명적입니다. 사용자들이 신뢰하지 않고 떠나버릴 수 있습니다. 이런 문제는 HTTPS를 사용하지 않아서 발생합니다. HTTP는 데이터가 평문으로 전송되어 중간에 누구나 볼 수 있지만, HTTPS는 암호화하여 보안을 보장합니다. 요즘은 HTTPS가 선택이 아닌 필수이며, 검색 엔진 순위에도 영향을 미칩니다. 바로 이럴 때 필요한 것이 Let's Encrypt 같은 무료 SSL 인증서와 Nginx의 SSL 설정입니다. 몇 가지 명령어만으로 무료로 HTTPS를 적용할 수 있고, 자동 갱신까지 설정할 수 있습니다. ### 개요 간단히 말해서, SSL/TLS는 클라이언트와 서버 간의 통신을 암호화하는 프로토콜이고, 인증서는 서버의 신원을 증명하는 디지털 문서입니다. 실무에서는 Let's Encrypt를 이용해 무료로 인증서를 발급받는 것이 표준입니다. 예를 들어, 개인 블로그부터 중소기업 웹사이트까지 대부분 Let's Encrypt를 사용하며, Certbot이라는 도구로 자동화할 수 있습니다. 기존에는 인증서를 구매하고 수동으로 갱신해야 했다면, 이제는 Certbot이 발급부터 설치, 갱신까지 모두 자동으로 처리합니다. 3개월마다 자동으로 갱신되므로 만료 걱정도 없습니다. SSL 설정의 핵심은 세 가지입니다: 인증서와 개인키 파일 경로 지정, 강력한 암호화 프로토콜 사용, HTTP에서 HTTPS로 자동 리다이렉트. 이를 통해 완벽한 보안 등급(A+)을 받을 수 있습니다. ### 코드 예제 ```javascript # Certbot으로 인증서 발급 (명령줄에서 실행) # sudo certbot --nginx -d example.com -d www.example.com server { listen 80; server_name example.com www.example.com; # HTTP를 HTTPS로 강제 리다이렉트 return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name example.com www.example.com; # SSL 인증서 경로 (Certbot이 자동 생성) ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; # 강력한 SSL 설정 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256'; ssl_prefer_server_ciphers off; # HSTS 설정 (브라우저가 항상 HTTPS 사용하도록) add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; root /var/www/example; index index.html; location / { try_files $uri $uri/ /index.html; } } ``` ### 설명 이것이 하는 일: SSL/TLS 설정은 클라이언트와 서버 간의 모든 데이터를 암호화하여 도청과 변조를 방지하고, 서버의 신원을 인증하여 피싱 공격을 차단합니다. 첫 번째로, Certbot 명령어를 실행하면 Let's Encrypt가 도메인 소유권을 검증하고 인증서를 발급합니다. --nginx 옵션은 Nginx 설정 파일을 자동으로 수정해주고, -d 옵션으로 여러 도메인을 한 번에 등록할 수 있습니다. 검증 과정에서 Certbot은 웹 서버에 임시 파일을 생성하여 도메인 소유권을 확인하므로, 포트 80이 열려있어야 합니다. 그 다음으로, 첫 번째 server 블록은 HTTP(80번 포트) 요청을 모두 HTTPS로 리다이렉트합니다. return 301은 영구 리다이렉트를 의미하며, $server_name과 $request_uri 변수로 원래 요청했던 도메인과 경로를 유지합니다. 예를 들어, http://example.com/about 요청은 https://example.com/about으로 자동 전환됩니다. 세 번째로, HTTPS server 블록에서 listen 443 ssl http2는 443번 포트에서 SSL과 HTTP/2를 활성화합니다. HTTP/2는 여러 요청을 동시에 처리하여 페이지 로딩 속도를 크게 향상시킵니다. ssl_certificate와 ssl_certificate_key는 Certbot이 생성한 인증서 파일을 가리킵니다. 네 번째로, ssl_protocols는 사용할 TLS 버전을 지정합니다. TLSv1.0과 1.1은 보안 취약점이 있어 제외하고, 1.2와 1.3만 허용합니다. ssl_ciphers는 암호화 알고리즘 목록인데, ECDHE는 완전 순방향 비밀성(Perfect Forward Secrecy)을 제공하여 과거 통신 내용을 보호합니다. 마지막으로, HSTS(HTTP Strict Transport Security) 헤더는 브라우저에게 항상 HTTPS만 사용하라고 지시합니다. max-age=31536000은 1년(초 단위)을 의미하며, includeSubDomains는 모든 하위 도메인에도 적용됩니다. 이렇게 하면 사용자가 실수로 http://로 접근해도 브라우저가 자동으로 https://로 바꿔줍니다. 여러분이 이 설정을 사용하면 브라우저 주소창에 자물쇠 아이콘이 표시되고, SSL Labs 테스트에서 A 등급 이상을 받을 수 있습니다. 사용자 데이터가 암호화되어 중간자 공격을 방지하고, SEO 순위도 향상됩니다. 또한 Certbot의 자동 갱신 기능으로 인증서 만료 걱정 없이 운영할 수 있으며, 서브도메인도 쉽게 추가할 수 있습니다. ### 실전 팁 💡 Certbot 자동 갱신이 제대로 작동하는지 "sudo certbot renew --dry-run"으로 테스트하세요. 실제 갱신 없이 시뮬레이션만 해서 문제를 미리 발견할 수 있습니다. 💡 와일드카드 인증서(*.example.com)를 발급받으려면 DNS 인증이 필요합니다. "certbot --manual --preferred-challenges=dns -d *.example.com"을 사용하고, DNS TXT 레코드를 추가해야 합니다. 💡 SSL Labs(ssllabs.com/ssltest)에서 여러분의 사이트를 테스트하여 보안 등급을 확인하세요. A+ 등급을 받으면 매우 안전한 설정입니다. 💡 여러 도메인에 대한 인증서를 관리할 때는 각각 별도의 server 블록을 만들고, 같은 certbot 명령으로 한 번에 발급받을 수 있습니다. 하나의 인증서로 여러 도메인을 커버합니다. 💡 개발 환경에서는 mkcert 도구로 로컬 인증서를 만들어 사용하세요. Let's Encrypt는 공개 도메인이 필요하지만, mkcert는 localhost에서도 작동합니다. --- ## 5. 로드 밸런싱으로 트래픽 분산하기 ### 시작하며 여러분의 웹 애플리케이션이 인기를 얻어 사용자가 급증했는데, 서버 하나로는 감당이 안 되어 응답 시간이 느려지고 간혹 타임아웃이 발생하는 경험을 해보셨나요? 서버를 추가로 구매했지만, 어떻게 트래픽을 나눠야 할지 막막했을 겁니다. 이런 문제는 단일 서버의 처리 능력 한계 때문에 발생합니다. 한 서버에 모든 요청이 몰리면 CPU와 메모리가 포화 상태가 되고, 일부 사용자는 서비스를 이용하지 못합니다. 또한 서버가 다운되면 전체 서비스가 중단되는 단일 장애점(Single Point of Failure) 문제도 있습니다. 바로 이럴 때 필요한 것이 Nginx의 로드 밸런싱 기능입니다. 여러 백엔드 서버를 upstream으로 등록하고, Nginx가 똑똑하게 요청을 분산시켜 성능과 가용성을 모두 확보할 수 있습니다. ### 개요 간단히 말해서, 로드 밸런싱은 들어오는 트래픽을 여러 서버에 균등하게 분배하여 각 서버의 부하를 줄이고, 전체 시스템의 처리량과 안정성을 높이는 기술입니다. 실무에서는 수평 확장(Scale-out) 전략의 핵심입니다. 예를 들어, Black Friday 같은 트래픽 폭증 시기에 서버를 여러 대 추가하고 로드 밸런서로 분산시켜 안정적으로 서비스합니다. AWS의 ELB나 Google Cloud의 Load Balancer도 같은 원리로 작동합니다. 기존에는 값비싼 전용 하드웨어 로드 밸런서를 구매했다면, 이제는 Nginx를 소프트웨어 로드 밸런서로 사용하여 비용을 절감하고 유연하게 설정할 수 있습니다. 로드 밸런싱의 핵심 기능은 네 가지입니다: 다양한 분산 알고리즘(라운드 로빈, least_conn, ip_hash), 헬스 체크로 장애 서버 자동 제외, 가중치 설정으로 서버별 비율 조절, 세션 유지(sticky session). 이를 통해 고가용성 시스템을 구축할 수 있습니다. ### 코드 예제 ```javascript # upstream 블록에서 백엔드 서버들 정의 upstream backend_servers { # 로드 밸런싱 알고리즘 (기본은 라운드 로빈) least_conn; # 연결 수가 가장 적은 서버로 전달 # 백엔드 서버 목록 server 192.168.1.101:3000 weight=3; # 가중치 3 (더 많은 요청 처리) server 192.168.1.102:3000 weight=2; server 192.168.1.103:3000 weight=1 backup; # 백업 서버 (다른 서버 실패 시만 사용) # 헬스 체크 설정 server 192.168.1.104:3000 max_fails=3 fail_timeout=30s; # 같은 클라이언트는 같은 서버로 (세션 유지) ip_hash; } server { listen 80; server_name app.example.com; location / { proxy_pass http://backend_servers; # 백엔드 서버 정보 헤더 추가 proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 실패 시 다음 서버로 재시도 proxy_next_upstream error timeout http_500 http_502 http_503; } } ``` ### 설명 이것이 하는 일: 로드 밸런싱 설정은 클라이언트 요청을 여러 백엔드 서버에 지능적으로 분산시키고, 장애가 발생한 서버를 자동으로 제외하여 무중단 서비스를 제공합니다. 첫 번째로, upstream 블록에서 backend_servers라는 이름으로 서버 그룹을 정의합니다. 이 이름은 proxy_pass에서 사용되며, 여러 upstream을 정의하여 용도별로 다른 서버 그룹을 만들 수 있습니다. 예를 들어, api_servers와 web_servers를 따로 만들어 관리할 수 있습니다. 그 다음으로, least_conn 디렉티브는 현재 활성 연결 수가 가장 적은 서버로 새 요청을 보냅니다. 라운드 로빈(기본값)은 순서대로 돌아가며 분배하지만, 요청 처리 시간이 다를 경우 불균형이 생깁니다. least_conn은 실제 부하를 고려하여 더 효율적입니다. 다른 옵션으로는 random(무작위), ip_hash(IP 기반 해싱) 등이 있습니다. 세 번째로, server 디렉티브의 weight 파라미터는 서버별 가중치를 지정합니다. weight=3인 서버는 weight=1인 서버보다 3배 많은 요청을 처리합니다. 이는 서버 성능이 다를 때 유용하며, 예를 들어 CPU가 4코어인 서버에 weight=2, 8코어인 서버에 weight=4를 주면 효율적입니다. backup 파라미터는 평상시엔 사용하지 않고, 다른 모든 서버가 실패했을 때만 사용하는 예비 서버를 지정합니다. 네 번째로, max_fails와 fail_timeout은 헬스 체크 로직을 정의합니다. max_fails=3은 3번 연속 실패하면 해당 서버를 비활성화하고, fail_timeout=30s는 30초 후 다시 시도합니다. 이를 통해 장애가 발생한 서버로 요청이 가지 않아 사용자 경험이 나빠지는 것을 방지합니다. 다섯 번째로, ip_hash 디렉티브는 클라이언트 IP 주소를 해시하여 항상 같은 서버로 보냅니다. 이는 세션 정보가 서버에 저장되는 경우 필수적입니다. 예를 들어, 로그인 세션이 메모리에 있다면, 같은 사용자가 다른 서버로 가면 다시 로그인해야 합니다. 단, ip_hash와 weight를 함께 사용할 수 없다는 제약이 있습니다. 마지막으로, proxy_next_upstream은 백엔드 서버가 에러를 반환하거나 타임아웃이 발생하면 자동으로 다음 서버로 재시도합니다. http_500, http_502, http_503은 서버 에러 상태 코드이며, 이런 에러가 발생하면 즉시 다른 서버로 전환하여 사용자는 에러를 보지 않습니다. 여러분이 이 설정을 사용하면 트래픽이 증가해도 서버를 추가하기만 하면 자동으로 분산되고, 한 서버가 다운되어도 나머지 서버가 계속 서비스를 제공합니다. Docker Swarm이나 Kubernetes 없이도 간단한 고가용성 시스템을 구축할 수 있으며, PM2 클러스터 모드와 함께 사용하면 프로세스 레벨과 서버 레벨 모두에서 부하 분산이 이루어집니다. 또한 A/B 테스팅을 위해 일부 트래픽만 새 버전 서버로 보내는 카나리 배포도 가능합니다. ### 실전 팁 💡 실제 프로덕션에서는 upstream 서버들이 같은 코드와 데이터베이스를 공유해야 합니다. 세션은 Redis 같은 중앙 저장소에 두어 어느 서버에서든 접근 가능하게 하세요. 💡 Active Health Check를 위해 Nginx Plus(유료)를 사용하거나, 무료 대안으로 각 백엔드에 /health 엔드포인트를 만들고 모니터링 도구로 주기적으로 체크하세요. 💡 로드 밸런서 자체가 단일 장애점이 되지 않도록, keepalived나 HAProxy를 사용해 Nginx 로드 밸런서를 이중화하는 것이 좋습니다. 💡 성능 테스트 도구(Apache Bench, wrk, k6)로 부하 테스트를 해보세요. 서버 추가 시 실제로 처리량이 증가하는지 확인할 수 있습니다. 💡 로그에 $upstream_addr 변수를 추가하면 어느 백엔드 서버가 요청을 처리했는지 기록됩니다. "log_format upstreamlog '$remote_addr - $upstream_addr';"처럼 사용하세요. --- ## 6. Gzip 압축으로 성능 최적화 ### 시작하며 여러분의 웹사이트를 만들고 배포했는데, 사용자들이 페이지 로딩이 너무 느리다고 불평하는 경험을 해보셨나요? 개발자 도구의 Network 탭을 열어보니 JavaScript 파일 하나가 2MB나 되고, 다운로드하는 데 수 초가 걸리는 것을 발견했을 겁니다. 이런 문제는 번들 크기가 크고 압축되지 않은 채로 전송되기 때문에 발생합니다. 특히 모바일 네트워크나 느린 인터넷 환경에서는 치명적입니다. 사용자는 흰 화면만 보다가 이탈할 수 있고, 데이터 요금도 많이 나옵니다. 바로 이럴 때 필요한 것이 Gzip 압축입니다. Nginx에서 몇 줄의 설정만으로 텍스트 기반 파일을 70-90% 압축하여 전송할 수 있고, 페이지 로딩 속도를 극적으로 개선할 수 있습니다. ### 개요 간단히 말해서, Gzip 압축은 서버가 파일을 압축하여 전송하고, 브라우저가 압축을 풀어 사용하는 기술로, 네트워크 대역폭을 크게 절약합니다. 실무에서는 거의 모든 프로덕션 웹 서버에서 Gzip 압축을 활성화합니다. 예를 들어, 500KB짜리 JavaScript 파일이 압축되면 100KB 정도로 줄어들어 5배 빠르게 다운로드됩니다. 모든 모던 브라우저가 Gzip을 지원하므로 호환성 걱정도 없습니다. 기존에는 빌드 타임에 미리 압축 파일을 생성하거나, CDN에서 압축을 처리했다면, Nginx는 런타임에 동적으로 압축하거나 사전 압축된 파일을 서빙할 수 있습니다. Gzip 압축의 핵심은 세 가지입니다: 적절한 파일 타입 선택(HTML, CSS, JS, JSON), 압축 레벨 조정(1-9, 기본 6), 최소 파일 크기 설정(너무 작은 파일은 압축 안 함). 이를 통해 성능과 CPU 사용량의 균형을 맞출 수 있습니다. ### 코드 예제 ```javascript http { # Gzip 압축 활성화 gzip on; # 압축 레벨 (1-9, 6이 적절한 균형점) gzip_comp_level 6; # 압축할 파일 타입 지정 gzip_types text/plain text/css text/xml text/javascript application/javascript application/x-javascript application/json application/xml application/xml+rss application/rss+xml font/truetype font/opentype application/vnd.ms-fontobject image/svg+xml; # 최소 압축 파일 크기 (1KB 미만은 압축 안 함) gzip_min_length 1000; # 프록시된 요청도 압축 gzip_proxied any; # IE6에서는 압축 비활성화 (버그 있음) gzip_disable "msie6"; # Vary 헤더 추가 (캐시 프록시를 위해) gzip_vary on; # 압축 버퍼 크기 gzip_buffers 16 8k; } ``` ### 설명 이것이 하는 일: Gzip 압축 설정은 서버가 응답 파일을 압축하여 네트워크 전송량을 줄이고, 브라우저는 압축을 풀어 원본 파일을 사용하게 합니다. 이를 통해 대역폭을 절약하고 페이지 로딩 속도를 향상시킵니다. 첫 번째로, gzip on 디렉티브가 압축 기능을 활성화합니다. 기본값은 off이므로 반드시 명시해야 합니다. 이 설정만으로도 기본 파일 타입(text/html)은 압축되지만, JavaScript나 CSS를 압축하려면 추가 설정이 필요합니다. 그 다음으로, gzip_comp_level은 압축 강도를 지정합니다. 레벨 1은 가장 빠르지만 압축률이 낮고, 레벨 9는 최대 압축이지만 CPU를 많이 씁니다. 실무에서는 레벨 6이 가장 많이 사용되며, 레벨 9와 비교해도 파일 크기 차이는 5% 미만이지만 CPU 사용량은 훨씬 적습니다. 세 번째로, gzip_types는 압축할 MIME 타입을 나열합니다. 텍스트 기반 파일(HTML, CSS, JavaScript, JSON, XML)은 압축률이 70-90%로 매우 높지만, 이미지(JPEG, PNG)나 비디오는 이미 압축되어 있어 효과가 없습니다. 오히려 압축 시도로 CPU만 낭비하므로 제외해야 합니다. SVG는 XML 기반이므로 압축하면 좋고, 폰트 파일도 상황에 따라 압축할 수 있습니다. 네 번째로, gzip_min_length는 압축할 최소 파일 크기를 바이트 단위로 지정합니다. 1000(1KB)은 일반적인 값이며, 너무 작은 파일을 압축하면 헤더 오버헤드 때문에 오히려 커질 수 있습니다. 예를 들어, 100바이트짜리 HTML을 압축하면 Gzip 헤더와 푸터 때문에 더 커집니다. 다섯 번째로, gzip_proxied any는 프록시된 요청에 대한 응답도 압축합니다. Nginx가 리버스 프록시로 사용될 때 중요하며, any는 모든 프록시 응답을 압축하라는 의미입니다. 다른 옵션으로는 expired, no-cache 등이 있어 캐시 정책에 따라 선택적으로 압축할 수 있습니다. 여섯 번째로, gzip_vary on은 Vary: Accept-Encoding 헤더를 추가합니다. 이는 CDN이나 프록시 캐시에게 압축 버전과 비압축 버전을 별도로 캐시하라고 알려줍니다. 이 설정이 없으면 압축을 지원하지 않는 오래된 브라우저가 압축된 파일을 받아 깨질 수 있습니다. 마지막으로, gzip_disable은 특정 브라우저에서 압축을 비활성화합니다. IE6는 Gzip에 버그가 있어 제외하며, 정규표현식으로 User-Agent를 매칭합니다. 현대 웹에서는 IE6 사용자가 거의 없으므로 큰 영향은 없습니다. 여러분이 이 설정을 사용하면 JavaScript 번들이 500KB에서 100KB로 줄어들어 로딩 시간이 5배 빨라집니다. 특히 모바일 사용자에게 큰 혜택을 주며, 서버 대역폭 비용도 절감됩니다. Google PageSpeed Insights나 WebPageTest 같은 도구로 측정하면 성능 점수가 크게 향상되는 것을 볼 수 있습니다. 또한 webpack이나 Vite에서 gzip-webpack-plugin을 사용해 빌드 타임에 .gz 파일을 미리 생성하고, Nginx의 gzip_static on으로 서빙하면 런타임 CPU 부하를 0으로 만들 수 있습니다. ### 실전 팁 💡 Brotli 압축을 추가로 사용하면 Gzip보다 15-25% 더 압축됩니다. ngx_brotli 모듈을 설치하고 "brotli on; brotli_types ..."로 활성화하세요. 모던 브라우저는 대부분 지원합니다. 💡 개발 환경에서 압축을 테스트하려면 "curl -H 'Accept-Encoding: gzip' -I http://localhost"로 응답 헤더에 Content-Encoding: gzip이 있는지 확인하세요. 💡 압축률을 확인하려면 "gzip_comp_level 1"과 "9"를 각각 테스트하고 파일 크기를 비교해보세요. 대부분의 경우 6이 최적이지만, 트래픽이 매우 많다면 레벨을 높여 대역폭을 더 절약할 수 있습니다. 💡 이미 압축된 파일(JPEG, PNG, MP4, ZIP)은 gzip_types에 포함시키지 마세요. 압축 효과가 없고 CPU만 낭비합니다. 오히려 원본 그대로 전송하는 게 빠릅니다. 💡 CDN을 사용한다면 CDN 자체의 압축 기능을 활용하세요. Cloudflare, AWS CloudFront 등은 자동으로 압축하므로 Nginx에서 중복 압축할 필요가 없습니다. --- ## 7. 접근 제어와 보안 헤더 설정 ### 시작하며 여러분의 웹 애플리케이션이 공개되었는데, 관리자 페이지(/admin)에 누구나 접근할 수 있어서 걱정되는 경험을 해보셨나요? 또는 XSS 공격이나 클릭재킹 같은 보안 취약점에 대해 들었지만 어떻게 방어해야 할지 몰라 답답했을 겁니다. 이런 문제는 적절한 접근 제어와 보안 헤더가 없어서 발생합니다. 민감한 경로를 모두에게 공개하면 브루트 포스 공격이나 무단 접근의 대상이 되고, 보안 헤더가 없으면 브라우저가 악성 스크립트를 막을 수 없습니다. 바로 이럴 때 필요한 것이 Nginx의 접근 제어 디렉티브와 보안 헤더입니다. IP 기반 차단, HTTP 인증, 그리고 CSP 같은 보안 헤더로 다층 방어를 구축할 수 있습니다. ### 개요 간단히 말해서, 접근 제어는 특정 경로나 리소스에 대한 접근을 IP 주소나 인증 정보로 제한하는 것이고, 보안 헤더는 브라우저에게 보안 정책을 알려주는 HTTP 응답 헤더입니다. 실무에서는 관리자 페이지, 데이터베이스 관리 도구(phpMyAdmin 등), 내부 API를 특정 IP에서만 접근 가능하게 합니다. 예를 들어, 회사 사무실 IP나 VPN IP만 허용하고 나머지는 차단하여 외부 공격을 원천 차단합니다. 기존에는 애플리케이션 코드에서 권한 체크를 했다면, Nginx 레벨에서 먼저 필터링하면 애플리케이션까지 도달하지 않아 더 안전하고 효율적입니다. 보안 설정의 핵심은 네 가지입니다: IP 화이트리스트/블랙리스트, HTTP Basic 인증, 중요 보안 헤더(CSP, X-Frame-Options, HSTS), rate limiting. 이를 통해 OWASP Top 10 취약점 대부분을 방어할 수 있습니다. ### 코드 예제 ```javascript server { listen 443 ssl http2; server_name example.com; # 보안 헤더 설정 add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Content-Type-Options "nosniff" always; add_header X-XSS-Protection "1; mode=block" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';" always; # 일반 사용자 접근 가능 영역 location / { root /var/www/html; try_files $uri $uri/ /index.html; } # 관리자 페이지 - IP 제한 location /admin { # 허용할 IP만 나열 allow 192.168.1.0/24; # 회사 네트워크 allow 10.0.0.5; # VPN IP deny all; # 나머지 모두 차단 # HTTP Basic 인증 추가 (2중 보안) auth_basic "Admin Area"; auth_basic_user_file /etc/nginx/.htpasswd; proxy_pass http://localhost:3000; } # API Rate Limiting limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s; location /api { limit_req zone=api_limit burst=20 nodelay; limit_req_status 429; proxy_pass http://localhost:3000; } } ``` ### 설명 이것이 하는 일: 접근 제어와 보안 헤더 설정은 여러 계층에서 웹 애플리케이션을 보호하며, 무단 접근을 차단하고 브라우저의 보안 기능을 활성화하여 다양한 공격을 방어합니다. 첫 번째로, 보안 헤더 블록에서 여러 중요한 헤더를 추가합니다. X-Frame-Options: SAMEORIGIN은 같은 도메인에서만 iframe으로 삽입할 수 있게 하여 클릭재킹 공격을 방지합니다. X-Content-Type-Options: nosniff는 브라우저가 MIME 타입을 추측하지 못하게 하여 악성 파일 실행을 막습니다. X-XSS-Protection은 XSS 공격 감지 시 페이지 로딩을 차단합니다. always 플래그는 4xx, 5xx 에러 응답에도 헤더를 추가합니다. 그 다음으로, Content-Security-Policy(CSP) 헤더가 가장 강력한 보안 기능을 제공합니다. default-src 'self'는 모든 리소스를 같은 도메인에서만 로드하고, script-src는 JavaScript 출처를 제한하며, style-src는 CSS 출처를 제한합니다. 'unsafe-inline'은 인라인 스크립트/스타일을 허용하는데, 보안상 좋지 않지만 기존 코드 때문에 필요할 수 있습니다. 실무에서는 nonce나 hash를 사용해 특정 인라인 코드만 허용하는 게 좋습니다. 세 번째로, location /admin 블록에서 IP 기반 접근 제어를 설정합니다. allow 디렉티브는 허용할 IP나 CIDR 범위를 지정하고, deny all은 나머지 모든 IP를 차단합니다. 순서가 중요하며, Nginx는 위에서 아래로 평가하여 첫 번째 매칭되는 규칙을 적용합니다. 예를 들어, 192.168.1.0/24는 192.168.1.1부터 192.168.1.254까지 모두 허용합니다. 네 번째로, auth_basic 디렉티브는 HTTP Basic 인증을 활성화합니다. 사용자 이름과 비밀번호를 입력해야 접근할 수 있으며, auth_basic_user_file은 인증 정보가 저장된 파일 경로입니다. 이 파일은 "htpasswd -c /etc/nginx/.htpasswd admin" 명령으로 생성하며, 비밀번호가 암호화되어 저장됩니다. IP 제한과 함께 사용하면 이중 보안이 됩니다. 다섯 번째로, limit_req_zone은 rate limiting을 설정합니다. $binary_remote_addr는 클라이언트 IP를 바이너리 형식으로 저장하여 메모리를 절약하고, zone=api_limit:10m은 10MB 크기의 공유 메모리 영역을 생성하며(약 16만 개 IP 추적 가능), rate=10r/s는 초당 10개 요청으로 제한합니다. 마지막으로, location /api에서 실제 rate limiting을 적용합니다. limit_req는 정의한 zone을 사용하고, burst=20은 일시적으로 20개까지 버스트를 허용하며, nodelay는 버스트 요청을 즉시 처리합니다. limit_req_status 429는 제한 초과 시 429(Too Many Requests) 상태 코드를 반환합니다. 이를 통해 DDoS나 브루트 포스 공격을 효과적으로 차단합니다. 여러분이 이 설정을 사용하면 관리자 페이지가 외부 공격으로부터 안전하고, XSS나 클릭재킹 같은 일반적인 공격도 브라우저 레벨에서 차단됩니다. API는 과도한 요청으로부터 보호되어 서버 과부하를 방지하고, 보안 감사 도구(Security Headers, Mozilla Observatory)에서 높은 점수를 받을 수 있습니다. 또한 GDPR이나 개인정보보호법 준수에도 도움이 되며, 사용자 신뢰도가 향상됩니다. ### 실전 팁 💡 CSP 헤더는 처음에는 report-only 모드로 테스트하세요. "Content-Security-Policy-Report-Only"로 설정하면 위반 사항을 로그로만 기록하고 차단하지 않아 안전하게 테스트할 수 있습니다. 💡 .htpasswd 파일을 생성할 때는 bcrypt 알고리즘을 사용하세요. "htpasswd -B -c /etc/nginx/.htpasswd admin"으로 더 강력한 암호화를 사용합니다. 💡 cloudflare 같은 CDN을 사용한다면 실제 클라이언트 IP는 X-Forwarded-For나 CF-Connecting-IP 헤더에 있습니다. limit_req_zone에서 $http_x_forwarded_for를 사용하세요. 💡 보안 헤더가 제대로 적용되는지 securityheaders.com에서 테스트하세요. A+ 등급을 목표로 하고, 부족한 헤더를 추가하면 됩니다. 💡 geo 모듈을 사용하면 국가별 접근 제어도 가능합니다. "geo $country { default no; KR yes; }" 같이 설정하고 "if ($country = no) { return 403; }"로 특정 국가만 허용할 수 있습니다. --- ## 8. 캐싱 전략으로 서버 부하 줄이기 ### 시작하며 여러분의 블로그나 뉴스 사이트가 인기를 얻어 방문자가 늘었는데, 같은 페이지를 요청할 때마다 데이터베이스를 조회하고 HTML을 렌더링해서 서버 CPU가 100%를 찍는 경험을 해보셨나요? 특히 트렌드에 오르면 서버가 다운될 수도 있습니다. 이런 문제는 매번 동적으로 콘텐츠를 생성하기 때문에 발생합니다. 블로그 글은 한 번 작성되면 거의 변하지 않는데, 방문자 1000명이 같은 글을 보면 1000번 똑같은 작업을 반복합니다. 이는 엄청난 리소스 낭비입니다. 바로 이럴 때 필요한 것이 Nginx의 캐싱 기능입니다. 한 번 생성된 응답을 메모리나 디스크에 저장했다가 재사용하면, 백엔드 서버 부하를 90% 이상 줄이고 응답 속도도 10배 빨라집니다. ### 개요 간단히 말해서, 캐싱은 자주 요청되는 응답을 임시 저장소에 보관했다가 같은 요청이 오면 백엔드를 거치지 않고 바로 응답하는 기술입니다. 실무에서는 프록시 캐싱과 브라우저 캐싱을 조합하여 사용합니다. 예를 들어, WordPress 같은 CMS는 페이지 생성에 수백 ms가 걸리지만, Nginx 캐시를 사용하면 1-2ms로 응답할 수 있습니다. 또한 API 응답도 캐싱하여 데이터베이스 부하를 크게 줄입니다. 기존에는 Redis나 Memcached 같은 별도의 캐시 서버를 운영했다면, Nginx 내장 캐싱만으로도 대부분의 사용 사례를 커버할 수 있어 인프라가 단순해집니다. 캐싱 전략의 핵심은 네 가지입니다: 무엇을 캐싱할지(정적 vs 동적), 얼마나 오래 보관할지(TTL), 언제 무효화할지(purge), 어떤 조건에서 캐싱할지(query string, cookie). 이를 통해 최신성과 성능의 균형을 맞출 수 있습니다. ### 코드 예제 ```javascript # http 블록에 캐시 경로 정의 proxy_cache_path /var/cache/nginx/proxy levels=1:2 keys_zone=my_cache:10m max_size=1g inactive=60m use_temp_path=off; server { listen 80; server_name blog.example.com; # 정적 파일 브라우저 캐싱 location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { expires 1y; add_header Cache-Control "public, immutable"; } # 동적 콘텐츠 프록시 캐싱 location / { proxy_pass http://localhost:3000; # 캐시 활성화 proxy_cache my_cache; proxy_cache_valid 200 10m; # 성공 응답은 10분 proxy_cache_valid 404 1m; # 404는 1분 proxy_cache_use_stale error timeout http_500 http_502 http_503; # 캐시 상태를 응답 헤더에 추가 (디버깅용) add_header X-Cache-Status $upstream_cache_status; # 특정 조건에서는 캐싱 건너뛰기 proxy_cache_bypass $http_pragma $http_authorization; proxy_no_cache $http_pragma $http_authorization; # 캐시 키 정의 proxy_cache_key "$scheme$request_method$host$request_uri"; # 동시 요청 시 하나만 백엔드로 전달 proxy_cache_lock on; proxy_cache_lock_timeout 5s; } # 관리자는 캐싱하지 않음 location /admin { proxy_pass http://localhost:3000; proxy_cache_bypass 1; } } ``` ### 설명 이것이 하는 일: 캐싱 설정은 자주 요청되는 응답을 디스크나 메모리에 저장하여 백엔드 서버 호출을 최소화하고, 응답 시간을 극적으로 단축하며, 서버 장애 시에도 서비스를 유지합니다. 첫 번째로, proxy_cache_path는 캐시 저장 위치와 동작 방식을 정의합니다. /var/cache/nginx/proxy는 캐시 파일이 저장될 디렉토리이고, levels=1:2는 하위 디렉토리 구조를 2단계로 만들어 많은 파일을 효율적으로 관리합니다. keys_zone=my_cache:10m은 캐시 키를 저장할 공유 메모리 영역(10MB, 약 8만 개 키 저장 가능)을 만들고, max_size=1g은 최대 캐시 크기를 1GB로 제한합니다. 그 다음으로, inactive=60m은 60분 동안 접근되지 않은 캐시를 삭제하여 공간을 확보합니다. 인기 있는 페이지는 계속 캐시에 남고, 오래된 페이지는 자동으로 정리됩니다. use_temp_path=off는 임시 파일을 캐시 디렉토리에 직접 쓰도록 하여 디스크 I/O를 줄입니다. 세 번째로, location / 블록에서 proxy_cache my_cache로 앞서 정의한 캐시 영역을 사용합니다. proxy_cache_valid는 HTTP 상태 코드별로 캐시 유지 시간을 지정하는데, 200(성공)은 10분, 404(없음)는 1분만 캐싱합니다. 이렇게 하면 존재하지 않는 페이지에 대한 반복 요청도 백엔드를 거치지 않습니다. 네 번째로, proxy_cache_use_stale은 백엔드 서버가 에러를 반환하거나 응답하지 않을 때 오래된 캐시를 제공합니다. error, timeout, http_500, http_502, http_503 조건에서 작동하며, 이를 통해 백엔드가 다운되어도 사용자는 이전 콘텐츠를 볼 수 있어 서비스 가용성이 높아집니다. "stale-while-revalidate" 개념과 유사합니다. 다섯 번째로, X-Cache-Status 헤더는 캐시 상태를 응답에 추가합니다. 값으로는 HIT(캐시에서 제공), MISS(백엔드에서 가져옴), BYPASS(캐싱 건너뜀), EXPIRED(만료되어 재검증) 등이 있습니다. 개발자 도구에서 이 헤더를 확인하여 캐싱이 제대로 작동하는지 검증할 수 있습니다. 여섯 번째로, proxy_cache_bypass와 proxy_no_cache는 특정 조건에서 캐싱을 건너뜁니다. $http_pragma는 Pragma: no-cache 헤더가 있을 때, $http_authorization은 Authorization 헤더가 있을 때 캐싱하지 않습니다. 로그인한 사용자나 관리자의 요청은 개인화된 콘텐츠를 보아야 하므로 캐싱하면 안 됩니다. 일곱 번째로, proxy_cache_key는 캐시를 식별하는 키를 정의합니다. $scheme(http/https), $request_method(GET/POST), $host(도메인), $request_uri(경로와 query string)를 조합하여 고유한 키를 만듭니다. 같은 URL이라도 쿼리 파라미터가 다르면 별도로 캐싱됩니다. 마지막으로, proxy_cache_lock은 동일한 요청이 동시에 여러 개 들어올 때, 첫 번째 요청만 백엔드로 전달하고 나머지는 대기시킵니다. 예를 들어, 인기 기사가 캐시에 없을 때 1000명이 동시에 요청하면 1번만 백엔드로 가고 나머지는 캐시가 생성될 때까지 기다렸다가 모두 캐시된 응답을 받습니다. 이를 "cache stampede" 방지라고 합니다. 여러분이 이 설정을 사용하면 같은 페이지를 1000번 요청해도 백엔드는 1번만 처리하고, 응답 시간이 200ms에서 2ms로 줄어듭니다. 데이터베이스 부하가 극적으로 감소하여 더 많은 사용자를 수용할 수 있고, 트래픽 급증 시에도 안정적으로 서비스할 수 있습니다. CloudFlare 같은 CDN과 함께 사용하면 전 세계 사용자에게 밀리초 단위로 응답할 수 있으며, 서버 비용도 크게 절감됩니다. 또한 캐시 통계를 모니터링하여 히트율을 추적하고 최적화할 수 있습니다. ### 실전 팁 💡 캐시를 수동으로 삭제하려면 proxy_cache_purge 모듈을 사용하거나, 간단히 "rm -rf /var/cache/nginx/proxy/*"로 전체 캐시를 비울 수 있습니다. 콘텐츠 배포 후 캐시 갱신이 필요할 때 유용합니다. 💡 캐시 히트율을 모니터링하려면 access_log에 $upstream_cache_status를 추가하고, AWK나 분석 도구로 HIT/MISS 비율을 계산하세요. 80% 이상이면 효과적으로 작동하는 것입니다. 💡 API 응답을 캐싱할 때는 Cache-Control 헤더를 존중하세요. "proxy_cache_valid any 5m" 대신 "proxy_cache_revalidate on"으로 설정하면 백엔드의 ETag/Last-Modified를 활용하여 변경된 콘텐츠만 다시 받습니다. 💡 로그인한 사용자별로 다른 콘텐츠를 보여준다면 쿠키를 캐시 키에 포함시키세요. "proxy_cache_key $cookie_sessionid$request_uri"처럼 설정하면 사용자별로 캐시를 분리할 수 있습니다. 💡 메모리 캐시(tmpfs)를 사용하면 더 빠릅니다. "/dev/shm/nginx-cache"처럼 RAM 디스크에 캐시를 두면 디스크 I/O가 제거되어 응답 시간이 더 줄어듭니다. --- ## 9. 로그 분석과 모니터링 설정 ### 시작하며 여러분의 웹사이트가 운영 중인데, 갑자기 에러가 발생하거나 성능이 느려졌을 때 어디서부터 문제를 찾아야 할지 막막했던 경험이 있나요? 또는 얼마나 많은 사용자가 방문하는지, 어떤 페이지가 인기 있는지 알고 싶었지만 방법을 몰라 답답했을 겁니다. 이런 문제는 적절한 로깅과 모니터링이 없어서 발생합니다. 로그가 없으면 장애 원인을 찾을 수 없고, 사용자 행동을 분석할 수도 없으며, 공격을 탐지할 수도 없습니다. 운영은 가시성(observability)에서 시작됩니다. 바로 이럴 때 필요한 것이 Nginx의 로그 설정과 모니터링 도구입니다. 커스텀 로그 포맷으로 필요한 정보를 정확히 기록하고, 실시간으로 분석하여 문제를 조기에 발견할 수 있습니다. ### 개요 간단히 말해서, 로그는 서버에서 발생하는 모든 이벤트(요청, 에러, 접근 등)를 시간순으로 기록한 파일이고, 모니터링은 이를 분석하여 시스템 상태를 추적하는 것입니다. 실무에서는 access log로 모든 요청을 기록하고, error log로 문제를 추적하며, ELK Stack(Elasticsearch, Logstash, Kibana)이나 Grafana로 시각화합니다. 예를 들어, 404 에러가 급증하면 알람을 받아 즉시 대응할 수 있습니다. 기존에는 로그 파일을 직접 열어 grep으로 검색했다면, 이제는 로그 수집기가 자동으로 파싱하고 대시보드에 실시간으로 표시하여 인사이트를 얻을 수 있습니다. 로그 전략의 핵심은 네 가지입니다: 커스텀 로그 포맷(JSON 등), 적절한 로그 레벨(error, warn, info), 로그 로테이션(디스크 공간 관리), 중앙 집중식 수집. 이를 통해 대규모 시스템도 효과적으로 관리할 수 있습니다. ### 코드 예제 ```javascript # JSON 형식의 커스텀 로그 포맷 정의 log_format json_combined escape=json '{' '"time_local":"$time_local",' '"remote_addr":"$remote_addr",' '"request":"$request",' '"status":$status,' '"body_bytes_sent":$body_bytes_sent,' '"request_time":$request_time,' '"upstream_response_time":"$upstream_response_time",' '"http_referer":"$http_referer",' '"http_user_agent":"$http_user_agent",' '"http_x_forwarded_for":"$http_x_forwarded_for"' '}'; server { listen 80; server_name example.com; # Access Log (JSON 포맷) access_log /var/log/nginx/access.log json_combined; # Error Log (레벨 지정) error_log /var/log/nginx/error.log warn; # 특정 경로만 별도 로그 location /api { access_log /var/log/nginx/api.log json_combined; proxy_pass http://localhost:3000; } # 정적 파일은 로깅 제외 (선택적) location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ { access_log off; expires 1y; } # Health check는 로깅 안 함 location /health { access_log off; return 200 "OK\n"; add_header Content-Type text/plain; } } # 로그 로테이션 (/etc/logrotate.d/nginx) # /var/log/nginx/*.log { # daily # rotate 14 # compress # delaycompress # notifempty # create 0640 www-data adm # sharedscripts # postrotate # [ -f /var/run/nginx.pid ] && kill -USR1 `cat /var/run/nginx.pid` # endscript # } ``` ### 설명 이것이 하는 일: 로그 설정은 서버에서 발생하는 모든 이벤트를 체계적으로 기록하여 문제 해결, 성능 분석, 보안 감사, 사용자 행동 분석을 가능하게 합니다. 첫 번째로, log_format 디렉티브는 로그에 기록할 정보의 형식을 정의합니다. json_combined라는 이름으로 JSON 형식을 만들었는데, 이는 Elasticsearch나 Logstash 같은 도구가 쉽게 파싱할 수 있습니다. escape=json은 특수 문자를 JSON 규격에 맞게 이스케이프합니다. 기본 combined 포맷은 사람이 읽기 편하지만 파싱이 어려워 자동화에는 JSON이 더 좋습니다. 그 다음으로, 로그 포맷에 포함된 변수들을 살펴보면, $time_local은 요청 시간, $remote_addr은 클라이언트 IP, $request는 HTTP 메서드와 경로, $status는 응답 코드입니다. $request_time은 요청 처리 전체 시간이고, $upstream_response_time은 백엔드 서버 응답 시간입니다. 이 둘을 비교하면 Nginx와 백엔드 중 어디가 느린지 알 수 있습니다. 세 번째로, access_log 디렉티브는 모든 HTTP 요청을 기록합니다. /var/log/nginx/access.log 경로에 json_combined 포맷으로 저장되며, 하루에 수만 개의 요청이 쌓입니다. 이 로그를 분석하면 가장 많이 방문한 페이지, 트래픽 패턴, 응답 시간 분포 등을 알 수 있습니다. buffer=32k 옵션을 추가하면 메모리에 모았다가 한 번에 쓰여 I/O를 줄일 수 있습니다. 네 번째로, error_log는 문제가 발생했을 때만 기록합니다. 레벨은 debug, info, notice, warn, error, crit, alert, emerg 순으로 심각도가 높아지며, warn으로 설정하면 경고 이상만 기록됩니다. debug는 개발 환경에서 유용하지만 프로덕션에서는 로그가 너무 많아 디스크를 채우므로 warn이나 error가 적절합니다. 다섯 번째로, location 블록마다 다른 로그 파일을 사용할 수 있습니다. /api 경로는 별도의 api.log에 기록하여 API 전용 분석을 할 수 있습니다. 반대로 정적 파일이나 health check는 access_log off로 로깅을 끄면 불필요한 로그를 줄일 수 있습니다. health check는 모니터링 도구가 매초 요청하므로 로깅하면 쓸모없는 로그가 대부분을 차지합니다. 여섯 번째로, 로그 로테이션 설정은 logrotate 도구로 관리됩니다. daily는 매일 자정에 로테이션하고, rotate 14는 14일치를 보관하며, compress는 오래된 로그를 gzip으로 압축합니다. delaycompress는 최신 로그는 압축하지 않아 분석 도구가 바로 읽을 수 있게 하고, notifempty는 빈 로그는 로테이션하지 않습니다. 마지막으로, postrotate 스크립트는 로테이션 후 Nginx에게 USR1 시그널을 보내 로그 파일을 다시 엽니다. 이 과정이 없으면 Nginx가 계속 rotated된 파일에 쓰려고 해서 로그가 기록되지 않습니다. sharedscripts는 여러 로그 파일이 있어도 스크립트를 한 번만 실행하도록 합니다. 여러분이 이 설정을 사용하면 모든 요청과 에러가 체계적으로 기록되어, 장애가 발생하면 로그를 통해 원인을 빠르게 찾을 수 있습니다. JSON 포맷으로 기록하면 Filebeat나 Fluentd로 수집하여 Elasticsearch에 저장하고, Kibana로 대시보드를 만들어 실시간 모니터링할 수 있습니다. 또한 GoAccess 같은 도구로 로그를 분석하면 실시간 HTML 리포트를 생성하여 트래픽 패턴을 시각적으로 파악할 수 있습니다. 보안 측면에서는 비정상적인 접근 패턴(브루트 포스, SQL injection 시도 등)을 탐지하여 차단할 수도 있습니다. ### 실전 팁 💡 GoAccess를 사용하면 터미널에서 실시간 로그 분석이 가능합니다. "goaccess /var/log/nginx/access.log -c"로 실행하면 방문자, 요청 수, 인기 페이지 등을 즉시 볼 수 있습니다. 💡 로그에 $request_id를 추가하면 요청을 고유하게 식별할 수 있습니다. 백엔드 로그와 Nginx 로그를 같은 request_id로 연결하여 end-to-end 추적이 가능해집니다. 💡 민감한 정보(비밀번호, 토큰)가 URL에 포함되지 않도록 주의하세요. 만약 포함된다면 map 디렉티브로 마스킹할 수 있습니다. 예: $request_uri에서 password 파라미터를 ***로 치환. 💡 CloudWatch, Datadog, New Relic 같은 APM 도구와 통합하려면 에이전트를 설치하거나, 로그를 S3에 업로드하여 중앙 집중식으로 관리하세요. 💡 에러 로그에서 자주 나오는 패턴을 찾아 수정하세요. "awk '{print $9}' /var/log/nginx/error.log | sort | uniq -c | sort -rn"으로 가장 많이 발생한 에러를 찾을 수 있습니다. --- ## 10. 무중단 배포와 버전 관리 ### 시작하며 여러분이 웹 애플리케이션을 업데이트하려고 서버를 재시작했는데, 그 사이에 접속한 사용자들이 에러 페이지를 보거나 연결이 끊기는 경험을 해보셨나요? 특히 결제 중이던 사용자가 있다면 큰 문제가 될 수 있습니다. 이런 문제는 다운타임이 발생하는 배포 방식 때문입니다. 기존 서버를 내리고 새 버전을 올리는 동안 서비스가 중단되어 사용자 경험이 나빠지고, 매출 손실도 발생할 수 있습니다. 24/7 운영이 필수인 현대 웹 서비스에서는 용납할 수 없습니다. 바로 이럴 때 필요한 것이 Nginx를 활용한 무중단 배포(Blue-Green Deployment 또는 Rolling Update)입니다. 새 버전을 준비한 후 트래픽을 점진적으로 전환하면, 사용자는 서비스 중단을 전혀 느끼지 못합니다. ### 개요 간단히 말해서, 무중단 배포는 서비스를 중단하지 않고 새 버전으로 업데이트하는 기술로, 이전 버전과 새 버전을 동시에 실행하며 트래픽을 전환합니다. 실무에서는 Blue-Green 배포나 Canary 배포를 많이 사용합니다. 예를 들어, Blue 환경(현재 버전)에서 서비스하다가 Green 환경(새 버전)을 준비하고, 테스트 후 Nginx 설정을 바꿔 트래픽을 Green으로 전환합니다. 문제가 있으면 즉시 Blue로 되돌릴 수 있습니다. 기존에는 메인터넌스 모드를 띄우고 서버를 재시작했다면, 이제는 upstream 서버를 하나씩 교체하여 사용자는 평소와 다름없이 서비스를 이용할 수 있습니다. 무중단 배포의 핵심은 네 가지입니다: 여러 버전 동시 실행, upstream 동적 전환, 헬스 체크로 안전성 확보, 빠른 롤백 메커니즘. 이를 통해 배포 위험을 최소화하고 빈번한 릴리스가 가능해집니다. ### 코드 예제 ```javascript # Blue-Green 배포 설정 upstream backend_blue { server 192.168.1.101:3000; # 현재 운영 버전 (Blue) server 192.168.1.102:3000; } upstream backend_green { server 192.168.1.103:3000; # 새 버전 (Green) server 192.168.1.104:3000; } # 심볼릭 링크로 활성 upstream 전환 # ln -sf /etc/nginx/sites-available/green /etc/nginx/conf.d/active-backend.conf map $cookie_version $backend_upstream { "green" backend_green; default backend_blue; } server { listen 80; server_name app.example.com; location / { # Canary 배포: 10%만 Green으로 split_clients "${remote_addr}${http_user_agent}" $upstream_variant { 10% backend_green; * backend_blue; } proxy_pass http://$upstream_variant; # 연결 유지 설정 (무중단 reload를 위해) proxy_http_version 1.1; proxy_set_header Connection ""; # 헬스 체크 (Nginx Plus 또는 별도 모듈 필요) # health_check interval=5s fails=3 passes=2; } # 버전 정보 엔드포인트 location /version { default_type application/json; return 200 '{"version":"blue","timestamp":"2024-01-15"}'; } } # Graceful reload 스크립트 # nginx -t && nginx -s reload ``` ### 설명 이것이 하는 일: 무중단 배포 설정은 여러 버전의 애플리케이션을 동시에 실행하고, 트래픽을 점진적으로 새 버전으로 전환하며, 문제 발생 시 즉시 이전 버전으로 롤백할 수 있게 합니다. 첫 번째로, upstream 블록에서 backend_blue와 backend_green 두 환경을 정의합니다. Blue는 현재 안정적으로 운영 중인 버전이고, Green은 새로 배포할 버전입니다. 각 환경은 독립적인 서버나 포트에서 실행되며, 같은 코드베이스의 다른 버전입니다. 예를 들어, Blue는 v1.5.0, Green은 v1.6.0입니다. 그 다음으로, map 디렉티브를 사용해 쿠키 기반으로 버전을 선택할 수 있습니다. $cookie_version이 "green"이면 backend_green으로, 그렇지 않으면 backend_blue로 라우팅합니다. 이를 활용하면 테스트 팀이나 베타 사용자에게만 쿠키를 설정하여 새 버전을 미리 체험하게 할 수 있습니다. 세 번째로, split_clients 디렉티브는 Canary 배포를 구현합니다. 클라이언트 IP와 User-Agent를 해시하여 10%는 Green, 90%는 Blue로 보냅니다. 이렇게 일부 사용자에게만 새 버전을 노출하고, 에러율이나 성능을 모니터링한 후 점진적으로 비율을 늘립니다(10% → 50% → 100%). 문제가 발견되면 비율을 0%로 줄여 즉시 롤백합니다. 네 번째로, proxy_http_version 1.1과 Connection "" 설정은 keep-alive 연결을 활성화합니다. 이는 Nginx 재시작 시에도 기존 연결을 유지하여 사용자 세션이 끊기지 않게 합니다. Nginx는 "nginx -s reload" 명령으로 graceful reload를 지원하는데, 기존 워커 프로세스는 현재 요청을 처리 완료한 후 종료하고, 새 워커가 새 요청을 받습니다. 다섯 번째로, /version 엔드포인트는 현재 어느 버전이 실행 중인지 확인할 수 있게 합니다. 배포 스크립트나 모니터링 도구가 이 엔드포인트를 호출하여 배포가 정상적으로 완료되었는지 검증합니다. JSON 형식으로 버전 번호와 배포 시간을 반환합니다. 여섯 번째로, 헬스 체크는 백엔드 서버가 정상인지 주기적으로 확인합니다. Nginx Plus(유료)는 내장 health_check를 지원하지만, 오픈소스 버전은 외부 모듈이나 스크립트를 사용해야 합니다. interval=5s는 5초마다 체크하고, fails=3은 3번 연속 실패 시 서버를 제외하며, passes=2는 2번 연속 성공 시 다시 포함시킵니다. 실제 배포 프로세스는 다음과 같습니다: (1) Green 환경에 새 버전 배포, (2) /version 엔드포인트로 Green 정상 확인, (3) split_clients 비율을 10%로 설정하여 일부 트래픽 전환, (4) 에러 로그와 메트릭 모니터링, (5) 문제 없으면 50%, 100%로 증가, (6) 완전 전환 후 Blue 환경 종료. 문제가 발견되면 즉시 비율을 0%로 돌려 롤백합니다. 여러분이 이 설정을 사용하면 하루에도 여러 번 배포할 수 있고, 사용자는 서비스 중단을 전혀 느끼지 못합니다. DevOps 문화에서 강조하는 CI/CD 파이프라인의 핵심 요소이며, 배포 공포증(deployment fear)을 없애줍니다. 또한 A/B 테스트에도 활용할 수 있어, 새 기능의 효과를 측정한 후 전체 출시를 결정할 수 있습니다. Docker나 Kubernetes와 함께 사용하면 더욱 강력한 배포 자동화가 가능합니다. ### 실전 팁 💡 배포 전에 반드시 "nginx -t"로 설정 파일 문법을 검증하세요. 잘못된 설정으로 reload하면 Nginx가 시작하지 않아 서비스 전체가 중단될 수 있습니다. 💡 Blue와 Green 환경을 완전히 동일하게 유지하세요(같은 OS, 라이브러리, 데이터베이스 스키마). 환경 차이 때문에 Green에서만 버그가 발생하면 무중단 배포의 의미가 없습니다. 💡 데이터베이스 마이그레이션은 backward compatible하게 작성하세요. 예를 들어, 컬럼을 삭제하는 대신 deprecated로 표시하고 다음 배포 때 삭제하면, Blue 버전도 계속 작동합니다. 💡 심볼릭 링크를 활용하면 설정 전환이 간단합니다. "/etc/nginx/conf.d/active.conf -> blue.conf"처럼 링크를 만들고, 배포 시 "ln -sf green.conf active.conf && nginx -s reload"로 전환합니다. 💡 모니터링 대시보드에 Blue/Green 비율을 표시하고, 에러율과 응답 시간을 버전별로 분리하여 추적하세요. Grafana 같은 도구로 실시간으로 비교할 수 있습니다. ---

카테고리: Nginx,프로젝트,실전

언어: JavaScript

태그: Nginx, ReverseProxy, LoadBalancing, SSL, Configuration, Nginx,프로젝트,실전

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

Nginx 실전 프로젝트 완벽 가이드

목차

1. Nginx 기본 설정과 프로젝트 구조

시작하며

개요

코드 예제

설명

실전 팁

2. 정적 파일 서빙과 SPA 라우팅

시작하며

개요

코드 예제

설명

실전 팁

3. 리버스 프록시로 Node.js 앱 배포하기

시작하며

개요

코드 예제

설명

실전 팁

4. SSL/TLS 인증서 설정과 HTTPS 적용

시작하며

개요

코드 예제

설명

실전 팁

5. 로드 밸런싱으로 트래픽 분산하기

시작하며

개요

코드 예제

설명

실전 팁

6. Gzip 압축으로 성능 최적화

시작하며

개요

코드 예제

설명

실전 팁

7. 접근 제어와 보안 헤더 설정

시작하며

개요

코드 예제

설명

실전 팁

8. 캐싱 전략으로 서버 부하 줄이기

시작하며

개요

코드 예제

설명

실전 팁

9. 로그 분석과 모니터링 설정

시작하며

개요

코드 예제

설명

실전 팁

10. 무중단 배포와 버전 관리

시작하며

개요

코드 예제

설명

실전 팁

이 카드뉴스가 포함된 코스

Nginx 완전 정복

댓글 (0)

함께 보면 좋은 카드 뉴스

SSL/TLS와 HTTPS 완벽 설정 가이드

Nginx Location 블록과 Rewrite 규칙 완벽 가이드

Let's Encrypt로 무료 SSL 인증서 설정하기

Docker와 Nginx 통합 완벽 가이드

Nginx 성능 최적화 완벽 가이드

로그 관리 및 모니터링 완벽 가이드