
실무에서 개발하면서, 많은 개발자들은 성능 개선에 대해 고민해왔다. 특히, 데이터베이스 부하를 줄이고, 빠른 응답 속도를 제공하는 것은 개발자에게 있어서, 중요한 과제이다.이를 해결하기 위한 대표적인 방법 중 하나가 캐싱(Caching) 이며, 그중에서도 Redis는
이전 프로젝트에서 Spring Security 적용 시, 권한(Role)과 API URI를 정적으로 관리를 했었다.하지만, 정적 관리는 권한 정책이 변경될 때마다 코드를 수정하고, 배포 해야한다는 단점이 있다.따라서, DB에서 권한과 URI 정보를 관리하고, 요청이 들

사이드 프로젝트를 진행하면서 Swagger 문서화 과정에서 공통 응답(Response DTO) 을 적용하는 데 한계를 느꼈다.일반적으로 @Schema(implementation = ApiResponse.class)를 사용하면 Swagger에서 응답을 표현할 수 있지만,
개발을 하다 보면 객체 간 변환이 필요할 때가 많다. 예를 들어, Entity ↔ DTO 변환을 해야 할 때, 일반적으로 Setter를 사용하거나, 생성자를 활용한 변환 로직을 직접 작성할 수도 있다. 하지만 유지보수성과 가독성을 위해, Static Method Fac

실무에서 테스트 코드를 작성하는 것은 선택이 아닌 필수가 되어가고 있다.테스트 코드의 중요성이 높아지면서, 백엔드 개발자들은 DB를 연동한 테스트를 어떻게 할 것인지에 대해 많은 고민을 해왔다.그러나 기존의 인메모리 데이터베이스(H2 등)나 로컬 DB를 사용하는 방식은

1️⃣ GitHub Repository 생성 ✅GitHub Dashboard 이동 -> New 선택 Repository 명, README 파일 추가 여부, Public 공개 여부 선택 후 Repository 생성 2️⃣ Repository Token 발급 ✅Repo
최근 새 프로젝트에서 에러 처리 방식을 통합하는 일을 맡았다.그동안은 예외가 발생하면 서비스마다 직접 만든 ErrorResponse DTO를 만들어서 반환하는 방식이었다.문제는 이 구조가 팀마다 제각각이라 API 문서 표준화가 힘들고, 공통 에러 코드나 필드 체계가 맞
사이드 프로젝트에서 특정 회원의 디바이스로 푸시 알림을 보내는 기능을 구현하던 중, 하나의 문제가 발생했다.알림 이벤트가 발생알림 테이블에 Insert디바이스 토큰을 조회푸시 메시지를 비동기로 전송그런데 트랜잭션이 롤백되었음에도 불구하고 푸시 알림이 먼저 발송되는 현상