FastAPI와 Supabase 연동 서버 최적화: DB 인덱싱(Indexing)으로 API 응답 속도 10배 끌어올리기

👤 인스피

조회 수 11

1. 병목의 원인 파악: 문제는 코드가 아니라 'DB 검색 방식'에 있었다

처음에는 제 파이썬 코드가 비효율적인 줄 알고 FastAPI의 비동기(async/await) 로직을 수십 번 뜯어보았습니다. 하지만 서버의 자원(CPU, RAM)은 널널하게 놀고 있었습니다.

원인은 백엔드 코드가 아니라, 뒤에 붙어있는 데이터베이스(Supabase)에 있었습니다. Supabase의 SQL 에디터를 열고, 특정 카테고리의 글을 불러오는 쿼리를 날려보았습니다.

SELECT id, title, created_at FROM posts WHERE category = 'IT 게시판' ORDER BY created_at DESC;

게시글이 몇백 개일 때는 금방 찾았지만, 전체 데이터가 4만 개에 육박하자 데이터베이스는 'IT 게시판' 글을 찾기 위해 1번 글부터 4만 번 글까지 처음부터 끝까지 하나하나 뒤져보는 이른바 '풀 테이블 스캔(Full Table Scan)'을 하고 있었던 것입니다. 두꺼운 백과사전에서 특정 단어를 찾기 위해 1페이지부터 끝장까지 눈으로 다 훑고 있는 셈이었죠.

2. 구원 투수 등장: 데이터베이스의 목차, 인덱스(Index) 생성하기

원인을 알았으니 해결책은 명확했습니다. 데이터베이스에 '목차'를 만들어주는 것입니다. 전공 용어로는 인덱싱(Indexing)이라고 부릅니다.

백과사전 맨 뒤에 있는 '찾아보기(색인)' 페이지를 이용하면, 단어의 위치를 1초 만에 찾을 수 있는 것과 완벽하게 똑같은 원리입니다. 저는 유저들이 가장 많이 검색하는 조건인 category 칼럼과, 최신순 정렬을 위해 매번 사용하는 created_at 칼럼에 복합 인덱스를 걸어주기로 했습니다.

Supabase는 내부에 강력한 PostgreSQL을 품고 있기 때문에, 아주 간단한 SQL 명령어 한 줄이면 인덱스를 생성할 수 있습니다. 저는 SQL 에디터에 다음과 같은 명령어를 입력했습니다.

CREATE INDEX idx_posts_category_created ON posts (category, created_at DESC);

엔터를 치는 순간, 데이터베이스 내부에서는 4만 개의 데이터를 카테고리별로, 그리고 시간순으로 깔끔하게 정리한 '비밀 목차'를 생성하기 시작했습니다. 작업은 불과 몇 초 만에 끝났습니다.

3. 결과 확인: 800ms 딜레이가 40ms로, 무려 20배의 속도 향상

"과연 얼마나 빨라졌을까?" 떨리는 마음으로 FastAPI 서버를 재가동하고, API 테스트 도구(Postman)를 이용해 똑같은 게시물 목록 호출 API를 날려보았습니다.

결과는 그야말로 충격적이었습니다. 인덱스를 걸기 전에는 800ms(0.8초) 가까이 걸리며 굼벵이처럼 응답하던 API가, 이제는 단 40ms(0.04초) 만에 JSON 데이터를 뱉어내기 시작했습니다. 무려 20배 가까운 성능 향상이었습니다.

실제 웹사이트에 접속해서 탭을 눌러보니, 클릭과 동시에 로딩 스피너를 볼 새도 없이 즉각적으로 게시물 목록이 화면에 렌더링 되었습니다. 풀 테이블 스캔으로 허덕이던 데이터베이스가, 이제는 인덱스라는 목차를 보고 필요한 데이터만 쏙쏙 뽑아서 백엔드로 전달해주기 때문입니다.

맺으며: 기본기의 중요성, 프레임워크 너머를 보자

1인 개발을 하다 보면 눈에 당장 보이는 화려한 프론트엔드 UI나 최신 백엔드 프레임워크 기술에만 집착하기 쉽습니다. 저 역시 FastAPI라는 최신 비동기 프레임워크를 썼으니 무조건 빠를 것이라는 착각에 빠져 있었습니다.

하지만 결국 데이터를 담아두고 꺼내는 근본적인 그릇은 '데이터베이스'입니다. 아무리 서버 코드를 최적화하더라도, DB 구조가 비효율적이면 서비스는 반드시 병목 현상을 겪게 된다는 뼈저린 교훈을 얻었습니다.

오늘도 트래픽 증가와 API 속도 저하로 고통받고 계신 개발자분이 계신다면, 서버 사양(RAM, CPU)을 돈 주고 업그레이드하기 전에 반드시 쿼리 실행 계획(EXPLAIN)을 분석해 보고 인덱스가 제대로 걸려 있는지 확인해 보시길 강력히 권장합니다. 명령어 한 줄이 서버 비용 수십만 원을 아껴주는 마법을 경험하실 수 있을 것입니다.