Contents
see List개요
웹서버 선택은 인프라 설계의 기본이면서도 중요한 결정입니다. Nginx는 오랫동안 고성능 웹서버의 대명사였지만, 최근 Caddy가 자동 HTTPS, 간결한 설정, 모던한 기본값으로 빠르게 점유율을 높이고 있습니다. 특히 Let's Encrypt 인증서 자동 발급/갱신이 기본 내장된 점은 많은 개발자에게 매력적입니다. 이 글에서는 Nginx와 Caddy를 성능, 설정 편의성, 기능 측면에서 비교하고, 각각의 실전 설정 예제를 제공합니다.
핵심 개념
Nginx: Igor Sysoev가 개발한 이벤트 기반 웹서버로, 리버스 프록시, 로드 밸런서, HTTP 캐시로 널리 사용됩니다. C10K 문제를 해결하기 위해 설계되었으며, 낮은 메모리 사용량과 높은 동시 접속 처리 능력이 특징입니다.
Caddy: Go 언어로 작성된 모던 웹서버입니다. HTTPS가 기본이며, ACME 프로토콜을 통한 인증서 자동 관리가 핵심 차별점입니다. Caddyfile이라는 간결한 설정 형식을 사용하며, JSON API로 동적 설정 변경도 가능합니다.
자동 HTTPS: Caddy는 도메인을 설정하면 자동으로 Let's Encrypt에서 인증서를 발급받고 갱신합니다. Nginx에서는 Certbot이나 acme.sh를 별도로 설치하고 cron을 설정해야 합니다.
성능 차이: 정적 파일 서빙에서 Nginx가 약간 우위이지만, 리버스 프록시 용도로는 실질적인 차이가 미미합니다. 대부분의 웹 애플리케이션에서 병목은 웹서버가 아닌 백엔드 애플리케이션입니다.
실전 예제: 동일 구성 비교
Next.js 앱의 리버스 프록시 + HTTPS 설정을 비교합니다.
Caddy 설정 (Caddyfile):
# /etc/caddy/Caddyfile
# Caddy 설치
sudo apt install -y caddy # 또는 brew install caddy
# Caddyfile 작성
sudo tee /etc/caddy/Caddyfile <<'EOF'
example.com {
reverse_proxy localhost:3000
# gzip 압축 (자동)
encode gzip
# 보안 헤더
header {
X-Content-Type-Options nosniff
X-Frame-Options DENY
Referrer-Policy strict-origin-when-cross-origin
-Server
}
# 로깅
log {
output file /var/log/caddy/access.log
format json
}
}
# 서브도메인 (API)
api.example.com {
reverse_proxy localhost:8080
# CORS 설정
header Access-Control-Allow-Origin "https://example.com"
header Access-Control-Allow-Methods "GET, POST, PUT, DELETE"
}
EOF
sudo systemctl reload caddy
Nginx 동일 설정:
# Nginx 설치
sudo apt install -y nginx
# Certbot으로 인증서 발급
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d api.example.com
# /etc/nginx/sites-available/example.com
sudo tee /etc/nginx/sites-available/example.com <<'EOF'
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
# 보안 헤더
add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options DENY;
add_header Referrer-Policy strict-origin-when-cross-origin;
server_tokens off;
# gzip 압축
gzip on;
gzip_types text/plain text/css application/json application/javascript;
gzip_min_length 1024;
location / {
proxy_pass http://localhost:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
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;
proxy_cache_bypass $http_upgrade;
}
access_log /var/log/nginx/example.access.log;
error_log /var/log/nginx/example.error.log;
}
server {
listen 443 ssl http2;
server_name api.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
add_header Access-Control-Allow-Origin "https://example.com";
add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE";
location / {
proxy_pass http://localhost:8080;
proxy_http_version 1.1;
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;
}
}
server {
listen 80;
server_name example.com api.example.com;
return 301 https://$host$request_uri;
}
EOF
sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
# 인증서 자동 갱신 확인
sudo certbot renew --dry-run
활용 팁
- 빠른 프로토타이핑: Caddy는 설정이 간결하여 개발 서버나 소규모 프로젝트에 적합합니다. HTTPS 설정을 고민할 필요가 없습니다.
- 고트래픽 프로덕션: Nginx는 오랜 역사와 풍부한 모듈 생태계로 대규모 환경에서 검증되었습니다. OpenResty(Lua 확장)도 강력합니다.
- Caddy의 JSON API: Caddy는 REST API로 설정을 동적 변경할 수 있어, CI/CD 파이프라인이나 서비스 디스커버리와 연동하기 좋습니다.
- Nginx에서 Caddy 전환: 기존 Nginx 설정을 Caddy로 마이그레이션할 때, nginx2caddy 같은 변환 도구를 참고하되 수동 검증은 필수입니다.
- 로드 밸런서: 둘 다 upstream 기반 로드 밸런싱을 지원합니다. Caddy는 active health check가 기본 내장이고, Nginx는 상용 Plus 버전에서 제공됩니다.
마무리
Nginx와 Caddy는 각각의 강점이 뚜렷합니다. 자동 HTTPS와 설정 간결함이 중요하면 Caddy를, 검증된 안정성과 세밀한 제어가 필요하면 Nginx를 선택하세요. 최근에는 Caddy의 성능과 안정성이 크게 향상되어, 신규 프로젝트에서는 Caddy를 우선 검토하고, 특별한 요구사항이 있을 때 Nginx를 사용하는 접근도 합리적입니다.