2023. 08 본과정 Week 11 WIL - 본 프로젝트 4주차 회고

Fact

MVP 배포 후 발견된 오류 수정 및 개선을 진행했다.

 

Feeling

 설계 당시에도 회의를 거쳐 많은 걸 고려하고 코드를 작성하지만, 클라이언트와 연결되고 실제로 작동해봐야 발견할 수 있는 문제들이 많다는 걸 느꼈다.

 

Finding

 이전 포스팅에서도 살짝 언급됐지만 역할 분담 시에 나는 웹 소켓과 매칭 대기열 시스템을 위주로 구현했었다.

https://hae3043.tistory.com/50

2023. 08. 14~19 시그널링 socket.io로 변경

 

 초기에 내가 맡았던 기능은 아니었지만, 팀원들의 코드를 합치고 클라이언트와 연결해서 배포 전 테스트를 하는 과정에서 여러 문제들이 발생했는데, 그 중 refresh Token과 관련 된 몇 가지의 이슈를 해결하게 됐다.

 

 프로젝트에서 access token의 탈취 피해를 줄이기 위해  access Token의 유효기간을 짧게 하고 refresh Token을 같이 발급해서, access Token의 만료 시 refresh Token을 활용해 access Token을 재발급 하도록 만들었다.

 기존의 로직에서는 단순히 로그인 시에 refresh Token을 같이 생성해서 redis에 저장하도록 만들었는데, 다른 브라우저에서 동일한 아이디로 로그인 하는 경우 새로운 refresh Token이 덮어씌워져서 기존의 로그인 유저는 access Token을 재발급 받지 못하는 상황이 생겼다.

 단순히 보자면 프로젝트의 refresh Token이 jwt토큰 방식이 아닌 random UUID 형식으로 생성된 값이라 토큰 자체에 유저를 판별할 수 있는 정보가 없기 때문에, user의 loginID를 key로 하는 hash 값으로 저장하고 access Token 재발급 시 refresh Token 값 전체를 비교하기 때문에 발생한 일이다.

 

 우리 조에서는 단순히 refresh Token의 저장 방식이나 access Token의 재발급 조건 비교 방식만을 수정하는 쪽으로 접근하지 않고,

 결국 트러블의 근본적인 원인인 다중 브라우저의 동일 아이디 로그인을 허용하느냐는 명제로 발전시켜서 수정 방식별로 발생할 만한 case에 대해 충분한 논의 후 개선을 진행했다.

https://github.com/project-teamIP/teamIP-BE/issues/102

refreshToken 관련 issue · Issue #102 · project-teamIP/teamIP-BE

 

 

 또 프로젝트 기능 중 현재 접속자 수를 대시보드에 띄워주는 기능이 있는데, 단순히 refresh Token의 갯수로 적용하게 되면 로그아웃 하지 않고 브라우저를 종료한 유저가 있을 경우 refresh Token이 redis에 그대로 남아있기 때문에 접속 유저 수가 실제 활동 유저를 정확하게 반영하지 못하는 상황이 생겼다.

 애초에 refresh Token 자체가 로그인을 길게 유지함으로서 유저의 편의성을 챙기는 방식이기 때문에 어찌보면 당연한 결과였다.

이것도 여러 해결 방법을 고민해본 끝에 access Token 재발급 시 refresh Token의 hash값에 access Token 재발급 시간을  업데이트 하고, 마지막 재발급 시간으로부터 일정 시간 이상 지난 경우 현재 활동 중이지 않은 유저로 간주해서 접속 중인 유저 집계에서 제외하는 방식으로 수정했다.

 물론 이 방식 또한 현재 활동 중인 유저를 정확하게 반영할 수는 없겠지만, 서비스 상황에서 불편을 겪거나 문제가 될 만한 부분들을 고민해보고 더 좋은 방법을 찾아나가는 과정을 경험해보았다고 생각한다. 단순히 코드만 보고 있었다면 알아차리기 힘들었을 부분들이 실제 제공되는 서비스 수준으로 확장시켜서 볼 때 더 잘 보이는 것 같다.

 

 

Future

비록 초기 역할분담에서 내가 맡았던 기능은 아니더라도, 전체적인 관점에서 문제점을 파악하고 함께 회의하고 개선해나감으로서 전체적인 완성도를 챙길 수 있도록 해야겠다.