Wayland와 컴포지터: X11과는 다른 설계

💡 한 줄 요약

• 이 글은 X11의 클라이언트-서버-윈도우매니저 3자 구도가 Wayland에서 클라이언트-컴포지터 2자 구도로 재편되는 이유와, Weston이 레퍼런스 컴포지터로서 하는 역할을 정리한다. (1부에서 다룬 X11 기초를 전제로 한다)

---

🚨 1. 이 글을 쓰는 이유 및 대상 독자 {#1}

• 동기: X11을 어느 정도 이해하고 나면 "Wayland는 그냥 최신 X11이다"라고 오해하기 쉽다. 실제로는 프로토콜 설계 철학 자체가 다르고, 특히 컴포지터라는 개념이 X11에는 없던 역할을 떠맡는다.
• 대상 독자: 1부(X11의 Display/Screen/$DISPLAY)를 읽었거나 X11 클라이언트-서버 구조를 이미 아는 상태에서, Wayland가 구조적으로 뭐가 다른지 궁금한 사람.

⚠️ 1부 리마인드 (3줄 요약)
X11은 하드웨어를 제어하는 X 서버, 창을 요청하는 X 클라이언트, 그리고 창 배치·포커스를 관리하는 윈도우 매니저(WM)까지 세 주체가 별도 프로세스로 통신하며 동작한다.

---

🛠️ 2. 사전 지식 & 개발 환경 {#2}

2.1 사전 지식

• 1부에서 다룬 X 클라이언트-서버 개념
• 윈도우 매니저(WM)가 X11에서 "특수한 클라이언트"로 동작한다는 사실

2.2 개발 환경

분류	기술 스택 / 도구	버전	비고
OS	Ubuntu	22.04 / 24.04	대부분의 배포판에서 동일
컴포지터	Weston	12.x / 13.x	Wayland 레퍼런스 컴포지터
확인 도구	weston-info, echo $WAYLAND_DISPLAY	-	실습에 사용

 

---

 

🔍 3. 핵심 개념: 3자 구도에서 2자 구도로 {#3}

X11의 구조를 다시 보면, 창 하나가 화면에 그려지기까지 세 프로세스가 관여한다.

 

X 서버는 "그림을 그리는 도화지"만 관리하고, 그 도화지 위에 창을 어디에 놓을지, 어떤 창이 활성화됐는지는 별도 프로세스인 WM이 X 서버에게 다시 요청해서 결정한다. 이 구조는 유연하지만, 세 프로세스 간 통신 왕복이 잦고 합성(compositing) 처리가 이원화되는 비효율이 있다.

Wayland는 이 구도를 아래처럼 단순화한다.

 

컴포지터가 X 서버 + 윈도우 매니저 + 컴포짓팅 관리자 세 역할을 한 프로세스로 통합한다. 클라이언트는 더 이상 "서버"에 그림을 요청하고 "WM"에게 배치를 맡기는 이원화된 통신을 하지 않는다. 클라이언트가 만드는 것은 surface라는 하나의 버퍼이고, 그 surface를 어디에 어떻게 그릴지는 전적으로 컴포지터가 결정한다.

---

🧪 4. 실습으로 확인하기 {#4}

# Wayland 세션인지 확인
echo $XDG_SESSION_TYPE
# wayland

# Wayland 소켓 확인 (X11의 /tmp/.X11-unix/X0 에 대응하는 개념)
echo $WAYLAND_DISPLAY
# wayland-0

ls -la /run/user/$(id -u)/
# srwxr-xr-x ... wayland-0

# Weston 컴포지터 정보 조회 (Weston 세션에서)
weston-info | head -20

 

X11의 $DISPLAY + /tmp/.X11-unix/X0 조합이, Wayland에서는 $WAYLAND_DISPLAY + /run/user/<uid>/wayland-0 조합으로 그대로 대응된다. 소켓 기반 통신이라는 기본 골격은 동일하고, 그 위에서 오가는 프로토콜 내용과 역할 분담이 다른 것이다.

---

🔬 5. 원인 분석: 컴포지터가 서버 역할까지 흡수한 이유 {#5}

 

X11에서는 각 클라이언트가 자기 창을 직접 화면에 그리고, 그 위에 다른 창이 겹치면 서버가 별도의 리페인트(damage/expose) 이벤트를 클라이언트에게 보내 "네 창이 가려졌으니 다시 그려라" 하는 방식이었다. 창이 많아질수록 이 왕복이 늘어나고, 화면 깜빡임(tearing)이나 지연이 생기기 쉬웠다.

Wayland는 애초에 모든 클라이언트가 자기 surface를 오프스크린 버퍼에만 그리고, 최종 합성(compositing)은 컴포지터가 한 번에 처리하도록 설계됐다. 클라이언트 입장에서는 "내가 그린 버퍼를 컴포지터에게 넘긴다"까지가 책임이고, 화면에 실제로 어떻게 배치·합성되는지는 신경 쓸 필요가 없다. 이 덕분에 통신 왕복이 줄고, 프레임 단위로 깔끔하게 합성되어 tearing이 구조적으로 방지된다.

즉 컴포지터가 서버 역할까지 흡수한 이유는 단순히 프로세스를 줄이기 위해서가 아니라, 합성 처리를 한 곳에 모아서 프레임 단위 원자성(atomicity)을 보장하기 위해서다.

---

💡 6. 흔한 오해 {#6}

• ❌ "Wayland는 X11의 업그레이드 버전이다" → 프로토콜 자체가 다르다. X11 위에 기능을 추가한 게 아니라 처음부터 다른 설계 철학(클라이언트는 그리기만, 배치·합성은 컴포지터가 전담)으로 새로 만들어졌다.
• ❌ "컴포지터 = 윈도우 매니저" → 컴포지터는 X11의 서버 역할(픽셀 관리, 소켓 통신)까지 포함한 상위 개념이다. WM 기능은 컴포지터가 흡수한 여러 역할 중 하나일 뿐이다.
• ❌ "Weston이 유일한 Wayland 컴포지터다" → Weston은 레퍼런스(표준 구현체) 성격이 강하고, 실제 데스크톱에서는 GNOME의 Mutter, KDE의 KWin 등 각자의 컴포지터를 쓴다.

---

🏁 7. 마무리 {#7}

7.1 결론

X11의 클라이언트-서버-WM 3자 구도는 Wayland에서 클라이언트-컴포지터 2자 구도로 단순화됐다. 이는 단순한 구조 축소가 아니라, 클라이언트는 surface를 그리는 데만 집중하고 배치·합성·출력을 컴포지터가 한 번에 원자적으로 처리하게 만들어 tearing과 통신 오버헤드를 구조적으로 줄이기 위한 설계다.

7.2 참고 자료

• Wayland 공식 문서
• Weston - Wayland 프로젝트 GitLab

7.3 다음 단계

3부: XWayland — Wayland 세션 안에서 X11 전용 앱이 어떻게 $DISPLAY와 소켓을 다시 만들어내며 동작하는지, 그리고 지금까지 다룬 X11/Wayland 개념이 실제 창 하나를 그리는 데 어떻게 맞물리는지 종합 정리