Django의 기본 개념

5 분 소요

Django

장고는 파이썬 기반 오픈 소스 웹 프레임워크이자 웹 개발에 필요한 요소를 모두 갖춘 “풀 스택 웹 프레임워크” 입니다.

장고의 목표는 데이터베이스를 기반으로 하는 고도의 웹서비스 제작 수고를 덜어 안전하고 안정적인 웹서비스를 빠르게 만들 수 있도록 하는 것입니다. “스스로 반복하지 말라 (Don’t Repeat Yourself)”는 DRY 원리에 따라 컴포넌트의 재사용성과 플러그인화를 강조하여 빠른 개발이 가능하도록 하고 있습니다.


다른 파이썬 웹 프레임워크와의 차이점

Flask

플라스크는 풀 스택 프레임워크인 장고와는 다르게 프레임워크의 핵심기능만을 유지하고 그 외에는 기능의 확장성에 기준을 둔 ‘마이크로 프레임워크’입니다. 기본 제공 기능이 적고 규칙도 심플한 만큼 자유도가 높고 유연한 것이 장점입니다.

하지만 만들고자 하는 웹서비스가 복잡할 수록 하나부터 열까지 개발자가 직접 고려하고 만들어야 할 사항이 많아지며, ASGI 를 지원하지 않아 동기 함수 처리만을 지원하는 WSGI를 사용하여 대용량 트래픽을 처리하는 데에 한계가 있습니다.

플라스크에 비해 장고는 상대적으로 무겁고 프레임워크를 사용하기 위한 규칙에 따라야해서 익숙해지는데 시간이 걸리지만 ORM이나 관리자 기능 및 기본 제공되는 클래스 등을 사용하여 개발을 빠르게 할 수 있습니다.

FastAPI

FastAPI는 가장 최근에 개발된 프레임워크로 코드 규칙은 Flask 만큼 간결하면서도 파이썬의 단점인 느린 속도를 커버하여 처리속도가 Go나 Node.js로 만든 API에 대등할 정도로 빠른 것이 장점입니다. FastAPI가 빠른 이유는 ASGI 프레임워크인 ‘Starlette’을 기반으로 만들어져서 비동기 처리를 지원하기 때문입니다.

Django도 3.0 버전부터 ASGI 사용을 지원하며 일부 테스트 결과에서는 FastAPI 보다 더 안정적인 성능을 보이기도 합니다*.

하지만 처음부터 비동기 처리를 기반으로 설계된 FastAPI에 비해 아직까지 django에서의 비동기 처리를 위한 코드 작성은 어려운 편입니다.

ORM도 지원하며 많은 장점을 가지고 성장하고 있는 프레임워크이지만 아직까지는 장고에 비해 지원되는 서드파티 라이브러리 수가 부족하고 사용 레퍼런스로 빈약한 상태입니다. 그리고 파일 구조를 강제하는 django에 비해 기능별 파일 분리를 강조하지 않는 구조를 가지고 있다보니 쉽게 가독성이 떨어질 수 있어 개발 시 구조에 대한 고민이 필요할 수 있습니다.

참고: https://ai.plainenglish.io/django-async-vs-fastapi-vs-wsgi-django-choice-of-ml-dl-inference-servers-answering-some-burning-e6a354bf272a?gi=2919fddffe53


MTV 패턴

장고는 MVC(Model View Controller) 패턴을 기반으로 하는 웹 프레임워크입니다. 다만, 자체적인 기능 구조에 따라 MVC 대신 그에 대응하는 MTV(Model Template View) 라는 용어를 사용합니다.

Model

모델의 역할은 어느 정도 MVC와 비슷합니다. 데이터 혹은 객체 클래스 정보를 가지고 이를 어떻게 DB와 연동시킬 것인지에 대한 내용이 들어갑니다.

장고는 ORM(Object Relational Mapping)을 지원하기 때문에 모델 내에 Fields 옵션을 사용만 잘 사용해서 클래스를 구성하면 SQL 쿼리문을 작성하지 않아도 DB의 조작이 가능합니다.

Template

MVC 패턴의 View에 해당하는 부분으로 유저에게 보여지는 화면을 정의합니다. 자체적인 Django Template 문법을 사용하여 html 템플릿 내에서 데이터의 활용이 가능합니다.

View

MTV의 View는 MVC의 Controller에 대응되는 부분으로, MVC의 View와 MTV의 View는 이름만 같을 뿐 서로 다른 역할을 합니다. 클라이언트로 받은 요청에 따라 모델에 CRUD를 지시하고 결과를 템플릿을 통해 보여주기 위한 로직을 수행하는 파트입니다.

여기에 추가로 장고는 URL과 뷰를 매핑하기 위한 URL Resolution 단계가 별도로 존재합니다. (urls.py)

Django의 실행 구조


출처: 유튜브 “웹 프레임워크 Django(python) 개념 정리”

클라이언트가 웹브라우저에서 요청을 보내면 웹서버를 통해 장고 웹 프레임워크로 요청이 전달됩니다. 이 과정에서 WSGI (Web Server Gateway Interface)가 웹서버와 장고 웹 어플리케이션을 연결시켜주며 http request를 파이썬으로 처리 가능하도록 Callable Object에 담아 전달합니다.

이후 전달된 http request의 URL을 확인하여 적절한 View로 연결하고, View 안의 로직에 따라 Model에 작업을 지시하여 DB의 데이터를 조작하거나 불러옵니다. 이후 유저에게 보여줄 UI와 Model을 통해 전달받은 데이터를 Template을 통해 화면으로 구성하고, 구성된 정보를 다시 웹서버를 통해 유저의 브라우저로 전달합니다.

세부 파일 구조 및 기능

프로젝트와 App

작업용 폴더 위치에서 “django-admin startproject {프로젝트명}” 명령어를 입력하면 자동으로 프로젝트 파일들이 구성됩니다. 앞서 Django 실행 구조에서 봤던 필수 실행 파일들이 다음과 같은 구조로 생성됩니다.

App은 Django 웹 어플리케이션 프로젝트의 기능 단위를 의미합니다. 하나의 프로젝트는 여러가지 기능, 즉 다양한 App의 결합으로 이루어지며 만들어진 App은 다른 장고 프로젝트에서도 하위 기능으로 호환이 가능합니다.

App은 “python manage.py startapp {앱이름}” 명령어로 생성하며 다음과 같은 형태로 파일이 생성됩니다.

Settings.py

Django는 프로젝트에 관한 환경 세팅을 자체 라이브러리를 통해 관리해주는데, 이와 관련된 설정들을 settings.py 파일을 통해 관리합니다.

  • BASE_DIR
    • 프로젝트의 루트 경로. 프로젝트 내의 기본 경로를 설정해주고 모듈을 임포트 할 때 등의 상황에서 프로젝트 루트 폴더를 기준으로 그 하위를 탐색하거나 하는 일을 수행하도록 합니다.
  • SECRET_KEY
    • 보안용 키
  • DEBUG
    • 디버그 모드를 설정
    • 오류 메시지를 출력하고 확인하기에 좋지만 실제 서비스를 배포/운영할 때는 반드시 False로 바꿔줘야 합니다.
  • ALLOWED_HOSTS
    • 접속 가능한 호스트를 정의
    • 디버그 모드가 False일 때, ALLOWED_HOSTS가 비어있으면 서비스를 시작 할 수 없습니다.
  • INSTALLED_APPS
    • 현재 프로젝트에서 사용되는 앱의 목록이 입력되는 공간.
    • 기본적으로 사용되는 앱 외에 pip로 설치한 라이브러리 및 본인이 만들 앱 또한 이곳에 추가로 입력해줘야합니다.
  • MIDDLEWARE
    • request와 response 사이에 실행되는 주요 기능 레이어
  • ROOT_URLCONF
    • urls.py의 경로를 설정
  • TEMPLATES
    • 템플릿 시스템 관련 설정
    • 템플릿 해석 엔진과 폴더의 경로 변경 등에 사용됩니다.
  • WSGI_APPLICATION
    • 웹 서버와의 결합에 사용할 WSGI 어플리케이션 입력
  • DATABASES
    • 데이터베이스 엔진 연결 설정
  • AUTH_PASSWORD_VALIDATORS
    • 비밀번호 입력시 필요 조건에 부합하는지 확인하는 검증 로직 입력란
  • LANGUAGE_CODE, TIME_ZONE…
    • 웹 어플리케이션에 사용될 언어, 시간대 등 internationalization 관련 설정
  • STATIC_URL
    • 정적 파일(css, javascript, img 등)의 URL 설정

manage.py

프로젝트의 settings.py 파일 위치를 환경변수로 등록하고 커맨드라인 입력을 통해 장고 프로젝트를 관리할 수 있도록 하는 파일입니다.

아래의 형태로 명령을 입력받아 실행하며 주요 명령어들은 다음과 같습니다.

python manage.py {명령어}

주요 명령어

  • startapp - app 생성
  • runserver - 개발용 서버 실행 (배포용으로 사용 X)
  • createsuperuser - 관리자 계정 생성
  • makemigrations - app의 모델 변경 사항 체크
  • migration - 모델 변경 사항을 DB에 반영
  • shell - 쉘을 통한 데이터 확인
  • collectstatic - static 파일을 한 곳으로 모음

앞서 설명했듯이 장고는 ORM(Object Relational Mapping)으로 객체(object)와 관계형DB(relational)를 연결(mapping) 하여 SQL 쿼리를 사용하지 않고도 데이터베이스의 CRUD조작이 가능하도록 해줍니다.

그런데 이게 가능하려면 model에 대한 변경사항이 있을 때 models.py 파일을 저장하고 끝낼게 아니라 DB에도 변경사항을 적용해줘야 하기 때문에 웹 어플리케이션을 실행하기 전 makemigrations와 migration 명령을 통해 개발 내용과 실제 환경이 매칭되도록 해줘야합니다.

View의 작성법

— 다시 한번 요약하자면, django 어플리케이션은 전달받은 http request를 request의 타겟 url에 따라 urls.py 를 통해 해당하는 views.py로 보내서 해당 파일에 작성된 코드에 따라 요청을 처리합니다. 이 때 View를 작성하는 방법이 FBV와 CBV 두 가지가 있습니다.

Function-based View (FBV)

함수를 기반으로 하는 뷰를 뜻하며 아래와 같은 형태로 작성하면 됩니다.

def index(request):
    if request.method == 'POST':         
        # POST 요청일경우
    else:         
        # POST 요청이 아닐 경우

함수형 뷰는 가독성이 좋고 기능을 구현하기가 간편합니다. 또한 장고는 다양한 HTTP 기능 지원을 위해 뷰에 적용할 수 있는 데코레이터를 제공하는데, 함수형 뷰는 데코레이터 사용이 직관적이라는 장점도 있습니다.

하지만 함수형 뷰는 코드를 확장시키거나 재사용하기 어렵다는 단점이 있습니다. 장고는 원래 함수형 뷰만 지원했으나, 함수형 뷰에서는 같은 코드를 계속해서 반복하여 써야하기 때문에 DRY 원칙에 어긋나므로 이후에 클래스 기반 뷰인 CBV가 추가되었습니다.

Class-based View (CBV)

클래스 기반 뷰를 의미합니다. 함수형 뷰를 완전히 대체하는 것은 아니지만 장고에서 제공하는 클래스들의 상속과 ‘믹스인’을 통해 자주 사용되는 기능의 코드를 재사용하거나 확장할 수 있으며 뷰를 체계적으로 구성할 수 있습니다.

클래스형 뷰는 아래와 같은 형태로 작성됩니다.

from django.views.generic import View

class IndexView(View):
    model = 사용할 모델이 있다면

    def get(self, request):
        # Get 리퀘스트 일경우
    def post(self, request):
        # POST 리퀘스트 일경우

필요한 기능에 따라 알맞는 Generic View 클래스를 선택하고 클래스 메소드를 사용하거나, 기능을 커스터마이즈 하고 싶을 경우에는 다중상속을 통해 믹스인 클래스들을 조합해서 사용할 수도 있습니다.

하지만 클래스형 뷰에도 단점이 있습니다. 코드의 흐름이 암시적이기 때문에 파악하기 위해서는 장고 클래스들에 대한 추가적인 이해가 필요하며, 이에 따라 가독성도 떨어지는 편입니다. 또한 데코레이터 사용을 위해서는 추가 import 및 메소드 오버라이딩이 별도로 필요합니다.

CBV 사용 가이드라인

  • 뷰는 간단 명료해야 한다.
  • 뷰 코드의 양은 적으면 적을수록 좋다.
  • 뷰 안에서 같은 코드를 반복적으로 사용하지 않는다.
  • 뷰는 프레젠테이션 로직에서 관리하고 비즈니스 로직은 모델에서 처리한다. 매우 특별한 경우에만 폼에서 처리한다.
  • 403, 404, 500 에러 핸들링에는 CBV를 이용하지 않고 FBV를 이용한다.
  • 믹스인은 간단명료해야 한다.

댓글남기기