최근 수정 시각 : 2024-10-06 12:42:39

와인(소프트웨어)

Wine에서 넘어옴

파일:나무위키+유도.png  
Wine은(는) 여기로 연결됩니다.
주류에 대한 내용은 와인 문서
번 문단을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
, 에 대한 내용은 문서
번 문단을
번 문단을
부분을
부분을
참고하십시오.
파일:external/3.bp.blogspot.com/th_wine_hq_logo.png 파일:wine_latest_version_configure.png
공식 로고 설정 스크린샷
1. 개요
1.1. 이름
2. 특징
2.1. 호환성2.2. WineHQ
2.2.1. WineHQ 등급
3. 버전별 역사4. 사용 팁
4.1. 한글입력
4.1.1. 2010년대 및 이전4.1.2. 2020년대
4.2. 글꼴 문제
4.2.1. 레지스트리 방식4.2.2. 덮어쓰기 방식4.2.3. 가짜 글꼴 덮어쓰기 방식4.2.4. 가독성 문제
4.3. WINEPREFIX
5. 파생 버전
5.1. PlayOnLinux5.2. Lutris5.3. Bottles
5.3.1. 설치 방법5.3.2. 사용 팁5.3.3. 리눅스 경로로의 접근 권한 관리
6. 여담
6.1. 험난한 개발 과정6.2. MS가 Wine에 기여한다?6.3. Linux에 주는 영향?

[clearfix]

1. 개요

공식 사이트

POSIX 호환 운영체제인 Linux BSD 등에서 Windows 프로그램를 실행할 수 있는 호환 레이어.[1] 오픈 소스이며, 코드 라이선스는 초창기에 MIT였다가 Cedega가 Wine을 이용하여 DirectX를 자체 구현하고 소스 코드를 비공개하자 LGPL로 변경했다.

1.1. 이름

Wine의 정식 이름은 'Wine Is Not an Emulator'이다.[2] 원래는 'WINdows Emulator'를 밀어주었으나, 에뮬레이터라는 이미지를 탈피하기 위한 목적으로 저렇게 이름을 바꾼 것이다. 애당초 에뮬레이터로 만든 것이 아니기 때문에, 게다가 법적 분쟁을 회피하기 위한 의도적인 이유로 노려서 저렇게 바꾼 것이다.[3]

그래서 Ubuntu 8.10부터는 지원 명칭이 'Wine Microsoft Windows Compatibility Layer'로 바뀌었다. Wine 측에서 투덜댄 모양. 변경된 명칭을 대충 직역해 보자면, 'Wine Microsoft Windows 호환성 계층(영역)'정도가 된다. 하여간 '에뮬레이터'란 단어는 절대로 안 쓴다.

2. 특징

일반적인 에뮬레이터는 ISA의 명령어 전체를 번역하지만, Wine은 Windows 프로그램 API/ABI를 운영체제가 처리할 수 있도록 번역한다.

부분적으로 에뮬레이트하기 때문에, x86 또는 x86_64 아키텍처에서 동작하는 Unix 기반 운영체제라면 구동이 가능하다. Windows 프로그램이 커널 모드가 아닌 사용자 모드에서 구동되므로, 하드웨어는 Wine이 아닌 운영체제가 담당한다.

자유 소프트웨어이므로 소스 코드가 공개되어 있으며, 이를 직접 수정해서 성능 향상에 기여할 수 있다.

2.1. 호환성

단체나 엔터프라이즈급 기업들의 지원과 더불어 호환성이 지속적으로 개선되고 있다. 최신 API나 오래된 DirectX를 사용하는 프로그램들의 지원이 좋지 못한 편이었으나 점차 해결되고 있다. 현재 Wine에서 작동하지 않는 프로그램도 주마다 별도로 업데이트되는 Wine Staging 버전이나 하단에 나오는 Wine의 용도별로 특화된 변형판 등에서는 작동할 수 있다.

Windows 10/11에서 돌아가지 않는 옛날 Windows 게임이나 어플이 Wine에서 실행 가능한 경우가 있다. 덕분에 클래식 게임 실행을 위한 플랫폼이 되기도 한다. MS-DOS 시절 게임들은 DOSBox로 돌린다지만 FMV가 주를 이루고 3D기술이 태동하던 1995년대 전후 게임들은 도리어 Wine으로 돌리는 것이 나은 경우가 종종 있다.[4]

다만 커널과 같은 Windows의 로우 레벨 단과 소통해야 하는 보안 프로그램, 안티 치트 등의 프로그램이 오류를 일으킬 수도 있다.

2.2. WineHQ

공식 홈페이지(영어)

말 그대로 Wine의 Headquarter(본부)라는 뜻. Wine 프로그램의 최신 및 베타 버전의 저장소가 이곳이다. 본래 각 Linux 배포판[5]의 패키지 저장소에는 해당 배포판에서 정상구동이 검증된 버전을 올리기에, WineHQ에서 직접 받는 것보다 구버전일 수밖에 없다. 그렇기에 최신 버전의 Wine을 깔고 싶다면 WineHQ의 저장소를 직접 추가하여 설치하는 것이다.

그러나 2020년대 들어 Bottles, Winetricks, PlayOnLinux, Lutris, Steam 등 별도의 관리툴을 두고, 실행 환경별로 샌드박스화하는 비중이 커지면서 신경 쓸 걱정을 덜게 됐다. 유틸리티 특화 변형판 (Soda, Caffe 등)이나 게임 특화 변형판 (Proton 등), Linux ARM ==> Windows (Hangover)처럼 용도별로 분화되어 발전하고 있기 때문이다. 순정 Wine 역시 9.0까지 버전업한 지금은 어지간히 구조가 복잡한 앱이 아닌 한은 웬만한 앱은 자체적으로 충분히 돌릴 수 있을 정도로 호환성과 성능이 발전해 있다.

WineHQ의 AppDB에서는 Wine을 처음 쓰는 유저를 위해 호환성 데이터베이스를 제공하는데, 각종 설명, 해당 프로그램 버전별 호환 현황 등이 등재되어 있으며 이를 등급으로 매기기도 한다. 등급 설명은 아래 참고.

2.2.1. WineHQ 등급

Platinum (플래티넘)
설정 조작 없이도 Windows 이상으로 아주 훌륭히 구동됨.
Gold (금)
설정 조작 후에 Windows 이상으로 훌륭히 구동됨.
Silver (은)
통상적인 사용에 지장은 없음. 그러나 조작이 없으면 문제 발생 우려.
Bronze (동)
구동은 되나, 통상적인 사용에 지장이 있음.
Garbage (쓰레기)
통상적인 사용이 전혀 불가능할 정도로 해결책이 아직 없는 치명적인 문제가 발생함. Linux에 완벽히 통달한 특별한 기술자가 아니라고 하면 많은 시간과 정신을 낭비할 수 있으므로 해당 등급의 프로그램 구동 포기를 요한다.

3. 버전별 역사

1993년 6월자 comp.os.linux의 유즈넷 관련 토론으로 시작되었다. Windows 3.1 시절부터 개발을 시작해서 뭐 1~2년 하는 것도 아니고 15년만에 베타 버전이 종식됐다.[6] 그래도 제작자들이 끈기있는 개발을 하여 2주에 한 번씩 베타 버전을 만드는 원칙은 잘 지켜졌다. 사실 2000년대까지의 지난한 개발 과정에는 다 이유가 있는데, 이에 대해서는 아래 여담 항목을 참조.

2008년 중반에 첫 공식 버전을 만들었다. 당시 제작자들에 따르면 약 3000개의 프로그램을 지원한다고 했으며, 월드 오브 워크래프트 문명 4, 스타크래프트, 스팀[7] 등 상당수의 유명 외산 게임은 안정적으로 지원한다. 굳이 게임이 아니더라도 한글 2010이라든지, 게임을 하지 않아도 윈도를 버리지 못하게 하는 프로그램들도 많이 지원한다.

4.0 이후 DirectX 12를 부분적으로 지원하고 있으며, 4.6 이후 Vulkan(API)을 백엔드로 사용하기 시작하면서 멀티스레드 렌더링이 가능해졌고 성능이 향상되고 있다. 기존에 설치가 불가능했던 .NET Framework 4.7도 설치가 가능해졌다.

2024년 1월 현재 최신 안정 (stable) 버전은 Wine 9.0이다. 9.0 릴리즈 노트

4. 사용 팁

4.1. 한글입력

4.1.1. 2010년대 및 이전

과거 (2010년대 및 이전)에는 시스템 내장입력기에서 한글 입력이 안되는 앱[8]에서 한글 입력을 하려면 새나루 입력기를 터미널로 설치해야 했었다.[9] 이건 IEs4Linux(OS X)도 마찬가지.

예시
Username:localhost$wine install.exe

단 날개셋 입력기는 터미널이 아닌 GUI로 설치할수 있지만 모듈 등록이 안된다. 단 모듈을 제외한 입력패드랑 편집기는 설치가 되며 새나루 입력기와 마찬가지로 dll, ime파일은 수동으로 등록해줘야 한다.

IBus 입력기를 사용할 시, 한글 입력이 제대로 안 된다. 이는 레지스트리를 건드려서 해결 가능하다.

4.1.2. 2020년대

Wine 개발에 가속도가 붙기 시작하고 IBus 한글 IME 완성도가 높아진 2020년대에 들어서는, Wine 구동 시 한글 입력에서 이슈가 생기는 일은 거의 없어졌다. 특히 후술할 Bottles나 Steam을 통해 관리할 경우 거의 어떤 프로그램이든 설치하면 한글 입력이 기본적으로 되는 수준까지 올라왔다.

파일:Screenshot from 2024-01-21 20-09-05.png
물론 게임 등 사용자 입력을 자체적으로 구현하는 경우처럼 예외는 있다. 가령 한컴오피스의 경우, 한컴 자체 입력기를 사용하면 한/영 전환이 제대로 안먹히므로 작업표시줄의 입력기 버튼을 눌러 위와 같이 '윈도우 입력기 사용'으로 체크해야 한다.

4.2. 글꼴 문제

Wine은 Windows 프로그램 실행을 위한 거의 최소한의 환경만 갖추어 놓으므로 굴림, 맑은 고딕과 같은 전통적으로 한글 Windows에서 사용되던 폰트들이 포함되어 있지 않다. 이 폰트들이 없는 건 리눅스 머신도 동일하므로 그 결과 한글이 전부 ㅁㅁ가 되는 ' 두부 현상'을 초래한다.

아래와 같은 3가지 방식 중 하나를 통해 해결할 수 있다.

4.2.1. 레지스트리 방식

Wine 내에 필요한 글꼴이 없으면 글자가 왕창 깨지는 경우가 발생한다. 이 경우는 Wine의 regedit에서 HKEY_CURRENT_USER\\Software\\Wine\\Fonts\\Replacements 키를 만든 다음 "Batang"="Nanumgothic", "Dotum"="Nanumgothic", "Gulim"="Nanumgothic","MS Gothic"="Nanumgothic" 정도만 추가해주면 된다. 신버전의 경우 NotoSans CJK KR도 괜찮다.

4.2.2. 덮어쓰기 방식

실제 Windows 설치의 C:\\Windows\\Fonts를 ~/.wine/drive_c/windows/Fonts에다가 덮어씌울 수 있다. 다만 굴림 폰트가 8px~18px 구간으로 들어갈 경우 비트맵으로 렌더링되는 Windows와는 달리 Wine에서는 무조건 벡터로 렌더링하기에 가독성 측면에서 문제가 있다.

4.2.3. 가짜 글꼴 덮어쓰기 방식

가짜 굴림
가짜 맑은 고딕

앞서 설명했듯 단순히 기존 폰트를 덮어쓰는 방식은 가독성 측면에서 문제가 있기에 아예 나눔 고딕 등 다른 폰트를 갖다가 굴림이나 맑은 고딕인 것처럼 속인 폰트로 덮어쓰는 방식이 제안되었다. 이를 통해 하드코딩해놓은 프로그램이라도 두부 현상과 가독성 문제를 동시에 간단히 해결할 수 있다.

4.2.4. 가독성 문제

위 레지스트리 방식과 Windows 폰트 덮어쓰기 방식으로 진행했을 경우 가독성 문제를 해결하는 방법이다.
  1. 폰트매니저(font-manager) 튜닝
    - 모니터 크기와 해상도로 DPI를 구해 폰트매니저 DPI를 조정
  2. wine 레지스트리에서 2번 폰트렌더링 타입 사용
  3. Windows 굴림글꼴 제거. 나눔고딕 사용
    - 기타 글꼴을 나눔고딕으로 레지스트리에서 폰트링크
  4. MS오피스 옵션에서 클리어타입 사용 해제

4.3. WINEPREFIX

WINEPREFIX는 Wine의 환경을 서로 분리시키는 환경변수이다. 실제 Windows도 그렇듯, 프로그램을 깔고 지우다 보면 그간 거쳐간 프로그램들이 남긴 수많은 찌꺼기들이 뒤얽혀서 한없이 느려지는 모습을 볼 수 있을 것이다. 또, 정상적인 프로그램들이 서로 충돌을 일으키며 동시 실행이 안 되거나 문제가 생겨버리는 경우도 존재한다.

그래서 Wine에는 Wine의 환경을 서로 분리해서 실행시킬 수 있는 환경변수가 있는데, 이것이 바로 WINEPREFIX이다. 이 환경변수의 기본값은 ~/.wine이며, 여러분의 Linux에 Wine이 설치되어 있다면 이 폴더에 들어가 보면 Wine과 관련된 몇몇 파일들이 존재하는 것을 알 수 있을 것이다.

만약, 제대로 돌아갈지 확신할 수 없는 프로그램을 설치하면서 기존의 프로그램에 영향을 미치고 싶지 않다면, 혹은 모든 프로그램이 각자의 깔끔한 환경 내에서 작동하도록 하고 싶다면 이 WINEPREFIX값을 변경시킴으로서 하나의 새로운 Wine 환경을 만들어 새롭게 설치할 수 있다. 예를 들자면, ~/다운로드/installer.exe에 설치파일이 있다면 다음과 같이 실행시키는 것이다.
WINEPREFIX=~/.wine_test wine ~/다운로드/installer.exe
이렇게 하면 기존의 ~/.wine과는 별개로 ~/.wine_test라는 폴더에 새로운 Wine 환경이 생성되며, installer.exe가 설치하는 프로그램은 ~/.wine_test/drive_c 내에 설치될 것이다.

이렇게 설치된 프로그램이 프로그램 메뉴에 등록될 때에는 자동으로 바로가기 내에 WINEPREFIX값이 설정되어 등록되므로 실행이 번거로워질까 걱정할 필요도 없고, 서로 다른 WINEPREFIX의 프로그램도 동시에 실행이 가능하므로 괜히 여러개 만들었다가 꼬이지 않을까 걱정할 필요도 없다. 이를테면, 스카이프[10]는 ~/.wine_skype내에 설치되어 있고 스타크래프트2는 ~/.wine_starcraft2에 설치되어 있다고 하더라도, 프로그램 메뉴 내에서 Skype와 스타크래프트 2를 각각 바로 실행시켜서 친구와 대화하면서 게임플레이를 하는 데 아무런 지장이 없다는 말이다.

이 WINEPREFIX로 환경을 분리하는 방식은 과거에 주로 사용하던 방식으로, Wine의 변형판이 다양해지기 시작한 2020년대부터는 아예 Bottles, Lutris, PlayOnLinux, Steam 등 별도 관리툴로 분리하는 방식이 주류가 되었다. 이 관리툴에 대해서는 아래 항목을 참조.

5. 파생 버전

Windows 소프트웨어를 타 플랫폼에 돌린다고 하는 점 때문에, 많은 프로그래머에게서 주목 받아 기여가 활발하게 진행되는 상황이다. 물론 그만큼 Wine 소스를 가져가 기반으로 만든 파생 버전이 꽤 있는 편.
  • CrossOver - CodeWeavers에서 만든 프로그램. macOS 전용, Linux 전용을 따로따로 만들었다. 원래는 스탠다드, 프로, 게임용으로 나뉘었지만 2023년 현재는 구분이 폐지되었고, 대신 12개월동안 유효한 일반 CrossOver와 구독제 소프트웨어에서는 드물게 평생 라이선스[11]를 지원하는 CrossOver Life로 구분되었다. 위의 세데가 사례와는 달리 이쪽은 오픈소스 원칙을 철저히 준수하여 소스를 공개하고 있다. 상용 소프트웨어인지라 연간 라이선스는 74달러, CrossOver Life는 494달러라는 꽤 비싼 가격에 팔리고 있다. 그래도 CodeWeavers는 Wine 측과 상당한 우호적인 관계로 유명한데[12], 소스만 기여한게 아니라 서버 호스팅 지원까지 해줄 정도이다. CodeWeavers의 지원 덕분에 Wine이 상당히 좋아져 CrossOver를 대신 사용해도 좋을 정도.
  • Proton - 밸브 코퍼레이션과 CodeWeavers가 협업하여 만든 호환 레이어. Steam Linux 버전에서 Windows 전용 게임을 실행하기 위한 프로젝트로, 2018년 8월 22일에 공개되었다. 현재는 최신 베타 클라이언트와 통합되어 작동한다. 원본 Wine에 비해 DirectX 관련 성능[13]이나 멀티스레드 처리 성능을 높이고 전체 화면 관련 호환성을 높이는 등 게임 실행과 관련된 부분의 개선에 집중한 것이 특징이다.
  • Cedega - Transgaming에서 만든 프로그램. 게임용으로 특화하여 게이머가 쉽게 제어에 접근할 수 있게 만든 프로그램이다. 의도는 꽤 좋긴 했으나, 문제는 Transgaming 측에서 Wine 소스를 잔뜩 가져다 써놓고, 이를 비공개하여 논란이 된 것이다. MIT 라이센스가 소스 코드를 의무적으로 공개하지 않는다는 점을 악용한 것인데, 결국 Wine 측에서 이 문제를 인식하여 라이선스를 LGPL로 바꾼것도 이 사건 때문이다. 결국, 2009년 7.3버전을 끝으로 2011년 2월 28일에 결국 지원이 전면 중단되고, 소스는 자연스럽게 전면 공개되었다. 링크 소스 가져가 놓고는 기여하지 않은 게 부메랑이 되어 돌아온 셈이다.[14] 이후, 나중에 'Findev'로 사명을 변경하고 Cider를 개발했다.
  • Wineskin / Winebottler - macOS 전용. 설치 과정이 간단해져 만들어진 것으로 유명하다. 그러나 macOS가 32비트 프로그램을 더 이상 지원하지 않으면서, Wine이 32비트에 최적화된 상황에서 최신 버전에서 그대로 사용할 수 없다. 그대로 사용하는 방법으로는 구 버전을 사용하는 것 말고는 없다.
  • Winulator( 공식 홈페이지) - Android 전용. 국내에서는 시저 3 스타크래프트를 폰에 돌리기 용도로 잘 알려져 있다. 그냥 Windows 프로그램을 그대로 돌리는 건 아니라, 실행 파일을 변환해서 SD 카드 최상위 루트에 투척해야 쓸 수 있는 거다. 2017년 이후로 개발이 방치되었고, 심지어 변환용 도구마저 소실되었으며, 실행을 보장한 게임은 언급된 이 두 게임 말고는 없다. 사실상 개발이 중단되어 사용 불가 상태. 플레이 스토어에서도 내려졌다.
  • Hangover - Android 전용. 위의 Winulator와는 달리 그나마 개발되는 버전. 기존 Wine Android 버전을 복불인 것 같지만, 그나마 그럴저럭 돌아가는 편. Linux ARM 버전에서도 돌아간다.
  • Exagear( 위키, 포럼) - Android 전용. 원래 프로그래머 엘텍(Eltech)이 만들던 것을 베트남계인 Akira Yuki를 포함한 여러 유튜버가 이어받아 업데이트하는 것이다. 다만 x86 에뮬레이터 위에서 돌아가다 보니 Direct3D 테스트 시는 30~40 fps정도 나온다. 실제 가속은 8 fps가 한계. 유튜버 Game Thích는 64비트 CPU에 Vulkan까지 지원하도록 수정했다. 나아가 전용 테마, Wine Internet Explorer 패치도 있다. 한글 표시 및 입력은 굴림, 바탕체를 c:\windows\fonts\에 복사하고 위 문단에 언급된 날개셋을 설치하면 된다. 구글링을 하면 한글 로캘판을 구할수도 있다. 최근 4PDA에서 VirGL을 이용한 3D가속을 적용하는데 성공했으며 오버레이 방식으로 작동한다. https://4pda.to/forum/index.php?showtopic=992239&st=7280 저번에 4PDA에서 누가 루팅없이 수정해서 이제 루팅 없이도 빠르게 게임을 플레이 할수 있으며 이젠 VirtIO-GPU까지 적용해 번거로운 작업을 거치지 않아도 된다.
  • ReactOS - Windows 클론 운영체제. 이쪽은 아예 NT 커널부터 클론해 버리는 프로젝트로 진도가 상당히 더디다. 그러다보니 처음에는 매우 불안정했으나 Wine의 일부 소스 코드를 수혈 받으면서 안정성이 상당히 개선된 상태다. 개발자들의 말에 따르면 많은 버그가 고쳐졌다고. 한때 베이퍼웨어가 될 뻔 하기도 했다고 한다. 2024년 말 기준으로 아직 쓸만한 수준이 되려면 한참 멀었지만 최근 개발 속도에 탄력이 붙는 걸 보면 아주 희망을 버릴 수준은 아닌듯.
  • 티맥스 윈도우 - 흑역사로 유명한 바로 그 운영체제이다. Wine 소스를 활용한 것으로 알려졌으나, 코드를 공개하지 않아 이리저리 헤매다가 결국 처참하게 버려졌고, 티맥스에서 이와 별도의 운영 체제를 TmaxOS로 새로 내놓았는데, 이것도 소스 코드 일부가 Wine인 것으로 알려졌다. 그러나 호환성은 Wine보다 매우 낮은데, 이는 대부분의 호환 코드를 티맥스에서 재작성했기 때문으로 보인다.[15]
  • Hangover( 저장소) - aarch64 리눅스에서 Win32 앱을 실행할 수 있게 한다.

5.1. PlayOnLinux

파일:asdgagf.jpg
파일:홈페이지 아이콘.svg
Wine의 GUI 관리툴. Wine과 PlayOnLinux는 파이썬 아나콘다의 관계와 유사하다. Linux 전용으로,[16] ESD같은 UI를 갖고 있으며, 다운로드/설치/환경변수 등록을 자동으로 수행한다. PlayOnLinux를 사용할 경우, 터미널에서 따로 Wine을 설치할 필요가 없다. 그 설치까지 알아서 해주기 때문.

각 프로그램에 맞는 최적의 Wine 버전과 최적의 설정값을 가져와서 해당 앱만을 위한 환경변수를 생성한 뒤 앱을 구동한다. 저작권 문제가 없는 앱일 경우 알아서 다운로드, 구성까지 수행하는 것이 PlayOnLinux의 특징이자 장점이다.[17] WinePrefix를 생성하고 관리하는게 귀찮다면 반드시 써볼 것. 환경값도 GUI로 편하게 편집할 수 있다.

다만 PlayOnLinux에서 제공하는 방법대로 설치한다고 100% 정상 작동한다는 보장은 없다. 일례로 2021년 7월 현재 카카오톡의 경우, PlayOnLinux 상에서 제공하는 방법대로 켜봐도 당장 설치화면부터 □□□의 향연이다. gulim.ttc나 malgun.ttf 등[18] 한글 폰트를 깔고 어찌어찌 설치하더라도, Linux의 언어셋이 ko_KR.UTF-8이 아닐 경우 한글 입력이 안된다.[19] 이후에도 GNOME 등 일부 환경에서는 트레이 아이콘이 별도의 윈도우로 튀어나오는 경우가 있다. [20] 이것도 해결하면 끝일까? 아니다. 파일 업로드/다운로드가 안된다. 정확히 말하면 수백KB 이상의 파일을 업/다운로드하는 경우 그냥 취소되어버리는 현상이 있다. 그리고 약 4줄이 넘어가는 장문의 톡을 작성하면 튕긴다. 이는 PlayOnLinux로는 해결이 안되고, 후술할 Bottles를 써야 한다.

또한 내장 Bash터미널을 지원하여, GUI로 실행하면 제대로 설치되지 않거나 실행이 불가능한 앱과 새나루 입력기 등을 설치하기가 편해졌다.

5.2. Lutris

Lutris 홈페이지
유사 소프트웨어로 Lutris가 있다. PlayOnLinux에서 실행이 제대로 되지 않는 것이 있다면 Lutris로 시도해 보자. 프로그램을 선택하고 밑의 Wine 아이콘 옆의 화살표를 클릭하면 Winetricks, Wine config 버튼으로 설정이 가능하다.

5.3. Bottles

파일:Bottles(소프트웨어) 정보 창 스크린샷.png
파일:홈페이지 아이콘.svg | 공식 문서
Wine의 prefix 관리 및 Wine 이외의 Proton, Soda, Caffe, Lutris, Proton-GE, Vainglia 등의 Windows 호환성 레이어 모듈을 선택 가능한 것이 특징으로 GUI를 개선하여 사용하기 편하게 만든 프로그램이다. PlayOnLinux의 유지보수가 점점 소홀해지는 사이 새롭게 부상하고 있는 관리툴이다. 특히 이쪽은 Windows 게임뿐만 아니라 DLL 계층이 복잡한 Windows 유틸의 실행까지 초점을 맞추어 발전하고 있다. PlayOnLinux에서 정상적으로 작동하지 않는 카카오톡의 PC버전이 동작한다.[21] ibus 한글 입력 또한 별도의 설정 없이 동작한다.

한글 폰트 깨짐 현상은 위 '글꼴 문제' 항목을 참고하여 해결할 수 있다. 한 가지 지양해야 할 것이 있다면, Bottles 디펜던시 설정란의 cjkfonts를 클릭하여 설치하면 "/home/<USER>/.var/app/com.usebottles.bottles/data/bottles/bottles/<BOTTLENAME>/drive_c/windows/Fonts" 디렉토리에 100MB 이상의 폰트 파일 한 개로 설치되기에 랙 현상이 있을 수 있다. 또한 Settings - Compatibility - Language 설정을 Korean 대신 System으로 지정하여야 한글/영문 전환키가 제대로 동작한다.

5.3.1. 설치 방법

  1. Flatpak 설치
    # 참조하여 설치. Bottles는 Flatpak으로 배포되므로 Flatpak부터 설치해야 한다.
  2. Flathub에서 Bottles 설치
    Flathub는 Flatpak 앱들을 모아놓은 스토어로, 여기에 들어가 Install 버튼을 누르면 com.usebottles.bottles.flatpakref 파일이 다운로드될 것이다. 해당 파일을 더블클릭하여 실행하면 Bottles 설치 화면이 나온다. 여기서 또 Install을 누르면 Bottles가 설치된다.
  3. Bottles 실행
    설치가 완료되면 바탕화면에서 Bottles를 실행할 수 있다.
  4. 새 Bottle 생성
    Bottles를 최초로 켠 뒤에 Bottle[22]을 새로 만든다.
  5. 원하는 Windows 프로그램 실행
    새로 만든 Bottle에 들어가서 Run executable를 누르고, 실행/설치하고자 하는 Windows 프로그램을 선택한다.

5.3.2. 사용 팁

Bottles에서 Windows 프로그램을 설치한 후 .desktop 파일을 생성하는 기능을 사용하기 위해서는 Flatpak에 관련 권한을 부여해야 한다. 그후 설치된 각 프로그램에 대한 데스크톱-엔트리 파일 추가 기능을 사용할 수 있다. 그리고 Options - Settings - Advanced Display Settings 메뉴에서 Window-Manager-Decorations의 체크를 해제하면 부가적인 타이틀바가 나타나지 않게 만들 수 있다.

특정 파일에 대한 프로그램 어소시에이션은 Bottles에서 데스크톱-엔트리 파일 추가 후 ~/.local/share/application 폴더의 .desktop 파일 내용을 수정하면 된다. # flatpak run \-\-command=bottles-cli com.usebottles.bottles run 명령어에 -b 옵션으로 생성한 Bottles 이름을 지정하고 -e 옵션에 파일 경로 및 exe 파일을 지정한 후, \-\-args "%F" 또는 \-\-args "z:%F" 와 같이 반드시 --args와 큰 따옴표로 지정하여야 한다. Bottles 선택 및 파라미터 지정 예시

여러 파일을 동일 프로그램에서 동시에 실행할 때 발생하는 "Bottles is not responding" 에러는 bottles-cli의 tools와 cmd 명령어로 터미널 창에 Windows cmd.exe 환경을 미리 실행해 놓으면 해결할 수 있다.

최신 runner를 직접 다운로드 하여 /home/<USER>/.var/app/com.usebottles.bottles/data/bottles/runners 디렉토리에 설치할 수도 있다.

5.3.3. 리눅스 경로로의 접근 권한 관리

Bottles의 윈도 앱에서 리눅스 머신의 경로에 접근하려면 별도의 조치를 취해줘야 한다. 앞서 언급했듯 Bottles의 배포 형태인 Flatpak은 기본적으로 샌드박스 환경으로 앱을 구동키기 때문.

가령, 아래와 같은 커맨드를 리눅스 셸에서 실행 후 Bottles를 재시작하면 /home/testuser/wine_shared_dir로의 접근 권한을 Bottles에 부여한다.
#!syntax sh
sudo flatpak override com.usebottles.bottles --filesystem=/home/testuser/wine_shared_dir

재시작 후, 윈도 앱에서는 Z:\home\testuser\wine_shared_dir 경로를 통해 접근할 수 있게 되며[23], 이러한 커맨드가 생소할 경우 Flatseal #이라는 샌드박스 관리 프로그램을 통해 설정하는 것도 가능하다. 다만 실제 윈도 환경과는 달리 안티바이러스가 없다는 점을 고려하여 무분별한 권한 부여는 지양해야 한다.

6. 여담

6.1. 험난한 개발 과정

엔터프라이즈 및 각종 커뮤니티의 참여가 활발해진 것은 2010년대 후반의 일로, 이전까지의 개발 과정은 무척이나 험난했다.

우선 Wine의 일차적인 목표는 다음과 같다. 윈도 프로그램을 돌리기 위해서 윈도에서 제공하는 API/ABI를 똑같이 제공하는 것.

이 목표를 달성하기 위하는 가장 쉬운 방법은 윈도의 바이너리 코드를 리버스 엔지니어링으로 필요한 코드를 얻은 다음 필요에 맞게 변형하는 것이다. 또 Windows 2000 Windows NT 4.0은 이미 2004년에, Windows XP Windows Server 2003은 2020년에 소스코드의 일부가 유출됐다.[24]

하지만 이런 것들을 가져다 쓰면 안 되는데, 동일한 코드가 들어가면 저작권 분쟁이 생기는 것이다.[25] 그래서 Wine 측에서는 윈도 API에 대해서 API 문서나 MS의 지원 페이지는 열심히 참고할 수 있고, 코드에 대해서 여러 가지 실험을 해 볼 수도 있지만, 코드를 까서 보는 것은 안되며, 지원 페이지 중에서도 API가 구현된 방식에 대해서 설명된 것은 보지 못하도록 규칙을 정하고 있다.

정확하게는 Wine을 직접 개발하는 프로그래머들이 절대로 윈도의 구성 요소를 역어셈블하지 않고 유출된 소스코드도 보지 않은 채 스스로 온갖 삽질을 하면서 독자적인 Wine 소스코드를 작성하면, 그 코드를 다른 프로그래머들이 혹시 Windows의 역어셈블한 코드나 유출된 코드와 비슷하지 않은지 검토해서 비슷하지 않으면 차기 버전으로 공개하는 식으로 프로젝트를 진행한다고 한다. 곧 Wine의 개발자들은 Wine 위에서 윈도용 소프트웨어가 작동하는 것은 Windows 위에서 실행하는 것과 동일하도록 만들어야 하지만 Wine 자체의 구조를 윈도 내부와 다르게 만들어야 한다는, 어찌 보면 서로 지향점이 반대인 두 가지 목표항상 한꺼번에 달성해야 하기에 이걸로 돈을 버는 것도 아니면서 굉장히 어려운 작업을 하고 있는 셈이다. 감사해야 한다.

그렇다면, 어차피 API는 프로그램 제작자를 위해 깔끔하게 정리돼 있으니까, '각 파일에 대해서 마이크로소프트가 제공하는 공식 API 문서에 규격화된 대로 구현만 하면 될까?'라고 생각할 수 있으나, 그것도 여의치 않다.
  • Windows에서 제공하는 API를 그대로, 정말 있는 그대로, MS에서 잘못 만든 버그마저 똑같이 구현해야 Windows 프로그램을 돌릴 수 있다. 프로그램 개발자 입장에서 이런 버그 때문에 덧댄 부분이 의도치 않게 동작할 수도 있고, 생각없이 버그가 정상적인 결과인 줄 알고 버그를 활용했을 수도 있고, 다른 버그를 가리기 위하는 별수 없는 수단으로 이 버그를 활용했을 수도 있다.
  • 또 앱 개발자들이 기본적인 윈도 API만을 써서 만드는 것도 아니라, 하드웨어를 직접 조작하는 요령을 부린 프로그램들도 있다. 이러면 호환성은 떨어져도 성능 면에서 이득이기 때문이다. Wine에서는 성능이 더 떨어질 수 있다.
  • Windows도 매년 새로운 API와 기능이 추가된다.

6.2. MS가 Wine에 기여한다?

어떤 한 기사에서 마이크로소프트가 오픈소스 기여에 참여한 것을 명분으로 Windows 소스 코드를 자발적으로 Wine에 제공했다는 내용이 보도되었지만, 실제로는 관계 없는 이야기에 기자 자신의 뇌피셜을 섞어 쓴 것에 불과한 것으로 나중에 밝혀졌다. 사실 MS의 변호인 브리핑 내용은 API 저작권에 대한 마이크로소프트의 입장일 뿐, MS가 Wine 프로젝트에 기여했다는 내용이 아니다.

6.3. Linux에 주는 영향?

OS/2의 사례를 들면서 Windows와의 호환성이 오히려 독이 될 수도 있다는 반대 의견도 만만치 않다. 굳이 호환성이 뛰어나다면 Linux용 앱을 만들 필요가 없게 되고, 그래서 Linux 생태계가 말라죽을 수 있다는 것. Windows와 Linux가 특징이나 주 사용층이 워낙 다르기에 상황이 그렇게만 돌아가지는 않겠지만 두고봐야 알 수 있는 문제. Linux를 쓰는 이유가 단순히 Linux용 어플리케이션을 사용하는 것은 아니기에 꼭 독이 된다고 볼수는 없다고 생각될수도 있다.

이에 대해 Wine 측은 홈페이지를 통해 "Wine을 통해 윈도우에서 리눅스로 플랫폼을 이동하려는 사용자들의 진입 장벽을 낮추고, 이를 통해 리눅스의 점유율을 높여 앱 개발자들이 네이티브 앱을 개발하도록 유도할 수 있다"고 답하고 있다.

Microsoft Office Adobe Photoshop 같은 케이스는 앱 생태계 문제에서 대표적인 예로 지적된다. Wine의 최중요 지원 소프트웨어 중 하나이기 때문에 정말 빠르고 매끄럽고 위화감 없이 작동하는걸 볼 수 있다. 지금이야 LibreOffice나 Gimp 등으로는 살짝 부족한 오피스 생태계를 메꿔서 Linux를 사무실에서 쓸 수 있게 해주는 일등공신이라고 할 수 있지만, Wine의 이런 행보가 계속되면 데스크톱 Linux의 점유율이 의미 있는 수준까지 올라간다고 해도 MS와 Adobe의 Linux용 정식 앱 출시는 느긋해질 수 밖에 없다.

가장 큰 문제는 앱 개발자 및 개발사들이 Wine을 통한 구동을 책임지지 않는다는 것이다. 앱 개발자 및 개발사들이 공식적으로 정상 구동을 보장하지 않는 루트이다보니 이로 인해서 나타나는 문제점이 만만치 않다. 개발자들은 어디까지나 Windows 환경을 위해 개발하지, Wine을 염두에 두고 개발하지 않는다. 또한 Wine을 통한 구동을 보장하지도 않고 Wine으로 구동하는 과정에서 나타나는 문제에 대한 어떠한 책임도 지지 않는다. 개발자 입장에서는 '우리는 Wine을 지원한다고 한 적 없다'고 하면 그만이다.

이러다보니 해당 앱이 버전 업데이트를 하거나 하면 계속 잘 구동될 거라는 보장도 없고, 개발자로부터 어떠한 사후지원도 받지 못하며, 이로 인해 사용자들은 무수한 삽질을 해야 하거나, 구버전을 계속 사용해야 하거나 하는 상황에 빠지게 된다. Wine을 통해 앱을 구동할때에 나타나는 무수한 문제들과 버그들은 대부분 여기서 기인한다. 그리고 구동을 위한 무수한 삽질은 오로지 사용자 몫이다.


[1] macOS는 Catalina 이후 Windows 지원에 필수적인 x86 ABI 지원이 빠져서 지원이 철폐되었다. [2] 직역하면 'Wine은 에뮬레이터가 아닙니다'. [3] 이런 식으로 약자의 원래 표현 안에 약자 자체가 다시 들어간 것(예를 들면 이 'Wine'의 정의에 다시 \'Wine Is Not an Emulator'로 돼 있어서 'Wine'이 들어가 있음)을 ' 재귀약자'로 부르는데, 사실 저렇게 법적 분쟁을 피하기 위하는 수사학적 말장난 밖에도, 이런 회귀적 네이밍 센스는 오픈소스 진영에서 흔히 써먹는 패턴으로 봐도 무방하다. ' GNU'의 'GNU is Not a Unix'가 그 대표적인 예. [4] 아예 WINE을 이용한 상용 NTVDM도 나왔다. [5] Debian, Pedora, Ubuntu, Zorin OS [6] 좀 더 정확히 말하자면, 12년동안 알파(…)가 나왔고 3년동안 베타가 나왔다. 최초의 정식 버전(Wine 1.0)은 개발 시작 15주년 기념으로 2008년에 릴리즈되었다. [7] 당시 안되는 게임이 적잖았으나 그래도 밸브 게임은 웬만하면 구동이 됐으며 Steam에서 직접 지원하는 변형판인 Proton은 2024년 현재 상당수 타이틀들을 큰 무리 없이 돌려주고 있다. [8] 예를들면 IE라던지... [9] PlayOn시리즈는 내장 Bash 터미널 [10] 2016년 4월 기준 설치가 가능은 하지만 번거로운 설정을 거쳐야 하고 약간 불안정하다. AppDB silver등급. 하지만 이제 Skype는 Linux를 정식으로 지원한다 [11] 리테일 소프트웨어와는 달리 버전업을 해도 비용을 낼 필요가 없다. [12] Wine 프로젝트의 총책임자인 알렉산더 줄리어드가 CodeWeavers의 CTO이다. 사실상 한몸인 셈. [13] VKD3D와 DXVK를 이용하여 DirectX API를 Vulkan API로 변환하여 작동한다. [14] 다만 이것은 지나치게 편향된 주장인데, 애초에 MIT 라이선스 자체가 코드를 비상업적이든 상업적으로든 어떻게 써도 상관없고 저작자 표기만 요구하는 라이선스이고 추가한 코드를 프로젝트에 기여해야 한다는 조항도, 그래야 한다는 암묵적 룰이 있는 것도 아니다. 애초에 라이선스를 MIT 라이선스로 해놓고 암묵적으로는 소스 공개 및 기여를 바라던 WINE 팀도 분명 책임이 있다. 가령 예를 들어서 FreeBSD 를 가져다가 쓰지만 기여나 소스 공개는 하지 않는 많은 기업들이 있으나 아무도 그런 기업들을 비판하지 않는 것과 같다. 소스 공개나 기여를 바란다면 애초부터 MIT 라이선스나 BSD 라이선스 등을 쓰면 안 되는 것이다. Transgaming의 행동이 오픈소스 정신에 위배하는 것이긴 하나 무작정 악의 축으로 몰고가는 것에는 문제가 있다. [15] 사실 개발 과정에서는 자체 호환성 레이어 없이 Wine만으로 Windows 프로그램을 지원했다. 하지만 그럼에도 오픈소스를 사용하지 않았다고 거짓말했다가 부랴부랴 자체 개발한 Windows 호환성 레이어로 대체한 것이다. 그런데 이 레이어는 카카오톡을 제외하고는 다른 프로그램은 설치가 불가능하거나 설치가 되더라도 실행 자체가 불가능할 수 있다(...). [16] macOS 전용으로 PlayOnMac이 있다. [17] 물론 용량이 매우 크거나 상용 소프트웨어의 경우엔 얄짤없다. MS 오피스벌써 목록에 올라와 있지만 당연히 환경만 구성해주고 설치는 알아서 해야 한다. 그래도 친절하게 설치방법도 안내해주니 그냥 구글 검색창과 쌩 터미널에서 머리 싸매는 것보다는 편하다. [18] 후술한 '글꼴 문제'에 나온 솔루션대로 해도 된다. [19] ibus 기준. 다른 입력기도 테스트 바람. 환경변수를 설정하려면 PlayOnLinux를 열고 카카오톡 선택 후 Configure > Miscellaneous > Command to exec before running the program 항목에 LANG="ko_KR.UTF-8" 입력하면 된다. 참고로 환경변수를 잘 설정하더라도 '홍길동'이 '홍기길길도동동'으로 써지는 식의 이슈가 발생할 수 있다. 입력기를 따로 설정하던가 위에 언급한 새나루, 날개셋 입력기를 별도로 설치하는게 좋다. [20] 이때 GNOME라면 sudo apt install gnome-shell-extension-top-icons-plus 실행 후 재로그인하면 된다. [21] 카카오톡 3.3.9.3090, 우분투 22.04 LTS 및 Wayland, Wine Caffe 7.7 기준. Wine 원본에서 발생하던 문제점이 Caffe에서는 발생하지 않는다. [22] 각 Wine 환경의 독립된 컨테이너. 눈치챘겠지만 Wine을 담는 병이라는 비유적 표현이다. [23] 드래그&드롭 시 '파일을 찾을 수 없습니다' 같은 오류가 대부분 이것으로 해결된다. [24] 마이크로소프트는 2001년 5월부터 OEM 파트너, 일부 국가의 정부, 일부 개발자들을 대상으로 자사 제품의 소스 코드를 공유할 수 있게 만든 'Shared Source Initiative'라는 프로그램을 운영한다. 따라서 MS 개발자가 아닌 사람들 중에도 MS 제품의 소스코드를 입수할 수 있는 사람들이 이미 꽤 많은 상태이다. 그래서 이들 중에 일부가 소스코드를 맘대로 또는 실수로 유출시키는 일들이 벌어진 것이다. [25] 실제로 ReactOS 쪽에서 개발 중에 MS의 바이너리와 동일한 어셈블리 코드가 들어간 게 발견된 바람에 털린 적이 있다. Windows는 엄연히 돈 받고 파는 상품이다.