2025년 6월 02일·7분
John Resig와 jQuery: 프론트엔드를 형성한 라이브러리
John Resig의 jQuery는 자바스크립트를 단순화하고 브라우저의 차이를 완화했으며, 프런트엔드 도구들에 영향을 준 패턴들을 보급했습니다. 이 글은 jQuery가 웹에 미친 영향을 설명합니다.
John Resig의 jQuery는 자바스크립트를 단순화하고 브라우저의 차이를 완화했으며, 프런트엔드 도구들에 영향을 준 패턴들을 보급했습니다. 이 글은 jQuery가 웹에 미친 영향을 설명합니다.
2005–2008년경에 웹사이트를 만들고 있었다면, 단순히 "자바스크립트를 쓴다"고 말할 수 없었습니다. 브라우저와 교섭하는 일이었죠.
메뉴 항목 강조, 모달 표시, 폼 검증, 페이지 전체 리프레시 없이 HTML 조각을 불러오는 간단한 기능조차 작은 연구 과제로 변할 수 있었습니다. 어떤 메서드가 어떤 브라우저에 있는지, 어떤 이벤트가 다르게 동작하는지, 그 DOM 호출이 내 환경에서는 동작하는데 사용자 절반에게는 왜 깨지는지를 찾아야 했습니다.
개발자들은 "한 번 쓰면 어디서나 실행"되기를 원했지만, 브라우저 차이 때문에 사실상 "세 번 쓰고 모두 테스트"하는 기분이었습니다. Internet Explorer는 고유한 특성이 있었고, 구버전의 Firefox와 Safari는 엣지 케이스에서 다르게 행동했으며, 이벤트 처리나 DOM 조작 같은 기본조차 일관되지 않았습니다.
이 불일치는 단순히 시간을 낭비하게 만든 것뿐만 아니라 팀이 무엇을 구축할지에 영향을 주었습니다. 인터랙티브한 UI는 가능했지만 비용이 많이 들고 유지보수가 취약했습니다. 많은 사이트가 필요 이상으로 단순한 상태로 남아있던 이유는 여러 브라우저에서 제대로 동작하게 만드는 비용이 너무 컸기 때문입니다.
John Resig가 만든 jQuery는 일상적 작업에 집중했기 때문에 의미가 있었습니다: 요소 선택, 사용자 액션에 반응, 페이지 변경, 작은 전환 애니메이션, AJAX 요청 등입니다. 브라우저 차이를 매끄럽게 처리하는 읽기 쉬운 작은 API를 제공해 기능을 만드는 데 더 많은 시간을 쓸 수 있도록 해주었습니다.
실제 사용에서는 공통 상호작용이 직관적이고 반복 가능하게 느껴졌습니다—가르치고, 공유하고, 재사용할 수 있는 것이었죠.
이야기는 단순히 jQuery가 시간을 절약했다는 것만이 아닙니다. 체이닝하는 습관, 간결한 셀렉터에 의존하는 방식, 이벤트 중심으로 UI 코드를 구성하는 방식, 그리고 라이브러리가 일관된 "개발자 경험"을 제공해야 한다는 기대를 널리 퍼뜨렸다는 점이 중요합니다. 이런 습관들은 웹 표준이 따라잡고 새로운 프레임워크가 등장한 이후에도 후속 도구들에 영향을 미쳤습니다.
"일반적인 경로를 쉽게 만들자"는 사고방식은 오늘날의 툴에서도 볼 수 있습니다. 예를 들어 Koder.ai 같은 현대 플랫폼은 다른 층위에서 같은 개발자 경험 원칙을 적용해 채팅 중심 워크플로우로 웹, 백엔드, 모바일 앱을 만들 수 있게 합니다—한때 jQuery가 브라우저 쪽 UI 코드를 친근하게 만들어 준 것과 유사합니다.
John Resig는 2000년대 중반 소규모 자바스크립트 헬퍼 라이브러리를 손대기 시작했을 때 운동을 일으키려 한 것이 아니었습니다. 그는 단순히 같은 마찰을 느끼는 실무 개발자였고, 웹에서 간단한 일들이 너무 많은 코드와 깨지기 쉬운 동작을 요구한다는 사실에 불편함을 느꼈습니다.
Resig의 핵심 동기는 명료함이었습니다. 개발자들에게 수십 가지 브라우저 특성을 외우라고 하기보다 사람들이 페이지를 만드는 방식—"이 요소를 찾아라", "이걸 바꿔라", "사용자가 클릭하면 저걸 해라"—에 맞는 명령 소수로 해결하고자 했습니다. jQuery는 보여주기식의 기교를 위해 만들어진 것이 아니라, 일상의 좌절을 줄여 평범한 프로젝트가 배포되도록 돕기 위해 만들어졌습니다.
동시에 일반 웹 개발자에 대한 공감도 중요했습니다. 대부분의 사람들은 실험적인 데모를 만드는 것이 아니라 마케팅 사이트, 관리 패널, 제품 페이지를 마감 기한 내에 유지·관리하고 있었습니다. jQuery의 작고 읽기 쉬운 API는 그런 현실을 반영했습니다.
jQuery는 배우기 쉽고 전달하기 쉬워 빠르게 확산되었습니다. Resig는 즉각적인 이득을 보여주는 발표와 데모를 했고, 프로젝트는 훌륭한 문서화와 접근 가능한 예제로 명성을 얻었습니다. 도구가 실제 문제를 몇 분 만에 해결해 준다면 개발자는 동료에게 이를 알리게 마련입니다.
초기 커뮤니티는 이 선순환을 강화했습니다. 사람들은 스니펫을 공유하고, 플러그인을 만들고, Resig 혼자 테스트할 수 없는 브라우저와 기기에서의 엣지 케이스를 보고했습니다. jQuery는 공개적으로 성장했고, 피드백은 무엇을 단순하게 유지할지, 무엇을 다듬을지 결정하는 데 영향을 주었습니다.
jQuery를 단일 "천재적 순간"으로 환원하는 건 유혹적이지만, 더 솔직한 이야기는 끈기와 현명한 판단입니다: 널리 퍼진 고통을 알아차리고, 일상적 워크플로우에 맞춰 설계하며, 일관성을 통해 신뢰를 쌓아간 것이죠. Resig는 단지 코드를 작성한 것이 아니라 웹이 실제로 작동하는 방식에 맞춘 친근한 지름길을 만든 것입니다.
jQuery 이전에는 "단순한" 인터랙션을 구현하려면 브라우저별 트릭을 잔뜩 이어붙여야 했습니다. 풍부한 인터페이스를 만들 수는 있었지만 그 비용은 시간과 인내, 많은 테스트였습니다.
오늘날 버튼을 가져와 텍스트를 바꾸는 일은 한 줄처럼 느껴집니다. 그때는 DOM 선택이 일관되지 않고 번거로웠습니다. 어떤 브라우저는 유용한 메서드를 지원하고 어떤 브라우저는 그렇지 않았기 때문에 getElementById, getElementsByTagName, 수동 루프, 문자열 검사 등을 섞어서 원하는 요소를 찾곤 했습니다.
심지어 필요한 요소를 선택했을 때도 컬렉션을 처리하거나 배열로 변환하거나 이상한 엣지 케이스를 우회하기 위해 추가 코드를 써야 했습니다.
클릭 핸들러, 키 입력, 호버 효과는 흔한 요구였지만 브라우저는 이벤트 바인딩 방식과 이벤트 객체의 구조에 대해 다르게 동작했습니다. 한 브라우저에서는 완벽히 동작하던 코드가 다른 브라우저에서는 조용히 실패하곤 했습니다.
개발자들은 이벤트 처리를 정규화하는 래퍼를 작성했습니다: "이 API가 있으면 그걸 쓰고, 그렇지 않으면 저걸 써라." 그러면 코드가 더 길어지고 디버깅도 늘어나며 버그가 끼어들 기회도 더 많아졌습니다.
비동기 요청은 가능했지만 친절하지 않았습니다. XMLHttpRequest를 직접 설정하면 여러 단계, 브라우저별 분기 논리, 응답 상태를 세심하게 다루는 일이 필요했습니다.
페이지 전체를 리로드하지 않고 폼을 제출하는 작은 기능조차 수십 줄의 코드와 재시도, 에러 처리, 브라우저 테스트를 요구할 수 있었습니다.
가장 큰 고통은 한 번 코드를 작성하는 것이 아니라 모든 환경에서 작동하게 유지하는 것이었습니다. 팀은 의존할 수 있고 배우기 쉬우며 새로운 개발자가 브라우저 호환성 체크리스트를 외우지 않아도 기여할 수 있는 무언가가 필요했습니다. jQuery는 그 일상의 마찰에 대한 답으로 등장했습니다.
jQuery의 돌파구는 새로운 브라우저 기능이 아니라 일상적 UI 작업을 생각하는 방식이었습니다. 요소를 찾고, 업데이트하고, 이벤트를 연결하는 많은 브라우저별 코드를 쓰는 대신 jQuery는 일상적인 패턴을 단순화했습니다: 무언가를 선택하고, 그다음에 그것에 대해 어떤 일을 한다.
중심에는 $() 함수가 있습니다. CSS와 유사한 선택자(또는 요소)를 넘기면 일치하는 요소를 감싼 jQuery 객체를 돌려줍니다.
그 이후에는 클래스 추가, 요소 숨기기, 텍스트 변경, 클릭 핸들러 연결 같은 작업을 수행하는 메서드를 호출합니다. 목적은 모든 저수준 세부를 노출하는 것이 아니라 거의 모든 사이트가 필요로 하는 UI 작업의 80%를 다루는 것이었습니다.
jQuery는 각 단계가 동일한 jQuery 객체를 반환하는 유창한 스타일을 권장했습니다. 그래서 다음과 같이 체인으로 이어 쓸 수 있었습니다:
$(".notice")
.addClass("active")
.text("Saved!")
.fadeIn();
내부 동작을 몰라도 이야기의 흐름—공지 찾기, 활성 표시, 메시지 설정, 표시—을 이해할 수 있었습니다.
jQuery 이전에는 개발자들이 항상 묻곤 했습니다: "이 브라우저에서 어떤 메서드가 작동하지?" 또는 "구버전에서는 속성 이름이 다르지?" jQuery는 일관된 메서드와 예측 가능한 동작으로 그 질문에 답했습니다. 초보자는 자바스크립트로 부드럽게 진입할 수 있었고, 전문가들은 속도를 얻었습니다: 커스텀 헬퍼 함수가 줄고 호환성 해킹이 줄며 리뷰할 코드가 줄어들었습니다.
API가 간결하고 메서드 이름이 UI 의도와 맞아떨어지면서 jQuery는 팀들이 스크립트를 더 쉽게 훑어보게 만들었습니다. 흩어진 DOM 호출과 임시 변수가 아닌, UI 행동의 연속으로 코드를 읽을 수 있게 된 것이죠. 프런트엔드 작업이 브라우저와 싸우는 것보다 명확한 단계들을 조립하는 느낌으로 바뀌었습니다.
jQuery의 가장 설득력 있는 점 중 하나는 UI 작업의 첫 번째 단계인 적절한 요소 선택을 아주 간단하게 만든 것입니다. 브라우저별 DOM 메서드를 외우는 대신 CSS처럼 보이는 표현을 써서 즉시 이해할 수 있게 했습니다.
디자이너와 프런트엔드 개발자들은 이미 셀렉터로 생각했습니다: "헤더 안의 .button들 가져오기", "첫 번째 항목 타깃팅", "특정 타입 입력 찾기" 같은 식이죠. jQuery는 그 정신 모델을 자바스크립트 도구로 바꿨습니다:
$(".nav a") — 내비게이션의 링크 작업$("#signup-form input[type=email]") — 특정 필드 찾기$("ul li:first") — 빠른 첫 항목 로직이 가독성은 중요했습니다. "원하는 것"을 "DOM이 요구하는 방식"으로 바꾸는 노력을 줄여주었죠.
$(selector) 뒤에는 jQuery의 셀렉터 엔진인 Sizzle이 있었습니다. 초기 브라우저들은 특정 셀렉터의 동작에 합의하지 않았고 일부는 전체 집합을 지원하지 않기도 했습니다. Sizzle은 일관된 해석과 폴백 동작을 제공해 $(".card > .title") 같은 선택자가 브라우저마다 달라지지 않도록 했습니다.
결과는 생산성의 실제 향상이었습니다: 조건문과 "IE라면…" 같은 우회가 줄고, 셀렉터가 한 브라우저에서는 일치하고 다른 브라우저에서는 안 맞는 이유를 디버깅하는 시간이 줄었습니다.
강력한 셀렉터는 비용도 감췄습니다:
그럼에도 일상적인 인터페이스 작업에서 "찾기"가 쉬워진 것은 큰 변화였고 jQuery가 강력하게 느껴진 큰 이유였습니다.
많은 개발자에게 jQuery는 "라이브러리"가 아니라 매일 찾게 되는 도구 상자였습니다. 브라우저가 세부적으로 다른 상황에서도 몇 가지 예측 가능한 호출로 상호작용을 구축할 수 있게 해주었죠.
jQuery 이전에는 클릭 핸들러를 연결하려면 다른 이벤트 모델과 엣지 케이스를 조정해야 했습니다. jQuery의 .on()(그리고 초창기 .bind()/.click())은 click, submit, 키보드 입력 같은 사용자 동작을 일관되게 듣는 방법을 제공했습니다.
또한 "페이지가 준비되었을 때 실행"을 다음과 같이 명확하게 표현하게 했습니다:
$(function () {
// safe to touch the DOM
});
이 하나의 습관은 일반 페이지에서의 타이밍 버그를 줄였습니다—요소가 존재하는지 더 이상 걱정할 필요가 없게 된 것이죠.
jQuery의 DOM API는 의도적으로 작고 실용적으로 설계되었습니다. 콘텐츠를 업데이트해야 한다면 .text()나 .html(). UI 조각을 만들어야 한다면 ('<div>...</div>')와 .append(). 시각적 상태는 .addClass(), .removeClass(), .toggleClass()로.
className 차이, 속성의 특이점, 불일치하는 노드 메서드를 다루느라 시간을 쓰는 대신 개발자는 무엇을 바꿔야 할지에 집중할 수 있었습니다.
.hide(), .show(), .fadeIn(), .slideToggle() 같은 내장 애니메이션은 최소한의 노력으로 페이지를 생동감 있게 만들었고 디자이너와 이해관계자들이 좋아했습니다.
단점은 이펙트를 쉽게 과용할 수 있다는 점입니다—과도한 페이드와 슬라이드는 인터페이스를 느리거나 장식적으로 만들 수 있었습니다. 그럼에도 메뉴, 아코디언, 알림 같은 전형적인 상호작용에는 jQuery가 다듬어진 느낌을 주는 진입 장벽을 낮췄습니다.
이벤트, DOM 변경, 이펙트 전반에서 진짜 이득은 단순함이었습니다: 일상 작업의 엣지 케이스가 줄고 팀이 빨리 배울 수 있는 공통 패턴이 생겼습니다.
jQuery 이전에 "AJAX"는 트릭처럼 들렸습니다: 전체 페이지를 새로 고치지 않고 일부만 업데이트하기. 본질적으로는 브라우저가 백그라운드에서 요청을 보내고(종종 HTML이나 JSON을 받고) 페이지를 업데이트해 사용자가 계속 진행할 수 있게 하는 것입니다.
XMLHttpRequest에서 원라이너로기본 기능은 XMLHttpRequest였지만 직접 쓰면 반복 코드가 많았습니다: 요청 생성, 상태 관찰, 응답 파싱, 브라우저별 엣지 케이스 처리 등.
jQuery는 그 복잡성을 다음과 같은 헬퍼 메서드로 감쌌습니다:
$.ajax() — 전체 제어$.get() / $.post() — 간단한 요청.load() — HTML을 가져와 요소에 주입이제 이벤트 핸들러 구성, 쿼리 스트링 생성, 응답 파싱을 일일이 작성하는 대신 사용자가 다음에 무엇을 보아야 하는지에 집중할 수 있었습니다.
다음과 같은 패턴이 웹 전반에 빠르게 보편화되었습니다:
서버가 구식이어도 jQuery 덕분에 인터페이스는 반응적으로 느껴졌습니다.
jQuery는 요청 시작을 쉽게 만들었지만, 끝까지 올바르게 처리하는 것은 항상 쉬운 일이 아니었습니다. 흔한 실수는:
API는 진입 장벽을 낮췄지만, "행복한 경로"만으로는 신뢰할 수 있는 인터페이스를 만들 수 없다는 교훈도 남겼습니다.
jQuery는 단순히 다운로드하는 라이브러리가 아니었습니다—사람들이 그 위에 구축하는 플랫폼이었습니다. 플러그인은 $.fn에 함수를 추가해 jQuery를 확장하는 작은 애드온이었고, 개발자는 이미 쓰던 스타일로 기능을 호출할 수 있었습니다.
진입 장벽이 낮았습니다. jQuery를 알면 플러그인 패턴을 이미 이해하고 있었고, 선택자 + 메서드 호출 + 옵션 객체라는 익숙한 방식으로 기능을 끼워 넣을 수 있었습니다.
또한 jQuery의 관례 덕분에 다른 작성자가 만든 플러그인도 놀랍도록 일관성 있게 느껴졌습니다:
$('.menu').dropdown()은 네이티브 jQuery처럼 읽혔습니다.$('.btn').addClass('x').plugin().fadeIn().{ speed: 200, theme: 'dark' } 같은 구성 방식은 복사해 쓰기 쉬웠습니다.플러그인은 원시 DOM 작업과 전체 애플리케이션 프레임워크 사이의 "누락된 중간"을 채웠습니다. 흔한 범주는 슬라이더/캐러셀, 폼 검증, 모달과 라이트박스, 날짜 선택기, 자동완성, 툴팁, 테이블 헬퍼 등이었습니다.
많은 팀에게 특히 마케팅 사이트나 내부 대시보드를 만드는 곳에서는 플러그인이 몇 주 걸리던 UI 작업을 하루 만에 조립할 수 있게 해주었습니다.
플러그인 붐은 비용도 가져왔습니다. 품질은 천차만별이었고, 문서화가 얇을 수 있었으며, 여러 플러그인을 결합하면 CSS 충돌이나 이벤트 핸들러 충돌이 발생하곤 했습니다. 의존성 확산도 현실적인 문제가 되었고, 한 기능이 다른 두 플러그인에 의존하면 각 플러그인의 업데이트 이력이 문제를 일으킬 수 있었습니다. 작성자가 떠나면 유지되지 않는 플러그인이 프로젝트를 구형 jQuery 버전에 묶어두거나 보안·안정성 위험이 되기도 했습니다.
jQuery의 핵심이 DOM 작업을 예측 가능하게 만들었지만, 팀은 여전히 인터페이스 조각을 직접 만들어야 했습니다. jQuery UI는 달력, 대화상자, 탭, 슬라이더, 아코디언, 드래그/정렬 행동 같은 준비된 컴포넌트를 채워 넣어 이 격차를 메웠습니다. 작은 팀이나 에이전시가 많은 마케팅 사이트나 내부 툴을 빨리 배포해야 할 때 이 "충분히 좋음, 이제" 가치는 매우 컸습니다.
큰 이득은 단순히 위젯 자체가 아니라 위젯 + 일관된 API와 테마 기능의 결합이었습니다. 대화상자나 자동완성을 붙여 빠르게 프로토타이핑하고 ThemeRoller로 "브랜딩"을 맞추면 매번 마크업과 CSS를 다시 작성할 필요가 없었습니다. 그 반복성은 jQuery UI를 디자인 시스템이라기보다 실용적 툴킷으로 만들었습니다.
jQuery Mobile은 다른 문제를 해결하려 했습니다: 초기 스마트폰은 브라우저 능력이 들쭉날쭉하고 CSS 지원이 제한적이었으며 반응형 디자인 관행이 정립되기 전이었습니다. 터치 친화적 UI 컴포넌트와 Ajax 페이지 전환을 포함한 "싱글 페이지" 내비게이션 모델을 제공해 하나의 코드베이스로 네이티브에 가까운 앱처럼 동작하게 만들려 했습니다.
웹 표준이 개선되고—CSS3, 더 나은 모바일 브라우저, 이후 네이티브 폼 컨트롤과 레이아웃 원시 기능 등장—이러한 추상화 중 일부는 이득보다 비용이 커졌습니다. jQuery UI 위젯은 무거워질 수 있고, 접근성 측면에서 맞추기 어렵거나 최신 디자인 기대치와 정렬하기 어려웠습니다. jQuery Mobile의 DOM 재작성과 내비게이션 모델은 반응형 우선 레이아웃이나 프레임워크 기반 라우팅과 충돌하기도 했습니다.
그렇더라도 두 프로젝트는 중요한 아이디어를 증명했습니다: 공유 가능하고 재사용 가능한 UI 컴포넌트는 실제 제품의 배포 속도를 극적으로 올릴 수 있다는 점입니다.
jQuery는 브라우저를 더 잘 보이게 만든 것뿐 아니라 "정상적인" 프런트엔드 코드의 모습을 바꿨습니다. 일상적인 UI 작업이 예측 가능해지자 팀은 특별한 페이지에만 자바스크립트를 쓰는 것이 아니라 매일 자바스크립트를 쓰기 시작했습니다.
jQuery의 가장 큰 문화적 변화 중 하나는 체이닝을 대중화한 것입니다: 요소를 선택하고 그 위에서 읽기 쉬운 흐름으로 계속 동작을 연결합니다.
$(".card")
.addClass("active")
.find(".title")
.text("Updated")
.end()
.fadeIn(200);
그 유창한 스타일은 이후 라이브러리와 현대 네이티브 API에도 영향을 주었습니다. 또한 개발자들을 큰 단일 함수 대신 작고 조합 가능한 연산으로 나누도록 유도했습니다.
$.each, $.map, $.extend, AJAX 단축메서드 같은 jQuery 헬퍼는 로직을 몇 줄로 압축하기 쉽게 만들었습니다. 이는 속도를 올렸지만 때로는 복잡한 원라이너와 암묵적 동작을 낳아 나중에 다시 보기 어려운 코드가 되기도 했습니다.
많은 코드베이스는 비즈니스 로직이 클릭 핸들러 안에 섞여 들어가 버렸습니다. "여기에 그냥 해버리자"는 편의성이 배포 속도를 올렸지만 장기적 복잡성을 키우는 원인이 되었습니다.
컴포넌트와 예측 가능한 상태 모델이 보편화되기 전에는 jQuery 앱들이 종종 상태를 DOM(클래스, 숨겨진 입력, 데이터 속성)에 저장했습니다. 디버깅은 라이브 HTML을 검사하고 예상치 못한 순서로 발생할 수 있는 이벤트 콜백을 스텝으로 따라가는 일이었습니다.
단위 테스트는 가능했지만 팀들은 수동 QA와 브라우저 개발자 도구에 더 의존하는 경우가 많았습니다. 문제들은 애니메이션, AJAX, 이벤트 버블링과 같은 타이밍 관련인 경우가 많아 버그가 간헐적으로 느껴지곤 했습니다.
jQuery 코드는 팀이 다음을 지킬 때 유지보수성이 높았습니다:
반대로 페이지에 핸들러 층이 쌓이고 동일한 셀렉터가 반복되며 애니메이션 콜백 안에 "한 번만 더" 하는 수정이 쌓이면 얽히기 쉬웠습니다. 라이브러리는 빠른 반복을 쉽게 만들었고, 규율이 결과가 오래 지속되는지를 가른 셈입니다.
jQuery는 하루아침에 사라지지 않았고 더 나빠져서 사라진 것도 아닙니다. 브라우저 플랫폼이 더 이상 통역자가 필요 없어졌기 때문에 덜 사용되게 된 것입니다. jQuery가 매끄럽게 처리했던 문제들—누락된 API, 일관성 없는 동작, 번거로운 워크플로우—은 표준이 성숙하고 브라우저들이 수렴하면서 줄어들었습니다.
DOM과 자바스크립트 API가 표준화되면서 많은 jQuery 호출이 직접적인 대응 기능을 얻었습니다:
document.querySelector()와 document.querySelectorAll()이 과거 $(...)의 많은 경우를 대체addEventListener()가 보편적으로 신뢰할 수 있게 되어 이벤트 처리의 큰 부분이 사라짐fetch()와 async/await가 AJAX 스타일 호출을 네이티브처럼 가독성 좋게 만듦네이티브 방식이 브라우저 전반에서 일관되면 헬퍼 라이브러리에 의존할 이유가 줄어듭니다.
웹 앱이 몇 개의 인터랙티브 위젯에서 제품 수준으로 커지면서 팀들은 로드 시간과 자바스크립트 비용을 더 신경 쓰게 되었습니다. 몇 가지 편의 기능을 위해 jQuery(및 플러그인)를 포함시키는 것이 정당화되기 어려워졌습니다—특히 모바일 네트워크 환경에서는 더더욱요.
jQuery가 느렸다는 것이 아니라 "한 개 더하는 의존성" 자체가 현실적인 트레이드오프로 다가온 겁니다. 개발자들은 점점 더 작고 목적이 분명한 유틸리티를 선호하거나, 플랫폼이 이미 해주는 일은 라이브러리를 쓰지 않기도 했습니다.
싱글 페이지 애플리케이션 프레임워크는 DOM을 수동으로 건드리는 대신 상태를 관리하고 컴포넌트로 UI를 조립하는 쪽으로 초점을 옮겼습니다. React/Vue/Angular 스타일 사고에서는 일반적으로 "페이지에 가서 이 요소를 찾아 바꿔라"가 아니라 데이터를 업데이트하면 UI가 재렌더링됩니다.
이 모델에서 jQuery의 강점—명령적 DOM 조작, 이펙트, 일회성 이벤트 연결—은 덜 중심적이거나 때로는 권장되지 않는 방식이 됩니다.
jQuery의 미션은 웹을 사용하기 쉽고 일관되게 만드는 것이었습니다. 브라우저가 따라잡으면서 jQuery는 덜 필요해졌지 덜 중요해진 것은 아닙니다. 많은 프로덕션 사이트가 여전히 jQuery를 사용하고 있고, 현대 API와 개발자 기대치는 jQuery가 일상 개발자들의 문제를 해결했던 교훈을 반영합니다.
jQuery는 더 이상 신규 프런트엔드 작업의 기본 선택은 아니지만, 의외로 많은 웹에서 조용히 동작하고 있으며 그 영향력은 많은 개발자의 자바스크립트 사고 방식에 녹아 있습니다.
주로 안정성을 재작성보다 우선시하는 곳에서 jQuery를 만나게 됩니다:
이런 프로젝트를 유지보수할 때의 장점은 예측 가능성입니다: 코드는 이해하기 쉽고 문서화가 잘 되어 있으며 보통 패치하기 쉽습니다.
현대 도구들이 jQuery를 그대로 복사하진 않았지만 그 좋은 직관들은 흡수했습니다:
심지어 바닐라 자바스크립트의 진화(querySelectorAll, classList, fetch, 개선된 이벤트 처리 등)도 jQuery가 해결했던 일상 문제들을 반영합니다.
가장 큰 교훈은 제품적 사고입니다: 작고 일관된 API와 훌륭한 문서는 업계가 코드를 작성하는 방식을 바꿀 수 있습니다.
또한 "개발자 경험(DX)"은 누적된 가치를 만든다는 점을 상기시켜줍니다. jQuery 시대의 DX는 브라우저 특성을 깔끔한 API 뒤로 숨기는 것이었지만, 오늘날에는 아이디어에서 실행 소프트웨어까지의 경로를 압축하는 것도 포함됩니다. 그래서 Koder.ai 같은 분위기 기반 코딩 플랫폼이 많은 팀에 공감되는 이유도 있습니다: 보일러플레이트를 수작업으로 조립하는 대신 채팅 인터페이스에서 반복하고, React 프런트엔드와 Go + PostgreSQL 백엔드(또는 Flutter 모바일 앱)를 생성하고, 필요할 때 소스 코드를 내보낼 수 있는 선택지도 유지할 수 있으니까요.
jQuery는 브라우저별로 달라지는 DOM 스크립팅을 작고 예측 가능한 도구 집합으로 바꿔 주었기 때문에 중요했습니다. 요소 선택, 이벤트 바인딩, DOM 변경, AJAX 같은 일상적인 작업을 브라우저 간 일관되게 처리할 수 있게 해 팀의 개발 속도와 신뢰도를 높였죠.
jQuery 이전에는 개발자들이 주로 다음과 같은 교차 브라우저 차이에 부딪혔습니다:
XMLHttpRequest 설정과 엣지 케이스)핵심 비용은 한 번 코드를 쓰는 것이 아니라, 그 코드를 모든 브라우저에서 안정적으로 유지하는 것이었습니다.
$()는 핵심 함수로, CSS 스타일의 선택자(또는 DOM 요소)를 전달하면 일치하는 요소들을 감싼 jQuery 객체를 반환합니다. 그 객체는 일관된 메서드 세트를 제공해 브라우저의 세부 차이에 신경 쓰지 않고 "찾고, 그다음 동작"하는 방식으로 작업할 수 있게 해줍니다.
체이닝이 중요한 이유는 대부분의 jQuery 메서드가 동작을 수행한 뒤 동일한 jQuery 객체를 반환하기 때문입니다. 덕분에 임시 변수를 적게 쓰고 한 줄에 UI 작업의 흐름(선택 → 수정 → 애니메이션)을 읽기 쉽게 표현할 수 있습니다.
Sizzle은 $(selector) 뒤에 있는 셀렉터 엔진입니다. 초기에는 브라우저마다 셀렉터 지원과 해석 방식이 달라 일관된 동작을 보장하기 어려웠는데, Sizzle은 그 차이를 보완해 더 넓은 셀렉터를 안정적으로 사용할 수 있게 했습니다.
jQuery는 공통적인 이벤트 작업을 정규화해 브라우저별 분기를 쓰지 않아도 되게 했습니다. 또한 DOM이 준비되었을 때 실행하는 편리한 패턴을 널리 퍼뜨렸습니다:
$(function () {
// safe to touch the DOM
});
이 습관은 전형적인 페이지에서 타이밍 관련 버그를 줄이는 데 큰 도움이 됐습니다.
jQuery의 AJAX 헬퍼는 XMLHttpRequest의 반복적인 부분을 감싸 일상적인 경우를 쉽게 만들었습니다:
$.ajax() — 세부 제어용$.get() / $.post() — 간단한 요청용.load() — HTML을 가져와 요소에 주입이로 인해 반응성이 좋은 UI를 만들기 쉬워졌지만, 여전히 견고한 에러 처리와 사용자 피드백은 필요합니다.
플러그인은 보통 $.fn에 메서드를 붙이는 방식으로 jQuery를 확장했습니다. jQuery를 알고 있다면 플러그인 패턴도 바로 이해할 수 있었고, 선택자 + 옵션 객체 + 체이닝이라는 친숙한 방식으로 기능을 ‘끼워 넣을’ 수 있었습니다. 이로 인해 모달, 슬라이더, 자동완성 등 많은 기능이 빠르게 확산되었죠.
jQuery가 쇠퇴한 주된 이유는 브라우저 자체가 jQuery가 감쌌던 문제들을 표준으로 채워 넣었기 때문입니다:
querySelector(All)는 과거 셀렉터 도움의 많은 부분을 대체했고addEventListener()는 이벤트 불일치 문제를 줄였으며fetch()와 async/await는 네트워크 코드를 더 깔끔하게 만들었습니다또한 성능과 번들 크기가 중요해지면서, 몇 가지 편의 기능 때문에 jQuery 전체를 싣고 가는 것이 점점 부담스러워졌습니다.
무조건 재작성할 필요는 없습니다. 현실적인 접근법은 다음과 같습니다:
jQuery는 레거시 앱, 오래된 CMS 테마/플러그인, 혹은 "이미 페이지에 올라와 있는" 소규모 보완 작업에서 여전히 현실적인 선택일 수 있습니다.