상품이 300개일 때는 문제없던 목록 페이지가, 3만 개를 넘어가는 순간 로딩에 5초가 걸리기 시작합니다. 서버를 업그레이드해도 크게 나아지지 않는다면 문제는 하드웨어가 아니라 쿼리와 인덱스에 있습니다. 대용량 상품 데이터의 병목은 대부분 “필터 조합이 늘어날수록 느려지는” 구조적 원인에서 시작됩니다.
느려지는 순서: 상품 수가 아니라 조합의 문제
정확히 말하면 병목의 원인은 상품 개수 자체가 아니라, 필터·정렬·옵션 조합이 늘어나면서 하나의 쿼리가 훑어야 하는 행(row)의 수가 기하급수적으로 늘어나는 것입니다.
| 상황 | 조회 방식 | 결과 |
|---|---|---|
| 카테고리만 필터 | 인덱스로 즉시 조회 | 빠름 |
| 카테고리+가격대+색상+정렬 | 인덱스가 조합을 커버하지 못해 전체 스캔 발생 | 느림 |
| 검색어+필터+옵션 | 텍스트 검색과 필터가 별도 처리되어 중간 결과가 비대화 | 매우 느림 |
필터가 하나씩 추가될 때마다 쿼리 플랜이 어떻게 바뀌는지 실제로 확인하지 않으면, 어느 순간 “필터를 하나 추가했을 뿐인데 갑자기 느려졌다”는 상황을 겪게 됩니다.
복합 인덱스 설계: 순서가 성능을 결정한다
인덱스를 걸었는데도 느리다는 문의의 대부분은 인덱스 컬럼 순서 문제입니다. 예를 들어 카테고리·가격·등록일 세 컬럼에 인덱스를 건다면, 실제 조회 조건의 사용 빈도와 선택도(값이 얼마나 다양한지)를 기준으로 순서를 정해야 합니다.
- 가장 자주 필터에 쓰이고 선택도가 높은 컬럼을 맨 앞에 배치
- 정렬에 쓰이는 컬럼을 인덱스 마지막에 포함시켜 별도 정렬 연산을 줄임
- 필터 조합이 여러 종류라면, 조합별로 커버링 인덱스를 별도로 설계
인덱스는 많이 걸수록 좋은 것이 아닙니다. 쓰기 성능(상품 등록·수정 속도)이 떨어지기 때문에, 실제 조회 패턴을 로그로 분석한 뒤 필요한 조합만 골라 설계해야 합니다.
풀텍스트 검색과 필터를 분리하는 이유
검색어와 필터를 같은 쿼리에서 한꺼번에 처리하면 최적화가 어려워집니다. 실무에서는 두 단계로 분리하는 방식을 씁니다.
- 1단계: 검색어로 후보 상품 ID 집합을 빠르게 추출 (전용 검색 인덱스 또는 풀텍스트 인덱스 활용)
- 2단계: 추출된 ID 집합에 한해 가격·옵션 필터와 정렬을 적용
이렇게 나누면 검색엔진과 관계형 DB가 각자 잘하는 일만 담당하게 되어, 검색어가 있을 때와 없을 때 모두 안정적인 응답 시간을 낼 수 있습니다.
캐시 계층: DB에 매번 묻지 않게 만들기
상품 목록·카테고리 트리처럼 자주 조회되지만 실시간 변경이 잦지 않은 데이터는 캐시로 분리하는 것이 효과적입니다.
정적 캐시 — 카테고리 구조, 인기 상품 순위처럼 몇 분 단위로만 바뀌는 데이터.
세션 무관 캐시 — 로그인 여부와 상관없는 상품 상세 정보.
캐시 무효화 전략 — 상품 등록·재고 변경 시점에 관련 캐시만 선택적으로 갱신, 전체 캐시를 매번 비우지 않도록 설계.
캐시를 도입하면 DB 부하가 줄어드는 대신 “방금 등록한 상품이 안 보인다”는 정합성 문제가 생길 수 있어, 무효화 시점을 명확히 정의하는 것이 캐시 자체보다 더 중요합니다.
대량 배치 작업이 실시간 서비스에 영향을 주지 않게 하기
가격 일괄 변경, 재고 동기화 같은 배치 작업이 실시간 서비스 쿼리와 같은 DB 자원을 두고 경쟁하면, 배치 실행 중에 사이트 전체가 느려지는 현상이 나타납니다.
- 배치는 트래픽이 낮은 시간대로 스케줄링
- 대량 업데이트는 작은 단위로 나눠(청크) 처리해 잠금 시간을 최소화
- 읽기 전용 복제본을 두어 배치·리포트 쿼리를 실시간 서비스와 분리
트래픽 규모가 커질수록 읽기와 쓰기를 분리하는 구조가 필수적으로 요구됩니다. 인프라 관점은 로드밸런싱·클라우드 아키텍처 가이드에서 함께 다룹니다.
튜닝 전후 반드시 측정해야 할 지표
튜닝 효과를 “빨라진 것 같다”로 판단하면 나중에 원인 파악이 불가능해집니다. 아래 지표를 튜닝 전후로 기록해야 합니다.
| 지표 | 확인 방법 |
|---|---|
| 쿼리 실행 시간 | 슬로우 쿼리 로그 분석 |
| 스캔한 행 수 | 쿼리 실행 계획(EXPLAIN) 비교 |
| 동시 접속 시 응답시간 변화 | 부하 테스트 도구로 실측 |
| 쓰기 성능 저하 여부 | 인덱스 추가 전후 등록·수정 응답시간 비교 |
언제 인덱스 튜닝을 넘어 구조 개편이 필요한가
인덱스와 캐시로 해결되지 않는 경우도 있습니다. 아래에 해당하면 테이블 구조 자체를 재설계할 시점입니다.
- 옵션 조합이 상품마다 달라 하나의 테이블에 모든 속성을 담기 어려움
- 검색 요구사항이 자유 텍스트·다중 조건으로 계속 복잡해짐
- 배치·리포트 쿼리가 실시간 쿼리와 자주 충돌
이 단계에서는 속성을 별도 테이블로 정규화하거나, 검색 전용 인덱스 시스템을 도입하는 것이 근본적인 해법입니다. 정확한 진단이 필요하면 DB 진단 상담을 받아보는 것을 권합니다.
자주 묻는 질문 (FAQ)
서버를 업그레이드하면 해결되지 않나요? +
일시적으로 개선되지만 쿼리 자체가 비효율적이면 데이터가 늘어날 때 다시 느려집니다. 하드웨어보다 쿼리·인덱스 구조를 먼저 점검하는 것이 근본적입니다.
인덱스는 많이 걸수록 좋은가요? +
아닙니다. 인덱스가 늘어나면 조회는 빨라지지만 등록·수정 시 인덱스를 갱신하는 비용이 늘어 쓰기 성능이 떨어집니다. 실제 조회 패턴에 맞춰 필요한 만큼만 설계해야 합니다.
캐시를 쓰면 재고 정보가 부정확해지지 않나요? +
캐시 무효화 시점을 재고 변경 이벤트에 맞춰 설계하면 실시간성과 성능을 함께 확보할 수 있습니다. 재고처럼 민감한 데이터는 캐시 유효시간을 짧게 두는 것이 일반적입니다.
튜닝은 서비스 운영 중에도 할 수 있나요? +
대부분 가능합니다. 인덱스 추가는 온라인으로 처리할 수 있는 경우가 많고, 구조 변경이 필요한 경우에는 트래픽이 낮은 시간대에 점진적으로 진행합니다.
몇 개 상품부터 튜닝을 고민해야 하나요? +
정확한 기준은 없지만, 목록·검색 페이지 응답시간이 1초를 넘기기 시작하면 점검이 필요한 신호로 보는 것이 일반적입니다.