Skip to content
←

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

✨ Learn with Quiz
|

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

들어가며 — 묘비명이 아니라 기술 선택의 역사

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에 직접 확인했습니다. 프로젝트는 다시 활발해지기도 하니 최신 상태는 직접 확인하세요.

함께 읽기

시리즈

  1. 빌드와 프론트엔드 도구 (이 글)
  2. 인프라와 컨테이너
  3. 데이터 저장소와 큐
  4. 언어와 프레임워크, 런타임
  5. 무엇이 기술을 교체시키는가

Build Tools That Stepped Down From Default — Why Ten Frontend Toolchains Gave Up Their Place

Introduction — this is a history of technical choices, not an epitaph

A standard from three years ago feels unfamiliar now. That does not mean those tools were built badly. Most of them were the right answer within the constraints of their moment, and they gave up their place when the constraints changed. This post looks at why those replacements happened. Every entry carries a what it left behind field, because even after a project steps down from being the default, the idea it proved usually lives on inside the next tool.

There are three evidence standards. An official deprecation notice or successor announcement, a public statement from a maintainer, or a dated observable fact such as repository archive status. Only entries where at least one of these was confirmed at the source made the list, and usage trends I cannot cite a source for are not quoted.

1. Create React App

  • What it was — the official scaffolding tool that let you start a React app with a single command.
  • Why it was right at the time — in 2016 the cost of starting with React was webpack and Babel configuration. Hiding that alone lowered the barrier dramatically.
  • What changed — the React team announced the deprecation on 14 February 2025. The reasons given are that it has no active maintainers and that many frameworks already solve the same problems.
  • What took its place — the same post recommends Next.js, React Router and Expo as frameworks, and Vite, Parcel and Rsbuild as build tools.
  • What it left behind — the expectation that you start without configuration. Every scaffolder today follows that standard.
  • When it is still right — the same post states it keeps working in maintenance mode and that a version compatible with React 19 was published. There is no need to move an existing app in a hurry.

2. Bower

  • What it was — a package manager dedicated to frontend assets.
  • Why it was right at the time — when npm was centred on server modules, browser assets needed a flat, non-nested dependency tree.
  • What changed — the repository README itself recommends yarn plus webpack or parcel for new projects. The repository is not archived and states that it is maintained.
  • What took its place — npm and yarn now handle browser assets too, and bundlers took over module resolution.
  • What it left behind — the premise that frontend dependencies deserve declarative management, and the flat tree as the solution.
  • When it is still right — maintaining legacy that is already pinned to Bower. Even by its own README there is no reason to adopt it fresh.

3. TSLint

  • What it was — a linter dedicated to TypeScript.
  • Why it was right at the time — when ESLint could not parse TypeScript syntax properly, this was the only linter that understood types.
  • What changed — the repository carries a deprecation notice and was archived read-only on 25 March 2021.
  • What took its place — typescript-eslint, which solved the problem by swapping out the ESLint parser to support type-aware rules.
  • What it left behind — the concept of lint rules that use type information, along with the rule set itself, which was ported to the successor project.
  • When it is still right — effectively never. An archived repository does not receive security fixes either.

4. Karma

  • What it was — a test runner that launched real browsers to run tests.
  • Why it was right at the time — browsers behaved differently from one another, and there was no verification method other than actually running in a real browser.
  • What changed — the repository README states that it accepts neither new features nor general bug fixes. The repository itself is not archived.
  • What took its place — the same notice lists Jest, Web Test Runner, Vitest and jasmine-browser-runner.
  • What it left behind — the standard that even unit tests should be runnable in a real browser.
  • When it is still right — legacy code that genuinely has to be verified against an old browser matrix. Note that the security-fix window described in the notice is finite.

5. Protractor

  • What it was — an end-to-end test framework for Angular.
  • Why it was right at the time — a runner that knows when the framework has finished rendering cuts a great deal of waiting code.
  • What changed — the Angular team stated in a blog post on 10 August 2022 that v16 would carry the final release, and the repository was archived on 29 July 2024.
  • What took its place — the same post presents Cypress, Nightwatch, WebdriverIO and Playwright.
  • What it left behind — the idea of implicit waiting driven by framework state. It is the ancestor of today's auto-waiting features.
  • When it is still right — the same post mentions a commercial long-term-support fork for teams that cannot migrate immediately.

6. PhantomJS

  • What it was — a scriptable headless browser.
  • Why it was right at the time — when browser vendors offered no headless mode, it was the only realistic way to verify rendering in CI.
  • What changed — the repository README states that development is suspended until further notice, and the repository was archived on 30 May 2023.
  • What took its place — once Chrome and Firefox shipped headless modes directly, Puppeteer and Playwright took over.
  • What it left behind — the category of the headless browser itself. Once this tool proved the demand, the vendors implemented it natively.
  • When it is still right — effectively never. It does not support modern web APIs.

7. LibSass and node-sass

  • What it was — the C++ implementation of the Sass compiler and its Node bindings.
  • Why it was right at the time — the original Ruby implementation was slow, and the C++ implementation cut build times by an order of magnitude.
  • What changed — the Sass team stated in a notice dated 26 October 2020 that they no longer recommend it for new projects. The reason is that there is not enough engineering bandwidth to keep pace with the language, and they added that serious bugs and security issues will still be fixed on a best-effort basis. The node-sass repository is archived.
  • What took its place — Dart Sass, and today Rust-based implementations are in the running too.
  • What it left behind — Sass syntax itself, plus the expensive lesson that a compiler reimplemented in another language struggles to keep up with the syntax evolution of the original.
  • When it is still right — completely frozen legacy builds. You only need to be clear that new Sass syntax is unavailable.

8. Moment.js

  • What it was — the de facto standard for date and time handling in JavaScript.
  • Why it was right at the time — browser date APIs were weak at parsing, formatting and time zones alike, and Moment filled that gap.
  • What changed — the project status section of the official docs describes the project as legacy and in maintenance mode. In its own words: "It is not dead, but it is indeed done."
  • What took its place — the same document recommends Luxon, Day.js, date-fns, js-Joda, and the native Date and Intl objects.
  • What it left behind — the idioms of date library APIs, and a case study in what mutable objects and tree-shaking-hostile design cost you over time.
  • When it is still right — codebases already written around Moment. The docs themselves say it is not dead.

9. Rome

  • What it was — a unified toolchain that aimed to merge formatter, linter and bundler into one.
  • Why it was right at the time — the cost of aligning configuration across five tools was real, and the hypothesis that merging them removes that cost was reasonable.
  • What changed — the repository was archived on 31 August 2023 and its README points to Biome as the community successor. The Biome announcement explains that the same maintainers continue to lead it, but that a new name was needed because of access issues around the package and organisation assets.
  • What took its place — Biome. The same people continue toward the same goal.
  • What it left behind — the unified toolchain goal and the entire codebase. This is less a case of giving up a place than of continuing under a new name.
  • When it is still right — never. The successor project is explicitly designated.

10. Grunt — still active, only stepped down from default

  • What it was — a configuration-driven task runner.
  • Why it was right at the time — when npm scripts were thin, there had to be a way to assemble build steps declaratively.
  • What changed — it was not deprecated. The repository is not archived and the README states that the latest version receives security and bug fixes. What changed is its status as the default choice for new projects.
  • What took its place — npm scripts, and pipelines built into bundlers.
  • What it left behind — the idea of declaring build steps as data. Nearly every build configuration file today has that shape.
  • When it is still right — if you have a Grunt pipeline that works, you can leave it alone. Replacing a maintained tool is itself a cost.

Conclusion — three recurring forces

First, the platform absorbs the feature. PhantomJS gave up its place once browsers shipped headless mode natively. A platform taking over the demand a tool proved is not failure; it is one form of success.

Second, maintenance capacity cannot keep pace with language evolution. The LibSass notice put this most honestly. The bottleneck was people, not feature demand.

Third, the problem definition moves. TSLint was a well-built linter, but the ESLint side, designed so the parser could be swapped, lasted longer.

None of these three forces has much to do with project quality. Asking whether the tool you use today will still be the default in five years is not a question about the tool; it is a question about the environment.

Status information was verified directly on 2026-08-12. Projects sometimes become active again, so check the current state yourself.

Related reading

Series

  1. Build and frontend tooling (this post)
  2. Infrastructure and containers
  3. Data stores and queues
  4. Languages, frameworks and runtimes
  5. What replaces technology