어둠 속 한 줄기 빛 - 발상의 전환

밤은 깊었고, 페이스북 본사의 불은 꺼질 줄 몰랐다. 모니터의 푸른빛만이 어둠 속에서 섬광처럼 번뜩였다. 조던 워크는 텅 빈 에너지 드링크 캔 옆에서 싸늘하게 식은 커피를 입에 댔다. 혀끝에 남는 쓴맛보다 더 지독한 것은, 머릿속을 떠나지 않는 코드의 미로였다.

XHP가 던져준 '컴포넌트'라는 개념은 분명 매력적이었다. UI를 독립적인 부품처럼 만들고 조립한다는 생각. 하지만 그것만으로는 충분하지 않았다. 진짜 문제는 그 부품들이 '어떻게' 상호작용하고 변화하는가에 있었다. 제이쿼리가 그랬듯, 컴포넌트 방식 역시 상태 변화를 추적하고 DOM을 직접 조작하는 굴레를 벗어나지 못한다면, 결국 또 다른 형태의 스파게티를 만들 뿐이었다.

"상태… 상태… 상태!"

조던은 키보드를 신경질적으로 두드리다 말고 중얼거렸다. 알림 개수, 사용자 입력 값, 로딩 상태… 모든 UI 변화의 근원은 결국 '상태(State)'의 변화였다. 그런데 왜 개발자들은 이 명백한 진실 대신, 변화의 '결과'인 DOM 요소를 붙잡고 씨름해야 하는 걸까?

'왜 우리는 브라우저에게 일일이 명령해야 하지? "저기 저 버튼 색깔을 파란색으로 바꿔줘", "이 목록에 새로운 항목을 추가해줘" 라고 말이야. 마치… 변덕 심한 황제에게 하나하나 아뢰는 신하처럼.'

그의 머릿속 회로가 타들어가는 듯한 격렬한 사고가 이어졌다.

'만약… 만약 우리가 브라우저에게 "명령"하는 대신, 그냥 "선언"만 하면 어떨까?'

선언(Declare).

그 단어가 조던의 뇌리에 꽂히는 순간, 마치 암흑 속에서 한 줄기 빛이 터져 나온 듯했다.

'그래! 이거다!'

그의 눈빛이 형형하게 빛나기 시작했다. 발상의 전환. 패러다임의 이동이었다.

'UI는… 결국 상태(State)의 함수(Function) 다!'

수학에서 y = f(x) 라는 함수가 있다. 입력값 x가 주어지면, 함수 f는 항상 동일한 결과값 y를 내놓는다. 복잡한 중간 과정은 함수 내부에 숨겨져 있다. 사용자는 그저 x를 넣고 y를 얻을 뿐이다.

'만약 UI(View)가 함수 f이고, 애플리케이션의 상태(State)가 입력값 x라면?'

UI = f(State)

이 단순한 등식이 조던의 머릿속에서 거대한 파문을 일으켰다.

'상태가 변경되면… 그냥 함수 f를 다시 실행해서, 새로운 상태에 맞는 UI 전체를 통째로 다시 그리면 되는 거야!'

이전 방식처럼 '어디가 어떻게 변했는지' 추적하고, DOM의 특정 부분을 찾아가 '이렇게 저렇게 바꿔라'고 명령할 필요가 없어진다. 그냥 새로운 상태를 함수에 넣고, 그 결과물(새로운 UI 모습)을 화면에 보여주기만 하면 된다!

"세상에…"

조던은 저도 모르게 탄성을 내뱉었다. 이 얼마나 단순하고 우아한가! 데이터 흐름은 명확해진다. 상태가 변하면 UI가 바뀐다. 끝! 복잡하게 얽힌 의존성, 예측 불가능한 연쇄 반응, 상태 불일치 문제… 이 모든 악몽에서 벗어날 수 있는 열쇠처럼 보였다.

'이토록 단순한 진실을 왜 아무도 생각하지 못했을까?'

흥분이 그의 온몸을 휘감았다. 하지만 그 흥분은 채 1분도 가지 못했다. 차가운 현실의 벽이 그의 앞을 가로막았다.

"하지만… 잠깐. 이게 말이 되나?"

상태가 조금만 바뀌어도 UI 전체를 새로 그린다? 페이스북처럼 복잡한 페이지를 눈 깜빡할 사이에 통째로 갈아치운다고?

'미쳤군. 성능이 버텨낼 리가 없어.'

브라우저에서 DOM을 조작하는 것은 매우 '비싼' 작업이다. 화면의 구조가 변경되면 브라우저는 레이아웃을 다시 계산하고(Reflow), 화면을 다시 그리는(Repaint) 복잡한 과정을 거쳐야 한다. 상태가 1초에 수십 번씩 변하는 실시간 업데이트 환경에서 UI 전체를 계속 다시 그린다면? 웹 페이지는 거북이처럼 느려지고, 화면은 끊임없이 깜빡이며 사용자 경험은 최악으로 치달을 것이다.

"젠장!"

방금 전까지 세상을 다 얻은 듯했던 조던의 얼굴에 다시 깊은 고뇌가 드리워졌다. 'UI는 상태의 함수다'라는 아이디어는 혁명적이었지만, 현실의 벽, 즉 '성능'이라는 거대한 벽 앞에서 무력해 보였다. 마치 하늘을 나는 꿈을 꾸었지만, 중력이라는 법칙에 발목 잡힌 기분이었다.

'아니야… 포기할 순 없어.'

조던은 두 주먹을 불끈 쥐었다. 핵심 아이디어는 옳았다. 문제는 구현 방법이었다. UI 전체를 '개념적으로는' 새로 그리되, 실제 브라우저에는 '효율적으로' 반영할 방법. DOM 조작의 비용을 최소화하면서 이 아름다운 '선언적' 모델을 현실로 만들 마법.

그는 다시 키보드 위에 손을 얹었다. 눈앞의 성능이라는 거대한 산맥. 그것을 넘어서야만 했다. 그의 머릿속에서는 이미 다음 단계의 탐색이 시작되고 있었다. 보이지 않는 세계, 실제 DOM과 코드 사이의 완충지대… 어쩌면 해답은 그곳에 있을지도 몰랐다.