[TIL 17] 프로젝트 중간 회고

 Today I Learned

개발 전 API 명세서

예상 API 명세서

개발 후 API 명세서

---

• 회고

이번 프로젝트에서는 유저 도메인을 맡게 되었다. 현재 개발을 시작한 지는 3일 정도 지났고, 이번 주 월요일에는 Jwt를 사용하여 로그인을 하기 위해 만든 Spring Security Filter에서 문제가 발생하여 팀원분의 도움을 받아 Security 부분을 문제없이 동작하도록 완성하였고, 본격적인 유저 도메인 개발은 화요일부터 수요일까지 이틀 동안 개발을 하여 오늘(수요일) 완성하였다.

아쉬운 점은 아직 Redis를 사용하여 회원 기능을 빠르게 체크하는 기능인 "로그아웃" , "회원 아이디 삭제  ", "권한 변경 승인 및 거절"을 구현하지 못하였지만, 이 기능들은 Redis를 사용하기 때문에 필수 과제가 아닌 추가 도전과제로 분류되기 때문에 일단은 필수 과제를 우선적으로 완성한 후 마지막에 하기로 팀원들과 얘기가 되었다.
유저 도메인을 만들면서 캐시를 어떤 식으로 사용할지 이미 머릿속으로 구상을 해놨기 때문에, 솔직한 내 마음은 유저를 만드는 김에 Redis를 사용하는 기능도 전부 끝내고 싶었지만, 개인이 아닌 팀 프로젝트이고, 아직 다른 필수 과제들이 많이 남았기 때문에 팀에 방향에 따라 다른 필수 기능인 AI 도메인을 먼저 맡아서 만들기로 하였다.

개발 전 API 명세서와 개발 후 API 명세서를 보면 알 수 있듯이 추가된 것들이 많아졌고, 처음 개발 전 API 명세서를 봤을 때는 "이 정도면 하루면 다 하겠지" 라고 생각하고 개발을 시작했지만. 막상 개발을 시작해 보니 생각보다 신경써야 할 것들이 많았다.

유저 도메인을 개발하며 배우고 느낀 점은 다음번 팀 프로젝트에서는 시작 전에 API 명세서와 ERD를 조금 더 섬세하게 만들어야겠다는 생각이 들었고, 도메인을 처음에 개발을 할 때, 우리는 프론트 없이 Postman을 사용하여 검증하기 때문에 만약 프론트에서 회원가입 시 유저 회원가입과, 가게 주인 회원가입이 따로 있을 거라고 생각해서 RequestDto에 권한을 직접 넣어주게 만들었는데 이것이 굉장히 위험한 접근이라는 것을 알게 되었다. 
왜냐하면 이렇게 개발을 했을 경우 MASTER or ADMIN 권한으로 누구든 접근할 수 있으며 이에 대한 방어 로직이 필요하게 된는 것을 알았다.
어찌 보면 당연한 이야기지만 왜 회원 가입을 처음 만들 때 권한 접근에 대한 방어 로직을 생각하지 못했는지 스스로 많이 부족하다는 것을 느끼게 되었다. 그치만 앞으로 이 부분에 대해서는 실수하지 않을 것 같으며 이렇게 하나 또 배운다고 생각하도록 하자.

최종적으로 우리 팀의 회원 가입 정책 방향은 처음 회원 가입 시 모든 유저는 CUSTOMER라는 권한만 부여받게 된다. 이후 CUSTOMER가 OWNER로 권한 업그레이드를 신청하면 "권한 신청 대기 중" 상태가 되며 MASTER의 승인 하에 OWNER로 승격하게 되게끔 로직을 완성하였다.
이렇게 방향을 잡은 이유는 회원의 토큰을 Redis에서 보관하여 DB의 부담을 줄어줄 계획인데 만약 권한이 수정되면 레디스의 권한도 수정되므로 수정된 권한으로부터 토큰을 재발급 받는 로직을 만들기 위해서 이 방향으로 가자고 팀원들에게 건의하고 정책을 정하였다.

내일부터는 AI 도메인을 개발할 예정이며, 구글 AI API 제미나이를 사용하여 상품 등록 시 상품에 대한 설명을 추천받고, 추천을 받기 위한 요청 질문과, AI로부터의 응답 질문을 DB에 보관하는 로직을 만들 예정이다.
제미나이를 한국에서는 잼민이 라고 부른다고 한다ㅎ.. 하하하하😊
처음 만들어 보는 도메인인 만큼 재밌을꺼 같다는 생각이 들고, 이번 주말까지는 개발을 진행하고 다음 주 월요일에 배포를 진행하면 될 것 같다.

---

• Gemini API 

😺 Blog: https://happy-coding.tistory.com/34