싸피 9기 특화프로젝트 회고록

💾프로젝트 회고

처음으로 기술 도메인을 정해서 진행했던 프로젝트였다. 나는 데이터에 관심이 많아서 빅데이터를 선택했었다. 근데 사실 생각과는 많이 다른 프로젝트였다. 빅데이터를 다룬다는 기대감에 진행했지만 hadoop이나 카프카를 공부해야 했고, 우리 팀에는 석사출신 빅데이터 다뤘던 팀원이 있어서 그 분이 데이터를 전담하게 되었다. 그래서 나는 따로 데이터 처리는 경험하지 못했고 단순 백엔드 포지션을 담당하게 되었다.
그래도 공통 때 깔끔하지 못했던 컨트롤러 로직, 여러 개의 기능을 담당했던 하나의 서비스 등등 많이 더러웠던 코드를 깔끔하게 바꾸려고 노력했다. 

기획

빅데이터 프로젝트라서 기획이 정말 어려웠다. 일단 기술 도메인이 빅데이터인 만큼 큰 데이터를 다루는 프로젝트여야했고, 이걸 시각적으로 보여주려면 결국 추천이 들어갈 수밖에 없었다. 그래서 우리는 빠르게 아이디어를 결정하자는 의견이 주였고 가장 빅데이터를 구하기 쉽운 음악으로 주제를 정했다. 근데 시각적으로 보여줘야하니? 이제 추천이 들어간 나만의 AI 라디오를 만들기로 결정했다. 
분명 빅데이터 분산이었는데? 어느 순간 추천, TTS등 다양한 기술이 들어가게 되었다... 사실 빅데이터 분산이 진짜 보여주기 힘들다고 들었었는데 이렇게 어려울 줄은 몰랐었다.

설계

이번에는 자바17을 써보려고 했다. 스프링부트 3.X로 넘어가는 추세이기도 하고 적응도 미리 해보려고 했지만, 아무래도 가장 걸렸던 점은 배워야하는 시간이 너무 오래 걸린다는 점이다. 또한 chat_gpt를 사용하는데 스프링부트 3.x 버전은 학습이 안돼있다는 점이 걸리기도 했다. 이 말은 진짜 공식 문서와 다양한 커뮤니티를 사용해서 문제를 해결해야하는데, 이 시간이 너무 오래걸리기도 하고 싸피에서는 주어진 시간이 많이 없기에 기존에 사용했던 자바 11을 그대로 사용하기로 결정했다.

이번에 DB를 설계하면서 가장 주요했던 점은 온캐스트를 어떻게 설계하느냐였다.
온캐스트 하나에는 라디오 스크립트 4개, 음성 TTS 4개, 추천 음악 3개가 들어간다.
처음에는 라디오 스크립트 테이블, TTS 테이블, 음악 테이블을 구분해서 따로따로 저장해서 불러오는 방식을 생각했었다. 그러나 이 방법의 문제점이라고 하면 온캐스트 하나를 부르는 데 총 4번 쿼리를 날려야 한다는 문제가 생겼다.
그리고 우리는 스크립트 개수, tts 개수, 음악의 개수가 고정이었기 때문에 하나의 온캐스트에 모든 정보를 담는 방향을 선택했다. 

그 결과 이런 테이블이 탄생하게 되었다. (근데 이거 지금 보니 테이블을 분리해도 쿼리를 4번 날리는데, 이렇게 만들어도 쿼리를 4번 날린다. 왜 이때는 그냥 비정규화를 시키고 만족했는지 도저히 모르겠다...)
그리고 지금 보면 음악에서 JOIN을 통해 하나의 쿼리로도 가져올 수 있을 것 같다.(이 부분은 추후에 리팩토링을 통해 속도를 측정해보고 기록해야겠다)

개발

그리고 기존에는 테이블을 하나 만들어서 통해 리프레시 토큰을 저장했는데, 이번에는 속도적인 측면에서 Redis에 저장하기로 했다. 분명 인메모리 DB라서 기존 RDBMS보다 빠른 속도를 자랑하지만, 이번에 RTR(Refresh Token Rotation) 기법을 사용하게 되면서 원래 의도했던 대로 캐싱을 사용하지는 못했다. 최소 1주 이상인 리프레시 토큰을 통해 액세스 재발급이 자주 일어나서 Redis를 사용했지만 리프레시 토큰도 함께 갱신해버리는 바람에 계속해서 토큰을 꺼낼 일이 없다는 점이다.(물론 캐싱을 활용하지만 의도했던 만큼은 아니다)