디스코드, 일렉트론에서 Rust로 가다

핵심 요약

• 디스코드 앱의 Rust 전환은 아직 계획입니다. CTO가 2026년 11월 4일(UTC) 데스크톱의 Electron과 모바일의 React Native를 없앤다고 밝혔고, 사용자 시험은 "곧"이라고만 했습니다. 출시일은 없습니다.
• 290MB와 1GB는 같은 조건에서 잰 숫자가 아닙니다. 290MB는 CTO가 올린 작업 관리자 화면이고, 1GB는 The Verge 기자의 서술입니다. 4GB는 사용량이 아니라 Discord의 자동 재시작 실험 기준입니다.
• Discord 앱이 아니라 직접 만든 측정용 앱을 쟀습니다. 글자 목록만 그리는 같은 채팅 화면을 Electron, Tauri, GPUI로 만들어 M1 Max에서 메시지 5,000개를 끝까지 스크롤했습니다. 메모리 중앙값은 170MB, 152MB, 63MB였고, Electron과 GPUI의 차이는 약 2.7배(회차별 약 2.5~2.8배)입니다.
• Tauri의 이득은 이 실험에서 메모리보다 앱 크기에 있었습니다. 앱 크기는 253MB에서 10.4MB로 줄었지만 메모리는 중앙값 기준 약 10%(회차별 약 8~19%) 줄었습니다. 프로세스 수도 Electron과 같은 4개였습니다.
• 이 실험으로 290MB와 1GB의 차이를 나눌 수는 없습니다. 글자 목록 앱에서 Electron과 GPUI의 차이는 107MB였습니다. 290MB와 1GB는 조건이 달라 그 차이를 프레임워크 몫으로 읽을 근거가 없고, 실제 앱에서는 이미지와 음성, 코드 크기 때문에 차이가 더 벌어질 수 있습니다(필자 해석).

목차

• 디스코드 앱 Electron 제거, 무엇이 발표됐나
• 290MB, 1GB, 4GB는 서로 다른 숫자다
• 부팅 영상에서 메인 화면은 약 2.4초 먼저 떴다
• 같은 화면을 세 번 만들어 쟀다
• Electron 앱의 메모리는 어디로 가나
• 왜 Tauri가 아니라 GPUI인가
• 재작성이 남기는 위험
• 지금 사용자와 개발자가 볼 기준
• 출처

디스코드 앱 Electron 제거, 무엇이 발표됐나

디스코드 앱 Electron 제거는 데스크톱 앱 전체를 Rust로 다시 만들겠다는 계획입니다. Discord 공동 창업자이자 CTO인 Stanislav Vishnevskiy는 2026년 11월 4일(UTC) X 글에서 "Electron goes away, and so does React Native"(Electron이 사라지고 React Native도 사라진다)라고 썼습니다. 같은 글에서 Discord가 2018년부터 Rust를 써 왔고, 인프라와 음성 기술, 현재 앱의 일부가 이미 Rust라고 밝혔습니다.

발표에서 확인되는 범위는 네 가지입니다.

• 데스크톱: Electron을 없애고 앱 전체를 Rust로 옮깁니다.
• 모바일: React Native를 없앱니다. 다만 "mobile keeps native UI"라고 해서 화면은 네이티브로 두고, 앱 코드만 Rust로 데스크톱과 공유합니다.
• 화면 프레임워크: Tauri가 아니라 GPUI입니다. CTO는 "it's not Tauri, it's GPUI"라고 적었습니다.
• 일정: "We hope to get it into testing with users soon"이 전부입니다. The Verge도 전환 시점이 분명하지 않다고 썼습니다.

앱이 웹 기술을 완전히 떠나는 것은 아닙니다. 웹뷰를 쓴다는 추측에 CTO는 답글에서 "this is just for things like YouTube or Activities, the app itself is native"(YouTube나 Activities 같은 기능에만 해당하고, 앱 자체는 네이티브다)라고 밝혔습니다. 이 답에 웹뷰라는 단어는 없지만, 앞 글의 맥락으로 보면 YouTube와 Activities 같은 기능에는 웹뷰가 남는다는 뜻으로 읽힙니다(필자 해석).

290MB, 1GB, 4GB는 서로 다른 숫자다

290MB는 CTO가 올린 Windows 작업 관리자 화면 한 장의 값입니다. 앱 목록에 "Discord Phoenix"가 290.2MB로 표시됩니다. 사진에서 열 제목은 잘려 있어, 이 값이 메모리라는 판단은 값의 형태로 본 것입니다. 함께 보이는 Chrome에는 (19), Notion에는 (9)처럼 프로세스 수가 붙어 있는데, Discord Phoenix에는 이 표시가 없습니다.

이 사진에서 알 수 없는 것이 더 많습니다. 서버가 몇 개인지, 앱을 얼마나 켜 뒀는지, 통화 중인지는 나와 있지 않습니다. 기존 Discord 앱도 같은 화면에 없습니다. 필자가 찾은 범위에서 CTO가 덧붙인 조건은 하나입니다. 290MB도 채팅 앱치고 많다는 지적에 계정 2개를 동시에 돌리는 상태라고 답했습니다. 봇 개발자가 메시지 컴포넌트 렌더링을 묻자 현재 앱과 똑같이 보이고 동작한다고 답했지만, 어떤 기능이 구현됐는지는 외부에서 확인할 방법이 아직 없습니다.

비교 대상으로 도는 숫자는 출처가 저마다 다릅니다.

4GB를 현재 앱의 사용량처럼 쓰면 안 됩니다. Discord 직원의 공지 원문은 "testing a restart when memory exceeds 4GB (normal usage is <1GB)"입니다. 자리를 비웠을 때만, 통화 중이 아닐 때만, 하루 한 번까지라는 조건이 붙은 임시 조치이고, 공지는 장기 해결책이 아니라고 못 박았습니다.

기준을 어디에 두느냐에 따라 절감률은 크게 달라집니다. 필자가 1GB를 1,024MB로 계산하면 1GB 대비 약 72%, 4GB 대비 약 93%입니다. Wumpus Central 글은 약 2GB를 기준으로 삼았고, 11월 6일 기준 CTO 글보다 좋아요가 두 배 넘게 많았습니다. 국내에서는 토큰포스트가 290MB와 1GB는 같은 컴퓨터와 사용 조건에서 잰 값이 아니라고 밝혔습니다. 반면 램 점유율이 60% 이상 떨어졌다는 블로그 문장도 보이는데, 필자는 그 근거를 찾지 못했습니다.

부팅 영상에서 메인 화면은 약 2.4초 먼저 떴다

Discord가 메모리 다음으로 내세운 것은 속도입니다. CTO는 11월 5일(UTC) "less RAM is just part of the story"(메모리 절감은 이야기의 일부일 뿐이다)라며 노트북 두 대를 나란히 놓은 영상을 올렸습니다. Discord 공식 계정은 왼쪽이 지금 앱, 오른쪽이 Rust로 다시 만든 버전이라고 설명했습니다.

필자가 영상을 0.25초 단위로 넘겨 읽으니 메인 화면은 왼쪽이 약 10.8초, 오른쪽이 약 8.4초에 떴습니다. 창이 보인 뒤부터 세면 왼쪽은 약 5초, 오른쪽은 약 1초입니다. 다만 오른쪽 창은 왼쪽보다 약 1.5초 늦게 나타났습니다. 2.4초도 영상 안의 시각 차이이고, 앱 아이콘을 누른 시점부터 잰 시간은 아닙니다. 차이는 분명하지만 회사가 만든 시연입니다. 두 기기의 사양과 캐시 상태는 밝히지 않았고, 외부에서 다시 재 볼 수도 없습니다.

같은 화면을 세 번 만들어 쟀다

공개된 숫자로는 비교가 되지 않아, 조건이 같은 값을 직접 만들었습니다. 메시지 5,000개를 메모리에 두고 보이는 줄만 그리는 채팅 목록을 Electron 45.2.3, Tauri 2.12.5, GPUI 0.2.2로 각각 만들었습니다. 데이터와 창 크기(1000x700), 줄 높이를 맞추고, 16밀리초마다 10줄씩 끝까지 스크롤하게 했습니다.

측정은 Apple M1 Max, 메모리 32GB, macOS 27.2에서 했습니다. 시나리오마다 앱을 번갈아 5번씩 띄웠고, 앱이 만든 모든 프로세스의 footprint 값을 더한 뒤 중앙값을 냈습니다. 메시지 5,000개 시나리오는 앱이 완료를 보고한 회차만 썼습니다. Electron과 Tauri는 30초 안에 보고가 없던 1회씩(234.9MB, 208.3MB)을 빼고 4회의 중앙값을 냈고, 보고가 없던 원인은 확인하지 못했습니다. 이 회차를 넣어도 중앙값은 170.2MB, 154.1MB입니다. 빈 창은 실행 15초 뒤, 메시지 5,000개는 30초 뒤에 한 번 잰 값이라 최고치를 잡은 것은 아닙니다. 메시지 5,000개에서 사용한 회차의 범위는 Electron 168.0~171.1MB, Tauri 138.2~156.5MB, GPUI 62.0~68.0MB입니다.

측정 스크립트를 줄인 의사 코드는 아래와 같습니다.

before = ps()  # 실행 전 목록
app = launch(cmd, MSG_N=5000)
wait(30)  # 빈 창은 15초
new = [p for p in ps()
       if p.pid not in before
       and belongs(p)]
total = sum(footprint(p) for p in new)

belongs는 측정 앱 폴더의 프로세스와 com.apple.WebKit 서비스를 고릅니다. footprint는 macOS의 footprint -p 값입니다.

메시지를 넣기 전에도 Electron은 GPUI의 2.3배였고, 넣은 뒤에는 2.7배로 벌어졌습니다. 메시지를 넣고 스크롤한 뒤 늘어난 양은 Electron 83.7MB, Tauri 82.3MB, GPUI 26.0MB입니다. 웹 기술을 쓰는 두 앱은 같은 데이터에서 GPUI보다 약 3배 많이 늘었습니다. 표의 소수점 값은 합계와 중앙값 계산 결과이고, 도구의 표시 단위 때문에 1MB 안팎의 오차가 있습니다. 이 증가분을 항목별로 나눠 재지는 않았고, 메시지 문자열 말고도 화면 요소를 다시 만든 흔적과 글자 캐시가 섞여 있을 것으로 봅니다(필자 추정).

이 표는 Discord의 성능표가 아닙니다. 이미지, 음성, 네트워크 없이 글자 목록만 그린 앱이고, Windows가 아니라 macOS입니다. GPUI는 Discord의 사내 포크가 아니라 crates.io의 0.2.2이고, Electron도 Discord가 2026년 9월 패치 노트에 적은 42가 아니라 45입니다. GPUI는 Metal 도구가 없어 셰이더를 실행 시 컴파일하는 설정으로 빌드했습니다. 측정 중 필자는 같은 맥에서 다른 앱을 쓰고 있었고, 창은 작업을 가리지 않게 불투명도 1%로 띄웠습니다. 웹 앱은 스크롤 위치와 rAF 횟수를, GPUI는 스크롤 루프 완료와 render 호출 수를 보고했습니다.

재는 항목이 바뀌면 숫자도 바뀝니다. 같은 Electron 앱을 ps의 RSS로 합치면 426MB가 나옵니다. RSS는 프로세스끼리 공유하는 메모리를 여러 번 세고, footprint가 세지 않는 깨끗한 메모리까지 포함하기 때문입니다. 그래서 Windows 작업 관리자 값과 macOS 측정값을 바로 비교하기 어렵다고 봅니다(필자 해석).

Electron 앱의 메모리는 어디로 가나

Electron 앱은 브라우저 구조를 함께 들고 다닙니다. Electron 문서는 "Electron inherits its multi-process architecture from Chromium"이라고 설명하고, 창마다 별도의 renderer 프로세스가 뜬다고 적습니다. 측정에서도 메인 프로세스 42.0MB, 화면을 그리는 renderer 86.5MB, 보조 프로세스 2개 41.1MB로 나뉘었습니다.

Tauri에서는 숫자를 잘못 읽기 쉽습니다. 앱 이름이 붙은 프로세스만 보면 메시지 5,000개에서 30.0MB입니다. 그런데 웹 화면은 macOS의 WebKit 서비스가 맡습니다. 이 서비스들은 앱의 자식 프로세스가 아니어서 앱 프로세스만 따라가면 빠지고, 이들까지 더해야 151.9MB가 됩니다. 그래서 측정 스크립트는 부모 프로세스를 따라가는 대신 실행 전후의 프로세스 목록을 비교했습니다.

GPUI는 다른 구조입니다. 브라우저가 없고, 앱 하나가 GPU로 화면을 직접 그립니다. Zed 개발자는 GPUI를 소개한 Zed 블로그 글에서 "Zed is rendered like a videogame"(Zed는 비디오 게임처럼 그려진다)이라고 설명하며, Electron 기반 Atom을 만들 때 가비지 컬렉션과 DOM 재배치로 프레임을 놓친 경험을 근거로 들었습니다. 측정에서도 프로세스는 1개였습니다. 스크린샷의 표시와 같은 방향이지만, 이것만으로 Discord Phoenix가 단일 프로세스라고 볼 수는 없습니다(필자 해석).

이 실험은 실제 Discord 앱에서 프레임워크가 차지하는 몫을 알려 주지 않습니다. 글자 목록 앱의 차이는 107MB였고, 290MB와 1GB의 차이는 조건이 달라 같은 격차로 볼 수 없습니다(필자 해석). 실제 앱은 이미지와 음성, 훨씬 큰 코드를 들고 있어 차이가 더 벌어질 수 있습니다. 그렇다고 문제 전부를 Electron 탓으로 돌리기도 어렵습니다. Discord는 2025년 12월 공지에서 메모리 문제 9건 이상을 고쳤고, 이와 별도로 플랫폼, 운영체제, 드라이버, 하드웨어 쪽 문제도 찾았다고 밝혔습니다. 코드를 처음부터 다시 쓰면 오래 쌓인 기능과 캐시도 함께 정리되므로, 언어 효과와 재작성 효과는 분리되지 않습니다(필자 해석).

왜 Tauri가 아니라 GPUI인가

Tauri 대신 GPUI를 고른 이유를 Discord가 밝힌 글은 찾지 못했습니다. 아래는 측정과 문서로 해 본 필자의 해석입니다.

Tauri는 웹 화면을 버리는 기술이 아닙니다. Tauri 문서는 앱이 작은 이유를 "they use the OS's webview"라고 설명합니다. 그래서 이 실험에서 Tauri는 앱 크기를 253MB에서 10.4MB로 약 24분의 1로 줄였지만, 메모리는 중앙값 기준 169.6MB에서 151.9MB로 약 10%(회차별 약 8~19%) 줄이는 데 그쳤습니다. 이 실험에서 웹 화면을 그대로 둔 Tauri의 메모리 이득은 크지 않았습니다. 국내에도 Tauri로 옮겨 크기와 메모리에는 만족했지만 파일 드래그 앤 드롭 제약과 웹뷰 호환성 때문에 Electron으로 돌아간 개인 개발 회고가 있습니다.

웹뷰가 운영체제마다 다르다는 점도 큽니다. Tauri 웹뷰 문서에 따르면 Tauri는 Windows에서 Chromium 기반 WebView2를, macOS와 Linux에서 WebKit을 씁니다. 이 글의 Tauri 수치는 WebKit 기준이라 Windows로 옮기면 달라질 수 있습니다. 같은 화면이 운영체제마다 다른 엔진에서 돌면 시험할 범위도 넓어집니다.

앱 크기 차이는 그대로 보였습니다. 1MB를 1,024KB로 계산하면 Electron은 Chromium을 함께 넣어 253MB, Tauri는 10.4MB, GPUI는 실행 파일 하나가 5.4MB였습니다. 다만 Chromium이 하던 일을 누가 맡는지는 다릅니다. Tauri는 운영체제의 웹뷰가 맡고, GPUI는 운영체제 API와 잇는 입력, 글자 표시, 접근성 처리까지 앱 쪽 프레임워크가 챙겨야 합니다.

재작성이 남기는 위험

GPUI는 아직 1.0 이전이라 Electron보다 변경 위험이 크다고 봅니다(필자 해석). GPUI 문서는 "still pre-1.0"(아직 1.0 이전)이고 버전 사이에 호환되지 않는 변경이 자주 있다고 적습니다. 공식 사이트도 당분간 Zed에 묶여 있다고 밝힙니다. Discord는 그 위에 자체 패치를 쌓고 있습니다. CTO는 공유할 만한 패치를 살펴보겠다고 했고, 이 작업을 한다고 밝힌 Hacker News 사용자는 "basically a private fork at this point"(지금은 사실상 사내 포크)라고 썼습니다.

접근성: 브라우저가 맡아 주던 일을 앱이 직접 해야 합니다. GPUI는 2026년 5월 AccessKit 연동을 넣었습니다. 하지만 필자가 받은 crates.io의 0.2.2에는 이 의존성이 없었고, Zed의 Windows 스크린 리더 이슈는 이 글을 쓰는 시점에 열려 있습니다. Discord가 접근성을 어떻게 맞췄는지는 찾지 못했습니다.

한글 입력: 한국 사용자라면 먼저 확인할 부분입니다(필자 판단). 입력이 어긋나면 채팅 앱은 바로 불편해집니다. Hacker News에는 중국어 입력이 된다는 경험담과 입력 지원이 불안정하다는 주장이 함께 있습니다. 한글 입력을 시험한 사례는 찾지 못했고, 측정 앱에도 입력창이 없습니다.

클라이언트 모드: Vencord 같은 모드를 쓰는 사용자는 앱을 꾸미는 방법을 잃을 수 있습니다. 모드가 모두 사라진다는 말은 커뮤니티에 옮겨진 발언으로만 확인했고, Discord의 공식 입장은 찾지 못했습니다.

AI 재작성 여부: 커뮤니티에는 AI로 다시 썼을 것이라는 추측이 많습니다. 필자가 찾은 범위에서 회사가 밝힌 내용은 없어, 어느 쪽으로도 단정할 근거가 없습니다.

지금 사용자와 개발자가 볼 기준

디스코드 사용자는 아직 새 앱을 쓸 수 없습니다. Discord가 정상이라고 쓴 기준은 1GB 미만이니, 작업 관리자에서 그보다 크게 높고 시간이 갈수록 늘면 앱을 다시 켜는 것이 가장 단순한 대응입니다. 하드웨어 가속을 끄면 메모리가 줄어든다는 근거는 찾지 못했고, 국내 글마다 안내하는 메뉴도 달랐습니다. Reddit에는 게임 클립 상시 기록을 끄자 800MB 아래로 내려갔다는 사용자 경험담이 있는데, 한 사람의 사례입니다. 필자가 찾은 국내 글에서는 메모리보다 화면 공유 중 끊김을 호소하는 경우가 많았습니다. Rust 버전이 이 문제까지 고치는지는 따로 봐야 합니다.

Electron 앱을 만드는 개발자는 메모리가 문제일 때 재작성을 결정하기 전에 세 가지를 확인하는 편이 좋습니다.

1. 빈 창을 기준으로 메모리가 얼마나 늘어나는지 봅니다. 이 실험의 Electron은 빈 창에서 86MB, 메시지 5,000개에서 170MB였습니다. 늘어난 양에는 내 코드와 데이터뿐 아니라 프레임워크가 화면과 글자를 다루며 쓴 메모리도 들어 있다고 봅니다(필자 추정).
2. 앱이 쓰는 프로세스를 전부 더합니다. 앱 이름의 프로세스만 보면 Tauri는 30MB로 보이지만, WebKit 서비스까지 더하면 152MB입니다. 다른 앱과 비교할 때는 어떤 프로세스를 더했는지와 측정 항목을 함께 적습니다.
3. 줄이려는 항목을 먼저 정합니다. 이 실험에서 Tauri로 옮기자 앱 크기는 253MB에서 10.4MB로 줄었지만, 메모리는 중앙값 기준 약 10% 줄었습니다. 앱 크기가 문제일 때와 메모리가 문제일 때의 답이 다를 수 있습니다.

메모리가 문제라면 재작성보다 누수와 캐시 점검을 먼저 하고, 그래도 부족할 때 재작성을 검토하는 순서가 비용이 적다고 봅니다(필자 판단).

Discord의 공개 수치는 이 순서의 다음 단계로 읽힙니다. Discord는 2025년 12월 공지에서 메모리 문제 9건 이상을 고쳤다고 밝혔지만, 공지 시점의 p95 메모리 감소는 5%였습니다. 2026년 9월 패치 노트를 보면 Electron 42로 올리고 사용 방식을 바꿔 p50 CPU를 약 17% 개선했지만, p50 메모리는 약 4% 늘었습니다. 필자는 Discord가 이런 개선만으로는 부족하다고 판단했을 가능성이 있다고 봅니다. 회사가 이렇게 설명한 것은 아니고 필자의 해석입니다.

재작성이 성공했는지는 Rust 버전이 배포된 뒤 같은 기기, 같은 계정과 서버 조건에서 비교해야 알 수 있습니다. Discord는 메모리와 속도를 앞세웠지만 접근성, 한글 입력, 클라이언트 모드처럼 아직 확인되지 않은 부분도 있습니다. 여러분은 디스코드 앱이 Electron을 떠나 Rust로 가는 방향을 어떻게 생각하시나요?

출처

1. Stanislav Vishnevskiy, X: x.com/svishnevskiy/status/2118081920194203799
2. The Verge: theverge.com/news/1027379/discord-ditching-electron-web-app
3. 답글: x.com/svishnevskiy/status/2118091270434554210
4. 계정 2개를 동시에 돌리는 상태: x.com/svishnevskiy/status/2118092648590573734
5. 현재 앱과 똑같이 보이고 동작한다: x.com/svishnevskiy/status/2118092321346756616
6. Discord 직원의 공지: reddit.com/r/discordapp/comments/1pej7l7/restart_on_excessive_memory_us…
7. Wumpus Central 글: x.com/WumpusCentral/status/2118106749446103371
8. 토큰포스트: tokenpost.kr/news/tech/433290
9. Stanislav Vishnevskiy, X: x.com/svishnevskiy/status/2118398632236073156
10. Discord 공식 계정: x.com/discord/status/2118401057571369252
11. Electron 문서: electronjs.org/docs/latest/tutorial/process-model
12. Zed 블로그 글: zed.dev/blog/videogame
13. Tauri 문서: v2.tauri.app/concept/architecture
14. Electron으로 돌아간 개인 개발 회고: m.blog.naver.com/mujette/223944832552
15. Tauri 웹뷰 문서: v2.tauri.app/reference/webview-versions
16. GPUI 문서: github.com/zed-industries/zed/blob/main/crates/gpui/README.md
17. 공식 사이트: gpui.rs
18. 공유할 만한 패치를 살펴보겠다: x.com/svishnevskiy/status/2118084029304230053
19. Hacker News 사용자: news.ycombinator.com/item?id=50388399
20. AccessKit 연동: github.com/zed-industries/zed/blob/main/crates/gpui/src/_accessibility.…
21. Windows 스크린 리더 이슈: github.com/zed-industries/zed/issues/41138
22. 중국어 입력이 된다는 경험담: news.ycombinator.com/item?id=50379359
23. 입력 지원이 불안정하다는 주장: news.ycombinator.com/item?id=50380332
24. 커뮤니티에 옮겨진 발언: reddit.com/r/linux_gaming/comments/1xo113w/discord_is_rewriting_its_ent…
25. AI로 다시 썼을 것: news.ycombinator.com/item?id=50379495
26. 800MB 아래로 내려갔다: reddit.com/r/discordapp/comments/1pej7l7/restart_on_excessive_memory_us…
27. 화면 공유 중 끊김: quasarzone.com/bbs/qb_free/views/8908690
28. 2026년 9월 패치 노트: discord.com/blog/discord-patch-notes-september-8-2026