[Django] Django:장고 웹 프레임워크 구조

Django(장고)는 파이썬 언어를 기반으로 만들어진 무료 오픈소스 웹 애플리케이션 프레임워크이다.

 

웹 프레임워크를 한번도 사용한 적이 없는 경우 단어 자체가 굉장히 낯설 수 있는데,

쉽게 풀어 이야기하자면 웹 사이트를 구축할 때 비슷한 유형의 요소들은 항상 존재하기 마련이다.

 

예를 들면 회원가입/로그인/로그아웃, 글쓰기/수정/삭제, 관리자 기능 등 어떤 웹에서나 필요한 기능들을 의미한다.

 

이런 필수 기능들을 매번 0부터 구현한다고 생각해보자.

엄청나게 비효율적이다.

 

이럴 때 바로 사용할 수 있는 구성 요소들을 갖춰 보다 쉽고 빠르게 웹 사이트를 개발할 수 있도록 돕는 것이 바로 웹 프레임워크이다.

개발자 치트키 도구같은거랄까. 알아서 다 해준다.

 

스프링이 자바나 코틀린 등의 언어로의 개발을 쉽게 도와주는 웹 프레임워크라면,

장고는 파이썬언어로 개발을 쉽게 도와주는 치트키인 셈이다.

 

장고는 웹 사이트를 설계할 때 애플리케이션이 모여 프로젝트가 개발되는 개념으로

애플리케이션과 프로젝트가 뭐가 다른가 싶었는데 마치 프로세스와 스레드의 차이정도 된다.

 

프로젝트가 웹 사이트 그 자체라면 애플리케이션은 프로젝트 내의 모듈화된 단위로,

카카오톡이 프로젝트라면 카카오톡 내 채팅기능이 애플리케이션이 되는 것이다.

---

장고는 MVT 패턴을 사용한다.

개발자라면 한번쯤 들어 본 MVC패턴.

MVC패턴이란 Model(DB와 데이터처리), View(사용자 인터페이스), Controller(비즈니스 처리로직)으로 나누어져

각각 코드에 대해 의존성을 낮추고 독립적으로 개발할 수 있는 대표적인 설계방식이다.

 

장고 역시 이 MVC패턴을 기반으로 삼는데, 차이가 있다면 MVT패턴이라고 표현을 한다.

 

1. 모델(Model)

모델은 애플리케이션의 데이터 구조를 정의하며 데이터베이스와 직접 상호작용을 처리하는 부분이다.

Django(장고)는 ORM(Object-Relational Mapping)을 사용하여 데이터베이스를 파이썬 코드로 추상화하여

SQL쿼리를 따로 구성하지 않아도 데이터베이스에 접근하여 작업을 할 수 있다는 특징이 있다.

 

2. 뷰(View)

뷰는 사용자의 요청을 받으면 모델을 통해 데이터를 가공/처리하고 그 결과를 템플릿에 전달하여 사용자 응답을 반환시켜준다.

뷰에는 애플리케이션의 로직이 포함되며, 사용자에게 전달된 입력 처리 및 데이터 가공을 담당하는 부분이다.

 

3. 템플릿(Template)

사용자 인터페이스를 보여주는 곳으로 사용자에게 보여지는 최종 HTML 응답을 생성하는 부분이다.

뷰로부터 전달받은 데이터를 기반으로 HTML파일에 동적 데이터를 삽입해 사용자에게 보여주는 역할을 한다.

 

MVC 개념이 있는 사람이라면 기능은 같으니 View 대신 Template, Controller대신 View라고 생각하면 편하다.

Django의 MVT 패턴

 

동작 순서를 살펴보자

1. 사용자 요청과 URL Dispatcher

우선 클라이언트의 URL 요청(Request)이 서버에 도달하면 URLconf(URL Configuration)를 사용하여 해당 요청에 맞는 뷰를 찾는다.

URLconf은 URL과 View를 매핑해놓은 집합이다.

 

2. View 처리

이 때 Django는 URL패턴을 뷰와 매핑하여 어떤 URL이 호출될 때 어떤 뷰가 처리할지를 결정하고

결정이 되면 뷰는 요청에 따른 로직을 처리하기 위해 필요한 데이터를 모델로부터 가져온다.

뷰가 필요한 데이터를 모델로부터 가져올 때 모델은 뷰에 전달할 데이터를 데이터베이스와 상호작용을 하며 데이터를 받아오는 것이다.

뷰는 모델에서 가져 온 데이터를 기반으로 요청을 처리하고 처리된 데이터를 템플릿에 전달한다.

 

3. Template 렌더링

템플릿은 뷰로부터 전달받은 데이터를 사용하여 사용자에게 보여 질 HTML을 생성하고

최종적으로 생성된 HTML 응답이 사용자에게 반환되어 클라이언트에서는 요청한 데이터를 볼 수 있는 것이다.

 

Django는 각각의 컴포넌트를 독립적으로 개발하고 테스트할 수 있는 MVT 패턴 구조를 제공하게되고

이는 개발의 복잡성을 줄이고, 개발 과정을 체계적으로 관리할 수 있게 해준다.

---

위에서 설명한 내용을 좀 더 작게작게 잘라서 이해해보자.

 

MODEL : 데이터 정의 및 데이터베이스와의 상호작용

모델은 데이터와 관련된 모든 것을 처리한다.

여기서 데이터베이스의 구조(스키마)를 정의하고 데이터의 추가/수정/삭제/검색 등과 같은 작업을 수행하는 메서드들이 포함된다.

ORM을 통해 SQL쿼리 없이도 데이터베이스와 상호 작용이 된다.

Django(장고)에서의 모델은 models.py모듈안에 파이썬 클래스로 정의되며, ORM을 통해 SQL쿼리 없이도 데이터베이스와 상호 작용이 된다.

 

VIEW : 비즈니스 처리로직

뷰는 클라이언트의 요청을 받아 모델에서 데이터를 가져오거나 저장하고 그 결과를 템플릿에 전달하는 역할을 한다.

애플리케이션의 로직을 담당하며 요청 유형에 따라 다른 템플릿을 렌더링하거나 다른 액션을 취하며

Django에서 뷰는 view.py 파일에 클래스의 메서드 형태로 작성될 수 있으며, HTTP 요청을 처리하고 HTTP 응답을 반환하다.

 

HTML 데이터, 리다이렉션 명령, 에러메세지 등 다양한 형태의 응답 데이터를 만들어내기 위한 로직이 뷰에 담겨있는 것이다.

 

TEMPLATE : 사용자 인터페이스(UI)

템플릿은 사용자에게 보여지는 페이지와 구조, 레이아웃 등을 정의한다.

기본은 HTML을 기반으로하며 Django 템플릿 태그와 필터를 사용하여 동적 데이터를 HTML 문서에 삽입이 가능하다.

 

뷰에서 처리된 데이터를 사용자에게 보여주는 데 사용되며, 뷰로부터 전달받은 컨텍스트(context) 데이터를 활용하여 동적 웹 페이지를 생성하게 된다.

---

URLconf

클라이언트의 URL요청이 서버에 도달하면 URLconf가 해당 요청에 맞는 뷰를 찾는다고 했다.

이 과정은 urls.py 파일에 정의 된 URL패턴과 매칭되는지 분석하는 것인데

urls.py 파일에는 URL과 처리(View)를 매핑하는 코드가 작성되어 있기 때문에

URL/VIEW 매핑 집합을 URLconf(URL Configuration)라고 하는 것이다.

from django.contrib import admin
from django.urls import path

urlpatterns = [
    path('admin/', admin.site.urls),
]

 

-> 클라이언트로부터 요청받은 URL은 가장 먼저 최상위 프로젝트 폴더 내의 urls.py 로 접근하여, URL 패턴 매칭 확인

-> 최상위 URLconf의 urlpatterns 리스트 변수에 path메서드로 URL패턴을 지정하고, URL패턴이 매칭되면 호출할 View를 지정

 

※ 어떻게 urls.py에 접근해서 URL매칭이 될까싶어 찾아봤더니 장고의 기능 중 하나다.

장고는 요청된 URL을 분석 할 때, project명/settings.py 파일에 ROOT_URLCONF항목에 정의된 urls.py 파일을 가장 먼저 분석한다고 한다.

ROOT_URLCONF = 'mysite.urls'

 

개별 애플리케이션에서 URL 분리하기

이게 뭔 소리냐고요?

Django(장고)에서 URLConf를 사용하여 개별 애플리케이션마다 URL을 분리하고 계층적인 URL 패턴을 설계할 수 있는데,

개별 애플리케이션 URL 분리의 핵심은 최상위 ROOT_URLconf와 개별 애플리케이션의 URLconf를 통해 URL을 관리하는 구조를 만드는 것이다.

 

이 방법은 각종 이점을 가지고 있는데,

 

1. 모듈성 : 각 애플리케이션의 URLconf를 분리함으로써, 애플리케이션을 더 모듈화하고 재사용이 가능하도록 만들 수 있다.

이는 큰 프로젝트나 여러 프로젝트 간에 공통된 애플리케이션이 사용될 때 유용하다.

 

2. 유지보수성 : URL패턴을 애플리케이션별로 분리하여 특정 애플리케이션과 관련된 변경사항이 발생할 경우

해당 애플리케이션의 URLconf에서만 처리하면 되기 때문에 프로젝트 전체의 복잡성이 줄어들고 유지보수가 용이해진다.

 

3. 명확한 구조 : 최상위 ROOT_URLconf에서 애플리케이션별 URLconf를 참조함으로써,

프로젝트의 URL구조를 좀 더 명확하고 이해하기 쉽게하며, 이는 개발자가 바뀌거나 새로 투입될 경우 프로젝트의 구조를 쉽고 빠르게 파악할 수 있다.

 

조금 더 쉽게 설명하자면 Django 프로젝트는 책장이고, 이 책장에 있는 모든 책이 각 애플리케이션이라고 생각해보자.

 

이 책장에 있는 책은 각각의 목차를 가지고 있는데, 이 때 이 목차가 그 책(애플리케이션)의 URLconf이고 

책장 전체(프로젝트)의 목차를 관리하는 것이 최상위 ROOT_URLconf인 것이다.

 

1. 책 준비하기 : 애플리케이션 준비하기

Django 프로젝트를 시작할 때 여러 개의 애플리케이션을 만든다.

각각의 애플리케이션은 하나의 프로젝트의 한 부분을 담당하고 있다.

 

2. 각 책에 목차 만들기 : 애플리케이션별 URLconf 생성

각 Django 애플리케이션 내에 urls.py 파일을 생성하는데, 이 파일 내에는 그 애플리케이션에서 사용할 모든 URL 패턴이 정의된다.

이 파일은 해당 애플리케이션 내의 루트 URLconf역할을 수행하는 것으로,

예를 들면, 블로그 애플리케이션의 목차에는 홈페이지, 글 목록, 글 상세보기 등의 페이지로 가는 경로(URL)가 적혀 있어야한다.

# 블로그 애플리케이션의 urls.py
from django.urls import path
from . import views

urlpatterns = [
    path('', views.home, name='home'),  # 홈페이지
    path('post/<int:post_id>/', views.post_detail, name='post_detail'),  # 글 상세보기
]

 

3. 책장 전체의 목차 만들기 : 프로젝트의 urls.py에서 애플리케이션 URL 포함

프로젝트의 최상위 폴더에 있는 urls.py 파일이 책장 전체(프로젝트)의 목차인 셈이다.

여기서는 각 애플리케이션의 URLconf을 include() 함수를 사용하여 각 애플리케이션의 urls.py 파일을 참조하는데,

이렇게 하면 해당 애플리케이션의 URL패턴이 프로젝트의 URL패턴에 통합되는 것이다.

# 프로젝트 최상위의 urls.py
from django.urls import path, include

urlpatterns = [
    path('blog/', include('blog.urls')),  # 블로그 애플리케이션으로 가는 경로
    path('users/', include('users.urls')),  # 사용자 관리 애플리케이션으로 가는 경로
]

 

 

URL 패턴 이름으로 하드코딩 된 URL 제거

코드의 유지보수와 가독성 등 여러 이점을 위해 개별 애플리케이션마다 URL을 찢어서 등록해줬다.

이렇게 찢어놓은 URL은 기능마다 여러 템플릿에 등록이 된다.

 

근데 만약 URL 구조가 변경된다면?

하나하나 URL이 쓰인 템플릿을 찾아가 일일이 수정해줘야하는 참사가 벌어지는데, 그런 일이 벌어지면 이러려고 코딩하나 싶어진다.

 

먼저 하드코딩 된 URL이란 아래처럼 직접 URL경로가 작성된 것을 말한다.

<a href="/blog/123/">Read this post</a>

저렇게 직접 URL경로로 작성된 코드가 100개라면 100개를 모두 찾아서 수정해야하는 번거로움이 생기는 것이다.

 

이런 불상사를 막기위해 있는 장고의 기능으로 하드코딩된 URL을 제거하고 URL 패턴 이름을 사용하여

템플릿 내의 링크를 더 관리하기 쉽게 만들어준다.

 

URL패턴 이름 사용하기

1. urls.py에서 URL패턴에 이름 지정하기

from django.urls import path
from . import views

urlpatterns = [
    path('post/<int:post_id>/', views.post_detail, name='post_detail'),
]

post/<int:post_id>/ 라는 긴 URL에 post_detail이라는 이름을 붙여주었다.

 

 

2. 템플릿에서 URL 패턴 이름 사용하기

<a href="{% url 'post_detail' post_id=123 %}">Read this post</a>

 

{% url %} 태그는 주어진 URL 패턴 이름과 변수들(여기서는 post_id=123)을 받아서, 해당하는 URL을 자동으로 생성해주는 태그이다.

그럼 이제 post_detail의 URL을 사용해야하는 모든 템플릿에는 URL패턴만 넣어주면? 끝!

 

이 방식을 사용하면, URL 구조가 변경되더라도 urls.py에서 패턴을 업데이트하기만 하면 되므로, 템플릿 파일을 일일이 수정할 필요가 없기 때문에

유지보수성도 향상되고 개발자가 명시적으로 URL을 지정했을 때 발생할 수 있는 오류가 감소하는 장점을 갖게 된다.

 

URL 패턴 이름의 중복 : app_name

여태껏 설명했던 모든 건 1개의 프로젝트의 1개의 애플리케이션. 즉 1개의 책장에 1개의 책만 가지고 설명했으니 중복 걱정이 없었지만,

실제로 장고의 프로젝트는 수많은 애플리케이션으로 이루어져있다.

 

책장에 책이 1권이 아니라 몇백권이 꽂혀있다는 것이다.

개발자는 기계가 아니다. 그러니 애플리케이션을 만들다보면 목차가 중복되는 일이 분명 생긴다.

 

Django의 app_name 변수는 애플리케이션 내의 urls.py 파일에서 사용되며, URL 네임스페이스를 정의하는 데 사용된다.

네임스페이스란 말 그대로 이름 공간이라는 의미로  Django 프로젝트 내에서 같은 이름의 URL 패턴을 가진 다른 애플리케이션과

구별할 수 있게 해 , URL 이름 충돌을 방지한다.

 

'app_name' 변수 사용하기

1. 'app_name' 설정하기

각 애플리케이션의 urls.py 파일 상단에 app_name을 설정해주면 이 이름을 가지고 해당 애플리케이션의 URL 패턴을 식별하는데 사용한다.

# blog 애플리케이션의 urls.py
app_name = 'blog'
urlpatterns = [
    path('', views.index, name='index'),
    path('post/<int:post_id>/', views.post_detail, name='post_detail'),
]

 

2. 템플릿에서 네임스페이스 사용하기

템플릿에서 {% url %} 태그를 사용할 때, app_name을 URL 패턴 이름 앞에 추가하면

해당 애플리케이션의 URL 패턴을 참조하고 동일한 URL패턴이 생겨도 올바른 URL 생성이 가능하다.

<!-- 템플릿 파일 내에서 -->
<a href="{% url 'blog:post_detail' post_id=123 %}">Read this post</a>