벌써 첫 번째 팀 프로젝트가 끝났다! 다행히 팀원들은 기술 숙련도도 높아보이고, 이해도 등 다양한 관점에서 나보다 훨씬 좋은 분들인 것 같아서 웬지 모르게 많은 믿음이 갔다. 각자 밸런스도 좋았고 너무 즐겁게 코딩도 하고 리뷰도 할 수 있어서 만족스러웠다. 그만큼 성장도 많이 한 것 같다!! 날 잘 이끌어주신 팀원분들께 너무 감사하다.
우선 프로젝트 결과물부터 공개한다 ㅎㅎ
데브나무 배포 링크
프로젝트를 진행하면서 들은 생각과 고민
유저 정보를 어떻게 관리해야 하는가
내가 맡은 부분은 회원가입, 로그인 등 유저 정보 관리였다. 로그인 후 axios interceptors에 필요한 토큰을 로컬 스토리지에 넣고, 유저 정보는 zustand 스토어에 우선 저장을 했는데, 유저 정보 상태관리를 클라이언트에서 하는게 맞는가? 서버 상태 관리인 react-query를 쓰는데 이렇게 된다면 너무 구분 없이 혼용되지 않을까? 하는 의문이 계속 들었다. (코드 리뷰에도 왜 필요한지에 대한 의문을 팀원에게 받았다.) 우선은 다양한 라이브러리를 사용해보고 싶었기 때문에 유저 정보를 저장하기까지 구현하고 필요가 없다 싶으면 걷어내기로 하고 넘어갔다.
그런데 유저 정보를 다 넣은 상태인데, 새로고침하면 어차피 전부 날아가게 된다는 문제점이 있다. 스토어에 다시 저장하려면 어차피 서버에 요청을 또 다시 해야하는데.. 클라이언트 쪽에서 관리하는 의미가 있을까..? 하는 의문점이 들게 되었다. zustand는 redux와 동일한 Flux 형식이기 때문에 새로고침 관련한 기능을 redux에 있는지 찾아보았는데 redux-persist가 있는 것을 확인했고, zustand에도 있는지 찾아보았는데 다행히 있었다. 그러나 스토리지에 저장하는 형식이기 때문에 유저 정보를 스토리지에 저장하는게 맞을까? 하는 생각이 들었다.
이어서 스토어에 저장되어 있는 상태를 참조할 때 스토어에 저장할 user 객체가 null로 뜬다면 로컬 스토리지에 저장되어 있는 토큰을 이용해서 유저 정보를 다시 불러오는 api를 호출해 정보를 다시 받아와 스토어에 저장하는 로직을 추가하려고 했다. 그러나 위에 든 의문과 같이 api 호출을 안하기 위해 전역 상태로 관리하려고 했으나 어차피 스토어는 게속 날아갈거고 api는 계속 호출되어야 할텐데 이 상황에서는 api 호출을 안 할 수가 없기에 굳이 스토어에 저장할 필요가 있을까? 쓸모없는 로직이 추가되고 있는게 아닐까? 라는 생각이 들어 스토어에 저장하지 않기로 결정했다.
결국 유저 정보를 불러오는 api 훅만 구현하여 그때그때 사용하기로 결정났다.
모달 전역 상태관리
현재 우리 데브나무 서비스에서는 모달의 종류가 로그인, 회원가입, 프로필 변경, 이용 방법이 있다. 따라서 이번에야 말로 zustand를 사용해야겠다.. 라고 생각했는데? 팀원님과 멘토님이 토스 슬래시 라이브러리인 useOverlay를 추천해주셨다.
찾아보니 <OverlayProvider>로 모달을 App을 감싸주면 내부에서 자동으로 모달을 전역 상태관리 해주는 라이브러리였다. 사용법도 간단하고 내가 굳이 스토어에 상태를 또 생성할 필요 없기 때문에 바로 사용하기로 했다.!
input 태그의 autocomplete 속성
input 태그에 autocomplete 속성을 지정해주지 않았더니 경고가 떴었다. 자동완성 관련이기 때문에 여기에서도 어디까지 자동 완성을 허용해야하지? 고민했다. 이메일 같은 경우는 그때마다 바뀌는 것(ex. 닉네임)이 아닌 자주 쓰는게 있으니 켜두는게 맞을 것 같은데 이름, 닉네임, 비밀번호 같은 경우는 어떻게 처리해야할지 궁금했는데 팀원이 보통 이름 같이 고유한 값을 입력할 경우엔 autocomplete를 off 해둔다고 조언해주셨다.! 이런 세세한 속성 관련에서도 고민해볼 수 있어서 좋았다.
프로젝트를 하며 느낀 성장과 성찰
사용하는 라이브러리를 잘 쓰기 위한 고민을 할 수 있게 되었다.
기술을 이용하기 위해 고려해야할 부분 등 생각의 폭이 넓어지고, 이 라이브러리가 왜 나오게 되었는지에 대한 이해를 조금 할 수 있게 된 것 같다. 유저 정보를 저장하기 위해 클라이언트 상태 관리인 zustand를 이용해야 하는지 관련하여 생각해보며, 이때까지는 써보고 싶으니까 써보자! 요즘 이거 많이 쓰던데? 하면서 사용해 본 것이 다인데, 나름대로 어떨 때 쓰는게 좋은지와 역할에 대해 생각해보는 계기가 되었다. 라이브러리를 잘못 쓰게 된다면 과연 그걸 써봤다고 내세울 수 있을까? 이 라이브러리를 쓴게 잘한 것인가? 하는 생각이 들기도 해서 로그인, 회원가입이 별 거 아닌 것처럼 보여도 유저 정보는 민감한 정보이기도 하고, 나에게는 많은 것을 생각해볼 수 있는 기회가 되어 좋았다.
웹 접근성에 대해 더 잘 알 수 있게 되었다.
UI 작업을 하다가 버튼에 아이콘만 넣고 이 요소를 설명할 텍스트가 존재하지 않는 코드가 있었다. 팀원이 코드 리뷰를 해주셨는데 aria-label 속성을 통해 스크린 리더 사용자는 어떤 버튼인지 알 수 있다고 말씀 주셨다. 화면에 현재 요소를 설명할 텍스트가 없을 경우에 사용하는 설명용 텍스트를 담을 수 있다고 해서 다음부터 고려해야겠다고 생각했다.
이어서 이용 모달을 만들다가 내가 원하는 곳에서 문장 띄우기(enter)를 해주고 싶었고, 무지성 br 태그를 남발해서 UI 작업을 한 적이 있었다. 그런데 팀원이 br 태그 사용하면 스크린 리더에서 끊어진다고 하셨다. span 태그에 display: block 속성을 추천해주셨으나 내가 원하는 곳에서 엔터를 넣고 싶었기 때문에 .. white-space: pre-wrap을 적용해보려고 했으나 잘 되지 않았고, 배포가 급해서 결국 단락 별로 p 태그로 묶게 되었다. 후에 다시 white-space: pre-wrap을 적용해보아야겠다. 웹 접근성 마스터인 팀원 덕에 많은 것을 알게 되었다!!
코드 리뷰에 자신감은 중요하지 않다는 것을 깨달았다.
팀원들이 리뷰를 워낙 잘 달아주셔서 꼼꼼한 리뷰가 가능했다. PR 설명에도 어떤 부분을 구현했는지, 스크린 샷이나 동영상을 첨부해주셔서 이해가 쉬웠다. 논리적인 부분에서의 리뷰는 아직 부족하지만 팀원의 코드를 배우고, 칭찬만 하던 과거에 비하면 많이 꼼꼼해진 것 같다. 팀원분들이 꼼꼼하게 내 코드를 봐주셔서 나도 더 잘 봐드려야지!! 하는 생각에 더 노력한 것 같다.
팀원분들은 숙련도가 더 있어서 코드 리뷰에 시간이 덜 걸리는줄 알았는데 우연히 대화를 하다 본인들도 코드 리뷰가 오래 걸리는 편이다 라고 말씀 주셔서 알게 되었다. 나는 코드 리뷰가 너무 오래 걸리기 때문에 다른 분들께 미루는 경우가 있었는데 코드 리뷰에 시간 투자를 많이 해주신다는 것을 듣고 엄청 반성하고 부끄러웠다 ..
사실 처음에 팀원들의 코드를 보아도 칭찬 말고는 리뷰를 잘 달아주지 않았다. 이유는 팀원들 실력이 좋은데 내 리뷰가 과연 도움이 될까? 하는 자신감 문제였다. 그래서 리뷰를 뜸하게 하다가 팀원들도 코드 리뷰에 많은 시간을 할애하고, 어떤 리뷰가 좋은 리뷰인지 고민하는 모습을 보면서 뒤늦게라도 열심히 참여했다. 그러나 팔로업이 늦어진 상태여서 코드의 흐름을 따라가기 어려운 상태가 되어버려서 반성을 더 많이 하게 되었다.
팀원들은 프로젝트 후반부에 다들 지쳐있을 때 열심히 코드리뷰를 해주는 나에게 감사함을 표현해주었지만 나는 너무 죄송스럽고 후회스런 마음이 들었다. 다음 프로젝트에서도 도움되는, 꼼꼼한 코드리뷰를 할 수 있도록 해야겠다.
생각이 너무 많아 개발이 지체될 때는 팀원에게 도움을 요청하자
회원가입, 로그인이 얼른 완료되어야 후에 팀원들이 작업을 할텐데 초반에 유저 정보를 관리하는 부분에 있어서 너무 많은 생각을 갖고 있었기에 개발 시간이 조금 지체된 것 같아서 반성을 많이 했다. 나보다 개발 실력이나 경험 면에서 더 많은 팀원들이 있음에도 불구하고 혼자 끙끙대다 찜찜한 채 PR을 올리게 되었는데, 결국 리뷰에서 팀원들이 많은 도움을 주셔서 생각이 바로 잡히고 팀원과 함께 이야기하며 해결할 수 있었다. 해결이라기 보다는 유저 정보를 어떻게 관리할 것인가에 대한 논의사항이 필요했고, 이를 정할 수 있었다에 더 가까운 것 같기는 하다.
따라서 다음부터는 고민이 되는 상황이거나 팀원 다 같이 논의해야할 만한 상황이라고 생각되면은 지체없이 도움을 요청하야 겠다고 반성했다. 실제로 팀원들이 새벽까지 라이브로 본인 문제를 보여주고 함께 뛰어들어 해결해주려는 모습을 보면서 방법이 보이지 않는 끙끙거림은 하지 말아야겠다고 생각했다! 그리고 나 또한 팀원이 어려움을 겪으면 함께 해결해주려고 노력해야 겠다.
