✍️ 필사 모드: 2026년에 피해야 할 도구와 트렌드 — 안티 추천 큐레이션, 그리고 대안 가이드

이 글은 "쓰지 마라"는 부정의 글이 아니다. 좋았던 시절을 인정한 뒤, 2026년 기준으로 더는 권하지 않는 도구와 그 자리를 채울 더 좋은 선택을 짝지어 정리한 큐레이션이다. 정답이 아니라 의견이지만, 근거가 있는 의견이다.

---

프롤로그 — 안티 추천이 왜 필요한가

좋은 도구를 소개하는 글은 많다. 그런데 나쁜 도구를 떠나라는 글은 드물다. 이유는 두 가지다. 첫째, 누군가의 추억과 결과물을 비판하는 일은 인기가 없다. 둘째, 도구는 진공에 있지 않기 때문에 "그건 나쁘다"는 단정은 거의 항상 부분적으로만 맞다.

그래도 누군가는 이 글을 써야 한다. 2026년의 신규 입사자가 검색해서 가장 먼저 만나는 튜토리얼이 2018년에 멈춰 있고, 그 튜토리얼이 권하는 도구 절반이 이미 유지보수가 끝났기 때문이다. 새 프로젝트를 그런 도구로 시작하면 첫 주에 빌드가 깨지고, 첫 달에 보안 권고가 쌓이고, 첫 분기에 마이그레이션 비용이 생긴다.

이 글의 전제는 단순하다.

1. 모든 도구는 한 시점에 옳았다. 비판은 그 시점을 부정하는 것이 아니다.
2. 시점이 지나면 비용이 역전된다. "이 도구가 한 일"보다 "이 도구가 막는 일"이 커진다.
3. 대안 없는 비판은 게으르다. 그래서 항목마다 대안을 짝짓는다.
4. 대안도 영원하지 않다. 1년 뒤 이 글의 절반은 다시 쓰여야 할 것이다.

마지막 전제가 중요하다. 이 글을 절대 진리로 읽지 말고, "오늘 새 프로젝트라면 어디서부터 시작하지 않을 것인가" 정도의 안내로 받기를 권한다.

---

1장 · 한눈 매트릭스 — AVOID / INSTEAD

본문 들어가기 전에 전체 지도를 먼저 펼친다.

표는 길지만 의도가 있다. 항목 자체가 아니라 짝을 기억하기를 바라기 때문이다. "Moment 안 써"가 아니라 "Moment 대신 date-fns/Temporal"이 한 묶음이다.

---

2장 · 프론트엔드 — CRA, Moment, lodash 풀임포트

2.1 Create React App

무엇이 잘못됐나. Create React App은 2016년 Facebook이 만든 React 부트스트랩 도구다. 한 줄 명령어로 의존성과 빌드 설정을 추상화해 줘서 학습 진입 장벽을 크게 낮췄다. 그러나 2022년 이후 사실상 유지보수가 멈췄고, 2023년 3월 React 공식 문서가 "새 앱에 권장하지 않는다"고 명시했다. 2025년 시점에는 React 팀이 직접 "CRA는 deprecated"라는 공지를 올렸다. Webpack 4 기반의 빌드는 콜드 스타트가 수십 초에서 분 단위까지 가고, 의존성 보안 권고가 누적되며, 새 React 기능과의 통합 경로가 사라진다.

왜 아직 쓰는가. 검색이 그를 데려간다. 2018-2022년 사이에 쓰인 튜토리얼이 여전히 상위 결과를 차지하고, 회사 내부 문서도 그 시절에 멈춰 있다. 새 입사자는 그 경로를 그대로 따른다.

무엇을 대신 쓰나.

• 단일 페이지 앱이라면 Vite + React. 콜드 스타트 1초 미만, HMR이 즉시.
• 풀스택/라우팅/서버 컴포넌트가 필요하면 Next.js. 현재 React의 사실상 표준 메타 프레임워크.
• 라우팅 우선의 SPA에 가까운 풀스택이 필요하면 TanStack Start. 타입 안전한 라우터와 데이터 로딩이 매력.

좋았던 점. CRA가 한 일을 잊지 말자. 한 명령어로 시작 가능한 React 경험을 처음 정의한 도구다. 후속 도구들이 디폴트 친화성을 닮은 이유다.

2.2 Moment.js

무엇이 잘못됐나. Moment는 한때 자바스크립트 날짜 처리의 표준이었다. 그러나 변경 가능한 객체 모델, 무거운 번들 크기, i18n 데이터 전체 포함, 트리 셰이킹 비친화 — 이 모든 것이 현대 프론트엔드의 가치관과 충돌한다. 결정적으로 Moment 팀 자신이 2020년 9월 "레거시 프로젝트"라고 공식 선언했다. 새 코드에는 권하지 않으며, 기능 추가도 하지 않겠다는 발표다.

왜 아직 쓰는가. 이미 모든 코드에 박혀 있다. 그리고 대안이 너무 많아서 결정 마비가 온다.

무엇을 대신 쓰나.

• date-fns: 함수형, 트리 셰이커블, 가장 호환성이 넓다. 단순 포맷팅/계산 위주라면 기본 선택.
• Day.js: Moment와 API 호환 지향. 마이그레이션 비용을 가장 낮춘다.
• Temporal: ECMAScript 표준화 진행 중. 폴리필로 미리 채택 가능. 장기적으로는 여기로 수렴.
• Luxon: Moment 팀 멤버가 만든 후속작. 좀 더 의견이 강한 API.

좋았던 점. Moment가 없었다면 자바스크립트의 빈약한 Date API 위에서 무엇을 하든 끔찍했을 것이다. 표준이 따라잡기까지 10년을 메워준 라이브러리다.

2.3 lodash 풀임포트

무엇이 잘못됐나. import _ from 'lodash'는 모든 함수를 번들로 끌어온다. 2026년의 표준 ES는 Array.prototype.at, structuredClone, Object.groupBy, Array.fromAsync, Promise.any, Promise.allSettled, String.prototype.replaceAll 등으로 lodash의 절반을 흡수했다. lodash 자체도 2021년 4.17.21 이후 메이저 업데이트가 사실상 없다.

왜 아직 쓰는가. 옛 코드와 옛 손가락의 관성. _.get, _.pick, _.debounce는 손에 익는다.

무엇을 대신 쓰나.

• 가능한 한 표준 ES를 쓴다. _.map → .map, _.filter → .filter, _.find → .find.
• 깊은 접근이 필요하면 옵셔널 체이닝(a?.b?.c)과 nullish 병합(??).
• 그래도 lodash 함수가 필요하면 lodash-es에서 개별 임포트: import { debounce } from 'lodash-es'.
• 런타임이 Bun이면 빌트인을 본다. Bun은 일부 유틸을 네이티브로 제공한다.

좋았던 점. lodash 문서는 오래도록 자바스크립트 표준 라이브러리의 사실상 레퍼런스였다. API 명세서로서의 가치는 지금도 살아 있다.

2.4 Gulp / Grunt / Bower

무엇이 잘못됐나. Bower는 2017년 공식적으로 "추가 작업 안 함" 선언, npm/yarn으로 옮기라고 권고했다. Gulp/Grunt는 빌드 파이프라인을 명시적 코드로 만든다는 가치가 있었지만, 번들러가 충분히 똑똑해진 시점에 그 역할이 대부분 사라졌다. 2026년에 새 프로젝트에서 Gulp/Grunt를 만나는 일은 거의 없다.

무엇을 대신 쓰나.

• 번들/HMR: Vite, Rspack, Turbopack, Bun.
• 태스크 러너: package.json scripts + npm-run-all / concurrently / turbo run.

좋았던 점. "빌드도 코드"라는 사고방식을 대중화했다. 그 사상은 살아남았고 도구가 바뀐 것뿐이다.

---

3장 · Node 도구체인 — Yarn 1, Yarn Workspaces 단독, Webpack 단독

3.1 Yarn 1

무엇이 잘못됐나. Yarn 1(클래식)은 2017-2020년 npm의 결함을 메워준 영웅이다. 그러나 Yarn 2 이후 Berry 라인으로 갈라졌고, 1.x는 보안 패치 외 사실상 동결이다. 더 큰 문제는 node_modules의 평탄화 전략이 의도치 않은 의존성 해석을 허용한다는 점 — pnpm이 해결한 그 문제다.

무엇을 대신 쓰나.

• 일반 단일 프로젝트: pnpm. 디스크 효율과 엄격한 해석이 표준이 됐다.
• 모노레포: pnpm workspaces + Turborepo 또는 Nx.
• 속도 우선: Bun. 설치/실행 모두 빠르고, 점점 호환성이 넓어진다.
• Yarn 자체를 좋아한다면 Yarn 4(Berry, PnP 또는 nodeModulesLinker). 다만 PnP의 호환성 이슈는 여전히 평가 후 결정.

3.2 Yarn Workspaces 단독으로 모노레포 굴리기

무엇이 잘못됐나. 워크스페이스 자체는 좋다. 그러나 빌드 캐시, 영향-분석, 원격 캐시가 없는 모노레포는 빠르게 무너진다. "이 PR이 무엇을 빌드/테스트해야 하는가"를 사람이 결정하기 시작하면 끝이다.

무엇을 대신 쓰나.

• Turborepo: 간단한 설정과 캐시. JS/TS 중심.
• Nx: 더 강력한 그래프와 플러그인. 다언어/대형 조직.
• Bazel: 정말 큰 조직, 다언어. 학습 곡선을 감수할 때만.

3.3 Webpack 단독 / webpack.config.js 손빨래

무엇이 잘못됐나. Webpack 자체가 나쁜 것이 아니라, 2026년에 "Webpack 설정을 직접 쓰면서 모든 로더와 플러그인을 손으로 챙기는" 작업은 거의 항상 손해다. Vite/Turbopack이 그 자리를 거의 다 가져갔고, 남은 영역도 Rspack(Rust 기반 Webpack 호환)이 빠르게 채우고 있다.

무엇을 대신 쓰나.

• 신규: Vite(범용), Next.js 내장(메타 프레임워크), Turbopack(Next.js와 함께).
• 기존 Webpack 자산을 거의 그대로 가져가고 싶다면 Rspack. 설정 호환을 유지하면서 속도만 올린다.

좋았던 점. Webpack은 "프론트엔드 빌드"라는 개념 자체를 정의한 도구다. 후속 도구들의 멘탈 모델(엔트리/로더/플러그인)은 거의 Webpack 유산이다.

---

4장 · 파이썬 — 시스템 파이썬, requirements.txt 단독, conda 남발

4.1 apt-get install python 또는 brew install python을 시스템 도구로 사용

무엇이 잘못됐나. 시스템 파이썬은 OS의 일부다. 거기에 pip install 하기 시작하면 시스템 도구가 망가지고, 한 번 망가지면 복구가 어렵다. 가상환경을 항상 만든다는 규율은 좋지만, 그 규율을 사람이 손으로 지키는 시대는 끝났다.

무엇을 대신 쓰나.

• uv (Astral): Rust 기반의 빠른 파이썬 패키지/프로젝트 매니저. 의존성 해결과 설치가 빠르고 락파일을 표준으로 다룬다. 2024-2025년 사이에 사실상 새 표준이 됐다.
• pipx: CLI 형태 파이썬 도구(예: black, httpie)를 격리해 설치.
• mise 또는 asdf: 파이썬 버전 자체를 프로젝트별로 관리. pyenv보다 빠르고 다언어 친화.

4.2 requirements.txt 단독 + pip freeze 워크플로

무엇이 잘못됐나. pip freeze > requirements.txt는 환경의 스냅숏이지 의존성 명세가 아니다. 직접 명시한 의존성과 그것이 끌고 온 전이 의존성이 섞이고, 플랫폼별 차이가 무시된다. 결과: 다른 머신에서 "내 머신에서는 됐는데"가 반복된다.

무엇을 대신 쓰나.

• uv의 pyproject.toml + uv.lock. 명시 의존성과 락파일이 분리되고, 멀티 플랫폼 락이 가능하다.
• Poetry: 좀 더 의견이 강한 경험. 락파일을 가장 먼저 대중화했다.
• Hatch: 빌드와 환경 관리를 통합. PEP 표준을 가장 직진으로 따른다.

4.3 conda를 "모든 것"에 쓰기

무엇이 잘못됐나. conda는 과학 계산 스택(GPU/네이티브 라이브러리)이 복잡할 때 진가를 발휘한다. 그러나 순수 파이썬 웹앱이나 CLI를 conda로 굴리면 의존성 해결 속도가 분 단위로 늘고, 채널 충돌과 라이선스 이슈(Anaconda 상용 채널 정책)가 따라온다.

무엇을 대신 쓰나.

• 순수 파이썬: uv 또는 Poetry.
• 과학/머신러닝 + 네이티브: mamba(빠른 conda 호환) 또는 pixi(Rust 기반, conda 패키지를 사용하면서 락파일과 작업 정의 통합). pixi는 2024-2026년 사이에 빠르게 채택을 늘리고 있다.

좋았던 점. conda는 "OS 패키지 매니저 없이도 GPU 스택을 굴리게 해 준" 첫 도구다. 그 가치는 지금도 남아 있다. 다만 범용 파이썬 워크플로의 디폴트로는 부적절하다.

---

5장 · AI 평가와 LLM 통합 — Open LLM Leaderboard, 옛 LangChain, 낡은 프롬프트 트릭

5.1 Open LLM Leaderboard

무엇이 잘못됐나. Hugging Face의 Open LLM Leaderboard는 2023-2024년 오픈 모델 평가의 사실상 표준이었다. 그러나 평가 셋(MMLU, ARC, HellaSwag, TruthfulQA, Winogrande, GSM8k)이 빠르게 포화하고 일부는 학습 데이터에 누출되면서 변별력이 떨어졌다. 공식적으로 2024년 6월 v2로 갱신됐고, 이후 v2 자체도 2025년 아카이브 상태로 전환됐다. 새 점수가 더 이상 산출되지 않는다.

무엇을 대신 쓰나.

• LMArena (구 Chatbot Arena): 사람의 페어와이즈 선호도 기반 Elo 랭킹. "어느 모델이 더 나은가"의 가장 신뢰할 수 있는 통합 지표.
• Artificial Analysis: 가격/지연/품질을 함께 보여주는 비교 사이트. 실무 의사결정에 유용.
• 도메인 평가: SWE-bench(소프트웨어 엔지니어링), LiveCodeBench(코딩, 오염 방지), MMLU-Pro(추론 강화), GPQA(대학원 수준 과학).
• 내부 평가: 결국 모든 팀은 자체 골든셋이 필요하다. 위 지표는 후보를 좁히는 데만 쓴다.

5.2 LangChain <v0.2 시절의 깊은 임포트

무엇이 잘못됐나. 2023-2024년 LangChain 코드는 종종 from langchain.something.deep.path import X 형태로 깊이 내부 모듈을 직접 가져왔다. v0.2 이후 패키지가 langchain, langchain-core, langchain-community, 통합별 langchain-openai, langchain-anthropic, langgraph 등으로 분리되면서 그 경로 대부분이 깨졌다.

왜 아직 쓰는가. 옛 튜토리얼이 검색 상위에 있다. 새 입사자가 그 코드를 그대로 복붙해서 갖다 쓴다. 그리고 v0.2+ 마이그레이션 가이드가 길어서 미루기 쉽다.

무엇을 대신 쓰나.

• 그대로 LangChain을 쓴다면, 통합별 패키지를 명시적으로 임포트하고 langgraph로 에이전트 그래프를 만든다.
• 간단한 호출이라면 LangChain을 쓰지 말고 공식 SDK(Anthropic, OpenAI, Google)를 직접 쓴다. 추상화 비용이 가치보다 큰 경우가 많다.
• 데이터 검색/인덱싱 중심이라면 LlamaIndex. 표면이 LangChain보다 일관적이다.
• 멀티 에이전트 오케스트레이션이라면 LangGraph, CrewAI, OpenAI Swarm 류를 비교 검토. 다만 추상화가 빠를수록 디버깅이 어렵다.

좋았던 점. LangChain은 "LLM을 코드로 묶는다"는 패러다임을 가장 먼저 정의했다. 그 패러다임이 표준 모범 사례가 되는 동안 라이브러리 자체는 자기 모양을 여러 번 바꿔야 했고, 그 결과 옛 코드와 새 코드 사이의 거리가 멀다.

5.3 "당신은 OO 전문가입니다" 류의 낡은 프롬프트 트릭

무엇이 잘못됐나. 2022-2023년에는 "당신은 시니어 엔지니어입니다, 단계별로 생각하세요, 깊게 숨을 쉬세요" 같은 접두가 실제로 성능을 올렸다. 모델이 RLHF로 정렬되면서 그런 일반적 격려의 한계 효용은 거의 사라졌다. 2025년 이후 주요 벤더의 프롬프트 가이드는 오히려 명세적이고 구체적일 것을 권한다.

무엇을 대신 쓰나.

• 시스템 프롬프트에 역할/제약/금기/포맷을 명시. "전문가"가 아니라 "감사 가능한 SQL을 작성, 주석 금지, 단일 트랜잭션".
• 평가 데이터셋과 함께 프롬프트를 변경. 인상이 아니라 점수로 확인.
• 너무 긴 시스템 프롬프트는 캐시 적중률과 컨텍스트 비용을 해친다. 짧고 단단하게.
• 체이닝이 필요하면 "단계별로 생각해" 대신 명시적 단계와 산출 스키마(JSON Schema 등).

좋았던 점. 옛 트릭들이 모두 무의미했던 것은 아니다. "단계별로 생각해"는 한때 진짜 효과가 있었고, 그 발견 자체가 추론 강화의 출발점이 됐다. 다만 도구가 진화하면서 트릭 자체는 흡수됐다.

---

6장 · 관측과 인프라 — 무거운 APM, 자체 포워더, Docker Hub 의존

6.1 AppDynamics / 무거운 APM을 작은 앱에 도입

무엇이 잘못됐나. AppDynamics, Dynatrace 같은 풀스택 APM은 대규모 모놀리스를 가진 엔터프라이즈에는 가치가 있다. 그러나 5명짜리 팀에 10개 마이크로서비스가 있는 상황에서는 라이선스 비용과 운영 부담이 가치를 압도한다. 그리고 벤더 락인.

무엇을 대신 쓰나.

• 표준은 OpenTelemetry(OTel). 메트릭/로그/트레이스를 한 표준으로.
• 메트릭: Prometheus + Grafana.
• 트레이스: Tempo 또는 Jaeger.
• 로그: Loki 또는 클라우드 네이티브 옵션.
• 한 묶음으로 호스팅하려면 Grafana Cloud 또는 Honeycomb. 다만 호스팅 비용은 따로 평가.
• 매니지드형 통합 솔루션이 정말 필요하면 Datadog, New Relic도 후보지만, "OTel 호환성"을 기준으로 비교.

6.2 자체 로그 포워더, 자체 포맷, 자체 파이프라인

무엇이 잘못됐나. "우리만의 로그 형식"은 처음 6개월은 빠르고 이후 6년은 느리다. 새 도구를 붙일 때마다 어댑터를 직접 짜야 하고, 검색/저장/보존 정책을 모두 자체 구현해야 한다.

무엇을 대신 쓰나.

• 포맷: 구조화 JSON. 키는 OTel semantic conventions 가이드를 따른다.
• 포워더: OpenTelemetry Collector 또는 Vector(Datadog 오픈소스).
• 저장: 매니지드 또는 ClickHouse/OpenSearch. 자체 구현은 마지막 옵션.

6.3 Docker Hub 무인증 풀에 빌드 SLA 묶기

무엇이 잘못됐나. Docker Hub는 2020년 이후 무인증/무료 계정 풀에 시간당 제한을 두고 있다. CI에서 그 제한에 걸리면 빌드 전체가 가짜로 실패한다. 그리고 베이스 이미지 무결성도 별도 검증 없이 신뢰하는 셈이 된다.

무엇을 대신 쓰나.

• 사내 이미지 미러: Harbor, JFrog Artifactory, 또는 클라우드 레지스트리(ECR, GHCR, Artifact Registry).
• 베이스 이미지는 미러를 통과시키고, SBOM과 서명(cosign)을 검증.
• 멀티 아키텍처(amd64/arm64)는 빌드 시 명시.

---

7장 · DevOps / CI — Travis OSS, 손빨래 Bash, "main에 직접 푸시"

7.1 Travis CI에 오픈소스 빌드 묶기

무엇이 잘못됐나. Travis CI는 오픈소스 CI의 황금기를 만든 도구다. 그러나 2020년 이후 무료 정책이 바뀌면서 많은 OSS 프로젝트가 사실상 사용이 어려워졌다. 새 OSS를 Travis 위에 만들 이유는 거의 없다.

무엇을 대신 쓰나.

• 가장 보편적: GitHub Actions. OSS 무제한 분 사용량이 충분히 넉넉.
• 가장 강력한 캐싱/병렬: Buildkite(셀프호스트 에이전트), CircleCI.
• GitLab을 쓴다면 GitLab CI.
• 모노레포: Turborepo/Nx 캐시 + 위의 어떤 CI든.

7.2 손으로 짠 Bash 파이프라인을 빌드 핵심에 두기

무엇이 잘못됐나. Bash는 강력하고 어디서나 돈다. 그러나 100줄을 넘기는 빌드 스크립트는 거의 항상 잘못된 추상화에 도달한다. 한 사람이 떠나면 그 사람만 알던 환경 변수가 사라진다.

무엇을 대신 쓰나.

• 단순 명령 묶음: package.json scripts, mise tasks, just.
• 빌드 그래프: Turborepo, Nx, Bazel.
• "스크립트가 길어지면" 그 시점에 도구로 옮긴다. 200줄 Bash는 신호다.

7.3 "main에 직접 푸시" 문화

무엇이 잘못됐나. 도구가 아니라 프로세스 안티패턴이다. 작은 팀이 빠르게 가려는 의도는 이해되지만, 리뷰 없는 머지는 학습이 멈춘 조직의 첫 신호다. 사고는 그 후에 정확히 도착한다.

무엇을 대신 쓰나.

• 짧은 PR(< 400라인 변경)을 표준으로.
• 머지 큐(Mergify, GitHub Merge Queue) — 메인 깨짐 방지.
• 자동 머지 룰 — 리뷰 통과 + CI 그린 시 자동 머지.
• 코드오너스와 1리뷰어 룰 — 진짜 책임자에게 라우팅.

---

8장 · 일반 프로세스 안티패턴 — VS Code 확장 비만, .env 커밋, "다시 만들자"

8.1 VS Code 확장 비만

무엇이 잘못됐나. VS Code는 풍성한 확장 생태계가 강점이다. 그런데 그 강점이 디폴트가 되면 — "유용해 보이면 일단 설치" — 두 가지가 동시에 무너진다. 성능(시작 시간, 메모리, 언어 서버 충돌)과 공급망 보안(악성 확장, 타입스쿼팅).

무엇을 대신 쓰나.

• 확장 다이어트. 분기마다 사용 안 하는 확장을 제거.
• 신뢰 가능한 게시자만(Microsoft, 공식 언어 팀, 잘 알려진 기업). 출처가 모호한 확장은 설치 전 검토.
• 워크스페이스별 권장 확장 목록(extensions.json).
• 작업에 따라 에디터를 분리: 무거운 IDE는 진짜 그때만.

좋았던 점. VS Code의 확장 모델은 에디터 생태계를 영원히 바꿨다. 문제는 모델이 아니라 무절제다.

8.2 .env 커밋, 평문 비밀 공유, 슬랙 DM에 토큰

무엇이 잘못됐나. 보안 사고의 단일 원인 1위. 한 번 커밋된 비밀은 영원하다 — 히스토리 재작성으로도 잡지 못하는 경우가 흔하다.

무엇을 대신 쓰나.

• 로컬: direnv + .envrc.local(절대 커밋 안 함) + 1Password CLI / op read.
• 팀: SOPS + age/KMS 키, Doppler, 1Password Secrets Automation.
• 인프라: Vault, 클라우드 시크릿 매니저(AWS Secrets Manager, GCP Secret Manager), SealedSecrets(Kubernetes).
• 사고 대응: git-secrets, gitleaks, trufflehog를 pre-commit과 CI에 모두.

8.3 "낡았으니 다 갈아엎자" 큰 재작성

무엇이 잘못됐나. 본 글의 모든 권고를 한 분기에 다 적용하려는 욕심. 큰 재작성은 가장 비싼 부채 상환 방식이며, 그 사이 새 부채가 쌓인다.

무엇을 대신 쓰나.

• 스트랭글러 무화과 패턴: 새 코드가 옛 코드를 천천히 둘러싸 대체.
• 모듈 단위 마이그레이션, 한 번에 하나.
• 분기별 "낡은 도구 1개 교체" 목표. 1년이면 4개.
• 마이그레이션마다 "전후 비교 지표"(빌드 시간, 번들 크기, 보안 권고 수)를 기록. 결정의 근거가 다음 결정의 자료가 된다.

---

9장 · 회색지대 — 죽지 않았지만 디폴트로는 아닌 도구들

이 절은 "절대 쓰지 마라"가 아니다. 새 프로젝트의 디폴트로는 권하지 않지만 맥락에 따라 합리적인 도구들.

회색지대는 솔직한 표지판이다. "디폴트는 아니지만 이유가 있다면 쓰라"는 신호. 도구의 가치는 맥락에 묶여 있다는 사실을 잊지 말기를.

---

10장 · 좋았던 것들에 대한 짧은 헌사

이 글은 비판이지만 묘비명은 아니다. 잠시 멈추고 인정하자.

• CRA는 React를 처음 시작하는 사람의 두려움을 한 줄로 줄였다. 후속 도구의 디폴트 친화성은 모두 CRA의 유산이다.
• Moment.js는 10년 동안 빈약한 JS Date API의 빈틈을 메웠다. 표준이 따라잡을 시간을 벌어준 라이브러리다.
• lodash는 자바스크립트 표준 라이브러리의 사실상 레퍼런스였다. 표준이 흡수한 함수 절반의 모범 답안.
• Webpack은 프론트엔드 빌드라는 개념을 정의했다. 그 멘탈 모델 없이는 Vite도 없다.
• Jenkins는 CI 문화를 대중화했다.
• Travis CI는 OSS의 CI 무료 시대를 열었다.
• LangChain은 LLM을 코드로 묶는 패러다임을 정의했고, 자신을 여러 번 바꾸면서 그 길을 닦았다.
• AppDynamics는 풀스택 APM이라는 카테고리 자체를 만들었다.

비판의 짝은 감사다. 우리가 지금 가진 더 좋은 도구들은 이 도구들이 닦은 길 위에 서 있다.

---

에필로그 — 한 분기 체크리스트와 다음 글

이번 분기 한 가지만 한다면

새 프로젝트라면, 위의 매트릭스에서 디폴트를 그대로 골라라. 기존 프로젝트라면, 가장 자주 빌드되는 파이프라인의 가장 느린 단계 하나만 교체하라. 일주일에 100번 도는 것을 30분 빠르게 만들면, 한 분기에 50시간이 돌아온다.

도입 전 6질문 체크리스트

1. 이 도구는 유지보수되고 있는가? 마지막 릴리스 날짜, 닫힌 이슈 비율을 본다.
2. 이 도구의 공식 권장 상태는 무엇인가? "deprecated" 같은 단어를 찾는다.
3. 대안과 마이그레이션 경로가 있는가? 잠긴 상태에서 시작하지 않는다.
4. 번들/실행 비용이 가치에 맞는가? 표준이 흡수한 기능을 위해 의존성을 들이지 않는다.
5. 공급망 위협은 어떻게 다루는가? 확장/플러그인/노드는 모두 제3자 코드다.
6. 탈출 비용은 얼마인가? 6개월 뒤 후회하면 빠져나올 수 있는가?

안티패턴 요약

• 검색 첫 결과에 멈추기 — 2018-2022년 글이 첫 결과인 분야가 절반이다.
• "팀이 익숙해서" — 익숙함은 자산이지만 새 입사자의 부채다.
• "별 1만 개니까" — 별은 관심이지 채택이 아니다.
• "내일부터 다 갈자" — 큰 재작성은 가장 비싼 부채 상환이다.
• 대안 없이 비판하기 — 이 글의 모든 항목이 짝을 가진 이유.

다음 글 예고

다음 글에서는 이 글이 자주 언급한 마이그레이션 자체를 깊이 판다. CRA → Vite, Moment → date-fns/Temporal, Yarn 1 → pnpm, requirements.txt → uv를 실제 코드와 함께 한 단계씩 옮기는 안내서다. 무엇을 깨고, 무엇을 미루고, 무엇을 자동화할 것인가 — "옮기는 결정"을 "옮긴 결과"로 만드는 실전편.

도구의 수명을 인정하는 것은 패배가 아니다. 다음 단계로 가는 첫 결정이다.

---

참고 / References

• React 공식 문서, "Create React App is deprecated" 안내 — https://react.dev/learn/start-a-new-react-project
• React 팀 블로그, "Sunsetting Create React App" — https://react.dev/blog/2025/02/14/sunsetting-create-react-app
• Moment.js 공식 공지, "Moment is now a legacy project" (2020년 9월) — https://momentjs.com/docs/#/-project-status/
• date-fns — https://date-fns.org/
• Day.js — https://day.js.org/
• TC39 Temporal 제안 — https://tc39.es/proposal-temporal/docs/
• pnpm — https://pnpm.io/
• Bun — https://bun.sh/
• Yarn 4 (Berry) — https://yarnpkg.com/
• Turborepo — https://turbo.build/repo
• Nx — https://nx.dev/
• Vite — https://vite.dev/
• Rspack — https://rspack.dev/
• Turbopack — https://turbo.build/pack
• TanStack Start — https://tanstack.com/start
• Bower, "Bower is dead, long live npm" — https://bower.io/blog/2017/how-to-migrate-away-from-bower/
• uv (Astral) — https://docs.astral.sh/uv/
• pipx — https://pipx.pypa.io/stable/
• mise — https://mise.jdx.dev/
• Poetry — https://python-poetry.org/
• Hatch — https://hatch.pypa.io/latest/
• Pixi — https://prefix.dev/
• Hugging Face Open LLM Leaderboard, v2 발표 — https://huggingface.co/spaces/open-llm-leaderboard/open_llm_leaderboard
• Hugging Face 블로그, "Open LLM Leaderboard v2 archive" — https://huggingface.co/blog/leaderboard-archive
• LMArena — https://lmarena.ai/
• Artificial Analysis — https://artificialanalysis.ai/
• SWE-bench — https://www.swebench.com/
• LiveCodeBench — https://livecodebench.github.io/
• LangChain v0.2 마이그레이션 가이드 — https://python.langchain.com/docs/versions/v0_2/
• LangGraph — https://langchain-ai.github.io/langgraph/
• LlamaIndex — https://docs.llamaindex.ai/
• OpenTelemetry — https://opentelemetry.io/
• Grafana Tempo — https://grafana.com/oss/tempo/
• Vector(Datadog 오픈소스) — https://vector.dev/
• Docker Hub 풀 제한 정책 — https://docs.docker.com/docker-hub/usage/
• cosign(Sigstore) — https://docs.sigstore.dev/cosign/overview/
• Travis CI 오픈소스 정책 변경 — https://blog.travis-ci.com/oss-announcement
• GitHub Actions — https://docs.github.com/actions
• SOPS(Mozilla) — https://github.com/getsops/sops
• Doppler — https://www.doppler.com/
• HashiCorp Vault — https://www.vaultproject.io/
• SealedSecrets — https://sealed-secrets.netlify.app/
• gitleaks — https://github.com/gitleaks/gitleaks
• trufflehog — https://github.com/trufflesecurity/trufflehog
• Playwright — https://playwright.dev/
• Cypress — https://www.cypress.io/
• Caddy — https://caddyserver.com/
• Envoy — https://www.envoyproxy.io/