[회고] 벗동소 : 벗들의 동아리를 소개합니다!

off_sujin·2022년 7월 5일

project

회고록

목록 보기

2/2

GDSC EWHA에서 만난 팀원들과 개발한 벗동소 프로젝트가 끝났다!
내가 PM을 맡고 프로젝트를 리드하면서 다양한 고민을 했던 프로젝트인 것 같다.
어떤 일들이 있었는지 복기해봅시다.

☘️ About 벗동소

🏄🏻 간단 정리

Why - GDSC EWHA 프로젝트!
What - 이화여대 동아리를 한눈에 볼 수 있는 웹사이트
Who - Front-End : 장아연, 서혜은 / Back-End : 정수진, 이채은
How - 동아리 정보를 수집하고, Spring boot를 이용해서 백엔드 서버를 개발했다!
When - 3개월 (2022년 04월 1일 ~ 2022년 6월 29일)

📖 프로젝트 설명

벗동소 : 벗들의 동아리를 소개합니다!
-> http://www.벗동소.kro.kr

벗동소는 이화여대 동아리를 한눈에 볼 수 있는 웹사이트이다.

간간이 에타에 올라오는 동아리 모집 공고가 아닌 동아리 목록을 보고 싶어요! 라는 글을 보고 이 프로젝트를 구상하게 되었다.
학교 홈페이지, 단과대 홈페이지에 동아리 목록이 있지만 통합되어 있지 않거나 변경 사항이 반영되지 않은 상황을 겪고 다채로운 이화여대 동아리를 한 곳에서 모아 볼 수 있는 웹의 필요성을 느꼈다.

✔️ 구현 기능

공통 기능 (회원/비회원 모두 사용 가능)

메인 화면에서 동아리 리스트 확인 가능 (전체 보기 & 카테고리 분류별 보기)
메인 화면에서 동아리 검색 가능
(검색 결과 없는 경우 404 페이지 보임 - Main 버튼 통해 메인 화면 이동)
특정 동아리 클릭 시 해당 동아리 정보 담긴 세부 페이지로 이동
(동아리 로고, 동아리명, 동아리 카테고리, 동아리 소개, 동아리 모집 여부, 동아리 최신 모집 공고 등)
로그인 여부에 따른 헤더
(로그인 X - 로그인/회원가입/문의, 로그인 O - 좋아요목록/로그아웃/문의)
로그인 :
입력 값의 조건 충족 여부 결과 보여주기
(입력 값이 달라지는 경우 새롭게 조건 충족 여부 확인 결과 보여주기)
모든 입력값이 조건 만족 시에만 로그인 버튼 활성화되어 api 요청 가능
회원가입 :
입력 값과 중복 확인 api 요청 결과에 따른 조건 충족 여부 보여주기
(조건 충족시 해당 입력값 변경 불가능 하도록 input 변경 비활성화)
모든 입력값이 조건 만족 시에만 회원가입 버튼 활성화 되오 api 요청 가능
비회원의 경우 해당 동아리 좋아요 여부(하트 아이콘)이 보여지지 않도록 함
로그인 되어 있지 않은 상태에서 좋아요 페이지 URL을 직접 입력하여도
좋아요 페이지가 아닌 로그인 페이지로 자동 이동

회원 기능 (회원만 이용 가능)

동아리 목록에서 좋아요에 해당하는 동아리는 꽉찬 하트 표시, 아닌 경우 빈하트 표시
좋아요에 해당하는 동아리 모아보는 페이지

⚒️ 사용 기술

Front-End

React(Reac hook, react-router-dom)
styled-component
context API
aws s3

Back-End

Spring Boot
JPA
MySQL
Spring Security
Lombok
Github Actions
AWS EC2, S3, CodeDeploy
Nginx

Communication

github
Jira

🏗 System Architecture

🙋 나의 역할

PM과 백엔드를 맡았다.

PM

데이터 수집을 위한 발버둥

이화여대 동아리의 정보를 수집하기 위해 이화여대동아리연합회 와 연락이 닿았고, 각 동아리에게 직접 정보를 받아야한다는 소식을 들었다..
동아리마다 [정보를 제공해주세요..] 라는 구글폼을 제작해서 각 동아리에 전달된 듯 싶었지만, 구글폼으로 들어온 결과지는 86개 동아리 중 11개에 불과했다 🥲
눈물이 났지만 일단 있는 정보를 DB에 저장하고, 남은 75개의 동아리의 정보들은 학교 홈페이지와 커뮤니티에서 직접 정보를 수집하기로 했다.
하지만 직접 정보를 긁으면서 이게 정보윤리에 맞는 방식인지 의문이 들었고, 정말 많은 시간이 들어서 서버 개발과 병행할 수 없었다.
결국 서버를 다 배포한 뒤에 백엔드 2명이 여기저기 돌아다니며 정보를 수집해보았지만 전체 동아리 정보를 취합하지는 못했다..

Jira를 이용한 협업

스프린트 설정 및 칸반보드를 이용하여 팀원들이 효율적으로 소통할 수 있고, 문서화와 공유가 편리한 Jira를 도입했다.
팀원 모두가 처음 사용해보는 것이었기 때문에(나 포함) 회의시간에 Jira에서 이슈 만드는 법, 칸반보드와 문서 사용법 등을 설명하면서 팀원들이 툴에 익숙해질 수 있도록 했다.
시험기간을 제외한 기간에는 일주일 단위의 스프린트를 진행하고, 매주 금요일 밤 11시에 스프린트 리뷰와 다음 스프린트 계획하는 시간을 가졌다.

프로젝트의 로드맵은 다음과 같다.

매 회의마다 작성한 회의록이나 프론트-백엔드 간 공유해야할 문서들은 Confluence를 활용했다.

백엔드

구현 기능

동아리 전체 조회
동아리 카테고리 조회
회원가입
좋아요

자동 배포 환경 구성

Github Actions workflow 생성
S3 에 jar 파일 업로드
CodeDeploy 생성 및 EC2 연결
Nginx 설정

ERD

API 문서

📚 Postman 링크

⏳ KPT 회고

🚀 Keep

일주일 주기의 스프린트와 리뷰 시간 갖기
- 매주 정기회의 시간에 자신이 개발한 부분과 어려웠던 부분을 말하고, 함께 다음 스프린트를 계획하는 것이 서로의 개발 진행상황을 알 수 있고 이를 토대로 다음 스프린트에 반영할 수 있어서 좋았다.
- 자신이 어려웠던 부분을 서로 공유함으로써 다른 팀원이 해결에 대한 아이디어를 주기도 하고, 정보를 함께 찾아주는 모습을 볼 수 있었다.
- API 문서 같은 경우에도 링크를 공유하면서 띡 보내는 것이 아니라, 단체 회의 시간에 내용을 짚어보면서 서로 이해한 부분이 같은지를 공유한 것이 프론트-백 둘의 기능 구현에 큰 도움이 된 것 같다.
공식 문서를 가까이 하기
- 배포 환경을 설정하면서 다양한 오류를 만났다. 그럼 먼저 구글링을 하게 되는데 왠지 모르게 공식 문서는 최후의 수단으로 남겨두고 싶은 마음이 있었다.
- 하지만 에러 해결의 실마리를 공식 문서를 차근차근 읽으면서 찾는 경험이 쌓이다보니 이제는 오류가 발생했을 때 해당 기술의 공식 문서에 가장 먼저 들어가보게 되었다.
- 정말 공식 문서만큼 확실한 오류 척척박사는 없는 것 같다!

🚨 Problem

EC2 프리티어 인스턴스에서 서버가 갑자기 뻗었다.
프로젝트 초반 팀원들이 Jira를 잘 사용하지 않는 문제가 발생했다.
동아리 DB를 다 채우지 못했다.
- 위에서 언급한 것처럼 구글폼으로 정보를 제공받은 동아리는 DB에 잘 저장해두었지만, 구글폼을 제출하지 않은 동아리는 정보 제공에 동의하지 않은 것이 아닐까라는 의문이 들었다.
- 남은 동아리에 대해서 막무가내로 정보를 긁어모으는 것이 맞는지 고민이 들었고, 서버 개발과 병행해야했기 때문에 점차 뒷순위로 밀리게 되었다.
- 서버를 다 배포하고 나니 그제야 휑한 DB가 눈에 보였고, 같이 백엔드를 개발한 채은이와 시력을 포기하며 정보를 모아보았지만 끝내 포기하게되었다..

💡 Try

EC2 프리티어 인스턴스에서 서버가 갑자기 뻗었다.
- 더 좋은 인스턴스를 사용할 자금이 부족했기 때문에 Swap Memory를 이용해서 최대한 프리티어에서 뻗지 않도록 수정했다.
- 문제를 해결하면서 작성한 글 -> EC2 프리티어에서 뻗은 서버 살리기 - Swap Memory
프로젝트 초반 팀원들이 Jira를 잘 사용하지 않는 문제가 발생했다.
- 나만 Jira를 사용하고 있다는 느낌이 들어서 팀원들에게 물어보니 사용법이 낯설게 느껴져서 잘 쓰지 않게된다는 이야기를 들었다.
- 돌아오는 회의시간에 Jira에서 이슈를 생성하는 방법과 칸반보드로 개발상황을 공유하는 방법, Confluence 사용법 등을 설명하면서 팀원들이 툴에 익숙해질 수 있도록 했다.
- 그 뒤에는 점차 팀원들이 Jira를 사용하기 시작했고, 서로의 개발 상황과 문서를 공유하는 과정이 용이해졌다.
- 팀 리드로서 새로운 툴을 도입할 때에는 사용법을 함께 공유하면서 팀원들이 익숙하게 사용할 수 있도록 도와주어야한다는 것을 깨달았다.
동아리 DB를 다 채우지 못했다.
- 서비스에 많은 정보가 요구될 때에는 프로젝트 기획때부터 DB를 어떻게 채울지를 고민해야겠다..
- ~~근데 이걸 정말 백엔드가 해야하는겁니까!!!!??????~~

💬 느낀점

너무나도 적당한 기간의 프로젝트 기간이어서 팀원들이 프로젝트에 흥미가 떨어지지 않도록하는 것이 가장 큰 고민이었다.
이에 대해 팀원들과 상의해본 결과, 결과물을 직접 보는 것이 우리 팀원들에게는 가장 큰 흥미유발도구라는 것을 파악했고 이를 토대로 프로젝트를 설계했다.
서비스에 가장 기본이 되는 기능을 빠르게 개발해서 먼저 1차 배포를 하고, 수정하고 싶은 부분과 함께 회원의 기능을 넣어서 2차 배포를 하는 식으로 전체 프로젝트를 구성했다.
결과적으로는 마지막까지 팀원들이 재미있게 프로젝트에 임해준 것 같아서 다행이다!
프로젝트를 리드할 때에는 팀원들의 성향을 잘 파악하는 것이 중요하다는 것을 깨달았다.

처음으로 프로젝트 매니저를 맡게 되고, 내가 잘 해야한다는 강박이 있었던 것 같다.
그래서 함께 나누어서 해결할 수 있던 문제도 리드인 내가 해결해야한다는 마음으로 접근했던 일도 있었다.
이번에 한 번 리드를 경험해보니 팀원 간 잘 소통할 수 있는 창구를 만들어주고, 효율적으로 일을 나누어서 빠르게 진행시키는 것 또한 PM의 역할이라는 생각이 들었다.
다음에 PM을 또 맡아서 그 때에는 좀 더 완성도 있는 프로젝트를 만들어보고싶다!

Nginx를 이용해서 무중단 배포 설정하는 과정도 재미있었다.
서버가 배포되는 아키텍처를 구상하고 이를 구현하는 과정까지 해보니까 서비스의 작동 흐름에 대해 알 수 있는 기회가 되었다.
다음에는 다양한 아키텍처를 찾아보고 새롭고 더 효율적인 구조를 짜보고싶다 😊

off_sujin

학습 중..

이전 포스트