MailVault는 Windows에서 메모리를 얼마나 씁니까? 직접 측정해 보았습니다

MailVault 2.16은 Windows에서 실행되는 첫 버전입니다. 새 데스크톱 앱, 특히 웹 기반 인터페이스를 쓰는 앱에 대해 사람들이 가장 먼저 묻는 질문은 메모리를 얼마나 쓰느냐는 것입니다. 그래서 Mac에서 이미 쓰고 있는 것과 같은 테스트 메일함으로, 같은 메모리 테스트를 Windows 11 노트북에서 실행하고 모든 수치를 기록했습니다.

간단히 말하면, 실행 시 약 210 MB, 메시지 10,000개짜리 받은편지함을 불러온 상태에서도 약 210 MB, 그 큰 받은편지함을 여는 몇 초 동안 365 MB 가까이 치솟고, 동기화를 맡는 백그라운드 도우미는 약 23 MB입니다.

테스트

이 테스트는 로컬 테스트 메일 서버에 있는 이메일 계정 두 개를 씁니다. 받은편지함에 메시지 58개가 있는 계정과 10,000개가 있는 계정입니다. 자동화된 실행이 사람처럼 실제 앱을 조작합니다. MailVault를 열고 작은 받은편지함을 연 다음, 큰 계정으로 전환해 메시지 헤더 10,000개가 모두 목록에 뜰 때까지 기다립니다. 목록 전체를 맨 위에서 맨 아래까지 스크롤한 뒤, 앱을 10분 동안 그대로 둡니다. 각 단계마다 MailVault가 소유한 모든 프로세스의 메모리를 기록합니다.

노트북은 MSI 제품으로 Intel Core i7-13620H와 메모리 16 GB를 갖췄고, 전원에 연결한 채 Windows 11 23H2에서 실행했습니다. 깨끗한 환경이 아니라 MailVault 사본 하나를 포함해 다른 앱도 열려 있었으므로, 평범하게 바쁜 컴퓨터에서 나온 결과로 봐 주십시오. 전체 테스트를 매번 새 빈 프로필로 세 번 실행했고, 아래 수치는 그 세 번의 실행 범위입니다. 빌드는 MailVault 2.16의 최적화된 릴리스 빌드에 테스트용 후크를 켠 것으로, 배포판과 거의 같지만 바이트 단위까지 동일하지는 않습니다.

MailVault의 메모리로 치는 것

Windows에서 MailVault는 프로세스 하나가 아니므로, 이름이 MailVault인 프로세스만 더하면 메모리 대부분을 놓치게 됩니다. 다음 세 부분으로 이루어져 있습니다.

• 앱 창(mailvault.exe): 창, 메뉴, Windows와의 연동 부분입니다.
• 백그라운드 도우미(mailvault-daemon.exe): 동기화, 메시지를 볼트에 저장하는 작업, 검색 인덱스, 백업을 담당합니다. 창을 닫아도 계속 실행되므로 예약된 백업도 그대로 실행됩니다.
• Microsoft Edge WebView2(여러 개의 msedgewebview2.exe 프로세스): 화면을 그리는 엔진입니다. Windows의 일부이므로 MailVault는 브라우저를 따로 담지 않으며, 작업을 렌더러, GPU 프로세스, 브라우저 프로세스, 작은 네트워크·저장소 도우미로 나눕니다.

우리는 이 모든 프로세스를, 단 우리가 실행한 MailVault에 속한 것만 셉니다. 사용하는 수치는 작업 관리자의 메모리 열에 나오는 값, 곧 프라이빗 워킹 셋(그 프로세스만 소유하고 지금 실제로 RAM에 있는 메모리)입니다. Edge를 비롯한 다른 앱도 함께 쓰는 WebView2 프로그램 코드 같은 공유 페이지는 세지 않습니다.

결과

Windows 11 · Intel i7-13620H · 16 GB · 3 runs · all MailVault processes

moment                           Task Manager    commit size
launch, 58 messages              209 – 224 MB    297 – 298 MB
10,000 messages loaded           197 – 218 MB    297 – 302 MB
peak while opening 10,000        357 – 367 MB    545 – 560 MB
after scrolling all 10,000       234 – 252 MB    355 – 356 MB
after ten minutes idle           102 – 122 MB    308 – 318 MB

background helper, 10,000 msgs    22 – 23 MB
app window                        11 – 13 MB

두 번째 열은 커밋 크기입니다. 각 프로세스가 예약해 둔 프라이빗 메모리로, 지금 RAM에 있는지 여부와는 무관합니다. 이 항목은 첫 실행 뒤에 추가했으므로 세 번이 아니라 두 번의 실행만 담고 있습니다. 이는 마지막 행에서 중요해집니다. 몇 분 동안 입력이 없으면 Windows는 쓰이지 않는 프로세스에서 메모리를 거둬 가고, 작업 관리자의 수치는 약 110 MB까지 떨어집니다. 이 메모리는 MailVault가 해제한 것이 아니라 Windows가 따로 챙겨 둔 것이며, 커밋 크기를 보면 앱이 돌아왔을 때 되찾을 수 있는 약 310 MB를 여전히 쥐고 있음을 알 수 있습니다. Windows에서 MailVault의 비용을 숫자 하나로 말한다면, 큰 메일함을 기준으로 대략 300 MB, 그 숫자를 쓰면 됩니다.

메모리는 어디로 가는가

메시지 10,000개를 불러온 상태에서 메모리의 약 5분의 4는 화면을 그리는 WebView2가 차지합니다. 진짜 MailVault 자체 코드에 해당하는 부분, 곧 앱 창과 백그라운드 도우미를 합치면 약 35 MB입니다.

• 화면을 그리는 WebView2 렌더러: 86 MB
• WebView2 GPU 프로세스: 51 MB
• WebView2 브라우저·네트워크·저장소 프로세스: 37 MB
• 백그라운드 도우미: 23 MB
• 앱 창: 12 MB

백그라운드 도우미가 작은 이유는 메일을 메모리에 두지 않기 때문입니다. 메시지와 헤더 캐시는 디스크의 파일과 작은 데이터베이스에 있으며, 도우미는 요청받을 때 이를 읽습니다. 실행 시 8 MB였다가 헤더 10,000개를 동기화한 뒤 23 MB로 늘었습니다. 조용한 10분이 지난 뒤 작업 관리자에는 10 MB로 표시되었지만, 커밋 크기는 25 MB 정도를 유지했습니다. 이 하락은 도우미가 메모리를 놓아준 것이 아니라 Windows가 덜어 낸 것입니다.

큰 메일함 열기

메모리가 크게 치솟는 유일한 순간은 큰 계정을 처음 열 때입니다. MailVault는 그 메일함에 캐시된 모든 헤더를 한꺼번에 목록에 불러오므로, 정렬과 개수, 필터가 스크롤을 지나온 부분뿐 아니라 메일함 전체를 대상으로 동작합니다. 렌더러는 그 목록을 만드는 동안 잠깐 대략 두 배로 늘었다가 대부분을 다시 돌려줍니다.

같은 급증을 Mac에서도 측정했고, 메일함을 더 작은 단위로 나눠 불러오는 방식으로 없애 보려 했습니다. 효과가 없었습니다. 급증은 그대로였습니다. 이를 없애려면 목록이 메시지를 담는 방식 자체를 바꿔야 하는데, 이는 앞으로 할 일 목록에는 있지만 이번 릴리스에는 들어 있지 않습니다.

Windows와 Mac 나란히 비교

Windows 실행보다 나흘 앞선 9월 22일에, 메모리 16 GB의 Apple M4 Mac mini에서 같은 테스트를 실행했습니다. 실행 시와 최고치는 두 시스템이 비슷합니다. Windows는 큰 메일함을 불러온 상태에서는 더 적게 나오고, 유휴 상태에서는 위에서 설명한 트리밍 때문에 훨씬 더 적게 나옵니다.

실행 시, 메시지 58개
Windows, 작업 관리자 메모리209–224 MB
Windows, 커밋 크기297–298 MB
Mac, 활성 상태 보기 메모리180 MB
메시지 10,000개 불러온 상태
Windows, 작업 관리자 메모리197–218 MB
Windows, 커밋 크기297–302 MB
Mac, 활성 상태 보기 메모리315–324 MB
10,000개를 여는 동안의 최고치
Windows, 작업 관리자 메모리357–367 MB
Windows, 커밋 크기545–560 MB
Mac, 활성 상태 보기 메모리368–380 MB
10분간 유휴 상태 후
Windows, 작업 관리자 메모리102–122 MB
Windows, 커밋 크기308–318 MB
Mac, 활성 상태 보기 메모리234–263 MB

이 비교는 경쟁이 아니라 나란히 놓은 두 측정값으로 읽어 주십시오. 두 시스템은 메모리를 세는 방식이 다릅니다. Mac의 활성 상태 보기 수치에는 macOS가 압축한 메모리가 포함되는 반면, 작업 관리자의 수치는 Windows가 덜어 낸 메모리를 빼고 보여 주며, 커밋 크기는 예약되었지만 한 번도 쓰이지 않았을 수도 있는 메모리까지 셉니다. 기기도 다르고, Mac 빌드는 나흘 더 오래된 것이었습니다. 이 비교가 보여 주는 것은 MailVault가 두 시스템 모두에서 수백 메가바이트 낮은 쪽의 비슷한 수준인 메모리를 쓴다는 것, 그리고 지켜본 10분간의 유휴 시간 동안 어느 시스템에서도 메모리가 늘지 않았다는 것입니다.

이 테스트가 보여 주지 않는 것

• 실제 메시지는 더 큽니다. 테스트 메시지는 아주 작아서 열어 본 메시지의 캐시가 한 번도 가득 차지 않았습니다. 메일을 많이 읽으면 캐시 한도인 128 MB까지 추가로 늘어날 수 있습니다.
• 열흘이 아니라 십 분입니다. 이 유휴 테스트는 빠른 누수를 잡아낼 만큼 길지만, 느린 누수까지는 잡아내지 못합니다. 더 긴 테스트는 다음 과제입니다.
• 노트북 한 대와 Mac 한 대뿐입니다. 그래픽 칩이나 Windows 버전이 다르면 전체의 대부분을 차지하는 WebView2 수치가 달라질 수 있습니다.

이 테스트는 직접 재현할 수 있습니다. MailVault 소스에 있는 ram-footprint 엔드투엔드 테스트로, wdio.ram.conf.js로 실행하며 모든 측정값을 프로세스별로 JSON 파일에 기록합니다.

측정일은 Windows가 2026년 9월 26일, macOS가 2026년 9월 22일입니다. 관련 글: 이메일 50,000통을 밀리초 만에 검색하기.