Steam 클라이언트가 이제 에픽이 바이브 코딩으로 만든 새 런처보다 빠릅니다

Steam Client is now faster than Epic's new vibe coded launcher

respawnfirst.com ▲ 282 댓글 279 starkparker

요약

밸브가 에픽의 새 런처 공개 하루 만에 Steam 클라이언트를 고쳐 실행 속도를 다시 앞질렀습니다.

게임 매체 리스폰퍼스트의 시칸다르 마흐무드가 쓴 글입니다. 에픽은 바이브 코딩(AI에게 맡겨 코드를 짜는 방식)으로 만든 새 런처 미리보기판을 Steam보다 빠르다고 홍보했고, 밸브는 24시간 안에 작은 업데이트로 응수했습니다.

왜 중요한가

  • AI로 새로 짠 런처보다 오래된 클라이언트를 겨냥해 다듬은 쪽이 더 빨랐다는 사례입니다.
  • 에픽이 내세운 가장 큰 장점인 속도 우위가 하루 만에 사라졌습니다.
  • 글쓴이는 에픽의 진짜 약점이 속도가 아니라 Steam에 오래 있던 기능이 없다는 점이라고 봤습니다.

핵심 내용

  • 패치 뒤 Steam의 콜드 부팅(꺼진 상태에서 처음 켜기)은 약 5.23초로, 에픽 Launcher V2의 약 5.47초보다 빨랐습니다.
  • 트레이(작업 표시줄 알림 영역)에서 창을 다시 띄우는 시간은 에픽이 0.36초로 Steam보다 0.06초 앞섰습니다.
  • 글쓴이는 새 런처가 느리기로 이름난 예전 에픽 클라이언트보다는 크게 나아졌다고 인정했습니다.
  • 다만 사용자 리뷰, 원격 플레이, 아이템 거래, 모드 공유 허브 등 18가지 기능이 에픽에 없다고 짚었습니다.
  • 소셜미디어에서는 에픽의 주장을 비웃거나 AI로 만든 스토어에 버그가 많다는 반응이 나왔습니다.

HN 반응

  • 직접 재 보면 Steam의 콜드 부팅이 여전히 10~15초라는 경험담과, 원래 무거운 크로미움 기반 앱끼리의 비교라 기준이 낮다는 지적이 나왔습니다.
  • 바이브 코딩으로 Electron(웹 기술로 데스크톱 앱을 만드는 틀) 대신 가벼운 네이티브 앱을 만들 수 있다는 기대와, 플랫폼마다 따로 만드는 부담을 걱정하는 반론이 맞섰습니다.

댓글

30개 표시 · 전체 279개
  1. tancop HN

    바이브 코딩이 느려터진 Electron 앱만 잔뜩 만들어 낼 줄 알았는데, 이제는 게임 런처끼리 속도 경쟁을 하고 있네요. 이런 흐름이 모든 종류의 소프트웨어로 번졌으면 좋겠어요.

    그건 그렇고, 방금 직접 테스트해 봤는데 Steam은 트레이에서 복원하는 데 2초쯤, 완전히 꺼진 상태에서 켜는 데 10~15초쯤 걸립니다. 에픽의 새 런처는 기사에서 말한 것처럼 각각 0.5초, 5초쯤이고요. 아직 A/B 테스트 중인 걸 수도 있겠네요.

  2. mahboi HN

    좋긴 한데 기준이 너무 낮아요. Steam은 Electron이 나오기도 전에 크롬 기반의 허접한 데스크톱 앱을 개척한 장본인이고, 그래서 Wine에서 Steam을 돌리기도 그렇게 어려운 거죠. 시작과 종료 과정(본인들도 그렇게 부르더라고요)이 제 OS 전체보다 더 길다니까요.

    그러더니 에픽, EA 같은 데서도 비슷한 런처를 만들었죠. 물론 하나같이 윈도 부팅하면 같이 실행되고, 시도 때도 없이 업데이트하고, 닫기를 눌러도 안 닫히고요.

  3. danparsonson HN

    궁금해서 그러는데, Steam을 왜 Wine에서 돌리시는 거예요?

  4. mahboi HN

    맥에서 윈도 전용 게임을 하려고요. 아니면 Proton이 나오기 전의 리눅스에서도 그랬고요. Steam 없이는 게임을 실행할 수 없으니까요.

  5. gsich HN

    처음에는 IE를 썼습니다.

  6. dgellow HN

    초창기 Steam 클라이언트는 크로미움 이전에 Trident 기반이었던 것 같은데, 아닌가요?

    수정: 찾아보니 Trident, 그다음 WebKit, 그다음 Chromium Embedded 순서였던 것 같네요.

  7. mahboi HN

    맞아요. 그래도 마침내 크로미움으로 갈아탔을 때가 여전히 Electron보다는 앞선 시기였어요.

  8. yboris HN

    바이브 코딩으로 Tauri 앱을 만들면 "Hello World" 앱이 130MB가 아니라 3MB쯤으로 나올 수 있습니다.

  9. m_w_ HN

    저라면 한 걸음 더 나가겠어요. 바이브 코딩을 한다면 Tauri는 아예 건너뛰세요. 저는 틈틈이 GitKraken 대체품을 바이브 코딩하고 있는데 egui를 쓰고 있고, 메모리 사용량이 아주 낮습니다. 그 외에는 어차피 어느 쪽이든 코드를 읽지 않으니 차이를 모르겠고요.

  10. wren6991 HN

    리눅스에서 Tauri를 써 보고 나니 Electron이 왜 브라우저를 통째로 같이 배포하는지 이해가 됐습니다. WebKitGTK는 여기저기 거칠거든요.

  11. egeozcan HN

    저는 wails로 붙여넣기 관리자를 바이브 코딩했는데( https://github.com/egeozcan/mahpastes ), 지금 리눅스(bazzite)를 쓰고 있고 렌더링 문제는 하나도 없어요.

  12. wren6991 HN

    제가 부딪힌 문제 중 하나는 "폴더 열기" 대화상자를 띄울 방법이 없다는 거였어요. "파일 열기"로 매핑되어 버립니다. 올바른 훅은 WebKit에도 GTK에도 있는데 WebKitGTK에서는 연결이 안 되어 있어요. 고치는 건 아주 사소할 것 같긴 한데, 패치를 올리려면 뭐가 필요한지 알아보고는 그냥 접었습니다. 이런 자잘한 불편이 정말 많아요.

    CSS나 렌더링에서 이상한 동작도 몇 번 만났는데, 렌더링 성능도 눈에 띄게 나빠 보였고 이쪽이 더 참기 힘들었습니다.

  13. jorl17 HN

    저도 최근에 이걸 바이브 코딩했는데 https://www.rominabox.app/ "빌더" 부분에 Tauri를 써 보니 아주 좋았습니다. 작업하기 정말 즐거웠어요.

    물론 아주 단순한 앱이긴 한데, 저는 수월하다고 느꼈습니다.

  14. kelvie HN

    egui는 CPU 효율이 정말 나쁘지 않나요? 예를 들어 마우스를 그 위로 움직이면 60fps로 다시 그리잖아요.

  15. m_w_ HN

    그렇다 해도 지금까지는 문제가 된 적이 없어요. 완전 바이브 코딩으로 가능한 한도 안에서 메모이제이션에 많이 신경 쓰고 있고요.

    참고로 제가 대체하려는 대상(GitKraken)이 느리고 둔하고 자원을 많이 먹어서, 이기기가 어렵지 않습니다.

  16. tdhz77 HN

    모바일 지원도 없고요.

  17. anthk HN

    egui라면 모를까요.

  18. james2doyle HN

    Tauri를 아예 건너뛰고 진짜 네이티브 앱을 만들 수도 있습니다. 웹을 감쌀 필요가 없어요.

  19. sosodev HN

    그래도 웹뷰 없이 크로스 플랫폼에서 일관된 결과를 얻을 방법은 아직 없잖아요? Tauri도 시스템 브라우저에 의존하고 브라우저마다 어느 정도 다르니 일관적이지 않긴 하겠지만요.

  20. tadfisher HN

    친구여, 일관성이 없는 게 바로 핵심입니다. 이제 플랫폼에 어울리고 모든 표준을 따르는 진짜 네이티브 앱을 만들 엄청난 힘이 생겼어요. 이제 병목은 당신, 아니면 각 대상 플랫폼을 맡아서 네이티브 앱의 감각을 아는 사람입니다.

  21. sosodev HN

    그러니까 제가 플랫폼마다 네이티브 앱을 따로 유지보수하면서, 시각적인 부분만 빼고 모든 면에서 맞추려고 애써야 한다는 거네요? 둘 이상을 쓰는 사람이 있으면 UX가 엉망이 되기 딱 좋아 보이는데요.

  22. Kuyawa HN

    당신이 아니라 코딩 에이전트가 합니다. 세 개 플랫폼에 최소 열 개 언어로요.

    끝까지 Rust로 간다면 플랫폼별 설치 프로그램만 있으면 됩니다.

  23. rafaelmn HN

    에이전트는 학습 분포에 한참 들어맞는 경우가 아니면 UX 결정을 정말 못합니다.

  24. bigstrat2003 HN

    오히려 반대예요. 웹뷰를 쓰는 건 사용자에게 가능한 최악의 UX입니다. 느리고, 메모리를 엄청나게 먹고, 데스크톱과도 잘 어우러지지 않아요. 사람들이 그렇게 만든 유일한 이유는 게을러서였지, 더 나은 제품이 나와서가 아니었습니다.

  25. Rohansi HN

    느리고 메모리를 많이 먹는 건 브라우저 전체를 탓할 일이 아니라 (심하게) 최적화가 안 된 웹사이트 탓이 더 크다고 봅니다. 물론 네이티브만큼 효율적일 수는 없겠지만, 브라우저 최적화에는 엄청난 노력이 들어갔고 대부분의 웹사이트는 최적화를 전혀 안 하니까요.

    메모리 사용량만 봐도 비교하기 흥미로운 사례인데, 웹사이트는 다른 애플리케이션보다 이미지나 영상을 훨씬 많이 불러오는 경향이 있거든요. PNG나 JPEG는 화면에 그리기 전에 전부 압축을 풀어야 해서 크기가 훨씬 커집니다.

  26. skydhash HN

    I'd argue that being slow and using a ton of memory has more to do with (very) poorly optimized websites rather than blaming browsers as a whole.

    (느리고 메모리를 많이 먹는 건 브라우저 전체를 탓할 일이 아니라 (심하게) 최적화가 안 된 웹사이트 탓이 더 크다고 봅니다.)

    웹 브라우저는 거대한 플랫폼입니다. 오디오, 2D·3D 그래픽, 파일 처리, 네트워크 요청 등등... 코드는 엄청나게 많은데 애플리케이션에 필요한 건 아주 작죠. 낭비이고 보안 위험입니다.

  27. Rohansi HN

    그건 애플리케이션에 브라우저를 같이 배포하는 것에 대한 반론일 뿐입니다. 일반 웹사이트나 웹뷰라면 브라우저를 공유하고 자동으로 업데이트되니 별로 문제가 되지 않아요.

  28. newdee HN

    네.

  29. mort96 HN

    맞아요, 문제는 일관성이 없다는 게 아니라 앱을 5개나 만들어야 한다는 거죠.

  30. mikestew HN

    앱을 다섯 개 만들고 있다면 잘못하고 있는 겁니다. 어떤 앱이든 상당 부분은 공통 비즈니스 로직과 연결 코드로 묶을 수 있고, 그 위에 네이티브 표현 계층만 얹으면 됩니다. 단순화한 거 맞아요, 하지만 사람들이 수십 년 동안 정확히 그렇게 해 왔습니다. 일이 더 많아지냐고요? 네, 공통 엔진을 써도 Electron을 띄우는 것보다는 일이 많죠. 거기서 "우리가 내놓는 물건에 대해 조금이라도 신경은 쓰는가?" 하는 질문이 나옵니다. 완성품에 자부심이 없다면 Electron도 그 제품을 구해 주지 못해요.

Hacker News에서 보기 ↗