무슨 일이 있었나요?
OpenBSD의 포트(ports) 메일링 리스트에 Wine 포트가 올라왔어요. 포트가 뭐냐면, OpenBSD에서 외부 소프트웨어를 빌드하고 설치할 수 있도록 정리해 둔 '설치 레시피' 모음이에요. 우분투의 apt 패키지나 macOS의 Homebrew 포뮬러를 떠올리면 쉬워요. 여기에 Wine이 들어온다는 건, 앞으로 OpenBSD 사용자도 패키지 하나만 설치하면 윈도우 프로그램을 돌려볼 수 있게 된다는 뜻이에요.
리눅스나 macOS를 쓰는 분들은 'Wine 돌아가는 게 뭐 그리 대단해?' 싶을 수 있어요. 그런데 OpenBSD의 64비트(amd64) 환경에서 Wine은 오랫동안 사실상 쓸 수 없는 물건이었거든요. 왜 그랬는지 알고 나면 이번 소식이 훨씬 재밌게 읽혀요.
Wine은 에뮬레이터가 아니에요
Wine이라는 이름부터가 'Wine Is Not an Emulator'의 약자예요. 에뮬레이터는 CPU 명령어를 하나하나 흉내 내는데, Wine은 그러지 않아요. x86 윈도우 프로그램의 기계어는 진짜 CPU 위에서 그대로 실행되고, 프로그램이 파일 열기나 메모리 할당 같은 윈도우 API를 부르면 Wine이 그걸 받아서 유닉스 방식의 호출로 바꿔줘요. 일종의 '통역사' 역할이에요.
덕분에 속도 손해는 적은데, 대신 치러야 할 게 있어요. 윈도우 프로그램이 기대하는 메모리 배치와 실행 환경을 호스트 OS 위에서 최대한 똑같이 만들어줘야 하거든요. 바로 이 지점에서 OpenBSD와 정면으로 부딪혀요.
OpenBSD에서 유독 어려웠던 이유
OpenBSD는 '기본값이 안전해야 한다'는 철학으로 유명한 OS예요. 문제는 그 철학을 지키려고 넣은 장치들이 Wine이 하려는 일과 하나하나 충돌한다는 거예요.
- W^X(쓰기 XOR 실행): 메모리는 '쓸 수 있거나' '실행할 수 있거나' 둘 중 하나만 돼요. 공격자가 메모리에 코드를 써넣고 실행하는 걸 막으려는 장치예요. 그런데 오래된 윈도우 프로그램, 실행 중에 코드를 만들어내는 JIT 엔진, 복제 방지 코드는 쓰기와 실행이 동시에 되는 메모리를 아무렇지 않게 요청해요. OpenBSD에서는 wxallowed 옵션으로 마운트된 파일시스템(기본 설치라면 /usr/local)에 있으면서 따로 표시가 된 바이너리만 예외를 받을 수 있어요.
- 시스템 콜 출처 제한: 최근 OpenBSD는 시스템 콜이 libc 같은 정해진 코드 위치에서만 들어오도록 강하게 묶어두고 있어요. 그런데 일부 윈도우 프로그램(주로 안티치트나 DRM)은 시스템 콜 명령어를 직접 실행하기도 해요. 리눅스에는 이런 호출을 Wine이 가로챌 수 있게 해주는 커널 기능(Syscall User Dispatch)까지 들어가 있지만, OpenBSD에서는 그런 코드가 그냥 차단돼요.
- 스택 검사: 시스템 콜에 들어갈 때 스택 포인터가 '스택 용도로 할당된 메모리'를 가리키는지 확인해요. Wine은 윈도우 쪽 코드와 유닉스 쪽 코드를 오가면서 스택을 바꿔 타는 일이 많아서, 이 규칙에 맞추기가 까다로워요.
- 32비트 호환 계층 없음: 이게 가장 큰 벽이었어요. OpenBSD amd64는 32비트 바이너리를 아예 돌리지 못해요. 그런데 전통적인 Wine은 32비트 윈도우 앱을 실행하려면 32비트 유닉스 라이브러리가 꼭 있어야 했어요.
판을 바꾼 Wine의 새 WoW64 모드
마지막 벽을 허문 건 Wine 쪽의 변화예요. Wine은 몇 년에 걸쳐 내부 DLL을 윈도우 실행 파일 형식(PE)으로 옮기면서 '새 WoW64 모드'를 다듬어 왔어요. WoW64(Windows-on-Windows 64)는 원래 64비트 윈도우가 32비트 앱을 돌리는 방식인데, Wine이 이 구조를 그대로 따라 한 거예요. 32비트 윈도우 코드가 부르는 함수는 윈도우 형식 DLL 안에서 64비트 호출로 바뀌고, 유닉스 쪽에는 64비트 Wine 하나만 있으면 돼요. 그러니까 호스트에 32비트 라이브러리가 하나도 없어도 32비트 윈도우 앱을 돌릴 수 있게 된 거예요.
이 기능이 원래 중요했던 건 32비트를 버린 macOS, 그리고 32비트 라이브러리 묶음(multilib)을 줄이려는 리눅스 배포판 때문이었어요. 그런데 64비트만 있는 OpenBSD 같은 환경에서는 사실상 유일한 해법이기도 해요. 다만 어떤 앱이 얼마나 잘 돌아가는지, 성능이나 그래픽 지원은 어떤지는 포트가 다듬어지고 사용자 테스트가 쌓여야 드러날 부분이에요. 당장 '게임까지 다 된다'를 기대하긴 일러요.
다른 OS와 비교하면
FreeBSD는 오래전부터 Wine 패키지를 제공해 왔고, 32비트 호환 라이브러리도 있어서 상대적으로 수월했어요. NetBSD도 pkgsrc로 Wine을 제공하고요. 리눅스에서는 밸브의 Proton 덕분에 Wine이 최신 게임까지 돌리는 수준으로 성장했죠. 반면 OpenBSD는 '편의보다 보안'을 택한 대가로 이런 호환 레이어와 가장 거리가 먼 OS였어요. Wine의 구조 개편이 이렇게 까다로운 플랫폼까지 영향을 미쳤다는 점에서 이번 소식은 상징적인 사례예요.
한국 개발자에게 주는 시사점
OpenBSD를 데스크톱으로 쓰는 국내 개발자는 많지 않을 거예요. 그래도 배울 점은 분명해요.
첫째, 보안 기능은 공짜가 아니에요. W^X나 시스템 콜 제한 같은 보안은 호환성을 일부 내주고 얻는 거예요. 컨테이너에 seccomp 프로필을 걸거나 SELinux를 켰을 때 '멀쩡하던 라이브러리가 왜 갑자기 죽지?'를 겪는 것과 똑같은 구조죠. 이번 포팅은 그 비용을 어떻게 최소화하는지 보여주는 좋은 교재예요.
둘째, 호환 레이어 설계의 교과서 같은 사례예요. Wine이 32비트 의존성을 걷어낸 방식, 즉 '변환을 어느 경계에서 할 것인가'를 바꾼 결정은 레거시 시스템을 마이그레이션할 때도 그대로 참고할 만한 사고방식이에요.
마무리
한 줄 정리: Wine을 64비트 중심으로 다시 설계한 작업이 쌓이면서, 가장 까다로운 OS였던 OpenBSD에서도 윈도우 앱을 돌릴 길이 열리고 있어요.
여러분은 보안 설정을 강화했다가 호환성 문제로 고생해 본 적 있나요? 보안과 호환성이 부딪힐 때 어떤 기준으로 타협하시는지 궁금해요.
🔗 출처: Hacker News