KDE Plasma 데스크톱은 훌륭한 환경을 제공하지만, 정작 대부분의 리눅스 배포판은 GNOME을 기본으로 채택하고 있습니다. 왜 더 많은 배포판이 KDE에 올인하지 않을까요? Plasma는 배포판의 기반으로 충분히 훌륭한데 말이죠. 그 이유는 대체로 기술적인 데 있습니다.
1. 방대한 코드베이스
KDE는 여러 부분으로 구성되어 있습니다. 사용자가 직접 마주하는 Plasma 데스크톱 환경, 백그라운드에서 작동하는 다양한 라이브러리와 프레임워크, 그리고 수백 개에 달하는 애플리케이션이 그것입니다. 학습해야 할 코드의 양이 방대하고, 이를 유지보수하고 지원해야 할 부담도 상당합니다.
문제는 단순히 코드의 양만이 아닙니다. 각 구성 요소는 오랜 세월 발전해 왔기 때문에 그 복잡성이 누적되었고, 이해하기가 한층 더 어려워졌습니다.
GNOME은 사용자 경험이 단순할 뿐 아니라 소프트웨어 자체도 더 간결합니다. 덕분에 배포가 쉽습니다. 실제로 상당수 KDE 기반 배포판은 어떤 배포판의 기본 데스크톱에 대한 '대안' 형태로 제공되는데, 이를 준비하는 데에는 겉으로 보이는 것보다 훨씬 많은 노력이 필요합니다.
2. 엇갈린 릴리스 일정
KDE 핵심 경험을 이루는 각 요소는 서로 다른 릴리스 주기를 따릅니다. 사용자가 직접 다루는 KDE Plasma 데스크톱, 백그라운드 라이브러리 모음인 KDE Frameworks, 그리고 120개 이상의 프로그램·라이브러리·플러그인으로 구성된 KDE Gear가 대표적입니다.
각 번들은 저마다 고유한 릴리스 일정을 가집니다. 때로는 KDE Plasma의 특정 버전이 아직 정식 출시되지 않은 KDE Frameworks 버전을 필요로 하는 기능과 함께 나오기도 합니다.
이렇게 끊임없이 움직이는 수많은 부품을 배포판 관리자가 따라가기란 쉽지 않습니다. GNOME 기반 배포판이라면 최신 GNOME 출시에 맞춰 6개월마다 새 버전을 내면 되지만, KDE 기반 배포판은 릴리스 주기 자체가 명확하지 않습니다.
3. 무한한 설정 가능성

KDE Plasma는 아마도 가장 자유롭게 꾸밀 수 있는 데스크톱 인터페이스일 것입니다. PC를 원하는 모습 그대로 만들고 싶어 하는 기술 애호가에게는 큰 강점입니다. 패널을 여러 개 두거나 아예 없앨 수도 있고, 전역 메뉴 바나 앱 메뉴, 독이나 작업 표시줄 등 취향에 맞는 무엇이든 선택할 수 있습니다.
심지어 코드를 몰라도, 추가 구성 요소를 설치하지 않고도 Plasma를 Windows, macOS, 심지어 GNOME처럼 보이게 만들 수 있습니다.
하지만 기술에 익숙하지 않은 사용자에게는 이것이 오히려 독이 됩니다. 메뉴를 빠르게 클릭하다가 작업 표시줄을 실수로 삭제하고, 되돌리는 방법조차 모르는 상황이 벌어질 수 있죠. 지원 팀 입장에서도 고통입니다. 기본 레이아웃의 문제뿐 아니라 가능한 모든 설정 조합에서 생기는 문제까지 대응해야 하니까요.
설정 가능성은 데스크톱에만 머물지 않습니다. 수많은 KDE 앱 역시 긴 메뉴와 폭넓은 옵션으로 세세한 조정이 가능합니다. 앱 메뉴를 제거하거나, 도구 모음의 아이콘을 바꾸거나, 창에 표시되는 내용을 변경하는 것도 가능합니다. 문제가 발생했을 때 개발자와 지원 팀 모두 동일한 환경을 재현하기가 어려워지는 이유입니다.
4. 더 복잡한 소프트웨어

KDE Plasma의 시스템 설정 앱을 열어보면 옵션이 사실상 무한대로 펼쳐집니다. 이름이 비슷한 카테고리가 많아 검색창의 도움 없이는 원하는 설정을 찾기 힘들 때도 있습니다.
대부분의 KDE 소프트웨어가 그렇습니다. 데스크톱 환경과 파일 관리자는 물론 텍스트 편집기까지, 많은 앱이 저마다 긴 환경설정 목록을 갖고 있습니다. KDE의 기본 터미널 하나를 설정하는 데만 해도 꽤 많은 시간을 쏟을 수 있습니다.
각 앱이 하는 일이 많다는 것은 배워야 할 코드가 더 많고, 감당해야 할 복잡성도 더 크다는 뜻입니다. 데스크톱의 모든 구성 요소를 이해하고 배포하는 작업은, 상대적으로 적은 일만 시도하는 다른 데스크톱 환경보다 훨씬 많은 노력을 요구합니다.
5. 더 많은 버그

높은 설정 자유도와 복잡성의 결과로, KDE는 더 많은 버그를 안고 있습니다. 데스크톱이 시도하는 일이 많을수록 개발자가 검증해야 할 범위도 그만큼 넓어집니다.
창 목록이 화면 하단에 열린 창을 잘 보여주는 것만으로는 부족합니다. 패널을 화면 옆으로 옮길 수도 있으니, 창 목록이 회전하고 크기를 조정할 수 있어야 합니다. 이를 구현하려면 추가 코드가 필요하고, 그만큼 버그가 스며들 여지도 커집니다.
마찬가지로 대체 테마와 여러 모니터의 자동 숨김 패널을 함께 쓸 때만 나타나는 버그도, 해당 기능이 모두 기본 제공된다면 '소수 사용 사례'라고 치부할 수 없습니다.
KDE 개발자 Nate Graham은 Destination Linux 261화에서 이런 과제의 일부를 이야기했습니다. 예컨대 모니터를 연결하거나 분리할 때마다 커스터마이징된 데스크톱 레이아웃이 그대로 유지되도록 보장하는 일 같은 것이죠. 멀티모니터 지원은 다른 데스크톱 환경에서 구현하기가 단순히 더 쉽습니다.
6. 완성도와 일관성의 부족

그 결과물은 상대적으로 덜 다듬어진 경험입니다. 전문적이고 품질 높은 데스크톱을 만들 재료는 모두 갖춰져 있지만, 모든 요소가 손쉽게 변경될 수 있는 구조에서는 각 부분이 완벽하게 어우러지도록 유지하기 어렵습니다.
게다가 KDE가 아무리 유연해도 쉽게 고칠 수 없는 문제가 있습니다. 앱 곳곳에 비일관성이 존재합니다. 어떤 앱은 메뉴 바를 쓰고, 어떤 앱은 햄버거 메뉴 버튼을 씁니다. 둘 다 사용하는 앱도 있습니다!
자세히 들여다봐야 보이는 문제도 있습니다. 서로 다른 여백을 가진 스크롤바, 테두리 없는 창(Dolphin이나 KWrite 등)의 가장자리에 딱 붙은 파란색 둥근 외곽선 같은 것들입니다. 이런 부분은 개발자가 되어 코드를 읽는 법을 배우기 전까지는 고칠 방법이 없습니다.
이런 문제들은 버그가 아닙니다. 해결하려면 "이것이 올바른 방식"이라는 통합된 비전과 커뮤니티 차원의 합의가 필요합니다. 일부 결정을 디자이너에게 위임하고 그 권고를 따르는 일, 그리고 변경을 실제로 실행할 개발자가 있는 일이기도 합니다. KDE 커뮤니티는 이 세 가지 과제에 동시에 직면해 있습니다.
그렇다면 KDE는 기본 데스크톱으로 부적합한가?
그렇지 않습니다. KDE를 기본으로 탑재하기 더 매력적인 환경이 만들어지고 있습니다. Valve가 Steam Deck을 위해 선보인 KDE 기반 데스크톱이 Fedora Silverblue처럼 읽기 전용 시스템 파일을 채택한 점을 생각해 보세요. 최신 KDE 업데이트를 받는 Arch 기반 시스템에서도 시스템이 망가지는 것을 막아줍니다. Valve가 Flatpak을 선택한 점 역시 항상 최신 앱을 받을 수 있게 해 줍니다.
Valve만 그런 것은 아닙니다. TUXEDO Computers도 자사 제품에 KDE Plasma를 탑재합니다. 일부 기업은 다른 대안보다 KDE를 택하지만, 아직은 소수입니다. 그럼에도 KDE의 미래가 밝다고 믿을 만한 충분한 이유가 있습니다.