0.아웃소싱이 무엇이랴? 달려!!

아웃소싱이란? 외주 업체에게 짧은 단위로 개발을 맡기는 것이라고 합니다.
우리는 그리하여 1주일, 아웃소싱 배달앱 개발을 위해 달려갔다.

사실 다들 달리는데 나 혼자서 기어가다가 여러 번 넘어졌다

아무튼, 그래서 어제 회원가입을 작성하고 오늘은 로그인, 로그아웃, aop까지 적용할 예정이었다.

1. 오늘의 애로사항

1. 컨플릭트

어제는 내가 했던 회원가입 부분을 커밋했는데 풀리퀘가 올라가지 않는 문제가 발생했다. 도대체 뭐지?? 싶어서 저번처럼 로컬에서 인텔리제이로 컨플릭트를 해결하기로 했다.
처음에는 혹시나 컨플릭트를 수정하다가 망할까봐 무서웠지만, 의외로 맡은 파트가 거의 겹치지 않았고, 트러블 파트도 3곳 밖에 없어서 어렵지는 않았다.

심지어 그 중에 두 곳은 내가 수정한 곳이었다. ㅋㅋ

깃허브에 커밋은 끝났지만, 풀리퀘를 올릴 수가 없기 때문에 로컬 환경에서 일단 한 번 디폴트 브랜치를 pull 받아서 병합한 후 올리는 방향으로 컨플릭트를 해결했다.

그런데 여기서 또 문제, 오늘은 무슨 날인거지? 내가 풀리퀘를 올렸는데 막상 코멘트를 다는 데에서 문제가 발생했다.

이러면서 메신저로 이야기를 나누고 있었는데 그 때 마침 다른 분께서 말씀해주시길 깃허브가 그 시간에 터졌다는 얘기였다.
깃허브 터진 건 또 어떻게 아시는 거지? 싶어서 깃허브 상태를 확인하는 사이트가 있는지 찾아봤는데 정말 존재했다.

원래 해외 사이트라서 +9시간 해야지 우리나라 시간이라고 한다.
우리가 막 뭐지? 이러고 있을 때가 01:31 UTC 무렵이라는 얘기다.
내 잘못인가 하고 괜히 찔렸잖아!!!!

아무튼 이러고 얼마 안 있다가 무사히 해결되었다.

2. 트러블슈팅

1. jwt를 이용한 logout?

• 배경 : jwt 토큰을 이용한 logout 방식에 대한 고민

  • 사실 저번 포스팅에서 썼던 내용이지만 나는 jwt에 대해 문외한이었다.
  • 아는 것이라고는 jwt 토큰은 자동으로 만료가 되는 토큰이며, 따로 로그아웃을 하려면 그 토큰을 못 쓰게 만드는 구현을 해야한다는 것이었다.

• 발단 : logout을 구현하기 위해 구글링을 하다가 조잡하고 이상한 방식들만 발견

  • jwt 토큰의 로그아웃은 구글링을 해서 나오는 결론들도, 지피티 선생님이 주는 결론들도 이상했다. 한 마디로 극혐이었다.
  • 로그인을 하면서 화이트 리스트에 유효값을 넣고, 로그아웃 시에 이것을 지우기
  • 블랙리스트로 레지스템플릿으로 관리? > 난 레지스를 잘 모르는 상황이다.
  • 클라이언트 측 토큰을 그냥 삭제해버리기

• 전개 : 복잡하기만 하고 현재 단계에서 굳이? 싶은 방식들의 향연

  • jwt토큰은 어차피 정보가 모두 저장되어 있는 집합체인데 그걸 왜 또 로그인 때 저장하는가?
  • jwt 토큰을 클라이언트에서만 지우는 게 과연 좋은 방법인가?

• 위기 : 스스로 무엇을 선택해야 할 지 모르겠다는 패닉이 옴

  • 도대체 이 jwt 토큰을 로그아웃 할 때에는 무슨 로직을 써야 맞는가? 진정 저 방식밖에 없는가?
  • 물론 저 방식이 100% 나쁜 건 아니지만 백엔드 개발자가 될 나로서는 이게 맞나? 하는 의문이 계속 들긴 했다. 클라이언트 측에서 지우는 것도... 무작정 강제 삭제만이 답인가?

• 절정 : jwt 토큰을 어디다 저장을 해야 하는 것은 맞다는 것을 인지

  • jwt 토큰을 막 임의로 파괴할 수는 없기 때문에 어딘가에 저장을 해 두어야 하는 것은 맞다고 보았다.
  • 그리하여 로그아웃 시에 jwt 토큰을 저장한 후, 그 토큰은 로그아웃 토큰이라고 알려주는 예외처리를 하는 것으로 해결하기로 하였다.

• 결말 : jwt 토큰을 Set으로 저장하여 jwtFilter에서 확인하는 것으로 해결

  • 로그아웃된 토큰을 위한 Set을 hashSet으로 선언하고, 로그아웃의 서비스로직에서 jwt 토큰을 Set으로 저장 -> 레지스를 잘 몰라서 그냥 Set으로 사용...;;
  • 토큰을 검증하는 jwtFilter에서 해당 Set에 있는 토큰이 아닌 지 확인하는 로직을 추가하여 해결

2. 사실 그 외의 트러블도 있긴 했다.

<valid가 너무해>

• 비밀번호 패턴을 구현했더니 그대로 나와서 메시지 추가를 해야한다는 걸 깨달았다.
• userRole에 NotBlank를 안 넣었더니 null 처리 된 걸 뒤늦게 깨달았다.

<Postman이 너무해>

• 분명히 제대로 적은 것 같은데 자꾸만 서버 에러가 났다. 찾아보니 원인이 위의 코드였다.
• userRole이 enum이라서 NotBlank는 안되고 NotNull만 가능하다는 거였다.

근데 또 문제가 발생했다.

이번에는 결국 해결하지 못한 문제인데 회원가입부터 로그인, 로그아웃 로직까지 다 정상작동 했는데 aop로 권한 분리를 하다가 자꾸만 필터 쪽에서 jwt 토큰을 걸러내는 문제가 발생했다. 이 부분은 내일 해결하기로 했다.

2. 오늘의 결론, 많이 공부한 자가 더 빨리 달린다. 그래서 난 느리다.

이번 조 분들은 정말 너무 다 잘하신다. 다들 달리는데 혼자서 기어가다가 울먹거리는 중이다.
그리고 함께 부트캠프를 하는 입장에서 같은 세션을 듣고, 같은 강의를 들었지만 이렇게 격차를 느낀 건 분명 그 분들의 노력의 깊이의 차이라고 생각이 들었다.
내가 기어가는 것은 전적으로 내가 적게 공부해서라는 결론이 나왔다.

일등까지는 안 바라겠습니다만 최종 프로젝트 전까지는 스스로 달릴 수 있게 성장했으면 좋겠다.