Django에서 앱에 대해 알아보자.
프로젝트는 하나 또는 여러 개의 앱이 모여서 이루어진다. 앱은 프로젝트의 기능이라고 볼 수 있다. 여러 기능을 가진 프로젝트를 만들 수도 있고, 하나의 앱으로만 이루어진 프로젝트를 만들 수도 있는 것이다. 그러나 관리하기 편하게 하기 위해서는 여러 개의 앱으로 구성한 프로젝트를 만드는 것을 추천한다고 한다.
VS Code의 터미널 창에 아래의 명령어를 입력해서 실행하면 앱을 생성할 수 있다.
python manage.py startapp <앱 이름>Django에서 앱 이름은 복수형으로 짓는 것을 추천한다고 한다. 그러나 복수형으로 이름을 짓지 않아도, 기능을 실행하거나 하는 데 있어서 전혀 문제는 없다고 한다. 실습에서는 'articles'로 앱 이름을 지었다.
앱을 생성하고 나면 등록해야 한다. 등록은 우리 프로젝트의 설정을 담당하는 settings.py에서 할 수 있다. 지금 우리는 이 파일의 내용을 모두 알아야 할 필요는 없다. 이 파일의 33번째 줄을 보면 아래와 같다.
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
]이는 우리 프로젝트에 등록된 앱 목록이다. 이곳에 우리가 방금 만들어준 앱의 이름, 즉 articles를 추가해주면 되는 것이다.
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'articles',
]여기서 콤마(',')를 붙여준 이유는 '트레일링 콤마'라고 해서, 다음에 우리가 무언가를 추가할 때, 콤마를 빼먹지 않을 수 있게 해주는 작업이다.
여기까지 우리는 앱을 생성하고 등록하는 작업을 했다. 우리가 생성한 앱 파일을 한번 살펴보자. 우선 migrations라는 폴더가 만들어져있다. 이 폴더는 DB 히스토리를 관리하는 폴더라고 보면 된다. 지금은 그냥 넘어가자. admin.py는 우리가 만든 앱에 대한 관리자 페이지 설정하는 것이다. Django는 프레임워크 단에서, 우리가 아무것도 하지 않아도 자동으로 관리자용 페이지를 만들어준다. apps.py는 앱과 관련된 설정을 하는 곳이다. models.py는 DB(데이터베이스) 관련 데이터를 정의하는 곳이다. tests.py는 테스트 관련 코드를 작성하는 곳이다. views.py는 요청을 처리하고, 그 처리한 결과를 반환하는 로직을 작성하는 곳이다. 여기가 메인 로직이 들어가는 곳인 것 같다. 우리는 지금은 models.py, views.py 이 둘을 중점적으로 보면 된다.
전 세계는 해저 케이블로 모두 물리적으로 연결돼있다. 이를 www(word wide web)이라고 한다. 즉, 웹이나 인터넷은 전 세계의 컴퓨터가 서로 연결돼있는 거대한 인프라를 이용하는 것이다.
클라이언트는 서비스를 요청하는 주체, 즉 사용자를 의미한다. 웹 브라우저를 예로 들 수 있다. 서버는 요청을 처리하고 응답하는 주체다. 즉, 자원을 가지고 있는 컴퓨터다. 구글 사이트에 접속하는 것을 예로 들어보자. 어딘가에 있는 구글 사이트를 가지고 있는 컴퓨터에게 '구글 홈페이지.html'을 달라고 요청하는 것이다. 즉, 구글.html 파일을 요청하고 → 구글 서버(서버)가 요청을 받아서 구글.html 파일을 우리 컴퓨터에게 전달하고 → 우리 컴퓨터의 웹 브라우저(클라이언트)가 구글.html 파일을 해석해서 예쁘게 보여준다.
웹 브라우저는 인터넷에서 내가 원하는 페이지를 찾아서 보여주고 하이퍼링크를 통해 다른 페이지로이동할 수 있도록 도와주는 프로그램이다. 랜더링, 즉 html 파일을 우리가 보는 예쁜 화면으로 바꿔주는 프로그램이다. 웹 페이지는 우리가 보는 모든 화면 하나 하나다. 이는 작성한 상태(우리가 작성한 html)를 그대로 제공하는 정적 웹페이지와 요청에 따라 모습이 달라지는 동적 웹페이지가 있다. 동적 웹페이지는 예를 들면, 포털 사이트에서 A유저가 로그인할 때와 B유저가 로그인할 때의 화면이 다른 것이다. 받은 메일의 개수, 가입한 카페 등의 내용이 다를 것이다. 요청에 따라 다른 모습을 보여주려면, 요청을 받아서 적절한 응답을 만들어주는 주체가 필요한데, 그것이 바로 Django다!
프론트엔드는 사용자가 직접 상호작용하는 화면과 UI를 개발하는 부분이고, 백엔드는 서버, 데이터베이스, 애플리케이션 로직 등 웹 애플리케이션의 내부 동작을 담당한다. 비유적으로 설명하자면, 프론트엔드는 사용자가 직접 보고 만지는 웹사이트의 얼굴이라면, 백엔드는 그 얼굴 뒤에서 모든 일을 처리하는 뇌와 심장이다.
클라이언트(웹 브라우저, 모바일 앱 등)는 서버에 특정 작업을 수행하도록 요청(Request)을 보낸다. 이 요청에는 클라이언트 정보, 요청 형식, 인증 정보 등이 포함된다. 요청에는 데이터를 담을 수 있으며, JSON, HTML 폼 데이터 등 다양한 형식으로 전달된다.
클라이언트가 요청하는 작업은 URL을 통해 확인할 수 있다. 서버는 클라이언트의 요청을 처리한 뒤 결과를 응답(Response)으로 전송한다. 응답에는 여러 추가 정보가 포함될 수 있으며, HTML, JSON, XML 등 다양한 형식으로 전달된다. 클라이언트의 요청 내용에 따라 응답 형태가 달라진다.
실습해보자. 우리가 만든 프로젝트 폴더로 이동해서(cd my_first_pjt) 아래의 명령어를 터미널창에 실행시킨다.
python manage.py runserver이를 통해 우리가 구글에 접속하는 것과 같은 현상이 일어나게 된다. 전 세계 어딘가에 있는 나의 서버를 내 컴퓨터에서 실행하고 있는 것이다. 즉, 내 컴퓨터가 하나의 서버로 실행하고 있는 것이다. 이 컴퓨터로 요청할 수 있는 주소는 터미널 창에 나타난 'http://127.0.0.1:8000/' 이 주소다. 이 주소를 주소창에 입력하고 엔터를 치면 아래와 같이 터미널 창에 내용이 생긴다.
[16/Dec/2024 08:16:47] "GET / HTTP/1.1" 200 10731
[16/Dec/2024 08:16:47] "GET /static/admin/css/fonts.css HTTP/1.1" 404 1816첫 번째 줄은 우리가 엔터를 치는 행위로 인해 생긴 요청이다. /라고 하는 아무것도 없는 이 주소로 요청(GET)을 보냈다는 뜻이다. 그리고 우리 눈에는 보이지 않지만, 코드 상에서 응답을 줘서 그 응답을 보고 html을 해석해서 로켓이 있는 화면을 보여주고 있는 것이다. 우리는 Django로 서버를 띄우고 우리가 띄운 이 서버를 클라이언트를 이용해서 요청을 보내고 응답을 받은 것이다.
현수교를 만들 때, 모두 다른 다리들이지만 같은 공법으로 다리를 만든다고 한다. 이를 소프트웨어에서 생각해보자. 다양한 응용 소프트웨어를 만들다보니 공통적인 구조와 문제가 발생하게 된다. 이 때, 구조에도 공통점이 있고, 문제에도 공통점이 존재한다. 즉, 패턴(Pattern)이 보인다.
전세계의 개발자들이 개발을 하다보니 비슷한 문제를 해결하는 공통적인 구조를 발견했다. 이를 소프트웨어의 디자인 패턴이라고 한다.
우리는 이전 장에서 클라이언트-서버를 배웠다. 이것 역시 소프트웨어 디자인 패턴 중 하나다. 클라이언트라는 개념과 서버라는 개념을 두고, 클라이언트는 요청(Request)만 하게 하고 서버는 요청을 처리한 결과를 반환하는 응답(Response)을 하는 구조를 만든 것이다. 즉, 디자인 패턴은 자주 사용되는 소프트웨어의 구조를, 마치 건축 공법처럼 일반화 한 것이라고 할 수 있다.
이제 Django에 적용돼있는 디자인 패턴을 알아보자. 우리는 이를 통해 Django가 작동되는 방식도 알 수 있게 될 것이다. Django의 설계 철학에도 디자인 패턴이 적용되어 있는데, 이를 MTV Pattern 이라고 한다. 이는 원래 있던 MVC 패턴을 Django의 입맛에 맞게 살짝 변형한 것이다.
먼저 MVC 패턴에 대해 알아보자. 이는 Model - View - Controller 3파트로 나누어져있다. 데이터와 논리 구조를 제어하는 설계로, 가장 많이 사용되는 디자인 패턴 중 하나다. 이 패턴이 만들어진 이유는 하나의 큰 소프트웨어를 나눠서 생각해보기 위해서이다. Model은 데이터와 관련된 로직을 관리하고, View는 레이아웃과 관련된 화면과 관련된 로직을 처리하고, Controller는 Model과 View를 사이를 연결하는 나머지 로직을 처리한다. 이렇게 나누어서 구조화한 이유는 생산성을 높이고 유지 보수가 용이하게 하기 위해서다.
MTV Pattern은 MVC 패턴과 이름만 다르지, 사실 똑같다고 할 수 있다. Model은 그대로 Model이다. 원래 MVC 패턴의 View가 하던 일을 MTV Pattern에서는 Template이 하고, 원래 MVC 패턴의 Controller가 하던 일을 MTV Pattern에서는 View가 하는 것이다. 간단히 표현하면 아래와 같다.
- Model -> Model
- View -> Template
- Controller -> View
Django의 MTV Pattern으로 다시 내용을 정리해보자. Model은 MVC에서의 Model과 같으며 데이터와 관련된 로직을 처리한다. 즉, 데이터 구조를 정의하고 데이터베이스 기록을 관리하는 곳이다. Template은 MVC에서의 View다. 레이아웃과 화면상의 로직을 처리한다. 즉, UI와 레이아웃을 다룬다. View는 MVC에서의 Controller로, Model과 Template을 연결하면서, 메인 비지니스 로직을 담당한다. 클라이언트의 요청에 대해 처리를 분기하는 역할을 한다. DB도 조회하고 외부로 요청하기도 한다. 응답을 만들어서 클라이언트에게 전달한다.
MTV Pattern의 View에 관해 추가 설명을 하겠다. 요청에 따라 다른 처리를 하게 된다. 데이터와 관련된 요청이 들어와서 데이터 관련 처리를 하려면 Model로 가서 처리를 하게 되고, 갖고온 데이터를 이용해서 Template 처리가 필요하면 Template한테 시켜서 Template을 받아오고 지지고 볶고 하면서 결과를 만든다고 한다. 그리고 이 만든 결과를 클라이언트한테 응답으로 보내주는 것도 View에서 한다. 유튜브 동영상 달라는 요청이 들어오면 외부로 요청하는 것도 View가 한다.
전체적인 내용을 정리해보자.
클라이언트로 HTTP Request가 들어오면, urls.py(URLS)에서 먼저 그 리퀘스트를 받아서 어떤 View로 보낼 지를 결정한다. View는 들어온 요청을 보고 로직에 따라서, 데이터 관련된 읽기나 쓰기 처리가 필요하면 models.py(Models)로 보내서 처리해서 View에 갖다준다. View가 그걸 받아서 HTML 파일이 필요하면 <filename>.html(Template)에 데이터를 주고 처리하게 할 수도 있고, 데이터를 주지 않고 Template을 가져오게 할 수도 있다. 웹에서의 화면은 HTML이기 때문에, HTML 관련된, 즉 화면과 관련된 부분은 모두 Template에서 하는 것이다. 이렇게 받은 결과를 응답으로 HTTP Response(HTML 등 여러 형식)를 주게 되는 것이다.