팀 프로젝트를 끝내고 받은 질문에서 프론트 부분에 해당하는 부분과 그에 대한 내 생각과 답변을 간단하게 정리했습니다.
Q : Netflify를 사용하셨는데, 이유가 궁금합니다! 그리고 사용했을 때 어떤 장점을 느꼈는지도 궁금합니다!
A : 우선 깃헙 페이지와 넷리파이 그리고 버셀 등.. 많은 선택지가 있었는데
최종적으로는 넷리파이를 선택하게 되었습니다.
우선 가장 중요했던 부분인 편의성인데 배포 경험이 미숙한 만큼 사용하기 쉬워야 했습니다.
넷리파이는 현재 꽤나 많은 사용자가 있고 그말은 즉, 생태계가 그만큼 활성화가 되어 있었기 때문에 공식 문서 뿐 아니라 다양한 소스를 확인할 수 있었고 또 공식 문서도 꾀나 친절했습니다.
또한 가장 메리트로 다가왔던 부분은 깃헙에 push만 해줘도 자동으로 빌드와 배포가 진행된다는 점이 있었는데 유지보수할게 많았던 저희 입장에서는 이러한 장점이 더 크게 다가왔었던것 같습니다.
Q : REST API로 Axios를 선택하셨는데요, ajax와 fetch의 차이점이 뭐가 있을까요?
A : 질문의 의도가 아마 비동기 통신을 위해서 질문에 나온 대표적인 3가지로 ajax, fetch, axios 중 axios를 선택한 이유와 ajax와 fetch의 차이가 무엇이냐 인거 같습니다.
우선 질문의 의도와 맞는 옳은 답변은 아닌거 같지만 제가 Jquery 세대가 아니기 때문에 Ajax 사용법이 익숙하지 않습니다. Ajax는 보통 Jquery와 사용해야 조금 더 간편하게 사용할 수 있는 걸로 알고 있는데요, 저희는 리액트를 사용하다 보니 axios를 선택하게 되었습니다.
뿐만 아니라 질문에 나온 차이점으로는 promise 기반인 fetch나 axios와는 달리 ajax는 promise 기반이 아니기 때문에 데이터를 한번 더 정재?해줘야 하는 귀찮음? 불편함?이 있기에 fetch나 axios를 선호하는 편입니다.
그리고 이제 fetch나 axios 중 굳이 내장된 모듈이 아닌 설치가 필요한 axios를 선택한 이유는 익스플로러 서비스가 종료된 현재 이걸 고려해야하나? 싶긴 하지만 분명 크로스 브라우징 이슈에서도 유리해서 호환성이 뛰어난 부분이 있고 더 많은 기능이 있기 때문에 axios를 선택하게 되었습니다.
Q : 깔끔하게 반응형까지 고려하여 UI 구현이 되어있는데, 팀에 전공자가 있었나요? 있었다면 팀 협업에 있어 팀원에게 어떤 도움을 주었나요?
A : 전공자는 아니지만 퍼블리싱 관련된 일을 아주 잠깐 했었던 적이 있습니다.
깔끔하게 UI를 구현했다? 라는 말은 사실 감사하지만 미숙한 부분이 너무 많아서 동의하지 못하는 부분입니다.
레시피를 확인하는 사이트이다 보니 당연하게 데스크탑이나 랩탑을 가지고 주방에서 레시피를 확인하는게 어렵다고 판단했고 그에 따라 모바일 퍼스트로 디자인을 하자고 제안했습니다.
아시다시피 모바일, 테블릿들이 워낙에 다양한 디바이스가 나왔고 그에 따라 너무 많은 뷰포트를 고려해야했기 때문에 가장 기본적인 크기인 375px과 767px을 만을 고려해서 모바일 퍼스트로 디자인을 구현했습니다.
Q : react 사용 이유와 개발 기간
A : 클라이언트 개발을 위해서 저희의 선택지는 바닐라, 제이쿼리 그리고 리액트가 있었는데,
리액트를 선택한 이유에 대한 형식적인 답변으로는 대표적으로 성능을 위한 가상 돔, 컴포넌트의 재사용성 혹은 페이지 전환이 부드럽다 등 이러한 이유가 있습니다 물론 이런 부분들이 중요하지 않다는 건 아니지만 이러한 형식적인 답변보다 가장 크게 와닿았던 부분은 개발자의 입장에서 데이터 바인딩이 쉽다는 점이였습니다.
저희 사이트는 서버 데이터를 화면에 뿌려줘야 하는 로직이 매우 많습니다.
이러한 부분을 바닐라로 구현하고자 한다면 어렵진 않지만 귀찮습니다.
물론 템플릿 리터럴이 나온 현재 그 부분이 조금 완화 되었다고는 하지만 귀찮은건 여전합니다.
이때 리액트의 jsx 구문을 사용해 DOM 조작을 한번이라도 해봤다면 바닐라로 돌아가기는 어려울 것이라 생각합니다. 일반적인 돔 조작보다 더 빠르기도 하고요.
즉, 개발 기간과도 연관성이 있는데요. 빠른 개발을 진행할 수 있고 컴포넌트 별 혹은 페이지 별로 분류하기 때문에 협업에 있어 충돌 문제에 대한 부분에도 유리하다고 판단했습니다.
Q : 리액트 쿼리 사용이유, 리덕스 사용이유가 궁금하네요
A : 클라이언트 개발을 할 때는 상태라는 것을 중요하게 관리할 필요가 있는데요.
저는 클라이언트 개발에서 크게 3가지로 상태를 분류합니다.
로컬 상태와 서버 상태 그리고 글로벌 상태로 분류를 하는데요.
먼저 리액트 쿼리 사용 이유에 대한 답변으로는 위 3가지 상태 중 서버 상태를 관리하기 위함입니다.
즉, 서버의 데이터를 관리하기 위함인데요.
이러면 서버와 클라이언트의 상태를 분류해서 관리할 수 있는 장점이 생깁니다. 즉, 효율적으로 데이터 관리를 할 수 있다는 점입니다.
이 뿐만 아니라 쿼리는 서버 데이터를 관리하기 위한 기능들을 너무 많이 제공해주기 때문에 기존에 불편했던 부분들을 리액트 쿼리를 통해서 해결할 수 있었습니다.
다음으로 리덕스입니다.
리덕스는 글로벌 상태를 분류하고 관리하기 위해 사용하는데요.
조금 더 정확히는 중앙 스토에어서 상태를 관리하기 위함인데, 사실 스코프가 작은 프로젝트의 경우 사용하기를 꺼려했습니다. 저희도 기획단계에서 리덕스를 사용할지에 대해 고민을 많이 했는데요. 러닝 커브가 높고 물론 툴킷 덕분에 완화 되었지만.. 그리고 보일러 플레이트가 꽤나 많다는 점 때문에 고민을 했지만
저희 사이트는 로그인 유저에 대한 권한 확인이 적지 않게 필요했습니다.
이런 상태를 프롭으로 전달하고 관리하자니 프롭 드릴링이 고민이 되기도 했어서 이런 유저 상태에 대한 관리만 전역적으로 관리하자 라는 판단으로 도입을 하게 되었습니다.
해당 답변에 이은 추가적인 코멘트
위에 대한 추가 질문과 답변으로 필자는 상태 관리(서버, 클라이언트)를 분류해서 관리하면 엄청난 장점이 된다고 생각했었는데,
상태 관리를 분류하는 로직이 많아지면 "A상태"는 어디에 어떤식으로 관리하고 사용해야 하는가에 대한 고민도 늘어나기 때문에 무조건 적인 상태 관리 분류는 한번 더 고민할 필요가 있다고 답변을 받았습니다.
Q : 로그인 시 access, refresh 토큰을 로컬 스토리지에 저장하고 있는데 쿠키가 아닌 로컬 스토리지에 저장하는 이유가 있을까요? (유저 정보를 localStorage에 저장한 이유 [동일 질문])
A :
답변하기 가장 부끄러웠던 내용이다
토큰을 탈취 당하면 최악의 경우 만료되기 전까지 계정의 제어권을 빼앗겨 버리는 큰 문제가 생길 수 도 있기 때문에 보안에 신경 쓸 수 밖에 없는 중요한 부분입니다.
어떤 서비스를 제공하는 웹이냐에 따라 다르겠지만 조금 더 안전한 방법으로는 토큰은 자바스크립트로 접근이 불가능 하도록 http only 옵션을 설정해서 쿠키에 저장하는 것이 더 바람직하다 라고 인지하고 있습니다. secure 옵션도 걸어주면 더 좋겠죠.
또 통신 자체를 하이재킹 당하더라도 https로 암호화가 되어 있기 때문에 값을 알아낼 수 없을 겁니다.
물론 이러한 쿠키 또한 CSRF(Cross-Site Request Forgery) 공격에 취약하기 때문에 대비를 해야겠지만요.
그런데 XSS(Cross Site Scripting) 공격에 취약한 로컬 스토리지에 토큰을 저장해서 사용했는데요.
핑계가 되진 않겠지만 우선 기능 구현을 우선시 하자는 마음에 사용하기도 편하고 성능도 좋은 로컬 스토리지를 사용했습니다.
물론 리팩토링을 한다면 해당 부분을 수정하는 걸 가장 먼저 우선사항에 넣을 것 같습니다.
