Nginx vs Apache 선택|.htaccess·PHP·Proxy 30분 테스트
Nginx와 Apache 중 무엇이 더 빠른지 묻기 전에 현재 서버에서 누가 PHP를 처리하고, URL 재작성 규칙을 어디서 관리하며, 앞단에 CDN이나 리버스 프록시가 있는지 확인해야 합니다. 같은 서버에서도 구성에 따라 결과가 달라지므로 제품 이름만으로 교체를 결정하면 장애와 원복 비용만 커질 수 있습니다. 아래 30분 점검은 기존 구성을 보존하면서 선택 근거를 만드는 방법입니다.
1. 5분: 현재 요청 경로 확인
curl -I https://example.com/
ps -ef | grep -E 'nginx|apache2|httpd|php-fpm' | grep -v grep
apachectl -V 2>/dev/null | grep -i mpm
nginx -V 2>&1 | head -n 1
Server 헤더는 숨기거나 프록시가 바꿀 수 있으므로 참고값일 뿐입니다. 실행 프로세스와 호스팅 제어판의 웹 서버·PHP 처리 방식을 함께 확인하세요. Apache는 MPM이 연결과 작업 배분을 담당하며 현대적인 Unix 계열에서는 대체로 event MPM이 기본입니다. Nginx는 master가 설정과 worker를 관리하고 worker가 이벤트 기반으로 요청을 처리합니다.
| 확인 항목 | Apache가 편한 경우 | Nginx가 편한 경우 |
|---|---|---|
| 설정 권한 | 서버 설정 권한 없이 .htaccess 사용 | 서버 블록을 직접 관리 가능 |
| PHP 연결 | 기존 모듈·호스팅 구성을 유지 | PHP-FPM과 명확히 분리 |
| 주요 역할 | 디렉터리별 규칙·모듈 호환 | 정적 파일·리버스 프록시 앞단 |
| 운영 난이도 | 한 계층으로 유지 | 설정·로그·배포 자동화 가능 |

2. 5분: .htaccess 의존성 찾기
find /var/www -name .htaccess -type f -print
grep -R "AllowOverride" /etc/apache2 /etc/httpd 2>/dev/null
Apache의 .htaccess는 메인 설정을 수정할 권한이 없는 환경에서 디렉터리별 규칙을 적용할 수 있다는 장점이 있습니다. 반면 Nginx는 요청 때마다 읽는 .htaccess 방식을 사용하지 않으므로 재작성·접근 제한 규칙을 서버 설정으로 옮겨야 합니다. 워드프레스 고유주소만 보고 단순 변환하지 말고 리디렉션, 보안 헤더, 다운로드 제한과 플러그인 규칙까지 목록화하세요.
3. 10분: 같은 URL을 같은 조건에서 측정
curl -sS -o /dev/null -w 'code=%{http_code} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}\n' https://example.com/
curl -sS -o /dev/null -w 'code=%{http_code} size=%{size_download} total=%{time_total}\n' https://example.com/wp-content/uploads/test.jpg
HTML 한 개와 정적 파일 한 개를 각각 여러 번 측정하고 첫 요청과 재요청을 나눠 기록합니다. CDN 캐시가 적중한 값과 원본 서버 값을 섞지 말고, 같은 시간대·같은 네트워크·같은 캐시 상태를 유지하세요. 평균 하나보다 중앙값과 가장 느린 값을 함께 보면 간헐적인 PHP·DB 지연을 정적 파일 성능으로 오해하는 일을 줄일 수 있습니다.
4. 5분: 설정 검사와 원복 경로 준비
nginx -t
apachectl configtest
curl -I https://example.com/login-test
설정을 적용하기 전에 문법 검사를 통과해야 합니다. 테스트 URL에서는 홈 화면뿐 아니라 로그인, 관리자 화면, 파일 업로드, 리디렉션과 404 응답을 확인하세요. 리버스 프록시를 추가했다면 원래 Host와 클라이언트 IP 전달, HTTPS 판별이 정상인지 로그로 검증해야 합니다. 문제가 생기면 웹 서버와 PHP를 동시에 바꾸지 말고 직전 설정 파일로 한 계층씩 원복합니다.
5. 5분: 최종 선택표 작성
| 상황 | 우선 선택 | 이유 |
|---|---|---|
| 공유 호스팅·.htaccess 필수 | Apache 유지 | 사용자 단위 설정과 기존 호환성 |
| Node·Python 앱 앞단 프록시 | Nginx 검토 | proxy_pass 기반 경로 구성이 단순 |
| Apache 사이트가 이미 안정적 | Apache 유지 후 측정 | 교체 자체가 성능 개선을 보장하지 않음 |
| 정적 파일과 PHP 계층 분리 | Nginx+PHP-FPM 검토 | 역할과 장애 범위를 분리 가능 |
| Nginx 앞단+Apache 백엔드 | 필요할 때만 | 로그·헤더·캐시 계층이 늘어남 |

TIP
웹 서버 교체 전후에는 ‘서버 종류’가 아니라 측정 조건을 기록하세요. URL, 캐시 상태, PHP 버전, 동시 접속 조건과 원복 시간을 같은 표에 남기면 결과를 재현할 수 있습니다. 첫 응답이 느리다면 워드프레스 TTFB 20분 진단, 압축 여부가 다르다면 Gzip·Brotli 적용 확인, 서버 CPU가 치솟는다면 리눅스 CPU 진단 순서를 먼저 확인하세요.
마무리
Nginx는 무조건 빠르고 Apache는 무조건 느리다는 결론은 실무 선택 기준이 될 수 없습니다. .htaccess와 모듈 호환이 중요하면 Apache가 단순하고, 서버 설정을 직접 관리하며 정적 파일·PHP·앱 프록시 역할을 분리하려면 Nginx가 편할 수 있습니다. 현재 경로를 확인하고 같은 조건으로 측정한 뒤, 장애 없이 원복할 수 있는 구성을 선택하세요.



댓글 0
첫 댓글을 남겨보세요.