규범적 경로라고 할 만한 것이 없다. 모든 방향을 향해 뻗어 나가는 최근의 개발 상황을 보면 웹 개발이 일종의 합의점으로 수렴한다는 희망은 사라졌다. 다만 이런 다양한 움직임을 관통하는 하나의 중심 테마가 있다면, 그것은 반응형 규범을 중심으로 성장한 거추장스러운 계층을 줄이고자 하는 열망이다. 무거운 복잡성 없이 다른 시각으로 사물을 바라보고 필요한 역량을 얻으려면 어떻게 해야 할까?

그 길을 가리키는 8가지 최첨단 웹 개발 툴을 소개한다.

프론트엔드의 마에스트로

일단의 클래식 음악 연주자들을 한 방에 모아서 악보를 주고 연주하도록 하면 어쩌다 괜찮은 연주가 나올 수도 있지만 대개는 모든 파트를 조율하는 지휘자, 즉 마에스트로가 필요하다. 프론트엔드 프레임워크에서 그 역할을 하는 툴은 아스트로(Astro)다.

아스트로는 셸을 반응형으로 만드는 프로세스, 즉 프론트엔드의 “하이드레이션”을 다루는 툴이다. Next.js나 넉스트(Nuxt)와 같은 전통적인 서버 사이드 렌더링(SSR)에서 서버는 HTML을 전송할 뿐만 아니라, 단순히 페이지에 이벤트 리스너를 첨부하기 위해 방대한 프레임워크 런타임까지 네트워크로 전송한다. 아스트로를 사용하면 리액트(React), 스벨트(Svelte), 뷰(Vue), 솔리드(Solid)로 컴포넌트를 작성할 수 있으며 브라우저에 도달하기 전에 컴파일러가 모든 자바스크립트를 걷어낸다. 아스트로는 기본적으로 JS를 전혀 전송하지 않고, 아일랜드 아키텍처를 통해 상호작용성이 필요한 특정 컴포넌트만 하이드레이션한다.

아스트로는 상호작용성을 별도의 아일랜드로 격리하므로 이런 아일랜드 간에 복잡한 상태를 공유하기는(예를 들어 복잡한 필터링 사이드바가 별도의 동적 데이터 그리드와 통신하기) 모놀리식 단일 페이지 애플리케이션에 비해 근본적으로 더 어렵다. 상호작용성이 강해 모든 컴포넌트가 다른 모든 컴포넌트에 영향을 미치는 대시보드 중심의 앱을 구축한다면 아스트로의 격리된 아일랜드가 자유롭지 않고 오히려 더 답답하다고 느낄 수도 있다.

함께 보기 : 퀵(Qwik). 아스트로는 자바스크립트를 완전히 없애는 방식으로 비대함을 해소하고, 퀵은 자바스크립트를 지연시켜 비대함을 해소한다. 퀵은 즉각적인 HTML을 제공하고 애플리케이션 상태를 직렬화해서, 사용자가 버튼을 클릭하는 그 순간 특정 상호작용에 필요한 자바스크립트 코드만 다운로드하고 실행한다.

바이옴 : 2026년에 어울리는 린트

러스트(Rust)는 자바스크립트 생태계의 기반 인프라를 점진적으로 대체하고 있다. 러스트는 바이옴(Biome)에 하드웨어에 근접한 속도를 부여하지만 바이옴의 진정함 강점은 무분별하게 확산되는 툴체인을 하나의 응집력 있는 우산 아래로 통합하는 데 있다.

.eslintrc 파일과 .prettierrc 파일, 그리고 이와 관련된 수십 개의 플러그인은 프로젝트를 잡아 끄는 무거운 늪이 될 수 있다. 바이옴은 그 늪에서 벗어나는 방법이다. 복잡하게 얽힌 포맷팅과 린팅 생태계 전체를 대체하는 하나의 아주 빠른 바이너리로, 거미줄같이 복잡한 종속성이 필요 없는 코드로 가는 길을 제공한다.

가장 큰 단점은 개방적인 확장성을 잃게 된다는 점인데, 역설적이게도 바이옴을 가볍게 만드는 바로 그 특징이기도 하다.

함께 보기 : Rspack. 바이옴이 린팅을 정리한다면 Rspack은 빌드 단계의 무거움을 해소한다. 속도를 위해 마찬가지로 러스트를 기반으로 구축됐으며, 비트(Vite)가 내세우는 새로운 esbuild 기반의 “언번들” 개발 모드에 도전해 번들 개발 모드를 사용한다.

번 : 빠른 통합 백엔드 자바스크립트

앞서가는 자바스크립트 애용자들은 대부분 번(Bun)에 대해 이미 잘 알고 있다. 원스톱 쇼핑의 편리함과 쾌적한 속도의 조합을 아직 경험하지 못했다면 반드시 사용해봐야 한다.

빠르다는 단어로는 부족하다. 노드에 익숙한 사람은 번을 사용하는 순간 명령이 실행되는 속도에 아마 깜짝 놀랄 것이다. 또한 번 팀은 엔진과 노드 API 간의 긴밀한 호환성을 구현하기 위해 오랜 시간 많은 노력을 기울였다. 전반적으로 번은 자바스크립트 개발자라면 누구나 관심을 가져야 할 놀라운 엔지니어링의 산물이다.

단, 지그(Zig) 기반의 번 엔진이 대다수 측면에서 노드를 대체할 수 있다 해도 특히 방대한 노드 패키지 생태계를 고려할 때 완벽하게 대체하지는 못한다. 노드는 서버 사이드 자바스크립트를 위한 보수적이고 안전한 엔진으로 여전히 자리를 지키고 있다.

함께 보기 : 디노(Deno). 번이 최첨단 혁신이라는 평가를 받는 데도 그만한 이유가 있지만 디노 역시 통합 배포 플랫폼, 프론트엔드 프레임워크(디노 프레시)와 같은 매력적인 엔터프라이즈 기능에 힘입어 조용히 발전해왔다.

HTMX : 에이잭스 KISS

웹의 복잡성을 덜기 위한 좋은 방법을 논한다면 HTMX를 대표 주자로 꼽을 수 있다. HTMX는 에이잭스(Ajax), 부분 업데이트와 같은 현대 웹 클라이언트의 핵심 메커니즘을 가져와 간단한 HTML 속성으로 바꾼다. 즉, 상태는 서버에만 존재한다. 서버는 HTMX 조각을 전송하는 역할을 한다.

물론 절충점이 있다. 가장 불가피한 절충은 네트워크에 대한 극단적인 의존성이다. 클라이언트 사이드 상태 머신이 없기 때문에 서버와 연결되지 않으면 브라우저는 고립된 채 아무것도 할 수 없다. 로컬 우선 데이터스토어가 있지만 실험적인 수준이다.

간단히 말해, 앱이 HTMX의 역량 범위 내에 들어맞는다면 HTMX는 그 앱을 구축하기 위한 가장 직관적인 RESTful 방식이 된다. 실제로 HTMX는 상당히 많은 부분을 처리할 수 있다.

함께 보기 : 핫와이어(Hotwire). 핫와이어는 네트워크로 전달되는 HTML을 사용하는 단일 페이지 스타일의 애플리케이션을 구축하기 위한 툴 모음이다. 간단한 가져오기 하나로 HTML을 새로 로드하지 않고 변경된 점만 비교해 반영하는 페이지 모핑과 같은 좋은 기능을 갖고 있다. HTMX와 핫와이어 프로젝트는 고전적인 자유 소프트웨어 문화를 충실히 따르는 만큼 자유롭게 아이디어를 교환한다.

파워싱크(PowerSync) : 데이터 계층의 재구성

파워싱크(PowerSync)가 표방하는 로컬 우선 데이터 혁명은 엔지니어링 측면에서 탐구할 만한 상당히 심층적인 주제지만 웹 개발자라면 웹 아키텍처에서 데이터의 이동 방식을 완전히 바꾼다는 이 툴의 핵심적인 제안 정도는 알아둬야 한다.

일반적으로 만들어지는 아키텍처에는 반응형 클라이언트와 데이터스토어 사이를 중재하기 위한 복잡한 미들웨어가 필요하다. 파워싱크는 혁신적인 대안으로, 강력한 SQLite Wasm 데이터베이스를 브라우저에 직접 집어넣어 이 중간자를 생략하는 방식을 제안한다.

UI는 로컬 데이터에서 익숙한 SQL을 사용해 동기적으로 작동한다. 지연이 없다. 보기 싫은 로딩 스피너가 완전히 사라진다. 백그라운드에서 파워싱크가 로컬 저장소와 중앙 포스트그레스 데이터베이스를 자동으로 맞춘다. 복잡한 동기화 알고리즘과 네트워크 소실을 처리해 결과적으로 애플리케이션을 기본적으로 오프라인 우선 상태로 만들어준다.

물론 대가도 따른다. 로컬 우선 개발을 위해서는 대대적인 인식의 전환이 필요하다. 각 클라이언트 사용자가 보유할 데이터 슬라이스(뷰와 비슷함)를 정의해야 한다. 어려운 일은 대부분 파워싱크 엔진이 처리하지만 스키마 마이그레이션이나 충돌 해결(두 사용자가 오프라인 상태에서 동일한 레코드를 편집)과 같은 작업은 표준 REST API보다 초기 설정이 훨씬 더 까다롭다.

함께 보기 : RxDB. 약간 다른 형태의 로컬 우선 데이터스토어다. 파워싱크가 포스트그레스, SQLite, 백그라운드 데몬에 많은 부분을 의존하는 것과 달리 RxDB는 NoSQL 오프라인 우선 반응형 데이터베이스를 제공해서 쿼리를 관찰 가능한 스트림으로 취급하고 로컬 데이터가 변경되는 순간에 사용자 인터페이스 업데이트한다.

루코드(RooCode) : 원하는 AI 자유롭게 사용하기

루코드(RooCode)의 장점은 어떤 AI 제공업체든 조율할 수 있는 기능이다. 게다가 무료다. 루코드는 비주얼 스튜디오 코드의 확장 프로그램으로, AI 관리자 계층을 제공한다. 이 계층은 LLM의 일반적인 능력과 코드에 특화된 프로젝트 수준 구조 사이를 연결한다.

루코드의 기능은 강력해서, 어느정도 에이전트처럼 작동할 수 있다. 커서(Cursor)나 안티그래비티(Antigravity) 같은 강력한 툴의 역량에는 미치지 못하지만 중소 규모의 요청은 대부분 충분히 처리할 수 있으며 그 과정에서 불필요한 오버헤드를 최소화한다. 필자는 소소한 요구사항을 낮은 비용으로, 더 큰 작업의 흐름을 방해하지 않으면서 처리하기 위해 AI 보조 IDE와 함께 루코드를 자주 사용한다.

루코드를 사용하면 사유 생태계에 갇힐 일이 없다. 클로드, 오픈AI 또는 자신의 하드웨어에서 실행되는 로컬 모델 등 무엇을 사용하든 자체 API 키를 연결할 수 있다.

그러나 모든 AI 코딩 어시스턴트에 따르는 숨은 대가는 개발자의 직무를 근본적으로 “작성자”에서 “편집자”로 바꾼다는 점이다. 개발자가 아키텍처 측면의 영향을 적극적으로 검토하지 않고 AI가 생성한 상용구 코드를 맹목적으로 수용할 경우 키스트로크의 간소화가 역설적으로 겉잡을 수 없이 비대한 코드베이스로 이어질 수 있다. 자칫 방심하면 50줄의 평이한 자바스크립트로 충분한 일을 하기 위해 에이전트가 복잡한 500줄짜리 리액트 코드를 작성하는 상황이 발생한다.

함께 보기 : 안티그래비티(Antigravity). 루코드가 기존 환경을 강화하는 가벼운 확장 프로그램이라면 구글 안티그래비티는 에이전트 기반 개발 워크플로우에 맞춰 AI를 중심으로 새로 설계된 맞춤형 편집기다.

탄스택 쿼리, 더 간단한 동기화

클라이언트 사이드 상태 관리가 해결되더라도(아래 주스탠드 참조) 아직 큰 구멍이 남아 있다. 바로 서버 경계를 넘나드는 동기화다. 탄스택 쿼리(TanStack Query)는 이때 필요한 툴이다.

분산 컴퓨팅은 잘 알려진 바와 같이 사방에 가시가 도사린 난제다. 실제로 표준 반응형 모델은 클라이언트와 서버, 두 개의 서로 다른 장소에 동일한 상태를 보관해 이 가시에 찔린다. 탄스택 쿼리는 지능적인 비동기 계층 역할을 수행함으로써 이런 본질적 아키텍처 마찰을 최대한 간편히 해결하고자 한다.

탄스택 쿼리는 useState 업데이트에 묶인 수많은 수동 페치, 취약한 isLoading 플래그, 복잡한 상태 동기화 로직을 사용하지 않는다. 대신 API 응답 처리, 백그라운드 업데이트, 요청 중복 제거 등의 무거운 작업을 소수의 훅으로 추상화한다. 탄스택 쿼리에 데이터를 어디서 가져올지 알려주면 탄스택 쿼리는 이른바 “stale-while-revalidate” 패턴을 사용한다. 즉, 프론트엔드에 데이터를 캐시하고 재사용하고(다시 로드하는 데 따르는 대기 시간을 제거), 백그라운드에서 최신 상태로 동기화한다.

여기서 함정은 캐시 무효화가 여전히 컴퓨터 과학에서 가장 어려운 문제 중 하나고, 탄스택 쿼리는 사용자가 이 문제를 정면으로 마주하도록 한다는 점이다. 사용자는 시간을 들여 “쿼리 키”에 대해 생각하고 특정 데이터 조각을 언제 “오래된(stale)” 것으로 간주해야 할지 결정해야 한다. 소프트웨어에서 공짜란 없다.

함께 보기 : SWR. 탄스택 쿼리가 복잡한 데이터 조작 분야의 절대적 강자라면 SWR은 여전히 API 미니멀리즘의 선두 주자로, 거의 아무런 구성 없이 이름 그대로(Stale-While-Revalidate)의 기능을 수행한다.

주스탠드 : 미니멀리스트의 상태

반응형 앱에서 대규모 상태 관리를 아직 경험해보지 못한 사람은 그 무서움을 아마 모를 것이다. 주스탠드(Zustand)가 제안하는 방식은 리듀서, 프로바이더, 그리고 까다로운 컨텍스트 래퍼 등의 형식적인 상용구 코드를 내다 버리고 아주 작고 단순한 전역 저장소를 사용하는 것이다.

주스탠드는 애플리케이션 트리 전체를 거대한 리액트(React) 컨텍스트 프로바이더에 억지로 집어넣어 DOM 전반에 걸쳐 불필요한 연쇄적 리렌더링을 유발하지 않는다. 대신 맞춤형 훅을 사용해 상태를 그 상태가 필요한 특정 컴포넌트에 직접 연결한다. 주스탠드는 VDOM 반응형 모델에서 시그널(Signal)처럼 반응성을 완전히 제거하는 것이 아니라 특정성을 달성하는 것을 추구한다.

저장소를 정의하고 호출하면 반응성은 그냥 작동한다. 주스탠드는 플럭스(Flux)와 같은 패턴의 복잡함을 걷어낸, 프론트엔드 아키텍처에 적용되는 KISS 철학의 구현이다. 해방에 대한 대가는 규율이라는 짐이다. 주스탠드는 비지향적이므로 사용자가 전역 저장소에 온갖 잡동사니를 집어넣어 어지럽힌다 해도 딱히 막지 않는다. 따라서 대규모 프로젝트를 관리 가능한 상태로 유지하려면 스스로 규칙과 가드레일을 마련해야 한다.

함께 보기 : 조타이(Jotai). 주스탠드가 비대함을 걷어낸 전역 저장소라면 조타이는 비대함을 걷어낸 원자적 접근 방식이다. 조타이는 상태를 상향식으로 관리하며, 애플리케이션 트리 전체에 방대한 리렌더링을 트리거하지 않으면서 정밀하게 변경 사항을 계산한다.

웹 개발의 새로운 방향

지금까지 소개한 8가지 툴에서 가장 주목할 만한 점은 모두 익숙함에 도전하는 대안적 접근 방식을 다룬다는 사실이다. 당장 도입할 수 없더라도 주시할 가치는 있다. 웹 애플리케이션의 형태와 구축 방식에 계속 영향을 미칠 핵심 요소이기 때문이다.
dl-itworldkorea@foundryco.com