웹 개발 세계는 지난 10년의 대부분을 브라우저가 핵심적인 역할을 수행해야 한다는 확신을 심어주는 데 보냈습니다. 우리는 문서와 양식에서 시작하여, 가능한 모든 작업을 점진적으로 클라이언트로 이전했습니다. 라우팅, 상태 관리, 데이터 페칭, 렌더링 로직, 심지어 GraphQL을 통한 데이터베이스 쿼리 오케스트레이션까지 — 이 모든 것이 릴리스가 거듭될수록 점점 더 무거워지는 JavaScript 번들 속으로 옮겨갔습니다. 프레임워크는 늘어났고, 빌드 파이프라인은 복잡해졌으며, 앱을 빠릿빠릿하게 만들기 위해 시작했던 방식은 메가바이트 단위의 코드가 다운로드되고, 파싱되고, 실행될 때까지 페이지가 단 하나의 의미 있는 픽셀도 렌더링할 수 없는 아키텍처로 변질되었습니다.
이러한 변화는 실제 문제들을 해결했습니다. jQuery를 살짝 곁들인 서버 렌더링 페이지는 사용자가 기대하는 매끄러운 앱 같은 전환을 제공하는 데 어려움이 있었습니다. 싱글 페이지 애플리케이션(SPA)은 즉각적인 탐색, 지속적인 상태, 풍부한 상호작용을 제공했습니다. 하지만 그 대가가 쌓였습니다. 이제 팀들은 복잡한 클라이언트 측 상태 저장소를 관리하고, 거대한 JavaScript 번들을 다루며, 까다로운 데이터 동기화 계층을 유지하고, 때로는 그 자체로 풀타임 업무처럼 느껴지는 빌드 파이프라인을 디버깅해야 합니다. 우리는 한 세트의 문제를 다른 세트의 문제와 맞바꿨으며, 이제 많은 개발자가 과연 모든 애플리케이션이 그 비용을 지불해야 하는지 의문을 제기하고 있습니다.
두 가지 발전이 이 질문에 대한 답을 내리기 쉽게 만들고 있습니다.
HTMX와 하이퍼미디어의 귀환
첫 번째는 HTMX입니다. 겉보기에는 작은 라이브러리처럼 보이지만, 아키텍처 측면에서 미치는 영향은 매우 큽니다. HTMX는 HTML을 JavaScript로 채워 넣어야 하는 정적인 껍데기로 취급하는 대신, 애플리케이션 로직을 위한 네이티브 형식으로 취급합니다.
실제로 무엇이 변하는지 살펴보겠습니다. 전통적으로 사용자가 '댓글 더 보기' 버튼을 클릭하면, 프론트엔드는 fetch 요청을 보내고, JSON 페이로드를 수신하고, 이를 클라이언트 측 저장소로 정규화하고, 컴포넌트 템플릿을 통해 실행하며, 가상 DOM을 비교(diff)한 다음, 최종적으로 페이지를 업데이트(patch)합니다. HTMX는 이 과정을 단축합니다. 버튼 자체에 브라우저가 요청을 어디로 보낼지, 어떤 페이지 요소를 교체할지를 알려주는 속성이 포함되어 있습니다. 서버는 HTML 조각(fragment) — 즉, div로 감싸진 새로운 댓글들 — 을 반환합니다. 브라우저는 이를 교체합니다. JSON도, 프론트엔드 상태 트리도, 재조정(reconciliation) 알고리즘도, UI를 서버와 동기화하기 위한 명령형 JavaScript도 필요 없습니다.
이것은 현대적 개발에 대한 거부가 아닙니다. 불필요한 추상화에 대한 거부입니다. HTMX는 초기 웹을 이끌었던 아키텍처 스타일인 하이퍼미디어가 현대적인 사용 편의성과 결합될 때 여전히 정교한 인터페이스를 지원할 수 있음을 증명합니다. 폼과 링크뿐만 아니라 어떤 요소든 요청을 보낼 수 있습니다. 어떤 이벤트든 업데이트를 트리거할 수 있습니다. 서버는 데이터와 프레젠테이션 모두에 대한 신뢰할 수 있는 단일 원천(source of truth)으로 남습니다.
Chrome의 선언적 부분 업데이트(Declarative Partial Updates)
두 번째 변화는 더 최신이며 브라우저 내부에 존재합니다. Chrome은 선언적 부분 업데이트(Declarative Partial Updates, DPU)를 도입하고 있습니다. 이 기능은 브라우저가 HTML을 스트리밍하고, 바이트가 도착하는 대로 페이지의 대상 부분에 직접 삽입할 수 있게 해줍니다.
DPU 이전에는 웹 페이지에 실시간 데이터를 스트리밍하려면 일반적으로 WebSockets, Server-Sent Events 또는 수동 DOM 조작과 결합된 롱 폴링(long-polling)을 사용해야 했습니다. 프론트엔드는 연결을 관리하고, 페이로드를 파싱하며, 마크업을 정확히 어떻게 어디에 주입할지 결정해야 했습니다. DPU는 이 과정을 선언적으로 만듦으로써 방정식을 바꿉니다. 개발자가 대상 컨테이너를 지정하면, 브라우저가 스트림 수신, 조각 파싱, 그리고 전체 응답이 종료되기 전이라도 정확한 위치에 배치하는 작업을 모두 처리합니다.
서버 로그를 보여주는 모니터링 대시보드나 실시간으로 업데이트되는 지원 대기열을 생각해 보십시오. DPU를 사용하면 백엔드는 생성되는 대로 일반 HTML 청크를 보냅니다. 브라우저는 클라이언트 측 스트리밍 로직을 단 한 줄도 작성하지 않고도 이를 테이블 본문이나 피드 컨테이너로 스트리밍합니다. 조립이 네이티브 방식으로 이루어지는 것입니다.
서버 우선 모델(The Server-First Model)
HTMX와 DPU를 결합하면 서버가 상태를 소유하고 UI를 생성하며, 브라우저는 표시와 사용자 입력을 처리하는 일관된 아키텍처를 얻게 됩니다. Rails, Laravel, Django, Go templates 또는 ASP.NET과 같은 백엔드 프레임워크가 다시 주요 인터페이스 계층이 됩니다. 프론트엔드는 API를 소비하는 별개의 애플리케이션이 아닙니다. 그것은 서버가 생성하는 하이퍼미디어 인터페이스입니다.
This model fits a surprisingly wide slice of software. Consider the typical SaaS application. It is dashboards with sortable tables. It is admin panels with forms and filters. It is internal tools that move records from one state to another. It is CRUD workflows that show a list, expose a detail view, and let the user edit fields. It is even AI interfaces where a language model streams tokens back to the user, and each token or paragraph can be wrapped in HTML and appended to the conversation thread. For all of these, a thick JavaScript client is often overkill.
The benefits are immediate and practical. Initial page loads are faster because the first meaningful paint arrives as HTML, not after a hydration cycle completes. JavaScript payloads shrink because there is no virtual DOM, no client-side router, and no state management library to ship. Search engines see complete content without executing bundles, so SEO works by default. Complexity drops because one codebase handles routing, business logic, and rendering. Debugging gets easier. When something looks wrong, you inspect the Network tab and see exactly what HTML the server sent. There is no opaque client-side state object to reverse-engineer.
What About React and Heavy Clients?
None of this means React is dead, or that SPAs are a mistake. Complex, editor-grade applications still need a thick client. Figma runs a C++ engine compiled to WebAssembly inside the browser because server round-trips would make drawing impossible. Canva manipulates the canvas at sixty frames per second with client-side geometry. Google Docs uses operational transforms to resolve editing conflicts in milliseconds. These tools are essentially desktop applications delivered through a browser tab. They are not going back to server-rendered forms.
But most software is not Figma. Most software is not a real-time graphics editor. Most software is a reporting screen, a configuration panel, a booking flow, or a content management form. For that long tail of applications, shipping hundreds of kilobytes of JavaScript framework just to toggle a modal or fetch a list of records never made much sense. The economics of the stack are shifting. We are rediscovering that the server can be close to the user thanks to the edge, and that the browser itself has grown capable enough to update fragments without a framework intermediating every byte.
The Pendulum Finds a Balance
The arc of web architecture is swinging back toward simplicity, but it is not a naive return to the nineties. The browser is becoming smarter. Features like DPU do not replace developer ingenuity; they absorb the patterns we used to implement by hand — streaming, partial updates, targeted DOM insertion — into the platform itself. HTMX gives us the vocabulary to express those behaviors without reconstructing a miniature operating system in the frontend.
You no longer have to choose between a simple architecture and a responsive user experience. You can have both. The server can drive the interface, the browser can assemble it, and the JavaScript you write can focus on genuine interactivity rather than plumbing.
For the next generation of dashboards, admin tools, and AI-powered interfaces, the smartest client might be the one that does less.