Wayland, 개발자에게는 악몽? X11보다 어려운 이유
Wayland는 X11의 대안으로 등장했지만, API의 비직관성(Non-intuitive API)과 복잡한 개발 과정(Complex Development Process)으로 개발자들에게 큰 어려움을 주고 있음
간단한 윈도우 생성(Window Creation)조차 수많은 콜백 함수와 프로토콜 확장을 거쳐야 하며, 디버깅(Debugging) 또한 쉽지 않음
다양한 Wayland Compositor 간의 프로토콜 구현 차이로 인해 호환성 문제가 발생하며, 개발의 어려움을 가중시킴
Wayland의 보안(Security)을 위한 설계가 오히려 개발 편의성을 저해하고, 기본적인 기능 구현조차 어렵게 만든다는 비판이 제기됨
Wayland의 복잡한 초기화 과정
Wayland 애플리케이션 개발은 객체 지향 프로토콜(Object-Oriented Protocol) 특성상, 초기화 과정에서 수많은 콜백 함수를 등록하고 관리해야 한다. 특히, wl_display_roundtrip() 및 wl_display_dispatch() 함수의 호출 순서를 예측하기 어려워 디버깅에 어려움이 따른다. 또한, OpenGL 윈도우를 생성하기 위한 초기화 코드는 여러 번 호출될 수 있어, 초기화 과정에서 오류 발생 시 윈도우가 생성되지 않는 문제가 발생한다.
입력 처리의 어려움: 키보드, 마우스, 그리고 갱신율
Wayland에서는 키보드 입력 처리를 위해 xkb 라이브러리를 사용하여 키 입력을 번역해야 하며, 키 반복(Key repetition)을 위해서는 별도의 타이머를 설정해야 한다. 또한, 현재 갱신율(Refresh rate) 정보를 얻기 위해서는 wl_output 객체와 관련된 모든 콜백을 등록하고, 갱신율 정보를 저장해야 한다. 이러한 복잡한 과정은 개발자가 기본적인 입력 처리를 구현하는 데 많은 시간과 노력을 쏟게 만든다.
Wayland 확장 프로토콜의 파편화
Wayland는 핵심 프로토콜 외에도 다양한 확장 프로토콜을 사용하며, XdgShell과 같은 확장 프로토콜은 윈도우 관리에 필수적이다. 하지만, 이러한 확장 프로토콜은 XML 파일로부터 API 코드가 생성되며, 공식 문서화가 미흡하여 개발자가 관련 정보를 얻기 어렵다. 또한, Wayland Compositor에 따라 지원하는 프로토콜과 구현 방식이 달라, 호환성 문제로 인해 개발의 어려움이 가중된다.
Wayland의 보안 설계와 개발 편의성 간의 갈등
Wayland는 보안을 위해 설계되었지만, 이러한 설계가 개발 편의성을 저해하는 결과를 초래한다. 예를 들어, 화면 공유(Screensharing)를 위해서는 xdg-desktop-portal을 사용해야 하며, 이는 여러 Compositor에서 각기 다른 방식으로 구현되어 파편화를 야기한다. 또한, 데스크톱 상태(Desktop State)를 얻기 위한 표준 API가 없어, 개발자는 Sway-IPC-Socket과 같은 비표준적인 방법을 사용해야 하는 상황에 놓인다.
Wayland 개발의 대안: 툴킷 및 라이브러리
Wayland의 복잡성으로 인해, 많은 개발자들이 GTK, Qt, SDL, winit과 같은 툴킷 또는 라이브러리를 사용하여 Wayland 애플리케이션을 개발한다. 이러한 툴킷은 Wayland의 복잡한 부분을 추상화하여 개발 편의성을 높이지만, 툴킷에 의존하게 되면서 Wayland의 모든 기능을 활용하는 데 제약이 발생할 수 있다. 또한, 툴킷의 Wayland 지원 여부에 따라 애플리케이션의 기능 구현이 제한될 수 있다.
