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

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 구조를 미리 선택한 이유이번 최적화는 갑자기 구조를 바꿔서 진행한 작업은 아니었습니다. 실제로 다국어를 처음 설계할 당시부터, ..

프로젝트 배경 및 개발 동기Autowini에서는 React로 분리 및 개선한 프론트엔드 프로젝트들이 여러 개 존재합니다.대표적으로 web-www-front (오토위니 웹), web-mobile-front (모바일 웹), web-admin-front (관리자 페이지) 등이 있습니다.기존 JSP 기반 페이지들 중 방문자 수가 많고 이슈가 잦은 페이지부터 차례로 React로 분리 및 개선 작업을 진행하고 있었습니다. 이 분리된 React 페이지들은 IDC 서버에 업로드된 빌드 결과물을 서비스하는 구조로, 기존에는 개발이 완료된 후 develop 브랜치에 머지하고, CLI를 통해 직접 IDC에 빌드 파일을 업로드하는 방식으로 운영하고 있었습니다.하지만 혼자 개발하는 환경이라면 문제가 없겠지만, 휴가 시 사수가 ..

프로젝트 내 다국어(i18n)를 관리하다 보면, 기능이 변경되거나 삭제될 때마다 사용하지 않는 번역 키가 남게 됩니다.이번에는 WiniLogis 프로젝트에서 점점 쌓여가던 불필요한 다국어 키를 정리한 과정을 공유하려고 합니다.❗️ 문제 상황WiniLogis에서는 Google Cloud Sheet를 기반으로 다국어를 관리하고 있습니다. 개발 환경에서는 스크립트를 통해 Sheet에 작성된 다국어 데이터를 public/locales/{언어}/translation.json 형태로 변환하여 저장합니다.public/ └─ locales/ ├─ en/translation.json ├─ es/translation.json └─ ru/translation.json 그러나 프로젝트가 커지고 여러 기능..

web-www-front는 오토위니(AutoWini)에서 기존 JSP 기반의 레거시 페이지를 React로 분리 및 개선하기 위해 만들어진 통합 프로젝트입니다. 현재까지 분리된 주요 페이지는 다음과 같습니다.필터 검색 페이지통합 검색 페이지찜 목록 페이지 (마이위니)운송 정보 제공 페이지파츠위니 통합 검색 페이지파츠위니 필터 검색 페이지이 프로젝트를 진행하면서 “테스트 코드를 도입할 필요가 있을까?”라는 질문을 스스로에게 던지고 있었습니다.🤔 테스트 코드, 정말 필요한 걸까?최근 여러 기업들의 채용 공고를 보면 "테스트 코드 작성 경험"이나 "TDD 경험자 우대"라는 문구를 자주 볼 수 있습니다.저 역시 Toss의 es-toolkit과 NaverPay의 hidash 라이브러리에 테스트 코드 및 벤치마크..