프론트엔드 설계
빌드·번들·정적 검사와 패키지 배포
모듈 번들링, 문법 변환, 런타임 호환성 보완, 정적 품질 검사는 각각 서로 다른 책임을 가집니다.
이럴 때 필요해요
불필요한 번들 크기를 줄이고 팀 전체가 재현 가능한 빌드 파이프라인과 안전한 배포 경계를 구축합니다.
어떻게 동작하나요?
우리가 작성한 최신 TypeScript와 JSX, 여러 모듈 파일이 사용자의 브라우저에서 빠르고 안전하게 실행되려면 여러 도구가 각자의 역할을 수행해야 합니다. webpack 같은 번들러는 import 의존성 그래프를 따라 모듈과 자산을 묶고 라우트별로 분할(Code Splitting)하며, Babel 같은 트랜스파일러는 최신 문법을 지원 대상 브라우저가 이해할 수 있는 문법으로 변환합니다. 이때 문법 변환만으로는 구형 브라우저에 없는 Promise 같은 내장 API가 생기지 않으므로 런타임 API 보완에는 polyfill을 함께 구성합니다.
코드 품질 면에서는 버그 가능성이 있는 패턴과 규칙을 잡는 ESLint와 코드 서식을 일관되게 정리하는 Prettier를 분리해 에디터와 CI에서 동일한 설정으로 실행합니다. 또한 번들 크기를 줄일 때는 번들 분석기로 실제 큰 비중을 차지하는 라이브러리를 먼저 찾은 뒤 동적 import()와 Tree Shaking을 적용하며, 네트워크 압축(Brotli/Gzip) 크기와 브라우저가 실제로 파싱·실행해야 하는 원본 JS 크기를 함께 살핍니다.
package.json에서는 런타임에 필요한 dependencies와 빌드·테스트 도구인 devDependencies를 구분하되, 프론트엔드 웹 앱의 최종 번들 포함 여부는 실제 import 그래프에 의해 결정된다는 점을 기억해야 합니다. 또한 애플리케이션에 설정하는 private: true는 실수로 npm 레지스트리에 공개 게시되는 것을 막는 안전장치일 뿐 소스 코드나 환경 변수를 숨겨 주는 보안 기능이 아니며, 실제 라이브러리를 배포할 때는 exports·types 경로와 npm pack 산출물을 반드시 사전 점검합니다.
코드 예제
동작을 설명하는 읽기 전용 예제입니다.
{
"name": "example-ui",
"version": "1.0.0",
"private": true,
"scripts": { "lint": "eslint ." }
}설명용 package.json 조각입니다. 외부로 배포할 라이브러리가 아닌 웹 애플리케이션 패키지에 private: true를 설정하면 실수로 npm에 게시되는 사고를 막을 수 있습니다.
자주 헷갈리는 포인트
- 코드에서 실제로 import해 쓰고 있는 패키지를 devDependencies로 옮기기만 하면 브라우저 번들에서 자동으로 빠진다고 생각하지 않습니다.
- Babel 문법 변환만 설정하면 브라우저에 없는 모든 최신 런타임 API와 Web API까지 자동으로 동작한다고 설명하지 않습니다.
내 말로 설명해 보기
화살표 함수 같은 문법은 변환되었지만 구형 환경에 Promise API 자체가 없을 때, 트랜스파일러(Babel)와 polyfill은 각각 어떤 역할을 맡나요?
함께 읽으면 좋은 개념
관련 면접 질문 7개
서로 다른 컴포넌트의 CSS 선택자는 왜 충돌하나요?
JavaScript 파일이 모듈별로 분리되어 있더라도 일반 .css 파일을 import하면 빌드 후에는 하나의 전역 스타일시트 규칙으로 문서 전체에 적용되기 때문입니다. 따라서 서로 다른 컴포넌트에서 우연히 같은 클래스 이름(.title, .card 등)을 사용하면 CSS의 명시도(specificity)와 선언 순서(cascade)에 따라 나중에 로드된 스타일이 다른 컴포넌트의 화면을 덮어쓰게 됩니다. 이를 방지하려면 CSS Modules나 스코프 스타일 도구로 클래스 이름을 고유하게 변환하거나, BEM 같은 명명 규칙과 레이어 정책을 일관되게 적용해야 합니다.
꼬리질문과 참고자료 →webpack·Babel·polyfill은 각각 어떤 역할인가요?
webpack은 여러 JavaScript 모듈과 CSS·이미지 같은 자산의 의존성 그래프를 분석해 배포용 번들로 묶고 분할(Code Splitting)하는 번들러입니다. 반면 Babel은 최신 JavaScript 문법이나 JSX, TypeScript를 구형 브라우저도 이해할 수 있는 하위 문법으로 바꾸는 트랜스파일러(컴파일러)입니다. 마지막으로 polyfill은 문법 변환만으로는 해결되지 않는 Promise, Array.prototype.at 같은 누락된 런타임 표준 API를 실행 환경에 채워 넣는 코드입니다.
꼬리질문과 참고자료 →ESLint와 Prettier는 왜 함께 사용하나요?
ESLint는 선언되지 않은 변수나 잘못된 Hook 의존성처럼 버그 가능성이 있는 코드 패턴과 규칙을 잡는 정적 분석 도구이고, Prettier는 들여쓰기·따옴표·줄바꿈 같은 코드 스타일을 일관되게 자동 정렬해 주는 포매터입니다. 두 도구를 함께 쓰면 코드 품질 규칙과 서식 통일을 동시에 챙길 수 있어, 코드 리뷰에서 소모적인 줄바꿈 논쟁을 줄이고 비즈니스 로직과 설계에 집중할 수 있습니다. 다만 ESLint의 포매팅 관련 규칙이 Prettier와 충돌하지 않도록 eslint-config-prettier 등으로 역할을 분리하고 CI에서 동일하게 검증합니다.
꼬리질문과 참고자료 →