웹 기술의 진화 과정 (자바 중심 + React)

1. 서블릿 Servlet

- 등장 배경

 웹이 1990년대 중반 급속도로 발전하면서 서버와 클라이언트 간 동적인 데이터 처리가 필요해졌다.
이전에는 HTML로 정적 웹 페이지를 만들 수는 있었지만,
사용자의 요청에 따라 실시간으로 변하는 페이지 생성 방법이 필요해졌다.
따라서 서블릿이 등장하게 된다.
 

- 특징

• 자바로 작성된 서버 측 프로그램으로, 클라이언트의 요청을 받아 처리함
• 동적인 웹 페이지 생성
• 웹 서버와의 통신을 위해 HTTP 프로토콜 사용
• 클라이언트의 요청 처리 후 응답 반환
• Java EE(Enterprise Edition)의 일부

 

- 문제점

• Java 코드만으로 HTML을 만들어야 하므로 매우 복잡하고 비효율적임
  👉 템플릿 엔진이 등장하게 됨

 

템플릿 엔진이란?

HTML 문서에서 필요한 곳만 코드를 적용하여
동적으로 변경하는 소프트웨어

예) JSP, Thymleaf, Freemarker, Velocity 등

 

---

 

2. JSP (JavaServer Pages)

- 등장 배경

서블릿은 HTML 코드와 Java 코드가 혼합되어 있어 코드가 복잡하다는 단점이 있다.
이것을 보완하기 위해 직관적이고 유지보수가 쉬운 JSP가 등장하게 된다.
 

- 특징

• HTML 내에 자바 코드를 삽입할 수 있는 템플릿 언어
• 웹 페이지의 시각적인 구성과 동적 컨텐츠 생성을 분리함
• 웹 서버에서 서블릿으로 변환되어 실행됨
• 개발자는 HTML과 자바 코드를 분리하여 더 쉽게 작성하고 유지할 수 있음

 

- 문제점

• Java의 비즈니스 로직이 전부 JSP에 노출됨
• JSP가 비즈니스 로직 + 뷰 역할 모두 담당(MVC1 패턴)
  👉 규모가 커지면 유지보수가 힘들어짐
  👉 비즈니스 로직과 뷰를 분리하기 위해 MVC2 패턴이 등장하게 됨

 
MVC 패턴이 궁금하다면? ↓↓
https://sproutinghye.tistory.com/69
 

JSP vs Thymleaf

	JSP	Thymleaf
패키징	jar 패키징 불가능, war 패키징만 가능 (war 패키징을 하려면 was 필요)	jar 패키징 가능 👉 Spring의 View 역할
코드 형태	순수 HTML 유지 X. JSP, HTML 코드 혼재 서버를 통해서만 렌더링 됨 👉 응답 결과를 받아야만 화면이 보임	순수 HTML 파일 유지 👉 웹 브라우저에서 파일 직접 열어도 내용 확인 가능
웹 페이지 생성	생성된 데이터를 웹 페이지와 함께 클라이언트 응답	HTML 파일을 가져와 파싱하고 분석한 후 정해진 위치에 데이터를 치환해 웹 페이지 생성
Servlet과의 관계	Servlet으로 변환되어 실행됨 👉 View에 비즈니스 로직 포함되어 복잡함	Servlet으로 변환X 👉 비즈니스 로직 완전 분리
속도	상대적으로 빠름	상대적으로 느림

 

---

 

3. Spring Framework

- 등장 배경

Servlet과 JSP로 인해 웹 애플리케이션 개발이 가능해졌지만,
복잡한 설정과 불편한 코드 구조로 인해 개발이 불편한 상태였다.
따라서 더 쉽고 유연한 프레임워크가 필요해졌고, 이렇게 만들어진 것이 바로 Spring이다.
 

- 특징

• 자바 기반의 경량 프레임워크
• 설정 및 의존성 주입으로 개발자들이 코드 관리를 더 쉽게 만들어줌
• POJO (Plain Old Java Object) 기반
  
  • 복잡한 xml 설정을 줄이고 어노테이션 기반 설정을 도입하여 개발자들이 직관적으로 작업할 수 있게 함
    👉 POJO 프로그래밍 코드를 위해 IoC/DI, AOP, PSA 지원
• IoC (Inversion of Control, 제어의 역전)
  
  • 보통 객체는 필요한 의존성을 스스로 생성하고 관리함 ex) new 연산자
    IoC는 외부의 컨테이너(Spring Container)가 각 객체의 생명주기와 의존성을 관리함
    👉 객체간 결합도 낮춤. 코드의 재사용성, 테스트 용이성을 높임
• DI (Dependency Injection, 의존성 주입)
  • IoC의 구현 방법. 객체가 의존하는 다른 객체(의존성)를 외부에서 주입받음
  • 종류: 생성자 주입, 세터 주입, 필드 주입
  • 장점
    - 결합도 감소: Service는 Repository 구현에 대해 알 필요가 없음
    - 테스트 용이성: 유닛 테스트가 쉬워짐
    - 유연성 좋아짐: Service는 다양한 Repository 구현체 사용이 가능함
    - 재사용성, 유지보수성 좋아짐
• AOP (Aspect Oriented Programming, 관점지향 프로그래밍)

 

---

 

4. SpringBoot

- 등장 배경

스프링 프레임워크는 여전히 설정 부담이 존재했다.
이러한 부담을 줄여준 것이 바로 SpringBoot이다.
 

- 특징

• 자동 설정(application.propeties/application.yml)을 통해 초기 설정을 간소화 함
• 내장 서버
  • Tomcat이 내장되어 있음
    👉 WAS 설치 없이 jar 파일로 패키징되어 실행됨
• 스타터 패키지
  • spring-boot-starter-web, spring-boot-starter-data-jpa 등 의존성을 묶어 사용함

 

그렇다면,
언제 스프링을 사용하고
언제 스프링부트를 사용할까?

Spring	SpringBoot
기존 애플리케이션 확장	빠른 개발 및 배포 필요
복잡한 애플리케이션 설계가 필요한 경우	독립 실행 애플리케이션 원할 때 (외부 WAS X)
	간단한 REST API, 웹 애플리케이션 개발

 

RESTful API란?
(REST API)

- 정의

REpresentational State Transfer의 줄임말로,
웹 애플리케이션의 데이터를 URL로 나타내고 HTTP 메서드를 통해 자원에 접근하는 API를 말한다.
 

- 특징

• HTTP 프로토콜 기반
  • GET, POST, PUT, DELETE로 자원 요청, 생성, 수정, 삭제
• 리소스 중심 설계
  • 애플리케이션의 데이터를 리소스로 정의함. 각 리소스는 고유한 URI(Uniform Resource Identifier)로 식별되고, HTTP 메소드로 동작함
• Stateless 무상태성
  • 서버는 클라이언트의 상태를 저장하지 않음. 요청이 독립적임
• 표준화된 응답 방식
  • JSON 혹은 XML 포맷을 사용해 데이터를 주고 받음
• 캐시 기능
  • 동일한 요청에 대해 서버 부하를 줄이고 성능을 개선할 수 있음

 

- 장점

• 간단하고 직관적인 설계
• 가벼운 데이터 전송
• 유연성 및 확장성
• 무상태성 👉 서버 확장성
• 캐싱 지원
• 폭 넓은 채택과 호환성

 

---

 

5. React

React를 설명하기 이전에, SPA 아키텍처에 대해서 간단히 설명하겠다.

 

SPA 아키텍처의 부상
Single Page Application

RESTful 웹 서비스가 보편화되면서, 클라이언트 측에서 필요한 데이터를 비동기적으로 가져오는 SPA 아키텍처의 인기가 많아졌다.
페이지 전체를 새로 고치지 않고도 사용자 인처페이스를 동적으로 업데이트하여 매끄러운 사용자 경험을 하게 해준다.

- 정의

SPA를 쉽게 개발할 수 있도록 도와주는 JS 라이브러리이다.

구성 요소 기반 아키텍처를 제공하고,

상태 관리와 UI 업데이트를 효율적으로 처리할 수 있게 해주어

동적이고, 반응성이 뛰어나다.

 

- JSP vs React

• JSP 기반의 웹 애플리케이션은 서버 측에서 HTML을 렌더링하여 클라이언트에게 보냄
  👉 사용자 경험이 제한적임. 페이지를 새로 고칠 때마다 전체 페이지를 로드함
• React와 RESTful 웹 서비스를 결합하면 클라이언트 측에서 필요한 데이터만 비동기적으로 가져와 페이지를 업데이트
  👉 빠르고 매끄러운 사용자 경험 제공