대부분 프로젝트를 진행하며 예외처리를 하기 위한 Exception 핸들러를 작성하게 된다.그 형식은 프로젝트에 따라 조금씩 다르겠지만, @RestControllerAdvice 어노테이션을 통해 예외 발생 시 이를 catch 하여 프로젝트의 형식에 맞도록 응답을 공통적으로 내려주도록 관리가 된다.private fun findActiveMember(memberId: Long): Member = memberRepository .findByIdAndDeletedAtIsNull(memberId) .orElseThrow { BusinessException(ErrorCode.INVALID_MEMBER) }이 코드에서 예외가 발생한다면@RestControllerAdv..

현재 진행중인 프로젝트에서 공동구매 기능이 있어 상품을 보여주는 페이지가 존재한다. 공동구매라는 특성 상, 사용자에게 빠르게 상품 데이터를 보여주고 추후 검색 기능까지 확장하기 위해서 페이징 방식보다는 커서 기반의 무한스크롤 방식을 채택하게 되었다. 그 후, 무한스크롤에 대한 정보를 찾아보던 중 기존 offset 기반 페이징 방식에 비해 커서방식의 무한 스크롤이 데이터가 많아질 수록 성능적으로 이점을 가져간다는 것을 알게 되었다. 이유는 간단하다, offset 방식의 경우 원하는 데이터가 나올 때까지 모두 탐색을 한 후에 원하는 데이터를 가져오게 된다. 예를 들어, offset이 100만이라면 100만 개의 데이터를 탐색한 후에 원하는 데이터를 가져오게 되는 셈이다. 하지만 커서 기반 무한스크롤의 경우..

왜 스케쥴러를 사용하게 되었는가?현재 진행중인 프로젝트는 공동구매 기능이 존재하기 때문에 이전에 작성하였던 결제 시스템을 구축하였었다.원래라면 실제 운영하게 되는 사이트의 경우라면공동구매 결제, 공동구매 성공, 공동구매 실패 -> 공동구매 조건 및 유저 결제확인상태에 따라 달라진다배송준비, 배송중, 배송완료 -> 상품을 판매하는 업체측이 직접 배송관련 관리를 하고 이에 따라 상태를 변화시킨다구매확정 -> 배송완료가 된 후, 유저가 상품을 판단하고 구매확정 버튼을 눌러 구매를 확정시킨다.와 같은 형태로 업체와 유저가 직접 버튼 등을 눌러서 조작하여야 하지만 우리 프로젝트는 실제로 배포를 진행하여 사용자를 받고 결제를 진행하지는 않기 때문에 결제 이후 배송등과 관련된 사항에서 시나리오를 작성하여 이에 맞춰서..

새로운 팀 프로젝트에 합류해서 코드를 작성하며 진행을 하고 있었다. 그런데, swagger로 엔드포인트를 테스트 하던 도중, 오류가 발생했는데 내가 원하는 response가 아니라 CORS 에러 같은 알 수 없는 오류가 발생하는 것을 확인하였다. 해당 코드는 단순히 유저의 내용을 변경하는 코드인데, 예외 테스트를 할 때 일부러 Json이 파싱되지 않게 넣었다. 당연히 예상 결과는 400 Bad Request가 발생해야 한다고 생각했는데 위처럼 아예 실패라는 결과를 얻게 되었다.. 이유가 뭔지 궁금해서 스프링의 로그를 확인해보니위 사진과 같은 형태로 에러 발생 후에도 계속해서 JWT 검증 필터에 접근하는 현상을 확인할 수 있었다. ExceptionHandler을 사용해서 처리하면 되는 부분 아닌가?사실 이..

IntroSpring boot를 통해서 프로젝트를 진행하고 공부하는 사람들 중에는 나처럼 일단 해보고 생각하자! 하면서 @Controller... @Entity.. 이렇게 코드부터 작성을 하는 사람들이 많을 것이다. 강의를 통하든, 인터넷 게시글 등을 통하든 대략적인 정보를 파악하고 코드를 쓰다 보면 에러가 발생하는 경우가 많은데, 이 에러들이 내가 평소에 알던 에러의 이름들이 아니다.Servlet이 어쩌고 저쩌고... Bean이 어쩌고 저쩌고.. 하면서 알지 못하던 부분들이 많게 되서 그때마다 구글링을 통해서 누락된 부분을 추가하거나 수정하는 식으로 공부를 하였다.그러던 와중 대체 이 Spring Boot가 어떻게 동작하길래 저런 에러들이 존재하는걸까? 하는 의문을 가지게 되었고 한 번 알아보기로 하였..