▲

XMLUI

 (blog.jonudell.net)
1P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • 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>
  <DataSource
    id="tubeStations"
    url="https://api.tfl.gov.uk/Line/{lines.value}/Route/Sequence/inbound";
    resultSelector="stations"/>
  <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 등 다양한 예시에 바로 적용 가능함.

좀 더 쉬운 웹 앱 제작 환경을 원하는 모든 개발자, 특히 비전문가 솔루션 빌더, 주니어 개발자, 백엔드 중심 개발자들에게 적극적으로 권장됨.

▲
GN⁺ 4일전  [-]
Hacker News 의견

  • Jon은 오랜 시간 동안 업계에 있었고, 나는 그의 팬임. 그는 많은 경험을 한 연륜 있는 사람이고, 그의 이야기를 들을 가치가 있음. 나는 웹 컴포넌트의 팬이지만, React가 주도적인 이유는 예전 Visual Basic 컴포넌트를 잘 활용했던 개발자들이 접근하기 어려운 환경 때문이라고 생각함. 이 점이 이 글에서 가장 중요한 부분임. 기술적 설명도 중요하지만, 왜 이런 시도가 필요한지 본질을 짚었음. XMLUI가 이런 개발자들에게 적합한 추상화를 제공할지는 지켜볼 필요가 있음. 그래도 이런 도전을 보는 것만으로 즐거움

    • 현재 코드는 JS evergreen 브라우저에서만 동작함. 예전 VB가 윈도우와 특정 DLL 설치 환경에서만 제대로 동작했던 것과 비슷한 느낌임

  • 2014년 쯤 Polymer에서도 이와 비슷한 시도가 있었음. 예를 들어 <iron-ajax> 같은 컴포넌트로 네트워크 요청을 구현했음 iron-ajax 링크. 또 Adobe Flex가 한참 유행하던 시절이 있었고, 지금은 Apache Royale로 남아 있음 Apache Royale 링크. 마이크로소프트에서는 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에 관해 글도 썼던 걸 보면 참고 링크, 이번에 의도적으로 뺐던 것 같기도 한데, 그 이유를 잘 모르겠음

    • XSLT가 쓰인 현장은 대부분 "원 저자 외에는 아무도 건드리기 무서워하는 복잡한 머리카락 뭉치"였음. 이 기술이 이상하게도 복잡성의 함정에 빠지거나 복잡성 페티시스트들을 끌어들이는 경향이 있음. 어쨌든 OP가 지향하는 목적에는 어울리는 선택지가 아니라고 생각함
    • 역사적 참고가 필요하긴 하지만 이번 글의 목적은 과거에 집중하는 게 아니라 앞으로 나아가는 데 있음. 이 도구를 직접 써보고 UI 구축에 생산적인지 평가하는 게 글의 목적임
    • 이 글에서는 XSLT가 크게 중요하지 않음. 현대 독자들에게 왜 이런 도구가 유용한지 설명하는 게 골자임. XSLT가 역사적으로 관련은 있지만, 여기서 언급하는 게 아이디어 전달에 도움 될 것 같진 않음
    • oleh kiselyov의 SXML/SSAX를 알게 된 후부턴 XSLT를 완전히 접었음. SSAX는 내가 써본 것 중 최고의 XML 파서임
    • 내 첫 XSLT 경험은 sketchers.com이었음 Sketchy Skechers.com. 아쉽게도 지금은 더 이상 사용하지 않는 것 같음

  • 나는 최근 HTML, web components, signals 기반으로 비슷한 걸 만들고 있음. Heximal이라는 프로젝트임 Heximal 링크. HTML에 표현식, 템플릿, 리액티비티, 컴포넌트 구조를 얹어 매우 모듈화되고 선언적인 앱이나 페이지를 만들면 뛰어난 기반이 된다고 생각함. HTML에 추가되는 많은 기능도 표준화될 수 있음

    • 아이디어는 흥미롭지만, 모바일(Android+Firefox)에서는 사이트가 잘 보이지 않음
    • 사이트가 읽기 어려움. HN 앱에서도 다른 댓글이 잘 안 보여서 다른 사람들이 같은 이슈 겪는지 모르겠음. 모바일 파이어폭스 기준임
    • 모바일에서 텍스트가 일부 잘려 보이고 확대해도 해결되지 않음. 참고하길 바람
    • 이 접근이 대세가 될 수도 있다고 생각함. C++가 대세가 된 것처럼 뒤로 호환성이 강력하다는 점이 정말 강점임

  • RJSF의 uiSchema가 jsonSchema 모델 정의를 보완하는 프레젠테이션 레이어로 좋은 방향을 제시했다고 생각함 uiSchema Reference 링크. 인상적으로 설계됐지만, 널리 퍼지지 않은 게 놀라웠던 기억임

  • 나는 아직 보이지 않는 부분들에 대해 특히 기대가 큼. 견고한 엔지니어링에 더해, WYSIWYG 프로그래머(직관적으로 UI를 구성하는 개발자들)에 대한 배려가 확실할 것 같음. 어릴 때 Visual Basic 덕분에 프로그래밍에 접근할 수 있었다고 생각함. C++의 복잡한 포인터 없이도 쉽고 마법 같이 많은 것을 할 수 있었고, 이 흐름이 웹 프로그래밍에도 초보자 우선 접근법으로 연결되어, 반응성, 부드러움에 타협하지 않으면서 적절히 현실적 타협이 이뤄지길 바람. 더 흥미로운 것은 https://docs.xmlui.com/mcp 임. Claude 같은 도구가 UX/대시보드 코드를 생성할 때 필요한 토큰 수를 줄여 더 간결한 코드를 만들어낼 수 있음. 오늘부터 바로 써볼 생각임

    • 사용 경험에 대해 꼭 알려주길 바람

  • XAML(특히 범위가 좁은 실버라이트 버전)은 잘 활용하면 정말 즐거운 도구였음. 그러나 가장 쉽고 명백한(동시에 비효율적인) 방식으로 사용하면 끔찍하기도 했음. 아마도 HTML5나 도구의 부족으로 잊힌 것임. 좋은 도구는 초보자도 성공에 이르게 도와야 하는데, XAML은 그런 점에서 부족했음

답변달기