텍스트 입력기로 본 Wayland의 현주소

지난 12월 14일 스프린트 서울에 다녀왔다. 별 생각 없이 현재 쓰고 있는 터미널에 한글 입력이 안 돼서 입력기 연동을 하겠다는 목표로 갔는데, 결론부터 말하자면 엄청나게 깊은 토끼굴을 파헤치다 왔다.

내가 막연하게 파악하고 있던 문제는 이렇다. Alacritty는 Rust로 작성된 터미널 에뮬레이터이며, glutin이라는 라이브러리를 통해 터미널을 렌더링한다. glutin은 winit이라는 라이브러리에 기반하며, 이 winit 라이브러리가 X11, Wayland, Cocoa, win32 같은 플랫폼 API를 이용하여 창을 관리한다. 나는 Wayland 데스크톱을 사용하고 있는데 winit 라이브러리에 Wayland 용 입력기 지원이 구현되지 않아서 생기는 문제로 추측했다. 따라서 winit에 Wayland용 IME 지원을 추가하기만 하면 해결될 문제로 생각했다. 그날 종일 삽질을 통해 알게 된 것은 이보다 훨씬 깊은 문제였다.

Wayland

우선 Wayland가 무엇인지 알아보자. Linux를 비롯한 Unix-like 운영체제들은 전통적으로 GUI를 X Window System 기반으로 구현했다. X Window System (이하 X)은 1984년 MIT에서 처음으로 개발되었으며, 프로토콜의 가장 최신 버전은 1987년에 나온 11 버전이며, 가장 최신 릴리즈는 2012년에 나온 X11R7.7이다. 즉, X는 2019년 현재까지 1987년에 나온 프로토콜을 바탕으로 굴러가고 있는 것이다.

X에는 프로토콜 확장 개념이 있기 때문에 1987년 시스템이 지금까지 그대로 변화 없이 쓰였던 것은 아니지만, 역사적인 이유로 만들어진 X의 낡은 디자인 결정들과 거대한 레거시, 지나치게 복잡해진 구조, 프로토콜의 한계 등 여러 문제들이 쌓여가고 있었다. 예를 들어, X는 역사적인 이유로 서버-클라이언트 구조를 채택하고 있고 X 응용들은 X 서버와 소켓 통신을 통해 데이터를 주고받도록 되어 있는데 이는 하드웨어 가속을 적극적으로 사용하는 현대의 하드웨어에서는 비효율적인 구조이기 때문에 Direct Rendering Infrastructure (DRI)라는 확장이 도입되었고 이를 통해 X 응용들은 X 서버와의 통신 없이 직접 프레임버퍼에 접근하여 렌더링할 수 있다. 이는 즉 X가 더이상 네트워크 투명하지 않다는 의미이며, X가 역사적으로 유지해 온 서버-클라이언트 모델의 의미가 없어짐을 의미한다.

Wayland는 X의 더 현대적인 대안이다. 30년 가까이 유지되어 온 거대한 레거시에서 탈피하여 현대적인 하드웨어에 더 맞는 구조를 채택하며, 최소한으로 구성된 가벼운 스펙을 가지고 있다. Wayland가 X와 다른 점을 일부 나열하자면,

• X에는 독립된 X 서버가 있고 이를 중심으로 응용과 창 관리자(Window manager) 등이 올라가는 구조이지만, Wayland에는 독립적인 서버가 없는 대신 Wayland 프로토콜을 이용하여 직접 서버를 구현하고 여기에서 창 관리를 직접 하도록 되어 있다. 이를 Wayland compositor라고 하는데, X 서버와 창 관리자를 합쳐놓은 형태라고 보면 되겠다.
• Wayland는 설계상 네트워크 투명성을 가지지 않는다. Wayland compositor는 클라이언트와 공유되는 rendering surface를 노출하고 클라이언트(응용)는 여기에 직접 그리도록 되어 있다. X와 달리 프로토콜 레벨에서 제공하는 드로잉 기능은 없다.
• Wayland 프로토콜 자체는 극단적으로 unopinionated 된 최소한의 기능들만 제공한다. 대신 추가적인 기능을 구현할 수 있도록 프로토콜 확장을 구현할 수 있는 메커니즘을 제공한다. 예를 들면 Wayland 자체에는 input grab 기능이 없고 프로토콜 확장을 통해 이를 구현하는데 이를 위한 표준 확장들이 있고(#, #, #), 이와 동시에 wlroots라는 compositor 라이브러리는 같은 문제를 자체적인 input inhibitor protocol을 제공하는 방식으로 해결하려 한다. 스크린샷을 찍을 수 있는 기능도 없기 때문에 데스크톱 환경별로 스크린샷을 찍는 방법도 다르다. KDE의 경우 KWin 에 스크린샷 기능이 구현되어 있고 D-Bus 인터페이스를 노출한 뒤에 Spectacle에서 이를 호출하는 방법으로 구현한다. X의 경우 서버의 root window를 가져와서 이를 pixmap으로 변환하면 된다.
• Wayland에 창 관리자라는 개념이 없기 때문에 창 테두리(Window decoration)라는 개념 역시 없다. 대신 창 테두리는 기본적으로는 응용에서 알아서 하도록 되어 있기 때문에 Qt 응용과 GTK+ 응용은 서로 창 테두리 모습이 달라 보일 것이다. compositor 차원에서 창 테두리를 통일할 수 있는 방법이 없는 것은 아니지만, 프로토콜 확장을 통해 제공되는 부가 기능이다.

Wayland의 입력기 문제

X에는 X Input Method(XIM)라는 입력기 프레임워크가 있지만 1994년에 마지막으로 업데이트된 낡은 표준이라 여러가지 문제가 있고 Qt와 GTK+ 같은 보편적 프레임워크들은 XIM을 거치지 않고 각자 프레임워크 레벨에서 입력기와 통신하는 것이 일반적이다. 그렇다면 Wayland는 어떨까?

간단히 요약하자면 현재 Wayland의 입력기 프로토콜은 확정되지 않았고 바뀔 여지가 있다.

우선 밝혀둬야 할 점은, Wayland 프로토콜은 버전간 하위 호환성이 없다. 만약 여러 개의 버전이 있으면 어플리케이션의 호환성을 위해 각 버전별 프로토콜 구현을 한벌씩 일일히 만들어야 한다. 이 점을 감안하고 읽어주셨으면 한다.

• 입력기를 구현하기 위해서는 input-method-* 프로토콜을 구현해야 한다. 공식 wayland-protocols 저장소에 따르면 최신 버전은 v1이며, 5년 전에 만들어졌다.
• wlroots (sway가 쓰고 있는 Wayland compositor 라이브러리) 의 GitHub 저장소에는 input-method-unstable-v2 프로토콜 정의가 있다. wayland-protocols 저장소에도 없는 이 리비전은 어디서 온 걸까?
• 응용 단에서 입력기를 이용한 텍스트 입력을 구현하기 위해서는 text-input-* 프로토콜을 이용해야 한다. wayland-protocol 저장소에 따르면 최신 버전은 text-input-unstable-v3 이다.

비록 unstable이나 다국어 입력을 위한 프로토콜이 있긴 하다. 그렇다면, 구현은 어떨까? Wayland 환경에서 입력기를 이용할 수 있는 인프라를 갖추려면 우선 Wayland compositor에서 input-method-* 와 text-input-* 프로토콜을 구현하고 입력기와 응용들이 각각 이 프로토콜에 대응하는 클라이언트 측 구현을 가지고 있어야 한다. 우선 compositor 쪽의 현재 구현 상태를 보자.

• Wayland compositor의 레퍼런스 구현인 Weston의 경우 text-input-unstable-v1 인터페이스와 input-method-unstable-v1 인터페이스를 구현하고 있다.
• GNOME의 경우 text-input-unstable-v3 프로토콜을 구현하고 있다. 다만 input-method-* 인터페이스 구현은 없다.
• KDE의 경우 text-input-unstable-v2 프로토콜을 구현하고 있다. 프로토콜 저장소에도 없는 버려진 버전의 프로토콜을 구현하고 있다. 역시 마찬가지로 input-method-* 프로토콜 구현은 없다.
• wlroots는 text-input-unstable-v3 프로토콜과 함께 input-method-unstable-v2 프로토콜 구현이 있다. 하지만 wlroots에 기반하는 Sway는 아직 이를 사용하고 있지 않다.

그럼 응용단에서는 어떨까?

• Qt는 KDE와 마찬가지로 text-input-unstable-v2 프로토콜을 구현하고 있다. 사실 Qt는 Wayland 환경에서도 QT_IM_MODULE 을 사용하면 되므로 유명무실하다.
• GTK+는 text-input-unstable-v3 프로토콜을 구현하고 있다. 마찬가지로이 프로토콜을 거치지 않고 GTK_IM_MODULE 을 사용하면 되므로 유명무실하다.

마지막으로 입력기 구현 상태는 어떨까?

• ibus는 input-method-unstable-v1 인터페이스를 구현하고 있다.
• fcitx는 아직 릴리스되지 않은 fcitx5 브랜치에서 input-method-unstable-v1 인터페이스를 구현하고 있다.
• nimf 역시 input-method-unstable-v1 인터페이스를 구현하고 있다.
• 그 외는 아직 Wayland 입력기 인터페이스를 제공하지 않는다.

요약하자면 다국어 입력을 위해 각각의 부분에서 구현된 것들이 전혀 없진 않지만 맞는 조합이 없다. 내가 찾아본 것이 맞다면, 현재 입력기 구현을 테스트할 수 있는 compositor와 응용 프레임워크, 입력기의 조합은 현 시점에서 단 하나도 없으며, 테스트할 수 있는 방법 역시 존재하지 않는다.

즉, winit을 고쳐서 Alacritty에서 한글 입력이 되게 만들겠다는 목표는 애초에달성하는 것이 불가능한 목표였다. winit에 언제 갈아치워질지 모르는 text-input-unstable-v3 인터페이스를 구현해봤자 한글 입력을 하는 것이 가능해질까?

당초 계획처럼 Alacritty에 한글이 입력되도록 하려면 이 작업들이 필요하다.

• 현재 사용중인 Wayland compositor에 서버사이드 text-input-unstable-v3 프로토콜과 input-method-unstable-v2 프로토콜 구현을 추가한다.
• 기존 입력기에 input-method-unstable-v2 지원을 추가하거나 이를 지원하는 새로운 한글 입력기를 만든다.
• winit 라이브러리의 Wayland 플랫폼 구현에 text-input-unstable-v3 구현을 추가한다.
• 현재 프로토콜이 더 이상 바뀌지 않고 픽스되기를 기도한다. (농담)

Wayland woes

현재 상황에 대해서는 실컷 얘기했으니 좀 더 메타적인 얘기를 해 보려 한다.

대다수 리눅스 데스크톱 사용자들은 훗날 Wayland가 X를 완전히 대체할 것이라는 부분에 대해 잠정적으로 동의하고 있다. X는 더 이상 활발하게 개발되고 있지 않으며, 현재 진행되고 있는 개발은 대부분 Xwayland (Wayland-X11 호환 레이어)와 관련된 것들이다. 하지만 Wayland의 입력기 토끼굴을 파헤치면서 Wayland가 과연 얼마만큼 시간이 흘러야 X를 완벽하게 대체할 수 있을지 회의감이 자라기 시작했다.

현재 Wayland는 미성숙한 구현, 프로토콜 파편화, 하드웨어 지원 등 여러 가지 문제가 있지만 결정적인 문제라고 생각하지 않는다. 하지만 개발을 지속하고 관리해나갈 수 있는 손이 부족하다면 이야기가 달라진다. 나는 Wayland를 개발하는 데 필요한 개발력이 부족한 것이 가장 큰 문제라고 본다. Windows, macOS와 달리 리눅스 데스크톱은 매우 니치하다. X는 개발 과정에서 X Consortium과 The Open Group 아래 많은 업체들의 참여를 통해서 나름 상용 UNIX 시스템들의 황금기에 만들어졌다. 현재는 리눅스가 그 자리를 채웠고 GUI 소프트웨어는 많지 않은 FOSS 커뮤니티에 의해 어찌저찌 어렵게 굴러가고 있으며 기업 단위의 기여자들은 이제 인텔, 레드 햇 정도만 남았다. X가 낡았고 여러 문제가 있다고는 하나 여전히 주류이며 대부분의 사용자들은 별 문제 없이 쓰고 있다는 것도 개발자들로 하여금 Wayland로 이행해야 할 당위성을 축소하는 요인 중 하나이다. 나는 생각보다 Wayland 개발에 참여하고 있는 사람들이 적은 것에 놀랐다.

다국어 텍스트 입력 쪽은 전통적으로 동아시아 개발자들이 주도해오고 있는데 Wayland 기여자들 대부분은 서양권에 있기 때문에 다국어 입력 문제에 별다른 관심이 없는 것 같다. 텍스트 입력 프로토콜 쪽은 Librem을 만들고 있는 Purism이라는 곳에서 조금씩 기여하고 있는 것으로 보이는데 이 기여가 얼마나 더 이어질 수 있을지도 잘 모르겠다.

리눅스 데스크톱을 오랫동안 사용해오고 있는 입장에서 Wayland 커뮤니티에 기여할 수 있는 현실적인 방법을 고민해볼 때다.

잘못 알고 있거나 틀린 부분을 지적해주시면 감사하겠습니다.