생존 신고를 위한 주간리포트 4월 4주차이다!
사실상 지지난주 개발 일기인데, 지난주에는 전사적으로 데이터 검수 작업을 진행하느라 거의 개발을 못하게 됐다 (덕분에 월요일날 쓰던 리포트를 목요일날 이어쓰게 됐다)
업무 (개발)
1. Auth service 에 mobile api 관련 로직 추가
- mobile api는 사실상 기존의 web mvc 프로젝트를 포팅한 것과 마찬가지였기 때문에(물론 로직상의 변경은 많이 일어나긴 했지만) 로그인 방식도 기존의 session/cookie 방식으로 포팅을 진행했다
- mobile은 reactive 방식으로 포팅했고(spring webflux) 리액티브 방식에서는 session 을 이용한 로그인 방식보다는 JWT token 을 이용한 로그인 방식이 권장된다고 하여 개발을 거의 진행했지만 바꾸게 됐다
- 어차피 모든 서비스 자체를 중앙의 auth service, eureka, spring cloud 를 거치게 할 계획또한 있던 것 같으므로 (관리 효율성이라고 하는데 사실 아직 그게 어떤 이점이 있는지는 크게 체감되지는 않음) 진행하는 김에 바꾸기로 했다
그런데 문제는 기존의 jwt 생성 로직에 약간의 문제(?) 사항이 있어서 결국 기존로직에 따라 개발을 하는 것은 아니고 새로 개발을 진행하게 됐다
기존의 jwt 로직은 아래와 같았다
- Login 요청 시 아이디 검증을 하고, 그에 따라 refresh token/access token 을 발급 해주고 access token 과 refresh token을 모두 db에 저장함
- 재발급 요청 시 access token과 refresh token 을 모두 전달하면 refresh token 만료 여부를 확인한 뒤에 access token 과 refresh token 을 모두 업데이트 한 후 프론트 측에 전달함(여기서 ? 했다)
- 이 때 DB 상의 access token 과 refresh token 도 업데이트를 해줌
- 때문에 프론트 측에서는 스토리지에 엑세스 토큰과 더불어 refresh token 을 access token 만료시간마다 지속적으로 업데이트 해줘야 했음
- 로그아웃시에는 access token 과 refresh token 을 전달하여 누가 전달했는지 확인 후에 삭제를 진행한다
하지만 위의 로직에서는 몇가지 눈에 띄는 문제점이 있었는데
- Access token 값 만료 주기에 맞춰서 refresh token 도 계속적으로 업데이트 할 경우에 refresh token 의 만료 주기가 의미가 없어짐
- Access token 을 새로 발급 받을 때마다 refresh token 과 access token 을 동시에 발급하여 프론트 측에 전달한다면 aceess token 의 만료 주기를 짧게 설정한 의미가 없어짐
- refresh token 을 탈취하여 access token 을 지속적으로 발급받을 수 있음
- refresh token은 로그인 한번 때만 발급받고 refresh token 만료 == 로그아웃 으로 알고 있음
- access token 업데이트 시마다 db update 를 진행하면 오히려 jwt 를 이용하는 것이 서버에 부담을 줄 수 있음
기존 코드 작성자 분께 왜 그렇게 작성했냐 여쭤보니
- 사용자 액션 시에는 로그아웃 시키고 싶지 않고 싶음
- 하지만 액션이 없는 시간 안에서는 짧은 시간 안에 로그아웃 시키고 싶음이라고 하였다
일단 admin 서버인데 그렇게까지 해야하나라는 생각이 들었지만, 작성자의 의도가 그렇다면 그런 것이라 생각했다
하지만 찾아보니 위 고민은 프론트 단에서 다른 방식으로 해결해야 하는 것이었는데 그 방법은 아래와 같았다
1. refresh token 만료 시간이 다가오면 재로그인 하라는 알람창을 띄워주기
2. 프론트단에서 자동 로그인을 구현하기
때문에 모바일은 jwt 사용성을 살리기 위해
- refresh token/access token 의 업데이트 주기를 따로 들고가기로 하였다
- 차후 admin 에 대해서도 변경할 듯 하다 - Access token 을 db에 저장하지 않기로 함
- 또한 access token update 후에는 access token 정보만 보내주도록 함
- Refresh 시에 access token은 header에, refresh token 은 body 에 담아서 보냄 - Logout == refresh token 삭제로 간주하여 진행
- 로그아웃 시 프론트에서는 스토리지의 refresh token, access token 을 삭제
- 서버측에는 단순히 refresh token 만을 전송하여 db에서 삭제
- 이 때 refresh token 은 쿠키에 담아서 보내도록 했다
이렇게 구현하기로 했는데 문제는 refresh token 은 만료됐는데, access token 이 살아있을 경우 여전히 정보를 가져오는 것은 유효하다는 점이었다
- 이는 블랙리스트를 두어 특정 access token 을 접근하지 못하도록 하는 방식을 많이 사용한다고 했다
- Access token 자체를 만료시키는 것은 어려울 듯 했다
이에 대해서는 일단 가정하지 않고 차후에 구현하도록 했다
그리고 기존에 session 방식으로 구현했을 때는 body 값에, 혹은 pathparameter에 시퀀스 정보(물론 암호화를 하긴 했음) 를 프론트에서 보관해서 api에 직접 요청했는데 jwt access token 자체에 그 값이 담겨있다보니, 그럴 필요가 없어진 듯 하다
- 그래서 그걸 파싱해서 쓰기로 생각을 하게 됐고 다음주에 그 작업을 진행해야 할 듯 하다
2. 날짜 순서 정렬 관련 문제
- 해당 회사의 최신 인력 정보를 가져오는데, 시퀀스 순서 == DB 들어온 순서 == 날짜 순서 라고 생각해서 그렇게 작성했는데 화면상의 오류가 있었다
- 실제로 확인하니 시퀀스 순서가 데이터 받아온 순서가 아니여서 난 오류였다
- 기존에 year, month 정보가 분리돼있어서 기업별로 partition by year, month 와 같은 쿼리로 작성해 정렬을 했는데, 기존의 쿼리 속도가 너무 느렸어서 year-month를 concat 해서 정렬한 쿼리로 변경했다
업무(데이터 검수 작업)
데이터 검수 작업
- 전사적으로 회사 데이터 검수 작업을 진행했다
- 다같이 같은 업무를 해서 뭔가 대학교 개별 과제 하는 느낌이 낭낭하고 재밌었다(대표님도 하시는게 너무 웃겼다)
- 직접 데이터를 검수하면서 느낀 것은 외부 데이터는 변수가 너무 많고, 찾아가는 방식도 너무 까다롭고 자동화를 하기 어려울 수 있다는 것이었다
- 하지만 뭐 서비스가 그렇다면 해야하지 않겠나..
- 사람마다 분류 기준이 너무 달라서, 전체 데이터를 기준 없이 분류하는 것이 아니라 일부 분류를 해보고 그 기준을 공유한 후 나머지를 하는 것이 효율적이지 않을까 생각하게 됐다
- (그리고 검수 피드백은 익명으로 하는게 좋은 것이 아닐까 하는 생각을 하게 됐다)
그 외 잡담
- 우리 CTO 님이 퇴근길에 같이 가면서 모바일 개발 다음 job으로 뭘 하고 싶냐고 물어봐주셨는데, 하고 싶은게 없다고 힘 빠지게 말했던 것 같아서 후회됐다
- 사실 하고 싶은게 없는거라기 보다는 어떤 일이든 그 무게는 나한테 다 같다고, 그냥 할 일을 하겠다고 정리해서 말했다면 좀 더 기운빠지지 않았을 것 같기도 했는데 그렇게 툭 던진게 집 오면서 너무 후회되고 죄송했다
- 그렇지만 또 이번에 데이터 검수 하면서 해당 데이터 수집 고도화 작업을 하면 어떨까 생각해보기도 했는데 일단 다음주에 티타임 하면 슬쩍 말씀드려야겠다
- 안되면 뭐 시키는 곳 가야지..
