2026년, 더 빠른 피드백 루프와 엄격한 가드레일을 통해 사람과 LLM 모두가 더 잘 일할 수 있도록 하는 최신 프론트엔드 툴링 스택을 소개한다.
Christoph Nakazawa
목차
2026년 2월 19일에 게시
읽는 데 7분, 1300단어
2026년은 JavaScript 툴링이 더 빨라지는 해다. TypeScript가 Go로 재작성되고, Oxlint와 Oxfmt 같은 도구들이 대중적 채택을 위한 준비를 하고 있다. 사람과 LLM 모두 빠른 피드백 루프, 엄격한 가드레일, 강한 로컬 추론(local reasoning)을 갖춘 코드베이스에서 훨씬 더 좋은 성과를 낸다. 이 글의 목적은 합리적이면서도 엄격한 기본값으로 모두가 더 빠르게 일하도록 돕는 것이다.1아직 확신이 없다면, 이 글에서 설명하는 스택은 OpenClaw가 로켓처럼 빠르게 배포하기 위해 쓰는 스택이다. 내가 거기에 넣었기 때문이다.
블로그 글 읽는 게 지루하다면, 내 Building Scalable Applications 발표를 보거나, 이 글을 LLM에 바로 보내거나, 아래 템플릿 중 하나로 바로 시작해도 된다:
스택을 더 빠르게 만드는 방법은 다음과 같다:
지난 6개월 동안 TypeScript의 Go 재작성판을 사용해왔고, 타입 체크가 약 10배 빨라졌다. 중간중간 약간의 문제들이 있었지만, 이제는 에디터 지원을 포함해 대부분 안정적이고 기능도 거의 완성됐다.
실험적 버전의 TypeScript로 전환하는 데 있어 내가 가장 걱정했던 건 타입 체크 동작의 회귀(regression)였다. 하지만 결과는 반대였다. tsgo가 JavaScript 구현이 잡지 못하던 타입 오류를 잡아냈다! 나는 1,000줄에서 1,000,000줄까지 다양한 규모의 20개+ 프로젝트에 tsgo를 적용했고, 반복(iteration) 속도가 꽤 개선됐다.
tsgo로 마이그레이션하고 싶고 현재 TypeScript로 코드를 컴파일하고 있다면, 먼저 라이브러리라면 tsdown으로, 웹 앱이라면 Vite로 전환하는 것을 추천한다. tsdown은 Rolldown 기반의 라이브러리용 빠른 번들러로, JavaScript 번들을 최적화한다.
그 다음 tsgo로의 마이그레이션은 빠르다:
npm install @typescript/native-previewtsc 호출을 모두 tsgo로 교체"typescript.experimental.useTsgo": true 추가Prettier가 알파였을 때부터 사용해왔다. 그 이후로 많은 포매터가 만들어졌지만, Prettier만큼의 기능 범위와 플러그인 시스템을 가진 것은 없었다. Oxfmt는 좋은 대안인데, import 정렬과 Tailwind CSS 클래스 정렬 같은 Prettier 플러그인 상당수를 내장하고 있고, JavaScript/TypeScript 외의 언어들(롱테일)에 대해서는 Prettier로 폴백해 포맷팅을 처리한다.
마이그레이션 프롬프트:
이 프로젝트를 Prettier에서 Oxfmt로 마이그레이션하라. https://oxc.rs/docs/guide/usage/formatter/migrate-from-prettier.md 를 읽어라. 모든 스크립트, 도구, 훅을 Oxfmt를 사용하도록 업데이트하라. 모든 Prettier 설정 파일을 제거하고 Oxfmt로 코드를 다시 포맷하라.
code --install-extension oxc.oxc-vscode로 Oxc VS Code 확장 설치를 추천한다.
Prettier와 마찬가지로, 새로운 린터를 만들려는 시도는 많았다. 하지만 ESLint 주변의 플러그인 생태계는 따라잡기 어렵다. Rust 기반 린터를 도입한 뒤에도, React Compiler 플러그인 같은 린트 규칙 때문에 ESLint를 계속 써야 했다.
Oxlint는 ESLint 플러그인 shim과 NAPI-RS를 통해 ESLint 플러그인을 직접 실행할 수 있는 최초의 새로운 린터다. Oxlint는 TypeScript 설정 파일도 지원하며 extends로 설정을 조합할 수 있다:
import nkzw from '@nkzw/oxlint-config';
import { defineConfig } from 'oxlint';
export default defineConfig({
extends: [nkzw],
});
마이그레이션 프롬프트:
이 프로젝트를 ESLint에서 Oxlint로 마이그레이션하라. https://oxc.rs/docs/guide/usage/linter/migrate-from-eslint.md 를 읽어라. 모든 스크립트, 도구, 훅을 Oxlint를 사용하도록 업데이트하라. 모든 ESLint 설정 파일을 제거하라. 코드를 린트하고 모든 린트 오류를 수정하라.
Oxlint는 타입 인지(type-aware) 린트 규칙도 지원한다. Oxlint와 함께 oxlint-tsgolint를 설치하고 oxlint --type-aware를 실행하라. TypeScript Go 기반으로 oxlint --type-aware --type-check를 통해 타입을 직접 체크할 수도 있다!
몇 주 전, 빈 Git 저장소에서 GPT 5.2 Codex에게 한 코드베이스를 한 UI 프레임워크에서 다른 프레임워크로 변환해보라고 요청했다. 그 다음 이 웹 앱 템플릿을 주고, 새 세션에서 같은 변환을 하라고 했다. 엄격한 가드레일 덕분에, 훨씬 더 적은 버그로 훨씬 더 좋은 결과를 냈다.
위 템플릿으로 새 프로젝트를 시작하는 게 아니라면, @nkzw/oxlint-config를 사용해 LLM이 더 좋은 코드를 쓰도록 안내하는 다음 원칙과 함께, 빠르고 엄격하며 포괄적인 린팅 경험을 즉시 얻을 수 있다:
instanceof 같은 문제 소지가 있는 패턴을 금지해, 더 견고한 패턴을 선택하도록 한다. console.log나 test.only 같은 디버그 전용 코드를 금지해 프로덕션에서의 의도치 않은 로깅이나 CI 실패를 방지한다.no-unused-vars보다 TypeScript의 noUnusedLocals 체크를 선호한다.나는 @nkzw/oxlint-config가 Oxlint를 위한 엄격한 내장 규칙과 JS 플러그인의 포괄적 세트를 처음으로 한데 모은 패키지라고 믿는다. 한번 써보라!
마이그레이션 프롬프트:
@nkzw/oxlint-config를 사용해 이 프로젝트를 ESLint에서 Oxlint로 마이그레이션하라. https://raw.githubusercontent.com/nkzw-tech/oxlint-config/refs/heads/main/README.md 와 https://oxc.rs/docs/guide/usage/linter/migrate-from-eslint.md 를 읽어라. 모든 스크립트, 도구, 훅을 Oxlint를 사용하도록 업데이트하라. 모든 ESLint 설정 파일을 제거하라.
나는 여전히 npm-run-all2를 좋아한다.2“2”는 오타가 아니다! npm-run-all의 현대적이고 작은 포크다! 바이너리 이름은 여전히 npm-run-all이라서 헷갈리긴 하지만, 빠른 로컬 실행을 위해 스크립트를 병렬화하는 데 유용하다:
"scripts": {
"lint:format": "oxfmt --check",
"lint": "oxlint",
"check": "npm-run-all --parallel tsc lint lint:format",
"tsc": "tsgo"
}
복잡한 도구는 많고 일부 패키지 매니저는 병렬화를 내장하고 있지만, 작은 작업에는 이 패키지가 놀랄 만큼 잘 작동한다:
ctrl+c를 누르면 실제로 모든 것을 즉시 종료한다.개발 중 TypeScript를 실행하는 해법은 이제 많지만, TypeScript의 모든 기능(JSX, enum 등)을 지원하면서 nodemon, ts-node, swc 조합보다 더 빠르게, 파일 변경 시 즉시 재시작하는 Node.js 서버 실행을 해주는 도구는 아직 찾지 못했다:
pnpm nodemon -q -I --exec node --no-warnings --experimental-specifier-resolution=node --loader ts-node/esm --env-file .env index.ts
그리고 tsconfig.json에는 다음을 추가한다:
"ts-node": {
"transpileOnly": true,
"transpiler": "ts-node/transpilers/swc",
"files": true,
"compilerOptions": {
"module": "esnext",
"isolatedModules": false
}
}
나는 타이핑하는 즉시 자동 저장한다(여전히 손으로 코딩하는 날에는). 변경이 Node.js 서비스에 영향을 주면, 키를 누를 때마다 매번 즉시 재시작되길 원한다. 내가 세상에 존재하는 거의 모든 걸 다 써본 느낌인데, 이 조합만큼 빠른 건 없었다. 트레이드오프 없이 이보다 좋은 게 있다면, DM 부탁.
이 주제에 대해 마지막으로 글을 쓴 이후에도 매일 사용하는 도구들을 언급할 가치가 있다.
pnpm은 JavaScript를 위한 최고의 패키지 매니저다. 빠르고 기능도 풍부하다.
Vite가 아닌 다른 번들러/개발 서버로 웹 프로젝트를 시작하는 건 상상하기 어렵다. 웹을 위한 빌드 플랫폼 중 가장 빠르고, 가장 안정적이며, 가장 확장 가능하다. 곧 Rolldown을 내부에 사용하면서 더 빨라질 것이다.
여러 UI 프레임워크를 시도해봤지만 결국 React로 돌아오게 된다. React Compiler가 성능을 유지해주고, Async React가 현대성을 유지해준다. 최근에는 React & tRPC를 위한 현대적인 데이터 클라이언트 fate를 만들었다 — 써보라!
JavaScript 도구는 빠르고, 안정적이며, 기능이 완성되어 있어야 한다. 최근 몇 년간 새로운 도구를 만들려는 시도는 많았지만, 모두 타협이 필요했다. 위의 새로운 도구들과 함께라면, 더는 타협할 필요가 없다.3최종 보스는 저장소 루트에 있는 설정 파일의 개수다. 곧 Vite+가 그 문제를 해결해줄 것이다.
읽어줘서 고맙고, 좋은 하루 보내길!
2022년 가장 빠른 프론트엔드 툴링 스타터 팩완벽한 개발 환경 스타터 팩새 Mac 설정하기, 빠르게 스타터 팩