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

> Clean Markdown view of GeekNews topic #23960. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=23960](https://news.hada.io/topic?id=23960)
- GeekNews Markdown: [https://news.hada.io/topic/23960.md](https://news.hada.io/topic/23960.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-10-28T09:54:55+09:00
- Updated: 2025-10-28T09:54:55+09:00
- Original source: [github.com/longbridge](https://github.com/longbridge/gpui-component)
- Points: 18
- Comments: 1

## Summary

Rust 생태계에 새 바람을 불어넣는 **gpui-component**는 GPUI 렌더 엔진 위에서 동작하는 **크로스플랫폼 UI 컴포넌트 라이브러리**로, macOS·Windows의 네이티브 감각과 **shadcn/ui**의 현대적 디자인을 절묘하게 결합합니다. **가상화 테이블**, **LSP 기반 코드 에디터**, **Markdown/HTML 렌더링** 등 실무 중심 기능을 갖춰, Rust로도 이제 “진짜 데스크톱 앱”을 만들 수 있다는 자신감을 줍니다. 단순한 위젯 모음이 아니라 **테마·도킹·i18n**까지 고려한 완성도 높은 프레임워크라, Iced나 egui로는 부족했던 개발자에게 특히 매력적으로 다가옵니다.

## Topic Body

- **Rust 기반 GPUI 프레임워크**를 활용해 크로스플랫폼 데스크톱 애플리케이션을 구축할 수 있는 **UI 컴포넌트 라이브러리**  
- 60개 이상의 **네이티브 스타일 UI 컴포넌트**를 제공하며, macOS·Windows 디자인 감각과 **shadcn/ui**의 현대적 미학을 결합  
- **가상화 테이블**, **고성능 코드 에디터**, **Markdown/HTML 렌더링**, **차트 시각화** 등 풍부한 기능을 내장  
- **테마 시스템**, **다국어(i18n)** , **도킹 레이아웃** 등 확장성과 커스터마이징을 중시한 설계  
- Rust 생태계에서 **Iced**, **egui**, **Qt** 등과 비교해 현대적 UI 스타일과 대규모 데이터 처리 성능에서 차별화된 의미  
  
---  
  
### 프로젝트 개요  
- **gpui-component**는 Rust로 작성된 **크로스플랫폼 데스크톱 UI 컴포넌트 모음**으로, GPUI 렌더 엔진을 기반으로 동작  
  - 목표는 “fantastic desktop applications”을 빠르고 일관된 방식으로 구축할 수 있게 하는 것  
  - 공식 사이트는 [longbridge.github.io/gpui-component](https://longbridge.github.io/gpui-component)  
- **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 레이어 후보**로 주목받는 프로젝트

## Comments



### Comment 45531

- Author: neo
- Created: 2025-10-28T09:54:55+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=45719004) 
- Rust UI 생태계에서 이건 지금까지 본 것 중 **가장 완성도 높은 컴포넌트 컬렉션**처럼 보임  
  아직 사용 사례는 거의 없지만, 문서가 점점 잘 정리되고 있음  
  비슷하게 완성도가 높은 다른 예로는 [fyrox-ui](https://crates.io/crates/fyrox-ui)가 있음. 다만 fyrox 엔진 외부에서는 거의 쓰이지 않음  
  Rust UI는 점점 성숙해지고 있지만, iced, egui, dioxus, slint 같은 인기 프레임워크들이 컴포넌트 완성도 면에서는 아직 부족해 보임  
  업데이트하자면, 이 프로젝트는 Rust UI 생태계에서 **큰 진전**을 보여줌.  
  모든 컴포넌트를 볼 수 있는 위젯 갤러리 앱을 [여기서 실행](https://github.com/longbridge/gpui-component/tree/main/crates/story)할 수 있음 — `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](https://zed.dev) 팀이 유지하고 있고, Longbridge는 [Longbridge Pro 앱](https://longbridge.com/desktop/)을 만드는 일반 브로커리지 회사로 보임. 특별히 문제될 건 없어 보임
  - **비트코인 정신**이 해커 문화와 닮았다고 생각함. “망가진 걸 고치자”는 태도 말임. 단기적 고통이 장기적 이익으로 이어질 수도 있음
  - Rust나 OCaml(Jane Street) 같은 일부 생태계에서는 그런 경향이 있지만, 전체적으로는 과장된 주장 같음
  - React를 만든 Facebook은 **Cambridge Analytica 스캔들**이나 **로힝야 학살** 같은 사건에 연루됐음. 그런 점에서 보면, 트레이딩/크립토 회사들이 오픈소스에 기여하는 건 오히려 도덕적으로 나은 일일 수도 있음

- 요즘 “모던” UI 툴킷들은 **시각적 UI 에디터**가 없는지 궁금함  
  Qt는 QtCreator나 QtDesigner 같은 도구로 드래그 앤 드롭만으로 UI를 만들 수 있었음  
  또, Qt 관련 비교표의 일부 항목이 틀렸음 — 예를 들어 최소 바이너리 크기나 QSyntaxHighlighter 설명 등
  - [Slint](https://slint.dev/) 같은 프레임워크는 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는 단순히 프레임마다 호출되는 **라이브러리형 구조**임

- 시각장애인용 **스크린 리더 접근성**이 잘 동작하는지 궁금함
  - 직접 실행해보진 않았지만, [공식 문서](https://longbridge.github.io/gpui-component/docs/components/list#accessibility)에 따르면 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](https://docs.rs/rfd/latest/rfd/) 같은 외부 라이브러리를 써야 해서 스타일 일관성이 깨짐
  - 스타일 일관성이 깨지는 건 오히려 **좋은 일**임. 사용자는 앱 간의 일관성을 원함. 즉, OS 네이티브 대화상자가 더 익숙함. Blender나 Photoshop 같은 전문 소프트웨어는 예외지만, 일반 앱은 네이티브가 낫다고 봄
  - 대부분의 UI 라이브러리도 최소한의 **네이티브 통합**은 필요함. 단축키, 시스템 메뉴, 파일 대화상자, 컨텍스트 메뉴 같은 것들 말임. 이런 부분이 사용자 친숙도를 높임
  - 파일 선택기는 반드시 **OS 기본 대화상자**를 써야 함. 직접 구현하는 건 좋지 않음