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

이미지 전송량 31MB → 1.2MB, CDN과 srcset으로 이미지 최적화하기

WiniLogis와 Autowini의 이미지 리소스에 Akamai Image Manager를 적용해, 이미지 포맷 변환과 리사이즈를 CDN에서 처리하도록 변경했습니다. 이전에 React Core 라이브러리를 분리하고 정적 리소스에 CDN 캐시를 적용했던 작업에 이어, 이번에는 이미지 전송량을 줄이는 작업이었습니다.적용 전 WiniLogis 블로그 목록 페이지를 확인해 보니 PNG 한 장이 1,240kB, 큰 것은 2,326kB였고, 이런 이미지가 20여 장 내려오면서 페이지 한 번 여는 데 이미지만 31MB를 전송하고 있었습니다. 실제 표시되는 카드 크기에 비하면 지나치게 큰 이미지였습니다.포맷 자동 변환Image Manager를 적용하면 CDN이 브라우저의 Accept 헤더를 보고 지원하는 최적 포맷으..

React 프로젝트의 성능 최적화를 위해 React Core 라이브러리를 react-vendor라는 별도 번들로 분리했습니다. React Core 라이브러리를 왜 분리했을까?React Core 계열 라이브러리를 별도의 react-vendor 청크로 분리했습니다.// vite.config.tsbuild: { rollupOptions: { output: { // react 코어 계열만 별도 vendor 청크로 분리 manualChunks(id) { if (/node_modules\/(react|react-dom|scheduler|react-router|react-router-dom)\//.test(id)) { return 'react-vendor'; ..

이미지를 교체해 배포했는데도 사용자 화면에는 이전 이미지가 계속 노출되는 문제가 발생했습니다. 브라우저를 새로고침해도 그대로이고, 다른 PC에서도 한동안 이전 이미지가 표시되는 상황이었습니다. 배포 이후에는 Akamai Purge API를 호출해 CDN 캐시를 항상 무효화하고 있었기 때문에 처음에는 CDN 캐시 문제라고 생각했습니다. 하지만 원인은 예상과 달리 브라우저 캐시에 있었습니다. 이번 글에서는 Purge를 수행했음에도 이미지가 변경되지 않았던 원인을 분석하고, 캐시 버스팅을 적용해 해결한 과정과 Akamai CDN에서도 정상적으로 동작하는지 검증한 내용을 정리해 보겠습니다.Purge를 했는데도 왜 이미지가 변경되지 않았을까?기존에는 공용 스프라이트 이미지를 아래와 같이 고정된 URL로 참조하고 ..

문제를 발견한 계기오토위니 통합검색 페이지는 검색 결과가 표시된 뒤 다음 페이지가 존재하면 하단에 More search results 버튼(이하 More 버튼으로 표시)이 노출되고, 이 버튼을 누르면 다음 페이지의 검색 결과를 이어 붙이는 무한스크롤형 리스트입니다. 그런데 페이지를 확인하던 중 이상 현상을 발견했습니다. 검색 리스트는 아직 비어 있는데, More 버튼만 먼저 떠 있는 것이었습니다. 원인을 디버깅해 보니 이 페이지는 메인 검색 API 외에 보조 API(리스트 중간에 끼워 넣는 추천 매물)를 함께 호출하고 있었고, More 버튼의 노출 조건은 메인 쿼리의 isLoading만 보고 있었습니다. 보조 API 응답이 늦어지면 리스트 병합은 미뤄지는데 버튼 조건은 이미 참이 되어, 버튼이 리스트보다..

문제사항WiniLogis Ocean Freight 상세 페이지에서는 iframe을 통해 YouTube 영상을 재생하고 있었습니다. 운영 중 아래와 같은 QA를 받게 되었습니다."저 동영상 더 보기는 못 숨기려나?, 서비스랑 상관도 없는 영상들인데" 영상을 정지했을 때나 플레이어 하단의 동영상 더보기 영역을 클릭했을 때, 서비스와 전혀 관련 없는 추천 영상이 노출되고 있었습니다. 이전에도 비슷한 문제를 겪은 적이 있었는데, 당시에는 추천 영상 영역 위를 하드코딩된 가림막으로 덮는 방식으로 처리했던 기억이 있었습니다. 하지만 반응형 환경에서는 플레이어 크기가 계속 변경되기 때문에, 단순히 영역을 덮는 방식은 유지보수 측면에서도 좋은 방법이라고 느껴지지 않았습니다. 그래서 다른 해결 방법이 없을까 찾아보다가 ..

이전 글에서 Vitest를 도입해 유틸 함수 단위 테스트 환경을 구축했습니다.이를 통해 전역적으로 사용하는 util 함수에 대한 검증을 마칠 수 있었습니다. 하지만 실제 프로젝트를 운영하면서 몇 가지 아쉬움이 있었습니다.Chrome 외 브라우저 환경은 직접 확인해야 했고, 단위 테스트만으로는 실제 UI가 어떻게 동작하는지까지 검증하기 어려웠습니다. 오토위니 Keycloak 테마 프로젝트에서 Storybook을 활용해 UI를 검증해 본 경험은 있었습니다.하지만 이번에는 단순히 컴포넌트를 확인하는 수준을 넘어, 실제 브라우저 환경에서 사용자 흐름까지 검증할 수 있는 테스트가 필요했습니다. 크로스 브라우징 테스트가 가능하고, 실제 UI 동작을 확인할 수 있으며, 비교적 간편하게 도입할 수 있는 도구를 찾고 있..

이전에 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은 구동 시 프로젝트 전체..