LabHub

블로그

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

2026-05-14 · 39 분 읽기 · #anti-pattern#tools-to-avoid#developer-tools#curation#retired-tools#opinion#modernization#tech-debt#decision-making

한국어English日本語

이 글은 "쓰지 마라"는 부정의 글이 아니다. 좋았던 시절을 인정한 뒤, 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년 사이에 쓰인 튜토리얼이 여전히 상위 결과를 차지하고, 회사 내부 문서도 그 시절에 멈춰 있다. 새 입사자는 그 경로를 그대로 따른다.

무엇을 대신 쓰나.

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

2.2 Moment.js

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

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

무엇을 대신 쓰나.

좋았던 점. 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는 손에 익는다.

무엇을 대신 쓰나.

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

2.4 Gulp / Grunt / Bower

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

무엇을 대신 쓰나.

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

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

3.1 Yarn 1

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

무엇을 대신 쓰나.

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

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

무엇을 대신 쓰나.

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

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

무엇을 대신 쓰나.

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

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

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

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

무엇을 대신 쓰나.

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

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

무엇을 대신 쓰나.

4.3 conda를 "모든 것"에 쓰기

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

무엇을 대신 쓰나.

좋았던 점. 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년 아카이브 상태로 전환됐다. 새 점수가 더 이상 산출되지 않는다.

무엇을 대신 쓰나.

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

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

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

무엇을 대신 쓰나.

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

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

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

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

무엇을 대신 쓰나.

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

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

무엇을 대신 쓰나.

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

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

무엇을 대신 쓰나.

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

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

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

무엇을 대신 쓰나.

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

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

무엇을 대신 쓰나.

7.3 "main에 직접 푸시" 문화

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

무엇을 대신 쓰나.

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

8.1 VS Code 확장 비만

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

무엇을 대신 쓰나.

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

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

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

무엇을 대신 쓰나.

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

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

무엇을 대신 쓰나.

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

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

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

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

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

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

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

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

이번 분기 한 가지만 한다면

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

도입 전 6질문 체크리스트

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

안티패턴 요약

다음 글 예고

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

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

참고 / References

원문 보기: https://www.youngju.dev/blog/culture/2026-05-14-tools-and-trends-to-avoid-2026-developer-anti-recommendations-curated-deep-dive-2026

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다