4개월여의 프로젝트 끝...!

SamSim·2022년 3월 27일
2

Django

목록 보기
2/2
post-thumbnail

11월에 시작했던 IT대학 사물함 예약 웹사이트 프로젝트가 끝났다. 이번주에 실제로 it대학 재학생들을 대상으로 신청을 진행했고, 큰 문제없이 신청을 진행할 수 있었다. 이번 프로젝트를 하면서 느꼈던 점, 배운 점을 정리해보고 개선할 점을 찾아보려한다.

프로젝트 진행과정,배운것

이 프로젝트의 시작과정이나 이유는 이전에 올렸던 https://velog.io/@makemyway-kr/Django-%EA%B1%B8%EC%9D%8C%EB%A7%88 게시물에 적어놓았으니 생략하도록 한다. Django 자체에 대해서도 많이 배웠지만, 여타 기술적인 것들은 충분히 django 홈페이지나 stackoverflow를 통해서도 찾아볼 수 있으니 외적으로 배운것을 말해보자면,

1."단"을 나눠야한다.

프로젝트를 진행하면서 웹 서버라는 것은 단순히 템플릿을 라우팅해주고, 디비에서 정보를 끌어오는 "기본적인" 역할만 하도록 단순히 설계해서는 안된다는 것을 배웠다. django에서 기본적으로 model을 지원해주기는 하지만, api / middleware / view를 나눠서 모듈을 설계하고 이 모듈들이 서로 동적으로 자료를 주고받으며 복잡도를 낮추고 무엇보다 코드 재사용률을 높여서 유지보수를 편하게 해야한다는 것을 깊게 깨달은것 같다. 초기에는 view파일 한곳에다가 모든 페이지에 필요한 코드를(model에서 정보 끌어와서, 처리하고, 보여주는 일련의 과정과 더불어 로그인,로그아웃 등등 모든 것을 각각의 함수에다가 한곳에 모두 때려박았었다). 당연히 이렇게 하니까 개발 속도도 느리고, 서버에서 오류가 나도 어디에 있는지 찾기도 힘들 뿐더러 느리기까지 했다. 그래서 최대한 서버의 "단"을 나누고 각각의 기능별로 모듈을 나누는 과정을 거쳤고 프론트에서 그때그때 url을 통해 요청하여 처리하도록 하는 편이 응답도 빠르고, 유지보수에도 좋음을 깨달았다. 어찌보면 당연한 이야기지만 난 그 당연한 이야기를 듣지 않았었고 몸소 깨달았다. 괜히 나누라고 하는게 아님을.

2.어떻게 "웹 서버"가 동작하는지, 관리는 어떻게 해야하는지 알게 되었다.(드디어 실제로 배포와 서비스를 해보았다😍)

NGINX(웹서버)는 혼자서 django와 연결하고 소통하지 못한다. WSGI(web server gateway interface)라는 애가 있어야 비로소 역할을 할 수 있다. NGINX가 static file들을 전달해주고 그 안에 들어갈 동적인 내용들은 wsgi를 통해 django was가 전달해준다. 지금은 다음 프로젝트를 위해 Spring을 공부중인데, Spring의 구조는 또 다르더라. 웹 서버의 구조라는 것은 프레임워크마다 상이한것 같은데 더 많은 공부가 필요한듯하다 이부분은.
하지만 django app을 EC2서버에 올리고, Nginx와 gunicorn을 붙여 호스팅을 하며 Route53을 통해 DNS설정을 해줘 비로소 이용자들이 내가 만든 서버에 접속하는 경험은 서버의 설치부터 관리까지(Nginx의 process 및 worker수의 조정, gunicorn의 worker조정을 통한 서버 "터짐" 방지) 해볼 수 있게 해주었다. 특히 이번 프로젝트는 동시 접속자 수가 다수 발생해서 시작 전에 염려되는 부분이 많았지만 사고는 나지 않았으니 잘했다고 자평하는 중이다.

3. 웹 서버에서의 "세션"

세션이라는 개념을 전공수업시간에 배웠지만 실제로 웹 서버에 이걸 어떻게 넣는 건지 전혀 몰랐다. 이번 프로젝트를 통해서 동시접속자 제한 기능을 넣어야 했고, 이 기능을 구현하는 과정에서 각 유저의 세션을 저장하고, 제한시간을 설정하며 유효한 세션이 있는 사람이 로그인하면 이 세션을 삭제해 강제로 로그아웃 시키는 기능을 넣었고, 물론 내 자신이 100%코드를 작성하지는 않았지만 다른이의 코드를 보고 분석해보며 어떻게 세션을 관리하는지, 세션의 생성부터 관리 삭제를 어떻게 코드로 구현할 수 있는지 배울 수 있었다.

4. 전공수업은 괜히 배우는게 아니다.


이번 프로젝트를 하면서 설계한 DB의 ER다이어그램중 일부이다. 위와 같이 디비를 설계하고, 기본 서버 구조와 각종 보안(비밀번호 처리 등등), 통신에 있어서 전공수업때 배운 컴퓨터네트워크 , 데이터베이스, 통신 , 정보보안 등의 과목들이 큰 도움이 됐다. 전공수업은 들을 때는 이걸 어디다가 써? 하지만 굉장히 중요한 것임을 깨닫게 되었다.

5. 개발일지는 필수다.

개발을 진행하면서, 팀원 모두가 노션을 통해서 개발일지를 남겼다. 개발일지를 남김으로써 개발 과정 중에 "저번에 뭐했더라?"하는 문제의 해결, 팀원간의 작업 현황 공유, 버그 리포트 , 팀원 자신의 개발 과정에 있어서 기록을 남겨 추후에 스스로의 발전을 위해 활용할 수 있었다. 개발일지 문화는 팀의 개발과 개개인의 성장에 있어 큰 도움이 되었고 앞으로도 이렇게 하려 한다.

개선할 점

1.프론트 , 클라이언트와의 소통

이번 프로젝트를 하면서 가장 크게 느낀 것은 'API문서'가 왜 필요한지이다. 이번 프로젝트의 각 페이지에 필요한 데이터의 수가 많은만큼 프론트와 백 사이에 활용해야할 API의 수가 많아진건 당연했다. 하지만 각 API의 request / respond형식, 주소 등을 그때그때 알려주려면 프론트 개발자들이나 나나 모두 코드를 찾아봐야하고 번거로운일이 아닐 수 없었다. 다음 프로젝트부터는 익히본 swagger같은 툴을 이용해서 api문서를 만들고 이를 통해 공유해서 개발 과정의 소통을 원할하게 해볼까 한다.

2. 어 이게 왜 안돼

사이트 메인 화면에는 "남은 사물함 수"와 학부별 신청 날짜 및 시간이 나타난다. django template rendering을 통해서 띄워주도록 하였는데 이게 admin페이지에서 날짜를 갱신하고, 학생들이 신청을 해도 갱신되지를 않았다. (테스트 서버에서는 정상적으로 바뀌었지만). 이 버그를 해결하고 만약 rendering해주는 방식의 문제라면 django에서 동적으로 fetch가 어떻게 이루어져야하는지 알아봐야할 것 같다.

3. 클라이언트(?)와의 소통.

사실 좋은 뜻으로 시작한 프로젝트지만, 배포 전 단계에서 너무나도 갈등이 많았다. 개발 과정에서 학생회측의 요구사항이나 이런것들을 들은 바 없어서 팀 내부에서 디자인부터 기능까지 선정하고 개발을 했었는데, 개발 완료 후 갑작스럽게 거의 갈아엎다시피(?) 해야하는 수정요구를 대뜸 배포 직전에 내놓아서, 우리 팀 모두 당황한 바 있다. (심지어 돈 안받고 자원봉사 수준으로 한 프로젝트다) 어쨌던 간에, 다음 프로젝트도 그렇고 프로젝트를 기획하고 개발하는 과정에서 타겟으로 생각하는 클라이언트와 인터뷰도 해보고, 의견을 수렴하고 수정하는 과정을 거칠 필요가 있어 보였다.

4. 개발 기간 관리

개발하면서, 각자 일도 있고 학교도 다녀야하고 하다보니 개발 일정이 생각보다 늘어진 면이 있다. 저번 프로젝트보다는 훨~씬 짧은 기간동안 잘 해내었지만, 여전히 내 생각보다는 그렇지 않은 면이 있어서 이번 정보처리기사 시험공부를 하면서 배운 "애자일 방법론"과 "나선형 모델"등 개발 모델을 참조해서 정석적으로 개발 기간을 관리해보고 과정을 더욱 매끄럽게 해보고 싶다.

Thanks to

프로젝트를 함께한 수호, 중간에 갑작스럽게 함께해달라 했는데 흔쾌히 참여해준 수민이 너무 고맙다🥳 다음 프로젝트도 화이팅!!!! TEAM MAT
아 그리고 프로젝트 기간동안 멘탈케어를 해준 준식이형에게도 땡큐

profile
개발새발

0개의 댓글