회의실의 무거운 침묵 속에서, 한 젊은 엔지니어가 조심스럽게 입을 열었다.
“하지만… jQuery가 없었다면, 우리는 여기까지 오지도 못했을 겁니다.”
그의 말에는 일리가 있었다. 그 자리에 있던 모두가 고개를 끄덕였다. 불과 몇 년 전만 해도, jQuery는 혼돈의 웹 개발 세계에 내려온 한 줄기 빛과 같은 존재였다.
2000년대 중후반은 ‘브라우저 전쟁’의 상흔이 짙게 남아있던 시대였다. 마이크로소프트의 인터넷 익스플로러와 넷스케이프의 후예인 파이어폭스, 그리고 다른 군소 브라우저들은 저마다 다른 방식으로 자바스크립트를 해석했다.
똑같은 코드를 작성해도 어떤 브라우저에서는 작동하고, 다른 곳에서는 오류를 뿜어내는 일이 비일비재했다. 개발자들은 코드의 절반을 기능 구현에, 나머지 절반을 이 지긋지긋한 호환성 문제를 해결하는 데 쏟아부어야 했다.
예를 들어, 특정 ID를 가진 HTML 요소를 찾기 위해 표준은 document.getElementById('myId')를 제시했지만, 당시 시장을 지배하던 익스플로러는 document.all.myId라는 비표준 방식을 사용했다. 개발자들은 언제나 두세 가지 경우의 수를 모두 고려한 방어적인 코드를 작성해야만 했다.
그때, 존 레식(John Resig)이라는 천재 개발자가 jQuery를 세상에 내놓았다.
$('myId')
단 한 줄. 이 간결하고 우아한 코드는 마법과도 같았다. 개발자는 더 이상 브라우저의 종류를 신경 쓸 필요가 없었다. jQuery가 내부적으로 모든 복잡한 분기 처리를 알아서 해결해 주었기 때문이다. “Write less, do more(적게 쓰고, 더 많이 하라)”는 jQuery의 슬로건은 개발자들에게 복음과도 같았다.
페이스북도 그 마법의 최대 수혜자 중 하나였다. jQuery 덕분에 페이스북은 놀라운 속도로 기능을 확장하고 사용자를 끌어모을 수 있었다. jQuery는 명실상부한 구원자였다.
“맞아. jQuery는 훌륭한 도구지.” 팀 리더 톰이 동의했다. “문제는 우리가 그 도구로 해결할 수 없는 문제를 마주하기 시작했다는 거야.”
그의 말이 맞았다. jQuery의 핵심 철학은 ‘DOM을 쉽게 조작하게 해주는 것’이었다. 원하는 요소를 쉽게 찾고(Selector), 그 내용을 바꾸거나(Manipulation), 움직이게(Effects) 하는 것.
하지만 페이스북의 문제는 이제 ‘어떻게 바꿀 것인가’가 아니었다. ‘무엇을, 언제, 누가 바꿔야 하는가’에 대한 규칙이 없는 것이 문제였다. jQuery는 강력한 실행 부대였지만, 작전 계획을 세워주는 사령부는 아니었다.
모든 스크립트가 jQuery라는 무기를 들고 화면(DOM)이라는 단 하나의 전장에 뛰어들어 난전을 벌이는 꼴이었다. 알림 스크립트가 수정한 부분을 채팅 스크립트가 덮어쓰고, 뉴스피드 스크립트가 예기치 않게 둘 모두에 영향을 주었다.
구원자였던 jQuery는 이제 복잡성의 근원이자, 개발자들을 옭아매는 보이지 않는 족쇄가 되어가고 있었다.
조던 워크는 그들의 대화를 들으며 생각에 잠겼다. 그는 jQuery를 비난하지 않았다. jQuery는 자신의 역할을 누구보다 훌륭하게 수행했다. 문제는 패러다임 자체에 있었다.
‘개발자가 화면 구석구석을 직접 통제하려는 생각부터가 잘못됐다.’
그는 깨달았다. 필요한 것은 더 정교하게 DOM을 조작하는 기술이 아니었다. 애플리케이션의 ‘상태(State)’라는 개념을 정립하고, 그 상태가 변하면 화면은 그저 결과물로서 자연스럽게 그려지도록 만드는 새로운 접근법이 필요했다.
톰이 결론을 내리듯 말했다.
“우리에게는 구조가 필요해. 데이터가 어디에 있고, 그 데이터가 어떻게 화면에 반영되는지에 대한 명확한 흐름과 규칙 말이야.”
그 말은 새로운 길에 대한 탐색의 시작을 의미했다. 그리고 그 길의 첫 번째 이정표로 떠오른 것은 바로 ‘모델-뷰-컨트롤러(MVC)’라는 오래된 설계 패턴이었다. 페이스북의 엔지니어들은 스파게티 코드의 미궁을 탈출하기 위한 첫 번째 시도를 앞두고 있었다.
