스크립트
00:00:00크로스 플랫폼 데스크톱 앱을 만든다고 하면 보통 일렉트론(Electron)을 떠올리곤 했지만, 요즘은
00:00:04선택지가 정말 많아졌습니다. 그래서 혼란을 해소하고자 오늘은 가장 뛰어난 세 가지 옵션을 비교해 보겠습니다.
00:00:09Rust로 작성된 타우리(Tauri), 번(Bun) 팀의 일렉트로번(Electro Bun),
00:00:14그리고 디노(Deno)에서 새로 내놓은 디노 데스크톱(Deno Desktop)입니다. 일렉트론을 기준으로 비교해 볼 예정이며,
00:00:20이 채널에서 다뤘으면 하는 다른 도구가 있다면 댓글로 알려주세요.
00:00:23번들 크기, 시작 성능, 런타임 성능, 그리고 개발자 경험, 이 네 가지 측면에서 비교할 것입니다.
00:00:29타임라인에서 결과물을 편집하고 MP4로 출력할 수 있는 화면 녹화 도구를 동일하게 네 번 개발했습니다.
00:00:35이런 종류의 앱을 선택한 이유는 영상 처리가 이러한 도구들의 성능을 극한까지 시험해 볼 수 있기 때문입니다.
00:00:40물론 모든 것이 성능만으로 결정되는 것은 아닙니다.
00:00:44팀의 기술 스택과 어떤 제품을 만들고 있는지에 따라 선택하는 프레임워크가 달라질 수 있습니다.
00:00:49하지만 이 영상이 여러분이 무엇을 기대할 수 있을지에 대한 가이드가 되길 바랍니다.
00:00:58그럼 우리가 만든 애플리케이션의 데모를 간단히 살펴보겠습니다. 먼저 앱을 실행한 뒤,
00:01:03녹화할 화면을 선택하고 녹화 버튼을 누릅니다. 이제 화면을 짧게 녹화해 보겠습니다.
00:01:08녹화가 끝나면 중지 버튼을 누르고, 타임라인에 녹화 영상이 포함된 창이 나타납니다.
00:01:12여기서 불필요한 부분을 잘라내고 '내보내기'를 눌러 MP4로 저장합니다. 앱 자체는
00:01:18매우 간단하지만 여러 API를 사용하고, 영상을 녹화 및 처리하며,
00:01:24UI를 렌더링하기 때문에 꽤 괜찮은 테스트가 될 것입니다. 첫 번째로 확인할 것은
00:01:28번들 크기입니다. 이 앱들은 모두 동일한 기능을 제공한다는 점을 기억하세요. 기준이 된 일렉트론은 323MB입니다.
00:01:35타우리는 57MB, 일렉트로번은 418MB, 그리고 디노는 111MB입니다.
00:01:44모두 MP4 내보내기를 위해 FFmpeg가 포함되어 있는데 이것만으로도 45MB를 차지합니다. 일렉트로번이 이렇게
00:01:52큰 이유는 크로미움(Chromium)을 함께 배포해야 했기 때문입니다. 정말 노력했지만,
00:01:56화면 녹화 기능이 네이티브 시스템 웹뷰에서 작동하게 하려면, 특히 자바스크립트에서 기록해야 했습니다.
00:02:01화면을 캡처하려면 Screen Capture API와 getDisplayMedia 함수가 필요합니다. 브라우저에 화면을 요청하면,
00:02:06스트림을 넘겨주고 미디어 레코더가 이를 인코딩합니다. 일렉트론과 디노는 이런 방식을 씁니다. 하지만 일렉트로번은
00:02:12해당 API를 전혀 포함하지 않아서, 유일한 해결책은 크로미움을 다시 넣는 것이었습니다.
00:02:17그 과정에서 약 200MB의 용량이 추가되었습니다. 디노의 API는 이 기능을 구현했기에 같은 코드를 사용하되
00:02:24크로미움 없이 실행됩니다. 그래서 디노의 번들 크기는 약 100MB, 일렉트로번은
00:02:30거의 400MB에 육박하게 됩니다. Rust는 이 중 아무것도 필요하지 않았는데, 타우리는 웹뷰에서
00:02:35녹화하지 않기 때문입니다. 백엔드에서 네이티브 화면 캡처 키트를 통해 직접 수행합니다.
00:02:40이것은 퀵타임(QuickTime)이 사용하는 것과 동일한 macOS 프레임워크로, 백엔드에서 모든 녹화가 이루어집니다. 여러분은
00:02:46디스플레이와 코덱, 파일 경로만 전달하면 됩니다. 웹뷰는 오직 UI일 뿐이며, 단 한 프레임도 처리하지 않습니다.
00:02:52또한 자바스크립트 빌드에서는 직접 처리해야 했던 기능들을 기본적으로 제공받습니다.
00:02:56Screen Capture Kit이 마이크와 시스템 오디오를 직접 믹싱하여 완성된 MP4를 만들어냅니다. 저는
00:03:02타우리 앱에도 FFmpeg를 넣어 다양한 포맷으로 내보낼 수 있게 했지만, 엄밀히 말하면 이는 선택 사항입니다.
00:03:07이제 앱을 실행해 시작 시간을 측정해 보겠습니다. 10번 반복 측정하여 중간값을 냈습니다.
00:03:13기준인 일렉트론은 273ms, 타우리는
00:03:19311ms였습니다. 일렉트로번은 773ms였고, 디노는 242ms였습니다.
00:03:29의외였던 점은 타우리가 가장 빠르지 않았다는 것입니다. 일렉트론보다 살짝 느렸고, 디노가
00:03:34전체 1위를 차지했습니다. Rust와 시스템 웹뷰를 사용하면 즉시 시작될 것이라 예상했지만,
00:03:39어쨌든 렌더링 엔진이 부팅되어야 하므로 그 과정이 시작 속도에 영향을 미치는 것 같습니다.
00:03:44일렉트로번이 눈에 띄게 느렸는데 일렉트론보다 3배 가까이 느렸습니다. 런처가 부팅되고, 번(Bun)이 부팅되고, 크로미움이 부팅되는
00:03:50세 가지 런타임이 연쇄적으로 작동하기 때문이며 실제로 그 속도 차이가 느껴집니다.
00:03:56이번엔 실행 후 메모리 점유율을 보겠습니다. 앱이 실행된 상태에서 일렉트론을 기준으로,
00:04:01128MB였습니다. 타우리는 109MB, 일렉트로번은 208MB, 디노는 98MB를 기록했습니다.
00:04:10디노와 타우리는 비슷했고, 일렉트로번은 다른 앱들의 거의 2배를 사용했습니다.
00:04:15타우리의 경우 마케팅에서 말하는 10배 성능 향상과는 거리가 멉니다. 디스크 공간은 확실히
00:04:21훨씬 작지만, 실행 중인 메모리 점유율은 다른 도구들과 비슷합니다.
00:04:26직접 확인하실 때 주의할 점이 하나 있는데, 타우리는
00:04:31시스템 웹뷰를 사용하며 해당 프로세스들은 앱의 자식 프로세스가 아닙니다. macOS가 별도로 시작하기 때문에
00:04:36활성 상태 보기(Activity Monitor)에서 타우리는 약 36MB로 보이고 일렉트론보다 3배 빠른 것처럼 보이지만,
00:04:42사실은 그렇지 않습니다. 관련 프로세스를 모두 더하면 약 109MB가 되어 테스트 결과와 일치하게 됩니다.
00:04:48화면 녹화 성능 자체는 타우리 앱이 훨씬 뛰어났습니다. 아마도 웹뷰에서 데이터를 녹화하고,
00:04:53브리지를 통해 전송하는 방식이 아니라,
00:04:58시스템 기본 SDK를 사용해 직접 기록하기 때문일 것입니다.
00:05:0460fps에 가까운 녹화를 원하신다면 Rust와 타우리가 최고의 선택이 될 것입니다.
00:05:10이제 개발자 경험을 살펴보겠습니다. 플랫폼마다 차이가 있어 이 간단한 앱을 만드는 과정이 전혀 쉽지 않았습니다.
00:05:15전반적으로 일렉트론과 타우리가 가장 구현하기 쉬웠고,
00:05:20디노와 일렉트로번은 수많은 문제와 시스템 충돌을 겪었습니다. 디노에서는 녹화를 시작하고
00:05:26앱을 숨기면 전체 애플리케이션이 바로 종료되었습니다. 아마도 화면이 표시되지 않으면,
00:05:30디노는 작업이 끝났다고 판단하여 프로세스를 강제로 종료하는 것 같습니다.
00:05:36그래서 뷰를 화면 밖으로 숨기는 방식의 임시방편을 써야 했습니다.
00:05:41일렉트로번은 화면 녹화를 위해 크로미움을 번들로 포함해야 한다는 문제가 있었고, 어찌 된 일인지
00:05:463D 렌더링을 위한 Three.js와 Babylon.js에 의존하고 있어 번들 크기가 비대해졌습니다.
00:05:53결론적으로 저는 타우리를 선택하겠습니다. Rust로 프로그래밍하고 싶지 않다면,
00:05:58타입스크립트 개발자에게는 여전히 일렉트론이 가장 성숙한 플랫폼입니다. 디노도 괜찮아 보이지만,
00:06:04플랫폼이 성숙해지려면 시간이 조금 더 필요해 보입니다. 일렉트로번은 최악이었습니다.
00:06:09여러분이 판단하는 데 도움이 되었으면 합니다. 여러분의 의견을 댓글로 알려주세요.
00:06:13디노 데스크톱에 대한 영상도 따로 제작했으니, 더 알고 싶으시면 이 영상을 클릭해 보세요.
00:06:18지금까지 Betterstack의 워렌이었습니다. 시청해 주셔서 감사합니다. 다음에 뵙겠습니다.