단독 인덱스 필요할 거 같다고 미리 추가하지 마세요 (경험담)

💭개발자일기

dev_seong 2026. 1. 9. 11:22

1. 문제 상황

Oracle Database 환경에서 운영 중인 서비스에서 유효기간 만료일 컬럼에 단독 인덱스를 추가한 이후, 기존에는 문제없이 동작하던 SELECT 쿼리가 갑자기 극단적으로 느려지는 현상이 발생했다.

당시 테이블 구조와 쿼리 조건은 다음과 같았다.

기존에 사용하던 쿼리의 조건절은 다음과 같다.

WHERE PK_COL = :pk AND EXPIRE_DATE >= SYSDATE

기존에는 PK 인덱스를 통해 1건 조회로 빠르게 처리되던 쿼리였다.

단독 인덱스 추가 이후 동일한 쿼리가 수 초에서 수백 초까지 지연되기 시작했다.

실행계획을 확인해보니, 기존에 사용되던 PK 인덱스가 아니라 새로 추가한 유효기간 만료일 단독 인덱스를 사용하고 있었다. 이로 인해 대량의 인덱스 스캔과 테이블 접근이 발생하고 있었다.

자세한 선택 방식에 대해선 아직 파악되지 않았지만 이 문제의 핵심 원인은 옵티마이저의 인덱스 선택에 있었다.

EXPIRE_DATE >= SYSDATE

이 조건은 생각보다 많은 로우를 만족시킬 수 있으며, 옵티마이저는 이를 기준으로 인덱스를 선택했다. 그 결과 PK 조건은 인덱스 접근 단계에서 활용되지 못하고, 필터 조건으로 뒤늦게 적용되었다.

사람의 관점에서는 PK 조건이 가장 선택도가 높아 먼저 적용되어야 한다고 생각하지만, 옵티마이저의 비용 계산 결과는 그렇지 않았던 것이다.

현재 인덱스 구성은 다음과 같았다.

하지만 실제 쿼리는 두 컬럼을 동시에 사용하고 있다.

WHERE PK_COL = ? AND EXPIRE_DATE >= SYSDATE

옵티마이저 입장에서는 두 조건을 동시에 만족시키는 인덱스가 존재하지 않는 상태였다. 이로 인해 일부 조건만 만족하는 인덱스를 선택하게 되었고, 결과적으로 성능 저하로 이어졌다.

운영 중인 대규모 환경에서는 인덱스 추가나 제거가 곧바로 가능한 선택지가 아니었다. 인덱스 변경은 서비스 영향도가 크고 작업 범위도 넓기 때문이다.

우선적인 대응으로 PK 인덱스를 강제로 사용하도록 힌트를 적용했다.

SELECT /*+ INDEX(TABLE_NAME PK_INDEX_NAME) */ ... FROM TABLE_NAME WHERE PK_COL = :pk AND EXPIRE_DATE >= SYSDATE;

이 조치를 통해 쿼리는 즉시 정상 속도로 동작하기 시작했다. 구조적으로 완벽한 해결책은 아니지만, 운영 환경에서 현실적인 응급 조치로 충분히 의미 있는 선택이었다.

장기적으로는 다음과 같은 개선이 필요하다.

첫째, 실제 쿼리 패턴에 맞는 복합 인덱스를 구성하는 것이다.

CREATE INDEX IDX_PK_EXPIRE ON TABLE_NAME (PK_COL, EXPIRE_DATE);

이를 통해 옵티마이저의 선택 여지를 줄이고, 안정적인 실행계획을 유도할 수 있다.

둘째, 통계 정보 관리와 쿼리 구조 개선이다. 조건절 구조를 명확히 하고, 필요하다면 통계 재수집이나 히스토그램 조정을 고려할 수 있다. 다만 Oracle 11g 환경에서는 이러한 방식만으로는 한계가 있는 경우도 많다.

데이터가 워낙 많은 환경이여서 테이블 인덱스 추가하기 위해서는 정기점검 걸고 해야 하기 때문에 추후 사용될 수 있을 거라는 생각 하나만으로 추가했던 단독인덱스였지만 이로 인해 이슈가 발생해 버렸다.

비록 자주 사용되는 게 아닌 특정 조건에 맞았을 때만 들어오는 부분이라 실제로 cs나 데이터가 꼬이는 이슈는 없었지만 문제가 생겼던 부분이니 크게 반성중이다.

인덱스 추가 역시 하나의 스키마 변경이며, 서비스 전반에 영향을 줄 수 있다는 점을 다시 한번 체감했다.

특히 Oracle 11g와 같은 레거시 환경에서는 인덱스를 추가하기 전에 기존 쿼리들의 실행계획이 어떻게 변할 수 있는지 반드시 검토해야 한다는 점을 배웠습니다.