XWayland: 두 세계를 잇는 다리, 그리고 종합 정리

💡 한 줄 요약

• 이 글은 Wayland 세션에서 X11 전용 앱이 동작할 수 있게 해주는 XWayland의 내부 원리와, $DISPLAY·소켓이 이 상황에서 다시 등장하는 이유를 정리한다. 마지막으로 1부(X11)와 2부(Wayland/컴포지터)의 개념을 하나의 다이어그램으로 종합한다.

---

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

• 동기: Wayland 데스크톱을 쓰면서도 echo $DISPLAY를 치면 여전히 :1 같은 값이 나오는 걸 보고 의아했던 적이 있다면, 그 답이 XWayland다. Wayland로 완전히 전환됐다고 생각했는데 X11 개념이 다시 튀어나오는 이유를 이 글에서 다룬다.
• 대상 독자: 1부(X11), 2부(Wayland/컴포지터)를 읽고, 두 세계가 실제로 어떻게 공존하는지 궁금한 사람.

⚠️ 1부·2부 리마인드
X11은 클라이언트-서버-WM 3자 구도로, $DISPLAY가 /tmp/.X11-unix/X<N> 소켓 주소를 가리킨다. Wayland는 클라이언트-컴포지터 2자 구도로, $WAYLAND_DISPLAY가 /run/user/<uid>/wayland-<N> 소켓을 가리킨다.

---

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

2.1 사전 지식

• 1부의 X11 클라이언트-서버-소켓 구조
• 2부의 Wayland 클라이언트-컴포지터 구조

2.2 개발 환경

분류	기술 스택 / 도구	버전	비고
OS	Ubuntu	22.04 / 24.04	GNOME(Mutter) 기본 Wayland 세션
XWayland	Xwayland	22.x / 23.x	대부분 Wayland 컴포지터에 내장
확인 도구	xlsclients, xeyes, ps	-	실습에 사용

---

🔍 3. 핵심 개념: XWayland는 무엇을 흉내 내는가 {#3}

XWayland는 별도의 "변환기"가 아니라, Wayland 컴포지터가 실행하는 특수한 Wayland 클라이언트이면서 동시에 진짜 X 서버 역할을 하는 프로세스다.

동작 순서로 풀어보면 이렇다.

1. XWayland가 시작되면서 진짜 X 서버처럼 /tmp/.X11-unix/X<N> 소켓을 만들고 $DISPLAY 값을 설정한다.
2. X11 전용 앱(xeyes 등)은 자신이 진짜 X11 환경에 있다고 믿고, 1부에서 다룬 것과 완전히 동일한 방식으로 이 소켓에 접속해 X11 프로토콜로 통신한다.
3. XWayland는 이 X11 요청을 받아서, 내부적으로 Wayland 클라이언트가 되어 자기 자신이 컴포지터에게 surface를 요청하는 것으로 변환한다.
4. 최종 렌더링은 2부에서 다룬 Wayland 합성 경로를 그대로 탄다.

즉 X11 앱 입장에서는 XWayland가 진짜 X 서버이고, 컴포지터 입장에서는 XWayland가 그냥 하나의 (약간 특별한) Wayland 클라이언트다. 이 이중 신분이 XWayland의 핵심이다.

---

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

# Wayland 세션인데도 $DISPLAY가 존재하는지 확인
echo $XDG_SESSION_TYPE
# wayland
echo $DISPLAY
# :1  (XWayland가 만든 값, 보통 :0이 아닌 :1 이후 번호)

# XWayland 프로세스 확인
ps aux | grep -i xwayland
# /usr/bin/Xwayland :1 -rootless ...

# XWayland 소켓도 실제로 생성되어 있는지 확인
ls -la /tmp/.X11-unix/
# X1  (XWayland가 만든 소켓)

# X11 전용 앱을 실행해서 XWayland를 거치는지 확인
xeyes &
xlsclients
# xeyes가 X 클라이언트 목록에 나타남 — XWayland가 X 서버 역할을 하고 있다는 증거

 

-rootless 옵션이 핵심이다. 전통적인 X 서버는 화면 전체를 자기 것으로 소유하지만, XWayland는 "루트 없이(rootless)" 동작해서 각 X11 창을 독립된 Wayland surface로 컴포지터에 등록한다. 그 결과 X11 앱 창도 다른 네이티브 Wayland 앱 창과 똑같이 섞여서 배치된다.

---

🔬 5. 원인 분석: X11 경로 vs Wayland+XWayland 경로 {#5}

두 경로를 나란히 놓고 비교하면 왜 XWayland가 "다리" 역할을 하는지 명확해진다.

 

 

1부에서 봤던 "클라이언트가 $DISPLAY를 읽고 소켓에 접속한다"는 흐름은 XWayland 구간까지는 X11과 완전히 동일하다. 다른 점은 그 다음, XWayland가 요청을 그대로 하드웨어에 넘기는 게 아니라 2부에서 본 Wayland 클라이언트-컴포지터 흐름으로 한 번 더 감싸서 전달한다는 것이다.

이 구조 덕분에 두 가지가 동시에 성립한다.

• X11 전용 앱은 코드를 한 줄도 안 고쳐도 그대로 실행된다 (하위 호환성).
• 최종 렌더링·합성은 여전히 컴포지터가 원자적으로 처리한다 (Wayland의 이점 유지).

---

💡 6. 흔한 오해 {#6}

• ❌ "XWayland가 있으면 X11은 완전히 안 쓰이는 것이다" → XWayland 자체가 실제로 X 서버 프로토콜을 구현하고 /tmp/.X11-unix 소켓을 만든다. X11 프로토콜은 여전히 그 구간에서 그대로 쓰인다. 다만 최종 출력 경로만 Wayland로 우회할 뿐이다.
• ❌ "XWayland는 모든 배포판에 기본 설치된다" → 대부분의 데스크톱 환경(GNOME, KDE)은 기본 포함하지만, 최소 설치나 임베디드 이미지에서는 별도 패키지(xwayland)를 설치해야 하는 경우가 많다.
• ❌ "XWayland를 쓰면 성능이 항상 떨어진다" → 변환 오버헤드가 이론적으로 존재하지만, -rootless 방식과 하드웨어 가속 버퍼 공유 덕분에 일반적인 사용에서는 체감 차이가 크지 않다. 다만 저사양 임베디드 환경에서는 네이티브 Wayland 앱 대비 약간의 오버헤드가 측정될 수 있다.

---

🏁 7. 마무리 {#7}

7.1 종합: 창 하나가 그려지기까지

세 편에 걸쳐 다룬 개념을 하나로 모으면 다음과 같다.

• 1부에서 다룬 Display·Screen·$DISPLAY·소켓은 경로 A와, XWayland가 만드는 경로 C의 앞부분에 그대로 적용된다.
• 2부에서 다룬 컴포지터의 2자 구도는 경로 B와, 경로 C의 뒷부분(XWayland → 컴포지터)에 적용된다.
• 3부의 XWayland는 이 두 경로를 이어붙이는 어댑터로, X11 앱이 인지하는 세계(경로 A의 앞부분)와 실제 화면에 그려지는 세계(경로 B의 뒷부분)를 연결한다.

7.2 결론

$DISPLAY, 소켓, 클라이언트-서버라는 X11의 개념은 XWayland를 통해 Wayland 시대에도 그대로 재사용된다. 다만 최종 합성·출력은 항상 컴포지터가 담당하도록 감싸져 있다는 점이 X11 네이티브 환경과의 결정적 차이다.

7.3 참고 자료

• XWayland - freedesktop.org 문서
• Xwayland 매뉴얼 페이지 (man Xwayland)