jQuery 4.0.0

2026-01-17

https://blog.jquery.com/2026/01/17/jquery-4-0-0/

jQuery 4.0.0 | Official jQuery Blog

출시 배경과 의미

● jQuery는 2006년 John Resig가 공개한 이후 20주년을 맞이했고, 이번 jQuery 4.0.0은 약 10년 만의 첫 메이저 릴리스다.

● 오랜 기간 미뤄졌던 구조 정리, 레거시 제거, 현대화 작업을 한 번에 수행한 버전으로,

    일부 breaking change가 존재하지만 대부분의 사용자는 큰 수정 없이 업그레이드 가능하다고 밝힘.

● 업그레이드를 돕기 위해 Upgrade Guide와 jQuery Migrate 플러그인이 함께 제공됨.

★ 과거 호환을 유지해주던 라이브러리 → 현대 웹 표준에 맞춘 정돈된 라이브러리

 

브라우저 지원 정책 변경

● IE 10 이하 공식 지원 종료

● Edge Legacy, 매우 오래된 iOS / Firefox / Android Browser 지원도 함께 종료

● IE11은 아직 유지하지만, 단계적으로 제거 예정 → 다음 큰 단계는 jQuery 5.0

● 만약 아직 구형 브라우저를 반드시 지원해야 한다면 jQuery 3.x 유지 권장

★ jQuery가 더 이상 모든 구형 브라우저를 위한 안전망 역할을 하지 않음

 

보안 강화: Trusted Types + CSP 대응

● Trusted Types 지원 추가

     ▶ CSP의 require-trusted-types-for 정책 환경에서도 jQuery의 DOM 조작이 보안 정책을 위반하지 않도록 개선됨

     ▶ AJAX / 비동기 스크립트 로딩에서 inline script 사용을 줄이고 <script> 태그 기반 로딩을 적극 사용

     ▶ 일부 특수 옵션(headers 등)을 사용하는 경우는 여전히 XHR을 사용하지만, 가능한 한 CSP 오류를 피하도록 설계가 바뀜

★ 보안 요구사항이 높은 서비스 환경을 더 잘 고려한 상황

 

내부 구조 현대화: AMD → ES Modules

● jQuery 소스가 AMD 기반에서 ES Modules(ESM)로 전환됨

● 기존에는 RequireJS 없이는 모듈로 직접 import 하기 어려웠으나, 이제는 현대 빌드 도구(Rollup 등)와 자연스럽게 호환됨

● <script type="module"> 환경에서도 사용 가능

★ jQuery는 옛날 기술이라는 인식을 줄이고, 현대 프론트엔드 툴 체인에 얹을 수 있는 상태로 정리

 

Deprecated API 대규모 제거

● 여러 버전 동안 deprecated 상태였던 API들이 이번 메이저 버전에서 완전히 제거

● 제거된 API 예:

     ▶ jQuery.isArray

     ▶ jQuery.parseJSON

     ▶ jQuery.trim

     ▶ jQuery.now

     ▶ jQuery.isNumeric

     ▶ jQuery.isFunction 등

● 이들 대부분은 이제 모든 지원 브라우저에서 네이티브 JS로 대체 가능

     ▶ Array.isArray(), JSON.parse(), String.prototype.trim(), Date.now() 등

● 이 정리로 인해 gzip 기준 3KB 이상 용량 감소

★ jQuery 고유 API보다 표준 JavaScript 사용을 장려하는 방향

 

내부 전용 메서드 제거

● jQuery 객체가 내부적으로 사용하던 push, sort, splice 메서드 제거

● 원래부터 내부 용도였으나, 일부 개발자가 직접 사용하고 있었을 수 있음

● 필요 시 Array 메서드를 직접 호출하는 방식으로 대체 가능

★ 돌아가긴 했지만 쓰면 안 됐던 것들을 명확히 정리

 

focus / blur 이벤트 동작 변경

● 과거 jQuery는 브라우저 간 차이를 흡수하기 위해 focus/blur 이벤트 순서를 자체적으로 조정했음

● 현재는 모든 최신 브라우저가 W3C 표준 이벤트 순서로 통일

● jQuery 4.0부터는 더 이상 이를 override 하지 않고 표준을 따름

● 이벤트 순서에 의존한 코드에서는 동작 변화 가능성 있음

★ 일관성을 유지하던 jQuery식 추상화를 내려놓고, 표준 중심으로 방향 전환

 

Slim 빌드 더 경량화

● Slim 빌드에서 Deferred / Callbacks 제거

● 대부분의 사용 사례는 native Promise로 대체 가능

● Slim 빌드 크기: 약 19.5KB (gzipped)

● IE11까지 지원해야 하면 메인 빌드 또는 Promise polyfill 필요

 

 

 

◎ breaking change

라이브러리를 업그레이드했을 때, 기존 코드가 더 이상 동일하게 동작하지 않거나 오류가 나는 변경

버전만 올렸고 코드는 그대로인데 동작이 달라지거나 에러가 발생하면 breaking change

이번 jQuery 4.0.0은 메이저 버전 업이라, 일부 breaking change를 의도적으로 허용

1. 제거된 API를 쓰고 있으면 바로 깨짐

$.trim(str);

jQuery 4.0에서는

❌ $.trim is not a function

→ API 자체가 삭제됨

→ native JS로 바꿔야 함

str.trim();

2. 내부용 메서드를 직접 쓰고 있었다면 깨짐

$elems.push(elem);

이전엔 우연히 동작했지만 4.0에서는

❌ $elems.push is not a function

→ 원래부터 쓰면 안 되는 내부 구현이었음

→ Array 메서드로 대체 필요

3. 이벤트 동작 순서에 의존한 코드는 동작이 달라짐

$(input).on('focusout', () => {
	// 이 시점엔 blur가 이미 끝났을 거라고 가정
});

jQuery 4.0부터는

• 이벤트 순서가 W3C 표준으로 변경됨

• 이전 jQuery 전용 순서와 다름

→ 에러는 안 나는데 동작 타이밍이 미묘하게 달라질 수 있음

4. 구형 브라우저에서 갑자기 안 돌아감

• IE 10 이하

• Edge Legacy

• 아주 오래된 모바일 브라우저

→ 코드는 그대로인데 환경이 더 이상 지원되지 않음

jQuery 팀이 제거한 것들의 공통점

✔ 이미 deprecated 상태였거나

✔ 공식 문서에서 권장하지 않던 사용법이거나

✔ 이제는 네이티브 JS로 충분히 대체 가능한 것들

 

◎ Trusted Types

DOM에 위험한 문자열(HTML, script URL 등)을 그냥 넣지 못하게 막는 브라우저 보안 규칙

XSS를 구조적으로 막기 위한 장치

→ Trusted Types = "아무 문자열이나 innerHTML 같은 데 넣지 말고, 신뢰된 객체만 넣어라"라는 브라우저 보안 메커니즘

웹 보안 사고의 대표 원인

element.innerHTML = userInput;

만약 userInput에

<script>alert('해킹')</script>

이 들어오면 → XSS(스크립트 삽입 공격)

기존엔 개발자가 조심해서 쓰는 것에 의존, 실수하면 바로 취약점 → Trusted Types의 핵심 아이디어

elem.innerHTML = "<div>hello</div>";	// 문자열이면 다 OK

Trusted Types 적용 후

elem.innerHTML = trustedHtml;	// 그냥 문자열 X

→ TrustedHTML 타입 객체만 허용

즉, 문자열 X, "이 HTML은 안전합니다"라고 명시적으로 만든 객체만 O그럼 TrustedHTML은 어떻게 만드나?보통 정책(policy)을 정의해서 만듦

const policy = trustedTypes.createPolicy("default", {
	createHTML: (input) => sanitize(input)
});

const safeHTML = policy.createHTML("<div>hello</div>");
elem.innerHTML = safeHtml;

이 과정을 거쳐야만 DOM에 들어갈 수 있음

CSP랑 같이 쓰이는 이유

Trusted Types는 보통 CSP(Content Security Policy)와 같이 씀

Content-Security-Policy: require-trusted-types-for 'script';

이 설정이 있으면 innerHTML = "문자열" 에러, TrustedHTML 객체만 O

jQuery는 원래 이런 코드를 많이 씀

$('.box').html('<div>hello</div>');

Trusted Types + CSP 환경에선 이게 바로 차단될 수 있음

그래서 jQuery 4.0에서 바뀐 점은 TrustedHTML로 감싼 HTML도 jQuery DOM 조작 메서드의 입력으로 허용

즉, 보안 정책을 쓰는 서비스에서도 jQuery를 에러 없이 계속 사용 가능

 

◎ require-trusted-types-for

브라우저에게 위험한 DOM API에는 Trusted Types만 쓰게 강제로 막으라고 지시하는 보안 설정

보통 Content Security Policy(CSP)의 지시어(directive)로 사용됨

require-trusted-types-for 'script' = 스크립트 관련 DOM 조작에는 문자열 금지, Trusted Types만 허용

왜 필요한가?

웹 해킹 사고 중 가장 흔한 게 XSS(스크립트 삽입 공격)

element.innerHTML = userInput;	// 매우 위험

이 한 줄만 실수해도

<script>해킹코드</script>

실행될 수 있음

→ require-trusted-types-for는 실수 자체를 코드 레벨에서 못 하게 만드는 장치

실제로 뭘 막아주나?

element.innerHTML = "<img src=x onerror=alert(1)>";

이게 막힘

TypeError: Failed to set 'innerHTML'
This document requires TrustedHTML

브라우저 콘솔

const policy = trustedTypes.createPolicy("default", {
	createHTML: (input) => sanitize(input)
});

const safeHTML = policy.createHTML("<div>safe</div>");
element.innerHTML = safeHTML;

이렇게만 가능

이 HTML은 검증됐음을 코드로 증명해야 함

 

◎ AJAX

페이지를 새로고침하지 않고, 서버와 데이터를 주고받는 웹 기술

화면은 그대로 두고, 뒤에서 서버랑 비동기 통신하는 방식

Asynchronous JavaScript and XML (요즘은 XML보다 JSON을 거의 씀)

왜 AJAX가 필요했을까?

AJAX가 없던 시절

버튼 클릭

→ 페이지 전체 새로고침

→ 서버 요청

→ 화면 다시 그림

• 느림

• 깜빡임

• 사용자 경험 나쁨

AJAX 사용

버튼 클릭

→ 서버에 요청 (뒤에서)

→ 데이터만 받아옴

→ 필요한 부분만 화면 업데이트

• 빠름

• 화면 안 깜빡임

• 앱처럼 부드러움

jQuery AJAX

$.ajax({
	url: '/api/data',
    method: 'GET',
    success: function (res) {
    	console.log(res);
    }
});

fetch

fetch('/api/data')
   .then(res => res.json())
   .then(data => console.log(data));

개념은 같고 도구만 바뀜

AJAX의 핵심 특징

1. 비동기(Asynchronous)

   : 서버 응답 기다린다고 화면 멈추지 않음

2. 부분 업데이트

   : 페이지 전체 말고 필요한 부분만 변경

3. 서버 통신

   : HTTP 요청(GET/POST 등)은 그대로 사용

jQuery는 원래

• AJAX를 아주 쉽게 만들어 준 라이브러리 → 그래서 초기에 엄청나게 성공함

지금은

• fetch, axios 등 대체 수단 많음

• 그래서 jQuery slim 빌드에서 AJAX가 빠지기도 함

 

◎ XHR

웹에서 서버와 데이터를 주고받기 위해 사용되는 브라우저 API

XMLHttpRequest

브라우저에서 JavaScript로 서버에 HTTP 요청을 보내는 기능

브라우저 → 서버 → 데이터 받기를 페이지 새로고침 없이 할 수 있게 만든 기술 → AJAX의 핵심 기술

 

◎ CSP 오류

웹사이트가 설정한 보안 정책(Content Security Policy)을 위반했을 때 브라우저가 막으면서 발생하는 오류

웹사이트가 어떤 스크립트, 이미지, 스타일 등을 어디서 로드할 수 있는지 제한하는 보안 정책

목적: XSS 같은 공격 방지

개발자 콘솔에서 보통 이렇게 뜸

Refused to load the script
because it violates the Content Security Policy directive
또는
Refused to execute inline script

 

◎ XSS

Cross-Site Script

웹사이트에 악성 JavaScript 코드를 삽입해서 다른 사용자의 브라우저에서 실행되게 만드는 공격

실제 해킹에서 하는 것

1. 로그인 정보 탈취 

→ 세션 쿠키 탈취

2. 가짜 UI 만들기

→ 피싱

3. 사용자 계정으로 행동

→ 좋아요 누르기, 글 작성, 송금 요청 등

XSS가 위험한 이유

: 서버가 해킹되는 게 아니라 사용자의 브라우저가 해킹됨 → 그래서 피해자가 많아질 수 있음

 

◎ AMD

JavaScript에서 모듈을 관리하는 방식 중 하나

Asynchronous Module Definition

→ 비동기로 모듈을 로드

브라우저에서 모듈을 필요할 때 가져옴※ ES Modules 이전에 사용되던 JavaScript 모듈 관리 방식

 

◎ Slim 빌드

라이브러리에서 일부 기능을 빼서 더 가볍게 만든 버전

Full version  → 모든 기능 포함
Slim version  → 핵심 기능만 포함

 

 

 

 

웹 개발 패러다임의 변화

웹 개발이 레거시 호환 중심에서 표준 중심으로 이동하고 있는 것 같다.

과거에는 다양한 브라우저 호환성을 맞추기 위해 라이브러리가 필요했지만, 이제는 대부분의 브라우저가 웹 표준을 따르기 때문에 라이브러리가 호환성을 대신 해결할 필요가 줄어들고 있다.

 

JavaScript의 발전으로 줄어드는 라이브러리 의존성

JavaScript 자체가 많이 발전한 것 같다.

과거에는 브라우저마다 기능 지원이 달라 jQuery가 다양한 유틸리티 함수를 제공했지만 현재는 대부분의 기능이 JavaScript 표준으로 제공되기 때문에 라이브러리 의존성이 점점 줄어드는 방향으로 발전하고 있다.

 

 

 

---

 

 

 

 

앞으로 라이브러리는 어떤 역할을 하게 될까?

앞으로 라이브러리는 과거처럼 브라우저 호환성을 해결하거나 기본 기능을 보완하는 역할보다는, 개발을 더 효율적으로 할 수 있도록 돕는 역할이 중심이 될 것 같다. JavaScript와 브라우저 표준이 발전하면서 예전처럼 라이브러리가 기본 기능을 대신 제공해야 할 필요는 줄어들었기 때문이다. 실제로 현재의 라이브러리들도 상태 관리나 UI 구성, 애플리케이션 구조 관리처럼 더 복잡한 문제를 해결하는 방향으로 발전하고 있는 것 같다.