소프트웨어 개발 업계가 대규모 언어 모델(LLM)을 정신없이 채택하는 동안 프론트엔드 생태계는 경쟁 관계이면서 상호 연관되기도 한 3개의 아키텍처 패러다임으로 조용히 분열됐다. 반응형 프레임워크의 지배력, 진정한 REST의 하이퍼미디어 기반 단순성, 그리고 어디에나 존재하는 SQL의 탈중앙화된 회복탄력성 사이에서 개발자들은 더 이상 단순히 라이브러리를 선택하는 것이 아니라, 데이터를 서버, 클라이언트 또는 양쪽 모두 중 어디에 둘지를 선택하고 있다.

경쟁하는 3개의 아키텍처

리액트(React)를 필두로 이와 비슷한 앵귤러(Angular), 뷰(Vue), 스벨트(Svelte)와 같은 반응형 프레임워크는 오래전부터 개발자들에게 익숙하다. 이 3개의 아키텍처는 거의 10년 동안 경쟁하고 상호 영향을 주고받으며 무대를 지배하고 있다. HTMX와 하이퍼미디어 기반 애플리케이션은 핫와이어(Hotwire), 언폴리(Unpoly)와 같은 여러 대안과 함께 진정한 RESTful 씬 클라이언트로의 회귀를 추구해왔다.

어떤 면에서 반응성과 하이퍼미디어를 서로 대립하는 두 진영으로 볼 수 있다. 둘 사이 어딘가에 브라우저에 직접 SQL을 집어넣는 방식을 제안하는 로컬 우선 SQL 진영이 있다. 로컬 SQL은 리액트와 함께 작동할 수 있고 실제로 그렇게 사용되기도 하므로 구분이 그렇게 명확하지는 않다.

데이터스토어(SQL 또는 기타)와 통신하는 JSON API 백엔드와 반응형 프레임워크를 결합하는 방식이 사실상의 표준이라고 말해도 아직은 무리가 없지만, 이 모놀리식 구조는 분열되기 시작했으며 그 방식도 꽤 흥미롭다.

데이터의 무게는 어디로

물론 데이터는 웹 애플리케이션의 중심이다. 데이터의 위치와 움직이는 방식이 곧 중력이 되고, 그 외의 다른 모든 요소는 이 중력을 중심으로 공전해야 한다. 각 아키텍처는 서로 다른 이점과 타협점을 갖고 그 중력을 처리하는 나름의 방식을 제안한다.

하이퍼미디어(예: HTMX) : 데이터를 대부분 클라이언트 외부에 둔다. 클라이언트는 서버 데이터의 시각적 표현일 뿐이다. 백엔드 “API”는 데이터 기반 마크업 생성을 담당한다. API 서버는 모든 종류의 데이터스토어를 사용할 수 있다.

리액트 계열 : 정교한 상태유지 엔진이 클라이언트에서 실행되며, 개발자는 RESTful JSON API 호출을 통해 이 상태를 백엔드와 동기화한다. 백엔드 서버는 대체로 단순하고 주로 비즈니스 로직이나 데이터 지속성을 제공하기 위해 다른 서비스를 호출하는 역할을 담당한다.

로컬 우선 SQL : 리액트 계열과 마찬가지로 데이터가 클라이언트로 분산되지만 그 방식에는 큰 차이가 있다. 데이터가 데이터스토어(포스트그레스 등)에 직접 자동으로 동기화되지만 백엔드 API 서버는 데이터 지속성이 아닌 특수한 서비스 호출에만 사용된다.

요약

• HTMX : 데이터 중력이 서버에 있다.
• 리액트 : 데이터 중력이 서버와 클라이언트에 나뉘어 존재한다.
• 로컬 우선 : 데이터 중력이 클라이언트에 있다.

접근 방식 비교

기술적인 특성 외에 개발자 경험도 각 패러다임마다 꽤 다르다. 다만 각 패러다임은 다른 느낌을 주는 동시에 상호 교차하는 부분도 있다. 더 자세히 살펴보자.

리액트 계열

반응성은 지난 15년 동안 익숙해진 환경이다. 리액트, 앵귤러, 뷰, 스벨트, 솔리드(Solid)와 같은 다채로운 프레임워크가 있고 Next.js, 넉스트(Nuxt), 스벨트킷(SvelteKit), 아스트로(Astro)와 같은 풀스택 변형도 있다. 이 진영의 대표적인 장점은 핵심이 되는 반응형 개념에 있다. 변수로 구성된 상태가 있고 UI는 자동으로 업데이트된다. UI는 상태의 순수 함수다($UI = f(state)$).

단점은 그 모든 것 위에 점진적으로, 거의 인지되지 않은 채 극심한 복잡성의 층이 쌓인다는 것이다. 이 복잡성은 처음에는 우발적인 요소처럼 보이지만 사실 브라우저에 상태 엔진을 구축한다는 기본 전제에 따른 직접적인 결과물이다.

그 결과 브라우저와 데이터베이스라는 두 개의 상태를 갖게 된다. 반응형 엔진은 협상 계층이 된다. 여기에 브라우저 상태 관리에 따르는 다양한 고유의 복잡성까지 더해지면 프런트엔드 개발자에게 상당한 부담이 된다.

이런 복잡성을 관리하고 더 높은 성능을 끌어내고 개발자 경험을 개선하기 위해 노력하는 과정에서 툴과 기법의 방대하게 확산되고 뻗어 나갔다. 리액트만 해도 리액트 서버 컴포넌트, 리덕스(Redux)나 주스탠드(Zustand)와 같은 복잡한 상태 관리 라이브러리, 그리고 수동 캐시 무효화를 위한 탄스택 쿼리(TanStack Query)와 같은 오케스트레이션 계층이 있다.

백엔드에서는 JSON API(또는 그래프QL)와 통신한다. 이는 일종의 상용구 계층으로 거추장스러워질 수 있지만, 거의 보편적으로 이해된다는 장점이 있다.

HTMX 및 유사 툴(핫와이어, 언폴리)

HTMX는 훨씬 더 강력해진 HTML을 사용하는 것과 같다. 몇 가지 부가적인 속성만으로 모든 AJAX와 수많은 부분 렌더링 및 효과를 포함한 반응형 프레임워크를 사용하는 목적의 상당 부분을 충족할 수 있다.

개발자는 퍼그(Pug), 타임리프(Thymeleaf), 코틀린 DSL(Kotlin DSL)과 같은 템플릿 엔진을 사용하면서 서버에서 많은 시간을 보낸다. 여기서 지속성 서비스의 데이터를 마크업과 결합하게 된다. 개발자가 생성하는 마크업에는 HTMX 속성이 포함된다.

개발자는 템플릿을 해체하는 경향, 즉 전용 청크로 나누는 경향이 있다. 이 개념은 전체 레이아웃을 만들기 위해 더 큰 UI 내에서 사용 가능한 청크를 확보하고, 이와 함께 AJAX 응답을 위해 필요할 때 그 청크만 단독으로 사용할 수 있는 능력을 갖추는 것이다.

HTMX를 활용한 하이퍼미디어는 매우 강력한 모델이다. 개발자는 실제로 REST를 사용하며, 이는 표현 상태를 전송한다는 것을 의미한다.

핫와이어와 언폴리는 서로 비슷한 라이브러리다. 핫와이어의 경우 터보 프레임(Turbo Frame)을 사용해 링크 클릭과 양식 제출을 인터셉트하고 표준 페이지 탐색을 자동으로 부분적 DOM 업데이트로 전환하는 것만으로 HTML 변경 없이 상당한 기능과 성능을 달성할 수 있다.

하이퍼미디어 접근 방식의 장점은 적은 노력으로 많은 것을 얻는다는 데 있다. 개발자는 단순함을 대표하는 HTML에 최대한 오래 머물게 되지만, 다른 한편으로는 반응형 프레임워크의 정교한 기능을 일부 포기하게 된다.

로컬 우선 앱

로컬 우선 개발은 비교적 새로운 방식이다. 리액트 계열과 마찬가지로 데이터를 두 장소에 두지만 방식은 근본적으로 다르다. 가장 본질적인 형태에서 설명하면, 동기화 엔진을 통해 원격 데이터스토어와 정렬된 상태를 유지하는 데이터베이스를 브라우저에서 실행하는 것을 의미한다. 이전에도 카우치DB(CouchDB) 같은 NoSQL 데이터베이스나 인덱스트DB(IndexedDB) API를 통해 시도된 적이 있는 방식이지만 현대의 브라우저는 SQLite 같은 Wasm 기반 데이터베이스 엔진을 통해 이를 한 차원 높은 수준으로 끌어올린다.

사용자는 전체 데이터의 작은 뷰를 얻는데, 이를 부분 복제본이나 버킷, 셰이프(shape)라고 한다. 프론트엔드 앱은 이 데이터와 직접 상호작용하며 인프라는 모든 요소를 동기화 상태로 유지하는 작업을 자동으로 수행한다. 여기서 얻는 큰 이점은 강력한 오프라인 지원이다(클라이언트 디바이스에 실제 데이터베이스가 들어가므로).

요청-응답 주기로부터의 대대적인 이탈이라고 할 수 있다. 로컬 우선 방식에서는 데이터를 가져오지(fetch) 않고 구독(subscribe)한다. 네트워크는 CRDT(충돌 없는 복제 데이터 타입)를 사용해 로컬 상태와 원격 상태를 조정하는 백그라운드 데몬이 된다. CRDT는 두 명의 사용자가 오프라인 상태에서 작업을 편집하더라도 병합이 엉키지 않고 매끄럽게 이뤄지도록 보장한다.

모든 곳에 SQL을 사용하면 단순함이라는 장점을 얻게 되지만 익숙하지 않고 복잡한 아키텍처 설정으로 인해 이 장점이 상쇄되는 측면도 있다. 파워싱크(PowerSync), 일렉트릭 SQL(Electric SQL)과 같은 동기화 엔진이 필요하며 유지 관리해야 할 일련의 규칙도 있다. 또한 데이터베이스와 동기화 엔진 사이의 인증과 상호작용도 구성해야 한다.

로컬 우선 방식은 API 서버와 HTML 템플릿 서버를 모두 없애고 개발자가 정의한 규칙에 따라 실행되는 자동화된 동기화 엔진에 데이터 협상 계층 전체를 밀어 넣는다.

흥미로운 점은 리액트(그리고 그 외의 반응형 엔진)나 일반 HTML + JS를 위한 데이터 드라이버로 로컬 우선 SQL을 사용할 수 있다는 것이다. 따라서 프론트엔드에 구속되지 않는, 웹 아키텍처에 대한 흥미로운 대안이 된다.

가장 특이한 조합이라면 아마 HTMX와 로컬 우선 SQL을 함께 사용하는 형태일 것이다. 물론 개발자들은 미친 과학자의 발상처럼 보이는 이 아키텍처를 실제로 사용한다. 여기서 백엔드 HTMX 템플릿 엔진은 SQL 엔진을 실행하는 서비스 워커다. 이론적으로는 이렇게 하면 HTMX의 단순함과 로컬 SQL의 초고속 + 오프라인 기능을 모두 얻을 수 있다.

반응성, 하이퍼미디어, 또는 로컬 우선?

지금은 여전히 리액트와 JSON API가 기본 선택인 시대다. 여기서 출발해 스벨트나 솔리드 같은 혁신적인 프레임워크를 실험해 볼 수 있다. RESTful의 단순함을 활용할 독창적인 방법을 찾는다면 HTMX나 핫와이어는 꼭 시도해 봐야 한다. 로컬 우선 SQL은 독특한 기술로, 현재 리니어(Linear), 노션(Notion)과 같은 서비스에는 잘 맞지만 일반적인 프로덕션 작업을 수행하는 대다수가 사용하기에는 다소 무모한 기술이다.

더 넓게 보면 이 트릴레마의 등장은 웹 개발에서 “유일한 정답”이 존재했던 시대의 종말을 의미한다. 세계는 라이브러리 전쟁에서 벗어나 아키텍처 선택으로 이동하고 있다.

반응성, 하이퍼미디어, 로컬 우선 사이의 선택은 단순한 코드의 문제가 아니라 데이터를 어디에 두고 싶은지에 관한 문제다.

• 데이터를 서버 측 문서로 두고 싶다면 하이퍼미디어를 선택하라.
• 데이터를 공유된 메모리 상태로 두고 싶다면 반응성을 선택하라.
• 데이터를 분산 데이터베이스로 두고 싶다면 로컬 우선을 선택하라.

물론 여러 접근 방식을 결합해서 프로젝트에 맞게 이점을 적절히 조합하는 것도 가능하다.

‘와이어를 통한 JSON’이라는 거대한 단일체가 계속해서 분열됨에 따라 앞으로는 최고의 설계자가 되려면 가장 많은 훅이나 속성을 아는 설계자가 아니라 데이터의 무게를 이해하고 데이터가 가장 자유롭게 이동할 수 있는 아키텍처를 선택하는 설계자가 되어야 한다. 프레임워크 전쟁은 끝났지만 네트워크를 향한 전투는 이제 막 시작됐다.
dl-itworldkorea@foundryco.com