JPA N+1 문제, 왜 생기고 어떻게 줄일까: fetch join과 EntityGraph 선택 기준까지 빠른 답 EAGER 는 N+1의 해결책이 아니라 연관 조회 시점을 앞당기는 설정에 가깝다. JPQL이나 Spring Data JPA 조회 메서드가 조인을 자동 보장하지는 않는다. LAZY 는 문제를 없애는 방식이 아니라 미루는 방식이다. 목록을 읽은 뒤 연관 필드를 순회하는 순간 N+1이 다시 나타날 수 있다. 목록 조회 최적화는 fetch join , @EntityGraph , 배치 로딩( @BatchSize , hibernate.default_batch_fetch_size )을 조회 형태와 페이징 요구사항에 맞춰 나눠 쓰는 편이 낫다. 최적화 여부는 SQL 로그, 바인드 값, 쿼리 수, 실행 계획까지 같이 봐야 판단할 수 있다. 목차 시간 흐름으로 이해하기 흐름으로 보기 패치가 아니라 fetch 전략이다 N+1이 생기는 구조를 쿼리 관점에서 보기 LAZY와 EAGER는 왜 둘 다 N+1에서 안전하지 않은가 findAll 호출 뒤에 실제 SQL이 어떻게 늘어나는가 실행 계획과 인덱스로 보면 왜 더 느려지는가 fetch join, EntityGraph, 배치 로딩은 어떻게 나눠 쓰나 설정과 검증 예시 자주 부딪히는 함정과 현재 기준 버전 차이 시간 흐름으로 이해하기 T1 목록 조회 시작 → T2 루트 쿼리 실행 → T3 연관 로딩 대기 → T4 연관 필드 접근 → T5 추가 SQL 반복 Post 목록 API는 대개 루트 엔티티만 읽는 SQL로 시작한다. 문제는 그다음 시점이다. DTO 매핑이나 JSON 직렬화에서 post.getAuthor().getName() 같은 코드가 실행되면, 그 순간 연관 엔티티 초기화가 시작되고 결과 건수만큼 비슷한 SQL이 반복될 수 있다. 흐름으로 보기 흐름 다이어그램 N+1은 "첫 쿼리 하나가 느린 문제"라기보다 "첫 쿼리 뒤에 반복 SQL이 따라붙는 구조"에 가...
SSR은 무엇이고 언제 써야 할까: CSR, 하이드레이션, Next.js까지 현재 기준으로 정리 빠른 답 SSR은 첫 화면 HTML을 서버에서 먼저 만들어 보내는 방식이다. 다만 버튼과 입력이 실제로 반응하는 시점은 하이드레이션 이후일 수 있다. 브라우저는 SSR 페이지도 DOM, CSSOM, 렌더 트리, 레이아웃, 페인트, 컴포지팅을 그대로 거친다. SSR은 브라우저 렌더링을 없애는 기술이 아니라 시작 시점을 바꾸는 쪽에 가깝다. SEO와 초기 콘텐츠 노출이 중요하면 SSR이 도움이 되지만, 요청마다 HTML을 만들면 TTFB와 서버 비용이 늘 수 있다. 2026-04-07 기준 Next.js는 getServerSideProps 만으로 SSR을 설명하기 어렵다. App Router의 서버 컴포넌트, 스트리밍, 캐시 모델까지 함께 봐야 현재 동작과 가깝다. 목차 시간 흐름으로 이해하기 흐름으로 보기 SSR이 다시 중요해진 이유와 흔한 오해 SSR, CSR, SSG를 먼저 구분해 두기 요청부터 화면 반응까지: HTML, DOM, CSSOM, 하이드레이션 브라우저 렌더링 관점에서 보면 왜 SSR도 느릴 수 있을까 Next.js 현재 기준으로 다시 보기 스트리밍과 캐시를 같이 봐야 하는 이유 무엇을 측정해야 SSR의 효과가 보일까 언제 SSR을 선택하는 편이 잘 맞을까 현재 기준에서 바꿔 읽어야 할 오래된 설명 공식 문서와 참고 링크 시간 흐름으로 이해하기 요청 시작 브라우저가 URL을 요청하고 네트워크 왕복이 시작된다. → 서버 생성 서버가 요청 시점 데이터로 HTML을 만들거나 캐시된 결과를 꺼낸다. → 첫 표시 HTML과 CSS가 도착하면 브라우저가 첫 화면을 그리기 시작한다. → 연결 단계 자바스크립트가 로드되고 React가 기존 DOM에 연결된다. → 상호작용 가능 이벤트 핸들러가 붙고 클릭, 입력, 토글이 기대한 대로 동작한다. 흐름으로 보기 흐름 다이어그램 이 순서를 먼저 잡아두면 SSR이 바꾸는 구간과 바꾸지 않는 구간이 자연스럽...