요약
디스코드가 데스크톱 앱에서 Electron을 걷어내고 클라이언트 전체를 Rust로 옮깁니다.
더버지가 디스코드 최고기술책임자(CTO) 스타니슬라프 비시넵스키가 X에 올린 글을 전했습니다. Electron은 웹 기술로 데스크톱 앱을 만드는 크로스플랫폼 프레임워크로, 시스템 자원을 많이 쓰기로 악명이 높습니다.
왜 중요한가
- 서버 몇 곳만 들어가도 1GB를 넘기던 윈도 앱의 메모리 사용량이 크게 줄어들 수 있습니다.
- React Native도 함께 빠지고, 데스크톱과 모바일이 Rust로 쓴 앱 코드를 함께 쓰게 됩니다.
핵심 내용
- 비시넵스키는 새 윈도 클라이언트가 RAM을 290MB만 쓰는 화면을 공개했습니다.
- 지금 윈도 앱은 서버 몇 곳에만 참여해도 RAM 사용량이 1GB를 쉽게 넘는다고 기사는 짚었습니다.
- 디스코드는 2018년부터 Rust를 써 왔고, 인프라와 음성 기술, 현재 클라이언트 일부가 이미 Rust입니다.
- 모바일 앱은 네이티브 UI를 유지하고, 앱 로직은 Rust로 데스크톱과 공유합니다.
- 전환 시점은 밝히지 않았고, 곧 사용자 테스트를 시작하고 싶다고만 했습니다.
HN 반응
- 이용자들은 CTO가 X에서 밝힌 대로 새 앱이 코드 편집기 Zed의 UI 프레임워크 GPUI로 만들어졌다는 점에 주목했습니다.
- 화면 낭독기 사용자들은 접근성이 빠질까 걱정했고, GPUI도 최근 접근성 지원을 갖췄다는 반론이 나왔습니다.
팝업 때문에 기사 앞부분 이상은 읽기가 힘들었습니다. 저는 디스코드 사용자이자 러스트 애플리케이션 프로그래머인데, 어떤 GUI 프레임워크를 쓰는 건가요? EGUI? GPUI? 아니면 자체 제작인가요?
댓글을 보니 GPUI라고요? 써 보려던 참이었는데, 몇 달 전에 유지보수가 불투명해질 수 있다는 공지가 나와서 물러섰습니다. 게다가 Zed는 제 용도에는 결국 가짜 메시아였고요. (JetBrains IDE 수준에는 못 미칩니다. 긴 스레드가 달렸는데도 닫아 버린 버그 때문인데, 제가 알기로 지금도 그대로입니다. 캐시된 버전의 파일을 열어서, 그 뒤에 다른 프로그램 등이 수정한 내용을 덮어써 버리는 버그예요. 소프트웨어를 쓰기에는 너무 위험해지는 종류의 버그죠. 많은 사람이 신고한 이런 심각한 버그를 무시하는 곳이 만든 GUI 프레임워크로는 갈아타지 않겠습니다.)
GPUI를 씁니다. X에 그렇게 나와 있어요.
"(그리고 Tauri가 아니라 GPUI입니다. 다들 좋은 추측이었어요.)"
제가 알기로 GPUI는 Zed(에디터)0가 쓰는 프레임워크와 같은 거예요.
GPUI를 쓴다는 건... 좋지 않은 소식이에요. 누가 네이티브 접근성 프레임워크와 연동되도록 만들고 있나요? 그렇지 않은데 네이티브 앱을 우리에게 강제로 쓰게 하면, 이번 전환 때문에 보조 기술을 쓰는 많은 사람이 배제될 거예요.
네, 이걸 보세요: https://github.com/longbridge/gpui-kit . 저도 이런 러스트 UI 툴킷들을 계속 지켜봐 왔는데 접근성 같은 건 늘 빠져 있었어요. 실제 제품을 만들 만큼 충분히 갖춘 UI 라이브러리는 이번이 처음 봅니다.
네, 그게 걱정이에요. wxdragon/Relm/GTK가 아닌 러스트 UI 라이브러리는 제가 본 거의 전부가 접근성이 없어요. 대부분은 그걸 위한 기본 요소(primitive)조차 없고요(대부분 방치된 상태라서요).
이 답변은 앞뒤가 안 맞지 않나요?
원 댓글에서는 접근성이 있냐고 물으셨고 부모 댓글은 있다, 여기 있다고 답했는데 그러자 걱정된다면서 그 증거를 무시하시는 건가요?
죄송합니다. 접근성이 부족하다는 점이 걱정된다는 뜻이었습니다(그리고 접근성이 이상하게 깨지는 문제도요).
또 받은 답변을 무시하시네요. "GPUI Kit은 문서화된 컴포넌트와 프리미티브 75개 이상, WebAssembly 지원, AccessKit 접근성을 제공합니다"라고 내세우는 프레임워크를 쓰는데 왜 접근성이 부족할 거라고 생각하시죠?
분명히 해 두자면 GPUI Kit과 GPUI는 다릅니다. Discord가 GPUI Kit을 쓰는지는 모르겠지만, 네이티브 접근성은 어느 쪽으로든 가능합니다.
다시 만드는 과정에서 Discord가 접근성에 신경 쓰지 않았을까 걱정하는 건 합리적입니다.
GPUI로는 접근성 있는 앱을 만드는 게 아예 불가능할지 모른다고 걱정하는 건 덜 합리적입니다. 이제 가능하니까요( https://github.com/zed-industries/zed/blob/main/crates/gpui/src/_accessibility.rs ). 비교적 최근에 추가된 기능이긴 하지만요.
GPUI Kit으로 만든 앱이 자동으로 접근성을 갖출 거라고 가정하는 것도 덜 합리적입니다. 여전히 노력을 들여야 합니다.
다들 눈앞의 분홍 코끼리를 왜 못 본 척하는지 모르겠습니다. Discord 앱 같은 중간 규모 프로젝트라면, 이제 LLM은 상위 수준의 아키텍처·구조 결정까지 포함해 초인적인 수준으로 유능합니다. 이번 재작성을 대부분 Claude(나 비슷한 것)가 하지 않았다면 정말 놀랄 겁니다. 그리고 이런 상황에서는 접근성도 프롬프트 한 줄이면 됩니다. 처음부터 안 넣었다고 쳐도요. 아마 처음부터 들어갔겠지만요.
접근성은 한 번에 뚝딱 만들어지는 게 아닙니다. 실제 스크린 리더와 접근성 스캔 도구로 오가며 테스트하고 고치는 일이 많이 필요해야 제대로 됩니다.
무시하는 게 아니라 얼마나 좋은지 확신이 없을 뿐입니다. 질이 양보다 중요하잖아요. UI 컴포넌트가 75개든 100개든 200개든, 어떤 건 접근성이 완벽할 수 있지만 어떤 건 accesskit이 아직 지원하지도 않는 것일 수 있고, 위젯을 일부만 지원할 수도 있습니다. 아래 스레드에서도 말했듯이, Discord가 이런 UI 툴킷을 쓰면 accesskit 지원 범위에 업스트림으로 좋은 영향이 가기를 바라고 있습니다. 사람들을 이 앱으로 옮기기 시작할 때 지켜봐야겠죠.
바로 이 때문에 Skip( https://skip.dev )의 후속으로 Day( https://daybrite.dev )를 만들기 시작했습니다. 어디서나 플랫폼 네이티브 툴킷을 쓰기 때문에 접근성이 공짜로 따라옵니다.
아직 정식으로 "출시"한 건 아니지만, 이미 App Store와 Play Store로 앱을 내고 있습니다. 5분짜리 둘러보기는 https://daybrite.dev/showcase/ 에서 보세요.
와, 이거 엄청 멋진데요! 재미 삼아 제 작은 diff 도구를 이걸로 옮겨 볼까 싶네요!
애초에 Iced가 접근성(a11y) 지원을 추가한 계기가 COSMIC의 실사용이었어요.
그러니 Discord가 gpui를 쓰면 필요한 기능이 생길 수도 있겠죠.
COSMIC은 iced의 포크를 쓰는데, 메인테이너가 한 명뿐이라 버스 팩터가 1이어서 변경 사항이 업스트림으로 돌아가는 속도가 한참 느려요.
둘을 한데 묶어 볼 수는 없죠.
무슨 말인지 모르겠네요. GPUI로도 지금 접근성을 구현할 수 있잖아요. 방법을 보여 주는 저장소를 링크했는데요.
네, 좋은 진전이에요(아래 스레드에 쓴 제 댓글은 직접 확인해 보기 전에 쓴 거였어요). 거기 보면 accesskit을 쓴다는데, 이미 꽤 훌륭하지만 아직 개발 중이라 UIA를 직접 쓰는 것만큼 접근성이 좋지는 않을 거예요. 그래도 accesskit(Godot에서도 쓰죠)이 계속 나아져서 그 차이가 메워지길 기대하고 있어요.
맞아요, Discord 같은 큰 제품이 쓰면 그게 더 빨라지는 데 도움이 될 거예요.
한 가지 관점이긴 하죠. 말씀하신 식으로 제게 결정적인 걸림돌이 되지는 않아요. 다들 자기만의 기준이 있겠죠. 모든 사람의 기준을 다 맞춰야 했다면 소프트웨어는 아예 없었을 거예요!
Discord처럼 큰 회사의 경우라면 이걸 제대로 처리해야 한다는 데 동의해요. 더 넓은 표준으로 보면 그만큼 걱정되지는 않고요.
저한테는 원하지 않더라도 결정적인 문제입니다. 애플리케이션이 접근성 프레임워크(UIA, AT-SPI, NSAccessibility 등)와 연동하지 않거나, 제 스크린 리더와 소통하는 동등한 수단을 구현하지 않으면, 말 그대로 그 앱을 쓸 수 없습니다. 앱을 OCR로 읽거나, AI에게 스크린샷으로 대신 쓰게 할 수는 있겠지만, 둘 다 네이티브 플랫폼 접근성 프레임워크를 쓰는 것과는 비교조차 안 됩니다.
누가 AI로 GPUI kit을 접근성 있게 만들 수는 없을까요? 누군가(아마 당신이요) 프리미티브조차 없다고 하셨는데, 그럼 시작도 못 하는 건가요?
아니요, 제가 말한 건 대부분의 러스트 UI 툴킷에 프리미티브조차 없다는 거였습니다. 접근성 프레임워크 없이 기본적인 접근성을 만들려면 포커스 이벤트, 캐럿 이동, 리스트 박스나 콤보 박스 같은 컨테이너 안에서의 이동, 여러 줄 편집 상자에서의 줄/문단 처리 같은 프리미티브가 필요합니다. 네이티브 접근성을 붙이면 이런 것 중 상당수를 어차피 하게 되는데, 텍스트를 스크린 리더로 바로 보내는 방식과는 다른 방식일 뿐입니다.
제가 직접 하느냐고요? 앞선 댓글들 말대로라면 이미 되어 있다지만, 제가 테스트해 보지 않아서 얼마나 완성도가 있는지는 모릅니다. 프레임워크에 UIA 지원을 넣는 것과 그 지원을 좋게 만드는 건 다릅니다(스크린 리더는 꽤 까다로워요). 예를 들어 편집 상자의 레이블이 있다고 해 봅시다. 레이블을 부모 컨테이너 안에서 딱 맞는 위치에 두면 스크린 리더가 자동으로 잡아서, 편집 상자에 포커스가 갈 때 그냥 읽어 줍니다. 그렇지 않으면 들리는 건 "edit <내용|비어 있음>"뿐이죠. 우회 방법이 있긴 하지만(레이블 감지를 오버라이드하는 식으로요) '이상적인' 상태는 스크린 리더가 그런 걸 알아서 잡고, 우리는 각종 컨트롤과 UI 요소의 경계만 넘겨주는 겁니다.
원하든 원하지 않든, 안타깝게도 수백만 명에게는 결정적인 문제가 될 수 있어요. 그분들에게 접근성은 선택이 아니고, "일단 지켜보자" 식으로 넘길 수 있는 문제도 아니니까요.
말 참 깔끔하게 포장하셨네요. 그냥 "시각장애인 따위 엿이나 먹으라지"라고 하면 충분했을 텐데요.
gpui에는 접근성(a11y) 지원이 있어요. Zed가 아직 연결하지 않았을 뿐이에요. 그리고 Discord는 필요했던 빠진 기능을 채우는 패치를 넣은 자체 gpui 포크를 쓰고 있을 거라고 거의 확신해요.
Zed가 지원을 넣어 주면 좋겠네요. 다들 좋다고 하니(특히 HN에서요 :)) 써 보고 싶거든요.
gpui 코드가 zed 저장소 안의 크레이트로만 존재한다는 점을 보면, 맞는 말씀 같네요.
그래픽(GRAPHICAL) 사용자 인터페이스를 위한 건데 웹사이트에 스크린샷이 한 장도 없다니 이상하네요. 예제 페이지에는 스크린샷이 있을 법한데, 실제로는 코드가 무엇을 그려 내는지 알 수 없는 예제 코드 조각뿐이에요.
[1] https://gpui.rs/
[2] https://gpui.rs/examples/