PostgreSQL 인덱스 기초 가이드: B씨 프로젝트가 8초

PostgreSQL 인덱스 기초 가이드: B씨 프로젝트가 8초 걸리던 쿼리를 0.3초로 단 실제 후기

작년 사내 코드를 점검하다가 이런 상황을 만났습니다. 결제 내역 화면이 8초씩 멈춥니다. 사용자 이탈이 조금씩 늘죠. 원인은 하나였습니다. 인덱스를 안 걸어서요. PostgreSQL 인덱스 기초 가이드를 찾아보신 분이라면, 오늘 이 글이 그대로 답이 될 겁니다.

이런 문제 있으신가요?

B씨는 프랜차이즈 ERP 프로젝트를 잠깐 맡았습니다. 연락이 온 건, 시스템이 느려서 장사가 안 된다는 사장님 항의 때문이었어요.

상황은 이랬습니다.

• 일 평균 주문 2만 건이 쌓이는 테이블.
• 결제일 기준 검색 시 8초 넘게 멈춤.
• 직원이 수동으로 한 줄씩 찾느라 점심도 못 먹음.

비슷한 고민, 한 번쯤 하셨을 거예요. 데이터는 늘는데 조회만 느려지는 그 느낌. 사실 무서운 게, 작은 프로젝트라 처음엔 잘 됩니다. 운영 6개월쯤 지나면 슬슬 보이죠. 결국 B씨도 그 자리에서 한숨부터 쉬더라고요.

B씨 사례를 보면, 미루면 미룰수록 비용이 커집니다. DB도 똑같아요.

원인 분석: 왜 이런 일이 생길까

PostgreSQL에서 인덱스 없이 조회하면 데이터베이스는 풀 스캔(Full Table Scan)을 합니다. 쉽게 말해 책의 모든 페이지를 한 장씩 넘기는 거예요. 행이 천 건이면 봐도 됩니다. 백만 건이 넘어가면 얘기가 완전 달라지죠.

공식 문서를 확인하면 (https://www.postgresql.org/docs/16/indexes.html), 인덱스는 보조 자료 구조로 특정 행에 빠르게 도달하게 해줍니다. 기본 알고리즘은 B-tree예요. PostgreSQL 16 버전 기준 문서에는 "Indexes are a common way to enhance database performance" 라고 적혀 있습니다. 번역하면 인덱스는 데이터베이스 성능을 끌어올리는 흔한 방법이라는 뜻이에요.

핵심만 정리하면 이렇습니다.

• 테이블 = 책 본문.
• 인덱스 = 책의 목차.

목차 없이 백만 줄짜리 책에서 키워드를 찾는다고 상상해 보세요. 진짜 그렇습니다. 시간만 낭비돼요.

실전에서 바로 쓰는 팁

그러면 어떻게 써야 할까요. 단계별로 정리했습니다.

1단계: 먼저 어디가 느린지 찾기

EXPLAIN ANALYZE는 필수 도구입니다. 실행 계획이랑 실제 걸린 시간을 같이 보여줘요. PostgreSQL 16 기준 문법은 다음과 같습니다.

EXPLAIN ANALYZE SELECT * FROM orders WHERE paid_at = '2025-01-01';

Seq Scan이 떴다면 인덱스가 없는 겁니다. 바로 다음 단계로 갑니다.

2단계: 인덱스 종류 선택

다르다고 생각하시는 분들도 있는데, 인덱스 종류는 무조건 하나가 아닙니다. 비교 표로 정리했습니다.

종류	용도	예시 컬럼	비고
B-tree	등호, 범위 비교	created_at, user_id	기본값, 가장 범용
Hash	등호 전용	status_code	PostgreSQL 10+ WAL 기록
GIN	배열, 전문 검색	tags, jsonb	jsonb_path_ops 활용
BRIN	대용량 자연 정렬	log_time	디스크 절약 효과

출처: PostgreSQL 16 공식 문서 (https://www.postgresql.org/docs/16/indexes-types.html)

B씨 프로젝트의 경우 결제일 조회가 가장 빈번했습니다. 그래서 B-tree로 paid_at 인덱스를 만들었어요.

3단계: 인덱스 생성하기

CREATE INDEX idx_orders_paid_at ON orders (paid_at);

여기서 잠깐. 운영 DB에서 바로 돌리면 락이 걸립니다. 대용량이면 CONCURRENTLY 옵션을 쓰세요.

CREATE INDEX CONCURRENTLY idx_orders_paid_at ON orders (paid_at);

공식 문서에 따르면 CONCURRENTLY는 테이블 락 없이 인덱스를 만들어 줍니다. 대신 두 배 정도 시간은 더 걸려요. 트레이드오프가 있습니다.

4단계: 인덱스 활용 확인

다시 EXPLAIN ANALYZE를 돌립니다. Seq Scan이 Index Scan으로 바뀌면 성공입니다.

간단합니다.

B씨 프로젝트에서는 8초에서 0.3초로 떨어졌습니다. 약 26배 개선이에요. 스택오버플로우 답변에 따르면 (https://stackoverflow.com/questions/10932921/), 비슷한 패턴에서 10~50배 개선 사례는 흔하게 보고됩니다. 환경마다 다르지만 10배는 기본이라는 얘기죠.

꼭 피해야 할 주의사항

⚠️

인덱스는 만능이 아닙니다. 쓰기 비용이 발생합니다. INSERT/UPDATE/DELETE가 잦은 컬럼에 남발하면 오히려 쓰기가 느려집니다.

한 번 B씨 팀이 모든 컬럼에 인덱스를 걸었던 적이 있어요. 결과가 어땠을까요. 조회는 빨라졌는데 쓰기 QPS가 절반으로 떨어졌습니다. 인덱스 갱신 비용을 무시하면 안 되죠.

주의사항을 정리하면 이렇습니다.

• 카디널리티가 낮은 컬럼(성별, boolean 등)에 단독 인덱스는 거의 무의미해요.
• 자주 갱신되는 컬럼엔 적용을 신중히 해야 합니다.
• 복합 인덱스는 컬럼 순서가 핵심입니다. 등호 조건 컬럼을 앞에 두세요.
• VACUUM/ANALYZE로 통계 정보를 최신 상태로 유지하세요.

마지막 줄 강조합니다. 진짜 그랬어요. 통계 안 갱신하면 옵티마이저가 엉뚱한 인덱스를 고릅니다. 2024년 PostgreSQL 16 릴리스 노트에 따르면 ANALYZE 자동 실행 빈도 옵션이 추가됐으니 참고하시면 좋습니다.

추가로 git.postgresql.org 커밋 로그를 살펴보면, 인덱스 관련 패치는 매월 수십 건씩 올라옵니다. 단순한 기능 같지만 깊게 파면 끝이 없죠.

마무리

오늘은 PostgreSQL 인덱스 기초 가이드를 B씨 실제 사례와 함께 정리해 봤습니다. 핵심은 세 가지로 압축됩니다.

• 인덱스 없이 운영하면, 데이터가 쌓일수록 느려집니다.
• EXPLAIN ANALYZE → 인덱스 생성 → 검증 흐름을 반복하세요.
• 무분별한 인덱스는 독이 됩니다. 카디널리티와 갱신 빈도를 같이 따져야 합니다.

작은 프로젝트라도 6개월 단위로 점검하시는 걸 추천드립니다. 돌이켜 보면, B씨도 처음에 한 번만 걸어뒀으면 매달 30분씩 줄었을 거예요.

💡

처음엔 B-tree 인덱스 하나만 정확히 거는 연습부터 시작하세요. 나머지 종류는 케이스가 쌓이면 자연스럽게 익혀집니다.

도움이 되셨으면 좋겠네요. 오늘은 여기까지입니다. 궁금한 점은 댓글로 알려주세요.

---

자주 묻는 질문 (FAQ)

Q. 인덱스는 한 테이블에 몇 개까지 걸 수 있나요? A. PostgreSQL은 이론적으로 무제한이지만, 성능·저장 공간을 고려해 보통 5개 내외가 권장됩니다. 너무 많으면 옵티마이저 선택지가 오히려 헷갈려요.

Q. 인덱스 만든 직후에도 느린데요. A. ANALYZE 테이블명; 으로 통계 정보를 갱신해 주세요. 옵티마이저가 인덱스 존재를 늦게 인지하는 경우가 있습니다.

Q. 복합 인덱스 컬럼 순서는 어떻게 정하나요? A. 등호(=) 조건 컬럼을 앞에, 범위(>, <) 조건을 뒤에 두는 게 일반적입니다. 카디널리티가 높은 순서대로도 정렬하곤 합니다.

Q. 인덱스 용량이 너무 크면 어떻게 하나요? A. BRIN 인덱스를 고려해 보세요. 자연 정렬된 대용량 로그 테이블에 특히 효과적입니다.

Q. PRIMARY KEY는 자동으로 인덱스가 생기나요? A. 네. PK 제약 조건은 자동으로 유니크 인덱스를 만듭니다. 별도 생성은 필요 없습니다.

#PostgreSQL #인덱스 #데이터베이스 #SQL #성능최적화