wms웹프로젝트 아키텍쳐 고민

섭정이·2025년 4월 12일
post-thumbnail

WMS + 쇼핑몰 통합 프로젝트 아키텍처 설계 과정 (JWT vs 세션 vs Redis)

목차

  1. 프로젝트 개요 및 요구사항
  2. 아키텍처 1: 세션 기반 클러스터링 구조
  3. 아키텍처 2: JWT 기반 구조
  4. 아키텍처 3: JWT + Refresh 구조
  5. 아키텍처 4: Redis 세션 구조 (최종)
  6. 해야 할 것

프로젝트 개요 및 요구사항

이번 프로젝트는 쇼핑몰과 WMS(Warehouse Management System)를 결합한 시스템이다.

또한 프로젝트 제약 사항으로는 서버사이드렌더링 레거시 스프링 사용 이 있었으므로 이 부분도 고려하였다.

  • 쇼핑몰 사용자와 관리자(물류 담당자) 모두 동일한 인증 체계를 사용해야 한다.
  • 인증된 사용자는 두 시스템을 넘나들며 리소스를 안전하게 접근할 수 있어야 한다.
  • 인증 상태는 서버 재시작, 수평 확장 상황에서도 유지되어야 한다.

이러한 요구사항을 만족하기 위한 인증 아키텍처 설계하면서 생긴 궁금증과 한계점들을 조사하고 최종 선정한 아키텍쳐를 정리하기위한 글이다.


아키텍처 1: 세션 기반 클러스터링 구조 (기본 세션 방식)

구조 설명

  • HttpSession 기반 인증 사용
  • 서버 간 세션 동기화가 필요함

장점

  • 구현이 간단하고 기존 스프링 MVC 방식과 호환성이 좋음
  • 기본 세션 구조로 관리가 쉽고 직관적임

한계점

  • 서버가 증가할수록 복잡성 및 관리 비용 증가
  • 장애 대응 및 확장성에 제약

서버수가 한대 늘어날때마다 각각 공유해야 하는 세션 수가 n개만큼 늘어나야 하고 해당 작업을 위해 드는 소요가 많을 것이라 판단하여 2번 구조를 고려하였다.


아키텍처 2: JWT 기반 구조

구조 설명

  • 인증 서버가 JWT 발급하고, 리소스 서버(WMS, 쇼핑몰)는 JWT 검증
  • Stateless 구조로 서버 간 상태 공유 불필요

장점

  • 서버 수평 확장에 강함
  • 서버 간 인증 상태 공유가 필요하지 않아 효율적

한계점

  • 토큰 탈취 시 위험 → 보안 문제

엑세스 토큰만 사용하는 jwt 인증서버를 사용하여 아키텍쳐를 구조화 하면 stateless 하기 떄문에 위의 세션방식에서 생긴 문제가 생기지 않을 것이라 판단하였다. 하지만 이경우에는 토큰만 탈취당하면 아무런 제약 없이 로그인 할수 있는 문제가 생기기 때문에 refresh 토큰을 도입하는 3번을 고려하였다.


아키텍처 3: JWT + Refresh 구조

구조 설명

  • Access Token 탈취 위험 보완을 위해 Refresh Token 도입
  • Refresh Token을 서버 측에 저장하여 관리

장점

  • JWT 탈취 문제 보완 가능
  • 일정 부분 무상태 유지

한계점

  • Refresh Token 저장 시 서버 간 상태 공유 필수
  • 세션 클러스터링과 유사한 문제로 복잡성 증가

stateless 하게 설계하는것이 목적이였는데 refresh 토큰을 사용하는 순간 결국 1번과 같이 stateless하지 못하게 된다. 따라서 그렇게 큰 의미가 없다고 판단하여 4번 구조로 최종 선택하였다.


아키텍처 4: Redis 세션 구조 (최종)

구조 설명

  • Spring Security를 통해 인증
  • 세션을 Redis에 저장(@EnableRedisHttpSession)
  • 쇼핑몰 및 WMS 서버가 동일 Redis 인스턴스를 통해 세션 공유

장점

  • 인증 상태 공유 및 관리 용이
  • 리프레시 토큰 관리 필요 없으므로 단순하고 명확
  • 세션 만료 및 관리가 세밀하고 안정적

한계점

  • Redis 장애 시 인증 불가능 (클러스터링 및 HA로 대응 가능)
  • Stateless 구조는 아님

stateless 는 아니지만 속도가 빠른 redis를 사용하여 세션을 대체하였고 redis를 공유하기 때문에 속도문제, 세션을 탈취당하더라고 서버에서 나름 이를 막을 방법이 있고 모든 서버가 세션을 공유해야 하는 문제도 막을 수 있을 것이라 판단하였다.


해야 할 것

이번 프로젝트에서는 인증 상태 공유가 필수였기 때문에 Stateless 구조로 출발한 JWT 방식은 보안성과 구조적 복잡성에서 단점이 컸습니다. 따라서 Redis 기반의 세션 공유 방식이 현실적이고 실용적인 대안이라는 판단으로 최종 설계되었습니다.

따라서 레거시 스프링에 스프링 시큐리티를 사용하고 저장소를 redis 로 하는 아키텍쳐를 구현하기위해 일단은 시큐리티에 대해 공부해보고 추후redis 적용 방법을 안 뒤에 구현해 나가야겠다.

profile
우직하게

0개의 댓글