요약
Rune은 에이전트가 화면 없이 렌더링하고 조작해 검증할 수 있게 만든 Rust GPU UI 프레임워크입니다.
어노멀리(Anomaly)가 MIT 라이선스로 공개했고, 렌더러와 텍스트, 레이아웃, 스프링 애니메이션을 모두 직접 구현했습니다. 저장소에는 opencode 테마와 코딩 에이전트 앱 데모가 함께 들어 있습니다.
왜 중요한가
- 사람이 화면을 보며 다듬는 대신 코딩 에이전트가 앱을 만들고 결과를 스스로 확인하는 개발 방식을 전제로 설계했습니다.
- 풀 리퀘스트 대신 이슈만 받아 에이전트가 처리하는 운영 방식을 내세워, LLM 시대의 오픈소스 기여 방식을 두고 논쟁을 불렀습니다.
핵심 내용
- 모든 앱을 헤드리스(화면 없이 실행)로 돌려 PNG로 렌더링하고, 요소 트리를 출력하고, 스크립트 입력으로 조작할 수 있습니다.
- 풀 리퀘스트는 받지 않으며, 에이전트로 이슈를 올리면 프로젝트 쪽 에이전트가 빠르게 처리한다고 안내합니다.
- 프레임마다 그리기 호출 한 번으로 화면을 그리고, macOS에서는 자체 Metal 백엔드를, 그 밖에는 wgpu를 씁니다.
- 레이아웃은 Taffy, 글자 배치는 Parley로 처리하며 macOS와 윈도 고유의 글꼴 렌더링을 흉내 냅니다.
- 아직 정식 출시 전이라 버전 대신 dev 브랜치의 특정 커밋을 고정해 쓰라고 권합니다.
HN 반응
- 바이브 코딩(AI에 맡겨 짠 코드)으로 만든 프로젝트라는 비판과 함께 egui, Iced, Slint, GPUI 같은 기존 프레임워크를 쓰라는 권유가 나왔습니다.
- 이슈만 받는 방침에는 엉성한 PR이 쏟아지는 것을 막는 현실적인 선택이라는 평가와, 손으로 기여하려는 초보자를 막는다는 아쉬움이 맞섰습니다.
GPU로 렌더링하는 러스트 UI 프레임워크에 관심이 있으시다면, 이 바이브 코딩 프로젝트는 건너뛰고 아래의 검증된 프로젝트들을 살펴보시길 권합니다.
제가 직접 고른 목록이고, crates.io 다운로드 수 순으로 정렬했습니다. 다운로드 수와 링크는 LLM에게 가져오게 했습니다. Tauri나 Dioxus Desktop 같은 웹뷰 기반 UI는 뺐고, 네이티브 툴킷 바인딩과 GTK도 뺐습니다.
제 생각에 러스트용 GUI 크레이트 중 최고는 윈도에서는 windows나 native-windows-gui, 맥OS에서는 objc2나 icrate, 리눅스에서는 gtk4-rs입니다. 사실 맥OS나 iOS라면 uniffi로 러스트 코어를 SwiftUI 앱에 끼워 넣어 쓰겠습니다.
2026년인 지금은 어떤 크로스 플랫폼 UI를 쓰려고 애쓰는 것보다, LLM으로 네이티브 프런트엔드 세 개를 동기화해 두는 편이 훨씬 낫다고 봅니다.
왜 그런지 설명해 주실 수 있나요? 색상 때문인가요? 뭐라 말하기 힘든 그 특유의 느낌인가요? 위젯의 둥글기나 글꼴 때문인가요? 성능인가요? 키보드 단축키인가요? 정말로 LLM으로 프런트엔드 세 개를 유지하는 게 EGUI, GPUI, QT 같은 걸 쓰는 것보다 쉽다고 느끼시나요?
지난주 HN의 GUI 프레임워크 글마다 이런 제안을 여러 번 봤습니다(요즘 GUI 글이 갑자기 늘었죠!). 그런데 항상 이유는 없이 말씀하신 방식 그대로입니다. 네이티브 UI 킷(OS 계열마다 하나씩 따로 필요한 것들)이 더 우월하고, 크로스 플랫폼은 "열등한 경험"이라고 단정만 합니다. 세 번이나 물어봤는데 답을 받은 적이 없습니다. 저는 윈도와 리눅스를 둘 다 늘 쓰는데, 앱을 실행하고 나면 기능상으로는 둘이 똑같다고 느낍니다. ABI, 드라이버, 파일 시스템 차이 같은 건 있지만, 특정 기능을 쓸 때 기능 게이트로 매끄럽게 처리하면 됩니다.
저는 앱에 필요한 기능이 다 있고, 빠르게 돌아가고, UI가 괜찮기를 바랍니다. 위젯이 제 다른 앱이나 OS 기본 앱과 같아 보이든 말든 상관없습니다. 애초에 표준화된 게 별로 없어서 그런 건 문제가 되지도 않고요. 어쩌면 맥에서는 표준화가 잘 돼 있어서 크로스 플랫폼 킷이 어색해 보일지도 모르겠네요?
"LLM으로 네이티브 킷 세 벌을 바이브 코딩한다"는 방식에도 따져볼 단점이 있습니다. 룩앤필이든 뭐든 이유를 들어 윈도 전용 등으로 만드는 것도 단점이 있고요. 제 생각에 요즘 OS들은 서로 너무 비슷해서 PC 소프트웨어는 거의 다 크로스 플랫폼이어야 합니다. 예외는 대체로 드라이버와 드라이버에 가까운 코드뿐입니다.
요즘은 윈도와 리눅스가 정말 비슷하게 느껴져서, 오갈 때 딱히 불편함이 없습니다. 그런데 맥을 쓰려고 하면 이야기가 완전히 달라져요. 그 OS는 도무지 이해가 안 됩니다. 키보드 단축키가 전부 정말 끔찍한 선택으로 보이고, 일관성도 없고, 다른 OS와 엄청나게 벌어져 있어요. 90년대에 갇혀 있는 느낌입니다.
일리가 있네요. 이 간극을 설명하는 제 가설은, 그런 비판이 맥의 관용을 기대하는 사람들에게서 나왔다는 겁니다. 저는 맥은 잘 몰라서 말씀드릴 수 없지만요. 윈도와 리눅스는 룩앤필이 원래부터 제각각이니까요.
네이티브 프런트엔드 세 개를 맞춰 가며 커스텀 비주얼 컴포넌트까지 유지하다 보면, 결국 크로스 플랫폼 UI를 만들고 있는 셈입니다. 커스텀 컴포넌트 없이 만들 수 있는 앱은 사소한 것들뿐이죠.
셋 다 웹뷰를 내장할 방법이 있습니다. 제 경험이 짧을 수도 있지만, 커스텀 비주얼 컴포넌트를 원하는 이유는 대부분 억지이거나 읽기 전용 화면 때문이었습니다. 저는 컨트롤은 모두 네이티브여야 한다고 보지만, 화려한 데이터 표현이 필요하다면 웹뷰를 쓰는 데 거리낌이 없습니다.
웹뷰가 접근성(그리고 UI 자동화)을 제대로 지원하기만 한다면, 대부분의 애플리케이션에는 아주 합리적인 방법 같습니다.
말이 나온 김에 제 꿈은 "HTML 라이트" 표준입니다. 로컬 UI용으로 설계한 기능 부분집합만 담고, 이 표준을 지원하는 가벼운 비브라우저 엔진이 모든 주요 OS 플랫폼에 공유 시스템 컴포넌트로 들어 있으면 좋겠어요.
8MB RAM 시스템에서도 돌아가는 브라우저가 있었잖아요. 공정한 비교는 아니겠지만, 램이 천 배 가까이 많은 시스템이 렌더링에 HTML과 JavaScript를 쓴다는 이유만으로 애플리케이션 몇 개 이상 돌리기 버거워할 기술적 이유는 없습니다.
제가 바로 그런 가벼운 브라우저 엔진을 만들고 있습니다. https://github.com/dioxuslabs/blitz 입니다. HTML/CSS 대부분을 지원하되, 브라우저가 끌어안고 있는 부가 기능은 많이 빼거나 선택 사항으로 두었습니다. 스크립팅 계층에서 JavaScript 대신 러스트를 쓸 수도 있고요.
다만 8MB RAM은 현실적이지 않습니다. 4K에서 RGBA 텍스처 하나가 약 30MB이고, 요즘 시스템은 버퍼링용으로 2~3개가 필요한 경우가 많으니까요. 적어도 맥OS에서는 요즘 환경의 기본선이 60MB에서 100MB 사이쯤 되는 것 같습니다.
새 규칙을 제안합니다. UI 경험이 짧은 프로그래머(저도 포함입니다)는 UI 디자이너와 개발자에게 뭐가 필요한지 왈가왈부하지 말 것.
이 방식의 장점은 모든 사람의 스크린 리더와 그 밖의 접근성 도구가 여러분의 앱에서 실제로 작동한다는 점입니다.
https://crates.io/crates/dioxus-native 는 3개월 전에 릴리스됐고 GitHub 링크도 없어서, 아직 검증된 프로젝트로 보기는 어렵다고 생각합니다.
(제가 dioxus native 메인테이너이고, 위 댓글도 제가 썼습니다.)
그래서 말씀드리면,
첫 버전은 1년도 더 전에 나왔습니다. 3개월 전이라는 건 안정 버전의 가장 최근 패치 릴리스입니다.
Dioxus 프로젝트( https://github.com/dioxuslabs/dioxus )의 일부이고, 이 프로젝트는 2021년부터 이어져 왔습니다(다만 다른 렌더러는 웹/웹뷰 기반입니다).
네이티브 렌더러( https://github.com/dioxuslabs/blitz )는 2024년 12월부터 개발 중입니다(웹 엔진을 통째로 새로 만드는 일은 그냥 규모가 큰 프로젝트입니다).
결국 1~4위만큼 검증되지 않았다는 말씀은 맞습니다. 그래도 목록 아래쪽의 다른 프레임워크들과 같은 자리에 둘 만하다고 생각합니다. 기술적으로 위쪽 프레임워크들과 겨룰 만한, 덜 알려진 프레임워크 중 하나니까요.
dioxus native, 벌써 안드로이드에서 쓸 수 있나요?
Qt를 쓰세요. 저 중에 실제 프로덕션에 쓸 만큼 성숙한 건 하나도 없습니다.
프로덕션에서 쓰는 회사가 많습니다.
다른 사람들이 어떤 맥락에서 쓰는지 하나도 모르면서 하시는 말씀이라 흥미롭네요. 모두가 어디서나 같은 요구를 갖고 있는 건 아닙니다. 맥락도 모르면서 뭉뚱그려 "아니, 아직 멀었다"고 하는 건 아이러니하게도 너무 성급해 보입니다.
약간 곁가지 얘기이긴 한데, 이런 건 처음 봤습니다.
허술할 수도 있는 PR이 수없이 쏟아지는 것보다는 꽤 흥미로운 방식이네요. LLM 시대의 오픈소스.. ("에이전트 소스"라고 해야 하나요?)
저는 이 문장이 솔직히 좀 슬픕니다. 누군가 손으로 직접 쓴 코드를 기여하고 싶다면요? 초보자가 이 프로젝트가 재미있어 보여서 자기 시간을 들여 참여하고 싶다면요?
아니면 개발에서 사람은 아예 빠진 건가요..
그렇다면 그들을 환영하는 프로젝트에 기여하는 편이 낫겠죠.
공감은 하지만, 기여의 대부분이 손으로 쓴 코드가 아닐 거라는 건 다들 알잖아요. 지금 현실에 맞춰 최적화한 겁니다.
그래도 기여하고 싶다면 포크해서 이슈에서 그 포크를 언급하면 됩니다.
메인테이너 마음입니다. 남의 코드를 리뷰하는 것보다, 필요한 걸 듣고 자기가 잘 아는 방식으로 효율적으로 직접 하는 편이 더 쉬울 때가 있으니까요.
막을 사람은 없습니다. 포크로 공개할 수도 있고요.
저도 바이브 코딩한 프로젝트[0]에서 똑같이 했지만, 사람이 직접 쓴 프로젝트였다면 절대 안 했을 겁니다. 간단히 말해, 기여 대부분이 비슷하게 바이브 코딩한 것이고 그렇게 리뷰되고 취급될 거라면, 소속 없는 에이전트가 올린 PR과 리뷰가 프로젝트 관리자가 관리하는 에이전트의 작업보다 나을 이유가 뭐겠습니까. 물론 사람이 관리하는 과정은 여전히 필요합니다.
이건 자연스러운 흐름입니다(이런 유형의 프로젝트에 한해서요). 예전에 기여를 받은 건 실제로 도움이 됐고, 어렵고 시간이 많이 드는 일이었기 때문입니다. 더는 그렇지 않다면 기여는 부담일 뿐이고, 진짜 가치는 문제나 아이디어 자체에 있으니 이슈를 열어 달라는 겁니다.
0 - https://github.com/cretz/vitaslop
이러면 결국 장기적으로 블로트웨어가 되지 않을까요? 제품을 만든다는 건 무엇에 아니라고 말할지 아는 일이기도 합니다. 그리고 제 경험상 고객이 내놓는 개선 아이디어가 원하는 기능을 구현하는 최선의 방법인 경우는 드뭅니다(아니면 같은 기능을 다르게 쓰는 다른 고객에게 문제가 생기기도 하고요).
모든 아이디어를 받아들이겠다고는 한 적이 없잖아요.
멋지네요. SwiftUI나 UIKit도 네이티브 맥 앱을 위해 이 아이디어를 가져오면 좋겠습니다.
SwiftUI로도 같은 걸 할 수 있어요. 렌더링 대상 서피스가 꼭 눈에 보일 필요는 없고, 트리도 훌륭한 인트로스펙션을 제공합니다.
헤드리스 부분은 깔끔하지만, 에이전트는 이미 앱을 조작하고 스크린샷을 찍을 수 있습니다. 참고로 저는 무선 adb와 HDMI 캡처 카드, mpv rpc로 에이전트가 안드로이드 TV를 조작하게 해 뒀는데, 보고 있으면 재밌습니다.
이걸 GPUI( https://gpui.rs )와 비교하면 어떻게 봐야 할까요? 장단점이 뭔가요?
트위터에서 Dax가 한 말입니다. "gpui로는 도저히 충분히 보기 좋게 만들 수가 없었다"