[Project/OurWorldcup] release v1.0 리뷰

프로젝트

• Github: https://github.com/dbwp031/OurWorldCup/tree/release/v1.0
• 홈페이지: https://ourworldcup.store
• 기간: 2023.09 (1달)
• 개발 스택: #Java #SpringBoot #SpringBootJpa #MySQL #OAuth2.0 #JWT #AWS

지난 한 달 동안 개발한 "우리끼리 월드컵"을 정리하고 회고하고자 합니다. 뿐 아니라, 이후 어떤 방향으로 프로젝트를 개선해 나갈지 정리하고자 합니다.

ourworldcup.store 메인 페이지

프로젝트 소개

 - 개요

근래 서비스되고 있는 (이상형) 월드컵 서비스들은 사용자들의 선택 기록을 공유하지 못합니다. 자신의 지인들과 월드컵을 플레이하고 각자 어떤 선택을 했는지 비교해보는 것이 진정한 묘미인데 말이죠! 
본 프로젝트는 이 아쉬움을 해결하고자 출시되었습니다.

우리끼리 월드컵만의 특징을 확인해보세요:

• 월드컵에 초대를 받아야만 플레이할 수 있습니다.
• 월드컵 참가자들의 게임 결과를 모두 확인해볼 수 있습니다.
• 우리끼리 월드컵에서 제공하는 재미있는 통계도 확인할 수 있습니다.
  • 나와 가장 유사한 플레이어

프로젝트 회고

- ERD 설계

ERD 설계: release v1.0

개발 전 설계한 ERD와 꽤 다른 모습입니다. [Project: Ourworldcup] ERD 설계하기

당시에는 비즈니스 로직과 가까운 Entity들만 작성되어 있던 모습인 반면, 실제 개발 후의 ERD에는 미처 고려하지 못했던 Uuid, Authority같은 엔티티와 member과 같은 relation table들이 추가된 모습입니다.

 

Uuid 엔티티 같은 경우, 유일하게 관리되어야 하는 객체들을 위해 추가된 엔티티로, S3에 올라가는 ItemImage, Thumbmail 엔티티와 연관되어 있기도 하며, 초대 링크에도 uuid가 사용되어 Invitation엔티티와도 연관되어 있습니다.

 

Authority, Role과 같은 테이블(여기선 DB와 관련된 얘기를 하다보니 테이블이란 단어를 선택했습니다)은 프로젝트 상에서 AuthorityType, RoleType으로 존재하는 객체를 필드로 사용하지 않고, 따로 테이블을 생성한 후, 연관관계 매핑을 해주었습니다. 정규화 관점에서 동일한 AuthorityType이 중복되는 상황이 발생하는 것을 막자는 취지였습니다. 하지만, 개발 이후 불필요한 트랜잭션이 필요한 경우가 종종 등장한 것 같아 이후 개발 시엔 해당 케이스에 대해 좀 더 고민한 후 개발 방향을 결정할 것 같습니다.

 

이렇게 실제로 서비스를 구현해보니, 어떤 엔티티들이 필요한지 더욱 와닿았던 것 같습니다.

- 포스팅

개발을 하면서 얻게 되는 지식을 포스팅하고자 했었습니다. 하지만 몇 번 진행해본 결과, 정리하고자 하는 내용이 코드만으로 표현이 되고, 커밋으로 지식을 정리하는 게 충분하다고 느꼈습니다. 이를 다시 블로그 포스팅으로 옮기는 것은 비효율적이라고 생각해서 블로그 포스팅을 줄이되, 커밋과 주석을 통해 지식을 잘 정리할 수 있도록 했습니다.

 

commit history 중 일부

- Git Flow

프로젝트 초기에는 Github flow를 사용하여 매우 가벼운 브랜치 전략을 사용하여 개발하려고 했습니다. 그러나, 개인 프로젝트를 진행하더라도 저는 경계와 역할이 명확한 기법이 저에게 잘 맞는다는 것을 느껴 이후 Git Flow로 변경하여 개발했습니다.

 

저는 GitKraken이라는 tool을 사용해 Git을 관리하는데 이 툴에서는 Git Flow를 편리하게 도와주는 서비스가 있어 더욱 편리함을 느꼈습니다.

GitKraken 화면

릴리즈 v1.0에서는 develop브랜치에 머지가 성공하면 자동 배포가 되도록 설정되어 있습니다. 최근까지 AWS에서 오하이오 리전에서만 프리티어를 지원하는 줄 알아서, 운영 / 배포 서버를 따로 운영하고 있지 않았습니다. 그러다보니, 굳이 develop서버에서 개발이 완료되면 -> release branch -> main branch로 넘어갈 일이 없었고, 이는 main branch를 운영 서버용으로 쓰는 Git Flow 전략을 충실히 이행하지 못한 것이죠. 이번 릴리즈 이후에 운영 / 배포 서버를 나누고, Git Flow 전략을 좀 더 올바르게 사용하려고 합니다.

 

- 프로젝트 아키텍쳐 구성

프로젝트를 개발하면서 로컬이 아닌 실제 서비스가 배포될 때, 그리고 서비스를 지인들에게 소개할 때 가장 신나고 동기부여가 됩니다. 저는 이번 프로젝트를 시작하면서 우선적으로 1차 배포를 하고, 이후 지속적으로 업데이트 해나가기로 했습니다. 

릴리즈 v1.0 프로젝트 아키텍쳐

현재 프로젝트 아키텍쳐는 위와 같습니다.

Public Subnet에 운영 서버가 돌아가는 EC2를 두었고, Private Subnet에 RDS를 두어 외부에서 접근할 수 없도록 막았습니다. 로드 밸런서를 두어 Reverse Proxy 역할을 수행하도록 하였습니다. 서비스상 이미지를 많이 저장해야 하는데, 이 이미지들은 모두 S3에 저장하도록 해두었습니다.

 

AWS를 구성하면서 프리티어 한도 내에서 구성하다보니 여러 EC2를 생성하지 못한다는 점이 가장 아쉬웠습니다. 또한 운영 서버와 배포 서버를 구분하지 않고 사용하다 보니 실제 현업에서 사용하는 아키텍쳐를 따르지 못한 것 같아 매우 아쉬었습니다. 최근 각 리전마다 프리티어가 따로 제공된다는 것을 알아서, 이후 릴리즈에서는 운영 서버와 배포 서버를 다른 리전으로 구분해서 구성하고자 합니다.

 

- CI/CD 구성

릴리즈 v1.0 CI/CD 파이프라인

현재 develop 브랜치에서 머지가 성공하면 자동 배포가 되도록 설정되어 있습니다. github actions와 AWS Code Deploy, AWS S3를 사용하여 파이프라인을 구축했습니다.

 

- Slack + AWS Lambda + AWS SNS로 배포 성공 알림을 추가한 이유

그런데 배포를 여러번 하면서 github actions가 성공한 후 Code Deploy에서 배포를 완료하기까지 생각보다 시간이 오래걸려서, 배포 직후 웹페이지에 접근이 안되면 이게 아직 배포 중인건지? 아니면 배포가 실패한건지?를 알 길이 없었습니다. 그래서 항상 확인하려면 항상 AWS에 로그인하고 Code Deploy에 들어가서 배포 상태를 확인해야 하는 오버헤드가 발생했습니다. 

 

이 오버헤드를 줄이기 위해 Code Deploy에서 배포가 성공하면 Slack으로 배포 성공 알림이 오도록 해서 오버헤드를 줄일 수 있었습니다.

- 로그인 기능: OAuth2.0 + JWT

KAKAO OAuth2.0을 사용하여 로그인 및 회원가입 기능을 구현했습니다. 또한 이후 로그인시 accessToken 및 refreshToken을 발급하여 사용자의 접근을 관리했습니다. 각 토큰은 JWT로 발급하여 사용자 브라우저 쿠키에 저장하며, refreshToken은 DB에 저장하여 관리했습니다.

- 포함하지 못한 기능들

기존 목표에선 더욱 다양한 기능들이 있었지만, 구현하다 보니 구현 난이도, 시간의 한계 등으로 인해서 추가하지 못한 기능들이 존재합니다. 기존 첫 릴리즈의 목표는 성능이 어느정도 개선된 서비스를 배포하는 것이었지만, 이후에 MVP 구현하여 배포하기로 했습니다.

아래에는 추가하지 못한 기능들입니다. 이후 릴리즈에 포함될 가능성이 높습니다:

• AOP를 활용한 로그인 유무 확인 기능
• AWS Cloud Front을 사용하여 이미지 로드 시간 감소
• AWS Lambda를 사용해 이미지를 작게 리사이즈 한 후 통신
• Redis로 RefreshToken 관리