river 0.4.0과 안정적인 river-window-management-v1 프로토콜이 Wayland 컴포지터와 윈도 매니저를 분리해 지연 없이 프레임-퍼펙트한 창 관리를 가능하게 하는 설계를 개괄한다.
전통적인 Wayland 컴포지터는 컴포지터와 윈도 매니저를 하나의 프로그램으로 결합한 모놀리식 아키텍처를 갖습니다. 이 방식의 단점은 Wayland 윈도 매니저가 전체 Wayland 컴포지터를 구현하는 상당한 작업까지 떠안아야 한다는 점입니다.
모놀리식이 아닌 Wayland 컴포지터인 river의 새로운 0.4.0 릴리스는 이러한 전통적 아키텍처에서 벗어나 윈도 매니저를 별도의 프로그램으로 분리합니다. river와 호환되는 많은 윈도 매니저가 이미 존재합니다.
안정적인 river-window-management-v1 프로토콜은 윈도 매니저가 창 위치, 키 바인딩, 그리고 기타 모든 창 관리 정책을 완전히 제어할 수 있게 하며, river 자체는 프레임-퍼펙트 렌더링, 우수한 성능, 그리고 필요한 모든 저수준 기반 기능(plumbing)을 제공합니다.
이 블로그 글은 이 프로토콜 뒤에 있는 설계 결정들을 높은 수준에서 개괄합니다. 이는 내가 FOSDEM 2026 발표에서 제시한 정보와 대략 동일합니다.
전통적인 Wayland 아키텍처는 컴포지터 프로세스 안에서 서로 다른 세 가지 역할을 결합합니다:
디스플레이 서버: 커널에서 온 입력 이벤트를 창으로 라우팅하고, 커널에 표시할 버퍼를 제공합니다.
컴포지터: 보이는 창들의 모든 버퍼를 하나의 버퍼로 합성하여 커널이 표시하도록 합니다.
윈도 매니저: 창을 배치하고, 키 바인딩을 정의하며, 기타 사용자 대면 동작을 정의합니다.
왜 지금까지의 Wayland 컴포지터들이 이러한 역할을 결합해 왔는지 이해하려면, Wayland가 해결하도록 설계된 X11 아키텍처의 근본적인 문제들 몇 가지를 먼저 이해해야 합니다.
X11 프로토콜에서는 디스플레이 서버가 컴포지터 및 윈도 매니저와 별도의 프로세스입니다:
사용자가 창 안의 버튼을 클릭하는 순간부터 창의 표시 내용이 바뀌기까지의 단계를 따라가 보면 상당히 유익합니다. 위 다이어그램의 번호를 참조하면:
사용자가 창 안의 버튼을 클릭합니다.
커널이 디스플레이 서버로 입력 이벤트를 보냅니다.
디스플레이 서버가 입력 이벤트를 어느 창으로 라우팅할지 결정합니다. 여기서 이미 문제가 생깁니다. 디스플레이 서버는 컴포지터의 씬 그래프를 알지 못하므로, 클릭 시점에 사용자의 마우스 아래에 실제로 어떤 창이 렌더링되어 있는지 100% 확신할 수 없습니다. 디스플레이 서버는 최선의 추측을 하고 이벤트를 어떤 창으로 보냅니다.
해당 창이 디스플레이 서버에 새 버퍼를 제출합니다.
디스플레이 서버가 그 창의 새 버퍼를 컴포지터로 전달합니다.
컴포지터가 그 창의 새 버퍼를 나머지 데스크톱과 합성한 뒤 새 버퍼를 디스플레이 서버로 보냅니다.
디스플레이 서버가 컴포지터의 새 버퍼를 커널로 전달합니다.
이 아키텍처에서는 디스플레이 서버가 커널, X11 창, 컴포지터 사이에서 불필요한 중간자 역할을 합니다. 그 결과 디스플레이 서버와 컴포지터 사이에 불필요한 왕복(roundtrip)이 발생해, 매 프레임마다 지연이 추가됩니다.
전통적인 Wayland 아키텍처는 디스플레이 서버와 컴포지터를 하나의 프로세스로 결합함으로써 이러한 불필요한 왕복을 제거하고, 2번 단계에서 언급한 입력 라우팅 문제도 해결합니다:
전통적으로 Wayland 컴포지터는 윈도 매니저의 역할까지 함께 맡아 왔지만, 이는 X11의 아키텍처 문제를 해결하기 위해 사실 필요한 단계는 아닙니다. 원래 Wayland 작성자들이 왜 윈도 매니저와 Wayland 컴포지터를 결합하기로 했는지 확실히 알 수는 없지만, 단지 저항이 가장 적은 길이었을 것이라 추정합니다. Wayland의 장점을 모두 유지하는 창 관리 프로토콜을 설계하는 일은 쉽지 않지만, 분명히 가능합니다.
river-window-management-v1 프로토콜은 Wayland의 핵심 장점들을 잃지 않으면서 윈도 매니저에 최대한의 제어권을 주도록 설계되었습니다. 구체적으로, 창 관리 프로토콜은 매 프레임 또는 매 입력 이벤트마다 왕복을 요구해서는 안 됩니다. 예를 들어 터미널 에뮬레이터에 타이핑을 하거나 게임을 할 때, 전통적인 모놀리식 Wayland 아키텍처에 비해 입력 지연 패널티가 없어야 합니다.
더 나아가 Wayland의 이상인 “프레임 퍼펙션(frame perfection)”도 유지되어야 합니다. 창 관리 맥락에서 프레임 퍼펙션이 의미하는 바를 설명하기 위해 다음 예를 생각해 봅시다. 여러 창이 화면 전체를 차지하는 타일 배치로 놓여 있고, 새 창이 열립니다. 윈도 매니저는 새 창을 타일 배치에 추가하기로 결정하고, 공간을 만들기 위해 기존 창들의 크기를 조정하고 재배치합니다.
이 경우 프레임 퍼펙션이란, 사용자가 타일 배치에 빈틈이 생긴 프레임이나, 창들이 겹쳐 이웃한 창들과 깔끔하게 맞물리지 않는 치수를 가진 프레임을 보지 않아야 한다는 뜻입니다. 여기서 프레임 퍼펙션을 달성하려면, 모든 창이 새로 요청된 치수로 버퍼를 제출할 때까지 기다렸다가 새로운 상태를 렌더링해야 합니다.
다만 프레임 퍼펙션은 창들이 잘 구현된 프로그램에 의해 그려질 때에만 달성 가능하다는 점에 유의해야 합니다. 컴포지터가 창들이 새 버퍼를 제출하길 무한정 기다리며 새 상태 렌더링을 계속 지연할 수는 없습니다. 너무 오래 지연하면 사용자에게는 더 부드럽기보다 덜 반응적인 느낌을 줍니다. 이를 해결하기 위해 컴포지터는 짧은 타임아웃을 사용합니다. 창들이 너무 느리면 프레임 퍼펙션은 불가능합니다.
river-window-management-v1 프로토콜은 윈도 매니저가 관리하는 상태를 서로 겹치지 않는 두 범주로 나눕니다: 창 관리 상태(window management state)와 렌더링 상태(rendering state).
창 관리 상태는 컴포지터와 개별 창 사이의 통신에 영향을 줍니다. 여기에는 창 치수, 전체화면 상태, 키보드 포커스, 키보드 바인딩 등이 포함됩니다.
반면 렌더링 상태는 컴포지터의 렌더링 출력에만 영향을 주며, 컴포지터와 개별 창 사이의 통신에는 영향을 주지 않습니다. 여기에는 창의 위치와 렌더링 순서, 서버 측 데코레이션, 창 크롭(cropping) 등이 포함됩니다.
프레임 퍼펙션을 달성하기 위해, 윈도 매니저가 이 상태에 가하는 수정은 river-window-management-v1 프로토콜을 통해 원자적 업데이트(atomic update)로 배치 처리됩니다. 창 관리 상태의 변경은 “관리 시퀀스(manage sequence)” 동안에만 발생할 수 있고, 렌더링 상태의 변경은 “렌더 시퀀스(render sequence)” 동안에만 발생할 수 있습니다.
위 상태 머신에서 보이듯, 컴포지터가 관리/렌더 시퀀스를 시작하며, 창 관리와 관련된 상태가 바뀌지 않은 동안에는 윈도 매니저와의 왕복이 필요하지 않습니다. 달리 말해, 사용자가 예를 들어 터미널에 타이핑하는 동안에는 윈도 매니저가 유휴 상태로 머물고, 예를 들어 사용자가 윈도 매니저 키 바인딩을 트리거하거나 새 창이 열릴 때 다시 깨워집니다.
동시에, 복잡한 타일 배치나 윈도 매니저가 렌더링하는 서버 측 데코레이션이 있더라도 프레임 퍼펙션이 가능합니다. 컴포지터가 창들과의 모든 동기화 작업을 처리하고, 윈도 매니저는 예를 들어 새 창 치수에 맞추어 창의 위치를 조정하거나 서버 측 데코레이션의 크기를 조정하기만 하면 됩니다.
이 상태 머신 자체는 사실 새로운 아이디어가 아닙니다. 예를 들어 river-classic이나 sway 같은 대부분의 기존 Wayland 컴포지터 내부에도 비슷한 것이 숨어 있습니다. 어떤 의미에서는, 이 상태 머신은 구버전 river가 사용하던 내부 아키텍처를 명확히 하고 공식화한 것입니다. 이는 river를 개발하며 6년 이상 쌓아 온 경험과, 시간이 지나며 아키텍처를 천천히 다듬어 온 결과입니다.
Wayland 컴포지터와 윈도 매니저를 분리하면 Wayland 윈도 매니저를 작성하기 위한 진입 장벽이 크게 낮아집니다. 윈도 매니저 작성자는 전체 Wayland 컴포지터까지 구현할 필요 없이 창 관리 정책에 집중할 수 있습니다. wlroots 같은 라이브러리가 컴포지터 작성을 다소 쉽게 만들어 주긴 하지만, 여전히 상당한 작업량입니다. Wayland 컴포지터를 작성하는 일은 주말 프로젝트가 아니지만, 새로운 river-window-management-v1 프로토콜을 사용하면 기본적이지만 쓸만한 Wayland 윈도 매니저를 주말 동안 작성하는 것이 이제 매우 가능해졌습니다.
윈도 매니저 개발자 경험도 크게 개선됩니다. 윈도 매니저가 크래시하더라도 Wayland 세션이 사라지지 않습니다. 윈도 매니저는 재시작할 수 있고, 서로 전환할 수도 있습니다. 윈도 매니저 디버깅은 Wayland 컴포지터 디버깅에 비해 훨씬 덜 고역입니다. Wayland 컴포지터를 작성해 본 사람이라면 “베어 메탈”(즉 DRM/KMS를 직접 사용)에서만 재현되는 이슈를 디버깅하는 고통을 알고 있을 텐데, 무엇이 잘못됐는지 알아내기 위해 다른 컴퓨터에서 ssh로 접속해야만 하는 상황도 생깁니다.
또한 컴포지터 성능/지연을 희생하지 않으면서, 느린 고수준 가비지 컬렉션 언어로도 윈도 매니저를 구현할 수 있습니다. 컴포지터에 가비지 컬렉터가 있으면 프레임 데드라인을 놓치고 입력 지연 스파이크를 유발하기 쉽습니다. 하지만 river-window-management-v1 프로토콜은 매 프레임 윈도 매니저와의 왕복을 요구하지 않기 때문에, 윈도 매니저에 가비지 컬렉터가 있어도 사실 크게 문제되지 않습니다. 나는 10년이 훨씬 넘은 ThinkPad x220에서 느리고 가비지 컬렉션 기반인 내 윈도 매니저를 매일 사용해도 성능 문제를 겪지 않습니다.
현재 Wayland는 X11 윈도 매니저의 다양성에 전혀 가까이 가지 못합니다. Wayland 컴포지터와 윈도 매니저를 분리하면 이것이 바뀔 것이라 믿으며, river를 위해 이미 작성된 15개의 윈도 매니저에서 그 변화의 시작을 보고 있습니다!
river-window-management-v1 프로토콜은 전통적인 2D 데스크톱 패러다임에서 벗어나는 사용 사례를 지원하지 않습니다. 예를 들어 VR 지원은 없습니다.
흔들리는 창 같은 과격한 시각 효과도 현재 river의 범위 밖입니다. 다만 단순한 애니메이션은 이미 잘 동작합니다. 언젠가 커스텀 셰이더를 탐색하여 윈도 매니저에 렌더링 제어권을 더 주는 방안을 열어 두고는 있지만, 빨라도 1~2년 안에는 일어나지 않을 것으로 보입니다. 지금은 다른 우선순위가 있습니다.
river가 프로토콜 확장으로 해결할 수 없는 창 관리 정책상의 제약을 둔다고는 인지하지 못하고 있습니다. river가 아직 지원하지 않는 사용 사례가 있는 윈도 매니저를 개발 중이라면 이슈를 열어 주세요. 어떻게 지원할지 함께 방법을 찾아보겠습니다!
0.4.0 릴리스 기준으로, river는 선택한 윈도 매니저와 조합해 일상적으로 사용하기에 이미 충분히 기능이 풍부합니다. 또한 river-window-management-v1 프로토콜은 안정적이며, 우리는 윈도 매니저를 깨뜨리는 변경을 하지 않습니다.
향후 어떤 기능이 추가될 계획인지 감을 잡는 가장 좋은 방법은 이슈 트래커의 accepted 라벨을 보는 것입니다.
river 1.0.0 이전에 무엇이 필요하냐는 관점에서는, river 호환 윈도 매니저를 시작하고 서로 전환하는 UX를 개선하는 몇 가지 아이디어를 탐색해 보고 싶습니다. river 0.4.0을 위해 작성된 모든 윈도 매니저는 river 1.0.0 이후에도 호환성을 유지하겠지만, 그 계획이 어떻게 정리되느냐에 따라 river의 CLI에는 사소한 하위 호환성 파괴 변경을 해야 할 수도 있습니다. 어떤 경우든, 다음 메이저 river 릴리스는 1.0.0이 될 것이라 기대해 주세요!
안타깝게도 현재의 river 개발 속도는 더 많은 재정적 지원 없이는 지속 가능하지 않습니다. river에 대한 내 작업이 당신의 삶에 가치를 더한다면 liberapay를 통해 정기 후원을 설정하는 것을 고려해 주세요. github sponsors나 ko-fi에서 일회성 또는 월간 후원으로도 지원할 수 있지만, 나는 비영리 단체가 운영하는 liberapay를 선호합니다. 지원해 주셔서 감사합니다!
윈도 매니저에 대한 이 모든 이야기를 좀 더 구체적으로 만들기 위해, river 아래에서 실행 중인 윈도 매니저들의 스크린샷을 즐겨 주세요. 이 선택은 시각적으로 가장 흥미로운 윈도 매니저들에 크게 치우쳐 있다는 점에 유의하세요. 선택할 수 있는 다른 훌륭한 윈도 매니저도 많습니다!
Canoe - 클래식한 룩앤필을 가진 스태킹 윈도 매니저:
reka - river를 위한 Emacs 기반 윈도 매니저(EXWM과 유사):
tarazed - 강력하고 산만함이 없는 데스크톱 경험:
rhine - 애니메이션을 갖춘 재귀적이고 모듈식인 창 관리:
