"내 사이트가 왜 이렇게 느려졌지?" 데이터의 무게를 체감하다

👤 인스피

조회 수 12

1. 병목의 원인: 무식하게 다 뒤지는 '풀 테이블 스캔(Full Table Scan)'

문제를 파악하기 위해 저는 제 FastAPI 코드에서 DB로 날아가는 SQL 쿼리를 점검했습니다. 특정 카테고리의 최신 글 20개를 가져오는 아주 평범한 로직이었습니다.

글이 100개일 때는 이 쿼리가 0.01초 만에 실행되었습니다. 하지만 글이 10,000개가 넘어가자 DB는 다음과 같이 행동하고 있었습니다. "주인님이 카테고리 5번 글을 찾아달라고 하네? 음... 어딘지 모르니까 1번 글부터 10,000번 글까지 하나하나 다 읽어보면서 카테고리 5번인 걸 골라내야겠다!"

이것을 데이터베이스 용어로 '풀 테이블 스캔(Full Table Scan)'이라고 부릅니다. 책에서 특정 단어를 찾을 때 색인(목차)을 보지 않고 첫 페이지부터 끝 페이지까지 모두 읽으면서 찾는 것과 똑같은 비효율적인 행동을 하고 있었던 것입니다. 서버의 CPU가 비명을 지르는 것은 당연했습니다.

2. 구원투수 등장: 데이터베이스 인덱스(Index)의 마법

이 문제를 해결하는 가장 확실하고 우아한 방법은 데이터베이스에 '인덱스(Index, 색인)'를 만들어 주는 것입니다.

인덱스란 책 맨 뒷장에 있는 '찾아보기(색인)'와 같습니다. "카테고리 5번 글은 100페이지, 250페이지, 800페이지에 있어!"라고 미리 정렬된 지도를 DB 서버 메모리에 올려두는 것입니다. 저는 즉시 DB 접속 툴(DBeaver)을 열고, 제가 자주 검색 조건(WHERE)으로 사용하는 컬럼들에 인덱스를 걸어주는 SQL 명령어를 실행했습니다.

3. 극적인 변화: 2초에서 0.05초로의 퀀텀 점프

인덱스 생성을 완료하는 데는 불과 5초도 걸리지 않았습니다. 떨리는 마음으로 다시 웹사이트에 접속해 게시판 카테고리를 클릭해 보았습니다.

결과는 그야말로 충격적이었습니다. 방금 전까지 2초 넘게 딜레이 되며 답답하게 열리던 게시판 목록이, 클릭과 동시에 눈 깜짝할 새(약 50ms) 화면에 뿌려졌습니다. 다시 쿼리 실행 계획을 살펴보니, DB는 더 이상 10,000개의 글을 다 뒤지지 않았습니다. 인덱스(지도)를 쓱 보고 정확히 카테고리 5번에 해당하는 글 20개만 '콕' 집어서 가져오는 '인덱스 스캔(Index Scan)'으로 완벽하게 동작 방식이 바뀌어 있었습니다.

백엔드 로직(파이썬 코드)이나 서버 사양을 단 하나도 건드리지 않고, 오직 DB 인덱싱 명령어 두 줄만으로 사이트의 체감 속도를 10배 이상 끌어올린 것입니다.

맺으며: 1인 개발자일수록 기본기(DB)에 충실해야 한다

웹 개발을 처음 시작할 때는 화려한 프론트엔드 UI나 트렌디한 최신 프레임워크에 눈길이 가기 마련입니다. 저 역시 그랬습니다. 하지만 서비스가 커지고 실제 트래픽과 데이터가 쌓이기 시작하면, 결국 서비스의 생사를 가르는 것은 가장 밑단에 있는 데이터베이스의 성능이라는 것을 뼈저리게 깨달았습니다.

아무리 서버를 오토스케일링(Scale-out)으로 여러 대 늘려봤자, 정작 데이터를 가져오는 DB가 병목을 일으키면 아무 소용이 없습니다.

혹시 지금 운영 중인 웹사이트나 앱이 이유 없이 느려지고 있나요? 그렇다면 백엔드 코드를 엎기 전에 가장 먼저 데이터베이스 쿼리를 점검하고, 자주 찾는 컬럼에 인덱스(Index)가 제대로 걸려 있는지 확인해 보시기 바랍니다. 이 작은 '색인' 하나가 여러분의 서비스와 서버를 구원해 줄 것입니다!

❓ 자주 묻는 질문 (FAQ)

Q1. 인덱스(Index)가 그렇게 좋다면, 모든 컬럼에 다 걸어두면 안 되나요?

A. 절대 안 됩니다! 인덱스는 마법의 약이 아닙니다. 인덱스를 만들면 조회가 엄청나게 빨라지는 대신, 새로운 글을 쓰거나(INSERT) 수정/삭제(UPDATE/DELETE)할 때마다 '지도(인덱스)'도 같이 업데이트해야 하므로 쓰기 속도가 느려집니다. 따라서 회원 ID, 카테고리, 날짜 등 조회 시 자주 조건으로 쓰이는 핵심 컬럼 2~3개에만 전략적으로 거는 것이 실무의 핵심입니다.

Q2. 제 DB에는 어떤 쿼리가 느린지 어떻게 찾을 수 있나요?

A. 데이터베이스마다 느린 쿼리를 찾아내는 기능이 있습니다. PostgreSQL이나 MySQL의 경우 Slow Query Log를 설정해 두면 특정 시간(예: 1초) 이상 걸리는 악성 쿼리들을 로그로 남겨줍니다. 백엔드 개발자라면 주기적으로 이 로그를 모니터링하여 병목을 찾아 인덱스를 추가해야 합니다.

Q3. 데이터가 몇 개 없을 때도 인덱스를 만들어야 하나요?

A. 데이터가 수백~수천 건 이하일 때는 DB 엔진이 인덱스를 읽는 것보다 그냥 전체 테이블을 훑어버리는 게 더 빠르다고 판단하기도 합니다. 따라서 서비스 초기보다는, 데이터가 유의미하게 쌓이기 시작하여 속도 저하가 체감될 때 도입하는 것을 추천합니다.