Apache Nginx Tomcat 차이 완벽 정리 - 웹서버 30년 변천사로 이해하기

 

Apache, Nginx, Apache Tomcat의 차이를 한 번에 정리합니다. 셋 다 "서버"라는 이름이 붙지만 Apache와 Nginx는 웹서버, Tomcat은 WAS(서블릿 컨테이너)로 역할이 다릅니다. 이 글은 1995년부터 2026년까지 웹서버 30년 변천사를 따라가며, 세 소프트웨어가 왜·어떤 순서로 등장했고 실무에서 어떻게 조합하는지까지 정리합니다.

 

 

"아파치랑 톰캣은 둘 다 '아파치'니까 같은 거 아니에요?"
"요즘은 다들 Nginx 쓴다던데, Apache는 한물 간 건가요?"
"웹서버랑 WAS가 도대체 뭐가 다른 거죠?"
"신규 프로젝트인데 뭘 깔아야 하나요?"

 

 

서버 인프라를 공부하다 보면 이 질문들을 한 번씩은 마주칩니다. 저도 신입 때 Apache와 Tomcat을 같은 거라 착각했고, 한참 뒤에야 "아, 둘은 애초에 하는 일이 다르구나"를 깨달았습니다. 이 셋의 관계는 단순 비교표만 봐서는 잘 안 들어옵니다. 각각이 어떤 시대에, 어떤 문제를 풀려고 태어났는지 순서대로 따라가야 비로소 그림이 그려집니다.

그래서 이 글은 "A는 이렇고 B는 저렇다" 식 나열 대신, 1995년부터 2026년 현재까지의 웹서버 변천사를 시간 순으로 풀어갑니다. 백엔드 신입, 인프라를 막 시작한 분, 면접 앞두고 개념을 정리하려는 분께 도움이 될 겁니다. 끝에 용어집도 붙여뒀으니 중간에 막히는 단어가 있으면 거기서 찾아보셔도 됩니다.

📋 목차

1. 비교 전에 - 웹서버와 WAS는 애초에 다른 물건입니다
2. 1995년, Apache의 등장 - 웹의 기초를 닦다
3. 20년 천하 - Apache는 왜 그렇게 오래 1위였나
4. 1999년, C10K라는 벽 - 접속 1만 개의 악몽
5. 2004년, Nginx - 발상을 뒤집은 신예
6. 구조의 차이 - 프로세스 군단 vs 이벤트 루프
7. 동적 콘텐츠의 시대 - 웹서버만으로는 안 되는 일
8. 1999년, Tomcat - 이름은 Apache지만 웹서버가 아니다
9. 웹서버 · 서블릿 컨테이너 · WAS 정리
10. 리버스 프록시 구조의 정착 - 셋을 조합하는 법
11. Spring Boot와 내장 Tomcat - 또 한 번의 변화
12. 2026년 현재 판도 - 누가 어디서 쓰이고 있나
13. 그래서 무엇을 써야 하나
14. 자주 묻는 질문 (FAQ)
15. 용어집

1. 비교 전에 - 웹서버와 WAS는 애초에 다른 물건입니다

변천사로 들어가기 전에 한 가지만 못 박고 가겠습니다. 이 글에 나오는 세 소프트웨어는 크게 두 종류로 갈립니다.

웹서버(Web Server)는 브라우저가 보낸 HTTP 요청을 받아 그에 맞는 응답을 돌려주는 소프트웨어입니다. 누가 https://example.com/index.html을 입력하면, 서버에 저장된 그 파일을 찾아 그대로 내려보냅니다. 이렇게 미리 저장된 파일을 손대지 않고 돌려주는 걸 정적(Static) 콘텐츠 처리라고 합니다.

반면 로그인 검증, DB 조회, 장바구니 계산처럼 요청할 때마다 결과가 달라지는 작업이 있습니다. 이건 동적(Dynamic) 콘텐츠 처리이고, 이런 코드를 실행하는 별도 소프트웨어를 보통 WAS(Web Application Server)라고 부릅니다.

 

 

📌 이 글의 핵심 한 줄

Apache와 Nginx는 웹서버, Apache Tomcat은 WAS(정확히는 서블릿 컨테이너)입니다.

이름이 비슷해서 헷갈릴 뿐, 역할이 다른 층에 있습니다.

이 구분만 잡고 가면 나머지는 자연스럽게 풀립니다.

 

2. 1995년, Apache의 등장 - 웹의 기초를 닦다

이야기는 1995년에 시작됩니다. 당시 웹은 막 대중화되던 참이었고, 사람들이 가장 많이 쓰던 웹서버는 미국 일리노이대(NCSA)에서 만든 NCSA HTTPd였습니다. 그런데 이 소프트웨어의 핵심 개발자가 학교를 떠나면서 관리가 흐지부지됩니다. 남은 사용자들이 각자 패치를 만들어 돌려쓰던 상황이었죠.

그 패치들을 모으고 다듬어 하나의 서버로 정리한 것이 Apache HTTP Server의 출발점입니다. 초기 개발은 로버트 맥쿨(Robert McCool) 등이 주도했고, 1999년에는 Apache Software Foundation(ASF)이라는 비영리 재단이 세워져 프로젝트를 이어받습니다.

 

 

💡 이름의 유래에 관한 이야기

"여기저기서 모은 패치(a patchy server)"라서 Apache라는 농담 같은 어원이 널리 퍼져 있습니다.

다만 재단 측은 미국 원주민 부족 '아파치'의 끈질긴 생명력에서 따왔다는 설명을 내놓은 적도 있어,

패치 어원설은 그럴듯한 속설 정도로 받아들이는 게 안전합니다.

 

 

중요한 건 이름이 아니라 영향력입니다. Apache는 등장 이후 빠르게 표준이 됐고, 2000년대 중반에는 전 세계 웹서버 시장의 70% 이상을 차지한 적도 있습니다. "Apache"라는 단어가 그냥 "웹서버"의 대명사처럼 쓰이던 시절이었습니다. 나중에 같은 재단이 만든 Tomcat과 이름이 겹쳐 혼란이 생기는 것도 이 때문입니다.

3. 20년 천하 - Apache는 왜 그렇게 오래 1위였나

Apache의 작동 방식부터 봐야 그다음 이야기가 이해됩니다. Apache는 MPM(Multi-Processing Module)이라는 구조로 요청을 처리하는데, 기본 발상은 단순합니다. 요청이 하나 들어오면 그걸 맡을 프로세스나 스레드를 하나 붙인다는 거죠.

식당으로 치면 손님 한 명마다 전담 직원 한 명을 붙이는 방식입니다. 손님 입장에선 편하고, 운영자 입장에선 직관적입니다. MPM에는 세 가지 방식이 있습니다.

- Prefork: 요청마다 독립된 프로세스를 띄움. 가장 안정적이지만 메모리를 많이 먹습니다.
- Worker: 프로세스 안에 여러 스레드를 둠. Prefork보다 가볍습니다.
- Event: Apache 2.4에서 들어온 방식. 연결 유지(Keep-Alive)를 별도로 처리해 효율을 끌어올렸습니다. 뒤에 나올 Nginx를 의식한 개선이죠.

Apache가 20년 넘게 버틴 데는 두 가지 무기가 컸습니다. 하나는 .htaccess입니다. 폴더마다 설정 파일을 따로 둘 수 있어서, 공유 호스팅에서 사용자가 서버 전체를 못 건드려도 자기 폴더 안의 리다이렉트나 접근 제한 정도는 알아서 손볼 수 있었습니다. 다른 하나는 모듈 시스템입니다. mod_rewrite, mod_ssl, mod_php 같은 모듈을 붙였다 뗐다 하며 기능을 확장할 수 있었고, 특히 mod_php로 PHP를 Apache 프로세스 안에서 바로 실행할 수 있다는 점이 PHP·WordPress 생태계와 찰떡이었습니다.

한동안은 이 구조가 충분했습니다. 문제는 웹 트래픽이 Apache가 설계되던 시절과는 비교가 안 되게 폭증하기 시작했다는 데 있었습니다.

4. 1999년, C10K라는 벽 - 접속 1만 개의 악몽

1999년, 댄 케겔(Dan Kegel)이라는 엔지니어가 한 가지 문제를 정리해 이름을 붙입니다. C10K 문제, 즉 "서버 한 대가 동시에 1만 개의 연결(connection)을 감당할 수 있는가"라는 물음이었습니다.

앞서 본 Apache 방식으로 돌아가 봅시다. 손님 한 명마다 직원 한 명. 그럼 손님이 1만 명 동시에 몰리면? 직원 1만 명을 동시에 세워야 합니다. 그런데 프로세스나 스레드는 만드는 비용이 싸지 않고, 하나하나가 메모리를 적잖이 차지합니다. 연결 수가 늘수록 메모리 사용량이 가파르게 치솟고, 어느 순간 서버가 주저앉습니다.

 

 

📌 왜 하필 이 시점이었나

1990년대 말부터 인터넷 사용자가 기하급수로 늘면서, "접속자가 많아도 안 죽는 서버"가 절실해졌습니다.

C10K는 단순한 기술 트리비아가 아니라, 프로세스·스레드 기반 서버의 구조적 한계를 정면으로 드러낸 화두였습니다.

이 문제의식이 다음 세대 서버들을 끌어냅니다.

 

5. 2004년, Nginx - 발상을 뒤집은 신예

C10K에 정면으로 답한 사람이 러시아 개발자 이고르 시소예프(Igor Sysoev)입니다. 그는 2002년경부터 Nginx(엔진엑스로 읽습니다) 개발에 착수했고, 2004년에 공개했습니다. 목표는 명확했습니다. 동시 연결 1만 개를 적은 자원으로 처리한다.

Nginx가 택한 방법은 발상 자체가 달랐습니다. 요청마다 프로세스를 붙이는 대신, 소수의 워커 프로세스(Worker Process)가 수천, 수만 개의 연결을 돌아가며 처리하는 이벤트 기반(Event-driven) 비동기(Asynchronous) 구조였습니다.

다시 식당 비유로. Nginx 식당은 손님이 1만 명 와도 직원이 8명뿐입니다. 대신 각 직원이 한 테이블 주문을 받고, 주방에 넘긴 다음 곧장 다음 테이블로 가고, 음식이 나오면 그때 서빙하는 식으로 여러 테이블을 쉴 새 없이 순환합니다. 한 손님을 붙들고 끝까지 기다리지 않으니, 적은 인원으로 훨씬 많은 손님을 감당합니다. 이 구조 덕분에 Nginx는 메모리 사용량이 낮게 유지되고, 정적 파일을 내려주는 속도가 특히 빠릅니다.

Nginx의 또 다른 강점은 리버스 프록시(Reverse Proxy)입니다. 클라이언트 요청을 받아 뒤에 있는 다른 서버(Tomcat, Node.js 등)로 넘겨주는 역할인데, 이 과정에서 로드 밸런싱, SSL 터미네이션, 캐싱을 같이 처리할 수 있습니다. 설정 문법도 블록 형태라 Apache의 태그 방식보다 읽기 편하다는 평이 많습니다. 이 리버스 프록시 능력이 뒤에 나올 "조합 구조"의 핵심이 됩니다.

물론 약점도 있습니다. .htaccess 같은 폴더별 설정을 지원하지 않아 설정을 바꾸면 전체 설정 파일을 고치고 리로드해야 하고, PHP·Python 같은 동적 언어를 직접 실행하지 못해 PHP-FPM 같은 외부 프로세스와 연동해야 합니다.

 

 

💡 회사가 된 오픈소스
Nginx는 2011년 NGINX, Inc.라는 회사로 상용화 길을 열었고,

2019년 네트워크 장비 기업 F5 Networks가 약 6억 7천만 달러에 인수했습니다.

무료 오픈소스(BSD 라이선스)와 유료 상용판(NGINX Plus)이 함께 굴러가는 구조입니다.

 

6. 구조의 차이 - 프로세스 군단 vs 이벤트 루프

여기까지 오면 Apache와 Nginx의 차이가 표 한 장으로 정리됩니다. 성능 우열의 문제라기보다 설계 철학이 다른 두 시대의 산물이라고 보는 게 정확합니다.

반응형

항목	🏛️ Apache	⚡ Nginx
처리 모델	프로세스/스레드 기반	이벤트 기반 비동기
동시 접속 처리	접속당 프로세스/스레드 할당	워커가 다수 연결을 순환 처리
메모리 효율	접속 늘수록 급증	대체로 일정하게 유지
정적 파일 속도	우수	매우 우수
PHP 직접 실행	mod_php로 가능	PHP-FPM 등 외부 연동 필요
.htaccess	지원	미지원 (전체 설정 수정)
설정 문법	태그 스타일 (httpd.conf)	블록 스타일 (nginx.conf)

참고로 설정 파일이 어떻게 생겼는지 잠깐 보면 분위기가 와닿습니다.

Apache (httpd.conf)

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/html
    <Directory /var/www/html>
        AllowOverride All
    </Directory>
</VirtualHost>

Nginx (nginx.conf)

server {
    listen 80;
    server_name example.com;
    root /var/www/html;

    location / {
        try_files $uri $uri/ =404;
    }
}

7. 동적 콘텐츠의 시대 - 웹서버만으로는 안 되는 일

지금까지는 "파일을 빨리, 많이 내려주는 경쟁"이었습니다. 그런데 웹이 발전하면서 요구가 달라졌습니다. 게시판, 로그인, 쇼핑몰처럼 요청마다 다른 결과를 만들어내야 하는 서비스가 늘어난 겁니다.

정적 파일만 내려주는 웹서버로는 이걸 감당할 수 없습니다. 사용자가 누구인지, 로그인했는지, 장바구니에 뭘 담았는지에 따라 화면이 달라져야 하니까요. 그래서 코드를 실제로 실행하는 계층이 필요해졌고, 여기서 언어별로 갈래가 생깁니다. PHP는 Apache의 mod_php로, 자바는 별도의 실행 환경으로 가는 식이었죠.

그리고 그 "자바 쪽 실행 환경"의 대표 주자가 바로 다음에 나올 Apache Tomcat입니다.

8. 1999년, Tomcat - 이름은 Apache지만 웹서버가 아니다

시계를 다시 1999년으로 돌립니다. 자바 진영에서는 서버에서 자바 코드를 돌리는 표준 기술로 서블릿(Servlet)과 JSP가 등장했습니다. 이 표준을 실제로 구현한 소프트웨어가 필요했고, 썬 마이크로시스템즈(Sun Microsystems)가 만들던 코드와 오픈소스 진영의 코드가 합쳐지면서 Tomcat이 태어났습니다. 1999년 10월 썬이 코드를 ASF에 기증했고, 그렇게 Apache 재단의 프로젝트가 됐습니다.

 

 

📌 가장 많이 하는 오해
Tomcat은 이름에 "Apache"가 들어가고 같은 재단이 만들었지만,

Apache HTTP Server와는 완전히 다른 소프트웨어입니다.

Apache HTTP Server는 웹서버이고,

Tomcat은 자바 서블릿을 실행하는 서블릿 컨테이너(=WAS에 가까운 물건)입니다.

둘을 같은 거라 착각하면 구조가 계속 안 풀립니다.

 

 

Tomcat 내부는 몇 개의 부품으로 나뉩니다. 서블릿을 실제로 굴리는 Catalina, HTTP 요청을 받아들이는 커넥터 Coyote, JSP를 자바 코드로 바꿔주는 Jasper가 핵심입니다. 하는 일을 정리하면 이렇습니다.

- 자바 서블릿 실행
- JSP를 자바 코드로 컴파일한 뒤 실행
- HTTP 요청을 받아 자바 메서드 호출
- DB 커넥션 풀과 세션 관리

주의할 점은 Tomcat이 정적 파일을 내려주는 속도는 Nginx나 Apache보다 한참 떨어진다는 겁니다. 이미지나 CSS, JS까지 전부 Tomcat에 맡기는 건 자원 낭비예요. 그래서 실무에서는 앞에 Nginx나 Apache를 세우고 정적 파일은 그쪽이 맡는 구조를 씁니다. 이 이야기는 10번 섹션에서 이어집니다.

덧붙이면 Tomcat은 버전에 따라 기준 규격이 바뀌었습니다. 9 버전까지는 Java EE 기반이었고, 10 버전부터는 후속 규격인 Jakarta EE를 따릅니다. 2026년 현재 안정 버전은 11.x 대입니다.

9. 웹서버 · 서블릿 컨테이너 · WAS 정리

여기서 용어를 한 번 정리하고 가겠습니다. 자주 뒤섞여 쓰이는데 엄밀히는 층이 다릅니다.

- 웹서버: 정적 파일을 HTTP로 내려주는 소프트웨어 (Apache, Nginx)
- 서블릿 컨테이너(웹 컨테이너): 자바 서블릿·JSP를 실행하는 런타임 (Tomcat, Jetty)
- 애플리케이션 서버(WAS): 서블릿 컨테이너 기능에 더해 EJB, 트랜잭션 관리 등 엔터프라이즈 기능까지 갖춘 것 (WebLogic, WebSphere, WildFly)

엄밀히 따지면 Tomcat은 완전한 WAS라기보다 "서블릿 컨테이너 + 가벼운 웹서버"에 가깝습니다. 다만 실무에서는 Java 백엔드를 굴리는 역할이라는 의미로 그냥 WAS라고 묶어 부르는 경우가 많습니다. 자바 진영의 주요 선택지를 비교하면 다음과 같습니다.

제품	진영	라이선스	주로 쓰이는 곳
Apache Tomcat	Apache 재단	무료	일반 웹 개발, Spring Boot
JBoss / WildFly	Red Hat	무료	완전한 Java EE 엔터프라이즈
WebLogic	Oracle	유료	대기업·금융권
WebSphere	IBM	유료	IBM 인프라 기반 대기업
Jetty	Eclipse 재단	무료	경량·임베디드 환경

10. 리버스 프록시 구조의 정착 - 셋을 조합하는 법

변천사의 결론부에 해당하는 부분입니다. 웹서버 하나로 다 끝내던 시절을 지나, 지금은 앞단에 웹서버(주로 Nginx), 뒷단에 WAS(주로 Tomcat)를 두고 역할을 나누는 게 정석이 됐습니다. Nginx의 리버스 프록시 능력이 이 구조를 가능하게 만든 핵심입니다.

 

 

💡 가장 흔한 구조: Nginx + Tomcat
클라이언트 → Nginx(80/443) → Tomcat(8080)

Nginx가 정적 파일(CSS, JS, 이미지)을 직접 처리하고, /api/* 같은 자바 요청만 뒤의 Tomcat으로 넘깁니다. HTTPS 복호화(SSL 터미네이션)도 Nginx가 맡아 Tomcat 부담을 덜고, 트래픽이 늘면 Tomcat을 여러 대 띄워 로드 밸런싱합니다.

 

 

이 외에도 상황별로 조합이 갈립니다.

- Apache + Tomcat: 오래된 자바 엔터프라이즈 시스템에서 자주 보이는 구조입니다. mod_jk나 AJP 프로토콜로 둘을 잇습니다. (AJP는 Ghostcat 취약점 이슈가 있어 요즘은 기본 비활성화를 권합니다.)
- Nginx 단독 + 백엔드: 백엔드가 Node.js·Django·Go처럼 자체 실행이 되는 경우, Nginx만 앞에 두고 바로 연동합니다.
- Apache 단독 + mod_php: WordPress 같은 PHP 사이트에서 여전히 흔합니다. .htaccess 기반 퍼머링크 설정이 WordPress와 잘 맞물립니다.

11. Spring Boot와 내장 Tomcat - 또 한 번의 변화

최근 자바 개발에서 한 번 더 흐름이 바뀐 지점이 있습니다. 요즘 많이 쓰는 Spring Boot는 Tomcat을 안에 품고(Embedded Tomcat) 나옵니다. 예전처럼 Tomcat을 따로 설치하고 그 위에 애플리케이션을 올리는 게 아니라, java -jar app.jar 한 줄이면 Tomcat이 내장된 채로 애플리케이션이 곧장 뜹니다.

그렇다고 Nginx가 필요 없어진 건 아닙니다. 내장 Tomcat이 자바 로직을 돌리더라도, 정적 파일 처리와 SSL, 로드 밸런싱은 여전히 앞단의 Nginx가 맡는 게 보통입니다. 결국 10번 섹션의 구조가 그대로 이어집니다. 설치 방식만 가벼워졌을 뿐, "앞에 웹서버, 뒤에 WAS"라는 큰 그림은 유지되는 셈이죠.

12. 2026년 현재 판도 - 누가 어디서 쓰이고 있나

그래서 지금은 누가 이기고 있을까요. 시장 점유율은 집계 기관과 측정 방식에 따라 숫자가 제법 달라지지만, 큰 그림은 일관됩니다.

 

 

📌 2026년 웹서버 점유율 (W3Techs 등 집계 기준)

Nginx가 1위로 대략 33~39% 안팎, Apache가 그 뒤로 약 24% 수준입니다.

한때 70%를 넘던 Apache의 점유율이 꾸준히 내려오고 Nginx가 그 자리를 메운 흐름이 뚜렷합니다.

그 뒤로 LiteSpeed, Cloudflare의 자체 서버 등이 점유율을 나눠 갖고 있습니다.

(수치는 집계 방식에 따라 편차가 있으니 추세로 봐주세요.)

 

 

최근 몇 년의 변화도 짚어두면 좋습니다. Nginx는 HTTP/3(QUIC)를 비교적 빨리 지원했고, 쿠버네티스 환경에서 트래픽 입구 역할을 하는 인그레스(Ingress) 컨트롤러로도 ingress-nginx가 사실상 표준처럼 쓰입니다. 클라우드 네이티브·마이크로서비스 쪽으로 무게추가 옮겨갈수록 Nginx 계열이 유리한 지형인 건 맞습니다.

그렇다고 Apache가 죽은 기술은 아닙니다. 공유 호스팅, cPanel 기반 환경, 기존 WordPress 사이트에서는 .htaccess와 mod_php의 편의성 때문에 여전히 굳건합니다. Tomcat은 자바 서블릿 컨테이너 시장에서 압도적 1위 자리를 그대로 지키고 있고요. 세 소프트웨어가 같은 자리를 두고 싸우는 게 아니라, 각자의 영역에서 살아 있다고 보는 게 맞습니다.

13. 그래서 무엇을 써야 하나

정리하면 이렇습니다. 무엇이 더 좋은 서버냐는 질문 자체가 살짝 어긋난 질문입니다. 셋은 경쟁자라기보다 역할이 다른 동료에 가깝거든요.

구분	🏛️ Apache	⚡ Nginx	☕ Tomcat
분류	웹서버	웹서버	서블릿 컨테이너(WAS)
등장	1995년	2004년	1999년
작성 언어	C	C	Java
정적 처리	우수	최고	부적합
동적 처리	mod_php 등	외부 연동 필요	Java 전문
리버스 프록시	가능	탁월	해당 없음
주요 사용처	PHP·WordPress	정적 서빙·리버스 프록시	Java 웹앱 실행

현실적인 선택 기준만 추리면 — PHP·WordPress를 굴린다면 Apache가 편하고, 정적 파일이 많거나 트래픽이 크거나 앞단 프록시가 필요하면 Nginx가 답입니다. 자바 백엔드(Spring 등)를 돌려야 한다면 Tomcat은 사실상 기본값이고, 그 앞에 Nginx를 세우는 조합이 가장 무난합니다.

마무리

웹서버의 30년은 결국 "트래픽이 늘어나는 속도를 어떻게 따라잡을 것인가"의 역사였습니다. Apache가 웹의 토대를 깔았고, C10K라는 벽 앞에서 Nginx가 발상을 뒤집었으며, 자바 진영은 Tomcat이라는 별도 계층을 만들어 동적 처리를 떠안았습니다. 지금의 "Nginx 앞, WAS 뒤" 구조도 그 흐름의 한 지점일 뿐, 언젠가 또 다른 무언가가 이 자리를 바꿀지도 모릅니다.

그러니 어느 하나를 외우기보다, 각각이 어떤 문제를 풀려고 나왔는지를 기억해두는 편이 오래갑니다. 새 기술이 나와도 "이건 무슨 문제를 풀려는 거지?"라는 같은 질문으로 자리를 잡아줄 수 있으니까요.

자주 묻는 질문 (FAQ)

Apache와 Tomcat의 차이는 무엇인가요?

Apache(HTTP Server)는 정적 파일을 내려주는 웹서버이고, Apache Tomcat은 자바 서블릿·JSP를 실행하는 서블릿 컨테이너입니다. 이름에 둘 다 "Apache"가 들어가고 같은 재단이 만들었지만 처리하는 층이 다릅니다. Apache는 파일을 전달하고, Tomcat은 자바 코드를 실행한다고 기억하면 됩니다.

Nginx와 Apache 중 어느 것이 더 빠른가요?

정적 파일 처리와 동시 접속이 많은 환경에서는 대체로 Nginx가 더 빠르고 메모리 효율이 좋습니다. 이벤트 기반 비동기 구조 덕분입니다. 다만 PHP를 mod_php로 직접 실행하거나 .htaccess 기반 설정이 필요한 환경에서는 Apache가 더 편합니다. 속도 하나로 단정하기보다 용도에 따라 갈린다고 보는 게 정확합니다.

Tomcat은 웹서버인가요, WAS인가요?

엄밀히는 "서블릿 컨테이너 + 가벼운 웹서버"에 가깝습니다. WebLogic·WebSphere처럼 EJB나 트랜잭션 관리까지 갖춘 완전한 WAS는 아니지만, 자바 웹 애플리케이션을 실행하는 역할이라 실무에서는 보통 WAS로 묶어 부릅니다.

Nginx와 Tomcat을 함께 쓰는 이유는 무엇인가요?

Tomcat은 정적 파일 처리 속도가 느립니다. 그래서 앞단에 Nginx를 세워 이미지·CSS·JS 같은 정적 파일은 Nginx가 직접 처리하고, 자바 로직이 필요한 요청만 Tomcat으로 넘깁니다. SSL 복호화와 로드 밸런싱도 Nginx가 맡아 Tomcat 부담을 덜어주죠. 자바 백엔드에서 가장 보편적인 구조입니다.

Spring Boot는 Tomcat이 내장돼 있는데 Nginx가 필요한가요?

내장 Tomcat이 자바 로직 실행을 맡더라도, 정적 파일 처리·SSL·로드 밸런싱은 여전히 앞단의 Nginx가 담당하는 게 보통입니다. 그래서 Spring Boot를 써도 운영 환경에서는 앞에 Nginx를 두는 구조를 흔히 씁니다.

2026년 기준 웹서버 점유율 1위는 무엇인가요?

집계 기관과 측정 방식에 따라 숫자는 달라지지만, Nginx가 대략 33~39%로 1위이고 Apache가 약 24%로 그 뒤를 잇습니다. 한때 70%를 넘던 Apache가 내려오고 Nginx가 그 자리를 채운 흐름이 뚜렷합니다.

📖 용어집

본문에 나온 용어들을 가볍게 정리했습니다.

- 웹서버: HTTP 요청을 받아 HTML·이미지 같은 정적 파일을 돌려주는 소프트웨어. Apache, Nginx가 대표.
- WAS: 비즈니스 로직을 실행하고 DB를 조회해 동적 결과를 만들어내는 서버. Tomcat, WebLogic 등.
- C10K 문제: 동시 연결 1만 개를 어떻게 처리하느냐는 화두. 1999년 Dan Kegel이 정리. 프로세스 기반 서버의 한계를 드러냄.
- 정적 vs 동적 콘텐츠: 정적은 저장된 파일을 그대로(요청마다 동일), 동적은 코드를 실행해 매번 다른 결과를 생성.
- 리버스 프록시: 클라이언트와 백엔드 사이에서 요청을 중계하는 서버. 보안·로드 밸런싱·캐싱을 함께 담당.
- 로드 밸런싱: 여러 서버에 트래픽을 나눠 한 곳에 과부하가 걸리지 않게 하는 기술.
- 이벤트 기반 비동기: 한 요청이 끝나길 기다리지 않고 여러 요청을 동시에 굴리는 방식. 소수 스레드로 대량 연결 처리. Node.js도 이 계열.
- SSL 터미네이션: HTTPS 암호화 트래픽을 복호화하는 지점. Nginx가 맡으면 뒤의 Tomcat은 HTTP로 가볍게 통신.
- 자바 서블릿: 자바로 작성된 서버 측 프로그램의 기본 단위. Spring MVC·JSP 밑바닥에 깔려 있음. Tomcat이 이를 실행.
- MPM: Apache의 요청 처리 방식 모듈. Prefork·Worker·Event 세 가지.
- .htaccess: Apache의 폴더별 설정 파일. 서버 전체 권한 없이 해당 폴더 설정만 손볼 수 있음.
- PHP-FPM: Nginx가 PHP를 직접 못 돌리기에, PHP 실행을 대신 맡아주는 프로세스 관리자.
- AJP: Apache와 Tomcat을 잇는 전용 프로토콜(8009 포트). Ghostcat 취약점 때문에 요즘은 비활성화 권장.
- Keep-Alive: HTTP 연결을 매 요청마다 끊지 않고 잠시 유지하는 기술. 스레드 기반 Apache에선 부담이 될 수 있으나 Nginx의 이벤트 방식은 효율적으로 처리.