# Xfwl4 – Xfce용 Wayland 컴포지터 로드맵 > Clean Markdown view of GeekNews topic #26205. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26205](https://news.hada.io/topic?id=26205) - GeekNews Markdown: [https://news.hada.io/topic/26205.md](https://news.hada.io/topic/26205.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-29T04:37:41+09:00 - Updated: 2026-01-29T04:37:41+09:00 - Original source: [alexxcons.github.io](https://alexxcons.github.io/blogpost_15.html) - Points: 1 - Comments: 1 ## Topic Body - Xfce 팀이 **Wayland 기반의 새로운 컴포지터 ‘xfwl4’** 개발 계획을 공개, 커뮤니티 기부금을 활용해 핵심 개발자 Brian Tarricone이 주도 - 기존 **xfwm4와 동일한 기능과 사용자 경험**을 목표로 하며, 설정 대화상자와 xfconf 구성을 재사용해 전환의 연속성 확보 - **Rust와 smithay 프레임워크**를 기반으로 완전한 신규 코드로 작성, 메모리 안정성과 맞춤형 그래픽·입력 파이프라인 제공 - 프로젝트 범위에는 **세션 관리 구조 변경, XWayland 및 xdg-session-management 지원, CI 빌드 시스템 개선**이 포함 - Xfce의 **Wayland 전환을 위한 핵심 투자**로, 첫 개발 릴리스는 연중 공개 예정 --- ### Xfce의 새로운 Wayland 컴포지터 계획 - Xfce 팀은 커뮤니티 기부금을 활용해 **새로운 Wayland 컴포지터 ‘xfwl4’** 개발을 시작 - 개발은 오랜 핵심 기여자인 **Brian Tarricone**이 담당 - 프로젝트 기금의 상당 부분이 이 개발에 사용될 예정 - 목표는 **xfwm4와 동일한 기능과 동작**을 Wayland 환경에서 구현하는 것 - 기존 **xfwm4 설정 대화상자와 xfconf 설정**을 그대로 활용해 사용자 경험의 일관성 유지 - **xfwl4는 기존 xfwm4 코드에 기반하지 않고**, Rust로 완전히 새로 작성 - **smithay** 라이브러리를 기반으로 구축 ### 기존 코드 재활용 대신 재작성 결정 이유 - 초기에는 xfwm4 코드 수정으로 X11과 Wayland를 병행 지원하려 했으나, 여러 이유로 부적합하다고 판단 - xfwm4의 구조가 **X11 종속적**이어서 일반화된 인터페이스 구현이 어려움 - 리팩터링 시 **X11 버그 발생 위험**이 높음 - **Wayland에서 지원되지 않는 X11 개념**이 존재해 코드 유지가 복잡 - 기존 코드 사용 시 **C 언어와 wlroots**에 의존해야 함 - 별도 코드베이스로 개발하면 **xfwm4 안정성 유지와 Wayland 실험적 개발 병행**이 가능 ### smithay 선택 이유 - Brian Tarricone은 **wlroots와 smithay**를 비교 평가 후 smithay를 선택 - smithay는 **공식 Wayland 프로토콜 확장 대부분**과 **wlroots·KDE 프로토콜**을 지원 - 고수준 추상화가 없어 **그래픽·입력 파이프라인의 세밀한 제어** 가능 - **문서화가 우수**하며, Rust 사용으로 **메모리 관련 버그와 크래시 위험 감소** - 개발자가 **Rust 선호** - wlroots는 C로 작성되어 **Rust 바인딩 작성이 어려움** ### 프로젝트 범위 및 기술 과제 - **xfwm4 기능 동등성 확보** 외에도 다음 과제 포함 - Wayland 환경에서는 **컴포지터가 세션 루트**가 되어야 하므로 **세션 시작 구조 변경 필요** - **xdg-session-management 프로토콜 지원** 추가 - **XWayland 지원** 포함 - **CI 컨테이너 빌드 시스템**을 Rust 코드 빌드가 가능한 meson 기반으로 업그레이드 - Brian Tarricone은 이미 개발을 시작했으며, **연중 첫 개발 릴리스 공개 예정** ### 커뮤니티와 후원 - 프로젝트는 **Open Collective US 및 EU 후원자들의 기부**로 가능해짐 - 개발 진행 상황과 기술 세부 사항은 **GitLab의 xfwl4 이슈 및 소스 코드 저장소**에서 확인 가능 - 관련 문의는 **Matrix 채널 #xfce-dev**를 통해 가능 ## Comments ### Comment 50163 - Author: neo - Created: 2026-01-29T04:37:41+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46779645) - xfwl4가 xfwm4와 **동일한 기능과 동작**을 목표로 한다고 들었음 하지만 X11과 Wayland의 구조적 차이를 고려하면, ‘동작’의 해석이 얼마나 엄격할지 궁금함 예를 들어 **포커스 훔치기 방지**는 X11에서는 복잡한 휴리스틱과 타임스탬프 검사를 필요로 하지만, Wayland에서는 컴포지터가 포커스를 완전히 통제함 결국 예전의 휴리스틱 느낌을 유지하면서도 Wayland의 권한 모델에 맞는 새로운 정책을 설계해야 하는 과제가 있음 또 하나의 관심사는 **컴포지팅 강제화로 인한 지연**임. 저사양 하드웨어에서 X11의 비컴포지팅 모드만큼 반응성을 낼 수 있을지 궁금함 - xfwl4 개발자임. “가능한 한 비슷하게”라는 문구 그대로임. 완전히 같을 수는 없지만 최대한 가깝게 만들 예정임 포커스 훔치기 방지는 오히려 Wayland 쪽이 더 **일관된 동작**을 보일 수 있음. Xfwm4는 휴리스틱 기반이라 가끔 오작동했지만, Wayland의 xdg-activation 모델은 훨씬 명확함 성능 면에서는, 최신 하드웨어에서는 큰 차이가 없을 것으로 보지만, **아주 오래된 기기**에서는 부담이 될 수도 있음. 실제로는 테스트를 더 해봐야 알 것 같음 - 예전에 400MHz 펜티엄 II + GeForce 2에서 xfwm의 컴포지터를 돌렸는데 문제없었음 컴포지팅의 부담은 사실상 **vsync 대기 시간**뿐임. 펜티엄 클래식급이 아니라면 괜찮음 - 솔직하게 이유를 밝히는 점이 좋음. 언어 섬처럼 **Rust 도입**이 빌드 툴링이나 생태계 통합에 마찰을 일으킬 수는 있겠지만, 그래도 GNOME보다 XFCE가 훨씬 만족스러웠음 - 컴포지팅이 꼭 vsync와 함께 해야 하는 건 아님. 클라이언트가 새 콘텐츠를 보낼 때 바로 화면을 갱신할 수도 있음 - 요즘은 **저가형 Intel GPU**에서도 컴포지터 오버헤드는 거의 문제되지 않음. 20년 된 노트북을 쓰는 사람만 예외일 뿐임 - XFCE가 여전히 **가벼운 데스크탑**으로 남기를 바람 KDE를 좋아하지만, 가볍다고 하긴 어려움 Wayland와 Rust 모두 긍정적으로 보며, Wayland는 미래 방향이고 Rust는 **크래시 방지**에 도움이 된다고 생각함 다만 XFCE의 전통적 사용자층은 보수적이라 새 기술에 회의적일 수 있음 - 2007년부터 XFCE를 써온 입장에서, 사용자들은 언어나 기술보다 **“그냥 잘 작동하는 것”** 을 원함 Wayland 전환은 불가피하고, 약간의 불평은 있겠지만 큰 문제 없이 진행될 것임 X11 고집파는 결국 소수로 남을 것임. XFCE 팀을 신뢰함 - Wayland가 왜 “미래처럼 느껴지는지” 모르겠음. 오히려 **기능 회귀**처럼 느껴짐 이미 잘 작동하는 GUI가 있는데, Wayland는 불필요한 복잡성과 호환성 문제를 만들고 있음 단순한 프로토콜이 오래 살아남는 법인데, Wayland는 그 반대임 - “고치지 않아도 되는 걸 고치지 말자”는 입장임 XFCE는 이미 빠르고 안정적임. Wayland로 전환해 느려진다면 **가장 큰 장점**을 잃는 셈임 - XFCE의 Wayland 전환은 **시간이 걸릴 것**으로 봄 안정성을 중시하는 커뮤니티라 X11을 기본으로 유지하다가, 완전한 기능 동등성이 확보되면 Wayland로 넘어갈 것임 - 오래된 XFCE 사용자로서, X11을 서둘러 폐기하지 않는 한 이번 변화는 긍정적으로 봄 언젠가 Wayland로 옮겨야 할 때 XFCE를 계속 쓸 수 있길 바람 - 이 프로젝트 자체가 **Wayland가 옳은 방향**임을 보여준다고 생각함 Xorg는 단일 구현이었지만, Wayland는 다양한 **라이브러리 생태계**(wlroots, Smithay 등)가 생겨남 덕분에 1인 프로젝트도 몇 달 만에 개발자 프리뷰를 낼 수 있음 이런 경쟁이 오픈소스 생태계를 발전시킬 것임 - Wayland가 저수준 기능만 제공하다 보니, **공통 데스크탑 인터페이스**를 급히 만들어야 했음 하지만 이 과정이 너무 서둘러 진행돼 통합성이 부족함. 완전한 Linux 데스크탑 API가 자리잡으려면 **10년은 더 걸릴 것**이라 봄 - 여러 구현이 생기면 경쟁이 생기지만, **유지보수 인력 부족**으로 기능 누락과 번아웃이 생길 수 있음 libcompositor 부재가 Wayland의 가장 큰 실수라고 생각함 - 코드 중복은 늘겠지만, 그만큼 각 팀이 자신들의 **철학에 맞는 구현**을 할 수 있음 XFCE 팀이 어떤 결과물을 낼지 기대됨 - 이런 논리로 Rails가 남용되던 시절을 떠올림 스택이 편리하긴 하지만, 결국 **깊은 수정이 어려운 구조**가 될 수 있음 - Wayland의 핵심은 커널이 많은 일을 대신 해준다는 점임 X는 사실상 **두 번째 커널**처럼 동작했지만, Wayland는 커널의 GEM, DMA-BUF, KMS 등 현대적 추상화를 활용함 덕분에 훨씬 깔끔하고 효율적인 구조로 발전할 수 있음 - 10년 넘게 XFCE를 메인으로 써왔음 Wayland 지원 소식이 반가움 Rust로 작성되면 **기여자 유입**에도 도움이 될 것 같음 후원을 원한다면 [Open Collective](https://opencollective.com/xfce)와 [xfce-eu](https://opencollective.com/xfce-eu)에 기부하길 권함 - 5년째 XFCE를 쓰고 있는데, 최근 매달 후원 시작했음. 좋은 소식이라 기쁨 - X11에서 Wayland로의 전환이 **리눅스 역사상 가장 고통스러운 변화**라고 생각함 - 커널 2.4에서 2.6으로 넘어갈 때도 꽤 힘들었음. 개발 모델이 완전히 바뀌었고, pre-git 시절은 혼란스러웠음 KDE4 시절도 암흑기였음 - 개인적으로는 **GNOME 2 → GNOME 3** 전환이 가장 괴로웠음. 결국 다른 WM으로 옮겼음 - 나에겐 X11에서 Wayland로의 전환은 **매우 매끄러웠음**. 결국 필요에 따라 다름 - 8년 후엔 Wayland도 X11만큼 오래돼서 **Wayland 2**가 나올지도 모름 - systemd 전환도 만만치 않았음 - Smithay의 Rust 클라이언트 툴킷을 써봤는데, **스레드 안전성**이 완전하지 않음 Arc<>로 감싸져 있어도 멀티스레드 호출 시 이상한 크래시가 남 Wayland API를 직접 파고들어 안전하게 쓰는 법을 배우고 싶음 - 현재도 대부분의 **wlroots 기반 컴포지터**에서 XFCE를 사용할 수 있음 나는 Gentoo에서 Hyprland + XFCE 조합으로 사용 중임 설정은 [이 저장소](https://github.com/bergutman/dots)에 있음 - 레트로 테마가 마음에 듦 Hyprland와 XFCE4 조합을 “저주받은 조합”이라 표현한 이유가 궁금함. 아마 XFCE가 자체 컴포지터를 만들기로 한 이유와 관련 있을 듯함 - 한때 Wayland를 거부했지만, **구형 하드웨어에서의 성능**을 보고 생각이 바뀜 오래된 Thinkpad에서 Firefox가 X11보다 훨씬 부드럽게 스크롤됨 터치패드 제스처도 추가돼 만족스러움. 설정은 조금 번거롭지만 **가치 있는 트레이드오프**임 - Wayland가 **비리눅스 시스템**에서도 동작하는지 궁금함. 예를 들어 BSD나 macOS에서 XQuartz처럼 원격 창을 띄울 수 있을까? - FreeBSD에서는 꽤 잘 동작함. OpenBSD에서도 wlroots 기반 컴포지터가 일부 작동함 Mac용 Wayland 컴포지터도 존재하며, Brodie Robertson이 관련 영상을 올림 - Microsoft의 **WSL2 GUI 통합**도 Wayland와 XWayland 기반임 [WSLg 프로젝트](https://github.com/microsoft/wslg)를 보면, Weston을 RDP로 렌더링해 플랫폼 간 윈도우 표시가 가능함 GPU 가속도 유지돼 X11 포워딩보다 낫다고 생각함 - Wayland는 **네트워크 투명성**이 없어서 원격 전송은 복잡함. Mac에서의 상태는 불확실함 - FreeBSD 공식 핸드북에도 Wayland 설정법이 있음 [FreeBSD Handbook Wayland](https://docs.freebsd.org/en/books/handbook/wayland/) - OpenBSD에서도 [Wayland_on_OpenBSD](https://xenocara.org/Wayland_on_OpenBSD.html) 문서로 실험 중임 - 요즘 “**Rust로 리라이트**”라는 말은 유지보수 인력이 없다는 뜻으로 들림 xfwm4를 패치할 사람이 없어서 새로 쓰는 것 같음 이는 세대 교체의 신호일 수도 있음 — 새 개발자들이 **단순하고 안전한 구조**로 다시 짜려는 것임 Wayland는 X11보다 단순하고, Rust는 실수를 줄여주니 자연스러운 흐름임 하지만 그 대가로 **네트워크 투명성, 성능, 안정성**이 희생될 수도 있음. 시대의 흐름이라 받아들임