jQuery는 DOM 선택, 이벤트, Ajax를 간단하게 만들어 자바스크립트를 쉽게 썼습니다. 무엇인지, 왜 쇠퇴했는지, 그리고 오늘날 언제 여전히 유용한지 알아보세요.

jQuery는 웹 페이지에서 흔히 하는 작업들을 더 쉽게 해주는 작은 자바스크립트 라이브러리입니다—요소 선택, 클릭 반응, 텍스트 변경, 페이지 일부 보이기/숨기기, 서버에 요청 보내기 같은 것들입니다.
만약 $("button").click(...) 같은 코드를 본 적이 있다면, 그건 jQuery입니다. $는 페이지에서 무언가를 찾아서 뭔가를 한다는 뜻의 단축입니다.
이 가이드는 실용적이고 비기술적 관점에서 작성되었습니다: jQuery가 무엇인지, 왜 인기를 끌었는지, 왜 최근 프로젝트에서 덜 사용되는지, 그리고 만약 사이트가 여전히 jQuery를 사용한다면 어떻게 다룰지입니다. 빠른 의견보다 명확한 예제와 현실적인 지침을 담기 위해 길게 썼습니다.
사람들이 jQuery가 “잊혀졌다”고 말할 때, 보통 사라졌다는 뜻이 아닙니다. 보통 의미하는 것은:
따라서 이야기는 “jQuery가 죽었다”가 아니라: jQuery가 프론트엔드 작업의 기본 도구에서 상속받아야 하는 레거시 의존성으로, 그리고 가끔은 의도적으로 여전히 선택되는 도구로 옮겨갔다는 쪽이 정확합니다.
jQuery 이전에는 프론트엔드 작업이 같은 짧고 성가신 코드들을 계속 반복 작성한 다음 여러 브라우저에서 테스트하고 다르게 동작하는 부분을 처리하는 일이 많았습니다. 단순히 “이 요소를 찾기”, “클릭핸들러를 붙이기”, “요청 보내기”처럼 보이는 작업도 특수한 예외 처리들로 가득할 수 있었습니다.
초기 자바스크립트 작업은 기능을 만드는 것보다 환경과 씨름하는 일에 더 가깝곤 했습니다. 한 브라우저에서 동작하던 코드를 다른 브라우저에서도 동작하게 만들려면 분기 처리를 추가해야 했습니다. 팀들은 일상적인 UI 변경을 버티기 위해 자체적으로 작은 헬퍼 함수 집합을 유지했습니다.
결과는: 개발 속도 저하, 버그 증가, 작은 변경이 오래된 브라우저를 망가뜨릴지 모른다는 불안감이었습니다.
브라우저들은 중요한 상세 동작에서 일치하지 않았습니다. DOM 선택 방법, 이벤트 처리, 심지어 요소 크기 측정 방법까지 달랐습니다. 특히 Internet Explorer는 이벤트와 XMLHTTP 요청에 대해 다른 API를 가지고 있어서 “표준” 코드가 항상 이식 가능한 것은 아니었습니다.
그건 실제로 중요한 문제였습니다. 결제 폼, 내비게이션 메뉴, 모달 대화상자가 인기 있는 브라우저에서 실패하면 실제 비즈니스 문제로 이어졌습니다.
jQuery가 큰 반향을 일으킨 이유는 브라우저 차이를 완화하는 일관되면서도 친근한 API를 제공했기 때문입니다.
주요 작업들을 훨씬 단순하게 만들었습니다:
더 중요한 점은, jQuery의 “적게 쓰고 더 많이 하자(write less, do more)” 스타일이 팀들이 더 빠르게 배포하도록 도왔다는 것입니다—특히 당시에는 현대 DOM API들이 지금처럼 강력하거나 폭넓게 지원되지 않던 시절에 그렇습니다.
jQuery의 진짜 강점은 완전히 새로운 아이디어를 도입한 것이 아니라, 흔한 브라우저 작업을 다양한 브라우저에서 일관되고 쉽게 느껴지게 만든 것이었습니다. 오래된 프론트엔드 코드를 보면 보통 jQuery가 네 가지 일상적 작업에 사용된 것을 볼 수 있습니다.
$ 함수 개념)$() 함수는 CSS처럼 생긴 선택자로 요소를 “잡아” 그룹으로 다룰 수 있게 했습니다.
브라우저 특이점과 장황한 API를 다루는 대신, 짧고 체이닝 가능한 호출로 모든 항목을 선택하거나 자식 요소를 찾거나 부모로 올라갈 수 있었습니다.
jQuery는 사용자 동작에 응답하는 것을 단순하게 만들었습니다:
clicksubmitready또한 브라우저가 이벤트 객체와 바인딩을 다루는 방식의 차이를 완화해 주었습니다. 브라우저 지원이 고르던 시절에는 이것이 큰 의미를 가졌습니다.
fetch()가 표준이 되기 전에는 jQuery의 $.ajax(), $.get(), $.post()가 서버에서 데이터를 요청하고 페이지를 새로 고치지 않고 업데이트하는 직관적인 방법이었습니다.
이를 통해 라이브 검색, “더 불러오기” 버튼, 부분 페이지 업데이트 같은 이제는 익숙한 패턴들이 단일 인터페이스로 가능해졌습니다.
jQuery는 hide(), show(), fadeIn(), slideToggle(), animate() 같은 빠른 UI 처리법을 대중화했습니다. 이들은 메뉴, 알림, 기본 전환에 편리했으며—특히 CSS 지원이 덜 안정적이던 시절에 유용했습니다.
이 편의 기능들이 결합되어 레거시 자바스크립트 코드에서 $(로 시작하는 코드가 흔한 이유를 설명합니다.
jQuery가 가진 명성이 많은 부분은 단순한 UI 작업을 적은 코드로 처리할 수 있었기 때문입니다—특히 브라우저 차이가 심할 때 그렇습니다. 아래의 비교가 이를 잘 보여줍니다.
jQuery
// Select a button and run code when it's clicked
$('#save').on('click', function (e) {
e.preventDefault();
$('.status').text('Saved!');
});
현대(바닐라) JavaScript
// Select a button and run code when it's clicked
const saveButton = document.querySelector('#save');
const status = document.querySelector('.status');
saveButton?.addEventListener('click', (e) =\u003e {
e.preventDefault();
if (status) status.textContent = 'Saved!';
});
겉보기에는 jQuery 버전이 더 “간결해 보입니다”: 하나의 체인이 요소를 선택하고 핸들러를 붙이고 텍스트를 업데이트합니다. 그 간결성이 큰 매력이었습니다.
현대 자바스크립트는 다소 장황하지만 더 명시적입니다:
querySelector와 addEventListener는 무슨 일이 일어나는지 정확히 알려줍니다.textContent는 표준 DOM 속성입니다(라이브러리 래퍼가 아님).?.)과 널 체크는 요소가 없을 때 무슨 일이 일어나는지 더 명확하게 합니다.문맥에 따라 다릅니다. 이미 프로젝트 전반에서 jQuery를 사용하고 있는 오래된 코드베이스를 유지한다면 jQuery 스니펫이 더 일관되고 빠르게 작업할 수 있습니다. 새 코드를 작성한다면, 현대 DOM API는 널리 지원되고 의존성을 줄이며 현재의 도구 및 프레임워크와 통합하기 쉽습니다.
오랫동안 jQuery의 가장 큰 장점은 예측 가능성이었습니다. 하나의 방식으로 요소를 선택하고 이벤트를 붙이거나 Ajax 요청을 하면 대부분의 환경에서 작동했습니다.
그러나 시간이 지나면서 브라우저들이 표준화되고 개선되었습니다. jQuery가 번들로 제공하던 많은 필수 편의 기능들이 이제 자바스크립트 자체에 내장되어 있어 기본적인 작업을 위해 추가 라이브러리가 필요하지 않을 때가 많아졌습니다.
현대 DOM 메서드들은 많은 jQuery 패턴을 대체합니다:
document.querySelector() / document.querySelectorAll()은 많은 경우 $(...)를 대체합니다.element.classList.add() / .remove() / .toggle()은 클래스 조작을 담당합니다.element.addEventListener()는 대부분의 경우 jQuery의 이벤트 래퍼를 대체합니다.이제 jQuery 특정 헬퍼를 기억하는 대신, 현대 브라우저에서 일관되게 동작하는 표준 API를 사용할 수 있습니다.
한때 $.ajax()가 많이 쓰였지만, 이제는 fetch()로 많은 일상적 요청을 더 간결하게 처리합니다—특히 JSON과 함께 사용하면 더욱 그렇습니다:
const res = await fetch('/api/items');
const data = await res.json();
오류와 타임아웃은 여전히 직접 처리해야 하지만, 핵심 아이디어—플러그인 없이 요청을 만드는 것—이 이제는 네이티브입니다.
jQuery는 콜백과 $.Deferred로 비동기 코드를 접하게 해 주었지만, 이제는 Promise와 async/await가 비동기 흐름을 더 읽기 쉽게 만들고 ES 모듈은 코드 조직을 더 명확하게 합니다.
이 조합(현대 DOM API + fetch + 최신 언어 기능)은 팀들이 기본적으로 jQuery를 찾던 많은 이유를 제거했습니다.
jQuery는 서버가 HTML을 렌더링하고 브라우저가 페이지를 불러온 뒤 기존 마크업 위에 동작을 '뿌리는' 다중 페이지 사이트 시대에 성장했습니다.
현대의 프론트엔드 프레임워크는 이 모델을 뒤집었습니다. 앱은 보통 브라우저에서 대부분의 UI를 생성하고 데이터를 기반으로 화면을 동기화합니다.
React, Vue, Angular는 컴포넌트—자신의 마크업, 동작, 상태를 가지는 재사용 가능한 작은 조각—로 인터페이스를 구성하는 개념을 대중화했습니다.
이 방식에서 프레임워크는 화면의 진실 공급원(source of truth)이 되고, 상태를 추적하며 상태가 바뀔 때 UI 일부를 다시 렌더링합니다. 프레임워크는 선언적으로(“X일 때 Y를 보여줘”) 변경을 표현하기를 기대합니다.
반면 jQuery는 명령형 DOM 조작(“이 요소를 찾아 텍스트를 바꿔, 숨겨”)을 장려합니다. 이 방식은 프레임워크의 렌더링 사이클과 충돌할 수 있습니다. 컴포넌트가 제어하는 DOM 노드를 수동으로 변경하면 다음 렌더링에서 변경이 덮어씌워지거나 일관성 문제가 발생해 디버깅이 어려워질 수 있습니다.
SPA가 보편화되면서 팀들은 Webpack, Rollup, Vite 같은 빌드 도구와 번들러를 채택했습니다. 페이지에 스크립트 태그 몇 개를 늘어놓는 대신, 모듈을 임포트하고 사용한 것만 번들링하며 성능 최적화를 합니다.
이 변화는 의존성과 번들 크기에 대한 민감도를 높였습니다. ‘혹시 필요할까’ 해서 jQuery를 가져오는 것은 모든 킬로바이트와 서드파티 업데이트가 파이프라인의 일부가 되는 환경에서 덜 자연스러워졌습니다.
프레임워크 안에서 jQuery를 사용할 수는 있지만, 보통 특수한 섬(Island)처럼 동작합니다—테스트하기 어렵고 추론하기 어려우며 리팩터링 중에 깨질 가능성이 높습니다. 그래서 많은 팀이 jQuery 스타일의 DOM 스크립팅 대신 프레임워크 고유의 패턴을 선택했습니다.
jQuery 자체는 “거대”하진 않지만, 그것과 함께 따라오는 부속(플러그인 등)이 문제를 만듭니다. jQuery에 의존하는 많은 프로젝트는 슬라이더, date picker, 모달 라이브러리, 유효성 검사 도구 같은 플러그인을 채워 넣어 시간이 지나며 더 많은 서드파티 코드를 다운로드하고 파싱하게 됩니다. 기능을 빠르게 추가하고 다시 보지 않으면 페이지는 여러 중복 유틸리티를 싣는 경우가 많습니다.
더 많은 자바스크립트는 브라우저가 가져오고 파싱하고 실행해야 할 양을 늘립니다. 이 영향은 모바일 장치, 느린 네트워크, 오래된 하드웨어에서 더 쉽게 느껴집니다. 사용자가 결국 매끄러운 경험을 얻는다 해도, 페이지가 추가 스크립트와 그 의존성을 기다리는 동안 ‘사용 가능해지기까지의 시간(time to usable)’이 악화될 수 있습니다.
오래된 사이트에서 흔히 보이는 패턴은 ‘하이브리드’ 코드베이스입니다: 어떤 기능은 jQuery로, 새로 추가된 부분은 React/Vue/Angular 같은 프레임워크로, 그리고 몇몇은 바닐라 JS로 섞여 있습니다. 그 혼합은 혼란을 초래합니다:
여러 스타일이 공존하면 작은 변경도 위험해집니다. 개발자가 컴포넌트를 업데이트하면 오래된 jQuery 스크립트가 여전히 같은 마크업을 조작하여 재현하기 어려운 버그를 유발할 수 있습니다.
팀들이 점차 jQuery에서 멀어지는 이유는 jQuery가 “작동을 멈추기” 때문이 아니라, 현대 프로젝트들이 번들 크기 축소와 UI 동작의 명확한 소유권을 우선시하기 때문입니다. 사이트가 커질수록 서드파티 코드를 줄이고 한 가지 접근 방식으로 표준화하는 것이 성능 조정, 디버깅, 온보딩을 훨씬 쉽게 만듭니다.
jQuery가 단지 인기 있었던 것이 아니라 기본 도구가 되었습니다. 수년 동안 상호작용 페이지를 안정적으로 만들기 위한 가장 쉬운 방법이었기 때문에 템플릿, 스니펫, 튜토리얼, 복사-붙여넣기 솔루션 곳곳에 박혔습니다.
한번 그렇게 되면 jQuery는 피하기 어려워졌습니다: 사이트가 하나의 작은 기능만 필요하더라도 종종 전체 라이브러리를 로드했습니다. 왜냐하면 다른 코드들이 jQuery가 존재한다고 가정했기 때문입니다.
jQuery가 여전히 존재하는 큰 이유는 성공 덕분에 써드파티 코드에 ‘어디에나’ 들어가게 되었기 때문입니다. 오래된 UI 위젯, 슬라이더, 라이트박스, 폼 유효성 검사, 테마 스크립트는 흔히 jQuery 플러그인으로 작성되었습니다. 사이트가 그런 컴포넌트들에 의존한다면 jQuery를 제거하려면 해당 의존성을 재작성하거나 교체해야 합니다—단순히 몇 줄 바꾸는 수준이 아닙니다.
WordPress는 많은 ‘레거시 jQuery’의 큰 원천입니다. 많은 테마와 플러그인—특히 몇 년 전에 만들어진 것들—이 프런트엔드 동작에 jQuery를 사용했고, 역사적으로는 WordPress 관리자 화면도 jQuery에 의존했습니다. 최신 버전이 현대 자바스크립트로 움직일 때조차도 기존 확장의 긴 꼬리가 많은 설치에서 jQuery를 유지하게 합니다.
오래된 사이트들은 종종 “작동하는 것을 건들지 말라”는 우선 순위를 가집니다. jQuery를 유지하는 것이 안전한 선택인 경우가 많습니다:
요컨대, jQuery는 항상 “잊혀진” 것이 아니라 사이트가 구축된 기반의 일부로 남아 있는 경우가 많고, 기반을 바꾸는 일은 쉽게 하지 않습니다.
jQuery가 “나쁘다”는 건 아니지만, 예전만큼 필요하지 않은 경우가 많습니다. 그래도 jQuery를 유지하거나 약간 추가하는 게 현실적으로 가장 실용적인 선택인 상황이 몇 가지 있습니다. 특히 시간, 호환성, 안정성을 우선할 때 그렇습니다.
구형 브라우저(특히 Internet Explorer 구버전)를 지원해야 한다면 jQuery는 DOM 선택, 이벤트 처리, Ajax를 네이티브 API만으로 맞추려면 필요한 여러 폴리필을 줄여줄 수 있습니다.
핵심 질문은 비용입니다: 레거시 브라우저를 지원하려면 어쨌든 추가 코드를 배포해야 하는 경우가 많습니다. 그 맥락에서 jQuery는 호환성 묶음의 합리적인 일부가 될 수 있습니다.
사이트가 이미 jQuery로 구축되어 있다면, 소규모 UI 수정은 같은 스타일로 하는 것이 더 빠르고 안전한 경우가 많습니다. 접근 방식을 혼용하면(이벤트 두 가지 방식, DOM 갱신 두 가지 방식) 유지보수가 더 어려워질 수 있습니다.
실용적인 규칙: 화면 한두 개만 건드리고 있고 앱이 전반적으로 안정적이라면 jQuery로 패치하는 것이 괜찮습니다—단 새 ‘시스템’으로 jQuery 사용을 확장하는 것은 피하세요.
단순한 마케팅 사이트나 내부 도구(번들러도, 트랜스파일러도 없는 경우)에서는 jQuery가 여전히 편리한 ‘한 줄 스크립트 태그’ 헬퍼입니다. 토글 메뉴나 간단한 폼 동작 같은 몇 가지 상호작용이 필요하고 빌드 파이프라인을 도입하고 싶지 않을 때 유용합니다.
많은 안정된 플러그인(달력, 테이블, 라이트박스)은 jQuery 기반으로 만들어졌습니다. 오래된 플러그인이 비즈니스적으로 중요하고 안정적이라면 jQuery를 의존성으로 유지하는 것이 가장 위험이 적은 선택일 수 있습니다.
커밋하기 전에 유지 관리되는 비-jQuery 대안이 있는지, 혹은 플러그인 업그레이드가 프로젝트가 감당할 수 없는 광범위한 재작성을 강제하는지 확인하세요.
jQuery에서 벗어나는 것은 큰 리팩터링이라기보다 의존성을 점진적으로 줄여 사용자에게 기대하는 동작을 깨뜨리지 않는 과정입니다. 안전한 접근법은 점진적입니다: 페이지가 작동하는 상태를 유지하면서 내부를 차근차근 교체합니다.
다음 세 가지 현실적 질문에 답하세요:
이 감사는 필요 없는 것을 교체하지 않게 도와주고 $.ajax()처럼 조용히 사용되는 숨겨진 의존성도 찾아냅니다.
대부분의 팀은 가장 흔한 패턴을 바꾸어 빠른 성과를 얻습니다:
$(".card") → document.querySelectorAll(".card").addClass() / .removeClass() → classList.add() / classList.remove().on("click", ...) → addEventListener("click", ...)작은 PR로 진행하면 리뷰와 롤백이 쉽습니다.
$.ajax()를 사용한다면, 해당 호출들을 fetch()(또는 작은 HTTP 헬퍼)로 하나씩 옮기세요. 응답 형태를 동일하게 유지하면 UI의 나머지 부분을 즉시 바꿀 필요가 없습니다.
// jQuery
$.ajax({ url: "/api/items", method: "GET" }).done(renderItems);
// Modern JS
fetch("/api/items")
.then(r =\u003e r.json())
.then(renderItems);
jQuery를 제거하기 전에 핵심 사용자 흐름, 폼 제출, 동적 UI에 대한 커버리지를 추가하세요. 가벼운 검사(Cypress 스모크 테스트나 QA 체크리스트)가 회귀를 조기에 잡아줄 수 있습니다. 가능하면 기능 플래그 뒤에 변경을 배포하고 분석/오류 비율이 안정적인지 확인하세요.
리팩터링 중 추가 안전이 필요하면 스냅샷과 롤백을 지원하는 도구를 사용하면 도움이 됩니다. 예를 들어, 레거시 프런트엔드를 현대화하는 팀들은 때때로 Koder.ai에서 교체안을 프로토타입하고 스냅샷/롤백 워크플로로 반복하면서 “잘 동작하는” 버전을 잃지 않고 실험합니다.
전반적인 계획을 정리하는 데 도움이 필요하면, 리팩터링 중 사용할 비교 기준으로 /blog/jquery-vs-vanilla-js를 참고하세요.
jQuery에서 벗어나는 과정은 보통 “문법을 바꾸는 것”보다 수년간 쌓인 가정들을 풀어내는 문제입니다. 팀을 늦추는 함정들과 피하는 방법은 다음과 같습니다.
완전한 재작성은 깔끔해 보이지만, 장기 브랜치, 많은 회귀, 미완성 작업을 배포해야 한다는 압박을 낳곤 합니다. 더 안전한 방법은 점진적입니다: 기능이나 페이지 단위로 하나씩 바꾸고 동작을 동일하게 유지하며 건드린 부분에 테스트를 추가하세요.
React/Vue/Svelte(혹은 가벼운 컴포넌트 시스템)를 도입하면서 jQuery가 동일한 DOM 노드를 직접 조작하면 “UI 줄다리기” 문제가 생깁니다: 프레임워크는 다시 렌더링하여 jQuery 변경을 덮어쓰고, jQuery는 프레임워크가 제어하는 요소를 수정합니다.
경험 법칙: 명확한 경계를 선택하세요. 또는:
오래된 코드의 많은 부분이 아래와 같은 위임 이벤트에 의존합니다:
$(document).on('click', '.btn', handler)
네이티브 DOM도 이걸 할 수 있지만, 매칭과 this/event.target 기대가 달라질 수 있습니다. 일반적인 버그는 중첩된 아이콘/스팬 때문에 잘못된 요소에 핸들러가 실행되거나, 리스너가 잘못된 상위 요소에 붙어 동적으로 추가된 항목에서는 동작하지 않는 것입니다. 위임 이벤트를 교체할 때는 다음을 확인하세요:
closest()가 자주 필요합니다)jQuery UI 효과나 커스텀 애니메이션은 때로는 우연히 접근성 문제를 숨기거나 도입하곤 했습니다. 페이드, 슬라이드, 토글을 교체할 때는 다음을 다시 확인하세요:
aria-expanded)prefers-reduced-motion)이 함정을 일찍 잡으면 마이그레이션이 더 빠르고 UI가 더 신뢰할 만해집니다—마지막 $()가 사라지기 전에도요.
jQuery는 ‘나쁜’ 것이 아닙니다. 브라우저들이 다르게 동작하던 시절에 실제 문제를 해결했습니다—특히 상호작용 페이지를 만들 때 반복적인 DOM 코드를 많이 줄여주었습니다. 달라진 것은 새 프로젝트에서는 보통 더 이상 그게 필요하지 않다는 점입니다.
몇 가지 요인이 그것을 ‘기본 선택’에서 ‘레거시 의존성’으로 밀어냈습니다:
오래된 사이트를 유지보수한다면 jQuery는 작은 수정, 안정된 플러그인, 또는 전체 재구축을 정당화하지 않는 페이지에 대해 여전히 합리적인 도구가 될 수 있습니다. 새 기능을 개발한다면 우선 네이티브 자바스크립트를 고려하고, jQuery는 명확히 시간을 절약하는 경우에만 유지하세요.
계속 실무에 도움이 되는 학습 경로:
더 빠르게 현대화할 방법을 평가 중이라면 점진적으로 프로토타입하고 배포하는 데 도움이 되는 도구를 고려하세요. Koder.ai 같은 도구는 채팅으로 원하는 동작을 설명하면 React 기반 UI와 필요 시 Go/PostgreSQL 백엔드를 생성하고, 준비되면 소스 코드를 내보낼 수 있어 기존 코드베이스와 통합하기 전에 프로토타입을 빠르게 만들어볼 수 있습니다.
도구나 지원 옵션을 평가 중이라면 여기를 참고하세요: /pricing
jQuery는 요소 선택, 이벤트 처리, Ajax 요청, 기본 효과(show/hide, fade, slide) 같은 브라우저에서 흔히 하는 작업을 단순화한 자바스크립트 라이브러리입니다. 대표적인 패턴은 $() 함수로 요소를 찾아 체이닝 방식으로 동작을 연결하는 것입니다.
$는 보통 jQuery가 제공하는 단축 함수로, 페이지에서 요소를 찾는 역할을 합니다—document.querySelectorAll()과 비슷한 역할을 하고, 체이닝 가능한 jQuery 객체를 반환합니다.
과거 코드에서 $()를 보면 보통 "무언가를 선택해서 작업을 수행한다"는 뜻입니다.
당시에는 브라우저마다 동작이 달라서 간단한 이벤트, DOM 탐색, Ajax도 브라우저별 예외 처리를 많이 필요로 했습니다.
jQuery는 그런 불일치를 숨기고 일관된 API를 제공해 주었기 때문에 팀들이 더 빠르게, 예측 가능하게 제품을 출시할 수 있게 해 주었습니다.
주로 현대 브라우저와 자바스크립트가 발전했기 때문입니다. 이제는 많은 전통적 jQuery 작업을 기본 기능으로 대체할 수 있습니다:
querySelector / querySelectorAllclassListaddEventListener아니요. 많은 기존 사이트들이 여전히 jQuery를 사용하고 있고, 동작도 계속합니다. 다만 ‘레거시’라는 말은 새 프로젝트에서는 덜 보인다는 뜻입니다.
실용적인 관점은 성능, 유지보수, 그리고 현재 의존성(특히 플러그인)을 고려해 유지할 가치가 있는지 판단하는 것입니다.
그것이 바로 이유입니다: 오래된 생태계—특히 테마와 플러그인—에 깊게 박혀 있기 때문입니다. 예를 들어 WordPress의 많은 확장과 테마는 역사적으로 jQuery에 의존했습니다.
사이트가 jQuery 전용 플러그인(슬라이더, date picker, 라이트박스, 유효성 검사 등)에 의존한다면 jQuery를 제거하려면 단순한 코드 변경이 아니라 해당 플러그인을 교체하거나 재작성해야 할 가능성이 큽니다.
몇몇 현실적인 상황에서는 여전히 쓸 만합니다:
이런 경우 안정성과 속도가 종속성 축소보다 더 중요할 수 있습니다.
점진적이고 측정 가능한 방식으로 접근하세요:
$.ajax()를 로 하나씩 옮깁니다.이벤트 위임 관련 버그가 흔합니다. jQuery 코드 예:
$(document).on('click', '.btn', handler)
네이티브 DOM으로 바꿀 때는 매칭과 this/event.target 기대치가 달라질 수 있습니다. 교체 시 확인할 것:
그럴 수 있습니다—효과나 DOM 재작성은 접근성에 영향을 줄 수 있습니다. hide()/show()나 슬라이드/페이드 동작을 교체할 때는 다음을 재검토하세요:
aria-expanded 같은 상태 속성prefers-reduced-motion)동작을 시각적으로 같게 만드는 것뿐 아니라 상호작용과 키보드 흐름까지 동일하게 유지하는 것이 중요합니다.
fetch + async/await그래서 새로운 프로젝트에서는 호환성 레이어가 덜 필요해졌습니다.
fetch()작은 PR과 단계적 배포로 회귀 위험을 줄이세요.
closest()가 필요한 경우가 많음)동적으로 추가되는 요소에 대한 동작을 반드시 테스트하세요.