✅ 알고리즘 & SQL 코드 카타 💡 오랜만에 코드 카타를 풀었는데 그래도 다행히 쉬운 문제여서 금방 풀 수 있었다. (알고리즘 문제에서 시간 초과 때문에 코드를 한 번 갈아 엎었지만...) SQL도 아직은 문제 유형이 반복적이라서 문제를 못 읽어서 못 풀지는 않는 것 같다. (예시를 보고 이해한 적도 더러 있지만...)

✅ 미니 프로젝트 성능 개선 💡 미니 프로젝트를 진행했을 때 성능 개선을 하고 싶었던 찜찜한 부분이 있었는데, 그 부분을 해결했다. 내가 100을 한 건 아니지만 같이 의견 제시하고 유의미한 결과를 도출해내서 좋은 경험이 되었던 것 같다.

전제 조건

우리가 진행한 미니 프로젝트는 배달앱을 모티브로 하였으며, 1건의 주문에 1건의 리뷰(일반 사용자)를 달 수 있고, 작성된 리뷰 1건에 1건의 코멘트(사장님)를 달 수 있는 전제 조건을 가지고 있다. 즉, 리뷰와 코멘트는 일대일 연관관계를 가지고 있다.

성능 개선의 필요성 인식

DB에 너무 많은 요청을 보내는데..?

// Dto
@Getter
public class ReviewListDto {
  // 리뷰 정보
  private Long reviewId;
  private Long purchaseId;
  private Long userId;
  private Long shopId;
  private Long starPoint;
  private String reviewContent;
  private LocalDateTime createdAt;
  private LocalDateTime updatedAt;
  // 코멘트 정보
  private CommentReviewDto comment;
>  
  // ... 생략
}
>
@Getter
@AllArgsConstructor
public class CommentReviewDto {
>
  private Long reviewId;
  private Long commentId;
  private Long userId;
  private String commentContent;
  private LocalDateTime createdAt;
  private LocalDateTime updatedAt;
>
  // ... 생략
  }
}

// Controller
@GetMapping("/shops/{shopId}")
public ResponseEntity<ApiResponse<List<ReviewListDto>>> getShopReview(
    @PathVariable Long shopId,
    @RequestParam(defaultValue = "1") Long minStarPoint,
    @RequestParam(defaultValue = "5") Long maxStarPoint) {
>
    List<ReviewListDto> reviewDtos = reviewService.getShopReview(shopId, minStarPoint, maxStarPoint);
    ApiResponse<List<ReviewListDto>> apiResponse = ApiResponse.success(HttpStatus.OK, "가게 리뷰 조회 성공", reviewDtos);
>
    return new ResponseEntity<>(apiResponse, HttpStatus.OK);
}

// Service
public List<ReviewListDto> getShopReview(Long shopId, Long minStarPoint, Long maxStarPoint) {
    // ... 생략
>
    List<Review> reviewList = reviewRepository.findAllByShopShopIdAndStarPointBetweenOrderByCreatedAtDesc(
        shopId, minStarPoint, maxStarPoint);
>   
    return reviewList.stream().map(
        review -> ReviewListDto.builder()
            .userId(review.getUser().getUserId())
            .createdAt(review.getCreatedAt()).updatedAt(review.getLastModifiedAt())
            .starPoint(review.getStarPoint()).reviewContent(review.getReviewContent())
            .shopId(review.getShop().getShopId()).reviewId(review.getReviewId())
            .purchaseId(review.getPurchase().getPurchaseId()).comment(
                Optional.ofNullable(
                    // 리뷰 1건의 데이터를 조회할 때마다 작성된 코멘트의 데이터도 조회
                    commentRepository.findByReviewReviewId(review.getReviewId()))
                    .map(CommentReviewDto::convertDto).orElse(null))
            .build()).toList();
  }

리뷰 조회시 코멘트에 대한 정보도 함께 출력해줘야 했으며, 위의 코드는 리뷰 조회 API의 일부 코드이다. 리뷰와 코멘트를 함께 출력해줘야 한다는 요구사항에 맞게 Dto 내부에 코멘트 Dto도 포함되어 있으며, 서비스에서는 조회한 리뷰 데이터마다 코멘트 데이터를 조회하고 있다. 프로그램 실행에 문제는 없었지만 이렇게 작성된 코드를 보니 DB에 보내는 요청을 너무나도 줄이고 싶었다.

지금 상태라면 n건의 리뷰 데이터가 있다고 가정할 때 2n번의 DB 접근이 필요하다. 그리고 commentContent라는 데이터 이외에는 필요 없는 데이터이기 때문에 힘들게 가져온 데이터 중에서도 상당 부분이 필요없는 데이터이다.

필요한 데이터만 최소한의 DB 접근으로 가져오자

그래서 우리는 DB 접근 횟수를 최소한으로 줄이면서 commentContent 만 가져올 수 있도록 수정을 시작했다.

// Dto
@Data
public class ReviewWithCommentDto {
>
  private Long reviewId;
  private Long userId;
  private LocalDateTime createdAt;
  private LocalDateTime lastModifiedAt;
  private Long starPoint;
  private String reviewContent;
  private Long shopId;
  private Long purchaseId;
  private String commentContent;
>  
  // ... 생략
  }
}

// Controller
@GetMapping("/shops/{shopId}")
public ResponseEntity<ApiResponse<List<ReviewWithCommentDto>>> getShopReview(
    @PathVariable Long shopId,
    @RequestParam(defaultValue = "1") Long minStarPoint,
    @RequestParam(defaultValue = "5") Long maxStarPoint) {
>
    List<ReviewWithCommentDto> reviewDtos = reviewService.getShopReview(shopId, minStarPoint, maxStarPoint);
    ApiResponse<List<ReviewWithCommentDto>> apiResponse = ApiResponse.success(HttpStatus.OK, "가게 리뷰 조회 성공", reviewDtos);
>
    return new ResponseEntity<>(apiResponse, HttpStatus.OK);
  }

// Service
public List<ReviewWithCommentDto> getShopReview(Long shopId, Long minStarPoint,
      Long maxStarPoint) {
    // ... 생략
>
    List<ReviewWithCommentDto> results = reviewRepository.findReviewsWithComment(shopId, minStarPoint, maxStarPoint);
>
    return results.stream()
        .map(dto -> ReviewWithCommentDto.builder()
            .reviewId(dto.getReviewId())
            .userId(dto.getUserId())
            .createdAt(dto.getCreatedAt())
            .lastModifiedAt(dto.getLastModifiedAt())
            .starPoint(dto.getStarPoint())
            .reviewContent(dto.getReviewContent())
            .shopId(dto.getShopId())
            .purchaseId(dto.getPurchaseId())
            .commentContent(dto.getCommentContent())
            .build())
        .toList();
  }

// Repository
public interface ReviewRepository extends JpaRepository<Review, Long> {
  @Query("""
          SELECT
              new Not.Delivered.review.domain.Dto.ReviewWithCommentDto(
                r.reviewId,
                r.user.userId,
                r.createdAt,
                r.lastModifiedAt,
                r.starPoint,
                r.reviewContent,
                r.shop.shopId,
                r.purchase.purchaseId,
                (SELECT c.commentContent FROM Comment c WHERE c.review.reviewId = r.reviewId)
              )
          FROM Review r
          WHERE r.shop.shopId = :shopId
          AND r.starPoint BETWEEN :minStarPoint AND :maxStarPoint
          ORDER BY r.createdAt DESC
      """)
  List<ReviewWithCommentDto> findReviewsWithComment(Long shopId, Long minStarPoint,
      Long maxStarPoint);
}

가장 크게 바뀐 것은 Dto와 Repository이다. Dto에서는 Comment의 모든 필드가 아닌 꼭 필요한 commentContent만 포함하도록 수정했다.

이에 따라 Repository에서도 바뀐 Dto인 ReviewWithCommentDto의 필드에 맞게 리뷰 테이블과 코멘트 테이블을 한 번에 조회하도록 수정했다. 이제 리뷰 테이블과 코멘트 테이블을 따로 조회하지 않아도 되는 것이다.

그래서 결과는..?

API를 반복적으로 호출하면 캐싱과 같은 부가적인 요소 때문에 시간이 다르게 측정될 수 있음을 고려하여, 각 API 호출 전에 애플리케이션을 재시작하였다. 데이터 수와 테스트 수 모두 많지 않지만 유의미한 결과를 볼 수 있었다.

1. 데이터 수 : 리뷰 3건, 코멘트 3건 →

성능 개선 이전

• DB 접근 횟수(쿼리 발생 횟수) : 6회
• 처리 시간 : 141 ms
  

성능 개선 이후

• DB 접근 횟수(쿼리 발생 횟수) : 2회
• 처리 시간 : 88 ms

2. 데이터 수 : 리뷰 20건, 코멘트 20건

성능 개선 이전

• DB 접근 횟수(쿼리 발생 횟수) : 40회
• 처리 시간 : 162 ms
  

성능 개선 이후

• DB 접근 횟수(쿼리 발생 횟수) : 2회
• 처리 시간 : 95 ms

3. 데이터 수 : 리뷰 50건, 코멘트 50건

성능 개선 이전

• DB 접근 횟수(쿼리 발생 횟수) : 100회
• 처리 시간 : 233 ms
  

성능 개선 이후

• DB 접근 횟수(쿼리 발생 횟수) : 2회
• 처리 시간 : 110 ms

정리

무분별한 쿼리메소드 사용은 불필요한 데이터까지 얻어오고, 잘못된 로직 구성은 꽤나 큰 리소스 낭비로 이어진다는 것을 알 수 있었다. 앞으로도 최적화, 개선에 초점을 맞춰서 개발할 수 있는 자세를 가져야겠다는 생각을 가지게 되었다.

✅ 테스트 내용 요약 #1 DB 접근 횟수(쿼리 발생 횟수) : 6회 → 2회 처리 시간 : 141ms → 88ms (약 1.6배의 처리 속도 증가 == 약 37.59%의 효율 증가)

#2 DB 접근 횟수(쿼리 발생 횟수) : 40회 → 2회 처리 시간 : 162ms → 95ms (약 1.71배의 처리 속도 증가 == 약 41.36%의 효율 증가)

#3 DB 접근 횟수(쿼리 발생 횟수) : 100회 → 2회 처리 시간 : 233ms → 110ms (약 2.12배의 처리 속도 증가 == 약 52.79%의 효율 증가)

• 프로젝트 명: 404 Not Delivered

• 팀 작업 내용

  • 배달의 민족을 모방한 배달 애플리케이션 아웃소싱

2. Keep

1) 협업 내용 정하기

IDE 세팅을 비롯한 다양한 코딩 컨벤션(변수 및 메소드명, 인덴트 사이즈 등....)과
깃 커밋 메시지, 브랜치 전략 등을 사전에 정하고 프로젝트를 진행해서 일관성 있게 
진행할 수 있었던 것 같다.

2) 원활한 의사소통

의사소통하는데에 약 이틀을 사용할 정도로 많은 의사소통을 해서 시간이 모자를 줄 알았는데,
오히려 프로젝트 후반에 강점을 발휘해서 빨리 끝낼 수 있던 요소로 작용한 것 같다.

3) PR을 자주 작성하기

브랜치 전략은 작은 기능 단위로 가져가면서 PR 및 코드리뷰를 할 상황이 많이 발생했는데,
리뷰어의 시간이 적게 소모되고 기능 사용이 익숙해져서 좋았다.

4) 팀원 간 구현 내용 공유

각자 맡은 부분만 구현한 다음에 합치고 끝!이 아니라 각자 구현한 부분을 서로에게
설명하고 질문을 하는 식으로 프로젝트 전체의 흐름에 대해서 파악할 수 있었던 점이 좋았다.

3. Problem

1) 패키지 네이밍 실수

프로젝트를 생성할 때 잘못 만들어서 추후에 리팩토링을 하려고 했더니
예상치 못한 부분에 많은 에러가 발생했다. 처음부터 신경써서 제대로 만들어야겠다.

2) 성능 개선 미반영

중복 코드 및 미사용 코드, DB에서의 데이터 조회 등에 대한 코드들이 성능 개선을 
할 수 있는 부분이 남아있는 채로 마무리 했다. 조금 더 효율적이면서 빠른 프로그램이 
될 수 있도록 고민을 할 필요가 있을 것 같다. 

4. Try

1) Docker를 사용한 환경설정 제공

환경설정을 통일할 수 있고, 예기치 못한 상황이 발생해서 환경이 꼬이더라도
재설정하는데 큰 리소스가 필요하지 않기 때문에 사용해보면 좋을 것 같다. 

2) AOP를 통한 중복코드 제거

AOP와 커스텀 어노테이션을 사용한다면 인가, 로깅과 같은 중복이 발생할 수 있는 부분에
대해서 관리할 수 있기 때문에 가독성 및 유지보수 측면에서 효과를 기대할 수 있을 것 같다.

3) CI/CD 적용하기

이번 프로젝트에서는 서버 담당자가 직접 배포를 진행해서 공백이 발생할 수 있는 부분이 있었다.
그래서 코드 컨벤션 및 테스트 정상 작동, 서버 자동 배포 등 리소스를 아낄 수 있는 CI/CD를 적용해 보면 좋을 것 같다.

5. Feel

• 강세민 팀장으로서 부족했던 모습이 많았을 것 같은데 팀원 분들이 모두 좋은 분들이고 각자 맡은 바를 생각 이상으로 너무 잘들 해주셔서 즐겁게 프로젝트를 진행할 수 있었다.

• 김형준 서버 배포를 준비하느라 전체적인 작업 흐름에 개입을 하지 못했던 게 아쉬웠다. API 문서를 짜며 팀원들의 코드 자체와 각각의 흐름을 눈에 익힐 수 있었지만, 이를 어느 정도 늦은 타이밍에 알아챘기에 개입할 여지가 적었다.

  Github Actions를 통한 CD를 구현은 했지만 적용해보지 못한 게 아쉬웠다. 그래도 의사소통에 좀 더 적극적으로 참여해봤던 점, 서버 캐시를 사용하는 방식들에 대해 이해할 수 있었던 점, 팀원들의 코드를 이해할 확실한 방법을 익혀봤던 점이 좋았다고 생각한다.

• 임희현

    프로젝트를 진행하면서 어려운 점이 있을 때마다 팀원들과 의견 교환 및 공유를 통해 많이 배울 수 있어서 좋은 경험이었다.

• 최원준

    동료들이 참조할 엔티티와 기능을 빠르게 만들고 코드의 일관성 유지와 품질 향상을 위해 노력했다. 
    협업 도구와 함께 메모장과 스티커 노트 등으로 체계적으로 기록하고 관리하는 것이 작업 효율성을 높이는 데 중요하다는 것을 깨달았다. 
    새로운 기술은 빠르게 쓰고, 기존 도구와 기술은 꼼꼼하게 관리하도록 해야겠다.

• 홍은기

  프로젝트를 진행하는데 큰 어려움이 없었던 가장 큰 이유는 원활한 의사소통이라고 생각한다. 
  의사소통을 나누며 모자란 부분, 더 알게 된 부분들이 많기 때문에 다시 한 번 의사소통의 중요성에 대해 알게 되었다.

Interceptor VS AOP

과제에 제시된 구현 방법은 인터셉터와 AOP 두 가지였는데 나는 AOP를 선택하였다. Admin 사용자만 접근할 수 있는 API의 실행 전후에 로깅을 한다는 세부 구현의 내용이 좀 더 주제에 맞는 것 같다고 생각했다. 또한, 인터셉터를 사용할 경우엔 SecurityContextHolder 또는 HttpServletRequest에서 사용자의 인증 정보를 가져올 수 있는데 나도 모르게 스프링 시큐리티를 사용하고 있을 것 같다는 생각이 들어서 인터셉터를 배제한 이유도 있다.

AOP로 구현하기

횡단 관심사라는 것을 나타내기 위해 @Aspect를 사용하고, 메소드 호출 전 / 후에 로깅을 해야하기 때문에 @Around를 사용하였다. 그리고 Admin 사용자만 접근할 수 있는 API라는 조건이 주어졌기 때문에 @Pointcut을 사용해서 Aspect가 언제 적용될 지 정의하였다.

@Slf4j
@Aspect
@Component
@RequiredArgsConstructor
public class AdminApiLogging {
>
    private final ObjectMapper objectMapper;
>
    @Around("adminMethodA() || adminMethodB()")
    public Object adminApiLogging(ProceedingJoinPoint joinPoint) throws Throwable {
        HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest();
        HttpServletResponse response = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getResponse();
>
        ContentCachingRequestWrapper wrappedRequest = new ContentCachingRequestWrapper(request);
        ContentCachingResponseWrapper wrappedResponse = new ContentCachingResponseWrapper(response);
>
        String requestBody = getRequestBody(wrappedRequest);
        Long userId = (Long) request.getAttribute("userId");
>
        log.info("API Request Log - User ID : {}, Request Time : {}, URL : {}, RequestBody : {}",
                userId, LocalDateTime.now(), request.getRequestURL(), requestBody);
>
        // 원래 메소드 실행
        Object result = joinPoint.proceed();
>
        String responseBody = getResponseBody(wrappedResponse);
        log.info("API Response Log - User ID : {}, ResponseBody : {}", userId, responseBody);
>
        return result;
    }
>
    // 로깅에 Json 형식으로 출력하기 위해 requestBody / responseBody를 Json으로 변환하는 로직
    private String getRequestBody(ContentCachingRequestWrapper request) throws IOException {
        // 생략
    }
>
    private String getResponseBody(ContentCachingResponseWrapper response) throws IOException {
        // 생략
    }
>
    @Pointcut("execution(* org.example.domain.user.controller.UserAdminController.adminMethodA(..))")
    private void adminMethodA() {
    }
>
    @Pointcut("execution(* org.example.domain.comment.controller.CommentAdminController.adminMethodB(..))")
    private void adminMethodB() {
    }
}

Admin 사용자만 접근 가능한 API를 실행하면 전후에 로깅은 문제 없이 출력됐다. 그런데 RequestBody가 빈 값으로 출력되는 문제가 있었다.(반환 타입이 void인 API이기 때문에 ResponseBody는 빈 값으로 출력되는게 정상이다.)

RequestBody 값은 왜 비어있을까?

API를 실행하면 Postman에서도 200 응답이기 때문에 API가 요청 / 응답 자체에 문제가 있는 것은 아닌 것 같았다. 그래서 요청을 보냈을 때부터 API가 실행되기 직전(현재 설정해놓은 AOP의 적용 시점이 API 호출 전 / 후이기 때문에)까지의 과정을 알아볼 필요가 있었다. HttpSevletRequest는 ServletRequest를 상속 받고 있는데 ServletRequest에 getInputStream()이라는 메소드가 있었다.

getInputStream()은 ServletInputStream 타입인데 톰캣의 공식 문서를 확인해보면 다음과 같은 내용이 있다.

Provides an input stream for reading binary data from a client request, including an efficient readLine method for reading data one line at a time. 
With some protocols, such as HTTP POST and PUT, a ServletInputStream object can be used to read data sent from the client.
A ServletInputStream object is normally retrieved via the ServletRequest.getInputStream() method.
>
This is an abstract class that a servlet container implements. Subclasses of this class must implement the java.io.InputStream.read() method.

클라이언트의 요청을 읽기 위해 제공 되는 InputStream이라는 것인데, InputStream은 데이터를 읽어들이는 통로로서 한 번 사용하면 없어진다. 그러면 위에서 작성한 AOP에 도달하기 전에 어디선가 요청을 읽어들였다는 의미가 된다. Json 형태로 요청을 보냈다고 가정한다면 다음과 같은 처리 과정을 거치게 된다.

DispatcherServlet
     👇
HandlerAdapter
     👇
HttpMessageConverter(요청 소비)
     👇
AOP(예시에선 AdminApiLogging)
     👇
Controller

그림엔 나타나 있지 않지만 빨간 네모로 표시된 부분에서 HttpMessageConverter가 Json 요청을 자바 객체로 변환하기 위해 InputStream을 사용한다. 지금은 요청이 Json 형태라고 가정했기 때문에 MappingJackson2HttpMessageConverter가 InputStream을 사용하게 된다. 그리고나서 컨트롤러 호출 직전에 AOP가 실행되는데 이미 사용되고 없는 요청을 읽으니 빈 값이 출력되고 있었던 것이다.

어떻게 해야 여러 번 쓸 수 있을까?

로그에 빈 값이 출력되고 있는 원인을 알았으니 해결책을 찾아야 하는데 이미 스프링에 답이 있었다. ContentCachingRequestWrapper와 ContentCachingResponseWrapper인데, 내용을 살펴보면 다음과 같다.

HttpServletRequest wrapper that caches all content read from the input stream and reader, and allows this content to be retrieved via a byte array.
This class acts as an interceptor that only caches content as it is being read but otherwise does not cause content to be read. 
That means if the request content is not consumed, then the content is not cached, and cannot be retrieved via getContentAsByteArray().
>
Used, for example, by AbstractRequestLoggingFilter.

getContentAsByteArray()와 같은 메소드를 통해 InputStream을 소비하면 내부의 byte 배열에 캐싱하는데, 이렇게 캐싱된 요청 데이터는 몇 번이고 사용할 수 있게 되는 것이다.

그럼 어디에서 캐싱해야 할까?

요청 데이터는 스프링 내부에서 계속 사용될테니 클라이언트와의 연결점에서 가장 최전선에 있는 필터에서 캐싱을 하는 것이 좋다고 생각했다. 그래서 아래와 같이 요청과 응답을 캐싱하는 필터를 추가주었다.

@Component
public class ContentCachingFilter implements Filter {
>
    @Override
    public void doFilter(ServletRequest servletRequest, ServletResponse servletResponse, FilterChain filterChain) throws IOException, ServletException {
>
        HttpServletRequest wrappedRequest = new ContentCachingRequestWrapper((HttpServletRequest) servletRequest);
        HttpServletResponse wrappedResponse = new ContentCachingResponseWrapper((HttpServletResponse) servletResponse);
>
        try {
            filterChain.doFilter(wrappedRequest, wrappedResponse);
        } finally {
            ((ContentCachingResponseWrapper) wrappedResponse).copyBodyToResponse();
        }
    }
}

필터를 추가하면 다음과 같은 처리 과정을 거치게 된다.

ContentCachingFilter(요청을 소비하고 캐싱)
     👇
DispatcherServlet
     👇
HandlerAdapter
     👇
HttpMessageConverter
     👇
AOP(예시에선 AdminApiLogging)
     👇
Controller

API 로깅에 다시 출력해보자

사용자가 보낸 요청을 필터에서 사용하고 캐싱했기 때문에 이후의 처리 과정에서는 캐싱한 요청 데이터를 사용하면 된다. 지금 작성해 놓은 API 로깅 코드에서는 캐싱한 요청 데이터를 사용하고 있지 않기 때문에 수정이 필요하다.

@Slf4j
@Aspect
@Component
@RequiredArgsConstructor
public class AdminApiLogging {
>
    private final ObjectMapper objectMapper;
>
    @Around("adminMethodA() || adminMethodB()")
    public Object adminApiLogging(ProceedingJoinPoint joinPoint) throws Throwable {
        HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest();
        HttpServletResponse response = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getResponse();
>
        String requestBody = getRequestBody((ContentCachingRequestWrapper) request);
        Long userId = (Long) request.getAttribute("userId");
>
        log.info("API Request Log - User ID : {}, Request Time : {}, URL : {}, RequestBody : {}",
                userId, LocalDateTime.now(), request.getRequestURL(), requestBody);
>
        // 원래 메소드 실행
        Object result = joinPoint.proceed();
>
        String responseBody = getResponseBody((ContentCachingResponseWrapper) response);
        log.info("API Response Log - User ID : {}, ResponseBody : {}", userId, responseBody);
>
        return result;
    }
>
    // 로깅에 Json 형식으로 출력하기 위해 requestBody / responseBody를 Json으로 변환하는 로직
    private String getRequestBody(ContentCachingRequestWrapper request) throws IOException {
        // 생략
    }
>
    private String getResponseBody(ContentCachingResponseWrapper response) throws IOException {
        // 생략
    }
>
    @Pointcut("execution(* org.example.domain.user.controller.UserAdminController.adminMethodA(..))")
    private void adminMethodA() {
    }
>
    @Pointcut("execution(* org.example.domain.comment.controller.CommentAdminController.adminMethodB(..))")
    private void adminMethodB() {
    }
}

RequestBody도 문제 없이 출력되는 것을 확인할 수 있다. 지금은 Json 형태의 요청이라고 가정하며 만들었기 때문에 Json 이외의 요청, 에러 상황 등에 대해서는 제대로 동작하지 않을 수 있다. 하지만 RequestBody가 왜 빈 값이 출력되는지 알아보는 과정에서 스프링의 구조적인 부분에 대해 공부가 됐기 때문에 추가적인 구현이 필요하다고 해도 조금 더 수월하게 진행할 수 있지 않을까 생각한다.

✅ 출처 Spring AOP란? https://velog.io/@wnguswn7/Spring-AOPAspect-Oriented-Programming%EB%9E%80

HttpServletRequest 여러 번 읽기 https://www.baeldung.com/spring-reading-httpservletrequest-multiple-times

AOP를 사용해서 로깅하기 https://velog.io/@wnguswn7/Project-Spring-AOP%EB%A1%9C-%EB%A1%9C%EA%B7%B8-%EC%95%8C%EB%A6%BC-%EA%B8%B0%EB%8A%A5-%EA%B5%AC%ED%98%84%ED%95%98%EA%B8%B0

JPA가 관리하는 Entity로 만들기 위해서는 해당 클래스에 어노테이션을 활용해야함.

• @Entity
  • JPA가 관리할 객체라는 것을 명시
  • PK 값을 나타내는 @Id는 반드시 필요
  • 기본 생성자 필수
  • final, enum, interface, inner 클래스에는 사용 불가
  • 필드에 final 키워드 사용 불가

• @Table
  • 엔티티와 매핑할 테이블을 지정
  • name 속성을 사용하여 테이블 이름을 지정

    @Entity
    @Table(name = "car")
    public class Car {
    // PK
    @Id
    private Long id;
    >
    // 필드
    private String maker;
    >   
    private String model;
    >
    // 기본 생성자
    public Tutor() {
    }
    >
    public Tutor(Long id, String maker, String model) {
      this.id = id;
      this.maker = maker;
      this.model = model;
    }
    }

기본키

• @Id
  • 엔티티를 생성할 때 필수로 존재해야 하며, 단독으로 사용시 DB에 데이터를 저장할 때 ID값을 수동으로 설정해줘야 함
  • 가장 권장되는 방식은 Long 타입의 기본키를 사용하는 것
• @GeneratedValue
  • ID값을 자동으로 생성해주며, strategy 속성을 사용하여 다양한 설정 가능
    • GenerationType
      • IDENTITY : MySQL, PostgreSQL에서 사용하며, PK 자동 생성
      • SEQUENCE : Oracle에서 사용하며, @SequenceGenerator와 함께 사용
      • TABLE : 키 생성용 테이블을 사용하며, @TableGenerator와 함께 사용
      • AUTO : DB 종류에 따라 자동 지정하며 GenerationType의 기본값

필드 매핑

엔티티의 필드는 테이블의 컬럼과 매핑되며, 다양한 설정 가능

• @Column
  • 생략해도 DB 컬럼으로 매핑이 가능하지만, 다양한 옵션을 사용하기 위해 설정

    속성	설명	기본값
    name	객체 필드와 매핑할 테이블의 컬럼 이름 설정	객체 필드 이름
    nullable	DDL 생성 시 null 값의 허용 여부 설정	true(허용)
    unique	DDL 생성 시 유니크 제약 조건 설정	-
    columnDefinition	DDL 생성 시 컬럼 정보 설정	-
    length	DDL 생성 시 문자 길이 설정(String만 가능)	255
    insertable	설정된 컬럼의 INSERT 가능 여부	true
    updatable	설정된 컬럼의 UPDATE 가능 여부	true

• @Temporal
  • 날짜 타입을 설정
    • 객체 필드의 데이터 타입이 LocalDate, LocalDateTime인 경우에는 생략 가능

• @Enumerated
  • enum 값을 사용하기 위해 설정(DB에는 enum 타입이 없음)
    • 속성으로 value를 사용하며, 값으로는 enum의 이름을 저장하는 EnumType.STRING을 사용
    • 값이 추가될 때마다 순서가 변하기 때문에 enum의 순서를 저장하는 EnumType.ORDINAL은 사용하지 않음

• @Transient
  • DB 컬럼과 매핑하지 않을 때 사용

    @Entity
    @Table(name = "board")
    public class Board {
    @Id
    private Long id;
    >
    // @Column을 사용하지 않아도 DB 컬럼으로 매핑
    private Integer view;
    >
    // 객체 필드 이름과 DB 컬럼 이름을 다르게 설정 가능
    @Column(name = "title")
    private String bigTitle;
    >
    @Enumerated(EnumType.STRING)
    private BoardType boardType;
    >
    // longtext를 설정하면 VARCHAR()를 넘어서는 큰 용량의 문자열 저장 가능
    @Column(columnDefinition = "longtext")
    private String contents;
    >
    // 날짜 타입 (DATE, TIME, TIMESTAMP) 사용 가능
    @Temporal(TemporalType.TIMESTAMP)
    private Date createdDate;
    >
    // LocalDate를 사용했기 때문에 @Temporal 생략 가능
    private LocalDate lastModifiedDate;
    >   
    // 객체에선 필요하지만 DB에는 필요 없은 필드
    @Transient
    private int count;
    >
    public Board() {
    }
    }

    > >> 💡 hibearnate.hbm2ddl.auto 애플리케이션 로딩 시점에 JPA가 DDL을 생성하기 위해 필요한 설정 값. >> |설정값|설명| |:--|:--| |create|기존 테이블을 삭제(DROP)한 후 다시 생성(CREATE)| |create-drop|기존 테이블을 삭제(DROP)한 후 다시 생성(CREATE)하고 애플리케이션 종료 시점에 테이블을 삭제(DROP)| |update|엔티티에서 변경된 사항만 DDL에 반영(데이터 타입, 컬럼명 등)| |validate|엔티티와 테이블이 정상적으로 매핑 되었는지 확인하며, 실패 시 예외 발생| |none|속성을 사용하지 않는 것으로서 아무 변화 없음| ```java // application.properties에서의 사용 예시 hibernate.hbm2ddl.auto=create ```

연관관계

단방향

객체 간의 관계가 한쪽에서만 참조될 수 있는 관계. 설정이 단순하고 유지 관리가 쉬우며 불필요한 데이터 접근 방지 가능.

• 객체가 다른 객체를 참조
• N:1 관계일 경우, @ManyToOne, @JoinColume을 사용
• N에 해당하는 테이블(Tutor)의 외래키와 1에 해당하는 테이블(Company)의 PK를 @JoinColumn으로 매핑

  @Entity
  @Table(name = "tutor")
  public class Tutor {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
  >        
    private String name;
    // N:1 단방향 연관관계 설정
    @ManyToOne
    @JoinColumn(name = "company_id")
    private Company company;
  >
    // 기본 생성자, getter/setter
  }

양방향

객체 간의 관계가 양쪽에서 서로를 참조할 수 있는 관계. 양쪽에서 데이터에 쉽게 접근할 수 있지만, 관계를 관리할 때는 한쪽에서만 연관관계를 설정하거나 삭제하지 않도록 주의 필요.

• DB 관점에서는 연관관계에 방향의 개념이 없음
• 따라서 테이블에 변화는 없음
• 양방향 연관관계 설정을 위해 mappedBy 속성을 설정
  • Tutor → Company N:1 연관관계 (단방향)
  • Company → Tutor 1:N 연관관계 (단방향)
  • 단방향 연관관계 두 개로 양방향을 설정

@Entity
@Table(name = "tutor")
public class Tutor {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
>    
    private String name;
    // N:1 단방향 연관관계 설정
    @ManyToOne
    @JoinColumn(name = "company_id")
    private Company company;
>        
    // 기본 생성자, getter/setter
}

@Entity
@Table(name = "company")
public class Company {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
>
    private String name;
>        
    // null을 방지하기 위해 ArrayList로 초기화
    // Tutor 클래스의 company 필드와 매핑
    @OneToMany(mappedBy = "company")
    private List<Tutor> tutors = new ArrayList<>();
>        
    // 기본 생성자, getter/setter
}

양방향 연관관계의 주인

mappedBy는 양방향 연관관계 설정 시 연관관계의 주인이 아닌 쪽에 선언. 이를 통해 외래 키 관리 책임을 주인 엔티티에 두고 매핑이 중복되지 않도록 함.

• Tutor의 Company를 수정할 때 FK 수정
• Company의 Tutor를 수정할 때 FK 수정
• Tutor가 새로운 Company를 간다면
  • Tutor가 참조하는 Company 수정
  • Company가 참조하는 List<Tutor> 수정
  • DB 입장에서는 FK만 수정되면 되기 때문에 한 쪽에서만 FK를 관리해야함

• 양방향 연관관계 규칙
  1. 두 개의 엔티티 중 하나를 연관관계의 주인으로 설정해야 함
  2. 연관관계의 주인은 mappedBy 속성을 사용하지 않음
  3. 연관관계의 주인이 아니면 mappedBy 속성을 사용
  4. 연관관계의 주인이 아니면 조회만 가능
  5. 연관관계의 주인만 외래키를 관리(등록, 수정)

• 연관관계의 주인 선정 기준
  • 외래키가 있는 곳을 연관관계의 주인으로 지정
  • Company가 주인인 경우
    • Company를 수정할 때 Tutor를 수정하는 SQL이 실행되기 때문에 두 번의 SQL이 실행되어야 하므로 혼동되기 쉬움

• 상속
  • DB에는 상속 관계가 없음
  • 각각의 객체별로 데이터를 저장해야하고, JOIN을 사용해서 데이터를 조회해야 함
  • 데이터를 저장하고 조회하기 까다롭기 때문에 DB에 저장할 객체는 상속 관계를 사용하지 않음

• 연관관계
  • DB는 외래키를 사용하여 표현
  • 객체는 참조를 사용하여 표현

    // 데이터베이스 중심 객체 설계
    public class Tutor {
      private Long id; // PK
      private Long companyId; // FK
      private String name;
    }
    >
    public class Company {
      private Long id; // PK
      private String name;
    }

    // 객체 중심 설계
    public class Tutor {
      private Long id; // PK
      private Company company; // 참조 연관관계
      private String name;
    >        
      public Company getCompany() {
              return company;
      }
    >        
      public Company setCompany(Company company) {
              this.company = company;
      }
    }
    >
    public Company {
      private Long id; // PK
      private String name;
    }

Product product1 = productRepository.findById(productId);
Product product2 = productRepository.findById(productId);
>
product1 == product2; // false

• 객체의 비교
  • 데이터는 같지만, 새로운 인스턴스이기 때문에 주소값이 다름
  • Collection에 저장하면 문제를 해결할 수 있음

JPA

객체 지향 프로그래밍 언어인 Java와 관계형 데이터베이스 간의 패러다임 불일치 문제를 해결하여 데이터베이스 작업을 객체 지향적으로 수행할 수 있도록 지원. 대표적으로 Hibernate를 사용.

ORM(Object-Relational Mapping)

• 객체와 관계형 DB를 자동으로 매핑하여 패러다임 불일치 문제를 해결
• 개발자 대신 데이터베이스와 상호작용하는 역할을 수행

JPA를 사용하는 이유

• 생산성
• 유지보수성
• 패러다임 불일치 문제 해결
  • SQL 중심적인 개발에서 객체 중심으로 개발하기 때문에
• 성능 향상
  • 1차 캐시
  • 쓰기 지연
  • 지연 로딩
  • 즉시 로딩

영속성 컨텍스트

Entity 객체를 영속성 상태로 관리하는 일종의 캐시 역할을 하는 공간으로 여기에 저장된 Entity는 데이터베이스와 자동으로 동기화되며, 같은 트랜잭션 내에서는 동일한 객체가 유지됨.

Entity

• 데이터베이스에서 엔티티란 저장할 수 있는 데이터의 집합을 의미
• JPA에서 엔티티란 데이터베이스의 테이블을 나타내는 클래스를 의미

Entity 생명주기

Entity 상태

• 비영속(new/transient)
  • 영속성 컨텍스트가 모르는 새로운 상태
  • 데이터베이스와 전혀 연관이 없는 객체 > >
• 영속(managed)
  • 영속성 컨텍스트에 저장되고 관리되고 있는 상태
  • 데이터베이스와 동기화되는 상태 > >
• 준영속(detached)
  • 영속성 컨텍스트에 저장되었다가 분리되어 더 이상 기억하지 않는 상태
  • 영속성 컨텍스트가 제공하는 기능을 사용하지 못함

• 삭제(removed)
  • 영속성 컨텍스트에 의해 삭제로 표시된 상태
  • 트랜잭션이 끝나면 데이터베이스에서 제거

1차 캐시

• 엔티티를 영속성 컨텍스트에 저장할 때 생성되는 메모리 내 캐시
• 엔티티는 1차 캐시에 먼저 저장
  • 이후 같은 엔티티를 요청하면 DB를 조회하지 않음
  • 1차 캐시에서 데이터를 반환하여 성능을 높임
• 동일한 트랜잭션 안에서만 사용 가능
• 트랜잭션이 종료되면 영속성 컨텍스트는 삭제됨

• 새로운 엔티티를 영속시키면 1차 캐시에 저장됨 > >
• id가 1번인 엔티티를 조회하면, DB가 아닌 1차 캐시에서 데이터를 반환함 > >
• id가 2번인 엔티티를 조회하면, 1차 캐시에 해당 데이터가 없으므로 > >
• DB를 조회하고, 1차 캐시에 저장한 후 데이터를 반환함

동일성 보장

• 동일한 트랜잭션 안에서 특정 엔티티를 여러 번 조회해도 항상 같은 객체 인스턴스를 반환
• 1차 캐시를 사용하여 동일한 객체를 참조하게 하기 때문에 일관성 유지 가능
  

쓰기 지연

• 동일한 트랜잭션 내에서 생성된 SQL들을 Commit 시점에 한꺼번에 반영
  > > > >

변경 감지(Dirty Checking)

• 영속성 컨텍스트가 엔티티의 초기 상태를 저장하고 커밋 시점에 현재 상태와 비교하여 변경 사항이 있는지 확인하는 기능

• DB에서 조회한 데이터에 대해 스냅샷(snapshot) 저장 > >
• 커밋 시점에 엔티티와 스냅샷을 비교
• 변경 사항이 있다면 UPDATE 쿼리문을 생성하여 반영

flush

• 영속성 컨텍스트의 변경 내용을 데이터베이스에 반영하는 기능
• 변경된 엔티티 정보를 SQL로 변환해 데이터베이스에 동기화함
• 트랜잭션 커밋 시 자동으로 실행되지만, 특정 시점에 데이터베이스 반영이 필요하다면 수동으로 호출도 가능

KEEP

• Git 컨벤션 및 브랜치 전략
  • 프로젝트를 시작하기에 앞서 Git에 관련된 컨벤션(커밋 메시지, 브랜치 이름 정하기 등) 및 브랜치 전략(main / develop / 작업 브랜치)을 정했더니 작업하는데 있어 효율적이었던 것 같다.

• 페어 코드 리뷰
  • 내가 모르고 있던 내용이나 시야에 대해서 공유를 할 수 있기 때문에 페어를 정해서 코드 리뷰를 했던건 좋았던 것 같다. 짧은 일정이었지만 중간에 페어를 바꿨던 것도 좋았던 것 같다.

• AI 코드 리뷰어
  • 리뷰를 해준다는 것은 페어가 그만큼 시간과 에너지를 들여야한다는 것이기 때문에 최소한의 시간과 에너지만 쓸 수 있도록 사전에 AI가 코드를 리뷰를 해주는 것도 좋았던 것 같다. 전체적인 내용보다는 파일 단위로 리뷰를 해주기 때문에 반복적인 내용이 있고 적용하면 안되는 내용도 섞여있지만, 오타, 중복 코드, 변수 네이밍 등 쉽게 놓칠 수 있는 부분은 꽤나 잘 찾아주기 때문에 잘 사용하면 유용할 것 같다.

PROBLEM

• 코드 컨벤션
  • Git에 대해서는 컨벤션을 정했지만 코드에 대해서는 컨벤션을 정하지 않아서 코드를 합친 후에 리팩토링을 해야하는 등 리소스가 추가로 투입되었다. 각자의 코드 스타일이 다르기 때문에 사전에 디테일한 부분에 대해 컨벤션을 정했더라면 코드의 품질은 올라가면서 리소스는 적게 필요했을 것 같다는 생각이 들었다.

• 브랜치 전략
  • 프로젝트 시작 전에 브랜치 전략을 정했지만 프로젝트를 진행하면서 제대로 지켜지지 않은 부분이 있었다. 하나의 브랜치에서 너무 많은 기능을 구현한다거나, develop 브랜치에 반영하는 타이밍을 제대로 잡지 못해서 각각의 브랜치를 서로 pull 당겨서 작업을 한다던가 하는 문제가 있었다.

• 적절한 역할 분담
  • 각자의 진도 상황, 참여하고 있는 수준별 학습반 등 여러 부분에서 차이가 있었는데 그것을 고려하고 역할 분담을 나눴음에도 프로젝트를 진행하면서 일정에 대한 압박과 함께 적절하게 역할 분담이 되고 있는가에 대한 생각을 하게 되었다.

TRY

• 코드 컨벤션
  • 다음 프로젝트에는 코드의 품질은 올리고 투입되는 리소스는 줄일 수 있도록 사전에 코드 컨벤션을 정할 것이다. 얼마만큼 디테일하게 정해야하는지 감이 오지 않기 때문에 이번에 코드 컨벤션을 적용한 조의 멤버와 튜터님들에게 조언을 구해서 진행하면 좋을 것 같다.

• 브랜치 전략
  • 이번 프로젝트에서 진행 했던 브랜치 전략은 처음에는 그럴싸 했지만 마지막에는 그럴싸하지 못했다. 끝까지 그럴싸하지 못했다는 것은 운용법이 잘못 되었을 수 있다는 뜻이기도 하기 때문에 튜터님들에게 조언을 구해서 끝까지 잘 지킬 수 있는 전략을 시도해봐야 할 것 같다.

• 프로젝트 디렉토리 관리
  • 이번 프로젝트는 계층, 설정 등으로 디렉토리를 관리했는데 기능이 많지 않았음에도 불구하고 깔끔한 모양이 아니었다. 발표회에서 좋은 평가를 받았던 도메인을 기준으로 관리하는 방법을 다음에는 사용해야 할 것 같다.

현재 브랜치 상황은?

main (최종 브랜치)
┗ develop (개발 브랜치)
  ┣ post-api (뉴스피드 기능 브랜치)
  ┃ ┣ feature/xxxxx
  ┃ ┗ feature/xxxxx
  ┃
  ┗ user-api (사용자 기능 브랜치)
    ┣ feature/xxxxx
    ┗ feature/xxxxx

우리 조는 위의 예시처럼 브랜치를 운영하기로 정했다. 그래서 기능을 구현하기 전에는 해당하는 브랜치를 생성한 후 작업을 했어야 했다. 하지만 이렇게 git으로 작업하시는게 처음이시라 브랜치를 만들어야 한다는 것을 잊어버리셔서 git clone한 상태 그대로 develop 브랜치에 작업을 하시고 push까지 하셔서 develop 브랜치가 그대로 덮어써졌다. 그래도 다행인 점은 작업량이 많지 않은 시점이었다는 것이었다.

develop 브랜치 복구 방법은?

이미 push까지 진행된 상태였기 때문에 작업 내용을 임시로 저장할 수 있는 git stash를 사용할 수 없어서 아래와 같은 순서로 복구 작업을 진행했다.

// 현재까지의 작업 내용을 저장할 별도의 브랜치 생성
git branch <브랜치 이름>
>
// git log를 통해 이전 커밋의 해시 확인
git log
>
// git reset을 통해 이전 커밋으로 되돌리기
git reset --hard <이전 커밋 해시>
>
// 원격 저장소에 강제로 push
git push origin develop --force

프로젝트를 하게 되면 git에서의 실수가 발생할 것이라고 생각은 했는데 이렇게 바로 생길 줄은 몰랐어서 얘기를 듣고서는 당황을 좀 했던 것 같다. 그래도 작업량이 적었던 극초반에 발생해서 매를 먼저 맞는다는 생각으로 해결했던 것 같다. 작업 하기 전에 무조건 브랜치부터 만들어야 한다는 것을 잊지 않을 것 같다.

JWT

왜 Spring Security를 선택했나?

인증/인가에 대해서 튜터님들의 세션을 들을 때마다 Spring Security는 투자하는 노력에 비해 가성비가 좋지 않으니 지금은 신경 쓰지 않아도 된다라는 것이었다. 하지만 Spring Security를 사용하지 않고 구현하는 방법이 머릿 속에 그려지지 않아서 Spring Security를 사용하는 쪽으로 결정했다. 3~4년 전에 복붙 수준으로 한 번 만들어봤던 것이 전부였기 때문에 참고할 자료가 많았으면 좋겠다라고 생각을 했는데 대부분 Spring Security를 사용했기 때문에 정한 것도 이유 중에 하나다.

어떻게 만들 것인가?

JWT의 특징들에 대해서만 알고 있었기 때문에 예제 코드나 구현 내용을 설명해주는 강의 같은게 필요했는데, 인프런에서 튜토리얼을 다루는 강의를 찾게 되었고 하나씩 차근차근 따라해 나갔다. 그런데...

생각치 못한 버전 업그레이드

강의를 따라서 튜토리얼 코드를 구현 중에 하위 메소드가 나오지 않는 것이었다. 검색해보니 버전이 변경 되면서 Deprecated 된 메소드들이었던 것이다. Spring Security와 jjwt(JWT를 구현하기 위해 사용한 라이브러리)에서 버전을 확인하고 버전에 따른 구현 방법을 찾았는데, 잘 찾아지지 않아서 JWT를 사용하지 않아도 되는지 상담까지 생각했었다. 마지막이라는 생각으로 강의에 최신 코드가 반영된 부분이 있을까 하고 찾아봤는데 강사님께서 버전에 맞춰서 작성해주신 예제 코드가 깃허브에 있었다!

잘 진행된 코드 작성과 그렇지 못한 실행 결과

어떻게 동작하는지에 대한 이해는 잠시 제쳐두고 깃허브에 있는 내용을 기반으로 코드 작성을 했다. 예제 코드가 꼼꼼하게 작성되어 있었기 때문에 코드를 작성하는데는 문제가 없었다. 다만, Spring Security가 들어가다보니 작성해야 할 양이 이전에 구현했던 Session과 비교해서 몇 배는 많았다. 코드 작성을 다 끝낸후 떨리는 마음으로 실행을 했는데 문제 없이 동작했다. 남은 일은 로그인이 성공적으로 이루어지고 생성된 토큰 값이 확인되는 것이었는데 다음과 같은 에러가 발생하였다. 참고로 진행 중인 프로젝트에서는 이메일과 비밀번호를 이용해서 로그인을 한다.

[newsfeed] [nio-8080-exec-1] o.t.n.exception.GlobalExceptionHandler   : [BadCredentialsException] 500 INTERNAL_SERVER_ERROR : 자격 증명에 실패하였습니다.
>
// 상세 에러 내용
org.springframework.security.authentication.dao.AbstractUserDetailsAuthenticationProvider.authenticate(AbstractUserDetailsAuthenticationProvider.java:141)
org.springframework.security.authentication.ProviderManager.authenticate(ProviderManager.java:182)
org.team14.newsfeed.controller.AuthController.login(AuthController.java:38)

위의 에러 내용을 기반으로 검색해보니 토큰을 만들때 사용자가 요청으로 전달한 비밀번호가 아닌 암호화된 비밀번호를 전달할 경우 발생하기 때문에 암호화하기 이전의 비밀번호를 사용하면 해결된다고 했는데, 나는 이미 암호화하기 이전의 비밀번호를 사용하기 있었기 때문에 해당하는 내용이 아니었다.

그렇게 원인을 찾아 헤매고 있었는데 같은 에러를 겪으신 분과 해결 방법을 찾으신 분이 있어서 참고하며 해결했다.

BadCredentialsException의 원인

토큰이 제대로 생성되지 않았기 때문에 상세 에러 내용에 적혀있는대로 토큰을 생성해주는 메소드부터 하나씩 따라가보려고 한다.

토큰을 생성해주는 메소드로 들어가보면 인증을 관리하는 AuthenticationManager 인터페이스를 만나게 된다.

ProviderManager의 authenticate의 구현체로 이동해서 다시 한번 authenticate 메소드로 이동하면

AuthenticationProvider 인터페이스를 만나게 된다.

💡 ProviderManager는 AuthenticationManager, MessageSourceAware, InitializingBean 구현체이다.

AbstractUserDetailsAuthenticationProvider의 구현체로 이동하게 되면 에러 내용에서 봤던 BadCredentialsException을 만나게 된다! 하지만 아직 끝이 아니다. 에러가 발생한 지점을 찾았으니 원인을 찾아야한다. catch문에서 예외가 처리되고 있기 때문에 try문의 retrieveUser 메소드로 이동하면

이렇게 추상 클래스를 만나게 되고

구현체로 이동하게 되면 사용자 이름으로 사용자 정보를 조회하는 loadByUsername이라는 메소드를 만나게 된다.

그런데 위에서 지나치듯 언급했지만, 우리는 이메일로 로그인을 하고 싶은데 username으로 사용자 정보를 조회하기 때문에 에러가 발생한 것 같았다. 직접 코드를 실행시켜서 확인해보니 우려하던 결과가 실제로 눈앞에 보여지게 됐다.

BadCredentialsException의 해결 방법

이메일로 로그인 하고 싶었는데 username으로 조회하는 것이 원인이라는 것까지는 알았는데 어떻게 해결해야하나 고민이 되었다. 그런데 다행인 것은 loadUserByUsername 메소드가 인터페이스라는 것이다.

그렇다는 것은 UserDetailService를 implements하여 loadUserByUsername 메소드를 오버라이딩 할 수 있다는 것이다.

그런데 어떻게 Spring Security랑 연결해주지..?

제목과 같은 고민을 잠깐 했었는데 Spring Security에서는 SecurityAutoConfiguration 클래스에 의해 구성을 설정하는데, 사용자가 정의한 UserDetailsService가 있다면 우선적으로 사용하도록 한다고 한다. 그러니까 CustomUserDetailService를 만들어서 Bean으로 등록한 순간 우리의 역할은 끝난 것이다!

결과는?

원하던 결과를 문제없이 얻을 수 있었고, 이번 트러블 슈팅으로 인해서 왜 Spring Security를 사용하려면 많은 투자가 필요하다고 했는지 느끼게 됐다. 기회가 된다면 Spring Security 없이 JWT를 구현하는 것을 연습해 보면 좋을 것 같다고 생각했다.

그런데 말입니다

자격 증명에 실패했다는 에러를 해결할 수 있는 방법 중에 하나로 암호화하기 이전의 비밀번호(사용자가 입력한 비밀번호)를 사용하는 것이었는데 이것은 왜 그래야하는건지 궁금해졌다.

다시 이동해보자

위의 메소드 파고들기 여정에서 AbstractUserDetailsAuthenticationProvider의 authenticate까지는 동일하다. loadUserByUsername에서 에러가 발생하지 않았다면, 그 이후의 코드가 진행될 것이기 때문에 그 부분을 살펴볼 것이다.

이동하게 되면 추상 클래스인 AbstractUserDetailsAuthenticationProvider를 만나게 된다.

구현체로 이동하게 되면 익숙한 BadCredentialsException을 만나게 된다. BadCredentialsException이 발생하게 되는 조건을 자세히 보면 사용자가 입력한 비밀번호와 조회해온 사용자 정보의 비밀번호가 일치하는지 확인한다. 그렇기 때문에 사용자가 입력한 비밀번호를 그대로 전해주어야 했던 것이었다.

✅ 출처

• 인프런 JWT 튜토리얼 강의 https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81%EB%B6%80%ED%8A%B8-jwt/dashboard

• JWT 예제 코드 https://github.com/SilverNine/spring-boot-jwt-tutorial/tree/master

• JJWT 라이브러리 https://github.com/jwtk/jjwt

• Spring Security https://docs.spring.io/spring-security/reference/getting-spring-security.html https://docs.spring.io/spring-security/reference/servlet/authentication/passwords/user-details-service.html https://youtu.be/q3gT4198RKU

• 참고 블로그 https://yoonsys.tistory.com/33 https://ming412.tistory.com/302

Token

Web Application이나 API에서 인증(Authentication)과 인가(Authorization) 과정에서 사용되며 사용자 또는 시스템의 신원과 권한을 증명하고 요청의 유효성을 검증하는 데 사용되는 디지털 문자열.

• Token의 장점
  • Token은 서버가 아닌 클라이언트에 저장되어 서버의 부담이 적음
  • Cookie는 웹 브라우저에만 존재하기 때문에 모바일 앱 등의 다양한 클라이언트에서 인증 처리 불가
  • Token 방식은 Stateless 기반이기 때문에 확장성이 뛰어남
  • 인증된 사용자임을 확인하기 위한 고유한 서명을 포함하여 위조된 요청인지 확인 가능
• Token의 단점
  • Cookie/Session 방식보다 많은 데이터 용량
    • 요청이 많아질 시, 트래픽 증가
  • Payload(전송되는 데이터)는 암호화되지 않아서 중요한 데이터를 담기에 어려움
  • Token을 탈취당하면 대처하기 어려움
    • 만료 시간(기본값 : 30분)을 설정
• Token의 동작 순서
  • Token 생성 시 사용자의 고유한 정보 포함
  • 데이터베이스에 접근하지 않고 Token의 유효성만 검증
    

JWT

인증에 필요한 정보들을 암호화시킨 JSON 형태의 Token을 의미. JSON 데이터 포맷을 사용하여 정보를 효율적으로 저장하고 암호화로 서버의 보안성 향상.

• JWT Encoding / Decoding
• JWT 구조

  XXXXXX.YYYYYY.ZZZZZZ
  (Header).(Payload).(Signature)

• Header
  • 토큰의 타입과 해싱 알고리즘 정의

    {
    "alg": "HS256",
    "typ": "JWT"
    }

• Payload
  • 실제로 인증과 관련된 데이터(Claims) 포함
  • Claims의 종료
    • Registered Claims : 미리 정의된 Claims
      • iss(issuer) : 발행자
      • exp(expiration time) : 만료시간
      • sub(subject) : 제목
      • iat(issued At) : 발행 시간
      • jti(JWT ID) : 토큰의 고유 식별자
    • Public Claims : 사용자가 정의할 수 있는 Claims이며, 공개용 정보 전달이 목적
    • Private Claims : 사용자 지정 Claims, 당사자들 간의 정보를 공유하기 위한 목적

      {
      "sub": "1234567890",
      "name": "Sparta",
      "exp": 1682563600
      }

• Signature
  • Header와 Payload를 서버의 Secret Key로 서명하여 암호화
  • 암호화는 Header에서 정의한 알고리즘을 활용
  • 서버는 서명을 통해 Token의 변조 여부를 확인 가능

    HMACSHA256(
    base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
    secret
    )

    💡 base64UrlEncode는 URL에서 사용할 수 있도록 +, / 값을 각각 -, _로 표기

    💡 Header와 Payload는 Encoding된 값이기 때문에 복호화 혹은 값을 수정할 수 있지만 Signature는 서버에서 관리하는 값이기 때문에 Secret Key가 유출되지 않는 이상 복호화 불가능

JWT 인증

JWT는 Base64로 인코딩되어 쉽게 복호화 할 수 있고, Payload가 그대로 노출되기 때문에 비밀번호나 민감한 정보를 저장하지 않음.

• JWT 인증 과정
  • 클라이언트의 로그인 요청
  • 로그인에 성공하면 Signature 생성
    • 이후 Base64로 Encoding 실행
    • 일반적으로 Cookie에 담아서 클라이언트에게 발급
  • 서버에 요청을 보낼 때 Authorization Header에 발급 받은 JWT를 포함
  • 서버에서 JWT의 유효성 검사를 통과하면 요청 처리
    • JWT 만료, 위변조 여부 검사
      > >
• JWT의 유효성 검사
  • A의 JWT를 B가 탈취
  • B가 탈취한 JWT를 임의로 수정
  • B가 수정한 JWT로 Server에 요청
  • 서버는 Signature를 사용하여 유효성 검사
    • Header, Payload, 서버의 Secret Key값으로 만든 Signature와 비교하기 때문에 조작된 데이터 판별 가능
      > >>💡 JWT의 목적은 정보 보호가 아닌, **위조 방지**

JWT 장단점

• JWT 장점
  • Signature로 서버의 보안성 증가
  • Token에 필요한 정보(유저 및 검증 정보)가 모두 존재
  • 서버는 인증 정보와 관련된 별도의 저장소를 사용하지 않음
  • 서버의 수평 확장성(Scale Out) 증가
  • Cookie가 없는 다른 환경에서도 인증/인가 적용 가능
  • DB를 조회하지 않아도 됨
• JWT 단점
  • Payload는 암호화 되어 있지 않기 때문에 민감한 정보를 다루지 못함
  • Token의 길이가 길어서 트래픽이 증가하면 네트워크 부하가 증가함
  • 클라이언트 측에서 Token을 관리하기 때문에 탈취당하면 대처가 힘듦

Access Token, Refresh Token

Token은 클라이언트에서 관리하여 탈취당할 위험성이 높기 때문에 만료 시간 설정이 필요. 이 때 발생하는 단점을 극복하기 위해 Access Token과 Refresh Token 사용.

• Access Token
  • 사용자 인증 후 서버가 발급하는 유저 정보가 담긴 토큰
  • 유효 기간 동안 API나 리소스에 접근할 때 사용
  • 보안을 위해 짧은 수명을 가짐
• Refresh Token
  • Access Token이 만료된 경우 재발급 받기위해 사용
  • 주로 데이터베이스에 유저 정보와 같이 저장
• Access Token, Refresh Token 인증
  • 클라이언트의 로그인 요청
  • 로그인에 성공하면 Signature 생성
  • 서버에 요청할 때 Authorization Header에 JWT(Access Token)를 포함
  • 서버에서 JWT의 유효성 검사를 통과하면 요청 처리
  • Access Token이 만료 되었다면 Refresh Token 으로 토큰 재발급 요청
  • 서버로부터 Access Token을 재발급 실행
    > >>💡 JWT를 Access Token만을 사용하여 인증한다면 탈취되었을 때 보안에 취약. 유효 시간을 부여하여 문제를 해결하지만 유효 시간이 짧은 경우, 로그인을 자주 해야하기 때문에 Refresh Token 적용.

Filter

공통 관심 사항(cross-cutting concerns)

횡단 관심사라고도 하며 여러 위치에서 공통적으로 사용되는 부가 기능을 의미.

• 핵심 기능(비즈니스 로직)
  >
• 부가 기능(비즈니스 로직과는 별개로 동작하는 기능) > >
• Spring AOP 활용 가능
• Web과 관련된 공통 관심사는 Servlet Filter나 Spring Interceptor를 사용
  • HttpServletRequest 객체를 제공하기 때문에 HTTP 정보나 URL 정보에 접근이 용이

    💡 AOP(Aspect-Oriented Programmin, 관점 지향 프로그래밍)란? 핵심 관심사(Core Concerns)와 횡단 관심사(Cross-cutting Concerns)를 분리하여 가독성과 모듈성을 증진시킬 수 있는 프로그래밍 패러다임

Servlet Filter

Servlet Filter는 보안, 로깅, 인코딩, 인증/인가 등 다양한 작업을 처리하기 위해 사용.

• Servlet Filter 특징
  • 공통 관심사 로직 처리
    • 공통된 로직을 중앙 집중적으로 구현하여 재사용성이 높고 유지보수가 쉬움
    • 모든 요청이 하나의 입구를 통해 처리되어 일관성 유지
  • HTTP 요청 및 응답 필터링
  • Filter Chain
    • 여러 개의 필터를 순차적으로 적용 가능
  • doFilter()
    • 실제 필터링 작업을 수행하는 주요 메소드
    • 다음 필터로 제어를 넘길지 결정

• Servlet Filter 적용
  • Filter를 적용하면 Servlet이 호출되기 이전에 항상 Filter를 거치게 됨
  • 공통 관심사를 필터에만 적용하면 모든 요청 / 응답에 적용됨
  • 특정 URL Pattern에 적용 가능
  • Spring에서 Servlet은 Dispatcher Servlet을 의미
  • 필터를 통과하지 못하면 컨트롤러를 호출하지 않음
    >
• Filter Chain
  • Filter는 Chain 형식으로 구성
  • 개발자가 자유롭게 추가할 수 있으며, 순서도 지정 가능
    

Filter Interface

Java Servlet에서 HTTP 요청과 응답을 가로채고, 이를 기반으로 다양한 처리 작업을 수행하는 데 사용되는 인터페이스.

• jakarta.servlet.Filter
  • Filter Interface를 Implements하여 구현하고 Bean으로 등록하여 사용
    • Servlet Container가 Filter를 Singleton 객체로 생성 및 관리
• 주요 메소드
  • init()
    • 필터를 초기화하며, Servlet Container가 생성될 때 호출
    • default 메소드이기 때문에 구현하지 않아도 됨
  • doFilter()
    • 클라이언트에서 요청이 올 때 마다 호출
      • doFilter() 내부에 필터 로직(공통 관심사 로직)을 구현
    • WAS에서 doFilter() 를 호출해주고 하나의 필터의 doFilter()가 통과된다면, 필터 체인의 순서에 따라서 doFilter() 를 호출
    • 더이상 호출할 필터가 없으면 Servlet 호출
  • destroy()
    • 필터를 종료하는 메소드로서 Servlet Container가 종료될 때 호출
    • default 메소드이기 때문에 구현하지 않아도 됨

      💡 ServletRequest는 기능이 별로 없기 때문에 대부분 기능이 많은 HttpServletRequest를 다운 캐스팅하여 사용

✅ 알고리즘 & SQL 코드카타 💡 오늘 알고리즘 문제는 조합에 관련된 문제였다. 조합이라는 것을 들었을 때 생각나는 것과 조금 다른 패턴이어서 로직을 생각해내는데 어려웠던 것 같다. 비슷한 유형을 많이 풀어보면서 다음에 나오면 바로 생각해 낼 수 있도록 해야할 것 같다. SQL에서도 서브쿼리를 활용한 계산, 조인을 활용한 계산 등이 많이 나오고 있어서 익숙해질 수 있도록 해야할 것 같다.

✅ 미니 프로젝트 1일차 💡 새로운 팀원들과 프로젝트 진행에 관해서 많은 얘기를 나눴다. 다들 적극적으로 의견을 내고 반응해서 잘 진행될 수 있었던 것 같다. 양해를 구하고 평소에 해보고 싶었던 Git ↔ Slack 연동과 Github Action을 통한 AI Code Reviewer를 설정했다. Slack과의 연동은 제대로 된 것을 확인했는데, AI Code Reviewer는 에러는 해결했지만 제대로 동작하는지는 진행하면서 살펴봐야할 것 같다. 튜터님께서도 사용해보는 것에 긍정적인 답변을 주셨는데 2가지를 당부하셨다. 첫 번째는 AI Code Reviewer의 결과를 공유하는 것, 두 번째는 팀원들끼리도 코드 리뷰를 하는 것이다. 코드 리뷰를 통해 얻어갈 수 있는게 많기 때문에 말씀하신 것 같다. 또, 언제 어떻게 발생할 지 모르기 때문에 트러블 슈팅을 잘 해놓으려고 한다. 그래서 이번에는 나한테서 발생한 트러블에 한정하지 않고, 팀 전체로 확장하려고 한다.

✅ 스프링 과제 리팩토링 및 제출 💡 수준별 학습반 세션을 들으면서 이건 과제에 적용해야겠다라고 메모해 놨던 부분들을 수정했다. 개인적인 욕심으로 API 명세서를 레벨별로 작성하느라 시간이 오래걸리긴 했지만 하고자 했던 부분들을 시간 안에 마무리해서 만족스러웠다.

✅ 세션 및 발제 참여 💡 과제 제출 후 과제 해설 세션, 미니 세션(쿠키 / 세션), 출결 관리 관련 발제에 참여했더니 오후 시간이 사라져 있었다.....

✅ 셀프 피드백 적용 💡 과제 해설 세션을 보면서 저렇게 할 수도 있구나 하는 부분이 몇몇 있었지만, 바로 적용하고 싶었던 부분은 프로젝트 구조였다. 내 과제는 계층별로 구분되어 있어서 요구 사항이 하나 추가될때마다 패키지가 늘어나서 뭐가 엄청 많았는데, 튜터님은 기능별로 구분하셔서 엄청 깔끔했기 때문이다.

에러(1)

Mapping Miss

코드를 짜고 스프링을 실행시켰는데 아래와 같은 에러가 발생했다.

Error starting ApplicationContext. To display the condition evaluation report re-run your application with 'debug' enabled.
2024-12-19T00:08:38.141+09:00 ERROR 26196 --- [develop_todo] [           main] o.s.b.d.LoggingFailureAnalysisReporter   : 
>
***************************
APPLICATION FAILED TO START
***************************
>
Description:
>
Invalid mapping pattern detected:
/{/id}
  ^
Expected close capture character after variable name }
>
Action:
>
Fix this pattern in your application or switch to the legacy parser implementation with 'spring.mvc.pathmatch.matching-strategy=ant_path_matcher'.
>
Disconnected from the target VM, address: '127.0.0.1:62780', transport: 'socket'
>
Process finished with exit code 1

처음에는 Expected close capture character after variable name } 내용만 보고 괄호 문제인줄 알고 코드 정렬을 했다. 에러가 발생한 파일명도 없어서 모든 파일에 대해서 했다. 하지만 그래도 해결되지 않았다. 에러를 다시 자세히 살펴보니 유효하지 않은 매핑 패턴이 있다는 것이다. 친절히 알려준 {/id}로 검색해보니 HttpMethod 매핑 부분에 오타가 있었다. 오타를 고치고 나니 문제 없이 실행되었다.

@GetMapping("{/id}")
public ResponseEntity<Map<String, TodoResponseDto>> findById(@PathVariable Long id) {
    ...
}
>
👇 오타 수정 후
>
@GetMapping("/{id}")
public ResponseEntity<Map<String, TodoResponseDto>> findById(@PathVariable Long id) {
    ...
}

에러(2)

Annotation Miss

Validation을 추가하고 제대로 동작하는지 Postman으로 확인하는데 아래와 같은 에러가 발생했다.

2024-12-19T00:21:33.577+09:00 ERROR 1460 --- [develop_todo] [nio-8080-exec-3] o.a.c.c.C.[.[.[/].[dispatcherServlet]    : Servlet.service() for servlet [dispatcherServlet] in context with path [] threw 
exception [Request processing failed: jakarta.validation.UnexpectedTypeException: HV000030: No validator could be found for constraint 'jakarta.validation.constraints.NotBlank' validating type 'java.lang
.Long'. Check configuration for 'userId'] with root cause
>
jakarta.validation.UnexpectedTypeException: HV000030: No validator could be found for constraint 'jakarta.validation.constraints.NotBlank' validating type 'java.lang.Long'. Check 
configuration for 'userId'
    at org.springframework.validation.beanvalidation.SpringValidatorAdapter.validate(SpringValidatorAdapter.java:105) ~[spring-context-6.2.0.jar:6.2.0]
    at org.springframework.boot.autoconfigure.validation.ValidatorAdapter.validate(ValidatorAdapter.java:67) ~[spring-boot-autoconfigure-3.4.0.jar:3.4.0]
    at org.springframework.validation.DataBinder.validate(DataBinder.java:1358) ~[spring-context-6.2.0.jar:6.2.0]
    at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:590) ~[tomcat-embed-core-10.1.33.jar:6.0]
    at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:885) ~[spring-webmvc-6.2.0.jar:6.2.0]
    at jakarta.servlet.http.HttpServlet.service(HttpServlet.java:658) ~[tomcat-embed-core-10.1.33.jar:6.0]
    at org.example.develop_todo.lv8.filter.LoginFilter.doFilter(LoginFilter.java:41) ~[main/:na]

userId에 설정한 @NotBlank가 제대로 동작하지 않는다는 것이었다. userId는 Long 타입이었는데, @NotBlank는 문자열(CharSequence)만 허용하기 때문이었다. userId에 null값이 들어오는지 확인하기 위해서는 @NotNull을 사용해야했다. @NotNull은 모든 타입을 허용한다.

학습하게 된 내용

JPA 페이징

JPA를 사용하여 페이징을 간단히 설정할 수 있는데, 사용법을 정리해놓으려고 한다.

// Controller
// 페이징에 필요한 페이지 번호와 페이지 크기를 QueryParam으로 요청 받음
@GetMapping("/cars")
public ResponseEntity<List<CarPagingDto>> findAllCar(
        @RequestParam(defaultValue = "0") int pageNum, // 페이지 번호
        @RequestParam(defaultValue = "10") int pageSize // 페이지 크기
) {
    Page<CarDto> carPagingDtoList = carService.findAllCar(pageNum, pageSize);
    return new ResponseEntity<>(carPagingDtoList, HttpStatus.OK);
}

// Serivce
public List<CarPagingDto> findAllCar(int pageNum, int pageSize) {
    Pageable pageable = PageRequest.of(pageNum, pageSize); // pageable 객체 생성
    Page<Car> foundAllCarList = carRepository.findAllByOrderByCreatedAtDesc(pageable); 
>
    return foundAllCarList.stream().map(CarPagingDto::toDto).toList(); // Dto로 매핑해서 반환
}

// Repository
@Repository
public interface CarRepository extends JpaRepository<Car, Long> {
    // 페이징을 적용할 쿼리 메소드 추가
    // 생성일을 내림차순으로 갖는 전체 목록 조회
    Page<Car> findAllByOrderByCreatedAtDesc(Pageable pageable); 
}

✅ 이번에는 큼직큼직한 에러보다는 잔실수로 인한 에러가 많았던 것 같다. 오타가 나지 않도록 조금 더 신경써야할 것 같고, 어노테이션을 사용할 때는 사용법에 대해서 좀 더 확실하게 숙지한 후에 사용해야겠다는 생각을 하게 되었다.

✅ 출처 및 참고 https://docs.jboss.org/hibernate/validator/8.0/reference/en-US/html_single/#section-builtin-constraints https://chaeyami.tistory.com/245

• 인증(Authentication)
  • 사용자가 누구인지 확인하는 과정 ex) 로그인
• 인가(Authorization)
  • 사용자가 어떤 권한을 가지고 있는지 결정하는 과정
  • 인증 선행 필수 ex) 회원만 조회 가능한 게시글, 본인이 작성한 게시글 수정

Cookie

사용자의 웹 브라우저에 저장되는 정보로 사용자의 상태 혹은 세션을 유지하거나 사용자 경험을 개선하기 위해 사용. 사용자 세션 관리(로그인, 장바구니, 접속 시간), 광고 트래킹(사용자 행동)등이 포함됨.

Cookie

• 쿠키를 사용하는 이유
  • HTTP는 Stateless, Connectionless 특성을 가지고 있기 때문에 Client가 재요청시 Server는 이전 요청에 대한 정보를 기억하지 못함
  • 로그인과 같이 상태를 유지해야 하는 경우 발생
  • Request에 사용자 정보를 포함하면 해결
    • 로그인 후에는 사용자 정보와 관련된 값이 저장되어 있어야 함
  • 브라우저를 완전히 종료한 뒤 다시 열어도 사용자 정보가 유지되어야 함

    💡 쿠키의 위치 브라우저 개발자 도구(F12) → Application → Cookies

• 로그인 성공시 응답
  • Set-Cookie
  • 로그인시 전달된 ID, Password로 User 테이블 조회하여 일치여부 확인
  • 일치한다면 Set-Cookie를 활용해 Cookie에 사용할 값 저장
• 로그인 이후 요청
  • 요청 헤더 Cookie : 사용자 정보
  • 로그인 이후의 모든 요청에는 Request Header에 항상 Cookie 값을 추가
    • 네트워크 트래픽이 추가적으로 발생
    • 최소한의 정보만 사용 해야 함
  • Cookie에 담겨있는 값으로 인증/인가를 진행

Cookie Header

서버에서는 HTTP 응답 헤더에 Set-Cookie 속성을 사용해 생성하고 설정할 수 있음.

• Cookie Header
  • Set-cookie
    • Server에서 Client로 Cookie 전달(Response Header)
  • Cookie
    • Client가 Cookie를 저장하고 HTTP 요청시 Server로 전달(Request Header)

// Response 알아보기
set-cookie: 
sessionId=abcd; 
expires=Sat, 11-Dec-2024 00:00:00 GMT;
path=/; 
domain=abcde.com;
Secure

• Cookie의 생명주기
  • 세션 Cookie
    • 만료 날짜(expires, max-age)를 생략하면 브라우저 완전 종료시 까지만 유지(Default)
    • 브라우저를 완전 종료 후 다시 페이지를 방문했을 때 재로그인 필요
  • 영속 Cookie
    • 만료 날짜를 입력하면 해당 날짜까지 유지
      • expires=Sat, 11-Dec-2024 00:00:00 GMT; (해당 만료일이 되면 쿠키가 삭제됨)
      • max-age=3600 (초단위, 0이 되거나 음수를 지정하면 쿠기가 삭제됨)
• Cookie의 도메인
  • 쿠키가 아무 사이트에서나 생기고 동작하면 안되기 때문에 설정
    • 필요없는 값 전송, 트래픽 문제 등이 발생
    • domain=abcde.com를 지정하여 쿠키를 저장
    • dev.abcde.com와 같은 서브 도메인에서도 쿠키에 접근
  • domain을 생략하면 현재 문서 기준 도메인만 적용
• Cookie의 경로
  • 1차적으로 도메인으로 필터링 후 Path 적용
  • 일반적으로 path=/ 루트(전체)로 지정
  • 위 경로를 포함한 하위 경로 페이지만 쿠키에 접근
    • path=/api 지정
      • path=/api/example 가능
      • path=/example 불가능
• Cookie 보안
  • Secure
    • 기본적으로 Cookie는 http, https 구분하지 않고 전송
    • Secure를 적용하면 https인 경우에만 전송
  • HttpOnly
    • XSS(Cross-site Scripting) 공격 방지
      • 악성 스크립트를 웹 페이지에 삽입하여 다른 사용자의 브라우저에서 실행되도록 하는 공격
    • 자바스크립트에서 Cookie 접근 불가
    • HTTP 요청시 사용
  • SameSite
    • 브라우저 지원 여부 확인필요
    • CSRF(Cross-Site Request Forgery) 공격 방지
      • 사용자가 의도하지 않은 상태에서 특정 요청을 서버에 전송하게 하여 사용자 계정에서 원치 않는 행동을 하게 만듦
    • 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키 전송

Cookie의 문제점

• 쿠키 값을 임의로 변경 가능
  • Client가 임의로 쿠키의 값을 변경하면 서버는 다른 유저로 인식
    • 브라우저 개발자도구(F12) → Application → Cookies → 값 수정 가능
• Cookie에 저장된 Data는 탈취되기 쉬움
  • 네트워크 전송 구간에서 탈취될 확률 매우 높음
    • HTTPS를 사용하는 이유 중 하나
    • 민감한 정보를 저장하면 안됨
  • 한번 탈취된 정보는 변경이 없다면 반영구적으로 사용 가능

• 대처 방법
  • 쿠키에 중요한값을 저장하지 않음
  • 일반 유저나 해커들이 알아보지 못하는 값을 노출
    • 일반적으로 암호화된 Token을 쿠키에 저장
    • 서버에서 암호화된 Token과 사용자를 매핑해서 인식
    • Token은 서버에서 관리
  • 토큰은 해커가 임의의 값을 넣어도 동작하지 않도록 만들어야 함
  • 토큰이 탈취 당해도 사용할 수 없도록 토큰 만료시간을 짧게 설정
  • 탈취가 의심되는 경우 해당 토큰을 강제로 만료시킴
    • 접속기기 혹은 IP가 다른 경우 등

Session

Session

Cookie를 사용한 방식은 여러가지 보안 문제가 있기 때문에 중요한 정보는 모두 서버에서 저장. Client와 서버는 예측 불가능한 임의의 값으로 연결.

• Session 생성 순서
  • 로그인에 성공하면 Server에서 임의로 만든 Session ID를 생성
    • Session ID는 예측 불가능 해야 함(ex. UUID)
  • 생성된 Session ID와 조회한 User 인스턴스를 서버의 Session 저장소에 저장
    • 서버에 유저와 관련된 중요한 정보를 저장
• Session 동작 순서
  • 로그인
    • 상태유지를 위해 Cookie 사용
      • 서버는 클라이언트에 Set-Cookie: SessionId=임의생성값 을 전달
      • 클라이언트는 Cookie 저장소에 전달받은 SessionId 값을 저장
  • 로그인 이후 요청
    • 클라이언트는 모든 요청에 Cookie의 SessionId를 전달
    • 서버에서는 전달된 SessionId로 Session 저장소를 조회
    • 로그인 시 저장하였던 Session 정보를 서버에서 사용

• Session 특징
  • Session을 사용하여 서버에 민감한 정보를 저장
    • 예측이 불가능한 세션 ID를 사용하여 쿠키값을 변조해도 문제 없음
    • 세션 ID에 중요한 정보는 포함되어 있지 않음
    • 시간이 지나면 세션이 만료되도록 설정
    • 해킹이 의심되는 경우 해당 세션을 제거
  • 데이터를 저장하는 곳이 클라이언트가 아닌 서버라는 것이 쿠키와 다른 점
  • Servlet은 Session을 자체적으로 지원

Spring의 Session

• @SessioinAttribute
  • 세션을 새로 생성하는 기능은 없음
  • 이미 로그인이 완료된 사용자를 찾는 경우, 즉 세션이 있는 경우에 사용

    @Controller
    @Requiredargsconstructor
    public class SessionHomeController {
    private UserService userService;
    >
    @GetMapping("/v2/session-home")
    public String homeV2(
          // 로그인 여부를 확인해야하므로 required = false
          @SessionAttribute(name = Const.LOGIN_USER, required = false) UserResponseDto loginUser,
          Model model) {
      // session에 loginUser가 없으면 Login 페이지로 이동
      if (loginUser == null) {
          return "session-login";
      }
      // Session이 정상적으로 조회되면 로그인된것으로 간주
      model.addAttribute("loginUser", loginUser);
      // home 화면으로 이동
      return "session-home";
    }
    }

• HttpSession
  • 세션을 간편하게 사용할 수 있도록 다양한 기능 지원

    @Slf4j
    @RestController
    public class SessionController {
    @GetMapping("/session")
    public String session(HttpServletRequest request) {
      HttpSession session = request.getSession(false);
    >
      if (session == null) {
          return "세션이 없습니다.";
      }
    >
      // jsessionId 값 조회
      log.info("session.getId()={}", session.getId());
      // 세션의 유효 시간(초단위, 기본값은 1800)
      log.info("session.getMaxInactiveInterval()={}", session.getMaxInactiveInterval());
      // 세션 생성 시간
      log.info("session.getCreationTime()={}", session.getCreationTime());
      // 해당 세션에 마지막으로 접근한 시간
      log.info("session.getLastAccessedTime()={}", session.getLastAccessedTime());
      // 새로 생성된 세션인지 확인
      log.info("session.isNew()={}", session.isNew());
      return "세션 조회 성공!";
    }
    }

Session TimeOut

Session은 logout 기능을 사용하여 session.invalidate(); 가 되어야 삭제되지만 대부분의 사용자들은 로그아웃을 굳이 하지않고, 브라우저를 종료함.

• Session의 문제점
  • HTTP는 Connectionless 특성을 가지고 있어서 서버가 브라우저의 종료 여부 판별 불가
  • 서버에서 언제 세션을 삭제해야 하는지 판단 불가
  • JSESSIONID의 값을 탈취 당한 경우 해당 값으로 악의적인 요청 가능
  • 세션은 서버 메모리에 생성되고 자원은 한정적이기 때문에 꼭 필요한 경우만 생성 필요

• Session 생명 주기
  • 기본적으로 30분을 기준으로 삭제
  • 실제 로그인 후 30분 이상의 시간동안 사용중인 사용자의 세션도 삭제됨
    • 재로그인 해야 하는 경우 발생

• HttpSession 사용
  • 세션 생성 시점으로부터 30분이 아닌 서버에 최근 Session을 요청한 시간을 기준으로 30분 유지

Session의 한계

Session은 서버의 메모리를 사용하여 확장성이 제한됨.

• 서버가 DB 혹은 메모리에 저장된 세션 정보를 매번 조회하여 오버헤드 발생
• 서버가 상태를 유지해야 하므로 사용자 수가 많아질수록 부담 증가
• Cookie는 웹 브라우저에만 존재하여 모바일 앱 등의 다양한 클라이언트에서 인증 처리 불가
• Scale Out(수평적 확장)에서 서버간 세션 공유가 여려움 > >>💡 오버헤드(Overhead)란? 어떤 처리를 하기 위해 들어가는 간접적인 처리 시간, 메모리 등을 의미한다.

✅ 알고리즘 & SQL 코드카타 💡 요즘 알고리즘 문제가 아니라 수학 문제를 푸는 것 같다. 문제에 설명이 없어서 검색해서 풀었다. SQL은 JOIN을 쓰는 문제가 계속 나오고 있다.

✅ 스프링 숙련 2주차 강의 정리 💡 쿠키와 세션에 대해서 정리했고, 어제 녹화본으로 시청한 베이직반 세션과 과제에서 구현한 로그인 기능에 사용했던 부분이라 다시 한 번 정리되는 느낌이었다.

✅ 스프링 과제 💡 Lv8까지 구현은 끝났다. API 명세서와 ERD 등 문서화 작업이 남아있다. 레벨별로 바뀐 점이 많아서 다 나눠서 작성하려니 생각보다 양이 많아서 오래 걸릴 것 같다. 리팩토링도 하고 싶은데 가능할지 모르겠다.

✅ 알고리즘 & SQL 코드카타 💡 알고리즘 문제는 어렵지는 않았는데 디테일한 부분을 놓쳐서 한 번에 제출을 하지 못했다. 주어진 입출력 말고도 테스트 케이스를 추가하는 것도 생각해봐야 할 것 같다. SQL은 지문이 조금씩 복잡해지고 있다. 다른 풀이법을 보고 여러 방법에 대해 알게 되는 것 같다. 시간이 생길지…는 모르겠지만 정리하면 좋을 것 같다.

✅ 스프링 숙련 1주차 강의 정리 💡 어제 정리하고 남았던 Spring Bean과 Validation에 대해서 정리했다. 마침 오늘 스프링 과제에서 Validation을 했어야 해서 사전에 복습한게 도움이 되었다.

✅ 스프링 과제 💡 어제에 이어서 Lv3~5까지 완료하고 Lv6을 막 시작했다. 요구 사항은 하나 늘어나지만 테스트가 필요한 부분은 여러 군데라서 확인하는데 시간이 들고 있다. 프로젝트 때 바로 적용이 가능할지는 모르겠지만 내가 구현한 부분이라도 테스트 코드를 만들어야 하나 고민 중에 있다.

Spring Bean 등록(1)

• @ComponentScan(자동 등록)
  • 특정 패키지 내에서 @Component 어노테이션이 붙은 클래스를 자동으로 찾아서 Bean으로 등록
    • @Service, @Repository, @Controller 같은 어노테이션도 @Component가 포함되어 있음
  • 스캐닝 범위는 주로 어플리케이션의 루트(최상위) 패키지
    • basePackages 옵션으로 스캔할 패키지 선택 가능
  • @SpringBootApplication에 포함되어 있음
    • 스프링 프로젝트를 생성하면 메인 메소드가 있는 클래스 상단에 @SpringBootApplication이 존재
• @Configuration & @Bean(수동 등록)
  • @Configuration이 있는 클래스를 Bean으로 등록하고 해당 클래스 파싱
  • @Bean이 있는 메소드를 찾아 Bean을 생성하며, 해당 메소드명이 Bean의 이름이 됨

    @Configuration
    public class AppConfig {
    @Bean
    public TestService testService() {
      ...
    }
    }

• Bean 충돌
  • 이름이 같은 Bean이 등록되려고 하는 경우, 충돌 발생
    • 자동 등록 vs 자동 등록에서 충돌이 발생하는 경우, ConflictingBeanDefinitionException가 발생
    • 수동 등록 vs 자동 등록에서 충돌이 발생하는 경우, 수동 등록이 자동 등록을 오버라이딩 해서 우선권을 가짐

의존관계 주입

• 생성자 주입
  • 생성자를 통해 의존성을 주입하는 방법
  • 최초에 한 번 생성된 후 값이 수정되지 못함(불변, 필수)
  • 애플리케이션 실행과 동시에 의존성이 주입되기 때문에 시스템 안정성이 향상됨
  • 스프링 팀에서 권장하는 방법

    @Component
    public class Car {
    private final Engine engine;
    >
    public Car(Engine engine) {
      this.engine = engine;
    }
    >
    public void start() {
     ...
    }
    }

    💡 @RequiredArgsConstructor

• 생성자 주입 방식에서 반복되는 코드를 편하게 작성하기 위해 Lombok에서 제공되는 어노테이션
• final 필드를 모아서 생성자를 자동으로 만들어주는 역할
• 컴파일 시점에 자동으로 생성자 코드를 생성

  @Component
  @RequiredArgsConstructor
  public class MyApp {
    // 필드에 final 키워드 필수
    private final MyService myService;
  >>
    // Annotation Processor가 만들어 주는 코드
    // public MyApp(MyService myService) {
    //     this.myService = myService;
    // }
  >>
    public void run() {
        myService.doSomething();
    }
  }

• Setter 주입
  • Setter 메소드를 통해 의존성을 주입하는 방법
  • 선택하거나 변경 가능한 의존관계에 사용
  • 클래스 안에 의존성이 숨겨져 있어서 유지보수 어려움
  • 의존성이 변경될 가능성이 있기 때문에 시스템 안정성이 떨어짐

    @Component
    public class Car {
    private Engine engine;
    >
    @Autowired // 세터 주입
    public void setEngine(Engine engine) {
      this.engine = engine;
    }
    >
    public void start() {
     ...
    }
    }

• 필드 주입
  • 필드에 직접적으로 주입하는 방법
  • 코드는 간결하지만 스프링이 없으면 동작하지 않음
  • 클래스 안에 의존성이 숨겨져 있어서 유지보수 어려움
  • 의존성이 변경될 가능성이 있기 때문에 시스템 안정성이 떨어짐

    @Component
    public class Car {
    @Autowired // 필드 주입
    private Engine engine;
    >
    public void start() {
     ...
    }
    }

Spring Bean 등록(2)

같은 타입의 Bean이 충돌했을 경우

• @Qualifier
  • Bean 등록시 추가 구분자를 붙여줌

    @Component
    @Qualifier("firstService")
    public class MyServiceImplV1 implements MyService { ... }
    >
    @Component
    @Qualifier("secondService")
    public class MyServiceImplV2 implements MyService { ... }
    >
    @Component
    public class ConflictApp {
    private MyService myService;
    >
    // 생성자 주입에 구분자 추가
    @Autowired
    public ConflictApp(@Qualifier("firstService") MyService myService) {
      this.myService = myService;
    }
    }        

• @Primary
  • 지정된 Bean이 우선 순위

    @Component
    public class MyServiceImplV1 implements MyService { ... }
    >
    @Component
    @Primary
    public class MyServiceImplV2 implements MyService { ... }
    >
    @Component
    public class ConflictApp {
      private MyService myService;
    >
      @Autowired
      public ConflictApp(MyService myService) {
              this.myService = myService;
      }
    ...
    }

💡 실제 적용 사례

• Database가 (메인 MySQL, 보조 Oracle) 두 개 존재하는 경우
  • 기본적으로 MySQL을 사용할 때 @Primary를 사용
  • 필요할 때 @Qualifier로 Oracle을 사용
  • 동시에 사용되는 경우 @Qualifier 의 우선 순위가 높음

Validataion(검증)

Validation

특정 데이터(주로 클라이언트의 요청 데이터)의 값이 유효한지 확인하는 단계.

• 검증의 역할
  • 검증을 통해 오류 발생 시 유저에게 적절한 메시지 제공
  • 검증 오류로 인한 비정상적인 동작 방지
  • 사용자가 입력한 데이터 유지
• 검증의 종류
  • 프론트 검증
    • 유저가 조작할 수 있어서 보안에 취약
    • 하지만 유저 사용성을 위해 필요 ex) 비밀번호에 특수문자가 포함되어야 한다면 즉각적인 alert 가능 → 유저 사용성 증가
  • 서버 검증
    • 프론트 검증 없이 서버에서만 검증한다면 유저 사용성이 저하됨
    • API 명세서의 Response에 검증 오류를 적어야함
      • 그에 맞는 대응 가능
    • 서버 검증은 선택이 아닌 필수
  • 데이터베이스 검증
  • Not Null, Default와 같은 제약조건 설정
  • 최종 방어선 역할

BindingResult

Spring에서 기본적으로 제공되는 검증 오류를 보관하는 객체. 주로 사용자 입력 폼을 검증할 때 많이 쓰이고 Field Error와 ObjectError를 보관.

• BindResult
  • Errors 인터페이스를 상속받은 인터페이스
  • Errors 인터페이스는 에러의 저장과 조회 기능 제공
  • BindingResult는 addError() 와 같은 추가적인 기능 제공
  • BeanPropertyBindingResult는 Spring이 기본적으로 사용하는 구현체

    @Data
    public class MemberCreateRequestDto {
    private Long point;
    private String name;
    private Integer age;
    }
    >
    @Controller
    public class BingdingResultController {
    @PostMapping("/v1/member")
    public String createMemberV1(@ModelAttribute MemberCreateRequestDto request, Model model) {
      System.out.println("/V1/member API가 호출되었습니다.");
      model.addAttribute("point", request.getPoint());
      model.addAttribute("name", request.getName());
      model.addAttribute("age", request.getAge());
      return "complete";
    }
    }

• 파라미터에 BindingResult가 없을 때 잘못된 요청을 보낸 경우
  • 검증 오류(400 Bad Request)가 발생하고 Controller가 호출 되지 않음

    @Controller
    public class BindingResultController {
    @PostMapping("/v2/member")
    public String createMemberV2(
      // @ModelAttribute 뒤에 BindingResult 위치
      @ModelAttribute MemberCreateRequestDto request,
      BindingResult bindingResult,
      Model model) {
      System.out.println("/V2/member API가 호출되었습니다.");
    >
      // BindingResult의 에러 출력
      List<ObjectError> allErrors = bindingResult.getAllErrors();
      System.out.println("allErrors = " + allErrors);
    >
      model.addAttribute("point", request.getPoint());
      model.addAttribute("name", request.getName());
      model.addAttribute("age", request.getAge());
      return "complete";
    }
    }

• 파라미터에 BindingResult가 있을 때 잘못된 요청을 보낸 경우
  • BindingResult는 검증 대상 파라미터 뒤에 위치해야 함
  • @ModelAttrbute 필드 또는 객체에 파라미터 바인딩 오류 발생
    • BindingResult에 오류가 보관되고 Controller가 호출됨
    • @ModelAttribute는 파라미터를 필드 하나하나에 바인딩하기 때문에 어떤 필드에 오류가 발생할 경우, 해당 필드를 제외하고 나머지 필드들만 바인딩 된 후 Controller가 호출됨

Bean Validation

• 파라미터에 대한 검증을 Conroller에서 하게 되면, Controller가 너무 커지며, 단일 책임 원칙(SRP)를 위배
• 객체의 필드나 메소드에 제약 조건을 설정하여, 올바른 값인지 검증하는 표준화된 방법
  • Bean Validation은 기술 표준 인터페이스
  • 다양한 어노테이션과 인터페이스로 구성
    • Bean Validation 구현체인 Hibernate Validator 사용

      @Getter
      public class SignUpRequestDto {
      @NotBlank
      private String name;
      >
      @NotNull
      @Range(min = 1, max = 120)
      private Integer age;
      }

      어노테이션 정보(공식문서)

Validator

어노테이션만 선언해도 검증이 완료되는 이유는 Validator가 존재하기 때문인데, validation 라이브러리를 설정하면 'org.springframework.boot:spring-boot-starter-validation' 자동으로 Bean Validator를 Spring에 통합되도록 설정해줌.

• 동작 순서
  • Spring Boot Application 실행 시 자동으로 Bean Validator 통합
    • LocalValidatorFactoryBean 을 Global Validator로 등록
    • Global Validator가 Default로 적용되어 있으니 @Valid, @Validated 적용
    • Bean Validation Annotation(@NotNull, @NotBlank, @Max ...)에 대한 검증 수행
    • Validation Error가 발생하면 FieldError, ObjectError를 생성하여 BindingResult에 보관

      💡 LocalValidatorFactoryBean의 클래스 다이어그램

      💥 Global Validator를 수동으로 등록하면 LocalValidatorFactoryBean를 등록하지 않는다.

• @Valid, @Validated 차이점
  • @Valid 는 Java 표준이고 @Validated 는 Spring에서 제공
  • @Validated를 통해 Group Validation 또는 Controller 이외 계층에서 Validation 가능
  • @Valid는 MethodArgumentNotValidException를 예외로 발생
  • @Validated는 ConstraintViolationException를 예외로 발생

에러 메시지

Spring의 Bean Validation은 디폴트로 제공하는 메시지가 존재하며, 임의로 수정 가능

• BindingResult에 등록된 검증 오류에는 어노테이션 이름으로 오류가 등록되어 있음
• 어노테이션의 message 속성을 사용해서 메시지 수정 가능

  @Data
  public class TestDto {
    @NotNull(message = "메시지 수정 가능")
    private String stringField;
  }

  Field error in object 'testDto' on field 'integerField': rejected value [null]; codes [NotNull.testDto.integerField,NotNull.integerField,NotNull.java.lang.Integer,NotNull]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [testDto.integerField,integerField]; arguments []; default message [integerField]]; default message [널이어서는 안됩니다]

  👇 메시지 수정 후

  Field error in object 'testDto' on field 'integerField': rejected value [null]; codes [NotNull.testDto.integerField,NotNull.integerField,NotNull.java.lang.Integer,NotNull]; arguments [org.springframework.context.support.DefaultMessageSourceResolvable: codes [testDto.integerField,integerField]; arguments []; default message [integerField]]; default message [메시지 수정 가능]

Bean Validtaion의 충돌

• 요구사항
  • 상품
    • id (식별자)
    • name (이름)
    • price (가격)
    • count (재고)
  • 상품 등록 API
    • 식별자 값은 필수가 아니다.
    • name은 null, “”, “ “을 허용하지 않는다.
    • price는 10 ~ 10000 사이의 숫자로 생성한다.
    • count는 1 ~ 999 사이의 숫자로 생성한다.
  • 상품 수정 API
    • 식별자 값이 필수이다.
    • name은 null, “”, “ “을 허용하지 않는다.
    • price는 무제한으로 허용한다.
    • count는 1 ~ 999 사이의 숫자로 생성한다.

• 등록과 수정API에 공통된 RequestDto를 사용할 수 없음
  • SaveRequestDto, UpdateRequestDto를 따로 사용(주로 사용하는 방법)
  • Bean Validation의 groups 기능 사용

groups

동일한 객체에 대한 검증을 상황에 따라 다르게 적용하고 싶을 때 활용.

// 저장용 group
public interface SaveCheck {
}
>
// 수정용 group
public interface UpdateCheck {
}
>
@Data
public class ProductRequestDtoV2 {
    // 저장, 수정 모두 적용
    @NotBlank(groups = {SaveCheck.class, UpdateCheck.class})
    private String name;
>
    // 사용하는 모든 곳에 적용
    @NotNull
    // 저장만 적용
    @Range(min = 10, max = 10000, groups = SaveCheck.class)
    private Integer price;
>
    @NotNull
    @Range(min = 1, max = 999)
    private Integer count;
}
>
@RestController
public class ProductController {
    @PostMapping("/v2/product")
    public String save(
            // 저장 속성값 설정
            @Validated(SaveCheck.class) @ModelAttribute ProductRequestDtoV2 requestDtoV2) {
        return "상품 생성이 완료되었습니다";
    }
>
    @PutMapping("/v2/product/{id}")
    public String update(
            @PathVariable Long id,
            // 수정 속성값 설정
            @Validated(UpdateCheck.class) @ModelAttribute ProductRequestDto test) {
        return "상품 수정이 완료되었습니다.";
    }
}

• groups 속성을 사용하면 각각 다르게 검증 적용 가능
  • 가독성이 떨어지고 코드 복잡도 증가
  • @Validated만 지원

@RequestBody

@Valid, @Validated는 @ModelAttribute뿐만 아니라 @RequestBody에도 적용 가능. @ModelAttribute는 요청 파라미터 혹은 Form Data(x-www-urlencoded)를 다룰 때 사용하고 @RequestBody 는 HTTP Body Data를 Object로 변환할 때 사용.

@Data
public class ExampleRequestDto {
    @NotBlank
    private String field1;
>
    @NotNull
    @Range(min = 1, max = 150)
    private Integer field2;
}
>
@Slf4j
@RestController
public class RequestBodyController {
    @PostMapping("/example")
    public Object save(
        @Validated @RequestBody ExampleRequestDto dto, BindingResult bindingResult) {
        log.info("RequestBody Controller 호출");
>
        if(bindingResult.hasErrors()) {
            log.info("validation errors={}", bindingResult);
            // Field, Object Error 모두 Json으로 반환
            return bindingResult.getAllErrors();
        }
        return dto;
    }
}

• RestAPI 요청에 따른 결과
  • 성공 요청
    • Controller 정상 호출
    • 응답 반환
  • 실패 요청 : Json 객체를 변환하는 것 자체가 실패
    • Controller 호출 되지 않음
    • 반드시 Json → 객체 변환이 되어야 검증 진행
  • 검증 오류 요청 : Json 객체로 변환하는 것은 성공했지만, 검증에서 실패
    • bindingResult.getAllErrors()가 MessageConverter에 의해 Json으로 변환되어 반환
    • Controller 호출
    • log로 작성한 bindingResult 에러가 콘솔에 출력

✅ 알고리즘 & SQL 코드카타 💡 알고리즘은 문제가 어렵진 않았는데 스택을 처음 써봐서 앞으로는 사용할 수 있다면 자주 사용해서 익숙해지도록 해야 할 것 같다. SQL은 해설이 있다는 것을 알게 되었는데 푼 방법과 다른 방법은 무엇이 있는지 살펴볼 수 있어서 좋은 것 같다.

✅ 스프링 숙련 1주차 강의 정리 💡 반정도 정리를 마쳤고, SOLID 원칙과 Spring Container에 대해서 복습할 수 있었다.

✅ 스프링 과제 💡 요구 사항 정의에 대해 궁금했던 부분을 튜터님께 물어보고 과제를 진행했다. Lv2까지 완료했고 Lv3를 시작하기 전에 인증/인가에 대한 세션 녹화본을 보고 있다. 내일 세션이 있긴하지만 Lv5까지는 끝낼 수 있지 않을까 생각하고 있다.

객체 지향 설계의 5가지 기본 원칙으로서 소프트웨어 설계에서 유지보수성, 확장성, 유연성을 높이기 위한 지침.

단일 책임 원칙(Single Responsibility Principle)

하나의 클래스는 하나의 책임만 가져야 한다.

// User 클래스는 사용자 정보 관리, 로그인 및 데이터베이스 저장 책임을 동시에 가지고 있음
public class User {
    private String name; // 사용자 정보
    public void login() { /* 로그인 기능 */ }
    public void saveUser() { /* 데이터베이스 저장 기능 */ }
}
>
👇 단일 책임 원칙 적용 후
>
public class User { 
    // 사용자 정보 관리
}
>
public class AuthService {
    public void login(User user) {
        // 로그인 기능
    }
}
>
public class UserRepository {
    public void saveUser(User user) { 
        // 데이터베이스 저장
    }
}

• 클래스는 한 가지 기능에 집중해야 하며, 그 외의 기능을 담당하지 않아야 함
• 클래스가 변경될 때 파급 효과가 작아야 함
• 상황에 따라 책임의 크기가 달라질 수 있음

개방 폐쇄 원칙(Open Closed Principle)

소프트웨어 요소는 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다.

public class Shape {
    public String type;
}
>
public class AreaCalculator {
    public double calculate(Shape shape) {
        if (shape.type.equals("circle")) {
            return 원의 넓이 계산;
        } else if (shape.type.equals("square")) {
            return 사각형의 넓이 계산;
        }
    }
}
>
👇 개방 폐쇄 원칙 적용 후
>
public interface Shape {
    double calculateArea();
}
>
public class Circle implements Shape {
    public double calculateArea() { 
        return 원의 넓이 계산; 
    }
}
>
public class Square implements Shape {
    public double calculateArea() { 
        return 사각형의 넓이 계산; 
    }
}
>
public class AreaCalculator {
    public double calculate(Shape shape) {
        return shape.calculateArea();
    }
}

• 새로운 기능을 추가할 때 기존 코드를 수정하지 않고 확장할 수 있도록 설계해야 함
  • 다형성을 활용하여 해결
  • OCP 적용 전에는 새로운 도형이 추가될 때마다 AreaCalculator 클래스를 수정해야함
  • OCP 적용 후에는 새로운 도형이 추가되더라도 Shape 인터페이스만 구현하면 AreaCalculator는 수정할 필요가 없음

💥 문제점

// Circle을 계산하는 경우
public class Main {
    public static void main(String[]) {
        AreaCalculator areaCalculator = new AreaCalculator();
        Circle circle = new Circle();
        areaCalculator.calculate(circle);
    }
}
>
// Square를 계산하는 경우
public class Main {
    public static void main(String[]) {
        AreaCalculator areaCalculator = new AreaCalculator();
        // Circle circle = new Circle();
        Square square = new Square();
        areaCalculator.calculate(square);
    }
}

• 구현 객체를 변경하기 위해서는 해당 코드를 사용하는 클라이언트측의 코드를 변경해야 함
• 객체의 생성, 사용 등을 자동으로 설정해주는 무엇인가가 필요해짐
  • Spring Container의 역할

리스코프 치환 원칙(Liskov Substitution Principle)

자식 클래스는 언제나 부모 클래스를 대체할 수 있어야 한다.

class Car {
    public void accelerate() {
        System.out.println("자동차가 휘발유로 가속합니다.");
    }
}
>
class ElectricCar extends Car {
    @Override
    public void accelerate() {
        throw new UnsupportedOperationException("전기차는 이 방식으로 가속하지 않습니다.");
    }
}
>
public class Main {
    public static void main(String[] args) {
        Car car = new Car();
        car.accelerate(); // "자동차가 가속합니다."
>
        Car electricCar = new ElectricCar();
        electricCar.accelerate(); // UnsupportedOperationException 발생
    }
}
>
👇 리스코프 치환 원칙 적용 후
>
interface Acceleratable {
    void accelerate();
}
>
class Car implements Acceleratable {
    @Override
    public void accelerate() {
        System.out.println("내연기관 자동차가 가속합니다.");
    }
}
>
class ElectricCar implements Acceleratable {
    @Override
    public void accelerate() {
        System.out.println("전기차가 배터리로 가속합니다.");
    }
}
>
public class Main {
    public static void main(String[] args) {
        Acceleratable car = new Car();
        car.accelerate(); // "내연기관 자동차가 가속합니다."
>
        Acceleratable electricCar = new ElectricCar();
        electricCar.accelerate(); // "전기차가 배터리로 가속합니다."
    }
}

• 부모 클래스를 사용하는 곳에서 자식 클래스를 사용해도 프로그램의 동작에 문제가 없어야 함
  • ElectricCar는 Car 클래스를 상속 받았지만, accelerate() 를 사용할 수 없음
  • 인터페이스를 구현한 구현체를 믿고 사용할 수 있도록 만들어줌

인터페이스 분리 원칙(Interface Segregation Principle)

특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.

public interface Animal {
    void fly();
    void run();
    void swim();
}
>
public class Dog implements Animal {
    public void fly() { /* 사용하지 않음 */ }
    public void run() { /* 달리기 */ }
    public void swim() { /* 수영 */ }
}
>
👇 인터페이스 분리 원칙 적용 후
>
public interface Runnable {
    void run();
}
>
public interface Swimmable {
    void swim();
}
>
public class Dog implements Runnable, Swimmable {
    public void run() { /* 달리기 */ }
    public void swim() { /* 수영 */ }
}

• 클라이언트는 자신이 사용하지 않는 메서드에 의존하지 않아야 함
  • Dog 클래스는 fly() 메소드를 사용하지 않지만 구현 해야함
  • 하나의 큰 인터페이스보다는 여러 개의 작은 인터페이스로 분리해야 함
    • 인터페이스가 명확해짐

의존관계 역전 원칙(Dependency Inversion Principle)

구체적인 클래스에 의존하지 말고, 인터페이스나 추상 클래스에 의존하도록 설계해야 한다.

class EmailNotifier {
    public void sendEmail(String message) {
        System.out.println("Email 알림: " + message);
    }
}
>
class NotificationService {
    private EmailNotifier emailNotifier;
>
    public NotificationService() {
        // 구체적인 클래스인 EmailNotifier에 의존
        this.emailNotifier = new EmailNotifier();
    }
>
    public void sendNotification(String message) {
        emailNotifier.sendEmail(message);
    }
}
>
public class Main {
    public static void main(String[] args) {
        NotificationService service = new NotificationService();
        service.sendNotification("안녕하세요! 이메일 알림입니다.");
    }
}
>
👇 의존관계 역전 원칙 적용 후
>
interface Notifier {
    void send(String message);
}
>
class EmailNotifier implements Notifier {
    @Override
    public void send(String message) {
        System.out.println("Email 알림: " + message);
    }
}
>
class SMSNotifier implements Notifier {
    @Override
    public void send(String message) {
        System.out.println("SMS 알림: " + message);
    }
}
>
class NotificationService {
    private Notifier notifier;
>
    public NotificationService(Notifier notifier) {
        this.notifier = notifier;
    }
>
    public void sendNotification(String message) {
        notifier.send(message);
    }
}
>
public class Main {
    public static void main(String[] args) {
        // Email 알림을 사용
        Notifier emailNotifier = new EmailNotifier();
        NotificationService emailService = new NotificationService(emailNotifier);
        emailService.sendNotification("안녕하세요! 이메일 알림입니다.");
>
        // SMS 알림을 사용
        Notifier smsNotifier = new SMSNotifier();
        NotificationService smsService = new NotificationService(smsNotifier);
        smsService.sendNotification("안녕하세요! SMS 알림입니다.");
    }
}

• 추상화된 Notifier 인터페이스에만 의존
  • DIP 적용 전에는 SMS 알림과 같은 기능이 추가 되면 NotificationService가 수정 되어야 함
  • DIP 적용 후에는 NotificationService이 수정되지 않아도 됨
• 필요한 Notifier 객체를 외부에서 주입받음
  • NotificationService는 어떤 알림 방식을 사용할지에 대한 세부 사항을 몰라도 되므로, 의존성이 약해짐
• 모듈간의 결합도를 낮추고 유연성과 확장성을 높일 수 있음
• 서로의 변경 사항에 독립적이어서 변경에 유연함

Spring과 객체지향

객체 지향의 핵심은 다형성에 있지만, 다형성만으로는 OCP, DIP를 지킬 수 없음. Spring은 IOC(Inversion Of Control), DI(Dependency Injection)을 통해 OCP, DIP가 가능하도록 만들어줌

• Spring의 역할

  • OCP, DIP 원칙을 지킬 수 있도록 도와줌
  • 코드의 변경 없이 기능을 확장할 수 있도록 만들어줌
  • 개발자가 원하는 구성 요소를 손쉽게 교체하고 결합할 수 있도록 만들어줌

• 개발자의 역할

  • 이상적으로는 모든 설계를 인터페이스로 만들어야 코드가 유연하게 변경이 가능해짐
    • 정해진 비지니스 로직이나 사용할 기술이 없는 상황에서도 개발할 수 있는 장점을 가짐

Spring Container

Spring Container

Spring으로 구성된 애플리케이션에서 객체(Bean)를 생성, 관리, 소멸하는 역할을 담당. 애플리케이션 시작 시, 설정 파일이나 Annotation을 읽어 Bean을 생성하고 주입하는 모든 과정을 담당

• 객체를 직접 생성하는 경우, 객체 간의 의존성 및 결합도가 높아짐
  • OCP, DIP 위반
• Spring Container를 사용하면 인터페이스에만 의존하는 설계가 가능해짐
  • OCP, DIP 준수
    
• Spring Container의 종류
  • BeanFactory
    • Spring Container의 최상위 인터페이스
    • Spring Bean을 관리하고 조회함
  • ApplicationContext
    • BeanFactory의 확장된 형태(implements)
    • Application 개발에 필요한 다양한 기능을 추가적으로 제공
      • 국제화, 환경변수 분리, 이벤트, 리소스 조회

        💡 일반적으로 ApplicationContext를 사용하기 때문에 ApplicationContext를 Spring Container라 표현함

Spring Bean

스프링 컨테이너가 관리하는 객체를 의미. 자바 객체 자체는 특별하지 않지만, 스프링이 객체를 관리하는 순간부터 Bean이 됨. Spring은 Bean을 생성, 초기화, 의존성 주입 등을 통해 관리.

• Spring Bean의 특징
  • 스프링 컨테이너에 의해 생성되고 관리됨
  • 기본적으로 Singleton으로 설정
  • 의존성 주입(DI)을 통해 다른 객체들과 의존 관계를 맺을 수 있음
  • 생성, 초기화, 사용, 소멸의 생명주기를 가짐

IOC(제어의 역전, Inversion Of Control)

객체의 생성과 관리 권한을 개발자가 아닌 스프링 컨테이너가 담당하는 것. 스프링 컨테이너가 객체의 생성, 주입, 소멸을 관리하며, 객체 간의 결합도는 낮추기 때문에 유연한 코드가 됨.

DI(의존성 주입, Dependency Injection)

스프링이 객체 간의 의존성을 자동으로 주입해주는 것. 객체가 다른 객체를 사용할 때, 해당 객체를 직접 생성하지 않고 Spring이 주입해주는 방식이며, IOC를 구현하는 방식 중 하나.

싱글톤 패턴(Singleton Patter)

클래스의 인스턴스가 오직 하나만 생성되도록 보장하는 디자인 패턴.

• 싱글톤 패턴 생성 예제

  public interface Singleton {
    void showMessage();
  }
  >
  public class SingletonImpl implements Singleton {
    private static SingletonImpl instance;
  >
    // private 생성자를 통해 외부에서 객체 생성을 방지
    private SingletonImpl() {}
  >
    // public으로 설정하여 인스턴스가 필요하면
    // getInstance 메서드를 통해 인스턴스에 접근하도록 만듦
    public static SingletonImpl getInstance() {
        // 인스턴스가 없을 때만 생성
        if (instance == null) {
            instance = new SingletonImpl();
        }
        return instance;
    }
  >
    @Override
    public void showMessage() {
        // 인스턴스 주소값 출력
        System.out.println(instance.toString());
    }
  }

  💥 싱글톤 패턴의 문제점
• 싱글톤 패턴을 구현하기 위한 코드의 양이 많음
• 구현 클래스에 의존(DIP, OCP 위반)
  • 유연성이 떨어지기 때문에 안티 패턴이라고도 불림

• 스프링의 싱글톤 컨테이너
  >
• 스프링 컨테이너는 싱글톤 패턴의 문제점들을 해결하면서 객체를 싱글톤으로 관리

싱글톤 패턴의 주의점

객체의 인스턴스를 하나만 생성하여 공유하기 때문에 싱글톤 패턴의 객체는 상태를 유지(stateful)하면 안됨.

public class StatefulSingleton {
    private static StatefulSingleton instance;
    private int value;
>
    private StatefulSingleton() {}
>
    public static StatefulSingleton getInstance() {
        if (instance == null) {
            instance = new StatefulSingleton();
        }
        return instance;
    }
>
    public void setValue(int value) {
        this.value = value;
    }
>
    public int getValue() {
        return this.value;
    }
}
>
public class MainApp {
    public static void main(String[] args) {
        // 클라이언트 1: 싱글톤 인스턴스를 가져와서 상태를 설정
        StatefulSingleton client1 = StatefulSingleton.getInstance();
        client1.setValue(42);
        System.out.println("클라이언트 1이 설정한 값: " + client1.getValue());
>
        // 클라이언트 2: 동일한 싱글톤 인스턴스를 사용해 상태를 변경
        StatefulSingleton client2 = StatefulSingleton.getInstance();
        client2.setValue(100);
        System.out.println("클라이언트 2가 설정한 값: " + client2.getValue());
>
        // 클라이언트 1이 다시 값을 확인
        System.out.println("클라이언트 1이 다시 확인한 값: " + client1.getValue());
    }
}

클라이언트 1이 설정한 값: 42
클라이언트 2가 설정한 값: 100
클라이언트 1이 다시 확인한 값: 100

• 상태 유지(stateful)의 문제점
  • 데이터의 불일치나 동시성 문제가 발생할 수 있음
  • Spring Bean은 항상 무상태(stateless)로 설계해야 함
    • 특정 클라이언트에 의존적인 필드가 있거나 변경할 수 있으면 안됨

💡 스프링 컨테이너가 해결한 싱글톤 패턴의 문제점 1. 코드의 복잡성 및 테스트 어려움

• 문제점: 싱글톤 패턴에서는 싱글톤을 구현하기 위해 private 생성자와 static 메서드 등을 사용해야 한다. 이러한 코드 작성은 복잡하고 테스트를 어렵게 만든다. 특히, 전역 상태를 가지는 싱글톤 객체는 테스트 중 다른 테스트에 영향을 줄 수 있다.

• 스프링의 해결: 스프링 컨테이너가 객체의 생명 주기를 관리하므로, 개발자가 직접 싱글톤 구현을 작성할 필요가 없다. 또한 스프링은 객체를 DI로 주입하기 때문에 테스트 환경에서 다른 객체로 쉽게 대체 가능하여 테스트 용이성을 높인다.

• 2. 멀티쓰레드 환경에서의 동기화 문제*
• 문제점: 싱글톤 패턴에서는 멀티쓰레드 환경에서 안전하게 동작하도록 동기화 코드를 작성해야 한다. 그러나 동기화 코드는 성능 저하를 유발할 수 있다.

• 스프링의 해결: 스프링 컨테이너는 내부적으로 안전하게 싱글톤 객체를 관리하므로, 개발자가 동기화 문제를 신경 쓰지 않아도 된다.

• 3. 객체 생명 주기 관리의 어려움*
• 문제점: 싱글톤 패턴으로 생성한 객체는 어플리케이션이 종료될 때까지 유지되므로, 사용하지 않더라도 메모리를 점유할 수 있다. 또한 명시적으로 해제하는 코드가 필요할 수도 있다.

• 스프링의 해결: 스프링 컨테이너는 싱글톤 객체를 생성, 초기화, 사용, 소멸 단계까지 관리한다. @PostConstruct와 @PreDestroy 같은 어노테이션을 통해 초기화 및 소멸 작업을 간편하게 처리할 수 있다.

• 4. 전역 상태 문제*
• 문제점: 싱글톤 객체는 전역 상태를 가질 수 있기 때문에, 한 곳에서 상태를 변경하면 다른 곳에서 의도치 않은 부작용이 발생할 수 있다.

• 스프링의 해결: 스프링은 필요한 경우 프로토타입 스코프(@Scope("prototype"))나 요청 스코프(@Scope("request")) 등 다양한 스코프를 지원하여 전역 상태 문제를 완화한다. 또한, 상태를 가지는 빈 대신 상태 없는 빈(stateless bean)을 권장한다.

• 5. DI 지원 부족*
• 문제점: 싱글톤에서는 객체 간의 의존성을 관리하기 어렵다. 의존성이 많아질수록 코드가 복잡해지고 결합도가 높아진다.

• 스프링의 해결: 스프링은 DI를 통해 객체 간 의존성을 관리하므로, 결합도를 낮추고 코드의 유연성과 재사용성을 높인다.

✅ 알고리즘 & SQL 코드카타 💡 오늘은 특별히 어려운 것이 없었다. 알고리즘은 문제 풀기 전에 생각을 정리하니까 잘 풀리는 것 같고, SQL도 영어 지문이 아직까지는 그렇게 복잡하지 않아서 할 만 하다.

✅ 스프링 강의 입문 6주차 강의 정리 💡 생각보다 양이 많아서 정리하는데 시간이 오래 걸렸다. 조금만 더 하면 끝날거 같은데 하다보니 시간을 많이 썼다. 하지만 쌓인게 많아서 천천히 할 수 없기는하다…

✅ 스프링 과제 💡 강의 정리에 시간을 많이 써서 이제 Lv2 구현 중에 있다. SQL을 안 쓰고 JPA로 하려니 헷갈리는 부분이 좀 있어서 잘 잡아야 할 것 같다. Lv7에서 테이블이 늘어나기 때문에 지금 안 잡아놓으면 그 때 가서도 헷갈려 할 것 같다.