개발자가 알아야 할 지식: 데이터베이스 인덱스, 빠른 조회는 공짜가 아니다

데이터베이스 인덱스는 코드가 커지고 사용자가 늘어날수록 조용히 중요해지는 실무 개념입니다. 처음에는 세부 구현처럼 보이지만, 실제로는 시스템이 실패를 어떻게 다룰지 정하는 기준이 됩니다.

왜 개발자가 알아야 하나

데이터베이스 인덱스는 작은 코드 조각보다 시스템의 약속에 더 가깝습니다.

이 기준이 없으면 구현은 동작해도 운영 순간에 비용, 장애, 데이터 불일치가 드러납니다.

개발자가 이 개념을 알면 설계 결정의 이유를 더 분명히 설명하고, 장애가 나기 전에 위험을 줄일 수 있습니다.

핵심 개념

첫 번째 핵심은 경계입니다. 데이터베이스 인덱스가 적용되는 범위와 적용되지 않는 범위를 구분해야 합니다. 경계가 흐리면 예외 처리가 곳곳에 흩어지고, 나중에는 같은 문제가 서로 다른 방식으로 해결됩니다.

두 번째 핵심은 계약입니다. 서버, 클라이언트, 데이터베이스, 운영 도구가 어떤 값을 믿고 어떤 실패를 허용하는지 문서와 코드에 함께 드러나야 합니다.

세 번째 핵심은 관측 가능성입니다. 제대로 설계했는지 알려면 성공 경로뿐 아니라 거절, 충돌, 지연, 재시도 같은 사건도 로그와 지표로 확인할 수 있어야 합니다.

작은 예시 또는 체크리스트

주문 테이블에서 WHERE user_id = ? ORDER BY created_at DESC LIMIT 20 쿼리가 자주 쓰인다면 user_id만 있는 인덱스보다 (user_id, created_at) 복합 인덱스가 더 적합할 수 있습니다. 하지만 모든 필드에 인덱스를 붙이면 주문 생성과 업데이트가 느려집니다.

• 느린 쿼리의 WHERE, JOIN, ORDER BY가 어떤 인덱스를 실제로 쓰는가?
• 인덱스 컬럼의 선택도가 충분한가?
• 복합 인덱스의 컬럼 순서가 실제 쿼리 패턴과 맞는가?
• 쓰기 빈도가 높은 테이블에 불필요한 인덱스가 쌓여 있지 않은가?
• EXPLAIN 결과를 보고 추측과 실제 실행 계획을 비교했는가?

실무에서 자주 생기는 오해

• “인덱스는 많을수록 빠르다”는 오해가 있습니다. 인덱스는 읽기를 돕지만 쓰기와 저장 공간 비용을 늘립니다.

• “컬럼 하나씩 인덱스를 만들면 된다”도 부족합니다. 실제 쿼리는 여러 조건과 정렬을 함께 사용합니다.

• “개발 DB에서 빠르면 운영도 빠르다”는 판단은 위험합니다. 데이터 크기와 분포가 바뀌면 실행 계획도 바뀝니다.

오늘 바로 적용해보기

가장 느린 쿼리 하나를 골라 EXPLAIN을 읽어보세요.

사용되지 않는 인덱스를 찾아 제거 후보로 분류하세요.

새 인덱스는 어떤 쿼리를 빠르게 만들고 어떤 쓰기를 느리게 할지 PR에 적으세요.

더 알아보기

• PostgreSQL Docs: Indexes

오늘의 takeaway

인덱스는 검색을 빠르게 하는 마법이 아니라, 읽기와 쓰기 사이의 명시적인 거래입니다.