jQuery 4.0 — 10년 만의 메이저 릴리스, 무엇이 바뀌었나
jQuery가 아직 살아 있냐고? 살아 있는 정도가 아니라, 2026년 2월 기준 **전 세계 웹사이트의 약 77%**가 여전히 jQuery를 사용하고 있다. 2006년 1월 14일 첫 출시 이후 정확히 20년. 그리고 3.0 이후 거의 10년 만에 메이저 버전인 jQuery 4.0이 나왔다. React, Vue, Svelte의 시대에 jQuery 4.0이 무슨 의미가 있는지, 그리고 무엇이 달라졌는지 정리한다.
핵심 변경 — 무엇을 버리고, 무엇을 얻었나
jQuery 4.0의 방향성은 명확하다. 레거시를 걷어내고 모던 웹에 맞춘다. 비유하면 20년 된 건물의 낡은 배관을 교체하면서 불필요한 방을 허문 것이다. 건물 자체를 새로 짓지는 않았지만, 내부 구조가 깔끔해졌다.
브라우저 지원 축소
| 브라우저 | jQuery 3.x | jQuery 4.0 |
|---|---|---|
| IE 10 이하 | 지원 | 제거 |
| IE 11 | 지원 | 지원 (5.0에서 제거 예정) |
| Edge Legacy | 지원 | 제거 |
| iOS 구버전 | 광범위 | 최근 3개 버전만 |
| Android Browser | 지원 | 제거 |
IE 10 이하와 Edge Legacy를 버렸다는 건 꽤 큰 결정이다. 이 브라우저들을 위한 분기 코드, 폴리필, 핵이 전부 삭제됐다.
[💡 잠깐! 이 용어는?] Edge Legacy: Chromium 기반으로 전환하기 전의 구형 Microsoft Edge를 뜻한다. EdgeHTML 엔진을 사용했으며, 2021년에 지원이 종료됐다.
모듈 시스템 전환 — AMD에서 ES Modules로
jQuery 4.0의 가장 큰 아키텍처 변화는 AMD(Asynchronous Module Definition)에서 ES Modules로의 전환이다. 빌드 시스템도 RequireJS에서 Rollup으로 교체됐다.
<script type="module">
import $ from './jquery.esm.js';
$('button').on('click', () => {
console.log('jQuery 4.0 with ES Modules');
});
</script><script type="module">로 직접 import할 수 있다는 건 jQuery를 현대적 빌드 파이프라인(Vite, Rollup, esbuild)에 자연스럽게 통합할 수 있다는 의미다. 트리 쉐이킹의 혜택도 받을 수 있게 된다.
[💡 잠깐! 이 용어는?]
AMD(Asynchronous Module Definition): RequireJS 시절의 모듈 포맷이다. define(['dep'], function(dep) { ... }) 형태로 의존성을 선언한다. ES Modules(import/export)가 표준화되면서 대부분의 프로젝트가 ESM으로 전환했다.
번들 크기 감소
deprecated 함수들을 제거하면서 gzip 기준 3,000바이트 이상이 줄었다. 작아 보일 수 있지만, jQuery처럼 거의 모든 페이지에 로드되는 라이브러리에서 3KB 절감은 전체 웹 트래픽으로 환산하면 상당한 양이다.
제거된 유틸리티 함수들과 그 대체제를 보면, jQuery가 왜 20년 전에는 필수였고 지금은 선택이 됐는지 알 수 있다.
| 제거된 함수 | 네이티브 대체제 |
|---|---|
jQuery.isArray() | Array.isArray() |
jQuery.parseJSON() | JSON.parse() |
jQuery.trim() | String.prototype.trim() |
jQuery.now() | Date.now() |
2006년에는 Array.isArray()조차 없어서 jQuery가 직접 구현해야 했다. 지금은 브라우저가 다 지원하니까 jQuery가 들고 있을 이유가 없다. 비유하면 휴대폰에 카메라가 달리면서 디지카를 따로 들고 다닐 필요가 없어진 것과 같다.
slim 빌드는 Deferreds와 Callbacks를 추가로 제거해서 gzip 기준 약 19.5KB까지 줄었다. 네이티브 Promise가 모든 지원 브라우저에서 사용 가능하기 때문이다(IE11 제외).
Trusted Types 지원
jQuery 4.0의 새로운 기능 중 보안 측면에서 가장 주목할 만한 것은 Trusted Types 지원이다.
const policy = trustedTypes.createPolicy('jquery', {
createHTML: (input) => DOMPurify.sanitize(input),
});
const safeHTML = policy.createHTML('<p>안전한 HTML</p>');
$('#container').html(safeHTML);TrustedHTML로 래핑된 HTML은 Content Security Policy(CSP) 위반 없이 jQuery의 DOM 조작 메서드에 전달할 수 있다. 또한 비동기 스크립트 요청 대부분이 인라인 스크립트 대신 <script> 태그를 사용하도록 변경되어 CSP 호환성이 개선됐다.
[💡 잠깐! 이 용어는?]
Trusted Types: 브라우저의 보안 API로, DOM XSS 공격을 방지하기 위해 문자열을 직접 DOM에 삽입하는 것을 차단하고, 사전 검증된 타입(TrustedHTML, TrustedScript)만 허용하는 메커니즘이다.
마이그레이션은 얼마나 어려운가
jQuery 팀은 "대부분의 사용자가 최소한의 변경으로 업그레이드할 수 있을 것"이라고 밝혔다. 공식 마이그레이션 가이드와 함께 jQuery Migrate 플러그인이 제공되어, deprecated API 사용 부분을 자동으로 감지하고 경고해준다.
| 상황 | 난이도 | 조치 |
|---|---|---|
| deprecated API 미사용 | 낮음 | 버전만 올리면 됨 |
$.isArray() 등 유틸 사용 | 낮음 | 네이티브 대체 (1:1 매핑) |
| IE 10 이하 지원 필요 | 불가 | jQuery 3.x 유지 |
| AMD 모듈 시스템 의존 | 중간 | ESM 전환 또는 번들러 설정 변경 |
| CSP strict 환경 | 낮음 | Trusted Types 도입으로 오히려 개선 |
jQuery가 여전히 의미 있는 이유
"jQuery는 죽었다"는 말은 개발자 커뮤니티에서 10년째 반복되고 있지만, 숫자는 다른 이야기를 한다. WordPress만 해도 jQuery를 기본 포함하고 있고, 수많은 레거시 시스템, 엔터프라이즈 인트라넷, CMS 플러그인이 jQuery 위에서 동작한다.
jQuery 4.0은 이런 현실을 인정하면서도 모던 웹 방향으로 한 발 내딛은 릴리스다. 새 프로젝트에서 jQuery를 선택할 이유는 거의 없지만, 이미 jQuery를 쓰고 있는 수십억 개의 페이지에게 4.0은 "교체하지 않아도 모던 웹 표준과 보안을 따라잡을 수 있다"는 메시지다.
정리
- jQuery 4.0은 10년 만의 메이저 릴리스로, IE 10 이하와 Edge Legacy 지원을 제거했다
- AMD에서 ES Modules로 전환하고 빌드 시스템을 Rollup으로 교체했다
- deprecated 유틸리티 함수 제거로 gzip 기준 3,000바이트 이상 절감됐다
- Trusted Types 지원으로 CSP 환경에서의 보안이 강화됐다
- jQuery Migrate 플러그인으로 대부분의 프로젝트가 최소한의 변경으로 업그레이드 가능하다
참고:
- InfoQ: https://www.infoq.com/news/2026/02/jquery-4-release/
- jQuery 4.0 Release Blog: https://blog.jquery.com/2026/02/06/jquery-4-0-0-released/
- jQuery Migrate: https://github.com/jquery/jquery-migrate
관심 있을 만한 포스트
Babel 7.29.0 — 10년 역사의 마지막 마이너, 그리고 8 RC1
2026년 1월 31일, Babel 7의 마지막 마이너 릴리스가 공개됐다. 이 버전이 갖는 역사적 의미와 Babel 8 RC1의 핵심 변화를 정리한다.
Babel 8 Beta — CJS를 버리고 ESM 전용으로 간다
2년간의 알파를 거쳐 베타에 진입한 Babel 8의 핵심 변경사항과 마이그레이션 전략을 정리한다.
Native JSON Modules — 번들러 없이 JSON을 import하는 시대
Import Attributes와 함께 표준이 된 native JSON module. 어떻게 동작하고, 기존 번들러 방식과 뭐가 다른지 정리했다.
Error.isError() — realm을 넘나드는 안전한 에러 검사 API
instanceof Error가 iframe과 worker에서 실패하는 이유, 그리고 이를 근본적으로 해결하는 Error.isError()의 동작 원리를 정리한다.
V8의 Sea of Nodes 탈출기 — 왜 우아한 이론이 실전에서 무너졌는가
V8 팀이 10년간 사용한 Sea of Nodes IR을 포기하고 Turboshaft로 전환한 7가지 이유와 그 교훈을 정리한다.
달리는 차의 엔진을 바꾸다 — Nx 모노레포에서 Bun 도입까지의 여정
Nx 18에서 21까지 버전 업그레이드와 Bun 패키지 매니저 도입을 동시에 진행한 컬리의 마이그레이션 전략과 실전 이슈를 정리한다.
V8 Mutable Heap Numbers — 숫자 하나 바꿀 때마다 새 객체를 만들던 비효율을 잡다
V8 엔진이 스크립트 컨텍스트의 숫자 변수를 매번 새 HeapNumber로 할당하던 방식을 제자리 수정(mutable)으로 바꿔 최대 2.5배 성능 향상을 달성했다.
V8 Explicit Compile Hints — 주석 한 줄로 JavaScript 시작 속도를 630ms 줄이는 법
Chrome 136에 도입된 V8의 Explicit Compile Hints 기능으로 JavaScript 초기 로딩 성능을 개선하는 원리와 사용법을 분석한다.