⟡ 배경·문제 정의회사에 입사하고 3개월쯤 지났을 때, 선배가 "이 API 좀 느린데 확인해볼래?"라며게시판 조회 API 하나를 던져주었다.로컬에서 테스트해보니 응답시간이 3초. 데이터가 겨우 100건인데 말이다.쿼리 로그를 켜보니 SELECT 문이 101번 실행되고 있었다.전형적인 N+1 문제였다.fetch join을 적용하면 되겠지 싶었지만, 현실은 그렇게 호락호락하지 않았다.결국 fetch join → @EntityGraph → @BatchSize + DTO 변환까지3번의 시도 끝에 응답시간을 300ms로 줄일 수 있었다. ⟡ 최종 해결 요약최종적으로 선택한 방식은 다음과 같다:Post 엔티티: @BatchSize(size = 100) 적용Service 계층: DTO 변환으로 엔티티 ..

2026년 새해가 밝았다.오늘도 난 퇴근 후 공부를 하고 난뒤, 업무를 하면서 겪었던 내용을 정리해 포스팅을 한다😳누구에겐 오늘이 뜻깊고 한해를 마무리하는 날 이지만, 나에겐 그리 특별하지 않다. 그냥 매일 똑같은 하루 같은 느낌이랄까.그래도 이 글을 읽는 분들은 행복한 날이 되길 바래본다❤️다들 새해 복 많이 받으세요🫶 ⟡ 인트로신입으로 입사해 처음 맡은 고도화 프로젝트에서 가장 큰 불안 요소는 테스트 코드가 전혀 없는 레거시 시스템이었다.코드를 수정할 때마다 전체 애플리케이션을 실행해서 수동으로 확인해야 했고, 사이드 이펙트를 발견하는 건 운에 맡겨야 했다.단위 테스트를 도입하려고 했지만 처음에는 방법을 몰라서 여러 번 실패했다.전체 Spring 컨텍스트를 로딩하는 느린 테스트,..