FastAPI와 Redis를 활용한 1인 개발자의 백엔드 최적화 여정

👤 인스피

조회 수 6

1. 왜 수많은 파이썬 프레임워크 중 'FastAPI'였을까?

일반적으로 파이썬(Python)으로 웹 서버를 만든다고 하면 십중팔구 장고(Django)나 플라스크(Flask)를 가장 먼저 떠올리실 겁니다. 방대한 생태계와 레퍼런스를 자랑하는 훌륭한 도구들이죠. 하지만 저는 과감하게 이들을 뒤로하고 상대적으로 후발주자인 FastAPI를 선택했습니다. 그 결정적인 이유는 바로 '네이티브 비동기(Asynchronous) 처리' 지원 때문이었습니다.

기존의 동기(Synchronous) 방식 프레임워크는 식당으로 비유하자면 '비효율적인 종업원'과 같습니다. 1번 테이블 손님이 주문한 음식이 주방에서 나올 때까지 주방장 앞에서 가만히 서서 기다립니다. 그동안 2번, 3번 테이블 손님은 주문조차 하지 못하고 방치되죠. 트래픽이 몰리면 서버가 그대로 멈춰버리는(병목 현상) 주된 원인입니다.

반면 FastAPI는 태생부터 비동기를 지원합니다. 종업원이 1번 테이블의 주문을 주방에 넣자마자, 요리가 나오는 시간을 기다리지 않고 즉시 2번 테이블로 이동해 다음 주문을 받습니다. I/O 작업(데이터베이스 조회, 외부 API 통신 등)이 완료될 때까지 CPU를 놀리지 않고 다른 요청을 끊임없이 처리하는 것입니다. 이 차이는 수백 명의 유저가 동시에 게시판을 클릭할 때 사이트가 버티느냐 무너지느냐를 가르는 결정적인 차이를 만들어냅니다.

2. 데이터베이스의 비명 소리, 비동기 SQLAlchemy로 잠재우다

웹 프레임워크를 비동기로 바꿨다고 해서 모든 문제가 해결되는 것은 아닙니다. 서버 로직이 아무리 빨라도 데이터를 꺼내오는 창고, 즉 관계형 데이터베이스(RDBMS)로 가는 통로가 꽉 막혀있다면 결국 응답 속도는 느려집니다.

초기에는 쪽지 기능이나 복잡한 게시글 목록을 불러올 때, 그 악명 높은 'N+1 쿼리 문제'가 발생하며 데이터베이스가 비명을 질러댔습니다. 10개의 글을 불러오기 위해 11번의 통신을 하는 끔찍한 비효율이었죠. 이를 해결하기 위해 백엔드에 비동기 SQLAlchemy(Async SQLAlchemy)를 전면 도입했습니다.

기존의 꽉 막힌 단방향 도로를 다차선 고속도로로 뚫어주는 작업이었습니다. selectinload와 같은 즉시 로딩(Eager Loading) 기법을 활용해, 게시글을 가져올 때 작성자의 프로필 정보까지 단 한 번의 비동기 쿼리로 모두 묶어서 끌고 오도록 아키텍처를 전면 수정했습니다. 그 결과, 페이지를 렌더링하는 데 걸리던 서버 처리 시간이 기존 대비 70% 이상 단축되는 놀라운 성과를 거둘 수 있었습니다.

3. 궁극의 무기: Redis 인메모리 캐싱(Caching)의 도입

아무리 데이터베이스 쿼리를 최적화해도, 모든 사용자가 메인 페이지에 접속할 때마다 매번 하드디스크 기반의 스토리지를 뒤적거리는 것은 서버의 체력을 갉아먹는 일입니다. 특히 검색엔진 로봇(SEO)이나 수많은 사람들이 반복해서 읽는 'IT 게시판'과 '메인 통합 목록'은 더더욱 그렇습니다.

그래서 저는 데이터베이스 앞단에 Redis(레디스)를 캐시 서버로 배치했습니다. Redis는 데이터를 느린 하드디스크가 아닌, 빛처럼 빠른 컴퓨터의 메모리(RAM) 위에 올려두고 서비스하는 인메모리(In-Memory) 시스템입니다.

유저가 메인 화면을 요청하면, 서버는 무거운 데이터베이스를 먼저 찌르지 않습니다. 가볍고 빠른 Redis에게 "혹시 아까 만들어둔 메인 화면 데이터 있어?"라고 물어봅니다. 만약 데이터가 있다면 밀리초(ms) 단위로 즉시 유저에게 화면을 던져줍니다. 이를 통해 백엔드 데이터베이스의 부하를 거의 0에 가깝게 줄여버렸습니다. 물론 데이터가 오래되는 것을 막기 위해 일정 시간마다 백그라운드에서 데이터를 최신화하는 SWR(Stale-While-Revalidate) 패턴도 함께 적용하여, 유저들은 언제나 지연 없는 쾌적한 화면을 볼 수 있게 되었습니다.

맺으며: 1인 개발자에게 최적화란 '생존'입니다

막대한 자본을 투자하여 무한정 서버 인프라(컴퓨팅 파워)를 늘려버리는 이른바 '스케일 업(Scale-up)'을 자유롭게 할 수 없는 1인 개발자에게, 코드 최적화와 효율적인 아키텍처 설계는 선택이 아닌 생존의 문제입니다.

파이썬과 FastAPI, 그리고 Redis를 엮어내며 수많은 에러 로그와 마주했지만, 튜닝이 끝난 로직이 모니터에 0.01초 단위의 빠른 응답 속도를 찍어줄 때의 그 짜릿함은 이루 말할 수 없습니다. 커뮤니티는 결국 '유저의 쾌적한 경험'이 전부라는 사실을 서버 관리 대시보드를 보며 다시 한번 깨닫습니다.