매개체로서의 jQuery(1)

문서 옵션 PDF - Fits A4 and Letter 479KB (16 pages) Get Adobe® Reader® JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 영어원문  제안 및 의견 피드백

난이도 : 중급

Michael Abernethy, Product Development Manager, Optimal Auctions

원문 게재일 : 2009 년 6 월 16 일
번역 게재일 : 2009 년 8 월 04 일

jQuery는 우수한 JavaScript 라이브러리입니다. 그렇다면 과연 그 성능은 어떻겠습니까? 웹 페이지의 사용 편의성과 성능 사이에는 상충 관계가 있기에 사용 편의성이 좋으면 성능이 좋을 수 없다는 말에 동의하십니까? 이 기사에서는 jQuery 성능에 대한 의문 사항을 풀어주고 애플리케이션에서 jQuery의 성능을 향상시키는 데 도움이 되는 몇 가지 팁을 설명합니다.

소개

이 기사는 이전 기사에 대한 피드백 이메일을 받고서 쓰게 되었다. 그 이메일에는 "간단한 페이지에서는 jQuery가 좋지만 복잡한 페이지에서는 성능이 아주 나쁘기에 성능 문제가 해결되기 전까지는 복잡한 페이지에 JavaScript를 사용해야 한다"라는 의견이 있었다. 이 이메일을 받은 후 필자는 그 즉시 "jQuery와 JavaScript의 성능을 어떻게 비교할까?"라는 의문이 들었다. 실제로 필자는 jQuery 라이브러리의 성능을 JavaScript 또는 다른 JavaScript 라이브러리의 성능과 비교한 기사를 거의 보지 못했다. 대부분의 사람들처럼 필자도 jQuery를 사용해서 클라이언트측 코딩을 얼마나 쉽게 할 수 있는지에 대한 내용만을 보고 성능에 관한 부분을 간과했었던 것이다. 필자는 분명 상충 관계의 의미를 인정한다. 하지만 그 상충 관계가 고려할만한 것일까? jQuery가 "일반" JavaScript보다 느릴까? 그리고 jQuery가 다른 라이브러리보다 느릴까? 이 기사에서는 이러한 질문에 대한 답을 찾아볼 것이다.

JavaScript 성능을 측정할 때 고려할 사항 중 가장 중요한 것은 실행 환경이다. 코드가 클라이언트에서 실행되므로 클라이언트의 컴퓨터가 성능의 가장 중요한 요소이다. 오래된 400MHz 프로세서 컴퓨터보다는 쿼드 코어를 실행하는 최신 서버에서 코드가 빠르게 실행된다는 점은 분명하므로 따로 언급할 필요가 없을 것이다. 하지만 사이트를 방문할 때 사용하게 되는 웹 애플리케이션 사용자의 시스템을 개발자가 제어할 수는 없기 때문에 성능을 측정할 때 굳이 하드웨어를 고려할 이유도 별로 없다.

초보 JavaScript 개발자의 경우 잘 모를 수도 있겠지만 JavaScript 성능과 관련하여 또 하나 고려할 사항은 JavaScript를 실행하는 데 사용되는 브라우저가 매우 중요한 요소라는 것이다. 모든 브라우저의 "화면 아래"에는 JavaScript 엔진이 있다. 이 엔진은 개발자가 작성한 JavaScript를 해석 및 실행하고 웹 애플리케이션의 페이지에 대한 작업을 수행하는 기본 코드이다. 따라서 클라이언트에서 사용되는 브라우저에 따라 성능이 크게 좌우되며 어떤 경우에는 사용자가 사용하는 브라우저를 개발자가 제어할 수도 있다. 이 기사에서는 JavaScript 성능에 대한 몇 가지 지침을 설명한 후 다양한 브라우저에서 실행되는 JavaScript의 차이점을 살펴본다.

마지막으로 필자는 JavaScript 및 특히, jQuery의 성능에 대한 몇 가지 결론을 내린 후 속도가 느려지는 원인을 피하면서 속도를 높일 수 있는 효과적인 방법을 활용하여 jQuery 코드의 성능을 향상시킬 수 있는 몇 가지 베스트 프랙티스를 정의한다. 이 기사를 읽고 나면 "jQuery의 성능이 좋을까?"라는 질문에 대한 답을 얻게 될 것이며 위에서 소개한 이메일을 보낸 독자도 자신의 의견이 어떻게 반영되었는지 알게 될 것이다.

성능 테스트 작성하기

성능 테스트의 첫 번째 단계는 적합한 성능 테스트를 작성하는 것이다. jQuery 및 JavaScript 라이브러리가 코드에서 수행하는 가장 중요한 역할 중 하나는 선택 메소드를 사용하여 특정 페이지 요소를 찾는 것이다. 이 기사의 첫 번째 성능 테스트에서는 이 특징을 사용한다. 좋은 성능 테스트가 되기 위해서는 JavaScript 라이브러리를 실제 환경 즉, 수천 개에 달하는 다양한 유형의 요소로 구성된 페이지에 대해 테스트해야 한다. 이러한 테스트를 통해 모든 선택 메소드를 실행해 보면 빠른 선택 메소드와 느린 메소드를 찾아낼 수 있다. 올바른 정답을 미리 알고 있으므로 JavaScript 라이브러리가 선택 메소드를 올바르게 실행했는지 여부도 판별할 수 있다. 마지막으로 모든 결과에는 실행 시간이 함께 제공되므로 모든 라이브러리의 결과를 쉽게 비교할 수 있다.

그리고 이 성능 테스트의 가장 중요한 특징이 한 가지 더 있다. 그것은 바로 이 테스트를 무료로 사용할 수 있다는 것이다. 이 시리즈의 기저에는 자신의 성과물을 무료로 제공하는 동시에 다른 개발자의 우수한 성과물을 활용한다는 공감대가 흐르고 있다. 따라서 필자는 이 기사에서도 이미 작성된 JavaScript 라이브러리 성능 테스트를 활용함으로써 이 공감대를 계속 유지할 것이다. 이 테스트의 이름은 SlickSpeed Selectors Test(참고자료 참조)이며 필자에게 필요한 기능을 모두 제공하고 있다. 이 테스트는 jQuery 1.2.6(이 기사를 집필하던 당시의 최신 버전)과 다른 4가지 유명한 JavaScript 라이브러리(MooTools, Prototype, YUI 및 Dojo)를 비교한다. 그런 다음 수천 개의 요소로 구성된 페이지에 대해 40가지의 선택 테스트를 실행한다. 즉, 이 테스트는 필자가 찾고 있던 완벽한 성능 테스트이다. 필자는 이 테스트를 첫 번째 성능 테스트 분석에 사용할 것이다.

JavaScript 라이브러리의 성능 비교하기

이 첫 번째 성능 테스트는 2.2GHz 프로세서, 2GB RAM 및 Firefox 3.0.3(가장 중요한 요소)이 갖춰진 시스템에서 실행한다. 이러한 설정 하에서 테스트를 5회 실행했으며 그림 1에서는 5회에 걸친 테스트의 평균 결과를 보여 준다.

이 초기 테스트에서 어떤 결론을 얻을 수 있을까? 여기에서는 테스트에서 실행된 개별 테스트의 결과보다는 전반적인 결과만을 살펴보자. 개별 테스트에 대해서는 몇 가지 대략적인 결론을 내린 후에 다룬다.

• 결론 1: YUI가 실제로 느리다.
  그렇다. 다른 라이브러리에 비해 YUI가 특히 느린 결과를 보여 주었다. 이유를 찾기 위해 개별 테스트를 살펴보면 이 라이브러리의 경우 요소 그룹(예: "p, a")을 선택하는 기능이 매우 취약하다는 것을 알 수 있다. 따라서 성능이 중요한 복잡한 페이지에서는 이 라이브러리를 선택하지 않는 것이 좋다.
• 결론 2: Mootools, jQuery 및 Dojo는 거의 비슷한 수준이다.
  이들 세 라이브러리는 모두 다른 두 라이브러리에 비해 상당히 빠른 편이다. 그 중에서도 Dojo가 가장 빨랐으며 jQuery가 가장 느린 결과를 보여 주었다. 하지만 전체적으로 고려했을 때 세 라이브러리 모두 거의 비슷한 속도를 보여 주었다.
• 결론 3: 라이브러리 간의 상대적 차이점이 중요하다.
  가장 느린 시간과 가장 빠른 시간의 비율을 계산하여 상대적인 속도 차이를 구해 보면 332%까지도 차이가 난다는 것을 알 수 있다. 이 점을 중요하게 생각해야 한다. 선택한 JavaScript 라이브러리에 따라 Firefox 브라우저에서 얻을 수 있는 성능이 확연히 달라질 수 있기 때문이다.

하지만 이러한 결론은 하나의 브라우저에서만 실행한 결과를 토대로 하고 있다는 점을 간과해서는 안된다. Firefox 3.0.3에서 테스트를 실행하여 결론을 얻었으므로 다음 섹션에서는 다양한 브라우저에서 이 테스트를 실행해 보자.

다양한 브라우저에서 실행한 JavaScript의 성능

많은 초보 웹 프로그래머들은 각 브라우저에서 JavaScript가 서로 다른 방식으로 실행될 뿐만 아니라 실행 시간도 다르고 결과도 다르다는 사실에 놀라기도 한다. 이러한 현상이 초보자에게 혼동을 주어 다양한 브라우저를 처리하는 정확한 코드를 작성해야 하는 초보자에게 좌절감을 심어줄 수도 있겠지만 숙련된 웹 프로그래머들은 Netscape와 Internet Explorer가 등장했던 초기부터 이 문제에 적응되어 있다. 또한 JavaScript 라이브러리에서는 대부분의 브라우저 차이점을 처리해야 하기 때문에 이 문제는 JavaScript 라이브러리 작업에서 중요하게 고려해야 하는 핵심 사항 중 하나이다.

JavaScript의 속도가 다르게 나타나는 핵심 이유는 브라우저마다 고유한 JavaScript 엔진을 사용하고 있기 때문이다. 이 엔진은 JavaScript를 해석하여 웹 애플리케이션에 대해 실행하는 기본 코드이다. 따라서 JavaScript의 실행 속도는 기본 엔진의 영향을 직접적으로 받게 된다. 달리 말하자면 엔진을 개발할 때 성능 향상을 위한 노력이 얼마나 들었는지에 따라 실행 속도가 결정되는 것이다. 지난 수 개월 동안 자사의 JavaScript 엔진 성능과 장점을 알리는 브라우저 회사가 매우 많았었다. 특정 페이지에서 JavaScript의 복잡도가 높아지고 있기 때문에 JavaScript 엔진의 속도에 따라 웹 페이지의 응답성 및 속도에서도 차이가 발생할 수 있다. 그리고 Google 및 Firefox와 같은 회사에서는 자사의 JavaScript 엔진을 소개하면서 차세대 엔진은 현재보다 10배 빨라질 것이기에 기반이 되는 JavaScript 엔진의 속도가 더욱 복잡해진 웹 애플리케이션의 성장을 직접 이끌게 될 것이라고 이야기하고 있다.

지금까지 JavaScript 엔진이 JavaScript 실행 속도를 결정하는 주요 요소라는 점을 살펴보았다. 이제 Firefox에서 실행했던 것과 동일한 테스트를 여러 다른 브라우저에서 실행하여 엔진의 차이가 JavaScript 성능에 미치는 영향을 계량화해 보자. 물론 이 테스트는 동일한 시스템의 Firefox에서 실행했던 것과 동일한 테스트이다. 즉, 다른 모든 조건이 동일한 상태에서 JavaScript 엔진만 다를 뿐이다. 그림 2에서는 테스트 결과를 보여 준다.

이러한 결과를 살펴볼 때 가장 먼저 확인할 부분은 브라우저별로 시간 범위가 매우 넓다는 점이다. 일단 jQuery만 보면, Chrome 1.0에서는 jQuery 테스트가 168ms에 완료되었지만 IE6에서는 1728ms가 걸렸다. 상당히 큰 시간 차이가 나는 것을 알 수 있다. jQuery를 선택한다면 Chrome에서 실행할 때보다 IE6에서 실행할 때 10배 이상의 시간이 걸릴 수 있다. 이러한 결과를 보면 Google에서 자사 JavaScript 엔진의 속도를 자랑하는 이유뿐만 아니라 일부 브라우저의 JavaScript 엔진에 대한 언급이 별로 없는 이유까지도 알 수 있을 것이다. 이 차이점이 매우 중요하다.

또 한 가지 살펴볼 사항은 Firefox에서 3번째로 빠른 속도를 보여 주었던 jQuery가 일부 브라우저에서 가장 빠르게 실행되었고 나머지 브라우저에서도 3번째로 빠르게 실행되었다는 점이다. 실제로 이러한 결과를 자세히 보면 브라우저에 상관 없이 모든 라이브러리는 성능 관점에서 두 그룹으로 분류된다. Mootools, Dojo 및 jQuery가 항상 같은 그룹을 형성하면서 Prototype 및 YUI를 비롯한 다른 그룹에 비해 상당히 빠른 성능을 보여 주고 있다.

성능 테스트 결론

이러한 결론은 JavaScript 개발자에게 매우 중요하기 때문에 결론별로 하나의 섹션을 할애하여 다룰만한 주제이다. 이 기사가 jQuery에 관한 기사이기는 하지만 필자는 이에 얽매이지 않고 위 성능 결과를 토대로 결론을 도출할 것이다.

결론 1: Mootools, jQuery, Dojo는 비슷한 수준에서 상당히 좋은 성능을 제공한다.
5가지 브라우저에 대한 결과를 모두 표준화하면 이들 세 라이브러리의 성능이 거의 동일하다는 것을 알 수 있다. (각 브라우저의 시장 점유율에 따라 가중치를 두고 표준화하는 방법이 이상적이겠지만 JavaScript 라이브러리를 사용하려는 사이트가 "평균 사용자"가 방문하는 사이트가 아니기 때문에 이들 숫자를 조정했다.)

결론 2: Prototype와 YUI는 속도가 매우 느리다.
이들 두 라이브러리의 표준화된 결과와 5가지 브라우저 중 jQuery의 표준화된 결과를 비교해 보면 성능 차이가 꽤 크다는 것을 알 수 있다. 평균적으로 이 두 라이브러리는 브라우저에서 jQuery에 비해 300% 느리게 실행된다.

결론 3: 성능이 중요하다면 Mootools, jQuery 및 Dojo 중 하나를 선택한다.
위 표준화된 결과를 보면 이들 세 라이브러리 중 어느 라이브러리를 선택하더라도 비슷한 성능을 얻을 수 있다. 모든 브라우저를 고려한다면 이들 세 라이브러리 모두 좋은 성능을 제공한다. 따라서 JavaScript 라이브러리를 선택할 때 이러한 세 라이브러리 중 하나를 선택하면 좋은 결과를 얻을 수 있을 것이다.

결론 4: 성능이 중요하다면 Prototype이나 YUI를 선택하면 안된다.
JavaScript 라이브러리를 사용할 때 성능이 중요한 고려 사항이거나 대규모 JavaScript 프로젝트를 작성할 계획이라면 이들 두 라이브러리를 선택하지 않아야 한다. 이들 라이브러리를 선택해서 얻을 수 있는 성능은 다른 라이브러리를 선택했을 때와 비교하면 상당히 낮다.

결론 5: 선택한 JavaScript 라이브러리보다 브라우저의 중요성이 훨씬 더 높다.
필자의 견해로는 이 결론이 가장 중요하다. 특정 상황에서 가장 빠른 JavaScript 라이브러리가 무엇인가에 대한 논쟁이 있을 수도 있겠지만 그렇다고 하더라도 이는 큰 문제가 되지 않는다. 왜냐하면 속도 및 성능 관점에서는 실제 라이브러리보다는 브라우저가 훨씬 더 중요한 요소이기 때문이다. 그림 3과 4의 표준화된 결과를 보면 '빠른' 세 라이러브리 중 가장 느린 라이브러리(Dojo)와 가장 빠른 라이브러리(jQuery)의 속도 차이가 15%에 불과하다는 것을 알 수 있다. 겨우 15%만 느릴 뿐이다. 하지만 가장 빠른 브라우저(Chrome 1.0)와 가장 느린 브라우저(IE 6)에서 jQuery를 실행한 결과를 보면 1000% 차이가 난다는 것을 알 수 있다. 1000%에 비해 15%라는 차이는 정말 사소한 차이에 불과하다. 이처럼 브라우저의 중요성이 크기 때문에 이들 세 라이브러리 중 어느 라이브러리가 가장 빠른가에 대한 논쟁은 더 이상 의미가 없으므로 여기에서 멈춰야 한다.

결론 6: JavaScript 성능이 웹 애플리케이션에 중요하고 사용자의 브라우저를 제어할 수 있다면 그렇게 해야 한다.
일부 웹 애플리케이션과 특정 상황에서는 사이트를 방문할 때 사용되는 브라우저를 제어할 수 있다. 그런 환경에 있다면 운이 좋은 편이다. 다행히도 필자는 그처럼 운이 좋은 프로젝트에 참여하고 있다. 이 상황에서 복잡한 JavaScript 애플리케이션이 있거나 성능이 중요한 고려 사항이라면 웹 애플리케이션에 방문하는 사용자의 브라우저를 제어하는 것이 좋다. 이러한 테스트의 결과는 명확해야 한다. JavaScript 애플리케이션이 복잡하고 사용자에게 Chrome을 사용해야 한다고 알릴 수 있다면 그 기회를 놓칠 필요는 없을 것이다.

결론 7: 사용자의 브라우저를 제어할 수 없다면 IE6에서의 성능을 고려한다.
이와는 반대로 우리 대부분은 사이트에 방문하는 사용자의 브라우저를 제어할 수 없는 환경에 살고 있다. 아쉽게도 아직까지는 많은 사용자가 IE 6을 사용하여 인터넷 탐색을 즐기고 있다. 이 기사의 테스트에서 보았던 것처럼 이 브라우저의 JavaScript 엔진은 테스트 대상 브라우저 중에서 가장 느리다. 하지만 아직까지도 많은 사용자가 IE 6을 사용하고 있고 "최소 공통 분모를 고려한 설계"가 좋은 웹 설계이므로 IE 6을 고려하여 모든 JavaScript 애플리케이션을 설계해야 한다.

'매개체로서의 jQuery(2)'보기

참고자료

• 전체 jQuery API Page에서 라이브러리의 모든 함수를 볼 수 있다.
  
  
• Release Notes for 1.3에서 최신 릴리스의 변경 및 개선 사항을 모두 볼 수 있다.
  
  
• SlickSpeed 테스트를 실행하여 결과를 직접 확인해 보자.
  
  
• 25 jQuery performance tips에서는 이 기사에서 설명한 세 가지 주요 팁 외에 성능에 대한 다른 여러 가지 팁도 볼 수 있다.
  
  
• W3Schools에서 CSS, JavaScript 및 기타 웹 언어에 대한 자세한 정보를 볼 수 있다.
  
  
• 다음은 jQuery 라이브러리에 대해 소개하고 있는 필자의 jQuery 시리즈 중 처음 세 편의 기사이다.
  • "jQuery로 작업하기, Part 1: 브라우저로 데스크톱 응용 옮기기"(developerWorks, 2008년 9월)
  • "jQuery로 작업하기, Part 2: 내일 나올 웹 응용을 오늘 구현해보자"(developerWorks, 2008년 9월)
  • "jQuery로 작업하기, 3부: jQuery와 Ajax로 RIA 만들기: JQuery: 내일 나올 웹 응용을 오늘 구현해보자"(developerWorks, 2008년 10월)
  
  

• 이 기사를 집필하던 시점에 가장 안정적인 버전이었던 1.3.2 Minimized jQuery를 다운로드하여 사용자의 코드에 추가할 수 있다.
  
  

필자소개

		10년에 걸친 기술 경험을 통해 Michael Abernethy는 광범위한 기술을 토대로 광범위한 클라이언트와 작업해 왔다. 현재 경매 소프트웨어 회사인 Optimal Auctions에서 제품 개발 관리자로 일하고 있다. Abernethy는 요즘 RIA(Rich Internet Applications)에 초점을 맞춰 복잡함과 단순함을 동시에 추구하고 있다. 컴퓨터 앞에 앉아 있지 않을 때는 양서를 끼고 멕시코 해변가에서 여유를 즐긴다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

이 문서 북마킹 하기 mar.gar.in naver eolin del.icio.us

위로