일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- satisfiles
- tanstackquery
- css
- test
- Redux
- 웹애플리케이션서버
- Gin
- component
- go
- javascript
- java
- React
- storybook
- hook
- frontend
- springboot
- designpatterns
- JPA
- typescript
- golang
- Spring
- backend
- RTK
- ReactHooks
- react-hook-form
- 티스토리챌린지
- 오블완
- JavaSpring
- Chakra
- Today
- Total
bkdragon's log
웹 기술의 발전과정 본문
자바 스프링을 공부하다보면 서블릿, 서블릿 컨테이너, 디스패처 서블릿 등의 용어를 심심치 않게 볼 수 있다. 이런 용어들은 사실 웹 기술의 발전 과정과 관련이 있다. 웹 기술은 시간이 지나면서 많은 발전을 이루어 왔는데 오늘 그 과정을 간단하게 살펴보려고 한다.
초기 웹은 정적 컨텐츠만 보여주면 됐지만 시간이 지남에 따라 동적 컨텐츠의 필요성을 느끼게 되었다. 그래서 처음 나온게 CGI이다.
CGI(Common Gateway Interface)
CGI는 초기 웹 서버와 외부 프로그램 간의 인터페이스로 사용되었다. 웹 서버는 정적인 HTML 파일만 제공할 수 있었기 때문에, 동적인 콘텐츠를 생성하기 위해 CGI가 필요했다. 그러나 CGI는 각 HTTP 요청마다 새로운 프로세스를 생성하여 응답을 처리했기 때문에 성능 저하와 자원 낭비가 발생했다.
서블릿
CGI의 성능 문제를 해결하기 위해 자바 기반의 서블릿이 등장했다. 서블릿은 자바 가상 머신(JVM) 내에서 실행되며, 프로세스 대신 스레드를 사용하여 요청을 처리함으로써 성능을 크게 향상시켰다. 서블릿은 웹 애플리케이션의 핵심 구성 요소로 자리 잡았으며, 자바의 강력한 객체 지향 기능을 활용할 수 있었다.
CGI의 성능 문제를 해결했지만, 서블릿에도 몇 가지 문제점이 존재한다.
중복 코드 문제: 각 서블릿이 개별적으로 요청을 처리하면서, 인증, 로깅, 보안 검사 등과 같은 공통 기능이 여러 서블릿에 중복되어 구현될 수 있다. 이는 유지보수의 어려움과 코드의 비효율성을 초래한다.
요청 라우팅의 복잡성: 각 서블릿이 직접 요청을 처리해야 하므로, 요청 라우팅 로직이 복잡해질 수 있다. 이는 코드의 가독성을 떨어뜨리고, 새로운 요청 경로를 추가하거나 변경할 때 많은 수정을 요구할 수 있다.
유연성 부족: 서블릿은 특정 요청에 대한 처리를 고정적으로 수행하기 때문에, 새로운 요청 처리 로직을 추가하거나 변경하기가 어렵다. 이는 변화하는 요구사항에 신속하게 대응하기 어렵게 만든다.
이러한 문제를 해결하기 위해 중앙에 하나의 서블릿을 두는 프론트 컨트롤러 패턴이 등장한다.
프론트 컨트롤러 패턴
프론트 컨트롤러 패턴은 모든 요청을 단일 진입점(프론트 컨트롤러 서블릿)에서 처리하여, 요청의 흐름을 중앙에서 관리한다.
중앙 집중화된 요청 처리: 모든 클라이언트 요청을 하나의 서블릿이 받아들이고, 이를 적절한 핸들러로 전달한다. (여기서 말하는 핸들러가 스프링부트에서 작성하는 Controller 이다.)
공통 기능의 일관된 처리: 인증, 로깅, 보안 검사 등과 같은 공통 기능을 중앙에서 처리하여 코드 중복을 줄인다.
유연한 요청 라우팅: 요청을 분석하고, 적절한 비즈니스 로직이나 뷰로 라우팅할 수 있다.
코드의 재사용성 향상: 공통 로직을 프론트 컨트롤러에 집중시킴으로써, 각 서블릿이나 핸들러에서 중복되는 코드를 줄일 수 있다.
디스패처 서블릿이 바로 프론트 컨트롤러이다.
서블릿 컨테이너
서블릿 컨테이너는 서블릿을 실행하고 웹 애플리케이션을 관리하는 서버 측 컴포넌트이다. 서블릿 컨테이너는 애플리케이션이 시작될 때 프론트 컨트롤러 서블릿을 초기화하고, 이를 실행 가능한 상태로 만든다. 클라이언트로부터 요청이 들어오면, 서블릿 컨테이너는 이 요청을 프론트 컨트롤러 서블릿으로 전달한다. 프론트 컨트롤러 서블릿은 요청을 분석하고, 적절한 핸들러로 라우팅한다.
서블릿 컨테이너와 WAS의 관계
서블릿 컨테이너는 단순히 서블릿과 JSP 파일을 실행할 수 있는 환경을 제공하지만, 대부분의 Java 웹 애플리케이션은 데이터베이스 연결 풀링, 트랜잭션 관리, 보안 인증 같은 더 복잡한 요구 사항이 필요하다. 이러한 고급 기능을 제공하는 웹 애플리케이션 서버(WAS)는 서블릿 컨테이너 기능을 포함하여 더 강력한 Java EE 기능을 지원한다. 예를 들어, Tomcat은 기본적으로 서블릿 컨테이너이지만, WAS로 확장할 수 있는 옵션이 있으며, WebSphere나 WebLogic 같은 풀 피처 WAS는 다양한 Java EE 표준을 지원한다.
스프링의 등장 배경과 프레임워크의 필요성
프론트 컨트롤러 패턴은 MVC(Model-View-Controller) 아키텍처와 결합되면서 스프링 프레임워크의 기반이 되었다. 프론트 컨트롤러 역할을 수행하는 스프링의 디스패처 서블릿은 모든 클라이언트 요청을 중앙에서 관리하고 라우팅하며, 스프링의 DI(Dependency Injection) 기능을 통해 서비스, 레포지토리 등을 손쉽게 연결할 수 있게 합니다. 스프링 MVC는 서블릿 API와의 의존성을 최소화하며, 코드의 가독성을 높이고 유지 보수를 용이하게 했다.
정리
간단하게(?) 웹 기술의 발전에 대해 알아보았다. 흐름을 이해하고 있다면 분명히 도움이 될 것이다. 아는 만큼 보인다는 말은 괜히 있는게 아니다.
'Java Spring' 카테고리의 다른 글
Specification 과 Criteria API (0) | 2024.11.08 |
---|---|
JPA와 하이버네이트 (2) | 2024.10.24 |
Transactional 원리 (0) | 2024.09.24 |
JDBC 부터 Spring Data JPA 까지 (0) | 2024.09.20 |