Skip to content

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

|

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

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


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

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

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

이 글의 전제는 단순하다.

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

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


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

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

범주AVOIDINSTEAD한 줄 이유
프론트엔드 부트스트랩Create React AppVite / Next.js / TanStack StartCRA는 2023년 공식 권장 중단, 2025년 사실상 동결
날짜 처리Moment.jsdate-fns / Day.js / TemporalMoment 팀이 "레거시"라고 직접 선언
유틸리티 라이브러리lodash 풀임포트표준 ES / 개별 함수 / Bun 빌트인트리 셰이킹 손해, 표준이 따라잡음
Node 패키지 매니저Yarn 1pnpm / Bun / Yarn 4Yarn 1은 더 이상 갱신되지 않음
모듈 번들러Webpack 단독 / Gulp 빌드Vite / Rspack / Turbopack / Bun콜드 스타트와 HMR이 한 자릿수 ms 시대
모노레포Yarn Workspaces 단독pnpm + Turborepo / Nx캐시와 영향-분석이 표준이 됨
파이썬 도구 설치apt-get install pythonuv / pipx / mise시스템 파이썬 오염 회피
파이썬 의존성pip install -r requirements.txtuv / Poetry / Hatch락파일과 동시 설치
AI 평가Open LLM LeaderboardLMArena / Artificial Analysis2024년 6월 아카이브 처리
LLM 통합LangChain <v0.2 깊은 임포트langchain-* 분리 패키지 / LlamaIndex / 직접 호출깊은 임포트 경로 자체가 바뀜
프롬프트"당신은 전문가입니다" 류 접두시스템 프롬프트 + 명세 + 평가모델이 더 똑똑해지면서 효용 사라짐
관측AppDynamics / 무거운 APMOpenTelemetry + Grafana / Tempo표준 텔레메트리, 벤더 락인 회피
로그 수집자체 포워더 + 자체 포맷OTel collector + 구조화 JSON표준이 곧 비용
CITravis CI (오픈소스 무료 종료)GitHub Actions / GitLab CI / BuildkiteTravis OSS 무료 정책 종료
컨테이너 빌드Docker Hub 무인증 풀 의존자체 미러 / ECR / GHCR / 사내 캐시풀 제한이 빌드 SLA를 흔듦
비밀 관리.env 커밋, 평문 공유SOPS / Doppler / Vault / SealedSecrets사고의 단일 원인 1위
에디터VS Code "확장 다 깔기"확장 다이어트 / 신뢰 가능한 출처만공급망과 성능을 동시에 해침
협업"PR 리뷰 안 함, 직접 머지"짧은 PR + 빠른 리뷰 + 머지 큐리뷰 없는 조직은 학습이 멈춤

표는 길지만 의도가 있다. 항목 자체가 아니라 짝을 기억하기를 바라기 때문이다. "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는 환경의 스냅숏이지 의존성 명세가 아니다. 직접 명시한 의존성과 그것이 끌고 온 전이 의존성이 섞이고, 플랫폼별 차이가 무시된다. 결과: 다른 머신에서 "내 머신에서는 됐는데"가 반복된다.

무엇을 대신 쓰나.

  • uvpyproject.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장 · 회색지대 — 죽지 않았지만 디폴트로는 아닌 도구들

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

도구디폴트가 아닌 이유그래도 쓰는 맥락
Jenkins셀프호스트 운영 부담, UI/플러그인 부채큰 사내, 강한 격리/온프레미스 요구
VagrantDocker/Devcontainer로 대부분 대체특정 VM 환경 재현이 진짜 필요할 때
MongoDB 디폴트트랜잭션/스키마/리포팅 약점비정형 + 고쓰루풋 + 스키마 진화가 빠른 도메인
jQueryDOM API와 fetch가 거의 흡수옛 시스템 유지 / 매우 단순한 페이지
Bootstrap 5 디폴트토큰/유틸리티 우선 시대와 어긋남빠른 사내 도구, 디자인 시스템 없음
Selenium신규는 Playwright/Cypress가 표준옛 그리드 자산, 비표준 브라우저
Nginx 수동 설정Caddy/Envoy가 더 모던한 디폴트정밀 튜닝, 큰 기존 자산

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


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

Tools and Trends to Avoid in 2026 — A Curated Anti-Recommendation Deep Dive

This is not a "stop using these" rant. It is a curated list of tools and trends that, as of 2026, I no longer recommend — paired in every case with what to use instead. Opinions, but with receipts.


Prologue — Why we need anti-recommendations

There are plenty of articles about good tools. Articles that tell you which tools to leave are rarer, for two reasons. First, criticizing someone's nostalgia and someone's working software is unpopular. Second, tools never live in a vacuum, so any "this is bad" claim is almost always only partly true.

Someone still has to write it. The tutorial a 2026 new hire finds first is often stuck in 2018, and half of the tools that tutorial recommends are no longer maintained. Starting a new project on that path means broken builds in the first week, piling security advisories in the first month, and a migration bill in the first quarter.

Premises of this article:

  1. Every tool was right at some point. Criticism does not erase that.
  2. The cost equation flips over time. Eventually "what this tool prevents" outweighs "what this tool did."
  3. Criticism without alternatives is lazy. Every item below ships with a replacement.
  4. The replacements are not eternal either. In a year, half of this article will need rewriting.

That last premise matters. Read this as guidance — "if I were starting a new project today, where would I not start?" — not as scripture.


1. The matrix at a glance — AVOID / INSTEAD

A map before the territory.

CategoryAVOIDINSTEADOne-line reason
Frontend bootstrapCreate React AppVite / Next.js / TanStack StartCRA was officially un-recommended in 2023; effectively retired in 2025
Date handlingMoment.jsdate-fns / Day.js / TemporalMoment's own team calls it "a legacy project"
Utility libraryFull lodash importStandard ES / per-function / Bun built-insTree-shaking loss, standards caught up
Node package managerYarn 1pnpm / Bun / Yarn 4Yarn 1 receives no real updates
BundlerStandalone Webpack / Gulp buildsVite / Rspack / Turbopack / BunSingle-digit-ms cold starts and HMR
MonorepoYarn Workspaces alonepnpm + Turborepo / NxCaching and impact analysis are now table stakes
Python tooling installapt-get install pythonuv / pipx / miseStop polluting the system Python
Python depspip install -r requirements.txtuv / Poetry / HatchReal lockfiles and parallel installs
AI evalOpen LLM LeaderboardLMArena / Artificial AnalysisArchived in 2024-2025
LLM integrationLangChain <v0.2 deep importsSplit langchain-* packages / LlamaIndex / direct SDKsThe deep paths themselves moved
Prompting"You are an expert in..." preamblesSystem prompt + spec + evalsFrontier models stopped rewarding generic flattery
ObservabilityAppDynamics / heavy APMOpenTelemetry + Grafana / TempoOne standard, no lock-in
Log shippingCustom forwarder + custom formatOTel collector + structured JSONStandards are leverage
CITravis CI (OSS-free era over)GitHub Actions / GitLab CI / BuildkiteTravis ended the OSS free tier
Container buildsUnauthenticated Docker Hub pullsInternal mirror / ECR / GHCR / cachePull limits break your build SLA
SecretsCommitted .env, plaintext sharingSOPS / Doppler / Vault / SealedSecretsThe #1 single-cause incident
EditorVS Code "install everything"Extension diet, vetted publishers onlySupply chain and performance, simultaneously
Collaboration"No review, push to main"Short PRs + fast review + merge queuesA team that never reviews stops learning

The table is long on purpose. The point is not the item but the pair. "Not Moment" is not the lesson — "not Moment, instead date-fns/Temporal" is.


2. Frontend — CRA, Moment, full lodash imports

2.1 Create React App

What went wrong. CRA shipped from Facebook in 2016 as the one-line bootstrap for React. It abstracted dependencies and a Webpack 4 config, which lowered the on-ramp dramatically. But maintenance effectively stopped in 2022, the official React docs deprecated it for new apps in March 2023, and the React team posted an explicit sunset notice in 2025. Cold starts climb into tens of seconds to minutes, security advisories pile up, and the path to new React features (server components, streaming, the App Router) does not run through CRA anymore.

Why people still reach for it. Search results take them there. Tutorials written between 2018 and 2022 still rank at the top, and internal company docs froze around the same time. New hires follow the path.

Use instead.

  • Single-page app: Vite + React. Sub-second cold starts, instant HMR.
  • Full-stack / routing / server components: Next.js. The de facto React meta-framework.
  • Routing-first SPA with a thin server: TanStack Start. Type-safe router and data loading.

Credit where due. CRA defined "one command to start" for React. The default-friendliness of every successor is its legacy.

2.2 Moment.js

What went wrong. Moment was the de facto JavaScript date library. But its mutable object model, large bundle, full locale bundling, and non-tree-shakable surface clash with modern frontend values. Decisively, the Moment team declared it "a legacy project" in September 2020: no new features, only critical fixes.

Why people still reach for it. The old code already imports it. And the alternatives are plural enough to cause decision paralysis.

Use instead.

  • date-fns: functional, tree-shakable, widest interoperability. Default choice for formatting and arithmetic.
  • Day.js: API-compatible with Moment. Lowest migration cost.
  • Temporal: an ECMAScript proposal in late stages. Adoptable today via polyfill. This is where the world is going.
  • Luxon: from a former Moment maintainer. More opinionated.

Credit where due. Without Moment, working with Date for a decade would have been worse than it already was. It bought time for the standard to catch up.

2.3 Full lodash import

What went wrong. import _ from 'lodash' pulls the whole library into the bundle. By 2026 the standard has absorbed about half of lodash: Array.prototype.at, structuredClone, Object.groupBy, Array.fromAsync, Promise.any, Promise.allSettled, String.prototype.replaceAll, optional chaining, nullish coalescing. lodash itself has had effectively no major updates since 4.17.21 in 2021.

Why people still reach for it. Old code and old muscle memory. _.get, _.pick, _.debounce are habit-shaped.

Use instead.

  • Prefer the standard whenever possible.
  • Deep access: optional chaining and nullish coalescing.
  • If you still need a specific lodash function, import from lodash-es per-function: import { debounce } from 'lodash-es'.
  • On Bun, check the runtime built-ins first.

Credit where due. lodash's documentation was, for years, the de facto reference for the JavaScript standard library.

2.4 Gulp / Grunt / Bower

What went wrong. Bower formally announced "we are done" in 2017 and pointed users at npm/yarn. Gulp/Grunt had real value when bundlers were less capable, but as Webpack and successors absorbed the pipeline, their footprint shrank. In 2026, encountering a new project on Gulp is rare.

Use instead.

  • Bundle/HMR: Vite, Rspack, Turbopack, Bun.
  • Task runners: package.json scripts + npm-run-all / concurrently / turbo run.

Credit where due. "Builds are code" was their gift. The idea survived; only the tools changed.


3. Node toolchain — Yarn 1, lone Workspaces, hand-rolled Webpack

3.1 Yarn 1

What went wrong. Yarn 1 was the hero of 2017-2020: it fixed npm's worst issues at the time. But Yarn 2+ split off into the Berry line, and 1.x became effectively frozen aside from security work. The bigger issue is the flattened node_modules strategy, which allows accidental dependency resolution — exactly what pnpm solved.

Use instead.

  • General single project: pnpm. Disk-efficient, strict resolution.
  • Monorepo: pnpm workspaces + Turborepo or Nx.
  • Speed: Bun. Fast install and run, broadening compatibility.
  • If you love Yarn itself: Yarn 4 (Berry, with PnP or nodeModulesLinker). Vet PnP compatibility before committing.

3.2 Running a monorepo on Yarn Workspaces alone

What went wrong. Workspaces themselves are fine. But a monorepo without a build cache, impact analysis, or remote caching collapses quickly. Once humans start deciding "what does this PR need to rebuild?", you have lost.

Use instead.

  • Turborepo: simple config, JS/TS-centric.
  • Nx: more powerful graph and plugins. Polyglot or large org.
  • Bazel: very large org, polyglot. Only when you can afford the learning curve.

3.3 Hand-rolled webpack.config.js

What went wrong. Webpack is not bad. But in 2026, sitting down to author a custom Webpack config — every loader, every plugin, by hand — is almost always a loss. Vite and Turbopack took most of that ground, and Rspack (Rust-based, Webpack-compatible) is catching the rest.

Use instead.

  • New projects: Vite, Next.js built-in, Turbopack via Next.
  • Existing Webpack assets you do not want to rewrite: Rspack. Keep the config, gain the speed.

Credit where due. Webpack defined "frontend build" as a concept. The mental model — entries, loaders, plugins — lives on in every successor.


4. Python — system Python, lone requirements.txt, conda overuse

4.1 apt-get install python (or brew install python) used as a tooling install

What went wrong. The system Python is part of the operating system. pip install into it breaks OS tooling in ways that are painful to recover. "Always use a venv" is a fine rule, but a rule humans hand-enforce is finished.

Use instead.

  • uv (Astral): Rust-based fast Python project manager. Quick resolution, install, and lockfiles by default. The new de facto standard since 2024-2025.
  • pipx: install CLI-style Python tools (black, httpie) into isolation.
  • mise or asdf: pin Python versions per project. Faster than pyenv, polyglot-friendly.

4.2 requirements.txt alone with pip freeze

What went wrong. pip freeze > requirements.txt is a snapshot of an environment, not a specification of dependencies. Direct deps and transitive deps merge, platforms collapse together, and "works on my machine" returns.

Use instead.

  • uv's pyproject.toml + uv.lock. Direct deps and lockfile are separate; cross-platform locks supported.
  • Poetry: opinionated experience. Popularized lockfiles for Python.
  • Hatch: builds and environment management aligned with PEPs.

4.3 conda for everything

What went wrong. conda shines when your science stack is heavy and full of native libraries. For pure Python web apps or CLIs, dependency resolution drags into minutes, channel conflicts appear, and Anaconda's commercial-channel policies add license risk to enterprise use.

Use instead.

  • Pure Python: uv or Poetry.
  • Science / ML / native: mamba (fast conda-compatible) or pixi (Rust-based, conda-package aware, integrates lockfiles and tasks). pixi is gaining ground fast in 2024-2026.

Credit where due. conda was the first tool that made GPU stacks installable without an OS package manager — and that gift is still real for the right workload.


5. AI eval and LLM integration — Open LLM Leaderboard, old LangChain, stale prompt tricks

5.1 Open LLM Leaderboard

What went wrong. Hugging Face's Open LLM Leaderboard was the de facto standard for open-model evaluation in 2023-2024. But the original eval set (MMLU, ARC, HellaSwag, TruthfulQA, Winogrande, GSM8K) saturated quickly, and parts of it leaked into training data. Hugging Face migrated to v2 in June 2024, then placed v2 itself into an archive state during 2025. Fresh scores no longer appear.

Use instead.

  • LMArena (formerly Chatbot Arena): pairwise human preference, Elo-style ranking. The single most reliable "which model is better" signal.
  • Artificial Analysis: quality vs. price vs. latency, side by side. Useful for actual procurement.
  • Domain benchmarks: SWE-bench for software engineering, LiveCodeBench for contamination-resistant coding, MMLU-Pro for harder reasoning, GPQA for graduate-level science.
  • Internal eval: every team needs a golden set of its own. The above narrow the candidate field; your set picks the winner.

5.2 Pre-v0.2 LangChain deep imports

What went wrong. LangChain code from 2023-2024 often reached deep — from langchain.something.deep.path import X. From v0.2 onward, the package was split into langchain, langchain-core, langchain-community, integration-specific langchain-openai, langchain-anthropic, and langgraph for agent graphs. Most of those deep paths broke.

Why people still reach for it. Old tutorials still rank, new hires copy-paste them, and the v0.2+ migration guide is long enough to defer.

Use instead.

  • If you keep LangChain, import from the integration-specific packages and use langgraph for agent topologies.
  • For simple calls, skip LangChain and use the official SDKs (Anthropic, OpenAI, Google). The abstraction often costs more than it pays.
  • Retrieval and indexing: LlamaIndex — surface is more consistent.
  • Multi-agent orchestration: weigh LangGraph, CrewAI, OpenAI Swarm. The fancier the abstraction, the harder the debugging.

Credit where due. LangChain crystallized the idea of "wiring an LLM into code." It also had to reshape itself repeatedly while best practices solidified, which is why old and new look so different.

5.3 "You are an expert in X" preambles and friends

What went wrong. In 2022-2023, prefixes like "You are a senior engineer, think step by step, take a deep breath" really did help. As models were RLHF-aligned and trained on tool use, the marginal value of those generic preambles collapsed. Since 2025, the major vendors' prompting guides ask for specification, not flattery.

Use instead.

  • System prompts that specify role, constraints, prohibitions, output format. Not "expert" — "produce auditable SQL, no comments, single transaction".
  • Change prompts against an eval set. Numbers, not vibes.
  • Long system prompts hurt cache hit rate and context cost. Short, sharp, structured.
  • If you need chain-of-thought, replace "think step by step" with explicit steps and an output schema (JSON Schema).

Credit where due. Not every old trick was empty. "Let's think step by step" had real effect once, and that observation seeded the entire reasoning-models line. Tricks were absorbed into training.


6. Observability and infrastructure — heavy APM, custom forwarders, Docker Hub habits

6.1 AppDynamics / Dynatrace on a small stack

What went wrong. Full-stack APMs make sense for large enterprise monoliths. For a five-person team with ten microservices, license cost and operational drag outweigh the value, and vendor lock-in is real.

Use instead.

  • The standard is OpenTelemetry (OTel). One spec for metrics, logs, traces.
  • Metrics: Prometheus + Grafana.
  • Traces: Tempo or Jaeger.
  • Logs: Loki or a cloud-native equivalent.
  • For hosted bundles: Grafana Cloud, Honeycomb. Evaluate hosting cost separately.
  • If you genuinely need an integrated commercial product: Datadog, New Relic. Benchmark by their OTel compatibility.

6.2 Custom log forwarder, custom format, custom pipeline

What went wrong. "Our own log format" is fast for six months and slow for six years. Every new tool needs an adapter, and search, retention, and storage all become DIY.

Use instead.

  • Format: structured JSON, keys aligned with OpenTelemetry semantic conventions.
  • Forwarder: OpenTelemetry Collector or Vector (open source from Datadog).
  • Storage: managed, or ClickHouse / OpenSearch. Build it yourself as a last resort.

6.3 Pinning your build SLA to anonymous Docker Hub pulls

What went wrong. Docker Hub has applied rate limits on unauthenticated/free pulls since 2020. When CI hits the limit, builds fake-fail. You also trust upstream base images with no separate verification.

Use instead.

  • Internal mirror: Harbor, JFrog Artifactory, or a cloud registry (ECR, GHCR, Artifact Registry).
  • Pull base images through the mirror; verify SBOM and signatures (cosign).
  • Make multi-architecture targets explicit (amd64/arm64).

7. DevOps and CI — Travis OSS, hand-rolled bash, push-to-main

7.1 Pinning an OSS project's CI to Travis

What went wrong. Travis CI built the OSS-free CI era. Their post-2020 policy change made many OSS projects effectively unable to keep using it. Starting a new OSS project on Travis in 2026 makes very little sense.

Use instead.

  • Most common: GitHub Actions. OSS minutes generous enough for almost everything.
  • Strongest caching/parallelism: Buildkite (self-hosted agents), CircleCI.
  • GitLab shops: GitLab CI.
  • Monorepos: Turborepo / Nx caching layered on any of the above.

7.2 Hand-written bash as the core of your build

What went wrong. Bash is powerful and ubiquitous. Bash scripts over 100 lines almost always pick the wrong abstraction. The person who knows the env vars leaves; the env vars go with them.

Use instead.

  • Simple command bundles: package.json scripts, mise tasks, just.
  • Build graphs: Turborepo, Nx, Bazel.
  • When a bash script gets long, that is the signal to migrate to a tool. 200 lines is a number, not a goal.

7.3 "Push to main" culture

What went wrong. This is a process anti-pattern, not a tool one. Small teams move fast that way — until they do not. Unreviewed merges are the first sign a team has stopped learning, and incidents arrive exactly on schedule.

Use instead.

  • Short PRs (under roughly 400 lines changed) as a norm.
  • Merge queues (Mergify, GitHub Merge Queue) — prevent main breakage.
  • Auto-merge rules — review approved plus CI green equals merge.
  • CODEOWNERS plus a single-reviewer rule — route changes to people who care.

8. General process anti-patterns — VS Code extension bloat, .env in git, "let's rewrite"

8.1 VS Code extension bloat

What went wrong. VS Code's rich extension ecosystem is a strength. When it becomes a default — "looks useful, install it" — two things break at once. Performance (startup time, memory, language-server clashes) and supply chain (malicious extensions, typosquatting).

Use instead.

  • Extension diet. Each quarter, remove what you do not use.
  • Vet publishers: Microsoft, official language teams, known companies. Anything else gets reviewed before install.
  • Workspace-recommended extensions (extensions.json).
  • Different tools for different work. Heavy IDEs only when you really need them.

Credit where due. VS Code's extension model permanently changed the editor world. The problem is not the model, it is the lack of restraint.

8.2 Committed .env, plaintext secrets, tokens in chat

What went wrong. The single most common root cause of incidents. A committed secret is forever — even history rewrites do not reliably catch every copy.

Use instead.

  • Local: direnv + .envrc.local (never committed) + 1Password CLI / op read.
  • Team: SOPS + age/KMS, Doppler, 1Password Secrets Automation.
  • Infrastructure: Vault, cloud secrets managers (AWS Secrets Manager, GCP Secret Manager), SealedSecrets (Kubernetes).
  • Detection: git-secrets, gitleaks, trufflehog in both pre-commit hooks and CI.

8.3 "It is old, let us rewrite everything"

What went wrong. The temptation to apply every recommendation in this article in one quarter. Big rewrites are the most expensive way to repay debt, and new debt accrues while the rewrite runs.

Use instead.

  • Strangler-fig pattern: new code grows around old code until the old code is unreachable.
  • Module-by-module migration, one at a time.
  • A quarterly "replace one tool" goal. Four per year is a lot.
  • Each migration logs before/after metrics (build time, bundle size, vulnerability count). Today's decision becomes tomorrow's evidence.

9. The gray zone — not dead, just not your default

This is not "never use these." These are tools that I would not pick as the default for a new project in 2026, but where context can justify them.

ToolWhy not the defaultWhere it still fits
JenkinsSelf-host burden, plugin debtLarge internal estates, strict on-prem requirements
VagrantDocker/Devcontainers absorbed most casesGenuine need for VM-level reproducibility
MongoDB by defaultTransactions, schema, reporting weakHigh-churn schemas plus throughput, true unstructured data
jQueryModern DOM + fetch handle most casesLegacy systems, very simple pages
Bootstrap 5 by defaultOut of step with token-and-utility-first designInternal tools that need to ship without a design system
SeleniumPlaywright/Cypress are the modern defaultOld grid investments, non-standard browsers
Hand-tuned NginxCaddy/Envoy are more modern defaultsPrecise tuning, large existing assets

Gray-zone honesty matters. "Not the default, but rational here" is a real category. Tools live in context.


10. A short eulogy for what they got right

Before the wake, the toasts.

  • CRA turned "starting React" from a research project into one command. Every successor's default-friendliness inherits its legacy.
  • Moment.js filled a decade-long gap in the JavaScript date API and bought time for the standard to catch up.
  • lodash doubled as the de facto reference manual for the JS standard library — the example list the standard now lives up to.
  • Webpack defined "frontend build" as a category. The mental model is inherited by Vite, Rspack, Turbopack.
  • Jenkins popularized CI culture.
  • Travis CI opened the OSS-CI free tier era.
  • LangChain named the pattern of wiring LLMs into code, and reshaped itself many times to keep the road clear for everyone else.
  • AppDynamics invented the full-stack APM category.

Criticism's partner is gratitude. Today's better tools stand on roads these tools paved.


Epilogue — A one-quarter checklist and the next post

If you can only do one thing this quarter

For a new project, take defaults from the matrix above and move on. For an existing project, replace the slowest step of the most frequently-run pipeline — and only that. Trimming a 30-minute step from a job that runs 100 times a week returns 50 hours per quarter.

Pre-adoption six-question checklist

  1. Is this tool maintained? Check the last release date and the closed-issue ratio.
  2. What is the official recommendation status? Look for words like "deprecated."
  3. Is there an alternative and migration path? Do not adopt locked-in.
  4. Is the bundle/runtime cost worth it? Do not add a dependency for what the standard now does.
  5. How is the supply chain risk handled? Extensions, plugins, and nodes are all third-party code.
  6. What is the exit cost? If you regret it in six months, can you get out?

Anti-patterns to remember

  • Stopping at the first search result — 2018-2022 articles still rank first in half of all queries.
  • "The team is used to it" — familiarity is an asset to one group and a liability to the next.
  • "It has 10,000 stars" — stars are attention, not adoption.
  • "We will rewrite next week" — big rewrites are the most expensive way to repay debt.
  • Criticizing without alternatives — every item here pairs with one for a reason.

Coming next

The next post takes the migrations themselves seriously. CRA → Vite, Moment → date-fns/Temporal, Yarn 1 → pnpm, requirements.txt → uv: a working, step-by-step playbook with real code, what to break, what to defer, what to automate. The piece that turns the decision to migrate into a finished migration.

Accepting a tool's expiration date is not a defeat. It is the first move of the next decision.


References