"비회원 해줘"
우리 프로젝트의 주된 기능 중 하나인 비회원 기능... 사실 해야하는 건 알았지만 어떤 식으로 해야하나? 라는 식으로 고민하다 뒤로 미루고 미루다 " 이제 슬슬 비회원 해야지요? 해줘! " 라는 느낌으로 시작하게 되었습니다.
기능 선택
그렇다면 어떤 식으로 구현할 것인가 라는 문제의 쟁점이 생겼다. 여러가지 방식이 있겠지만 그 과정에서 찾아본 방식은 2가지이다. 세션을 활용한 방식, 레디스를 활용하여 사용하는 방식 이렇게 2가지이다.
- 세션
현재 JWT를 이용한 회원인증 방식을 사용하고 있기 때문에 세션을 활용한다는 점에서 뭔가 이상함을 조금 느끼긴 했지만 찾아보니, 유저의 권한과 비유저의 권한을 비교하는 방식에서는 자주 이용하는 방식이라고 한다. 그러나 해당 방식은 프론트 측에서, 세션을 담은 쿠키를 다시 체크하는 작업이 필요하기 때문에 현재 세션을 이용하는 방식이 아닌 상황에서 사용하기에는 정말 필수적이 아닌 기능을 포함하고 있다는 생각이 들어서 잠시 보류하였다.
- Redis
레디스의 휘발성 데이터를 저장한다는 점에서 주목하여 비회원의 정보를 ip를 활용하여 key으로 만들어 데이터를 저장하는 방식으로 구상하였다. 더하여 현재 우리의 서비스에서 비회원의 경우 어떤 문제는 맞았고 어떤 문제는 틀렸고를 알수없는 기준이기 때문에 데이터 관리의 편리성 즉, 데이터를 저장하지 않는다는 점에 중심을 둔것과 프론트와의 처리방식에서의 불필요한 작업을 줄이는 방식을 중심으로 레디스를 선택하였다.
결정 - Redis
때문의 위와같은 점을 중심으로 우리는 Redis를 사용하기로 결정하였다. 이를 구현한 방식은 레디스의 보안처리한 ip+퀴즈의 id 값을 key로 정하고 맞춘 문제의 번호를 레디스 리스트에 저장하는 방식으로 정답여부를 확인하였다. 그 이후 결과창에서 아까 정한 key값으로 조회한 뒤 리스트의 사이즈를 측정하여 정답의 갯수를 보여주는 형식으로 구현하였다. 그 이후 리스트의 모든 결과를 날려 다시 같은 문제를 풀더라도 다른 방식의 응답이 나오게 구현하였다.
남아있는 문제점
현재의 비회원 기능은 데이터 관리를 어떤식으로 가볍게 할 수 있을까? 혹은 1번 퀴즈를 풀었을 때의 정확성을 어떤 식으로 구현할까? 하는 점이 가장 컸다. 때문에 현재는 1번 문제를 풀고 정답을 보는 것 까지는 가능하지만, 회원의 새로고침에 의하여 데이터를 지운다는 관점에서 소실되었기 맞춘 정답의 갯수가 0개가 된다는 것이 남아있는 문제점이다. 해당 방식은 기존의 데이터를 소실한다는 점에서 단시간 동안 살린다는 점으로 변경한다던지, 아니면 저장시간을 두고 시도 횟수를 정해서 key값 뒤에 붙여 2가지 시도가 독립적으로 운용되어 0이 있다면 1에, 답을 체크하고 0 을 지우고 번갈아가며 가능하게 만들 수 있을 것 같다.
'Spring' 카테고리의 다른 글
Java 알고리즘 학습 (0) | 2023.12.04 |
---|---|
알고리즘 풀이 - 자료구조 (0) | 2023.11.27 |
트러블 슈팅 - 중복 저장 문제 (0) | 2023.11.06 |
항해 99 - 트러블 슈팅 Optional(Likes) (1) | 2023.10.25 |
항해 99 - 서비스와 RDB (1) | 2023.10.21 |