검색 속도가 100배 빨라지는 마법! DB 인덱스(Index) 원리와 장단점 완벽 정리

안녕하세요, 여러분의 든든한 IT 길잡이 데브프리입니다.

 

개발 초기에는 데이터베이스(DB)에 데이터가 몇십 개, 몇백 개 수준이라서 내가 어떻게 쿼리(SQL)를 짜든 0.001초 만에 데이터가 슉슉 잘 나옵니다. "역시 내 코드는 완벽해!" 하고 뿌듯해하기 쉽죠.

 

하지만 실제 서비스가 론칭되고 사용자가 늘어나 데이터가 10만 건, 100만 건으로 쌓이기 시작하면 상황이 완전히 달라집니다. 평소엔 잘 뜨던 마이페이지나 게시판 화면이 3초, 5초씩 뱅글뱅글 로딩창만 돌다가 뻗어버리는 지옥 같은 상황을 마주하게 됩니다.

 

"코드는 바꾼 게 없는데, 왜 갑자기 조회가 이렇게 느려진 걸까요?"

"느려진 쿼리를 해결하려면 도대체 뭘 해야 하죠?"

 

이때 백엔드 개발자가 가장 먼저 확인하고 적용해야 하는 데이터베이스의 핵심 무기! 바로 인덱스(Index)입니다. 오늘은 데이터베이스의 조회 성능을 100배 이상 끌어올려 주는 인덱스의 원리와 장단점을 '책 뒷장의 찾아보기(색인)'에 비유하여 아주 명쾌하게 정리해 드리겠습니다.

 

1. 인덱스(Index)란? (책 뒷장의 '찾아보기' 비유)

인덱스(Index)는 데이터베이스 테이블의 조회 속도를 극대화하기 위해, 특정 컬럼의 값들을 정렬하여 메모리 공간에 미리 저장해 둔 '색인(찾아보기) 테이블'입니다.

인덱스는 수천 페이지의 책에서 내가 원하는 단어를 찾기 위해 첫 장부터 다 읽는 대신, 책 뒷장의 '찾아보기'를 보고 곧바로 해당 페이지로 점프하는 기술입니다.

데이터가 100만 개 있는 테이블이 있습니다. 여기서 내가 username = 'devfree'인 회원을 찾고 싶습니다.

• 인덱스가 없다면 (Full Table Scan): 데이터베이스는 1번 회원부터 100만 번 회원까지 100만 칸을 전부 일일이 뒤져서 'devfree'가 맞는지 확인해야 합니다. 데이터가 늘어날수록 조회 시간은 끔찍하게 길어집니다.
• 인덱스가 있다면 (Index Scan): '이름' 컬럼에 인덱스를 걸어두면, DB는 이름 순(가나다/알파벳 순)으로 예쁘게 정렬된 '색인 주소록'을 미리 만들어 둡니다. 그리고 그 주소록을 이용해 아주 빠르게 'devfree'를 찾아낸 뒤, 그 회원 정보가 담긴 진짜 방 번호로 다이렉트로 점프합니다.

 

2. 인덱스는 내부적으로 어떻게 동작하나요? (B-Tree 구조)

데이터베이스가 인덱스를 정렬해서 보관할 때 가장 많이 사용하는 자료구조는 B-Tree (Balanced Tree, 균형 트리)입니다.

B-Tree는 최상단(Root)에서 출발해 대소 관계를 비교해가며 좌우로 타고 내려가 최단 경로로 원하는 데이터를 찾아내는 마법 같은 자료구조입니다.

쉽게 말해 '토너먼트 대진표'나 '업앤다운(Up & Down) 게임'을 생각하시면 됩니다.

1부터 100까지의 숫자 중 인덱스가 '50'을 기준으로 탐색을 시작합니다. 내가 찾는 값이 75라면, '50보다 크니까 오른쪽 길로 가자!' 하고 바로 뒤도 안 돌아보고 절반을 날려버립니다. 그다음 75와 비교하며 아주 순식간에 데이터를 찾아냅니다.

 

이렇게 정렬된 상태로 데이터를 분기하여 찾기 때문에, 데이터가 100만 개가 있든 1000만 개가 있든 단 몇 번의 비교(보통 3~4번의 디스크 탐색)만으로 정확한 위치를 집어낼 수 있습니다.

 

3. 공짜는 없다! 인덱스의 치명적인 단점 (Trade-off)

조회 속도가 100배나 빨라진다면 모든 컬럼에 인덱스를 다 걸어두면 안 될까요? 안타깝게도 인덱스는 엄청난 장점이 있는 만큼 대가가 따르는 아주 무거운 기술입니다.

데이터를 새로 넣거나 지울 때마다, 인덱스 주소록을 매번 기역-니은-디귿 순으로 다시 정렬해야 하므로 쓰기(CUD) 속도가 느려집니다.

 

단점 ①: 데이터 추가/수정/삭제(CUD)가 느려집니다.

• 새로운 회원(INSERT)이 가입하면, 회원 테이블에 데이터를 넣는 것뿐만 아니라 '이름 인덱스 주소록'에도 이 회원을 정렬 기준에 맞춰 끼워 넣어야 합니다.
• 기존 주소록 카드들을 다 한 칸씩 밀어내고 정렬하는 과정이 매번 발생하기 때문에, INSERT, UPDATE, DELETE 성능이 크게 떨어집니다.

단점 ②: 추가적인 저장 공간(용량)을 차지합니다.

• 인덱스는 별도의 정렬된 주소록 파일입니다. 보통 테이블 크기의 약 10% 내외의 추가 저장 공간이 필요한데, 인덱스를 남발하면 배보다 배꼽이 더 커져 데이터베이스 서버의 메모리가 부족해지는 현상이 발생할 수 있습니다.

 

4. 한눈에 비교하는 요약표

비교 항목	인덱스가 없을 때	인덱스가 있을 때
조회 속도 (SELECT)	데이터가 많을수록 기하급수적으로 느려짐	데이터가 많아도 거의 0.1초 만에 해결
등록/수정/삭제 (CUD)	매우 빠름 (그냥 끝에 데이터만 추가하면 됨)	느려짐 (인덱스 테이블 재정렬 오버헤드)
서버 용량	테이블 본래 크기만 차지함	인덱스 개수당 약 10% 추가 용량 필요
데이터 탐색 방식	Full Table Scan (첫 장부터 일일이 다 읽기)	Index Scan (색인 타고 필요한 곳만 집기)

 

마무리

정리해 볼까요?

• 데이터베이스 조회 속도를 미친 듯이 끌어올려 주는 구원자이지만, 그 대가로 쓰기 속도를 일부 희생하고 용량을 더 소모하는 트레이드오프(Trade-off) 기술이 바로 인덱스입니다.

따라서 실제 실무나 개인 프로젝트를 진행할 때는 아래 3가지 규칙을 기억하며 인덱스를 적용해 보세요.

1. 조회가 아주 빈번하게 일어나는 컬럼에 걸기 (예: 회원 ID, 글 카테고리)
2. INSERT나 UPDATE가 끊임없이 일어나는 컬럼은 인덱스 피하기 (예: 조회수, 좋아요 수)
3. 값의 종류가 몇 개 없는 컬럼은 인덱스를 걸어도 효과가 없음 (예: 성별 '남/여' - 걸어봤자 절반을 다 읽어야 하므로 무의미)

오늘 배운 인덱스의 핵심 원리를 바탕으로 데이터의 규모에 맞는 건강하고 똑똑한 데이터베이스 아키텍처를 설계해 보시기를 바랍니다!

 

오늘의 데브 노트가 유익하셨다면 공감과 댓글 부탁드립니다. 지금까지 데브프리였습니다. 감사합니다!