결심은 섰지만, 길은 보이지 않았다. 조던 워크는 텅 빈 코드 에디터를 앞에 두고 깊은 고민에 빠졌다. UI = f(data)라는 아름다운 이상을 현실의 자바스크립트 코드로 어떻게 구현할 것인가?
그의 머릿속에는 지난 몇 년간 페이스북에서 겪었던 문제들과 그것을 해결하기 위해 시도했던 기술들의 파편들이 흩어져 있었다. 그는 그 조각들을 하나씩 꺼내어 재조립하기 시작했다.
첫 번째 조각: XHP의 컴포넌트
XHP는 PHP의 세계에 ‘컴포넌트’라는 개념을 성공적으로 안착시켰다. <ui:post>처럼 재사용 가능하고 독립적인 UI 단위. 이것은 반드시 가져와야 할 핵심 아이디어였다. 복잡한 UI를 잘게 쪼개어 관리 가능한 단위로 만드는 것. 이것이 모든 것의 출발점이었다.
두 번째 조각: XHP의 XML 문법
XHP의 또 다른 성공 요인은 HTML을 언어의 일부처럼 다루는 문법이었다. <div>나 <img>가 더 이상 문자열이 아니었기에, 컴파일러가 문법 오류를 잡아주고 보안을 자동으로 처리해 줄 수 있었다. 자바스크립트에서도 이와 유사한 경험을 제공할 방법이 필요했다. 하지만 자바스크립트 언어 자체를 수정할 수는 없는 노릇이었다.
‘어떻게 하면 자바스크립트 코드 안에 HTML과 유사한 문법을 자연스럽게 녹여낼 수 있을까?’
이 질문은 당장 해결할 수 없는, 가장 큰 기술적 난제였다. 그는 일단 이 문제를 ‘미래의 숙제’로 남겨두기로 했다.
세 번째 조각: 스탠다드 ML의 순수 함수
UI 컴포넌트는 가급적 순수 함수처럼 동작해야 한다. 동일한 데이터를 받으면 언제나 동일한 결과물을 내놓고, 외부 상태를 건드리지 않는다. 이 원칙은 시스템의 예측 가능성을 극대화할 것이다. LikeButton(data)가 button을 반환하는 것처럼, 모든 컴포넌트는 데이터를 받아 UI의 ‘설계도’를 반환하는 함수여야 했다.
네 번째 조각: 스탠다드 ML의 불변성
데이터는 불변이어야 한다. 상태가 변경될 때마다 기존 데이터를 수정하는 것이 아니라, 새로운 데이터 객체를 만들어야 한다. 그래야만 ‘상태가 변경되었음’을 아주 쉽고 빠르게 감지할 수 있다. 이것은 백본의 복잡한 이벤트 시스템을 대체할 핵심 열쇠였다.
조던은 이 네 가지 아이디어 조각들을 화이트보드에 적었다.
- Component: 재사용 가능한 UI 단위
- Declarative Syntax: 선언적인 UI 작성 문법 (XHP처럼)
- Pure Rendering: 순수 함수와 같은 렌더링 로직
- Immutable Data: 불변 데이터를 통한 변경 감지
이제 가장 중요한 마지막 퍼즐 조각이 남았다. 이 모든 것을 종합했을 때 필연적으로 마주하게 될 문제.
‘매번 전체 UI를 새로 계산한다면, 성능은 어떻게 할 것인가?’
데이터가 조금만 바뀌어도 전체 UI 컴포넌트 트리를 다시 계산하는 것은 엄청난 낭비다. 계산된 결과물을 실제 DOM에 적용하는 것은 더더욱 끔찍한 성능 저하를 일으킬 것이다. 백본의 뷰가 모델의 특정 변경 사항에만 반응하여 최소한의 DOM 조작을 했던 것은, 바로 이 성능 문제 때문이었다.
조던은 UI = f(data)라는 단순한 공식이 가진 명료함을 포기하고 싶지 않았다. 개발자는 그저 ‘데이터가 바뀌었으니 알아서 그려줘’라고만 말하고 싶었다. DOM의 어느 부분을 어떻게 바꿔야 하는지에 대한 고민을 완전히 시스템에 위임하고 싶었다.
그렇다면 시스템이 그 ‘최소한의 변경’을 알아서 찾아내야만 한다.
“어떻게?”
그는 스스로에게 물었다.
“이전 UI 설계도와 새로운 UI 설계도를 비교해서, 바뀐 부분만 콕 집어낼 수 있다면…”
그 순간, 그의 머릿속에서 완전히 새로운 개념이 희미하게 모습을 드러내기 시작했다. 실제 DOM에 적용하기 전에, 메모리상에서 먼저 변화를 계산해보는 가상의 공간. 보이지 않는 설계도.
그것이 바로 조던 워크의 새로운 라이브러리의 심장이 될, 가장 혁신적인 아이디어의 씨앗이었다.
