백과사전의 색인처럼 빠른 검색
서비스 속도를 극적으로 높여주는 인덱스(Index)의 원리를 이해하고, AI가 짠 쿼리가 어떻게 실행되는지 파악하는 실행 계획의 기초를 알아봅니다.
서비스가 대박이 나서 가입자가 100만 명을 돌파했습니다! 그런데 기쁨도 잠시, 유저들이 "게시판 검색을 누르면 모래시계만 돌고 화면이 10초 동안 안 떠요"라며 불만을 쏟아냅니다. 코드는 예전과 똑같은데 왜 느려진 걸까요? 데이터가 방대해졌을 때 데이터베이스는 100만 장의 서류 더미를 1번부터 100만 번까지 무식하게 한 장씩 넘겨가며 검색을 하고 있기 때문입니다. 이 무식한 검색을 빛의 속도로 바꿔주는 마법의 지름길, '인덱스(Index)'에 대해 알아봅니다.
무식한 풀 스캔(Full Scan)의 공포
우리가 전화번호부 책에서 '홍길동'의 번호를 찾는다고 해봅시다. 책이 가나다순으로 정렬되어 있지 않다면, 1페이지부터 마지막 1000페이지까지 한 장 한 장 넘기며 눈으로 홍길동을 찾아야 합니다. 이를 데이터베이스 용어로 '풀 스캔(Full Table Scan)'이라고 부릅니다.
유저가 10명일 때는 풀 스캔을 해도 0.001초면 끝나서 느린 줄 모릅니다. 하지만 100만 명이 되면 10초가 걸리고, 만약 100명이 동시에 검색 버튼을 누르면 서버는 100만 장 넘기기 작업을 100번 해야 하므로 결국 과부하로 죽어버립니다.
마법의 목차: 인덱스(Index)
두꺼운 백과사전 맨 뒷장에는 항상 '찾아보기(색인)' 페이지가 있습니다. '사과: 15페이지, 호랑이: 320페이지'처럼 단어들이 가나다순으로 예쁘게 정렬되어 있어, 단 3초 만에 원하는 페이지를 찾아갈 수 있습니다.
데이터베이스의 인덱스(Index)가 바로 이 백과사전의 색인과 완전히 똑같은 역할을 합니다.
이름(name) 컬럼에 인덱스 걸기
"사람들이 검색창에서 유저의 '이름'으로 자주 검색하니까, 이름 순서대로 정렬된 얇은 목차 책을 하나 따로 만들어둬!"라고 데이터베이스에 지시합니다.
CREATE INDEX idx_user_name ON users(name);이 한 줄을 치는 순간, 데이터베이스는 `users` 테이블을 뒤져서 이름을 가나다순으로 정렬한 아주 작고 빠른 '목차 파일'을 하나 별도로 생성합니다. 이제 누군가 홍길동을 검색하면, 100만 장의 원본 서류를 뒤지는 대신 이 조그만 목차 파일에서 홍길동을 순식간에 찾아 진짜 데이터가 있는 위치로 바로 점프합니다. (0.01초 소요)
AI 코드의 성능 저하 진단하기: 실행 계획 (`EXPLAIN`)
바이브코딩으로 짠 쿼리가 너무 느릴 때, 데이터베이스가 지금 무식한 풀 스캔을 하고 있는지, 아니면 똑똑하게 인덱스 목차를 타고 점프하고 있는지 우리의 눈으로 직접 검사해 볼 수 있습니다. 쿼리문 맨 앞에 `EXPLAIN`이라는 마법의 단어를 붙여서 실행해 봅니다.
EXPLAIN SELECT * FROM users WHERE name = '홍길동';그러면 데이터베이스는 진짜 검색을 하는 대신, "주인님, 제가 이 질문을 받으면 앞으로 이렇게 검색할 계획입니다"라는 실행 계획서(Execution Plan)를 보여줍니다.
- 결과에 `Seq Scan` (Sequential Scan) 이라는 끔찍한 단어가 보인다면, 1번부터 100만 번까지 무식하게 풀 스캔을 하겠다는 뜻입니다. 당장 인덱스를 걸어야 합니다.
- 결과에 `Index Scan` 이라는 예쁜 단어가 보인다면, 만들어둔 목차를 타고 똑똑하고 빠르게 찾겠다는 뜻입니다. 안심하셔도 됩니다.
인덱스의 치명적 부작용 (남용 금지)
오해 또는 실수
인덱스는 공짜가 아닙니다
바로잡기
목차 책도 결국 용량을 차지합니다. 모든 컬럼에 인덱스를 다 걸어버리면 목차 책이 원본 책보다 뚱뚱해지는 기현상이 발생합니다.
오해 또는 실수
검색은 빨라지지만, 쓰기(INSERT/UPDATE)는 느려집니다
바로잡기
새로운 유저 '강감찬'이 가입했습니다. 원본 테이블에 한 줄 넣으면 끝나는 게 아니라, 가나다순으로 정렬된 목차 책을 다시 펼쳐서 ㄱ 자리에 강감찬을 끼워 넣는 정렬 작업을 DB가 매번 수행해야 합니다. 글이 써질 때마다 목차를 고치느라 서버가 숨을 헐떡이게 됩니다.
오해 또는 실수
결론
바로잡기
유저들이 검색창에서 '자주 검색하는 조건'이나, JOIN할 때 연결 고리가 되는 컬럼(id 등)에만 족집게처럼 딱 필요한 2~3개의 인덱스만 걸어주는 것이 진정한 고수의 실력입니다.
여러분의 서비스가 느려졌을 때 무작정 서버 사양을 돈 주고 올리기 전에, AI에게 "가장 조회가 자주 일어나는 컬럼들을 분석해서 인덱스를 생성하는 SQL을 짜줘"라고 부탁해 보세요. 돈 한 푼 안 들이고 웹사이트 속도를 100배 이상 올릴 수 있습니다.
개념 퀴즈
퀴즈 답을 맞춰야 학습 완료가 됩니다.게시판에 글이 1,000만 개 쌓여서, 사용자들이 '작성자 이름'으로 검색을 할 때마다 화면이 멈추는 현상이 발생했습니다. 이를 해결하기 위해 백과사전의 '찾아보기'처럼 데이터베이스가 검색 속도를 극적으로 높일 수 있도록 작성자 이름 컬럼에 만들어주어야 하는 것은 무엇인가요?
3줄 요약
- 1데이터가 방대해졌을 때 WHERE 조건 검색이 느려지는 이유는 데이터베이스가 1번부터 끝까지 전부 다 찾아보는 풀 스캔(Full Scan)을 하기 때문입니다.
- 2인덱스(Index)를 생성하면 데이터베이스가 백과사전 색인처럼 정렬된 목차를 만들어 검색 속도를 극적으로 향상시킵니다.
- 3조회 쿼리 앞에 EXPLAIN을 붙여 실행 계획을 점검할 수 있으며, 인덱스를 무분별하게 많이 만들면 오히려 쓰기(추가/수정) 속도가 심각하게 느려지므로 주의해야 합니다.