1996년 자바스크립트가 넷스케이프 내비게이터와 함께 처음 소개되었을 때 성능은 그다지 중요하지 않았습니다. 인터넷은 초기 단계였고 항상 느렸습니다. 성능이 좋지 않은 가정용 컴퓨터에서 다이얼 업 네트워킹으로 접속하던 그 당시의 웹 서핑은 인내심을 기르는 훈련 같을 때가 많았습니다. 사용자는 웹 페이지가 로드될 때까지 기다리는 것을 당연하게 생각했고 페이지가 잘 로드되면 기꺼이 축배라도 들 기분이었습니다.
자바스크립트의 원래 목적은 웹 페이지에서 폼 입력 오류 등으로 인한 사용자의 시간 낭비를 줄이는 것이었습니다. 폼에 입력된 값이 유효한지 검사하는 등의 간단한 작업을 위해 서버까지 갔다가 돌아오는 대신 이러한 기능을 자바스크립트가 페이지에서 직접 수행했습니다. 이렇게 해서 서버까지 왕복하는 시간을 줄일 수 있었습니다. 입력할 내용이 많은 폼을 다 작성하고, 서버로 전송하고, 1분 가까이 기다렸더니 필드 하나를 잘못 입력했다는 응답을 받은 기분을 상상해 보세요. 자바스크립트는 이러한 부분에서 초기 인터넷 사용자의 시간을 많이 줄여준 공로를 인정받아야 합니다.

인터넷은 진화했습니다
십 년 동안 컴퓨터와 인터넷은 진화를 거듭했고, 둘 다 무척 빨라졌습니다. 프로세서의 성능은 급격하게 좋아졌고 메모리 가격은 낮아졌으며 광섬유 연결이 등장해 인터넷은 새로운 시대로 진입했습니다. 그때까지는 볼 수 없었던 빠른 연결이 일반화되어 웹 페이지에 더 많은 정보와 멀티미디어 파일을 담으면서 무거워졌습니다. 문서만 링크하던 밋밋한 웹 페이지에 다양한 디자인과 인터페이스를 담게 되었습니다. 모든 것이 변했지만 자바스크립트만 예전 그대로입니다.
서버까지의 왕복을 줄이는 용도로 쓰이던 자바스크립트가 어디에든 쓰이게 되었습니다. 예전에는 수십 줄이면 충분했던 코드가 이제는 수백 줄을 넘어서 수천 줄이 되었습니다. 페이지를 다시 불러오지 않아도 페이지의 모양을 바꿀 수 있는 DHTML과 인터넷 익스플로러 4의 등장으로 자바스크립트의 비대화는 예견된 것이었습니다. 브라우저 발전에서 가장 중요한 단계는 인터넷 익스플로러 5, 넷스케이프 내비게이터 6, 오페라에서 제각기 구현한 DHTML에 대한 통일안인 DOM(Document Object Model: 문서 객체 모델)의 등장입니다. DOM이 도입된 직후 ECMA-262 3판에서 자바스크립트의 표준화가 이루어졌습니다. 모든 브라우저가 DOM을 지원하고 같은 버전의 자바스크립트를 지원하면서 웹 애플리케이션 플랫폼이 탄생했습니다. ECMA-262에서 표준화되고 DOM 같은 공통 API가 도입되면서 자바스크립트가 많이 발전했는데도 정작 그 코드를 실행할 자바스크립트 엔진은 거의 변하지 않았습니다.

왜 최적화가 필요한가
수십 줄의 코드를 실행하면서 웹 페이지를 보조하던 1996년이나, 수천 줄의 코드를 실행하는 요즘이나 자바스크립트 엔진은 같습니다. 브라우저가 자바스크립트를 잘 관리하고 기반 작업에 신경썼다면 자바스크립트는 크게 성공할 수 있었을 겁니다. 브라우저가 자바스크립트에 별로 신경쓰지 않았다는 것은, 발표 당시에는 안전성과 속도를 널리 인정받았던 인터넷 익스플로러 6이 얼마 안 있어 느린 속도와 버그로 웹 애플리케이션 플랫폼으로는 최악이라는 악명을 떨치게 된 것만 봐도 알 수 있습니다.
사실 인터넷 익스플로러 6이 느려진 것이 아니라 해야 할 일이 늘어났을 뿐입니다. 2001년 인터넷 익스플로러 6이 발표되던 당시의 웹 애플리케이션은 2005년에 개발된 것에 비해 아주 단순하고 가벼웠으며 코드도 무척 짧았습니다. 코드의 양이 늘어나면서 브라우저는 자바스크립트를 잘 관리하지 않은 부작용이 눈에 띄게 드러나게 되었는데, 그 단적인 예가 인터넷 익스플로러 6의 가비지 컬렉션 루틴입니다. 인터넷 익스플로러 6의 자바스크립트 엔진은 메모리에 있는 객체가 일정 숫자까지 증가했는지 살펴서 가비지 컬렉션 시기를 결정합니다. 초기 웹 애플리케이션 개발자는 인터넷 익스플로러 6에서 정해 놓은 한계선을 넘기는 일이 드물었지만 자바스크립트 코드가 길어지면서 메모리에 남는 객체의 숫자도 늘어났고 복잡한 웹 애플리케이션은 이 한계선을 자주 넘깁니다. 문제가 무엇인지 분명해졌습니다. 자바스크립트 개발자와 웹 애플리케이션은 진화했지만 자바스크립트 엔진은 그렇지 않기 때문입니다.
다른 브라우저에서 더 논리적인 메모리 반환 루틴을 도입하고 실행 성능을 좀 더 끌어올리기는 했지만 대다수는 여전히 자바스크립트 인터프리터로 코드를 실행합니다. 코드 인터프리터는 자바스크립트 코드를 실제로 컴퓨터가 실행하는 코드로 바꿔야 하기 때문에 근본적으로 컴파일러보다 느립니다. 인터프리터를 아무리 잘 설계하고 최적화하더라도, 항상 더 느릴 수밖에 없습니다.
컴파일러는 개발자가 효율성을 걱정할 필요 없이 원하는 대로 코드를 작성할 수 있도록 온갖 종류의 최적화를 합니다. 또한 개발자가 작성한 코드를 그 언어의 문법대로 분석해서 하는 일을 알아낸 다음 컴퓨터가 실행할 수 있는 가장 빠른 저수준 언어로 바꿔줍니다. 인터프리터는 컴파일러가 하는 최적화를 거의 하지 못하므로 코드가 작성된 그대로 실행될 때가 많습니다. 결과적으로 다른 언어에서는 컴파일러가 하는 최적화 작업을 자바스크립트에서는 개발자가 직접 할 수밖에 없습니다.

차세대 자바스크립트 엔진
2008년 자바스크립트 엔진은 첫 번째로 성능이 향상되었는데, 구글에서 완전히 새로운 브라우저, 크롬을 발표했습니다. 크롬은 코드 최적화 기능이 있는 자바스크립트 엔진을 탑재한 최초의 브라우저입니다. 코드네임 V8이라 불리는 이 엔진은 자바스크립트 코드를 기계어로 바꿔서 실행하는(JIT) 자바스크립트 컴파일 엔진입니다. 이 엔진은 자바스크립트 실행 성능을 크게 향상시켰습니다.
다른 브라우저도 곧 독자적인 자바스크립트 최적화 엔진을 도입했습니다. 사파리 4는 적시 변환 자바스크립트 엔진 Squirrel Fish Extreme(Nitro라고도 합니다)을 선보였고 파이어폭스 3.5는 자주 실행하는 코드를 최적화하는 TraceMonkey 엔진을 도입했습니다. 새로운 자바스크립트 엔진은 당연히 최적화를 담당해야 할 곳인 컴파일러에서 최적화합니다. 언젠가는 개발자가 코드를 짜면서 성능 최적화에 신경쓰지 않아도 되는 날이 올 겁니다. 하지만 아직은 아닙니다. 아직은 성능에 신경 써야 합니다
자바스크립트 코어의 실행 시간이 많이 단축되기는 했지만 자바스크립트에는 새로운 엔진과 무관한 문제점이 있습니다. 페이지의 외관에 영향을 미치는 작업과 네트워크 지연율 때문에 생기는 지연 시간은 브라우저에서 더 개선해야 합니다. 인라인 함수, 코드 축소, 문자열 병합 알고리즘 같은 간단한 최적화는 컴파일러에서 쉽게 처리할 수 있지만, 웹 애플리케이션의 동적이고 다면적인 구조는 엔진 최적화로 쉽게 해결할 수 없는 문제이기 때문에 최적화는 성능 문제의 일부분만 해결할 수 있습니다.
새로운 자바스크립트 엔진이 등장해 훨씬 빠른 인터넷을 사용하는 미래를 상상할 수 있지만, 지금 성능을 연구하는 것도 미래에 여전히 쓸모 있고 중요할 것이라고 예견할 수 있습니다. 이 책에서는 실행 시간, 내려받기, DOM과의 상호작용, 페이지의 라이프 사이클 등 자바스크립트의 다양한 부분에 관한 테크닉과 접근 방법을 살펴봅니다. 자바스크립트 엔진이 발전하면 코어(ECMAScript) 성능에 관한 일부는 필요 없어지겠지만, 아직은 아닙니다.
다른 주제는 DOM과의 상호작용, 네트워크 지연 시간, 자바스크립트 내려받기의 두 가지 양상(차단과 병행) 등 자바스크립트 엔진이 빨라지더라도 별 도움이 되지 않는 문제에 관한 것입니다. 저수준 자바스크립트 실행 성능이 계속 향상되더라도 이러한 주제는 여전히 중요하고, 앞으로도 더 많은 관심과 연구의 대상이 될 것입니다.---저자 서문 중에서

"우리 머리에 주먹질을 해 대는 책이 아니라면, 우리가 왜 그런 책을 읽어야 한단 말인가"
- 프란츠 카프카

자바스크립트는 현재 웹에서 사용되는 언어 중 가장 중요한 언어라고 할 수 있습니다. 처음에는 자바스크립트를 써서 페이지를 좀 더 역동적으로 보이게 하고, 작성할 양식이 많은 폼에 잘못된 형식의 값을 써서 서버에 보냈다가 처음부터 다시 작성하는 일이 없도록 방지하는 정도였습니다. 하지만 이제 자바스크립트는 상상할 수 있는 거의 모든 일을 해내고, 상상하지 못했던 일도 척척 해내고 있습니다.
자바가 처음 개발되었을 때 가장 많은 주목을 받은 특징은 이식성입니다. "이 프로그램은 자바로 만들었으므로 유닉스, 윈도우, 맥 모두에서 동작합니다"라는 문구가 자바의 이식성을 말해줍니다. 하지만 자바스크립트는 이식성이라는 말 조차 필요 없습니다. "그냥 됩니다"
자바스크립트가 번창하게 된 이유는 몇 가지 있지만, 대표적인 이유를 두 개만 든다면 저는 이렇게 말하겠습니다.
1. "그냥 됩니다" - 운영체제? 장치? 브라우저? 상관없이 다 돌아갑니다.
2. "쉽습니다" - 컴파일이 필요 없고 쓴 순서대로 동작하는 스크립트 언어입니다.

하지만 이 대표적인 장점은 또한 대표적인 약점이기도 합니다. 모든 브라우저에서 동작한다는 말은, 바꿔 말해 모든 브라우저를 다 신경써야 한다는 말이기도 합니다. 컴파일이 필요 없다는 말은, 바꿔 말해 컴파일할 수 없으니 성능 문제에서 자유로울 수 없다는 말이기도 합니다.
웹이 점점 우리 생활에서 널리 쓰이고 있습니다. 충분한 성능의 데스크톱 컴퓨터에서 동작하던 자바스크립트는 최근 한두 해 사이에 비교적 성능이 떨어지는 모바일 장치에서 동작하게 되었습니다. 모바일 장치의 성능이 점점 더 좋아지지 않느냐구요? 자바스크립트가 느리게 느껴진다면 하드웨어 성능이 느려서가 아니라, 코드를 미숙하게 짰기 때문일 겁니다. 즉, 지금 느리게 실행되는 코드는 모바일 장치의 성능이 좋아지더라도 여전히 느리게 실행될 가능성이 높습니다. 이 책은 처음부터 끝까지 자바스크립트 성능에 초점을 맞추고 있습니다. 자바스크립트가 어떻게 동작하는지, 웹과 브라우저 환경의 특이점에는 어떤 것이 있는지 살펴보면서 가장 효율적으로 코드를 쓰는 방법을 알려줍니다. 성능 평가를 통해 어떤 부분이 느린지 명확하게 찾아내서 한정된 개발 시간에 최대의 효과를 내는 방법도 다룹니다.
저는 자바스크립트를 공부하면서 많은 책을 접했습니다. 다행히 그 책 모두 좋았지만, 그 중에서 최고를 꼽으라면 단 1초도 생각하지 않고 『더글라스 크락포드의 자바스크립트 핵심 가이드』(한빛미디어, 2008)를 꼽겠습니다. 10번을 넘게 읽었는데도 읽을 때마다 새롭습니다. 번역을 마무리하면서 "이제 두 번째로 좋은 책을 꼽으라 해도 전혀 망설이지 않겠구나"라는 생각이 듭니다.
먼저 이 책을 선택하신 여러분께 감사 드립니다. 늘 노력하는 여러분 덕에 세상이 발전할 수 있습니다. 당장 이해하기 어려운 점이 있더라도 꾸준히 노력한다면 분명 그 열매를 얻을 것입니다.
좋은 책을 맡겨주신 한빛미디어, 숱한 오류와 어색한 번역을 교정해 준 한동훈 편집자께도 감사 드립니다. 1년 가까운 기간 동안 코어 자바스크립트 스터디를 함께 한 김태선, 연병화 씨에게도 감사합니다. 혼자였다면 끝까지 공부하지 못했을 겁니다.