스웨거를 도입하게 된 이유 기존의 프로젝트에서는 노션으로 API 명세를 하고 있었다. API 내용을 일일이 쓰는게 꽤 오래걸리긴 하지만, 그만큼 상세하게 설명할 수 있어서 좋았다. 개발 전에는 프론트엔드와 크로스체킹까지 해서 누락되거나 기획상 틀린 정보가 거의 없었다. 문제는 개발을 하는중에 생겼는데, API 명세서와 다르게 응답값을 설정하는 일이 빈번하게 생겼던 것. 그래서 프론트엔드 팀원께서 많은 불편을 겪었다. 그래서 결국 스웨거를 적용하게 됐다. 해당 프로젝트의 Spring Boot 버전은 3.0이고 springfox가 아닌 springdoc-openapi를 의존한다. 생각보다 springdoc-openapi, 특히 webmvc-ui 버전을 적용하고 정리해놓은 블로그가 많이 없었다. 공식 문서까지..
🔍예외의 종류 예외처리를 알아보기 전에 예외의 종류부터 살펴보자. Unchecked Exception (RunTimeException) Exception Class의 서브 클래스 RuntimeException Class를 상속 Transaction으로 Rollback이 진행 됨 반드시 예외를 체크하지 않아도 되는 경우 사용합니다. 이처럼 명시적인 예외처리를 강제하지 않기 때문에 언체크 예외라고 부릅니다. 언체크 예외는 런타임 예외라고도 부릅니다. 체크 예외와는 달리 따로 처리하지 않아도 컴파일 에러가 발생하지 않습니다. 예외를 피할 수 있지만 개발자가 부주의해서 발생할 수 있는 경우를 위해 만든 예외입니다. 즉, 주로 프로그램 자체의 오류가 있을 때 발생하도록 의도됩니다. 대표적으로 NullPointer..
💡 발단 현재 프로젝트에선 기존에 로그인된 유저 정보를 불러오는 편의메소드를 제작하여 사용했다. (잠깐, SecurityContextHolder란) public class SecurityUtils { public static String getCurrentUserSocialEmail() { // 유저 정보를 불러오는 부분 Authentication authentication = SecurityContextHolder.getContext().getAuthentication(); if (authentication == null || authentication.getName() == null) { throw new UserException(StatusCode.NOT_FOUND_USER); } // 유저 식별값..
💡 발단 현재 프로젝트에선 팀원이 Security 로직을 잘 구현해놨다. *카카오 연동 소셜 로그인(OAuth2.0)과 JWT 인증 방식을 사용한다. 그래서 난 내가 맡은 기능만 구현하면 되겠다고 생각했는데, Security의 구조를 모르니 문제가 생겼다. 로그인된 유저 객체를 ... 어떻게 가져오지? 분명 DB에서 조회해올텐데? 찾아보니 편의 메서드를 만들어서 쓰고 있었고, 난 이 함수를 불러와서 다른 로직을 구현할 수 있었다. public class UserService { // ... public User getCurrentUser() { // DB에서 유저 엔티티 조회 return userRepository.findBySocialEmail(getCurrentUserSocialEmail()).orE..
