Quick-Book 프로젝트 회고

박윤택·2022년 10월 14일
0

회고

목록 보기
1/2

아이디어 선정

[2022.09.07 ~ 2022.10.12] 기간 동안 진행해야할 프로젝트를 진행하는데 있어서 미리 팀원분들과 아이디어를 공유하였다.
제시된 아이디어는 다음과 같았다.

1. 헬스장, 식당 QR 코드 대기 서비스
2. 삼일 작심 - 목표를 달성하여 포인트를 적립
3. 코여정 - 각 나라의 코로나 정보를 가져와 한번에 모든 정보를 확인
4. 밴드 모임 사이트 - 악기 중고 거래, 밴드 모임
5. 부동산 중고 거래 사이트 - 3차원 방 뷰어 도입
6. 원룸, 빌라형 주택 공동 관리 서비스
7. 운동인 - 집 근처 헬스장 정보들 게시판
8. 오늘의 옷차림 - cctv 데이터를 활용한 실시간 바깥 날씨에 따른 옷차림 확인

그 중 다른 아이디어들은 큰 틀이 게시판인 것에 비해 1번인 QR 코드 예약 대기 서비스는 관리자 페이지, 사용자 페이지 두 개를 만들 수 있었기 때문에 신선하기도 했고 팀원이 프론트 4분, 백엔드 2분이었기에 감당할 수 있는 프로젝트라 생각이 들었다.

투표를 통해 내가 제시 했던 QR 코드 예약 대기 서비스를 프로젝트 주제로 선정되고 빠르게 Figma를 이용하여 와이어 프레임을 만들었다. 디테일한 부분들은 프론트 분들이 디자인과 함께 잡아주셨다.

초기 와이어 프레임

와이어 프레임을 기준으로 사용자 정의요구서를 작성하였다.

사용자 정의요구서

중간에 기획적인 부분이 변경되었다... 범용적인 QR 코드 서비스가 아닌 매장에 국한한 서비스로 방향을 잡고 작업했던 내용들을 조금씩 수정하였다.

다음으로 요구사항 정의서를 기준으로 어떤 데이터가 필요할지에 대한 정립이 필요했다. 크게 Entity들을 나누고 필요한 데이터 칼럼들을 구글 스프레드 시트에 나열하고 ERD Diagram과 테이블 정의서를 작성했다.

ERD Diagram

테이블 정의서

ERD Diagram과 테이블 정의서는 프론트엔드 시안이 중간에 바뀜에 따라 조금 변경되었다. 초기 테이블 설계와 비교를 한다면 매장 테이블(BUSINESS), 리뷰 테이블(REVIEW), 메뉴 테이블(MENU)이 추가되었다.

  • 연관관계 매핑
    회원(MEMBER) - 매장(BUSINESS) -> 1 : 1
    매장(BUSINESS) - 리뷰(REVIEW) -> 1 : N
    매장(BUSINESS) - 메뉴(MENU) -> 1 : N
    매장(BUSINESS) - QR 코드(QR_CODE) -> 1 : N
    QR 코드(QR_CODE) - 예약(RESERVATION) -> 1 : N
    QR 코드(QR_CODE) - 식자제(KEEP) -> 1 : N

아쉬웠던 점은 연관 관계를 매핑함에 있어서 복잡한 N : M의 관계가 생성되지 않았다. 서비스를 확장한다면 태그 테이블을 생성해서 매장과 연결시켜 매장의 키워드를 넣어 줄 수 있을 것 같다.


개발

개발을 시작하면서 팀원분들에게 git flow와 git convention에 대해 설명드렸다. 그리고 프로젝트 폴더 구조를 나누고 spring boot 기반 프로젝트를 시작하였다.

유일한 전공자이기도, 경험자이기도 하였기에 프론트 프로젝트에 .env 파일이나 폴더 구조를 조금 잡아 드렸다.

업무 분담

백엔드 프로젝트에서는 함께 하시던 분께서 코드를 작성하는 거에 있어서 낯설어 하셨기에 Member Entity를 제외한 다른 Entity간의 연관 관계 매핑 작업을 부탁드리고 함께 잘못된 부분을 개선해나갔다.

4주라는 긴박한 시간동안 프론트 분들에게 빨리 API를 전달해드려야 했기 때문에 메인 업무는 주로 내가 담당하고 추후에 서비스 확장을 고려하여 자제 관리 API 작업을 부탁드렸다.

개발을 하면서 프론트 분들로부터 에러가 있어 같이 보고 해결하기도 하고, 구현하는데 있어서 방향성을 제시하기도 했다.

혼자 너무 바쁜것 같은 느낌이 들었다...


회원 가입

회원 관련 API를 구현하면서 OAuth2와 메일 인증을 고려하였다.
구현함에 있어서 일반 회원가입에 있어서 메일인증 절차에 대해 고민을 하였다. 먼저 구현을 해놓고 스스로 생각하기에 합당하다고 생각했지만 더 나은 방법이 있을지 멘토님께 질문 드렸다.

말마는 멘토님께 질문

-> 로직적으로 큰 문제 없어 보인다, 이대로 진행해도 될듯 하다"

마찬가지로 OAuth2의 경우 최초 로그인 시에 추가 정보를 기입해야 하는 로직에 대해서도 질문 드렸다.

말마는 멘토님께 질문

-> 이 또한 로직적으로 문제 없어 보인다."


Spring Batch 적용

기획 단계에서 고려했던 QR 코드 만료일자에 따른 알림 메시지를 사용자에게 전달하는 기능을 구현하는데 있어서 자동으로 작업을 처리해주는 게 없을까 찾아보다가 Spring Batch를 알게 되었다.

"Spring Batch만으로 배치 처리를 진행할 수 없고 스케줄러가 함께 동작되어야 한다."

Spring Batch에서 Job은 여러가지 Step의 모음으로 구성되어 있고 순차적으로 Step을 수행한다. Step은 Tasklet 처리 방식과 Chunk 처리 방식이 있다. Tasklet 처리 방식은 하나라도 실패하면 모두 실패하고 Chunk 처리 방식은 몇 개씩 끊어서 처리를 한다.

Chunk 지향방식으로 Batch를 구현하였고 QR 코드 만료 하루 전날, 만료일에 메일을 전송하고 만료일에 QR 코드를 삭제하는 로직을 짰다.

Quartz를 이용하여 스케쥴러를 구현하는데 있어 매일 자정에 배치 작업을 처리할 수 있도록 하였다.

Step이 단순하였기에 여러 블로그를 보면서 코드를 작성하는 건 크게 문제가 없었지만 정의나 용어에 대한 정리가 필요하다. 이는 추후에 블로깅 하기로...

참고 : Spring Batch


케시 레이어 적용

반복적으로 자주 사용되는 데이터에 대하여 읽기 전용 케시 레이어를 사용해보기로 하였다.
현재 로그인한 사용자의 정보/예약 리스트/매장 존재 여부의 서비스 로직에 읽기 전용 케시레이어를 적용하였다. 서비스 계층에서 케시를 적용하는데 있어 크게 두가지 문제가 있었다.

1. 메서드 레벨에 적용할 때 redis에 케시 데이터가 들어가지 않는 문제

그 이유는 한 클래스 내부에 케시 관련 어노테이션을 붙인 메서드가 다른 메서드에서 호출된다면 케시가 적용되지 않는다.

2. 케시에 읽기 전용으로 쓸 데이터가 제대로 들어가지 않는 문제
default 생성자가 없을 경우 default 생성자를 추가한다.
케시에 등록하고 싶지 않은 변수에 대해서는 @JsonProperty(access = JsonProperty.Access.WRITE_ONLY) 어노테이션을 추가한다.
예약리스트의 경우 변경 사항이 있을때 @CacheEvict 어노테이션을 이용하여 케시를 삭제하여 케시 데이터와 DB 데이터를 동기화를 한다.

케시 레이어 적용에 대해서도 좀 더 공부하고 블로깅을 하자!!


AWS 세팅

https를 등록하기 위해서는 DNS가 필요하여 Freenom에서 무료 도메인을 발급받고 ACM에 등록하였다. 등록된 SSL 인증서를 CloudFront와 ELB에 적용시켜 프론트/백엔드 서버에 https를 적용시켰다.

AWS를 세팅하면서 제일 중요하게 다가왔던게 보안그룹의 중요성이었다. 같은 VPC 내에서 인바운드 규칙을 잘 설정하여 사용하고자 하는 인스턴스들끼리 연결을 제대로 되도록 설정해야 했다.

ec2 freetier에서 제공되는 인스턴스는 메모리가 1GB 밖에 되지 않아 빌드가 되지 않아 한참 헤매었다. 메모리를 조금이나마 더 확보하는 방법은 Swap 공간을 생성하여 EBS의 일정 영역을 끌어와 메모리로 사용하는 것이다.


참고 : AWS EC2 프리티어에서 메모리 부족현상 해결방법

AWS Architecure

프론트엔드는 S3에 빌드된 파일을 배포하고 EC2에 백엔드 배포를 하였다. ElastiCache(redis)를 이용하여 refresh token, 케시 레이어를 관리하고 RDS는 MySQL을 사용하였다. Route53에서 발급받은 도메인을 등록하고 SSL 인증서를 CloudFront와 ELB에 적용시켰다.


총평

Spring Boot 기반 첫 프로젝트를 마무리하는 과정에서 처음 시도해보는 것들을 많이 적용해보았다. 개념적인 부분에 있어서는 한번 더 정리가 필요하고 변수명이나 메서드명 등에서 다시 한번 코드를 보고 고쳐봐야겠다는 생각이 들었다.
계속해서 해당 프로젝트를 업그레이드하기 위해 고객센터, socket을 이용한 실시간 매장 문의, 서비스 구독 결제 등의 기능을 추가적으로 넣어보려 한다. 더 나아가 MSA 구조로 회원 관련 서버, 예약 관련 서버, 식자제 관련 서버로 나누어 바꿔보면서 도전해봐야겠다.
백엔드 뿐만 아니라 React도 조금 더 공부해서 기존의 Promise로 api를 호출하는 방법에서 async/await 방식으로 다 바꾸고 데이터를 받아오는 부분을 좀 더 디테일하게 손보려 한다. js 기반이 아닌 ts로 적용을 시도해봐야겠다.


0개의 댓글