파이썬 웹프레임워크 왕중왕전!
파이썬으로 아무리 다른 멋진 작업을 많이 할 수 있다해도 가장 수요도 많고 생산성을 높이며, 수익성도 좋은 것은 웹서비스의 백엔드서버로 파이썬을 사용하는 것이 아닌가 하는 생각이 듭니다. 파이썬에는 수많은 웹프레임워크가 있고 그 중에 당연 으뜸으로 Django 가 자리 하고 있고 그 아래에 Flask, Tornado 등 많은 프레임워크가 있습니다.
파이썬 웹프레임워크 리스트
- Django - http://www.djangoproject.com/
- Flask - http://flask.pocoo.org
- Tornado - http://www.tornadoweb.org/
- FastAPI - https://fastapi.tiangolo.com/
- AIOHTTP - https://docs.aiohttp.org/
- Bottle - http://bottlepy.org
- Pyramid - http://www.pylonsproject.org/
- WebPy - http://webpy.org/
- Sanic - https://sanicframework.org/
- Web2py - http://www.web2py.com
- CherryPy - http://cherrypy.org/
- Falson - http://falconframework.org/
- Gnok - http://grok.zope.org
- Zope - http://zope.org
- TurboGrears - http://www.turbogears.org
- Quart - https://pgjones.gitlab.io/quart/
- Masonite - https://masoniteproject.com
이것보다 사실 더 많습니다. 다 리스팅 하지 못한 것 입니다.
수 많은 웹프레임워크를 다 둘러 볼수는 없고 제가 웹프레임워크의 왕을 고를 기준을 먼저 정해 보겠습니다.
- 용도
- Github Stargazer 숫자
- 큰 플랫폼이나 기업에서 사용하고 있는지?
- 퍼포먼스
미리보기
** GINO 는 ORM이라기 보다 SQLAlchemy Wrapper에 가깝습니다.
용도별
- 풀 프레임워크
(1) Django, 이미 왕좌에 오른 프레임워크
현재 버전 : 3.1.5 (2021년 1월)
장고는 High-level Framework 입니다. 개발 하시다 보면 느낄수 있지만, 무조건 쉽고, 무조건 편하게 라는 느낌을 많이 받게 됩니다. 더욱이 Django 디자인 철학에서 보다 자세하게 설명되어 있습니다.
디자인 철학은 6가지 카테고리로 수십가지 철학을 기본으로 하고 있는데, 우선 대표적인 4가지는 아래와 같습니다.
- Loose Coupling
- 프레임워크내 레이어들은 꼭 서로 알아야 하는 상황이 아니면 서로서로 알 필요가 없다. Django는 풀프레임워크지만, 그 안에 조각들은 독립적으로 작동한다.
- Less Code
- 코딩을 더 조금만 할 수 있도록
- Quick Development
- 빠르게 개발할 수 있도록
- Don't Repeat Yourself
- 코드 내용은 프로젝트 내 한 곳에만 있을 수 있도록. 프레임워크는 작은 정보에서 더 큰 것을 추론할 수 있어야 한다.
장점
이미 모든 것이 준비되어 있다.
일단 탑승만 하시라. 모든것이 준비되어 있습니다. 기본적인 기능부터 프로 개발자들이 개발해 놓은 각종 패키지들까지 모두 들어가 있습니다. 시간을 아낄 수 있고, 기본 기능을 만드느라 시간을 지체할 필요가 없습니다. 서드 파티(구글, 페이스북) 등과 연계할만한 기능들도 갖추고 있습니다. 엄청난 크기의 생태계는 당신이 무엇을 생각하고 있던, 누군가 이미 만들어 놓았다는 것을 의미하기도 합니다. 원하는대로 받아서 원하는대로 조립하는 느낌이 드는 프레임 워크입니다. 시간을 아끼세요!
매우 우수한 문서, 매우 큰 생태계
Django 는 심할정도로 디테일하게 문서를 써 두었습니다. ORM 도 내부에서 지원하기 떄문에 ORM 문서 역시 합쳐져 있지요. StackOverflow에 질문을 하시면 그 중 절반은 "문서에 있으니, 문서를 읽어보라" 라는 말로 끝날 정도 입니다. 또한, 엄청난 크기의 생태계는 그들의 실력과 경험에 상관없이 서로를 보완하는데 상당한 도움이 되어 줍니다. 궁금하면 물어보고 그러면서 배우며, 이제 갓 시작한 비기너들은 지식뿐 아니라, 그 생태계 안에서 개발자들이 갖춰야 하는 매너 역시 배우게 됩니다. StackOverflow에서 검색 해보지 않고 무조건 질문 올리면 '비추' 폭탄 맞는거 처럼요.
확장성
많은 프로젝트들이 신경쓰고 있는 부분입니다. 특히 요즘 대세인 Start Small, Build Big 정신을 토대로, 처음은 모두 작게 시작하는 것을 원합니다. 작은 프로젝트를 스케일링 하는 기능을 장고는 기본적으로 제공합니다. Django를 사용하는 Spotify, 인스타그램도, 아마 그렇게 시작했을 거에요!
어드민패널
장고 어드민은 엄청난 것을 제공합니다. 바로 DB에 CRUD를 할 수 있는 공간이 생깁니다. 저는 데이터베이스 툴을 따로 사용하지만, 그렇게 없으셔도 Django는 그런 것을 지원합니다. 혹시 PHP를 써보신분은 PHPmyAdmin 이라는 것을 하실거에요. 그런것을 기본으로 지원합니다! 다른말로 바꾸어 말해보면, 아.. 아무것도 필요 없이 우선 탑승하세요! 다른건 탑승 후 가시면서 배우세요!
매우 좋은 프레임워크라는 것에는 이견이 없지만, 그래도 단점이 있습니다.
부담스러운 사이즈
편의점 삼각김밥 까지는 아니지만, 밀키트 처럼 먹기 딱 좋게 세팅하려다 보니 무겁습니다. 프레임워크만 거의 30만줄에 달하고 점점 늘어나고 있습니다. '내부 기능들이 서로서로 독립적으로' 가 디자인 철학이지만, 서로서로 엉켜있는 듯한 느낌이 들기도 합니다.
속도
Django는 빠른 웹프렘워크가 아닙니다. 무거우면 무거울수록 그렇습니다. 3.0 버전으로 올라오면서 ASGI를 지원하기 시작하여 그 전 버전들은 더욱 그렇습니다. 빠른 속도가 필수가 되어 가는 시대 입니다만, 속도면에서 아쉬운 것은 어쩔수 없습니다. 이 속도를 메꾸기 위해 뛰어난 캐시시스템이 내부에 탑재되어 있지만, 그것만으로는 역부족이에요. 하지만, 지금 시작하시는 분들에게 속도는 문제가 되지 않을것입니다. 사용자가 늘어나면, 그때가서 생각해도 되니까요. 그 속도차이가 인간이 느낄수 있을만한 그런 차이는 아니거든요. 많은 사용자가 생기고 지연이 누적되고 누적되야 비로소 느껴지는 차이 입니다.
하이레벨 프레임워크란? 프레임워크는 지속되는 문제들을 보다 쉽게 개발자들이 해결할 수 있도록 만들어진 일종에 솔루션이며, 하이레벨 프레임워크는 이런 지속되는 문제들을 해결하는데 실제적으로 거의 코딩이 필요없도록 지원해주는 프레임워크 입니다.
(2) Pyramid, 미니멀리즘
현재 버전 :1.10.5 (2021년 1월)
풀 프레임워크를 찾으시는데, 장고의 무게가 부담스럽다면, 차선책으로 생각해볼 수 있는 웹프레임워크 입니다. 미니멀한 웹프레임워크도 매우 큰 프로젝트를 감당해 낼 수 있습니다. 사용자의 프로젝트 크기와는 상관이 없어요. 아주 작은 어플리케이션 부터 매우 복잡한 프로젝트도 충분히 감당해 낼 수 있는 프레임워크 입니다.
장점
라우터 생성
다른 프레임워크와는 조금 다른 방식, 하지만, 편한방식으로 라우팅 URL을 생성할 수 있습니다. 이 방식이 가장 우수하다고 생각하고 있는 Pyramid 이고, 다른 프로젝트와는 다름을 보여준다는 리스트(공식 문서에서)에 가장 처음에 등록되어 있습니다. 신기한 기능들이 있는것은 사실입니다. 아래 문서에서 확인해보세요!
https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/urldispatch.html
SQLAlchemy 지원
장점이 될수 있으나, 많은 프로젝트들이 차용하고 있는 방법입니다. SQLAlchemy는 Django ORM 에 한계를 느끼는 사람들이 갈아타기도 하는 매우 우수한 ORM 입니다. 세션, 쿼리, 세션풀 등을 더 세밀하게 관리할 수 있고, 트렌젝션을 보다 사용할 수 있다는 장점이 있습니다. Django ORM에서 못하는 것은 아니지만, 화려한 조인 및 Annotate 를 포함한 쿼리를 보다 직관적으로 짤 수 있습니다. 물론, Django도 할 수 있지만! 제가 주위에서 본 결과 Django ORM 에서 SQLAlchemy로 가시는 분들은 많이 봤는데, 반대는 거의 못봤습니다. Reddit은 Django + SQLAlchemy를 사용합니다.
유연성과 확장성
매우 유연합니다. 안에 들어 있는 특정 기능이 마음에 들지 않는다면 다른 것으로 교체하실 수 있습니다. 작고 가볍기 때문에 속도도 빠릅니다. 생태계가 빈약하기 때문에 외부 라이브러리를 유연하게 사용할 수 있도록 해두었습니다.
장점
작은 생태계와 유연함
필요한 기능을 가진 라이브러리를 찾는데 어쩌면 많은 시간이 소요될 수도 있습니다. 그래서 직접 구성해야 할 수도 있습니다. 유연하고 탄력적인 프레임워크 이기 때문에 처음 시작하시는 분들이 하기엔 무리가 있을 수 있습니다. 작고 가볍고 유연하다는 말은, 다시 말해 내가 처음부터 끝까지 다 돌보고 살펴야 한다는 뜻이기 때문입니다.
- 마이크로 프레임워크 (비동기 포함)
(1) Flask, 마이크로 프레임워크는 내가 접수한다
현재 버전 : 1.1.12 (2021년 1월)
플라스크는 WSGI 프레임워크 입니다. 플라스크는 당신이 어떤 프로젝트를 만들던 그에 맞게 높은 퍼포먼스를 보여 줄 거에요. 2010년에 처음 세상에 나와서 이미 깃헙 스타 5만3천여개를 받고 있고 큰 커뮤니티를 가지고 있습니다. 필요하다면 Jinja2를 사용하여 프론트엔드 작업도 가미할 수 있습니다. SQLAlchemy가 아니더라도 그어떤 ORM도 사용할 수 있고, 쿠키와 클라이언트 사이드 세션을 지원합니다. 유닛테스트를 지원하며 우수한 성능의 디버거가 포함되어 있습니다.
장점
이 보다 미니멀하고 직관적일 수 없다.
코드 몇 줄 이면 시작할 수 있습니다. Django 보다 코드가 10% 정도 밖에 안되는 가벼운 프레임워크 입니다. 꽤 쉽게 이해할 수 있고 꽤 쉽게 개발을 시작할 수 있습니다.
매우 빠른 개발 속도
보안 등 세밀한 부분에 신경을 쓰지 않아도 된다면, 아마 프로토타이핑에 가장 빠른 프레임워크라고 해도 과언이 아닐정도로 빠르게 개발할 수 있습니다. 패키징된 프레임워크 안에 이미 당신이 필요한 모든 것이 들어 있습니다.
단점
WSGI의 한계
WSGI는 구조적으로 한번에 많은 트래픽을 처리하기엔 느리다는 단점이 있습니다. ASGI를 공식적으로 지원하지 않는 이상 빠른 웹프레임워크라는 수식어는 앞으로 사용할 수 없을 수도 있습니다. 우리에겐 Gunicorn이 있지만, 관리 요소가 늘어나고, WSGI의 구조적 한계를 Gunicorn으로 완전히 지울 수 없는 것이 사실입니다.
가파른 러닝커브
혹시, 팀 내에 파이썬이나, Flask 를 처음 쓰는 개발자가 있다면, 고민을 해봐야합니다. 가볍은 프레임워크라는 말은 개발자가 하나부터 열까지 다 해야한다는 이야기. 지금 하고 있는 일이 어떤일인지 정확히 아는 전문가들이 고도화를 해야 하는 프레임워크 입니다. 만약 파이썬이나, 웹프레임워크라는 것 자체가 익숙치 않다면, 당신 대신 모든 것을 다해주는 Django가 더 편할 수 도 있습니다.
(2) FastAPI, Node.js 아성에 도전한다.
현재 버전 :0.63.0 (2021년 1월)
Django Rest Framework, Flask 중 고민하시는 분이 FastAPI를 알게 되시면 아마 이걸 택하지 않을까 싶습니다. 아직 1.0이 나오지 않았고 출시된지 2년이 갓 넘은 시점에 Github Star 는 이미 Django의 절반 정도까지 따라 왔습니다. 이 웹프레임워크는 나온지 얼마 안되 강의도 잘 되어 있지않고, 아직 현업에서 사용하는 곳이 많지 않지만, Python 개발자 뿐 아니라, 다른 언어 개발자 분들도 유심히 지켜보고 있는 프레임워크입니다. 어쩌면 지각변동을 일으킬 그런 프레임워크가 될수도 있을 것 같습니다.
철학
- 빠르고
- 코딩하기 쉽고
- 배우기 쉽고
- 바로 운영 적용이 가능하게!
장점
ASGI 사용
ASGI 사용으로 FastAPI 안에서 비동기 처리를 수행할 수 있습니다.
Pydantic 을 사용한 벨리데이션
Pydantic 은 현존 파이썬 벨리데이터 중에 가장 빠릅니다. Pydantic 으로 복잡한 벨리데이션 코드 없이 편하게 벨리데이션이 가능합니다. 물론 오류 Json Response도 Pydantic이 직접 만들어 전송합니다.
OpenAPI 문서 자동생성
이건.. 한번 경험하면 다시는 빠져 나가지 못할 매력이 있습니다. 내가 만드는 API 문서를 코드를 분석하여 자동으로 만들어 줍니다.
뛰어난 문서
아주 상세한 문서로 빈약한 생태계를 커버하고 있습니다.(개발자에겐 이게 가장 중요합니다!)
추가적으로, 더 알아보시고 싶다면, 저의 다른 글에서 보실 수 있습니다.
단점
약한 생태계
확실히 나온지 얼마 안되서 생태계가 빈약합니다. 빠른 속도로 늘어나고 있지만, 아직 이 프레임워크를 본격적으로 쓰는 회사가 없기 때문에 많은 라이브러리를 사용하기 쉽지 않습니다. 일일히 하나씩 다 만들거나 모든 Python 프로젝트에서 사용할 수 있는 라이브러리 등을 사용해야 합니다.
1.0 버전을 기다려야 하는가..?
의외로 이걸 문제로 삼으시는 분들이 있으셨습니다. 아직 지속적으로 개선중이고.. "이걸 이렇게 만들었다고..?" 하는 내용도 있습니다. 조금씩 나아지겠지만, 아직 1.0 버전이 나오지 않은 베타 버전의 프레임워크 입니다. 상황에 따라 더 기다려보는 것도 좋을 수 있습니다. 1.0 으로 올라가면서 드라마틱 하게 바뀌어서 그거 수정하는데 시간을 엄청 소비할 수 도 있으니까요!
(3) Sanic, 내가 파이썬에서 제일 빠릅니다.
벤치 마크로 보면 가장 빠릅니다.
Flask 와 AIOHTTP를 섞어 놓은 것 같은 느낌이 드는 프레임워크 입니다. Flask의 심플하고 가벼운 점을 채택하고 AIOHTTP의 ASGI를 선택하였으며, GINO 를 사용하여 넌블락킹 ORM을 구현하였고, Class-based view를 지원합니다. 또한, 플라스크 처럼 블루프린트와 서브라우팅을 어플리케이션 안에서 지원합니다.
생산성, 코드 확장, 유지보수 측면에서 플라스크의 장점을 그대로 따왔습니다.
ASGI를 처음부터 지원했던 것은 아닙니다. 2018년 말에 처음으로 ASGI 지원에 관련된 이야기가 나왔고 하나 둘씩 붙여 다가면서 지금처럼 우수한 웹프레임워크가 되었습니다.
(4) AIOHttp, 이름부터 빠를 것 같은..
위 벤치마크를 보면 상당히 높은 곳에 랭크되어 있습니다.
특징으로는 서버뿐 아니라 클라이언트를 만는 것도 가능합니다. 요청을 받는 것이 아니라 요청을 하는 어플리케이션을 만들 수도 있습니다. 물론 다른 프레임워크도 requests 라는 라이브러리를 사용하여 할 수 있으나, AIOHTTP는 프레임워크 자체에서 지원합니다. 서버 웹소켓과 클라이언트 웹소켓도 지원하며, 웹서버에서는 미들웨어, 시그널 등을 지원합니다.
그럼 무엇을 사용해볼까?
Python으로 웹프레임워크가 처음이다 Django
API 서버를 구축하려하고, 웹프레임워크 안다 FastAPI, Sanic
API 서버를 구축하려하고, 웹프레임워크 좀 아는데 생태계가 컸으면한다. Flask, Django Rest Framework
ASGI, Uvicorn 을 사용해서 트렌드에 맞춰 비동기 서버를 구축해보고 싶다 FastAPI, Sanic
프론트엔드와 협업을 위해 자동 API 문서가 지원되었으면 좋겠다. FastAPI
프론트엔드(템플릿) 작업도 함께 하고 싶다. Django (이 분께서 이 분야에 넘사벽)
취업을 위해 뭔가 만들고 싶다. Django, Flask
우리 서비스 코드는 너무 크거나 매우 작다. Flask, Sanic (FastAPI은 나중에.. 아직은..)
ORM 사용이 편했으면 좋겠고, 문서가 잘되어 있으면 좋겠다 Django
기본적인 보안 등 세팅이 다 되어있었으면 좋겠다. Django
NoSQL을 사용할 생각이다 Django 제외
스크래치부터 해내고 싶다. Flask, FastAPI, Sanic
구인 공고 수도 그렇고 Stack Overflow 질문수도 그렇고 생태계 크기도 그렇고.. 아직은 Django가 왕인듯 합니다. 개인적으로 FastAPI를 회사에서 메인 프레임워크로 사용하기도 하고, 아직은 정보가 많이 없는 것 같아 유튜브에서 강좌도 하고 있습니다! 많은 시청 해주세요!
긴 포스팅 이었습니다. 이것저것 많이 찾아보고 사용해봤던 경험을 떠올리며 작성해 보았지만, 가장 중요한 것은 가슴이 시키는 길을 따르는 것, 즉 개인 취향 입니다.
- [[a.original_name]] ([[a.file_size | fileSizer]])
