25-02-20

📌 Daily Report

https://github.com/ssginc-be/DOKI/issues/4

📌 프로젝트 상황

이제 남은 기간이 얼마 없다. 프레젠테이션 때 최대의 결과를 보여드려야 하는데 기획에 CRUD가 다 없어서(특히 DELETE) 이게 심사 항목 상 문제가 되지 않을지 걱정이다.

모니터링이나 퍼포먼스 부분들은 내가 하고 싶은 부분인데 뭐랄까, '하고싶다' 레벨을 넘어섰다.

'한다', '안하는 미래는 없다'라는 생각이 더 지배적이다.

솔직히 집중을 위해 집에서 아무와도 상호작용 없이 작업하고 싶다. (상호작용이 있으면 현재 수준의 몰입이 좀 흐트러진다.)

근데 밖에서 이러한 몰입을 유지하도록 연습하는 당장의 환경이 좋은 경험이라고 생각은 한다.

📌 ER Diagram

https://www.erdcloud.com/d/iALeanZK8tosAe79p

다음의 도메인을 drop 했다.

• 결제: 상품, 장바구니, 주문, 결제
• 채팅: 챗봇, 신고
• 권한: 팝업스토어 운영자(MANAGER)

왜냐하면 이전 포트폴리오들의 PR을 통해 해당 도메인은 이미 할 수 있다는 것을 보여줄 수 있을 것 같았다.

권한 부분에 있어선 운영자가 날라가므로 플랫폼 관리자가 문서 상의 팝업스토어 정보를 직접 등록해주는 것으로 기획 변경.

운영자가 날라가면서 회원계정 <-> 팝업스토어 사이의 M:N 관계 중계하는 테이블도 ㅂㅂ 했는데, 중계 자체를 버리긴 싫어서 이를 팝업스토어 <-> 카테고리 관계에 적용했다.

불량이용자 제재는 원래 채팅에서의 불량이용자를 의미했는데, 혹시 여유 시간 생기면 예약에서의 비정상 트래픽 탐지 및 제재로 옆그레이드 할 수 있을 것 같아서 테이블은 남겨뒀다.

늘 그래왔는데, 유난히 automation + tolerance한 시스템에 재미가 느껴진다.

그만큼 정교하게 만들고 싶은데 이것까지는 욕심 같음... 기간이 너무............ 없어도 너무 없음........

결제는 PG 좀 붙여보고 싶었는데 아숩지만 다음에 하면 되지. 잠시 안녕~

📌 회원가입/로그인

기존 아키텍쳐에서 큰 변동사항은 없을 것 같다. auth는 별도의 micro service로 두는 경우가 많긴 한데, 기간 고려하면 지금 그거 분리할 때가 아니다.

분리하면 할수록 service 간의 통신에서 오는 오버헤드나, cross-cutting concerns 부분을 고려하게 돼서, 걍 이 기간엔 안 그러는 것이 맞다고 생각했다.

MSA 아키텍쳐의 당위성을 납득시키려면 해당 부분에 대한 고민이 많아야 하는데, 지금 구현이 0순위라 어쩔 수가 없음.

그래서 기존의 계획은, PT때 기간 상의 한계를 들며 이 부분을 제언하려고 했다. 누가 봐도 MSA라는데 서비스 분리 딱 2개 해놓으면 '???' 싶기 때문에 ㅋㅋ

---

참고 레퍼런스

https://pixx.tistory.com/287 https://pixx.tistory.com/275 -> 요거 내용 좋음. 밥먹으면서 여러번 보셈

이를 통해 flow를 정리하자면,

1. G/W는 filter를 구현해서 끼워넣으면 이걸로 JWT validation을 수행.
2. sign up, sign in, sign out 관련 비즈니스 로직은 controller, service 구현해서 common service로 ㄱㄱ
3. 그리고 겸사겸사 G/W에 routing 넣어야 하는데 이슈 분리하고 싶지만 바쁘니 타협함. (바빠서 하는 타협은 늘 기분이 별로다.)

---

📌 JwtUtil, 어디로 가야하나

validation 부분에서 DB를 한 번 갔다와야 하는데, G/W에서 그럴 순 없고

common service 쪽에 사용자 조회 api를 구현하고 OpenFeign 써야 할 듯! ... 이라고 생각했으나?

그럼 JwtUtil 어쩔거임. G/W랑 common service에 있을때랑 각자 사용자 정보 퍼오는 방식이 다르자늠? (내부 API 호출 vs. JPA 직빵 조회)

해결방안 후보

1. 각각에 맞도록 JwtUtil을 복붙해서 작성하기 -> 아 이건 좀;
2. common service에 JwtUtil 두고 G/W에는 유틸따위 없음 ㅇㅇ 그냥 모든 JWT 관련을 common service에 맡기기

...당연히 2안을 선택했다.

📌 AT 재발급의 최선책은?

현재의 기획으로는, AT와 RT는 모두 쿠키에 들어간다.

그럼 지정한 path에 대해선 둘 다 자동으로 쏘아지고, 서버는 해당 정보를 안다는 것이다.

여기서, 이용자가 플랫폼을 켜두고 잠깐 점심 먹고 왔다고 가정하자.

다시 돌아왔을 때 AT는 만료되었을 것이다. 이 상태로 서버에 request를 보내면, 서버가 검증단에서 만료된 토큰임을 인지한다.

그래. 근데 그 다음은? 추가로 생각을 또 나열해보자.

1. 서버: 401 던짐 -> 클라: 재발급 api 호출 -> 서버: AT 재발급하고 쿠키 세팅 -> 클라: AT 쿠키 갱신됨 -> 클라: 비즈니스 api 재호출
2. 서버: Redis에서 RT 조회 -> 서버: RT 유효하면 AT 재발급하고 쿠키 세팅 + 비즈니스 로직에 대한 결과 반환 -> 클라: AT 쿠키 갱신됨

1과 2중에서 어느 방식으로 할 지 내심 고민이 있었다. 근데 멘토분께서 보통은 서버가 덜 처리하는 방식으로 간다고 하셔서 1안을 선택했다.

따라서 JWT flow는 하단과 비슷하게 될 것 같다.