이번 시간에는 간단한 미니 프로젝트를 하나 진행해 볼까 합니다. 바로 게시판 서비스!! 간단하게 게시판 서비스를 구현하고, 이를 REST API와 연동하여 사용하는 방법을 살펴보고자 합니다.
게시판 서비스 구상하기
가장 먼저 저희가 할 일은, 어떤 게시판 서비스를 제공할 것인가? 에 대한 부분 입니다. 일종의 요구 사항을 분석하고, 이를 토대로 설계를 하는 과정이죠. 이번에 만들어볼 게시판은, 정말 일반적이고 흔한 한국형 게시판을 만들어 보려고 합니다. 게시물들을 조회할 수 있고 / 글쓰기를 통해 게시물을 생성할 수 있으며 / 수정…. 은 귀찮으니 일단 빼고 / 삭제도 가능하며 / 댓글…. 도 귀찮으니 나중에 만들어보고… 뭔가 많이 빠진 거 같지만, 기분 탓 입니다. 자, 그럼 간단하게 구상한 이 게시판을 토대로 데이터 모델링을 먼저 해볼까요?
게시판 모델링
일단, 간략하게 개념을 하나 잡아 보겠습니다. 화면을 중심으로 개념을 잡아 볼까요? 대충, 만들고자 하는 게시판을 이미지로 그려보면 이렇게 될 겁니다.
엄청 대충 그린 거 같고…. ‘검색’ 기능도 빠져있지만, 아무렴… 이런 모양 만들 거잖아요?
저런 모양이 될 겁니다. 일단, 사각형이 하나의 게시물 이라고 가정해 보자구요. 아, 제일 오른쪽 아래에 있는 건 ‘글쓰기’ 버튼 이네요. 자, 여기서 ‘기능’ 과 ‘데이터’ 를 분리해서 정리를 한번 해보면,
1. 데이터는 ‘게시물’ 하나 에 포함되는 내용으로, ‘순번’, ‘제목’, ‘내용’, ‘작성자’, ‘작성 시간’ 등의 게시물 하나와 연관된 데이터이다.
2. 이 게시판 에서 기능은 ‘게시물’ 하나를 제어하기 위한 내용으로, ‘게시물 작성’, ‘게시물 수정(이런 거 없슴다)‘, ‘게시물 검색(이런 거 도 없슴다)‘, ‘게시물에 댓글 달기(허 거참…)‘, ‘게시물 삭제’ 등을 가진다.
라고 정리해 볼 수 있겠습니다. 먼저, 게시판에 대한 데이터 모델링을 먼저 시작하고, 이를 토대로 기능들을 하나하나 구현해 갈 것 이므로…. 먼저 ‘데이터 모델링’ 을 시작해 보죠.
게시물 데이터 모델링
게시물에 대한 데이터 모델을 만들기 위해, 어떠한 데이터들이 게시물 데이터에 포함되어져야 하는지 다시 한번 정리해 봅시다.
1. 게시물의 고유한 인덱스
2. 게시물의 제목
3. 게시물의 내용
4. 게시물의 작성자
5. 게시물의 작성시간
6. 게시물의 고유 비밀번호
대략 6가지 정도가 필요할 거 같네요. 이 부분은 요구 사항과 필요한 기능에 따라 달라질 겁니다. 저희는 정말 간단한 게시판 서비스를 할 거니… 저 정도면 충분할 거 같네요. 이제 대략적인 데이터 모델링이 끝났으니, Django 프로젝트를 한번 시작해 봅시다.
프로젝트 시작
프로젝트 작성은 다른 포스팅을 참고하시고, ‘board’ 라는 프로젝트를 만들어서 진행해 보겠습니다.
구성은 대략 이렇습니다. 템플릿은 일단 기본 Django 템플릿을 사용합시다.
프로젝트를 만들고, 바로 모델링을 시작해 보죠. 일단, 간략하게 다음 구성대로 진행해 보려고 합니다.
– 프로젝트 명 : board
– 앱 : post_service / 게시물 하나하나를 관리하고 다룰 앱.
그럼, 이러한 내용을 토대로 바로 앱을 하나 만들어 봐야겠네요?
board 프로젝트에서 app을 생성해 봅시다. PyCharm을 쓴다면, Ctrl + Alt + R 키를 누르면 Django 태스크를 쉽고 빠르게 실행할 수 있습니다. 콘솔이라면, django-admin startapp post_service 를 입력해서 처리할 수 있습니다.앱 이름은 post_service로 설정하고…post_service 앱이 실행 된 것을 확인 합니다.만들어진 앱을 settings.py 에 등록해야 django 의 관리하에 사용할 수 있습니다. settings.py 에 INSTALLED_APPS 에 방금 추가한 post_service를 추가하고, rest_framework 와 rest_framework_swagger를 각각 추가하여 REST Api 에도 대응해 봅시다.board 프로젝트의 url 을 설정해 둡시다. 저는 http://server/board/ 로 들어오는 모든 요청을 post_service에 위임하여 처리하려고 합니다. 따라서, url 설정에 post_service.urls 를 include 하게 작성해 봅시다.post_service/urls.py 를 만들어서 urls.py 를 정상적으로 연결 시켜주기 까지 끝냈습니다. 이제 post_service의 urls 만을 관리하여 개발해 나가면 됩니다.
자, 이렇게 기본적인 앱 하나를 실행 했습니다. 그럼 이어서 데이터 모델을 Django 에 맞게 설정해 볼 시간이네요?
post_service 에 models.py 에 들어가, 모델링을 시작해 봅시다. 데이터 모델은 앞에 정의한 대로의 구성으로 진행할 것이며,이런 식으로 구성될 겁니다. 일단, 인덱스는 Django가 기본으로 관리하는 고유키 pk 값을 활용할 것이고, 패스워드는 사용자 인증을 거치는 것으로 ‘게시물 작성자’ 인 경우만 삭제 권한을 줄 것이고, 나머지는 저런 모양으로 일단 만들 겁니다.
그리고 이렇게 모델링을 다 했으면, 이제 migrate 명령을 내려줘야겠죠?
makemigrations 명령으로 마이그레이션 데이터를 먼저 생성 합니다. 이 부분은 Django 1.7.x 이상 버전만 가능하며, 이하 버전은 syncdb 명령을 내려야 한다는 점, 잊지 마세요!마이그레이션 데이터가 만들어 졌다면, 콘솔에 exit 0 으로 종료되는 내용을 볼 수 있습니다.이제 마이그레이션 명령을 내려서….마이그레이션을 완료 합니다. 큰 이슈가 없다면 아래와 같이 exit code 0 으로 종료가 됩니다.
뷰 만들기
이제 기본적인 구성은 끝이 났습니다. 여기까지는 정말 ‘기본’ 인 구성이니, 본격적인 작업은 이제부터 시작이죠. 이제 화면을 구성해 봅시다. 일단, Django framework는 MVC 패턴을 가지고 있습니다. 하지만, 실제로 작업을 해보면 알지만… MVC가 아닌 MTV 구조를 지닙니다. 이게 무슨 소리냐면,
경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다. https://s1004games.com
M – Model
V – View
C – Controller
의 구조가 아니라,
M – Model
T – TemplateV – View
의 구조를 지닙니다. 기존의 MVC와 구조적으로 큰 차이점이 있는 건 아니지만, 개념적으로 차이점을 지니고 있습니다. 이 부분을 굳이 설명해 보자면, Django FAQ 문서를 인용하여 내용을 펼쳐 보면
우리가 해석한 MVC에서는 “view” 는 ‘사용자에게 제공될 데이터를 보는 것’ 을 의미 합니다. ‘데이터가 어떻게 보이는가?’ 에 대한 것은 필요하지 않으며,’어떤 데이터가 보일 것인가?’ 에 집중합니다. 즉, view는 ‘당신이 보는 데이터’ 를 의미하며, ‘당신이 어떻게 보는지’ 를 의미 하지 않습니다. 매우 미묘한 차이죠.
즉, Django 는 MVC 패턴의 각 의미를 다시 해석하여, MTV 라는 구조를 만들어 사용 합니다. MVC 패턴과 차이점은, 관점의 차이라 생각 하시면 됩니다. 지극히 개발자 관점에서 V의 의미를 다시 정의 내렸고, 이는 곧 V가 ‘사용자가 보는 데이터’ 가 아닌 ‘개발자가 보는 데이터’ 의 의미로 정착 시켰습니다. 다시 말해 Django 에서 사용되는 View는 ‘사용자에게 보여질 데이터를 가공하는 단계’ 라 보시면 됩니다. 개발자가 View 를 만드는 것을 View 로 정의 내린 셈 입니다.
설명이 길어 졌는데, 이를 토대로 Django 에서 View를 만들어보도록 합시다.
먼저 View를 구성해 봅시다. Django 에서 View는 ‘어떤 데이터를 보여줄 것인가?’ 에 집중 되어져 있습니다. 다시 말해, 데이터들을 모아서 Template 에 보내주고, 그 결과를 사용자에게 보여주는 역할을 합니다. 한번 해 보죠. 간단하게 post_list 라는 함수를 하나 만듭시다.post_service 앱 내에 templates 라는 폴더를 하나 만듭시다. board 프로젝트에도 templates 가 있으나, 전 관리를 위해서 각 앱들이 별도로 templates를 소유하는 것을 선호 합니다. 취향 입니다. 존중해 주시죠?이름은 post_list.html 파일로 할 겁니다.기본 원형이 생성 되었습니다.뭐가 뭔지 알기 쉽게 하기 위해, 코딩을 하면 늘 하는 Hello World!를 (지겹게) 넣어 보겠습니다.그리고 아까 만들던 View 로 돌아가, post_list 함수를 좀 더 다듬어 봅시다. django.template 패키지에는 다양한 템플릿 관련 메소드 및 클래스가 있습니다. loader 패키지에 포함된 get_template 을 통하여 template 파일을 쉽게 불러올 수 있습니다. template 는 Context 라고 하는 데이터 집합체를 필요로 하는데, Context 에는 다량의 데이터 정보를 포함하여 Template 가 해당 데이터들을 인지하고 출력할 수 있게 준비해주는 역할을 합니다. 일단 코드를 작성하고, 넘어 가 봅시다.post_service 의 url 도 추가하여, 방금 만든 view를 호출하도록 수정 합시다.그리고 서버를 켰….더니 에러가 나네요?? 지금까지 강의를 봐주셔서 감사 합니다…..?!첫번째 실수는 board 프로젝트의 urls.py 에 가보면 바로 나타납니다. 위에 Example 로도 있지만, include 에 포함되어야 할 것은 ‘함수’ 이지, ‘모듈’ 이 아니죠. urls.py 파일은 모듈 파일 이니까요. 따라서 위 예제에도 나와 있듯 문자열로 해당 내용을 전달해 줌으로서, Django가 알아서 뒤지도록 해줘야 합니다.이제 되는가 싶었더니, /board/ 페이지에 Page not found 가 뜨네요. 어라? 뭐가 문제지??두번째 실수는 board 프로젝트 내 urls.py 에 url(r’^board/’ … 라고 작성한게 문제 였습니다. 하위 url은 무조건 board/ 이 후의 내용만 포함해야 되는데… 제가 시작을 / 로 했으니, board// 라고 하지 않는 이상 접근이 될리가 없네요. 따라서 잘못 적용한 url을 수정해 줍시다.신난다!! 오늘 블로그는 여기까지…. 이번에는 SafeText 란 에러가 나왔네요. 뭐지 이놈은….이왕 디버깅을 시작한 거, Break point 도 걸어보고 별 짓을 다 해봅시다!! view 렌더링 시에 난 에러로 보이니, view 에 브레이크를 걸어 봤습니다. 하지만 안타깝게도 Context도, Template도 정상 이더라 이 말입니다.….는 제 실수 였네요. 세번째, View는 응답으로 반환해야 합니다. Template가 렌더링한 내용은 Html 파일, 즉 본문 입니다. HttpResponse 객체로 넘겨줘야 됩니다…. 핳핳성공적으로 렌더링 된 모습입니다!
데이터 넘겨서 출력해 보기
이렇게 Template를 만들고, View 를 출력해 봤습니다. 이거만 봐서는 허전하니까…. 그래도 뭔가 좀 더 해볼까요? Hello ‘Python’ World! 로 바꿔서 출력해 봅시다. 아, 물론 ‘Python’ 은 Context로 데이터를 넘겨 보도록 하구요.
먼저 Template 를 조금 수정해 봅시다. PHP 나 ASP 나 JSP 나…. 그런 애들 처럼, Django 템플릿 엔진도 저렇게 된 문법으로 Template 안에 로직을 첨부할 수 있습니다. {{ }} 로 감싸면, 해당 이름을 가진 데이터를 출력하는 용도로 쓰입니다.View 에서 Context를 수정해 줍시다. Context 에 넘어갈 데이터를 정의해 줍시다. ‘python_word’ 라고 Template 에 정의해 뒀으니, 파이썬 딕셔너리 형태인 { Key : Value } 로 데이터를 넘겨 줍니다.반갑습니다!! 파이썬 월드에 오신것을!
마치며…
간단하다면 간단하게, 게시판 서비스를 위한 기본적인 내용들을 진행해 봤습니다. 이제 남은 건 몇 가지 없죠? 사실 이 정도만 해봐도 기본적인 게시판을 만들기 위한 준비는 다 끝난 셈 입니다. Context로 Model 을 넘겨줘서 잘 뿌리기만 해도 끝이니까요. 하지만 그렇게 할 거면 이 포스팅을 시작하지 않았겠죠? 다음번 포스팅 때는,
– Pagination 을 통하여 Paging 손 쉽게 하기
– Template 안에서 Logic 만들기
– 사용자 권한 부여하기
