- 마지막 5주간의 프로젝트 결과물이다. 아래 사진과 같이 도메인으로 서버배포까지 마친 모습이다.
피그마에서 꾸민 기획내용
- 사이트로서의 기능을 하려면 무엇이 필요한가 많이 고민했던 거 같았다.
그래서 기능을 먼저 정리하고 팀원들이 원하는 사항들을 적었었다.
진행하면서 가졌던 목표
- 1차적으로는 부트캠프에서 여러 예비개발자분들과 동고동락하다보니 정이 많이 들어서 1기가 소통할 수 있는 공간을 만들고 싶었다.
- 코드를 짤 때 보여지고 끝이 아닌 리팩토링이 가능한 코드를 작성하고 싶었다.
어려웠던 점들
-
각자 전에 하던 개발방식도 달랐고, git에 올리는 방식(소스트리, git 터미널 등등)도 달랐다. 이거를 통일해서 사용하는데서 소통오류 및 에러가 있었다.
-
RESTFUL API도 짰으며, 모든 회의사항들도 기록하면서 하다보니 생각보다 많은 시간이 소요됐다.
-
글쓰는 부분에서 벨로그나 다른 까페처럼 글을 꾸미는 기능을 넣고자해서 찾아보니 텍스트에디터를 넣어서 기능구현이 가능했는데 ck_editor라는 친구가 form형식이라 커스텀할 때 많이 어려워서 검색을 많이 했던 기억이 있다.
-
마감이 정해져있었는데, 완벽을 추구하자니 모자란 부분이 너무 많았다. 그리고 서버 배포 후에, RDS를 각각의 기능을 합쳐서 적용하는 단계에서 나는 버그들을 픽스하는 때도 어려움이 많았었다.
특히, 서버 배포할 때는 정적파일이 안 적용되서 찾아보니 장고에서는 자동으로 static 파일들을 알아서 찾아쓰지만 다른 환경에서는 static 파일들을 모아줘서 적용시켜줘야된다고 한다. 그래서 s3쪽으로 경로 연결을 해준 뒤 python manage.py collectstatic으로 정적파일들을 s3에 보관해주도록 했다.
좋았던 점들
-
전 프로젝트에서는 장고에 대한 이해가 부족해서 js나 Ajax 통신을 통해 작업을 진행했었다. 그래서 이번에는 내가 맡은 부분은 무조건 장고템플릿으로만 작업을 진행했었다. (경로나 장고내부에서 지원하는 페이지네이션 기능 paginator 등등)
-
제대로 서버 배포를 해본 점. 로드밸런서도 써보고, AWS에 들어가서 VPC도 만져보고 서브넷도 생성해서 라우팅테이블과 연결도 해봤다. 그러면서 아키텍처라는 개념도 배울 수 있었다.
-
RESTFUL API에 대한 이해도가 높아졌다. 그 전에는 API 하면 리모컨 스위치 같은 거 아냐? 버튼 누르면 경로 연결해서 기능 작동하게 해주는 그런거? 정도였는데, 지금은 더 정형화된 메소드 형식에 따른 request,response가 나오는 친구들이 되었다.
작성하는 과정에서 구글링을 통해 알아보니
REST에는 -->> GET POST DELETE PUT ........ 이러한 정해진 형식이 있다.
url path에서는 명사가 들어가야된다.
등등
REST하다는 게 뭔지 배웠다.
추가적으로 url 경로는 타고타고 가야지 이상하게 타면 정상적으로 작동이 안 된다는 것도 에러를 통해 배웠었다.
아쉬운 점들
-
제일 아쉬운게 서버스트레스를 적용 못 해봤다. 계획도 하고 나름대로 유튜브에서 우아한테크에서 얘기하는 서버스트레스적용방법도 보고 그랬는데 마감에 대한 우선순위에 밀려서 못해봐서 아쉬웠다.
-
테스트 코드작성을 많이 못 해본 게 아쉽다. Given, When, Then, Expect.... 내가 처음 작성한 코드는 RDS와 연동되었었는데 테스트코드 기본세팅은 로컬 mysql로 되어있었다. 이러한 문제는 나중에 테스트 코드를 작성하는 과정에서 보았고, 그 당시는 이미 회의에서 우리 팀 전체의 개발이 목표보다 뒤쳐지고 있음을 깨달은 상태였다. 더군다나 새로운 이슈와 기능추가사항들이 생기면서 개발일정이 타이트하다 못해 터지는 상황이 발생하고 있었다. 사실 이 부분은 어려웠던 부분이면서 아쉬운 부분인데, 내가 시간이 많이 걸려서 어려웠다고 했던 계획짜기와 회의시간 덕에 문제들을 픽스해나가며 프로젝트를 마무리 할 수 있었다. 테스트코드와 디버깅을 제대로 많이 못해본 점이 아쉽다. 아직은 프린트나 console.log()로 찍어서 실물을 보는 게 익숙한 게 사실이다.
추후에는 테스트 코드와 디버깅을 중점적으로 개발을 하고싶다. -
프론트를 만지는 시간이 너무 많았다. 기능들을 합치고 처음으로 서버를 돌릴 때 모바일 반응형 및 미디어쿼리를 만질 수 있는 팀원이 없다보니 내가 만져야했다. 사실 내가 만들어보고 싶었던 기능도 있었고, 프론트 만질 시간에 다른 거를 하고싶었지만 사용자가 보기에 불편하면 이용조차 하지않는 요즘 기본이상의 ui,ux는 만들어야겠다는 생각에 만들어진 틀에서 픽스를 했었다.
-
API설계 당시 종속성에 대한 고려를 안 했다. 예를들어 user가 있어야 우리가 게시글작성도 되고, 좋아요나 북마크 기능을 만들 수 있다. 그러면 user에 대한 모델이 먼저 만들어져야 개발이 되는데 당시 각자 기능별로 나누자해서 생각없이 A는 유저 / B는 북마크,좋아요 / C는 게시판을 만들었다.
유저기능 담당자가 당시 코로나에 걸려서 개발이 뒤쳐졌고, user 없이 기능개발을 하다보니 다른 파트들에서도 어려움이 있었다. 임시로 user모델을 각자 app에서 만들어서 진행을 했으나 합칠 때도 오류가 생겨서 전체적인 코드리뷰후에 뜯어고치는 작업을 했던 기억이 있다.
추후 계획
- 프로젝트를 계속 이끌어나가면서 서비스 운영에대한 경험을 가지기로 팀 내부적으로 합의를 봤다. 물론 이 프로젝트에만 매달리는 게 아니라 각자의 길을 걸으면서 더 나아가는 공부를 하자는 의미였다.
- 우선은 취업준비와 더불어 남는 시간에는 추가하고 싶은 기능 + 피드백 받았는데 다 못적용한 부분을 개선하고 싶다.
