코드 네임: 팩스JS(FaxJS)

'UI는 상태의 함수다.'

그 혁명적인 발상은 조던 워크의 뇌리를 떠나지 않았다. 하지만 동시에, '성능'이라는 거대한 벽 또한 그의 앞을 가로막고 있었다. 상태가 변할 때마다 UI 전체를 다시 그리는 것은 이론적으로는 아름다웠지만, 현실적으로는 자살 행위나 다름없었다.

그러나 조던은 포기할 수 없었다. 그의 가슴속 깊은 곳에서, 이 아이디어가 단순한 망상이 아니라 웹 개발의 고질적인 문제를 해결할 '성배'가 될 수 있다는 강렬한 예감이 꿈틀거렸다.

"증명해야 해… 가능성을."

그는 결심했다. 더 이상 머릿속으로만 고민할 때가 아니었다. 직접 코드로 부딪혀봐야 했다. 그의 손가락이 키보드 위에서 춤을 추기 시작했다. 정규 업무 시간이 끝난 뒤, 동료들이 하나둘 퇴근한 텅 빈 사무실에서, 혹은 주말의 고요한 새벽녘 자신의 집에서, 그는 홀로 새로운 코드의 세계를 탐험하기 시작했다.

이것은 회사에서 주어진 공식적인 프로젝트가 아니었다. 그의 개인적인, 어쩌면 무모한 도전이었다. 실패해도 누구 하나 알아주지 않을, 성공한다 해도 어떤 보상이 기다릴지 알 수 없는 외로운 싸움.

그는 이 비밀스러운 프로젝트에 코드 네임을 붙였다.

팩스JS (FaxJS).

왜 하필 '팩스'였을까? 낡고 구시대적인 이미지의 그 기계? 어쩌면 그것은 일종의 역설적인 유머였는지도 모른다. 혹은, 상태가 변경될 때마다 UI의 '전체 모습(페이지)'을 마치 팩스를 보내듯 시스템에 전달한다는 개념을 담고 싶었는지도. 중요한 것은 이름이 아니었다. 중요한 것은 이 코드 네임 아래에서 태어날 새로운 가능성이었다.

그의 첫 번째 목표는 'UI = f(State)'라는 개념을 자바스크립트로 구현하는 것이었다.

// FaxJS 초기 개념 스케치

function renderUserProfile(state) {
  // 입력: 사용자 상태 (이름, 프로필 사진 URL 등)
  // 출력: UI 구조를 '묘사'하는 객체 (실제 DOM 아님!)
  return {
    type: 'div',
    props: { className: 'profile-card' },
    children: [
      {
        type: 'img',
        props: { src: state.profilePicUrl, className: 'profile-pic' },
      },
      {
        type: 'span',
        props: { className: 'user-name' },
        children: state.userName,
      },
    ],
  };
}

// 상태 정의
let currentState = {
  userName: 'Jordan Walke',
  profilePicUrl: '/images/jordan.jpg',
};

// 상태가 주어지면, UI '묘사' 객체를 생성!
let uiDescription = renderUserProfile(currentState);

// ??? -> 이제 이 '묘사'를 어떻게 실제 화면에 효율적으로 그릴 것인가?

"좋아… 일단 UI를 데이터 구조로 표현하는 것까진 됐어."

조던은 중얼거렸다. 함수는 상태를 받아서, HTML 태그 대신 자바스크립트 객체로 UI의 구조와 내용을 '묘사(description)'하는 결과물을 반환했다. 여기까지는 순조로웠다. 문제는 그 다음이었다. 이 '묘사 객체'를 실제 브라우저의 DOM으로 변환해야 했다. 그리고 상태가 변경될 때마다 이 과정을 반복해야 했다.

'만약 상태가 바뀌어서 userName이 'Pete Hunt'로 변경된다면? renderUserProfile 함수는 새로운 uiDescription 객체를 반환하겠지.'

그럼 그 새로운 묘사 객체를 가지고 어떻게 해야 할까?

1. 기존에 화면에 그려진 DOM을 전부 지운다.
2. 새로운 묘사 객체를 기반으로 DOM을 처음부터 다시 만든다.

"… 역시 이건 아니야. 너무 무식해."

조던은 머리를 감쌌다. 이 방식으로는 성능 문제를 절대 해결할 수 없었다. 화면 전체를 지우고 다시 그리는 것은 끔찍한 자원 낭비였다. 특히 userName만 살짝 바뀌었을 뿐인데, 프로필 사진(img 태그)까지 다시 그릴 필요는 없지 않은가?

'변화… 그래, 변화를 감지해야 해.'

그의 눈빛이 다시 날카로워졌다. 이전 UI 묘사와 새로운 UI 묘사 사이의 '차이점(Difference)'을 찾아내야 한다! 그리고 그 차이점만을 실제 DOM에 최소한으로 반영하는 것이다.

'마치… 틀린 그림 찾기처럼?'

이전 상태의 UI 묘사와 새로운 상태의 UI 묘사. 이 두 개의 '설계도'를 비교해서, 변경된 부분만 콕 집어내는 알고리즘. 그것이 필요했다.

"하지만… 어떻게?"

두 개의 복잡한 트리(Tree) 구조 객체를 효율적으로 비교하고 차이점을 찾아내는 것. 그것은 또 다른 거대한 기술적 난관이었다.

팩스JS의 여정은 이제 막 첫발을 내디뎠을 뿐이었다. 'UI = f(State)'라는 혁명적인 아이디어는 여전히 성능이라는 암초 앞에서 좌초될 위기에 놓여 있었다. 하지만 조던 워크의 집념은 꺼지지 않았다. 그는 알고 있었다. 이 난관 너머에, 웹 개발의 새로운 지평을 열 열쇠가 숨겨져 있다는 것을. 그 열쇠의 이름은 아마도… '가상(Virtual)'이라는 단어와 관련이 있을 터였다.