인덱스가 없을 때 실제로 벌어지는 일

인덱스 없이 “제목에 특정 단어가 포함된 글”을 찾으면, DB는 처음 글부터 마지막 글까지 하나씩 대조합니다.

게시글 수가 적을 때는 인덱스가 없어도 체감 차이가 크지 않아 문제를 늦게 발견하는 경우가 많습니다. 문제는 “이미 데이터가 많이 쌓인 뒤”에 발견된다는 점입니다.

게시판에 필요한 인덱스 유형

게시판은 조회 패턴이 비교적 정형화되어 있어 인덱스 설계가 명확합니다.

• 목록 정렬용 — 등록일 기준 최신순 정렬에 쓰는 인덱스
• 카테고리 필터용 — 게시판 구분·카테고리와 등록일을 함께 포함한 복합 인덱스
• 제목·내용 검색용 — 단순 문자열 포함 검색이 아니라 전용 텍스트 검색 인덱스
• 작성자별 조회용 — 특정 회원의 작성글 목록을 빠르게 조회하기 위한 인덱스

모든 컬럼에 인덱스를 걸 필요는 없습니다. 실제 어떤 조건으로 검색·정렬하는지 조회 로그를 분석해 필요한 조합만 선별해야 합니다.

텍스트 검색이 특히 느린 이유와 대안

제목·내용에서 특정 단어를 찾는 검색은 일반 인덱스로는 한계가 있습니다.

1. 단어가 문자열 중간에 있으면 일반 인덱스가 활용되지 못해 전체 스캔이 발생
2. 이를 해결하기 위해 전용 텍스트 검색 인덱스(풀텍스트 인덱스)를 별도로 구성
3. 검색 요구사항이 복잡해지면(오타 허용, 유사어 검색 등) 별도 검색 엔진을 도입하는 것도 고려

텍스트 검색 기능이 게시판의 핵심 기능이라면, 관계형 DB의 기본 검색만으로는 사용자 기대치를 만족시키기 어려운 경우가 많아 규모가 커지면 검색 전용 시스템 도입을 검토해야 합니다.

페이지네이션이 느려지는 이유: OFFSET의 함정

게시판에서 “다음 페이지”를 누를 때 뒤쪽 페이지로 갈수록 점점 느려지는 현상을 겪은 적이 있다면, 흔히 쓰는 페이지네이션 방식의 구조적 한계입니다.

• 일반적인 방식은 “앞에서부터 N개를 건너뛰고 보여줘”라는 방식으로 동작해, 뒤쪽 페이지일수록 건너뛰는 양이 늘어나 느려짐
• 대안으로 마지막으로 본 게시글의 기준값(ID, 등록일)을 기억해 “그 다음부터 보여줘”라는 방식을 쓰면 페이지 번호와 무관하게 일정한 속도 유지

이 방식(커서 기반 페이지네이션)은 게시글 수가 아주 많은 게시판이나 무한 스크롤 UI에 특히 효과적입니다.

인덱스가 오히려 발목을 잡는 경우

인덱스를 무조건 많이 걸면 좋을 것 같지만, 아래 상황에서는 오히려 문제가 됩니다.

쓰기 성능 저하 — 게시글 등록·수정마다 관련된 모든 인덱스를 함께 갱신해야 해, 인덱스가 많을수록 등록 속도가 느려집니다.

불필요한 인덱스 방치 — 초기에 걸어두고 실제로는 쓰이지 않는 인덱스가 저장 공간과 쓰기 성능을 낭비합니다.

주기적으로 실제 사용되는 인덱스를 점검하고, 쓰이지 않는 인덱스는 정리하는 것이 장기적인 성능 관리에 중요합니다.

대규모 게시판 성능 점검 체크리스트

게시판 성능 문제를 진단할 때는 아래 순서로 점검합니다.

1. 느린 쿼리 로그를 확인해 실제로 느린 쿼리를 특정
2. 해당 쿼리의 실행 계획을 확인해 인덱스가 제대로 활용되는지 검증
3. 필요한 인덱스를 추가하거나 쿼리 자체를 재작성
4. 페이지네이션 방식이 대량 데이터에 적합한지 재검토

이 진단은 DB 튜닝 가이드에서 다루는 원칙과 동일하게 적용됩니다. 게시판뿐 아니라 상품 목록 등 대량 데이터를 다루는 모든 화면에 공통으로 적용할 수 있습니다.

기존 시스템에서 인덱스만 추가해도 되는 경우

모든 성능 문제가 구조 재설계를 필요로 하는 것은 아닙니다. 아래 상황이라면 인덱스 추가만으로 상당한 개선을 볼 수 있습니다.

• 특정 조건의 조회만 느리고 나머지는 정상적으로 동작하는 경우
• 페이지네이션 방식을 당장 바꾸기 어려운 상황이라면 우선 인덱스만으로 체감 속도를 개선

반대로 검색 요구사항이 계속 복잡해지고 있다면 검색 전용 시스템 도입을 함께 검토하는 것이 장기적으로 더 효율적입니다. 진단이 필요하면 무료 성능 진단을 요청해보세요.