백엔드 N+1 문제 해결, Fetch Join만 외우면 면접에서 떨어지는 진짜 이유

by 그릿 | GROWTH_ESSAY | 2026-11-04

백엔드 개발자 이력서 열 장을 열면 아홉 장에 똑같은 문장이 적혀 있습니다. "JPA N+1 문제를 Fetch Join으로 해결하여 쿼리 수를 대폭 줄였습니다." 하지만 면접관이 "페이징 처리는 어떻게 하셨나요?"라고 묻는 순간, 아홉 명 중 여덟 명의 말문이 막힙니다.

N+1 문제의 정답을 단순한 문법 키워드로만 외웠기 때문입니다. 현업에서 N+1은 단순히 Fetch Join 한 줄을 붙여서 끝나는 문제가 아닙니다.

페이징 쿼리에 Fetch Join을 쓰면 무슨 일이 생길까요?

200명이 넘는 백엔드 멘티들의 코드를 보면서 가장 흔하게 마주친 참사가 있습니다. 1:N 관계의 연관 엔티티를 조회하면서 페이징(Pageable) 쿼리에 무작정 Fetch Join을 거는 경우입니다.

이 코드는 로컬 환경에서 데이터가 10건일 때는 아무 문제 없이 돌아갑니다. 콘솔에 쿼리가 한 번만 찍히니 성능을 최적화했다고 착각합니다. 하지만 데이터가 수만 건으로 늘어나는 순간 서버는 메모리 부족(OutOfMemoryError)으로 뻗어버립니다.

하이버네이트는 1:N 컬렉션 페이징을 데이터베이스 레벨에서 처리하지 못합니다. 모든 레코드를 메모리로 끌어올려 애플리케이션 안에서 직접 잘라내기 때문입니다. 면접관이 N+1 문제를 묻는 이유는 Fetch Join 키워드를 아는지 확인하려는 것이 아닙니다. 메모리와 데이터 정합성을 함께 고려할 줄 아는지를 검증하려는 것입니다.

단순 키워드 암기가 왜 서류와 면접을 망칠까요?

Fetch Join이 만능 해결책인 것처럼 적힌 블로그 글을 그대로 복사해 포트폴리오에 넣는 지원자가 너무 많습니다. MultipleBagFetchException을 왜 만나는지, batch_size 설정으로 해결하는 방식과 무엇이 다른지 고민해 본 흔적이 보이지 않습니다.

면접관은 지원자가 작성한 코드의 부작용을 통제할 수 있는지 봅니다. 기술 하나를 선택했을 때 따라오는 비용과 한계를 모른다면, 실무에 투입되었을 때 언제 터질지 모르는 시한폭탄을 심는 것과 같습니다.

N+1 문제를 제대로 마주했다면 세 가지를 스스로 설명할 수 있어야 합니다. 첫째, 왜 지연 로딩에서 이 문제가 터지는가. 둘째, Fetch Join 대신 batch_size를 선택해야 하는 순간은 언제인가. 셋째, 데이터 수가 늘어났을 때 메모리에 어떤 부하를 주는가. 이 세 질문에 답하지 못한다면 N+1 문제를 해결한 것이 아닙니다.

기술의 키워드만 외우는 습관을 버리고, 내가 선택한 기술이 시스템에 미치는 영향을 끝까지 추적하십시오. 지금 내 백엔드 공부 방향이 올바른 궤도 위에 있는지 점검하고 싶다면 팀그릿 방향 진단(https://teamgrit.co/direction)에서 기준을 확인해보시기 바랍니다.