Wayland X11 비교: Linux 데스크톱 선택 가이드와 성능 체크

Wayland X11 비교는 요즘 Linux 데스크톱을 만지는 분들이 결국 한 번은 부딪히는 주제입니다. 같은 노트북, 같은 외부 모니터, 같은 브라우저를 써도 세션이 Wayland냐 X11이냐에 따라 느낌이 꽤 다르거든요. 어떤 날은 제스처와 스케일링이 아주 자연스럽고, 또 어떤 날은 화면 공유 하나 붙이자마자 워크플로가 흔들립니다. 겉으로는 둘 다 데스크톱이지만, 운영 관점에서 보면 장애 포인트가 분명히 다릅니다.

핵심은 단순한 신구 대결이 아닙니다. Wayland는 최신 Linux 데스크톱의 일상 사용감과 보안 모델에서 강점이 크고, X11은 도구 생태계와 자동화 호환성에서 여전히 강합니다. 문제는 많은 비교 글이 여기서 끝난다는 점이죠. 실제 운영에서는 “무엇이 더 현대적인가”보다 “내가 자주 쓰는 작업이 어디서 덜 깨지는가”가 더 중요하더라고요. 이 글은 그 기준으로 보겠습니다. 명령어, 로그, 설정 파일, 실패 모드, 선택 기준까지 실무적으로 정리해보겠습니다.

Wayland compositor와 X.Org server 구조 차이를 한눈에 보여주는 개요 이미지입니다.

1. Wayland X11 비교가 아직 중요한 이유

요즘 배포판은 Wayland를 기본 세션으로 제공하는 경우가 많습니다. GNOME은 Wayland 중심으로 다듬어졌고, KDE Plasma도 Wayland 완성도가 많이 올라왔죠. 그래서 겉보기에는 이미 승부가 끝난 것처럼 보일 수 있습니다. 그런데 실제로는 그렇지 않습니다. 데스크톱은 브라우저 창만 띄우는 환경이 아니라, 화면 공유, 캡처, 원격 접속, GUI 자동화, 멀티 모니터, 혼합 배율, 게임 런처, 오버레이, 입력기까지 다 엮인 운영 체계이기 때문입니다.

Wayland X11 비교에서 먼저 볼 건 FPS 하나가 아닙니다. 아래 네 가지가 더 중요합니다.

• 입력과 표시의 일관성: 스크롤, 제스처, 프랙셔널 스케일링, 티어링 억제
• 도구 호환성: 화면 녹화, 원격 제어, GUI 자동화, 컬러 피커, 오버레이
• 장애 분리 난이도: 문제가 세션 구조인지, 드라이버인지, 포털인지 빨리 구분되는가
• 보안 모델의 비용: 화면 접근을 막아 얻는 안전성과, 그 대가로 잃는 편의성

실무에서는 이 네 가지가 계속 충돌합니다. 예를 들어 Wayland는 앱이 다른 앱의 화면이나 입력에 임의로 접근하기 어렵게 설계돼 있어 보안상 유리합니다. 대신 예전 X11 방식에 기대던 캡처 도구나 매크로 도구는 여기서 막히기 쉽습니다. 반대로 X11은 도구가 잘 붙지만, 앱 간 경계가 느슨해서 “되는 게 많다”는 장점이 그대로 관리 포인트가 되기도 합니다.

2. Wayland와 X11 구조 차이: 어디서 문제가 생길까

디스플레이 서버를 교과서식으로 길게 볼 필요는 없습니다. 운영에 필요한 만큼만 잡고 가면 됩니다. 핵심은 입력과 화면 합성, 그리고 앱의 화면 접근 권한을 누가 쥐고 있느냐입니다.

Wayland 구조에서 생기는 특징

Wayland에서는 compositor가 중심입니다. GNOME의 Mutter, KDE의 KWin이 대표적이죠. 앱은 compositor와 직접 프로토콜을 주고받고, 오래된 X11 앱은 대개 XWayland를 통해 실행됩니다. 이 구조 덕분에 최신 노트북에서 제스처, 프랙셔널 스케일링, 모니터별 배율 같은 부분은 Wayland가 더 자연스럽게 느껴지는 경우가 많습니다. 노트북과 4K 외부 모니터를 함께 쓰는 환경에서도 이 차이가 먼저 체감되는 편입니다.

대신 비용도 분명합니다. Wayland는 “앱이 화면 전체를 마음대로 읽는다”는 오래된 전제를 기본값으로 허용하지 않습니다. 그래서 스크린샷, 화면 녹화, 원격 제어, 매크로 자동화가 포털(xdg-desktop-portal), PipeWire, compositor 구현에 더 의존합니다. 구조는 깔끔한데, 실제 운영에서는 확인해야 할 계층이 한 단계 바뀐 셈입니다.

X11 구조에서 생기는 특징

X11은 생태계가 넓고 역사가 길어서, 오래된 도구가 정말 많습니다. `xdotool`, 좌표 기반 클릭, 창 트리 조작, 구형 캡처 도구, 일부 원격 툴은 여전히 X11 전제를 깔고 있습니다. 이런 도구를 업무 핵심으로 쓰는 환경이라면 X11이 더 편할 때가 많습니다. GUI 회귀 테스트나 반복 입력 자동화가 필요한 장비에서 X11을 남겨두는 이유도 보통 여기 있습니다.

문제는 구성 편차입니다. X.Org server, window manager, compositor, 드라이버 설정이 조합에 따라 달라져서 같은 “X11”이라도 결과가 제각각일 수 있습니다. 특히 멀티 모니터, 혼합 DPI, 티어링 제어는 배포판 기본값과 compositor 설정 영향을 많이 받습니다. 그래서 X11은 익숙하고 유연하지만, 운영자가 책임져야 할 면적이 넓습니다.

로그인 화면에서 Wayland 세션과 X11 세션을 선택하는 흐름을 설명하는 이미지입니다.

3. Wayland X11 비교 전 확인: 지금 세션이 무엇인지 보는 방법

현장에서는 “분명 Wayland로 로그인한 줄 알았는데 아니었네”가 꽤 흔합니다. 로그인 화면의 문구만 믿지 말고, 실제 세션과 프로세스를 같이 보는 편이 안전합니다. 특히 원격 접속, GDM 설정, NVIDIA 드라이버 조합, 가상 환경에서는 생각보다 자주 엇나가거든요.

1차 확인: 세션 타입과 기본 환경 변수

echo "$XDG_SESSION_TYPE"
loginctl show-session "$XDG_SESSION_ID" -p Type -p Class -p Name -p Remote -p State
printf 'WAYLAND_DISPLAY=%s\nDISPLAY=%s\nXDG_CURRENT_DESKTOP=%s\n' \
  "$WAYLAND_DISPLAY" "$DISPLAY" "$XDG_CURRENT_DESKTOP"
ls -l "$XDG_RUNTIME_DIR"/wayland-* /tmp/.X11-unix 2>/dev/null

여기서는 이렇게 읽으면 됩니다.

1. `XDG_SESSION_TYPE=wayland`면 Wayland 세션, `x11`이면 X11 세션입니다.
2. `WAYLAND_DISPLAY`와 `DISPLAY`가 둘 다 잡혀 있어도 이상한 건 아닙니다. Wayland 세션 위에서 XWayland 앱을 함께 돌리면 흔한 상태입니다.
3. `Remote=yes`라면 로컬 콘솔 세션과 동작이 다를 수 있습니다. 이 경우 입력 지연이나 화면 공유 결과를 같은 기준으로 비교하면 오판하기 쉽습니다.

2차 확인: 실제 프로세스와 앱 백엔드

ps -e -o pid,comm | grep -E 'Xorg|Xwayland|gnome-shell|kwin_wayland|mutter|sway'
pgrep -a Xwayland
loginctl session-status "$XDG_SESSION_ID"

여기서 중요한 포인트가 하나 있습니다. `Xwayland`가 떠 있다고 해서 X11 세션이라는 뜻은 아닙니다. Wayland 세션에서 구형 X11 앱을 돌리기 위한 호환 레이어일 수 있습니다. 반대로 X11 세션에서는 `Xorg`가 중심으로 떠 있고, 앱 대부분이 `DISPLAY`를 통해 붙습니다.

앱 단위로 백엔드를 강제로 바꿔보는 것도 문제 분리에 꽤 유용합니다. 예를 들어 GTK 앱이 Wayland 네이티브로 돌 때만 이상하다면, 같은 앱을 X11 백엔드로 띄워 차이를 볼 수 있습니다. 이거 실제로 해보면 원인 분리가 꽤 빨라집니다.

GDK_BACKEND=x11 gedit
GDK_BACKEND=wayland gedit
QT_QPA_PLATFORM=xcb kate
QT_QPA_PLATFORM=wayland kate

세션 전체를 갈아엎지 않고도 “문제가 앱 백엔드인지, 세션 전체인지”를 빠르게 가를 수 있다는 점이 포인트입니다.

4. Wayland X11 성능 비교: 숫자보다 패턴을 봐야 하는 이유

Wayland X11 비교에서 가장 흔한 실수는 “게임 FPS가 비슷하니 차이 없다” 혹은 “스크롤이 부드러우니 Wayland가 무조건 낫다” 식으로 단정하는 겁니다. 데스크톱 성능은 단일 수치로 설명하기 어렵습니다. 실제로는 아래 다섯 가지를 같이 봐야 판단이 덜 흔들립니다.

• 입력 지연: 클릭, 스크롤, 제스처가 즉시 반응하는가
• 프레임 일관성: 창 이동, 워크스페이스 전환, 전체화면 전환에서 끊김이 반복되는가
• 티어링과 깜빡임: 특히 외부 모니터, VRR, 혼합 주사율 환경에서 재현되는가
• 스케일링 품질: 100%와 150% 모니터를 섞었을 때 글자와 커서가 어색하지 않은가
• 도구 부하: 화면 공유, 녹화, 오버레이를 붙였을 때 compositor나 Xorg가 비정상적으로 치솟는가

현장에서 느끼는 차이는 대체로 이렇습니다.

• Wayland 장점: 최신 GNOME/KDE 기준으로 입력과 화면 합성의 일관성이 좋고, 혼합 DPI 환경에서 덜 거슬리는 경우가 많습니다.
• X11 장점: 오래된 도구와 API가 잘 붙어서 우회 없이 바로 되는 일이 많습니다.
• Wayland 주의점: 문제가 생기면 앱 자체보다 portal, PipeWire, compositor, 드라이버 층을 같이 봐야 해서 진단이 한 단계 더 필요합니다.
• X11 주의점: 잘 되는 대신 설정 편차가 커서, 장비나 모니터 조합이 바뀌면 다른 종류의 스트레스를 받기 쉽습니다.

로그와 리소스로 보는 기본 점검

pids=$(pgrep -d',' -x gnome-shell -x kwin_wayland -x Xorg -x Xwayland)
[ -n "$pids" ] && top -H -p "$pids"
journalctl -b --no-pager | grep -Ei 'wayland|xorg|xwayland|mutter|kwin|drm|amdgpu|nvidia|nouveau|i915|intel'
journalctl --user -b --no-pager | grep -Ei 'pipewire|portal|screencast|wireplumber'

숫자를 볼 때도 해석 기준이 있어야 합니다.

• 유휴 상태에서 compositor CPU가 계속 높으면 확장 기능, 화면 녹화, 오버레이, 브라우저 가속, 잘못된 VRR 조합을 먼저 의심합니다.
• `drm`, `amdgpu`, `nvidia`, `i915` 관련 경고가 반복되면 세션 종류보다 드라이버 문제가 더 상위 원인일 수 있습니다.
• 화면 공유를 켜는 순간부터 문제가 시작되면 Wayland 자체를 탓하기 전에 `xdg-desktop-portal`과 `PipeWire` 상태부터 보는 편이 정확합니다.
• 문제가 창 전환이나 전체화면 진입 때만 터진다면 compositor 설정이나 주사율 협상 쪽일 가능성이 큽니다.

Wayland가 빠르다, X11이 안정적이다 같은 문장은 반만 맞습니다. 실제로는 “어떤 작업에서, 어떤 드라이버와 compositor 조합으로, 어떤 도구를 붙였을 때 덜 깨지느냐”가 답에 더 가깝습니다.

5. 실전 테스트 시나리오: 세션 교체 전에 꼭 해볼 체크리스트

막연하게 감으로 고르지 말고, 같은 작업을 양쪽 세션에서 재현해보는 게 가장 정확합니다. 아래 순서는 장애 분리에도 잘 맞습니다.

1. 로그인 화면에서 Wayland 세션과 X11 세션을 각각 선택합니다.
2. 같은 외부 모니터, 같은 전원 상태, 같은 주사율, 같은 브라우저 탭 수로 맞춥니다.
3. 창 여러 개 이동, 워크스페이스 전환, 전체화면 전환, 스크린샷, 화면 녹화, 원격 접속, 동영상 재생을 반복합니다.
4. 세션별로 `journalctl -b`와 사용자 저널을 따로 저장해 비교합니다.
5. 문제가 앱 전체인지 특정 앱인지 보려고 같은 앱을 Wayland/X11 백엔드로 각각 띄워봅니다.

이때 많이 놓치는 게 하나 있습니다. 같은 앱이라도 내부 백엔드가 다를 수 있다는 점입니다. 브라우저 화면 공유는 portal 경로를 타고, 구형 녹화 도구는 X11 API를 기대하고, Electron 앱은 버전과 패키징에 따라 Wayland 처리 방식이 다를 수 있습니다. 그래서 “브라우저는 괜찮은데 녹화 도구만 안 된다” 같은 결과가 생깁니다.

테스트 결과를 남길 때는 감상보다 조건을 적어두는 편이 훨씬 좋습니다. 예를 들어 “Wayland가 더 부드러움”보다 “Wayland 세션 + 외부 4K 150% + 브라우저 화면 공유 켠 상태에서는 정상, X11 세션에서는 전체화면 전환 시 깜빡임 재현”처럼 기록해야 다음 장애 대응이 빨라집니다. 이런 식으로 써두면 나중에 진짜 큰 도움이 됩니다.

세션 타입 확인과 로그 점검 명령어를 실행하는 실제 운영 흐름을 보여주는 이미지입니다.

6. 트러블슈팅: Wayland와 X11에서 자주 만나는 문제

이 섹션은 “왜 안 되지?”에서 끝나지 않도록 원인 층위를 같이 적겠습니다. 같은 증상이어도 뿌리가 다르면 해법도 달라집니다.

문제 1. Wayland에서 스크린샷·화면 녹화·화면 공유가 들쭉날쭉하다

이건 대개 Wayland의 보안 모델과 portal 경로 이해가 부족해서 생깁니다. Wayland에서는 앱이 화면 전체를 직접 읽는 방식이 기본값이 아닙니다. 대신 데스크톱 포털과 PipeWire가 중간에서 권한과 스트림을 다룹니다. 예전처럼 앱이 바로 가져가는 구조가 아니라는 점이 핵심입니다.

systemctl --user status pipewire wireplumber xdg-desktop-portal \
  xdg-desktop-portal-gnome xdg-desktop-portal-kde
journalctl --user -b -u pipewire -u wireplumber -u xdg-desktop-portal --no-pager
busctl --user tree org.freedesktop.portal.Desktop 2>/dev/null | head

여기서 보는 기준은 단순합니다.

• 포털 서비스가 아예 안 떠 있으면 화면 공유가 불안정하거나 시작조차 안 될 수 있습니다.
• GNOME 환경인데 KDE용 포털만 살아 있거나, 반대로 KDE 환경에 GNOME 포털만 섞여 있으면 선택 창이 이상하거나 캡처 경로가 꼬일 수 있습니다.
• 문제가 특정 앱에서만 나면 앱이 portal 경로를 제대로 쓰는지, 패키지 형태(Flatpak, Snap, distro package) 차이도 같이 봐야 합니다.

이 경우 Wayland 자체를 포기하기보다 먼저 portal 계층부터 바로잡는 편이 낫습니다. 원인이 세션이 아니라 사용자 세션 서비스인 경우가 생각보다 많거든요.

문제 2. X11에서는 되던 `xdotool`·매크로·좌표 클릭 자동화가 Wayland에서 안 된다

이건 버그라기보다 설계 차이에 가깝습니다. X11은 앱 간 입력 주입과 창 조작이 넓게 허용되어 왔고, Wayland는 그 가정을 기본값으로 인정하지 않습니다. 그래서 GUI 자동화가 핵심인 장비라면 Wayland에 억지로 맞추는 것보다 X11 세션을 남겨두는 편이 현실적입니다.

이 상황에서는 기준을 명확히 잡는 게 좋습니다.

• 사무용 개인 데스크톱: Wayland 우선
• 테스트 자동화용 데스크톱: X11 유지
• 업무 앱이 하나라도 X11 전용 도구에 깊게 묶여 있음: X11 우선 검토

“최신이니까 옮긴다”는 판단이 제일 비쌀 때가 많습니다. 바꾸고 나서 자동화 파이프라인이 흔들리면 되돌리는 비용이 더 크거든요.

문제 3. 멀티 모니터에서 배율, 커서, 전체화면 전환이 어색하다

이 문제는 단순히 Wayland가 낫다, X11이 낫다로 자르기 어렵습니다. 다만 혼합 DPI 환경에서는 Wayland가 더 덜 거슬리는 편이라는 평가가 많습니다. 반대로 X11은 모니터별 스케일링이 깔끔하지 않거나, 특정 조합에서 티어링 제어가 설정 의존적인 경우가 있습니다.

체크할 때는 세션 종류만 보지 말고, 도구도 구분해서 보셔야 합니다. 아래 명령은 환경에 따라 일부만 설치돼 있을 수 있습니다.

xrandr --listmonitors 2>/dev/null
xrandr --query 2>/dev/null
wlr-randr 2>/dev/null
kscreen-doctor -o 2>/dev/null

`xrandr`는 X11 쪽 확인에는 유용하지만 Wayland 전체를 대표하지는 않습니다. Wayland에서는 compositor별 도구가 갈립니다. 그래서 GNOME, KDE, wlroots 계열이 같은 방식으로 보이지 않는다고 해서 이상한 건 아닙니다. 여기서 많이 헷갈립니다.

문제 4. NVIDIA 환경에서 로그인 세션이 기대와 다르게 올라온다

이건 배포판, 디스플레이 매니저, 드라이버 조합 영향을 많이 받습니다. 여기서 중요한 건 소문이 아니라 실제 세션 타입입니다. 로그인 화면 메뉴에 Wayland처럼 보여도 실제로는 X11로 오른 경우가 있고, 반대도 있습니다. 그래서 반드시 로그인 후 `echo $XDG_SESSION_TYPE`와 `loginctl show-session`으로 확인하는 편이 안전합니다.

GNOME 계열에서 GDM이 Wayland를 비활성화했는지 점검할 때는 보통 아래 파일을 봅니다. 다만 배포판에 따라 경로와 기본값은 조금 다를 수 있습니다.

grep -nE '^[# ]*WaylandEnable=' /etc/gdm/custom.conf 2>/dev/null
grep -nE '^[# ]*DefaultSession=' /etc/gdm/custom.conf 2>/dev/null

`WaylandEnable=false`가 있으면 GDM에서 Wayland가 비활성화돼 Xorg 세션으로 기울 수 있습니다. 물론 이 파일 하나로 모든 경우가 설명되지는 않지만, “왜 계속 X11로만 뜨지?” 할 때 가장 먼저 볼 만한 지점입니다.

문제 5. 원격 제어는 되는데 화면 공유만 불안정하거나, 반대로 공유는 되는데 입력 전달이 이상하다

이 경우 세션보다 원격 도구가 무엇을 전제로 설계됐는지를 먼저 보는 편이 맞습니다. X11 전용 방식에 기대는 도구는 Wayland에서 입력 주입이 제한될 수 있고, Wayland 친화적인 도구는 portal/PipeWire가 정상일 때 훨씬 깔끔하게 동작하기도 합니다. 원격 업무 비중이 높다면, 세션 선택 전에 쓰는 도구 목록부터 적어두고 지원 범위를 확인하는 게 훨씬 현실적입니다.

7. 검증과 결과 확인: 무엇이 잘 된 상태인가

세션을 바꾸고 “대충 되는 것 같네요”로 끝내면 다시 같은 장애를 만납니다. 아래 기준을 통과해야 정상으로 보는 편이 안전합니다.

• 세션 타입이 의도한 값으로 일관되게 올라온다.
• 브라우저 화면 공유, 스크린샷, 녹화가 같은 절차로 반복 재현된다.
• 창 이동, 전체화면 전환, 외부 모니터 hotplug 시 깜빡임이나 멈춤이 반복되지 않는다.
• `journalctl -b`와 `journalctl –user -b`에 같은 그래픽/portal 오류가 누적되지 않는다.
• X11 전용 앱은 XWayland 또는 X11 세션에서 예측 가능한 방식으로 동작한다.

운영 검증용으로는 이런 식의 미니 점검 스크립트도 자주 씁니다. 새 장비나 배포판을 올린 뒤 결과를 남기기 좋아요.

echo "session=$XDG_SESSION_TYPE desktop=$XDG_CURRENT_DESKTOP"
loginctl show-session "$XDG_SESSION_ID" -p Type -p Remote -p State
ps -e -o comm | grep -E 'Xorg|Xwayland|gnome-shell|kwin_wayland' || true
systemctl --user --no-pager --full status pipewire xdg-desktop-portal | sed -n '1,20p'
journalctl --user -b --no-pager | grep -Ei 'portal|pipewire|screencast' | tail -n 20

실제로 써보면 Wayland는 “평소 데스크톱 사용감”이 좋고, X11은 “도구가 예상대로 움직이는 범위”가 넓습니다. 어느 쪽이든 로그가 조용하고, 자주 쓰는 워크플로가 재현 가능하게 유지되는 쪽이 오래 갑니다.

세션 종류, 로그 상태, 화면 공유, 멀티 모니터 안정성을 검증하는 결과 요약 이미지입니다.

8. 선택 가이드: 이런 경우엔 Wayland, 이런 경우엔 X11

여기서는 애매하게 말하지 않겠습니다. 실제 선택 기준이 있어야 운영이 편합니다. 아래 표는 Linux 데스크톱을 세팅할 때 바로 써먹기 좋은 판단표입니다.

정리하면 선택 기준은 꽤 분명합니다.

• 개인용 Linux 노트북이나 일반 데스크톱이면 Wayland부터 시작하는 편이 맞습니다.
• 업무 핵심이 GUI 자동화, 특수 원격 도구, 오래된 캡처 툴이라면 X11을 기본값으로 두는 편이 덜 피곤합니다.
• 둘 중 하나로 못 박기 어렵다면, 로그인 화면에서 두 세션을 모두 선택 가능하게 남겨두는 게 좋습니다. 장애 대응 속도가 꽤 달라집니다.

관련 글로 Linux 디스플레이 트러블슈팅 가이드도 함께 보시면 원인 분리가 훨씬 빨라집니다.

사용자 유형별로 Wayland와 X11 중 어떤 선택이 더 맞는지 요약한 이미지입니다.

9. 마무리: 운영 리스크 기준으로 고르면 덜 흔들립니다

데스크톱도 결국 “취향”보다 “재현 가능한 안정성”으로 봐야 합니다. 새 기술이라고 무조건 옮기면 다른 층위의 장애를 떠안을 수 있고, 익숙한 방식만 고집하면 현대 하드웨어의 장점을 놓칠 수도 있습니다. Wayland와 X11도 정확히 그 구도입니다.

일반적인 Linux 데스크톱, 노트북, 멀티 모니터, 최신 GNOME/KDE라면 Wayland를 먼저 써보는 편이 좋습니다. 입력과 스케일링, 일상 사용감, 보안 모델까지 종합하면 장점이 분명하거든요. 대신 화면 녹화, 원격 제어, GUI 자동화, 구형 업무 앱이 핵심이라면 X11을 유지하는 편이 더 합리적입니다. 이건 보수적인 선택이라기보다, 장애 비용을 줄이는 선택에 가깝습니다.

결국 기준은 단순합니다. 평소 작업이 더 부드러운 쪽이 아니라, 자주 쓰는 워크플로가 덜 깨지는 쪽을 고르면 됩니다. Wayland X11 비교에서 이 기준만 놓치지 않으면, 괜한 종교전 없이 자기 환경에 맞는 답을 찾기 쉬워집니다.

FAQ

Wayland가 무조건 더 빠른가요?

아닙니다. 최신 데스크톱에서 입력과 스케일링 체감이 좋은 경우가 많지만, 실제 운영 만족도는 compositor, 드라이버, portal, 앱 호환성에 따라 달라집니다.

X11은 이제 완전히 버려도 되는 기술인가요?

그렇게 보긴 어렵습니다. 레거시 도구, GUI 자동화, 특정 원격 제어, 오래된 업무 앱에서는 여전히 실용적입니다. 업무가 거기에 걸려 있다면 X11이 더 좋은 선택일 수 있습니다.

무엇부터 점검하면 가장 덜 헤맬까요?

`echo $XDG_SESSION_TYPE`, `loginctl show-session`, 프로세스 확인, portal/PipeWire 상태, 같은 작업의 교차 재현 테스트 순서로 보면 됩니다. 이 순서가 세션 문제와 드라이버 문제를 분리하는 데 꽤 유용합니다.