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

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

최근 Android 네이티브 앱에서 WebView로 표시되는 페이지의 문제를 확인해야 하는 상황이 있었습니다. iOS의 경우 Mac을 사용하고 있었기 때문에 Safari의 Web Inspector를 이용하면 비교적 간단하게 WebView 디버깅을 진행할 수 있습니다.Mac에서 Safari의 개발자 메뉴를 활성화한 뒤 iPhone을 연결하면 실행 중인 WebView를 바로 확인하고 디버깅할 수 있기 때문입니다. 반면 Android에서는 Chrome DevTools의 Remote Debugging 기능을 사용해야 합니다. Android 기기에서 USB Debugging을 활성화한 뒤 Mac과 USB로 연결하고, Chrome에서 다음 주소로 접속했습니다.chrome://inspect/#devices 정상적으로..

Frontend Kit은 프론트엔드 면접 질문을 플래시카드 형태로 학습할 수 있도록 만든 PWA 웹앱입니다.기존에는 면접 질문을 학습 하기 위해 잘 정리된 GitHub 저장소나 블로그를 직접 북마크 하여 학습했지만, 모바일 환경에서 더 편하게 학습하기 위해 카드 기반 UI로 재구성했습니다.초기 버전은 복습 중심 구조였습니다.스와이프 / 버튼으로 카드 넘기기답변 슬라이드 애니메이션으로 공개6개 카테고리 필터 (CS, HTML/CSS, JavaScript, React, 자료구조, 알고리즘)랜덤 셔플 모드다크모드 / 라이트모드글자 크기 조절 (소 / 중 / 대)키보드 단축키 (← →, Space / Enter)PWA 지원 (홈 화면 추가, 오프라인 접속)하지만 사용하면서 한 가지 한계가 명확해졌습니다. 학습을..

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

오토위니 서비스에 Keycloak을 도입하며 로그인 화면 커스터마이징을 진행했습니다. 국내 자료가 부족해 구현 과정에서 겪었던 경험과 Keycloakify를 통해 15개국 다국어 대응을 완료한 과정을 공유합니다. Keycloakify 선정 이유Keycloak 로그인 화면은 기본적으로 FTL(FreeMarker Template Language) 문법을 사용합니다. 하지만 추후 프로젝트의 유지보수를 고려해 Keycloakify 프레임워크를 선택했습니다.가장 큰 이유는 팀원들에게 익숙한 React(JSX) 문법을 그대로 사용할 수 있다는 점이었습니다. 러닝 커브를 줄이고 기존에 사용하던 라이브러리들을 활용할 수 있어 개발 생산성 측면에서 유리하다고 판단했습니다.1. 클라이언트별 테마 분기 (clientId)단..

현재 제 포트폴리오 프로젝트는 Next.js와 Supabase를 기반으로 구축되어 있으며, Vercel을 통해 배포 및 관리되고 있습니다. 그동안 Lighthouse 점수 개선, SEO 최적화, 이미지 최적화 등 프론트엔드 개발자로서 할 수 있는 다양한 최적화 작업을 진행해 왔습니다. 그 결과 성능 97, 접근성 85, SEO 100이라는 준수한 지표를 얻을 수 있었습니다. 하지만 지표와는 별개로, 실제 페이지 진입 시 질문 데이터를 불러오는 과정에서 이해하기 힘들 정도의 로딩 지연이 발생했습니다. 이번 글에서는 코드 레벨을 넘어 인프라 설정(Region)을 통해 이 문제를 해결한 과정을 공유합니다.왜 성능 지표는 좋은데 체감 속도는 느렸는가?Lighthouse는 정적 리소스 로딩과 초기 렌더링 성능..

현재 오토위니에서는 React 기반으로 대부분의 프론트엔드 프로젝트를 분리하여 운영하고 있습니다. web-www-front, web-mobile-front, web-mobile-search, web-admin-front 등 다양한 프로젝트가 Bitbucket Pipelines를 통해 자동 빌드 및 배포되고 있습니다. 지난 1편에서는 파이프라인 구축 과정을 다루었다면, 이번 2편에서는 배포 성공·실패 결과를 팀원들에게 실시간으로 공유하여 운영 효율을 높인 '알림 자동화' 과정을 공유합니다.왜 배포 알림이 필요했는가?기존 파이프라인은 자동화되어 있었지만, 결과 확인 방식에는 한계가 있었습니다.정보의 파편화: 배포 결과를 확인하려면 매번 Bitbucket Pipeline 페이지에 직접 접속해야 했습니다.공유..

이번 글에서는 Autowini 필터 검색 페이지의 좌측 Accordion 메뉴에서 발생한 UX 문제를 계기로, TanStack Query의 placeholderData 옵션을 활용해 구조를 개선한 리팩토링 경험을 정리해보려 합니다. 문제 상황Autowini 필터 검색 페이지의 좌측 영역은 Accordion UI로 구성되어 있으며, 필터 조건이 변경될 때마다 서버에서 필터 데이터를 다시 조회하도록 구현되어 있었습니다. 이 과정에서 다음과 같은 UX 문제가 발생했습니다.필터 파라미터 변경API 재호출로딩 중 data가 undefinedAccordion 내부 리스트가 비어짐모든 메뉴가 접혔다가 다시 펼쳐지는 현상 발생사용자 입장에서는 필터를 조작할 때마다 화면이 깜빡이거나 필터가 초기화되는 것처럼 느껴졌습니다..

안녕하세요, 프론트엔드 개발자 엄성준입니다. React 기반 SPA 환경에서 SEO 최적화를 위해 react-helmet이나 react-helmet-async는 사실상 표준처럼 사용되어 왔습니다. 저 역시 개인 프로젝트와 사내 서비스에서 이 라이브러리들을 꾸준히 활용해 왔습니다. 하지만 실제 서비스 환경을 운영하며, index.html에 정의한 초기 메타 태그와 페이지 이동 시 동적으로 생성되는 메타 태그가 중복되는 문제를 발견했습니다. 이 글에서는 기존 라이브러리의 한계와 이를 해결하기 위해 직접 react-head-safe를 개발하게 된 과정을 공유합니다.1. SPA 환경에서 SEO가 여전히 까다로운 이유React SPA는 초기 로딩 시 서버로부터 빈 HTML(root div만 존재하는)을 전달받습니..

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