- Published on
기본값에서 내려온 빌드 도구들 — 프론트엔드 툴체인 10개가 자리를 내준 이유
- Authors

- Name
- Youngju Kim
- @fjvbn20031
- 들어가며 — 묘비명이 아니라 기술 선택의 역사
- 1. Create React App
- 2. Bower
- 3. TSLint
- 4. Karma
- 5. Protractor
- 6. PhantomJS
- 7. LibSass와 node-sass
- 8. Moment.js
- 9. Rome
- 10. Grunt — 아직 현역인데 기본값에서만 내려온 경우
- 정리 — 반복되는 세 가지 힘
- 함께 읽기
- 시리즈
들어가며 — 묘비명이 아니라 기술 선택의 역사
3년 전 표준이 지금은 낯설게 느껴집니다. 그 도구들이 잘못 만들어진 것은 아닙니다. 대부분은 자기 시대의 제약 안에서 정답이었고, 제약이 바뀌면서 자리를 내주었습니다. 이 글은 그 교체가 왜 일어났는지를 봅니다. 항목마다 무엇을 남겼나를 반드시 적습니다. 기본값에서 내려와도 그 프로젝트가 증명한 아이디어는 대개 다음 도구 안에 살아 있기 때문입니다.
근거 기준은 셋입니다. 공식 폐기 공지나 후속 프로젝트 발표, 메인테이너의 공개 성명, 저장소 보관 여부처럼 날짜가 붙은 사실. 이 중 하나 이상을 확인한 항목만 넣었고, 출처를 댈 수 없는 다운로드 추세는 인용하지 않습니다.
1. Create React App
- 무엇이었나 — 명령 하나로 React 앱을 시작하게 해 준 공식 스캐폴딩입니다.
- 왜 그때 옳았나 — 2016년 React의 시작 비용은 웹팩과 바벨 설정이었고, 그걸 감춘 것만으로 진입 장벽이 크게 낮아졌습니다.
- 무엇이 바뀌었나 — React 팀이 2025년 2월 14일 공식 블로그에서 폐기를 발표했습니다. 활성 메인테이너가 없고 같은 문제를 푸는 프레임워크가 이미 많다는 것이 이유입니다.
- 무엇이 그 자리에 왔나 — 같은 글이 Next.js, React Router, Expo와 Vite, Parcel, Rsbuild를 권합니다.
- 무엇을 남겼나 — 설정 없이 시작한다는 기대치입니다. 지금 모든 스캐폴더가 이 기준을 따릅니다.
- 지금도 쓰는 게 맞는 경우 — 같은 글이 유지보수 모드로 동작하며 React 19 대응판을 냈다고 밝혔습니다. 급히 옮길 이유는 없습니다.
2. Bower
- 무엇이었나 — 프론트엔드 자산 전용 패키지 매니저입니다.
- 왜 그때 옳았나 — npm이 서버 모듈 중심이던 시절, 브라우저 자산에는 중첩되지 않는 평평한 의존성 트리가 필요했습니다.
- 무엇이 바뀌었나 — 저장소 README가 새 프로젝트에는 yarn과 webpack 또는 parcel을 권한다고 직접 적습니다. 보관되지 않았고 유지보수 중이라고 명시합니다.
- 무엇이 그 자리에 왔나 — npm과 yarn이 브라우저 자산까지 다루고, 모듈 해석은 번들러가 맡습니다.
- 무엇을 남겼나 — 프론트엔드 의존성도 선언적으로 관리한다는 전제와 평평한 트리라는 해법입니다.
- 지금도 쓰는 게 맞는 경우 — 이미 Bower로 고정된 레거시 유지입니다. 새로 도입할 이유는 공식 README 기준으로도 없습니다.
3. TSLint
- 무엇이었나 — TypeScript 전용 린터입니다.
- 왜 그때 옳았나 — ESLint가 TypeScript 구문을 파싱하지 못하던 시절, 타입을 아는 린터는 이것뿐이었습니다.
- 무엇이 바뀌었나 — 저장소에 폐기 공지가 붙어 있고 2021년 3월 25일 읽기 전용으로 보관되었습니다.
- 무엇이 그 자리에 왔나 — typescript-eslint입니다. 파서를 교체해 타입 인지 규칙을 지원하는 방식으로 풀었습니다.
- 무엇을 남겼나 — 타입 정보를 쓰는 린트 규칙이라는 개념과 규칙 세트가 후속 프로젝트로 이식되었습니다.
- 지금도 쓰는 게 맞는 경우 — 사실상 없습니다. 보관된 저장소는 보안 수정도 받지 않습니다.
4. Karma
- 무엇이었나 — 실제 브라우저를 띄워 테스트를 돌리는 러너입니다.
- 왜 그때 옳았나 — 브라우저마다 동작이 달랐고, 진짜 브라우저에서 돌려 보는 것 말고는 검증 수단이 없었습니다.
- 무엇이 바뀌었나 — 저장소 README가 새 기능과 일반 버그 수정을 받지 않는다고 명시합니다. 저장소 자체는 보관되지 않았습니다.
- 무엇이 그 자리에 왔나 — 같은 공지가 Jest, Web Test Runner, Vitest, jasmine-browser-runner를 듭니다.
- 무엇을 남겼나 — 유닛 테스트도 실제 브라우저에서 돌릴 수 있어야 한다는 기준입니다.
- 지금도 쓰는 게 맞는 경우 — 오래된 브라우저 매트릭스를 실제로 검증해야 하는 레거시입니다. 공지가 밝힌 보안 수정 기간은 유한합니다.
5. Protractor
- 무엇이었나 — Angular용 종단간 테스트 프레임워크입니다.
- 왜 그때 옳았나 — 프레임워크가 언제 렌더링을 끝냈는지 아는 러너는 대기 코드를 크게 줄여 줍니다.
- 무엇이 바뀌었나 — Angular 팀이 2022년 8월 10일 블로그에서 v16을 마지막 릴리스로 하겠다고 밝혔고, 저장소는 2024년 7월 29일 보관되었습니다.
- 무엇이 그 자리에 왔나 — 같은 글이 Cypress, Nightwatch, WebdriverIO, Playwright를 제시합니다.
- 무엇을 남겼나 — 프레임워크 상태를 아는 암묵적 대기라는 발상입니다. 오늘날 자동 대기의 원형입니다.
- 지금도 쓰는 게 맞는 경우 — 같은 글이 즉시 이전이 어려운 팀을 위한 상용 장기 지원 포크를 언급합니다.
6. PhantomJS
- 무엇이었나 — 스크립트로 조종하는 헤드리스 브라우저입니다.
- 왜 그때 옳았나 — 브라우저 벤더가 헤드리스 모드를 주지 않던 시절, CI에서 렌더링을 검증할 유일한 수단이었습니다.
- 무엇이 바뀌었나 — 저장소 README가 개발이 추후 공지가 있을 때까지 중단되었다고 밝히며, 2023년 5월 30일 보관되었습니다.
- 무엇이 그 자리에 왔나 — 크롬과 파이어폭스가 헤드리스를 직접 제공하면서 Puppeteer와 Playwright가 가져갔습니다.
- 무엇을 남겼나 — 헤드리스 브라우저라는 범주 자체입니다. 수요를 증명하자 벤더가 직접 구현했습니다.
- 지금도 쓰는 게 맞는 경우 — 사실상 없습니다. 최신 웹 API를 지원하지 않습니다.
7. LibSass와 node-sass
- 무엇이었나 — Sass 컴파일러의 C++ 구현과 그 Node 바인딩입니다.
- 왜 그때 옳았나 — 원래 루비 구현은 느렸고, C++ 구현은 빌드 시간을 자릿수 단위로 줄였습니다.
- 무엇이 바뀌었나 — Sass 팀이 2020년 10월 26일 공지에서 새 프로젝트에는 권하지 않는다고 밝혔습니다. 언어 진화를 따라갈 여력이 없다는 이유이며, 심각한 버그와 보안 문제는 계속 고친다고 덧붙였습니다. node-sass 저장소는 보관 상태입니다.
- 무엇이 그 자리에 왔나 — Dart Sass이고, 지금은 러스트 기반 구현도 경쟁에 있습니다.
- 무엇을 남겼나 — Sass 문법 자체, 그리고 다른 언어로 재구현한 컴파일러는 본체의 문법 진화를 따라가기 어렵다는 교훈입니다.
- 지금도 쓰는 게 맞는 경우 — 빌드가 완전히 고정된 레거시입니다. 새 문법을 못 쓴다는 점만 알면 됩니다.
8. Moment.js
- 무엇이었나 — 자바스크립트 날짜와 시간 처리의 사실상 표준이었습니다.
- 왜 그때 옳았나 — 브라우저의 날짜 API는 파싱과 포매팅, 시간대 처리가 모두 빈약했고 Moment가 그 구멍을 메웠습니다.
- 무엇이 바뀌었나 — 공식 문서의 프로젝트 상태 항목이 스스로를 유지보수 모드의 레거시 프로젝트로 규정합니다. 표현을 그대로 옮기면 "It is not dead, but it is indeed done."입니다.
- 무엇이 그 자리에 왔나 — 같은 문서가 Luxon, Day.js, date-fns, js-Joda와 네이티브 Date, Intl을 권합니다.
- 무엇을 남겼나 — 날짜 API의 관용구, 그리고 가변 객체와 트리 셰이킹 비친화 설계가 무엇을 비용으로 돌려주는지에 대한 사례입니다.
- 지금도 쓰는 게 맞는 경우 — 이미 Moment로 짜인 코드베이스입니다. 문서 스스로 죽지 않았다고 말합니다.
9. Rome
- 무엇이었나 — 포매터와 린터, 번들러를 하나로 합치려던 통합 툴체인입니다.
- 왜 그때 옳았나 — 도구 다섯 개의 설정을 맞추는 비용은 실재했고, 합치면 사라진다는 가설은 합리적이었습니다.
- 무엇이 바뀌었나 — 저장소는 2023년 8월 31일 보관되었고 README가 Biome을 후속 프로젝트로 안내합니다. Biome 발표문은 기존 메인테이너들이 그대로 이끌지만 패키지와 조직 자산 접근 문제로 새 이름이 필요했다고 설명합니다.
- 무엇이 그 자리에 왔나 — Biome입니다. 같은 사람들이 같은 목표를 이어갑니다.
- 무엇을 남겼나 — 통합 툴체인이라는 목표와 코드베이스 전부입니다. 이름을 바꿔 이어진 사례입니다.
- 지금도 쓰는 게 맞는 경우 — 없습니다. 후속 프로젝트가 명시적으로 지정되어 있습니다.
10. Grunt — 아직 현역인데 기본값에서만 내려온 경우
- 무엇이었나 — 설정 기반 태스크 러너입니다.
- 왜 그때 옳았나 — npm 스크립트가 빈약하던 시절, 빌드 단계를 선언적으로 조립할 방법이 필요했습니다.
- 무엇이 바뀌었나 — 폐기되지 않았습니다. 저장소는 보관되지 않았고 README는 최신 버전에 보안과 버그 수정을 제공한다고 밝힙니다. 바뀐 것은 새 프로젝트의 기본 선택지라는 지위입니다.
- 무엇이 그 자리에 왔나 — npm 스크립트, 그리고 번들러에 내장된 파이프라인입니다.
- 무엇을 남겼나 — 빌드 단계를 데이터로 선언한다는 발상입니다. 오늘날 거의 모든 빌드 설정이 이 형태입니다.
- 지금도 쓰는 게 맞는 경우 — 잘 돌아가는 파이프라인이 있다면 그대로 두어도 됩니다. 유지보수되는 도구를 교체하는 것 자체가 비용입니다.
정리 — 반복되는 세 가지 힘
첫째, 플랫폼이 기능을 흡수합니다. PhantomJS는 브라우저가 헤드리스 모드를 내장하면서 자리를 내주었습니다. 도구가 증명한 수요를 플랫폼이 가져가는 것은 실패가 아니라 성공의 한 형태입니다.
둘째, 유지보수 여력이 언어 진화 속도를 못 따라갑니다. LibSass 공지가 이 점을 가장 솔직하게 적었습니다. 기능 수요가 아니라 인력이 병목이었습니다.
셋째, 문제 정의가 바뀝니다. TSLint는 잘 만든 린터였지만, 파서를 교체할 수 있게 설계한 ESLint 쪽이 더 오래 갔습니다.
세 힘 모두 프로젝트의 품질과는 상관이 없습니다. 지금 쓰는 도구가 5년 뒤에도 기본값일지 묻는 질문은 도구를 의심하는 것이 아니라 환경을 읽는 것입니다.
상태 정보는 2026-08-12에 직접 확인했습니다. 프로젝트는 다시 활발해지기도 하니 최신 상태는 직접 확인하세요.
함께 읽기
- 의존성 공급망 보안
- 버스 팩터는 결정할 수 있는 사람 수다
- Airflow 2 EOL 마이그레이션의 현실
- 레거시 코드와 일하기
- 도구: 텍스트 비교기 · SW 정기점검 체크리스트 · Git 플레이그라운드
시리즈
- 빌드와 프론트엔드 도구 (이 글)
- 인프라와 컨테이너
- 데이터 저장소와 큐
- 언어와 프레임워크, 런타임
- 무엇이 기술을 교체시키는가