[개별 멘토링] 2024.11.24 서산
- 쉬운 시작을 위해 목차를 분리하여 제공합니다.
- 성장을 종합적으로 기록하는 데 익숙해진 이후에는 각자의 형식을 갖춰봐도 좋을 것 같습니다.
1시간동안 차분히 회고하며 정리해보세요.
“문제”의 범위는 어디까지 일까요? 이번주에 내가 가장 해결하고자 집중한 것이 있다면 무엇이든 문제가 될 수 있습니다.
“해결 경험”을 미래의 나와 동료/멘토가 이해할 수 있게 정리해보세요. 문제의 배경과 맥락, 문제에 접근한 방법과 해결 과정, 그 결과를 상세히 포함하면 좋습니다. 나아가 이 과정에서 좋았거나 아쉬웠던 점도 회고해보세요.
참고할만한 외부 링크가 있다면 함께 기록해두어도 좋습니다.
KakaoTalk_Video_2024-11-16-16-49-17.mp4
위에 보이는 동영상처럼 한글 입력 후 스페이스바, 방향키, 엔터키, 클릭 이벤트 발생시 Debounce가 한번 더 발생하는 문제가 있었다. 해당 이슈는 Safari 브라우저에서만 발생했고 Chrome 브라우저에서는 발생하지 않았다. 따라서 이 이슈가 브라우저의 차이에서 발생한다고 판단했고 브라우저마다 한글 입력을 처리하는 방식에 대해 학습을 진행했다. 자세한 학습 내용의 경우 아래 링크를 참고하면 된다.
이제 현재까지 파악한 상황을 말하면 Safari의 경우 간헐적으로 발생하고 있다. 개인 로컬 설정도 관련 없고 Safari 버전도 관련이 없다는 것을 확인했다. 또한 Safari에서 문제가 발생할 경우 토스 증권 사이트에서도 동일하게 Debounce가 한번 더 발생하는 것을 확인할 수 있다. 그리고 Safari의 경우 해당 문제를 겪는다고 해도 한번 PC를 껐다키면 문제가 해결되는 것을 확인할 수 있다.
또한 현재 Mac용 Chrome에서는 문제가 발생하지 않지만 Window용 Chrome에서는 해당 문제가 발생하는 것을 확인했다.
개발을 하다보니 아래와 같은 문제를 마주치게 되었다. 아래 문제는 useEffect 내부에서 사용하는 요소가 의존성 배열에 없기 때문에 발생하는 문구인데 단순하게 의존성 배열에 해당 함수나 값을 넣게 되면 무한 렌더링이 발생할 수 있다.
해당 내용에 대한 상세한 내용은 아래 링크에 있다.
useEffect의 의존성 배열 관련 경고를 무시하더라도 코드는 정상적으로 작동한다. 하지만 이는 useEffect가 실행될 때마다 불필요하게 함수가 재선언되는 문제를 초래할 수 있다. 이러한 문제를 해결하기 위해 useCallback을 사용하여 함수를 메모이제이션하고, 이를 의존성 배열에 포함시키는 것이 권장된다. 하지만, useCallback을 과도하게 사용하면 오히려 메모리 사용량이 증가하고 성능이 저하될 수 있으므로, 실제로 최적화가 필요한 경우에만 선별적으로 사용해야 한다.
차트 고도화를 하는 작업이 이번주에 가장 많은 시간을 투자한 작업이었다.
차트 고도화는 우리가 켄버스에 그렸던 차트에 실재 주식 차트에 존재하는 기능들을 추가하는 것을 의미한다.
우선 차트 고도화에 앞서 이미 가장 많이 사용 중인 TradingView 라이브러리가 어떻게 출력이 되는지 확인했다. 그런데 TradingView의 경우 상단 차트, 하단 차트, X축, 상단 Y축, 하단 Y축 각각 서로 다른 켄버스에 그리고 있다는 것을 알 수 있었다. 그래서 생각을 해보았더니 차트의 비율을 조정하는 기능을 위해서는 반드시 켄버스를 나눠서 그려야함을 알 수 있었다. 따라서 우선 현재 1개의 켄버스에 모든 것을 그리고 있던 코드를 하나하나 분리하는 작업을 진행했다. 1개의 차트 내에서 선차트, 캔들차트, 막대차트, X축,Y축, 격자선 등등 많은 것들을 하다보니 생각보다 분리하는 작업이 오래 걸렸다.
분리하는 작업을 마치고 차트 화면 비율을 사용자가 동적으로 수정하는 기능을 구현하니 생각보다 금방 완료할 수 있었다. 하지만 문제는 마우스 위치에 따른 차트 값을 출력하는 부분이었다. 현재는 마우스 위치를 useState 상태로 저장하여 이를 켄버스에 반영하는 방식으로 진행 중인데 이렇게 만드니 마우스 위치에 따라 매번 해당 컴포넌트가 리렌더링 되게 되었다. 물론 버벅임 없이 잘 수행되지만, 타 서비스를 확인했을 때 차트 위에서 마우스를 움직여도 해당 차트 부분이 리렌더링이 되지 않는 것을 보면 최적화하는 방법이 있을 것이라고 생각된다.
동료와 공유하거나 의견을 묻고 싶은 부분을 정리해보세요.
피어세션에서 나눈 이야기 중 나의 문제 해결 경험과 관련한 피드백과 새롭게 깨달은 점이 있다면 기록으로 남겨주세요.
멘토에게 전달하고 싶은 이야기를 정리해보세요. 개별 멘토링 24시간 전에 멘토가 미리 내용을 보고 올 수 있도록 공유해야 합니다.
개별 멘토링 이후에는 멘토와 나눈 이야기가 휘발되지 않도록 기록해보세요.
현재 위에서 언급했던 한글 Composition이 정확하게 window Chrome에서만 발생하는 것으로 확인했습니다.
그런데 이게 제가 window PC가 없어서 직접 확인하면서 개발할 수 없는 상황인데 현업에서는 이렇게 직접 확인할 수 없는 문제의 경우 어떻게 확인하면서 개발을 진행하나요?
⇒ 최대한 찾아보고 어쩔 수 없는 부분은 known issue로 두고 넘어가는 것도 방법이다. 실재로 현업에서도 해결할 수 없는 부분은 known issue로 두고 넘어가는 경우가 있다. 그리고 현업의 경우 여러 디바이스가 대체로 있기 때문에 이렇게 확인이 되지 않는 문제의 경우 드물다.
차트 고도화가 앞으로 좌우 스크롤 정도랑 많게는 확대까지 진행할 수 있을 것 같다고 생각됩니다.
만약 이렇게 완성했을 때 어느정도 완성도가 있어 보일지 아니면 차라리 라이브러리를 사용하는게 나을뻔 했다는 말을 들을지 걱정됩니다.
⇒ 걱정 안해도 될듯함. 우리가 학습을 목표로 차트를 라이브러리 없이 직접 구현하고 있고 이 과정에서 많은 것을 얻었기 때문에 그것만으로도 충분히 좋은 선택이었다고 생각한다.
제가 웹 최적화를 해본 경험이 없어서 어떤 부분을 신경 쓰는게 최적화를 하는 것인지 잘 모르겠습니다.
일단 현재는 lighthouse를 이용해 경고 문구를 최대한 줄이는 방향으로 생각하고 있는데 최적화를 한다고 하면 어떤 부분을 살펴보는 것인지 궁금합니다. 그리고 현업에서도 어떻게 진행하는지 궁금합니다.
⇒ 현업의 경우 문제가 생겼을 경우 문제에 맞게 해결하는 편이다. 예를 들어 로딩이 너무 오래걸리고 원인이 이미지의 크기라면 이미지 크기를 줄이는 작업을 진행하고 페이지네이션이 없어서 발생한 문제라면 페이지네이션을 추가하는 방식으로 진행된다.