리눅스 데스크톱으로의 여정에서 느껴지는 딜레마 몇가지 by 파란오이


최근 음... 몇 가지 이유로 노트북 한 대만 남기고는 모두 최신 리눅스 배포판으로 옮겨가고자 하는 시도를 해 본 적이 있습니다. 지난 블로그 포스팅을 보니 대략 한 달이 조금 넘었군요. 이런 시도를 해 봤던 마지막 시기가 근 10여년 전이니, 시대가 많이 바뀌긴 했습니다. 그리고 예전에 예상했던 문제들은 거의 다 해결된 모습이지만, 미처 예상치 못했던 문제 몇 가지가 발목을 잡아 딜레마를 만들고 있었습니다.

1. 이제 음... 메이저급 리눅스 배포판에서 대부분의 작업은 무리없이 잘 될 겁니다. 이건 오픈소스 생태계가 발전된 것도 있고, 구글과 크로미엄을 필두로 웹 생태계가 크게 확장된 것도 있습니다. 심지어 예전에는 참 삐걱대던 Wine 조차 이제는 오피스나 카카오톡 같은 앱들을 큰 무리 없이 돌려 줄 정도니까요. 오히려 저는 지금까지 쓰던 윈도우 위주의 프로그램 구성들을, 리눅스 기반의 멀티플랫폼 오픈소스 플랫폼 위주로 바꿀 수도 있었을 정도입니다. 예전에 마지막 미련으로 남던 인터넷 익스플로러도 이제 없고, 시대의 대세는 멀티플랫폼 크로미엄이 되었죠.

​하드웨어 지원에서도 음... 오픈소스 순혈주의를 고집하는 페도라나 까다로운 정책의 CentOS 같은 게 아니라면, 우분투 계열 정도에서는 윈도우 정도는 아니더라도 대부분의 하드웨어 지원에서 큰 아쉬움은 없을 겁니다. 사실 제 경우에는 비 오픈소스 계열 드라이버 설치가 필요한 하드웨어가 딱 하나 있었는데, 그게 비디오카드였네요. 엔비디아의 드라이버는 여전히 독점 드라이버 중심으로 배포되고 있는데, 윈도우와 비슷한 모델이라 성능 같은 면에서는 확실하지만, 의외로 지원에 그레이존 같은 부분들이 있습니다.


2. 리눅스를 메인 데스크톱으로 쓰는 데 있어 의외의 함정카드는 이 웹 지원에서 나왔습니다. 리눅스 환경에서 보통 주력은 크로미엄이나 파이어폭스일 텐데, 의외로 이런 웹브라우저들에서 하드웨어 디코딩, 인코딩 가속 같은 GPU 가속 기능들이 제대로 적용되지 않습니다. 구글 크롬은 리눅스에서 공식적으로 GPU 하드웨어 가속을 제대로 지원하지 않는데, VAAPI 지원이 들어가 있긴 해서 실험용 flags 설정으로 활성화는 되지만 정말 실험적입니다. 그리고 파이어폭스도 비교적 최신 빌드에서는 VAAPI 지원이 들어가 있긴 한데, 기본적으로는 비활성화 상태입니다.

​리눅스에서 웹 스트리밍 영상의 하드웨어 가속을 사용함에 있어, 크로미엄이나 파이어폭스가 지원하는 기본 API는 VAAPI이고, 이걸 제일 잘 지원하는 GPU는 인텔 계열이며, AMD도 지원하긴 합니다. 문제는 엔비디아의 독점 드라이버는 이거 말고 VDPAU를 기본 지원하며 VAAPI 지원 의욕이 없다는 것이군요. 그 유명한 리누스 토발즈의 짤이 납득이 되는 느낌입니다. 그래서 예전부터 이 VDPAU를 VAAPI로 전환하는 라이브러리가 있긴 했는데... 이게 또 제약이 많습니다. 버전을 제법 타고, 비교적 최신 GPU의 VP9 지원도 복잡하고, AV1 지원은 아직 초기입니다. 그냥 스위치 켜면 되는 윈도우와는 상황이 다르죠. 제 경우에는 이렇게 복잡한 퍼즐을 맞췄지만 디코더만 활성화되고, 브라우저에서 인코더 활성화는 실패했습니다. GPU 메모리 버퍼 하드웨어 지원 유형에서도 리눅스에서는 올 소프트웨어만 뜨는 건 덤이군요.

​한편, 지금 데스크톱에 사용하는 GPU가 이미 나온 지 10년을 앞둔(?) 케플러 세대의 GTX 760이라는 것도 이 딜레마를 크게 만듭니다. 일단 윈도우와 리눅스 모두 마지막 드라이버 지원은 470 버전대 드라이버고, 영상 처리를 위한 하드웨어 디코더와 인코더 모두 H.264 수준까지만 지원합니다. 현재 시스템 사양에서 유튜브 720p/1080p 정도는 H.264는 하드웨어로 돌리나 소프트웨어로 돌리나 별 문제가 없고, VP9이나 AV1은 애초에 가속이 안되는 것이죠. 요즘 유튜브가 대부분의 스트리밍을 VP9이나 AV1으로 푸시하고 있는 상황에서, h264ify 같은 것으로 형식을 고정하지 않는 상황이면, 힘들여 영상 가속 설정을 하느니 GPU 활용을 포기하는 게 더 현실적일 수도 있겠습니다.

3. 원격 제어 측면에서는 양 쪽이 동급이라 칠 수도 있을 법 했는데...이 쪽은 아무래도 Cockpit의 편의성이 압도적인 리눅스 쪽의 손을 들어줘야 할 것 같습니다. 웹 기반에서 호스트의 커맨드라인 제어, VM과 컨테이너의 VNC 제어 등이 모두 가능하거든요. 아쉬운 부분이 호스트의 GUI 제어인데, 이건 그냥 전통적인 VNC나 스크린 공유 기능 같은 것을 쓰면 됩니다. 그래도 원격 데스크톱의 설정과 활용의 안정성 쪽은 아무래도 익숙한 윈도우가 나은 것 같기도 하고 그렇습니다. 

​가상머신 플랫폼 쪽은 음... 뭐 대동소이한데, 개인적으로는 VM을 리눅스를 올린다면 KVM 쪽이 더 낫다고 봅니다. Cockpit과 연계되면 훨씬 편하게 쓸 수 있거든요. 뭐 요즘 배포판이라면 윈도우에서 VMware Player 같은 걸로 올려도, VM 쪽으로의 원격 제어는 그리 큰 일이 아닐 수도 있겠습니다. 기능에 스위치 하나 켜 주는 정도로 원격 데스크톱 연결을 사용할 수 있으니까요. 물론 가상머신 플랫폼 쪽의 치트키라면 VMware ESXi나 Proxmox VE 같은 것들이 있겠는데, 우분투와 Cockpit 조합도 이에 크게 아쉽지 않은 모습을 보여 줍니다. 

4. 아무래도 서버로의 용도로 쓰면 리눅스 쪽이 접근이 더 까다롭긴 하지만 쓸 수 있는 카드가 많고, 라이선스 등에서 운신의 폭이 넓은 게 장점 같습니다. 하지만 원격이 아니라 로컬에서 PC처럼 직접 사용한다면야 약간씩 아쉬운 점들이 보이는 덕분에, 아무래도 제 경우에는 윈도우가 더 나아 보입니다. 물론 제가 비교적 최신 세대의 인텔 내장 그래픽을 사용하고 있었다면 아쉬운 부분이 더 적었겠지만... 지금 데스크톱은 내장 그래픽 없는 구형 HEDT라 어쩔 수 없네요.

​그래서 이제 이 데스크톱은 윈도우 11로 올라가지 못하는 상황에서 윈도우 10의 지원 기간을 끝까지 채우면서 GPU 하드웨어 지원을 살려 가다가 나중에 지원 끊기면 폐기 혹은 가상머신 풀로 전환할 것이냐, 아니면 지금 리눅스로 전환해서 GPU 활용에 대한 기대를 거의 접고 가상머신 풀과 백업 스토리지로 전환할 것이냐의 선택지에 놓였습니다. 둘 다 찜찜한 부분이 남아서 제법 고민이군요. 어차피 클라이언트로의 주력 PC는 비교적 최신 노트북이 될 것이니 잃는 것과 얻는 것 둘 다 고만고만 합니다. 이런 고민 중에, 일단은 데스크톱 쪽은 아직 GPU에 대한 미련이 조금은 남아서 윈도우 쪽으로 다시 돌려는 놨지만, 어디로 가도 찜찜함이 남습니다.

​한편, 이런 직접 사용과 GPU 활용에 해당사항이 없는 파일서버 쪽은, 아주 간단히 해놓은 CentOS Stream 9 구성이 대단히 만족스럽습니다. 오히려 이 쪽은 메모리와 스토리지를 더 붙여 주고 싶지만, 미니PC 특성상 쉽지 않습니다. 스토리지는 나중에 USB 외장하드 같은 걸로 붙여주는 수밖에 없겠고... 메모리는 이제 업무용 PC로 쓰는 씽크패드 E460이 용도상실이 확정되면 이 쪽의 16GB를 옮겨주기 전까지는 별다르게 손을 댈 여지가 없겠네요. 사실 요즘 파일서버 활용도 원드라이브 위주로 가면서 많이 줄어서, 그리 아쉽지 않습니다. 여러 모로 환경 간소화를 위한 길이 더 복잡해지는 느낌이긴 하네요.


덧글

댓글 입력 영역

ad3