앞에서 polls 애플리케이션을 설계할 때 3개의 페이지가 필요했습니다.

이 3개의 페이지를 보여주기 위해 필요한 뷰와 템플릿을 코딩해보도록 하겠습니다.







1. 처리 흐름

URL 패턴                뷰 이름        뷰가 처리하는 내용

/polls/                index()      index.html 템플릿을 보여줍니다.

/polls/5/              detail()     detail.html 템플릿을 보여줍니다.

/polls/5/vote/         vote()       detail.html에 있는 폼을 POST 방식으로 처리합니다.

/polls/5/results/     results()    results.html 템플릿을 보여줍니다.

/admin/                (장고 기능)     Admin 사이트를 보여줍니다. (장고에서 기본적으로 제공)    

* URL 패턴에서 5는 예시로, 질문번호가 채워지는 자리입니다.


위 설계 내용을 개발하기 위해 아래 순서대로 코딩하도록 하겠습니다. 코딩 순서는 정해진 것은 없지만, 일반적으로 URLconf, 뷰, 템플릿, 뷰 순서로 코딩합니다.

urls.py 작성                // URLconf 내용을 작성

views.index() 함수 작성     // index.html 템플릿도 같이 작성

view.detail() 함수 작성     // detail.html 템플릿도 같이 작성

views.vote() 함수 작성       // redirection 처리 들어있음

views.results() 함수 작성    // results.html 템플릿도 같이 작성


URLconf 설계 내용에 따르면, Admin 사이트까지 포함하여 5개의 URL과 뷰가 필요합니다. 그 내용을 기계적으로 urls.py 파일에 코딩합니다. 코드는 아래와 같습니다.


$ cd ch3/mysite

$ vi urls.py

from django.conf.urls import patterns, url -------------------------------------------------- 1

from polls import views --------------------------------------------------------------------- 2


urlpatterns = patterns('', ------------------------------------------------------------------ 3 url(r'^polls/$', views.index, name = 'index'), url(r'^polls/(?P<question_id>\d+)/$', views.detail, name = 'detail'), url(r'^polls/(?P<question_id)\d+)/vote/$', views.vote, name = 'vote'), url(r'^polls/(?P<question_id)\d+)/results/$', views.results, name = 'results'), ----- 4 url(r'^admin/', include(admin.site.urls)), ------------------------------------------ 5 )


위의 코드를 라인별로 설명하면 아래와 같습니다.

1. 장고의 내장 함수인 patterns(), url() 두 개의 함수를 import 합니다.

2. URLconf에서 뷰를 지정하므로, 뷰가 정의되어 있는 views 모듈을 임포트합니다.

3. patterns() 함수는 URL/뷰 매핑을 처리하는 함수로, 동일한 형식으로 사용하기 때문에 보이는 그대로 코딩하면 됩니다.

4. url() 함수는 5개의 인자를 가지고 있습니다. 앞의 2개는 필수 인자이고, 뒤에 3개는 선택 인자입니다.

5. 마지막 줄에는 Admin 사이트 관련 URLconf가 정의되어 있습니다. 이처럼 이미 정의된 URLconf를 include() 함수로 가져와서 사용할 수 있습니다.


url() 함수는 장고 라이브러리 django.conf.url.py 파일에 아래처럼 정의되어 있습니다.

url(regex, view, kwargs = None, name = None, prefix = '')

    • regex : URL을 정규표현식으로 표현합니다. 정규표현식을 통해 뷰 함수에 넘겨줄 파라미터를 추출할 수 있습니다.
    • view : 요청의 URL이 regex 인자에 매칭되면 장고가 뷰 함수를 호출합니다. 뷰 함수에는 HttpRequest와 Regex에서 추출한 항목을 인자로 넘겨줍니다.
    • kwargs : regex 인자에서 추출한 파라미터 외에 추가적인 인자를 파이썬 사전 타입의 키워드 인자로 뷰 함수에 넘겨줄 수 있습니다.
    • name : 각 URL 별로 이름을 붙여줍니다. 여기서 정해준 이름은 템플릿 파일에서 사용되니 기억해 두기 바랍니다.
    • prefix : 뷰 함수에 대한 접두사 문자열입니다. 우리 예제에서는 사용하지 않으니 무시해도 됩니다.

자, 이제 앞에서 코딩한 내용을 살펴보도록 하겠습니다. 각 라인의 의미는 다음과 같습니다.

url(r'^polls/$', views.index, name = 'index'),

만일, 요청의 URL이 /polls/라면 위 라인이 매칭되고, 정규표현식에서 파라미터를 추출하지 않으므로 views.index(request) 처럼 뷰 함수가 호출됩니다. 이 URL 패턴의 이름을 index라고 정했습니다.

url(r'^polls/(?P<question_id>\d+)/$', views.detail, name = 'detail'),

만일, 요청의 URL이 /polls/5/ 라면 위 라인이 매칭되고, 뷰 함수 호출 시 view.detail(request, question_id = '5')처럼 인자가 대입됩니다. 이 URL 패턴의 이름을 detail이라고 정했습니다. 타 라인의 코드의 동작 방식도 이와 같습니다.


url(r'^admin/', include(admin.site.urls)),

만일 요청의 URL이 /admin/이라면 아래 라인이 매칭되고, 장고에서 제공해주는 뷰 함수를 호출합니다. 우리는 아래 라인처럼 include() 함수만으로 Admin 사이트를 그대로 사용할 수 있습니다.


ROOT_URLCONF = 'mysite.urls'

추가적으로, mysite/settings.py 파일에 ROOT_URLCONF 항목이 정의된다는 것을 기억하시기 바랍니다. 장고는 URL 분석 시, 이 항목에 정의된 urls.py 파일을 가장 먼저 분석하시기 바랍니다.




2. URLconf의 코딩 방법

한 가지 더 알아두어야 할 사항은 URLconf를 코딩할 때 앞에서처럼 하나의 urls.py 파일에 작성할 수도 있고, 다음과 같이 mysite/urls.py와 polls/urls.py 2개의 파일에 작성할 수도 있습니다. 


mysite/urls.py 코딩 방법

$ cd ch3/mysite

$ vi urls.py

from django.conf.urls import patterns, url, include

from django.contrib import admin


urlpatterns = patterns('',

url(r'^polls/', include('polls.urls', namespace = "polls")),

url(r'^admin/', include(admin.site.urls)),

)


polls/urls.py 코딩 방법

$ cd ch3/polls

$ vi urls.py

from django.conf.urls import patterns, url

from polls import views


urlpatterns = patterns('', url(r'^polls/$', views.index, name = 'index'), url(r'^polls/(?P<question_id>\d+)/$', views.detail, name = 'detail'), url(r'^polls/(?P<question_id)\d+)/vote/$', views.vote, name = 'vote'), url(r'^polls/(?P<question_id)\d+)/results/$', views.results, name = 'results'), url(r'^admin/', include(admin.site.urls)), - )


그렇다면, 위의 두 가지 방식 중 어떤 방식이 좋을까요?

두 번째 방법을 추천합니다. 즉, URLconf 모듈을 계층적으로 구성하는 것이 변경도 쉬워지고 확장도 용이해지기 때문입니다. 만일 URL의 polls를 vote라고 변경한다고 가정했을 때, 1개의 파일로 URLconf를 코딩한 경우는 모든 패턴마다, 즉 위 예제의 경우 4개의 패턴을 수정해야 하지만, 2개의 파일로 URLconf를 코딩한 경우는 사우이 URLconf에서 1개의 패턴만 수정하면 됩니다. 이것이 재사용을 기본 원칙으로 하는 장고의 장점 중 하나입니다.

그리고 mysite/urls.py 파일의 include() 함수를 정의할 때 사용한 namespace 인자는 URL패턴의 이름이 충돌나는 것을 방지하기 위한 것입니다. 우리 예제에서는 애플리케이션이 polls 하나뿐이지만, 보통의 프로젝트에서는 여러 개의 애플리케이션으로 이뤄지는 경우가 대부분입니다. 예를 들어, polls 애플리케이션의 URL패턴 이르과 blog 애플리케이션 URL 패턴 이름이 detail이 되는 경우가 발생할 수 있습니다. 이 둘을 구별하기 위해 include() 함수의 namespace 인자를 사용합니다.



앞선 포스팅에서 애플리케이션의 뼈대를 만들어 보았습니다. 이제부터는 실제 개발 대상인 애플리케이션을 추가해 나가도록 하겠습니다.

애플리케이션 파일들을 담을 디렉토리와 애플리케이션 개발에 필요한 파일은 이미 만들었습니다. 파일에 우리가 원하는 내용들을 채워주기만 하면 됩니다.


우리가 개발하게 될 애플리케이션의 내용은 설문에 해당하는 질문을 보여주고, 질문에 포함되어 있는 답변 항목에 투표한 후, 투표 결과를 알려주는 예제입니다.






1. Application 개발 - Model 설계

  코딩을 시작하기 전, 애플리케이션의 로직을 설계해보도록 하겠습니다. 앞서 말씀드린 예제의 요구사항을 분석한 결과 3개의 페이지에 대한 개발이 필요하다고 생각했습니다.


1. index.html : 최근에 실시한 질문의 리스트를 표시합니다.

2. detail.html : 하나의 질문에 대해 투표할 수 있도록 답변 항목을 보여줍니다.

3. results.html : 질문에 따른 투표 결과를 표시합니다.


  위와 같은 요구사항을 반영하여 필요한 테이블을 설계하였습니다.
    • 모든 컬럼은 Null을 담을 수 없도록 했습니다.
    • PK는 자동 증가 속성으로 저장하였습니다.
    • Choice 테이블의 question_id 컬럼은 Question 테이블과 Foreign Key 관계로 연결되도록 했고, 또한 Index를 생성하도록 하였습니다.

< Question Table >

 컬럼명

타입 

제약 조건 

설명 

id 

integer 

NotNull, PK, AutoIncrement 

Primary Key 

question_text 

varchar(200) 

NotNull 

질문 문장 

pub_date 

datetime 

NotNull 

질문 생성 시각 

  질문을 저장하는 테이블입니다.


< Choice Table >

 컬럼명

타입 

제약 조건 

설명 

id 

integer 

NotNull, PK, AutoIncrement 

Primary Key 

choice_text 

varchar(200)

NotNull 

답변 항목 카운트 

votes 

integer 

NotNull 

투표 카운트 

question_id 

integer 

NotNull, FK(Question.id), Index

Foreign Key 

  질문별로 선택용 답변 항목을 저장하는 테이블입니다.






2. Application 개발 - Model 코딩

  모델 작업은 데이터베이스에 테이블을 생성하도록 해주는 작업입니다. 다음 순서대로 진행합니다.

1. vi settings.py

2. vi models.py

3. vi admin.py

4. python manage.py makemigrations

5. python manage.py migrate

6. python manage.py runserver



데이터베이스 확인 (settings.py 파일 설정하기)

  장고는 기본적으로 SQLite3 데이터베이스 엔진을 사용하도록 지정해줍니다. 만일 MySQL 이나 Oracle 등 다른 데이터베이스로 변경하고 싶다면 settings.py 파일에서 수정해주면 됩니다. settings.py 파일은 프로젝트의 전반적인 사항들을 설정해주는 곳으로, 루트 디렉토리를 포함한 각종 디렉토리의 위치, 로그의 형식, 프로젝트에 포함된 애플리케이션 등이 지정되어 있어서 그 내용에 익숙해질수록 장고의 모습을 이해하는 데 도움이 됩니다.

  해당 예제에서는 변경없이 SQLite3 데이터베이스를 사용하여 진행하도록 하기 때문에 설정된 사항을 변경없이 확인만 해보도록 하겠습니다.
  

$ cd ch3/mysite/

$ vi settings.py


  위의 명령어를 입력하여 settings.py 파일을 열고, 중간을 확인해보면 아래와 같이 SQLite3로 데이터베이스가 설정되어 있음을 확인할  수 있습니다.


  추가적으로 몇 가지 더 설정하도록 하겠습니다. 첫 번째로, 프로젝트에 포함되는 애플리케이션들은 모두 설정 파일에 지정되어야 합니다. 따라서, 우리가 개발하고 있는 polls 애플리케이션도 다음과 같이 등록해야 합니다. settings.py 파일 중간에 위치한 INSTALLED_APPS 의 대괄호 안에 polls를 입력해줍니다. 

INSTALLED_APPS = [

...,

'polls',

]



  두 번째로, 타임존이 최초에는 세계표준시로 설정되어 있는데, 한국 시간으로 변경하도록 하겠습니다.

기존 설정 : TIME_ZONE = 'UTC'

바꾼 설정 : TIME_ZONE = 'Asia/Seoul'




테이블 정의 (models.py 파일 설정하기)

앞서 설계한 것처럼, polls 애플리케이션은 Question과 Choice 두 개의 테이블이 필요합니다. 테이블은 models.py 파일에 정의합니다.

$ cd ch3/polls

$ vi models.py


  vi 명령을 사용하여 models.py 파일에 들어가면 아무 내용도 적혀 있지 않은 것을 확인할 수 있습니다.  그곳에 테이블을 설계한 내용에 따라 다음과 같이 입력합니다.   

from django.db import models


class Question(models.Model):

question_text = models.CharField(max_length = 200)

pub_data = models.DateTimeField('data published')


def __str__(self):

return self.question_text    # 이 함수는 객체를 스트링으로 표현할 때 사용하는 함수입니다.                                나중에 보게 될 Admin 사이트나 장고 쉘 등에서 테이블명을 보여줘야 하는데,                                이 함수를 정의하지 않으면 테이블명이 제대로 표시되지 않습니다.



class Choice(models.Model):

question = models.ForeignKey(Question)

choice_text = models.CharField(max_length = 200)

votes = models.IntegerField(default = 0)


def __str__(self):

return self.choice_text

  장고에서는 테이블을 하나의 클래스로 정의하고, 테이블의 컬럼은 클래스의 변수(속성)로 매핑합니다. 테이블 클래스는 django.db.models.Model 클래스를 상속받아 정의하고, 각 클래스 변수의 타입도 장고에서 미리 정의된 필드 클래스를 사용합니다. 


  장고에서 테이블을 설계할 때 몇 가지 유의할 사항은 다음과 같습니다.

  • PK는 클래스에 지정해주지 않아도, 장고는 항상 PK에 대한 속성을 Not Null 및 AutoIncrement로, 이름은 테이블명의 소문자를 접두어로하여 자동으로 생성합니다.
  • DateTimeField() 필드 클래스에 정의한 date published는 pub_date 컬럼에 대한 레이블 문구입니다. 나중에 설명하는 Admin 사이트에서 해당 문구를 확인할 수 있습니다.
  • FK는 항상 다른 테이블의 PK에 연결되므로, Question 클래스의 question_id까지 지정할 필요 없이 Question 클래스만 지정합니다.



Admin 사이트에 테이블 반영 (admin.py 파일 설정하기)

  admin 사이트에 접속해보면 현재까지는 장고에서 기본적으로 제공하는 Users, Groups 테이블만 보입니다. 이제 앞서 models.py 파일에서 정의한 테이블도 Admin 사이트에 보이도록 등록하겠습니다.

$ cd ch3/polls

$ vi admin.py


  models.py 모듈에서 정의한 Question, Choice 클래스를 import 하고, admin.site.register() 함수를 사용하여 임포트한 클래스를 Admin 사이트에 등록해주면 됩니다. 이와 같이 테이블을 새로 만들때는 models.py 와 admin.py 두 개의 파일을 함께 수정해야 합니다.

from django.contrib import admin

from polls.models import Question, Choice


admin.site.register(Question)

admin.site.register(Choice)



데이터베이스에 변경사항 반영

  테이블의 신규 생성, 테이블의 정의 변경 등 데이터베이스에 변경이 필요한 사항이 있으면, 이를 데이터베이스에 실제로 반영해주는 작업을 해야 합니다. 아직까지는 클래스로 테이블 정의만 변경한 상태입니다. 다음 명령으로 변경사항을 데이터베이스에 반영합니다.

$ cd ch3/

$ python manage.py makemigrations    # polls/migrations 디렉토리 하위에 마이그레이션 파일들이 생깁니다.

$ python manage.py migrate    # migrate 명령이 데이터베이스에 테이블을 생성합니다.


  migration 이라는 용어는 장고 1.7 버전부터 사용된 개념으로, 테이블 및 필드의 생성, 삭제, 변경 등과 같이 데이터베이스에 대한 변경사항을 알려주는 정보입니다. 물리적으로는 애플리케이션 디렉토리별로 마이그레이션 파일이 존재합니다. 즉, 우리 예제에서는 polls/migrations 디렉토리 하위에 마이그레이션 파일들이 존재합니다.

    


지금까지의 작업 확인

  지금까지 데이터베이스 관련 사항을 작업하였습니다. 즉, models.py 파일에 테이블을 정의하고 이를 데이터베이스에 반영하는 명령을 실행하였습니다. 또한 테이블을 Admin 사이트에도 등록하였습니다. 지금까지의 작업이 정상적으로 잘 처리되었는지 확인하기 위해 Admin 사이트로 접속해보도록 하겠습니다. 

  만일 runserver가 실행되지 않았다면, 앞서 설명한 것처럼 runserver를 실행시키고, 브라우저 주소창에 다음과 같이 입력합니다.

$ cd ch3/

$ python manage.py runserver 127.0.0.1:8000


http://127.0.0.1:8000/admin

  

  로그인 화면이 나오게 되는데, superuser를 생성하지 않았다면 다음과 같은 명령을 통해 슈퍼계정을 생성합니다.

$ cd ch3/

$ python manage.py createsuperuser


  로그인 화면에서 createsuperuser 명령으로 만든 관리자 Username / Password를 입력하여 로그인하면 다음과 같이 Users, Groups 이외에 우리가 추가한 테이블이 생성되어 있는 것을 확인할 수 있습니다.



장고 프레임워크를 사용하여 웹 개발을 하다 보면, 프로젝트애플리케이션이란 용어가 많이 나옵니다.

장고에서는 이 두 가지 용어에 대해 일반적인 의미와는 조금 다르게, 용어의 개념을 웹 서버 개발 측면에서 좀 더 구체화하여 사용하고 있습니다.

프로젝트란, 개발 대상이 되는 전체 프로그램을 의미하며, 프로젝트를 몇 개의 기능 그룹으로 나누었을 때, 프로젝트 하위의 서브 프로그램을 애플리케이션이라고 말합니다.

즉 서브 프로그램인 애플리케이션을 개발하고, 이들을 모아서 프로젝트 개발을 완성하게 되는 것입니다. 이런 개념으로 프로젝트 디렉토리와 애플리케이션 디렉토리를 구분하고,

코딩하는 파일도 프로젝트 파일인지 애플리케이션 파일인지 구분하여 적절한 위치에 저장해야 합니다.

이런 개념에서 장고가 중요한 점은 하나의 애플리케이션이 여러 개의 프로젝트에 포함될 수 있기 때문에, 애플리케이션을 한 번만 개발하고 이를 다른 프로젝트에

재사용하여 개발의 생산성을 높일 수 있다는 것입니다. 또한 애플리케이션 단위로 이들을 모아 프로젝트로 만들고, 프로젝트를 모아 더 큰 프로젝트를 만드는 방식으로,

계층적인 웹 프로그램 개발이 가능하는 장점이 있습니다.






1. Django 프로젝트의 뼈대 디렉토리

  

< 프로젝트 뼈대의 최종 디렉토리 모습>


  위 그림에서 소개한 디렉토리 및 파일은 뼈대에 해당하는 것으로, 이외에도 프로젝트가 완성된 후에는 templates, static, logs 등의 디렉토리가 더 필요합니다. 또한 개발자가 필요하다고 판단되면 프로젝트 개발을 진행하면서 임의로 추가해도 무방합니다. 각 디렉토리 및 파일의 용도는 다음과 같습니다.

항목

  설명

ch3

  프로젝트 관련 디렉토리 및 파일을 모아주는 최상위 디렉토리입니다. 보통 settings.py 파일의 BASE_DIR 항목으로 지정됩니다. 

db.sqlite3

  SQLite3 데이터베이스 파일입니다. db 디렉토리를 만들고 그 하위에 두기도 합니다.

manage.py 

  장고의 명령어를 처리하는 파일입니다. 

mysite 

  프로젝트명으로 만들어진 디렉토리입니다. 프로젝트 관련 파일들이 들어있습니다. 

__init__.py 

  디렉토리에 이 파일이 있으면 파이썬 패키지로 인식합니다. 

settings.py 

  프로젝트 설정 파일입니다. 

urls.py 

  프로젝트 레벨의 URL 패턴을 정의하는 최상위 URLconf입니다. 보통은 하위 애플리케이션 디렉토리마다 urls.py파일이 또 있습니다. 

wsgi.py 

  Apache와 같은 상용 웹 서버와 WSGI 규격으로 연동하기 위한 파일입니다. 

polls 

  애플리케이션명으로 만들어진 디렉토리입니다. 해당 애플리케이션 관련 파일들이 들어 있습니다.

admin.py

  Admin 사이트에 모델 클래스를 등록해주는 파일입니다. 

 migration

  데이터베이스 변경사항을 관리하기 위한 디렉토리입니다. 데이터베이스에 추가, 삭제, 변경 등이 발생하면 변경 내역을 기록한 파일들이 위치합니다. 

 models.py

  데이터베이스 모델 클래스를 정의하는 파일입니다. 

tests.py

  단위 테스트용 파일입니다. 

views.py

  뷰 함수를 정의하는 파일입니다. 함수형 뷰 및 클래스형 뷰 모두 이 파일에 정의합니다. 






2. Django 프로젝트 생성

 

Step 1. 가장 먼저 아래의 명령으로 mysite라는 프로젝트를 만들도록 하겠습니다.

$ django-admin.py startproject mysite

  mysite라는 프로젝트를 생성하고 현재 디렉토리를 확인해보면 mysite라는 디렉토리가 생겼음을 확인할 수 있습니다. 또한, mysite라는 프로젝트 안에 또다른 mysite 디렉토리가 있음을 알 수 있습니다. 하위 mysite 디렉토리는 프로젝트 디렉토리이고, 상위 mysite 디렉토리는 프로젝트 관련 디렉토리 / 파일을 모으는 역할만 하는 디렉토리입니다. 상위 mysite 디렉토리는 특별한 의미를 가지고 있지 않기 때문에 이름을 변경해도 무방합니다. 하위의 프로젝트 디렉토리 이름과 동일해서 혼동할 수 있으므로, 이름을 변경해보도록 하겠습니다.


Step 2. 디렉토리 이름 혼동 방지를 위해 디렉토리 이름을 변경해줍니다.

$ mv mysite ch3


Step 3. Application 생성하기

  polls라는 애플리케이션을 만드는 명령을 실행합니다. 아래의 명령을 입력하면 장고가 polls라는 애플리케이션 디렉토리와 그 하위에 필요한 파일들을 생성해줍니다. 생성된 파일들의 이름을 눈여겨 보도록 합니다.

$ cd ch3/

$ python manage.py startapp polls

  모든 애플리케이션 개발에 필요한 파일들을 장고가 생성해주고, 개발자들은 그 내용을 채워넣기만 하면 됩니다. 즉, 개발자들이 어떤 파일들을 만들어야 할지 고민할 필요가 없어졌습니다. 어느 파일에 어떤 내용을 채워야 할지는 이름만 봐도 짐작이 가겠지만, 나중에 자세히 설명하도록 하겠습니다.


Step 4. 데이터베이스 변경사항 반영하기

  데이터베이스에 변경사항이 있을 때 이를 반영해주는 명령입니다. 데이터베이스는 디폴트로 SQLite3 데이터베이스 엔진을 사용하는 것으로 지정합니다. 물론 다른 데이터베이스 엔진으로 변경할 수도 있습니다.

  그런데, 아직 데이터베이스 테이블을 만들지도 않았는데, 왜 이 명령이 필요할까요? 장고는 웹 프로젝트 개발 시 반드시 사용자와 사용자의 그룹 테이블이 필요하다고 가정하고 설계되었습니다. 그래서 우리가 테이블을 만들지 않았더라도, 사용자 그룹 테이블을 만들어주기 위해서 프로젝트 개발 시작 시점에 이 명령을 실행하는 것입니다. 명령을 실행하면 migrate 명령에 대한 로그가 보이고, 실행 결과로 SQLite3 데이터베이스 파일인 db.sqlite3 파일이 생성된 것을 확인할 수 있습니다.

$ cd ch3/

$ python manage.py migrate

 위의 명령을 실행하면 ch3 디렉토리에 db.sqlite3 파일이 생성된 것을 확인할 수 있습니다.


Step 5. 현재까지의 작업 확인하기

  지금까지 프로젝트의 뼈대에 해당하는 프로젝트 디렉토리, 애플리케이션 디렉토리를 비롯해 관련 파일들 그리고 사용자 및 사용자 그룹 테이블을 만들었습니다. 이러한 작업만으로도 장고가 제공해주는 웹 페이지와 테이블을 확인할 수 있습니다.

  확인을 위해서 웹 서버를 실행하고, 그 웹 서버에 접속해보겠습니다. 장고에서는 개발 과정 도중에 현재 상태를 확인해볼 수 있도록 runserver라고 하는 간단한 테스트용 웹 서버를 제공해줍니다. 웹 서버를 실행하기 위해서 다음 명령을 입력합니다.

$ cd ch3/

$ python manage.py runserver 127.0.0.1:8000


  runserver가 정상적으로 실행되었다면, 이제 웹 브라우저를 열고 주소창에 다음과 같이 입력합니다.

http://127.0.0.1:8000


  다음 화면처럼 장고의 환영 메시지가 나타나면 정상적으로 실행된 것입니다. 





References

  • 'Django로 배우는 쉽고 빠른 웹 개발', 김석훈, 한빛미디어
  • '나의 첫 번째 Django 프로젝트'


  • 웹 개발 또는 웹 서비스 개발이란 용어를 좀 더 정확하게 표현하면, 웹 애플리케이션 개발이라고 할 수 있습니다.

    그렇다면 애플리케이션이란 무엇일까요?


    1. Django에서의 Application이란?

      웹 사이트를 설계할 때 가장 먼저 해야 할 일은 프로그램이 해야 할 일을 적당한 크기로 나누어서 모듈화하는 것입니다. 이 경우, 웹 사이트의 전체 프로그램 또는 모듈화된 단위 프로그램을 애플리케이션이라고 합니다. 즉, 프로그램을 코딩할 대상을 애플리케이션(Application)이라고 부릅니다.

      그러나 장고에서는 용어를 사용할 때, 애플리케이션의 개념을 웹 서버 개발 측면에서 좀 더 구체화하고 있습니다. 웹 사이트에 대한 전체 프로그램을 프로젝트(Project)라 하고, 모듈화된 단위 프로그램을 애플리케이션이라고 하고, 모듈화된 단위 프로그램을 애플리케이션이라 부르고 있습니다. 즉, 애플리케이션 프로그램들이 모여서 프로젝트를 개발하는 개념입니다. 장고는 기본적으로 MTV모델에 따라 애플리케이션을 개발하도록 유도합니다.



    2. MTV 패턴

      웹 프로그램 개발 시 일반적으로 언급되는 MVC(Model-View-Cotroller)패턴이란 데이터(ModeL), 사용자 인터페이스(View), 데이터를 처리하는 로직(Controller)을 구분해서 한 요소가 다른 요소들에 영향을 주지 않도록 설계하는 방식입니다. 이런 방식으로 개발을 진행하면 UI 디자이너는 데이터 관리나 애플리케이션 로직에 신경 쓰지 않고도 화면 UI를 설계할 수 있고, 로직이나 데이터를 설계하는 개발자도 화면 디자인은 디자이너에게 맡기고 자신의 설계 및 개발 업무에만 집중할 수 있게 됩니다. 파이썬도 이러한 MVC개념을 그대로 받아들였는데, 용어는 다르게 사용하고 있습니다.

      장고 프레임워크에서는 View를 Templete, Controller는 View라고 표현하며, MVC를 MTV 패턴이라고 표현합니다. 예를 들면, 모델은 블로그의 내용을 데이터베이스로부터 가지고 오거나 저장, 수정하는 기능을, 템플릿은 출력을 위해 디자인과 테마를 적용해서 보여지는 페이지를 만들어주는 과정을, 뷰는 버튼을 눌렀을 때 어떤 함수를 호툴하며 데이터를 어떻게 가공할 것인지 결정하는 역할을 담당합니다.

      • Model : 모델은 데이터에 관한 정보를 담습니다. 데이터에 대한 접근, 검증, 작동과 데이터 사이의 관계를 정의하는데, 일반적으로 각각의 모델은 데이터베이스에서 테이블에 해당합니다. 장고에서는 모델을 정의할 때 필드의 종류를 지정해줘야 하는데, 이것이 데이터베이스에게 컬럼 타입을 알려주고 HTML 폼으로 표시 될 때의 입력 타입도 내포하는 역할을 수행합니다. 또한 장고의 폼 자동 생성 API를 이용할 때 데이터 검증에 쓰이기도 합니다.

      • Template : 사용자가 보게 될 화면의 모습을 정의하는 영역입니다. 데이터가 어떻게 표시되는지를 정의하며, 템플릿은 사용자에게 실제로 보여지는 웹 페이지나 문서를 다룹니다. 흔히 HTML에 기반하여 템플릿을 만들며, HTML에 동적인 요소를 추가하기 위해 파이썬의 일부 기능을 쓰게 도와주는 장고 템플릿 태그가 존재합니다.

      • View : 애플리케이션의 제어 흐름 및 처리 로직을 정의하는 영역입니다. 어떤 데이터가 표시될 것인지를 정의합니다. View는 HTTP 응답을 반환해야 하며 응답의 종류는 웹 페이지, 리디렉션, 문서 등의 다양한 형태가 가능합니다. 장고에는 자주 사용되는 형태의 뷰를 패턴화하여 추상화 해둔 재사용 가능한 뷰들을 내장해 놓았는데, 이들을 '제네릭 뷰'라고 하며 원하는 제네릭 뷰를 상속한 클래식 뷰를 생성하여 사용할 수 있습니다.


      웹 클라이언트의 요청을 받고, 장고에서 MTV 모델에 따라 처리하는 과정을 요약하면, 다음과 같습니다.

        1. 클라이언트로부터 요청을 받으면 URLconf 모듈을 이용하여 URL을 분석합니다.

        2. URL분석 결과를 통해 해당 URL에 대한 처리를 담당할 뷰를 결정합니다.

        3. 뷰는 자신의 로직을 실행하면서, 만일 데이터베이스 처리가 필요하면 모델을 통해 처리하고 그 결과를 반환받습니다.

        4. 뷰는 자신의 로직 처리가 끝나면 템플릿을 사용하여 클라이언트에 전송할 HTML 파일을 생성합니다.

        5. 뷰는 최종 결과로 HTML 파일을 클라이언트에게 보내 응답합니다.



    Model - 데이터베이스 설계

      위에서 모델, 템플릿, 뷰에 대해 간략하게 살펴보았습니다. 이제부터는 조금 세부적인 내용을 살펴보도록 하겠습니다. 모델이란 사용될 데이터에 대한 정의를 담고 있는 장고의 클래스입니다. 장고는 ORM 기법을 사용하여 애플리케이션에서 사용할 데이터베이스를 클래스로 매핑해서 코딩 할 수 있습니다. 즉 하나의 모델 클래스는 하나의 테이블에 매핑되고, 모델 클래스의 속성은 테이블의 컬럼에 매핑됩니다. 애플리케이션에서는 데이터베이스에 대한 액세스를 SQL 없이도 클래스를 다루는 것처럼 할 수 있어서 편리합니다. 또한 SQLite3, MySQL, PostgreSQL 등 데이터베이스 엔진을 변경하더라도 ORM을 통한 API는 변경할 필요가 없기 때문에 필요에 따라 데이터베이스 엔진을 훨씬 쉽게 변경할 수 있습니다.

    Template - 화면 UI 설계

      장고는 자체 템플릿 시스템을 갖고 있기 때문에 디자이너도 쉽게 이해할 수 있는 문법을 제공하고 있습니다. 화면의 디자인을 변경할 일이 생기면 디자이너는 프로그램 로직에 상관없이 문법에 맞게 템플릿만 수정하면 되므로, 디자이너와 개발자 간에 협업이 편리해졌습니다. 또한 장고에서 제공하는 템플릿은 파이썬 코드를 직접 사용할 수 있기 때문에 더욱 강력하고 확장하기 쉬운 구조로 되어 있습니다.
      템플릿 파일은 *.html 확장자를 가지며, 장고의 템플릿 시스템 문법에 맞게 작성합니다. 유의할 점은 템플릿 파일을 적절한 디렉토리에 위치시켜야 한다는 것입니다. 즉, 장고에서 템플릿 파일을 찾는 방식을 이해하고 있어야 하며, 장고는 그에 맞는 위치에 템플릿 파일이 위치해야 템플릿 파일을 찾을 수 있습니다.

    View - 로직 설계

      일반적으로 뷰는 웹 요청을 받아서 데이터베이스 접속 등 해당 애플리케이션의 로직에 맞는 처리를 하고, 그 결과 데이터를 HTML로 변환하기 위하여 템플릿 처리를 한 후에, 최종 HTML로 된 응답 데이터를 웹 클라이언트로 반환하는 역할을 합니다. 
      장고에서 뷰는 함수 또는 클래스의 메소드로 작성되며, 웹 요청을 받고 응답을 반환해줍니다. 여기서 응답은 HTML 데이터일 수도 있고, 리다이렉션 명령일 수도 있고, 404 에러 메시지일 수도 있습니다. 다양한 형태의 응답 데이터를 만들어내기 위한 로직을 뷰에 작성하는 것입니다. 이러한 뷰는 보통 views.py 파일에 작성하지만, 원한다면 다른 파일에 작성해도 무방합니다. 다만 파이썬 경로에 있는 파일이어야 찾을 수 있습니다.



    References
    • 'Django로 배우는 쉽고 빠른 웹 개발', 김석훈, 한빛미디어


    Django를 설치하는 방법은 크게 2가지로 나뉩니다.

    1. Git을 사용하여 로컬에 Django를 설치하는 방법
    2. pip를 사용하여 Django를 설치하는 방법

    현재 포스팅에서는 pip를 사용하여 Django를 설치하는 방법을 알려드리도록 하겠습니다.

    1. Django 설치


    Git을 사용하여 로컬에 설치하는 방법


      Django를 설치하기 위해서는 Git이 사전에 설치되어 있어야 합니다. Git 설치 방법을 모른다면 macOS에서 Git 사용하기 (1) 포스팅을 참조합니다.
    Git이 설치되었다면, 터미널에서 아래와 같은 명령어를 입력합니다. 

    $ git clone git://github.com/django/django.git

    Github에서 Django 파일을 복제합니다. 위의 명령어를 입력하면 아래와 같은 Install 화면이 나타나며 설치가 진행됩니다.


    pip를 사용하여 Django를 설치하는 방법


    Step 1. pip를 사용하기 위해 pip를 설치합니다. 

    $ sudo easy_install pip


    Step 2.  성공적으로 pip를 설치했다면, 이제 pip로 파이썬의 패키지들을 설치할 수 있습니다. 이후, 가상환경인 Virtualenv를 설치합니다. Virtualenv는 macOS에 기본적으로 설치되어있는 파이썬 환경과는 별도의 환경으로 완전히 구별하고 싶을 때 사용합니다. 아래의 명령을 사용하여 Virtualenv를 설치합니다.

    $ sudo pip install virtualenv

      

    Step 3. Virtualenv도 성공적으로 설치했다면, 이제 새로운 프로젝트의 루트 디렉토리가 될 새로운 디렉토리를 생성해줍니다. 저의 경우에는 'djangoPrac'으로 이름을 설정했습니다.

    $ mkdir [directory_name] $ cd [directory_name]


    Step 4. 새로운 가상환경을 만듭니다. 저의 경우에는 'django'라고 가상환경 이름을 설정했습니다. *(--no-site-packages 옵션은 기존의 파이썬 환경설정을 따르지 않겠다는 의미입니다.)

    $ virtualenv [virtualenv_name] --no-site-packages


    Step 5. 아래의 명령어를 입력하여 새로운 가상환경을 실행할 수 있습니다. 아래의 명령을 실행하면 명령어 입력 창이 아래와 같은 모양으로 바뀌게 됩니다.

    $ source [virtualenv_name]/bin/activate


    Step 6. 가상환경에 django를 설치해줍니다. 설치 이후 아래와 같은 명령어를 연속하여 입력하면 장고의 설치 상태를 확인할 수 있습니다.

    (django) pip install django

    (django) python -c "import django; print(django.get_version())"

     위와 같이 장고 버전이 출력된다면 정상적으로 설치 된 것입니다.


    위와 같은 과정을 다 마쳤다면, 장고 프로젝트를 시작할 준비가 된 것입니다.

    다음 포스팅에서는 가상환경에서의 장고를 활용하여 새로운 장고 프로젝트를 생성해보도록 하겠습니다.


    References


    장고(Django)는 파이썬으로 작성된 오픈 소스 웹 애플리케이션 프레임워크로, 모델 - 뷰 - 컨트롤러(MVC) 패턴을 따르고 있습니다.

    고도의 데이터베이스 기반 웹사이트를 작성하는 데 있어서 수고를 더는 것이 장고의 주된 목표입니다.

    장고는 컴포넌트의 재사용성과 플러그인화 가능성, 빠른 개발 등을 강조하고 있습니다.


    1. Django의 역사

      장고(Django)는 2003년과 2004년에 로렌스 저널-월드라는 신문사의 인턴 웹 프로그래머였던 에이드리안 홀로바티와 사이먼 윌리슨이 파이썬 이용해 애플리케이션을 만들기 시작하면서 처음 개발되었습니다. 홀로바티와 윌리슨은 PHP가 규마가 큰 웹사이트에 적합하지 않다고 생각하였고 이를 계기로 파이썬을 웹 개발 언어로 사용하기로 결심했습니다. 하지만 규모가 큰 웹 개발에 적합한 파이썬 도구가 없다는 것을 깨닫고 그들은 장고를 개발하게 되었습니다.




    2. Django의 특징

      Django는 Python을 기반으로 만들어진 웹 프레임워크[각주:1]입니다. 웹 개발에서 번거로운 요소들을 새로 개발할 필요 없이 내장된 기능만을 이용해 빠른 개발을 할 수 있다는 장점이 있습니다. Django의 대표적인 특징을 몇 가지 정리해보도록 하겠습니다.


    MVC 패턴 기반 MTV

      장고는 MVC(Model - View - Controller)를 기반으로 한 프레임워크입니다. 하지만 장고에서는 View를 Template, Controller를 View라고 부릅니다. 장고에서 View는 데이터를 가져오고 변형하는 컴포넌트인 반면에 Template는 데이터를 사용자에게 보여주는 컴포넌트입니다. 그래서 장고를 흔히 MTV(Model - Template - View) 프레임워크라고 부르기도 합니다.


    우아한 URL 설계

      웹 프로그래밍을 할 때 URL 디자인은 필수적인 요소입니다. 장고에서는 유연하면서도 강력한 기능을 제공합니다. 장고는 파이썬 프레임워크의 일반적인 우아한 URL 방식을 채택하여 다른 프레임워크에서도 사용할 수 있습니다. 또한 URL 형태를 개발자가 직접 결정할 수 있고, 각 URL 형태를 파이썬 함수에 직접 연결하도록 되어 있어 개발이 편리하고 이해하기도 쉽습니다.


    관리자 웹 인터페이스 제공

      보통 웹 어플리케이션 작성에 있어서 관리자 인터페이스는 꼭 필요한 것이면서도, 일반적인 기능과도 많이 중복되어 구현이 번거롭던 것이 사실입니다. 사용자관리, 사용자 그룹관리, 사용자 별 권한에 대한 것 뿐 아니라, 각각의 모델 객체에 대해서, 목록/추가/삭제/변경의 기능이 관리자 인터페이스에서 모두 제공됩니다. 이는 특히, 데이터베이스, 웹 어플리케이션을 실험적으로 작성하기 좋습니다. 데이터베이스 모델링만으로 웹 어플리케이션의 작동을 실험해 볼 수 있습니다.


    객체 관계 매핑(ORM; Object-Relational Mapping)

      장고의 객체 관계 매핑은 데이터베이스 시스템과 데이터 모델을 연결시키는 다리와 같은 역할을 합니다. 이런 ORM 기능을 통해 다양한 데이터베이스 시스템을 지원하고 있으며, 이미 구축한 데이터베이스 시스템을 다른 데이터베이스로 변경하는 경우에도 설정을 조금만 변경하면 가능하도록 쉽고 편리해졌습니다.


    자체 템플릿 시스템

      장고는 내부적으로 확장이 가능하고 디자인이 쉬운 강력한 템플릿 시스템을 갖고 있습니다. 이를 통해 화면 디자인과 로직에 대한 코딩을 분리하여 독립적으로 개발 진행이 가능합니다. 장고의 템플릿 시스템은 HTML과 같은 텍스트형 언어를 쉽게 다룰 수 있도록 개발되었습니다. 


    캐시 시스템

      동적인 페이지를 만들기 위해서 데이터베이스 쿼리를 수행하고 템플릿을 해석하며, 관련 로직을 실행하서 페이지를 생성하는 일은 서버에 엄청난 부하를 주는 작업입니다. 그래서 캐시 시스템을 사용하여 자주 이용되는 내용을 저장해 두었다가 재사용하는 것이 성능을 높여주는 방법입니다.

      장고의 캐시 시스템은 캐시용 페이지를 메모리, 데이터베이스 내부, 파일 시스템 중 아무 곳에나 저장할 수 있습니다. 또한 캐시 단위를 페이지에서부터 사이트 전체 또는 특정 뷰의 결과, 템플릿의 일부 영역만을 지정하여 저장해 둘 수도 있습니다.


    다국어 지원

      장고는 동일한 소스코드를 다른 나라에서도 사용할 수 있도록 텍스트의 번역, 날짜/시간/숫자의 포맷, 타임존의 지정 등과 같은 다국어 환경을 제공합니다. 간단한 작업만으로 메시지를 하나 이상의 언어로 번역해주기 때문에 다국어를 제공하는 웹 사이트에 아주 유용하게 사용할 수 있습니다.


    풍부한 개발 환경

      장고는 개발에 도움이 될 수 있는 여러 기능을 제공합니다. 대표적으로 테스트용 웹 서버를 포함하고 있어서 개발 과정에서 아파치 등의 사용 웹 서버가 없어도 테스트를 진행할 수 있습니다. 또한 디버깅 모드를 사용할 경우에는 에러를 쉽게 파악하고 해결할 수 있도록 아주 상세한 메시지를 보여줍니다.


    소스 변경사항 자동 반영

      장고에서는 *.py 파일의 변경 여부를 감시하고 있다가 변경이 되면 실행 파일에 변경 내역을 바로 반영해줍니다. 그래서 장고 테스트용 웹 서버를 실행 중인 상태에서 소스 파일을 수정할 경우에도 웹 서버를 다시 시작할 필요 없이 자동으로 새로운 파일이 반영됩니다.



    . References


    1. 웹 프레임워크는 다양한 웹 프로그램들을 손쉽게 만드는 기반인 플랫폼의 개념으로, 이를 활용하면 CMS와 같은 복잡한 웹 프로그램을 비교적 적은 노력을 들여서 만들 수 있습니다. [본문으로]

    + Recent posts