뉴젯 프로젝트에 함께하게 되었다.
뉴젯 프로젝트란 현재 상용화되어 앱시장에 나와있는 뉴젯 서비스의 백엔드 프레임워크를 스프링으로 이전하고 성능 개선 및 유저 피드백 개선에 초점을 둔 프로젝트이다.
첫 번째 과정으로, 인증파트를 도맡아 구현하였고 그 과정을 담았다.
개요
- 기존 슈퍼베이스 기반 서드파티 인증 로직을 서버 내부로 이전한다
- JWT 관리용 환경을 객체지향적으로 설계하고, 구현한다.
- 인터셉터와 리졸버, 커스텀 어노테이션 등을 이용하여 인증 시스템을 도입한다.
배경
기존 인증 시스템은 슈퍼베이스에 의존하고 있어 다음과 같은 문제점이 있었다
- 외부 서비스 의존도가 높아 장애 발생 시 대응이 어려움
- 인증 로직의 커스터마이징 제약이 있음
- 토큰 관리 및 검증 과정에서의 제어 권한 부족
- 보안 정책 적용의 유연성 부족
이러한 문제를 해결하기 위해 서버 내부에서 JWT를 직접 발급하고 관리하는 시스템으로 전환하여, 더 안정적이고 확장 가능한 인증 시스템을 구축하였다.
변경된 점
1. 도메인 중심 설계
핵심 도메인 객체 구현
- Feat: 토큰 객체 추가 [Token] : 토큰의 타입, 값, 유효기간 등을 캡슐화한 불변 객체 (Oauth 토큰 복수 사용 가능)
- Feat: 인증된 유저 객체 생성 [AuthUser] : 인증된 사용자 정보를 표현하는 도메인 객체 (필요 필드 추가 가능)
- Feat: 토큰 객체 추가 [TokenType] : 액세스 토큰과 리프레시 토큰을 구분하는 enum (타입 확장 가능)
2. JWT 관리 시스템 구현
- Feat: 토큰 생성용 Factory 구현 [JwtFactory] : JWT 생성을 담당하는 팩토리 클래스
- Feat: Token 메인 비즈니스 로직 구현 [JwtService] : 토큰 발급, 검증, 갱신 등의 비즈니스 로직 처리
- Feat: TokenRepository 인터페이스의 레디스 구현체 추가 [RedisRefreshTokenRepository] : 리프레시 토큰 저장소를 Redis로 구현하여 빠른 액세스와 자동 만료 기능 활용
3. 인증 인프라 구축
- Feat: JWT 인증용 인터셉터 구현 [AuthInterceptor] : @RequireAuth 어노테이션으로 인증 필요 여부를 판단, 요청 전처리 및 JWT 유효성 검증
- Feat: 인증 어노테이션 활용 및 AuthUser 전달을 위한 리졸버 구현 [AuthUserArgumentResolver] : @Login 어노테이션이 붙은 컨트롤러 파라미터에 인증된 사용자 정보 주입
4. 테스트 커버리지 확보
- 단위 테스트: 각 컴포넌트별 격리된 테스트로 동작 검증
JwtFactoryTest, JwtServiceTest 등 - Mock 기반 테스트: 인터셉터와 리졸버의 정상 작동 검증 등
- Test: TokenRepository의 Redis 구현체에 대한 실제 test레디스 통합테스트 추가 통합 테스트: Redis 리포지토리 리프레쉬 토큰 테스트
5. 보안 강화 및 편의 기능
- Feat: Token 인증용 Validator 구현 [TokenStolenException] : 토큰 탈취 감지 메커니즘 도입
- Feat: TokenRepository 인터페이스의 레디스 구현체 추가 [removeToken] : 서버 측 리프레쉬 토큰 무효화 가능 환경 구성
- Feat: TokenRepository 인터페이스의 레디스 구현체 추가 [deviceType] : deviceType 도입으로 디바이스별 고유한 유저 리프레쉬 토큰 관리 가능으로 동일 유저의 복수 디바이스 인증 용이성 확보
6. 특이사항
기존에는 인터셉터 단에서 발생하는 예외를 잡기 위해 커스텀 필터를 추가했으나, 실제 테스트 결과 해당 예외는 글로벌 예외 처리기(@RestControllerAdvice)에서 정상적으로 캐치됨을 확인했다.
원인 분석
Spring MVC는 요청 처리 시 아래와 같은 순서로 DispatcherServlet을 통해 요청을 위임한다.
Client → Filter → DispatcherServlet → Interceptor → Controller → ExceptionResolver (ex. @ControllerAdvice)초기에는 인터셉터 내부에서 예외 발생 시 필터에서 이를 잡아야 한다고 판단했지만, DispatcherServlet 이후에 발생한 예외는 Spring 자체의 ExceptionResolver에서 처리되므로, 커스텀 필터를 통한 예외 캐치가 필요하지 않음을 확인했다.
결과
불필요한 필터 제거를 통해 요청 흐름을 단순화하고 유지보수를 용이하게 했다.
Spring의 예외 처리 흐름(DispatcherServlet → ExceptionResolver)을 신뢰하고 이를 활용한 처리 방식으로 정리했다.
참고자료
JWT 공식 문서: https://jwt.io/introduction
도메인 주도 설계 DDD: https://incheol-jung.gitbook.io/docs/q-and-a/architecture/ddd
서블릿으로 예외처리 하기 : https://develop-writing.tistory.com/97
해당 PR 에서도 확인하실 수 있습니다 ☺️
