Day 78. 본격 유저 피드백 반영 시작

유저 피드백을 받고 주말이 흘렀다. 유저 피드백의 대부분은 페이지의 구성이나 디자인 쪽 피드백이어서 상대적으로 수정할 것이 많지 않았다. 피드백을 반영하며 새로 기능을 추가하게 된 것은 "신고 기능"이었다. 유저 신고를 위해 관리자 페이지가 필요해져서 간단하게나마 프론트엔드에게 요청을 하게 되었고 신고 기능을 위한 리스트업 페이지가 생겨났다. 

서비스라는 것이 처음 한 번에 모든 사용자의 마음을 만족시킬 수 없다는 것을 알았지만 피드백에 안좋은 글이 있으면 기분이 반감되기는 했다. (내새끼 욕하는 느낌....😥)   하지만 우리의 프로젝트가 조금 더 잘되라는 마음으로 써주신 피드백들이기 때문에 하나하나 소중히 반영할 수 있었고 덕분에 더 멋진 서비스가 되어가고 있는 것 같다. 그래도 우리 팀은 1차에서 거의 모든 기능을 구현한 상태로 릴리즈 했기 때문에 다른 팀보다 상대적으로 추가해야하는 기능이나 수정해야하는 부분이 적었다.  역시.. 기획을 잘 한 것 같다. ㅎㅎㅎ 이렇게 유저 피드백을 반영하는 것도 나중에 실제 현업에서는 정말 수백 번, 수천 번 하게 될텐데 미리 경험할 수 있다는게 정말 값진 경험이라고 생각한다. 

 

아무튼, 이러한 피드백을 받으면서 생각한건 우리 서비스가 만약 실제로 런칭되었다면 얼마나 많은 사용자들 받아들일 수 있을지 궁금해졌다. 유저 피드백을 받는 첫 날, 바로 화면공유가 안되는 문제가 생겼는데 이것은 결국 서버상에서 문제가 생겼던 것이었다. 프리티어 서버에 올려둬서 그런 것인지 바로 서버가 터지다니.. 그 날 바로 서버 사양을 t3.medium으로 올리고 진행했더니 문제가 사라졌다. 이래서 유저 테스트 전에 부하 테스트를 해봐야하는구나 라는 생각을 했다.

 

더불어 동시성 제어도 궁금해졌다. 만약 방에 입장 가능한 인원이 1명인데 두 명이 0.00001초도 차이가 나지 않게 그 방에 입장하려고 한다면 어떻게 될까? 둘 다 입장이 안될 것인지, 랜덤으로 입장이 가능할 것인지 궁금했다. 그러면서 이것을 어떻게 제어하는게 효과적인건지 찾아보게 되었다. 

 

동시성제어

동시성 제어 기법 — 잠금(Locking) 기법

우선 동시성 제어의 대표적인 방법에는 Locking이 있는 것 같다. A, B가 동시에 요청이 들어왔을 때 요청에 Lock을 걸어 대기하도록 만드는 것. 그럼 이걸 어떻게 코드로 구현해야하는거지? 라는 궁금증이 생겼고.

 

Redis 활용 - 동시성 제어

[Spring boot] 좋아요수 증가 분산락을 이용하여 동시성 제어하기 (redis활용하기)

 

이렇게 레디스를 사용하여 가능하다는 것을 알게 되었다! 이번 프로젝트에 레디스를 캐시 메모리로도 사용하고 채팅을 위해서도 쓰고 있는데.. 이미 접하고 있는 것으로 동시성 제어도 할 수 있다고 하니 어떻게보면 그렇게 어려운 일이 아니라고 생각했다. 지금은 동시성 제어까지 해볼 여유가 없어서 간단히 개념을 정리하는 것으로 만족해야겠다. 

 

@Transactional - 동시성 제어

[Spring] @Transactional로 DB 동시성 문제를 방지하자

" MYSQL을 사용중이라면 defalut transaction isolation level은 2 "

" REPEATABLE READ는 고립 레벨 2에 해당되는 수준이며, 해당 레벨에서는 커밋하기 전 작업 중인 데이터의 값을 읽을 수 없을 뿐 아니라, 읽기 트랜잭션이 끝나기 전까지 Undo 영역을 타 트랜잭션에서 쓰기 작업 후 커밋한 데이터로 덮어쓸 수 없다. 그렇기 때문에 Non-Repeatable Read가 발생하지 않게 된다. "

 

트랜잭션 어노테이션이 이미 동시성 제어를 해주고 있었구나?!