1. 웹 애플리케이션 구조

웹 애플리케이션은 위와 같은 구조로 통신한다. Web browser는 client에 해당하고 Web Server와 WAS(Web Application Server), DB Server는 Server에 해당한다. Client(우리가 흔히 쓰는 브라우저)에서 URL을 통해 어떤 정보를 요청(request)하면 Server는 요청정보를 받아와서 일련의 application을 수행하고 반환, 반응, 응답(response)한다.
이때 Client(browser)에게 정보를 보여주는 방식을 만드는 기술이 Front-End, Server에서 요청정보를 가지고 일련의 처리를 하는 기술이 Back-End, 이 모든 기술들을 합쳐 Full-Stack이라 칭한다.
Web Browser에 응답정보를 디자인이나 UI 등을 사용해서 보여주는 Front-End 기술은 대개 HTML, CSS, Javascript를 사용한다. 이외의 다른 언어를 사용하는 방식은 거의 없다.
하지만 Back-End의 경우 웹서버에도 다양한 프로그램이 있으며, Web Application Server(WAS)에도 다양한 언어를 사용해서 개발이 가능하다.

2. Django (장고)
장고는 python 기반의 Full-Stack 프레임워크 중 가장 많은 빈도로 사용되는 프레임워크이다.
장고의 기능 요소에는 여러가지가 있는데 이는 다음과 같다.
- View : HTTP의 요청을 처리 (라우터와 같은 기능으로 볼 수 있다.)
- Model : 데이터 베이스와 관련된 기능을 수행한다.
- Template : 사용자의 인터페이스를 처리해준다. (UI 및 디자인 → Frontend)
- Form : 사용자의 입력 데이터를 처리
- Static 파일 : 정적 파일 관리
- Media 파일 : 사용자가 업로드한 파일 관리
- Message Framework : 일회성 메시지 처리
- Send Email : 이메일 작성 및 전송
- Admin앱 : 관리자를 위한 쉬운 DB 데이터 관리 UI 제공
- Auth앱 : 사용자 인증에 관련된 서비스 제공
- Session앱 : 사용자별로 사용되는 데이터 서비스 제공
위의 장고 기능들은 각각 backend, frontend, DB에서 사용되는데 하나하나 배우면서 정리해볼 것이다.
2.1. MVT 디자인 패턴

장고가 작동하는 구조는 위의 MVT 디자인 패턴을 기준으로 돌아간다. M은 model, V는 view, T는 Template으로 각각 DB, 라우팅, Frontend를 맡는다.
먼저 View는 views.py 스크립트 파일을 사용해서 Client로부터 URL을 통해 요청정보를 받으면 해당 URL을 수행할 수 있는 세부 앱으로 이동시킨다.
Model은 DB 데이터 처리를 담당하는데 view와 연결되어서 앱들이 DB에 접근하여 CRUD를 가능하게 해준다.
마지막으로 Template은 위에서 구현한 app이 응답하는 응답정보를 사용자들이 화면으로 볼 수 있도록 하는 처리를 담당한다.
2.2. 장고 실습
2.2.1. 개발 환경 구축
개발 환경 구축은 어려운 부분은 아니기 때문에 필요한 환경만 나열하고 넘어가겠다.
- 장고(version 3.2)
- 파이썬(version 3.9.4)
- Visual Studio Code
- vs code 확장 → 장고
- vs code 확장 → 장고 템플릿
2.2.2. 장고 프로젝트 생성
먼저 장고는 상위에 프로젝트, 프로젝트의 하위에 앱들을 구성함으로써 Server를 구축한다. 예를 들어, 네이버 웹사이트 서비스를 만드는 프로젝트를 진행한다면 각각의 네이버 뉴스, 금융, 날씨 등등은 앱에 해당한다.
<bash />django-admin startproject 프로젝트이름
본인은 프로젝트 이름을 'mysite2'라고 만들었으며, 위 코드 실행시에는 프로젝트를 만들 폴더 위치로 이동한 후 실행하도록 한다.
프로젝트를 생성하면 해당 프로젝트 이름의 폴더가 생성된다. 폴더 내부에는 장고 프레임워크에 의해 project에 필요한 다양한 파일들이 자동 생성되어있다.
폴더를 기준으로 트리를 찍어보면 아래와 같다.

2.2.3. manage.py
장고 프로젝트에서 manage.py는 장고에서의 많은 기능들을 실행할 때 사용되는 파일이다.
<bash />python manage.py 명령어 [옵션]
위처럼 다양한 명령을 manage.py를 사용해서 수행할 수 있다. 앞으로 계속 보게 될 것.
2.2.4. 초기 설정
장고 프로젝트가 원활히 수행될 수 있도록 먼저 초기 설정을 수행해보자.
<bash />python manage.py migrate
migrate 명령어는 이후에도 다시 설명할테지만 DB에 현재 설정을 반영하는 명령어이다. migrate는 Model 파일에서 DB를 만들고 table을 만들기 위해 migration 파일을 만들고 migrate를 진행해서 Table을 DB에 추가시키는데, 여기서 위의 migrate 명령어는 기본적으로 프로젝트에 존재해야하는 파일들을 DB에 추가시켜주기 위함이다.
2.2.5. 웹 서버 실행
장고를 사용해 웹서버를 실행시키려면 아래의 명령어를 입력하면 된다.
<bash />python manage.py runserver
입력하게 되면 cmd창은 아래와 같이 출력된다.

이 후 cmd창에 출력된 url로 이동하게 되면 웹 브라우저에서 아래와 같이 나타난다.

cmd창에 출력되는 url 주소는 localhost의 주소이다. (127.0.0.1 대신 localhost 라고 입력해도 동일하게 웹 서버를 볼 수 있다.)
2.2.6. 장고 앱 생성
이제 프로젝트 하위에서 앱을 만들어보자.
<bash />python manage.py startapp 앱이름
위와 같은 명령어로 앱을 프로젝트 하위에 생성할 수 있다. 본인은 앱의 이름을 'blog'로 하여 생성했다.
프로젝트 생성시와 마찬가지로 위의 앱 생성 명령어를 실행하면 앱 이름의 폴더가 생성된다.
내부의 파일들은 각각 다른 기능을 수행한다.
- admin.py : 현재 앱의 모델을 admin앱에서 사용하기 위한 설정 파일
- apps.py : 현재 앱에 대한 환경설정 파일
- models.py : 현재 앱에서 사용하는 모델에 대해 구현하는 파일
- tests.py : 현재 앱을 테스트하기 위한 파일
- views.py : 현재 앱의 서비스 기능을 구현하는 파일
- __init__.py : 현재 디텍토리를 패키지로 인식하기 위한 파일
- migrations : 현재 앱의 models.py에 구현된 모델들에 대한 변경작업을 기록하는 파일들이 저장되는 디렉토리이다. (models.py에서 생성, 삭제, 변경 등의 DB작업을 했을 때 바로 DB로 전달되는 것이 아니라 migrations를 거쳐 이동하게됨)
2.2.7. 장고 앱 등록
장고 앱을 생성하였다면 앱을 프로젝트에 연결시켜주는 작업이 필요하다. 그냥 폴더만 존재한다면 장고는 그 폴더가 자신의 하위 앱인지 인식하지 못한다.
프로젝트 하위 디렉토리에서 settings.py에 진입하고 INSTALLED_APPS라는 변수 리스트에 추가할 앱 이름을 입력한다.

위처럼 'blog'라는 앱을 project와 연결시켜주는 작업을 마쳤다. INSTALLED_APPS 리스트를 보면 방금전에 만든 앱 'blog'를 제외하고도 다른 기본 앱들이 이미 연결되어 있는 것도 확인할 수 있다.
2.2.8. URL과 뷰 맵핑
위에서 runserver 명령어에 의해 project 서버가 가동되고 이제 연결된 앱들에 접속할 수 있게 되었다. 그렇다면 앱에는 어떻게 진입할 수 있을까?
URL에 새로운 라우터(URI)를 추가해서 해당 경로의 URL로 이동하게 되면 알맞는 html을 client에게 응답해주도록 설정하면 된다. 이러한 기능을 하는 것이 뷰(view)의 기능이다.

위처럼 우리는 localhost의 blog앱에 있는 test라는 페이지에 접속하고 싶다. 이런 경우에는 blog라는 앱에 먼저 접속하고 세부적으로 어떤 페이지에 접속할 것인지 지정할 수 있다.
- 먼저 최상단의 project 폴더 내 urls.py에 접속하여 '현재까지의 경로 + blog/' 경로로 이동하게 되면 blog 폴더내의 urls 파일에서 처리하도록 라우팅을 해준다.
- blog 폴더(앱)의 urls 파일에서 한번 더 라우팅을 해줌으로써 /blog/test1/에 접속하게 되면 blog 폴더 내 views 파일에서 test1_view라는 view 함수가 작동되도록 설정한다.
프로젝트의 urls 파일에서 blog의 urls로 라우팅하는 부분은 django urls 패키지 내부의 include 메서드를 사용한다. include 메서드를 사용해서 앱별로 url을 관리할 수 있도록 도와주고 고정적인 url을 사용할 수 있다.
2.2.9. View 함수
초기에 언급했듯이 View는 WAS(Web Application Server)의 역할을 한다. 즉, client의 요청정보가 들어오면 일련의 처리과정을 하는 백엔드의 중심이 되는 기능인 것이다.


이제 Client가 요청정보를 Server로 전송하면 Server는 View함수를 통해 응답을 한다는 사실을 알 수 있다. 이번에는 Client가 보낸 요청정보를 사용하는 일부 방법을 보자.


위와 같이 blog 폴더 내부에 urls.py를 만들고 라우터를 만들어주면 test1/숫자(int)로 접속이 가능해진다. 숫자부분은 인자를 view에 전달할 수 있는 부분으로 위의 test1/<int:no> 주소로 요청이 들어오면 아래와 같이 응답한다.

위의 웹화면은 30이라는 int값을 주어 view를 통해 응답한 것이다. path를 지정하는 부분에서 <> 꺾쇠괄호는 인자를 포함한다는 의미이기 때문에 인자를 전달할 때는 반드시 입력해줘야하고 'int:' 부분은 인자인 no가 받는 형식을 int로 한정하겠다는 의미이다.
만약 다른 값이 들어온다면 int: 부분에서 int로 변환하는 작업을 converter에 의해 진행하게 된다.
converter는 django에 포함된 모듈이며 아래와 같은 종류를 가진다.

2.2.10. Model (모델) 설정
Server에서는 DB와 소통할 수 있는 기능이 필요하다. 바로 Model이 그것이다. Model은 연결된 DB와 ORM으로 소통하여 데이터의 저장, 읽기, 삭제, 수정을 수행한다. 이런 과정을 웹에서 할 수 있게끔 만들어주는 것도 Model의 역할이다.
ORM은 뭘까? 보통 DB를 관리한다면 DB와 관련된 언어로 데이터를 CRUD하게 된다. 다만 Django에서는 ORM을 지원하기 때문에 DB안에서 직접 SQL문을 입력하지 않아도 된다. ORM은 파이썬을 DB언어로 인식하게 할 수 있는 번역과도 같은 기능을 수행한다. 실제 SQL문과 비슷할 수 있지만 익숙해지면 훨씬 편리하게 사용할 수 있다고 한다.

먼저 우리가 수행하는 프로젝트 내에서 어떤 DB를 사용하는지 지정해야하고 환경설정이 필요하다.
프로젝트의 settings.py 파일에서 DB 환경설정을 진행한다.

어떤 DB엔진을 사용할 것인지 명시하고 그것이 위치를 명시하면 된다.
만약 mysql을 사용할 것이라면 아래와 같이 진행하면 된다.

2.2.11.
2.2.12. Model 생성
모델은 모델 클래스를 models.py에 생성하여 table을 만드는 방식으로 진행된다. 프로젝트는 blog내부에서 새로운 기능들을 추가하길 원한다. 이번에는 댓글, 태그, 글같은 app들을 만든다고 가정하고 진행해보자.
먼저 'Post'라는 글을 의미하는 Model 클래스 객체를 만들자.

model에서는 다양한 field를 지원한다. (나중에 form 클래스에서도 많이 사용됨) Model에서 이 Field는 DB 테이블에서 각 컬럼이 어떤 형식을 갖는지 제한해주는 역할을 한다. 위와 같이 field를 추가하면 title이라는 컬럼(최대 길이는 250글자), body라는 컬럼을 생성한다. 이제 Post라는 테이블 틀이 만들어진 셈이다.
위 처럼 model 클래스를 생성하면 끝일까? 아니다. 우리가 가지고 있는 model 클래스는 DB와 연동하기 위해서는 2단계를 거쳐야 한다.
- 마이그레이션 파일 작성
- 마이그레이션 파일의 내용을 DB에 반영
model 클래스는 DB에 추가하기 전에 migration이라는 파일을 만들어 제대로 클래스 만들었는지 체크한다. 이후 migrate를 사용해서 만들었던 model 클래스를 DB에 반영한다.
makemigrations 명령어로 migration 파일 작성 후 migrate 수행하여 DB에 table 추가

2.2.13.
2.2.14. Admin과 관리자 계정 만들기
모델을 만들어주었다면 아주 간단하게 웹에서 관리자로 접속해서 데이터를 데이터베이스에 추가해줄 수 있다. 물론 직전에 만든 model의 field 양식에 맞춰서!!
admin에 접속하기 위해서는 슈퍼계정이 필요하다. 이를 위해서 먼저 superuser를 만들어주자.

위의 명령어처럼 'createsuperuser'를 사용해서 super계정을 만들어줄 수 있다. 중간에 빨간글씨로 warning문구가 있지만 오류는 아니므로 넘어가자.
이후 super user로 admin 웹에 접속해보자. localhost 또는 127.0.0.1:8000/admin에 접속하면 된다.

좀전에 만든 super user 아이디로 접속하면?

관리자 화면이 등장한다.
하지만 models에서 만든 Post model이 보이지 않는다!!
DB와 연동이 되지 않은걸까?
정답은 admin에 모델을 추가하지 않아서 그렇다.
우리가 진행하고 있는 'blog' 폴더 내에 있는 admin.py에 들어가서 admin site에서 접근할 수 있는 Model로 지정해주면 된다.

admin에 Post를 등록했다면 아래처럼 해당 앱과 admin에 등록한 앱 내의 model을 볼 수 있다.

2.2.15. 장고 쉘
이번에는 터미널에서 장고 쉘 (shell)에 접속하여 DB를 직접적으로 확인해보자. (이미 Post model의 instance를 만들어 놓은 상태 (= 데이터 추가한 상태))
<bash />python manage.py shell
위의 명령어로 아주 쉽게 shell에 접속할 수 있다.
이 후 DB를 탐색하기 위해 명령어를 입력해보자.

먼저 Post class를 가져와서 해당 모델의 모든 인스턴스를 '.objects.all()' 로 불러오자.
objects는 model의 manager 클래스 객체로 DB table을 관리하는데에 사용된다. 나중에 더 자세하게 설명할 예정이다.
불러온 인스턴스들을 보면 Post object라고 보여진다. 우리는 이런식으로 보여지는 것을 원치않기 때문에 변경할 것이다.

Post model에서 부모 객체인 models.Model의 메서드인 '__str__'을 사용해서 인스턴스를 불러올 때 보여지는 이름을 변경할 수 있다. 아래는 변경한 뒤에 인스턴스를 검색한 결과이다.

위처럼 데이터 베이스를 검색할 수도 있고 추가, 변경, 삭제까지 가능하다.
- 추가
데이터 추가는 아래와 같이 두 가지 방식으로 가능하다.


- 변경

위처럼 불러와서 일부 컬럼 요소값을 변경한뒤 '.save()'를 해주면 된다.
- 삭제

2.2.16. 모델 사용
이번에는 모델을 view에서 사용하여 웹에 시각적으로 나타내보자.
먼저 view함수를 아래와 같이 요청정보와 함께 숫자가 들어왔을 때 해당 인스턴스를 찾아 응답하도록 구현한다.

urls.py에서도 라우팅으로 id를 인자로 넣을 수 있는 url 경로를 만들어준다.

이제 접속해보면 각각의 id에 맞는 인스턴스의 title이 잘 출력되는 것을 확인할 수 있다.

2.2.17. 에러 만들기
만약 view함수에서 id를 받을 때 해당 id가 Post 모델 인스턴스들 중에 존재하는 것이 없다면 어떻게 해야할까? 오류를 발생시켜 출력해야 한다.
에러를 출력하는 방법은 여러가지가 있는데 그 중 일부를 소개한다.
- try - except + 단순출력

위처럼 get을 시도하고 존재하지 않는다면 존재하지 않는 데이터라고 직접적으로 출력시키는 방법이다.

html형식으로 에러 메시지를 확인할 수 있다.
하지만 위와 같은 방법은 메시지만 인식할 수 있고 에러 코드는 확인할 수 없기 때문에 좋은 방법은 아니다.
- Http404()

이전 에러를 출력하는 방법과 유사한데, 이번에는 get에서 어떤 것도 불러오지 못했을 때 except문에서 'raise'를 사용해서 에러코드와 함께 에러 메시지를 출력하도록 한다.

다만 이를 위해서는 django http 패키지 모듈에서 Http404 메서드를 가져와 사용해야 한다.
- get_object_or_404()
마지막 방법은 'get_object_or_404'라는 메서드 사용방식이다. 이 메서드는 메서드 이름에서 알 수 있듯이 인스턴스를 가져와보고 가져오지 못한다면 404에러를 반환하도록 구현되어있다.

코드의 구현도 위와 같이 매우 단순하고 404에러코드도 반환할 수 있어 자주 사용된다.
2.2.18. Reference
https://velog.io/@ddusi/django-2
django urls include를 여러개 써서 효율적인 관리
2020-02-10-django url include multiple django를 쓸 때, 프로젝트의 url을 include를 써서 고정적인 url을 쉽게 관리하거나, 앱별로 url을 관리 할 수 있는 강력한 기능이 있다. 하지만 나는 사용하면서 하나의
velog.io
힘드실 때 보고 힘내세요!
훈남 베이스시스트의 버뮤다 트라이앵글입니다.
https://www.youtube.com/watch?v=s1DKc8_isMM
'웹' 카테고리의 다른 글
[Django] URL Reverse (0) | 2022.11.19 |
---|---|
[Django] 장고 Form (0) | 2022.11.19 |
[Django] 장고 ORM (2) | 2022.11.19 |
[Django] 장고 Model 활용 (1) | 2022.11.19 |
[Django] Template 템플릿 (0) | 2022.11.15 |