오늘은 개발에서 자주 언급되는 N+1 문제에 대해 정리했다.
N+1 문제는 어떤 데이터를 한 번 조회한 뒤,
그 데이터와 관련된 정보를 가져오기 위해 추가 요청이 여러 번 반복되는 문제를 말한다.
여기서 N은 처음 조회한 데이터의 개수이고,
+1은 처음 데이터를 조회한 요청 1번을 의미한다.
즉, 처음 목록을 가져오기 위한 요청 1번과
목록에 포함된 각 데이터의 추가 정보를 가져오기 위한 요청 N번이 더해져
총 N+1번의 요청이 발생하는 상황이다.
예시로 이해하기
예를 들어 게시글 목록과 작성자 정보를 화면에 보여줘야 한다고 해보자.
먼저 게시글 목록을 가져온다.
게시글 목록 조회 1번
조회 결과가 5개라면 다음과 같은 게시글이 있다고 볼 수 있다.
게시글 1
게시글 2
게시글 3
게시글 4
게시글 5
그런데 각 게시글의 작성자 이름도 필요하다면,
게시글마다 작성자 정보를 다시 가져올 수 있다.
게시글 1의 작성자 조회
게시글 2의 작성자 조회
게시글 3의 작성자 조회
게시글 4의 작성자 조회
게시글 5의 작성자 조회
결과적으로 요청은 다음과 같이 발생한다.
게시글 목록 조회 1번
작성자 정보 조회 5번
총 6번 요청
처음 조회한 게시글이 5개라서 1 + 5,
즉 N+1 문제가 발생한 것이다.
왜 문제가 될까?
데이터가 적을 때는 큰 문제가 없어 보일 수 있다.
하지만 게시글이 5개가 아니라 100개라면 어떻게 될까?
게시글 목록 조회 1번
작성자 정보 조회 100번
총 101번 요청
게시글이 1000개라면 요청은 1001번까지 늘어날 수 있다.
이렇게 요청이 많아지면 다음과 같은 문제가 생길 수 있다.
응답 속도 저하
서버 부하 증가
데이터베이스 부하 증가
불필요한 네트워크 비용 증가
즉, N+1 문제는 기능이 동작하지 않는 오류라기보다는
성능을 떨어뜨리는 구조적인 문제에 가깝다.
해결 방향
N+1 문제를 해결하는 핵심은
반복해서 가져올 정보를 한 번에 가져오도록 구조를 바꾸는 것이다.
1. 처음 조회할 때 필요한 정보를 함께 가져오기
게시글 목록을 가져올 때 작성자 정보도 함께 가져오면
작성자 정보를 게시글마다 다시 조회하지 않아도 된다.
게시글 + 작성자 정보를 한 번에 조회
이렇게 하면 요청 흐름이 다음처럼 바뀐다.
기존 방식:
게시글 목록 조회 1번
작성자 조회 N번
개선 방식:
게시글과 작성자 정보를 함께 조회 1번
2. 여러 개의 추가 정보를 묶어서 가져오기
각 게시글마다 작성자를 하나씩 조회하는 대신,
필요한 작성자 ID를 모아서 한 번에 조회할 수도 있다.
작성자 ID 1, 2, 3, 4, 5를 모아서 한 번에 조회
이렇게 하면 요청이 다음처럼 줄어든다.
기존 방식:
작성자 조회 5번
개선 방식:
작성자 목록 조회 1번
3. 화면에 정말 필요한 데이터만 가져오기
처음부터 모든 관련 정보를 가져오는 것이 항상 좋은 것은 아니다.
필요하지 않은 정보까지 많이 가져오면
그 자체로 성능 문제가 될 수 있다.
따라서 화면이나 기능에서 실제로 필요한 데이터가 무엇인지 먼저 확인하고,
그 데이터만 적절한 방식으로 가져오는 것이 중요하다.
'Study' 카테고리의 다른 글
| Redis로 분산락 거는 방법 (0) | 2026.05.07 |
|---|---|
| 분산락 (0) | 2026.05.06 |
| Redis Sorted Set (0) | 2026.05.02 |
| WebSocket & 실시간 통신 (0) | 2026.05.01 |
| Inbox / Outbox 패턴 정리 (0) | 2026.04.30 |