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

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

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

오늘 프로젝트 QA처리 도중 개발 서버와 실서버 모두 같은 이름의 사용자를 띄워줘야 하는 상황이 있었습니다. 이때 같은 이름의 사용자를 불러오는 key가 staffId였는데 개발서버와 실서버의 staffId값이 서로 다른 상황이라 구분을 해줄 수 있어야 했습니다. 이때 참고 한 문서가 아래의 링크입니다. https://ko.vitejs.dev/guide/env-and-mode.html Vite Vite, 차세대 프런트엔드 개발 툴 ko.vitejs.dev import.meta.env.MODE -> 이 문구를 console.log()로 찍어보면 개발 환경일 때는 즉 local인 경우에는 'development'를 출력하고 개발 환경이 아닌 경우에는 ‘production'를 출력한다. 이를 통해 문제를 해결..

우리 팀의 프로젝트는 Front는 React -- ts를 통해서 구성하고 Back은 Spring boot를 통해서 구상하기로 하였다. Back-end 분들은 작업 Tool로 Intellij를 이용하시고 Front는 VScode를 이용하기로 하였다. 먼저 Project를 구축하기 위해 https://start.spring.io/ 접속하였다. 예전에 김영한 선생님 강의를 볼 때 제외하고 처음이었다. Group명을 제외하고 나머지는 이렇게 작성한 듯싶다. 그 후 GENERATE를 통해서 파일을 내려받았다. 그 후 아래의 링크의 내용을 적어주신 분의 글을 참고하여서 개발환경을 구축하였는데 https://velog.io/@u-nij/Spring-Boot-React.js-%EA%B0%9C%EB%B0%9C%ED%99..