2026년 2월 5일 목요일

[State of JS 2025] 2025 JS 생태계 정리: Vite 툴체인 확정 + Next.js 만족도 하락 + AI 코딩 본격화

State of JS 2025 분석: Vite 툴체인 확정, Next.js ‘역설’, 그리고 AI 코딩 29% 시대의 실전 체크리스트

State of JavaScript 2025 리포트를 바탕으로, 2026년 팀의 프론트/풀스택 기술 선택(빌드·테스트·메타프레임워크·백엔드·AI 도입 규칙)을 “바로 적용 가능한 기준”으로 정리합니다.

지금 JS 생태계는 “도구의 승리”가 아니라 “선택의 비용”이 커진 시대입니다. 이 글은 그 비용을 줄이는 체크리스트를 제공합니다

이미지: AI 생성(리포트 핵심 주제인 툴체인/테스트/AI 코딩 흐름을 시각화)

원문 리포트: State of JavaScript 2025

왜 이 리포트를 봐야 하나

State of JS 2025는 단순 “인기 투표”가 아니라, 도구/프레임워크별로 사용률(usage), 만족도(satisfaction), 관심도(interest) 같은 지표를 함께 제공합니다. 즉, “많이 쓰는데 불만이 큰지”, “아직 안 쓰지만 곧 들어올지”를 분리해서 볼 수 있습니다.

특히 이번 리포트는 도구 변화(빌드·테스트), 프레임워크 변화(SSR/메타프레임워크), 그리고 개발 방식 변화(AI 코드 생성 비중 증가)가 동시에 나타납니다. 그래서 “우리 팀은 내년 무엇을 채택/유지/정리해야 하는가?”를 결정하기에 딱 좋은 타이밍의 자료입니다.

핵심 변화 3가지

1) ‘Vite 툴체인’이 사실상 표준 라인업이 됨

리포트 결론에서는 Vite 다운로드가 webpack을 넘어섰다는 점을 짚고, Rolldown 기반으로 더 빨라질 Vite의 다음 스텝까지 이야기합니다. (결론 섹션: Conclusion)

Awards에서도 Vite는 만족도 98%로 최상위권이고, Vitest는 관심도 83% 및 “가장 빠르게 채택되는 도구(전년 대비 +14%)”로 등장합니다. (Awards: Awards)

2) Next.js는 커지는데, 만족도는 떨어진다

Meta-frameworks 분석에서는 “Next.js의 점유는 늘지만 만족도는 하락”이라는 흐름을 강하게 언급하고, Astro 대비 만족도 격차가 크다는 포인트도 함께 나옵니다. (Meta-frameworks: Meta-frameworks)

이건 “Next.js가 나쁘다”가 아니라, 스케일이 커질수록 복잡도/운영/성능/비용 문제로 불만이 드러나는 단계에 들어갔다는 신호로 읽는 게 실무적으로 유용합니다.

3) AI 코딩은 ‘보조’가 아니라 ‘생산 비중’의 문제

Usage 섹션은 “AI가 생성한 코드 비중 평균 29%”라는 숫자를 제시합니다. 또한 AI 도구 사용 순위에서 ChatGPT, Copilot, Claude, Gemini, Cursor 같은 도구들이 실제로 얼마나 쓰이는지도 수치로 보여줍니다. (Usage: Usage, Other Tools: Other Tools)

빌드/테스트 툴체인: Vite · Vitest · Playwright

이미지: AI 생성(빌드/단위테스트/브라우저테스트 파이프라인 개념도)

빌드 도구: Vite는 ‘기본값’이 되어가고, 다음은 Rolldown

Build Tools 섹션의 코멘터리/결론을 종합하면 흐름은 명확합니다. Vite는 이미 “현재의 표준”으로 자리잡았고, 다음 경쟁 포인트는 “더 빠른 번들링/개발 경험”으로 이동 중입니다. (Build Tools: Build Tools, Conclusion: Conclusion)

실무 적용: “webpack을 언제까지 유지할 것인가” 판단 기준

  • 유지 가능: 대규모 레거시 설정(커스텀 로더/플러그인) 의존이 깊고, 현재 병목이 빌드가 아니라 런타임/데이터 계층에 있을 때
  • 전환 추천: 신규 프로젝트, 또는 FE 플랫폼을 재정비하는 팀(모노레포/패키지 분리/테스트 강화)일 때
  • 전환 시 주의: “설정 단순화”가 목표여야지, 설정을 그대로 옮기려 하면 전환 효과가 줄어듭니다

테스트: Jest → Vitest 이동이 현실화되는 신호

Testing 섹션은 Vitest가 빠르게 성장하며 Jest와의 역전 가능성을 언급합니다. Awards에서도 Vitest는 “Most Adopted”로 표시될 만큼 채택 증가폭이 큽니다. (Testing: Testing, Awards: Awards)

실무 적용: 팀 테스트 스택 추천(현실적인 조합)

  • 단위/통합: Vitest (+ Testing Library 계열)
  • E2E/브라우저: Playwright
  • 품질 게이트: PR마다 최소 단위 테스트, main merge 전 최소 E2E(핵심 플로우) 1회

예시: Vitest + React 테스트 스니펫


// vitest + @testing-library/react 예시(개념)
// npm i -D vitest @testing-library/react @testing-library/jest-dom jsdom

import { describe, it, expect } from "vitest";
import { render, screen } from "@testing-library/react";

function Hello({ name }: { name: string }) {
  return <h1>Hello, {name}</h1>;
}

describe("Hello", () => {
  it("renders name", () => {
    render(<Hello name="Vite" />);
    expect(screen.getByText("Hello, Vite")).toBeTruthy();
  });
});

메타프레임워크: Next.js의 성장과 만족도 하락

Meta-frameworks 섹션은 Next.js가 여전히 시장을 주도하지만, 만족도 측면에서 이전과 다른 신호를 보여준다고 정리합니다. (Meta-frameworks: Meta-frameworks)

실무적으로 중요한 질문: “우리 팀의 Next.js 불만은 어디서 오나?”

만족도 하락은 보통 “학습 곡선” 문제가 아니라, 운영 단계에서 겪는 다음 이슈에서 발생하는 경우가 많습니다. 여기부터는 팀 내부 회고/이슈 로그와 연결하면 글이 ‘현업 글’이 됩니다.

  • 빌드/캐시 복잡도: 캐시/프리렌더/서버 컴포넌트 조합이 커지면 디버깅 비용이 상승
  • 성능 튜닝 난이도: 번들·렌더·데이터 패칭 경로가 여러 레이어로 분산
  • 운영 비용: 배포 방식/호스팅/이미지 최적화/엣지 런타임 등 선택지가 늘수록 비용/락인이 커짐
  • 팀 생산성: “규칙”이 없으면 코드베이스가 빠르게 다중 패턴으로 오염

대안 포지셔닝: Astro 같은 선택이 유효한 팀

리포트가 말하는 핵심은 “대안이 떠오른다”가 아니라, 프로젝트 성격에 맞는 프레임워크 분화가 강해졌다는 겁니다. 마케팅 사이트/콘텐츠 중심 사이트/부분적 인터랙션은 다른 해법이 더 잘 맞을 수 있습니다.

실무 적용: 프레임워크 선택 기준(간단 매트릭스)

요구사항 추천 방향 이유
복잡한 앱(대시보드/권한/상태 많음) Next.js(단, 규칙 기반 운영) 풀스택/라우팅/데이터 패턴 통합
콘텐츠 중심(블로그/문서/랜딩) Astro 계열 고려 성능/단순성/빌드 전략이 명확
SSR이 필요하지만 운영 최소화 “필요한 만큼만 SSR” 전략 SSR이 만능이 아니라는 비용 인식

백엔드 프레임워크: Express 1위와 신흥 강자

Back-end frameworks 섹션에서는 Express가 여전히 사용률 1위를 차지하는 한편, 만족도 측면에서 Hono/Nitro/ElysiaJS 같은 프레임워크가 눈에 띄게 등장합니다. (Back-end frameworks: Back-end frameworks)

실무 적용: “새로운 백엔드 프레임워크를 언제 도입할까?”

  • 도입해볼 만함: 신규 서비스, 엣지/서버리스, 성능/콜드스타트가 KPI인 경우
  • 보수적 접근: 레거시 Express 대규모 유지보수 중이라면 “프레임워크 교체”보다 “테스트/관측성/모듈화”가 먼저
  • 추천 전략: 작은 서비스/서브도메인부터 실험 → 운영 데이터로 확대
이미지: AI 생성(Node.js 백엔드 프레임워크 비교를 돕는 시각 자료)
이미지: AI 생성(Node.js 백엔드 프레임워크 비교를 돕는 시각 자료)

언어/표준: Temporal과 ‘JS에 부족한 것’

Features 섹션에서 Temporal이 가장 큰 관심을 받는 제안으로 올라옵니다. 그리고 “JS에 부족한 것”에서는 static typing, standard library, signals 같은 항목이 상위로 등장합니다. (Features: Features)

실무 적용: 날짜/시간 문제는 ‘코드’보다 ‘정책’으로 줄인다

리포트의 Pain Points에서도 날짜 관리는 여전히 상위권에 위치합니다. Temporal이 오기 전까지(그리고 온 뒤에도) 팀이 할 수 있는 최선은 “규칙”입니다. (Usage: Usage)

추천 규칙(바로 문서에 박아도 됨)

  • 서버 기준 시간: 저장은 UTC(ISO-8601), 화면 표시만 로컬 타임존
  • 도메인 시간: “업무 날짜”가 중요하면 DateTime이 아니라 LocalDate(개념)를 별도 모델로 다룸
  • 변환 위치: UI 경계에서만 변환(서비스/도메인 내부는 UTC 기반)
  • 테스트: 타임존/서머타임 케이스 최소 1개 포함

AI 코딩 29% 시대: 팀 프로세스 규칙

Usage 섹션은 “AI 생성 코드 비중 평균 29%”라는 숫자를 제시합니다. 즉, AI는 ‘가끔 쓰는 도구’가 아니라, 이미 코드베이스의 상당 부분에 영향을 주는 생산 수단이 되었습니다. (Usage: Usage)

핵심 관점: AI 도입은 ‘도구 설치’가 아니라 ‘품질 기준’의 도입

같은 리포트에서 JS Pain Points 상위에 “Architecture”, “State management”, “Dependencies”가 잡힙니다. AI는 이 영역의 문제를 더 빨리 드러나게(혹은 더 빨리 악화시키게) 만들 수 있습니다. (Usage: Usage)

팀 규칙(추천): “AI 작성 코드 PR 체크리스트”

  1. 테스트: 변경 경로에 대한 단위/통합 테스트가 있는가?
  2. 보안: 입력 검증, 권한 체크, 민감정보 로그 누출이 없는가?
  3. 라이선스/복붙: 외부 코드/스니펫 출처가 불명확하지 않은가?
  4. 아키텍처 일관성: 기존 레이어/모듈 경계를 깨지 않았는가?
  5. 가독성: “동작은 되는데 설명 불가”한 코드가 아닌가?

팀 규칙(추천): “AI 사용 범위 가이드”

  • 적극 권장: 보일러플레이트, 테스트 케이스 초안, 마이그레이션 스크립트, 문서화
  • 주의 필요: 인증/인가, 결제/정산, 암호화, DB 마이그레이션 핵심 로직
  • 금지(원칙): 비밀키/토큰/내부 URL을 프롬프트에 직접 포함

이미지: AI 생성(AI 코딩을 팀 프로세스에 넣는 흐름도)
이미지: AI 생성(AI 코딩을 팀 프로세스에 넣는 흐름도)

바로 적용하는 체크리스트

1) 신규 프로젝트(2026) 기본 스택 추천

  • 빌드: Vite
  • 단위/통합 테스트: Vitest
  • E2E: Playwright
  • 품질: lint + typecheck + 테스트를 PR 게이트로 고정

참고: 위 스택은 리포트 Awards/Testing 흐름과 가장 잘 맞습니다. (Awards: Awards, Testing: Testing)

2) Next.js를 쓰는 팀이 “만족도 하락”을 피하는 운영 규칙

  • 패턴 표준화: 데이터 패칭/캐시/라우팅 규칙을 문서로 고정(예: “서버 컴포넌트는 어디까지”)
  • 성능 지표: LCP/TTFB/빌드타임을 정기 측정하고 PR에서 악화 감지
  • 기술 부채 관리: “임시 우회(캐시 무효화/옵션 난사)”를 금지하고, 반드시 원인/대안을 기록

3) AI 도입 체크: ‘도구’보다 ‘통제’가 먼저

  • PR 체크리스트를 팀 룰로 강제(위 섹션 그대로 복붙 가능)
  • 프롬프트 보안 규칙 문서화(비밀키/내부정보 금지)
  • 에이전트/IDE 도입 시 권한/로그/추적(누가 무엇을 생성했는지) 체계 마련

4) 레거시(webpack/Jest/Express)를 “버리지 않고” 개선하는 순서

  1. 테스트 안정화(플레이키 제거) → CI 게이트화
  2. 관측성 추가(빌드/런타임 병목 측정)
  3. 작은 영역부터 교체(패키지/서브도메인/새 화면)
  4. 마지막에 도구 교체(그때가 진짜 ‘전환 효과’가 커짐)

참고 링크

작성자:
레이블:

댓글 없음:

댓글 쓰기

피드 구독하기: 댓글 (Atom)