게시판 서비스 github URL: https://github.com/jiyean99/eazy-board.git
이번에 Spring Boot 2.7 + Java 11 환경에서 MVC 패턴으로 게시판을 만들면서, 평소에 많이 쓰던 RESTful 방식과 흐름이 어떻게 다른지 다시 정리하게 됐다. 동시에 로그인 방식도 토큰 기반(JWT 등)과 세션 기반이 어떤 차이를 가지는지, 구현 관점에서 무엇이 자동화되고 무엇을 직접 설계해야 하는지도 비교해볼 수 있었다.
이 글은 내가 만든 게시판 프로젝트 README에 적었던 내용과, 실습하면서 정리한 개념(아키텍처/인증/세션 저장소)을 하나의 흐름으로 연결해 정리한 것이다.
RESTful vs MVC: 화면을 누가 책임지는가
RESTful: 서버는 데이터만 제공한다(2-step)
RESTful 방식은 서버가 “화면”이 아니라 “데이터(JSON)”를 제공하는 구조다. 사용자가 www.xxx.com으로 접근하면, 먼저 프론트엔드가 HTML/CSS/JS를 사용자에게 내려준다. 그리고 내려받은 JS 코드(예: axios 요청)가 API들을 호출한다. 서버는 각 API 요청에 대해 JSON을 응답하고, 프론트는 그 JSON을 화면에 바인딩하면서 UI를 완성한다.
정리하면 단계가 이렇게 나뉜다.
- 1단계: 정적/번들 리소스(HTML/CSS/JS) 응답
- 2단계: JS가 API 호출 → 서버는 JSON 응답 → 화면에 데이터 삽입
이 구조의 장점은 화면 개발을 고도화하기 쉽다는 점이다. 프론트에서 컴포넌트/상태관리/라우팅을 자유롭게 구성할 수 있고, 서버는 비즈니스 로직과 데이터 제공에 집중할 수 있다.
MVC: 서버가 화면과 데이터를 함께 제공한다(1-step)
반대로 MVC 방식은 사용자가 URL로 접근하면 요청이 서버로 직접 들어가고, 서버가 DB를 조회한 뒤 “화면 템플릿 + 데이터”를 합쳐서 HTML로 응답한다. 즉, 서버가 View 렌더링을 담당한다.
정리하면 다음 흐름이다.
- 요청 → 서버 → DB 조회 → 템플릿 엔진이 데이터 바인딩 → HTML 응답
MVC의 장점은 빠르게 화면을 구성하고 동작시키기 쉽다는 점이다. 특히 CRUD 중심의 관리형 화면이나 간단한 서비스는 템플릿 기반으로 속도감 있게 만들 수 있다. 대신 화면을 세밀하게 고도화하거나, 프론트 영역의 복잡한 상호작용을 적극적으로 만들려면 구조적으로 불리해질 수 있다.
MVC에서 화면에 데이터를 끼워 넣는 대표 기술이 JSP, Thymeleaf 같은 템플릿 엔진이고, 이번 프로젝트에서는 Thymeleaf를 사용했다.
게시판 실습 프로젝트에서 MVC를 선택한 이유와 구현 범위
이번 프로젝트는 “MVC 패턴을 몸으로 익히는 것”이 목표였고, 그래서 화면까지 서버에서 렌더링하는 구조로 진행했다. 구현한 기능은 아래 범위를 기준으로 정리할 수 있다.
- 게시글
- 목록 조회 + 페이징(Pageable)
- 상세 조회
- 작성/수정
- 삭제(Soft Delete,
delYn플래그)
- 회원
- 회원가입
- 로그인/로그아웃
- 회원 목록/상세(관리자 영역)
- 권한
- ADMIN일 때만 회원 관리 메뉴 노출
- 게시글 작성은 로그인 필요
MVC 구조에서 보통 세션 로그인 사용 빈도가 높은 편인데, 이번에도 세션 기반으로 구성했다. 그리고 멀티 서버 환경에서의 세션 문제를 고려해 Redis 세션 저장소(Spring Session + Redis)까지 적용했다.
토큰 로그인 vs 세션 로그인: 인증을 누가 얼마나 자동화해주나
아키텍처가 MVC냐 REST냐와 별개로, 로그인 인증을 어떻게 구성하느냐도 중요한 설계 포인트다. 나는 토큰 기반과 세션 기반을 아래처럼 비교해서 이해하고 있다.
토큰(Token) 기반 인증 흐름
토큰 인증은 대체로 이런 단계로 구성된다.
1) 사용자가 email/pw로 로그인 요청
2) 서버가 DB에서 사용자 검증
3) 서버가 토큰 발급
4) 사용자는 이후 요청마다 토큰을 함께 전송
5) 서버의 토큰 필터가 토큰 검증
6) 검증 성공 시 Authentication 객체를 생성해 SecurityContext에 세팅
토큰은 기본적으로 서버가 상태를 저장하지 않는 방향(무상태, stateless)을 지향한다. 물론 Refresh Token을 쓰면 서버 저장소를 도입하는 경우도 있지만, “무조건 저장”은 아니다.
로그아웃의 의미도 세션과 다르다. 일반적인 토큰 기반에서 로그아웃은 “프론트에서 저장된 토큰을 제거하는 행위”가 된다(서버에서 할 일이 없는 구조). RT를 저장하는 구조라면 서버 저장된 RT를 삭제하는 방식도 가능하다.
세션(Session) 기반 인증 흐름
세션 기반은 Spring Security의 기본 기능들이 상당 부분 자동화해준다. 내가 정리한 “세션 로그인 흐름”은 다음과 같다.
1) 화면에서 /doLogin 호출
2) Spring Security 내부의 로그인 처리에서 loadUserByUsername 호출
3) 조회된 User와 사용자가 입력한 email/password를 비교 검증
4) 검증 완료 시 Authentication 객체 생성 + 세션 ID 발급
5) 이후 요청은 세션 ID 기반으로 자동 검증
즉 “로그인 처리/검증/인증 객체 생성/세션 발급”의 큰 골격이 프레임워크에 내장돼 있고, 개발자는 설정과 핸들러(성공/실패 처리) 중심으로 확장한다.
로그아웃도 차이가 있다. 세션은 서버가 세션 ID를 저장하고 있으므로, 로그아웃 시 서버에서 세션을 제거해 “로그아웃을 서버가 확정”할 수 있다.
| 로그인 전 세션ID값 | 로그인 후 세션ID값 |
|---|---|
 |  |
로그인 이후 세션ID값을 로그인전 세션ID값으로 강제 변경시에 글 작성 등 인증이 필요한 페이지에서 튕기게 됨
세션 로그인과 Redis: 멀티 서버에서의 문제를 어떻게 해결하는가
세션 로그인은 기본적으로 서버 메모리에 세션이 저장되는 구조가 많다. 이 방식은 단일 서버에서는 단순하고 잘 동작하지만, 서버가 여러 대가 되는 순간 문제가 생긴다.
- A 서버에 로그인 세션이 저장됐는데
- 다음 요청이 로드밸런서에 의해 B 서버로 가면
- B 서버에는 세션이 없어서 인증이 풀린 것처럼 보일 수 있다
이 문제를 해결하는 전형적인 방식이 “세션 저장소를 외부로 분리”하는 것이고, 여기서 Redis가 많이 쓰인다. 이번 프로젝트에서는 spring-session-data-redis를 사용해 세션이 Redis에 저장되도록 구성했다.
실습 프로젝트지만, 단순히 “로그인 된다/안 된다” 수준에서 끝내지 않고, 세션 기반 인증이 커질 때 어떤 문제가 생기는지와 그 해결책(세션 저장소 분리)을 함께 다뤄본 게 개인적으로 의미가 있었다.
마무리: MVC를 다시 해보면서 얻은 감각
최근에는 Java 17 + Spring Boot 3.5 조합을 메인으로 쓰고 있지만, MVC 흐름을 명확히 익히기 위해 일부러 Java 11 + Boot 2.7 환경으로 내려서 작업했다. 덕분에 “서버가 화면까지 책임지는 방식”의 장단점이 더 명확하게 체감됐고, 인증 역시 토큰 기반과 세션 기반을 “자동화 범위/운영 관점/로그아웃 의미”로 비교해볼 수 있었다.
