# XMLUI > Clean Markdown view of GeekNews topic #22084. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=22084](https://news.hada.io/topic?id=22084) - GeekNews Markdown: [https://news.hada.io/topic/22084.md](https://news.hada.io/topic/22084.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-07-21T09:42:32+09:00 - Updated: 2025-07-21T09:42:32+09:00 - Original source: [blog.jonudell.net](https://blog.jonudell.net/2025/07/18/introducing-xmlui/) - Points: 2 - Comments: 1 ## Topic Body - **XMLUI**는 Visual Basic의 컴포넌트 개발 모델을 현대 웹에 적용하여, **React와 CSS 지식 없이도 웹 앱**을 간단하게 개발할 수 있음 - XMLUI는 다양한 **컴포넌트**를 XML 마크업으로 손쉽게 조합할 수 있으며, **리액티브 데이터 바인딩**, **테마 관리**, **스키마 확장** 등을 지원함 - **Model Context Protocol(MCP)** 를 통해 **AI와 협업**하여 개발 효율성 향상 및 코드의 유지보수성을 높일 수 있음 - XMLUI는 복잡한 React 생태계를 단순화함으로써 **비전문가도 손쉽게 UI 및 앱 개발**이 가능한 환경을 제공함 - **배포 및 확장**이 용이하며, 기존에 React·CSS를 잘 모르는 개발자도 다양한 웹 프로젝트와 CMS 구현 수행 가능함 --- ### 소개 및 개요 XMLUI 프로젝트는 **1990년대 Visual Basic**에서 찾을 수 있는 직관적인 컴포넌트 조합 방식을 웹 환경으로 가져오려는 시도임. 당시 Visual Basic을 통해 전문 프로그래머가 아니더라도 다양한 컴포넌트를 연결하여 유용한 소프트웨어를 쉽게 만들 수 있었음. 반면, 웹 환경에서는 이러한 수준의 사용성이나 생태계가 이루어지지 못했음. **XMLUI**는 React 컴포넌트와 CSS를 감싸고, XML 형태의 마크업만으로 웹 앱을 개발하게 해줌. 다음은 몇 줄의 XMLUI 코드 예시임: ``` <App> <Select id="lines" initialValue="bakerloo"> <Items data="https://api.tfl.gov.uk/line/mode/tube/status"> </Items> </Select> <Table data="{tubeStations}" height="280px"> <Column bindTo="name" /> <Column bindTo="modes" /> </Table> </App> ``` 이렇게 12줄 정도의 XML만으로도 다음 작업을 표현 가능함: - **API 호출을 통해 Select 옵션을 자동 채움** - Select의 값을 활용해 **다른 API에서 데이터 취득** - API 결과 내 특정 필드만을 추출하고, 이를 표 형태로 바인딩함 XMLUI는 **현대적인 컴포넌트 기반이며 리액티브(reactive)** 특성을 가지고 있으면서도, 사용자는 React나 CSS의 내부 지식 없이 개발, 유지보수가 가능함. 이 점이 기존의 JavaScript 생태계가 가진 장벽을 낮추는 중요한 차별점임. ### 컴포넌트 생태계 #### 과거와 현재 과거 Visual Basic 시대엔, 차트, 네트워크, 데이터 접근, 미디어 재생 등 다양한 **구성 요소(컴포넌트)** 를 쉽게 앱에 결합할 수 있었음. 그러나 이러한 생산적인 컴포넌트 생태계는 웹으로 온전히 옮겨지지 못함. React 기반의 컴포넌트가 현재 웹에서 주로 쓰이지만, 여전히 전문 개발자의 역량이 요구됨. **XMLUI는 이러한 React 컴포넌트들을 래핑하여 누구나 쉽게 쓸 수 있게 함.** #### 사용자 정의 컴포넌트 XMLUI는 **다채로운 내장 컴포넌트**는 물론, **직접 컴포넌트를 정의**하고, 필요에 따라 서로 조합 및 재사용이 가능함. 예를 들어, London 지하철역의 정보를 보여주는 `TubeStops` 컴포넌트를 다음과 같이 정의할 수 있음: ``` <Component name="TubeStops"> <DataSource ... /> <Text variant="strong">{...}</Text> <Table ... > <Column ... /> </Table> </Component> ``` `TubeStops`는 Line 이름별로 API에서 데이터를 받아와 표 형식으로 나타냄. 실제 마크업을 보면 가독성이 높고, 100줄 넘게 커지면 컴포넌트로 리팩터링하여 유지보수를 쉽게 할 수 있음. 최근에는 **LLM(대형 언어 모델)** 의 조력으로 컴포넌트 리팩터링 및 코드 유지보수가 더욱 유연해졌음. ### 리액티브 바인딩 및 선언적 개발 XMLUI에서 **데이터와 UI의 값 변화가 자동으로 연동**(Reactive Data Binding)됨. 예를 들어, `Select` 컴포넌트의 선택이 변경되면, 이를 참조하는 API 주소(`DataSource의 url`) 또한 자동으로 업데이트되어 새로운 데이터를 다시 조회함. 이런 방식은 Excel의 셀 참조와 유사함. 과거식 명령형 개발이 아닌 **선언적(Declarative) 개발 패러다임**에 익숙해질 필요가 있으나, 익숙해지면 빠르고 직관적인 개발 경험을 얻을 수 있음. 예로, 검색(Search) 기능을 구현할 때 버튼 없이 입력 박스의 값 변화만으로 데이터가 실시간 연동, 표에 반영되는 구조를 쉽게 만들 수 있음. ### 테마 시스템 처음에는 테마 시스템에 대한 관심이 크지 않았으나, XMLUI의 **테마 관리 기능**은 매우 강력함. **CSS 작성 없이**도 각 **컴포넌트의 색상, 배경, 여백, 폰트 등**을 변수 기반으로 일관되게 관리 가능함. 예시로, 버튼의 색상을 컨텍스트와 상태(hover 등)에 따라 다르게 지정할 수 있음. 테마는 `color-primary`, `backgroundColor-Button` 등의 형태로 세분된 제어가 가능하며, 전체적인 UI 컬러 팔레트를 손쉽게 정의하고 글로벌 혹은 세부적으로 적용 가능함. ### 스크립트 활용 XMLUI는 전체가 선언적이진 않음. Visual Basic처럼 **간단한 스크립트(주로 JavaScript)의 부분적 도입**이 가능하며, 예를 들어 API 응답 가공(transformResult), 조건부 렌더링 등에 활용함. 이는 복잡한 전문가 수준이 아니더라도 일반적인 개발자라면 충분히 활용 가능한 난이도임. ### Model Context Protocol(MCP) 및 AI 협업 "이젠 LLM이 React 앱을 바로 만들어주니 XMLUI의 의미가 뭔가?"라는 질문에, 작성자는 **코드의 접근성, 유지보수성, 협업성** 측면에서 XMLUI의 가치를 강조함. **MCP(Model Context Protocol)** 는 LLM 등의 에이전트가 XMLUI 코드/문서/예제를 검색, 파악, 인용할 수 있는 서버를 제공함. 이로써 AI 및 개발자가 동일한 의미망에서 소통, 코드를 점진적으로 자동 생성 및 수정을 조율할 수 있음. - 예: 특정 기능 사용법, 예제, 문서, 사용처를 LLM과 즉시 질의/응답하며 개발 진행 가능 LLM과 제대로 협업하기 위한 가이드라인도 제공됨. 예를 들면, 코드 제안 전 미리 논의, 문서화된 예제만 활용, 불필요한 스타일링 제한 등이 있음. 또한 문서 사이트에 "How To" 섹션, MCP 연동으로 AI도 쉽게 접근 가능한 구조를 마련함. ### 콘텐츠 관리 및 CMS 적용 XMLUI를 이용하면 **웹사이트 및 CMS** 구성도 쉽고, **React나 Next.js 지식 없이**도 일상적인 페이지 수정, 유지보수가 쉬움. 실제로 **XMLUI 공식 사이트, 데모, 문서** 등은 모두 XMLUI로 제작 및 유지되고 있음. 코드, 설명, 실시간 데모를 한 문서에서 모두 제공할 수 있어 실용적임. ### 확장성 기본적으로 XMLUI는 다양한 React 컴포넌트를 래핑하지만, **새로운 외부 컴포넌트 래핑도 용이**함. 예시로, 고급 문서 편집기 Tiptap을 XMLUI TableEditor로 손쉽게 래핑함. 실제로 Markdown 편집에서 어려운 부분(테이블 만들기 등)을 시각 편집기로 쉽게 해결할 수 있음. 이처럼, 기존에는 컴포넌트와 솔루션 개발자의 역할이 명확히 나뉘었으나, XMLUI를 통해 일반 개발자도 유용한 UI 컴포넌트를 직접 확장, 조합 가능함. ### 배포 XMLUI 앱의 배포는 **매우 간단**함. - 최소 구성: Main.xmlui, index.html, XMLUI JS 파일만 있으면 됨 - 어떠한 정적 웹서버든 사용 가능하며, AWS S3 버킷에서 바로 구동할 수 있음 - 복잡한 서버 환경이 필수가 아니며, 필요시 추가적인 로컬 서버, CORS 프록시 등도 구성할 수 있음 ### 모두를 위한 웹 개발 XMLUI의 창시자인 Gent Hito는 /n software, CData 등에서 개발 환경의 진입 장벽을 낮추는 데 주력해왔음. - /n software: 네트워크 컴포넌트의 손쉬운 사용 - CData: 데이터 접근의 간편화 - XMLUI: **UI 개발의 간소화** 최근 20여년 동안 웹의 UI 개발은 점점 전문화, 복잡화되어 왔으나, XMULI는 전문가가 아니더라도 솔루션 개발자가 자신만의 UI 및 앱을 쉽게 만들 수 있도록 설계됨. 실제로 CoreSSH 관련 대시보드 UI 등 다양한 예시에 바로 적용 가능함. 좀 더 쉬운 웹 앱 제작 환경을 원하는 모든 개발자, 특히 비전문가 솔루션 빌더, 주니어 개발자, 백엔드 중심 개발자들에게 적극적으로 권장됨. ## Comments ### Comment 41617 - Author: neo - Created: 2025-07-21T09:42:33+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=44625292) * Jon은 오랜 시간 동안 업계에 있었고, 나는 그의 팬임. 그는 많은 경험을 한 연륜 있는 사람이고, 그의 이야기를 들을 가치가 있음. 나는 웹 컴포넌트의 팬이지만, React가 주도적인 이유는 예전 Visual Basic 컴포넌트를 잘 활용했던 개발자들이 접근하기 어려운 환경 때문이라고 생각함. 이 점이 이 글에서 가장 중요한 부분임. 기술적 설명도 중요하지만, 왜 이런 시도가 필요한지 본질을 짚었음. XMLUI가 이런 개발자들에게 적합한 추상화를 제공할지는 지켜볼 필요가 있음. 그래도 이런 도전을 보는 것만으로 즐거움 * 현재 코드는 JS evergreen 브라우저에서만 동작함. 예전 VB가 윈도우와 특정 DLL 설치 환경에서만 제대로 동작했던 것과 비슷한 느낌임 * 2014년 쯤 Polymer에서도 이와 비슷한 시도가 있었음. 예를 들어 `<iron-ajax>` 같은 컴포넌트로 네트워크 요청을 구현했음 [iron-ajax 링크](https://github.com/PolymerElements/iron-ajax). 또 Adobe Flex가 한참 유행하던 시절이 있었고, 지금은 Apache Royale로 남아 있음 [Apache Royale 링크](https://apache.github.io/royale-docs/features/mxml). 마이크로소프트에서는 XAML, NetUI, FlexUI도 있었고, 오피스 2007 UI도 그렇게 만들어졌음. 이론적으로는 모두 멋졌지만, 실제로는 이런 마크업 기반 추상화가 초보자에게도 JSX와 같은 코드 우선 접근 방식보다 효과가 떨어졌다고 느꼈음 * Coldfusion도 있었음(추억에 몸서리침) * 나는 "우리는 HTML을 또다시 재발명하고 있다"는 생각과 "이건 내게 당장 쓸모 있을 것 같다"는 느낌을 동시에 가짐. 인간이란 원래 다면적 존재임 * Walt Whitman이라는 시인과 그 작업을 소개해주어서 고마움. "내가 스스로를 모순하는가? 그렇다면 나는 기꺼이 모순하는 사람이 되겠음" * 정말 공감가는 표현임. 결국 중요한 것은 이것이 실제로 너처럼 필요하다고 상상하는 사람들에게 곧바로 쓸모 있는가임 * 나는 Qt C++로 KDE에 7년간 오픈소스 기여를 했었음. 이 방식은 QtWidgets의 .ui 파일, 즉 특정 XML 스키마를 따르는 커스텀 UI 파일을 떠올리게 함. 나중에는 QML이 나왔지만 나에겐 비직관적이라 흥미를 잃었음. 하지만 여전히 UI 정의에 XML 사용은 말이 된다고 생각하고, 대규모 환경에서 여전히 쓰이는 게 이해가 됨 * 아직도 C++과 .ui 파일만으로 Qt를 쓰는 사람들이 있음. QML로 전환할 충분한 이유를 못 느꼈음 * Blizzard 게임 런처도 QT를 쓴다고 들었는데, Blizzard 소프트웨어의 UI 완성도가 항상 최고라고 생각함. 혹시 추천할 만한 Qt 프로젝트가 또 있을지 궁금함 * wxWidgets나 glade 파일도 같은 맥락임 * 내 생각에 최고의 GUI 접근 방식은 JUCE임. 모든 UI 요소가 C++ 클래스로, 그리기 함수가 따로 있음. 새로운 UI 요소는 다른 요소들을 합성해 또 다른 클래스로 만들 수 있고, 에디터가 소스코드를 자동 생성함. 버튼 등은 상태별(hover, pressed, active, disabled 등) 그리기 처리를 위한 if…else 영역이 큼. 내부적으로는 Metal/OpenGL/DirectX 등 얇은 드로잉 라이브러리를 사용함. 이런 완전 명령형(imperative) 방식이 신선함. 어디든 브레이크포인트 걸 수 있고, 어떤 파라미터로 어떻게 호출되는지 바로 확인 가능함. 렌더링 중간 결과를 imdraw로 내보내기도 쉬움. 폰트 안티앨리어싱만 빼면 거의 모든 플랫폼에서 픽셀 단위로 정확한 렌더링임. 그런데 여기서 소개되는 XML 방식은 내가 늘 피하려는 프레임워크 의존적 마법임. 앞으로 3번만 업데이트돼도 레이아웃이 조금씩 엇나갈 확신이 큼. 사용자가 직접 레이아웃을 제어하는 게 아니라 프레임워크의 자비를 구하는 셈임. Electron은 구형 기술(CSS 등) 위라 이런 문제를 조금이나마 덜 겪는데, 그렇지 않으면 레이아웃 제어에 늘 곤란을 겪게 됨 * JUCE는 사용 안 해봤지만, 예전 Qt에서 모든 게 C++ 클래스로 돼 있던 시절이 그립기도 함. 템플릿 언어가 대세지만, 클래스와 객체 조합식이 훨씬 읽기 쉽다고 느껴짐. 템플릿에서 가장 큰 장점은 "이 모듈이 부모 밑에 제대로 들어갔나?" 밖에 없는 듯함 * JUICE와 접근성에 대한 사용 경험을 공유해줄 분이 있으면 좋겠음 * JUCE는 잘 알지 못하지만, JUCE::Component가 DOM/canvas 요소와 비슷해 웹 플랫폼과 견줄 수 있을 듯. XMLUI는 오히려 JUCE 위의 선언적 UI 시스템(GUI Magic, JIVE, VITRO)과 비교돼야 함. 선언적, 명령형 UI는 양립 불가가 아님. SwiftUI, UIKit처럼 둘 다 쓰는 환경도 흔함 * JUCE는 안 써봤지만, 명령형은 구현이 커져도 일어나는 모든 일을 명확히 알 수 있으니 제어가 쉬움. 선언형은 언제나 탈출구가 필요한데, 이 탈출구가 항상 직접 만들거나 통과하기 어려움 * 오디오 개발 쪽에서 7년 간 썼고, 요즘은 그냥 모든 크로스 플랫폼 고성능 GUI/일반 앱에 JUCE를 씀. 한번이라도 쓸 만한 JUCE -> CI 파이프라인이 구축되면 정말 무한한 가능성이 열림. 하지만, 가끔은 JUCE의 모든 GUI 코드를 Lazarus 비슷한 프론트엔드, 예를 들면 LUA로 작성하고 C++와 섞어서 루아-씨++ 괴작을 만드는 것도 재미있겠다는 상상을 함 * XSLT를 언급하지 않은 게 아쉬움. 예전에 XML을 스타일링/트랜스폼하는 걸 고민한 적이 있는 사람들에게 현재의 발전이 얼마나 큰 도약인지 설명하는 데 중요한 요소라고 생각함. Jon Udell이 XSLT에 관해 글도 썼던 걸 보면 [참고 링크](https://www.xml.com/pub/a/2003/08/13/udell.html), 이번에 의도적으로 뺐던 것 같기도 한데, 그 이유를 잘 모르겠음 * XSLT가 쓰인 현장은 대부분 "원 저자 외에는 아무도 건드리기 무서워하는 복잡한 머리카락 뭉치"였음. 이 기술이 이상하게도 복잡성의 함정에 빠지거나 복잡성 페티시스트들을 끌어들이는 경향이 있음. 어쨌든 OP가 지향하는 목적에는 어울리는 선택지가 아니라고 생각함 * 역사적 참고가 필요하긴 하지만 이번 글의 목적은 과거에 집중하는 게 아니라 앞으로 나아가는 데 있음. 이 도구를 직접 써보고 UI 구축에 생산적인지 평가하는 게 글의 목적임 * 이 글에서는 XSLT가 크게 중요하지 않음. 현대 독자들에게 왜 이런 도구가 유용한지 설명하는 게 골자임. XSLT가 역사적으로 관련은 있지만, 여기서 언급하는 게 아이디어 전달에 도움 될 것 같진 않음 * oleh kiselyov의 SXML/SSAX를 알게 된 후부턴 XSLT를 완전히 접었음. SSAX는 내가 써본 것 중 최고의 XML 파서임 * 내 첫 XSLT 경험은 sketchers.com이었음 [Sketchy Skechers.com](https://thedailywtf.com/articles/Sketchy-Skecherscom). 아쉽게도 지금은 더 이상 사용하지 않는 것 같음 * 나는 최근 HTML, web components, signals 기반으로 비슷한 걸 만들고 있음. Heximal이라는 프로젝트임 [Heximal 링크](https://heximal.dev/). HTML에 표현식, 템플릿, 리액티비티, 컴포넌트 구조를 얹어 매우 모듈화되고 선언적인 앱이나 페이지를 만들면 뛰어난 기반이 된다고 생각함. HTML에 추가되는 많은 기능도 표준화될 수 있음 * 아이디어는 흥미롭지만, 모바일(Android+Firefox)에서는 사이트가 잘 보이지 않음 * 사이트가 읽기 어려움. HN 앱에서도 다른 댓글이 잘 안 보여서 다른 사람들이 같은 이슈 겪는지 모르겠음. 모바일 파이어폭스 기준임 * 모바일에서 텍스트가 일부 잘려 보이고 확대해도 해결되지 않음. 참고하길 바람 * 이 접근이 대세가 될 수도 있다고 생각함. C++가 대세가 된 것처럼 뒤로 호환성이 강력하다는 점이 정말 강점임 * RJSF의 uiSchema가 jsonSchema 모델 정의를 보완하는 프레젠테이션 레이어로 좋은 방향을 제시했다고 생각함 [uiSchema Reference 링크](https://rjsf-team.github.io/react-jsonschema-form/docs/api-reference/uiSchema/). 인상적으로 설계됐지만, 널리 퍼지지 않은 게 놀라웠던 기억임 * 나는 아직 보이지 않는 부분들에 대해 특히 기대가 큼. 견고한 엔지니어링에 더해, WYSIWYG 프로그래머(직관적으로 UI를 구성하는 개발자들)에 대한 배려가 확실할 것 같음. 어릴 때 Visual Basic 덕분에 프로그래밍에 접근할 수 있었다고 생각함. C++의 복잡한 포인터 없이도 쉽고 마법 같이 많은 것을 할 수 있었고, 이 흐름이 웹 프로그래밍에도 초보자 우선 접근법으로 연결되어, 반응성, 부드러움에 타협하지 않으면서 적절히 현실적 타협이 이뤄지길 바람. 더 흥미로운 것은 [https://docs.xmlui.com/mcp](https://docs.xmlui.com/mcp) 임. Claude 같은 도구가 UX/대시보드 코드를 생성할 때 필요한 토큰 수를 줄여 더 간결한 코드를 만들어낼 수 있음. 오늘부터 바로 써볼 생각임 * 사용 경험에 대해 꼭 알려주길 바람 * XAML(특히 범위가 좁은 실버라이트 버전)은 잘 활용하면 정말 즐거운 도구였음. 그러나 가장 쉽고 명백한(동시에 비효율적인) 방식으로 사용하면 끔찍하기도 했음. 아마도 HTML5나 도구의 부족으로 잊힌 것임. 좋은 도구는 초보자도 성공에 이르게 도와야 하는데, XAML은 그런 점에서 부족했음