한/영 키가 안 먹는 게 사실 '가짜 Alt 키'였을 때 — xev로 잡은 Alt_R 정체와 xmodmap 재매핑
환경: Kubuntu 26.04 LTS · KDE Plasma 6 · fcitx5 + fcitx5-hangul · X11 세션 · 키보드: Logitech MX Keys S
TL;DR / 빠른 해결
물리 한/영 키가 Hangul 키코드를 안 보내고 오른쪽 Alt(Alt_R)만 보내는 키보드가 흔하다. 그러면 fcitx5 단독 트리거는 겨우 되지만 조합키와 함께 누르면 씹히고, Firefox 같은 GTK 앱은 한/영을 Alt로 받아 메뉴바를 연다.
먼저 xev로 실제 신호를 확인하고,
xev | grep -A2 KeyPress # 한/영 키를 한 번 눌러본다Alt_R(keycode 108)로 나온다면 그 키코드를 Hangul로 재매핑한다(X11 전용).
xmodmap -e "keycode 108 = Hangul Hangul Hangul Hangul"재부팅 후에도 유지하려면 ~/.Xmodmap에 같은 줄을 넣는다.
증상: 무관해 보이는 버그 두 개
Kubuntu + Plasma 6 + fcitx5 조합에서 증상이 두 개 있었다.
- 한/영 전환이 조건부로 안 됨 — 아무 키도 안 누른 상태에서 한/영만 딱 누르면 전환이 된다. 그런데 Shift나 문자키를 누르고 있는 상태에서 한/영을 누르면 씹힌다. 사용자는 같은 키보드로 Windows에선 늘 즉시 전환됐다고 했다.
- Firefox에서 한/영을 누르면 Alt 메뉴가 뜸 — 한/영을 눌렀는데 Firefox 메뉴바가 반응한다(GTK 앱의 "Alt 단독 탭 → 메뉴바 토글" 동작).
처음엔 이 둘을 완전히 별개 문제로 보고 따로 접근했다. 이게 첫 실수였다.
오진 배제: "Wayland IME 프로토콜이 미성숙해서"
처음 세운 가설은 Wayland 쪽이었다. fcitx5의 한/영 트리거 키가 KDE 전역 단축키 목록(kglobalshortcutsrc)에 안 걸려 있는 걸 보고, fcitx5의 Wayland 프론트엔드(libwaylandim)가 KWin과 직접 주고받는 경로라 생성되는 미성숙 문제라고 추정했다.
이건 오판이었다. 검증하려고 사용자에게 X11 세션으로 바꿔서 같은 걸 시켜봤더니 두 증상이 똑같이 재현됐다. Wayland 전용 문제였다면 X11에선 사라졌어야 하는데 그대로였다 — 즉 Wayland/X11 공통의, 더 아래 레이어 문제라는 뜻이었다.
fcitx5 설정의 EnumerateWithTriggerKeys(트리거 키를 누르고 있을 때 입력기 목록 순환)를 꺼보게도 했지만 효과 없었다. IME 설정 레벨에서 헤매고 있었던 것이다.
근본 원인: xev로 raw 키 신호를 찍어보다
결국 시스템이 이 키를 뭘로 인식하는지부터 봐야 한다는 결론에 도달했다. 사용자에게 xev를 켜고 한/영 키를 딱 한 번 눌러보도록 요청했다.
KeyPress event, ... keycode 108 (keysym 0xffea, Alt_R), ...
KeyRelease event, ... keycode 108 (keysym 0xffea, Alt_R), ...
이 키보드의 물리 "한/영" 키는 Hangul 신호를 단 한 번도 보내지 않았다. 오직 Alt_R(오른쪽 Alt)만 보낸다. 애초에 전용 Hangul 키코드가 없고, 한/영 키가 오른쪽 Alt를 겸하는 하드웨어였던 것이다.
이 한 줄이 두 버그를 동시에 설명한다.
- Firefox가 Alt 메뉴를 여는 이유: Firefox는 시스템이 실제로 보내는 신호(
Alt_R)를 그대로 받아 정직하게 Alt로 처리한 것뿐이다. - fcitx5가 그래도 단독으론 작동한 이유: fcitx5는 이 키를 XKB가 해석한 키심볼이 아니라 물리 키 위치(keycode) 기준으로도 인식한다. 그래서 단독으로 누르면 "한/영 키"로 처리해줬다.
- 조합키와 함께 누르면 씹힌 이유: 다른 키를 누른 상태에서 이 키를 누르면 시스템은 정직하게
Alt_R + 다른 키= 진짜 Alt 단축키 조합으로 해석한다. 이 해석이 fcitx5의 "한/영 트리거" 인식을 밀어내면서 전환이 실패한다.
해결: keycode 108을 Alt_R 대신 Hangul로 재매핑
사용자에게 xmodmap으로 이 키코드가 보내는 신호 자체를 바꾸도록 안내했다.
xmodmap -e "keycode 108 = Hangul Hangul Hangul Hangul"사용자가 바로 테스트하니 두 증상 다 사라졌다. 재부팅 후에도 유지되도록 사용자가 ~/.Xmodmap에 같은 줄을 등록했다.
! 한/영 키가 물리적으로 Alt_R(keycode 108)만 보내던 문제 재매핑
keycode 108 = Hangul Hangul Hangul Hangul
Debian/Ubuntu 계열에는 X11 로그인 시 ~/.Xmodmap을 자동으로 읽어주는 스크립트(/etc/X11/Xsession.d/의 80kubuntu-xmodmap 등)가 들어 있는 경우가 많아, 그럴 땐 파일만 만들어두면 별도 자동시작 설정 없이 적용된다. 다만 배포판·버전에 따라 이 스크립트가 없거나 동작하지 않을 수 있으니(특히 SDDM/Wayland 우선인 최신 환경), 재로그인 후에도 매핑이 안 잡히면 로그인 autostart에 xmodmap ~/.Xmodmap을 직접 걸어주면 된다.
한계: X11 전용 픽스
xmodmap은 Wayland에서는 전혀 작동하지 않는다. Wayland 세션으로 돌아가면 두 버그가 그대로 재발한다. Wayland까지 커버하려면 xmodmap보다 아래 레벨 — udev hwdb로 커널 evdev 단계에서 재매핑하거나 keyd 같은 데몬 — 이 필요한데, 이번엔 X11만 쓰기로 해서 거기까진 가지 않았다.
교훈 / 체크리스트
- 한/영·한자 키가 있는 "국제 배열" 키보드라도, 실제로는 전용 키코드 없이 Alt/Ctrl을 겸용하는 제품이 흔하다. 특정 앱에서만 이상하게 반응하면
xev로 실제 신호부터 확인할 것. - 겉보기에 무관한 두 버그가 사실 하나의 하드웨어 레벨 원인을 공유하기도 한다 — "다른 앱에서도 이상한 게 있나?"를 먼저 물었으면 더 빨리 찾았을 것이다.
EnumerateWithTriggerKeys같은 fcitx5 설정을 만졌는데도 안 고쳐지면, IME 설정 레벨이 아니라 **시스템이 그 키를 뭘로 인식하는지(xev)**부터 의심하라.
관련 글
이 문제는 Kubuntu 26.04 듀얼부팅 설치 직후 fcitx5로 한글 입력기를 올리는 과정에서 드러났다.