• 목록

조회가 느린 SQL을 만나면 인덱스부터 추가하고 싶어집니다. 하지만 어느 열에 인덱스를 만들지 결정하려면 애플리케이션이 어떤 조건으로, 얼마나 많은 행을 가져오는지부터 알아야 합니다.

인덱스가 있다는 사실과 실제 조회에서 이득을 얻는다는 사실은 다릅니다. 이 글은 PostgreSQL의 공식 문서를 바탕으로 기본 원리를 정리하고, 작은 게시판 프로젝트를 가정해 확인 순서를 설명합니다.

예시에 등장하는 데이터 양과 업무 상황은 이해를 위한 가정이며 성능 측정 결과가 아닙니다.

AI 생성 삽화 · 개념 이해를 위한 AI 연출 이미지이며 실제 시스템 구성도나 측정 결과가 아닙니다.

핵심 정리
인덱스는 특정 조건의 행을 찾는 경로를 제공하지만 저장 공간과 변경 처리 비용이 듭니다. 자주 실행하는 쿼리를 정한 뒤 실행 계획과 읽기·쓰기 성능을 함께 비교해야 합니다.

1. 검색 조건을 먼저 문장으로 설명합니다

가상의 게시판에서 필요한 기능이 특정 작성자의 최신 글 열 개라고 가정합니다. 여기에는 작성자 조건, 최신순 정렬, 반환 개수라는 세 가지 요구가 있습니다.

단순히 게시글 테이블이 느리다고 기록하면 어느 요구를 개선해야 하는지 알기 어렵습니다. 실제 SQL과 대표적인 입력값을 함께 남겨야 인덱스 후보를 구체적으로 검토할 수 있습니다.

목록 화면에서 쓰는 쿼리와 관리자 전체 내려받기 쿼리도 따로 봅니다. 같은 테이블을 읽더라도 일부 행을 찾는 작업과 대부분의 행을 가져오는 작업은 성격이 다르기 때문입니다.

요청 빈도와 사용자가 기다리는 시간도 적어 두면, 드물게 실행되는 조회보다 자주 불편을 만드는 조회를 우선 검토할 수 있습니다. 먼저 문제를 한 문장으로 정의하는 과정이 튜닝의 출발점입니다.

2. 인덱스가 줄이는 작업과 추가하는 작업을 나눕니다

PostgreSQL은 인덱스를 이용해 조건에 맞는 행의 위치를 찾을 수 있습니다. 책의 색인을 보고 필요한 쪽을 찾아가는 방식에 비유할 수 있지만, 실제 데이터베이스에는 여러 인덱스 유형과 실행 경로가 있습니다.

색인이 모든 읽기를 대신한다고 생각하기보다는 탐색에 사용할 수 있는 별도의 구조가 생긴다고 이해하는 편이 좋습니다. 테이블 내용이 바뀌면 관련 인덱스도 관리해야 하므로 변경 처리에 부담이 추가됩니다.

따라서 조회 시간이 줄었다는 결과만으로 후보를 확정하지 않습니다. 가상의 주문 서비스라면 상품 조회와 주문 생성이 함께 발생합니다.

조회 실험만 빠르고 주문 입력의 처리량이 크게 줄었다면 서비스 전체에서 이득인지 다시 판단해야 합니다. 인덱스 이름 옆에 지원하려는 쿼리를 기록하면, 나중에 비슷한 구조를 중복해서 추가하는 실수도 줄일 수 있습니다.

관련 공식 문서

3. 복합 인덱스는 열의 목록뿐 아니라 순서도 봅니다

작성자와 작성 시각을 함께 사용하는 조회라면 두 열을 포함하는 인덱스를 검토할 수 있습니다. PostgreSQL의 다중 열 B-tree 인덱스는 앞쪽 열의 조건이 탐색 범위에 영향을 주며, 모든 순서가 같은 효과를 내는 것은 아닙니다.

그렇다고 첫 번째 열의 조건이 없으면 절대로 사용할 수 없다는 규칙으로 외우면 곤란합니다. 공식 문서에는 조건과 값의 분포에 따라 적용될 수 있는 skip scan도 설명되어 있습니다.

입문 단계에서는 예외를 암기하기보다 실제 사용하는 데이터베이스 버전과 실행 계획을 확인하는 습관이 중요합니다. 작성자별 목록과 기간별 전체 목록을 각각 테스트 목록에 적어 보십시오. 둘 다 날짜 열이 등장하더라도 최적의 접근 경로가 같다고 미리 결론 내리지 않습니다.

인덱스 후보를 비교할 때는 하나의 성공 사례뿐 아니라 함께 사용하는 다른 조회가 어떻게 달라졌는지도 살펴봅니다.

관련 공식 문서

4. 실행 계획의 예상과 실제 시간을 구분합니다

EXPLAIN은 데이터베이스가 선택한 실행 계획을 보여 줍니다. 순차 스캔이나 인덱스 스캔 같은 이름뿐 아니라 예상 행 수와 조건이 적용되는 위치를 함께 읽어야 합니다.

계획의 cost 숫자는 그대로 밀리초를 뜻하지 않습니다. EXPLAIN ANALYZE는 쿼리를 실제 실행하므로 특히 데이터를 변경하는 문장이나 큰 작업은 운영 환경에서 무심코 실행하면 안 됩니다.

먼저 분리된 실습 환경에서 읽기 쿼리로 연습하는 편이 좋습니다. 가상의 테스트 기록에는 실행 계획 파일, 데이터 건수, 입력값, 실행 횟수를 나란히 보관합니다.

한 번의 빠른 결과만 캡처하면 캐시 상태나 순간 부하 차이를 놓칠 수 있습니다. 계획을 보는 목적은 인덱스라는 단어를 찾는 데 그치지 않습니다.

왜 그 경로를 택했고 어느 단계가 많은 작업을 하는지 설명할 수 있어야 다음 실험을 정할 수 있습니다.

관련 공식 문서

5. 작은 실험에서도 비교 조건을 고정합니다

자체 실습은 동일한 데이터 복사본에 인덱스를 추가하기 전과 후를 비교하는 방식으로 구성할 수 있습니다. 이때 애플리케이션 코드나 조회 조건까지 동시에 바꾸면 어느 변화가 결과에 영향을 주었는지 판단하기 어렵습니다.

예를 들어 작성자별 목록을 측정하다가 두 번째 실험에서 반환 열을 줄였다면 인덱스만의 효과라고 보고할 수 없습니다. 흔한 입력값과 드문 입력값을 따로 정하고, 각 결과의 행 수가 같은지도 확인합니다.

빠르게 끝났지만 필요한 행이 빠졌다면 성공적인 최적화가 아닙니다. 실험 기록에는 평균 시간만 적기보다 반복 실행 값과 특이사항을 남기는 편이 유용합니다.

외부 API 호출이나 화면 렌더링까지 포함한 응답 시간은 데이터베이스 실행 시간과 구분합니다. SQL이 개선되어도 화면이 그대로 느리다면 다음 병목을 찾을 근거가 생깁니다.

6. 추가 이후의 관리 계획까지 남깁니다

인덱스 변경 제안에는 대상 쿼리, 기대 효과, 확인 방법, 되돌릴 조건을 포함합니다. 작은 팀 프로젝트라도 이 네 가지가 있으면 동료가 판단 과정을 따라가기 쉽습니다.

가령 특정 작성자의 목록을 개선하려는 변경이라면 목록 조회 결과가 동일한지, 입력 작업에 눈에 띄는 변화가 없는지, 인덱스 크기가 어느 정도인지 확인 항목으로 적습니다. 실제 서비스에서는 생성 작업 자체의 영향도 별도로 검토해야 합니다.

사용 빈도가 줄어든 기능의 인덱스를 정리할 때도 이름만 보고 즉시 삭제하지 않습니다. 다른 쿼리와 제약 조건에 연결되는지 확인하고 변경 절차에 따라 진행합니다.

포트폴리오에는 빠르게 만들었다는 표현보다 문제 쿼리와 실험 조건, 선택 이유를 남기는 편이 설명력이 높습니다. 같은 결론을 다른 데이터 규모에서도 보장할 수 없다는 범위를 적으면 결과를 더 정확하게 전달할 수 있습니다.

7. 자주 묻는 질문

Q1. 인덱스를 많이 만들면 항상 좋아지나요?

조회에 도움이 되는 경로가 늘 수 있지만 변경 처리와 저장 공간의 부담도 생깁니다. 실제 사용하는 쿼리와 읽기·쓰기의 비중을 기준으로 판단해야 합니다.

Q2. 순차 스캔이 나오면 실패인가요?

그 이름만으로 실패를 판단할 수 없습니다. 읽어야 하는 데이터의 범위와 비용을 고려해 선택된 계획인지 살펴보고, 결과와 실제 시간을 함께 비교합니다.

Q3. 개발용 작은 데이터로 충분한가요?

기능 확인에는 도움이 되지만 운영 규모의 성능을 그대로 예측하기는 어렵습니다. 테스트 데이터의 규모와 분포가 실제 환경과 얼마나 다른지 기록해 두는 것이 좋습니다.

Q4. 면접에서는 무엇부터 설명하면 되나요?

어떤 조회가 문제였고 어떤 조건을 고정해 비교했는지부터 설명하면 됩니다. 인덱스 추가 후 조회뿐 아니라 쓰기와 결과의 정확성을 어떻게 확인했는지도 덧붙입니다.

참고 자료

• PostgreSQL: 인덱스 소개
• PostgreSQL: 다중 열 인덱스
• PostgreSQL: EXPLAIN 사용