redis는 인메모리 저장소로 NO-SQL방식의 저장소이다. 접근 속도가 빠르고 key-value로 이뤄진 Map형태를 가지고 있기 때문에 탐색이 용이하여 데이터 관리가 편하다는 장점이 있다.

Redis를 이용한 보안관리

기존에 LocalStroge에서 JWT토큰을 관리하게 되면 로그인을 한 사용자 스토리지를 확인하면 JWT를 그대로 알 수 있다는 보안상 문제가 존재한다.

Access토큰은 외부로 유출되어도 유지시간이 짧기 때문에 보안상 크게 문제가 되지 않지만, 문제는 Refresh 토큰이다.

리프레시 토큰이 탈취당하게 되면 Access토큰을 무한으로 생성할 수 있기 때문에 보안상의 큰 위협이 된다.

이런 형태로 작동하는데 중간에서 탈취당하게 되면 보안상 막을 수 없어진다.

따라서 Accesstoken은 그대로 사용하되 Refresh 토큰은 Redis를 이용한 토큰 저장소에 저장하고 id를 외부로 노출시키는 방법을 사용하면 외부로의 토큰 유출을 막을 수 있다.

이런 인증 절차를 거치게 해서 보안을 강화할 수 있다.

Redis 저장소와 로그아웃

Redis를 사용하면 로그아웃 기능도 구현할 수 있게 된다.

기본적으로 서버에서 로그아웃을 하면 스토리지에 있는 토큰 정보는 지워지게 된다. 하지만 Refresh Token이 탈취된 상태로 지워지게 되면 헤더에 토큰 정보를 담아 로그인 시도를 할 수 있게 된다.

그래서 ID를 저장한 Redis저장소의 토큰을 기한 만료 시키거나 삭제해준다면 Refresh토큰을 이용한 로그인 시도를 방지할 수 있다.

SpringSecurity에서 제공하는 보안 기능은 기본적으로 세션의 형태로 작동하게 된다. 또한 기본 로그인 폼과 기초 인증, 인가를 제공하기 때문에 보안적으로 사용자가 신경써야할 점을 많이 대신해주게 된다.

하지만 JWT토큰 인증 방식을 사용하기 위해선 Stateless상태로 구성해야하기 때문에 파이프라인을 조금 손봐야 한다.

이번에는 파이프라인에 JWT인증을 추가하는 방법과 구성시 세팅을 알아보도록한다.

기본적인 SpringSecurity pipeline

위 사진의 형태로 파이프라인이 제공되게 된다.

잘 보면 UsernamePasswordAuthentiactionFilter이라는 객체가 있는데, 이 객체가 인증, 인가요청을 담당하게 된다. 인증을 하고 그 정보를 SecurityContextHolder라는 요청을 저장하는 공간에 담아 인가요청을 처리하게 된다.

코드로 보면 아래와 같다.

UsernamePasswordAuthenticationToken usernamePasswordAuthenticationToken =
                            new UsernamePasswordAuthenticationToken(
                                    userDetails,
                                    null,
                                    userDetails.getAuthorities()
                            );
                    log.info("■ 접근 토큰 생성 완료");
                    //접근 토큰 활성화
                    SecurityContextHolder.getContext().setAuthentication(usernamePasswordAuthenticationToken);
                    log.info("■ 접근 토큰 활성화: "+usernamePasswordAuthenticationToken.getAuthorities());

사용하는 코드의 일부를 가져왔는데, SecurityContextHoler에 setAuthentication메서드를 통해 등록해야하는 UsernamePasswordAuthenticationToken을 등록해 유저가 파이프 라인을 지나갈 수 있는 통행증을 만든다.

이후 session을 통해 관리하게 되고 세션이 유지되면 인증, 인가 요청이 들어올 때 마다 파이프라인을 통과시키게 된다.

JWT 토큰을 이용한 파이프라인 설정

JWT토큰을 이용하게 되면 아래와 같은 기능이 필요가 없어진다.

• ContextHolder을 이용한 세션유지 처리
• 기본적인 로그인 폼

세션유지는 stateless 형태로 작용하기 때문에 그런 것이고 로그인 폼은 기본적인 로그인 폼을 사용하면 파이프라인에 들어올때 Serucrityfilter가 먼저 들어오게 되는데 아래에 나올 내용이지만 이렇게하면 JWT인증 요청이 두번 발생할 수 있다.

JWT인증 요청 구조는 아래와같다.

이런 형식으로 필터를 구성하게 되면 Spring Security에 들어오기 전에 jwt인증 요청을 해서 원하는 로직으로 JWT토큰을 발급할 수 있다.

오류 : JWT인증 요청이 두번 발생함.

파이프라인을 구성할 때 아래와 같이 JWT필터를 넣어주었다.

http.addFilterBefore(new jwtRequestFilter(jwtBuilder,userDetailsService), UsernamePasswordAuthenticationFilter.class);

jwtRequsetFilter라는 jwt인증요청을 처리하는 필터를 만들어서 UsernamePasswordAuthentication필터 앞에 넣도록 하였다. 저게 바로 Springboot Security에서 진입점에 해당하는 필터이다.

근데 이렇게 하면 문제가 발생한다. 인증이 두번 요청이 되서 처리는 제대로 되는데 로그를 보면 JWT토큰을 두번 인증하게 된다.

문제점은 new로 새로운 의존성을 주입해 객체를만들게 되는데 JWT인증 구조를 보면 아래와 같은 클래스를 상속하고 있는 것을 볼 수 있다.

@Component
@RequiredArgsConstructor
@Slf4j
public class JwtRequestFilter extends OncePerRequestFilter

OncePerRequestFilter 클래스는 해당 필터가 반드시 한번만 동작하도록 보장하는 필터이다.

그럼 두번 동작을 하면 안되는데, 왜 두번 인증을 요청할까? 그건 SpringBoot Bean등록 방식을 봐야한다.

SpringBoot에서 빈을 등록할 때 우리는 어노테이션을 이용해서 Service,Contorller등의 빈을 등록한다. 이 과정은 컴파일 시간에서 이뤄지고 같은 빈은 등록되면 오류가 나기 때문에 반드시 하나의 빈만 등록된다. 하지만 security를 사용하게 되면 Security내부적으로 빈을 등록하는 절차를 거치게 된다.

여기서 문제가 발생한다. Spring에서 등록한 JWT필터 빈을 Seucrity에서 new로 새로운 필터를 넣었기 때문에 Spring에서 빈을 등록하고 Security에서 빈을 또 등록해서 이중 인증이 되는 것이다. 원래는 같은 빈은 등록이 되지 않지만 Security에서 등록하기 때문에 컴파일 단계에서 걸러지지 않는것 같다.

해결 방법은 간단하다 코드를

@RequiredArgsConstructor
@Slf4j
public class JwtRequestFilter extends OncePerRequestFilter

이렇게 수정하면 Spring에서 빈등록을 하지 않게 된다. JwtRequest필터는 Security에서만 사용하기 때문에 등록되지 않은 빈을 사용하는 오류가 날 위험도 없다.

따라서 중복문제를 해결할 수 있다. 그리고 새로운 객체를 new를 이용해서 만들고 필터에 넣으면 코드를 보기 힘들 수 있기 때문에

http.addFilterBefore(jwtRequestFilter(jwtBuilder,userDetailsService), UsernamePasswordAuthenticationFilter.class);

이런식으로 생성자를 주입한 클래스를 위에서 적용하고 필터 순서를 정할 때 주입된 클래스를 활용하는 것이 안전할 듯 하다.

로그인을 하면 JWT토큰을 발행해서 헤더에 담아서 반환하는 것을 구현하였다.

Controller

private final signinService service;
    private final JwtBuilder jwtBuilder;
    @PostMapping
    public ResponseEntity<ResponseJson<Object>> signin(
            @RequestBody RequestSignincheckDto signincheckDto,
            HttpServletResponse res
            ){
        String jwtToken = null;
        ResponseSignincheckDto response = service.loginCheck(signincheckDto);
        if(response.getState().value){
            jwtToken = jwtBuilder.generateAccessToken(response.getName());
            res.setHeader("Content-Type", "application/json");
            res.setHeader("Authorization", "Bearer " + jwtToken);
        }
        return ResponseEntity.ok(
                ResponseJson.builder()
                        .status(200)
                        .message("JWT")
                        .result(res.getHeader("Authorization"))
                        .build()
        );
    }

Dto는 아이디와 비밀번호를 받는 것과, 로그인이 완료되면 반환받는 객체 두개로 나누었다.

여기서 HttpServletResponse라는게 나오는데 웹에서 우리가 어떤 요청을 받고 그걸 반환할 때 웹에 있는 헤더 혹은 바디에 반환할 수 있게 해주는 것이다. 여기서는 JWT토큰을 헤더에 담아 반환하기 위해서 사용되었다.

로그인 체크를 이용해 만약 정상적인 유저임이 판단되면 JWT토큰을 생성해서 헤더에 넣어준다. 그리고 헤더에 넣은 값을 확인을 위해 Json으로 반환하도록하였다.

Service

 private final authRepository repo;

    @Description("로그인 check")
    public ResponseSignincheckDto loginCheck(RequestSignincheckDto dto) {
        String id = dto.getId();
        String pw = dto.getPw();
        SignUp valid = repo.findByEmailID(id);
        if(valid!=null){
            if(valid.getPassword().equals(pw)){
                return ResponseSignincheckDto.builder()
                        .state(State.OK)
                        .name(valid.getUserName())
                        .build();
            }
        }
        return ResponseSignincheckDto.builder()
                .state(State.NULL)
                .build();
    }

Service이다. 로그인 채크 기능을 넣어서 authReposiroty Jpa로 탐색을 해서 있는 아이디라면 로그인이 가능하도록 하였다. State를 넣어서 반환하게 하는데, State는 단순히 불린 값으로 해도 상관없지만 보는 사람의 가독성을 위해서 Enum을 하나 정의해서 OK, Null등의 값을 지정하였다. 그리고 그 값을 불린 값으로 value받을 수 있도록 하여 컨트롤러에서 처리하도록 하였다.

Repository

public interface authRepository extends JpaRepository<SignUp,Long> {
    SignUp findByEmailID(String id);
}

이전에 한번 썼던 리포지토리인데, Jpa에서 제공하는 메서드형 쿼리는 findBy~라고 시작하는 것 뒤에 칼럼을 적으면 대상을 탐색해 준다. 따라서 아이디를 탐색할 수 있도록 만든 것이다.

JWT

@Component
public interface JwtBuilder {
    String generateJWT(String name,Long exptime);
    String generateAccessToken(String name);
    String generateRefreshToken(String name);
    JwtCode validateToken(String token);
}

컨트롤러에서 사용하는 JWT빌더의 인터페이스이다. @Component를 이용해서 스프링 빈에 등록될 수 있도록 하였고, 사용할 메서드를 등록해주었다.

@Component
public class JwtBuilderImpl implements JwtBuilder {
    @Value("${jwt.secret.key}")
    private String SecretKey; //키값임.
    private static final Long AccessTokenExpTime = 1000*60L*3L;
    private static final Long RefreshTokenExpTime = 60L * 1000 * 60L;
    public String generateJWT(String name,Long exptime){
        Map<String,Object> header = new HashMap<>();
        header.put("typ", "JWT"); //토큰 헤더 설정

        Date ext = new Date();
        ext.setTime(ext.getTime()+exptime); //유효시간 설정

        Map<String,Object> payload = new HashMap<>();
        payload.put("user_name",name);//토큰 페이로드설정

        String jwt = Jwts.builder()
                .setHeader(header)
                .setClaims(payload)
                .setSubject("test")
                .setExpiration(ext)
                .signWith(SignatureAlgorithm.HS256,SecretKey.getBytes())
                .compact();
        return jwt;
    }

재정의한 Impl이다. 키값을 정하는 SecretKey는 Value어노테이션으로 application.properies에 jwt.secret.key 이런 식으로 정의한 것을 가져올 수 있게 하였다. 토큰은 유지시간이 있어야 보안적으로 안정적이기 때문에 어세스, 리프레시 토큰의 유지시간을 설정해 주었다. 그리고 헤더, 페이로드 등을 설정한 후에 jwts의 빌더를 통해 등록해주고 마지막에 signWith에 등록한 키와 알고리즘을 넣어주면 토큰 값을 얻을 수 있다.

public String generateAccessToken(String name){
        return generateJWT(name,AccessTokenExpTime);
    }
    public String generateRefreshToken(String name){
        return generateJWT(name,RefreshTokenExpTime);
    }

실제로 사용할 토큰 발급 메서드이다. AccessToken과 RefreshToken을 구분해서 생성해야 하기 때문에 이렇게 메서드를 나눠서 발급 시간을 조정하였다.

    public JwtCode validateToken(String token) {
        if (token == null || token.trim().isEmpty()) {
            return JwtCode.DENIED; // 토큰이 유효하지 않음
        }
        try {
            Jwts.parserBuilder().setSigningKey(SecretKey).build().parseClaimsJws(token);
            return JwtCode.ACCESS;
        } catch (ExpiredJwtException e) { // 기한 만료
            return JwtCode.EXPIRED;
        } catch (Exception e) {
            return JwtCode.DENIED;
        }

토큰을 검증하는 메서드이다. 나중에 어떤 페이지에 접근하건 헤더에 있는 토큰을 검증해서 사용해야할텐데 그 검증을 도와주는 메서드이다.

이제 이걸HTTP에 날려서 확인해보면

이렇게 POST요청을 날려주면

이런 식으로 요청이 반환 되는 것을 볼 수 있다. 이걸 https://jwt.io 사이트에서 디코딩을 해볼 수 있는데,

이런 결과를 얻을 수 있다. 헤더와 페이로드는 알 수 있지만 가장 중요한 사인은 디코딩을 해도 알 수 없는 모습이다. 이렇게 페이지 보안을 강화할 수 있다.

먼저 이 오류는 잘 되다가 갑자기 발생했었다. git으로 여러 컴퓨터와 연결해서 사용하고 있었는데, Test파일을 수정한 후에 push를 하고 다른 컴퓨터에 가서 patch를 하니까 오류가 발생했다.

총 4가지의 오류가 발생했는데 다 비슷한 문구를 가지고 있었다. Error: Could not find or load main class worker.org.gradle.process.internal.worker.GradleWorkerMain 이건 뭘까 해서 Gpt한테 물어봤더니

1. 플러그인 버전 확인
2. Spring 플러그인 저장소 추가
3. Gradle 캐시 정리 및 다시 다운로드
4. Gradle 버전 확인
5. Gradle Wrapper 사용

이런 해결책을 내놓았다. 해서 다 해봤는데 당연히 안됬고 회사에 가서 사수님께 물어봤더니 경로 확인을 해보라고 하셨다. 문제는 거기에 있었는데

이렇게 프로젝트 경로가 영어로 되어있어야 하는데, 어느 곳이던 한글 경로가 들어가 있으면 오류가 발생하였다. 한글을 바꿔주니까 잘 작동하였다.

추가로 이런 오류의 대부분은 그래들 문제가 아니고 파일 설정에 관한 문제라고 한다.

가입하는 방식은 아이디와 비밀번호, 사용자 이름을 입력하면 사용자 이름을 반환하도록 하였다. DB에서 PK가 사용자 이름으로 되어있기 때문에 중복된 사용자는 가입을 해도 DB가 변하지 않는다, 나중에 추가적으로 오류를 발생시키는 코드를 넣고 이번에는 그냥 가입만 진행할 수 있도록 한다.

Controller

@Description("회원가입")
    @PostMapping("/api/sign-up")
    public ResponseEntity<ResponseJson<Object>> signUp(@RequestBody RequestSignupPostDto requestSignupPostDto){
        ResponseSavedNameDto response = service.signup(requestSignupPostDto);

        return ResponseEntity.ok(
                ResponseJson.builder()
                        .status(200)
                        .message("OK")
                        .result(response)
                        .build()
        );
    }

회원가입을 진행하기 위해 사용할 컨트롤러이다. RequsetSignupPostDto는 사용자에게 요청을 하기 위한 필드이다. Dto안에 있는 필드로 요청을 받을 수 있게 된다. ResponseSvedNameDto는 가입한 사용자 이름을 반환하기 위한 Dto이다. Dto의 목적은 반환하는 것와 요청하는 Dto를 다르게 해야 그 의미가 있는것이라. (한가지 역할만 해야한다) Request요청을 처리하는 것과 Response요청을 처리하는 것은 나눠야 한다.

그렇게 받은 데이터를 Json의 형태로 만들어 보내기 위해 ResponseJson이라는 것을 만들어 보내도록 하였다.

DTO

public class RequestSignupPostDto {
    private String email;
    private String password;
    private String userName;
}

public class ResponseSavedNameDto {

    private String userName;
}
public class ResponseJson<T> {
    Integer status;
    String message;
    T result;

    @JsonIgnore
    Object trace;
    @JsonIgnore
    Object path;
}

Json은 Dto는 아닌데 일단 그냥 넣어놨다. Dto는 반드시 받을 데이터의 필드만 존재해야 하기 떄문에 타입과 필드명만 지정해주고 나머지는 쓰지 않아야 한다. Dto,Dao,VO의 구분을 확실히 해야한다.

Service

public class signupService {

    private final authRepository signInRepo;

    @Description("회원 가입")
    public ResponseSavedNameDto signup(RequestSignupPostDto request) {
        SignUp signUp = SignUp.builder()
                .emailID(request.getEmail())
                .password(request.getPassword())
                .userName(request.getUserName())
                .build();
        SignUp savedSignUp = signInRepo.save(signUp);
        return ResponseSavedNameDto.builder()
                .userName(savedSignUp.getUserName())
                .build();
    }
}

위 코드에서는 좀 빠진부분이 있는데 service라고 정의된 부분이다. Sevice단에서는 엔티티를 이용해서 DB에 커넥션하고 데이터를 수정하는 역할을 한다. 요청으로 받은 RequsetDto를 SignUp엔티티에 적용해서 DB에 적용시킨다. DB에 적용하는 것은 JPA를 이용하였다. 그리고 반환된 이름을 다시 ResponseDto에 넣어서 컨트롤러로 반환해준다.

Entity

@Entity
@Getter
@Builder
@AllArgsConstructor
@NoArgsConstructor
public class SignUp {
    @Id
    @Column(length = 20)
    private String emailID;

    @Column(length = 10)
    private String password;

    @Column(length = 10)
    private String userName;

    @CreatedDate
    private LocalDateTime signInDate;


}

엔티티이다. 엔티티는 반드시 DB와 일치하는 컬럼을 가지고 있어야 한다. 따라서 수정 또한 자유롭게 두면 안된다. 그래서 위에 어노테이션 설정한 것을 보면 Setter가 없다는 것을 알 수 있다. 빌더를 통하지 않고 Setter로 하게되면 잘못된 데이터를 넣을 가능성이 있기 때문에 수정을 제한하는 것이다.

Repository

public interface authRepository extends JpaRepository<SignUp,Long> {
    SignUp findByEmailID(String id);
}

리포지토리이다. JPA를 이용하고 있으며 JPA에 대한 것은 다른 포스트에 정리했기 때문에 넘어가겠다. 각 엔티티로 반환하는 메서드쿼리를 날리면 그에 따른 응답을 받을 수 있다.

물론 저 findByEmailID를 여기서는 사용하지 않았다 그냥 필요해서 나중에 쓸라고 추가한 것이고

SignUp savedSignUp = signInRepo.save(signUp);`

이게 회원가입을 할때 Save를 할 수 있는 기능이다. 엔티티에 정보를 담고 그걸 다시 저장된 엔티티로 반환하는 개념이다.

HTTP

인텔리제이에서는 HTTP를 날려볼 수 있는 기능을 지원한다.

PostMapping을 눌러보면 이렇게 HTTP요청을 날릴 수 있는 것이 나온다. 그럼 이런식으로 POST요청을 날릴 수 있는 기능을 지원하고 HTTP의 메서드는 다 해볼 수 있다.

이 요청을 날려보면

이렇게 정상적으로 요청이 처리된 것을 볼 수 있다.

DB에서 확인해보면

정상적으로 DB에도 들어온 것을 확인할 수 있다.

웹에서 프론트엔드와 벡엔드를 나눠서 개발하기 전에 필수적으로 알아야할 개념이라고 생각해서 정리한다.

API(Application Programming Interface)

애플리케이션간의 통신 방법을 정의하는 것을 의미한다. 주로 요청과 응답으로 이루어져 있으며, 클라이언트와 서버 관계에서 웹 API또는 RestAPI로 많이 사용된다.

예전에는 템플릿 언어로 구성된 화면에서 파라미터를 통해 화면으로 보내는 View방식을 사용했지만 요즘은 벡단과 프론트단으로 나눠서 하기 때문에, 프론트단에서 백단으로 데이터를 Requset하고 백단에서는 요청받은 데이터를 가공해서 프론트단으로 Response해야한다.

이때 서로 규칙을 정해야하는데, 이게 바로 API이다.

이런 방식으로 웹이 통신하게 된다.

UI

사용자가 브라우저에서 접하는 화면이다. 사용자의 행위에 의해 이벤트가 발생하고, 서버로 요청이 들어간다. 전통적인 방식은 HTML을 요청해서 화면을 구성하지만 SPA(Vue, Angular, React)는 클라이언트에서 렌더링하고 API를 호출하게 된다.

웹애플리케이션

HTML,Css,JAVAScript등이 여기에 속한다. 서버 렌더링인 경우 JSP를 이용해서 REST API를 호출하고 벡엔드로부터 전달받은 JSON데이터로 구성한다. 클라이언트 렌더링에서는 웹애플리케이션 서버 내부 파일시스템 대신 버킷 등의 오브젝트 저장소를 사용해서 Static Web을 구성한다.

📌 REST API

Rest를 기반으로 만들어진 API이다.

REST(Representational State Transfer)

자원의 이름을 구분해서 해당 자원의 상태를 주고 받는 모든 것

1. HTTP URI를 통해 자원을 명시
2. HTTP Method(POST,GET등)을 통해
3. 해당 자원에 대한 CRUD Operation을 적용한다.

쉽게 말하면 HTTP 프로토콜을 통해 수정사항을 DB에 반영할 수 있게되는 것이다.

REST API응답에 포함된 요소

1) 상태 표시줄 여러가지 상태 코드가 반환되는데 각 코드는 의미를 담고있다.

• 200 OK 일반 성공 응답
• 201 Created POST 성공 응답
• 400 BadRequest 서버가 처리할 수 없는 잘못된 요청
• 500 Internal Server Error 서버에 문제가 있음
• 503 Service Unavailable 서버가 요청을 처리할 준비가 되지 않았음

이외에도 여러가지 코드가 있다.

2) 메시지 본문 헤더에 포함된 내용을 기반으로 적절한 표현형식을 선택하여 리소스를 표현한다. 주로 JSON형식을 반환한다.

3) 헤더 응답에 대한 헤더 또는 메타데이터를 포함한다. 서버, 인코딩, 날짜 콘텐츠 유형같은 정보를 포함한다.

REST API인증

RESTful 웹서비스는 응답을 보내기 전에 먼저 요청을 인증해야한다.

1) HTTP인증 기본 : 클라이언트는 요청 헤더에 사용자 이름과 암호를 넣어 전송한다. 전달자(Bearer)인증 : 토큰 전달자에 대한 엑세스 제어를 제공한다. 일반적으로 전달자 토큰은 서버가 로그인 요청에 대한 응답으로 생성하는 암호화 된 문자열이다. 주로 JWT를 사용한다.

2) API키 REST API를 인증하기 위한 또다른 옵션이다. 서버는 고유하게 생성된 값을 최초 클라이언트에 할당하고 클아이언트는 리소스에 엑세스 하려고 할 때마다 고유한 API키를 사용한다.

3) OAuth 모든 시스템에 대한 안전한 로그인 프로세스를 보장하기 위해 암호와 토큰을 결합한다. 나중에 한번 다시 정리할거긴 한데, OAuth2.0에 대한 글을 작성할 것이다.

스프링 부트에서 사용하는 어노테이션 중에 Controller단에서 사용하는 RestController와 Controller가 있다. 문제의 발생은 html 파일을 열어야 하는 Controller단에서 html파일을 어떻게 해도 불러올 수 없길래 찾아보게 되었다.

📌 Controller

간단하게 말하면 MVC 패턴에서 사용하는 View를 불러오는 방법 이라고 표현할 수 있을 것 같다. Controller는 기본적으로 view를 띄우는 것에 활용하게 된다. resource폴더에서 html파일을 띄워서 직접적으로 연결해서 활용하는 방법을 사용하게 되는데, 요즘은 벡엔드와 프론트엔드를 나눠서 json으로 데이터만 전달하는 방식을 활용하고 있기 때문에 view를 따로 연결하지 않는다는 이유로 잘 사용하지 않는다.

controller은 @controller 와 @ResponseBody를 사용해서 페이지가 아니라 응답값을 그대로 반환하기 위해서 사용하게 된다. json으로 데이터를 넘겨주기 위해 두가지 어노테이션을 사용해야한다.

📌 RestController

간단하게 Controller과 ResponseBody를 합친 것이라고 생각하면 된다.

벡엔드와 프론트엔드가 나눠서 작업을 하기 때문에 데이터만 주고받으면된다. 따라서 페이지를 띄우는 Controller방식을 사용할 필요가 없어졌기 때문에 RestConstroller방식을 사용하게 되었다.

다음 포스트에서는 Restcontroller을 어떻게 사용하는지 프론트엔드와 벡엔드 사이에서 구동하는 방식에 대해서 알아봐야겠다.

지난 포스트에서 아이디어를 잘 작성했는데, 코드를 작성하는데 있어서 문제가 없진 않았다. 해결책과 동시에 코드를 첨부한다.

📌 코드

 public void makeTreeNode() {
        while (!priorityQueue.isEmpty()) {
            CategoryTest categoryTest = priorityQueue.poll();
            if (categoryTest.getDepth() == 0) { // Root node
                TreeNode<String, CategoryTest> root = new TreeNode<>(categoryTest.getSeq().toString(), categoryTest.getName(), categoryTest);
                unionAll(root);
                categoryTree = new Tree<>(root);
                break;
            }
            if (contains(categoryTest.getSeq().toString())) {
                unionTreeNode(categoryTest);
            } else {
                insertOrAddToMap(categoryTest);
            }
        }
    }

메인 코드는 이렇게 동작한다 하나하나씩 살펴보면

while (!priorityQueue.isEmpty()) {
CategoryTest categoryTest = priorityQueue.poll();

큐에서 모든 자료를 다 꺼낼 때 까지 반복하도록 한다.

if (categoryTest.getDepth() == 0) { // Root node
                TreeNode<String, CategoryTest> root = new TreeNode<>(categoryTest.getSeq().toString(), categoryTest.getName(), categoryTest);
                unionAll(root);
                categoryTree = new Tree<>(root);
                break;
            }

depth를 검사했을 때 0이라면 최상위 노드이기 때문에 root노드를 만들어서 최상위 노드를 만들어준다.

public void unionAll(TreeNode<String, CategoryTest> root) {
        LinkedList<TreeNode<String, CategoryTest>> unionList = map.get(root.getKey());
        root.setChildren(unionList);
    }

사용되는 unionAll함수이다. 트리를 만들다 보면 루트 트리 아래에 도달하면(depth가 1) map안에는 depth가 1인 것 하나만 남아있어야 한다. 그 부분을 구현한 것이다. setChildren을 통해 리스트를 루트에 연결해준다.

 if (contains(categoryTest.getSeq().toString())) {
                unionTreeNode(categoryTest);

seq가 이미 map에 키로 포함되어있는 경우이다. 이 경우에는 map에서 리스트를 해당 노드의 자식으로 만들어 줘야 한다.

    public void unionTreeNode(CategoryTest categoryTest) {
        TreeNode<String, CategoryTest> node = new TreeNode<>(categoryTest.getSeq().toString(), categoryTest.getName(), categoryTest);
        List<TreeNode<String, CategoryTest>> children = map.get(categoryTest.getSeq().toString());

        if (children != null) {
            node.setChildren(new LinkedList<>(children)); // Copy and set children
        }
        map.computeIfAbsent(categoryTest.getParentSeq().toString(), k -> new LinkedList<>()).add(node);
        map.remove(categoryTest.getSeq().toString()); // Safely remove child data after moving
    }

그 부분을 구현하는 unionTreeNode이다. 해당 노드의 seq값은 자식 노드 그니까 map에 들어간 노드의 parnetSeq값일 것이다. 그것을 이용해서 자식을 찾는다. 이후에 자식이 비어있지 않다면 자식을 부모 노드로 연결을 해주는데, 이때 새로운 리스트로연결을 해줘야 한다. 이유는 참조에 관련된 이야기인데, 아래 코드를 보면 remove를 통해 원래 있었던 자식의 공간을 지우고 있다. 이 과정에서 깊은 복사가 이뤄지지 않으면 복사했던 객체의 참조도 지워지게 되서 자식이 지워지는 경우가 발생한다. 그래서 새로운 객체로 옮겨서 주소를 옮겨주는 것이다. 이 모든 경우에도 포함되지 않는다면,

    public void InsertOrAddToMap(CategoryTest categoryTest) {
        TreeNode<String, CategoryTest> node = new TreeNode<>(categoryTest.getSeq().toString(), categoryTest.getName(), categoryTest);
        map.computeIfAbsent(categoryTest.getParentSeq().toString(), k -> new LinkedList<>()).add(node);
    }

이미 키가 있다면 추가하고 없다면 새로 만들어서 추가하는 메서드이다. computeIfAbsent 메서드는 Map에서 제공하는 메서드인데, categoryTest.getParentSeq().toString() 를 찾는 것에 실패한다면 새로운 링크리스트를 만들어서 add하고 성공한다면 getParentSeq를 한 곳에 add하는 메서드이다. 참이면 본인을 반환하고 거짓이라면 뒤를 반환한다.

    public Tree<String, DepartmentTest> getTree() {
        makeTreeNode();
        return Tree;
    }

만든 트리를 반환하는 로직이다. 생성자에 makeTreeNode를 넣을수도 있지만 LazyEvaluation을 하기 위해서 getTree에 넣어서 원할때만 트리를 만들도록 하였다.

정리

코드를 짜는 것은 어렵지 않았다. 몇 가지 이슈가 있었지만 코드 내용 자체는 간단했고, 트리를 만드는 것에 한하여 속도 향상 또한 많이 좋아졌다. 이제 이걸 다양한 곳에 사용하기 위한 제네릭 클래스를 만들어볼 것이다.

코드 리팩토링은 기존 코드의 동작을 바꾸지 않고 구조와 가독성을 개선하는 과정을 말한다. 코드 품질을 높이고 유지보수성을 향상시키는 것에 목적이 있다.

📌 리팩토링을 하는 코드와 그 이유

코드중에 이런 코드가 있었다.

-- WITH RECURSIVE를 사용하여 재귀 쿼리 작성
WITH RECURSIVE EmployeeHierarchy AS (
    -- Anchor 쿼리: 최상위 직원 (ManagerID가 NULL인 직원)
    SELECT 
        EmployeeID,
        Name,
        ManagerID,
        1 AS Level
    FROM Employees
    WHERE ManagerID IS NULL

    UNION ALL

    -- 재귀 쿼리: 하위 직원 탐색
    SELECT 
        e.EmployeeID,
        e.Name,
        e.ManagerID,
        eh.Level + 1 AS Level
    FROM Employees e
    INNER JOIN EmployeeHierarchy eh
        ON e.ManagerID = eh.EmployeeID
)
-- 결과 조회
SELECT * 
FROM EmployeeHierarchy
ORDER BY Level, EmployeeID;

정확히 원본 코드는 아니지만 최상위 직원을 찾아서 트리를 구성하는 재귀 탐색 SQL탐색문이다.

이렇게 구성하면 SQL을 본래 알던 사람도 다른 사람의 코드를 보면 한번에 이해하기 힘들다는 단점이 있다. 이는 곧 유지보수의 문제가 있다는 단점으로 갈 수 있기 때문에 좋지 못한 코드가 된다.

그런문제도 있지만 가장 큰 문제점은 재귀 탐색을 하고 있어서 성능의 문제가 있다는 것이다.

📌 해결 아이디어

기본적인 아이디어 흐름은 먼저 재귀 탐색을 없애는 것이다. SQL에서 재귀탐색을 통해 트리를 구성하고 밖에 나와서 또 재귀탐색을 통해 트리를 내보내는 형태인 코드를 재귀 탐색을 완전히 없애는 것이 목적이다.

-> 쿼리를 이용해서 재귀 탐색을 진행하니까 쿼리를 쓰지 않고 트리를 구성하면 되지 않을까? 현재 파일 구성은 mapper을 이용해서 DB를 커넥션해서 불러오고 있다. 이 과정에서 Xml파일에 SQL이 담기고 그걸 이용해서 트리를 만들고 있다.

-> 이 방법을 사용하지 않으려면? Mapper로 불러오는 방법 대신 다른 방법을 사용해야 한다. -> Jpa를 통해 불러오자

 @Repository
public interface TestRepository extends JpaRepository<MyEntity, Long>{
    List<MyEntity> findBySeq(Long Seq);
}

이런 식으로 불러올수 있다. Jpa에 대한 설명은 다른 포스트에 하도록 한다.

여기서 MyEntity는 엔티티 객체이다. 이 엔티티 객체가 곧 DB커넥션을 통해 값을 가져올 수 있는 중간 매계가 된다.

-> 어떤 방식으로 불러오는것일까? 순서가 어떻게 될까 Jpa를 통해 DB에서 값을 불러오고 Controller에 그 값을 전달한 후에 적절한 처리를 통해 트리를 구성해서 Json으로 반환하면 되겠다.

-> 기준 키가 무엇일까? 이걸 알려면 일단 DB에서 어떻게 데이터를 전달하는지 알아야 했다.

{
    "seq": 719,
    "parentSeq": 713,
    "companySeq": 197,
    "depth": 4,
    "name": "기술연구소",
    "status": "A",
    "regId": "string",
    "regDate": "2024-08-26T00:42:18.859+00:00",
    "modId": "",
    "sort": 0
  }

이런 형식으로 불러온다는 것을 알게 되었다. 그럼 아까 Jpa를 통해 depth가 10인 필드부터 불러올 수 있겠다. -> 근데 이렇게 하면 SQL호출을 해야해서 JPQL을 사용하거나 따로 쿼리문을 작성해서 Mapper을 써야한다.

우리가 원하는 방식은 Jpa를 사용해서 불러오는 것이기 때문에 일단 모든 값을 불러오고 그 값을 정리하는 방식을 써야겠다.

-> 그럼 기준을 어떻게 잡아야 할까? 자세히 보니까 companySeq라는 부분이 모든 json에서 동일한 것을 확인하였다. 따라서 companySeq로 일단 모든 트리 객체를 불러올 수 있을 것 같다.

-> 그럼 모두 뽑은 후에는 어떻게 정렬해야 할까? 트리의 구조를 만드는 것에는 위에서 내려오는 방법도 있지만 아래에서 모든 것을 통합해서 올리는 방법도 있다. 이 방법을 사용할 것이다. 우선순위 큐를 사용해서 Depth를 높은 순(10~0) 순으로 정렬하고 알고리즘을 짜면 되겠다.

->알고리즘 순서

1. Jpa로 모든 트리 요소를 불러와서 List에 담는다.
2. 우선순위 큐안에 depth가 높은 순서대로 정렬한다.
3. 큐 안에서 하나를 뽑아서 트리노드 하나로 만든다.
4. 그 노드는 depth가 가장 높은 가장 하위 객체일 것임
5. 큐가 빌 때까지 아래 과정을 반복한다. 5-1. depth비교 후같다면 5-2. Map에 키가 존재한다면 이미 등록된것임으로 추가하고 5-3. 키가 존재하지 않는다면 새로운 키임으로 하나를 만들어서 Map에 넣는다.
6. 이런 과정을 반복해서 하나의 depth가 끝난다면 모아놓은 데이터를 모두 부모 객체에 전달하고 부모를 추가한다.
7. depth가 0이 나오면 모든 객체를 전부 넣어서 트리를 마무리한다.

이렇게 쓰면 좀 이해가 어렵다. 요는 아래서부터 트리를 만드는 것인데 그림을 참고하자

부모가 같은 노드를 삽입할 때

부모가 다른 노드를 삽입할 때 depth가 같다면

depth가 다른 노드를 삽입할 때

이런 형식으로 작동하게 된다. 일단 아이디어는 이렇고 다음 포스트에서는 코드를 다루겠다.

어노테이션은 다른 프로그램에게 유용한 정보를 제공하기위해 사용되는 것으로 주석과 같은 의미를 가진다.

사전적 정의는 이러한데, 사실 사용될 때 보면 정말 많은 정보와 기능을 담고 있다. 어노테이션을 사용한 프로그래밍은 유지보수적, 코드 가독성에 정말 많은 도움을 주니까 꼭 알아두도록 하자.

📌 어노테이션의 역할과 종류

어노테이션의 역할

• 컴파일러에게 문법 에러를 체크하도록 정보를 제공한다.
• 프로그램을 빌드할 때 코드를 자동으로 생성할 수 있도록 정보를 제공한다.
• 런타임에 특정 기능을 실행하도록 정보를 제공한다.

어노테이션의 종류 어노테이션은 크게 세 종류로 구분할 수 있다.

• 표준 어노테이션
• 메타 어노테이션
• 사용자 어노테이션

표준 어노테이션

자바에서 기본적으로 제공하는 어노테이션이다. @Override가 대표적인 표준 어노테이션이다.

메타 어노테이션

어노테이션에 붙이는 어노테이션으로, 어노테이션을 정의하는 것에 사용한다. 이게 대체 무슨말인가 하면 표준 어노테이션의 적용 범위나 주석(스키마)를 단다고 생각하면 된다.

사용자정의 어노테이션

말 그대로 어노테이션을 붙이면 사용자가 원하는 행동을 할 수 있도록 정의할 수 있게 하는 것이다. TestCase포스트에서 Valid를 사용하면서 MyNotNull 어노테이션을 만들면서 jakarta 어노테이션을 만든 적이 있었는데, 이런 것이 사용자 어노테이션이다.

장점으로는 표준 어노테이션과 다르게 행동을 정의할 수 있다는 점이 있지만, 행동을 제약하려면 특정한 방식 즉 나름의 프레임 워크를 따라 가야해서 어느정도는 규칙을 지켜야 한다.

📌 Spring Boot 에서 많이 쓰는 어노테이션

아래는 스프링 부트에서 정말 많이 사용되는, 그리고 자바에서도 많이 사용되는 어노테이션들이다. 점점 알게 될 수록 추가할 예정이다.

@Validated

메서드 파라미터의 검증을 위해 사용함

@Tag

API 그룹 설정 테그에 설정된 name이 같은 것끼리 하나의 api그룹으로 묶음 controller나 Controller의 메서드 영역에 설정

@Schema

모델에 대한 정보를 작성함 각 필드값들에 대한 설명이나 기본값, 허용가능한 값 등 api문서를 더 상세히 기술하는 것에 사용함.

@Operation

API동작에 대한 명세를 작성하기 위해 사용 summary에는 간략한 설명, description에는 상세 설명을 기제한다.

@Parameter

파라미터에 대한 설명을 작성한다. name에 반드시 해당 파라미터의 이름을 적어야한다.

@PostMapping

API POST요청을 처리한다. 뒤에 있는 주소로 POST를 하여 받은 데이터를 저장한다.

@RequsetBody

API POST,PUT,PATCH와 같이 사용한다. 요청 본문에 있는 데이터를 전송한다.

@Data

아래의 클래스에 있는 getter,setter을 자동으로 생성해준다.

@ApiResponses, @ApiResponse

api 코드에 대한 반환 값을 입력한다.

@SecurityRequirements

API엔드포인트에서 보안 요구사항을 정의 아무것도 없다면 보안 요구사항을 무효화하거나 변경하는 것

@GetMapping

http GET요청을 처리한다 뒤에 있는 주소로 GET을 해서 받아온다

@NoArgsConstructor:

기본 생성자를 자동으로 생성.

@AllArgsConstructor:

모든 필드를 초기화하는 생성자를 자동으로 생성.

@SequenceGenerator

예시 @SequenceGenerator(name="EMP_SEQ", allocationSize=25) 속성

• name 필수 속성이며 @GeneratedValue의 설정된 name을 설정하면 해당 @GeneratedValue가 붙은 컬럼에 적용된다.
• allocationSize 선택사항이며 시퀀스 번호가 증가할 때 증가할 양을 설정한다.
• catalog
• 선택사항이며 시퀀스의 카탈로그 이다.
• initialValue 선택사항이며 시퀀스의 시작값을 설정한다.
• schema 선택사항이며 시퀀스의 스키마이다.
• sequenceName 데이터베이스에 저장될 시퀀스 개체의 이름을 설정한다.

@Id/ @GeneratedValue

@Id는 PK를 형성해주는역할을 함 @ GeneratedValue를 같이 사용해서 4가지 방법으로 자동생성하는 방법이 있음

1. @GeneratedValue(strategy = GenerationType.IDENTITY) 기본키 생성을 데이터베이스에게 위임하는 방식 데이터베이스가 자동으로 생성하게 된다. JPA가 처리할때 데이터베이스에 먼저 insert쿼리를 실행 해서 PK를 먼저 받아오는 방식

2. @GeneratedValue(strategy = GenerationType.SEQUNCE) DB의 Sequence Object를 이용해서 DB가 생성한다 @SequenceGenerator가 필요함 @GeneratedValue(strategy = GenerationType.SEQUENCE,

                    generator="USER_PK_GENERATOR")

   이렇게 사용하는데, generator에는 SquenceGenerator의 이름이 들어가야 한다. DB에서 받아와서 생성하고 allocationSize로 증가 범위를 조절한다.

3. @GeneratedValue(strategy = GenerationType.TABLE) 테이블을 이용해서 생성한다. 방식은 Seq방식과 동일하지만 최적화되지 않은 것을 사용하기 때문에 성능에 이슈가 있다

4. @GeneratedValue(strategy = GenerationType.AUTO) 기본 설정 값으로 자동 생성한다.

@Builder

변수를 .변수명(값)으로 지정할 수 있게 해주는 패턴이다. 유지보수가 용이하다.

@Autowired

생성자,수정자의 의존성을 자동으로 주입한다.

@Param

메서드 매개변수를 명시적으로 연결해주는 역할을 한다.

@Column

name : 필드와 매핑할 테이블의 컬럼 이름 nullable : null값의 허용 여부 설정. 기본값은 true

@Table

엔티티와 매핑할 테이블을 지정 name : 매핑할 테이블 이름 schema : DB에서 schema를 매핑

@Schema

description : 클래스나 필드의 대한 설명 추가 example : 문서에서 보여줄 예제 값을 설정 minimum(필드) : 최소값 제한 maximum(필드) : 최대값 제한

@Enumerated

EnumType.ORDINAL, EnumType.STRING enum의 값이나 이름을 데이터베이스에 저장한다.

@Transient

엔티티 내부에서 DB와 매핑되지 않도록 한다.

@Component

Autowired가 가능하도록 SpringBean에 등록한다. String으로 빈의 이름을 설정할 수 있음

@RequestBody

HTTP요청을 자바 객체로 변환하여 객체에 저장한다.

@RequiredArgsConstructor

의존성 주입 방법중에 생성자 주입을 임의의 코드없이 자동으로 설정해 줌

@Slf4j

추가 로깅 인터페이스로 디버깅 상세화 제공

@RequestParam

Http에서 해당 이름으로 바인딩 할 수 있게 한다.

테스트 케이스를 작성 중에 시스템 단위 테스트를 하는데, 단위 테스트 범위가 Mapper에 들어가 있어서 정확히 시간테스트를 진행할 수 없었다. Mapper은 Xml파일에서 얼마나 빠른 속도로 SQL을 통해 DB에서 데이터를 끌어올 수 있는지를 체크해야하는데, 정확한 시간을 잡아낼 수 없었다.

원래는 @Autowired를 통해 의존성 주입을 하고 사용했는데, 전체 시간 속에서 다른 mapper을 불러오려면 AOP를 활용해서 불러와야 했다.

📌AOP?

Aspect Oriented Programming의 약자로 관점 지향 프로그래밍이라고 불린다. 어떤 로직을 기준으로 핵심적인 관점, 북적인 관점으로 나누었느냐, 그리고 그 관점으로 모듈화 한다는 것이다.

@Aspect
@Component
public class testAspect

이런 식으로 클래스에 @Aspect를 이용해서 Aspect클래스라는 것을 명시한다. 그리고 @Component를 붙여 스프링 빈으로 등록한다.

@Around("excution(경로))
public Object test(ProceedingJoinPoint joinPoint) throws Throwable{
        long start = System.nanoTime();
        Object result = joinPoint.proceed();
        long end = System.nanoTime();
 }

이런 식으로 @Aspect를 이용해서 타겟 메서드를 감싸서 특정 Advice를 실행하겠다는 것이다. excution에 붙은 경로는 패키지 경로가 들어간느데, 이는 특정 객체 아래에 모든 메서드에 Aspect를 적용한다는 것이다.

📌테스트에 적용

테스트에 적용하는 것은 간단하다. 기본적으로 Junit 테스트를 진행하는 것과 동일하게 작동하기 때문에 차이점은 없고 이번에 할 테스트는 전체 시간중에서 얼마나 그 메서드가 동작하는지 확인하는 것이기 때문에 전체 시간을 재고 그 시간과 AOP로 호출한 Service계층의 속도를 비교할 것이다.

    @Autowired
    private SelectAOP selectAop; // AOP 클래스

    @Autowired
    private SelectController controller;

    @Test
    void getExecutionTime(){
        long start = System.nanoTime();
        controller.getExecution();
        long end = System.nanoTime();

        long methodExecutionTime = selectAop.getMethodExecutionTime();

이런 식으로 적용해서 각각의 시간을 잴 수 있다. 이렇게 AOP를 호출해서 하면 좋은 점이 안에 있는 메서드를 따로 테스트에 호출하지 않아도 geExecution이 실행되면서 발생하는 DB커넥션 테스트를 진행 할 수 있다.

@Valid 를 사용해서 처리하고 있었다. 이제까지는 핸들러로 Exception을 잡아서 해결하고 있었는데, 여러모로 불편한 점이 많아서 그렇게 하지 않고 사용자 정의 어노테이션으로 해결하려고 한다.

방법 1. AOP

AOP(Aspect-Oriented Programming)방법을 쓰면 어노테이션 방법을 쓰면서 throw exception을 유연하게 처리할 수 있다.

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.PARAMETER)
public @interface MyNotNull {
    String message() default "Field must not be null";
    String apiMessage() default "INVALID_INPUT";
}

이런 식으로 어노테이션을 만들고

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.springframework.stereotype.Component;

@Aspect
@Component
public class MyNotNullAspect {

    @Before("@annotation(myNotNull) && args(value,..)")
    public void validateNotNull(MyNotNull myNotNull, String value) {
        if (value == null || value.trim().isEmpty()) {
            String defaultMessage = myNotNull.message();
            ApiCodeEnum apiCode = ApiCodeEnum.valueOf(myNotNull.apiMessage());
            throw new CommonException(apiCode, defaultMessage);
        }
    }
}

이렇게 어노테이션 검사식을 추가할 수 있다. 같은 동작을 하긴 하는데, 이전과 다른 점은 Jakara에서 제공하는 @Valid어노테이션을 사용하면 ConstraintViolationException을 발생시킨다. 하지 않는 방법이 있지만 이건 나중에 다루도록 하고, AOP방식을 사용하면 내가 원하는 Exception을 터트릴 수 있다는 점에서 관리가 유연하다는 점이 있다.

public void processRequest(@MyNotNull(message = "Name is required", 
apiMessage = "INVALID_NAME") String name) {
    // 메서드 실행 전에 AOP로 유효성 검사 수행
}

이런 식으로 사용한다.

방법 2. 커스텀 Validator클래스 사용

이전 방법에서는 어노테이션만 만들었다면 이번에는 Jakrta처럼 Validator클래스를 만들어서 그에 따른 동작을 하게하는 방법이다.

public interface Validator<T> {
    void validate(T value) throws CommonException;
}

이렇게 범용 인터페이스를 정의하고

public class MyNotNullValidator implements Validator<String> {
    private final String defaultMessage;
    private final ApiCodeEnum apiCode;

    public MyNotNullValidator(String defaultMessage, ApiCodeEnum apiCode) {
        this.defaultMessage = defaultMessage;
        this.apiCode = apiCode;
    }

    @Override
    public void validate(String value) {
        if (value == null || value.trim().isEmpty()) {
            throw new CommonException(apiCode, defaultMessage);
        }
    }
}

이렇게 사용하면, 그에따른 동작을 하게 만들어진다. 이 방법의 장점은 유연성과 재사용성을 모두 챙겼다는 점이다. 그리고 만약에 나중에 다른 어노테이션을 사용하려고 했을 때도 독립정의된 인터페이스로 작동하기 때문에 독립적으로 작동한다는 장점이 있다.

Validator<String> validator = new MyNotNullValidator("Value cannot be null", ApiCodeEnum.INVALID_INPUT);
validator.validate(inputValue);

이렇게 사용한다.

방법 3. Jakarta어노테이션

지금까지 사용했던 방법들이 좋은 방법들이지만 지금 하려는 것에 치명적인 문제점이 있다. 위 방법대로 사용하면 @Vlidate로 검사를 시작할 수 없다. 모두 독립적인 방법으로 검사를 진행하기 때문에 기존에 있던 코드를 모두 변경해줘야 하는 참사가 발생한다. 그래서 호완이 가능한 Jakarta 어노테이션을 사용한다.

import jakarta.validation.Constraint;
import jakarta.validation.Payload;

import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

@Constraint(validatedBy = MyNotNullValidator.class) // 검증기를 연결
@Target({ ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER }) // 적용 대상
@Retention(RetentionPolicy.RUNTIME) // 런타임에 유지
public @interface MyNotNull {

    // 기본 에러 메시지
    String message() default "This field cannot be null or empty";

    // API 메시지 커스텀
    String APImessage() default "INVALID_FIELD";

    // 그룹 지정 (기본값: {})
    Class<?>[] groups() default {};

    // 확장에 사용되는 Payload (기본값: {})
    Class<? extends Payload>[] payload() default {};
}

이렇게 어노테이션을 만들 수 있다.

public class MyNotNullValidator implements ConstraintValidator<MyNotNull, String> {

    private String defaultMessage;
    private ApiCodeEnum apiMessage;

    @Override
    public void initialize(MyNotNull constraintAnnotation) {
        this.defaultMessage = constraintAnnotation.message();  // 기본 메시지
        this.apiMessage = constraintAnnotation.APImessage();   // API 메시지
    }

    @Override
    public boolean isValid(String value, ConstraintValidatorContext context) {
        if (value == null || value.trim().isEmpty()) {
            context.disableDefaultConstraintViolation();
            context.buildConstraintViolationWithTemplate(MessageUtils.getMessage("error." + apiMessage,defaultMessage))
                    .addConstraintViolation();
            return false;
        }
        return true;
    }
}

이렇게 컨트롤러를 만들어줘야 하는데 하나하나 살펴보면

@MyNotNull(message="not",apiMessage=ApiCodeEnum.Error_code)

이렇게 어노테이션을 사용하게 될 것이다. 그럼 not이라는 메세지를 담은 API_Error_code가 ConstraintViolationException으로 나오게 되는 것이다.

📌해결

기존 코드를 모두 바꿀 수 없으니 방법 3을 사용하기로 하였다. 근데 문제가 아직 하나 남아있다. 우리는 기존에 터트려야하는 Exception이 CommonException이다. 하지만 3번 방법을 사용하게 되면 원하는 에러를 발생시킬 수 없다.

그래서 방법을 찾아봤는데 총 두가지의 방법이 있었다.

방법 1. isValid안에서 Exception발생

생각해보면 매우 간단한 방법인데

@Override
    public boolean isValid(String value, ConstraintValidatorContext context) {
        if (value == null || value.trim().isEmpty()) {
               throw new CommonException(apimessage,defualtmessage);
        }
        return true;
    }

이렇게 하면 검사를 함과 동시에 CommonException을 발생시킬 수 있다. 가장 큰 장점은 쉽다는 것이다. 이렇게 하면 별다른 핸들러가 필요없이 하나의 코드에서 처리할 수 있다.

하지만 단점이 있다. 바로 Springboot 프레임워크의 규칙을 위반한다는 것이다.

이게 무슨말이냐, 프레임워크는 정해진 틀이있고 그 안에서 발생할 수 있는 예외가 정해져있다. 하지만 CommonException은 정의한 Exception이고 이것은 프레임워크에서 발생하면 안되는 오류이다. 따라서 프레임워크는 아래와 같은 메세지를 보낸다.

"An unexpected error occurred"

사실 오류 처리만 제대로 하고 있다면 무시해도 별 상관은 없다.(라고 공식문서에 나와있다) 하지만 프레임워크의 특성상 웬만하면 구조는 건들지 않는 것이 좋다. 나중에 어떤 문제가 터질지 모르는 것이니.

방법 2. ExceptionHandler이용

CommonException을 처리할 수 없다면 예외를 catch해서 다른 예외로 바꾸는 핸들러를 사용하면 된다.

@RestControllerAdvice
@Validated
public class GlobalExceptionHandler {

    @ExceptionHandler(ConstraintViolationException.class)
    public void handleConstraintViolationException(ConstraintViolationException ex) {
        // 예외 메시지를 추출
        List<String> errorMessages = ex.getConstraintViolations().stream()
            .map(violation -> violation.getPropertyPath() + ": " + violation.getMessage())
            .collect(Collectors.toList());

        // CommonException으로 변환하여 던짐
        throw new CommonException(ApiCodeEnum.ERROR_938, errorMessages);
    }
}

천천히 살펴보자

@RestControllerAdvice
@Validated

RestControllerAdvice는 사실 여기서는 필요없는 어노테이션이다. 원래 해주는 역할은 @Valid가 Controller단에 걸려있다면 그걸 잡는 역할을 하는데, 여기서는 service단에 걸어놨기 때문에 필요없는 어노테이션이다.

@Validated는 @Valid를 처리할 것이라는 명시적 어노테이션인것 같다.(확실하지 않다..)

@ExceptionHandler(ConstraintViolationException.class)

아래 나오는 메서드에서 ConstraintViolationException을 처리하겠다는 명시이다. 그냥 메서드로 작성할 수 있지만 다른 오류를 같이 처리하기 위해 묶어서 작성한다.

handleConstraintViolationException(ConstraintViolationException ex) {
        // 예외 메시지를 추출
        List<String> errorMessages = ex.getConstraintViolations().stream()
            .map(violation -> violation.getPropertyPath() + ": " + violation.getMessage())
            .collect(Collectors.toList());

ConstraintViolationException에서 발생한 예외 메세지를 담아서 리스트화 한다. 리스트로 만드는 이유는 아래 CommonException에서 받는 형식이기 때문이다.

throw new CommonException(ApiCodeEnum.ERROR_938, errorMessages);

CommonException을 터트린다.

이런 방식으로 하니까 확실히 코드가 나눠져서 보기에는 편할 수 있었다. 하지만 이전 포스트에서 설명 했다시피 @Valid는 발생시킬 수 있는 예외가 총 3가지가 있다. 보통 컨트롤러 단에서 잡으니 2개는 잡을 필요가 없지만 그래도 핸들러를 만드려면 다 만들어 줘야 사용하기에 용이하다. 이런 점에서 약간 불편하지만 이런 방식을 채택하는게 유지보수와 사용용이성면에서 좋은 결과를 가질 수 있는것 같다.

📌 세팅

public class SignupVO {
    @Valid
    private Account account;
    // 기타 필드와 메서드
}

이런 식으로 생긴 JAVA코드를 @Valid를 이용해서 유효검증을 하려고 한다.

@NotNull(message ="null password")
    private String pw;

@NotNull 어노테이션을 사용해서 Null 필드를 사용하지 않겠다고 하였고

@Override
    public Account signUp(@Valid SignupVO signupVO, String mobile)

이런 식으로 메서드를 재정의 해서 @Valid를 적용하여 SignupVO를 검증하게 하였다.

📌 문제

1. @Valid가 적용되지 않는다.

분명 @Valid를 적용하면 유효성 검증을 할 수 있다고 하였다. 하지만 이 코드의 경우 그냥 넣었을 때는 유효성 검증이 불가능 하였다. MethodArgumentNotValidException 이라는 예외가 등장하여야 하는데 다른 예외가 터지는것으로 보아 검증이 제대로 이뤄지지 않는 것이었다.

1. @Valid가 적용되지 않는다 (해결)

문제의 해결은 간단했다.

@Validate
public class TestCase{

    public void case1(@Valid signUpVO signupvo){
    ...
    }

}

이런 식으로 작성해야 했다. public class위에 Validate를 적용해줘야 아래 @Valid가 정상적으로 검증을 수행하였다.

2. jakarta.validation.ConstraintDeclarationException: HV000151 오류 발생

public class AuthServiceImpl implements AuthService {
    @Override
    public Account signUp(@Valid SignupVO signupVO, String mobile) {
        // 메서드 구현
    }
}

이런 식으로 작성된 코드를 실행하였더니 오류가 발생하였다. 찾아보니 호완성 오류라는데 해결은 간단했다.

2. jakarta.validation.ConstraintDeclarationException: HV000151 오류 발생(해결)

public interface AuthService {
    Account signUp(SignupVO signupVO, String mobile);
}

문제의 인터페이스이다. AuthService를 인터페이스로 작성하였는데, 그 안에있는 메서드인 signUp이 호완이 되지 않아 발생하는 문제이다.

public interface AuthService {
    Account signUp(@Valid SignupVO signupVO, String mobile);
}

이렇게 바꿔주면 정상적으로 작동하게 된다. @Valid또한 문법인지라, 인터페이스에 맞게 작성해줘야 한다.

3. jakarta.validation.ConstraintViolationException을 CommonException으로 변환 불가

테스트케이스의 핵심은 CommonException으로 다국어화 한 Exception을 발생시키는 것이었다. DB에서 그것들을 불러와서 Exception Enum으로 정의된 것을 통해 획일화된 Exception을 발생시켜야 하는데, 이것을 하기 위해서 GlobalExceptionHandler을 사용하였다.

public class GlobalExceptionHandler {

    // ConstraintViolationException을 처리
    @ExceptionHandler(ConstraintViolationException.class)
    public void handleConstraintViolationException(ConstraintViolationException ex) {
        // 오류 메시지 추출
        List<String> errorMessages = ex.getConstraintViolations().stream()
            ...
        // CommonException 던지기
        throw new CommonException(ApiCodeEnum.ERROR_938, errorMessages);
    }

이렇게 작성해서 ConstraintViolationException을 잡으려고 하였다. 하지만

org.opentest4j.AssertionFailedError: Unexpected exception type thrown, 
Expected :class com.duegosystem.core.config.exception.CommonException
Actual   :class jakarta.validation.ConstraintViolationException

이런 오류문구(테스트결과)를 얻게 되었다. 해석하면, 예외를 기대한 것은 commonException이었는데 ConstraintCiolationException이 터졌다는 말이었다.

즉, 핸들러가 작동하지 않아서 원래 오류인 ConstraintCiolationException이 터졌다는 말이다.

3. jakarta.validation.ConstraintViolationException을 CommonException으로 변환 불가(해결)

많은 서칭과 GPT를 통해 해결책을 얻었다.

@RestControllerAdvice
@Validated
public class GlobalExceptionHandler {

    // ConstraintViolationException을 처리
    @ExceptionHandler(ConstraintViolationException.class)
    public void handleConstraintViolationException(ConstraintViolationException ex) {
        // 오류 메시지 추출
        List<String> errorMessages = ex.getConstraintViolations().stream()
            ...

        // CommonException 던지기
        throw new CommonException(ApiCodeEnum.ERROR_938, errorMessages);
    }

먼저 @RestContollerAdvice를 추가하였다. 여기서의 역할은 아래의 public class를 전역적인 class로 만들어서 어디서 예외가 발생하던 잡을 수 있도록 만드는 것이라는데, 이건 Controller 계층에서 해당하는 말이고, 지금 작업하는 계층은 Service계층이기 때문에 별로 의미있는 어노테이션은 아니다.

문제점은 테스트에 있었다. SpringBoot와 Junit으로 테스트 케이스를 작성하였는데, 두개의 특성상 GlobalExceptionHandler에 예외를 던지기 전에 예외를 반환하고 테스트 케이스를 종료한다.

그랬기 때문에 아무리 메인 코드를 바꿔도 처리가 되지 않았던 것. 이걸 하기 위해 방법이 두가지가 있었다.

1. Mock를 사용하는 것(실패) 예전에도 한번 시도해 봤었다.

   @Autowired
   private MockMvc mockMvc;

   이런 식으로 MockMvc로 가상의 객체를 만들어서 API를 전달하는 방법인데, 어째선지 이유를 찾지는 못했는데 NPE(NullPointException)이 발생해서 빈번히 실패했었다. 이유는 Mock객체가 만들어지지 않았다고 하는데... 이건 나중에 다시 찾아보는 것으로
2. Intellij Http 사용(성공) Intellij에는 http라는 기능이 있다. 처음 써봤을 때 매우 신기했는데, API를 직접 만들어서 서버단에서 전송할 수 있는 기능이다.

   GET https://localhost:8080/auth/service

   이런 방법으로 .http파일에 작성하면 옆에 실행 버튼이 뜨게 된다. 그 버튼을 누르면 해당 주소에서 API를 불러오게 된다.

POST https://localhost:8080/auth/service
Content-Type: application/json

{
  "groupName": "그룹명",
  "members": [
    "회원1",
    "회원2",
    "회원3"
  ],
  "date": {
    "year": 2018,
    "month": 1,
    "day": 24
  }
}

이런 식으로 POST도 할 수 있다. 이렇게 하면 내가 원하는 데이터를 API형식으로 웹에 전달하게 된다. 물론 서버는 켜져 있어야 정상적으로 작동한다.

아무튼 이런 방식으로 내가 원하는 데이터를 만들어서 전송시켰더니 CommonException이 정상적으로 나오는 것을 볼 수 있었다.

📌 추가적으로 생각해 본 것

1. @Valid의 Exception은 MethodArgumentNotValidException을 발생시켜야 하는데 왜 ConstraintViolationException이 터질까?

이유는 @Valid의 사용 위치에 따라 달랐다

@RestController
public class AuthController {

    @PostMapping("/signUp")
    public ResponseEntity<String> signUp(@Valid @RequestBody SignupVO signupVO) {
        return ResponseEntity.ok("Signup successful");
    }
}

이렇게 Controller메서드에서 @Valid가 사용될 때는 MethodArgumentNotValidException을 발생시킨다.

@Service
@Validated
public class AuthService {

    public void signUp(@Valid SignupVO signupVO) {
        // 메서드 로직
    }
}

그리고 이렇게 Service메서드에서 @Valid를 호출하면 ConstraintViolationException가 발생하게 된다.

@Controller
public class FormController {

    @PostMapping("/submitForm")
    public String submitForm(@Valid FormData formData, BindingResult bindingResult) {
        if (bindingResult.hasErrors()) {
            return "error";
        }
        return "success";
    }
}

또 이런 경우가 있다는데 한번도 보진 못했다 Controller메서드에서 발생하는 것 같다. BindException을 발생시킨다. form에 매핑이 제대로 되지 않으면 발생하는 것 같다.

이런 3가지 경우로 발생시킬 수 있다.

회사에서 테스트 케이스를 작성하게 되었는데 막히는 일도 있고 정리하면 좋을 것 같아서 시작하게 되었다.

📌 사용한 언어 및 프레임워크

• JAVA Junit

테스트 케이스의 종류와 방법

먼저 테스트 케이스를 작성하려면 테스트케이스에 어떤 종류가 있고 무슨 방식으로 테스트 케이스를 작성하는지 알아야 한다고 생각한다

블렉박스 테스트(Black-Box Test)

위 그림처럼 내부 경로에 대한 지식을 보지 않고 프로그램의 외부 규격서에 의거해서 입력 데이터와 출력 데이터가 규격서에 정해진 바와 같은 결과를 얻을 수 있는지 테스트한다. 요구사항이 명확하고 얻어야하는 결과가 명확할 때 사용할 수 있다.

화이트박스 테스트(White-Box Test)

위 이미지 처럼 프로그램의 코드나 모듈에 접근하여 요구에 맞게 잘 동작하는가에 초점을 둔 테스트이다. 프로그램 내부 구조의 타당성 여부를 시험하고, 내부구조를 테스트해서 프로그램 루틴에 대해 시험한다.

단위 테스트(Unit Test)

모듈테스트(Module Test)라고도 한다. 테스트 가능한 가장 작은 단위를 개별적으로 테스트 한다

통합 테스트(Intergration Test)

프로그램 또는 그 구성 요소인 모듈 등의 정보 시스템 하나하나의 구성 요소를 결합해서 인터페이스와 각 결합 단계에서의 기능을 확인한다. 컴포넌트나 서브시스템 단위이다. 이외에도 많은 테스트가 있다

여기서 할 부분은 화이트 박스 테스트를 진행하고 코드에 대한 단위 테스트를 진행하게 되었다. 그럼 화이트박스 테스트라고 했으니 코드는 이미 적용되어 있고 단위 테스트를 진행해야 하는데 단위테스트를 진행하는 방법이 뭘까?

테스트 과정

1. 원시 코드를 통해 애플리케이션의 구조를 이해
2. 검증 기준(커버리지) 선정
3. 각 경로를 구동시키는 테스트 데이터 준비

크게 이렇게 이뤄진다. 애플리케이션의 구조를 이해하기 위해 논리흐름도를 작성할 수 있으나, 너무 코드가 길기 때문에 논리코드가 지저분하게 나와서 굳이 작성하지 않고 각 기능을 하는 메서드별로 테스트케이스를 작성하기로 하였다.

검증 기준(커버리지) 선정

문장 커버리지(Statement Coverage)

프로그램 내의 모든 명령문을 적어도 한번 실행해야 한다 조건문에 관계 없이 구문 실행 개수로 계산한다.

결정(선택), 분기 커버리지(Branch Coverage)

각 분기의 결정 포인트 내의 조건식이 적어도 한번은 참과 거짓의 결과를 수행해야 한다. (문장 커버리지를 포함한다)

조건 커버리지(Condition Coverage)

각 분기의 결정 포인트 내의 각 개별 조건식이 적어도 한번은 참과 거짓이 수행되어야 함.

조건/결정 커버리지(Condition/Decicion Coverage)

전체 조건 뿐 아니라 개별 조건식도 참과 거짓의 결과가 한번씩 나와야 한다.

이게 말만 들었을 때는 분기 커버리지와 조건 커버리지의 차이가 잘 느껴지지 않는다. 그래서 아래 코드를 보면

if(a>0 || b<0){
System.out.println("ok");
}

이 코드를 사용한다고 하였을 때

test2과 test3 둘중 하나와 test1이면 100%를 얻을 수 있다. 분기 커버리지는 if분기에서 조건문이 참/거짓을 만족하면 되기 때문이다.

하지만 조건 커버리지를 적용하면 test2,3을 적용하면 100%를 얻을 수 있다. 조건 커버리지는 분기와 다르게 결과값에 상관없이 조건문 안의 조건들이 각각 true와 false를 가져야 한다.

그래서 곧 조건!=분기가 적용되게 된다. 조건커버리지를 만족하지만 분기 커버리지는 만족하지 않을 수 있는 것이다.

이런 부분을 개선하기위해 나온 것이 조건/결정 커버리지이다. test1,2,3을 모두 사용해야 100%를 얻을 수 있다.

정리

지금까지 테스트 케이스 작성을 위한 준비 과정이었다. 코드를 미리 볼 수 있는 만큼 테스트 데이터를 잘 준비해서 모든 커버리지를 만족할 수 있는 케이스를 작성해야한다.