▲

2026년에 드디어 Wayland을 쓸 수 있을까?

 (michael.stapelberg.ch)
2P by GN⁺ 2일전 | ★ favorite | 댓글 1개
  • Wayland는 X11의 후속 그래픽 스택으로 2008년에 시작되었지만, 작성자는 18년 동안 자신의 시스템에서 제대로 사용할 수 없었다고 평가함
  • 2025년 기준 nVidia 드라이버의 GBM 및 explicit sync 지원으로 기본 실행은 가능해졌으나, 여전히 8K 모니터 TILE 미지원 등으로 완전한 전환은 어려움
  • Sway 1.11과 wlroots 0.19.0에서 주요 기술적 진전이 있었지만, 입력 지연·그래픽 글리치·Xwayland 스케일링 문제 등 실사용 장애가 다수 존재
  • 주요 애플리케이션인 Chrome과 Emacs는 여전히 성능 저하, 렌더링 차이, 하드웨어 가속 불안정 등의 문제를 보임
  • 전반적으로 Wayland는 “이제야 실사용이 가시권에 들어왔지만”, 일상 업무용으로는 여전히 X11/i3 조합이 더 안정적이라는 결론

Wayland의 역사적 배경

  • Wayland는 2008년 시작된 X 서버(X11, Xorg)의 후속 프로젝트로, 작성자는 2009년 X11용 타일링 윈도 관리자 i3를 개발함
  • 초기에는 Weston 데모 컴포지터만 실행 가능했으며, 2014년 GNOME, 이후 KDE가 Wayland를 지원하기 시작
  • Firefox, Chrome, Emacs 등 주요 애플리케이션은 실험적 플래그를 통해서만 Wayland를 사용할 수 있었음
  • nVidia GPU는 오랜 기간 Wayland에서 작동하지 않거나 그래픽 오류를 일으켰으며, 8K 모니터 호환성 문제도 지속됨
  • 최근 Fedora, RHEL, Asahi Linux 등 주요 배포판이 Wayland를 기본 또는 유일한 데스크톱 스택으로 채택하면서 전환 압력이 증가함

Wayland 실행 환경 구성

  • 테스트 시스템은 nVidia RTX 4070 Ti(랩 PC)와 RTX 3060 Ti(메인 PC)를 사용
  • nVidia 드라이버 495(2021) 부터 GBM 지원이 추가되었고, explicit sync 기능이 Sway 1.11(2025) 과 wlroots 0.19.0에서 구현됨
  • 그러나 8K Dell UP3218K 모니터의 TILE 속성 미지원으로 Sway에서는 화면이 두 개로 분리되어 표시됨
    • EBADBEEF의 패치와 Claude Code의 분석을 통해 SRC_X DRM 속성 버그를 발견하고, 우회 패치로 전체 화면 표시 성공
  • GNOME은 TILE을 지원하지만 화면 중앙에 심한 티어링이 발생함
  • NixOS 25.11 환경에서 GDM, GNOME, Sway를 병행 설정하고, foot, fuzzel, wayland-utils 등 Wayland 전용 도구를 추가함

실험 결과: Sway 환경

  • Sway는 i3 설정과 대부분 호환되며, 작성자는 NEO 키보드 레이아웃과 입력·출력 설정을 조정함
  • 주요 문제점:
    • 마우스 포인터 지연 및 부드럽지 않은 움직임 (nVidia 하드웨어 커서 미지원 추정)
    • Xwayland 앱의 스케일링 불가로 흐릿하거나 이중 확대 표시
    • 일부 단축키가 이중 실행(ghost key press) 되는 현상
  • GTK 앱은 초기 폰트 크기 과대 문제를 gsettings reset으로 해결
  • GTK3는 dconf 설정만 사용하므로 font-name을 dconf로 지정해야 렌더링 일치
  • swaylock은 i3lock과 달리 종료 시 “붉은 화면” 상태가 되며, SIGUSR1로만 해제 가능
  • i3 IPC 기반 자동화 도구는 소켓 경로 차이, 프로세스 잔류, 레이아웃 복원 미지원 등으로 부분적 호환

주요 애플리케이션 테스트

  • foot 터미널은 경량이지만 일부 색상 차이, Ctrl+Enter 처리, URL 선택, screen 색상 문제 등 발견
  • Emacs는 기본 버전이 Xwayland에서 실행되어 흐릿하게 표시되며, pgtk 버전은 입력 지연과 글자 간격 차이 존재
  • Chrome은 GPU 프로세스 충돌로 하드웨어 가속이 중단되며, 창 복원 시 이전 워크스페이스 정보 미유지
  • 화면 공유는 xdg-desktop-portal-wlr을 통해 가능하지만, 창 단위 공유 미지원 및 저해상도 전송 문제 존재
  • 출력 스케일링 활성화 시 창 내용이 순간적으로 이동하거나 흐릿해지는 글리치 발생
  • dunst 알림과 rofi(2.0.0 이상) 는 정상 작동, grim 스크린샷 도구는 창 선택 기능이 불편함

결론: 2026년의 Wayland 사용 가능성

  • Wayland/Sway 세션이 처음으로 실사용 수준에 근접, 그러나 여전히 다수의 결함 존재
  • X11/i3 환경은 지연 763μs 수준의 낮은 입력 지연과 완벽한 안정성을 제공
  • Wayland 전환 시 그래픽 글리치, 입력 지연, 주요 앱 성능 저하가 발생
  • 일상 사용을 위해 필요한 조건:
    • Sway의 이중 키 입력 및 전환 글리치 해결
    • Chrome 하드웨어 가속 안정화 및 창 복원 지원
    • Emacs(pgtk) 의 입력 지연 및 렌더링 개선
  • 결론적으로, Wayland는 아직 일상 업무용으로는 준비되지 않았으며, 작성자는 X11/i3를 계속 사용할 계획임
▲
GN⁺ 2일전  [-]
Hacker News 의견들
  • Wayland은 단순히 프로토콜일 뿐이라 여러 구현체(GNOME, KDE, wlroots 등)가 존재함
    Xorg는 하나의 견고한 기반 위에 데스크톱이 얹히는 구조였지만, Wayland는 각 데스크톱이 바퀴를 다시 만드는 셈임
    Weston은 참고용으로는 좋지만 일상 사용에는 부적합함
    모든 데스크톱이 공통으로 사용할 표준 라이브러리가 필요하다고 생각함. wlroots가 그 역할을 노리지만 GNOME이나 KDE가 곧 옮겨갈 것 같지는 않음
    • X.org는 적절한 추상화 수준을 잡았다고 생각함. WM이 입력이나 출력 처리를 직접 다루지 않아도 되었고, 그 덕분에 단순성과 전력 효율이 좋았음. Wayland는 X11의 교훈을 배우지 못한 셈임
    • 나는 Sway와 Hyprland, 지금은 niri를 써왔음. wlroots 기반인 Sway와 niri는 꽤 괜찮지만 여전히 랜덤한 버그가 많음. Wine 앱의 포인터 문제, 화면 공유 충돌, 10비트 색상 문제 등. 2027년쯤엔 안정될지도 모르겠지만, 20년 개발치고는 비효율적이었다고 느낌
    • KDE와 GNOME은 각각 xdg-desktop-portal 구현체를 따로 가지고 있어서 호환성 문제가 생김. wlroots 기반이라면 xdg-desktop-portal-wlr을, Hyprland라면 xdg-desktop-portal-hyprland를 써야 함.
      Wayland의 구조 자체는 공식 아키텍처 문서처럼 이론상 좋아 보이지만, 실제로는 프로토콜 수준에서 빠진 기능이 많음
    • 사실 X도 프로토콜이었지만, X.org라는 단일 구현체가 있었기에 혼란이 적었음. wlroots 수준의 표준화된 라이브러리를 하나 두는 게 기술적으로 불가능한 건 아님
    • Wayland 개발자들은 원래 디스플레이 전용 프로토콜로 설계했음. 입력이나 윈도 관리 프로토콜은 별도 그룹이 만들길 기대했는데, 그게 잘 안 됨.
      지금 Wayland를 대체하려는 시도는 결국 이미 성숙한 부분을 다시 만드는 낭비가 될 수 있음
  • 아직 Wayland를 써야 할 이유를 모르겠음. Xorg는 안정적이고, 대부분의 문제 해결 글도 “Wayland 쓰면 Xorg로 돌아가라”로 시작함.
    아마도 systemd처럼 배포판이 강제로 기본으로 바꿀 때쯤에야 본격 채택이 늘 것 같음
    • 일반 사용자는 굳이 바꿀 이유가 없음. 다만 Wayland는 다중 디스플레이 스케일링 같은 X11이 약한 부분을 잘 처리함.
      GNOME과 KDE 입장에서는 X11을 계속 유지보수하는 부담을 줄이기 위해 Wayland로 옮기려는 게 큼.
      올해는 “단점이 없는 수준”까지 가는 게 목표라고 생각함
    • Wayland가 더 부드러운 성능을 주는 느낌이지만, 일부 앱 때문에 Xorg를 써야 함.
      이미 Arch와 Ubuntu의 GNOME 49는 Xorg를 기본에서 제외했고, KDE도 곧 따라올 예정임. Xorg의 시대는 끝나가고 있음
    • 예전엔 xorg.conf를 직접 수정해야 했는데, Ubuntu에서 Wayland를 실험적으로 써본 뒤로는 완전히 갈아탐. AMD GPU라 그런지 문제 없이 매끄러움
    • Wayland의 장점은 fractional scaling임
    • 나는 x2x, xev, xdotool 같은 툴을 써야 하는데, Wayland의 보안 모델상 불가능해서 Xorg에 머물러 있음
  • Nvidia가 Wayland의 GBM API를 거부했다는 건 오해임. GBM은 Mesa 내부의 비공식 API라 Nvidia가 직접 구현할 수 없었음.
    그래서 EGLStreams라는 벤더 중립적 대안을 제시했음.
    오히려 freedesktop 쪽이 Nvidia 드라이버가 작동할 수 있는 구조를 제공하지 않았던 게 문제였음
    • 그런데 어떻게 오픈소스 프로젝트인 Mesa가 비공개 API에 의존할 수 있는지 의문임
  • 나는 Gnome에서 Wayland를 수년째 쓰고 있는데 아무 문제 없음.
    물론 Nvidia가 아닌 단순한 하드웨어 덕도 있겠지만, Wayland가 잘 작동할 수 있다는 점은 강조하고 싶음
    • 나도 마찬가지로 Sway(2016)와 KDE Plasma 6에서 완벽히 작동 중임. Steam 게임만 XWayland로 돌림. AMD/Intel 조합이 훨씬 안정적임
    • Nvidia 하드웨어로도 최근엔 꽤 매끄럽게 작동함. 예전엔 버벅였지만 지금은 Xorg보다 낫다고 느낌.
      다만 창 위치 제어나 다른 앱 탐색 같은 기능은 Gnome Shell Extension으로 우회해야 함
    • 예전에 CRT 모니터 깜빡임을 못 느꼈던 일화처럼, Wayland의 미세한 입력감이나 폰트 차이 같은 작은 불편함은 사람마다 다르게 느껴질 수 있음
  • 나는 wlroots/swaywm 기반 Wayland를 몇 년째 쓰고 있고, eGPU까지 완벽히 작동함.
    다만 AMD 하드웨어라서 그런 걸 수도 있음. 인생은 Nvidia 문제로 낭비하기엔 짧음
    • 반대로 Intel 내장 그래픽에서는 sway가 자주 크래시해서 i3+Xorg로 돌아감
    • Nvidia를 23년 써왔지만 큰 문제는 없었음. 다만 각자 선택의 문제라고 생각함
    • 예전엔 Nvidia에서도 잘 썼고, TILE 패치로 5K 화면도 괜찮았음.
      다중 출력 스케일링 지원 때문에 Wayland로 옮겼다가 다시 돌아오기도 했음
  • 최근 Windows 문제로 Linux로 넘어왔는데, 예전엔 fractional scaling 부재 때문에 불가능했음.
    Wayland 덕분에 해결되어 큰 개선임. 다만 모든 배포판이 Wayland를 기본으로 쓰진 않아 Ubuntu를 선택함.
    Snap Firefox가 하드웨어 가속을 안 써서 약간 불편했음
    • 나도 fractional scaling이 Linux에서 제일 아쉬움.
      MacOS는 “1440p처럼 보이게” 설정해도 완벽하고, Windows는 약간 흐릿함.
      Linux에서는 X11은 느리고, Wayland는 여전히 성능 지연이 있음
  • 나도 i3+NixOS+urxvt+zsh+Emacs+rofi+maim+xdotool 조합을 씀.
    완벽히 작동하는 이 스택을 Sway로 바꾸는 건 이득보다 손해가 큼.
    Michael이 시도하고 문서화한 건 대단하다고 생각함
    • 실제 문제를 꼼꼼히 기록한 점이 인상적임
  • 내가 쓰는 윈도 매니저(WM) 가 Wayland를 지원하기 전엔 옮기지 않을 생각임.
    Wayland의 가장 큰 문제는 다양한 WM 프로젝트가 인력 부족으로 전환을 못 한다는 점임.
    XWayland로 우회할 수는 있지만, 이미 완벽히 작동하는 환경에 굳이 레이어를 더하고 싶지 않음
    • 당신이 StumpWM을 쓴다면, Wayland 버전인 Mahogany가 활발히 개발 중임.
      또 Wayback은 X11 데스크톱 전체를 Wayland 위에서 돌리는 프로젝트임
  • Framework 노트북에서 Wayland를 쓰는데 완벽히 작동함.
    4K 모니터, 단일 화면 전환, fractional scaling 모두 문제없음.
    오래된 Chromebook에서도 화면 찢김이 사라졌고, 부드럽게 동작함.
    단점은 아직 못 느꼈고, 오히려 “틀렸다”는 말을 듣는 게 유일한 단점임
    • 잘 작동한다면 좋지만, 반대로 안 되는 사람도 있다는 점을 인정해야 함
    • 운이 좋아서 문제를 못 겪는다고 해서 단점이 없는 건 아님
  • 나에게 Wayland는 단점만 있고 장점은 없음. 복잡성을 다른 레이어로 떠넘기는 구조가 잘못됐다고 생각함.
    앞으로도 Xorg와 Openbox를 쓸 예정임
    • 복잡성을 한 곳에서 여러 곳으로 분산시킨 건 이해할 수 없는 결정임
    • 그래도 Xorg는 유지보수가 줄어들고 있고, 주요 개발자들이 Wayland로 옮겨가고 있음.
      결국 Wayland가 유일하게 적극적으로 관리되는 선택지가 될 것임
답변달기