본문으로 건너뛰기
J
피드

Zig로 처음부터 새로 짠 X 서버 'Phoenix' — Wayland 대신 X11을 택한 이유

open-source 약 5분
tags
#zig#x11#linux#display-server#wayland
vote
0
댓글
북마크

Xorg를 포크하지 않고 Zig로 처음부터 새로 작성한 X 서버 Phoenix가 공개됨. 아직 초기 단계이지만, 앱 격리 보안, HDR/VRR 지원, 내장 컴포지터 등 현대적 기능을 목표로 함. 제작자는 Wayland의 근본적 한계를 지적하며 X11 프로토콜 확장을 선택함.

  • 1

    Xorg 포크가 아닌 Zig로 처음부터 작성한 새 X 서버

  • 2

    앱 간 격리, 안전한 클립보드 등 보안 강화가 핵심 목표

  • 3

    Wayland의 'policy over mechanism' 철학이 비표준 앱에 치명적이라는 주장

  • 4

    GPU Screen Recorder UI의 글로벌 단축키 문제가 프로젝트의 직접적 동기

Zig로 처음부터 새로 짠 X 서버 'Phoenix'

  • Xorg를 포크한 게 아니라 Zig로 처음부터 새로 작성한 X 서버임. 제작자는 GPU Screen Recorder로 유명한 dec05eba
  • 아직 초기 단계로, 기존 X 서버 위에서 nested 모드로 간단한 GLX/EGL/Vulkan 앱만 렌더링 가능한 수준임
  • GPL-3.0 라이선스이고 현재 개발은 비공개로 진행 중

핵심 목표

  • 단순함: X11 프로토콜의 부분집합만 지원. 최근 ~20년 내 작성/업데이트된 앱이면 다 돌아감 (gtk2 포함)
  • 보안: 앱 간 기본 격리, 다른 앱 접근 시 GUI 권한 프롬프트 필요. 클립보드는 포커스된 앱만 읽을 수 있어서 Wayland 컴포지터보다도 안전하다는 주장
  • 현대 하드웨어: 멀티 모니터 개별 주사율, VRR, HDR 지원
  • 내장 컴포지터: 기본적으로 티어링 없음. picom 같은 외부 컴포지터 실행 시 자동 비활성화
  • X11 프로토콜 확장: HDR 같은 새 기능이 필요하면 X11 프로토콜 자체를 확장할 예정

비목표 (Non-goals)

  • Xorg를 대체하려는 게 아님. Xorg가 항상 더 많은 X11 기능과 오래된 하드웨어를 지원할 것
  • 레거시 비주얼 미지원 (TrueColor만), 복수 X11 스크린 미지원, GrabServer 무시
  • 간접(원격) GLX도 미지원 — 요즘은 원격 스트리밍이 더 효율적이라는 입장

Wayland를 안 쓰는 이유 — 가장 흥미로운 부분

  • 제작자의 GPU Screen Recorder UI가 Wayland에서 제대로 동작할 수 없는 게 직접적 동기임
  • Wayland 프로토콜만으로는 아예 불가능하고, Xwayland를 써도 각 컴포지터의 미정의 동작에 의존해야 함
  • 글로벌 단축키 문제가 대표적: XDG desktop portal의 글로벌 단축키 프로토콜이 사실상 KDE Plasma에서만 쓸만하고, Hyprland에서는 GUI 앱에서 못 쓰는 방식으로 구현됨. 많은 Wayland 컴포지터에선 아예 미구현
  • 이 글로벌 단축키 프로토콜이 Hyprland과 GNOME desktop portal 모두 크래시시킨 적 있음 (제작자가 Hyprland 쪽 수정 PR까지 날림)
  • 근본 철학 차이: X11은 "mechanism over policy" (단순하지만 강력한 기본 도구 제공), Wayland는 "policy over mechanism" (컴포지터 개발자가 의도한 것만 가능)
  • Wayland에서는 범용 소프트웨어를 만들 수 없고, 실질적으로 KWin/Wlroots/Mutter 중 특정 컴포지터 타겟으로 개발해야 함
  • Wayland 프로토콜 결정에 수년이 걸리는 반면 X11은 ~2개월이면 됨. 그 결과물도 덜 유연하고 구현 복잡도가 1000배 높다는 주장
  • 자기 Wayland 컴포지터를 만들어도, X11처럼 동작하게 만들어야 하니 결국 X11 서버 만드는 것과 다를 바 없음. 게다가 그 컴포지터에서만 동작하는 앱이 되어버림
  • Wayland 호환은 12to11 같은 브릿지 앱을 통해 지원할 예정

기술 스택

  • Zig 0.15.2 필요, libxkbcommon 의존
  • 백엔드: X11 (nested), Wayland (미지원), DRM (미지원) 선택 가능
  • 빌드: zig build -Doptimize=ReleaseSafe로 빌드

X11 vs Wayland 논쟁에서 실제 앱 개발자가 겪는 고통을 생생하게 보여주는 프로젝트. Wayland 전환이 늦어지는 진짜 이유를 이해하는 데 도움이 됨.

prev

이전 기사 (P)

next

다음 기사 (N)

댓글

댓글

댓글을 불러오는 중...

관련 기사

open-source

NIPA, 260명 규모 오픈소스 컨트리뷰션 아카데미 시작

정보통신산업진흥원이 2026 오픈소스 컨트리뷰션 아카데미 발대식을 열고 13주간의 프로젝트 활동을 시작했음. 국내 개발자들이 GitHub 기반 글로벌 협업 환경에서 코드, 문서, 버그 수정, 풀 리퀘스트를 직접 경험하게 하는 프로그램임.

open-source

그누보드7, 디딤과 손잡고 멀티클라우드 도입 문턱 낮춘다

에스아이알소프트가 클라우드 전문기업 디딤과 협력해 그누보드7 기반 웹서비스 구축·운영 환경을 넓히기로 했다. 커뮤니티, 쇼핑몰, 예약, 구독형 서비스 같은 실무 프로젝트에서 서버 구성과 운영 부담을 줄이는 게 핵심이다.

open-source

오픈소스 컨트리뷰션 아카데미 출범, 국내 개발자 260여 명 참여

정보통신산업진흥원이 2026 오픈소스 컨트리뷰션 아카데미 발대식을 열고 13주간의 활동을 시작했다. 11개 프로젝트팀의 멘토와 멘티 260여 명이 글로벌 오픈소스 프로젝트 기여를 목표로 코드 개발, 문서화, 오류 수정 등을 진행한다.

open-source

NIPA, 국내 개발자 260명 규모 오픈소스 컨트리뷰션 아카데미 시작

정보통신산업진흥원이 2026 오픈소스 컨트리뷰션 아카데미 발대식을 열고 국내 개발자의 글로벌 오픈소스 프로젝트 참여를 지원한다. 11개 프로젝트팀, 멘토·멘티 260여 명이 13주 동안 깃허브 기반 협업, 코드 리뷰, 문서화, 오류 수정 등을 실제로 경험한다.

open-source

Ghostty 엔진을 Emacs 안으로 끌고 온 터미널, Ghostel.el

Ghostel.el은 Ghostty의 libghostty-vt를 기반으로 Emacs 안에서 동작하는 터미널 에뮬레이터다. eat 스타일의 여러 입력 모드, 안정적인 복사 모드, line mode, 자동 password prompt 처리, compile-mode 유사 실행 버퍼, Kitty graphics 지원, 높은 throughput을 앞세워 eat/vterm과 차별화함.