시연이 끝난 후에도 회의실의 열기는 식지 않았다. 충격에 빠졌던 엔지니어들은 이제 조던 워크의 프로토타입을 다른 관점에서 보기 시작했다. 단순한 성능 데모가 아니라, 자신들의 고통스러운 일상을 바꿀 수도 있는 혁신적인 도구로써.
가장 먼저 침묵을 깬 것은 뜻밖에도 가장 회의적이었던 데이빗이었다. 그는 더 이상 비꼬는 투가 아니었다. 진지한 엔지니어의 얼굴로 돌아와 있었다.
“조던, 한 가지 더 보여줄 수 있습니까?” 데이빗이 물었다. “만약 컴포넌트의 구조 자체가 바뀐다면 어떻게 되죠? 예를 들어, 테이블의 행(<tr>)을 클릭하면, 그 안에 있던 셀(<td>)들이 갑자기 <div>로 바뀐다거나 하는 식으로요.”
그것은 Diffing 알고리즘의 엣지 케이스를 시험하는 날카로운 질문이었다. 조던이 제안한 첫 번째 가정, 즉 ‘서로 다른 타입의 컴포넌트는 다른 트리를 만든다’는 원칙이 어떻게 동작하는지를 보려는 의도였다.
조던은 잠시 코드를 수정했다. 이제 행을 클릭하면, 그 행의 모든 <td> 자식들이 <div>로 바뀌도록 했다. 그리고 데모를 다시 실행했다.
그는 테이블의 한 행을 클릭했다.
순간, 개발자 도구의 페인트 플래싱 화면에서 클릭된 행 전체가 한 번에 녹색으로 번쩍였다.
데이빗은 그 모습을 보고 고개를 끄덕였다. 그의 얼굴에 희미한 미소가 번졌다.
“알겠습니다. 노드 타입이 바뀌니, 하위 노드들을 비교하는 걸 포기하고 그냥 행 전체를 새로 그리는군요. 똑똑하네요. 완벽한 최소 변경을 찾는 대신, 가장 흔한 경우에 최적화하고 예외적인 경우는 과감하게 포기한다… 실용적인 선택입니다.”
이 작은 테스트는 데이빗의 마지막 의심마저 씻어냈다. 그는 조던의 라이브러리가 단순히 빠른 것이 아니라, 웹 개발의 현실을 이해하고 설계된 ‘지능적인’ 시스템임을 인정한 것이다.
그때, 회의 내내 조용히 있던 젊은 개발자 하나가 떨리는 목소리로 물었다.
“그렇다면… 조던. 이 방식을 쓰면, 저희는 더 이상 서버에서 내려온 HTML 구조가 어떻게 생겼는지 신경 쓸 필요가 없어지는 건가요?”
그의 질문은 팀이 겪었던 ‘좋아요’ 버튼 사태의 핵심을 찌르고 있었다.
조던이 대답했다. “네, 그렇습니다. 서버에서는 <LikeButton postId={123} /> 같은 컴포넌트를 렌더링하고, 클라이언트 자바스크립트에서도 똑같이 LikeButton({ postId: 123 })을 렌더링하면 됩니다. 서버와 클라이언트가 같은 컴포넌트 설계도를 공유하는 거죠. 내부 HTML 구조가 어떻게 바뀌든, 양쪽 모두에서 자동으로 반영될 겁니다. 더 이상 동기화를 걱정할 필요가 없어요.”
그 말을 듣는 순간, 팀원들 사이에서 깊은 탄식이 흘러나왔다. 그것은 절망의 탄식이 아니라, 오랜 시간 그들을 괴롭혔던 문제에서 마침내 해방될 수 있다는 안도의 한숨이었다. 서버와 클라이언트의 분리. XHP와 jQuery의 어색한 동거. 그 모든 악몽이 끝날 수도 있었다.
회의가 끝나고, 톰은 자신의 사무실에서 조던을 따로 불렀다. 그는 창밖을 내다보며 한참을 생각에 잠겨 있다가, 조용히 입을 열었다.
“조던, 오늘 당신이 보여준 건… 단순히 빠른 라이브러리가 아니었소.”
톰은 조던을 돌아보았다. 그의 눈빛은 그 어느 때보다 진지했다.
“단방향 데이터 흐름으로 예측 가능성을 확보하고, 버추얼 DOM으로 성능 문제를 해결하고, 컴포넌트 모델로 서버와 클라이언트를 통합한다… 이건 프론트엔드 개발의 모든 문제를 한 번에 해결하려는 거대한 계획이야.”
그는 잠시 말을 멈췄다. 그리고 나지막하지만, 무게감 있는 목소리로 말했다.
“만약 이게 정말로 성공한다면, 이건 페이스북뿐만 아니라… 웹 개발의 세상 전체를 바꿀 수도 있겠어.”
톰의 그 한마디는, 조던 워크의 작은 개인 프로젝트가 이제 페이스북의 미래를 짊어질 수도 있는 공식적인 프로젝트로 나아갈 것임을 암시하는 신호탄이었다.
