메뉴의 실종, 그리고 부활: KDE의 숨은 보석 'KCommandBar'

 리눅스 데스크탑을 오래 쓰신 분들이라면 2010년대 초반, 우분투(Ubuntu)가 선보였던 Unity HUD의 충격을 기억하실 겁니다. 당시 "메뉴바를 없애고 검색으로 모든 걸 해결하자"는 시도는 혁신적이었지만, 동시에 수많은 '메뉴바 유저'들의 반발을 샀던 애증의 역사이기도 하죠.

오늘은 그 역사의 끝에서 KDE가 어떻게 가장 완벽한 해답을 내놓았는지, KCommandBar를 통해 이야기해보려 합니다.

1. 잃어버린 메뉴를 찾아서: HUD의 잔혹사

과거 GNOME이 상단 바를 활용하며 맥(macOS)의 레이아웃을 지향하고, 우분투가 Unity를 통해 메뉴바를 숨기기 시작했을 때 리눅스 생태계는 혼란에 빠졌습니다.

  • 극단적인 환경: 메뉴는 사라졌는데 검색 엔진(HUD)은 불안정했고, 버그는 넘쳐났습니다.

  • 사용자 반발: "직관적으로 클릭하고 싶은데 왜 매번 타자를 쳐야 하나?"라는 불만이 터져 나왔죠.

  • KDE의 초기 대응: 당시 KDE도 이를 흉내 내기 위해 여러 시도를 했지만, UI가 따로 놀거나 반응 속도가 처참해 "역시 KDE는 이런 거 안 어울려"라는 소리를 듣기도 했습니다.

2. 2022년, KDE의 '조용한 혁명' (KCommandBar의 등장)

그렇게 잊히는 듯했던 HUD 개념은 2022년 Plasma 5.24에 이르러 KCommandBar라는 이름으로 화려하게 부활했습니다. 과거의 어설픈 흉내와 달리, 이번에는 앱의 심장부인 QAction 시스템과 직접 통합되었습니다.

  • 단축키: Ctrl + Alt + I (KDE Frameworks 기반 모든 앱 공통)

  • 특징: 단순히 메뉴 이름을 검색하는 게 아니라, 해당 앱이 가진 모든 실행 가능 액션을 인덱싱합니다.

GIMP나 Krita처럼 메뉴가 5단계씩 파묻혀 있는 복잡한 그래픽 툴을 쓸 때, 이제 더 이상 마우스로 모험을 떠날 필요가 없게 된 것이죠.

3. KRunner vs KCommandBar: 무엇이 다른가?

가장 많이 헷갈리는 부분이 "Alt+Space(KRunner)가 있는데 왜 이게 또 필요해?"라는 점입니다. 하지만 둘의 역할은 명확히 나뉩니다.

비교 항목KRunner (시스템 엔진)KCommandBar (앱 HUD)
범위시스템 전체 (앱 실행, 파일 검색, 계산기)현재 사용 중인 앱 내부
대상파일, 웹사이트, 설치된 프로그램메뉴 항목, 도구, 플러그인 액션
특징가끔 권한(Policy) 문제로 타임아웃 발생가볍고 빠르며 앱 로직과 밀착됨

4. 왜 지금 KCommandBar인가?

최근의 KDE는 과거의 "이상한 플러그인 규격"이나 복잡한 .desktop 설정의 미로를 벗어나, 사용자 경험의 **'일관성'**에 집중하고 있습니다.

사용자가 직접 만든 Dolphin 서비스 메뉴나 Krusader 액션들이 이 커맨드바에서 검색어로 툭툭 튀어나올 때, 비로소 리눅스 데스크탑은 "내가 길들인 나만의 도구"가 됩니다.

한 줄 평: > "우분투가 꿈꿨던 이상향을, KDE가 가장 실용적이고 안정적인 방식으로 완성했다."

팁: 만약 지금 KDE를 쓰고 계신다면, 아무 앱이나 열고 Ctrl + Alt + I를 눌러보세요. 당신이 십수 년 전 헤매던 그 메뉴가 검색창 안에 조용히 기다리고 있을 겁니다.

글을 마치며...

예전 KDE 4 시절의 투박한 손맛도 그립지만, 이렇게 역사의 흔적을 품고 세련되게 다듬어진 도구들을 만날 때면 오픈소스 생태계의 성장이 참 대단하다는 걸 느낍니다. 여러분은 어떤 방식의 인터페이스를 선호하시나요? 댓글로 의견 나눠주세요!


일단 Qt기반이나 KDE4앱 ,GTK, GNOME기반앱은 지원이되지 않습니다. 

중요!!
KILE등 오래된 앱들도 최신 빌드는 KDE6기반이라 지원합니다. 이거 쌈박합니다. 훌륭해요.

댓글

댓글 쓰기