이제와서 jQuery를 쓰면 안되는 이유, 혹은 jQuery와 웹개발의 역사

TL;DR

jQuery는 DOM을 직접 다루는 기능이 너무 많기 때문에 안티패턴의 위험이 높다. jQuery를 쓰는 것자체가 나쁜 건 아니지만 좋은 개발을 위해선 위험한 기능은 쓰지 않도록 강제해야 한다.

올해로 jQuery가 나온지 10년이 되었습니다. 나올때부터 인기있던 jQuery지만 현재도 탑 밀리언 사이트 내의 이용율이 78%나 될 정도로 시장을 평정하고 있는 것은 놀라운 일입니다. 이런 인기의 비결은 무엇일까요? 작년 5월 jQuery 창시자인 존 레식은 트위터에서 이렇게 이야기했습니다.

이런 말 하는게 슬프지만 jQuery가 javascript를 대체하지는 않는다.  jQuery가 성공한 것은 DOM이 문제가 많다는 증거일 뿐이다. 원문 링크

프론트엔드 개발의 현재 상황에 대한 상당히 의미심장한 이야기이죠. 이 말의 의미를 제대로 이해하기 위해서 10년도 더 된 고릿적 이야기를 한 번 꺼내보겠습니다.

1990년대 웹개발에는 javascript가 나설 자리가 없었습니다. javascript의 기능자체도 별게 없었지만, 깔끔하게 정리된 문서도 없었고, 시장을 양분하고 있던 Netscape과 IE의 DOM구조가 완전히 달랐기 때문에 하나의 기능을 위해서 두번의 스크립트 개발이 필요했습니다. 이런 사정이 나아진 것은 Netscape가 완전히 망가진 2003년도 전후로 Windows XP와 IE6가 세상을 통일하기 시작하면서부터였습니다. 성능 좋은 브라우저가 시장을 독점하니 암흑의 시기가 끝나고 드디어 스크립트의 전성기가 열렸습니다. 2004년 말에 AJAX기능을 위시한 Web 2.0의 논의가 시작된 것도 그런 흐름 때문이였습니다.

Web 2.0의 유행을 타고 2005년 전후로 다양한 javascript 프레임웍이 출현했습니다. prototype, script.aculo.us, dojo등등.. 당시의 프레임웍은 DOM을 확장하고,  prototype을 이용해 타 언어의 class를 흉내내려하는 경우가 많았습니다. 그러한 방식은 자바스크립트를 좀 더 자바처럼 보이게 해주었습니다. 지금은 잘 이해가 안가겠지만 그땐 그게 쿨했습니다.

한편 Netscape의 후신인 파이어폭스가 2004년 말에 출시되었습니다. 휴식기간이 길었음에도 MS가 열심히 삽질을 해준 덕분에 파이어폭스의 기능과 성능은 IE를 월등히 뛰어넘었고 사용자들은 열광했습니다. MS입장에서 보자면 삽질할 만한 어쩔수 없는 이유가 있었지만, 그 덕분에 브라우저 시장의 유일한 지배자가 될 기회를 영원히 놓치고 말았습니다. 덕분에 다시 혼돈의 카오스가 열리게 됩니다.

2006년에 파이어폭스의 애드온으로 등장한 firebug덕분에 프론트엔드 개발은 정말이지 거대한 패러다임의 변화를 맞이했습니다. 과거에는 코드 내에 document.write나 alert를 넣는 매우 원시적인 방식으로 디버깅을 했었는데, firebug의 등장으로 한번에 상황이 바뀌게 되었습니다.(무려 console.log라니!) 덕분에 마이너했던 파이어폭스가 사이트 개발 할 때는 메인 브라우저가 되었고, IE는 출시전 테스트 단계에서만 쓰이는 찬밥 신세가 되었습니다. 그러면서 자연스럽게 웹표준을 준수하는 브라우저와 IE의 괴리가 문제가 되기 시작했습니다.

IE와 파폭은 DOM 구조가 달랐고, 기존의 프레임웍으로는 모듈화 하기가 쉽지 않았습니다. 하나의 브라우저가 시장을 지배하는 구조가 끝났기 때문에 다양한 문제가 파생했습니다. IE6가 만들었던 2003~2005년의 짧은 평화는 깨졌습니다. 이런 시대적 배경 속에 드디어 jQuery가 등장합니다. DOM을 추상화해서 관리해 주는데다, 깔끔한 플러그인 방식을 지원했기 때문에 jQuery는 나오자마자 선풍적인 인기를 끌었습니다.

2006년에 프론트엔드의 혁명이 시작되었다면, 2007년은  jQuery, 파이어폭스, Firebug가 적극적으로 시장을 넓혀가는 와중에 IE7이 삽질하고 있는 상황으로 요약할 수 있겠습니다. 2008년부터는 애플의 사파리와 구글의 크롬이 등장하면서 본격적인 브라우저 춘추전국시대로 돌입합니다. 그리고 그 즈음 iPhone으로 인해 모바일의 시대가 열리고 브라우저 파편화는 더욱 가속화 되어 현재까지 이어집니다. 2000년대 후반 jQuery가 지원하는 브라우저는 Nightly Build버전을 포함해서 11개 였는데, 요즘은 최소 30여개 이상입니다.

이렇게 생각할수도 있겠습니다. 브라우저가 파편화되더라도 표준만 제대로 지키면 문제없지 않겠느냐고요. 네, 이론적으로는 그렇습니다만 새로운 브라우저는 예외없이 새로운 문제를 만들었습니다. 이런 상황에서 jQuery가 업계 표준이 된 것은 당연합니다. 물론 jQuery만으로 모든 cross-browser문제가 해결 되는 것은 아니지만 jQuery없이 개발하는 건 상상하기 힘든 일입니다.

처음으로 돌아가서 존 레식의 이야기는 이런 의미입니다. 요즘 사람들은 브라우저의 파편화가 보편화된 시대에 살고 있고, DOM이 제대로 동작한다는 것을 믿을 수 없기 때문에 일상적으로 jQuery를 씁니다. jQuery의 개발 방법론이 좋아서가 아니구요. 이미 시대는 jQuery의 패러다임을 뛰어 넘었습니다. Babel을 통해 ES6가 현실화 되었고, MVC패턴과 two-way binding이 일상화 되었고, node.js로 서버도 만들고, 심지어 atom에디터같은 데스크탑 어플도 만들수 있는 시대가 되었습니다.

그런데 시대가 바뀌었음에도 jQuery만 하면 자바스크립트를 왠만큼 하는 것 처럼 생각하시는 분들이 많이 있습니다. 이미 jQuery가 제공하는 개발 방법론은 낡았는데 그대로 쓰시는 분들이 너무 많습니다. 예를 들면 .closest()같은게 대표적입니다. 박스를 만들고 그 중에 하나를 클릭하면 상위 엘리먼트에 클래스를 지정하는 경우를 가정해 봅시다.

<div class="box">
<ul>
  <li><a href="#dog" class="item">Dog</a></li>
  ...
</ul>
</div>

li를 클릭하면 상위 div에 class를 추가하는 스크립트를 .closest()를 이용해서 만들어 봅니다. 박스가 한 페이지에 여러 개 들어갈수도 있으니 each를 써서 이벤트를 지정해야합니다.

$("div.box").each(function(){
  var $items = $(this).find("li a.item");
  $items.on("click", function(e){
    var $this = $(this);
    $this.closest("div").removeClass().addClass($this.text().toLowerCase());
  });
})

여기서부터 문제가 생깁니다. javascript 코드에.closest(“div”)가 갑툭튀하는데, 이것만 봐서는 무슨 의미인지 알수가 없습니다. 실제로 html태그를 확인해야 하는데, 그러기위해선 크롬 디버그 창을 열고 해당 엘리먼트를 선택한 후 Source화면에서 하나씩 위로 올라가봐야 합니다.

스크립트 개발이 다 끝나고 나니, 애니메이션을 위해 여분의 div를 넣자는 의견이 나옵니다.

<div class="box">
<ul>
  <li><div class="anim"><a href="#dog" class="item">Dog</a></div></li>
  ...
</ul>
</div>

이렇게 되면 javascript는 전혀 건드리지 않고 html만 수정했는데, 프로그램이 동작하지 않습니다. jQuery가 DOM을 다루는데 스페셜리스트인 것은 좋은데, 이런 기능은 View와 Controller를 연동시키기때문에 안티 MVC패턴을 만듭니다. 역사가 10년이나 된 jQuery에는 안타깝게도 이런 식의 DOM을 다루는 스페셜한 기능이 너무나 많습니다. 그리고 이런 기능을 사용한 후에 자기는 jQuery 좀 할 줄 안다고 어깨를 으쓱대는 사람들도 많습니다.

※참고로 위의 코드는 이런 식으로 재작성이 가능합니다.

$("div.box").each(function(){
  var $box = $(this);
  $box.find("li a.item").on("click", function(e){
    $box.removeClass().addClass(this.href.replace(/.*#/, ""));
  });
})

2016년이 되면서 IE 10이하의 브라우저의 대응이 끝났습니다. 현장에서는 IE8이 대응리스트에서 사라지고 있는 중이고, 당장 저부터 다음 프로젝트에는 대응할 생각이 없습니다. 게다가 IE11을 제외한 모든 브라우저가 에버그린 업데이트를 지원하기 시작했기때문에 브라우저 파편화 문제는 많이 해결되는 추세입니다. 올해 말이면 더욱 더 좋아져 있겠죠.  jQuery가 단기간에 대체되지는 않겠지만, 앞으로는 점점 jQuery에 의존할 필요가 없어질 것입니다.

앞으로는 부작용없이 최소한의 기능만을 빌린 jqLite, bliss.js, u.js 등을 이용한 개발이나, ES6 스타일로 개발하는 것도 유망해 질 듯합니다. 복잡다단했던 웹 업계에 jQuery중독에서 벗어날 시기가 찾아온 것입니다.

P.S. 방문하시는 분들이 많아서 2부를 작성해봤습니다.

이제와서 jQuery를 쓰면 안되는 이유 part 2