FastAPI는 왜 사용하는 것일까?

현재 프로젝트에서는 FastAPI를 백엔드 기술스택으로 채택하고 있다. 전체 프로젝트 기술스택 선정 이후에 프로젝트에 참여했기 때문에 당시 의사결정에는 참여하지 않았지만, 프로젝트가 AI를 다루는 프로젝트이다보니 자연스럽게 AI 패키지 통합을 위해 파이썬 프레임워크를 사용했다.

썸네일

FastAPI 프레임워크

FastAPI는 파이썬 언어 위에서 돌아가는 프레임워크이다. Node 진영에는 Express, Nestjs가 있고, Java 진영에는 Spring이 있듯이 파이썬에는 FastAPI, Django 등의 프레임워크가 존재한다. 공식문서도 한국어로 지원하는 웹페이지가 있다.

FastAPI의 장점

FastAPI의 장점은 무엇일까. 이름에 당당하게 Fast를 붙였는데 과연 빠를지도 알아보면 좋을 것 같다.

원래 기본적으로 파이썬은 타입을 추론하는 프로그래밍 언어이기 때문에 추론에 들어가는 오버헤드로 인해 느린 언어라는 것은 유명하게 알려져있다. 그런 파이썬에서 FastAPI 같은 프레임워크를 만들었다는 것이 처음에는 이해하기 어려웠다.

파이썬의 약점을 해결한 Pydantic

개인적으로는 FastAPI에서 가장 핵심적인 역할을 하는 부분이라고 생각이 된다.

Pydantic은 파이썬의 타입 힌트를 기반으로 데이터 유효성 검사 + 파싱 + 직렬화 등을 자동으로 처리해주는 라이브러리이다.

from pydantic import BaseModel

class User(BaseModel):
    username: str
    email: str
    age: int = 25  # 기본값 지정 가능

# 유효한 데이터
user = User(username="john", email="john@example.com")
print(user.age)  # 25 (기본값)

# 잘못된 데이터 → ValidationError 자동 발생
User(username="jane", email=123)  # email은 str이어야 함

FastAPI는 이런 Pydantic을 핵심 엔진으로 사용하고 있다. 최근에는 v2로 업데이트 되면서 내부적으로 Rust를 사용하여 성능이 더 좋아졌다고 한다.

일반적인 모델 검증 ~17x 빨라졌다고 한다.

현대 프로그래밍에서는 타입 일관성을 지키는게 가장 중요하다고 느꼈다. 타입이 일관적이지 못하면 중간에 생기는 사이드이펙트 디버깅에 들어가는 시간과 공수가 너무 많이 들어간다고 생각했다. 그런 점에서 FastAPI를 사용할 때에는 Pydantic 모델을 미리 정의하고 하는 것을 컨벤션으로 지정해두는 것이 좋겠다.

다른 프레임워크에 비해 가지는 장점

사실 이 섹션이 가장 중요할 것 같다. 기술스택을 선택할 때 많은 대체제가 존재하는데 그 중에서 파이썬의 FastAPI를 선택해야하는 이유에 대해서 알아보자.

Python 언어는 고정일 경우라면?

파이썬 언어를 사용해야만 하는 프로젝트라면 FastAPI를 선택해야할 이유는 명확하다.

1️⃣ 압도적인 성능

• FastAPI는 ASGI + Uvicorn 조합으로 동작해서 nodejs 같은 이벤트루프 기반으로 비동기 방식으로 요청을 처리한다. 다른 프레임워크들(Flask, Django)의 블로킹 WSGI 방식과는 다르다.

2️⃣ 자동 문서화 및 검증, 타입 힌트 기반 개발 생산성

• Pydantic 타입 엔진의 강력함이 하나의 무기이다. Pydantic 모델을 한 번만 정의하면 요청 검증, 응답 직렬화, Swagger API Docs 같은 문서를 자동으로 생성해준다.
• 별도의 라이브러리가 해주는 일들을 알아서 해주는 부분이 많아 개발 생산성에서 유리하다.

3️⃣ async / await 지원

• 다른 프레임워크 Flask 같은 경우는 별도 설정 후에 비동기 async/await을 사용할 수 있지만, FastAPI는 비동기를 네이티브하게 지원한다.

4️⃣ 높은 AI 프로젝트 통합도

• 우리 프로젝트에서는 이 경우에 해당했다. AI기반 프로젝트는 파이썬의 높은 AI 패키지 활용도를 활용하는 것이 좋기 때문이다.
• 머신러닝 모델 대부분이 Python으로 개발되기 때문에, 별도 변환 없이 모델을 바로 API 엔드포인트에 연결할 수 있는 점이 강력한 점이다.
• 나의 경우에도 AI 패키지를 모노레포로 관리 중인데 이 패키지의 함수들 별도의 어댑터나 브릿지 없이 바로 사용할 수 있기 때문에 편리한 것 같다.

다른 생태계를 사용해도 된다면?

다른 생태계 그러니까 Python을 고정적으로 사용해야하는 환경이 아니라면 Nest.js나 Spring Boot 같은 다른 프레임워크 옵션들을 선택해볼 수 있다.

그렇다면 이들과의 비교는 어떨까?

평균 응답시간에서는 다른 프레임워크 보다 우위에 있다는 점에 놀랐고, 초기 메모리도 압도적으로 가볍다는 점도 신기했다. FastAPI라고 자신할 만한 성능이라고 생각된다.

실제 테스트 시나리오를 기반으로 성능 비교를 했을 때는 아래와 같은 결과를 보여준다.

테스트 시나리오 별 처리량 차트

JSON 직렬화 같은 간단한 작업의 경우에는 FastAPI가 좋은 성능을 보여주지만, DB가 붙는 순간 다른 프레임워크에 비해 성능이 낮아지는 경우를 볼 수 있다.

약점은 무엇인가?

하지만 약점도 명확하다.

바로 생태계와 그 성숙도의 차이이다.

java와 node 진영은 라이브러리 배포와 사용 생태계가 잘 갖춰져있고 성숙되었다. 하지만 파이썬은 약간은 열받는 버전 별 큰 차이점들과 비동기를 적극적으로 사용하는 프레임워크지만 생태계 전반에 비동기를 지원하는 라이브러리의 부족과 성숙도 낮음 문제가 명확한 약점이다.

이게 생태계 성숙도를 무시할 수 없는 이유가 있다. 이전 섹션에서 FastAPI와 다른 프레임워크(Spring Boot, Nestjs)와의 비교에서 단순 작업의 처리량은 제일 빠르지만 DB쿼리의 경우는 낮아지는 모습을 확인했다. 그 이유는 아래 생태계의 성숙도 때문이라고 볼 수 있다.

FastAPI는 분명 빠르지만, 비동기를 지원하지 않는 라이브러리를 함께 사용하는 순간 비동기의 이점이 사라진다. 예를 들어 동기 ORM이나 동기 DB 드라이버를 그대로 쓰면, 이벤트 루프가 블로킹되어 오히려 성능이 떨어질 수 있다.

GIL의 존재로 인한 CPU 집약적 작업 처리 비효율

이 부분은 Python 자체의 약점이지만, FastAPI는 Python 위에서 동작하는 프레임워크이기 때문에 영향을 받는 부분이다. GIL(Global Interpreter Lock) 은 Python 인터프리터가 한 번에 하나의 스레드만 실행하도록 제한하는 락이다.

이로 인해 **CPU 집약적인 작업(이미지 처리, 대용량 연산 등)**에서는 멀티스레드를 써도 병렬화가 되지 않아 오히려 스레드 전환 오버헤드만 생기는 경우가 있다. 이런 작업이 필요하다면 multiprocessing이나 Celery 같은 별도 태스크 큐로 분리하는 것이 일반적인 해결책이라고 한다.

이렇게 적어보니 명확하게 나오는 것 같다.

결론

선택해야하는 경우

• AI / ML 프로젝트이다.
• Python을 써야하는데 빠른 성능을 원한다.

선택하지 않아도 되는 경우

AI / ML 프로젝트가 아니고, 팀의 주력 언어가 TypeScript나 Java라면 NestJS나 Spring Boot가 생태계 성숙도 면에서 유리하다.

출처

벤치마크통계 자료 출처 techmpower round 22