Wayland 컴포지터와 윈도 관리자 분리

• 기존 Wayland 환경은 컴포지터와 윈도 관리자가 하나의 프로그램으로 결합된 구조였으나, river 0.4.0은 이를 별도 프로세스로 분리함
• 새로운 river-window-management-v1 프로토콜은 윈도 관리자에게 창 배치, 키 바인딩 등 정책 전권을 부여하면서도 프레임 완전성(frame perfection) 과 성능을 유지함
• 이 구조는 입력 지연(latency) 없이 동작하며, 복잡한 타일 레이아웃에서도 원자적 상태 업데이트를 통해 깔끔한 렌더링을 보장함
• 분리된 구조 덕분에 윈도 관리자는 독립적으로 개발·재시작 가능, 고수준 언어로도 구현이 용이함
• 이 접근은 Wayland 생태계의 윈도 관리자 다양성 확대를 촉진하며, river는 이미 15개 이상의 호환 관리자를 지원함

---

Wayland 전통 구조와 river의 분리 접근

• 기존 Wayland 컴포지터는 디스플레이 서버, 컴포지터, 윈도 관리자 세 역할을 하나의 프로세스에 통합
  • 디스플레이 서버는 입력 이벤트를 라우팅하고, 커널에 표시 버퍼를 전달
  • 컴포지터는 여러 창의 버퍼를 결합해 최종 화면을 생성
  • 윈도 관리자는 창 배치와 키 바인딩 등 사용자 정책을 담당
• X11 구조에서는 디스플레이 서버가 별도 프로세스로 존재해 불필요한 왕복 통신과 지연이 발생
• Wayland는 이를 해결하기 위해 서버와 컴포지터를 통합했으나, 윈도 관리자까지 결합한 것은 필수적이지 않음
• river는 이 결합을 해체해 윈도 관리자를 별도 프로그램으로 분리함

river-window-management-v1 프로토콜의 설계 원칙

• 윈도 관리자가 최대 제어권을 가지면서도 Wayland의 장점을 유지하도록 설계
• 매 프레임이나 입력 이벤트마다 왕복 통신이 필요하지 않음, 입력 지연이 없음
• 프레임 완전성(frame perfection) 유지: 창이 새로 열리거나 크기가 바뀔 때 틈이나 겹침 없는 화면 갱신 보장
  • 모든 창이 새 버퍼를 제출할 때까지 렌더링을 지연하되, 일정 시간 초과 시 타임아웃으로 처리
• 잘 구현된 애플리케이션일수록 완전한 프레임 동기화가 가능

상태 머신 기반 윈도 관리 구조

• 프로토콜은 상태를 윈도 관리 상태와 렌더링 상태로 구분
  • 윈도 관리 상태: 창 크기, 전체화면 여부, 키보드 포커스, 키 바인딩 등
  • 렌더링 상태: 창 위치, 순서, 장식, 크롭 등
• 변경 사항은 원자적 업데이트(manage/render sequence) 로 묶여 처리
• 컴포지터가 시퀀스를 시작하며, 상태 변화가 없을 때는 윈도 관리자가 대기 상태로 유지
• 이 구조는 기존 river-classic, sway 등에도 내재된 개념을 명시적으로 정형화한 형태

분리 구조의 이점

• 윈도 관리자 개발자는 컴포지터 전체를 구현할 필요 없이 정책에만 집중 가능
• 디버깅과 재시작이 용이, 윈도 관리자 충돌이 세션 종료로 이어지지 않음
• 가비지 컬렉션 언어로 작성해도 성능 저하 없음, 프레임 지연 없이 동작
• 이미 15개 이상의 river 호환 윈도 관리자가 존재하며, X11 수준의 다양성 확장을 기대

한계와 향후 계획

• 현재 프로토콜은 2D 데스크톱 환경만 지원, VR 등은 미지원
• 복잡한 시각 효과(예: 흔들리는 창)는 범위 밖이지만, 단순 애니메이션은 가능
• 향후 커스텀 셰이더 지원을 검토 중이나 단기 계획은 아님
• river 0.4.0은 일상 사용에 충분하며, 1.0.0 버전 전환 전 UX 개선이 예정
• 개발 지속을 위해 liberapay, GitHub Sponsors, Ko-fi를 통한 후원 요청

예시 및 갤러리

• river에서 동작하는 다양한 윈도 관리자 예시 제공
  • Canoe: 클래식한 스태킹 윈도 관리자
  • reka: Emacs 기반 윈도 관리자
  • tarazed: 집중형 데스크톱 환경
  • rhine: 재귀적·모듈형 윈도 관리와 애니메이션 지원
• 이외에도 다수의 river 호환 윈도 관리자가 존재함

[GN⁺]

Hacker News 의견들

• 댓글들에서 Wayland(프로토콜)에 대한 불만을 이해하기 어렵다는 생각임
  wlroots 같은 라이브러리가 이미 무거운 부분을 처리했고, 이제 river가 더 높은 수준의 추상화를 제공함
  Wayland 프로젝트가 이런 추상화를 더 일찍 제공할 수도 있었겠지만, 누구나 할 수 있었던 일이라 생각함
  결국 우리는 이런 발전을 무료로 얻고 있으니, 남이 대신 해주지 않는다고 불평할 필요는 없다고 봄

  • Wayland가 초기에 스크린샷 금지 같은 원칙적 입장을 취한 게 문제의 시작이었다고 봄
    접근성 문제도 보안 리스크로 여겨서 설계가 어려워졌고, 이제 Agentic AI 시대에 접어들면서 이게 흥미로운 지점이 될 것 같음
    Pipewire가 Wayland가 놓친 부분을 채워가고 있지만, 여전히 사용자 친화적 설계가 부족하다는 인식이 있음
    그래도 Wayland는 한두 걸음 뒤로 가더라도 전체적으로는 두 걸음 앞으로 나아가는 중이라 생각함
  • 불만의 근본 원인은 Wayland 커뮤니티, 특히 GNOME 진영의 태도 때문이라 봄
    “내 방식 아니면 나가라” 식의 대응이 많고, 외부 요청에 유연하지 않음
    무료로 제공된다는 점은 좋지만, Xorg가 중단되고 대안이 없는 상황에서 강제로 밀어붙이는 건 문제라고 생각함

• 이번 프로젝트를 보고 처음으로 Wayland가 시간 낭비가 아니라고 느껴짐
  디스플레이 서버가 굳이 윈도우 관리까지 복잡하게 할 필요는 없다고 생각함
  원래 Wayland가 윈도우 매니저와 컴포지터를 합친 이유는 단순히 저항이 적은 길이었을 것 같음
  다만 원격 접근 기능은 여전히 문제임. X11에서는 잘 되던 게 Wayland에서는 버그가 많았음

  • X11은 Xserver와 윈도우 매니저가 분리되어 있어서 초기 윈도우 배치 같은 문제를 해결하기 어려웠음
    Wayland는 이를 통합해 해결했지만, 다른 부작용이 생겼음
  • 대부분의 소형 Wayland 컴포지터는 wlroots나 smithay 같은 라이브러리를 사용함
    API 경계가 잘 잡혀 있어서 코드 공유가 쉬움
    90도 회전 버그는 compositor 쪽 문제인지 wlroots 문제인지 궁금함
  • X11의 원격 접근은 엉망이었음. Wayland에서는 EGL이나 Vulkan을 통해 더 깔끔하게 계층화할 수 있어서 오히려 낫다고 생각함
  • X11에서는 윈도우 매니저가 데코레이션을 담당했기 때문에, 분리하려면 메시징과 설정이 복잡해짐
  • 아마도 데스크탑 환경들이 자기들만의 생태계를 만들며 사다리를 걷어찬 것일 수도 있음

• Wayland의 여러 설계 결함 중 하나가 이제야 고쳐지기 시작했다고 생각함
  공통 프로토콜이 자리 잡고 윈도우 매니저들이 X11 수준으로 성숙하려면 또 15년은 걸릴 것 같음
  그리고 결국 또 누군가 “더 나은 걸 만들겠다”며 Wayland를 버리고 새로 시작할 것 같음

  • 그래서 요즘은 WSL이나 Virtualization Framework 같은 게 데스크탑 리눅스의 현실적 해법이라 생각함
    UEFI 문제로 고생하다 결국 Samsung DEX로 넘어감
  • Wayland를 새로 만든다 해도 결과는 비슷할 것임
    한계는 기술적이라기보다 정치적 문제라고 봄

• 25년째 리눅스 사용자로서, 5년 전 Wayland로 전환한 뒤로는 화면 찢김(tear) 문제 없이 만족 중임
  개발자 입장에서는 더 많은 일이 생기겠지만, 사용자로서는 분명한 개선임

  • 그래도 윈도우 셰이딩 기능이 없는 건 아쉬움
    예전 CDE 기능을 그리워하던 사람들처럼 나도 계속 이 얘기를 하게 될까 싶음

• River는 분리 이전에도 훌륭했음. 앞으로의 발전이 기대됨
  잠시 Niri로 옮겼지만 언젠가 다시 돌아올 예정임
  Xmonad 사용자라면 River가 가장 잘 맞을 것 같음

  • 나도 Xmonad를 쓰고 있는데, Hyprland는 master/slave 스택을 제대로 처리하지 못했음
    River에서는 새 창이 현재 선택된 창 위에 삽입되는지 궁금함
    분리 후에는 윈도우 매니저 쪽 프로젝트 이름이 뭔지도 알고 싶음

• 결국 우리는 X11의 기능을 하나씩 재발명하고 있는 셈임
  언젠가 Wayland 창이 자기 위치를 알 수 있게 될지도 모르겠음

  • 이상주의자들은 여전히 가상 2D 픽셀 그리드조차 명시하기를 꺼림
    아마 한동안은 기다려야 할 듯함
  • 하지만 이제는 대부분의 GNU/Linux가 헤드리스 서버나 임베디드용으로 쓰이기 때문에 큰 의미는 없을 것임
    데스크탑은 Android, ChromeOS, 혹은 Windows/macOS 위의 VM들이 차지할 것 같음

• 나는 완전히 커스터마이즈한 River 윈도우 매니저를 쓰고 있음
  Hyprland에서는 기본적으로 BSP 타일링만 가능해서 불편했는데, River에서는 원하는 대로 균등 타일링이 가능함
  이 분리가 내 워크플로에 큰 변화를 줬음

  • “균등 타일링”을 원한다면 hy3를 참고할 만함
    나도 예전 i3 사용자였는데, hy3 덕분에 Hyprland를 쓸 수 있었음
  • 나도 Hyprland에서 비슷한 문제를 겪었고, 결국 Niri로 옮겨 안정적인 개발 환경을 찾았음
    내 설정은 dotfiles에 정리해둠
  • BSP가 뭔지 묻고 싶음

• Wayland의 핵심 설계 중 하나가 윈도우 매니저와 컴포지터의 통합이었던 걸로 알고 있음
  왜 그렇게 설계했는지 궁금함

  • 윈도우 매니저가 별도 프로세스로 비동기 통신을 하면 프레임 싱크 문제가 생김
    Wayland는 이를 동기적으로 처리해 시각적 불일치를 없앰
  • Wayland는 컨텍스트 스위칭 최소화를 위해 모든 걸 한 프로세스에 넣었음
    이번 프로토콜은 그 성능 이점을 유지하면서도 그래픽 서버와 윈도우 매니저를 분리하려는 시도임

• Wayland에서 플러그형 윈도우 매니저를 쉽게 교체할 수 없는 점이 X11 대비 가장 큰 손실이라 생각함
  이런 문제를 해결하려는 사람들은 정말 귀한 존재임

  • 수십 년간 같은 윈도우 매니저를 써온 입장에서, 완전한 대체 인터페이스가 없으면 Wayland로 옮기기 어려움
    River나 Wayback 같은 레이어가 그런 역할을 해주길 바람
  • 이 제약은 새로운 WM·DE 개발에도 큰 장애임
    나도 실험적인 데스크탑 아이디어가 있지만, 빠른 반복이 가능한 X11로 시작할 수밖에 없음
    Wayland는 여전히 설계상 약점이 있음
  • 사실 한 구현체만 WM 확장 API를 제공하면 충분하다고 생각함
    표준에서 특정 구조를 강제할 필요는 없음
  • 이상적으로는 루트 Wayland 서버 아래에 사용자별 Wayland 서버, 그 안에 X11 서버, 그리고 그 위에 윈도우 매니저가 있는 계층형 구조가 가장 깔끔할 것 같음

• 15년째 i3를 쓰고 있는데, 이런 프로젝트가 나올 때마다 왜 Wayland가 필요한지 의문이 듦
  X11은 단점이 있어도 원하는 건 거의 다 할 수 있음
  Wayland는 항상 마찰이 많아 보임

  • 나는 KDE 5 시절부터 Wayland를 써왔는데, HiDPI 스케일링이 훌륭했음
    노트북 사용자로서 큰 장점이었고, VRR이나 HDR 지원도 X.org보다 훨씬 쉬움
  • 사용자 입장에서는 그냥 잘 작동함
    디스플레이별 DPI 조정, 화면 찢김 방지, 그리고 앱의 무단 스크린 녹화 차단이 기본적으로 해결됨
  • i3에서 sway로 옮긴 이유도 DPI 지원 때문이었음
    Xorg.conf를 더 이상 만지지 않아도 돼서 삶의 질이 올라감
    지금도 모니터마다 다른 스케일 비율을 쓰고 있음
  • X11은 고주사율 설정이 항상 문제였음
  • 최근 겪은 문제는 Wayland가 DeviceEvent를 지원하지 않는다는 점이었음
    윈도우가 비활성화돼도 입력을 받는 기능이 필요한데, 마우스 이동만 예외적으로 작동함
    결국 Window Event로 바꿨지만 여전히 불편함