Estre UI rimwork / Lagacy Conquest

명세 두 장으로 PWA 앱을 하나 만들었습니다 — Rimlog 빌드 기록

SoliEstre — Fri, 17 Jul 2026 14:18:38 +0900

Rimlog 스크린샷

작은 앱을 하나 만들어서 공개했습니다. Rimlog라는 독서 기록 앱인데, 책이나 유튜브를 보다가 마음에 남는 대목과 내 생각을 적어 두면 AI가 예전 메모 중에 이어지는 걸 찾아서 붙여 주고, 질문을 하나 던져 줍니다. 오프라인에서도 돌고, 데이터는 브라우저에만 있습니다. 서버가 없으니 회원가입도 없습니다.

앱 자체는 사실 평범합니다. 이 글을 쓰는 이유는 만든 과정이 좀 이상했기 때문입니다. 저는 이 앱의 코드를 거의 쓰지 않았습니다. 대신 한국어로 명세 두 장을 썼습니다.

명세가 코드가 되는 과정

리포지토리의 eux/ 폴더에 파일이 두 개 있습니다. rimlog-app.eux는 40줄 정도인데, 페이지 세 장의 구성과 동작, 로컬 스토리지에 뭘 저장할지, AI를 언제 부르고 실패하면 어떻게 할지가 전부 문장으로 적혀 있습니다. 이를테면 이런 식입니다.

saveCapture : 캡처 폼(소스명·인용·내 생각·태그) 저장 — captures 맨 앞 삽입 + 로컬 스토리지 반영 + "저장됐어요" 토스트 + 기록 탭으로 전환.

이 파일을 EstreUX라는 도구에 넣으면 코드가 나옵니다. 이 과정을 brew라고 부릅니다. 나온 코드에는 명세의 해시가 박혀서, 누가 명세를 고치고 코드를 안 고치면(반대도 마찬가지) 커밋이 막힙니다.

왜 이렇게 하냐면, AI한테 코딩을 시켜 본 분은 아실 텐데, 결과물은 남는데 그걸 만들어 낸 대화는 날아갑니다. 석 달 뒤에 "이 코드가 왜 이렇게 돼 있지?"라고 물을 곳이 없습니다. 명세를 git에 남기고 코드를 산출물 취급하면 그 질문에 답할 곳이 생깁니다. 적어도 그게 이 실험의 가설입니다.

프레임워크는 두 개를 썼습니다

Rimlog의 큰 틀, 그러니까 페이지 전환이나 뒤로가기, 서비스워커 같은 것들은 EstreUI가 맡습니다. 안드로이드 액티비티랑 비슷한 라이프사이클이 있어서 페이지마다 onShow, onHide 같은 훅이 옵니다. 명세 첫 장이 이쪽 코드로 나옵니다.

보라색 AI 카드 하나는 EstreUV라는 웹컴포넌트 라이브러리로 만들었습니다. 명세 둘째 장이 <ai-insight-card>라는 커스텀 엘리먼트가 되고, EstreUI 페이지 안에 끼워집니다. shadow DOM이라 격리돼 있고, 라이트 모드나 다크 모드 전환은 호스트가 CSS 변수로 흘려 넣습니다.

명세 하나에서 다른 타깃을 뽑을 수도 있습니다. 예전에 만든 끝말잇기 데모는 명세 한 장에서 세 가지 버전(EstreUI 단독, 웹컴포넌트 단독, 둘 조합)이 나왔습니다. 프레임워크를 갈아탈 일이 생겨도 명세는 그대로 두고 타깃만 바꿔 다시 뽑으면 된다는 뜻입니다.

절감은 실측을 해 봤습니다. 프레임워크에 원래 있던 숫자 키패드와 접이식 블록 컴포넌트를 명세로 되돌렸더니 사람이 유지하는 줄 수가 60에서 82퍼센트 줄었습니다. 152줄짜리 숫자 키패드 코드가 28줄 명세가 된 식입니다. 생성된 코드 자체는 원본보다 길어지기도 합니다. 줄어드는 건 사람이 읽고 고치는 쪽이고, 측정 기록도 리포에 그대로 있습니다.

써 보시려면

라이브는 https://soliestre.github.io/Rimlog/ 입니다. 모바일 브라우저에서 열고 홈 화면에 추가하면 앱처럼 씁니다. AI 연결은 주간 탭의 설정 카드에서 고릅니다. API 키를 넣으면 실제 모델을 쓰고, 안 넣으면 태그 겹침 기반의 단순한 폴백으로 돕니다. 키는 브라우저 세션에만 있다가 사라집니다.

덧붙임 — 무료 모델로 제대로 돌리기

Pages 버전은 서버가 없어서 위처럼 폴백이나 직접 키 입력으로만 돕니다. 그래서 셀프호스트 옵션을 하나 넣었습니다. 리포에 의존성 없는 단일 파일 node 서버가 들어 있는데(이것도 명세에서 brew한 산출물입니다), 앱 서빙과 인사이트 생성을 같이 합니다. 기본 백엔드는 NVIDIA의 무료 호스팅 모델입니다. build.nvidia.com에서 카드 등록 없이 API 키를 주고, OpenAI 호환 프로토콜에 무료 구간이 분당 40회쯤이라 개인 일지 용도로는 넉넉합니다. 이미 내고 있는 구독을 재활용하는 쪽도 됩니다. claude-cli 백엔드는 요청마다 claude -p를, codex-cli는 codex exec를 부릅니다. 어느 쪽이든 키와 인증은 서버에만 있고 브라우저로는 안 나갑니다. 세팅은 README의 Self-host 절에 세 줄로 적어 뒀습니다.

리포지토리의 커밋 이력을 처음부터 보시면 스캐폴드에서 명세, 생성, 다듬는 과정까지 순서대로 남아 있습니다. 명세 포맷이 궁금하면 EstreUX 리포에 문서가 있습니다.

명세를 유지하고 코드를 산출물로 취급하는 방식이 맞는 방향인지는 저도 아직 확신이 없습니다. 다만 검증 가능한 앱 하나가 나왔고, 그 과정이 전부 리포에 남았다는 것까지는 사실입니다. 의견은 댓글이나 GitHub 이슈로 남겨 주세요.

[EstreUI 1.2.0] Multi Instance 및 Full-Stack 네비게이션 정식 지원 안내

SoliEstre — Sat, 28 Feb 2026 12:54:55 +0900

안녕하세요! EstreUI가 1.2.0 버전으로 업데이트되면서 많은 분들이 기다려주셨던 Multi Instance(멀티 인스턴스) 기능과 더욱 강력해진 Full-Stack 네비게이션을 정식으로 지원하게 되었습니다.

이번 포스팅에서는 기존 버전과의 차이점과 함께, 새로운 기능을 활용하기 위해 변경된 API 명세(특히 instanceOrigin 및 instanceId 관련)를 상세히 알아보겠습니다.

1. 기존 동작 방식 (1.2.0 이전)

이전 버전에서는 멀티 인스턴스 기능이 '구현 예정(Planned)' 상태에 머물러 있었습니다. 따라서 페이지 속성을 멀티 인스턴스로 지정하더라도, 실제 동작은 단일 인스턴스(Single Instance) 페이지처럼 취급되었습니다.
동일한 멀티 인스턴스 페이지를 여러 번 호출하더라도 새로운 인스턴스가 생성되는 대신, 기존 페이지를 재호출하며 인텐트(Intent)만 업데이트하는 방식으로 동작했습니다.

2. 완벽해진 Multi Instance & Full-Stack 네비게이션

1.2.0 버전부터는 진정한 의미의 Multi Instance 지원이 추가되었습니다! 이제 동일한 UI 컨테이너나 페이지를 완벽하게 독립적인 상태를 가진 인스턴스로 여러 개 띄울 수 있게 되었습니다.

더불어 이를 뒷받침하기 위해 Full-Stack 네비게이션 구조가 도입되어, 겹겹이 쌓이는 복잡한 계층의 페이지들도 안정적으로 상태를 유지하고 전환할 수 있습니다.

3. API 변경 사항 및 주의점 (estreUi.js 변경점 분석)

멀티 인스턴스가 지원되면서, 특정 페이지를 제어할 때 "어떤 인스턴스를 제어할 것인가?"를 명확히 해야 하는 요구사항이 생겼습니다. 이에 따라 estreUi.js의 핵심 네비게이션 메서드 및 하위 페이지 관리 로직에 중요한 변화가 생겼습니다.

① 페이지 호출/닫기 API에 `instanceOrigin` 파라미터 활용 (단일 계층 및 배열 지원)

멀티 인스턴스 환경을 제어하기 위해 bringPage, showPage, hidePage, closePage 등의 메서드에 instanceOrigin 파라미터가 사용됩니다.

// EstreUI 1.2.0 부터의 기본 페이지 제어 메서드 시그니처
pageManager.bringPage(pid, intent, instanceOrigin);
pageManager.showPage(pid, intent, instanceOrigin);
pageManager.hidePage(pid, hideHost, instanceOrigin);
pageManager.closePage(pid, closeHost, instanceOrigin);

선택적 입력과 사전 지정의 중요성 (bring, show): bringPage나 showPage로 페이지를 열 때 instanceOrigin 파라미터는 사실 옵션(선택 사항)입니다. 값을 넘기지 않으면 프레임워크 내부에서 자동으로 임의의 값을 생성해 줍니다. 하지만 나중에 외부에서 해당 페이지의 특정 인스턴스 상태에 접근(핸들링)해야 할 상황이 생긴다면, 이 자동 생성된 값을 찾아내기가 번거로울 수 있습니다. 때문에 추후 추가적인 제어나 참조가 필요하다면 미리 의미 있는 값을 지정해 두는 것이 좋습니다.
정확한 타겟팅 필수 (hide, close): 동일한 페이지 인스턴스가 여러 개 열려 있을 수 있는 만큼, 특정 페이지를 닫거나 숨길 때는 어떤 인스턴스를 닫을 것인지 명확히 알려주어야 합니다. 이 때는 대상을 식별할 수 있는 instanceOrigin 값이 중요하게 활용됩니다.
배열(Array) 형태의 다중 계층 지정 지원: 멀티 인스턴스가 선언된 호스트(Component) 내부에 속한 하위 페이지(Container, Article) 역시 멀티 인스턴스로 동작하는 계층적인 상황이 발생할 수 있습니다. 이러한 복합적인 계층 구조를 명확하게 제어할 수 있도록 instanceOrigin 파라미터에 [componentOrigin, containerOrigin, articleOrigin] 형태의 배열을 입력받을 수 있도록 설계되었습니다. 이를 통해 각 계층의 Origin을 한 번에 매핑할 수 있습니다.

② 하위 페이지(Section, Container, Article) 제어 시 `instanceId` 활용으로의 전환

기존에는 하위 요소(section, container, article 등)의 핸들을 요청하거나 관리할 때 단순한 페이지 컴포넌트 id를 사용했습니다. 그러나 멀티 인스턴스 모델에서는 같은 id를 가진 컨테이너가 인스턴스별로 여러 개 복제되어 존재할 수 있습니다.

이를 해소하기 위해 1.2.0 버전부터는 하위 페이지 핸들을 제어할 때 단순 id가 아닌 instanceId를 사용하는 방식으로 패러다임이 변경되었습니다.

이에 따라 getContainer, getArticle 등으로 하위 요소를 탐색할 때 자신이 속한 고유의 인스턴스 식별자(instanceId)를 기준으로 격리되어 작동하므로, 서로 다른 인스턴스 간의 상태 충돌이 완벽히 방지됩니다.

4. 마치는 글

EstreUI 1.2.0의 Multi Instance 및 Full-Stack 네비게이션 지원을 통해 보다 복잡한 윈도우 창 분할, 독립된 다중 작업 UI, 모달 중첩 등을 훨씬 매끄럽게 구현할 수 있게 되었습니다.

기존 코드를 마이그레이션 중이시라면, 멀티 인스턴스 관련 페이지 제어 시 instanceOrigin 파라미터의 활용법과 하위 요소 제어 시 instanceId를 사용하는 변경된 흐름을 꼭 숙지하여 적용하시기 바랍니다!

도움이 필요하시거나 궁금한 점이 있다면 언제든 공식 문서(https://estreui.mpsolutions.kr)를 참조해주세요. 감사합니다!

Multi Instance on Estre UI

jQuery 4.0의 귀환, 그리고 Estre UI가 선택한 미학

SoliEstre — Sun, 25 Jan 2026 12:55:45 +0900

2026년 1월, 드디어 기다리던 jQuery 4.0이 정식으로 배포되었습니다. 한때 웹 개발의 알파이자 오메가였지만, 모던 프레임워크의 홍수 속에서 "레거시"라는 꼬리표를 달아야 했던 jQuery. 하지만 이번 4.0 버전은 단순한 생명 연장이 아닌, 완벽한 현대화(Modernization)를 선언하며 화려하게 복귀했습니다.

그리고 여기, 시대를 역행하는 듯하면서도 가장 실용적인 해답을 제시하는 UI 프레임워크가 있습니다. 바로 jQuery의 철학을 계승하고 현대적으로 재해석한 Estre UI입니다.

jQuery 4.0, 무엇이 달라졌나?

오랜 침묵을 깨고 등장한 jQuery 4.0은 "가벼움"과 "최신 웹 표준 준수"라는 두 마리 토끼를 잡았습니다.

IE와의 완전한 결별: 더 이상 Internet Explorer 10 이하 버전을 지원하지 않습니다. 덕분에 불필요한 폴리필과 레거시 코드가 대거 삭제되어 라이브러리 용량이 획기적으로 줄어들었습니다.
모던 자바스크립트 도입: 내부적으로 ES Modules(ESM)를 도입하고, 최신 브라우저 API를 적극 활용하여 성능을 끌어올렸습니다.
향상된 보안: Trusted Types 지원으로 최신 보안 표준인 CSP(Content Security Policy) 환경에서도 안전하게 사용할 수 있습니다.

이제 jQuery는 무겁고 느린 라이브러리가 아닙니다. 가장 직관적이고 가벼운 DOM 제어 유틸리티로 다시 태어난 것입니다.

Estre UI: 실용주의와 현대적 감각의 만남

Estre UI는 이러한 jQuery의 진화를 꿰뚫어 보고 있었습니다. 복잡한 Virtual DOM과 상태 관리 라이브러리로 점철된 현대 웹 개발 씬에서, Estre UI는 jQuery의 독보적인 장점만을 취해 "Native-like"한 경험을 제공하는 Rimwork(림워크)를 지향합니다.

1. 직관적인 '거시레벨의' DOM 제어

Estre UI의 핵심 철학은 "보이는 그대로를 제어한다"는 것입니다. 리액트나 뷰(Vue)가 데이터를 통해 뷰를 간접적으로 제어한다면, Estre UI는 jQuery의 강력한 선택자($)를 통해 화면의 요소들을 직접, 그리고 직관적으로 제어합니다.

우리는 이것을 '거시레벨의(Macro-level)' DOM 제어라고 부릅니다. 개별 컴포넌트의 미세한 상태(State)보다, 페이지 전체의 흐름과 UI 요소들의 상호작용을 더 큰 관점에서 시원스럽게 다루는 방식입니다.

2. 소스 구성의 미학: 간결함과 명료함

Estre UI의 코드는 jQuery의 체이닝(Chaining)과 일괄 처리(Batch Processing) 특성을 극대화하여 설계되었습니다.

다음은 estreUi.js와 main.js에서 볼 수 있는 실제 사용 패턴입니다.

선언적 UI 정의

복잡한 컴포넌트 파일 대신, UI 요소들을 명확한 상수로 정의합니다.

// UI 요소들을 직관적인 이름으로 매핑
const uis = {
    toggleBtn: "button.toggle",    // 토글 버튼
    container: ".container",       // 메인 컨테이너
    tabBlock: ".tab_block",        // 탭 블록
    // ...
};

단 한 줄로 시작되는 마법

초기화 코드는 놀라울 정도로 단순합니다.

$(document).ready(() => {
    // Estre UI 초기화: 이 한 줄로 모든 네이티브 효과가 적용됩니다.
    estreUi.init(false); 
});

쿼리 체이닝을 통한 강력한 제어

복잡한 반복문(for, map) 없이, jQuery의 강력한 집합 처리를 통해 수많은 UI 요소를 한 번에 제어합니다.

// 모든 토글 버튼에 클릭 이벤트를 일괄 binding
$(uis.toggleBtn).on('click', function() {
    $(this).toggleClass('active');
    // ...
});

결론: 2026년, 다시 jQuery를 주목해야 하는 이유

프레임워크의 복잡도에 지친 개발자들에게, jQuery 4.0으로 무장한 Estre UI는 신선한 충격입니다.
가볍고 빠르며, 무엇보다 작성한 대로 동작하는 직관성은 개발자에게 잃어버렸던 '통제권'을 다시 돌려줍니다.

가장 현대적인 웹 앱을 가장 고전적인(그러나 진화된) 도구로 만드는 경험.
jQuery 4.0과 Estre UI가 함께하는 지금이 바로 그 시작점입니다.

React2Shell 사태: 복잡한 블랙박스에서 벗어나 투명한 Native Web으로

SoliEstre — Mon, 15 Dec 2025 14:27:09 +0900

최근 개발자 커뮤니티를 강타한 React 생태계의 보안 이슈들은
우리에게 근본적인 질문을 던집니다.
"우리가 사용하는 도구를 우리는 얼마나 장악하고 있는가?"

2025년 말, React 생태계의 위기

2024년 말부터 이어진 npm 공급망 공격은 2025년 12월, "React2Shell" (CVE-2025-55182) 사태로 정점을 찍었습니다. React Server Components(RSC)의 직렬화 과정에서 발견된 치명적인 원격 코드 실행(RCE) 취약점은 Next.js, Expo 등 주요 프레임워크를 사용하는 수많은 서비스를 공포에 떨게 했습니다.

단순히 특정 버전의 버그라면 패치하면 그만입니다. 하지만 개발자들을 더욱 지치게 만드는 것은 "업데이트 피로(Update Fatigue)"와 "무력감"입니다. 내 코드는 안전하게 짰다고 생각했지만, 수천 개의 의존성 트리 어딘가, 내가 알지도 못하는 깊은 곳에서 발생한 구멍으로 인해 서비스 전체가 위협받는 상황.

이젠 인정해야 할 때가 되었습니다. 우리는 'Modern Stack'이라는 이름 아래, 너무 많은 권한을 블랙박스(Blackbox) 에 넘겨주었습니다.

문제의 본질: 과도한 엔지니어링과 불투명성

"Modern Web Development"는 어느새 "Complex Build Process"와 동의어가 되어버렸습니다.

보이지 않는 코드: node_modules 폴더 안에 수만 개의 파일이 있지만, 그중 우리가 실제로 검증한 코드는 몇 줄이나 될까요? "Chalk/Debug" 사태나 "Shai-Hulud Worm"은 바로 이 맹점을 파고들었습니다.
통제 불가능한 빌드: Webpack, Turbopack 등 거대 번들러가 만들어내는 결과물을 개발자가 100% 이해하고 통제하는 것은 불가능에 가깝습니다.
서버 측 공격 표면 확대: RSC와 같이 서버와 클라이언트의 경계가 모호해지는 기술은 편리함을 주지만, 동시에 서버 로직에 대한 공격 벡터를 기하급수적으로 늘렸습니다.

우리가 잃어버린 것은 기술력이 아닙니다. 바로 "내 코드에 대한 완전한 통제권(Code Sovereignty)"입니다.

직관성이 곧 보안이다: EstreUI가 제안하는 대안

이러한 혼란 속에서 EstreUI는 조금 다른 길을 제안합니다. 시대를 역행하는 것이 아니라, 웹 표준(Web Standards)의 본질로 돌아가 모던함을 재해석하는 것입니다.

1. Modern Core: jQuery의 편안함 위에 쌓아 올린 ES11+

EstreUI를 단순히 "jQuery 프레임워크"라고 부르는 것은 반만 맞는 말입니다. EstreUI는 ES11+(ECMAScript 2020 이상) 의 강력한 최신 문법을 기반으로 설계되었습니다. 전체 코드베이스의 50% 이상은 순수 Vanilla JS로 작성되어 있으며, jQuery는 개발자에게 익숙한 DOM 조작 편의성과 메서드 체이닝을 제공하는 '도구'로서 존재합니다.

이는 낡은 기술의 답습이 아닙니다. 가장 안정적이고 검증된 API(jQuery)와 가장 강력한 표준(Modern JS)의 실용적인 결합입니다.

2. Transparent No-Build: "보이는 것이 실행되는 것이다 (WYSIWYG)"

EstreUI에는 숨겨진 빌드 단계나 난독화된 의존성 트리가 없습니다.

No Blackbox: 소스 코드가 곧 실행 코드입니다. 개발자는 브라우저에서 실행되는 모든 로직을 투명하게 볼 수 있습니다.
Auditability: 복잡한 트랜스파일링이 없기 때문에 보안 감사(Security Audit)가 훨씬 쉽고 명확합니다.

공급망 공격의 시대에, "내가 작성하지 않은 코드가 내 서비스에서 실행되지 않는다"는 것은 가장 강력한 보안 자산입니다.

3. Intuitive Structure: 직관적인 3-Depth 아키텍처

EstreUI는 현대 프레임워크의 복잡한 상태 관리나 라이프사이클 훅 대신, Component - Container - Article이라는 명쾌한 3단계 구조를 사용합니다.

데이터 흐름과 DOM 구조가 직관적으로 일치하기 때문에, "코드가 어떻게 동작할지" 예측하기 쉽습니다. 예측 가능성은 곧 버그 감소와 보안성 향상으로 이어집니다.

4. Client-Side Safety

EstreUI는 기본적으로 클라이언트 사이드 중심의 아키텍처를 지향합니다. 서버 사이드 렌더링(SSR)의 복잡성을 덜어냄으로써, 이번 React2Shell 사태와 같은 서버 측 직렬화/역직렬화 취약점으로부터 구조적으로 훨씬 자유롭습니다. 백엔드는 API로서 데이터만 제공하고, UI 로직은 클라이언트가 온전히 담당하는 관심사의 분리(Separation of Concerns) 를 명확히 합니다.

결론: 단순하고 투명한 것이 가장 강력하다

프레임워크의 유행은 돌고 돕니다. 하지만 "내 프로젝트를 내가 완전히 이해하고 통제해야 한다"는 원칙은 변하지 않습니다.

수천 개의 의존성 패키지와 복잡한 설정 파일 속에서 길을 잃었다면, 이제는 잠시 멈춰볼 때입니다. EstreUI는 화려한 블랙박스 대신, 투명하고 직관적인 Native Web의 세계로 여러분을 초대합니다.

지금 바로, 가장 안전하고 직관적인 개발을 경험해보세요.

2026년, 왜 다시 jQuery인가? : 복잡함에 지친 개발자들을 위한 제안

SoliEstre — Fri, 28 Nov 2025 09:58:39 +0900

"또 새로운 프레임워크야?" "빌드 설정만 하다가 하루가 다 갔네..."

2025년을 넘어 2026년을 바라보는 지금, 프론트엔드 생태계는 그 어느 때보다 거대하고 복잡해졌습니다. React, Next.js, Server Components, Hydration... 훌륭한 기술들이지만, 가끔은 이런 생각이 들지 않으신가요?

"그냥 index.html 하나 만들고 바로 코딩하면 안 되나?"

빌드 없는 자유, 그리고 '앱' 같은 경험

우리가 웹 개발을 처음 시작했을 때를 떠올려보세요. 메모장을 열고, 태그를 적고, 브라우저를 새로고침하면 끝이었습니다. 그 단순함과 직관성이 그리운 분들을 위해, 그리고 여전히 그 방식이 유효하다고 믿는 분들을 위해 EstreUI를 소개합니다.

EstreUI가 뭔가요?

EstreUI는 거창한 프레임워크가 아닙니다. 우리는 이것을 "Rimwork (Runnable Frame)"라고 부릅니다. 자동차로 치면 엔진부터 조립하는 게 아니라, 이미 잘 굴러가는 튼튼한 섀시(Rim)를 제공해 드리는 겁니다. 여러분은 그 위에 원하는 시트와 핸들만 얹으시면 됩니다.

가장 큰 특징은 "jQuery 문법 그대로, 네이티브 앱 같은 UX를 만든다"는 점입니다.

왜 지금 jQuery인가요?

많은 사람들이 "jQuery는 죽었다"고 말합니다. 하지만 전 세계 웹사이트의 70%는 여전히 jQuery를 사용합니다.

직관성: $('#id').show()보다 직관적인 코드는 아직 없습니다.
생산성: 복잡한 상태 관리(State Management)나 Props Drilling 없이, 그냥 눈에 보이는 요소를 제어하면 됩니다.
No Build: Webpack, Vite, Babel... 다 필요 없습니다. 그냥 <script> 태그 한 줄이면 준비 끝입니다.

EstreUI의 핵심 기능

Android Activity 같은 생명주기
- 웹에서도 onCreate, onShow, onPause 같은 라이프사이클을 사용할 수 있습니다.
- 안드로이드 개발자라면 설명서 없이도 바로 이해할 수 있는 구조입니다.
부드러운 화면 전환 (Transition)
- SPA(Single Page Application)의 핵심인 부드러운 페이지 이동을 기본 지원합니다.
- 이전 단계를 기억하는 세미 스택(Semi-Stack) 네비게이션을 지원합니다.
  - 1.2.0 버전부터 멀티 인스턴스(Multi Instance)를 정식 지원하면서 풀 스택(Full-Stack) 네비게이션을 지원합니다.
강력한 데이터 바인딩 (Active Struct)
- jQuery의 단점인 "데이터-UI 동기화"를 해결했습니다.
- data-bind 속성만 넣으면 데이터가 변할 때 화면이 자동으로 바뀝니다. (React 부럽지 않죠?)

백문이 불여일견

말로만 설명하면 와닿지 않으실 겁니다. EstreUI로 만든 데모 앱을 직접 확인해보세요.

마치며: 레거시가 아니라, 클래식입니다.

오래된 것이 낡은 것은 아닙니다. 익숙한 도구로 가장 빠르게, 가장 훌륭한 결과물을 낼 수 있다면 그것이 바로 최고의 기술입니다.

React의 복잡함에 지치셨나요? 혹은 기존 레거시 프로젝트를 모바일 앱처럼 리뉴얼해야 하는 미션을 받으셨나요? EstreUI가 가장 현실적이고 강력한 대안이 될 수 있습니다.

이 글은 EstreUI 개발팀에서 작성되었습니다.