django-admin을 이용하여 프로젝트를 생성하면, 프로젝트에 필요한 기본적인 파일이 프로젝트명 파일 아래에 생성된다. 가령, 필자가 django-admin start project TEST 라는 명령어를 입력하면, TEST 라는 폴더 및에 TEST 프로젝트 웹 서버를 구동할 기본적인 뼈대 파일이 생성된다는 이야기다. 웹 서버를 만드는 입장에서는 이 기본 파일들의 내용만 조금씩 수정하면 원하는 모양의 서버를 구상할 수 있기 때문에 일일이 기능 구현을 위한 코딩을 진행하지 않아도 된다는 장점이 있다. 마치 Apache 서비스로 웹 구동을 하기 위해 모든 것을 개발할 필요 없이 별도의 /etc 파일 설정만 건드려주어도 되는 것처럼 말이다.
그럼, 이 기본 파일은 무엇이 있을까? 지난 번 포스팅에서 필자가 만들었던 Web_Server_Test라는 프로젝트 폴더를 열어 확인해보도록 하자.
기본적으로 생성되는 파일은 __init__.py을 포함한 asgi, settings, urls, wsgi 파이썬 파일이 있으며, 이들 파일 구동 시 생성되는 파일들을 저장하는 __pycache 폴더가 있다. 하나의 포스팅에서 이 모든 것을 다 다루기에는 내용도 많고, 간단한 웹 페이지는 settings.py와 urls.py 외에 아직 건드릴 일이 없기 때문에, settings.py 파일부터 먼저 살펴보려 한다.
1. settings.py
settings.py는 말 그대로, 만들어진 프로젝트에 대한 웹 Setting을 설정하는 파일이라 보면 된다. 이 파일은 크게 13 개의 부분으로 구분해 볼 수 있다.
- BASE DIR
- Secret Key
- Debug
- Allowed_Hosts
- Application (Installed App과 Middleware)
- Root URL
- Templates
- wsgi application
- DB
- Auth Password Validation
- Internationalization
- Static URLS
- Default_Auto_Field
(1) BASE_DIR
BASE_DIR는 base directory의 줄임말로, settings.py 파일이 현재 프로젝트 파일의 Root 폴더 위치를 인식할 수 있게 만드는 변수다. BASE_DIR 변수에 입력된 내용을 보면, settings.py 파일의 절대 경로(Path(__file__))를 획득하고, 이 경로의 두 계단 상위 폴더(parent.parent), 즉 프로젝트의 루트 폴더를 가리킴을 알 수 있다.
settings.py 마지막에 위와 같이 코드를 입력하고, settings.py를 실행하면, 아래와 같이 settings.py 파일의 두 계단 위의 프로젝트 Root 폴더가 나타남을 알 수 있다.
(2) Secret Key
Django의 공식 문서에 따르면, Secret Key는 캐시에 저장된 세션 사용, 비밀번호의 초기화, 인증된 Hash의 세션을 얻는 용도 등에 사용이 된다고 나온다. 조금 간단하게 압축하자면, Django 웹 서버에서 인증이 필요한 부분에 사용하는 비밀키라고 보면 된다. 따라서 이 키 값은 웹 서버가 다수에게 서비스를 제공하는 경우, 절대 유출되어서는 안되는 값이며, 이 때문에 최근에는 Secret key 값을 직접적으로 settings.py에 명시하지 않고, json 형태의 별도 파일에 보관하고 그 파일을 import 하는 방식으로 이용하는 듯 하다(추후 이와 관련된 포스팅을 진행할 예정이다)
현재는 기본 웹 서버만 구동하려는 단계이기 때문에, 이 secret 값에 대해 별다른 조치를 취해줄 내용은 없다.
(3) Debug
Debug는 현재의 웹 서버를 개발 용도로 사용할 것인지, 아니면 외부로 서비스를 제공할 것인지 설정하는 변수다. Debug는 Bool 변수이며 True와 False 값을 가질 수 있다.
Debug 값이 True 인 경우 개발 모드, False 인 경우 서비스 모드로 전환되는데, True 모드로 설정된 경우 웹 실행 시 실행한 내용에 대한 로그, 또는 에러 등이 상세하게 출력된다.
만약, 웹 사이트 하위 경로가 존재하지 않는 경우, 경로를 설정하는 urls.py 에 해당 경로에 대한 내용이 없다는 내용도 웹 상으로 상세하게 출력해준다.
반면에, Debug 값이 False로 되어 있는 경우, 웹 페이지 접속에 따른 로그도 상세히 나오지 않으며, 잘못된 하위 경로로 접근 시, 웹 브라우저에서도 Not Found 에러만 확인할 수 있다.
그렇기 때문에, Debug 값은 웹 서버에 대한 개발이 진행중인 경우에만 True 로 설정해야 하며, 서비스 제공 시에 이 값을 반드시 False로 돌릴 것을 Django 매뉴얼에서 권고하고 있다.
(4) Allowed_Hosts
Allowed_Hosts는 리눅스 서비스 설정 파일에서 흔히 볼 수 있는 Listen Address와 동일한 역할을 한다. 이 값은 List 형태로 되어 있기 때문에 둘 이상이 값을 지정하여 사용하는 것도 가능하며, 사용하는 DNS 서버가 존재하는 경우 일반적인 사이트 주소 형식(fqdn)으로 사용하는 것도 가능하다.
manage.py runserver 명령어 실행 시, 이 Allowed_Hosts에 명시되지 않은 IP나 사이트 주소로 웹 서버를 실행한다면 아래와 같이 입력한 IP/사이트 주소로 웹 서버의 기동이 불가하다는 에러 문구가 출력된다.
(5) Application (Installed App과 Middleware)
django의 기본 웹을 구동하면 자동으로 화면에 출력되는 관리자 페이지의 기능들은 어떻게 나타나는 것일까? 우리는 관리자를 위한 어떠한 작업도 하지 않은 상태인데 말이다. 사실 이 관리자 페이지와 관련된 파일들은 Django에서 프로젝트를 생성하면 기본적으로 생성된다. 그리고 관리자 페이지에서 볼 수 있는 관리자 등록 관련 기능과 웹 상의 그래픽 등은 Application에 의해 Django의 기본 라이브러리 폴더에 별도로 정의가 되어 있다.
하지만 단순히 라이브러리에 저장만 되어 있다면 이 기능을 사용할 수가 없다. 비밀번호 입력에 사용하는 getpass 모듈 역시 기본 라이브러리 폴더에 저장되어 있지만 import를 하지 않으면 사용할 수 없는 것처럼 말이다. 따라서 admin, auth 등의 기능이 정의된 application 모듈 역시, settings.py에 import 해 줄 필요가 있다. 다만, 일반적인 Python과 달리 import 문으로 시작하는 코드를 직접 입력하는 형태가 아니라, Installed_Application이라는 리스트 변수에 이 모듈들을 입력만 해주면 된다.
기본적으로 필요한 기능은 초기값으로 입력이 된 상태로 나타난다. Installed_Application에 정의된 기본 모듈이 주석처리 될 경우, 웹 구동이 안되거나 구동이 되더라도 화면이 제대로 나타나지 않는 등의 문제가 발생할 수 있다. 가령 예를 들어 필자가 Application의 가장 마지막 모듈인 django.contrib.staticfiles를 주석처리한다고 가정해보자. 이 Application은 화면상의 그림 파일 호출 및 디자인(CSS, js)과 연관된 모듈인데, 이 모듈이 등록되지 않은 경우 관리자 페이지 화면이 밋밋하게 나타나게 된다.
관리자 페이지에 기타 기능이 필요한 경우, 추가 Application을 정의한 뒤 settings.py의 installed_application 변수 내에 생성한 application의 경로를 명시해주면 된다. settings.py에서 installed_application과 Middlewear의 Root 폴더는 아래의 두 경로를 참고한다.
Middleware의 경우, Application과 마찬가지로 특정 기능을 가지는 모듈을 등록하는 점이라는 것은 같지만, Application과 달리 웹 페이지 호출 및 응답 사이에만 관여하는 기능을 별도의 리스트 변수로 지정한 것이라 보면 된다. 기본 웹 구동만 진행하는 경우, Middleware 역시 크게 건드릴 부분은 없다.
(6) Root_URLConf
Root_URLConf 변수는, 구동하려는 웹 서버의 하위 세부 주소를 명시한 파일 이름을 저장하는 변수다. 일반적인 Software 사이트에 가보면, Software에 대해 설명하는 부분, Software를 다운받는 부분 등으로 나뉘어져 있는데, 이 페이지들로 접근할 때, 메인 주소 뒤에 경로(/)를 지정해주는 경우가 있다.
Root_URLConf 변수는 웹 페이지의 경로가 정의된 파일을 값으로 입력받으며, 기본값은 settings.py와 동일한 위치에 있는 urls.py를 지정하고 있다(urls.py 파일은 다음 포스팅에서 알아볼 예정이다).
참고로 urls.py에는 /admin에 대한 경로만 정의가 되어 있으며, 이 정의로 인해 우리가 관리자 페이지로 로그인 할 수 있는 것이다.
(7) Templates
Templates는 말 그대로 Templates, 뼈대 파일을 관리하는 것과 관련이 있다. 이 뼈대파일을 어느 경로에서 찾을지 설정하는 부분이 Templates 변수와 관련된 내용이다.
DIRS와 APP_DIRS가 Templates 관련 경로를 찾는데 사용되는 Dictionary의 Key 값이다. DIRS는 templates 경로를 리스트 형태로 입력하면 되며, APP_DIRS는 등록된(Installed) Application의 기본 Templates 폴더에서 templates 파일들을 사용할 지 말지 결정하는 변수라 bool 값(True / False)으로 입력해주면 된다. APP_DIRS는 기본값이 True 이며, True일 경우 등록된 Application의 templates 파일들을 불러 사용하게 된다.
말로만 이렇게 설명하면 이해가 어려우니, 직접 실험해보자.
현재 웹 서버의 경우, admin, auth를 비롯한 몇몇 Application이 등록되어 있으며, 이들 Application에 대한 기본 페이지가 정의된 파일은 각각의 templates 폴더에 저장되어 있다. 따라서 APP_DIRS가 True로 설정되어 있는 경우, 우리가 계속 봐왔던 관리자 페이지가 무리없이 화면에 나타남을 확인할 수 있다.
이제 이 APP_DIRS 값을 False로 변경시키고 다시 웹 서버를 구동해보자.
필자가 관리자 페이지인 /admin을 호출했으나, APP_DIRS의 값이 False로 설정되어 있기 때문에 기본 Application의 templates 폴더를 참고하지 못한다. 따라서 서버는 화면에 "너가 요청한 자료를 찾을 수 없어" 라는 에러 문구를 보여주는 것이다.
이제 DIRS를 보자. 만약 지금과 같이 APP_DIRS 변수가 False라 기본 templates를 참고하지 않을 때, 이를 Root 폴더에 templates라는 폴더를 만든 다음 /admin에 대한 login.html 을 등록해준다면 어떻게 될까?
우선, Root 폴더 밑에 templates 폴더를 만들어 웹 사이트와 관련된 모든 templates 파일을 모두 이 폴더에 저장하는 것으로 하자. 다음과 같이 Root폴더/templates/admin 아래에 login.html 파일을 생성하자.
다음으로, settings.py 파일을 열어 DIRS 값에 templates 폴더 경로를 입력해주자. 필자는 Root 폴더 아래에 templates 경로를 지정해주었기에, 아래와 같이 DIRS 값을 입력할 것이다.
이제 APP_DIRS가 False로 정의되어 있더라도, /admin 페이지에 대한 templates 파일을 찾는데 있어 문제는 없게 된다.
다시 서버를 실행하고 admin 페이지로 접속해보자. 그럼, 우리가 등록한 login.html의 내용이 고스란히 화면에 출력되는 것을 확인할 수 있다.
(8) wsgi application
다음은 wsgi application이다. wsgi라는 단어가 굉장히 생소한데, 찾아보니 Web Server Gateway Interface의 약자란다. 약자를 봐도 감이 오지 않아 검색을 조금 진행해보니, Python으로 구성된 웹 프레임워크(Django)와 물리 웹 서버 사이를 중계해주는 역할을 하는 녀석이다.
크게 인터넷 웹 페이지는 두 가지 방식으로 제공된다. 하나는 정적페이지, 다른 하나는 동적 페이지라고 한다. 정적 페이지의 경우, 우리가 저장한 문서 파일을 열어보는 것과 비슷하게 동작하는데, 서버에 저장된 html이나 html 내에 포함된 img 파일 등을 고스란히 보여주기만 하는 페이지를 말한다. 즉, 웹에 요청한 자료가 별도의 가공 없이 고스란히 화면에 출력되는 것이라 보면 된다. 필자가 방금 전에 위에서 만든 login.html 파일과 같은 경우가 정적 페이지라고 보면 된다.
반면 동적 페이지는 Django의 관리자 페이지를 생각하면 된다. 관리자 페이지에 들어가면 사용자를 추가하거나 비밀번호를 변경하는 메뉴가 존재하는데, 이 메뉴들은 사용자가 입력한 값을 토대로 DB를 갱신, 즉 입력값에 대한 추가 작업이 필요한 사이트다. 이렇게 입력값에 대한 별도의 전처리가 존재하는 사이트를 동적 사이트라고 한다.
일반적인 웹 서버는 동적 페이지를 인지하지 못한다. 그렇기 때문에 기타 프로그래밍 언어로 입력값을 처리할 수 있는 코드를 별도로 만들어 붙인다. Django의 경우도 Python으로 입력값에 대한 처리가 이루어지도록 되어 있으므로, 일반 웹 서버에서는 Python의 동작을 인지할 수 없으나, wsgi라는 녀석이 Python 스크립트와 서버 사이 중계역할을 함으로써, 동적인 Django가 웹 서버를 통해 서비스를 제공할 수 있게 된다.
보통 이 wsgi Application과 관련된 값은 프로젝트 생성 시 기본으로 지정된 값을 사용하면 된다.
(9) DB
DataBase(DB)는 웹 페이지 동작에 필요한 Data를 저장하는 Database의 종류와 경로를 지정하는 변수다. Django의 경우 sqlite라고 불리는 Database를 사용하고 있으며, project 시작 시 입력한 "python manage.py migrate"에 의해 생성된 DB 파일을 기본값으로 참조하도록 되어 있다. 그렇기 때문에, Migrate 없이 서버를 실행할 경우, 아래와 같이 DB 파일을 migrate 으로 생성하라는 에러 문구가 출력된다.
(10) Auth Password Validation
Auth Password Validation은 말 그대로, 비밀번호에 대한 복잡도 검증을 진행하는 모듈을 정의하는 변수라 보면 된다.
일반적인 웹 사이트의 경우, 비밀번호의 복잡도를 설정하여 무조건 특수문자나 숫자가 들어가도록, 또는 최소 문자 수를 제한하도록 설정되어 있는데, Django의 경우도 기본 패스워드에 대한 복잡도를 별도의 Python 모듈로 명시해두어 설정하려는 비밀번호에 대한 복잡도 검증을 진행할 수 있게 되어 있다.
python manage.py createsuperuser 명령어로 관리자 계정을 만들면서 확인해보자.
비밀번호에 대한 복잡도는 크게 4 가지로 구성되어 있다. (1) 8자 이상인지, (2) 일반적이지 않은 비밀번호인지, (3) 숫자로만 구성되어 있는지, (4) Username의 속성(ID, 이름, E-mail 등)과 비슷한 값으로 비밀번호가 구성되어 있는지에 대한 검증을 진행한다.
만약, Auth Password Validation의 가장 윗 모듈(속성과 비슷한 값을 검증)을 제외한 나머지를 주석처리 하면, 비밀번호를 1234로 지정하더라도 별도의 경고 없이 비밀번호가 잘 적용됨을 확인할 수 있다.
모듈 4개 중 하나라도 등록이 되어야 동작하도록 코딩되어 있는지, 모든 모듈에 주석처리를 하면 비밀번호 입력 시 계정이 생성되지 않는다.
(11) Internationalization
Internationalization은 해석하면 "국제화"로 번역이 되는데, 말 그대로 언어 및 로컬 시간 설정 등을 진행하는 구역이라 보면 된다.
- Language_code: 웹 페이지에 표시하고자 하는 언어를 설정하는 변수다. 현재 필자는 미국 영어(en-us)로 설정되어 있기 때문에 웹 페이지의 모든 내용이 영어로 표시된다.
한국어로 표시하고자 한다면 en-us 대신 ko-kr를 입력해주면 되며, 해당 언어가 적용될 경우 아래와 같이 한글이 웹 화면에 표시되게 된다.
- Time_Zone: 이 변수는 시간과 관련된 변수다. 사실 이 변수는 일반 사용자보다 관리 목적으로 설정하는 경우가 많다. 현재 Debug True인 개발 상태에서는 웹에서 행하는 모든 행위가 로그로 출력되어 화면에 표시되는데, 이 로그들이 찍히는 시간을 잘 보면 모두 UTC 시간(한국시간 -9로 그리니치 시간대)이다.
웹 사이트 관리를 위해 시간을 한국 현지 시간으로 변경해야 하는 경우, 이 변수의 값을 Asia/Seoul로 지정해주면 된다. 한국 시간으로 바꾸고 로그 출력 시간을 확인하면 현지 시간과 동일하게 나타남을 확인할 수 있다.
- USE 관련 변수
이 변수들은 날짜 포맷 또는 언어의 번역과 관련된 변수다. USE_I18N은 Django의 번역 시스템 활성 여부를, USE_L10N과 USE_TZ는 datetime의 형식과 관련된 변수라고 하는데, 아직까지 저 값들을 변경함으로써 유의미한 정보를 알아내지 못했다. 추후 다른 내용을 포스팅하면서 이와 관련된 내용이 나올 경우 업데이트 할 예정이다.
(12) Static URL
Static URL은 정적 웹페이지에 필요한 내용(html, css)만 별도로 관리해야 할 필요성이 있을 때 사용하는 변수다. 웹 서버 내에 사용하는 모든 정적 파일을 하나의 폴더, 예를 들어 Root 폴더 아래의 statics라는 폴더로 관리한다고 하면, settings.py 파일에 static 파일 경로를 찾을 수 있도록 STATICFILES_DIRS 라는 변수를 정의해주어야 한다. 정의 방식은 templates의 DIRS와 유사하게 리스트 형태로 입력하면 된다.
아직까지 정적파일을 별도로 관리하는 단계는 아니기 때문에, 이 내용 역시 추후에 별도 업데이트를 진행할 예정이다.
(13) Default_Auto_Field
Default_Auto_Field는 DB와 관련이 있는 변수다. 보통 DB의 경우 새로운 저장값이 들어왔을 때, ID 필드를 생성하여 번호를 부여하여 관리하게 된다. 보통 이 ID는 새 값이 들어오는 경우 기존 마지막 ID에서 1을 추가하여 부여하게 되는데, 이 ID의 자료형이 int인 경우 너무 큰 정수값을 ID로 쓸 수 없다는 단점이 있다.
그렇기 때문에 자동으로 증가하는 필드값의 경우, 일일이 자료형을 BigInt로 변환해야 했는데 Django 3.2버전부터 Default_Auto_Field 변수를 통해 모든 필드에 전역적으로 설정을 적용할 수 있게 되면서 조금 더 관리가 편해졌다고 한다. 이 부분 역시 본격적으로 DB 관련 내용이 포스팅된다면 추가로 업데이트 할 예정이다.
이번 포스팅에서는 Django로 생성한 프로젝트의 기본 뼈대 파일 중, 설정과 관련된 settings.py에 대해 세세하게 알아보았다. Django가 뼈대 파일을 이용한 프로그램이라 그런지, 이런식으로 기본 파일을 세세하게 들여다볼수록 동작 구조나 기능에 대해 이해가 훨씬 빠르다. Django를 처음 접하시는 분들이라면 프로젝트 진행보다도 기본 파일에 대해 세부적으로 파고 들면서 어떤 방식으로 동작하는지 이해하는 것이 훨씬 좋을 것이라는 생각이 든다.
Fin.
'WebFramework > Python Django' 카테고리의 다른 글
| [Python Django] 6. Django의 기본 파일 살펴보기 - models.py (1) (0) | 2023.08.11 |
|---|---|
| [Python Django] 5. Django의 기본 파일 살펴보기 - urls.py(2) (0) | 2021.07.24 |
| [Python Django] 4. Django의 기본 파일 살펴보기 - views.py(1) (0) | 2021.06.27 |
| [Python Django] 3. Django의 기본 파일 살펴보기 - urls.py(1) (0) | 2021.06.22 |
| [Python Django] 1. Django 설치, 개발 환경 구성 및 기본 설정/구동 (0) | 2021.06.16 |
댓글