바이브 코딩이 느린 Electron 앱만 양산할 줄 알았는데, 오히려 게임 실행기 사이에 속도 경쟁이 벌어지고 있음. 이런 흐름이 모든 소프트웨어로 확산되길 바람.
방금 직접 측정해 보니 Steam은 트레이에서 복원하는 데 약 2초, 완전히 종료한 상태에서 시작하는 데 10~15초가 걸림. 새 Epic 실행기는 기사대로 각각 약 0.5초와 5초였음. 아직 A/B 테스트 중인지도 모르겠음.
바이브 코딩으로 Tauri 앱을 만들면 “Hello World” 앱의 크기를 130MB가 아니라 3MB 정도로 줄일 수 있음.
바이브 코딩은 엄격한 타입 시스템과 특히 잘 맞는다고 봄. Claude Code는 결과가 “맞을” 때까지 반복하는데, 타입 시스템은 그 기준 일부를 컴파일 과정에 넣어 최소 요건을 통과하지 못한 코드를 확실히 막아줌.
Claude로 성능 좋은 Rust 코드를 생성하는 데 꽤 좋은 결과를 얻었음.
기술 부채 정리를 강제하는 계기로 봄.
Steam은 내가 쓰는 앱 중에서도 시작이 가장 느린 축에 속함. Photoshop도 비슷하게 굼뜸.
경쟁이라고 보기도 어려움. Steam 업데이트가 Epic의 도발보다 하루 먼저 나왔으니 오히려 웃긴 상황임.
“Epic은 바이브 코딩으로 빨라졌지만 Valve는 오래된 생태계의 정밀 최적화로 AI 속도전을 이겼다”는 구분에 동의하기 어려움. 프로젝트 최적화는 AI로 하기 가장 쉬운 작업 중 하나임.
Valve 엔지니어들이 AI를 쓰지 않는다는 것도 믿기 어려움. “Claude, 시작이 느린 원인을 순위별로 정리해 줘” 다음에 “이제 고쳐 줘”라고 하면 되는 작업임. 양보해도 다들 일종의 암흑의 숲처럼 몰래 쓰고 있다는 정도임.
제대로 된 벤치마크 스크립트를 마련하자 Opus 4.8인가 하는 모델이 내 터미널 앱을 ghostty와 kitty보다 빠르고 메모리도 적게 쓰도록 바꿔줬음. 특별히 흥미로운 일도 아님.
HN에서 읽은 글 중 가장 씁쓸한 축에 속함. 이곳의 상태와 댓글들이 얼마나 망상에 빠져들었는지 보여줌.
암흑의 숲 가설은 자신의 존재와 위치를 경쟁자에게 알리는 것이 위험하므로 외계 문명들이 침묵하고, 그래서 우리가 외계 생명체를 찾지 못한다는 가설임. 그런데 여기서는 무슨 뜻으로 쓴 것임?
Valve 엔지니어들도 AI에게 더 빠르게 만들라고 했을 가능성이 높음. 다만 Reddit처럼 AI에 극도로 적대적인 곳을 생각하면 Epic이 바이브 코딩을 공개적으로 인정한 건 자충수에 가까움. 그냥 “더 빠르고 Linux도 지원함”이라고 했으면 인터넷의 사랑을 받았을 것임.
Valve가 AI를 안 쓸 수도 있지 않겠음? 그곳 엔지니어들은 자신이 하는 일을 잘 아는 듯하고, 숙련된 엔지니어에게 LLM의 효용은 매우 제한적임.
이 상황에서 가장 먼저 드는 생각은 Valve를 대신해 화내고 방어하느라 얼마나 시간을 낭비하느냐는 것임. 앱 자체와 준사회적 관계를 맺은 듯함.
“빠진 기능”이라는 목록도 마찬가지임. 게임 아이템 커뮤니티 장터, 이용자 간 직접 아이템 거래, 디지털 트레이딩 카드·레벨·포인트 상점 같은 기능은 더 많은 개발자가 넣는 걸 잊어버렸으면 좋겠음.
플랫폼의 “명예”를 지키느라 시간을 낭비하는 건 수십 년째 이어짐. Sega 대 Nintendo, PlayStation 대 Xbox를 거쳐 이제 Steam 대 EGS가 됐을 뿐임.
그래도 Steam에는 Linux에서 Windows 게임 실행 지원, 게임별 포럼·스크린샷·아트워크·공략처럼 유용한 기능이 있음. Microsoft라는 생존 위협에 대응하려는 목적이더라도 Linux 지원은 고마운 일이고, 자체 커뮤니티가 없는 게임에는 Steam 커뮤니티가 특히 유용함.
언제든 취소될 수 있는 이용권에 불과한 게임을 할인 행사로 합리적인 가격에 살 수 있다는 것도 장점임. 60파운드에 사느니 5파운드가 될 때까지 기다리겠음.
내가 본 한 기존 구매자는 판매가 중단된 게임도 계속 내려받을 수 있었고, 음악 라이선스 때문에 업데이트된 게임도 약간의 수고를 들이면 옛 버전을 받을 수 있음. Steamworks만 DRM으로 쓰는 게임은 우회가 쉬워 Valve가 망하더라도 라이브러리 대부분은 계속 즐길 수 있으리라 봄. 별도 DRM과 실행기를 강요하는 배급사보다는 나음. Valve가 청소년에게 도박과 단기매매를 팔아 부를 쌓는다고 해도 유용한 기능까지 사라지는 건 아님.
Steam 서브레딧 인기 게시물 제목이 “당했네, 얘들아”임. 마치 자신들이 Valve 직원인 듯함. 본문은 “기업이 어떻게 이렇게 현실 감각이 없을 수 있나, 창피하다”라는 내용임.
내가 Valve를 옹호하는 건 Linux 최종 사용자 경험을 신경 쓰는 유일한 회사처럼 보이기 때문임. Rocket League에도 Linux 버전이 있었지만 Epic이 없애버렸음.
최근 Steam Frame을 산 이유도 절반은 Linux 데스크톱 지원과 ARM JIT 변환 같은 Valve의 연구개발을 지원하기 위해서임. “지갑으로 투표하라”고 하면서, 실제로 계속 구매하며 지지하는 회사가 생기면 왜 옹호하느냐고 비난하는 건 이상함. 가상 스티커나 소소한 보상보다 내 게임들이 Linux에서 잘 실행되는 게 중요함.
경쟁사들은 실망스러움. VR 쪽에는 Meta가 있고, Epic은 캐릭터만 쏟아내는 익스트랙션 슈터와 열 때마다 더 성가셔지는 실행기를 만듦. Microsoft는 스튜디오들을 없애고, EA와 Ubisoft는 구매한 게임을 없앤 뒤 이용자를 외면함.
Valve는 투자자 수익을 위해 모든 걸 악화시키려는 압력에 저항하는 거의 유일한 회사임. 비상장으로 남아 있는 덕분에 가능한 일들이 좋음. 사모펀드가 인수하면 Half-Life 후속작과 모바일판을 줄줄이 내놓고 전부 망쳐버릴 것 같음.
이번에는 그냥 Epic을 정말 싫어해서 그러는 것 같음.
Steam 클라이언트가 이렇게 형편없는데 왜 더 일찍 고치지 않았는지 모르겠음. 변명의 여지가 없음.
Steam이 형편없다는 건 2005년 이후로 거의 못 들어본 평가 아닌가? 빨라지면 좋지만 완전 종료 후 10초의 시작 시간은 큰 문제가 아님. 대개 계속 켜두기도 함. 메모리 사용량, 게임 목록, 전반적인 기능이 훨씬 중요함.
이 업데이트는 한동안 베타 채널에서 다듬어지고 있었음. Steam은 베타를 꾸준히 갱신하고 주기적으로 일반 채널에 반영함.
시점으로 보면 주된 목적은 Steam Frame일 것 같음. Steam은 단순 실행기가 아니라 Steam Machine, Steam Deck, Bazzite 등의 데스크톱 환경 전체이기도 함. 이런 기기에서는 몇 초 차이가 대체로 크게 느껴지지 않음.
하지만 얼굴에 쓰고 시야를 완전히 가린 상태로 부팅할 Steam Frame에서는 첫 상호작용까지 걸리는 시간이 훨씬 절실함. 단순히 빠르면 좋은 수준을 넘어 사용감과 첫 사용 경험에 직접 영향을 줌. 평소에는 절전 모드를 쓰더라도 완전 부팅이나 재부팅 때는 매초가 느껴질 것임.
훨씬 전부터 계획된 업데이트였고, 시점이 우연히 겹쳤을 뿐임.
좋지 않긴 하지만 형편없다고까지 하지는 않겠음. Linux에서 문맥 메뉴가 무작위로 작동하지 않는 현상 같은 불편이 남아 있음. 관련 설정을 껐다 켜도 별 효과가 없어 Big Picture 모드를 써야 하는데, 이것만 고치면 클라이언트에 불만이 없을 것임.
그래도 내 관심사는 클라이언트보다 게임이고, 게임은 Linux에서 매끄럽게 돌아감!
Epic이 독점권을 사들이는 대신 개발자와 이용자를 위한 기능·품질 경쟁을 시작하는 것이라면 전적으로 환영함.
이제 자존심 대결이 된 것인가? Gabe Newell 사진을 포함해 그 사이트의 글투가 꽤 불쾌하게 느껴짐.
AI 밈 사이트이지 제대로 취재하는 매체가 아님. Steam 실행 시간의 근거도 다른 것과 비교하지 않은, 맥락 없는 영상 한 조각뿐임.
AI가 메모리를 적게 쓰고 빠른 앱을 만드는 법을 배울 가능성은 얼마나 될까? 사람에게는 상당한 지적 노력을 요구하면서도 보상은 적고, 사용자에게는 큰 이익을 주는 작업 같음.
최근 Rust로 작성한 Listary 새 베타를 알게 됐는데 정말 빠름. 이전 버전은 계속 충돌했음. AI에게 Rust 방식으로 코딩하라고 요청하는 게 지름길일 수도 있겠음.
Epic에서 무료로 받느니 Steam에서 돈을 내고 구매할 정도로 Epic이 별로임.
준비 완료 처리를 앞당기고 부수적인 정보는 백그라운드에서 가져오는 것 아닐까 의심했는데, 조금 역공학해 보니 실제로 클라이언트를 더 일찍 띄우도록 바꾼 것이었음.
Steam 클라이언트 자체는 원래 빨랐고, 로딩 시간의 대부분은 지금도 앞으로도 네트워크 속도에 달려 있음.