자세히 보기

‘강력하고 방대한’ 파이썬 웹 프레임워크 5종

웹 사이트 또는 서비스를 위한 백엔드를 구축해보면 처음에는 대단해 보이지 않는 것도 곧 결코 그렇지 않다는 사실을 알게 된다. ‘단순한’ 사이트도 복잡한 실타래처럼 보인다. 사용자 관리, 데이터 디자인, 서식 제출, 보안 등 이 모든 것을 수동으로 구현하는 것은 지루하고 힘든 작업이다.

특히 대형 웹 프로젝트의 경우 온갖 요소를 내장한 프레임워크로 전향하는 것이 최선이다. 탄탄한 웹 애플리케이션 등을 구축하기 위해 필요한 모든 것이 갖춰진 파이썬용 웹 프레임워크 5종에 관해 살펴본다.

큐빅웹(CubicWeb)
큐빅웹은 ‘재사용 및 객체 지향적 디자인에 유리한 의미론적(semantic) 웹 애플리케이션’이라 불린다. 릭 그레한이 2011년에 인포월드에서 이것을 리뷰했을 때 말했던 것처럼, 이는 ‘큐브’라 불리는 재사용 가능한 코드 블록과 앱스트랙션(abstractions )의 사용을 강조하는 매우 흥미로운 시스템이다. 사실, 큐빅웹은 개발자에 따라 너무 추상적이거나 특이할 수 있으며, 개발 속도와 기능이 다른 프레임워크보다 뒤쳐진다.

큐브는 스키마(Schema, 데이터 모델), 실체(Entity, 프로그래밍 로직), 뷰(View)가 특징인 소프트웨어 구성요소이다. 각각 작업을 수행하는 여러 개의 큐브를 조합함으로써 자신과 타인의 코드를 재사용하여 소프트웨어 애플리케이션을 구성할 수 있다.

큐빅웹은 모든 웹 앱이 사용하는 기본적인 스캐폴딩, 데이터 연결 및 저장을 위한 ‘저장소’, 기본적인 HTTP 요청/응답과 CRUD 동작을 위한 ‘웹 엔진’, 모델링 데이터를 위한 스키마를 제공한다. 이 모든 것이 파이썬 클래스 정의에 설명되어 있다.

큐빅웹 인스턴스를 설정하고 관리하려면 장고에 사용하는 것과 같은 명령줄 도구를 사용한다. 내장된 템플레이팅(Tamplating) 시스템을 통해 HTML 출력을 프로그램으로 생성할 수 있다. 또한 부트스트랩(Bootstrap) HTML 프레임워크 등의 웹 UI를 위한 도구를 제공하는 큐브도 사용할 수 있다.

큐빅웹이 파이썬 3(버전 3.23 이상)을 지원하지만 파이썬 3의 네이티브 비동기 기능은 사용하지 않는 것으로 보인다. 비동기를 포함시키는 우회책은 ‘cubicweb.pyramid’ 모듈을 사용하여 피라미드 프레임워크를 웹 서버로 사용하고 비동기 구성을 사용하는 피라미드의 포킹(Forking) 버전을 이용하는 것이다. 또한 ‘cubicweb-worker’ 큐브를 통해 작업을 비동기식으로 수행하는 것도 가능하다. 하지만 현재로서는 더 간단한 방법이 없는 것으로 보인다.

큐빅웹 앱에서 영구적인 데이터를 불러오거나 조작하려면 SQL 같은 문법을 사용한다. 그러나 W3C의 SparQL의 패턴을 따르는 RQL(Relation Query Language)을 사용한다. 이에 대한 큐빅웹의 정당화 근거 역시 추상화이다. RQL은 다양한 데이터 소스를 연관시키기 위해 분리된 경로를 제공한다.

큐빅웹은 의존성이 많기 때문에 pip install을 사용하여 모두 불러오는 것이 가장 좋다. 또한 로컬 환경에서 일정량의 수동 조정을 수행해야 할 수도 있다. pip install을 실행하거나 프레임워크의 코드를 다른 프로젝트의 하위 폴더에 넣기만 하면 되는 다른 프레임워크들과는 다른 부분이다. 또는 도커 컨테이너를 사용하여 모든 것을 실행할 수 있다.

큐빅웹은 긴 문서를 ‘북(Book)’이라 부른다. 북의 저자들은 큐빅웹의 이례적인 접근방식을 설명하고 일부 기본적인 애플리케이션을 구축하는 방법을 보여주며 API 참조를 포함시키고 전반적으로 저마다 구체적인 설명을 제공한다.

큐빅웹은 느리긴 하지만 여전히 개발이 진행 중이다. 큐빅웹 4.0에 대한 계획은 2012년부터 고려되었지만 등장 시점은 아직 제시되지 않았다.

장고
장고(Django)는 등장 이후 10년 만에 웹 애플리케이션 생성을 위해 파이썬에서 가장 널리 배치된 프레임워크가 되었다. 장고에는 필요할 수 있는 거의 모든 것이 포함되어 있기 때문에 작은 것보다는 큰 애플리케이션을 구축하는 데 더 적합하다.

장고는 수 년 동안 버전 1.x대에 머물러 있었다. 2017년 말 장고 2.0이 공개되자 파이썬 2와의 호환성을 포기하고 파이썬 3.4 이상과 호환되었다. 2019년 12월에 공개된 장고 3.0은 파이썬 3.6 이상을 요구하며 파이썬 웹 애플리케이션을 위한 새로운 비동기식 ASGI 표준에 대한 지원을 추가했다.

장고의 매력의 핵심은 배치 속도이다. 장고 에는 일반적인 웹 애플리케이션 개발을 위해 필요한 많은 것들이 포함되어 있기 때문에 신속하게 움직일 수 있다. 라우팅(Routing), URL 분석, ORM(object-relational mapper)을 포함한 데이터베이스 연결, 서식 검증, 공격 보호, 템플레이팅이 모두 내장되어 있다.

보편적인 웹 애플리케이션 시나리오에 필요한 구성 요소를 대부분 찾을 수 있다. 예를 들어, 사용자 관리는 대부분의 웹 사이트에서 지원하기 때문에 장고 는 이것을 표준 요소로 제공한다. 사용자 계정, 세션, 비밀번호, 로그인/로그아웃, 관리자 권한 등을 추적하기 위한 자체 시스템을 구축하는 대신에 장고 는 이런 기능을 네이티브로 제공한다. 이것들을 그대로 사용하거나 확장하여 초소한의 노력으로 사용 사례를 아우를 수 있다.

장고는 웹 애플리케이션을 공격으로부터 보호하는 데 도움이 되는 온전하고 안전한 기본값이 있다. HTML이나 자바스크립트가 포함된 문자열 등의 변수를 페이지 템플릿에 넣으면 변수의 인스턴스를 명확하게 안전한 것으로 지정하지 않는 한 내용이 그대로 표시되지 않는다. 이 자체를 통해 많은 보편적인 사이트 간 스크립트 작성 문제가 사라진다. 서식 검증을 원하는 경우 단순한 CSRF 보호부터 세부적인 오류 피드백을 제공하는 완전한 필드별 검증 메커니즘까지 모든 것을 사용할 수 있다.

기능이 풍부하고 광범위해도 강력한 문서가 수반되지 않으면 소용이 없다.  장고 문서는 이 프레임워크의 모든 측면에서 자세히 다룬다. 파이썬 3이나 다른 언어를 사용한 작업, 보안 적용, 보편적인 웹 애플리케이션 구성요소(세션이나 페이지네이션), 사이트맵 생성 등 모든 것을 다룬다. 각 애플리케이션 계층(모델, 뷰, 템플릿)의 API도 자세하게 설명되어 있다.

하지만 능력에 따라 복잡성도 커진다. 장고 애플리케이션은 무겁고 움직이는 부분이 많은 것으로 정평이 나 있다. 간단한 장고 앱도 동작을 위해 상당량의 구성이 필요하다. 일련의 단순한 REST 종점을 설정하는 것 외에 다른 것을 원한다면 장고는 분명 지나치다.

장고는 이상한 점도 있다. 예를 들어, 페이지 템플릿은 콜러블(Callable)을 사용할 수 없다. 일례로 탬플릿에서 {{user.name}}를 구성요소로 전달할 수 있지만 {{user.get_name()}}는 불가능하다. 장고가 템플릿이 부주의로 자기 무덤을 파지 않도록 하는 방법 중 하나이지만 이런 제약에 대비하지 않으면 충돌이 발생할 수 있다. 우회책이 있기는 하지만 성능에 타격을 주는 경향이 있다.

버전 3.0에서 장고는 비동기식 뷰에 대한 지원을 추가했다. 안타깝게도 ORM처럼 장고 스택의 다른 부분에서 아직 비동기를 지원하지 않는다. 하지만 ASGI를 통해 장고를 배치하여 비동기 뷰를 제대로 활용할 수 있다.

웹투파이
루비(Ruby) 프로그래밍 세계에서는 루비 온 레일즈(Ruby on Rails)가 실질적인 프레임워크이다. 드폴대학교 컴퓨터 공학 교수 마시모 디 피에로는 레일즈에서 영감을 얻어 파이썬에서 유사한 수준으로 쉽게 설정하고 사용할 수 있는 웹 프레임워크를 구축했다. 그 결과물이 웹투파이(Web2py)다.

웹투파이의 가장 큰 매력은 내장된 개발 환경이다. 웹투파이 인스턴스를 설정하면 해당 앱의 구성요소를 구성할 수 있는 온라인 파이썬 애플리케이션 편집기인 웹 인터페이스가 제공된다. 즉, 파이썬 모듈이나 HTML 템플릿을 통해 설명된 모델, 뷰, 컨트롤러를 생성할 수 있다. 웹투파이는 기본적으로 몇 가지 예제 앱을 제공한다. 이것들을 분석하여 메커니즘을 파악하거나 시작 템플릿으로 활용하여 자신만의 앱을 개발할 수 있다.

개발자들은 일반적으로 웹투파이의 소스 코드를 다운로드하고 이를 기반으로 구축하여 배포한다. 하지만 윈도우 또는 맥OS를 사용하는 기술 지식이 부족한 사용자들을 위해 웹투파이의 개발자들은 기본적으로 단독형 서버인 버전을 제공한다. 이런 버전을 다운로드하고 압축을 해제하며 실행하면 웹투파이가 내장된 로컬 웹 서버를 갖게 된다. 이를 통해 처음에 웹투파이 앱을 손쉽게 구축하고 필요에 따라 다른 곳에 배치할 수 있다.

웹투파이의 인터페이스는 부트스트랩 4로 구축되었기 때문에 보기에도 좋고 쉽게 탐색할 수 있다. 브라우저 기반 편집기가 완전한 기능을 갖춘 IDE를 대체할 수는 없지만 줄 번호 매기기와 파이썬 문법 강조(자동 들여쓰기 포함) 등의 유용한 지원 기능을 갖추었다. 또한 파이썬 쉘(Shell)에 대한 간단한 웹 인터페이스가 포함되어 있어 명령줄에서 웹투파이와 상호작용할 수 있다. 전문가들에게는 좋은 기능이다.

웹투파이에서 사용되는 데이터 추상화 시스템은 장고의 ORM 및 여기에서 영감을 얻은 다른 ORM(Peewee 등)과는 조금 다르게 작동한다. 이 시스템들은 파이썬 클래스를 사용하여 모델을 정의하지만 웹투파이는 define_table 같은 생성자 기능을 사용하여 모델을 인스턴스화한다. 다른 방식에 익숙해진 경우에만 차이점이 두드러질 가능성이 있으며, 초보자들이 당황할 일은 없을 것이다. 웹투파이는 현존하는 거의 모든 주요 데이터베이스와 통신하기 때문에 데이터 제공자에게 연결시키는 데 문제가 있을 가능성이 없다.

웹투파이에서 정말 유용한 데이터베이스 관련 기능은 모델의 다이어그램을 생성하여 모델이 서로 어떻게 연계되는지 시각화 할 수 있는 기능이다. 하지만 이 기능을 활성화하려면 PyGraphviz 라이브러리를 설치해야 한다.

웹투파이는 통합된 jQuery 및 AJAX 지원을 통해 국제화 기능, 다양한 캐시(Cache) 처리 방법, 액세스 관리 및 승인, 프론트 엔드(Front End) 효과(서식의 날짜 선택기 등) 등 다른 전문가 수준의 구성요소를 제공한다. 외부 및 내부 미들웨어(Middleware) 연결도 포함되어 있지만 미들웨어를 사용하여 핵심 웹투파이 기능을 대체할 수는 없다. 하지만 웹투파이에는 명시적으로 파이썬의 비동기 기능을 사용할 수 있는 방법이 없으며, 장기 작업을 처리하기 위한 스케줄러(Scheduler)가 있기는 하다. 

웹투파이의 문서도 당연히 ‘북’이라 불린다. 첫째, 웹투파이, 파이썬, 이것들에 사용되는 배치 환경에 대한 엄청난 양의 자료를 다룬다. 둘째, 접근성이 높은 서술식으로 작성되어 있다. 셋째, 보편적인 애플리케이션 구축 시나리오에 대해 심층적으로 다룬다. 예를 들어, 챕터 하나가 jQuery를 사용하여 AJAX 애플리케이션을 구축하는 방법을 다룬다.

웨피
웨피(Weppy)는 플라스크(Flask)의 간결성과 장고의 완전성 사이에 있는 존재처럼 느껴진다. 웨피 앱 개발은 플래시만큼 쉽지만 웨피에는 데이터 계층과 인증 등 장고에 있는 많은 기능도 있다. 그래서 웨피는 극단적으로 단순한 것부터 꽤 정교한 것까지 다양한 앱에 적합하다.

처음에는 웨피 코드가 플라스크 코드나 보틀 코드처럼 단순해 보인다. 설명이 없이도 기본적인 단일 경로 웹 사이트를 구성하여 실행할 수 있다. 경로는 기능 데코레이터(Decorator, 쉬운 방법)나 프로그램으로 설명할 수 있으며, 그 문법은 Flask/Bottle과 유사하다. 템플레이팅도 문법의 사소한 차이를 제외하고는 거의 같다.

웨피는 이런 소규모 프레임워크와는 달리 플러그인 또는 부가기능으로만 통합하는 기능이 포함되어 있다. 예를 들어, 플라스크나 보틀에는 내장된 ORM 또는 데이터 관리 시스템이 없다. 웨피에는 ORM이 포함되어 있다. 단, 훨씬 인기 있는 SQLAlchemy가 아니라 pyDAL 프로젝트에 기반한 것이다. 웨피는 심지어 스키마 마이그레이션을 지원한다. 장고는 이를 ORM으로 지원한다(Django의 마이그레이션 시스템은 훨씬 더 자동화되어 있기도 하다). 웨피는 확장기능 메커니즘이 있지만 공식적으로 승인된 부가기능이 플라스크의 확장기능 카탈로그보다 훨씬 적다.

웨피처럼 가벼운 프레임워크는 RESTful API 구축에 사용되는 경우가 많으며 웨피에는 이를 위해 편의성 기능이 탑재되어 있다. 경로에 @service 데코레이터를 넣으면 반환하는 데이터가 자동으로 서식화 된다(JSON 또는 XML).

웨피에는 더 큰 프레임워크와 유사해 보이지만 소규모로 구현되는 다른 기능들이 포함되어 있다. 그 예로 데이터 검증 메커니즘, 서식 처리, 응답 캐시 처리, 사용자 검증 등이 있다. 모든 경우에 웨피는 ‘적당한’ 접근방식을 취한다. 제공되는 기능은 Django와 다른 무거운 프레임워크만큼 완전하지 않지만 개발자는 이것들을 활용하기 위해 많은 노력을 기울일 필요가 없고 항상 사후에 확장할 수 있다.

웨피에 포함된 또 다른 무거운 프레임워크의 기능은 국제화 지원이다. 템플릿의 문자열은 애플리케이션과 함께 제공되는 로케일(Locale) 파일(단순한 파이썬 사전)에 따라 해석할 수 있다. 언어 선택도 브라우저 요청(즉, Accept-Language HTTP 헤더)을 분석하거나 해석을 특정 경로에 연동시켜 설정할 수 있다.

웨피의 문서는 프레임워크 자체와 같은 성향이다. 깔끔하고 가독성이 좋으며 인간이 소비하도록 작성되었다. 일반적인 ‘헬로우 월드(Hello World)’ 예제 외에 시작 프로젝트로 마이크로블로깅 시스템을 구축할 수 있는 워크스루(Walkthrough) 튜토리얼이 포함되어 있다.

웨피의 장기 계획에는 비동기 및 소켓(Socket)이 저수준 제1 클래스 실체로 포함되어 있다. 웨피의 개발자들은 이런 기능을 버전 2.0에서 도입한 후 미래의 모든 웨피 버전에서는 파이썬 3.7 이상을 요구할 계획이다.

조프
조프(Zope)는 단순한 RESTful API(Bottle 또는 Flask에 따름)나 상호작용성이 있는 기본적인 웹 사이트(Django 스타일)를 위한 것이 아니다. 대신에 조프는 자바(Java)를 위한 서버 제품과 유사한 완전한 기능을 갖춘 기업용 애플리케이션 서버 스택(Stack)이다. 문서에서는 이 프레임워크를 ‘구성요소 개발자, 통합자, 웹 디자이너에게 가장 유용하다’고 설명되어 있다. 제3자 제품인 Plone CMS는 조프를 기질로 사용하며 조프의 지속적인 개발을 위한 주요 동인으로 작용한다.

조프는 웹에서 요청을 받아 요청의 파라미터를 내부 객체 데이터베이스(ZODB)와 비교하고 요청의 GET 또는 POST 파라미터를 사용하여 해당 객체를 실행시킨다. 객체 뒤에 오는 것은 무엇이든 클라이언트로 반환된다. 조프는 이 데이터베이스 객체 시스템을 사용하여 미묘한 객체 권한 할당, 객체에 대한 계승 계층 구조 제공, 데이터베이스 객체의 트랜잭션 및 롤백 처리 같은 작업을 단순화한다.

조프의 규모와 복잡성 때문에 설치가 쉽지는 않다. 소스를 프로젝트 하위 폴더로 압축 해제한다고 되는 일이 아니다. 조프는 구성 파일에 따라 조프 소스 배포판의 사본을 설치하는 zc.buildout이라는 특수한 설치 도구를 사용한다. 파이썬의 패키지 관리 시스템을 사용하는 사람이라면 주춤할 것이다.

조프를 실행시키고 서버에 연결하면 웹 UI가 제공되며, 거기에서 ZODB 객체를 생성 및 편집할 수 있다. 객체는 콘텐츠, 로직, 프레젠테이션 등 3가지 기본적인 역할 중에 하나를 담당하며 문서(MIME 유형을 가진 모든 파일), 파이썬 스크립트, HTML 템플릿으로 구성될 수 있다.

템플릿은 새롭고 더욱 유연한 ZPT(조프 Page Template) 시스템이 더 오래되고 기본적인 DTML 마크업 시스템을 사용하여 처리한다. ZPT는 HTML 태그 안의 속성을 사용하여 데이터를 배치할 곳을 나타내기 때문에 일반적인 HTML 도구를 사용하여 템플릿을 더 쉽게 디자인할 수 있다. 하지만 ZPT 문법은 익숙해지는 데 시간이 필요하다.

조프가 장점으로 주장하는 것 중 하나는 객체지향적 방법론관 관련 있다. 시스템 안에서의 모든 동작이 작동하는 객체의 종류에 상관없이 트랜잭션에 의해 캡슐화 된다는 점이다. 따라서 조프의 데이터베이스에 저장되어 있는 파일을 삭제하거나 코드의 일부에 파괴적인 변경을 가하는 경우 이를 수행한 동작을 롤백하기만 하면 된다.

조프의 접근방식의 단점은 이런 코드베이스에 깃(Git) 같은 현대적인 소스 제어 도구를 사용하기가 어렵다는 것이며, 이로 인해 데이터가 조프의 사용자 정의 데이터베이스 도구에 의해 좌우된다. MySQL 같은 외부 데이터베이스를 조프 애플리케이션에 연결할 수 있지만 ZODB를 대체하는 것이 아니라 애플리케이션 데이터를 호스팅하는 것으로 제한된다.

최소한 현재의 형태에서 조프의 또 다른 단점은 파이썬의 비동기 문법을 직접 지원하지 않는다는 점이다. 하지만 zc.async 패키지를 통해 기기들 사이에서 작업을 분배하고 ZODB 인스턴스 안에서 동기화할 수 있다.dl-ciokorea@foundryco.com