정적 인덱싱으로 설계하는 데이터베이스 검색 성능

정적 인덱싱의 구조와 B-Tree·해시·비트맵 인덱스의 특성, 워크로드별 설계와 유지 관리 기준을 정리합니다.

2026-08-14 · 최초 발행 2025-08-10

검색 경로를 미리 갖추는 정적 인덱싱

정적 인덱싱은 테이블의 특정 컬럼에 검색용 자료구조를 생성해 데이터 접근 속도를 높이는 방식이다. 대량 데이터를 다루는 시스템에서는 이 접근 경로의 설계가 전체 성능에 직접 영향을 준다.

인덱스 구조는 테이블 데이터 변경과 무관하게 유지되며, 생성 뒤에는 DBA의 명시적 조작 없이는 변경되지 않는다. 구현에는 B-Tree, Hash, Bitmap 같은 자료구조가 쓰이고, 각 구조는 서로 다른 쿼리 유형에 맞춰진다.

쿼리 조건에 따라 달라지는 인덱스 구조

범위와 정렬을 다루는 B-Tree

Root NodeInternal Node 1Internal Node 2Leaf Node 1Leaf Node 2Leaf Node 3Leaf Node 4

B-Tree는 가장 널리 쓰이는 균형 트리 기반 인덱스다. 범위 검색(range query)과 정렬에 효율적이고, 데이터 분포와 관계없이 일정한 성능을 보장한다.

고유 식별자(PK), 외래 키(FK), 자주 조회되는 컬럼에 적합하다. Oracle, MySQL, PostgreSQL 등 대부분의 RDBMS에서 기본 인덱스로 사용된다.

정확한 일치 검색에 맞는 해시

Hash FunctionBucket 1Bucket 2Bucket 3Bucket 4Record 1Record 2Record 3Record 4Record 5

해시 인덱스는 해시 함수로 데이터를 버킷에 배치한다. 등호(=) 조건 검색에서는 매우 빠른 O(1) 성능을 제공한다.

반면 범위 검색과 정렬에는 적합하지 않고, 데이터 분포에 따라 성능 차이가 발생할 수 있다. 정확한 일치 검색이 주로 필요한 메모리 기반 데이터베이스에 맞으며, Redis·Memcached 같은 Key-Value 저장소와 MySQL의 MEMORY 스토리지 엔진에서 활용된다.

낮은 카디널리티를 겨냥하는 비트맵

Column ValuesValue 1Value 2Value 3Bitmap: 1 0 0 1 0 1Bitmap: 0 1 0 0 1 0Bitmap: 0 0 1 0 0 0

비트맵 인덱스는 각 고유 값마다 비트 벡터를 만들어 저장한다. 중복이 많은 낮은 카디널리티 컬럼에서 효율적이며, 비트 연산으로 복합 조건을 빠르게 처리할 수 있다.

고유 값이 많은 컬럼에서는 공간 효율성이 떨어진다. 데이터 웨어하우스와 OLAP 시스템에 적합하며 Oracle, Vertica 같은 데이터 웨어하우스 시스템에서 사용된다.

인덱스를 추가하기 전에 확인할 조건

인덱스 후보는 WHERE 절, JOIN 조건, ORDER BY와 GROUP BY에 반복적으로 등장하는 컬럼에서 찾는다. 높은 선택도(Selectivity)를 가진 컬럼을 우선 검토한다.

복합 인덱스는 함께 사용되는 컬럼을 하나의 인덱스로 구성한다. 컬럼 순서는 등호(=) 조건이 먼저 오도록 배치하고, 인덱스 선행 컬럼이 조건에 포함되어야 효율적으로 사용할 수 있다.

조회 속도는 빨라지지만 인덱스는 저장 공간을 추가로 사용한다. 삽입·수정·삭제 작업은 인덱스 갱신 비용만큼 느려질 수 있으며, 과도한 인덱스는 DML 성능 저하와 시스템 리소스 소모로 이어진다.

데이터 변경이 쌓이면 인덱스 구조의 비효율성, 즉 인덱스 파편화(Fragmentation)가 발생할 수 있다. 주기적인 인덱스 재구성(Rebuild)이 필요하며, 데이터 분포가 바뀌면 통계 정보도 갱신해야 한다. 이 통계 정보는 쿼리 옵티마이저의 실행 계획 최적화에 영향을 준다.

워크로드별 인덱스 적용 방식

OLTP의 짧은 트랜잭션

OLTP는 많은 수의 짧은 트랜잭션과 소량 데이터 접근이 중심이다. B-Tree 인덱스를 주로 사용하고, PK와 FK에는 인덱스를 필수로 적용한다. 자주 조회하는 필드에는 선택적으로 인덱스를 추가하며, 인덱스 커버링으로 I/O를 줄인다.

금융 거래 시스템에서는 계좌번호와 거래번호 등에 인덱스를 적용할 수 있다.

CREATE INDEX idx_account_transactions ON transactions(account_id, transaction_date);

OLAP의 집계와 대량 스캔

OLAP 환경에서는 복잡한 집계 쿼리와 대량 데이터 스캔이 많다. 비트맵 인덱스를 활용하고, 스타 스키마 조인을 위해 차원 테이블을 인덱싱하며, 데이터 파티셔닝과 인덱스 설계를 함께 고려한다.

고객 행동 분석 시스템에서는 인구통계학적 속성에 비트맵 인덱스를 적용할 수 있다.

CREATE BITMAP INDEX idx_customer_region ON customers(region);
CREATE BITMAP INDEX idx_customer_age_group ON customers(age_group);

전문 검색을 위한 역인덱스

검색 엔진은 텍스트 기반 검색과 비정형 데이터를 다룬다. 역인덱스(Inverted Index) 구조를 사용하고, 텍스트를 토큰화·정규화한 뒤 검색어에 가중치를 부여한다.

문서 관리 시스템에서는 전문 검색을 위해 다음과 같은 인덱스를 적용할 수 있다.

CREATE INDEX idx_document_content ON documents
USING GIN (to_tsvector('english', content));

데이터베이스 구조 변화에 따른 활용

인메모리 데이터베이스는 T-Tree, ART 등 메모리 최적화 인덱스 구조를 사용하고 캐시 지역성(Cache Locality)을 고려한다. SAP HANA와 Redis 등이 이에 해당한다.

컬럼 기반 저장소는 컬럼 지향 인덱싱과 압축을 결합해 효율적인 인덱스를 구현한다. Vertica와 Redshift 같은 분석 데이터베이스에서 활용된다.

NoSQL 데이터베이스에서는 분산 환경에 맞춘 인덱스 구조와 2차 인덱스(Secondary Index)를 지원한다. MongoDB의 B-Tree 인덱스와 Cassandra의 SSTable이 사례다.

정적 구조가 맞지 않는 경우

데이터 변경이 빈번하면 인덱스 유지 관리 오버헤드가 커진다. 대용량 데이터에서는 인덱스 자체의 크기가 문제가 될 수 있고, 복잡한 쿼리 패턴에는 최적화 한계도 있다.

이런 조건에서는 쿼리 패턴에 따라 인덱스를 자동으로 생성·제거하는 동적 인덱싱, 데이터 접근 패턴에 맞춰 점진적으로 인덱스를 구축하는 적응형 인덱싱(Adaptive Indexing), 정확한 인덱스 대신 근사 기법을 쓰는 근사 쿼리 처리(Approximate Query Processing)를 대안으로 검토할 수 있다.

정적 인덱싱은 데이터베이스 최적화의 기본이다. 다만 인덱스를 늘리는 일 자체가 목표가 되어서는 안 된다. 워크로드 특성에 맞는 구조를 선택하고, 기존 정적 인덱싱과 새로운 접근 방식을 조합하는 것이 데이터 시스템의 성능 전략이 된다.

정적 인덱싱데이터베이스쿼리 최적화B-Tree인덱스 설계