1. 테스트 개요
MongoDB 컬렉션에서 복합 인덱스의 유무가 특정 조회 기능의 성능에 미치는 영향을 측정하고 분석해보려고 한다.
이전 PostUuid를 이용한 단일 인덱스 테스트에서 성능 향상을 경험한 바 있으며, 이번 테스트는 사용자의 주요 기능으로 예상되는 카테고리별 게시글 목록 조회 기능에 초첨을 맞춘다.
해당 기능은 mainCategoryId, subCategoryId, 그리고 정렬 타입(createdAt, viewCount, likeCount)을 기준으로 데이터를 조회하는 특성상, 복합 인덱스가 필요할 것이라고 생각하였다.
이 테스트에서는 이를 검증하기 위해, 복합 인덱스 적용 전후의 평균 응답 시간과 처리량을 JMeter를 통해 측정하고 비교 분석하려고 한다.
2. 테스트 환경 및 시나리오
2.1 데이터 및 대상 API
- 테스트 데이터 : 컬렉션 내 100,000건의 게시물
- 테스트 API 경로
GET /api/v1/post-read?mainCategoryId=${RANDOM_MAIN_CATEGORY}&subCategoryId=${RANDOM_SUB_CATEGORY}&postSortType=POPULAR&size=20
DB 및 애플리케이션 캐시의 영향을 최소화하고 결과의 신뢰도를 높이기 위해, mainCategoryId와 subCategoryId를 JMeter의 Random Variable을 이용해 동적으로 변경하며 테스트를 진행하였다.
2.2 JMeter 부하 테스트 설정
- Number of Threads (Users): 20
- Ramp-up period (seconds): 10
- Loop Count: 100
- 총 요청 수: 2,000회 (20 Users * 100 Loops)
3. 테스트 결과
3.1 인덱스 적용 전 (Before)
별도의 인덱스를 설정하지 않은 상태에서 조회 성능 테스트를 진행하였다.

3.2 인덱스 적용 후 (After)
아래와 같이 deletedStatus, mainCategoryId, subCategoryId, viewCount를 포함하는 복합 인덱스를 생성한 후, 동일한 조건으로 테스트를 진행하였다.
@CompoundIndex(name = "category_sort_view_count", def = "{'deletedStatus': 1, 'mainCategoryId': 1, 'subCategoryId': 1, 'viewCount': -1}")

3.3 성능 비교 요약
| 지표 (Metric) | 인덱스 사용 전 | 인덱스 사용 후 | 개선 효과 |
| 평균 응답 시간 (Average) | 1080ms (1.08초) | 16ms (0.016초) | 약 67.5배 빨라짐 |
| 처리량 (Throughput) | 17.1/초 | 181.7/초 | 약 10.6배 많아짐 |
| 최대 응답 시간 (Max) | 1850ms (1.85초) | 67ms (0.067초) | 매우 안정적으로 변경 |
4. 결과 분석
평균 응답 시간: 인덱스 적용 후, 평균 응답 시간은 1.08초에서 0.016초로 약 67.5배 단축되었다. 이는 Full Scan으로 동작하던 쿼리가 인덱스를 통해 필요한 데이터에 즉시 접근하게 되면서 발생한 극적인 성능 향상으로, 사용자 경험(UX)을 크게 개선할 수 있음을 시사한다.
처리량 (Throughput): 1초당 처리 가능한 요청의 수는 17.1개에서 181.7개로 약 10.6배 증가하였다. 이는 각 요청이 DB 리소스를 점유하는 시간이 크게 줄었기 때문이며, 동일한 서버 자원으로 훨씬 더 많은 동시 사용자를 감당할 수 있음을 의미한다.
안정성: 최대 응답 시간이 1.85초에서 0.067초로 줄어, 일부 사용자가 겪을 수 있는 극단적인 지연 현상이 사라지고 매우 일관되고 안정적인 성능을 제공하게 되었다.
5. 결론 및 고찰
테스트 결과, (deletedStatus, mainCategoryId, subCategoryId, viewCount) 복합 인덱스는 카테고리별 인기순 정렬 조회 기능의 성능을 압도적으로 향상시키는 것으로 확인되었다.
물론 인덱스를 생성하면 조회 성능은 향상되지만, 데이터의 생성/수정/삭제 시 인덱스를 업데이트하는 추가 비용이 발생하여 쓰기 성능이 저하되는 트레이드오프가 존재한다.
하지만 본 프로젝트의 게시글 조회 기능은 쓰기 작업에 비해 읽기 작업이 훨씬 더 빈번하게 발생할 것으로 예상된다. 따라서 쓰기 성능의 미미한 저하라는 비용보다는, 핵심 기능의 조회 성능을 극대화하는 이점이 훨씬 크다고 판단하여 해당 복합 인덱스를 채택하기로 결정하였다.
'공부방' 카테고리의 다른 글
| 2. LLM (1) | 2025.12.06 |
|---|---|
| 1. 데이터 분석 (0) | 2025.12.06 |
| RESTful API 설계 및 구현 (0) | 2025.08.20 |
| Spring Data JPA + QueryDSL로 구현한 효율적인 페이징 처리 (0) | 2025.08.13 |
| 복잡한 동적 상품 필터링, 왜 QueryDSL을 선택했나? (2) | 2025.08.13 |