웹서버 & WAS, 서블릿, 멀티 쓰레드, CSR/SSR, 자바 벡엔드 역사 정리
1. 웹 서버(Web Server)와 웹 애플리케이션 서버(WAS)
1-1. 모든 것이 HTTP 기반
브라우저 ↔ 서버 간의 모든 통신은 HTTP 프로토콜을 기반으로 한다.
정적/동적 리소스 제공 방식은 서버 종류에 따라 다르다.
1-2. 웹 서버(Web Server)
정적 리소스를 제공하는 서버.
(HTML, CSS, JS, 이미지, 영상 파일 등)
- 요청이 오면 파일 그대로 전달
- 실행 로직 없음 → 가볍고 빠르고 잘 안 죽음
- 예: NGINX, Apache
1-3. 웹 애플리케이션 서버(WAS)
정적 리소스 제공 + 애플리케이션 로직 실행이 가능한 서버.
- 동적으로 HTML 생성 (JSP, Thymeleaf)
- REST API(JSON) 응답
- 서블릿, JSP, 스프링 MVC 처리
- 예: Tomcat
1-4. 웹 서버 vs WAS (핵심 정리)
| 구분 | Web Server | WAS |
|---|---|---|
| 역할 | 정적 리소스 제공 | 애플리케이션 로직 실행 |
| 부하 | 가벼움 | 상대적으로 무거움 |
| 예시 | NGINX, Apache | Tomcat |
자바 기반에서 서블릿 컨테이너 기능을 제공하면 WAS로 분류됨.
1-5. 웹 시스템 구성 방식
✔ WAS + DB
- 단독 구성 가능
- 하지만 정적 리소스까지 WAS가 떠맡으면 과부하 발생
- WAS 장애 시 에러 페이지도 제공할 수 없음
✔ Web Server + WAS + DB (권장)
-
정적 리소스: Web Server
-
동적 로직: WAS
-
장점
- 효율적인 리소스 분리
- Web Server는 안정성이 높음
- 장애 시 Web Server가 에러 페이지 응답 가능
-
REST API만 사용하는 시스템은 Web Server 생략해도 됨
2. 서블릿(Servlet)
2-1. HTML Form 데이터 전송
- 브라우저 → 서버로 데이터 전달 시 POST 요청 사용
- 이를 처리하는 것이 서블릿
(예: /hello 주소 호출 → HelloServlet 실행)
2-2. 서블릿의 역할
-
HttpServletRequest
→ 요청 데이터 조회 (request.getParameter()등) -
HttpServletResponse
→ 응답 메시지 생성 (HTML, JSON 등)
HTTP 스펙을 개발자가 직접 다룰 수 있게 설계된 API라고 보면 됨.
2-3. 서블릿 요청/응답 흐름
- 클라이언트가 HTTP 요청
- WAS가 Request/Response 객체 생성
- 해당 URL 매핑된 서블릿 호출
- 개발자가 request/response에 데이터를 읽고 쓰기
- WAS가 Response 내용을 기반으로 최종 HTTP 응답 생성
→ 개발자는 HTTP 처리 복잡성을 크게 줄일 수 있음.
2-4. 서블릿 컨테이너(=WAS의 핵심 기능)
WAS 내부에서 서블릿을 관리하는 기능을 말함.
- 서블릿 객체 생성·초기화·종료 관리
- 싱글톤으로 관리 (한 번만 만들고 재사용)
- 멀티쓰레드 환경 제공 → 동시 요청 처리
- JSP는 서블릿으로 변환되어 실행됨
주의:
싱글톤 객체이므로, 공유 변수 사용 시 동시성 문제에 유의해야 한다.
3. 멀티쓰레드 & 쓰레드 풀(Thread Pool)
3-1. 쓰레드(Thread)
- 코드 흐름을 수행하는 실행 단위
- 동시 처리가 필요하면 여러 쓰레드가 사용됨
3-2. 요청마다 쓰레드 생성 방식의 문제
- 쓰레드 생성 비용이 매우 크다
- 동시 요청 폭주 → 쓰레드 무제한 생성 → CPU/메모리 초과 → 서버 다운
3-3. WAS의 해결책: 쓰레드 풀(Thread Pool)
WAS는 내부적으로 쓰레드 풀을 운영한다.
특징
-
미리 쓰레드를 만들어 두고 재사용
-
요청 → 쓰레드 대여
-
처리 완료 → 쓰레드 반납
-
최대 쓰레드 개수 존재
- Tomcat 기본 200개
장점
- 많은 요청도 안정적으로 처리 가능
- 개발자는 멀티쓰레드 코드를 직접 구현할 필요가 없음
→ 싱글 쓰레드 코딩하듯 개발해도 됨
3-4. 실무 팁
- 쓰레드 수가 너무 적으면 → CPU는 남는데 처리량 부족
- 너무 많으면 → 서버가 오히려 장애
- 적정 숫자는 서비스마다 다르므로 성능 테스트 필수
테스트 도구
- Apache ab
- JMeter
- nGrinder
4. HTML, HTTP API, CSR, SSR 정리
4-1. 정적 리소스
- 변경되지 않는 HTML, CSS, JS 파일
4-2. HTML 페이지
- JSP/Thymeleaf처럼 서버가 HTML을 만들어 전달하는 방식
4-3. HTTP API
- HTML이 아닌 데이터(JSON) 전달
- 앱, 웹, 서버 간 통신에 널리 사용
4-4. SSR (Server-Side Rendering)
서버가 HTML 완성본을 만들어 클라이언트에 전송
- 정적인 화면에 적합
- JSP, 타임리프
- 백엔드 중심 구조
4-5. CSR (Client-Side Rendering)
HTML을 클라이언트(브라우저)에서 JS로 동적으로 생성
- React, Vue.js
- Gmail, Google Maps처럼 인터랙션이 많은 UI에 적합
SSR + CSR 혼합 방식도 가능 (Next.js 등)
5. 자바 백엔드 기술 역사
5-1. 과거
Servlet
- 동적 화면 생성 어려움 (HTML 출력 코드를 직접 작성해야 함)
JSP
- HTML 렌더링은 편하지만
- 로직 + 렌더링이 뒤섞여 유지보수 어려움
→ MVC 패턴 도입
→ 화면과 비즈니스 로직 분리
5-2. 현재: Spring MVC & Spring Boot
Spring MVC
- 애노테이션 기반 (
@Controller,@RequestMapping) - MVC 아키텍처를 표준으로 자리 잡음
Spring Boot
- 내장 WAS 제공 → Jar 파일만으로 실행 가능
- 복잡한 설정 자동화
- 배포 간소화
5-3. 최신 기술: Spring WebFlux
WebFlux (Reactive)
- 비동기 논블로킹 처리
- 적은 쓰레드로 높은 성능
- 함수형 프로그래밍 스타일
→ 고성능 & 실시간 스트리밍 시스템에서 유용
→ 하지만 실무 채택률은 아직 낮음
5-4. 뷰 템플릿의 역사
| 기술 | 특징 |
|---|---|
| JSP | 느리고 기능 제한 |
| Freemarker / Velocity | 빠르고 유연 |
| Thymeleaf | HTML 구조 그대로 유지(내추럴 템플릿) + 스프링 통합 |
🔎 전체 흐름 요약
- Web Server는 정적 파일 제공, WAS는 로직 처리
- 서블릿은 HTTP 요청을 처리하는 핵심 기반 기술
- WAS는 멀티쓰레드 + 쓰레드풀로 동시 요청 처리
- Rendering 방식은 SSR, CSR로 나뉨
- 자바 백엔드는 Servlet → JSP → MVC → Spring MVC → Spring Boot → WebFlux로 발전 중
출처
