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

> Clean Markdown view of GeekNews topic #25569. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25569](https://news.hada.io/topic?id=25569)
- GeekNews Markdown: [https://news.hada.io/topic/25569.md](https://news.hada.io/topic/25569.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-01-05T09:49:17+09:00
- Updated: 2026-01-05T09:49:17+09:00
- Original source: [michael.stapelberg.ch](https://michael.stapelberg.ch/posts/2026-01-04-wayland-sway-in-2026/)
- Points: 2
- Comments: 1

## Topic Body

- **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를 계속 사용**할 계획임

## Comments



### Comment 48672

- Author: neo
- Created: 2026-01-05T09:49:18+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46485989) 
- 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의 구조 자체는 [공식 아키텍처 문서](https://wayland.freedesktop.org/architecture.html)처럼 이론상 좋아 보이지만, 실제로는 프로토콜 수준에서 빠진 기능이 많음
  - 사실 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](https://github.com/stumpwm/mahogany)가 활발히 개발 중임.  
    또 [Wayback](https://gitlab.freedesktop.org/wayback/wayback)은 X11 데스크톱 전체를 Wayland 위에서 돌리는 프로젝트임
- Framework 노트북에서 Wayland를 쓰는데 완벽히 작동함.  
  4K 모니터, 단일 화면 전환, fractional scaling 모두 문제없음.  
  오래된 Chromebook에서도 **화면 찢김**이 사라졌고, 부드럽게 동작함.  
  단점은 아직 못 느꼈고, 오히려 “틀렸다”는 말을 듣는 게 유일한 단점임
  - 잘 작동한다면 좋지만, 반대로 **안 되는 사람**도 있다는 점을 인정해야 함
  - 운이 좋아서 문제를 못 겪는다고 해서 단점이 없는 건 아님
- 나에게 Wayland는 **단점만 있고 장점은 없음**. 복잡성을 다른 레이어로 떠넘기는 구조가 잘못됐다고 생각함.  
  앞으로도 Xorg와 Openbox를 쓸 예정임
  - 복잡성을 한 곳에서 여러 곳으로 분산시킨 건 **이해할 수 없는 결정**임
  - 그래도 Xorg는 유지보수가 줄어들고 있고, 주요 개발자들이 Wayland로 옮겨가고 있음.  
    결국 Wayland가 **유일하게 적극적으로 관리되는** 선택지가 될 것임