[Inflearn] 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 정리 (A)

📚 강의 출처

---

스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술 강의 | 김영한 - 인프런

강사님께 항상 감사합니다. 🧑🏻‍💻
해당 글은 김영한님의 강의와 개인적 지식을 바탕으로 정리한 내용입니다.
모든 자료의 출처는 김영한 강사님임을 미리 밝힙니다.

섹션 1. 웹 애플리케이션의 이해

---

• Web - HTTP 기반
• 웹서버(Web Server)
  • 클라이언트로부터 HTTP 요청 처리 
  • 정적 컨텐츠 제공 (HTML, CSS, JavaScript)
  • 동적 컨텐츠 요청 시, 이를 적절한 웹 애플리케이션 서버나 스크립트로 전달

• 웹 애플리케이션(WAS - Web Application Server)
  • 사용자 요청에 따라 데이터 처리 및 비즈니스 로직 수행
  • 동적 컨텐츠 생성
  • 사용자 입력을 받아 처리하고, 결과를 사용자에게 반환

• Web 서버와 WAS 차이
  • Web 서버는 정적 리소스, WAS는 애플리케이션 로직

 

• 웹 시스템 구성 - Web, WAS, DB
  • 정적 리소스는 Web 서버 처리
  • 동적인 로직은 WAS가 처리
  • 효율적인 리소스 관리가 가능
    • 정적 리소스가 많다? Web 서버 증설
    • 동적인 로직 리소스가 많다? WAS 증설

 

서블릿 예시

• 서블릿 특징
  • "/hello" URL 호출 시 서블릿 코드 실행
  • 요청 정보 사용 HttpServletRequest
  • 응답 정보 제공 HttpServletResponse

서블릿 동작

• 서블릿 컨테이너
  • 생성, 초기화, 호출, 종료하는 생명주기 관리
  • 싱글톤으로 관리
    • 공유 변수 사용 주의 ⚠️
  • JSP도 서블릿으로 변환
  • 멀티 쓰레드 처리 지원

 

• 쓰레드 : 코드를 하나하나 순차적으로 실행하는 것을 쓰레드 담당
• 요청 별 쓰레드 생성
  • 장점
    • 동시 요청 처리 가능
    • CPU, 메모리가 허용할 때까지 가능
  • 단점
    • 쓰레드 비용 과다
    • 쓰레드의 컨텍스트 스위칭 비용 발생 
      • 컨텍스트 스위칭 : 코어가 쓰레드 처리할 때 이동하는 시간
    • 쓰레드 생성에 제한 X

 

• 쓰레드 풀
  • 장점
    • 쓰레드를 생성하고 종료하는 비용 절약, 응답 시간 쾌적
    • 쓰레드 최대치 설정으로 요청의 제한을 두어 안전하게 처리 가능
  • 최대 쓰레드(max thread) 수
    • 낮게 설정 : 동시 요청이 많을 때, 서버는 여유 - 클라이언트는 응답 지연
    • 높게 설정 : 동시 요청이 많을 때, CPU, 메모리 임계점 초과로 서버 다운
    • 적정 수치는 로직의 복잡도, CPU, 메모리, IO 리소스 상황에 따라 -> 성능 테스트 시도

쓰레드 풀

• HTTP API
  
  • 주로 JSON 형태 데이터 통신
  • 앱, 웹 클라이언트, 서버 to 서버

 

• SSR - 서버 사이드 렌더링
  • HTML 최종 결과를 서버에서 웹 브라우저 전달
  • 관련 기술 : JSP, 타임리프
• CSR - 클라이언트 사이드 렌더링
  • HTML 결과를 웹 브라우저에서 동적으로 생성해서 적용
  • 관련 기술 : React, Vue.js

 

• 자바 웹 기술 역사
  • 서블릿 - 1997
  • JSP - 1999
  • 서블릿, JSP 조합 MVC 패턴 사용
  • MVC 프레임워크 춘추 적국 시대 - 2000년 초 ~ 2010년 초

 

• 자바 뷰 템플릿 역사
  • JSP - 속도 느림, 기능 부족
  • 프리마커, 벨로시티 - 속도 문제 해결, 다양한 기능
  • 타임리프 - 스프링 MVC와 강력한 기능 통합, 내추럴 템플릿

 

섹션 2. 서블릿

---

• @ServletComponentScan 서블릿 직접 등록 어노테이션
• @WebServlet 서블릿 어노테이션
  • name : 서블릿 이름
  • urlPatterns : URL 매핑

웹 애플리케이션 서버의 요청 응답 구조

• HttpServletRequest
  • HTTP 요청 메시지를 파싱해 결과를 객체에 담아서 제공
  • 편리하게 HTTP 요청 메시지 조회 가능
  • 임시 저장소, 세션 관리 기능 제공

 

• 클라이언트 -> 서버 데이터 전달
  • GET - 쿼리 파라미터
  • POST - HTML Form
  • HTTP message body 데이터 포함 전달
  • 주로 JSON 사용
    • JSON 결과 파싱은 Jackson, Gson 변환 라이브러리 사용
    • Spring MVC는 Jackson 라이브러리 사용

 

• HttpServletResponse
  • 응답코드, 헤더, 바디 생성
  • Content-Type, 쿠키, Redirect 기능 제공
  • JSON 반환 타입은 'application/json' 지정
    • 'application/json'는 utf-8 형식을 사용하도록 지정

 

🧑🏻‍💻 강의 실습 기록

섹션 2. 서블릿 · Issue #24 · taek2222/Inflearn_Spring

 

섹션 3. 서블릿, JSP, MVC  패턴

---

/**
* 동시성 문제가 고려되어 있지 않음, 실무에서는 ConcurrentHashMap, AtomicLong 사용 고려 
*/
public class MemberRepository {
private static Map<Long, Member> store = new HashMap<>(); //static 사용
private static long sequence = 0L; //static 사용

• 동시성 문제
  • HashMap -> ConurrentHashMap 권장
  • long sequence  -> AtomicLong 권장

 

• 스프링 빈 방식이 아닌 직접 싱글톤 패턴을 적용한 빈 생성

 

• 템플릿 엔진의 등장
  • Servlet과 Java만으로 웹 애플리케이션 개발
  • 코드 매우 복잡
  • 코드 비효율적
  • 템플릿 엔진 ex) JSP, Thymeleaf, Freemaker, Velocity

 

• JSP
  • <%@ %> : 자바의 import문
  • <% ~~ %> : 자바 코드 입력
  • <%= ~~ %> : 자바 코드 출력

 

• MVC 패턴 등장
  • 서블릿, JSP처럼 비즈니스 로직 및 뷰 랜더링을 모두 처리 시 유지보수의 어려움 발생
  • 변경의 라이프 사이클의 불편함

 

• MVC(Model View Controller)
  • 컨트롤러(Controller)와 뷰(View)라는 영역으로 역할 나눠 관리
    • 컨트롤러 : HTTP 요청을 받아 검증 후 비즈니스 로직 실행
    • 모델 : 뷰에 출력할 데이터 보관
    • 뷰 : 모델에 담겨 있는 데이터를 활용한 화면 구성
  • 컨트롤러는 일반적으로 서비스, 리포지토리 등의 계층을 별도로 만들어 처리

 

• "/WEB-INF"
  • 경로 안에 JSP 존재 시 외부에서 직접 호출 불가

 

• redirect vs forward
  • redirect : 클라이언트가 요청을 보낸 후 응답을 받아 다시 redirect 경로로 요청
  • forward : 서버 내부에서 호출 발생해 재요청 X

 

• MVC 패턴 한계
  • 컨트롤러와 뷰 역할을 명확하게 구분
  • 하지만, 코드에 불필요한 중복이 많이 존재.

 

• 포워드 중복

RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath);
dispatcher.forward(request, response);

• ViewPath 중복

String viewPath = "/WEB-INF/views/new-form.jsp";

• 사용하지 않는 코드 지속적 호출
• 공통 처리의 어려움

 

• MVC 패턴 한계 해결점
  • 공통 기능을 처리하는 수문장 역할을 하는 기능
  • 프론트 컨트롤러 패턴 도입

 

🧑🏻‍💻 강의 실습 기록

섹션 3. 서블릿, JSP, MVC 패턴 · Issue #26 · taek2222/Inflearn_Spring

 

섹션 4. MVC 프레임워크 만들기

---

프론트 컨트롤러 역할

• FrontController 패턴 특징
  • 서블릿 하나로 요청에 맞는 컨트롤러 탐색 호출
  • 공통 처리 기능

 

• 스프링 웹 MVC 핵심은 FrontController
• DispatcherServlet 이 해당 패턴으로 구현

 

v1 모델

• V1 프론트 컨트롤러 도입 - 해석
  1. 클라이언트가 HTTP 요청을 보낸다.
  2. FrontController에 도달한 요청은, 저장되어 있는 URL 매핑 정보랑 비교해 알맞은 Controller 탐색한다.
  3. Controller에 클라이언트로 받은 Request, Response 데이터를 전달하면서 컨트롤러를 실행한다.
  4. JSP는 최종적으로 사용자에게 로직대로 실행되어 사용자에게 전달된다.

v2 모델

• V2 View 분리 - 해석
  1. 클라이언트가 HTTP 요청을 보낸다.
  2. FrontController에 도달한 요청은, 저장되어 있는 URL 매핑 정보랑 비교해 알맞은 Controller 탐색한다.
  3. Controller에 클라이언트로 받은 Request와 Response 데이터를 전달받아, MyView 호출해 렌더링한다.
  4. MyView에서 전달 받은 정보를 바탕으로 일치하는 주소를 탐색해 JSP 로직대로 실행되어 사용자에게 전달된다.

v3 모델

• V3 서블릿 종속성 제거 - 해석
  1. 클라이언트가 HTTP 요청을 보낸다.
  2. FrontController에 도달한 요청은, 저장되어 있는 URL 매핑 정보랑 비교해 알맞는 Controller 탐색한다.
  3. Controller에 로직 처리를 수행하고, 결과 데이터와 함께 ModelView 객체를 생성해 반환한다.
  4. FrontController에서 실제 경로를 호출하는 viewResolver 메서드 호출해 JSP 파일 경로 반환
  5. 완성된 객체를 통해 뷰 렌더링 과정을 거쳐 요청이 JSP 파일로 포워드 되며, 사용자에게 전달된다.

 

• V4 ModelView 반환 -> ViewName 반환. V3 구조와 동일 
  • 번거로운 ModelView 객체 생성 후 반환 과정을 ViewName으로만 전달
  • "프레임워크나 공통 기능이 수고로워야 사용하는 개발자가 편리하다"

v5 모델

• V5 어댑터 패턴 도입 - 해석
  1. 클라이언트가 HTTP 요청을 보낸다.
  2. FrontController에 도달한 요청의 URI에 따라 적절한 핸들러 탐색한다.
  3. 찾은 핸들러를 처리할 수 있는 어댑터 조회 후, 어댑터를 사용하여 핸들러를 실행합니다.
  4. 다른 내용은 이전과 동일하게 ModelView를 생성해 렌더링 하고 클라이언트에게 최종 응답을 전송합니다.

 

• 정리
  • V1 : 프론트 컨트롤러 도입
  • V2 : View 분류
    
    • 반복되는 로직 뷰 분리
  • V3 : Model 추가
    • 서블릿 종속성 제거
    • 뷰 이름 중복 제거
  • V4 : 단순하고 실용적인 컨트롤러
  • V5 : 유연한 컨트롤러
    • 어댑터 도입

 

🧑🏻‍💻 강의 실습 기록

28 섹션 4 mvc 프레임워크 만들기 by taek2222 · Pull Request #29 · taek2222/Inflearn_Spring