42GG 3기 개발 회고

리팩토링을 목표로 시작했던 3기, 리빌딩으로 마무리했다.

 

탁구 매칭 & 랭킹 시스템으로 42Seoul 카뎃들을 대상으로 하는 서비스이고 작년쯤부터 개발했던걸로 알고있다.

1기때 메인 기능 개발하고 2기때는 관리자 기능이 추가됐다.

 

나는 3기때 들어오게 되서 기존 서버 구성을 늦게 알게 되었는데, OAuth 를 잘못 사용하고 있는 부분(안쓰고 있는 것과 마찬가지였다.)과 데이터베이스 정규화 제대로 안되어있는 부분들(외래키가 불필요하게 많이 걸려있는 부분, 컬럼은 있는데 값이 아예 안들어가는 부분,,)로 인해 3기 온보딩 중에 설계문제로 디비에 똑같은 데이터가 두번 들어가는 문제가 있었다.

또한 코드 리팩토링을 해야하는데 안쓰는 클래스 파일도 몇개 있는데 양이 많고 기존 코드에 대해 완벽히 이해하고 있는 사람도 없어서 리빌딩하기로 했다.

 

일단 기존에 제대로 동작하지 않던 OAuth 부터 적용하고 넘어가기로 했다. 보통 프로젝트 진행할 때는 OAuth 를 먼저 하면 테스트할 때 인증을 계속 해줘야해서 나중에 하는게 편한데 이번에는 리빌딩 시작이 온보딩 중간에 시작되어서 프론트 팀이랑 일정을 맞춰야 했는데 회의를 해야 다른 부분들 작업이 가능해서 OAuth 먼저 하게 되었다.

OAuth 를 나랑 다른 팀원 두분이서 같이 작업해서 accessToken 으로 동작하는걸 먼저 완성시킨 후에, 다른 기능들 추가하면서 refresh token 으로 access token을 발급하는 기능도 추가했다. refresh token 은 redis 에 저장해서 만료되는걸 확인할 수 있게 했다.

https://junior-datalist.tistory.com/352

Refresh Token Rotation 과 Redis로 토큰 탈취 시나리오 대응

그 외의 다른 기능들을 구현하면서 일정관리를 위해 Jira 를 사용했고, 전체 작업 목록을 백로그에 작성한 후 스프린트 단위를 1주일로 잡아 1주일마다 팀원들에게 작업을 할당하며 진행했다.

데일리 스크럼도 했는데, 데일리 스크럼을 통해 하루 목표를 세울 수 있는 것도 좋았고 팀장이다보니 팀원이 어떤 업무를 오래 잡고 있으면 어떤 어려움 때문에 오래 걸리는지 확인할 수 있는 것도 좋았다.

 

스프린트가 종료될 때마다 회고를 했는데, 초반에 레디스 구조를 잡았던 부분에 대해 수정이 필요하다던가 미처 이전에 정하지 못했던 부분을 바로바로 하다보니 잠깐만 자리에 없으면 뭔가 바뀌어 있는 상황이 자주 발생하면서 바뀐 부분에 대해 공유가 잘 안됐었다.

이 부분을 해결하기 위해 서버 정책에 대한 문서를 노션에 만들었고, 서버 정책에 수정사항이 생길 때마다 문서를 업데이트하고 문서를 공유하여 소통을 원활히 할 수 있었다.

 

이번 프로젝트를 진행하면서 내가 팀장을 맡을 생각이 없었는데 사다리타기로 팀장이 됐는데, 다들 진행하면서 팀장하려고 마음먹고 온줄 알았다고 해서 웃겼다 ㅋㅋㅋ

여태 진행한 팀플중 웹플젝 횟수별로 따지면 7개정도..?팀장을 했는데 대부분 잘 따라와준 팀원들이 있어서 잘 된것 같다

그리고 뭔가 나에 대해 잘 알게된? 프로젝트였다. 그동안 서버 몇번 해보니까 플젝을 하는게 거기서 거기인 느낌이 있었는데 이번에 OAuth 적용하면서 refresh token 적용까지 해본게 처음이고, redis 도 이번에 처음 써봤다. 리팩토링 스터디 하면서 진행해서 내가 짰던 코드를 중간중간 다시 리팩토링하기도 하고, 롬복 어노테이션이나 스프링에서 사용하는 어노테이션들에 대해 막 쓰면 안된다는 것도 찾아서 규칙도 정하고 컨트롤러 - 서비스 클래스의 구분? 컨트롤러에서 어느 부분까지 처리하고 서비스 로직으로 넘겨줄 것인지에 대해 토론하기도 했다.

서비스가 또 다른 서비스를 호출할 것인지 아니면 아예 한 서비스에서 다른 서비스 호출을 막을 것인지에 대해서 얘기하기도 했다.

 

배포 다 하고 다음기수 진행 중에 피드백 디엠을 받았다. 게임 시간별로 큐를 둬서 여러개를 신청할 수 있게 하고 탁구력이 차이가 많이 나지 않는 사람이 들어오면 매칭될 수 있게 했다. 그리고 취소하면 큐가 전부 지워지고 취소한 사람은 1분간 슬롯에 매칭 신청을 할 수 없는데 이 패널티 시간이 짧아 의도적으로 취소한 뒤 다시 잡는 사람이 있는 것 같다는 피드백이었다.

일단 회의를 통해 기능을 어떻게 변경할지 이야기해야해서 일단 30분으로 패널티 시간을 늘렸다. 사실 이것만으로 게임 취소 인원이 크게 줄었다. 이전에는 하루에 보통 1명 이상 많으면 4-5명까지 있었는데 이제는 많으면 1-2명이고 일주일에 0~3명정도가 됐다.

그래도 게임 취소 당한 사람이 피해를 보고 있는 상황이기 때문에 큐는 게임 시작 전까지 살려두고 매칭이 취소되면 취소 당한 사람은 다시 큐에서 대기할 수 있도록 변경했다.

 

시간 되면 통계기능 개발해볼 생각,,,

 

최근 아키텍처 공부를 같이 하고 있는데, 기존부터 생각했던 멀티모듈 프로젝트를 도입했으면 좋겠다는 생각이 더 강해졌다.

4기 분들이 진행하면서 상점 기능을 추가해서 아이템이나 구매 내역, 재화 기능이 추가되었는데 어드민 기능도 있어서 단일 구조로 가기에는 기능 추가에 점점 부담이 있다고 느껴진다.

 

취준도 해야되는데 할 수 있을지 모르겠다!

랭킹 시스템의 현재 문제점이 랭킹 정렬 속도를 위해 레디스에 데이터를 다 집어넣고 zset 을 사용해서 정렬한다. 이 방법으로 엄청난 성능 향상이 일어나긴 했지만, 동일한 탁구력을 가진 유저들이 등수가 같은 문제가 일어났다.(점수가 같은데 등수가 다르게 나옴)

게다가 레디스에 현재 시즌 뿐만 아니라 이전 시즌의 랭킹 데이터까지 전부 담아두고 사용하고 있는데, 레디스는 램을 사용하여 데이터를 저장하다 보니 램용량이 초과하면 스왑메모리를 사용한다는 것을 알게 되었다. 이는 서버에 큰 부담이 될 수 있고, 이 랭킹 부분에서는 레디스를 캐시서버로 쓰는게 아니라 하나의 디비처럼 쓰고 있기 때문에 레디스에 데이터가 사라질 경우 대책이 없다는 문제도 있다.

이 부분도 사실 mysql 에서 rank 계산하는 쿼리를 사용하면 동일 점수에 대해 동일 등수로 처리가 가능하기 때문에 이 부분을 캐싱하면 괜찮지 않을까? 생각한다.