Goyummy

봄봄 ‘이달의 독서왕’ 랭킹: 데드락 원인 분석과 ShedLock 적용기

배경이달의 독서왕 랭킹 시스템 설계와 구현동기부여 장치로 ‘이달의 독서왕’ 월간 랭킹을 도입했습니다. 랭킹은 사용자의 월간 읽기 개수를 기준으로 계산되며,상위 10명의 닉네임·월간 읽기 개수를 공개해 성취감을 제공하고,모든 사용자에게 현재 순위, 월간 읽기 개수, 바로 앞 순위와의 격차를 보여 “조금만 더 읽으면 순위를 올릴 수 있다”는 즉각적인 동기를 제공합니다.운영 방안은 10분 주기 배치 갱신입니다. 요청 시점마다 실시간 계산을 수행하면 데이터베이스 부하가 크기 때문에, Spring Scheduler의 @Scheduled로 10분마다 일괄 집계합니다. 순위와 격차 계산은 애플리케이션에서 반복 처리하지 않고, **데이터베이스(윈도우 함수·집계 쿼리)**로 일괄 계산해 네트워크 왕복을 줄이고 일관성을 ..

Querydsl을 프로젝트에 적용하면서 보안 툴에서 다음과 같은 경고 문구를 확인했다.Querydsl의 버전을 낮춰도 동일한 경고 문구가 나타난다. 구글링을 해보니, OrderBy 절에서 사용자 입력을 검증하지 않을 경우 SQL Injection가 발생할 수 있음을 알 수 있었다.🔎 문제가 되는 코드 예시@GetMappingpublic List getProducts(@RequestParam("orderBy") String orderBy) { JPAQuery query = new JPAQuery(entityManager).from(test); PathBuilder pathBuilder = new PathBuilder(Test.class, "test"); OrderSpecifier orde..

운영 서버를 직접 다루다 보니, 생각보다 보안에 취약할 수 있다는 점을 깨닫게 되었다. 당장 Nginx 로그에서도 부적절한 접근 로그가 쏟아지는 것을 보기도 했다. 그래서, 단순히 서비스가 잘 동작하는 것만으로는 충분하지 않았고, 외부에서 들어오는 수많은 요청 속에서 악성 접근을 어떻게 차단할지 고민하게 되었다.처음에는 로그를 기반으로 비정상적인 접근을 차단하는 Fail2ban만으로도 충분하다고 생각했다. 하지만 팀원이 ModSecurity를 함께 적용해야 한다고 강하게 주장했고, 조사해 보니 두 도구가 방어하는 범위가 다르다는 사실을 알게 되었다.Fail2ban과 ModSecurity를 적용해 보안을 강화하기로 했다. 🔒Fail2banFail2ban은 로그 파일(예: /var/log/nginx/err..

이전 글: https://iwbdev.tistory.com/entry/%EC%96%B4%EC%A7%80%EB%9F%BD%EB%8D%98-%EB%8F%99%EC%A0%81%EC%BF%BC%EB%A6%AC%EC%97%90-Querydsl%EC%9D%84-%EB%8F%84%EC%9E%85%ED%95%98%EC%97%AC-%EA%B0%9C%EC%84%A0%ED%95%98%EA%B8%B0 이번에도 Highlight를 구현하는 중에 문제를 만났다.Highlight를 구현하기 위해서는 프론트에서 넘겨주는 위치 데이터를 서버에서 관리해야 한다. 위치 데이터는 값 객체로 묶어 관리하고 있다.원래, 응답에서 Highlight는 응답 DTO로 변환해주어도 위치 정보는 값 객체 그대로 내보내도 된다고 생각하여, 응답 DTO로..

Querydsl 도입 이유현재 Article 목록 조회에서 category, date 등을 바탕으로 필터링이 필요하다. 이 필터링 로직을 위해서는 동적 쿼리를 작성해야 하는데, Querydsl을 사용하지 않고 동적 쿼리를 작성하기 위해서는 JPQL이나 SQL을 직접 조합하여야 한다. 이는 가독성이 좋지 않다.또한, StringBuilder를 사용하여 JPQL을 조합하고 있기 때문에, 엔티티명이 바뀌거나, 필드명이 바뀌면 컴파일 타임에 에러가 나지 않고 런타임 에러가 발생하여 예방이 불가능하다.따라서, Querydsl을 도입하여, 메서드 체이닝으로 작성된 쿼리를 더 쉽게 읽을 수 있고, 잘못된 쿼리 작성 시에 컴파일 타임에 에러를 잡을 수 있다.Q 클래스 or Q(쿼리) 타입Querydsl로 쿼리를 작성할..

불안 속에 피어난 확신이전의 나학습 방법개념을 공부한 후에 적용하는 것이 나에게 잘맞는 학습 방법이라고 생각했다. 그래서 인터넷 강의나 학교 수업의 정해진 커리큘럼을 따라가기만 하였고, 학습 자료 내용만 이해하면 충분하다고 생각했다. 이해하고 내 것으로 만드는 시간이나 학습 키워드에 대해 더 깊이 고민하는 시간은 가지지 않아 학습했던 키워드를 다시 만났을 때, 내용을 제대로 설명하지 못하는 경우가 많았다. 지금 생각해보면, 학습 후에 제대로 적용해보지 않아 더 깊이 못나아간 것이라는 생각이 든다.대인 관계다른 사람에 대해 궁금한 점이 없었다. 다른 사람이 나에 대해 질문해도, 답만 하고 되묻지 않았다. 첫인상이 차갑고 무섭다는 얘기도 들었다. 그러면서도, 나에 대해 안좋게 생각하는 것이 너무 두려웠고 친..

개발 초기에는 로그를 보기 쉽게 여러 줄로 출력했습니다. 각 항목을 줄마다 구분해두면 사람이 읽기에는 편하다고 생각했기 때문입니다. 하지만 리뷰어인 로키의 피드백을 통해 로그는 사람이 아닌 도구가 읽기 쉬워야 한다는 점을 알게 되었고, 이후 로그를 한 줄로 기록하는 방향으로 개선하게 되었습니다. 1. 로그는 왜 한 줄이어야 할까?사람이 아닌 시스템이 로그를 읽는다 처음에는 다음과 같은 식으로 로그를 찍었습니다:[ReservationService.createReservation]요청 사용자 ID: 123요청 날짜: 2025-06-01요청 테마 ID: 7하지만 로그 분석 도구나 CLI 기반 필터링 도구 입장에서는 이 로그는 4줄짜리 로그가 아니라, 4개의 독립적인 이벤트처럼 인식될 수 있습니다. 이는 다음과..

JDBC에서 JPA로 전환하며 느낀 테스트 설계의 고민이 고민은 방탈출 예약 대기 미션으로 넘어오면서 시작되었다.요구사항 중 하나는 기존 JDBC 기반의 구현을 Spring Data JPA로 전환하는 것이었다.전환 이후, 이전에 작성해둔 테스트 코드들이 대거 실패하면서 꽤나 당황스러운 경험을 했다.물론, 테스트를 처음부터 깔끔하게 설계하지 못한 내 책임도 있었겠지만, JdbcTemplate에서 EntityManager로 바뀐 기술 간의 차이 역시 그 원인 중 하나였다.이러한 경험은 나에게 새로운 질문을 던지게 했다:“Spring Data JPA를 쓰는데, Repository 테스트를 굳이 작성해야 할까?” 내가 선택한 방향처음에는 고민이 많았다.하지만 레벨 2 수업 시트에서 @DataJpaTest라는 힌..

Spring Bean이란?Spring에서 IoC 컨테이너(Spring Context, Spring Container)가 관리하는 객체를 Bean이라고 부른다.IoC는 제어의 역전을 이르는 말인데, 개발자가 직접 객체를 생성하고 관리하지 않고, Spring Container가 이 역할을 대신 수행하는 것처럼, 개발자가 관리하던 것을 외부에서 관리해주는다는 것이다.IoC를 통해 가져올 수 있는 장점은,Spring Container (Spring Context)Spring Bean의 생명 주기를 관리하며, 생성된 Spring Bean들에게 추가적인 기능을 제공한다.추가적인 기능?Bean의 생명 주기 관리 또한, IoC와 DI의 원리가 스프링 컨테이너에 적용된다.IoC와 DI의 원리Spring Container..

@RequestBody Request 메시지나 Response 메시지에 담기는 Body의 대표적인 데이터 형식은 JSON이다.@RequestBody는 JSON 형식의 데이터를 자바 객체로 변환한다. ```@Controllerpublic class UserController { @PostMapping("/users") @ResponseBody public ResponseEntity createUser(@RequestBody User user) { users.add(user); return ResponseEntity.ok(user); }}//요청 예시{ "name": "홍길동", "age": 30}->위 요청이 들어오면, @RequestBody에 의해 name은 "홍길동", ag..