조던 워크는 눈을 감았다. 그의 머릿속에서 ‘스탠다드 ML’이라는, 대부분의 웹 개발자에게는 생소하기 짝이 없는 이름이 조용히 떠올랐다. 그것은 그가 대학 시절, 호기심에 깊이 파고들었던 프로그래밍 언어였다. 실용적인 기술보다는 학문적 탐구의 대상에 가까운, 일종의 지적 유희와도 같았다.
당시 대부분의 학생들은 자바(Java)나 C++ 같은 객체지향 프로그래밍에 열광했다. 세상을 역할과 책임을 가진 객체들로 모델링하고, 이 객체들이 서로 메시지를 주고받으며 협력하는 방식. 그것이 소프트웨어 공학의 주류였다.
하지만 조던은 그 반대편에 있는, 소수의 마니아들만이 탐구하던 ‘함수형 프로그래밍(Functional Programming)’이라는 세계에 매료되었다.
함수형 프로그래밍의 핵심 철학은 당시 그가 알던 모든 것과 달랐다. 그중에서도 조던의 뇌리에 가장 깊이 박혔던 두 가지 원칙이 있었다.
첫 번째는 ‘불변성(Immutability)’이었다.
데이터는 한번 생성되면, 그 누구도 절대로 수정할 수 없다. 만약 데이터의 변경이 필요하다면, 기존 데이터를 수정하는 것이 아니라 그 데이터를 기반으로 완전히 새로운 복사본을 만들어내야 했다.
이 개념은 당시 페이스북의 현실과 정면으로 배치되는 것이었다. 페이스북의 코드는 모든 것이 ‘변화’의 연속이었다. UserModel의 데이터가 변하고, DOM 요소의 클래스가 추가되거나 삭제되고, View 객체의 상태값이 수시로 바뀌었다. 모든 것이 서로를 끊임없이 수정하고 덧씌우는, 예측 불가능한 변화의 소용돌이였다.
두 번째 원칙은 ‘순수 함수(Pure Functions)’였다.
순수 함수란, 동일한 입력값이 주어지면 언제나, 반드시 동일한 결과값을 반환하는 함수를 의미했다. 외부의 어떤 상태에도 영향을 받지 않으며, 외부의 어떤 상태도 변경하지 않는다(No Side Effects). 마치 수학 공식 y = f(x)처럼, x가 정해지면 y는 언제나 같은 값인 것이다.
이 역시 jQuery와 백본의 세계와는 거리가 멀었다. jQuery 함수는 실행될 때마다 DOM이라는 거대한 외부 상태를 직접 변경했다. 백본의 뷰 역시 모델의 데이터를 바꾸거나, 자기 자신의 내부 상태를 변경하는 등 수많은 부작용(Side Effect)을 일으켰다.
그동안 조던에게 함수형 프로그래밍은 그저 아름답지만 현실 세계와는 동떨어진 이상향 같은 것이었다.
하지만 바로 지금, 이 혼돈의 한복판에서, 그는 깨달았다.
페이스북이 겪는 모든 문제—꼬리에 꼬리를 무는 업데이트 지옥과 예측 불가능한 버그들—는 바로 이 ‘변화’와 ‘부작용’ 때문에 발생하고 있었다.
만약… 만약 UI를 만드는 과정을 하나의 거대한 순수 함수로 볼 수 있다면?
UI = render(DATA)
render라는 순수 함수는 오직 DATA라는 입력값에만 의존한다. DATA가 같다면, render 함수는 언제나 똑같은 UI의 ‘설계도’를 반환한다. 이 함수는 DOM을 직접 건드리지도, 다른 모델의 상태를 바꾸지도 않는다. 그저 설계도를 만들어낼 뿐이다.
이 생각에 이르자, 조던의 눈이 번쩍 뜨였다.
문제의 해결책은 자바스크립트에 XHP의 문법을 흉내 내는 것이 아니었다. 더 깊은 곳, 프로그래밍의 패러다임 자체를 바꾸는 데 있었다. 자바스크립트라는 혼돈의 언어 위에서, 스탠다드 ML이 가르쳐준 불변성과 순수성이라는 철학을 구현해내는 것.
그는 아직 구체적인 방법을 몰랐다. 하지만 방향은 명확해졌다. 그는 더 이상 jQuery와 백본의 연장선에서 문제를 해결하려 하지 않을 것이다. 완전히 새로운 판을 짜야 했다.
조던 워크는 에디터에 새 파일을 열었다. 아직 이름 없는 그 파일이, 훗날 웹의 역사를 바꿀 라이브러리의 첫 번째 초석이 될 터였다.
