데브코스 백엔드과정 3차 프로젝트 후기

 

[Project]데브코스 백엔드과정 2차 프로젝트 후기

 

데브코스 3차 프로젝트는 지난번 진행했었던 2차 프로젝트의 코드를 자바에서 코틀린으로 마이그레이션 하는 프로젝트였다.

하지만 2차 프로젝트와 3차 프로젝트 사이에는 코틀린을 학습하는 수업이 있었기 때문에 

코어 타임에는 코틀린을 학습하고, 이후 저녁 시간에는 2차에 진행한 프로젝트를 좀 더 디벨롭할 수 있는 약간의 시간적 여유가 있었다.

 

 

추가적으로 개발한 것

(좌)기존 홈화면 , (우)새로운 홈화면

이 기간동안 팀원들과 논의 후 새로운 홈 화면을 개발하기로 했다. 

기존의 서비스에서는 전체공연을 조회하는 페이지가 홈 화면으로 사용되고 있었고,

해당 홈에서는 공연 검색과 카테고리별 조회 기능을 제공했다.

하지만 단순히 공연을 조회하는 기능만을 제공한다면 사용자의 입장에서 서비스를 이용할 메리트가 없을 것이라 생각했다.

 

따라서 새로운 홈화면에서는 사용자 친화적인 서비스를 위해 실시간 인기 공연과

사용자마다 등록한 선호카테고리를 기반으로 한 추천 공연,

그리고 전체 공연을 확인할 수 있도록 홈화면을 구성했다.

 

사용자별 추천 공연 조회

사용자는 회원가입시 혹은 마이페이지에서 자신이 선호하는 카테고리를 최대 3개 지정할 수 있다.

또한 공연을 등록할때 해당 공연이 속한 카테고리를 최대 3개까지 선택할 수 있다.

따라서 사용자의 선호 카테고리와 공연이 속한 카테고리를 비교하여 가장 많이 매칭되는 순으로 10개의 공연을 찾는

방식으로 구현하였다. 성능을 향상시키기 위해 queryDSL로 구현했는데

아쉬운 점은 최적화를 하거나 부하테스트를 따로 해보지 못했던 것이다. 이후 진행할 프로젝트에서는

쿼리를 좀 더 최적화하거나, 부하테스트를 통해 성능을 수치화하는 작업들을 해보고 싶다.

 

실시간 인기 공연 조회

처음 이 기능을 구현할때 다양한 방식을 고민했다.

특정 시간동안시간 동안 좋아요를 가장 많이 받은 순으로 정렬, 특정 시간 동안 가장 티켓이 많이 팔린 공연 순으로 정렬 등등

하지만 티켓을 아예 판매하지않는 무료공연도 존재하고, 좋아요 기능을 새롭게 추가하기에는 시간적으로 부족했기 때문에 

조회수를 기반으로 인기 공연을 판별하도록 했다.

redis insight를 통해 확인

(좌) sorted set으로 조회수 높은순 공연id 정렬 , (우) 메인 DB에서 공연정보를 가져와 캐싱

 

프로젝트에서 메인DB로 MySQL을 사용하고 있었는데 조회수를 실시간으로 빠르게 반영하고, 메인 DB의

부하를 방지하고자 인기공연조회에는  redis를 사용하기로 했고,

구현을 위해서 redis의 List와 Sorted Set, 그리고 캐싱기능을 이용하였다.

 

기본적인 로직은 아래와 같다.

사용자가 특정 공연을 조회했을 때 해당 공연의 id 값을 redis의 list에 최대 300개만 저장한다.

(이때 list의 길이가 300을 넘어가면 가장 오래된 조회기록은 삭제하고 새로운 조회기록을 추가한다)

sorted set을 통해 해당 list에서 가장 많이 조회된 공연순으로 정렬한다.

스케줄러를 통해 5분마다 한 번씩 sorted set에서 상위 10개의 공연의 id를 가져온다.

해당 공연들의 id를 이용하여 메인 DB에서 공연정보를 가져와 redis에 캐싱한다. 

이후 사용자가 인기공연을 조회할 때마다 redis에 캐싱되어 있는 데이터를 보내준다.

 

이 과정에서 처음으로 redis를 사용하기도 했고, 팀원들의 개발 편의성을 위해 embedded redis도 적용하는 등 

개인적으로 3차 프로젝트에서 가장 배운 게 많았던 작업이었다. 

특히 특정 상황에 가장 적절한 기술과 방식을 찾아 고민하고 적용하는 과정을 통해 

'선택에는 이유가 있어야 한다'는 말을 다시 한번 곱씹어보는 좋은 경험이었다.

 

코틀린 마이그레이션

마이그레이션을 할 때는 크게 entity, dto,  repository, service, controller 순으로 진행했다.

참조되는 역순으로 마이그레이션을 진행하는 것이 그나마 의존성 충돌이 덜 발생할 것이라 판단했기 때문이었다.

하지만 그렇게 진행해도 각각의 팀원이 마이그레이션 한 코드들을 합칠 때면 충돌이 발생하는 건 어쩔 수 없었다.

 

단순 충돌 이외에도 

코틀린과 자바에서의 null 처리가 다른 것, gradle 파일의 변환, 인텔리제이가 제공하는 자동 코틀린 변환의 불완전성등

다양한 이유 때문에 곳곳에서 문제가 발생했다. 

 

생각보다 시간이 많이 걸렸지만 팀원분들과 같이 모여 버그를 수정하고, 서로 의견 공유를 하면서

결과적으로는 모든 코드들을 코틀린으로 마이그레이션 하면서 마감기한 내에 제출할 수 있었다.

 

느낀 점

상황에 맞는 적절한 기술을 찾기 위해 고민하고, 팀의 개발환경 통일성을 위해 embedded redis를 도입했다.

그리고 지난 2차 프로젝트에서 미처 작성하지 못한 테스트 코드도 작성하였다.

이런 경험들 때문인지 2차 프로젝트 때 보다 조금 더 성장했다는 뿌듯함을 느낄 수 있었다.

 

하지만 통합테스트, 부하테스트, 모니터링, 배포 등등 아직 경험해보지 못한 것들도 많기 때문에

다음 프로젝트에서는 더 다양한 경험을 하고 싶다.