프런트엔드 개발에서 '반응성(reactivity)'은 오랫동안 React, Vue, Svelte 같은 대형 프레임워크의 전유물처럼 여겨져 왔다. 상태가 바뀌면 화면이 자동으로 갱신되는 이 편리함을 얻기 위해, 개발자들은 컴포넌트 모델과 가상 DOM(virtual DOM), 그리고 빌드 파이프라인이라는 상당한 무게의 도구를 함께 들여와야 했다. 최근 Show HN에 공개된 'Mador'는 이런 전제에 반기를 든다. 이 라이브러리는 80줄 남짓한 코드로, 이미 존재하는 DOM에 최소한의 반응성만 얹어 주는 것을 목표로 한다.
무엇을 하는 도구인가
Mador의 핵심은 '반응형 상태(reactive state)'와 그 상태를 기존 DOM에 연결하는 바인딩(binding) 두 가지다. 저자는 이를 프록시(Proxy) 기반 상태 튜플로 구현했다고 설명한다. 프록시는 자바스크립트에서 객체의 속성 읽기와 쓰기를 가로챌 수 있는 표준 기능으로, Mador는 이를 이용해 어떤 바인딩이 어떤 상태 속성을 읽었는지 추적한다. 그 결과 특정 속성이 변경됐을 때 그 속성에 실제로 의존하는 바인딩만 다시 실행된다. 불필요한 재계산을 피하는 이 '의존성 추적' 방식은 오늘날 많은 반응형 라이브러리가 공유하는 접근이기도 하다.
바인딩은 세 가지 요소로 구성된다. selector는 갱신할 대상 요소를 선택하고, read는 이 바인딩이 의존하는 상태를 골라내며, update는 각 요소와 read가 반환한 값을 받아 실제 DOM을 갱신한다. 즉 개발자는 '어떤 요소를, 어떤 상태에 따라, 어떻게 바꿀지'만 선언하면 된다. 또한 쓰기 작업은 배치(batch) 처리되어, 같은 쓰기 안에서 발생한 여러 변경이 한꺼번에 반영된다. 이는 상태를 여러 번 수정해도 화면 갱신이 한 번으로 묶여 성능 낭비를 줄인다는 의미다.
컴포넌트도, 가상 DOM도 없다
Mador가 스스로를 차별화하는 지점은 '없는 것'의 목록이다. 컴포넌트도, 템플릿도, 가상 DOM도 없다. 대신 이미 페이지에 존재하는 HTML과 자바스크립트를 그대로 활용한다. 저자의 표현을 빌리면 "때로는 페이지에 프레임워크가 필요 없다. 이미 HTML과 자바스크립트가 있고, 약간의 반응성만 필요할 뿐이다"라는 문제의식에서 출발한다.
관리 부담을 줄이는 장치도 있다. 바인딩은 자신이 갱신하는 DOM과 묶여 있어서, 해당 요소가 사라지면 Mador가 대응하는 반응형 러너(runner)를 제거할 수 있다. 별도로 신경 써야 할 컴포넌트 생명주기(lifecycle)가 없다는 점은, 프레임워크에서 마운트·언마운트 훅을 다뤄 본 개발자라면 체감할 수 있는 단순함이다. 배포 측면에서도 가볍다. Mador는 네이티브 ES 모듈이라 npm으로 설치하거나 CDN에서 바로 불러올 수 있고, 전역 런타임이나 빌드 단계가 필요 없다. 저자는 현재 런타임 용량을 최소화(minify) 기준 약 855바이트라고 밝히고 있다.
실무에서 어디에 쓸까
이런 특성은 대상 용도를 비교적 뚜렷하게 그려 준다. 서버가 렌더링한 정적 페이지나 기존 레거시 페이지에 검색 필터, 카운터, 토글, 실시간 표시 값 같은 국소적인 상호작용만 추가하고 싶을 때 Mador는 매력적이다. 전체를 SPA로 다시 짜지 않고도, 스크립트 태그 하나로 필요한 부분에만 반응성을 주입할 수 있기 때문이다. 빌드 단계가 없다는 점은 도구 체인 설정에 드는 시간과 유지보수 비용을 없애 준다. 서버 사이드 렌더링이 다시 주목받고, 프레임워크의 번들 크기와 복잡도에 대한 피로감이 쌓인 지금의 흐름과도 잘 맞는다.
다만 한계도 분명히 인식할 필요가 있다. 컴포넌트와 템플릿, 가상 DOM이 없다는 것은 곧 대규모 애플리케이션에서 상태와 뷰의 구조를 체계적으로 관리해 주는 장치가 없다는 뜻이기도 하다. 화면 대부분이 동적으로 생성되고, 라우팅과 복잡한 상태 흐름이 얽히는 애플리케이션이라면 selector와 update를 손으로 조율하는 방식은 오히려 관리 비용을 키울 수 있다. Mador는 프레임워크의 대체재라기보다, 프레임워크가 과할 때 선택하는 '작은 도구'에 가깝다.
또 하나 유의할 점은 공개된 정보의 성격이다. 855바이트라는 용량이나 80줄 규모, 의존성 추적과 배치 처리 같은 설명은 저자가 제시한 것으로, 실제 프로젝트에서의 안정성이나 브라우저 호환성, 엣지 케이스 처리 수준은 직접 코드를 읽고 검증해야 확인할 수 있다. 프록시 기반 접근은 구형 환경 지원에 제약이 있을 수 있다는 점도 도입 전에 따져볼 대목이다. 그럼에도 '필요한 곳에만 최소한의 반응성'이라는 발상 자체는, 도구 선택의 기본값을 다시 생각하게 만든다는 점에서 살펴볼 가치가 있다.