Wayland 앱 프로그래밍이 고통스러운 이유

X11에서 Wayland로의 전환, 끝나지 않는 진통

리눅스 데스크톱의 디스플레이 서버가 X11에서 Wayland로 전환되고 있다는 이야기는 이제 10년 넘게 이어지고 있다. 2025년 현재, 대부분의 주요 리눅스 배포판이 Wayland를 기본 세션으로 채택하고 있고, GNOME과 KDE 같은 데스크톱 환경도 Wayland 위에서 작동하는 것이 기본값이 되었다. 최종 사용자 입장에서는 "잘 모르겠지만 어쨌든 돌아간다"는 수준까지 왔을 수 있다. 하지만 Wayland 위에서 직접 애플리케이션을 개발하려는 프로그래머의 시각에서는 이야기가 전혀 다르다.

한 개발자가 Wayland 애플리케이션 프로그래밍의 고충을 상세하게 토로한 글이 공유되었는데, 그 내용을 들여다보면 Wayland의 설계 철학이 애플리케이션 개발자에게 얼마나 큰 부담을 전가하는지 잘 드러난다.

X11과 Wayland의 근본적 차이

이 문제를 이해하려면 X11과 Wayland의 아키텍처 차이를 알아야 한다. X11(X Window System)은 1984년에 처음 만들어진 클라이언트-서버 프로토콜로, 디스플레이 서버가 창 관리, 입력 처리, 렌더링 지원 등 굉장히 많은 일을 담당한다. 애플리케이션은 X 서버에게 "여기에 창을 띄워줘", "이 영역을 다시 그려줘" 같은 요청을 보내면 된다. 서버가 많은 것을 처리해주기 때문에 클라이언트(애플리케이션)는 비교적 단순할 수 있다.

Wayland는 이 모델을 뒤집었다. Wayland 컴포지터는 최소한의 역할만 하고, 창 장식(title bar, 테두리), 클립보드 관리, 화면 배치 등 많은 책임이 클라이언트 쪽으로 이동했다. 이것이 Wayland가 "더 안전하고 현대적"이라고 평가받는 이유이기도 하다. X11에서는 어떤 애플리케이션이든 다른 앱의 입력을 가로채거나 화면을 캡처할 수 있었는데(보안상 큰 문제), Wayland는 이런 접근을 원천적으로 차단한다.

문제는 이 설계 철학이 만들어내는 개발 경험이다.

개발자가 직접 구현해야 하는 것들

글에서 지적하는 핵심 문제는 Wayland의 프로토콜이 너무 저수준(low-level)이라는 것이다. X11에서는 서버가 처리해주던 많은 기능을 Wayland에서는 애플리케이션(또는 그 사이의 라이브러리)이 직접 구현해야 한다.

예를 들어 창 장식(Client-Side Decorations, CSD) 문제가 있다. X11에서는 윈도우 매니저가 타이틀 바와 창 테두리를 그려주었다. 하지만 Wayland에서는 애플리케이션이 자기 창의 장식을 직접 그리는 것이 기본이다. 이는 모든 앱이 타이틀 바 렌더링, 창 리사이즈 핸들링, 마우스 커서 변경 영역 계산 같은 로직을 각자 구현해야 한다는 뜻이다. 물론 libdecor 같은 라이브러리가 이를 도와주지만, 완벽하지는 않다.

입력 처리 쪽도 복잡하다. 키보드 입력을 처리하려면 xkbcommon 라이브러리를 사용해 키맵을 직접 관리해야 한다. 키 반복(key repeat) 처리도 애플리케이션 책임이다. X11에서는 서버가 키 반복 이벤트를 보내주었지만, Wayland에서는 컴포지터가 "키 반복 속도는 이 정도"라고 알려주면 클라이언트가 자체 타이머를 돌려야 한다.

스크린 캡처와 글로벌 단축키도 직접 구현이 쉽지 않다. Wayland의 보안 모델상 애플리케이션은 자기 창 밖의 내용을 알 수 없다. 스크린 캡처를 하려면 xdg-desktop-portal이라는 D-Bus 기반 인터페이스를 거쳐야 하고, 사용자의 명시적 허가가 필요하다. 글로벌 핫키도 비슷한 이유로 직접 등록이 불가능하며, 별도의 프로토콜 확장에 의존해야 한다.

프로토콜 확장의 파편화

Wayland의 또 다른 문제는 프로토콜 확장이 파편화되어 있다는 점이다. Wayland 코어 프로토콜은 매우 미니멀하기 때문에, 실제로 유용한 기능 대부분은 프로토콜 확장(protocol extensions)으로 제공된다. 창 위치 지정, 레이어 셸(layer shell, 패널이나 런처 같은 앱용), 화면 잠금, DMA-BUF 공유 등이 모두 확장이다.

문제는 이 확장들의 지원이 컴포지터마다 다르다는 것이다. GNOME의 Mutter, KDE의 KWin, Sway의 wlroots 기반 컴포지터는 각각 지원하는 확장 셋이 다르다. 어떤 확장은 wlroots 생태계에서만 작동하고, 어떤 확장은 GNOME에서만 사용 가능하다. 애플리케이션 개발자 입장에서는 "이 기능이 사용자의 환경에서 작동할지" 확신할 수 없는 상황이 된다.

X11에서는 EWMH(Extended Window Manager Hints)라는 비교적 통일된 표준이 있어서, 대부분의 윈도우 매니저에서 같은 기능이 같은 방식으로 작동했다. Wayland에서 이에 상응하는 통일된 표준은 아직 형성 중이다.

GTK와 Qt가 다 해주는 것 아닌가?

"그런 건 GTK나 Qt 같은 툴킷이 추상화해주니까 직접 Wayland 프로토콜을 다룰 일은 없지 않느냐"고 반문할 수 있다. 맞는 말이고, 대부분의 데스크톱 앱 개발자는 실제로 그렇게 작업한다. 하지만 게임 엔진, 미디어 플레이어, 터미널 에뮬레이터, 임베디드 UI 시스템 같은 영역에서는 저수준 디스플레이 서버 접근이 필수적이고, 이때 Wayland의 복잡성을 피할 수 없다.

또한 GTK나 Qt 자체도 Wayland 백엔드에서 발생하는 버그나 제약에서 자유롭지 않다. GTK의 Wayland 백엔드에서 특정 기능이 구현되지 않았거나, Qt의 Wayland 지원에서 특정 컴포지터와 호환 문제가 있는 등의 이슈가 지속적으로 보고된다.

한국 개발자에게 주는 시사점

한국에서 리눅스 데스크톱 앱을 직접 개발하는 개발자는 많지 않을 수 있지만, 간접적으로 영향을 받는 영역은 넓다. 임베디드 리눅스 기반의 키오스크, 차량 인포테인먼트 시스템, 산업용 HMI(Human-Machine Interface) 등에서 Wayland는 이미 활발히 사용되고 있다. 이런 프로젝트에서 커스텀 UI를 구현할 때 Wayland의 저수준 특성과 컴포지터별 차이를 이해하는 것이 중요하다.

Electron이나 Flutter 같은 크로스플랫폼 프레임워크를 사용하더라도, 내부적으로 이들이 Wayland와 어떻게 상호작용하는지 파악해두면 디버깅 시 도움이 된다. 특히 리눅스 서버 환경에서 GUI 앱을 돌리거나, 원격 데스크톱 환경을 구성할 때 X11 포워딩이 되는데 Wayland에서는 안 되는 상황을 마주할 수 있다.

마무리

Wayland는 X11의 근본적인 문제를 해결하기 위해 탄생했고, 보안과 현대적 디스플레이 처리 측면에서 올바른 방향이다. 하지만 "올바른 설계"가 반드시 "좋은 개발자 경험"을 의미하지는 않는다는 점을 이 글은 보여준다. 리눅스 데스크톱 생태계가 X11의 유산을 완전히 벗어나려면 아직 갈 길이 멀어 보입니다. Wayland 개발 경험이 있는 분이라면, 가장 고통스러웠던 부분은 무엇이었나요?