프롤로그: 2006년 1월, 뉴욕의 작은 이벤트
2006년 1월 14일, 뉴욕의 BarCamp NYC라는 작은 "언컨퍼런스"에서 22살의 청년이 자신의 프로젝트를 발표했습니다.[3,5] 그의 이름은 John Resig. 그가 가져온 것은 "jQuery"라는 이름의 JavaScript 라이브러리였죠.
당시 웹 개발자들은 지옥을 살고 있었습니다. Internet Explorer 6, Firefox, Safari, Opera... 브라우저마다 JavaScript가 다르게 작동했어요.[1,3] 간단한 DOM 조작 하나를 위해 수십 줄의 크로스 브라우저 분기 코드를 작성해야 했습니다.
// 2005년, 요소 하나 선택하는 데 이렇게 써야 했습니다
var element;
if (document.getElementById) {
element = document.getElementById('myElement');
} else if (document.all) {
element = document.all['myElement'];
} else if (document.layers) {
element = document.layers['myElement'];
}
JavaScript
복사
John Resig은 Rochester Institute of Technology의 컴퓨터 과학과 학생이었고, 이런 상황에 질려 있었습니다.[5] "JavaScript 코드를 작성하는 건 즐거워야 한다"는 생각으로 jQuery를 만들었죠. 그의 모토는 간단했습니다: "Write Less, Do More".[3,4]
// jQuery로는 이렇게
$('#myElement').click(function() {
$(this).addClass('active');
});
JavaScript
복사
BarCamp NYC는 "관객 없이, 오직 참여자만"을 표방하는 이벤트였습니다.[5] 형식에 얽매이지 않고, 누구나 자신이 만든 것을 공유할 수 있는 자유로운 분위기. jQuery는 그런 곳에서 세상에 첫선을 보였습니다.
그리고 폭발했습니다. Digg와 Delicious 같은 당시 인기 사이트들이 첫날부터 jQuery를 다뤘습니다.[6] 웹 개발자들이 목말라 하던 것이 바로 이것이었거든요.
1막: 프레임워크 전쟁의 서막 (2006-2007)
하지만 jQuery는 혼자가 아니었습니다. 2006년, JavaScript 프레임워크는 이미 십여 개가 넘게 있었습니다.[9] Prototype.js, MooTools, YUI, Dojo... 그중에서도 특히 MooTools가 jQuery의 가장 강력한 경쟁자였습니다.
MooTools의 철학: "진짜 프로그래밍"
2005년, 이탈리아 개발자 Valerio Proietti는 Prototype용 애니메이션 라이브러리 Moo.fx를 만들었습니다.[이전 대화 참고] 하지만 Prototype의 기능에 만족하지 못해, 2006년 12월에 자신만의 프레임워크 MooTools(My Object-Oriented Tools)를 만들었죠.
MooTools의 접근은 완전히 달랐습니다. jQuery가 "빠르고 쉽게"를 추구했다면, MooTools는 "제대로, 우아하게"를 추구했습니다.[14,16]
// MooTools의 클래스 시스템 - Java처럼 보이죠?
var Animal = new Class({
initialize: function(name) {
this.name = name;
},
speak: function() {
return 'My name is ' + this.name;
}
});
var Dog = new Class({
Extends: Animal,
speak: function() {
return this.parent() + '. Woof!';
}
});
JavaScript
복사
MooTools는 JavaScript 자체를 확장했습니다. Array, String, Function에 메소드를 추가해서, JavaScript를 더 강력한 언어로 만들었죠.[14,16] 2008년경, "진지한" JavaScript 개발자들은 MooTools를 선호했습니다.[18] Robert Penner의 easing equation이 내장되어 있어 애니메이션이 더 부드러웠고, 객체지향적이고, 모듈식이었습니다.
반면 jQuery는... 뭐랄까, "디자이너용"으로 보였습니다.[19] 모든 게 $(...)나 $.something로 시작했고, JavaScript를 확장하기보다는 감싸기만 했죠. "진짜 프로그래머"들에게는 너무 단순해 보였습니다.
2007년 12월: 전쟁의 불씨
2007년 12월, LA 개발자 모임에서 MooTools 개발자 Olmo Maldonado가 발표를 했습니다.[11,12] 그리고... jQuery에 대해 염증 나는 발언들을 했죠. jQuery가 코드를 훔쳤다거나, 개발자를 신경 쓰지 않는다거나, 파일 크기만 신경 쓴다는 등.[11]
이 발표를 공식 MooTools 블로그에 올렸습니다. 큰 실수였죠.
John Resig은 즉시 응수했습니다. "I Learned Some Things About jQuery Today"(오늘 jQuery에 대해 배운 것들)라는 풍자적인 글을 올렸어요.[11]
"오늘 알게 되었는데, jQuery는 기업만 생각하고 개발자는 신경 안 쓴대요. 또 jQuery는 아직도 모뎀 쓰는 사람들만 신경 쓴대요. 배신당한 기분이네요..."
MooTools 커뮤니티는 분열했습니다. 리더 Valerio는 Olmo를 프로젝트에서 추방하고, 진심 어린 사과문을 올렸습니다.[11,12]
이 사건은 상징적이었습니다. 기술적 우월성으로는 승부가 나지 않았어요. 커뮤니티의 성숙도, 협력적인 문화가 더 중요했습니다.[12]
2막: jQuery의 압도적 승리 (2008-2010)
V8의 등장: JavaScript가 빨라지다
2008년 9월 2일, 웹 세상이 또 한 번 바뀌었습니다. Google이 Chrome 브라우저와 함께 V8 JavaScript 엔진을 공개한 것이죠.[21,22]
V8의 리더는 덴마크 프로그래머 Lars Bak이었습니다.[22,24] Google은 2006년 가을에 그를 고용했고, Lars는 덴마크 Aarhus의 자신의 농장 건물에서 팀과 함께 V8을 개발하기 시작했습니다.[22] 프로젝트 이름 "V8"은 클래식 머슬카의 강력한 엔진에서 따온 것이었죠.
당시 JavaScript는 여전히 "장난감 언어"로 취급받고 있었습니다.[28] Gmail을 로딩하는 것만으로 컴퓨터가 버벅거렸어요. 왜냐하면 당시 JavaScript 엔진들은 단순한 인터프리터였기 때문입니다. 코드 한 줄 한 줄을 그때그때 기계어로 번역했고, 최적화는 전혀 없었죠.[28,30]
V8은 완전히 다른 접근을 했습니다: JIT(Just-In-Time) 컴파일.[30] JavaScript 코드를 실행하면서 자주 실행되는 "핫" 경로를 찾아내고, 그 부분을 최적화된 기계어로 미리 컴파일해두는 것입니다.
결과는? 3배 이상의 성능 향상.[23,28] 웹 개발자들은 충격을 받았습니다. 갑자기 JavaScript가 "진짜" 애플리케이션을 만들 수 있는 언어가 된 거예요.
jQuery의 결정타: Microsoft와 Nokia
2008년, Microsoft가 발표했습니다: jQuery를 Visual Studio에 포함한다고.[4] Nokia도 자신들의 SDK에 jQuery를 넣었습니다.
이건 게임 체인저였어요.[4] 갑자기 jQuery는 "비공식 표준"이 되었습니다. 기업 개발자들도, 모바일 개발자들도 jQuery를 쓰기 시작했죠.
반면 MooTools는? 2010년경, 핵심 기여자들이 하나둘 프로젝트를 떠나기 시작했습니다.[16] 개발이 느려졌고, 커뮤니티가 침체되었습니다. jQuery가 jQuery Mobile을 출시하며 모바일 세계로 확장할 때, MooTools는 정체되어 있었죠.[16]
어느 순간, 모든 MooTools 라이브러리가 업데이트를 멈췄습니다. 아무도 MooTools로 멋진 걸 만들지 않았어요. 개발자들은 슬픈 마음으로 프로젝트를 jQuery로 재작성했습니다.[14]
한 개발자의 회고:[14]
"웹이 잘못된 선택을 했다고 생각했어요. MooTools가 분명히 jQuery보다 나았는데... 하지만 웹 커뮤니티 전체가 합의에 도달하면, 당신도 따라가야 한다는 걸 배웠습니다. MooTools를 선택한 건 제가 한 나쁜 기술 선택들의 첫 번째였죠."
왜 jQuery가 이겼나?
기술적으로, MooTools가 더 우아했을 수도 있습니다. 하지만:[16]
1.
jQuery는 절대 포기하지 않았습니다. 커뮤니티가 계속 성장했고, 업데이트가 멈추지 않았어요.
2.
플러그인 생태계가 폭발했습니다. Carousel, datepicker, validation... 원하는 모든 게 이미 jQuery 플러그인으로 있었죠.[17]
3.
배우기 쉬웠습니다. 디자이너들도 쉽게 배울 수 있었어요. "진짜 프로그래밍"을 할 필요가 없었습니다.[19]
4.
문서화.[5] jQuery는 처음부터 문서화에 신경 썼습니다. 다른 라이브러리들이 "소스 코드를 보라"고 할 때, jQuery는 자세한 문서를 제공했죠. John Resig의 첫 고용은 심지어 커뮤니티 매니저였습니다!
2010년경, jQuery는 완전히 승리했습니다. 거의 모든 웹사이트가 jQuery를 사용했죠.[3]
3막: 승리의 대가 - 스파게티의 시대 (2008-2010)
하지만 승리에는 대가가 따랐습니다. jQuery는 너무 쉬웠어요. 그래서 개발자들은 구조 없이 코드를 마구 작성했습니다.
// 2009년의 전형적인 jQuery 코드
$(document).ready(function() {
$('#button1').click(function() {
$.ajax({
url: '/api/data',
success: function(data) {
$('#result').html(data);
$('#button2').click(function() {
$.ajax({
url: '/api/more',
success: function(moreData) {
$('#more').html(moreData);
// 그리고 또 ajax... 그리고 또... 끝없는 콜백 지옥
}
});
});
}
});
});
// 100줄 더...
// 200줄 더...
// 모든 로직이 document.ready 안에!
});
JavaScript
복사
이게 **"콜백 지옥"**의 시작이었습니다. 그리고 더 심각한 문제가 있었어요.
4막: 클라이언트 렌더링의 환상
V8이 JavaScript를 빠르게 만들었습니다. jQuery가 DOM 조작을 쉽게 만들었죠. 그래서 2008-2010년, 개발자들은 생각하기 시작했습니다:
"이제 JavaScript가 충분히 빠른데... 서버에서 HTML 만들 필요가 있을까? 그냥 서버는 **데이터(JSON)**만 주고, HTML은 클라이언트에서 만들면 안 될까?"
이것이 바로 **Single Page Application(SPA)**의 씨앗이었습니다.
// 2009년, 새로운 패턴이 등장하기 시작했습니다
$.getJSON('/api/posts', function(posts) {
var html = '<ul>';
posts.forEach(function(post) {
html += '<li>' + post.title + '</li>';
});
html += '</ul>';
$('#posts').html(html);
});
JavaScript
복사
여기서 중요한 것을 봐야 합니다. 서버는 더 이상 HTML을 보내지 않았습니다. JSON만 보냈어요. 그리고 클라이언트에서 HTML을 만들었습니다.
이게... SSR의 종말일까요?
에필로그: 환상의 끝
아니었습니다. 곧 문제가 드러나기 시작했으니까요.
첫 번째 문제: 초기 로딩 지연. 사용자가 웹사이트를 방문하면:
1.
빈 HTML 다운로드 (1초)
2.
jQuery 다운로드 (2초)
3.
애플리케이션 JavaScript 다운로드 (3초)
4.
JSON 데이터 요청 (4초)
5.
HTML 생성 및 렌더링 (5초)
5초 동안 사용자는 빈 화면을 봐야 했습니다.
두 번째 문제: SEO의 재앙. Google 크롤러는 JavaScript를 실행하지 않았습니다. 그래서 빈 페이지만 보였죠. 검색 엔진에서 완전히 사라졌습니다.
세 번째 문제: 모바일 성능. 2007년 iPhone이 나왔습니다. 하지만 모바일 기기는 느렸어요. JavaScript를 실행하는 데 너무 오래 걸렸습니다.
그래서 개발자들은 깨달았습니다:
"음... 그냥 처음에는 서버에서 HTML을 보내고, 그다음부터는 클라이언트에서 업데이트하면 안 될까?"
맞습니다. 여전히 SSR이 필요했어요. 단지 부분적(partial) SSR일 뿐이었죠. 첫 페이지는 서버에서, 나머지는 클라이언트에서.
하지만 이걸 어떻게 구현할 것인가? jQuery 시대의 도구들로는 너무 복잡했습니다.
다음 장 예고:
2011년, Airbnb의 한 엔지니어가 모바일 웹의 끔찍한 성능을 보며 생각했습니다. "같은 코드를 서버와 클라이언트 양쪽에서 실행하면 안 될까?"
그리고 Ryan Dahl이 만든 어떤 도구가 이를 가능하게 만들었죠.
2009년, Node.js가 등장합니다.
참고 문헌 (작성 중):
[1] John Resig (2016), "10th Anniversary of jQuery"
[3] LogRocket Blog (2024), "The history and legacy of jQuery"
[4] TutsInsider (2025), "jQuery History and Version Timeline"
[5] Pamela Gutierrez (2021), "jQuery Saves the Day: A History"
[6] Coderwall (2017), "History of jQuery"
[9] jQuery Blog (2016), "Ten Years of jQuery and Beyond"
[11] John Resig (2007), "I Learned Some Things About jQuery Today"
[12] David Walsh (2007), "When JavaScript Frameworks Collide"
[14] chanind.github.io (2020), "...and I still think Mootools is better than jQuery"
[16] The History of the Web (2023), "That Time MooTools Almost Broke the Web"
[17-20] Various forum discussions and comparisons
[21-30] V8 engine history sources from Google, Wikipedia, Medium, etc.
