▲

Wine 11, 커널 수준에서 Linux의 Windows 게임 실행 방식을 재작성해 대규모 성능 향상 달성

 (xda-developers.com)
10P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • Linux에서 Windows 게임 실행 구조를 커널 수준에서 전면 재설계해, 기존 wineserver 기반 동기화 병목을 제거
  • 새로운 NTSYNC 드라이버가 NT 동기화 객체를 커널에서 직접 처리하며, 최대 8배 이상의 FPS 향상을 기록
  • WoW64 완성으로 64비트 Linux에서도 32비트 Windows 앱을 별도 라이브러리 없이 실행 가능
  • Wayland 드라이버 강화, Vulkan 1.4 지원, Bluetooth·Force feedback 개선 등 그래픽·입출력 전반의 호환성 확대
  • Proton, SteamOS, Lutris 등 Wine 기반 생태계 전반에 성능과 안정성 향상 효과가 확산됨

Wine 11의 핵심 변화

  • Wine 11은 단순한 연례 업데이트가 아니라, Linux에서 Windows 게임 실행 방식을 커널 수준에서 재작성한 대규모 개편판

    • 수년간의 누적된 버그 수정과 성능 개선 외에도 NTSYNC 지원, WoW64 완성, Wayland 드라이버 강화 등 구조적 변화 포함
    • Proton, SteamOS 등 Wine 기반 프로젝트 전반에 성능 향상이 확산됨

기존의 한계와 임시방편

  • 과거 Wine은 Windows의 NT 동기화 프리미티브(mutex, semaphore, event 등)를 Linux에서 완벽히 구현하지 못함
    • 각 스레드 간 동기화를 위해 매번 wineserver로 RPC 호출을 수행, 초당 수천 회의 호출이 프레임 지연과 불규칙한 타이밍을 유발
  • Esync는 eventfd를 활용해 wineserver 호출을 줄였으나, 파일 디스크립터 한도 문제 발생
  • Fsync는 futex 기반으로 더 빠르지만, 커널 외부 패치가 필요해 일반 배포판에서는 사용이 어려움
    • Linux 5.16의 futex_waitv는 Fsync의 원형과 다르며 완전한 대체는 아님
  • 두 방식 모두 임시방편적 해결책으로, 일부 NT API(예: NtPulseEvent, NtWaitForMultipleObjects의 wait-for-all 모드)는 정확히 구현 불가

NTSYNC — 커널 수준의 동기화 재설계

  • NTSYNC는 Linux 커널에 새로운 /dev/ntsync 장치 드라이버를 추가해 Windows NT 동기화 객체를 직접 모델링
    • 사용자 공간이 아닌 커널 내부에서 동기화 처리, wineserver 왕복 호출 제거
    • 큐 관리, 이벤트 의미론, 원자적 연산을 모두 커널이 직접 수행
  • 개발자는 Esync와 Fsync를 만든 Elizabeth Figura, 2023년 Linux Plumbers Conference에서 발표 후 Linux 6.14에 병합

  • 성능 향상 수치

    • Dirt 3: 110.6 → 860.7 FPS (678% 향상)
    • Resident Evil 2: 26 → 77 FPS
    • Call of Juarez: 99.8 → 224.1 FPS
    • Tiny Tina’s Wonderlands: 130 → 360 FPS
    • Call of Duty: Black Ops I은 완전한 플레이 가능 상태

  • fsync 대비 차이점

    • fsync 사용자에게는 향상이 제한적이지만, 멀티스레드 병목이 있던 게임에서는 극적인 개선
    • 메인라인 커널 포함으로 별도 패치 불필요, Fedora 42·Ubuntu 25.04 등 최신 배포판에서 즉시 사용 가능
    • SteamOS 3.7.20 베타에 기본 탑재, Proton GE에서도 활성화
    • NTSYNC는 Wine 역사상 처음으로 커널 수준에서 정확한 동기화 구현을 달성한 사례

WoW64 완성 — 32비트 호환성의 통합

  • WoW64(Windows 32-bit on Windows 64-bit) 아키텍처 구현이 Wine 11에서 완성
    • 64비트 Linux 시스템에서 32비트 Windows 앱 실행 시 별도 32비트 라이브러리 설치 불필요
    • 단일 바이너리가 실행 파일의 비트 수를 자동 감지해 처리
  • OpenGL 메모리 매핑, SCSI 패스스루, 16비트 애플리케이션 지원까지 포함
    • 1990년대 구형 Windows 소프트웨어도 실행 가능
  • 과거에는 배포판별 multilib 설정 차이로 실행이 어려웠으나, 이제 Wine이 내부적으로 처리

Wayland 및 기타 주요 개선

  • Wayland 드라이버

    • 클립보드 양방향 복사, 드래그 앤 드롭 지원, 해상도 전환 시 컴포지터 스케일링으로 구형 게임 호환성 향상
    • X11에서 Wayland로 전환 시 Wine 호환성 문제 대부분 해소

  • 그래픽 및 미디어

    • X11에서 EGL이 OpenGL 기본 백엔드로 변경, GLX 대체
    • Vulkan 1.4 지원, Vulkan Video 기반 H.264 하드웨어 가속 디코딩 추가

  • 입출력 및 주변기기

    • Force feedback 개선으로 레이싱 휠·플라이트 스틱 대응 강화

    • Bluetooth BLE 서비스 및 페어링 지원**,** MIDI 사운드폰트 처리 개선

      • Zip64 압축, Unicode 17.0.0, TWAIN 2.0 스캐닝(64비트), IPv6 ping 기능 추가

  • 성능 및 플랫폼 확장

    • Linux·macOS에서 스레드 우선순위 관리 개선, 멀티스레드 성능 향상
    • ARM64에서 4K 페이지 크기 시뮬레이션 지원, ARM 기반 Linux 기기 호환성 확보

게임 호환성과 버그 수정

  • Nioh 2, StarCraft 2, The Witcher 2, Call of Duty: Black Ops II, Final Fantasy XI, Battle.net 등 주요 타이틀의 호환성 개선
  • 수백 건의 버그 수정이 포함되어 전반적인 안정성과 성능 향상

종합 평가

  • NTSYNC, WoW64 완성, Wayland 개선, 대규모 버그 수정이 결합된 Wine 11은 Proton 이후 가장 중요한 릴리스
  • Proton, Lutris, Bottles 등 Wine 기반 모든 프로젝트의 성능과 호환성이 향상
  • Linux에서 게임을 즐기는 사용자라면 Wine 11은 반드시 시도할 가치가 있는 버전
▲
GN⁺ 5시간전  [-]
Hacker News 의견들

  • 나는 Wine 프로젝트에 거의 무한한 존경심을 가지고 있음
    30년간 Windows의 문서화된/비문서화되지 않은 동작을 그대로 재현하려는 작업은 지루하고 보상도 적은 일처럼 들리지만, 그 덕분에 Wine이 실제로 쓸 만한 제품이 되었음
    특히 오래된 게임들이 Windows보다 더 잘 돌아가는 걸 보면, 세밀함과 고통에 대한 인내심이 대단하다고 느껴짐

    • 예전엔 Wine이 제대로 작동할 리 없다고 생각해서 Linux로 게임하는 걸 피했음
      가끔 간단한 게임을 돌려보고 “이게 되네?” 싶었지만, 신뢰할 수 있다고는 생각하지 않았음
      지금은 그 판단이 완전히 틀렸음을 인정함
    • 정말 훌륭한 프로젝트임에도 불구하고, Word나 Excel, Outlook 같은 비즈니스용 앱은 여전히 잘 안 돌아가는 게 아쉬움
      Excel 2010이 마지막으로 Platinum 등급을 받은 버전이라 함
      게임보다 이런 앱들이 더 어려운 이유가 흥미로움
    • Wine은 다양한 플랫폼에서 호환성 테스트를 자동으로 돌림
      테스트 결과 페이지를 보면, 이런 체계적인 검증이 높은 호환성을 만드는 핵심임
    • ReactOS도 언급할 가치가 있음
      그 프로젝트에서 얻은 지식이 Wine 개발에 많이 흘러들어감
    • 90년대에 OS/2를 쓸 때 Windows 앱을 돌리려면 Windows 전체를 띄워야 했음
      그때 Wine 같은 걸 직접 만들고 싶었지만 지식이 부족했음
      지금은 Linux를 서버용으로만 써서 쓸 일이 없고, Mac용 Wine도 있다고 들었지만 굳이 돌리고 싶은 Windows 앱이 없음

  • Proton 덕분에 게임 프레임이 엄청나게 오른 걸 보고 놀람
    Dirt 3가 110FPS에서 860FPS로, Resident Evil 2가 26FPS에서 77FPS로 올랐다는 건 믿기 어려움
    Valve가 여기에 돈을 쏟아부은 덕분이라 생각함

    • 다만 이 수치는 Wine+ntsync와 Wine 기본 버전을 비교한 결과라 과장된 면이 있음
      기존의 fsync 기반 Wine과 비교하면 향상폭은 몇 퍼센트 수준임
      그래도 ntsync는 분명한 개선임
      ntsync 문서를 보면, Windows의 동기화 구조를 Linux에서 더 정확히 구현하기 위한 커널 드라이버임
    • “esync나 fsync를 쓰지 않았을 때”의 비교라는 점도 주의해야 함
    • Proton과 Wine의 관계가 궁금함 — Proton은 Valve/SteamOS용 이름인지, 아니면 별도 프로젝트인지 알고 싶음

  • ntsync 성능 향상에 너무 들뜨지 말라는 의견도 있음
    대부분의 경우 성능 향상은 한 자릿수 퍼센트 수준이며, 일부 게임은 오히려 약간 느려질 수도 있음

    • fsync 패치가 없는 커널을 쓰는 사람이라면 얘기가 다를 수 있음
    • Wayland와 X11의 성능 차이도 비교해볼 만하다는 의견이 나옴

  • 이런 저수준 기술 얘기를 보면 내가 CRUD 앱만 만드는 게 부끄럽게 느껴짐

    • 하지만 CRUD도 가치가 있고, 정신 건강에 좋음
      예전에 천재 개발자가 극한 일정에 시달리다 결국 단순한 VB CRUD 업무로 옮겨 “유급 휴가 같다”고 했던 일화를 들은 적 있음
    • 나도 Outlook에서 “여기 클릭, 저기 클릭” 같은 단순한 도움을 주지만, 이런 일도 필수적인 일임
    • 반대로 저수준 개발자들도 고수준 시스템을 다룰 때는 자신이 부족하다고 느낀다고 함
    • 컴파일러를 만드는 나조차 개인 프로젝트용 CRUD 앱을 여러 번 시도하다 실패했음
      Rails, Phoenix, Django 다 해봤지만 쉽지 않았음
      최근엔 Claude의 도움으로 조금 진전이 있음
    • CRUD 앱도 만만치 않음
      기업 요구사항이 복잡해서 아키텍처가 쉽게 무너질 수 있음

  • Valve에 수천 달러를 쓴 게 결국 Wine 개선에 쓰였다니 기쁨임
    Valve가 얼마나 많은 개발자와 계약자를 고용했는지 궁금함

    • Wine 개발자의 3분의 2는 CodeWeavers 소속이며, Valve와 Proton 계약을 맺고 있음
      즉 대부분의 자금이 그쪽으로 흘러감

  • Wine이 역설적으로 자기 파괴적일 수도 있음
    Linux에서 게임이 잘 돌아가면 개발자들이 아예 Linux용 포트를 만들 테니 Wine이 필요 없어질 수도 있음

    • 하지만 Wine의 API가 Linux보다 더 안정적이라, 오히려 Wine이 1급 타깃이 될 수도 있음
    • 실제로는 반대라고 생각함
      네이티브 포트가 있어도 Windows 버전을 Proton으로 돌리는 게 더 안정적임
      Windows API는 익숙하고 변하지 않아서 개발자들이 계속 그쪽을 기준으로 개발함
    • 요즘 “Linux 지원”이란 결국 Proton에서 잘 돌아가게 하는 것을 의미함
    • 이런 상황은 “좋은 문제”라고 생각함
    • 게다가 Wine은 게임 외에도 다양한 용도로 쓰이므로, 네이티브 포트가 늘어나도 수요는 계속 있을 것임
      Windows ABI가 여전히 더 안정적이기 때문에, 성능 차이가 미미한 한 Windows 빌드만 유지하는 게 효율적임

  • 사용자 공간에서 공유 메모리로 ntsync를 구현할 수 있지 않냐는 질문이 있었음
    Claude는 “95%의 게임엔 단순한 접근법으로 충분했기 때문에 복잡한 공유 메모리 로직을 구현할 동기가 없었고, 정확성이 중요해진 시점엔 커널에 넣는 게 자연스러웠다”고 설명함

    • 하지만 실제로는 Linux가 그런 사용자 공간 기능을 제공하지 않기 때문에 불가능함
      ntsync는 단순한 API 래퍼가 아니라 NT 커널의 동기화 동작을 재현하는 커널 수준 어댑터임
      소스 코드를 보면 커널 스케줄러와 긴밀히 연동됨
    • 커널 문서에도 “사용자 공간 구현으로는 Windows 수준의 성능과 정확성을 맞출 수 없다”고 명시되어 있음
      문서 링크

  • Linux가 Windows를 재구현하면서 오히려 더 잘하는 걸 보는 게 놀라움
    Microsoft가 자사 소프트웨어를 점점 더 불편하게 만드는 와중에 이런 성취는 대단함

    • 특히 64비트 Windows에서 사라진 16비트 지원을 Wine이 유지하는 건 큰 의미가 있음
      오래된 게임 중엔 16비트 기반이 많고, 32비트 게임이라도 설치 프로그램이 16비트인 경우가 많음

  • Wine 개발자가 이 글을 본다면, Carolina Code Conference 2026에서 관련 발표를 해줬으면 함
    발표자 모집이 3월 31일까지 열려 있음

  • macOS에서도 같은 걸 원한다면 이 저장소에 기여하면 됨

    • 하지만 솔직히 MacOS용 게임은 너무 적어서 관심 있는 개발자도 거의 없을 듯함
      예전에 학교 Mac에서 Bolo 탱크 게임을 하던 추억은 있지만, Windows 게임 수의 1%도 안 될 것 같음
    • 그런데 성능상 이유로 커널에 넣어야 했다면, 왜 Linux는 사용자 공간에서 하지 않았는지 궁금함
답변달기