아직 아무도 이야기하지 않는 가장 흥미로운 웹 아키텍처

HTMX와 선언적 부분 업데이트(Declarative Partial Updates)가 마침내 서버 주도 UI(Server-Driven UI)의 약속을 실현하는 방법

웹 애플리케이션의 미래가 더 많은 JavaScript가 아니라, 더 나은 HTML이라면 어떨까요?

지난 10년 동안 프론트엔드(Frontend) 개발은 주로 하나의 아이디어를 중심으로 돌아갔습니다:

HTML은 적게 보내고, JavaScript는 더 많이 보내라.

React, Vue, Angular, Next.js, Remix, Solid 및 수많은 다른 프레임워크들은 애플리케이션 로직을 브라우저로 옮기는 데 수년을 소비했습니다.

그리고 공정하게 말하자면, 이들은 실제 문제들을 해결했습니다.

사용자들은 애플리케이션이 즉각적으로 반응하기를 기대합니다. 그들은 풍부한 상호작용, 실시간 업데이트, 그리고 매끄러운 내비게이션을 기대합니다.

하지만 이러한 과제들을 해결하는 과정에서, 우리는 새로운 종류의 복잡성을 도입했습니다:

하이드레이션 (Hydration)
거대한 JavaScript 번들 (Massive JavaScript bundles)
클라이언트 측 상태 관리 (Client-side state management)
빌드 파이프라인 (Build pipelines)
데이터 페칭 레이어 (Data-fetching layers)
REST 및 GraphQL 오케스트레이션 (Orchestration)
서버/클라이언트 렌더링 불일치 (Server/client rendering mismatches)

때로는 우리가 이전 추상화의 한계를 보완하기 위해 추상화 계층을 구축하는 데 10년을 보낸 것처럼 느껴지기도 합니다.

그러다 흥미로운 일이 일어났습니다.

Chrome은 HTML 스트리밍과 부분 UI 업데이트를 브라우저의 네이티브 기능으로 만들기 위해 설계된 신흥 브라우저 프리미티브(Primitives) 세트인 **선언적 부분 업데이트 (Declarative Partial Updates, DPU)**를 도입했습니다.

동시에, 많은 개발자가 HTMX와 같은 도구들이 옹호하는 아이디어들을 재발견하기 시작했습니다:

어쩌면 HTML은 결코 문제가 아니었을지도 모른다.

그리고 이 두 가지 아이디어를 결합하면, 매혹적인 가능성이 나타나기 시작합니다.

React의 죽음이 아닙니다.

SPA의 종말도 아닙니다.

하지만 진지한 아키텍처 옵션으로서의 서버 주도 UI (Server-driven UI)의 귀환입니다.

HTML만으로 충분했던 때를 기억하시나요?

전통적인 웹 애플리케이션은 놀라울 정도로 단순했습니다.

Browser
   ↓
Request
...

브라우저는 UI를 받았습니다.

서버가 애플리케이션 상태를 소유했습니다.

렌더링 모델은 직관적이었습니다.

그 후 싱글 페이지 애플리케이션 (Single Page Applications, SPAs)이 등장했습니다.

Browser
   ↓
Download JavaScript
...

이것은 우리에게 놀라운 사용자 경험을 제공했습니다.

하지만 이는 더 복잡한 렌더링 파이프라인을 도입하기도 했습니다:

Backend
   ↓
REST / GraphQL
...

브라우저는 UI를 받는 것을 멈췄습니다.

브라우저는 데이터를 받기 시작했습니다.

그리고 갑자기 모든 애플리케이션에 프론트엔드 프레임워크 (Frontend Framework)가 필요해졌습니다.

React 개발자가 HTMX에 관심을 가져야 하는 이유

대부분의 React 개발자들은 HTMX를 틈새 라이브러리 (Niche Library)로 치부하며 무시합니다.

저 또한 예전에는 똑같이 생각했습니다.

결국, React는 많은 문제들을 해결해주었으니까요:

컴포넌트 합성 (Component Composition)
상태 기반 렌더링 (State-driven Rendering)
풍부한 상호작용 (Rich Interactions)
복잡한 애플리케이션 워크플로우 (Complex Application Workflows)

그렇다면 왜 누군가가 과거로 돌아가고 싶어 하겠습니까?

흥미로운 점은 HTMX가 실제로 우리를 과거로 되돌리려 하는 것이 아니라는 사실입니다.

HTMX는 다른 질문을 던지고 있습니다:

우리가 정상이라고 받아들여 온 복잡성 중 일부가 사실은 필요하지 않다면 어떨까?

다음과 같은 방식 대신에:

const cart = await fetch("/api/cart");
setState(cart);

그리고 이어서:

<Cart items={cart} />

HTMX를 사용하면 다음과 같이 작성할 수 있습니다:

<button
  hx-post="/cart/add"
  hx-target="#cart">
...

서버는 다음과 같이 응답합니다:

<div id="cart">
  5 items
</div>

브라우저가 업데이트됩니다.

JSON 변환 (JSON Transformation)도 필요 없습니다.

클라이언트 사이드 템플릿 (Client-side Templates)도 필요 없습니다.

컴포넌트 재조정 (Component Reconciliation)도 필요 없습니다.

그저 HTML뿐입니다.

수년 동안 이것은 대안적인 접근 방식처럼 느껴졌습니다.

하지만 선언적 부분 업데이트 (Declarative Partial Updates)와 함께, 이것은 갑자기 브라우저 자체가 나아가고 있는 방향과 일치한다는 느낌을 주기 시작했습니다.

개발자들이 서버 주도 UI (Server-Driven UI)를 재발견하는 이유

수년 동안 업계의 메시지는 명확했습니다:

더 많은 로직을 프론트엔드 (Frontend)로 밀어 넣어라.

하지만 많은 팀이 불편한 진실을 발견하고 있습니다.

비즈니스 애플리케이션의 상당 부분은 근본적으로 다음과 같습니다:

양식 (Forms)
테이블 (Tables)
대시보드 (Dashboards)
보고서 (Reports)
내부 도구 (Internal Tools)
관리자 패널 (Admin Panels)
CRUD 워크플로우 (CRUD Workflows)

이러한 애플리케이션의 경우, 거대한 SPA (Single Page Application)의 복잡성은 종종 그 이점보다 더 큽니다.

서버는 이미 다음 사항들을 알고 있습니다:

상태 (State)
권한 (Permissions)
비즈니스 로직 (Business Logic)
데이터 (Data)

왜 브라우저에서 UI를 재구성하기 위해 모든 것을 끊임없이 JSON으로 직렬화 (Serialize)해야 할까요?

인터페이스 자체를 보낼 수 있는데 왜 굳이 데이터를 보낼까요?

이 지점이 바로 HTMX가 흥미로워지는 부분입니다.

그리고 바로 이 지점에서 선언적 부분 업데이트 (Declarative Partial Updates)가 진정으로 흥미로워집니다.

빠져 있던 조각

HTMX는 페이지의 일부를 업데이트하는 데 탁월합니다.

하지만 항상 한 가지 한계가 있었습니다.

브라우저는 전통적으로 HTML을 대부분 선형적인 (linear) 방식으로 처리합니다.

대시보드를 상상해 보세요:

+----------------------------+
| Navigation                 |
+----------------------------+
...

예를 들어 다음과 같다고 가정해 봅시다:

매출 위젯 (Revenue Widget)은 100ms 소요
알림 (Notifications)은 200ms 소요
AI 인사이트 (AI Insights)는 5초 소요

역사적으로 여러분에게는 몇 가지 선택지가 있었습니다:

모든 것이 완료될 때까지 기다리기
여러 번의 요청 (multiple requests) 보내기
커스텀 스트리밍 시스템 구축하기
대규모 프론트엔드 프레임워크 (frontend framework) 사용하기

그 어떤 것도 특별히 우아하지는 않습니다.

이 지점이 바로 선언적 부분 업데이트 (Declarative Partial Updates)가 매우 흥미로워지는 부분입니다.

선언적 부분 업데이트가 바꾸는 것

선언적 부분 업데이트 (Declarative Partial Updates)는 콘텐츠가 준비되는 대로 미리 정의된 위치에 삽입할 수 있도록 브라우저 네이티브 메커니즘을 도입합니다.

개념적으로는 다음과 같습니다:

<div>
  <?marker name="revenue"?>
</div>

나중에:

<template for="revenue">
  <h2>$2.1M Revenue</h2>
</template>

브라우저는 콘텐츠가 도착하면 이를 삽입합니다.

핵심적인 혁신은 문법 (syntax)이 아닙니다.

그것은 아키텍처의 전환 (architectural shift)입니다.

처음으로, 브라우저가 대량의 클라이언트 측 자바스크립트 (client-side JavaScript)를 요구하지 않고도 점진적인 UI 조립 (incremental UI assembly)에 참여할 수 있게 되었습니다.

모든 렌더링이 끝날 때까지 기다리는 대신, 콘텐츠가 준비되는 즉시 도착할 수 있습니다.

HTML은 더욱 동적 (dynamic)이 됩니다.

브라우저는 더욱 유능해집니다.

놀라울 정도로 우아해지는 로딩 상태 (Loading States)

선언적 부분 업데이트 (Declarative Partial Updates)의 측면 중 충분히 주목받지 못하는 부분은 로딩 상태 (loading states)를 얼마나 자연스럽게 처리할 수 있는가 하는 점입니다.

현대의 React 애플리케이션에서 우리는 종종 다음과 같이 작성합니다:

if (isLoading) {
  return <Spinner />;
}

또는:

<Suspense fallback={<Spinner />}>
  <Dashboard />
</Suspense>

DPU를 사용하면 플레이스홀더 (placeholders)가 HTML 자체의 일부가 됩니다.

상상해 보세요:

<section class="revenue-card">

  <div class="shimmer title"></div>
...

[IMG:N]

사용자는 즉시 스켈레톤 UI (Skeleton UI)를 보게 됩니다.

빈 화면이 아닙니다.

스피너 (Spinner)도 아닙니다.

최종적인 경험의 형태입니다.

데이터가 도착하면:

<template for="revenue">
  <div class="revenue-card">
    <h3>Total Revenue</h3>
...

브라우저가 플레이스홀더 (Placeholder)를 교체합니다.

로딩 상태 변수 (Loading state variables)가 필요 없습니다.

클라이언트 측 오케스트레이션 (Client-side orchestration)도 필요 없습니다.

재조정 과정 (Reconciliation process)도 필요 없습니다.

특히 흥미로운 점은 로딩 상태조차 서버 주도 (Server-driven)가 된다는 것입니다.

Dashboard Appears
        ↓
Revenue Loaded
...

이것은 놀라울 정도로 React Suspense와 유사하게 느껴집니다.

다만 브라우저 네이티브 HTML 프리미티브 (Browser-native HTML primitives)를 통해 일어난다는 점이 다릅니다.

HTMX + 선언적 부분 업데이트 (Declarative Partial Updates) = 새로운 아키텍처

다음과 같은 흐름을 상상해 보세요:

User Action
      ↓
HTMX Request
...

무엇이 빠져 있는지 주목해 보세요:

Redux
React Query
Apollo Client
GraphQL 캐시 관리 (GraphQL Cache Management)
상태 동기화 계층 (State Synchronization Layers)

서버가 UI를 소유합니다.

브라우저가 이를 조립합니다.

HTMX가 상호작용을 처리합니다.

선언적 부분 업데이트 (Declarative Partial Updates)가 스트리밍 (Streaming)을 처리합니다.

이는 믿을 수 없을 정도로 매력적인 모델입니다.

이것이 React 개발자들에게 중요한 이유

이것이 흥미로운 이유는 React가 사라지기 때문이 아닙니다.

React 개발자들이 수년 동안 다음과 같은 문제들을 해결하는 데 시간을 보냈기 때문에 흥미로운 것입니다:

스트리밍 (Streaming)
Suspense
서버 컴포넌트 (Server Components)
부분 렌더링 (Partial Rendering)
하이드레이션 (Hydration)

그런데 갑자기 브라우저 자체가 유사한 방향으로 진화하고 있습니다.

진짜 질문은 이것이 아닙니다:

DPU가 React를 대체할 것인가?

진짜 질문은 이것입니다:

미래의 React 아키텍처가 프레임워크 런타임 (Framework runtimes)에 전적으로 의존하는 대신, 브라우저 네이티브 스트리밍 프리미티브 (Browser-native streaming primitives)를 활용할 수 있을까?

그것은 주의를 기울일 만한 가치가 있는 대화입니다.

킬러 유스케이스 (Killer Use Case): AI 애플리케이션

AI 애플리케이션은 본질적으로 스트리밍 방식입니다.

오늘날의 아키텍처는 흔히 다음과 같은 모습입니다:

LLM
 ↓
Token Stream
...

만약 이것이 다음과 같은 모습이라면 어떨까요?

LLM
 ↓
Server Generates HTML
...

상상해 보세요:

<?marker name="response"?>

그리고 나서:

<template for="response">
  <p>정답은...</p>
</template>

브라우저가 즉시 업데이트됩니다.

JSON 매핑도 필요 없습니다.

상태 동기화 (State synchronization)도 필요 없습니다.

가상 DOM (Virtual DOM) 작업도 필요 없습니다.

그저 스트리밍되는 UI (Streamed UI)일 뿐입니다.

아이러니하게도, 인터넷상의 가장 현대적인 애플리케이션 중 일부는 서버 주도 렌더링 (Server-driven rendering) 원칙으로 돌아감으로써 이득을 얻을 수도 있습니다.

HTMX에도 한계는 있습니다

이런 글을 읽고 HTMX가 모든 문제의 정답이라고 결론 내리기 쉽습니다.

하지만 그렇지 않습니다.

HTMX는 다음과 같은 상황에서 빛을 발합니다:

서버가 상태 (State)를 소유할 때
UI를 HTML 조각 (Fragments)으로 표현할 수 있을 때
대부분의 상호작용이 서버 통신을 포함할 때

하지만 모든 애플리케이션이 이 모델에 부합하는 것은 아닙니다.

HTMX는 다음과 같은 상황을 다룰 때 매력이 떨어집니다:

복잡한 로컬 상태 (Local state)
드래그 앤 드롭 (Drag-and-drop) 에디터
캔버스 (Canvas) 중심의 애플리케이션
오프라인 우선 (Offline-first) 경험
실시간 협업 애플리케이션
고도로 상호작용적인 시각적 도구

그러한 환경에서는 React의 컴포넌트 모델 (Component model)과 클라이언트 사이드 상태 관리 (Client-side state management)가 여전히 매우 가치 있습니다.

그렇기 때문에 저는 HTMX가 React와 경쟁한다고 보지 않습니다.

저는 HTMX가 불필요한 복잡성 (Unnecessary complexity)과 경쟁한다고 봅니다.

제가 가장 기대하는 아키텍처

이 비전이 성숙해진다면, 제가 꿈꾸는 스택은 다음과 같은 모습일 것입니다:

PostgreSQL
      ↓
Backend Services
...

고도로 상호작용적인 섬 (Islands)들을 위한:

React
      ↓
Small Client Components

그 외의 모든 것은 서버 주도 (Server-driven) 방식으로 유지됩니다.

이점

✅ 더 빠른 초기 렌더링 (Initial rendering)

✅ 더 작은 자바스크립트 (JavaScript) 번들

✅ 향상된 SEO

✅ 더 나은 스트리밍 (Streaming) 기능

✅ 낮은 프론트엔드 복잡성

✅ 더 쉬운 디버깅 (Debugging)

✅ 감소된 하이드레이션 (Hydration) 비용

✅ 저사양 기기에서의 더 나은 성능

✅ 더 단순한 멘탈 모델 (Mental model)

그래서 우리는 실제로 무엇을 얻게 될까요?

HTMX와 선언적 부분 업데이트 (Declarative Partial Updates)가 함께 발전한다면, 우리는 놀라울 정도로 강력한 무언가를 얻게 될지도 모릅니다.

1. SPA의 복잡성 없는 SPA 같은 사용자 경험

사용자는 다음을 얻습니다:

빠른 업데이트
매끄러운 상호작용
점진적 렌더링 (Incremental rendering)
반응형 인터페이스

개발자는 다음을 피할 수 있습니다:

막대한 하이드레이션 비용 (Massive hydration costs)
과도한 클라이언트 측 상태 (Excessive client-side state)
복잡한 프론트엔드 인프라 (Complex frontend infrastructure)

2. HTML이 다시 전송 프로토콜 (Transport Protocol)이 된다

다음 대신에:

데이터 (Data)
 ↓
JSON
...

우리는 다음과 같이 얻습니다:

UI
 ↓
HTML
...

서버가 경험을 직접 전송합니다.

3. 기본적으로 더 나은 성능

다음 대신에:

모든 것을 기다림 (Wait For Everything)
 ↓
렌더링 (Render)

우리는 다음과 같이 얻습니다:

준비된 것을 렌더링 (Render What Is Ready)
 ↓
더 많이 렌더링 (Render More)
...

사용자는 즉시 진행 상황을 볼 수 있습니다.

4. 더 단순한 시스템

더 적은 레이어 (Layers).

더 적은 동기화 (Synchronization).

더 적은 중복 렌더링 로직 (Duplicated rendering logic).

더 적은 코드.

5. 스트리밍 AI (Streaming AI)에 더 적합함

AI는 본질적으로 스트리밍 방식입니다.

DPU는 스트리밍을 일급 시민 경험 (First-class experience)으로 취급합니다.

이는 매우 흥미로운 방향입니다.

솔직해집시다: 이것이 모든 애플리케이션을 대체하지는 않습니다

새로운 아키텍처 패턴이 등장할 때마다, 인터넷은 두 진영으로 나뉘는 경향이 있습니다.

"이것이 모든 것을 바꿀 것이다!"

그리고

"이것은 쓸모없다!"

진실은 보통 그 중간 어디쯤에 있습니다.

선언적 부분 업데이트 (Declarative Partial Updates)는 흥미롭습니다.

하지만 이것이 만능 해결책 (Silver bullet)은 아닙니다.

현재 이것은 여전히 떠오르는 브라우저 기능 (Browser capabilities)입니다.

프로덕션 환경 전반에 널리 배포되지 않았습니다.

아직 현대적인 웹 애플리케이션의 기본 아키텍처가 아닙니다.

그리고 많은 애플리케이션은 풍부한 클라이언트 측 프레임워크로부터 진정으로 이득을 얻습니다.

다음 사례들을 생각해 보세요:

Figma
Canva
Google Docs
Miro
VS Code Web
복잡한 트레이딩 플랫폼 (Complex trading platforms)
CAD 애플리케이션

이러한 시스템들은 상당한 클라이언트 측 상태와 상호작용 모델을 유지합니다.

이들이 조만간 주로 서버 주도형 (Server-driven)으로 바뀔 가능성은 낮습니다.

React, Vue 및 기타 클라이언트 측 프레임워크는 그러한 종류의 경험을 위한 훌륭한 솔루션으로 계속 남을 것입니다.

더 큰 기회는 다른 곳에 있습니다.

대다수의 소프트웨어는 Figma가 아닙니다.

대부분의 소프트웨어는 다음과 같습니다:

대시보드 (Dashboards)
관리자 포털 (Admin portals)
비즈니스 애플리케이션 (Business applications)
분석 시스템 (Analytics systems)
내부 도구 (Internal tools)
AI 제품 (AI products)
콘텐츠 중심 애플리케이션 (Content-centric applications)

그러한 애플리케이션의 경우, 서버 주도 아키텍처 (server-driven architectures)가 점점 더 매력적으로 다가오고 있습니다.

흥미로운 점은 DPU가 기존 솔루션을 대체한다는 사실이 아닙니다.

진정으로 흥미로운 점은 이것이 웹 플랫폼이 어디로 향하고 있는지에 대해 시사하는 바입니다.

마치며 (Final Thoughts)

수년 동안 우리는 서버에서 브라우저로 점점 더 많은 로직을 옮겨왔습니다.

어쩌면 미래는 더 많은 것을 옮기는 것에 관한 것이 아닐지도 모릅니다.

어쩌면 HTML을 더 똑똑하게 만드는 것에 관한 것일지도 모릅니다.

HTMX는 HTML 조각 (HTML fragments)이 애플리케이션 프로토콜 (application protocol) 역할을 할 수 있음을 입증했습니다.

선언적 부분 업데이트 (Declarative Partial Updates)는 HTML이 스트리밍 프로토콜 (streaming protocol)이 될 수도 있음을 시사합니다.

Insights