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

문제를 발견한 계기오토위니 통합검색 페이지는 검색 결과가 표시된 뒤 다음 페이지가 존재하면 하단에 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은 구동 시 프로젝트 전체..

오토위니 서비스에 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 페이지에 직접 접속해야 했습니다.공유..