Wayland에서의 텍스트 확장: 왜 작동하지 않고, 실제로 무엇이 통하는가
간단한 답변: 텍스트 확장기는 시스템 전체의 모든 키 입력을 감시하고, 포커스가 있는 앱에 입력을 시뮬레이션해야 합니다. X11은 기본적으로 둘 다 허용했지만, Wayland의 컴포지터는 보안상의 이유로 둘 다를 의도적으로 제한합니다. 그래서 Ubuntu 20.04에서는 완벽하게 작동하던 텍스트 확장기가 최신 Wayland 세션에서는 오류 메시지 하나 없이 깔끔하게 설치되고도 아무 일도 하지 않을 수 있습니다. 단일한 해결책은 없습니다. 실제 선택지는 XWayland(호환 레이어 안에서 예전 방식으로 실행), input-group에 명시적으로 접근하는 evdev/uinput 백엔드, 또는 일회성 권한 부여를 요청하는 전용 저수준 입력 백엔드입니다. Lightning Assist는 마지막 방식을 사용합니다.
텍스트 확장기를 설치하고 트리거를 입력했는데 아무 일도 일어나지 않았다면 — 오류도, 충돌도 없이 그냥 조용하다면 — 십중팔구 Wayland를 사용 중인 것이며, 이는 선택한 도구만의 버그가 아니라 잘 알려진 유형의 문제입니다.
Wayland가 전역 키 감시를 차단하는 이유
X11에서는 어떤 프로세스든 저수준 키보드 훅을 등록해 시스템의 모든 키 입력을 읽을 수 있고, 어떤 프로세스든 현재 포커스가 있는 창에 키 입력을 시뮬레이션할 수 있습니다 — xdotool 같은 도구가 하는 일이 정확히 이것이며, 텍스트 확장기, 핫키 매니저, 원격 제어 소프트웨어가 20년 동안 Linux에서 큰 마찰 없이 작동해 온 이유이기도 합니다. 동시에 보안 관점에서 보면 이는 기본값으로는 절대 원치 않을 만한 것이기도 합니다. 침해당한 앱을 포함해 어떤 애플리케이션이든 키 입력을 기록하거나 은행 세션에 임의의 입력을 주입할 수 있기 때문입니다.
Wayland의 컴포지터(GNOME의 Mutter, KDE Plasma의 KWin, Sway 등에서 쓰이는 wlroots 기반 컴포지터)는 정반대의 기본값을 전제로 설계되었습니다. 애플리케이션은 오직 자기 창으로 향하는 입력 이벤트만 볼 수 있고, 명시적이고 의도적인 메커니즘 없이는 다른 애플리케이션에 합성 입력을 주입할 수 없습니다. 이는 실수나 누락된 기능이 아니라, 보안 모델이 의도한 대로 작동하는 것입니다. 그 대가로, X11의 "어떤 프로세스든 감시하고 주입할 수 있다"는 동작에 의존했던 모든 도구는 같은 일을 하기 위해 다르고, 대개는 더 제한적인 방법이 필요합니다.
실질적인 결과는 이렇습니다. X11 방식으로 키 입력을 훅하는 텍스트 확장기는 순수한 Wayland 세션에서 아무것도 보지 못하고, X11 방식으로 텍스트를 주입하는 텍스트 확장기는 주입할 대상 자체가 없습니다. 명확한 오류 대신 보통 조용히 실패합니다. 예외가 발생하는 게 아니라, 감시하던 이벤트가 애초에 전혀 도착하지 않기 때문입니다.
브라우저 확장 프로그램이 데스크톱 전체를 커버하지 못하는 이유
자연스러운 우회책은 브라우저 확장 프로그램 기반 텍스트 확장기이며, 브라우저 탭 안에서만큼은 실제로 작동합니다 — 확장 프로그램은 페이지의 DOM 안에서 동작하므로 Wayland의 입력 모델과는 무관하기 때문입니다. 문제는 범위입니다. 확장 프로그램은 설치된 브라우저만 볼 수 있습니다. 터미널, IDE, 네이티브 GTK나 Qt 애플리케이션, Slack이나 Discord의 데스크톱 클라이언트, PDF 리더에서는 스니펫을 확장할 수 없습니다. 하루 일과에 브라우저 탭 밖의 작업이 포함된다면 — 개발자와 지원팀에게는 그것이 하루의 대부분일 텐데 — 브라우저 확장 프로그램은 문제의 일부만 해결하고 나머지 데스크톱은 그대로 남겨둡니다.
현재 Wayland에 실제로 존재하는 방법들
만능 해결책은 없지만, 각각 트레이드오프가 있는 실질적이고 문서화된 접근법 몇 가지가 있습니다.
XWayland — 호환 레이어 안에서 예전 방식으로 실행하기
대부분의 Wayland 데스크톱 환경(GNOME, Ubuntu 22.04+ 및 Fedora 38+ 등에서 기본 제공되는 KDE Plasma 등)은 네이티브 Wayland 컴포지터와 함께 XWayland를 실행합니다 — X11 전용 애플리케이션이 계속 작동하도록 해주는 호환 레이어입니다. X11 입력 훅 위에 구축된 도구는 XWayland 안에서 실행되는 애플리케이션에 대해서는 계속 작동합니다. 함정은 범위입니다. XWayland가 명시적으로 비활성화된 세션(일부 강화된 GNOME 구성)에 있거나, 입력 대상 애플리케이션이 XWayland가 아니라 네이티브 Wayland 클라이언트라면 X11 방식의 훅은 거기까지 닿지 않습니다.
zwp_virtual_keyboard_v1 프로토콜
GNOME의 Mutter와 KDE의 KWin을 포함한 일부 Wayland 컴포지터는 zwp_virtual_keyboard_v1 Wayland 프로토콜을 구현하는데, 이는 애플리케이션에 키보드 이벤트를 시뮬레이션할 수 있는 공인된 방법을 제공합니다. 이는 우회책이라기보다 내장된 프로토콜 수준의 해법에 가깝지만 컴포지터에 의존적입니다. 이를 사용하는 앱은 해당 컴포지터가 그 프로토콜을 구현하기로 선택한 곳에서만 작동하며, 동작이 여전히 달라질 수 있습니다 — 일부 환경에서는 클립보드 붙여넣기 방식으로 대체되는데, 이는 특수한 붙여넣기 처리를 하는 앱(예: bracketed-paste 모드를 쓰는 터미널)에서 다르게 동작할 수 있습니다.
xdg-desktop-portal의 RemoteDesktop 인터페이스
freedesktop.org의 portal 사양은 "데스크톱 세션의 원격 제어를 허용"하기 위해 명시적으로 만들어진 RemoteDesktop 인터페이스를 정의합니다 — 키보드와 포인터 이벤트를 주입할 수 있지만, 세션이 시작될 때 사용자가 KEYBOARD/POINTER 접근 권한을 부여한 뒤에만 가능하며, 상시 작동하는 시스템 훅이 아니라 권한 범위가 지정된 세션 메커니즘입니다. 이는 Wayland가 입력 주입을 위해 마련한 공인된 통로이지만, 원래 원격 제어와 화면 공유 도구를 염두에 두고 설계된 것이지, 텍스트 확장기가 실제로 필요로 하는 "백그라운드에서 내가 입력하는 모든 트리거를 영원히 조용히 감지하는" 용도로 설계된 것이 아닙니다.
input-group 접근 권한을 활용한 evdev/uinput
더 낮은 수준의 방법은 /dev/input(evdev)에서 원시 입력을 직접 읽고 /dev/uinput을 통해 합성 이벤트를 주입해서, 컴포지터의 입력 모델을 아예 우회하는 것입니다. 이는 진정한 의미에서 컴포지터에 구애받지 않습니다 — GNOME이든 KDE든 Sway든 상관없이 이들 모두보다 아래인 커널 입력 계층에서 동작하기 때문입니다. Espanso는 자사 문서에서 "현재 실험적"이라고 설명하는 Wayland 지원에 정확히 이 방식을 사용합니다. root로 실행하지 않고 원시 입력을 읽으려면 바이너리에 일회성 setcap cap_dac_override+p 권한을 부여(또는 설정에 따라 input 그룹 소속)해야 하며, 알려진 주의사항도 있습니다 — 미국식이 아닌 키보드 레이아웃은 별도 설정이 필요하고, GNOME 세션에서는 클립보드 백엔드 깜빡임이 나타날 수 있으며, 새 키보드를 연결하면 서비스를 수동으로 재시작해야 합니다. 작동은 하지만, 현재 상태를 표현하기에는 "실험적"이라는 표현이 정확합니다.
Wayland를 아예 지원하지 않는 도구들
일부 Linux 자동화 도구는 xdotool과 X11 창 트리 위에 직접 구축되어 Wayland 경로가 전혀 없습니다 — AutoKey가 가장 명확한 예입니다. X11 전용이며, 입력 시뮬레이션이 컴포지터가 아니라 X11 창 트리를 직접 대상으로 하기 때문에 XWayland도 도움이 되지 않습니다. 순수한 Wayland 세션에 있다면, 이런 도구는 설정과 무관하게 그냥 작동하지 않습니다.
Lightning Assist는 이를 어떻게 처리하는가
Lightning Assist는 세션 유형에 따라 두 가지 경로를 사용합니다. X11 세션과 XWayland 세션에서는 표준 X11 입력 훅을 사용합니다 — 수년간 Linux에서 안정적으로 작동해 온 것과 동일한 메커니즘입니다. 순수한 Wayland 세션에서는 전용 저수준 입력 백엔드로 전환합니다. 처음 필요할 때 앱이 한 번 입력 접근 권한을 요청하고("Grant access" 프롬프트), 그 한 번의 승인 후에는 GNOME, KDE, 기타 컴포지터 전반에서 전역 키 감지와 텍스트 확장이 동일하게 작동합니다 — YAML도 없고, 직접 실행해야 할 setcap 명령도 없고, 키보드 레이아웃별 설정 단계도 없습니다. 이는 나중에 덧붙인 대체 수단이 아니라 이 목적을 위해 유지·관리되는 백엔드이며, 일회성 승인 모델 덕분에 세션마다 수동 단계를 반복할 필요가 없습니다.
도구를 선택하기 전에 확인할 실용적 체크리스트
도구마다 이렇게 차이가 크다는 점을 감안하면, Wayland 데스크톱에서 하나를 선택하기 전에 몇 가지를 확인해 볼 가치가 있습니다.
- Wayland 지원을 명시적으로 문서화하고 있는가, 아니면 그냥 "Linux 지원"이라고만 폭넓게 주장하는가? 포괄적인 주장은 흔히 "X11에서 테스트됨"을 의미하며 Wayland에서의 동작은 검증되지 않았을 수 있습니다.
- Wayland에서 작동하려면 수동
setcap이나 root 권한 단계가 필요한가? 결정적인 단점은 아니지만, 설치 후에 알게 되기보다는 미리 알아두어야 할 사항입니다. - "Wayland에서 작동함"이라고 뭉뚱그리기보다 특정 컴포지터(GNOME, KDE, Sway)의 주의사항을 구체적으로 명시하는가? 컴포지터별 특이사항(클립보드 깜빡임, 키보드 레이아웃 설정, 새 기기 연결 시 재시작)에 대해 솔직한 도구는 대개 실제로 그 환경에서 테스트된 도구입니다.
- XWayland를 계속 활성화해 두어야 하는가? 어떤 도구가 XWayland를 통해서만 작동한다면, 호환성을 당연하게 여기기 전에 자신의 데스크톱 환경에서 이것이 기본적으로 켜져 있는지(대부분은 그렇습니다) 확인하세요.
자주 묻는 질문
왜 어떤 Linux 컴퓨터에서는 텍스트 확장기가 작동하고 다른 컴퓨터에서는 작동하지 않나요?
가장 흔한 원인은 세션 유형입니다. X11 세션과 Wayland 세션은 전역 입력을 완전히 다르게 처리하며, 주로 X11 입력 훅을 중심으로 만들어진 도구는 한쪽에서는 완벽히 작동하고 다른 쪽에서는 전혀 작동하지 않을 수 있습니다. 터미널에서 echo $XDG_SESSION_TYPE을 실행하면 현재 어떤 세션 유형으로 실행 중인지 확인할 수 있습니다.
Wayland는 생산성 도구에게 그냥 고장 난 환경인가요?
아닙니다 — 버그가 아니라 다르고 더 제한적인 보안 모델일 뿐입니다. 단순한 전역 입력 도구를 차단하는 제한은, 악성 앱이 키 입력을 기록하거나 은행 세션에 입력을 주입하기 어렵게 만드는 것과 같은 제한입니다. Wayland에서 잘 작동하는 도구는 X11 방식의 무제한 접근을 가정한 도구가 아니라, Wayland의 권한 모델(portal, zwp_virtual_keyboard_v1, 또는 input-group 접근 권한을 사용하는 전용 evdev/uinput 백엔드)을 중심으로 특별히 설계된 도구입니다.
XWayland를 비활성화하면 텍스트 확장이 깨지나요?
XWayland에서 실행되는 애플리케이션에 도달하기 위해 X11 방식 훅에 의존하는 도구라면 그럴 수 있습니다. XWayland가 명시적으로 비활성화된 강화 설정을 사용 중이라면, 텍스트 확장기에 (단순한 X11 훅이 아니라) 네이티브 Wayland 백엔드가 있는지 구체적으로 확인하세요 — Lightning Assist의 전용 Wayland 입력 백엔드와 Espanso의 실험적 evdev/uinput 모드는 모두 정확히 이런 경우를 위해 만들어졌습니다. 반면 AutoKey처럼 순전히 xdotool이나 X11 창 트리 접근만으로 구축된 도구는 그렇지 않습니다.
Wayland 지원을 작동시키려면 터미널 명령을 실행해야 하나요?
도구에 따라 다릅니다. Espanso의 Wayland 모드는 직접 실행해야 하는 일회성 setcap 권한 부여(또는 그에 상응하는 input-group 소속)가 필요합니다. 반면 Lightning Assist의 Wayland 백엔드는 처음 필요할 때 앱 안에서 일회성 "Grant access" 권한을 요청할 뿐입니다 — 터미널 명령은 필요 없습니다.
관련 글
- Linux용 텍스트 확장기 — 텍스트 확장에 특화된 X11/XWayland/Wayland 전체 정리
- Linux용 음성 인식 및 음성 받아쓰기 — 동일한 입력 주입 제약을 음성 입력에 적용한 설명
- Linux에서의 음성 받아쓰기: 2026년 현황 — 동일한 Wayland 프로토콜 세부사항을 포함해 Linux 음성 입력 환경을 폭넓게 살펴보는 글