Wayland와 Qt
Wayland는 리눅스에서 X11의 대안으로 개발되었습니다. 주요 목적은 공유된 화면에서 애플리케이션의 콘텐츠가 함께 표시되는 방식과, 사용자가 동일한 입력 장치를 공유하는 여러 애플리케이션과 상호작용하는 방식을 관리하는 것입니다.
운영 체제에서 이러한 역할을 흔히 ‘디스플레이 서버’라고 부릅니다. Wayland 디스플레이 서버는 그 임무의 일환으로 수행하는 특정 작업을 지칭하여 때때로 ‘컴포지터’나 ‘윈도우 매니저’라고도 불립니다.
이하에서는 Wayland와 Qt에서 Wayland가 수행하는 역할에 대해 간략히 소개하겠습니다. Wayland 자체에 대한 자세한 내용과 배경 정보는 공식 문서를 참조하십시오.
디스플레이 서버란 무엇인가
디스플레이 서버는 화면 영역 및 기타 공유 자원을 관리하는 운영 체제의 일부입니다. 일반적인 데스크톱 시스템에서는 여러 개의 독립적인 애플리케이션이 동시에 실행될 수 있으며, 각 애플리케이션은 화면에 그래픽을 렌더링하고 입력을 수신할 수 있기를 기대합니다.
디스플레이 서버는 애플리케이션과 화면, 입력 장치와 같은 공유 리소스 사이의 연결 고리 역할을 합니다. 데스크톱 시스템의 일반적인 디스플레이 서버는 애플리케이션 콘텐츠를 사용자가 이동하거나 크기를 조정할 수 있는 별개의 직사각형 “창”에 배치합니다. 디스플레이 서버는 애플리케이션 콘텐츠가 화면의 올바른 위치에 표시되도록 하고, 활성 창이 키보드 입력을 수신하도록 하며, 겹쳐진 창들이 올바른 순서대로 그려지도록 하는 등의 역할을 수행합니다.
다른 유형의 시스템에서는 디스플레이 서버가 더 제한적일 수 있습니다. 예를 들어, 화면이 자동차의 계기판이나 지게차의 제어판인 경우, 창을 이동하거나 크기를 조정하는 것은 바람직하지 않을 수 있습니다. 대신, 각 애플리케이션은 화면의 미리 정의된 영역에 고정되어 미리 할당된 장치로부터 입력을 수신할 수 있습니다.
어느 쪽이든, 동일한 자원을 놓고 경쟁하는 여러 개의 분리된 프로세스가 존재하는 한 디스플레이 서버는 유용합니다.
Wayland의 역할
Wayland라는 이름은 다음과 같은 여러 관련 항목을 가리킬 수 있습니다:
- 디스플레이 서버와 클라이언트 간의 통신을 위한 일련의 프로토콜.
- C 언어로 작성된 라이브러리로, 프로세스 간 통신 기능을 제공하며, 앞서 언급한 프로토콜을 구현하는 기반이 됩니다.
- 프로토콜을 확장하기 위한 XML 기반 언어이자, 이러한 확장을 바탕으로 C 언어로 된 바인딩 코드를 생성하는 도구.
Qt는 이 프로토콜의 클라이언트 측과 서버 측 모두에 대한 구현을 제공합니다.
"wayland" QPA 플러그인을 선택하면(일부 시스템에서는 이것이 기본값입니다) 일반 Qt 애플리케이션을 Wayland 디스플레이 서버에서 클라이언트로 실행할 수 있습니다. 이를 위해서는 -qpa wayland 옵션을 사용하면 됩니다. 또한, Qt Wayland Compositor 모듈을 사용하여 디스플레이 서버 자체를 개발할 수도 있습니다.
또한 Qt는 새로운 인터페이스를 통해 Wayland 프로토콜을 쉽게 확장할 수 있는 편리한 기능을 제공합니다.
Wayland 및 기타 기술
리눅스 데스크톱 환경에서 Wayland는 X11 및 관련 확장 기능의 대안입니다. Wayland는 본질적으로 합성(compositing) 디스플레이 서버이며, Wayland 서버를 설명할 때 종종 “합성기(compositor)”라는 용어가 사용됩니다. 즉, 클라이언트는 콘텐츠를 오프스크린 버퍼에 렌더링하고, 이 버퍼는 나중에 화면상의 다른 클라이언트와 “합성”되어 드롭 섀도우, 투명도, 배경 흐림 효과 등과 같은 창 효과를 구현할 수 있게 됩니다.
원래 X11 프로토콜의 중요한 설계 원칙 중 하나는 디스플레이 서버가 화면과 입력 장치만 갖춘 얇은 터미널에서 실행될 수 있다는 점입니다. 이 경우 클라이언트는 더 높은 처리 능력을 갖춘 원격 시스템에서 실행되며, 네트워크 연결을 통해 서버와 통신하게 됩니다.
반면, Wayland는 현대적인 환경에서 클라이언트와 디스플레이 서버가 대개 동일한 하드웨어에서 실행된다는 점에 착안하여 설계되었습니다. 분산 컴퓨팅, 원격 저장소 및 원격 데스크톱 기능은 대개 다른 메커니즘을 통해 처리됩니다. 이러한 점을 프로토콜에 반영함으로써 클라이언트와 서버 간에 그래픽 메모리를 공유할 수 있게 되었습니다. 컴포지터가 클라이언트 콘텐츠를 화면에 표시할 때, 그래픽 메모리의 한 부분에서 다른 부분으로 간단히 복사하기만 하면 됩니다.
이 기능이 최적으로 작동하려면 그래픽 드라이버가 Wayland를 지원해야 합니다. 이러한 지원은 EGL 의 확장 기능인 EXT_platform_wayland 를 통해 제공됩니다.
참고: Qt Wayland는 EXT_platform_wayland 가 지원되지 않는 시스템에서도 XComposite 를 사용하거나 애플리케이션 콘텐츠를 공유 CPU 메모리로 복사하는 방식을 통해 컴포지팅을 지원합니다. 하지만 최적의 성능을 위해서는 드라이버가 지원되는 시스템을 사용하는 것이 좋습니다.
X11은 컴포지팅 및 다이렉트 렌더링과 같은 기능을 지원하도록 확장되었지만, Wayland는 처음부터 이러한 사용 사례를 염두에 두고 설계되었습니다. 또한 시간이 지남에 따라 복잡해진 X11과 달리, Wayland는 가볍고 확장성이 뛰어나도록 설계되었습니다.
확장성과 임베디드 시스템
Wayland는 핵심 기능이 최소화되어 있고 쉽게 확장할 수 있기 때문에, 임베디드 리눅스 플랫폼을 구축할 때 이상적인 도구입니다.
예를 들어, 데스크톱 스타일의 윈도우 시스템 기능은 핵심 프로토콜의 일부가 아닙니다. 대신 Wayland에는 클라이언트가 자신의 표면을 관리할 수 있는 방법을 제공하는 “셸(shells)”이라고 불리는 특별한 종류의 프로토콜 확장 기능이 있습니다. 데스크톱 스타일의 기능은 XDG Shell 라는 셸을 통해 제공됩니다. 다른 유형의 시스템의 경우, 보다 전문화되고(아마도 더 제한적인) “셸”을 사용할 수 있습니다. 예를 들어, In-Vehicle Infotainment 시스템을 구축할 때는 IVI Shell 가 더 적합할 수 있습니다.
Wayland 서버는 클라이언트가 연결될 때 지원하는 프로토콜(또는 “인터페이스”) 목록을 브로드캐스트하며, 클라이언트는 사용하고자 하는 프로토콜에 바인딩할 수 있습니다. 이는 표준 인터페이스 중 어느 것이든 될 수 있지만, 새로운 확장 기능도 쉽게 추가할 수 있습니다. Wayland는 프로토콜을 정의하기 위한 이해하기 쉬운 XML 형식을 정의하고 있으며, waylandscanner 도구를 사용하여 이를 바탕으로 C 코드를 생성할 수 있습니다. (Qt에서는 추가적인 C++ 바인딩 코드를 생성하는 qtwaylandscanner 도 제공합니다.)
클라이언트가 인터페이스에 바인딩한 후에는 서버에 “요청”을 보낼 수 있으며, 서버는 클라이언트에 “이벤트”를 보낼 수 있습니다. 요청과 이벤트, 그리고 그 인수는 프로토콜을 설명하는 XML 파일에 정의되어 있습니다.
플랫폼을 처음부터 구축할 때, 서버와 클라이언트 양쪽의 코드를 모두 제어할 수 있다면, 확장 기능을 추가하는 것은 운영 체제 기능을 추가하는 쉽고 체계적인 방법입니다.
다중 프로세스 또는 단일 프로세스
Qt를 사용하여 간단한 임베디드 플랫폼을 구축할 때, UI의 모든 부분을 단일 프로세스에서 실행하는 것도 충분히 타당한 선택입니다. 하지만 시스템이 점점 복잡해지면, 대신 다중 프로세스 시스템을 고려해 볼 필요가 있습니다. 바로 여기서 Wayland가 등장합니다. Qt를 사용하면 개발 과정의 어느 단계에서든 단일 프로세스와 다중 프로세스 간에 전환할 수 있습니다.
다중 프로세스의 장점
다음 다이어그램은 다중 프로세스 시스템과 단일 프로세스 시스템의 차이점을 보여줍니다.
다중 프로세스 클라이언트 아키텍처
단일 프로세스 클라이언트 아키텍처
이 Qt Wayland Compositor 모듈은 임베디드 리눅스의 다중 프로세스 시스템에서 디스플레이 서버와 컴포지터를 생성하는 데 이상적입니다. 다중 프로세스를 사용하면 다음과 같은 이점이 있습니다:
| 안정성 | |
|---|---|
| 클라이언트가 응답을 멈추거나 충돌했을 때 복구가 더 용이함 | UI가 복잡한 경우, UI의 한 부분이 충돌하더라도 전체 시스템에 영향을 미치지 않기 때문에 다중 프로세스 방식이 유용합니다. 마찬가지로, 클라이언트 하나가 멈춰도 화면이 멈추지 않습니다. 참고: 클라이언트가 법적으로 안전에 중요한 정보를 표시해야 하는 경우 , 다음을 사용하는 것을 고려하십시오 Qt Safe Renderer. |
| 잠재적인 메모리 누수 방지 | 다중 프로세스 시스템에서 한 클라이언트에 메모리 누수가 발생하여 많은 메모리를 소모하더라도, 해당 클라이언트가 종료되면 그 메모리는 회수됩니다. 반면 단일 프로세스 시스템에서는 시스템 전체가 재시작될 때까지 메모리 누수가 지속됩니다. |
| 보안 |
|---|
| 단일 프로세스 시스템에서는 모든 클라이언트가 서로의 메모리에 접근할 수 있습니다. 예를 들어, 민감한 데이터 전송에 대한 격리가 없으며, 모든 코드 줄이 동등하게 신뢰할 수 있어야 합니다. 다중 프로세스 시스템에서는 설계상 이러한 격리가 보장됩니다. |
| 성능 |
|---|
| 다중 코어 CPU를 사용하는 경우, 다중 프로세스 시스템을 통해 부하를 여러 코어에 고르게 분산시켜 CPU를 더 효율적으로 활용할 수 있습니다. |
| 상호 운용성 |
|---|
| 클라이언트가 Wayland 또는 X11을 지원하는 한, 다중 프로세스 시스템에서 Qt가 아닌 클라이언트와도 연동할 수 있습니다. 예를 들어, 비디오 재생에 gstreamer를 사용하거나 다른 UI 툴킷으로 구축된 내비게이션 애플리케이션을 사용하려는 경우, 이러한 클라이언트를 다른 Qt 기반 클라이언트와 함께 실행할 수 있습니다. |
다중 프로세스 방식의 장단점
단일 프로세스에서 다중 프로세스로 전환할 때는 다음과 같은 장단점을 염두에 두는 것이 중요합니다:
| 비디오 메모리 소비량 증가 |
|---|
| 이는 임베디드 기기의 경우 제약 요인이 될 수 있습니다. 다중 프로세스 환경에서는 각 클라이언트가 자체 그래픽 버퍼를 가지고 있어야 하며, 이를 컴포지터로 전송합니다. 결과적으로, 모든 것이 한 번에 그려지고 각 부분을 중간 버퍼에 저장할 필요가 없는 단일 프로세스 환경에 비해 더 많은 비디오 메모리를 사용하게 됩니다. |
| 메인 메모리 소비량 증가 |
|---|
| OS 수준에서 발생하는 약간의 추가 오버헤드 외에도, 여러 클라이언트를 실행하면 일부 구성 요소가 클라이언트당 한 번씩 중복되어 로드되므로 메인 메모리 사용량이 증가할 수 있습니다. 예를 들어, QML을 실행할 경우 각 클라이언트마다 별도의 QML 엔진이 필요합니다. 결과적으로, Qt Quick Controls 를 사용하는 단일 클라이언트를 실행하면 해당 리소스는 한 번만 로드됩니다. 이 클라이언트를 여러 클라이언트로 분할하면 Qt Quick Controls 를 여러 번 로드하게 되어, 클라이언트를 초기화하는 데 더 많은 시작 비용이 소요됩니다. |
| 그래픽 리소스의 중복 저장 |
|---|
| 단일 프로세스 시스템에서 여러 곳에 동일한 텍스처, 배경 또는 아이콘을 사용하는 경우, 해당 이미지는 한 번만 저장됩니다. 반면, 다중 프로세스 시스템에서 이러한 이미지를 사용하면 여러 번 저장해야 합니다. 이 경우 한 가지 해결책은 클라이언트 간에 그래픽 리소스를 공유하는 것입니다. Qt는 이미 Wayland를 거치지 않고도 프로세스 간 메인 메모리에서 이미지 리소스를 공유할 수 있도록 지원합니다. 반면, 프로세스 간 GPU 텍스처를 공유하려면 더 정교한 해결책이 필요합니다. Qt를 사용하면 이러한 해결책을 Wayland 확장 프로토콜이나 QQuickImageProvider 등을 통해 개발할 수 있습니다. |
| 입력-광자 지연 시간 |
|---|
| 단일 프로세스 시스템에서는 애플리케이션이 메인 프레임 버퍼에 직접 액세스합니다. 즉, 이러한 환경에서는 입력 이벤트와 화면에 반영되는 시점 사이의 지연 시간을 최소화할 수 있습니다. 다중 프로세스 시스템에서는, 서버가 버퍼를 읽는 동안 클라이언트가 해당 버퍼에 그림을 그리지 않도록 하기 위해 애플리케이션 콘텐츠를 트리플 버퍼링해야 합니다. 그렇지 않으면 티어링 현상이 발생하기 때문입니다. 즉, 다중 프로세스 시스템에는 암묵적인 지연 시간이 존재합니다. |
X11이나 맞춤형 솔루션 대신 Wayland를 사용하는 이유
앞서 설명한 바와 같이, X11은 오늘날의 일반적인 시스템 구성에 최적의 선택이 아닙니다. X11은 규모가 상당히 크고 복잡하며, 사용자 정의 기능이 부족합니다. 실제로 X11을 사용하면 클라이언트를 부드럽게 실행하기 어렵고, 티어링 없이 60fps에 도달하기 어렵습니다. 반면 Wayland는 구현이 더 쉽고 성능이 우수하며, 최신 그래픽 하드웨어에서 효율적으로 구동하는 데 필요한 모든 요소를 갖추고 있습니다. 리눅스 기반의 임베디드 멀티프로세스 시스템에서는 Wayland가 표준으로 자리 잡고 있습니다.
하지만 구형 하드웨어나 레거시 애플리케이션을 다루는 경우, Wayland는 좋은 선택지가 아닐 수 있습니다. Wayland 프로토콜은 보안과 격리를 염두에 두고 설계되었으며, 클라이언트가 이용할 수 있는 정보와 기능에 대해 엄격하고 보수적인 기준을 적용합니다. 이는 더 깔끔하고 안전한 인터페이스를 제공하지만, 레거시 애플리케이션이 기대하는 일부 기능은 Wayland에서 더 이상 사용할 수 없을 수도 있습니다.
특히, Wayland가 최선의 선택이 아닐 수 있는 세 가지 일반적인 사용 사례가 있습니다:
- 하드웨어나 플랫폼이 오래되어 X11만 지원하는 경우입니다. 이 경우에는 선택의 여지가 없습니다.
- 보안과 단순성을 위해 Wayland 프로토콜에 없는 기능에 의존하는 레거시 애플리케이션을 지원해야 하는 경우.
- Wayland에서는 전혀 실행되지 않는 UI 툴킷을 사용하는 레거시 애플리케이션을 지원해야 하는 경우입니다. 경우에 따라 해당 애플리케이션을 XWayland에서 실행함으로써 이 문제를 우회할 수 있습니다.
X11이 매우 대중적이었던 시절, 개발자들은 X11의 문제점을 우회하기 위해 자체적인 맞춤형 솔루션을 개발하곤 했습니다. 구버전 Qt에는 Qt Windowing System(QWS)이 포함되어 있었으나, 현재는 더 이상 지원되지 않습니다. 오늘날 이러한 사용 사례의 대부분은 Wayland로 해결되고 있으며, 맞춤형 솔루션은 점점 더 드물어지고 있습니다.
Qt Wayland가 제공하는 기능
클라이언트용
Qt 클라이언트는 Wayland 프로젝트의 일환으로 개발된 레퍼런스 컴포지터인 Weston을 포함하여, 모든 Wayland 컴포지터에서 실행될 수 있습니다.
모든 Qt 프로그램은 Wayland 클라이언트(다중 프로세스 시스템의 일부) 또는 독립형 클라이언트(단일 프로세스)로 실행될 수 있습니다. 이는 시작 시점에 결정되며, 이때 다양한 백엔드 중에서 선택할 수 있습니다. 개발 과정에서는 먼저 데스크톱에서 클라이언트를 개발한 다음, 나중에 대상 하드웨어에서 테스트할 수 있습니다. 클라이언트를 항상 실제 대상 하드웨어에서 실행할 필요는 없습니다.
단일 프로세스 클라이언트 개발
리눅스 시스템에서 개발하는 경우, 개발용 머신의 창 내에서 컴포지터를 실행할 수도 있습니다. 이를 통해 대상 기기와 매우 유사한 환경에서 클라이언트를 실행할 수 있습니다. 클라이언트를 다시 빌드하지 않고도 ` -platform wayland `을 사용하여 컴포지터 내에서 클라이언트를 실행할 수 있습니다. -platform xcb (X11용)을 사용하는 경우, 데스크톱에서 클라이언트를 실행할 수 있습니다. 즉, 컴포지터가 사용 준비가 되기 전에 클라이언트 개발을 시작할 수 있습니다.
서버용
서버 (또는 컴포지터)는 디스플레이에 연결되어 각 클라이언트의 내용을 화면에 표시합니다. 컴포지터는 입력을 처리하고 해당 클라이언트에 입력 이벤트를 전송합니다. 이에 따라 각 클라이언트는 컴포지터에 연결되어 자신의 창 내용을 전송합니다. 다음을 결정하는 것은 컴포지터의 몫입니다:
- 콘텐츠를 어떻게, 어디에 표시할지
- 어떤 콘텐츠를 표시할지
- 서로 다른 클라이언트 그래픽 버퍼를 어떻게 처리할지
즉, 다중 프로세스 시스템이 무엇을 의미하는지는 컴포지터가 결정합니다. 예를 들어, 클라이언트는 벽면에 창이 있는 3D 장면의 일부일 수도 있고, VR 시스템 상에 있을 수도 있으며, 구면에 매핑되어 있을 수도 있습니다.
이 Qt Wayland Compositor 는 사용자 정의 컴포지터를 구축하기 위한 API입니다. 이 API를 사용하면 맞춤형 컴포지터 UI를 자유롭게 구축하고 다양한 클라이언트의 창을 관리할 수 있습니다. Qt Quick 과 QML을 Qt Wayland Compositor 와 결합하여 인상적이고 창의적인 UI를 만들 수 있습니다. 자세한 내용은 Qt Wayland Compositor를 참조하십시오.
Qt는 또한 Wayland 확장 기능을 구현하고 QML 또는 C++에서 이를 사용할 수 있도록 지원하는 강력하고 사용자 친화적인 API를 제공합니다.
관련 콘텐츠
© 2026 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.
