KB IT's Your Life 7기 - Servlet과 Spring 핥아보기

 

지난 포스팅에 이어서 백엔드 교육에 대한 내용을 바탕으로 글을 작성하게 되었다.

하지만 이번 글은 아주 대략적인 요약본으로 작성하려고 한다.

그 이유는... 근 일주일 사이에 배운 내용이 너무나도 방대했기 때문이다.

 

 

실제로 하나하나 따지고 들어갈 만한 좋은 내용들이 정말 많다.

하지만 이 모든걸 하나의 포스팅으로 담는건... 포스팅의 가치가 완전히 없어지는 수준이 되지 않나 싶다.

눈에 들어오지도 않고, 단순히 정보를 뱉어내는 글밖에는 되지 않을 것 같다.

그래서 이번에는 아주 간략하게, 내가 수업에서 배웠던 내용을 복습하는 차원의 포스팅으로 구성해 보았다.

 

---

Servlet - 한글 처리, 세션, 쿠키, 필터

지난 포스팅에서는 Servlet에 대한 대략적인 내용을 정리했다.

이후 수업시간에서는 서블릿을 좀 더 잘 다루기 위해서 어떤걸 거치게 되는지 심화적으로 배우게 된다.

하지만 이것들도 결국 요청과 응답을 조금 더 현실적으로 다루기 위한 기능들이다.

 

 

한글 처리는 사용자가 입력한 값을 제대로 읽기 위해서 UTF-8 인코딩으로 변경하는 기본 작업이다.
세션(Session)은 서버가 사용자의 상태를 기억하기 위한 방법이다.
쿠키(Cookie)는 브라우저에 간단한 값을 저장하기 위한 방법이다.
필터(Filter)는 여러 서블릿에서 반복되는 공통 처리를 분리하기 위한 방법이다.

 

결국 서블릿 심화 부분을 배울 때는 단순히 request, response만 다루는 단계에서 벗어나, 웹 애플리케이션의 상태와 공통 흐름을 관리하는 과정을 거쳤다고 할 수 있다. 

 

---

EL ( Expression Language )

EL은 Expression Language의 줄임말이다.

간단하게 말하면 JSP에서 데이터를 쉽게 출력하기 위한 표현식 언어다.

 

 

EL을 사용하니 코드가 훨씬 보기 편안해졌다.

 

강사님의 말씀에 따르면, 기존 JSP보다 EL을 사용하면 프로그래머만 읽을 수 있는 코드가 아니라 디자이너와 같은 다른 비전공자 사람들도 쉽게 이해할 수 있게되면서 생산성이 향상된다는 그런 이야기다. 당연한 소리지만, 역시 중요한 이야기이기도 하다. 프로그래머도 당연히 EL이 훨씬 보기 편하니, 좋은게 좋은거지.

 

JSTL ( JSP Standard Tag Library )

EL이 데이터를 출력하는 문법이라면, JSTL은 JSP에서 자주 쓰는 제어 기능을 태그 형태로 제공하는 라이브러리다.

예를 들어 조건문을 작성한다고 해보자. JSP 안에서 Java 코드를 직접 쓰면 이런 식이 된다.

<%
    if ("ADMIN".equals(role)) {
%>
    관리자
<%
    }
%>

 

동작은 하겠지만 가독성이 진짜 최악이다.

하지만 JSTL을 사용하면?

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<c:if test="${role == 'ADMIN'}">
    관리자
</c:if>

 

 

훨씬 보기 편해진다. 저 중괄호를 안넣어도 된다는게 이렇게 읽기 편해지는거다.

JSTL을 사용하려면 JSP 상단에 taglib 지시자를 추가해주면 된다.

이 JSTL을 이용해서 조건, 반복, 포맷같은 로직을 처리해주면 된다.

EL, JSTL의 스코프

JSP에서 `${name}` 이라고 작성하면 EL은 무작정 아무 곳에서나 값을 가져오는지는 않고 정해진 순서를 거쳐서 가져온다.

가장 가까운 page, request, session, application 영역 순으로 찾아온다고 생각하면 된다.

 

 

---

FrontController

서블릿은 사용자들의 요청을 처리해주는 역할이었다. 이제 그 서블릿들을 한군데로 모아주는 역할을 만드는게 FrontController다. 말 그대로 앞단의 컨트롤러라고 생각하면 된다. 사용자의 모든 요청을 먼저 앞단에서 받아주고, 그걸 적절한 서블릿으로 넘겨주는게 핵심이다.

@WebServlet("/")
public class FrontController extends HttpServlet {
    // 모든 요청을 먼저 받는 입구
}

 

GET 요청은 보통 화면을 보여주는 요청이니까 JSP로 forward 한다. forward는 서버 내부에서 JSP로 이동하는 방식이다.
request에 담아둔 데이터도 그대로 유지된다.

RequestDispatcher dis = request.getRequestDispatcher(
    "/WEB-INF/views/todo/list.jsp"
);
dis.forward(request, response);

 

반면 POST 요청은 보통 등록, 수정, 삭제처럼 데이터를 변경하는 요청들이다. 그래서 이런 요청은 처리 후 redirect 한다. redirect는 브라우저에게 다시 요청하라고 시키는 방식이다. 그래서 새로고침했을 때 같은 POST 요청이 반복 실행되는 문제를 줄일 수 있다.

response.sendRedirect("/todo/list");

---

Spring Context

Spring Context는 Spring이 객체를 만들고 보관하고 관리하는 공간이다. Spring은 필요한 객체를 직접 생성하고, 그 객체를 Bean이라는 이름으로 관리한다. 즉, 우리가 매번 new로 객체를 만들지 않아도 Spring이 대신 객체를 만들고 필요한 곳에 넣어준다.

 

Bean은 Spring이 관리하는 객체다. 그냥 Java 객체와 형태가 특별히 다른 것은 아니고, 누가 관리하느냐가 중요한 것일 뿐이다. 내가 직접 만든 객체는 일반 객체고, Spring Context에 등록되어 Spring이 관리하는 객체는 Bean이다.

@Bean
public BoardService boardService() {
    return new BoardServiceImpl();
}

 

이렇게 등록하면 Spring은 BoardService 객체를 Bean으로 관리한다.

Bean을 등록할 때는 `@Configuration`, `@Bean`을 사용할 수 있다.

필요한 객체를 직접 만들지 않고 외부에서 받는 방식을 의존성 주입(DI, Dependency Injection)이라고 한다.

그리고 Spring은 이 의존성 주입을 통해 Controller, Service, Mapper 같은 객체들을 서로 연결해준다.

 

 

Spring MVC ( Model, View, Controller )

Spring MVC 프로젝트에서는 설정 파일이 역할별로 나뉜다.

 

RootConfig는 공통으로 사용할 Bean을 등록한다. 주로 Service, Mapper, DataSource, TransactionManager 같은 객체들이 여기에 들어간다.

 

ServletConfig는 DispatcherServlet과 관련된 설정을 담당한다. Controller 스캔, ViewResolver, 정적 파일 경로 같은 웹 MVC 설정이 여기에 들어간다.

 

WebConfig는 기존의 web.xml을 Java 설정으로 대체하는 역할을 한다. RootConfig와 ServletConfig를 등록하고, 필터 같은 웹 설정을 연결한다.

 

 

---

DispatcherServlet

DispatcherServlet은 Spring MVC의 FrontController다. 즉, 모든 웹 요청의 입구 역할을 한다. 그래서 흐름을 익혀두는 편이 좋다고 한다.

브라우저 요청
→ DispatcherServlet
→ HandlerMapping
→ Controller
→ Service
→ Model
→ ViewResolver
→ JSP 응답

 

0. Spring MVC에서 요청은 Controller로 바로 가지 않는다.

1. 먼저 DispatcherServlet이 요청을 받는다.
2. 그다음 HandlerMapping을 통해 알맞은 Controller 메서드를 찾는다.
3. Controller는 요청 파라미터를 받고, Service를 호출하고, 결과를 Model에 담는다.
4. 마지막으로 ViewResolver가 JSP를 찾아 응답 화면을 만든다.

 

Spring MVC Controller는 요청을 받아서 비즈니스 로직으로 연결하고, 결과 데이터를 View로 넘기는 역할을 하는 것이다. DispatcherServlet이 전체 흐름을 조율하고, Controller는 각각의 요청을 실제 기능으로 연결하게 된다.

 

 

---

Spring과 MySQL 연동

1. 먼저 properties에 DB 접속 정보를 적는다. 이걸 사용하면 Java 코드에 DB 설정값을 넣지 않아도 된다.
2. Spring은 그 값을 읽어서 DataSource를 만든다. DB 연결 커넥션 풀을 Bean으로 등록해서 관리해 효율성을 높인다.
3. SqlSessionFactory는 MyBatis가 SQL을 실행할 수 있게 준비한다. 
4. TransactionManager는 여러 DB 작업을 하나의 트랜잭션으로 묶어준다.

application.properties
→ DataSource(HikariCP)
→ SqlSessionFactory(MyBatis)
→ TransactionManager
→ Mapper
→ MySQL

 

결국 우리가 이 설정을 하는 이유는 Controller와 Service에서는 DB 연결 과정을 직접 신경 쓰지 않고, 비즈니스 로직에 집중하기 위해서다. 하나의 단계에서 하나의 작업에만 집중하는 시스템을 구현해야 유지보수가 편해진다는 것이다. 

 

 

---

 

솔직히 말하면 이번 한 주는 조금 많이 버거웠다.

하나를 이해하면 그 아래에 또 다른 개념이 있었고, 그걸 이해하면 또 다음 개념이 이어지고 있고...

새로운 어노테이션을 배우고, 설정방법을 배우고... 너무나도 많은 지식이 쏟아지니 머리에 잘 들어오지도 않았던 것 같다.

정작 이전에 배웠던 방식에 대해서 체화가 되지 않아서 다음걸 익힐 때 이전 것을 까먹는 일도 잦았다.

자격증 준비를 하느라 시간이 없던 것도 한몫 했다.

 

그래도 나름 이 글을 정리하면서 개념들이 다시 재정립되는 느낌이랄까? 이해되지 않았던 부분들이 조금씩 보이기 시작하기도 한다. 내가 직접 코드를 치고 만들어보면서 체화하는 시간이 더욱 필요할 것 같다는 생각이 든다. 곧 있으면 팀프로젝트를 시작하게 될 탠데, 부족하지 않은 모습을 보이려면 더욱 열심히 공부해야겠다.