▲

Rust 크로스플랫폼 GPUI 컴포넌트

 (github.com/longbridge)
10P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • Rust 기반 GPUI 프레임워크를 활용해 크로스플랫폼 데스크톱 애플리케이션을 구축할 수 있는 UI 컴포넌트 라이브러리
  • 60개 이상의 네이티브 스타일 UI 컴포넌트를 제공하며, macOS·Windows 디자인 감각과 shadcn/ui의 현대적 미학을 결합
  • 가상화 테이블, 고성능 코드 에디터, Markdown/HTML 렌더링, 차트 시각화 등 풍부한 기능을 내장
  • 테마 시스템, 다국어(i18n) , 도킹 레이아웃 등 확장성과 커스터마이징을 중시한 설계
  • Rust 생태계에서 Iced, egui, Qt 등과 비교해 현대적 UI 스타일과 대규모 데이터 처리 성능에서 차별화된 의미

프로젝트 개요

  • gpui-component는 Rust로 작성된 크로스플랫폼 데스크톱 UI 컴포넌트 모음으로, GPUI 렌더 엔진을 기반으로 동작
  • Apache-2.0 라이선스

주요 기능

  • 풍부한 컴포넌트 구성: 60개 이상의 UI 요소를 포함, 버튼·리스트·테이블·차트·에디터 등 다양한 구성 제공
  • 네이티브 감각 디자인: macOS와 Windows의 기본 컨트롤에서 영감을 받아 shadcn/ui 스타일을 결합한 현대적 인터페이스 구현
  • 간결한 사용성: 상태 없는 RenderOnce 컴포넌트 구조로 단순하고 직관적인 코드 작성 가능
  • 테마 및 색상 시스템: Theme과 ThemeColor를 통해 다중 테마 및 변수 기반 설정 지원
  • 유연한 레이아웃: Dock layout으로 패널 배치, 크기 조정, 자유로운 타일형 구성 가능
  • 고성능 렌더링: Virtualized Table/List로 대규모 데이터도 부드럽게 표시
  • 콘텐츠 렌더링: Markdown과 간단한 HTML을 네이티브로 지원
  • 차트 기능: 내장 차트로 데이터 시각화 가능
  • 코드 에디터: 최대 20만 줄까지 지원하는 LSP 기반 고성능 코드 편집기 포함
    • 진단, 자동완성, hover 등 기능 지원
  • 문법 하이라이팅: Tree Sitter를 이용해 에디터와 Markdown 모두에 구문 강조 제공

기술 스택 및 통계

  • 언어 구성: Rust 98.2%, Tree-sitter Query 0.8%, HTML 0.2%, Shell 0.2%, Python 0.1%, C 0.1%
  • 저장소 지표: 5.4k stars, 223 forks, 45명 이상의 기여자
  • 최신 릴리스: v0.3.1 (2025년 10월 27일)

요약적 의미

  • gpui-component는 Rust 생태계에서 현대적 UI/UX와 고성능 렌더링을 결합한 새로운 데스크톱 UI 프레임워크로 평가됨
  • 기존 Rust GUI 프레임워크의 한계를 보완하며, 대규모 데이터 처리·테마화·Markdown 통합 등 실무 친화적 기능을 제공
  • 향후 Rust 기반 크로스플랫폼 앱 개발의 표준화된 UI 레이어 후보로 주목받는 프로젝트
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • Rust UI 생태계에서 이건 지금까지 본 것 중 가장 완성도 높은 컴포넌트 컬렉션처럼 보임
    아직 사용 사례는 거의 없지만, 문서가 점점 잘 정리되고 있음
    비슷하게 완성도가 높은 다른 예로는 fyrox-ui가 있음. 다만 fyrox 엔진 외부에서는 거의 쓰이지 않음
    Rust UI는 점점 성숙해지고 있지만, iced, egui, dioxus, slint 같은 인기 프레임워크들이 컴포넌트 완성도 면에서는 아직 부족해 보임
    업데이트하자면, 이 프로젝트는 Rust UI 생태계에서 큰 진전을 보여줌.
    모든 컴포넌트를 볼 수 있는 위젯 갤러리 앱을 여기서 실행할 수 있음 — cargo run --release로 바로 가능함

    • gpui는 Zed Editor에서 분리된 프로젝트라, 실제 사용량은 다른 Rust UI 크레이트보다 훨씬 많을 것 같음
    • Fyrox는 Rust 게임 개발에 대한 회의감을 주는 존재임. 가장 성숙한 엔진인데도 아무도 쓰지 않음. 반면 Bevy의 ECS에만 사람들이 열광함. 결국 시스템 자체에만 흥미가 있었지, 진짜 게임을 만들고 싶었던 건 아닌 듯함
    • Rust UI 프레임워크들이 아직 빠르게 변화 중이라 완성도가 낮아 보이는 것 같음. 그래도 모멘텀은 확실히 있음. 나 혼자만의 경험이지만, 이미 Rust로 엔터프라이즈급 UI를 만들 수 있었음
    • Longbridge 앱을 직접 설치해봤는데, 진짜 Mac 네이티브 앱처럼 자연스럽게 동작함. Electron보다 훨씬 부드럽게 실행됨
    • 위젯 갤러리 앱은 인상적이지만, 900개 이상의 의존성이 있다는 점이 조금 걱정됨. GUI 앱에서는 이 정도가 일반적인지는 잘 모르겠음

  • 가장 단순한 예제조차 1000개 이상의 의존성을 가짐. GTK, GDK, pango 같은 툴킷에 의존하고 있음. 다른 툴킷을 또 의존하는 구조가 좀 이상하게 느껴짐

    • GNOME이 서버 사이드 데코레이션을 구현하지 않아서 libadwaita에 의존해야 함. 이게 GTK 관련 의존성을 다 끌어오는 원인 같음
    • Linux에서는 이런 구조가 흔함. 상위 윈도우나 메뉴를 그리기 위해 GTK나 Qt를 사용하는 게 일반적임
    • 작고 조합 가능한 의존성 1000개가 낫다고 생각함. 거대한 단일 코드베이스보다 훨씬 감사(audit)하기 쉬움
    • 요즘 Rust 프로젝트들이 점점 이런 식으로 커지는 게 아쉬움

  • 오픈소스의 많은 기반 기술이 트레이딩·크립토 회사에서 만들어지는 게 씁쓸함. 그래도 사회에 뭔가 기여한다는 점은 긍정적임

    • gpui는 Zed.dev 팀이 유지하고 있고, Longbridge는 Longbridge Pro 앱을 만드는 일반 브로커리지 회사로 보임. 특별히 문제될 건 없어 보임
    • 비트코인 정신이 해커 문화와 닮았다고 생각함. “망가진 걸 고치자”는 태도 말임. 단기적 고통이 장기적 이익으로 이어질 수도 있음
    • Rust나 OCaml(Jane Street) 같은 일부 생태계에서는 그런 경향이 있지만, 전체적으로는 과장된 주장 같음
    • React를 만든 Facebook은 Cambridge Analytica 스캔들이나 로힝야 학살 같은 사건에 연루됐음. 그런 점에서 보면, 트레이딩/크립토 회사들이 오픈소스에 기여하는 건 오히려 도덕적으로 나은 일일 수도 있음

  • 요즘 “모던” UI 툴킷들은 시각적 UI 에디터가 없는지 궁금함
    Qt는 QtCreator나 QtDesigner 같은 도구로 드래그 앤 드롭만으로 UI를 만들 수 있었음
    또, Qt 관련 비교표의 일부 항목이 틀렸음 — 예를 들어 최소 바이너리 크기나 QSyntaxHighlighter 설명 등

    • Slint 같은 프레임워크는 Figma 통합을 지원해서 Qt Design Studio처럼 쓸 수 있음. 예전 네이티브 GUI 디자이너들이 얼마나 강력했는지 요즘은 잘 모르는 듯함
    • 완성도 높은 컴포넌트 라이브러리를 기반으로 하면 이런 시각적 에디터도 Rust에서 구현 가능함. XML/마크업 기반 구조를 매크로로 연결하고, 실시간 미리보기 앱을 만들면 Glade나 XAML처럼 동작할 수 있음
    • Qt의 최소 크기는 실제로는 20MB보다 작지만, 일반적으로는 30~40MB 정도임. Core, Gui, QML, Widget 모듈이 각각 8MB 정도라 Hello World도 2~3개는 필요함
    • Qt Designer는 단순한 UI에는 괜찮지만, 커스텀 스타일링을 적용하면 금방 망가짐. 그래서 결국 수동으로 UI 파일을 작성했음. 훨씬 깔끔하고 작아졌음
    • Qt6가 테마를 지원하지 않는다는 건 완전히 틀린 주장임

  • 아쉽게도 이건 프레임워크임. 즉, 자체 이벤트 루프를 가져야 함
    이미 다른 루프가 있는 환경에서는 통합이 어려움. 반면 egui는 단순히 프레임마다 호출되는 라이브러리형 구조임

  • 시각장애인용 스크린 리더 접근성이 잘 동작하는지 궁금함

    • 직접 실행해보진 않았지만, 공식 문서에 따르면 ARIA 규격을 지원함. 필요한 라벨과 설명만 추가하면 됨
    • 하지만 Zed Editor는 스크린 리더에 완전히 불투명함. 그래서 큰 기대는 하지 않음
    • 새로운 UI 프레임워크를 볼 때마다 내가 제일 먼저 묻는 게 바로 접근성임

  • “네이티브”라는 게 웹이 아니라는 뜻인지, 아니면 OS의 기본 위젯을 사용하는지 궁금함. Java 진영도 이 차이를 크게 겪었음

    • macOS만이 진짜 네이티브 앱을 만들 수 있는 플랫폼임. Linux는 GTK/Qt로 나뉘고, Windows는 너무 많은 프레임워크가 섞여 있어서 WebView조차 네이티브처럼 보일 수 있음
    • 여기서 말하는 네이티브는 “웹이 아님”이라는 뜻임. GPU API로 직접 그리는 구조임
    • 즉, 네이티브 실행 파일이지, OS 위젯을 쓰는 건 아님
    • OS 통합은 없고, 완전히 자체 렌더링 방식임

  • 이 프레임워크가 접근성(a11y) 을 구현했는지 궁금함. Rust UI들은 종종 예쁘지만 접근성 요구가 생기면 전면 재작성해야 함

    • 접근성을 중시한다면 Dioxus를 고려할 만함. 다만 이 정도로 완성된 컴포넌트 라이브러리는 아직 없음
    • GPUI는 Zed 팀이 만든 기반 위에 있지만, 스크린 리더에는 여전히 불투명함. 접근성이 중요하다면 Slint나 Qt(cxx-qt) 쪽이 낫고, System76이 Iced를 채택했으니 그쪽도 개선될 듯함
    • 접근성은 구현되어 있음

  • 가상화된 리스트와 테이블 기능이 정말 훌륭함. 많은 UI 프레임워크들이 이걸 직접 구현해야 해서 불편했음

  • Rust에는 GUI 툴킷은 많지만, 재사용 가능한 컴포넌트 컬렉션은 부족함
    이 컬렉션은 유용해 보이지만, 대부분 웹 프레임워크의 컴포넌트 목록과 비슷함. 네이티브 특화 요소는 webview 정도뿐임. 파일 열기 대화상자 같은 건 rfd 같은 외부 라이브러리를 써야 해서 스타일 일관성이 깨짐

    • 스타일 일관성이 깨지는 건 오히려 좋은 일임. 사용자는 앱 간의 일관성을 원함. 즉, OS 네이티브 대화상자가 더 익숙함. Blender나 Photoshop 같은 전문 소프트웨어는 예외지만, 일반 앱은 네이티브가 낫다고 봄
    • 대부분의 UI 라이브러리도 최소한의 네이티브 통합은 필요함. 단축키, 시스템 메뉴, 파일 대화상자, 컨텍스트 메뉴 같은 것들 말임. 이런 부분이 사용자 친숙도를 높임
    • 파일 선택기는 반드시 OS 기본 대화상자를 써야 함. 직접 구현하는 건 좋지 않음
답변달기