[번역] 장고(Django)와 플라스크(Flask) : 2023년 어떤 것을 선택해야 하는가? 1편

Django vs. Flask in 2023: Which Framework to Choose

2021 JetBrains Python Developers Survey에 따르면 Django와 Flask 모두 인기있는 파이썬 웹 프레임워크이다. 장고가 전통적으로 아주 인기있는 파이썬 웹 프레임워크라면, 플라스크는 탑을 노리기 위해 장고 몇여년 동안 따라갔다. 그다지 놀랍지 않은 트렌드로, 더 가벼운 프레임워크, 마이크로서비스 그리고 서버리스 플랫폼을 지향했던 지난 몇년간의 웹 개발 산업 트렌드이다. 

혹은 산업계에서 더 적게 나타나고 젯브레인 유저들에게서 더 많이 나타나는 것일지도 모른다.

장고와 플라스크 둘다 거대한 커뮤니티, 널리 알려지고 지원받고, 앱 개발에 있어 생산적인 접근을 제공해주며 둘 다 앱을 만듬에 있어, 코어 설계보다는 당신의 시간과 에너지를 아주 특별한 부분에 신경쓰도록 한다. 끝으로 두 프레임워크 모두 웹앱을 만드는 곳에 쓴다. 이 둘의 차이점은 이 목적을 어떻게 이루는지에 달려있다. 장고가 자동차라고 하면 플라스크는 자전거라고 볼 수 있듯이 말이다. 둘다 - 자동차와 자전거 둘다 - A지점에서 B지점까지 데려다 주지면, 둘의 접근은 다르다. 각각 최적의 선택지로서 쓰이는 상황이 있다. 이는 장고와 플라스크 둘 모두에 적용된다. 이 글에서는 장고와 플라스크를 특별하게 만들어주는 - 교육적인 측면과 개발적인 측면에서 - 최적의 상황을 살펴볼 것이다.

 

철학 - Philosophy

장고와 플라스크 모두 자유롭게 사용 가능하며, 오픈소스, 그리고 웹앱을 만들기위해 디자인된 파이썬 기반의 웹 프레임워크이다. 플라스크와 비교하면 장고는 포용력 높은 - 마치 내장형 배터리 처럼 툴, 패턴 특징 그리고 기능성을 가지고 있는 - 따로 특별한 설정이 필요없는 즉시 사용가능한 자동차이다. 유지보수 측면에서, 장고는 일반적으로 더 길고 까다로우면서 엄격한 릴리즈 사이클을 가지고 있다. 그래서, 장고가 적으면서 반짝이는 새로운 기능들을 가지고 올 때 아주 강력한 하위 호환성을 제공하려고 한다.

 

Werkzeug을 기반으로 한 플라스크는 기반 작업을 다룬다. 즉시 실행 가능하기에, URL라우팅, 리퀘스트와 에러 처리, 틀 잡기, 쿠키와 함께 유닛 테스트, 디버거 그리고 개발 서버 지원을 해준다. 대부분의 웹앱이 좀더 많은 기능들을 요구하기에 - 조금 예를 들자면, ORM, 인증 및 인가 등이 있다 - 당신의 앱을 만들기 위해 결정을 할 필요가 있다. 당신이 써드파티 확장자나 스스로 코드를 커스터마이징하는 등 어떻게 활용하는지에 따라, 플라스크는 당신 곁을 떠날 수도 있다. 장고보다 더 유연하다는 것이다. 공격 취약에 대한 타격 면적이 장고에 비해 적고, 리뷰할 코드의 양도 적으며(less code to review), 개조를 원한다면 보닛을 열고 소스코드를 직접 보자.

개인적으로 플라스크의 소스 코드를 읽고 리뷰하기를 권장한다. 깔끔하며 깨끗하고 간결하다. 이는 아주 잘 설계된 파이썬 코드이다.

 

특징 - Features

데이터베이스

장고는 바로 사용할 수 있는, 여러 관계형 데이터베이스(databases) - SQLite, PostgreSQL, MySQL, MariaDB, 그리고 Oracle - 을 지원하는 심플하고도 강력한 ORM을 포함하고 있다. 데이터베이스 마이그레이션(migrations)을 관리 및 생성에 대한 지원을 제공하는 ORM이다. 데이터 모델에 기반한 form, view 그리고 template을 쉽게 만들 수 있고, 이는 곧 전형적인 CRUD 웹앱에 딱 맞을 것이다. 물론 단점(shortcomings)도 있지만, 주된 웹 앱에 있어 충분하다. 

 

플라스크는 데이터가 어떻게 저장될지에 대해 어떤 가정도 하지 않지만, 여러 라이브러리 그리고 확장팩들이 존재한다.

 

사용처	라이브러리	확장팩
ORM	SQLAlchemy	Flask-SQLAlcehmy
SQLAlchemy를 위한 마이그레이션 툴	Alembic	Flask-Alembic
ORM, 마이그레이션	Peewee	Flask-Peewee
ORM	PonyORM	Flask-Pony
ODM(Object Document Mapper)	PyMongo	Flask-PyMongo
ODM	MongoEngine	Flask-MongoEngine

결론부터 말하자면, 관계형 데이터베이스를 사용한다면 장고가 더 시작하기 편할것이다. 내장된 ORM과 마이그레이션 관리 툴이 있기 때문이다. 하지만 NoSQL을 사용하거나 SQLAlchemy와 같은 툴을 사용한다면 장고는 당신과 매 단계마다 싸우려 들것이다. 여기에 더해 Django Admin, Model Forms, 그리고 DRF 모델 직렬화의 이점을 사용하기 어려울 것이다.

 

플라스크는 당신 곁에서 한발짝 떨어져 어플리케이션에 딱 맞는 ORM(혹은 ODM)을 고르거나 뽑을 자유를 준다. 비록 자유에는 대가가 따른다. 스스로 관리해야 되기에 이는 곧, 높은 러닝커브 그리고 당신을 기다리는 더 많은 에러들을 가져다 준다.

 

스스로 자신만의 무언가를 할수록 당신이 만들 실수는 많아진다, 특히 스케일이 커질수록

 

인증 - Auth

대부분의 웹 앱들이 인증(누구인지?)과 인가(어떤 행동을 허락받았는지?)를 요구하기에, 장고는 User model을 통해 세션과, 계정 관리를 기능적으로 바로 쓸 수 있게 지원한다. 플라스크는 쿠키 기반 세션 지원을 제공하지만 계정 관리, 인증, 인가를 위한 확장팩을 찾게 될 것이다.

사용처	확장팩
계정 관리, 인증	Flask-Login
인증	Flask-Principal
계정 관리, 인증, 인가	Flask-Security

 

관리자 - Admin

장고는 admin panel이 딸려오는데, 당신이 만든 모델 기반의 데이터를 관리하기 위한 유저 인터페이스를 제공하는 웹 애플리케이션이다. 장고가 빛이나는 부분이기도 하다. 이를 통해 CRUD를 어떠한 추가 코드 작성 없이 당신의 모델에 대해 수행할 수 있게 한다. 그에 반해, 플라스크는 어떠한 것도 당신에게 던져주지 않지만, Flask-Admin 확장팩이 같은 기능 혹은 더 많은 기능(all of the same functionality and a lot more)을 부여한다:

장고는 기능적으로 많은 일을 할 수 있다.

플라스크의 철학은 살짝 다르다 - 명백한 것이 함축한 것보다 낫다. 만약 무언가가 초기세팅이 되어야 하면, 이는 개발자의 손에 의해 이루어져야 한다는 것이다.

Flask-Admin은 이러한 관습을 따른다. 당신은 - 즉 개발자는 - Flask-Admin에게 무엇을 보여주고 어떻게 할지에 대한 권한이 달

때로는 이러한 것은 보일러플레이트 코드 작성을 요구하기도 하지만, 미래에 비용이 감소되며, 특히 당신이 커스텀 로직을 짤 때 더더욱 도움이 될 것이다.

Flask-Admin는  SQLAlchemy, Peewee, MongoEngine와 같은 몇몇 데이터베이스 백엔드(number of database backends)를 지원한다. 당신만의 백엔드를 추가할 수 도 있다(add your own backends). 또한 유명한 플라스크 인증 확장팩하고도 같이 혹은 따로 쓸수도 있다.

1. Flask-Login 그리고 Flask-Principal
2. Flask-Security

 

라우팅과 뷰 - Routing and Views

두 프레임워크 모두 뷰에 URL을 매핑할 수 있도록 하며, CBV(Class-Based Views)나 FBV(Function-Based View)를 지원한다.

장고

만약 리퀘스트가 URL패턴과 매치되면, HTTP 요구사항을 품고 있는 리퀘스트 객체는 뷰로 패스되며, 뷰가 실행되게 된다. 리퀘스트 객체에 접근하고 싶을 때 마다, 이를 통해 명시적으로 넘겨줘야 한다.

 

URL과 뷰는 각기 다른 파일에 있다 - 각각 urls.py 그리고 views.py이다.

1. Routing
2. Views
3. Class-based views
4. Request context
5. How Django processes a request

 

플라스크

플라스크에서 코어로 Werkzeug를 사용하며, 이는 URL 라우팅과 리퀘스트/리스폰스 처리를 제공해준다. 플라스크에서 리퀘스트 객체는 전역적이기 때문에 - 당신이 import하는 한 - 더 쉽게 접근 가능하다. URL은 일반적으로 뷰를 통해 -  decorator와 함께 - 정의되지만, 장고의 패턴처럼 중앙화된 지역에다 분리(separated out)될수도 있다.

1. Routing
2. Views
3. Class-based views
4. Request context

혹시 장고와 플라스크 둘다 어떻게 요청을 처리하는지 눈치 챘는가? 일반적으로 플라스크가 명시적으로 움직이려 하면, 장고는 그 반대라고 볼 수 있다. 장고는 노골적으로 전달을 주위로 넘기게끔 강요한다면, 플라스크의 리퀘스트는 마법처럼(magically)사용할 수 있다. 이는 플라스크가 어렵게 느껴지는 부분중 하나이다, 특히 Express.js처럼 새로이 접근하는 사람들에게 말이다.