Steam Frame, Raspberry Pi, Asahi Linux를 위한 Factorio의 ARM64 Linux 포팅과 출시 소식입니다.
안녕하세요,
제가 펭귄에 관한 이야기를 더 들려드리는 동안 함께 모여 주세요...
Valve이 처음 차세대 하드웨어를 발표했을 때, 저는 Steam Controller에는 매우 흥분했고 Steam Machine에는 어느 정도 흥분했지만, Steam Frame에는 그다지 흥분하지 않았습니다. 친구의 HTC Vive로 VR을 해볼 기회가 있었고, 프라하의 Wube 사무실을 방문할 때면 위층에 있는 회사의 Valve Index로 플레이하곤 했습니다. 이런 경험은 매우 멋졌지만, 플레이 공간을 비우고, 헤드셋을 PC에 연결하고, 공간 추적을 위한 라이트하우스를 설치하는 데 필요한 준비 과정은 VR 게임을 즐기기 위한 진입 장벽을 제가 감당하고 싶은 수준 이상으로 높였습니다. 저는 VR을 그저 제게는 맞지 않는 기믹으로 치부했습니다.
VR 엔지니어와 개발자들은 진입 장벽 문제를 알고 있었기에, 최근 몇 년 동안 헤드셋은 "인사이드아웃" 추적을 지원하도록 발전해 왔습니다. VR 공간에서의 위치를 추적하기 위해 전용 고정 센서(라이트하우스)를 설치하는 대신, 인사이드아웃 헤드셋은 내장 카메라로 방 안에서의 위치를 추적하고, 이를 이용해 현실 세계의 위치를 VR 공간으로 변환합니다. 이로써 필요한 라이트하우스 설치가 사라지며, 여기에 모든 연산 장치와 배터리를 헤드셋 안에 넣으면 선과 번거로움에서 자유로운, 콘솔 같은 무선 VR 경험을 얻을 수 있습니다. 헤드셋을 쓰고 바로 플레이하면 됩니다.
독립형 VR은 진입 장벽을 크게 낮춰 주지만, 지금까지는 최선의 선택지가 궁극적 동기와 개인정보 보호 기준이 제게 받아들일 수 없는 기업들에 묶여 있었기 때문에 관심이 없었습니다. 하지만 Steam Frame은 상황을 바꿉니다. Valve이 개인정보 보호에 더 친화적이라는 점에 더해, 이것은 위장한 Linux PC입니다. 헤드셋에 직접 만든 소프트웨어를 설치하거나 운영 체제를 완전히 교체하고 싶다면, 그것은 여러분의 선택입니다! 이 모든 점이 매우 매력적으로 다가왔고, 저는 곧 하나를 구매할 계획을 세우기 시작했습니다.
Steam Frame은 ARM64 Linux 컴퓨팅이 더 대중화될 기회를 의미합니다. 지금까지 ARM64 Linux를 위한 최선의 선택지는 Raspberry Pi(상대적으로 약한 단일 보드 컴퓨터), Ampere 서버(일반인이 접근하기 어려움), 그리고 Apple Silicon MacBook에서의 Asahi Linux(여전히 아주 초기 알파 단계)로 제한되어 있었습니다. Steam Frame은 실용적인 ARM64 Linux 사용 사례의 아주 짧은 목록에 합류하며, Frame에서 VR 타이틀과 함께 전통적인 2D 게임을 강조하는 Valve 덕분에 저는 마침내 Factorio를 ARM64 Linux로 포팅할 구실을 얻었습니다.
포팅 과정에서 가장 많은 작업이 필요했던 부분은 실제로 Frame과 전혀 관련이 없었습니다. 바로 x86 -> ARM64 크로스 컴파일 설정입니다. 무엇을 해야 할지 전혀 몰랐기 때문에, 처음 몇 시간은 이 과정을 조사하는 데 썼습니다. 다행히 우리가 선택한 Linux 컴파일러인 Clang은 크로스 컴파일을 꽤 잘 지원하며, 결국 필요한 것은 세 가지뿐입니다.
단연 가장 도움이 된 자료는 mcillioni의 이 블로그 글이었으며, 요구 사항과 과정을 간결하게 설명해 주었습니다. 감사합니다!
시스루트를 얻기 위한 제 초기 해결책은 mcillioni의 스크립트를 수정해 Raspberry Pi에서 시스템 파일을 추출하는 것이었습니다. 이것은 잠시 동안 작동했지만 지속 가능한 해결책은 아니었습니다. 그러자 Sanqui가 debootstrap라는 훌륭한 도구를 알려주었습니다. 이 도구는 원하는 디렉터리에 ARM64 Debian 시스템 파일을 설치하는 데 사용할 수 있습니다. 이는 로컬 개발의 편의성과 빌드 서버 양쪽 모두에 매우 좋은 해결책으로 판명되었습니다.
우리는 의존성을 정적으로 링크하는 편을 선호하며, FASTBuild라는 다소 특이한 빌드 시스템을 사용하기 때문에 새 플랫폼용 의존성을 빌드하는 일은 때때로 까다로울 수 있습니다. 거의 모든 것은 큰 문제 없이 작동했지만, Linux에서만 사용하고 다른 곳에서는 전혀 사용하지 않는 의존성이 하나 있습니다. 바로 OpenSSL입니다.
OpenSSL은 설정 가능성이 매우 높은 라이브러리이고, 빌드 시스템도 꽤 복잡합니다. 이를 FASTBuild로 직접 옮기는 대신, FASTBuild가 메타빌드 시스템인 Perl 스크립트를 호출하게 하고 생성된 Makefile을 실행하는 방식으로 OpenSSL을 빌드합니다. OpenSSL의 다소 난해한 문서와 Perl에 익숙하지 않았던 탓에 ARM64용 OpenSSL 빌드는 약간 도전적이었지만, 마침내 전달해야 할 올바른 플래그와 인수 조합을 알아냈고 게임의 모든 정적 의존성을 빌드했습니다!
저는 Factorio Linux 크로스 컴파일을 단 두 단계로 줄였습니다. just create-sysroot arm64를 실행해 debootstrap으로 시스루트를 생성한 뒤, just arch=arm64 build를 실행해 컴파일하면 됩니다!
Valve은 친절하게도 개발 키트 하나가 아니라 _두 개_를 보내 주었습니다. 하나는 프라하 사무실로, 다른 하나는 미국에 있는 제 집으로 직접 보냈습니다! 하드웨어에 대한 첫인상은 매우 긍정적이었습니다. 이것은 대단히 가볍고(Steam Deck 무게의 2/3!), 특히 상단 스트랩을 장착하면 장시간 착용하기에도 매우 편안합니다. 제가 지금까지 써 본 VR 헤드셋 중 가장 편안합니다.
Factorio를 Frame에서 실행하는 일은 비교적 간단했지만, 몇 가지 넘어야 할 관문이 있었습니다. Valve은 "Steam Linux Runtime"(steamrt)이라는 도구를 제공하며, 이는 네이티브 Linux 게임이 대상으로 삼을 수 있는 안정적인 동적 라이브러리 기반을 제공하여 동적 의존성 지옥과 관련된 많은 문제를 우회합니다. 우리는 의존성을 정적으로 링크하기 때문에 게임 실행에 steamrt가 필요하지는 않지만, Steam은 게임이 이를 선택 해제하는 것을 허용하지 않으므로 steamrt 1.0을 대상으로 해왔습니다.
하지만 steamrt 1.0에는 ARM64 버전이 없습니다. 사실 ARM64를 지원하도록 업데이트된 것은 steamrt 4.0뿐이었습니다. 따라서 업그레이드할 시간이었습니다. steamrt 버전은 모든 플레이어에게 영향을 미치는 전역 설정이므로, Steam을 통해 ARM64 빌드를 배포할 준비가 되었을 때 모두를 위해 Factorio의 steamrt 버전을 4.0으로 바꾸는 어려운 결정을 내려야 했습니다. 다행히 이로 인한 문제는 발견하지 못했습니다.
ARM64 Steamworks 공유 라이브러리에 링크할 수 있도록 Steamworks SDK 버전도 업데이트해야 했습니다. 이 업데이트는 2.1.15에 적용되었고, 핫픽스가 필요했던 한 가지 주요 버그가 있었습니다. 다행히 그것이 가장 심각한 일이었고, 또 다른 문제는 하나만 보고되었습니다.
Steam Frame은 Steam Deck 및 Steam Machine에서 사용되는 것과 동일한 SteamOS Devkit Client 소프트웨어를 사용하므로, Frame에서 개발자 모드를 활성화하고 제 노트북의 개발 키트 클라이언트에 연결한 다음 빌드를 업로드하기만 하면 되었습니다. 호환되지 않는 glibc 버전(안타깝게도 피할 수 없는 동적 의존성)과 관련된 몇 번의 실패 끝에, 2026년 2월 처음으로 Steam Frame에서 Factorio를 성공적으로 부팅했습니다!
이 이미지는 SteamOS의 초기 개발 빌드에서 촬영되었으며, 최종 경험을 나타내지 않습니다.
Valve과 함께 해결한 몇 가지 문제가 있었지만, 전반적으로 매우 매끄럽게 실행되었습니다! 2.1 출시 전인 2026년 5월 Wube LAN 파티 동안 대부분의 시간 동안 사무실 개발 키트를 게임에 연결했고, Nintendo Switch 및 Apple Silicon 포팅에서 이루어진 이전 노력 덕분에 ARM64 대 x86 관련 동기화 불일치는 한 번도 경험하지 않았습니다. Frame은 문제없이 게임을 따라갈 수 있었고, 플레이를 마쳤을 때 저는 Frame으로 플레이 중이었습니다.
제가 Factorio를 하고 있을까요? 아무도 모르죠...
Frame에서 실행할 때 Factorio는 Steam Deck과 동일한 그래픽 설정을 사용하며 720p로 실행됩니다. 게임은 대부분의 경우 60 FPS를 쉽게 유지하지만, 복잡한 장면에서는 약간 떨어질 수 있습니다. 그래픽 설정을 낮춰도 성능에는 도움이 되지 않았으며, 이는 Factorio의 OpenGL 렌더러가 Frame의 소프트웨어 스택과 상호 작용하는 방식에 더 근본적인 한계가 있음을 시사합니다.
CPU 측면에서 네이티브 ARM64 빌드의 성능은 FEX를 통해 실행되는 x86 빌드보다 약 11% 더 빠릅니다.
맵: Klonan | 4k trains Megagrid | 10k SPM | Base game + Elevated rails
FEX 변환 계층의 성능은 매우 인상적입니다!
Frame에서 실행되는 2D 게임은 VR 기능에 접근할 수 없으므로, Factorio는 대체로 Steam Deck이나 Nintendo Switch에서와 동일하게 플레이됩니다. 하지만 게임패드 모드에서도 Factorio는 마우스 이동과 클릭에 반응하며, 이는 우연히도 Frame의 레이저 마우스와 잘 어울립니다. 선택 도구를 사용하거나 GUI 요소를 빠르게 클릭할 때 레이저 마우스를 전환하는 것이 매우 편리하다는 것을 알게 되었습니다. 그리고 물론 Steam Controller를 연결하여 Steam Deck과 매우 비슷한 트랙패드 경험을 얻거나, 마우스와 키보드를 연결해 전통적인 방식으로 플레이할 수도 있습니다!
Valve은 Proton+FEX를 통해 실행되는 Windows 게임과 Lepton을 통해 실행되는 Android 게임 지원을 우선시해 왔기에, 네이티브 ARM64 Linux 게임을 위한 기반 시설은 잘 정의되어 있지 않습니다. 우리는 모든 플레이어에게 두 바이너리를 모두 제공하고 호스트 아키텍처에 따라 올바른 바이너리를 실행하는 셸 스크립트를 사용하는 우회책을 구현하기 위해 Valve과 협력해야 했습니다. 일부 커뮤니티 구성원이 이미알아챘듯이, ARM64 Linux Steam 빌드는 이미 모든 Linux Steam 실험 버전 플레이어에게 배포되었습니다! 이를 작동시키는 과정에는 실제 환경에서의 시행착오가 있었고, 그 결과 재미있는 오해와 게임 실행 문제가 발생했습니다.
Factorio는 공식적으로 Steam Frame Certified입니다! 이 인증은 게임이 Frame에서 훌륭하게 작동한다는 Valve과 Wube의 보증입니다. Gamers Nexus와 Dave2D의 Steam Frame 리뷰에서 "Great on Frame" 페이지에 잠깐 등장한 Factorio를 발견해 기뻤습니다.
개발 키트를 보내 주시고 문제가 생겼을 때 이메일에 신속히 답해 주신 Valve에 감사드립니다. 또한 Steam Frame 출시에 맞춰 모든 것을 준비하기 위해, 시차 때문에 종종 늦은 밤까지 저와 오랜 시간 함께 작업한 Wube 친구들 Sanqui와 Klonan에게도 감사드리고 싶습니다. Klonan의 훌륭한 표현을 빌리자면, "여름의 끝, 비 내리던 그 밤에 우리 모두는 이 순간을 함께 나눴습니다."
하지만 Factorio를 실행할 수 있는 새 기기는 Steam Frame만이 아닙니다...
물론 Raspberry Pi도 지원할 것입니다. 특히 개발에 사용한 초기 시스루트를 얻기 위해 제 것을 사용했다는 점을 고려하면 더욱 그렇습니다! 안타깝게도 Pi의 OpenGL 지원은 꽤 제한적이므로, Pi에서 서버를 쉽게 호스팅할 수는 있지만 그래픽을 사용해 게임을 플레이할 수는 없습니다.
몇 주 전 비밀리에 제 Pi에서 서버를 호스팅하고 Steam Frame으로 접속해, 친구 _CodeGreen과 제 동생 Doomquill에게 동기화 불일치 테스트를 도와달라고 요청했습니다. 무작위 플레이어 몇 명도 접속했고, 동기화 불일치나 다른 문제는 전혀 발생하지 않았습니다. 자신도 모르게 테스트 대상이 되어 준 darklich14와 Erielhonan에게 감사드립니다!
네이티브 ARM64의 CPU 성능은 box64를 통해 실행되는 x86보다 약 28% 더 빠릅니다.
맵: Klonan | 4k trains Megagrid | 10k SPM | Base game + Elevated rails
하드웨어: Raspberry Pi 5 8GB
하지만 아직 더 있습니다!
그렇습니다. Factorio는 ARM 프로세서를 탑재한 MacBook용 Linux 배포판인 Asahi Linux에서도 작동합니다! Sanqui의 친구가 친절하게도 몇 가지 빌드를 테스트해 주었고, 모든 것이 훌륭하게 작동하는 듯합니다. 이는 무엇보다도 기분 좋은 우연입니다. 작동하게 하기 위해 특별한 노력을 기울이지 않았기 때문입니다. 안타깝게도 Wube에는 Asahi Linux가 설치된 MacBook을 가진 사람이 없으므로, 우리가 알지 못하는 문제가 거의 확실히 있을 것입니다. 감수하고 플레이하세요!
벤치마크 결과는 이들 중 가장 극적이었습니다. 네이티브 ARM64 버전은 FEX를 통해 실행되는 x86 버전보다 무려 35% 더 빠릅니다.
맵: Klonan | 4k trains Megagrid | 10k SPM | Base game + Elevated rails
하드웨어: Macbook Pro M1 Pro (Model A2442, 8-Core, 16GB, 512GB)
Factorio를 ARM64 Linux로 포팅하는 과정은 매우 재미있고 교육적이었으며, 이 작업을 맡을 수 있었던 것에 매우 감사하게 생각합니다. VR과 다른 ARM64 Linux 기기에서 Factorio를 즐겁게 플레이하시기를 바랍니다!
우리 플레이어층은 적어도 11년 동안 Factorio의 Linux ARM 포트를 요청해 왔습니다. 우리는 귀를 기울이고 새 하드웨어의 가능성에도 흥분하지만, 새로운 플랫폼을 지원하는 데는 개발 시간, 테스트, 장기 지원 측면에서 공짜가 없습니다. 수년에 걸쳐 이 포트의 실현 가능성을 정기적으로 재평가했지만, 가장 최근에는 하드웨어 측면에서 벽에 부딪혔습니다. ARM 서버는 그저 구할 수 없는 물건처럼 보입니다. 하드웨어 제공업체는 Ampere Altra 서버를 조달하지 못했고, 독일 VPS 제공업체 Hetzner의 ARM64 가상 서버는 계속 품절 상태입니다. 결국 x86-64에서의 크로스 컴파일로 결정했고, 이제 Raspberry Pi 5를 전용 테스트 실행기로 사용하고 있습니다.
네이티브 ARM64 Linux를 실행하는 Steam Frame은 이러한 노력을 결승선 너머로 밀어준 촉매제가 되었으며, 오늘 모든 ARM64 Linux 사용자에게 이 포트를 제공하게 되어 기쁩니다!
언제나 그렇듯, 여러분의 생각을 담은 차이를 포함하고 GPG 키로 서명한 패치를 평소의 장소에 제출해 주세요.
다음 주에 뵙겠습니다!
