고대 유물(?) XHP의 속삭임

MVC 패턴의 화려한 청사진이 현실의 복잡성 앞에서 처참히 무너지는 것을 목격한 조던 워크. 그의 머릿속은 뒤엉킨 실타래처럼 혼란스러웠다. 기존의 방식으로는 더 이상 나아갈 수 없다는 절망감과, 그럼에도 어딘가에는 반드시 해답이 있을 것이라는 희미한 희망이 교차했다.

"젠장, 뭔가… 뭔가 다른 게 필요해."

그는 습관처럼 페이스북 내부 위키와 코드 저장소를 뒤적였다. 새로운 기술 동향, 다른 팀의 프로젝트 문서, 심지어는 지금은 거의 사용되지 않는 오래된 기술 자료까지. 마치 사막에서 바늘을 찾는 심정이었다. 그러던 그의 눈에, 먼지 쌓인 고문서 같은 이름 하나가 들어왔다.

XHP.

"XHP…?"

이름조차 생소했다. 설명을 읽어보니, PHP를 확장하여 XML 문법처럼 UI 컴포넌트를 만들 수 있게 해주는 서버 사이드 기술이라고 했다. 페이스북 초창기에 일부 사용되었으나, 지금은 프론트엔드 기술의 발전과 함께 주류에서 밀려난, 말 그대로 '고대 유물' 취급을 받는 기술이었다.

'PHP? 서버 사이드? 지금 내가 찾는 건 클라이언트 사이드 문제인데…'

조던은 실망하며 창을 닫으려 했다. 하지만 그 순간, 예제 코드 한 줄이 그의 시선을 붙잡았다.

// XHP 코드 예시
<?php
  // ... PHP 로직 ...
  $user_name = 'Jordan Walke';
  $profile_pic_url = '/images/jordan.jpg';
?>

<fb:profile-card> // <-- 이게 컴포넌트?
  <fb:profile-pic src={$profile_pic_url} size="medium" /> // <-- 이것도?
  <fb:user-name name={$user_name} linkify={true} />
</fb:profile-card>

"어?"

조던의 눈이 번뜩였다. 이건… 뭔가 달랐다. HTML 태그처럼 보이는데, <fb:profile-card>, <fb:profile-pic> 같은 사용자 정의 태그들이 아닌가! 그리고 그 태그들은 마치 함수처럼 속성(Attribute)을 통해 데이터를 전달받고 있었다 (src={$profile_pic_url}, name={$user_name}).

'이건… UI를 마치… 조립 부품처럼 다루고 있잖아?'

그의 심장이 미세하게 떨리기 시작했다. XHP는 서버에서 HTML을 생성하는 기술이지만, 그 발상 자체는 조던이 어렴풋이 그려왔던 그림과 맞닿아 있었다.

• 재사용 가능한 단위: profile-pic이나 user-name 같은 UI 조각들을 독립된 '컴포넌트'로 정의하고, 필요할 때마다 가져다 쓴다.
• 명확한 인터페이스: 각 컴포넌트는 외부로부터 어떤 데이터(속성)를 받을지 명확하게 정의한다. 내부 구현은 숨겨져 있다.
• 조합(Composition): 작은 컴포넌트들을 조립하여 더 큰 컴포넌트(profile-card)를 만든다. 마치 레고 블록처럼!

"그래! 이거야!"

조던은 자신도 모르게 작게 탄성을 내뱉었다. 이것은 제이쿼리로 DOM 요소를 하나하나 찾아다니며 스타일을 바꾸고 이벤트를 붙이는 방식과는 근본적으로 달랐다. UI를 거대한 하나의 덩어리가 아닌, 독립적이고 재사용 가능한 '컴포넌트'들의 '조합'으로 바라보는 관점!

'만약… 만약 이 컴포넌트 개념을… 자바스크립트로 가져올 수 있다면?'

순간, 그의 머릿속에 벼락처럼 아이디어가 꽂혔다. XHP는 PHP 기반의 서버 기술이라는 명백한 한계가 있었다. 하지만 그 핵심 철학 – UI를 컴포넌트 단위로 만들고 조합한다는 생각 – 은 클라이언트 사이드의 복잡성을 해결할 열쇠가 될 수 있지 않을까?

지금까지 개발자들은 거대한 HTML 덩어리를 놓고, 그 위에 제이쿼리나 자바스크립트로 덧칠하고 수선하는 방식으로 일해왔다. 하지만 XHP의 방식은 달랐다. 처음부터 잘 정의된 부품(컴포넌트)들을 설계하고, 그것들을 조립하여 원하는 UI를 '선언적으로' 구축하는 방식이었다.

'상태(State)가 변하면… 영향을 받는 컴포넌트만 다시 그리면 되는 거 아닐까? DOM 전체를 뒤엎는 게 아니라, 변화가 필요한 최소한의 부품만 교체하는 것처럼!'

물론, 이 아이디어를 브라우저 환경의 자바스크립트로 구현하는 것은 전혀 다른 차원의 문제였다. 성능은? 상태 관리는 어떻게? 컴포넌트 간의 통신은? 수많은 난관이 기다리고 있을 터였다.

하지만 조던 워크의 눈빛은 이전과는 확연히 달라져 있었다. 그는 더 이상 어둠 속을 헤매는 방랑자가 아니었다. 비록 희미하지만, 가야 할 길을 발견한 탐험가의 눈빛이었다. 먼지 쌓인 고대 유물, XHP의 속삭임 속에서 그는 웹 개발의 미래를 뒤바꿀 혁명의 실마리를 움켜쥔 것이다.

그의 손가락이 다시 키보드 위에서 움직이기 시작했다. 이제는 막연한 불만이 아닌, 명확한 목표를 향한 첫걸음이었다. 코드 네임: 팩스JS(FaxJS). 그의 손끝에서 새로운 연금술이 시작되려 하고 있었다.