나는 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일까지 열려 있음
Hacker News 의견들
나는 Wine 프로젝트에 거의 무한한 존경심을 가지고 있음
30년간 Windows의 문서화된/비문서화되지 않은 동작을 그대로 재현하려는 작업은 지루하고 보상도 적은 일처럼 들리지만, 그 덕분에 Wine이 실제로 쓸 만한 제품이 되었음
특히 오래된 게임들이 Windows보다 더 잘 돌아가는 걸 보면, 세밀함과 고통에 대한 인내심이 대단하다고 느껴짐
가끔 간단한 게임을 돌려보고 “이게 되네?” 싶었지만, 신뢰할 수 있다고는 생각하지 않았음
지금은 그 판단이 완전히 틀렸음을 인정함
Excel 2010이 마지막으로 Platinum 등급을 받은 버전이라 함
게임보다 이런 앱들이 더 어려운 이유가 흥미로움
테스트 결과 페이지를 보면, 이런 체계적인 검증이 높은 호환성을 만드는 핵심임
그 프로젝트에서 얻은 지식이 Wine 개발에 많이 흘러들어감
그때 Wine 같은 걸 직접 만들고 싶었지만 지식이 부족했음
지금은 Linux를 서버용으로만 써서 쓸 일이 없고, Mac용 Wine도 있다고 들었지만 굳이 돌리고 싶은 Windows 앱이 없음
Proton 덕분에 게임 프레임이 엄청나게 오른 걸 보고 놀람
Dirt 3가 110FPS에서 860FPS로, Resident Evil 2가 26FPS에서 77FPS로 올랐다는 건 믿기 어려움
Valve가 여기에 돈을 쏟아부은 덕분이라 생각함
기존의 fsync 기반 Wine과 비교하면 향상폭은 몇 퍼센트 수준임
그래도 ntsync는 분명한 개선임
ntsync 문서를 보면, Windows의 동기화 구조를 Linux에서 더 정확히 구현하기 위한 커널 드라이버임
ntsync 성능 향상에 너무 들뜨지 말라는 의견도 있음
대부분의 경우 성능 향상은 한 자릿수 퍼센트 수준이며, 일부 게임은 오히려 약간 느려질 수도 있음
이런 저수준 기술 얘기를 보면 내가 CRUD 앱만 만드는 게 부끄럽게 느껴짐
예전에 천재 개발자가 극한 일정에 시달리다 결국 단순한 VB CRUD 업무로 옮겨 “유급 휴가 같다”고 했던 일화를 들은 적 있음
Rails, Phoenix, Django 다 해봤지만 쉽지 않았음
최근엔 Claude의 도움으로 조금 진전이 있음
기업 요구사항이 복잡해서 아키텍처가 쉽게 무너질 수 있음
Valve에 수천 달러를 쓴 게 결국 Wine 개선에 쓰였다니 기쁨임
Valve가 얼마나 많은 개발자와 계약자를 고용했는지 궁금함
즉 대부분의 자금이 그쪽으로 흘러감
Wine이 역설적으로 자기 파괴적일 수도 있음
Linux에서 게임이 잘 돌아가면 개발자들이 아예 Linux용 포트를 만들 테니 Wine이 필요 없어질 수도 있음
네이티브 포트가 있어도 Windows 버전을 Proton으로 돌리는 게 더 안정적임
Windows API는 익숙하고 변하지 않아서 개발자들이 계속 그쪽을 기준으로 개발함
Windows ABI가 여전히 더 안정적이기 때문에, 성능 차이가 미미한 한 Windows 빌드만 유지하는 게 효율적임
사용자 공간에서 공유 메모리로 ntsync를 구현할 수 있지 않냐는 질문이 있었음
Claude는 “95%의 게임엔 단순한 접근법으로 충분했기 때문에 복잡한 공유 메모리 로직을 구현할 동기가 없었고, 정확성이 중요해진 시점엔 커널에 넣는 게 자연스러웠다”고 설명함
ntsync는 단순한 API 래퍼가 아니라 NT 커널의 동기화 동작을 재현하는 커널 수준 어댑터임
소스 코드를 보면 커널 스케줄러와 긴밀히 연동됨
문서 링크
Linux가 Windows를 재구현하면서 오히려 더 잘하는 걸 보는 게 놀라움
Microsoft가 자사 소프트웨어를 점점 더 불편하게 만드는 와중에 이런 성취는 대단함
오래된 게임 중엔 16비트 기반이 많고, 32비트 게임이라도 설치 프로그램이 16비트인 경우가 많음
Wine 개발자가 이 글을 본다면, Carolina Code Conference 2026에서 관련 발표를 해줬으면 함
발표자 모집이 3월 31일까지 열려 있음
macOS에서도 같은 걸 원한다면 이 저장소에 기여하면 됨
예전에 학교 Mac에서 Bolo 탱크 게임을 하던 추억은 있지만, Windows 게임 수의 1%도 안 될 것 같음