프론트엔드 개발자 엄성준 블로그

이전에 WiniLogis 프로젝트의 성능 최적화를 진행하면서 코드 스플리팅을 적용한 경험이 있습니다. 기존에는 SPA 특성상 메인 페이지에 접속하면 모든 페이지의 리소스가 하나의 JS 파일로 번들링되어 로드되고 있었습니다.이로 인해 초기 로딩 시 불필요한 코드까지 함께 로드되는 문제가 있었습니다. 이를 개선하기 위해 React의 Lazy와 Suspense를 활용하여 도메인 단위로 파일을 분리하고, 필요한 시점에만 리소스를 불러오도록 구조를 변경했습니다. 그 결과 메인 페이지에서 로드되는 코드 양을 281,862줄 → 63,303줄로 줄이며 성능을 개선할 수 있었습니다. 또한 이외에도 이미지 리소스 최적화, i18n 기반 다국어 처리 개선 등을 함께 진행하며 전반적인 성능 점수와 접근성 점수도 개선할 수 ..

WiniLogis 프로젝트를 작업하며, 사내의 다른 Vite 기반 프로젝트들과 비교해 개발 환경 구동 속도가 39초로 현저히 느리다는 문제를 인지했습니다.특히 코드 수정 시마다 브라우저가 전체 재렌더링되며 흰 화면이 노출되는 등, 개발 흐름을 반복적으로 끊는 비효율이 발생하고 있었습니다. 또한 Jenkins 파이프라인의 빌드 시간이 길어, 코드 반영부터 배포 완료까지의 피드백 루프가 지나치게 늘어나는 문제도 함께 존재했습니다. 이러한 병목 지점을 해소하고 개발자 경험을 개선하기 위해, WiniLogis 프로젝트에 Webpack → Vite 마이그레이션을 진행했고, 그 과정과 결과를 공유하고자 합니다.Vite 선정 이유1. Native ESM 기반의 압도적인 구동 속도Webpack은 구동 시 프로젝트 전체..

기존에 작성했던 React i18n 다국어 처리 빌드 크기 최적화 1 글에 이어지는 내용입니다. 이전 글에서는 프로젝트 내 src 하위에서 관리하던 다국어 파일을 public 디렉터리로 분리하고, i18next-http-backend를 활용해 런타임 시 필요한 언어만 로드하도록 개선하면서 JS 번들 크기와 초기 로딩 성능을 개선한 경험을 공유했습니다. 이번 글에서는 그 다음 단계로, Google Sheet로 관리하던 다국어 데이터를 페이지 단위로 분리해 각 페이지에서 정말 필요한 다국어만 로드하도록 최적화한 과정을 정리해보려고 합니다.key 설계 배경: namespace.key 구조를 미리 선택한 이유이번 최적화는 갑자기 구조를 바꿔서 진행한 작업은 아니었습니다. 실제로 다국어를 처음 설계할 당시부터, ..

WiniLogis는 글로벌 무역 부킹 서비스를 제공하는 플랫폼으로, 블로그를 운영하고 있습니다.현재 블로그의 콘텐츠는 WiniLogis 관리자 사이트를 통해 관리되지만, 단순 텍스트만 입력할 수 있다는 문제가 있어 다른 플랫폼에서 운영하는 블로그에 비해 가독성이 떨어지는 문제가 있었습니다. WiniLogis 관리자의 블로그 글 작성 시 가독성 문제를 해결하기 위해, 텍스트 에디터를 도입하여 글을 편집할 수 있도록 개선한 방법에 대해 작성하려고 합니다.먼저 React 프로젝트와 잘 어울리는 텍스트 에디터를 찾기 위해 여러 정보를 조사했습니다. 아래 글을 통해 다양한 텍스트 에디터의 종류를 확인하고, 각 에디터의 장단점을 비교하여 최종적으로 적용할 에디터를 결정했습니다.https://code-b.dev/bl..

먼저 기획서에서 모바일 화면일 때 3줄 이상의 문장일 경우 Read more 버튼이 보이게 해 달라는 요청이었습니다.저는 이 요구사항을 충족시키기 위해 모바일일 경우 특정 길이 이상일 때 Read more 버튼이 보이게 직접 구현했었습니다.하지만 이때 문제점은 영어와 한글이 섞여있거나 A, b와 같이 문자열의 너비 차이 등등 여러 가지 문제 점이 등장했습니다. 이 문제를 해결하기 위해 구글 검색을 정말 많이 했었는데 딱히 마음에 드는 해결방법을 찾지 못하던 중이었습니다. 하지만 계속된 노력 끝에 WiniLogis에서 사용 중인 기술스택에 적합한 라이브러리를 찾게 되었습니다.https://www.npmjs.com/package/react-show-more-text react-show-more-textThe..