1. [문제 인식 및 정의]
JwtFilter에서 JWT의 userRole 값을 UserRole enum으로 변환해서 사용하고 있었지만, request attribute에는 다시 문자열로 저장하고 있었다.
이로 인해 이후 AdminCheckInterceptor에서 다시 문자열을 enum으로 변환해야 했고, 같은 역할 정보가 서로 다른 타입으로 처리되어 코드 흐름이 일관되지 않았다.
기능 자체는 동작할 수 있었지만, 타입 혼용으로 인해 유지보수성과 가독성 측면에서 개선이 필요하다고 판단했다.
2. [해결 방안]
2-1. [의사결정 과정]
문제의 원인은 userRole을 한 번은 enum으로, 한 번은 문자열로 다루고 있다는 점이라고 판단했다.
이미 JwtFilter에서 UserRole enum으로 변환한 값이 있으므로, 이후에도 동일한 타입을 유지하는 것이 가장 간단하고 자연스러운 해결 방법이라고 생각했다.
따라서 request attribute에도 문자열이 아닌 enum 자체를 저장하고, Interceptor에서도 이를 그대로 꺼내 사용하도록 수정하기로 했다.
2-2. [해결 과정]
기존에는 아래와 같이 userRole을 enum으로 만든 뒤, request에는 다시 문자열로 저장하고 있었다.
UserRole userRole = UserRole.valueOf(claims.get("userRole", String.class)); httpRequest.setAttribute("userRole", claims.get("userRole"));
이를 아래와 같이 수정하여 enum 값을 그대로 저장하도록 변경했다.
UserRole userRole = UserRole.valueOf(claims.get("userRole", String.class)); httpRequest.setAttribute("userRole", userRole);
또한 AdminCheckInterceptor에서도 문자열을 다시 변환하는 방식 대신, request에 저장된 enum 값을 그대로 꺼내 사용하도록 수정했다.
기존:
UserRole role = UserRole.of((String) request.getAttribute("userRole"));
수정:
UserRole role = (UserRole) request.getAttribute("userRole");
이렇게 수정하여 userRole이 JwtFilter부터 Interceptor까지 동일한 타입으로 전달되도록 정리했다.
3. [해결 완료]
3-1. [회고]
이번 작업을 하면서 느낀 점은, 기능이 동작하더라도 다른 사람이 작성한 코드를 이해하고 흐름을 파악하는 일은 생각보다 쉽지 않다는 것이었다.
특히 타입이 섞여 있는 작은 차이도 바로 보이지 않아, 코드를 더 꼼꼼하게 읽는 연습과 기본기에 대한 공부가 더 필요하다고 느꼈다.
3-2. [전후 데이터 비교]
전:
후:
출력까지 잘 나온다!!
