docs: 2026-04-29-fontend update

Author: TreeStone94

_posts/frontend/2026-04-29-frontend.md

@@ -7,11 +7,11 @@ mermaid: true
 categories: [Blogging,frontend]
 ---
 
-신입 때 처음 이 프로젝트를 접했을 때부터 빌드 시간은 분명한 불편이었습니다.
+신입 때 처음 이 프로젝트를 접했을 때부터 빌드 시간은 개발하는데 있어 불편이었습니다.
 ![스크린샷 2026-04-29 오후 4.28.12.png](/assets/img/frontend/2026-04-29-frontend-06.png)
 _레거시 UI 프로젝트 사용자 수_
 
-여러 팀이 개발하는 메인 레거시 UI 프로젝트입니다. 시간이 지나도 상황은 변하지 않았습니다, 어느 순간부터는 모두가 그 불편에 맞춰 일하고 있었습니다. 로컬 개발을 하려면 사용하지 않는 서비스 라우터를 주석 처리해야 했고, 개발기 검수는 빌드가 끝날 때까지 기다려야 했습니다.
+여러 팀이 함께 개발하는 메인 레거시 UI 프로젝트입니다. 프로젝트를 개발할때에는 모두가 그 불편에 맞춰 일하고 있었습니다. 로컬 개발을 하려면 사용하지 않는 서비스 라우터를 주석 처리해야 했고, 개발기 검수는 빌드가 끝날 때까지 기다려야 했습니다.
 
 저는 이 상황을 "프론트엔드 빌드가 느리다"보다 조금 다르게 봤습니다. 개발 흐름 전체를 막는 병목에 가까웠습니다.
 
@@ -41,11 +41,11 @@ _레거시 UI 프로젝트 사용자 수_
 실제 기능 개발은 여러 역할을 거쳐 진행됩니다. 기획자가 새 기능을 기획하면 디자인팀이 화면과 상태를 정의하고, 마크업팀은 그 디자인을 받아 UI를 구성합니다. 이후 개발자는 기획을 검토하고 백엔드 개발이 필요한지 확인합니다. API나 데이터 처리 작업이 먼저 필요한 경우에는 백엔드 작업 결과가 나온 뒤, 프론트엔드에서 마크업을 확인하며 기능을 연결합니다.
 
 기능 개발이 끝나도 개발기 빌드에 40~50분이 걸리니 QA팀은 바로 검수를 시작하지 못했습니다. 개발자는 빌드가 끝났는지 확인한 뒤에야 검수를 요청했고, QA 피드백이 돌아오는 시간도 자연스럽게 뒤로 밀렸습니다.
-빌드 시간은 개발자 한 명의 대기 시간으로 끝나지 않았습니다. QA 요청, 검수, 운영 반영, 운영 검수까지 이어지는 피드백 루프 전체를 늦추는 병목이었습니다.
+빌드 시간은 개발자 한 명의 대기 시간으로 끝나지 않았습니다. QA 요청, 검수, 운영 반영, 운영 검수까지 전체를 늦추는 병목이었습니다.
 
 ![image.png](/assets/img/frontend/2026-04-29-frontend-03.png)
 
-제가 이 작업을 통해 보여주고 싶었던 것은 “프론트엔드 잘 안다”가 아니었습니다. 제 주 업무는 백엔드에 더 가깝습니다. 다만 이 문제는 특정 프론트엔드 기술 하나의 문제가 아니라 협업 흐름의 문제였고, 그래서 빌드 도구를 바꾸기 전에 조직의 대기 시간을 줄이는 일로 봐야 했습니다.
+제가 이 작업을 통해 보여주고 싶었던 것은 “프론트엔드 잘 안다”가 아니었습니다. 다만 이 문제는 특정 프론트엔드 기술 하나의 문제가 아니라 협업 흐름의 문제였고, 그래서 빌드 도구를 바꾸기 전에 조직의 대기 시간을 줄이는 일로 봐야 했습니다.
 
 ## AI 활용의 전제
 
@@ -103,14 +103,16 @@ AI에게 프롬프트 한번으로 빌드 개선이 아닌 분석 가능한 코
 
 AI가 대신 책임질 수 없는 질문들입니다. 그래서 저는 이 작업을 단순한 코드 수정이 아니라, 계획과 검증이 필요한 개선 프로젝트로 다루었습니다.
 
-## **단계적 개선 전략**
+먼저 기존 빌드 구조를 분석하고, 어디에서 시간이 많이 쓰이는지 확인했습니다. 그 과정에서 Webpack 2, Babel, minification 단계가 주요 검토 대상이 되었고, 개선 후보로 Webpack 5 전환, SWC 도입, esbuild 기반 minification 교체를 함께 검토했습니다.
 
-처음부터 Webpack 2를 Webpack 5로 바꾸고 Babel을 SWC로 교체하는 방식은 위험하다고 판단했습니다. 프로젝트 규모가 크고 오래된 문법과 내부 패키지가 많았기 때문에, 한 번에 바꾸면 문제가 생겼을 때 원인을 찾기 어려웠습니다.
+## 단계적 개선 전략
 
-그래서 개선 단계를 나누었습니다.
+검토 결과, 처음부터 Webpack 2를 Webpack 5로 바꾸고 Babel을 SWC로 교체하는 방식은 위험하다고 판단했습니다. 프로젝트 규모가 크고 오래된 문법과 내부 패키지가 많았기 때문에, 한 번에 바꾸면 문제가 생겼을 때 원인을 분리하기 어려웠습니다.
 
-- **1단계 (즉시 개선):** 기존 Webpack 2를 유지하면서 안전하게 줄일 여지가 있는 부분부터 정리했습니다. 빌드 스크립트를 손보고, babel 캐시를 켜고, dev 빌드에서는 minification을 제거했습니다.
-- **2단계 (도구 교체):** minification 도구를 esbuild 기반으로 교체했습니다.
-- **3단계 (근본 전환):** Webpack 5와 SWC로 전환했습니다.
+그래서 변경 범위를 한 번에 넓히지 않고, 검증 가능한 단위로 나누어 개선하기로 했습니다. 각 단계는 이전 단계의 결과를 기준으로 다음 변경을 판단할 수 있도록 설계했습니다.
+
+- **1단계 (즉시 개선):** 기존 Webpack 2를 유지하면서 안전하게 줄일 수 있는 부분부터 정리했습니다. 빌드 스크립트를 손보고 Babel 캐시를 설정해, 큰 구조 변경 없이 개선 효과를 확인했습니다.
+- **2단계 (도구 교체):** 번들러는 그대로 둔 상태에서 minification 단계만 esbuild 기반으로 교체했습니다. 이렇게 하면 Webpack 전체를 바꾸지 않고도 압축 단계의 개선 효과를 따로 검증할 수 있습니다.
+- **3단계 (근본 전환):** 앞선 단계에서 비교 기준과 검증 방법을 확보한 뒤, Webpack 5와 SWC 전환을 진행했습니다. 이 단계는 단순 최적화가 아니라 빌드 구조 자체를 바꾸는 작업이기 때문에 마지막 단계로 두었습니다.
 
 ![image.png](/assets/img/frontend/2026-04-29-frontend-05.png)