[장고웹개발] 장고와 친해져 봅시다. (부제: 요즘도 장고 쓰냐)

스프링을 한참 공부하다가 장고를 공부하게 되었다. 새로운 직장은 기술 부채가 다소 있는 편인데, PHP로 대부분의 서버를 구성해온 상황에서 장고 서비스를 구축해 조금씩 이전해 나가려는 계획을 가지고 있다.

나는 장고에 대한 경험이 거의 전무했다. 과거에 파이썬 기초 교육을 끝내고 겁도 없이 장고에 도전했다가 나가떨어진 적이 있었기에 장고는 "괜히" 어렵고 "쓸데없이" 복잡한 구조라고 생각했던 적도 있다. 여우와 신 포도 같은 것이었다.

당시에 왜 장고에게서 어떤 벽을 느낀 것일까?

• 일단 웹 서버와 클라이언트가 상호 교류하는 것에 대한 이해가 부족했다.
• 거기에다 MVT... MVC... 단어만 들어도 어려울 것 같은 패턴 구조
• ORM에 대한 갈증을 느끼기 전에 맛을 보니 쓴 맛만 보게 됐다.
• 프레임워크와 라이브러리의 차이를 제대로 알지 못했고, 뭐 이렇게 하라는게 맞나 생각했다.

... 이런 이유가 되겠다. 

길게 풀어 쓸 생각은 없지만 웹서버에 관해서는 장고와 손절한 뒤 플라스크+몽고디비를 사용한 웹개발을 익혔고, 그 다음 자바 스프링+JPA를 익혔다. 그리고 취업해서는 장고를 쓰게 된 것이다!! (와우 일관성 없는 커리어로군)

아무튼 계속하자.

장고의 장점은 매우 많다. 파이썬을 사용하면서 나오는 장점들은 다른 곳에서도 많이 말하는 것 같고, 파이썬의 머신러닝 라이브러리들이나 웹 스크래핑을 사용하는 프로젝트에서 연결하기 편하다(아마도 이것이 장고를 주요 스택으로 쓰는 회사들인 것 같다.). 강력한 폼과 모델, 템플릿 기능을 가지고 있다. (이 부분에 대해서 아래에서 다뤄 보겠다.)

장고의 공식 홈페이지에서는 빠르다. 확장성 있다. 보안에 뛰어나다. 세가지를 내세운다. 이 중에 빠르다는 부분에 대해서 조금 확신이 없었던 게, 개발 속도를 빠르게 해주는 부분을 더 내세우는 것 같은데 이것저것 해줘야 할 게 많으니까 더 번거롭지 않나? 하는 생각을 했었다. 

(깃털 같이 가벼운 프레임워크) 플라스크를 만져본 후에 비교적 무거운 스프링을 배우려니까. 서버 한번 끄고 켤 때마다 수 분을 소요하는 스프링(자바)은 날 너무 답답하게 했고 그 후에 취업 준비 중에 장고를 독학하면서 막힌 속이 뚫리는 기분을 느끼게 되었다. 내 컴퓨터 사양이 안좋은 탓도 있었겠지.. 인텔리제이 하나로 휘청이는 나의 작고 소중한 그램14....

아무튼 장고를 배워보고 있는데, 생각보다 재미있었고, 해 볼 만 한 것 같다.

그런데 파이썬 기초를 막 끝냈을 무렵인 작년 5월 경에 접한 장고 강의와 올해 초에 구매해 공부한 장고 강의의 결이 뭔가 달랐다. 부트캠프에서 내가 성장한 탓도 있겠지만, 강의의 내용이 좀 달라진 기분 (구매한 곳은 둘다 패스트캠퍼스였다.)이 들었고, 커리큘럼을 다시 읽어보다 느낀 것은 그 잠깐의 텀에도 불구하고, 장고의 강력한 form과 template에 중점을 둔 작년 강의에 비해 올해의 강의에는 장고의 확장성과 안정성을 강조하는 차이가 있었다. 작년의 강의는 Form과 Field, Template Language를 하나하나 꼼꼼히 다뤘는데, 그런 부분을 이번 강의에선 과감하게 생략하셨다. 그리고 그 이유도 납득할 만했다. 마이크로서비스아키텍쳐에 한발 더 가까워진 강의. 그래서 장고의 100퍼센트를 모두 사용하려는 것보다 강점인 부분만을 흡수시키는 느낌이었다.

그래서 이번에 내가 구현한 프로젝트는, forms.py 파일 조차 가지고 있지 않다. (schemas.py도 없다.) 하지만 장고의 강력한 어드민 기능은 최대한으로 사용했고, ORM도 많이 사용했다.

그리고 한가지 차이점은

Django Ninja를 사용했다.

Django는 개발에 편의성을 많이 가져다 주지만, 그렇게 빠르지는 않다. Django Rest Framework를 사용하면 Flask와 MongoDB를 사용할 때의 엄청난 속도를 기대하기는 힘들어진다. 그래서 FastAPI나 Flask가 최근에 많이 사랑받았던 것 같다. 그래서 등장한 것이 이 장고-닌자다. 

Django Ninja는 Django 및 Python 3.6+ 타입 힌트를 사용하여 API를 빌드하기 위한 웹 프레임워크입니다.

쉽고 직관적: 사용하기 쉽고 직관적으로 설계되었습니다.
비동기 지원: Pydantic 및 비동기 지원 덕분에 매우 높은 성능을 제공 합니다.
빠른 문서화: 입력 힌트와 자동 문서를 통해 비즈니스 로직에만 집중할 수 있습니다.
RESTful하다: API에 대한 개방형 표준을 준수하며 OpenAPI (Swagger로 알려짐) 및 JSON Schema 를 지원한다.
장고 친화적: Django Core 및 ORM과 잘 통합된다.

피곤하니까 코드 던지고 자러갑니댱 슈ㅅ슉 쉬발러마 슈슉

from typing import List
# 리턴 타입 명시를 위해 임포트
from django.core.handlers.wsgi import WSGIRequest
# 요청 형태는 WSGIRequest로 들어올 예정
# 이렇게 타입을 계속해서 명시해 주면 다른 개발자들과 소통하기 좋고,
# 에디터도 계속해서 프로젝트를 따라오고 있기 때문에 자동완성을 쾌적하게 제공한다.
from ninja import NinjaAPI
# NinjaAPI 호출
from ninja.orm import create_schema
# NinjaAPI의 ORM으로 대상 모델을 Serialize 해준다.
from ninja.pagination import paginate, LimitOffsetPagination
# Pageable한 리스트를 가져오기 위해 간단한 어노테이션을 제공한다.
# limit(100) offset(0)을 각각 지정하는 LimitOffsetPagination
# page-number를 지정하는 PageNumberPagination이 있다.

from crawler.models import TrackingApps
# 장고의 ORM은 이렇게 모델을 정의하고, object로 데이터베이스의 스트림?을 가져온다.

api = NinjaAPI(title="Ninja")
# 타이틀은 SwaggerUI 화면에서 보이게 된다.

TrackingSchema = create_schema(TrackingApps)
# serializing 


# following "GET"
@api.get("/following", response=List[TrackingSchema], tags=["Tracking Apps"])
@paginate(LimitOffsetPagination)
# 이 어노테이션으로 인해서 limit, offset이라는 두개의 파라미터가 추가되고, 페이지가 생긴다.
def list_tracking(request: WSGIRequest, sort="created_at", reverse=True):
    """
    ## parameters:
    - request: WSGIRequest
    - sort: "id", "created_at", "deal_type", "app_name", "icon_url", "market_appid", "package_name", "rank"
    - reverse: reversed or not
    이렇게 적어주면 swagger에서 예쁘게 나타납니다.
    """
    print(request.GET)
    if reverse:
        return TrackingApps.objects.order_by(sort).reverse().all()
    return TrackingApps.objects.order_by(sort).all()

 

이렇게 익숙한 스웨거의 UI를 만들어준다.

함수의 이름으로 자동으로 짧은 설명이 붙고, doc-string으로 작성한 글이 문서에 작성된다. limit과 offset은 pagination에서 제공한 것이다.

외주 작업 등의 이유로 관리자 페이지가 필요한 경우 빠른 개발을 위해 장고를 적극 추천하고, 또 장고를 사용해 프론트와 백엔드를 각각의 서버에 배포하는 아키텍처를 구상하는 경우에 닌자API를 추천한다.

개발일지 써야지써야지 하다가 짧게나마 쓰고 갑니다 슈슈슉