수학과의 개발자 도전기

1. 개요

스프링 시큐리티로 로그인을 구현했으니, 스프링 시큐리티로 로그아웃도 구현해보자. 로그아웃은 SecurityConfig 같은 시큐리티 config 클래스에서 설정해주면 된다.

스펙

• Spring Security
• JWT

2. SecurityConfig 코드

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig {

    private final JwtTokenProvider jwtTokenProvider;
    
    ...

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        ....
        http.
            ....
            .logout(logout -> logout
                                .logoutUrl("/logout")
                                .logoutSuccessUrl("/index")
                                // 로그아웃 핸들러 추가 (세션 무효화 처리)
                                .addLogoutHandler((request, response, authentication) -> {
                                    HttpSession session = request.getSession();
                                    session.invalidate();
                                })
                                // 로그아웃 성공 핸들러 추가 (리다이렉션 처리)
                                .logoutSuccessHandler((request, response, authentication) ->
                                        response.sendRedirect("/index"))
                                .deleteCookies("JSESSIONID", "access_token"));

        return http.build();
    }
}

3. 코드 톺아보기 - 로그아웃

SecurityConfig 클래스의 filterChain() 내부에서 logout을 설정해주면 되는데, 구체적인 과정은 다음과 같다.

• .logoutUrl() : 로그아웃을 요청할 url 설정
• .logoutSuccessUrl() : 로그아웃 성공시 리다이렉트 할 url
• .addLogoutHandler() : 세션 무효화 처리를 할 로그아웃 핸들러
  • 로그아웃 성공 실패 여부 상관없이 시도했을 때 수행된다
• .logoutSuccessHandler() : 로그아웃 성공 핸들러
  • addLogoutHandler가 수행되고, 로그아웃이 성공했을 때 수행된다
• .deleteCookies() : 쿠키 값 삭제 
  • "JSESSIONID" 를 설정해야 쿠키 에러가 발생하지 않는다.
  • jwt 토큰을 쿠키에 "access_token=~" 형태로 저장했으므로 "access_token"도 삭제한다.

.logout(logout -> logout
        .logoutUrl("/logout")
        .logoutSuccessUrl("/index")
        // 로그아웃 핸들러 추가 (세션 무효화 처리)
        .addLogoutHandler((request, response, authentication) -> {
            HttpSession session = request.getSession();
            session.invalidate();
        })
        // 로그아웃 성공 핸들러 추가 (리다이렉션 처리)
        .logoutSuccessHandler((request, response, authentication) ->
                response.sendRedirect("/index"))
        .deleteCookies("JSESSIONID", "access_token"));

SecurityContextLogoutHandler

코드 상에서 직접 세션을 무효화하거나 쿠키를 삭제하지 않더라도 세션을 무효화하고, 쿠키를 삭제하는 기능을 한다. 

순서는 개발자가 직접 정의한 핸들러 -> 스프링 시큐리티 제공 핸들러 로 진행된다.

참고

https://goto-pangyo.tistory.com/170

1. 개요

Spring Security를 이용해 로그인 기능 구현방법에 대한 내용이다. 로그인 기능을 위해서만을 위해 스프링 시큐리티를 적용하는 것이 애플리케이션이 무거워질 수 있다고는 하지만 일단 한번 경험해보면 좋을 것 같아서 스프링 시큐리티를 적용해보았다.

- Spring Security란?

스프링 시큐리티는 스프링 생태계에서 사용자 인증/권한 관리/보안 등의 기능을 효율적이고 신속하게 구현할 수 있게 도움을 주는 스프링 프레임워크 중 하나이다. 다양한 인증방식 중에 principal(username)-credential(password) 패턴을 사용하고 있다.

Spring Security 특징

• Filter를 기반으로 동작
  • Spring MVC와 분리되어 관리하고 동작할 수 있다.
• Bean으로 설정가능
  • Spring Security 3.2부터는 XML 설정하지 않아도 됨

- Spring Security Architecture

구체적인 과정은 다음과 같다.

1. 사용자 로그인 정보가 담긴 HTTP 요청이 서버로 들어온다.

2. AuthenticationFilter가 요청을 가로채고, 가로챈 정보를 통해 UsernamePasswordAuthenticationToken의 인증용 객체를 생성

3. Filter를 통해 AuthenticationToken을 AuthenticationManager로 위임한다.

4. AuthenticationManager는 등록된 AuthenticationProvider들을 조회하며 인증을 요구한다.

5. AuthenticationProvider는 UserDetailsService를 통해 입력받은 사용자 정보를 DB에서 조회한다.

• supports() 메서드를 통해 실행 가능한지 체크
• authentication() 메서드를 통해 DB에 저장된 이용자 정보와 입력한 로그인 정보 비교
  • DB 이용자 정보 : UserDetailsService의 loadUserByUsername()을 통해 불러옴
  • 입력 로그인 정보 : (4)애서 받았던 Authentication 객체(UsernameAuthentication Token)
• 일치하는 경우 Authentication 반환

6. AuthenticationManager는 Authentication 객체를 AuthenticationFilter로 전달한다.

7. AuthenticationFilter는 전달받은 Authentication 객체를 LoginSuccessHandler로 전송하고, SecurityContextHolder에 정보를 저장한다. 

2. 과정

2-1. 의존성 추가

build.gradle

implementation 'org.springframework.boot:spring-boot-starter-security'
testImplementation 'org.springframework.security:spring-security-test'

2-2. SecurityConfig

전체 코드

@Configuration
@EnableWebSecurity
@RequiredArgsConstructor
public class SecurityConfig {

    private final JwtTokenProvider jwtTokenProvider;

    @Bean
    public PasswordEncoder passwordEncoder() {
        return PasswordEncoderFactories.createDelegatingPasswordEncoder();
    }

    // authenticationManager 를 Bean 등록
    @Bean
    public AuthenticationManager authenticationManager(
            AuthenticationConfiguration authenticationConfiguration
    ) throws Exception {
        return authenticationConfiguration.getAuthenticationManager();
    }

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http.httpBasic(HttpBasicConfigurer::disable);
        http.csrf(AbstractHttpConfigurer::disable);
        http.sessionManagement(configurer -> configurer.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
            .authorizeHttpRequests(authorize-> authorize
                                                .requestMatchers(new AntPathRequestMatcher("/index")).permitAll()
                                                .requestMatchers(new AntPathRequestMatcher("/sign-up")).permitAll()
                                                .requestMatchers(new AntPathRequestMatcher("/sign-in")).permitAll()
                                                .requestMatchers(new AntPathRequestMatcher("/denied-page")).permitAll()
                                                .requestMatchers(new AntPathRequestMatcher("/v1/**")).permitAll()
                                                .requestMatchers(new AntPathRequestMatcher("/configuration/ui")).permitAll()
                                                .requestMatchers(new AntPathRequestMatcher("/configuration/security")).permitAll()
                                                .requestMatchers(new AntPathRequestMatcher("/webjars/**")).permitAll()
                                                .requestMatchers(new AntPathRequestMatcher("/static/**")).permitAll()
                                                .requestMatchers(new AntPathRequestMatcher("/ws-stomp/**")).permitAll()
                                                .anyRequest().authenticated())
            .addFilterBefore(new JwtAuthenticationFilter(jwtTokenProvider),
                                UsernamePasswordAuthenticationFilter.class)
            .logout(logout -> logout
                                .logoutUrl("/logout")
                                .logoutSuccessUrl("/index")
                                // 로그아웃 핸들러 추가 (세션 무효화 처리)
                                .addLogoutHandler((request, response, authentication) -> {
                                    HttpSession session = request.getSession();
                                    session.invalidate();
                                })
                                // 로그아웃 성공 핸들러 추가 (리다이렉션 처리)
                                .logoutSuccessHandler((request, response, authentication) ->
                                        response.sendRedirect("/index"))
                                .deleteCookies("JSESSIONID", "access_token"));

        return http.build();
    }
}

코드 톺아보기 - filterChain()

Spring Security 6.0.0 이후부터 WebSecurityConfigurerAdapter는 deprecated 되었기에 FilterChain의 역할을 하는 메서드를 직접 구현해 Bean으로 등록해 주어야 한다.

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {    
    http.httpBasic(HttpBasicConfigurer::disable);
    http.csrf(AbstractHttpConfigurer::disable);
    http.sessionManagement(configurer -> configurer.sessionCreationPolicy(SessionCreationPolicy.STATELESS))
         .authorizeHttpRequests(authorize-> authorize
                                .requestMatchers(new AntPathRequestMatcher("/index")).permitAll()
                                .requestMatchers(new AntPathRequestMatcher("/sign-up")).permitAll()
                                .requestMatchers(new AntPathRequestMatcher("/sign-in")).permitAll()
                                .requestMatchers(new AntPathRequestMatcher("/denied-page")).permitAll()
                                .requestMatchers(new AntPathRequestMatcher("/v1/**")).permitAll()
                                .requestMatchers(new AntPathRequestMatcher("/configuration/ui")).permitAll()
                                .requestMatchers(new AntPathRequestMatcher("/configuration/security")).permitAll()
                                .requestMatchers(new AntPathRequestMatcher("/webjars/**")).permitAll()
                                .requestMatchers(new AntPathRequestMatcher("/static/**")).permitAll()
                                .requestMatchers(new AntPathRequestMatcher("/ws-stomp/**")).permitAll()
                                .anyRequest().authenticated())
        .addFilterBefore(new JwtAuthenticationFilter(jwtTokenProvider),
                         UsernamePasswordAuthenticationFilter.class)
                         
	....
}

• http.httpBasic(HttpBasicConfigurer::disable) : JWT토큰을 사용하는 REST API 방식이기에 disable 처리
• http.csrf(AbstractHttpConfigurer::disable) : REST API 형식으로 JSON으로만 데이터를 주고 받는 Stateless한 통신방식을 사용하기에 csrf 설정이 불필요해 disable 처리
• http.sessionManagement() : 기존의 .sessionManagement().sessionCreationPolicy()가 deprecated된 후 개정된 코드이다.
• .authorizeHttpRequests() : 토큰 없이도 접근이 허용되는 url을 설정할 수 있고, 허용 설정을 하지 않은 url은 모든 인증단계를 거쳐야 접근할 수 있다.
• .addFilterBefore(filter A, filter B) : B 체인 전에 A 체인을 추가하는 역할의 메서드이다. 순서가 (JwtAuthenticationFilter(), UsernamePassword~.class) 이므로 UsernamePasswordAuthenticationFilter 전에 JwtTokenProvider를 실행한다. 즉, JwtFilter를 통과하면 UsernamePasswordAuthenticationFilter 이후의 필터는 통과한 것을 의미한다. 쉽게 말해 JWT를 통해 Username + Password 인증 수행을 의미한다. 

2-3. JwtAuthenticationFilter

• 이 클래스는 클라이언트 요청시 JWT 인증을 하기 위해 설치하는 커스텀 필터
• UsernamePasswordAuthenticationFilter 이전에 실행된다.

@RequiredArgsConstructor
public class JwtAuthenticationFilter extends GenericFilterBean {

    private final JwtTokenProvider jwtTokenProvider;

    @Override
    public void doFilter(ServletRequest request,
                         ServletResponse response,
                         FilterChain chain) throws IOException, ServletException {

        // 1. Request Header 에서 JWT 토큰 추출
        String token = jwtTokenProvider.resolveToken((HttpServletRequest) request);

        // 2. validateToken 으로 토큰 유효성 검사
        if (token != null && jwtTokenProvider.isValidateToken(token)) {
            Authentication authentication = jwtTokenProvider.getAuthentication(token);
            SecurityContextHolder.getContext().setAuthentication(authentication);
        }
        chain.doFilter(request, response);
    }
}

JwtTokenProvider의 resolveToken()으로 토큰을 추출한 뒤, 그 유효성을 isValidateToken()으로 확인한다. 모든 검사가 통과되면 다음단계로 넘어간다.

2-4. JwtTokenProvider

JWT 토큰을 발급하고, 추출하고, 유효한지 확인하는 클래스이다.

@Slf4j
@Component
public class JwtTokenProvider {

    @Value("${jwt.secret}")
    private String secretKey;
    private final static long TOKEN_VALID_TIME = 30 * 60 * 1000L; // 토큰 유효시간 30분
    private UserDetailsService userDetailsService;

    public JwtTokenProvider(@Lazy UserDetailsService userDetailsService) {
        this.userDetailsService = userDetailsService;
    }

    // 객체 초기화, secretKey 를 Base64로 인코딩
    @PostConstruct
    protected void init() {
        secretKey = Base64.getEncoder().encodeToString(secretKey.getBytes());
    }

    // JWT 토큰 생성
    public TokenResponseDto createToken(String email, List<String> roles) {
        Claims claims = Jwts.claims().setSubject(email);
        claims.put("roles", roles); // 정보 저장 (key-value)
        Date now = new Date();
        return new TokenResponseDto(Jwts.builder()
                .setClaims(claims)
                .setIssuedAt(now)
                .setExpiration(new Date(now.getTime() + TOKEN_VALID_TIME)) // set Expire Time
                .signWith(SignatureAlgorithm.HS256, secretKey) // 사용할 암호화 알고리즘과 signature에 들어갈 secret 값 세팅
                .compact());
    }

    // JWT 토큰에서 인증 정보 조회
    public Authentication getAuthentication(String token) {
        UserDetails userDetails =
                userDetailsService.loadUserByUsername(this.getUserEmail(token));
        return new UsernamePasswordAuthenticationToken(
                userDetails,
                "",
                userDetails.getAuthorities()
        );
    }

    // 토큰에서 회원 정보 추출
    public String getUserEmail(String token) {
        return Jwts.parser()
                .setSigningKey(secretKey)
                .parseClaimsJws(token)
                .getBody()
                .getSubject();
    }

    public String resolveToken(HttpServletRequest request) {
        String cookie = request.getHeader("Cookie");
        if (cookie != null) {
            String bearerToken = cookie.split("access_token=")[1];
            if (StringUtils.hasText(bearerToken)) {
                return bearerToken;
            }
        }

        return null;
    }

    // 토큰의 유효성 + 만료일자 확인
    public boolean isValidateToken(String jwtToken) {
        try {
            Jws<Claims> claims = Jwts.parser().
                            setSigningKey(secretKey).
                            parseClaimsJws(jwtToken);
            return !claims.getBody().getExpiration().before(new Date());
        } catch (Exception e) {
            return false;
        }
    }
}

코드 톺아보기

@Value("${jwt.secret}")

jwt:
  secret: 비밀키

secretKey는 JWt의 signature 부분을 암호화할 개인 시크릿키를 설정해주는 값이다. 값이 비밀로 유지되어야 하므로 yml파일에 jwt.secret이라는 이름으로 .gitignore 처리해서 저장해서 사용하면 된다. 그 후 @Value("${jwt.secret}")으로 런타임에 키를 가져와 사용할 수 있게 하면된다.

createToken()

JWT 토큰을 생성하기 위한 메서드로, AuthService에서 로그인하는 함수인 signIn()에서 사용된다.

// JWT 토큰 생성
public TokenResponseDto createToken(String email, List<String> roles) {
     Claims claims = Jwts.claims().setSubject(email);
     claims.put("roles", roles); // 정보 저장 (key-value)
     Date now = new Date();
     return new TokenResponseDto(Jwts.builder()
                .setClaims(claims)
                .setIssuedAt(now)
                .setExpiration(new Date(now.getTime() + TOKEN_VALID_TIME)) // set Expire Time
                .signWith(SignatureAlgorithm.HS256, secretKey) // 사용할 암호화 알고리즘과 signature에 들어갈 secret 값 세팅
                .compact());
}

• setSubject() : JWT의 목적 같은 내용 추가
• setClaim : JWT 토큰의 payload에 들어갈 내용으로, key-value 형태로 저장
• signWith : JWT토큰의 signature를 의미하며, HS256으로 인코딩하고 secretkey를 이용한다는 것을 의미한다

getAuthentication()

// JWT 토큰에서 인증 정보 조회
public Authentication getAuthentication(String token) {
    UserDetails userDetails =
        userDetailsService.loadUserByUsername(this.getUserEmail(token));
        
        return new UsernamePasswordAuthenticationToken(
                userDetails,
                "",
                userDetails.getAuthorities()
        );
    }

• UserDetailsService.loadUserbyUsername(this.getUserEmail(token)) : 토큰으로 사용자 이메일을 추출한 뒤 사용자 정보를 가져온다
• 인증용 객체인 UsernamePasswordAuthenticationToken을 반환한다(시큐리티 동작 과정중 (2)에 해당하는 내용)

getUserEmail()

매개변수로 입력된 token을 파싱해서 회원정보를 반환하는 함수이다.

// 토큰에서 회원 정보 추출
public String getUserEmail(String token) {
    return Jwts.parser()
                .setSigningKey(secretKey)
                .parseClaimsJws(token)
                .getBody()
                .getSubject();
}

resolveToken()

HTTP request 헤더 Cookie에 있는 access token을 추출하는 메서드이다. 내가 구현한 애플리케이션에는 헤더 쿠키에 'access_token= ~'형태로 access token이 있기에 'access_token='으로 split한 문자열에서 쿠키를 가져온 뒤 bearerToken이 있다면 토큰을 반환하는 방식으로 구현했다.

public String resolveToken(HttpServletRequest request) {
    String cookie = request.getHeader("Cookie");
    if (cookie != null) {
        String bearerToken = cookie.split("access_token=")[1];
        if (StringUtils.hasText(bearerToken)) {
           return bearerToken;
        }
    }
        return null;
    }

isValidateToken()

유효한 토큰인지, 토큰이 만료되지 않았는지 확인하는 함수이다. boolean 값을 반환하므로 메서드명을 is~()형태로 명명했다.

(보니까 유효성에 대한 코드는 없는 것 같은데, 유효한지는 어떻게 확인하지?)

// 토큰의 유효성 + 만료일자 확인
public boolean isValidateToken(String jwtToken) {
     try {
        Jws<Claims> claims = Jwts.parser().
                            setSigningKey(secretKey).
                            parseClaimsJws(jwtToken);
            return !claims.getBody().getExpiration().before(new Date()); // 만료일자 확인
    } catch (Exception e) {
            return false;
}

2-5. CustomUserDetailsService

UserDetailsService 인터페이스를 구현한 커스텀 서비스이고, JwtTokenProvider 클래스의 getAuthentication()메서드 내부에서 사용하는 클래스이다. 여기에서는 http 요청으로 넘어온 사용자 정보가 서버에 존재하는 사용자인지 확인하고 다음과 같은 결과를 반환한다. 

• 성공 시 UserDetails 타입의 객체를 반환
• 실패 시 UsernameNotFoundException을 반환

@Service
@RequiredArgsConstructor
public class CustomUserDetailsService implements UserDetailsService {

    private final MemberRepository memberRepository;

    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        return memberRepository
                .findByEmail(username)
                .map(this::createUserDetails)
                .orElseThrow(() -> new UsernameNotFoundException("해당하는 회원을 찾을 수 없습니다."));
    }

    // 해당하는 Member 의 데이터가 존재한다면 User 객체로 만들어서 리턴
    private UserDetails createUserDetails(Member member) {
        return new SecurityUser(member);
    }
}

loadUserByUsername 내부를 보면 memberRepository에서 이메일로 사용자를 찾고, 그 결과를 SecurityUser로 매핑해서 반환하는 것을 볼 수 있다(람다와 스트림을 사용했다). 만약 사용자가 존재하지 않는다면 예외를 throw 한다.

2-6. SecurityUser

위 커스텀 서비스의 createUserDetails() 메서드에서 반환하는 타입으로, 시큐리티의 User를 상속받고 있다. 매개변수로 넘어온 Member 객체의 정보로 User 생성자를 호출해 User 객체를 생성한다.

@Getter
public class SecurityUser extends User {

    private Member member;

    public SecurityUser(Member member) {
        super(member.getEmail(), member.getPassword(),
                AuthorityUtils.createAuthorityList(member.getRole().toString()));
        this.member = member;
    }
}

참고

• https://thalals.tistory.com/436
• https://velog.io/@hope0206/Spring-Security-%EA%B5%AC%EC%A1%B0-%ED%9D%90%EB%A6%84-%EA%B7%B8%EB%A6%AC%EA%B3%A0-%EC%97%AD%ED%95%A0-%EC%95%8C%EC%95%84%EB%B3%B4%EA%B8%B0

서비스 계층의 순수함을 유지하기 위한 과정을 지나왔다. 서비스 계층은 어느정도 순수함을 유지하게 되었으니, 이제는 리포지토리에서 JDBC에서 발생하는 코드 반복 문제를 해결해보자.

JDBC 코드 반복 문제

반복되는 JDBC 코드는 다음과 같다.

• 커넥션 관련 - 조회, 동기화
• PreparedStatement 생성 및 파라미터 바인딩
• 쿼리 실행
• 결과 바인딩
• 예외 발생시 스프링 예외 변환기 실행
• 리소스 종료

템플릿 콜백 패턴

이토록 같은 처리 과정이 중복되는 것을 확인할 수 있다. 이런 반복을 효과적으로 처리할 수 있는 방법이 바로 템플릿 콜백 패턴이다.

스프링은 JDBC의 반복 문제를 해결하기 위해 JDBCTemplate 이라는 템플릿을 제공한다. JDBCTemplate을 사용하면 다음과 같이 코드가 많이 줄어드는 것을 확인할 수 있다.

• 회원 저장 함수

@Override
public Member save(Member member) {
    String sql = "insert into member(member_id, money) values(?, ?)";
    template.update(sql, member.getMemberId(), member.getMoney());
    return member;
}

원래는 커넥션 관련, 구문, 쿼리 실행, 결과 바인딩 등 몇 십줄의 코드가 있었는데 JDBCTemplate을 적용하니 template.update()처럼 JDBCTemplate 인스턴스에 함수 하나마 호출하면 위 과정을 한번에 처리할 수 있다.

• 회원 정보 조회 함수
  • 조회 로직도 저장 로직과 비슷한데 RowMapper라는 게 달라서 기록한다.
  • 쿼리 결과를 바인딩할 때 사용하는 것 같다.

@Override
public void update(String memberId, int money) {
    String sql = "update member set money=? where member_id=?";
    template.update(sql, money, memberId);
}

private RowMapper<Member> memberRowMapper() {
    return (rs, rowNum) -> {
        Member member = new Member();
        member.setMemberId(rs.getString("member_id"));
        member.setMoney(rs.getInt("money"));

        return member;
    }; 
}

정리

JDBCTemplate을 활용해 JDBC로 개발시 발생하는 반복 문제를 대부분 해결해준다. 뿐만 아니라 트랜잭션을 위한 동기화, 예외 발생시 스프링 예외 변환기도 자동으로 실행해준다. 참 편리해졌다!

최종 정리

• 서비스 계층의 순수성
  • 트랜잭션 추상화 + 트랜잭션 AOP 덕분에 서비스 계층의 순수성을 최대한 유지하면서 서비스 계층에서 트랜잭션을 사용할 수 있다.
  • 스프링이 제공하는 예외 추상화와 예외 변환기 덕분에, 데이터 접근 기술이 변경되어도 서비스 계층의 순수성을 유지하면서 예외도 사용할 수 있다.
  • 서비스 계층이 리포지토리 인터페이스에 의존한 덕분에 향후 리포지토리가 다른 구현 기술로 변경되어도 서비스 계층을 순수하게 유지할 수 있다.
• 리포지토리에서 JDBC를 사용하는 반복 코드가 JdbcTemplate 으로 대부분 제거되었다.

데이터 소스, 트랜잭션, 자바 예외, 스프링 예외 등 나름 알고 있다고 생각했었는데, 이 강의를 들으면서 내 기본기가 많이 약하다는 것을 알게 되었다.

기본기부터 찬찬히 원리를 이해하며 공부할 수 있어서 유익했다!

Reference

인프런 김영한 - '스프링 DB 1편 - 데이터 접근 핵심 원리'

체크 예외와 인터페이스

서비스 계층은 가급적 특정 구현 기술에 의존하지 않고, 순수하게 유지하는 것이 좋다. 이렇게 하려면 예외에 대한 의존도 함께 해결해야한다.

그렇다면 서비스가 처리할 수 없는 SQLException에 대한 의존은 어떻게 제거할 수 있을까?

이는 리포지토리에서 SQLException 체크 예외를 런타임 예외로 전환해서 서비스 계층에 던지면 된다.

스프링 예외 추상화 이해

런타임 예외 변환으로 체크 예외에 의존하는 것은 해결했지만, 각 예외상황마다 오류 코드가 다른 경우가 있다. 예를 들어 키 중복 오류 코드는 H2의 경우 23505, MySQL의 경우 1062인 것 처럼 말이다. 문제는 이 오류코드가 하나의 데이터베이스에도 수백개인데 또 데이터베이스 별로 다 다르다는 것이다.

만약 각 오류 코드 별로 분기문을 만들어 진행한다면 코드 양이 방대해지고, DB를 바꾸게 되면 전체 코드를 바꿔야 할 수도 있다.

이 문제를 스프링은 데이터 접근과 관련된 예외를 추상화해서 해결해준다. 계층 구조는 다음과 같다.

• 스프링은 데이터 접근 계층에 대한 수십 가지 예외를 정리해서 일관된 예외 계층을 제공한다.
• 각 예외는 특정 기술에 종속적이지 않게 설계되어 있다. 따라서 서비스 계층에서도 스프링이 제공하는 예외를 사용하면 된다.
• 가장 상위에는 DataAccessException 예외가 있다. 이는 런타임 예외를 상속 받았기에 모두 런타임 예외이다.
• DataAccessException
  • 이는 NonTransient, Transient 예외로 구분된다.
  • Transient는 일시적이라는 뜻으로, Transient 하위 예외는 동일한 SQL을 다시 시도했을 때 성공할 가능성이 있다.
    • 예를 들어 쿼리 타임아웃, 락과 관련된 오류들이 있다. 이런 오류들은 데이터베이스 상태가 좋아지거나, 락이 풀렸을 때 다시 시도하면 성공할 수도 있다.
  • NonTransient는 일시적이지 않다는 뜻이다. 같은 SQL을 그대로 반복해서 실행하면 실패한다.
    • SQL 문법 오류, 데이터베이사 제약조건 위배 등이 있다.

스프링이 제공하는 예외 변환기

스프링은 데이터베이스에서 발생하는 오류 코드를 스프링이 정의한 예외로 자동으로 변환해주는 변환기를 제공한다. 구체적인 코드는 다음과 같다.

SQLExceptionTranslator exTranslator = 
    new SQLErrorCodeSQLExceptionTranslator(dataSource);
DataAccessException resultEx = exTranslator.translate("select", sql, e);

• translate(a, b, c) : a는 읽을 수 있는 설명이고, b는 실행한 sql, c는 발생된 Exception을 전달하면 된다. 이렇게 하면 적절한 스프링 데이터 접근 계층의 예외로 변환해서 반환해준다.
• 이렇게 하면 일일이 if (e.getErrorCode().equals(40122)) 처럼 코드별로 분기문으로 나눠 오류코드를 처리하지 않아도 된다.

그렇다면 스프링에서는 어떻게 이 코드들을 인식하고 처리하는 걸까? 비밀은 다음 파일에 있다.

// sql-error-codes.xml 파일
<bean id="H2" class="org.springframework.jdbc.support.SQLErrorCodes">
     <property name="badSqlGrammarCodes">
         <value>42000,42001,42101,42102,42111,42112,42121,42122,42132</value>
     </property>
     <property name="duplicateKeyCodes">
         <value>23001,23505</value>
     </property>
 </bean>
 <bean id="MySQL" class="org.springframework.jdbc.support.SQLErrorCodes">
     <property name="badSqlGrammarCodes">
         <value>1054,1064,1146</value>
     </property>
     <property name="duplicateKeyCodes">
         <value>1062</value>
     </property>
 </bean>

• 각 코드 별로 에러명이 분류되어 있는 것을 확인할 수 있다.

정리

스프링이 예외를 추상화 해준 덕분에, 서비스 계층은 특정 리포지토리의 구현 기술과 예외에 종속적이지 않게 되었다. 따라서 서비스 계층은 특정 구현 기술이 변경되어도 그대로 유지할 수 있게 되었다. 다시 DI를 제대로 적용할 수 있게 된 것이다.

추가로 서비스 계층에서 예외를 catch해서 복구해야 하는 경우, 예외가 스프링이 제공하는 데이터 접근 예외로 변경되어서 서비스 계층에 넘어오기 때문에, 필요한 경우 예외를 잡아서 복구하면 된다.

Reference

인프런 김영한 - '스프링 DB 1편 - 데이터 접근 핵심 원리'