Flask는 죽었는가? FastAPI가 미래인가?

제가 관련 검색을 하는 동안, 2024년에도 여전히 많은 사람들이 Flask를 Python 웹 프레임워크로 추천하는 것을 알게 되었습니다. 그러나 제 생각에는 "Flask는 사라져가고 있고, FastAPI가 미래를 대표합니다." 그래서 이 글을 쓰고 있습니다. 저는 모든 분들이 토론에 참여하여 반론을 제시해 주시기를 환영합니다.

Flask vs FastAPI

Flask는 Python 개발자들의 마음속에 중요한 위치를 차지하고 있습니다. 웹 개발자라면 Flask를 사용해 보셨을 가능성이 높지만, FastAPI는 아직 사용해 보지 않으셨을 수도 있습니다.

다음은 두 가지 증거입니다.

지난 1~2년 동안 웹 개발과 관련된 주요 새로운 Python 프로젝트에서 웹 개발과 관련된 거의 모든 프로젝트가 FastAPI를 채택했습니다.
2024년 12월 25일 현재 GitHub에서 FastAPI의 스타 수(78.9k)는 이미 Flask(68.4k)의 스타 수를 넘어섰습니다.

이제 공식 Python 개발자 설문 조사에서 웹 프레임워크의 비중 변화를 살펴보겠습니다.

2019년에는 FastAPI가 옵션으로조차 나열되지 않았지만, 2022년에는 그 점유율이 25%에 도달한 것이 분명합니다. (현재 2022년까지의 데이터만 있습니다.)

이 비율 데이터는 기존 시스템을 포함하므로 Django와 Flask의 비율이 급격히 떨어지지는 않을 것이라는 점에 유의해야 합니다. 그럼에도 불구하고 추세는 분명합니다.

웹 프레임워크 분야는 매우 다작이며 거의 매년 새로운 프레임워크가 등장한다는 것을 우리는 모두 알고 있습니다. 이러한 프레임워크의 대부분은 단명하지만, 일부는 살아남습니다. FastAPI는 2018년 말에 탄생하여 2019년 말경에 이름을 알리기 시작했습니다. 그렇다면 2010년 말에 탄생한 Flask를 단 5년 만에 어떻게 인기를 따라잡을 수 있었을까요? 다음으로, 더 나은 이해를 위해 Python 웹 프레임워크 및 관련 솔루션의 개발 역사를 타임라인에 따라 추적해 보겠습니다.

웹 프레임워크의 발전 (플러그인, 도구)

FastAPI의 작성자는 Python 생태계의 발전에 매우 주의를 기울이는 개발자입니다. 확장 읽기 링크 2는 작성자가 작성한 "대안, 영감 및 비교"(https://fastapi.tiangolo.com/alternatives/)이며, FastAPI가 다양한 라이브러리에서 얻은 참조 또는 영감에 대해 자세히 설명합니다. 이 기사의 개발 역사 섹션도 이 글을 참조합니다. FastAPI의 등장 배경과 작성자의 설계 개념이 담겨 있으므로 원문을 읽어보시는 것을 추천합니다.

Flask

Flask는 Django와는 완전히 다른 "마이크로" 프레임워크입니다. 몇 가지 핵심 기능만 유지하고 분리하기 위해 다른 기능을 여러 라이브러리(예: Jinja2, Werkzeug 등)로 분할합니다. 이를 통해 개발자는 충분한 자유를 얻고 관련 기능에 대한 타사 플러그인을 쉽게 작성할 수 있습니다. blueprints, contexts, 라우트, 신호 등을 나타내는 decorators와 같은 내부 설계는 당시에는 상당히 발전되었습니다. 포괄적인 문서와 함께 제공되어 초보자에게 매우 친숙합니다.

Flask REST Frameworks

단순성 덕분에 Flask는 API를 구축하는 데 매우 적합합니다. 그러나 Flask 자체에는 내장된 기능이 없으므로 특수 REST 프레임워크가 필요합니다. 결과적으로 flask-restful, Flask-RESTPlus 및 flask-api와 같은 프레임워크가 잇따라 등장했습니다. 또한 REST 서비스에는 데이터 유효성 검사, 파싱 및 사양에 대한 요구 사항이 있으므로 Marshmallow, Webargs 및 APISpec이 등장하여 Flask-apispec이 등장했습니다. 그러나 이러한 개발 과정에서 DRF에 필적할 만한 Flask REST Framework는 실현되지 않았습니다.

이 단계에서 Flask의 단점이 점차 드러났습니다.

Flask의 원래 강점은 유연성과 미니멀리즘에 있지만, 이는 또한 많은 구성 요소를 사내에서 개발해야 함을 의미합니다. 이는 개발 및 유지 관리를 위한 전담 개발자가 있는 대기업 또는 매우 유능한 개인 개발자가 필요합니다. 그렇지 않으면 플러그인이 프로덕션 품질에 도달하기가 어렵고 Flask용 타사 플러그인이 혼합되어 장기적인 유지 관리가 보장되지 않습니다. 앞서 언급했듯이 많은 라이브러리가 이미 유지 관리가 중단되었습니다.

따라서 오늘날에도 Flask로 API 서비스를 구축하려면 여전히 다양한 구성 요소를 조합해야 합니다. 적시에 업데이트되지 않은 일부 구성 요소의 경우 직접 문제를 해결해야 합니다. 베테랑은 처리할 수 있지만 초보자에게는 특히 최신 사례와 개념을 적용하려는 경우 다소 벅찰 수 있습니다.

Asyncio 생태계

Python 3.5 이후 asyncio는 미래의 추세였습니다. 결과적으로 aiohttp, Starlette 및 sanic과 같이 asyncio를 기본적으로 지원하는 일부 웹 프레임워크가 등장했습니다.

이때 Flask는 적응하기를 꺼렸습니다. 커뮤니티는 asyncio 지원을 추가하는 데 느렸고 Flask의 원래 작성자는 Rust를 작성하는 것으로 전환하여 프로젝트를 두 명의 유지 관리자에게 맡겼습니다 (현재는 한 명만 남았습니다).

apistar 및 molten과 같은 API 서비스 구축 프로젝트는 모두 FastAPI 탄생에 대한 설계 영감을 제공했습니다.

FastAPI

그런 다음 FastAPI가 탄생했습니다. 작성자는 원래 좋은 솔루션을 찾고 있었지만 위의 상황에는 각각 고유한 문제 또는 제한 사항이 있었습니다. 그래서 작성자는 이 새로운 프레임워크를 만들었습니다.

FastAPI가 돋보이는 이유

이것이 기사의 핵심 부분입니다. 다음과 같은 이유는 FastAPI가 Flask를 대체할 수 있는 이유입니다.

Pydantic을 사용한 사용자 데이터 유효성 검사

API 개발 과정에서 데이터 형식 유효성 검사, 구문 분석 및 직렬화는 일상적인 작업입니다. 수년에 걸쳐 여러 솔루션이 등장했으며 현재 Pydantic이 최고의 선택입니다.

from fastapi import FastAPI
from pydantic import BaseModel


class Item(BaseModel):
    name: str
    description: str | None = None
    price: float
    tax: float | None = None


app = FastAPI()


@app.post("/items/")
async def create_item(item: Item):
    return item

언뜻 보면 이 코드는 ORM 또는 데이터 클래스를 작성하는 방식처럼 보일 수 있지만 실제로는 Python의 기본 Type Hints 구문을 사용하여 필드 유형을 주석 처리합니다. 예를 들어 위의 예에서 /items/ 요청의 Item 스키마가 명확하게 정의되었고 각 필드의 값 유형이 명시적입니다. 스키마 설명 또는 하드 코딩을 사용하는 이전 방법에 비해 이 접근 방식은 더 간결하고 Python 스타일에 더 부합하며 IDE 지원이 더 좋습니다.

현재 Pydantic은 사용자 데이터 유효성 검사 분야를 지배하고 있습니다. FastAPI에 내장되어 있으므로 유효성 검사 프로세스가 크게 단순화되고 오류가 줄어듭니다. 이것이 FastAPI 공식 웹사이트에서 이 솔루션이 개발자의 오류를 최대 40%까지 줄일 수 있다고 언급하는 이유입니다. Python과 같은 동적 언어의 경우 mypy를 사용하여 유형 검사를 수행하지 않으면 Pydantic을 적용하는 것이 필수적입니다.

또한 Pydantic 통합 덕분에 프로젝트에 ORM (예: SQLAlchemy)을 추가하는 것이 매우 쉬워집니다. 데이터 유효성 검사가 이미 완료되었으므로 요청에서 얻은 객체를 데이터베이스로 직접 전달할 수 있습니다. 반대로 데이터베이스에서 검색된 객체를 직접 반환할 수도 있습니다.

대조적으로 Flask는 이 점에서 부족합니다.

비동기 설계

Flask 시대에는 코드 실행이 단일 스레드 및 동기식이었습니다. 이는 요청을 하나씩 처리해야 하고 다른 요청은 이전 요청이 완료되기 전에 I/O 작업을 기다리는 데 시간을 낭비한다는 의미입니다. 반면에 Asyncio는 최적의 솔루션입니다. I/O 작업을 비동기식으로 만들 수 있으므로 작업이 완료될 때까지 기다리지 않고 작업 결과를 얻은 다음 다른 작업 요청을 처리할 수 있습니다.

FastAPI는 동시 및 비동기 코드를 기본적으로 지원합니다. 코드가 올바르게 작성되어 있는 한 최고 효율성을 달성할 수 있습니다. 따라서 현재 가장 빠른 Python 프레임워크로 간주되며 NodeJS 또는 Go와 유사한 효율성을 제공합니다. 속도와 성능이 가장 중요한 경우 FastAPI가 의심할 여지 없이 최상의 선택입니다.

ASGI에 대한 기본 지원

먼저 WSGI에 대해 언급하겠습니다. 전체 이름은 "Python 웹 서버 게이트웨이 인터페이스"이며 "PEP 3333"(https://peps.python.org/pep-3333/)에서 참조할 수 있습니다. 웹 애플리케이션과 서버 간의 상호 작용을 위해 특별히 작성된 Python 표준입니다. PHP 또는 Ruby를 사용했다면 더 쉽게 이해할 수 있습니다. Flask는 WSGI 제품군인 Werkzeug에 의존하므로 Flask는 이 오래된 WSGI 표준을 지원하고 ASGI는 지원하지 않습니다.

WSGI의 문제는 비동기성을 활용하여 성능과 효율성을 높일 수 없다는 것입니다. 따라서 Django 채널은 ASGI를 개척했습니다. 전체 이름은 "비동기 서버 게이트웨이 인터페이스"이며 반복적이고 거의 완전히 재설계된 표준입니다. 비동기 서버/애플리케이션 인터페이스를 제공하고 HTTP, HTTP/2 및 WebSocket을 지원합니다. WSGI와 달리 ASGI는 각 애플리케이션이 여러 개의 비동기 이벤트를 가질 수 있도록 합니다. 또한 ASGI는 동기 및 비동기 애플리케이션을 모두 지원합니다. 기존 동기 WSGI 웹 애플리케이션을 ASGI로 마이그레이션하거나 ASGI를 사용하여 새로운 비동기 웹 애플리케이션을 구축할 수 있습니다.

결론을 내리기 전에 5가지 용어 설명을 추가하겠습니다.

ASGI 툴킷: URL 라우팅, Request/Response 객체, 템플릿 엔진 등과 같은 ASGI 관련 기능을 구현하는 라이브러리입니다. 이 기사에서는 주로 Flask의 종속성인 Werkzeug에 해당하는 Starlette를 의미합니다.
ASGI 웹 프레임워크: ASGI 사양을 구현하는 웹 프레임워크 (예: FastAPI), 반면 Flask와 Django는 WSGI를 구현하는 웹 프레임워크입니다. 이러한 프레임워크는 개발자가 사용하기 쉬운 인터페이스로 애플리케이션을 작성할 수 있도록 설계되었습니다. 개발자는 필요에 따라 비즈니스 로직만 채우면 됩니다. 초기 프레임워크는 대부분 ASGI 툴킷을 내부적으로 구현했지만, 나중 프레임워크는 일반적으로 적합한 툴킷을 결합합니다. 예를 들어 Flask는 Werkzeug (자체)를 사용하고 FastAPI는 Starlette (다른 사람으로부터)를 사용합니다.
웹 애플리케이션: 웹 프레임워크를 사용하여 만든 애플리케이션은 웹 애플리케이션입니다. 일반적으로 웹 프레임워크에는 개발 및 디버깅을 위해 시작할 수 있는 테스트 서버가 함께 제공됩니다. 성능과 안정성이 중요하지 않은 경우 브라우저에서 개발 주소에 액세스하여 이 애플리케이션을 방문할 수 있습니다.
웹 서버: 현실 세계는 예상보다 더 복잡합니다. 웹 애플리케이션이 프로덕션 환경에 배포된 후에는 요청 로드 밸런싱, 정적 파일 제공, 액세스 제어 및 리버스 프록시와 같은 요구 사항을 고려해야 하며, 고성능 요구 사항도 있습니다. 웹 프레임워크의 내장 웹 서버는 이러한 요구 사항을 전혀 충족할 수 없으므로 전문 웹 서버가 필요합니다. 현재 Nginx가 주류 선택입니다.
ASGI 서버: ASGI 서버는 웹 서버와 웹 애플리케이션 간의 다리 역할을 합니다. ASGI 서버도 ASGI 사양을 준수하지만 주요 작업은 요청 전달의 성능 요구 사항을 충족하는 것이므로 주로 ASGI의 "G" (게이트웨이) 부분을 담당합니다. 해당 코드는 개발자가 웹 애플리케이션 비즈니스 및 라우팅 로직을 작성하는 데 적합하지 않습니다. 현재 가장 잘 알려진 ASGI 서버는 Uvicorn이며 원래 WSGI 서버 Gunicorn에서 제공되는 uvicorn.workers.UvicornWorker도 옵션입니다. 이것이 프로덕션 환경에서 권장되는 사용법입니다.

과거에는 WSGI에 대한 프로덕션 환경 솔루션이 일반적으로 Nginx + Gunicorn + Flask (Django)였지만 요즘에는 ASGI에 대한 프로덕션 환경 솔루션이 Nginx + Uvicorn + FastAPI입니다.

한 가지 더. FastAPI의 이름과 소개에서 판단하건대 API 서비스 구축을 위해 설계된 것이 분명합니다. 실제로 핵심 코드는 바로 그와 같습니다. 기존의 완전히 자체 구현된 프레임워크가 아니라 다양한 프레임워크의 강점을 결합한 프레임워크라고 할 수 있습니다. 빈 셸에서 시작하여 필요한 적절한 구성 요소를 조립합니다. 예를 들어 템플릿 엔진이 없습니다. 템플릿 렌더링이 필요한 웹 애플리케이션을 구축하는 데 실제로 사용해야 하는 경우 필요한 템플릿 엔진을 선택하고 결합할 수 있습니다. 물론 Starlette (예, Flask에도 내장되어 있음)에 내장된 Jinja2를 사용할 수도 있습니다.

Flask가 죽었다고 하는 이유

위에서 언급한 FastAPI의 장점만으로는 Flask가 죽었다고 결론지을 수 없습니다. 그렇다면 왜 이런 견해를 갖게 되었을까요? 주로 개발자와 사용자 간의 인기에 달려 있습니다.

여기서 "인기"는 다소 주관적입니다. 제가 생각할 수 있는 지표는 다음과 같습니다.

커뮤니티 활동(https://github.com/pallets/flask/issues): 예를 들어 프로젝트의 이슈 및 풀 요청 수를 살펴보겠습니다. Flask는 한 자릿수 숫자만 가지고 있으며 이는 FastAPI와 비교하여 완전히 다른 리그에 있습니다. 이는 실제로 프로젝트가 더 이상 활성화되지 않는다는 것을 측면에서 반영합니다. 프로젝트가 활성화되면 기존 사용자에게 더 많은 요구 사항이 발생합니다. 질문을 멈추면 떠났다는 의미입니다. 그리고 새로운 사용자는 확실히 모든 종류의 문제를 겪을 것입니다. 자세한 문서가 있더라도 여전히 질문을 하고 코드를 기여하는 사용자가 많아야 합니다. 그러한 상황이 부족하면 사용자가 적다는 것을 나타냅니다.
토론 열기: 즉, 블로그 게시물, Stack Overflow 및 기타 웹사이트에서 문의 및 토론의 인기입니다. 요즘 Flask에 대해 글을 쓰는 사람이 거의 없다는 것은 매우 분명합니다.
개발 반복 빈도(https://github.com/pallets/flask/pulls): 커밋 기록을 살펴보면 Flask에는 버그를 수정하는 유지 관리자가 한 명만 있으며 주요 기능 개발은 없습니다.
핵심 인물의 영향력: Flask의 핵심 인물인 프로젝트 개시자가 오랫동안 프로젝트에 참여하지 않았습니다. 프로젝트 기여 기록에 따르면 Armin Ronacher는 6년 전에 마지막으로 개발에 기여했습니다.

제 생각에는 이러한 모든 상황이 Flask의 전성기가 지났고 FastAPI가 떠오르는 별이라는 것을 시사합니다.

마지막으로 Flask/FastAPI 배포에 이상적인 플랫폼인 Leapcell을 소개하겠습니다.

Leapcell은 최신 분산 애플리케이션을 위해 특별히 설계된 클라우드 컴퓨팅 플랫폼입니다. 사용량에 따라 지불하는 가격 모델은 유휴 비용이 없음을 보장하므로 사용자는 실제로 사용하는 리소스에 대해서만 비용을 지불합니다.

WSGI/ASGI 애플리케이션을 위한 Leapcell의 고유한 장점:

1. 다국어 지원

JavaScript, Python, Go 또는 Rust로 개발을 지원합니다.

무제한 프로젝트의 무료 배포

사용량에 따라 청구합니다. 요청이 없으면 요금이 부과되지 않습니다.

2. 타의 추종을 불허하는 비용 효율성

사용량에 따라 지불하며 유휴 요금이 없습니다.
예를 들어 $25는 694만 건의 요청을 지원할 수 있으며 평균 응답 시간은 60밀리초입니다.

3. 간소화된 개발자 경험

쉬운 설정을 위한 직관적인 사용자 인터페이스.
완전 자동화된 CI/CD 파이프라인 및 GitOps 통합.
실시간 메트릭 및 로그를 제공하여 실행 가능한 인사이트를 제공합니다.

4. 손쉬운 확장성 및 고성능

높은 동시성을 쉽게 처리할 수 있도록 자동 확장합니다.
운영 오버헤드가 없으므로 개발자는 개발에 집중할 수 있습니다.

설명서!에서 자세히 알아보세요.

Leapcell Twitter: https://x.com/LeapcellHQ