[Project] OurSpace

임종성·2021년 8월 28일
3

Project

목록 보기
7/7
post-thumbnail

1차 프로젝트가 끝나고, SpaceCloud 모티브의 웹사이트를 개발하는 그룹 프로젝트를 새롭게 진행했다. 새로운 팀원들과 함께했던 지난 2주간의 프로젝트의 과정과 결과, 그리고 회고를 담아보았다.

OurSpace

SpaceCloud Motive Project

[Project Schedule]

  • 2021/08/16 ~ 2021/08/27

[Project Member]

  • Frontend - 심택준, 이수정, 이현준, 최호정,
  • Backend - 임종성, 장이주

[Project Github Link]

[Project Video Link]
https://www.youtube.com/watch?v=8b4LgFIEaCk

Personal Goal

그룹 프로젝트이기에 팀의 목표, 즉 제대로 기능이 구현되는 웹 사이트를 개발하는 것이 가장 중요하다. 그러나 개인의 목표를 세우고 달성하는 것 또한 중요하다. OurSpace 프로젝트를 시작하기 전, 이전 프로젝트를 진행하면서 부족하다고 생각했던 것과 이번 프로젝트에서 내가 중점적으로 달성하고 싶은 목표를 설정해봤다.

1. Git Flow를 명확히 이해하고 Git Squash, Rebase를 활용하여 Commit을 관리한다.
2. Trello 티켓의 기능을 세분화하고 구현할 기능을 명확히하여 관리한다.
3. 구현할 기능에 대해 Front와 적극적으로 소통한다.
4. AWS S3와 RDS를 활용하여 파일과 DB를 관리한다.
5. AWS EC2, Docker를 사용해 개발된 환경을 배포해본다.

Project Process

프로젝트 첫 날, 팀원들과 함께 모여 사이트를 둘러보고 Sprint Meeting을 진행했다. 사전스터디를 함께했던 택준님이 PM을 맡으시고 1차 프로젝트를 같이 진행한 호정님이 계셔서 마음이 편했다. 확실히 프로젝트 경험이 도움이 되었는지, 1차 프로젝트와 달리 웹사이트를 보고 대략적인 Web Flow와 구현해야 할 기능들이 어느정도 감이 잡혔다.

[초기 계획 필수 구현사항]

  • 카카오 API를 활용한 소셜로그인/회원가입
  • 공간 필터링 API
  • 공간 등록 API
  • 공간 예약 API
  • 공간 사용후기 API
  • 공간 상세정보 API

[초기 계획 추가 구현사항]

  • 검색어 활용 API
  • 찜하기 기능
  • 마이페이지(Q&A) API
  • 공간 예약 조회 API
  • 공간 결제 API

Database Modeling


백엔드 파트너인 이주님과 함께 ERD를 작성했다. SpaceCloud를 둘러보고 우리가 2주동안 구현 가능하도록 Modeling을 했다. 크게 수정한 내용들을 살펴보면,

  • Space 예약 Option을 시간별로 하지 않고 Day, Night, All의 세가지로 구분했다.
  • District 부분을 세분화하지 않고 서울의 강남, 강북, 강서, 강동으로 나누었다.
  • Category는 세분화하지 않고 8종류로 축소했다.

Filtering Spaces View

지역, 공간유형, 예약 가능한 날짜, 인원수로 공간들을 필터링하는 API를 구현했다.

단순히 Filter Query를 사용하는 것이 아니라 Q()를 적극적으로 활용하여 Filtering을 하려고 노력했다. 코드를 작성하는 과정에서 date로 필터링하는 것이 가장 어려웠는데, optionall이거나 day, night둘다 존재할 경우를 생각해야 했다.

day, night 둘 다 존재할 경우는 filter query를 두번 사용하면 가능했지만, 거기서 exclude를 사용해도 내가 생각한대로 QuerySet이 나오지 않았다. 그래서 결국 특정 dateorder 개수가 2개인 경우를 제외하는 query를 작성하여 해결했다. 이 부분은 옵션이 all, day, night인 특정 경우에만 가능한 것이고 일반적으로는 해결되는 방법이 아니기에 refactoring이 필요한 것 같다.

Unit Test

Unit Test를 활용하여 내가 구현한 기능을 상황에 따라 평가해봤다.

2차 프로젝트와 이전 프로젝트와 가장 다른 점은 모든 기능을 구현할 때 Unit Test를 작성해야 한다는 점이다. Unit Test는 내가 작성한 기능의 가장 작은 단위인 함수를 테스트하는 방식으로, POSTMAN이 Client와 Server가 결합하여 Test하는 Integration Test보다 실행시간이 빠르고 비용이 싸다.

실제로 내가 구현한 ProductsView의 Unit Test를 작성하고 나머지 기능도 모두 Unit Test를 작성하고 통과했다.

Django ORM Optimization

Query Debugger와 Logging을 활용해 API의 성능을 분석하고 최적화했다.

프로젝트 진행 중 Django ORM의 특징과 작동원리를 파악하고 ORM 최적화와 관련된 세션을 수강했다. 2차 프로젝트는 기능 구현 능력보다는 새로운 기술 스택을 적용하고 기본 역량을 탄탄히 하는 것이 중요하다고 느꼈다. 따라서 구현한 기능에서 실행되는 Query 개수와 실행 속도를 분석하고 최적화하기 위해 노력했다.

실제로 내가 구현한 ProductsView에서 발생하는 N+1 Problem을 해결하기 위해 Eager Loading을 적용하고 성능을 최적화했고, 나머지 모든 기능에 대해서도 Query 최적화를 수행했다.

Before Optimization

After Optimization

Space Reservation API

Date, Count(인원수), Option을 요청받아 공간 예약 정보를 저장하고 결제 페이지에서 필요한 정보를 반환하는 API를 구현했다.

공간의 예약, 결제 상태를 구분하기 위해 OrderStatus Table을 따로 생성하여 관리했다. 초기 API 기능 구현 단계에서는 공간 상세 페이지에서 예약버튼을 누르면 date, option, count를 요청해 정보를 저장하는 API와 결제 페이지에서 표출해야 할 정보를 불러오는 API로 나누어 구현했다. 그러나 예약버튼을 눌러 정보를 저장하는 동시에 반환한 Data로 Frontend가 다음 페이지에서 정보를 표출할 수 있도록 API를 합치게 되었다.

Space Review API

이미지, 평점, 글을 작성하여 공간 등록 후기를 등록할 수 있는 API를 구현했다.

1차 프로젝트에서는 Form Data로 Image File을 요청받고, Django Static을 활용해 Local에 파일을 저장하여 관리했다. 하지만 이번에는 AWS S3를 활용해 파일을 업로드하여 관리할 수 있도록 했다.

Review API 뿐 아니라 Space Registration API에서도 이미지 파일을 등록하기 때문에 범용적으로 활용하기 위해 S3Client Class를 작성했다.

AWS EC2 & Docker

AWS EC2 Server에 Docker Image를 실행시켜 Container를 띄우고 Application을 배포했다.

이전 프로젝트에서는 AWS EC2 Server에 우리가 개발했던 Project를 Git을 활용해 Pull하여 RDS와 연동해 배포하고자 했지만 시간관계상 그러지 못했다. 그러나 이번에는 기능을 구현함에 있어 프론트와 속도를 맞추고 조율하여 배포를 하는 것을 목표로 했다.

특히 Docker라는 개념을 배우고 멘토님들이 Docker의 중요성을 강조하셨는데, 개념을 이해하려고 노력해도 너무 생소하고 어려웠다. 그래서 많은 시간을 Docker 공부에 투자했고, 결과적으로 EC2 서버에서 Docker image를 이용하여 배포하는 것에 성공하고 최종발표 때 시연과 동영상 제작 또한 Docker로 배포한 것을 활용했다!

Docker 배포 관련 자세한 내용은 따로 블로깅을 할 예정이다.

End of Project

[필수 구현사항]

  • 카카오 API를 활용한 소셜로그인/회원가입
  • 공간 필터링 API
  • 공간 등록 API
  • 공간 예약 API
  • 공간 사용후기 API
  • 공간 상세정보 API

[추가 구현사항]

  • 검색어 활용 API
  • 찜하기 기능
  • 마이페이지(Q&A) API
  • 공간 예약 조회 API
  • 공간 결제 API

1, 2차 스프린트를 마치고 구현한 사항을 확인해 보니, 생각보다 많은 기능이 구현되지 못한 것을 알 수 있었다. 사실 임시공휴일로 인해 프로젝트를 하루 늦게 시작하고, 많은 기능 구현보다는 완성도 높은 기능 구현에 집중했기에 당연한 결과였다.

팀원들도 처음 기획한 기능들을 모두 구현할 수 없음을 인지하고, 상황에 맞게 기획을 조정하여 업무를 배분했다. 그 과정에서 PM인 택준님의 역할이 컸고, 성공적으로 프로젝트를 마칠 수 있었다.

Checklist를 활용해 프로젝트의 목표를 이해하고 달성했는지 확인해보자.

Scrum


개인적인 목표 설정에도 있었지만, 1차 프로젝트 때 Trello를 제대로 활용하지 못했기에 이번에는 구현할 기능을 좀 더 세분화하고 정리하여 잘 관리하고 싶은 욕심이 있었다. 프로젝트 초기에는 나름 열심히 트렐로를 작성하고 API 정의서와 Meeting Log를 활용했다. 하지만 후반에는 어느정도 트렐로를 안봐도 정리가 되고 소통을 직접 하다보니 좀 해이해진 면이 있었던 것 같다. 돌아보면 정리할 내용에 대한 공유와 피드백이 있는 순간마다 트렐로를 활용하는 습관을 들였어야 하는 것 같다.

Communication

이전 프로젝트에서 소통이 너무 부족했다고 느꼈고, 그 피드백으로 이번 프로젝트에서는 적극적으로 프론트와 소통하려고 노력했다. 또한 백엔드 파트너인 이주님과 기능구현을 제대로 분업하는 반면 적극적으로 소통내용을 공유하여 효율적으로 프로젝트를 진행할 수 있었다.

GIT

마찬가지로 이전에 Git을 제대로 활용하지 못했다고 생각했기에 이번 프로젝트에서는 Git Flow를 제대로 이해하고 squash, rebase와 같은 명령어를 정확히 활용하려고 노력했다. Branch마다 Commit이 1개가 되도록 꼼꼼히 확인하고, Conflict가 발생해도 차근차근 해결하다 보니 큰 issue 없이 프로젝트를 마쳤다.

Unit Test

이전 프로젝트에서 팀원과 함께 많은 기능을 구현하고 배운 개념을 적용했다면, 이번에는 Git Rebase, Unit Test, ORM 최적화와 같이 새로운 기술을 바로 적용하는 프로젝트엿다. 모든 기능에 대해 Unit Test를 작성하다 보니 당연히 진행속도가 더뎌질 수 밖에 없었지만, 기초를 탄탄히 한다는 느낌이 강하게 들었다. 또한 TDD를 현업에서 적용하기 위해 익숙해지는 과정이라고 생각하고 최대한 꼼꼼하게 Test를 수행할 수 있도록 노력했다.

Docker

이번 프로젝트에서 가장 중요하다고 느꼈던 개념이 바로 Docker이다. 실제 대부분의 개발 환경에서 Docker를 이용해 서비스를 배포하고, 개발자로서 가져야 할 기본적인 역량 중 하나라고 생각하여 Docker 개념을 이해하고 배포하는 데 시간을 꽤 많이 투자했다.

사실 Docker로 프로젝트를 배포하는 것은 팀의 필수적인 목표라기 보단 개인적인 목표이기에 최대한 전체적인 팀의 목표에 지장이 없도록 노력했고, 자기 전에 조금씩 시간투자하여 배포에 성공했다.


1차 프로젝트 때도 시간이 빨리 갔지만, 이번에는 정말 빨리 지나간 것 같다. 생각해보면 2차 프로젝트는 여러가지 이슈가 존재했다. 임시공휴일로 하루 늦게 시작한 것, 다음주부터 시작하는 기업협업 관련된 이슈, ImageField를 URLField로 바꾸는 등 크고작은 Blocker들...

여러가지 정신이 없는 와중에, 이번에도 아주 성공적으로 프로젝트를 끝마쳤다. 최종발표 때도 언급했지만, 팀원 모두가 힘들고 스트레스를 받음에도 내색하지 않고 서로를 배려하면서 좋은 팀 분위기를 생성했기에 좋은 결과가 나왔음이 틀림없다.

PM으로서 프로젝트를 이끌고 조화로운 팀 분위기를 만들며 본받고 싶은 택준님

1, 2차 프로젝트를 함께하며 서버에 가장 많은 요청을 보낸 호정님

자신이 맡은 기능에 책임감을 가지고 어떻게든 해결하려는 모습이 너무 보기 좋았던 수정님

앞으로도 기업협업으로 한 달 함께할, CSS를 잘 다루고 습득력이 좋은 현준님

그리고 백엔드 파트너로서 가장 많은 소통을 하고, 정말 힘들었을텐데도 불구하고 제 역할을 다 하기위해 노력하고 모든 걸 해내신 우리 이주님

모든 팀원들이 너무도 제 역할을 잘 해주시고, 배려해주시고, 소통하려는 모습이 눈에 잘 보였다. 괜히 위코드의 동기사랑이라는 말이 있는 게 아닌 것 같다.

나는 어떤 개발자이고, 어떤 팀원이었을까? 프로젝트를 하다보면 여러 이슈로 인해 사람들이 불편해하고, 불안해하는 모습을 볼 수 있었다. 그럴 때 나는 나와 함께 함으로서 그런 불안함을 없애고, 팀원의 마음이 조금 편해졌으면 한다. 내가 같은 팀이라면 괜찮다는 믿음을 주고 팀으로서 함께 하고 싶은 사람이 되고 싶다. 앞으로도 동기들과 좋은 관계를 유지하고 서로를 도와주며, 개발자로서 함께 길을 걷고 싶다.

profile
어디를 가든 마음을 다해 가자

0개의 댓글