# Wayland 컴포지터와 윈도 관리자 분리 > Clean Markdown view of GeekNews topic #27561. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27561](https://news.hada.io/topic?id=27561) - GeekNews Markdown: [https://news.hada.io/topic/27561.md](https://news.hada.io/topic/27561.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-16T20:33:36+09:00 - Updated: 2026-03-16T20:33:36+09:00 - Original source: [isaacfreund.com](https://isaacfreund.com/blog/river-window-management/) - Points: 2 - Comments: 1 ## Topic Body - 기존 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 호환 윈도 관리자**가 존재함 ## Comments ### Comment 53150 - Author: neo - Created: 2026-03-16T20:33:36+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47388137) - 댓글들에서 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](https://github.com/outfoxxed/hy3)를 참고할 만함 나도 예전 i3 사용자였는데, hy3 덕분에 Hyprland를 쓸 수 있었음 - 나도 Hyprland에서 비슷한 문제를 겪었고, 결국 **Niri**로 옮겨 안정적인 개발 환경을 찾았음 내 설정은 [dotfiles](https://github.com/ArikRahman/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로 바꿨지만 여전히 불편함