[개별 멘토링] 2024.11.23 고동우

이번주 문제 해결 경험

1. 로컬에서 쿠키 인증 문제 해결

   우리 서비스는 oAuth 인증을 하면 http only옵션 쿠키로 accessToken을 준다.

   로컬에서 쿠키가 필요한 api 매수 요청을 진행했는데 쿠키가 담기지 않는 문제가 발생했다.

   문제 분석 결과 쿠키의 도메인과 요청하고 있는 웹브라우저 사이의 도메인이 달라서 생긴 문제였다.

   localhost ≠ 111.111.111.11

   브라우저의 SOP(Same-Origin-Policy)에 따라 도메인이 다르면 쿠키가 전송되지 않는다.

   이를 해결하기 위한 방법으로 sameSite 옵션을 None으로 설정하면 크로스 도메인에서도 쿠키를 전달 받을 수 있다. 하지만 우리 알파 서버가 http였어서 sameSite None을 설정하지 못했다. https에서만 sameSite None으로 설정할 수 있다고 한다.

   방법을 찾아보니 vite proxy server를 사용해서 해결하는 방법을 알게 되었다.

   큰 흐름은 다음과 같다.

   1. vite proxy server 설정

   2. 서버로부터 개발용 임시 토큰 발급

   3. 응답 받은 토큰을 직접 js로 쿠키 설정

      쿠키키 domain이 localhost로 설정됨!

   4. api 요청 (웹브라우저 → vite proxy server)

      모두 도메인이 localhost라서 cookie 전송 잘 됨

   5. vite proxy server → 백엔드 서버 쿠키 전송

      서버 간 통신이므로 쿠키가 전송 잘 됨

   이번에 직접 vite proxy server를 사용하고 보니 proxy server가 중개 역할을 해주면서 문제를 해결하는 server라는 것을 이해하게 되었다.

   추가로 포워드 프록시, 리버스 프록시에 대해서도 관련 영상을 보며 학습했다.

   프록시 서버를 통해 캐싱, 로드밸런스 등의 다양한 이점을 주는 것을 알게 되었다.

   결론은 vite proxy server를 활용해 로컬에서도 원활하게 api 테스트를 할 수 있는 환경을 구축할 수 있었다.!

2. Error Boundary 적용 로그인이 되어 있어야 보여줄 수 있는 정보가 있는 페이지에서 인증 기간이 지나면(accessToken이 만료되면) 페이지가 다운되는 문제가 있었다.

   401에러로 관련 데이터를 못받아 와서 생기는 문제인 것 같다.

   로그인이 만료되면 이를 알려주는 페이지가 필요한 것 같았고 Error Boundary를 root에 설정하고 fallback UI를 설정해주었다.

   페이지별로 ErrorBoundary를 세부적으로 설정해서 좀 더 사용성 있도록 구현할 수도 있을 것 같다.

   이는 다음주 작업에 진행해볼 예정이다.

피어세션 기록

• n-gram 검색 방식
• 검색창에 길이 2이상 입력해주세요 메시지 하면 좋겠다
• 이동 평균선 추가되면 더 멋있을 것 같아요

개별 멘토링 기록

1. 테스트 코드를 작성해보는 태스크를 추가해보는 게 좋을까요?

   현재 프론트에서 신속한 개발을 위해 테스트 코드를 작성하지는 않고 있습니다.

   다른 팀들을 보니까 스토리북을 적용해서 테스트코드, 문서화 작업을 하고 있더라구요..

   5주차 개발 작업이 끝나고 6주차 리팩토링 기간에 적용해보는 것도 좋을까요??

2. 컴포넌트가 점점 많아지고 있는 것 같아서 멘토님의 컴포넌트 분리 방법이 궁금합니다.

   예를 들어 StocksDetail에 존재하는 컴포넌트들인데 생각보다 많은 것 같습니다.

   어떤 식으로 분리하는 게 좋을지 궁금하고 멘토님만의 컴포넌트명 짓는 방법도 알고 싶습니다!

3. 페이지에 필요한 데이터를 모두 포함한 api를 호출해서 한 번만 네트워크 요청하는 방식이 일반적인가요??

4. (개인적인 궁금증) 회사에서 요구사항 분석하고 task 나누는 일들은 개발자를 비롯한 팀 구성원들 모두가 같이 진행하나요?? PM이나 PO가 주도적으로 하고 제공하나요??

멘토님 답변

<로컬에서 쿠키 인증 문제> 멘토님께서도 겪었던 문제

쿼리파람으로 tempStr로 임시 토큰을 주는 방식으로 해결할 수도 있다.

localhost의 도메인을 변경해주는 방법도 있다 but, 번거롭다…!

<테스트 코드 적용과 관련해서>

테스트 한 번 적용해보는 것도 좋을 것 같다

프론트 핵심적인 부분 위주로 unit을 쪼개서 진행하는 방식으로?

프로젝트가 끝나고 나서 해도 괜찮을 듯하다.

프로젝트 목표가 도메인을 오픈해서 사용자를 받는 게 목표라면 오히려 페이지 성능 최적화, 버그 해결과 같은 것을 검증해보는 과정이 더 중요할 것 같다.

테스트 코드 도입에 충분한 이유가 있어서 도입하는 것은 더 좋다!

<컴포넌트 나누는 방법>

멘토님께서는 큼지막하게 나누는 것을 선호하는 타입

자신은 차트, 테이블, 주문 섹션 총 세 가지로 나눌 것 같음

각 섹션에서도 컴포넌트가 많아진다면 폴더 세가지로 나눠서 구분하는 것도 좋을 것 같다.

Chart 컴포넌트 대략 40번째~350번째까지 커스텀 hooks로 분리하면 좋을 것 같다.

<반응형 관련해서>

반응형 도전해보는 것도 좋다

차트로 반응형 구현하는 게 어려우면 화면 크기가 작으면 토스처럼 ‘PC로 접속해주세요’라는 화면 띄어주는 것도 좋음

<페이지에 필요한 데이터를 포함한 한 api로 모두 가져오는 게 일반적인지>

충분히 고려해볼만 한 주제이긴 함

근데 현대에서 컴포넌트 별로 api 여러개 보냈다고 그렇게 큰 네트워크 비용 차이가 나지 않아서 멘토님은 컴포넌트별로 여러개 쏴도 괜찮을 듯하다.

<회사에서 요구사항 분석/일정 관리를 어떻게 하나요?>

기획자들이 기획이 끊나면 다같이 공유하는 자리를 가짐

개발 규모가 클 경우 모두 모여 일정 산정하는 시간을 가진다

토스 같은 경우는 사일로, 챕터 문화가 있다.