Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — "리눅스도 이제 HDR 됩니다"를 저장소 기록으로 검증하기
5년짜리 머지 리퀘스트 — color-management-v1이 오기까지
어느 릴리스에 실렸나 — 컴포지터별 핀
프로토콜은 병합 후에도 움직인다 — v2, v3, color-representation
아직 매끄럽지 않은 것들 — 저장소가 말해 주는 마찰
같은 기간 X 서버는 — "버려졌다" 대신 측정값으로
실무 체크리스트
마치며
참고 자료

들어가며 — "리눅스도 이제 HDR 됩니다"를 저장소 기록으로 검증하기

작년부터 "리눅스 데스크톱 HDR"이라는 말이 뉴스 헤드라인에 자주 올라왔습니다. 그런데 헤드라인은 대개 두 가지를 뭉갭니다 — 프로토콜이 표준으로 병합된 시점과, 그게 실제로 당신 컴포지터의 릴리스에 실린 시점입니다. 이 둘 사이에는 짧게는 한 달, 길게는 1년 넘는 간격이 있고, 실무에서 중요한 건 언제나 후자입니다.

그래서 이 글은 발표문 대신 저장소 기록을 읽습니다. wayland-protocols의 태그별 디렉터리 트리, Mutter의 NEWS 파일, KWin 커밋이 처음 포함된 태그, wlroots 릴리스 노트, 그리고 X 서버 저장소의 커밋 수를 직접 세서, "색 관리와 HDR이 리눅스 데스크톱에 실제로 배포된 연대기"를 버전 번호에 핀으로 꽂습니다. 모든 날짜와 수치는 2026년 7월 17일 기준으로 GitLab/invent.kde.org API와 git 태그에서 직접 확인한 값입니다(태그 날짜는 태그가 가리키는 커밋의 날짜 기준). 데스크톱 생태계 전반의 큰 그림은 리눅스 데스크톱 2026 딥다이브에서 다뤘고, 이 글은 그중 디스플레이 스택 한 조각을 소스 레벨로 팝니다.

5년짜리 머지 리퀘스트 — color-management-v1이 오기까지

숫자부터 봅시다. wayland-protocols의 MR !14 "staging: add color management protocol"은 2020년 1월 23일에 열려 2025년 2월 13일에 병합됐습니다. 5년 3주입니다. 나흘 뒤인 2025년 2월 17일, wayland-protocols 1.41이 이 프로토콜을 staging 디렉터리에 담아 릴리스됐습니다 — 1.40(2025-01-30)의 트리에는 color-management가 없고 1.41에는 있다는 걸 태그별 트리 비교로 확인할 수 있습니다.

MR이 5년이지 논의가 5년인 것도 아닙니다. 프로토콜 개발에 오래 관여해 온 Collabora의 회고 글 제목이 아예 "12 years of incubating Wayland color management"입니다.

왜 이렇게 오래 걸렸는지는 프로토콜의 모양이 말해 줍니다. color-management-v1은 인터페이스 9개짜리(1.49 기준) 대형 프로토콜입니다. 클라이언트가 자기 콘텐츠의 색 공간을 ICC 프로파일로도, 파라메트릭(원색 좌표 + 전달 함수 + 휘도)으로도 선언할 수 있고, 마스터링 디스플레이 메타데이터(maxCLL/maxFALL 등)와 렌더링 인텐트까지 다룹니다. 그리고 병합 뒤에도 XML 커밋 로그에는 set_luminance 재정의, 전달 함수 교체 같은 정정이 계속 이어집니다 — 색 과학을 프로토콜 문장으로 고정하는 일이 얼마나 어려운지를 병합 이후의 이력 자체가 보여 줍니다.

어느 릴리스에 실렸나 — 컴포지터별 핀

핵심 질문은 하나입니다. "내 데스크톱에서 wp_color_management_v1이 언제부터 잡히나." 공식(병합된) 프로토콜 기준으로 정리하면 이렇습니다.

구현	공식 프로토콜이 처음 실린 릴리스	날짜(태그 기준)
Mutter (GNOME)	Mutter 48.0 — GNOME 48	2025-03-16
KWin (KDE Plasma)	Plasma 6.4.0	2025-06-12
wlroots (Sway 등)	wlroots 0.19.0	2025-05-15
Weston	병합 전 드래프트 구현이 14.0.0(2024-09-04)부터 트리에 존재	—

표만으로는 각 프로젝트의 결이 안 보이니, 하나씩 짚습니다.

Mutter. NEWS 파일을 릴리스 단위로 읽으면 궤적이 선명합니다. 47 주기(47.0 태그: 2024-09-14)에 "실험적 색 관리 프로토콜 지원"이 47.rc 항목으로 올랐습니다 — 이때는 프로토콜 병합 전이라 드래프트 구현입니다. 48.rc(2025-03-03)에서 "Support wp_color_management_v1 protocol"로 공식 프로토콜이 실렸고, GNOME 48 릴리스 노트는 이를 "시스템 수준 HDR 지원의 최초 도입"이라 불렀습니다 — 같은 노트가 "현재 HDR을 지원하는 앱의 수는 제한적"이고, HDR을 켜면 하드웨어 밝기 조절이 안 되는 경우가 많아 소프트웨어 에뮬레이션 밝기 조절을 함께 넣었다고 정직하게 적고 있습니다. 48.1(2025-04-01)에서는 비-atomic(레거시) KMS 드라이버에서 HDR을 비활성화했습니다. 49.0(2025-09-14)에서 color-representation 프로토콜 구현이, 50(2026-03-15)에서는 프로토콜 v2 지원(MR !4905, 2026-02-20 병합)과 HDR 화면 공유, "sdr-native" 색 모드, CRTC KMS 색 속성 지원이 들어왔습니다.

KWin. invent.kde.org의 커밋 이력이 재미있는 디테일을 줍니다. KWin은 병합을 기다리지 않고 2024년 1월 29일에 실험(xx-) 태그 버전 구현을 넣었고(처음 포함된 태그는 v6.0.90, 즉 Plasma 6.1 계열), 프로토콜이 병합된 바로 그날인 2025년 2월 13일에 공식 프로토콜로 전환하는 커밋을 올렸습니다. 다만 Plasma 6.3.0 태그가 그보다 일주일 앞선 2025-02-06에 찍혔기 때문에, 이 전환이 사용자에게 도달한 첫 릴리스는 Plasma 6.4.0(태그 2025-06-12)입니다. v2 구현은 2026-01-12 커밋으로 들어가 Plasma 6.6.0(태그 2026-02-12)에 실렸습니다.

wlroots. 0.19.0 릴리스 노트(2025-05-15)는 "color-management-v1 for HDR10 support"를 새 프로토콜 구현으로 올리면서, 괄호 안에 "renderer and backend bits have not yet been merged"라는 단서를 그대로 달았습니다 — 프로토콜은 말할 줄 알지만 렌더링 파이프라인 배관은 아직이라는 뜻입니다. 그 배관은 0.20.0(2026-03-26)에서 왔습니다: Vulkan 렌더러·백엔드·씬그래프의 전체 지원, DRM 백엔드의 색 원색·HDR 메타데이터 전달, color-representation-v1 구현, 그리고 프로토콜 마이너 버전 2까지. wlroots 기반 컴포지터(Sway 등)의 HDR은 실질적으로 0.20 세대의 이야기입니다.

Weston. 레퍼런스 컴포지터인 Weston의 libweston/color-management.c는 병합 1년 전인 2024-02-14부터 트리에 있었고(14.0.0에 포함), color-representation 구현은 2025-12-19에 들어가 15.0.0(2026-02-19)에 실렸습니다.

정리하면 — 프로토콜 병합(2025년 2월)에서 3대 구현의 공식 지원 릴리스까지 1~4개월, 렌더링 배관과 v2까지 포함한 "완성형"은 2026년 상반기입니다. 배포는 이벤트가 아니라 공정이었습니다.

프로토콜은 병합 후에도 움직인다 — v2, v3, color-representation

staging에 들어갔다고 끝이 아닙니다. 인터페이스 버전이 계속 올라갑니다. 태그별 XML의 version 속성으로 확인하면:

v1 — wayland-protocols 1.41(2025-02-17)부터 1.46까지.
v2 — 1.47(2025-12-15). 병합 직전의 커밋 제목들로 내용을 요약하면: ready2 이벤트 추가, absolute_no_adaptation 렌더링 인텐트 추가, wp_image_description_reference_v1 신설, 2-피스 전달 함수 교체와 deprecated 항목 광고 금지 같은 전달 함수 정리, maxCLL/maxFALL 제약 완화.
v3 — 1.49(2026-06-07). 핵심은 create_windows_bt2100 요청 하나입니다. XML 설명을 그대로 옮기면, "Windows 10이 BT.2100/PQ 신호 모드로 구동되는 HDR 화면에 대해 자체 정의한 BT.2100 색 공간을 다루는 방식"을 재현하는 미리 정의된 이미지 디스크립션입니다.

v3가 왜 필요한지는 KWin 커밋 로그가 답합니다 — 2025-12-18 "Windows HDR 앱을 위한 워크어라운드 + 설정 추가", 2026-02-21 "Windows 실행 파일 이름 목록에 wine64-preloader 추가". Wine/Proton으로 도는 Windows 게임들이 Windows의 HDR 인코딩 관례(scRGB, Windows-BT.2100)를 기대하기 때문에, 컴포지터가 그 관례를 프로토콜 차원에서 말할 수 있게 만든 겁니다. 리눅스 HDR의 주요 고객이 게임이라는 현실이 프로토콜 버전 히스토리에 그대로 찍혀 있습니다.

참고로 이 글을 쓰는 시점(2026-07-17)에 v3 구현이 릴리스에 실린 주요 컴포지터는 아직 확인하지 못했습니다 — Mutter 51.alpha NEWS에 관련 항목이 없고, KWin의 색 관리 소스 파일에 닿은 마지막 커밋은 2026-04-23(v3 릴리스 이전)이며, wlroots 0.20.0 노트는 "마이너 버전 2"까지만 말합니다. 1.49가 나온 지 한 달 남짓이니 자연스러운 시차입니다.

자매 프로토콜도 있습니다. color-representation-v1(버퍼의 색 인코딩·레인지 기술 — YCbCr 계수, full/limited 레인지, 알파 모드)은 1.44(2025-04-27)에 병합됐고, Mutter 49(2025-09), wlroots 0.20(2026-03), Weston 15(2026-02)가 구현을 실었습니다. 비디오 재생 파이프라인의 색이 정확해지려면 이쪽이 필요합니다.

아직 매끄럽지 않은 것들 — 저장소가 말해 주는 마찰

배포 연대기만 보면 순항 같지만, 같은 저장소들에는 마찰의 기록도 있습니다. 도입을 검토한다면 이쪽을 더 주의 깊게 읽어야 합니다.

톤 매핑은 지금 꺼져 있습니다(Mutter). Mutter 50.rc의 NEWS에 "Disable tone mapping with HDR"이 있습니다. MR !4897의 설명은 이렇습니다 — 현재 톤 매핑 구현이 현재 블렌딩 색 공간과 올바르게 동작하지 않고, 휘도 매핑을 톤 매핑과 분리해서 다뤄야 하며, 실제 디스플레이가 재현할 수 없는 10,000니트까지의 PQ 전 범위를 항상 쓰는 동안에는 HDR 톤 매핑이 의미도 없다는 겁니다. HDR 파이프라인이 "켜진다"와 "잘 보인다" 사이의 거리를 보여 주는 정직한 커밋입니다.

레거시 드라이버는 제외됩니다. Mutter 48.1은 비-atomic(레거시) KMS 드라이버에서 HDR을 비활성화했고, HDR 모니터가 HDR 능력을 잃으면 기본 색 모드로 폴백하는 처리도 이때 들어왔습니다. 오래된 GPU/드라이버 조합에서는 컴포지터 버전이 맞아도 HDR이 안 뜹니다.

클라이언트 생태계는 아직 조정 중입니다. KWin의 색 관리 파일 이력에는 "work around Firefox"(2026-01-13) → 리버트(2026-01-20) → "work around Firefox again"(2026-01-22) → 다시 리버트(2026-04-23)라는 왕복이 남아 있습니다. 프로토콜이 표준이 됐다고 클라이언트들이 그걸 올바르게 쓰는 건 아니고, 그 비용은 일단 컴포지터가 워크어라운드로 치릅니다.

앱 지원은 여전히 좁습니다. GNOME 48 릴리스 노트의 표현을 다시 빌리면, HDR을 지원하는 앱의 수는 "제한적"입니다. 컴포지터가 프로토콜을 말해도 툴킷과 앱이 따라와야 하는데, 그 지형은 이 글의 범위 밖이니 도입 전 각자 확인이 필요합니다.

실무 판단으로 옮기면 — SDR만 쓰는 환경이라면 이 스택 때문에 지금 무언가를 바꿀 이유가 없습니다. 색 정확도가 계약 조건인 워크플로(인쇄 교정, 영상 마스터링)라면, 위의 마찰 기록이 정리될 때까지 자체 검증 없이 리눅스 HDR 경로에 올라타는 건 이르다고 보는 게 안전합니다. 반대로 HDR 게임(특히 Proton)과 HDR 미디어 소비가 목적이라면, 2026년 상반기 릴리스들(Plasma 6.6, GNOME 50, wlroots 0.20 기반)이 실질적인 출발선입니다.

같은 기간 X 서버는 — "버려졌다" 대신 측정값으로

이 연대기의 반대편에는 X 서버가 있습니다. "Xorg는 죽었다"는 단언 대신, 저장소를 직접 세어 봤습니다(방법: xorg/xserver를 tree:0 partial clone으로 받아 git rev-list --count, 2026-07-17 기준).

릴리스 열차부터. xorg-server의 마지막 메이저는 21.1.0(2021-10-27)이고, 그 뒤로는 21.1.x 패치 릴리스만 나왔습니다 — 최신은 21.1.24(2026-07-08). 독립 릴리스로 분리된 Xwayland도 24.1.0(2024-05-15) 이후 새 메이저 없이 24.1.x만 이어져 최신이 24.1.13(2026-07-08)입니다. 이 두 최신 릴리스는 같은 날 나온 보안 권고(CVE-2026-55999, CVE-2026-56000)의 수정판입니다. 즉 보안 대응은 지금도 돌아갑니다.

커밋 수. 그런데 커밋 수를 세려니 전제가 하나 무너져 있었습니다. 2026년 2월, xserver 저장소는 master 브랜치를 닫았습니다. Alan Coopersmith의 xorg-devel 제안 메일(2026-01-20)이 배경을 설명합니다 — master에는 나중에 리버트된 커밋들, "한 개발자가 계획했지만 이제 우리 저장소에는 들어오지 않을 작업을 준비하던 커밋들", 다른 개발자들이 동의하지 않은 변경이 쌓여 있었고, 그래서 2024년 2월 시점에서 새 main 브랜치를 따고 유지할 커밋만 선별해 다시 올리자는 겁니다. 제안 시점 기준으로 master의 분기 후 커밋 1,386개 중 835개만 남기는 안이었고, 선별 기준에는 "라이선스 고지 요건을 안 지킨 커밋 제외", "이득 대비 휘저음이 큰 커밋 제외", "알려진 ABI/API 파괴 제외"가 명시돼 있습니다. 같은 메일에는 이런 문장도 있습니다 — "작년에 이 난장판 때문에 Xwayland와 X 서버의 25.1 릴리스 계획이 무산됐고, 올해는 26.1 브랜치를 만들 수 있기를 바란다."

실제로 벌어진 일을 측정하면: master는 2026-02-08 커밋으로 폐쇄 선언됐고(README에 "defunct" 문구 추가), 두 브랜치의 분기점은 2024-02-10의 커밋입니다. 분기 이후 커밋은 master 쪽 1,428개, 현재 main 쪽 1,108개(재구축 이후의 신규 작업 포함)입니다. 저자별로 보면 가장 크게 줄어든 건 Enrico Weigelt의 커밋으로, master의 804개에서 main의 399개가 됐습니다 — master 분기 후 커밋의 절반 이상(804/1,428)이 한 사람 것이었다는 뜻이기도 합니다.

이 재구축 때문에 "연도별 커밋 수"는 세는 방법에 따라 달라집니다. 재구축된 main은 2026년 1월에 과거 커밋들을 다시 커밋했으므로 커밋일 기준 집계는 왜곡되고, 작성일(author date) 기준이 실제 활동에 가깝습니다:

xorg/xserver, 현재 main 브랜치, 작성일 기준 연간 커밋 수 (2026-07-17 측정)
2020: 224   2021: 341   2022: 215   2023: 265
2024: 631   2025: 224   2026: 235 (7월 17일까지)

참고: 폐쇄된 구 master의 커밋일 기준으로는 2024: 772, 2025: 666 —
     이 차이(대량 커밋과 그 리버트, 그리고 재구축에서의 탈락분)가
     위 본문에서 설명한 사건의 크기입니다.

2026년 작성 커밋 235개의 상위 저자는 Peter Hutterer(99), Alan Coopersmith(72), Olivier Fourdan(30)입니다. 소수 인원의 꾸준한 유지보수 — 그게 측정이 보여 주는 그림입니다. "버려졌다"는 틀렸고, "예전처럼 개발된다"도 틀렸습니다.

그리고 기능 격차는 구조적입니다. Xwayland의 빌드 정의(hw/xwayland/meson.build)에는 색 관리 프로토콜에 대한 참조가 전혀 없습니다. 즉 이 글 전반부의 색 관리·HDR 스택은 X11 앱에는 도달하지 않는 경로입니다. 한편 GNOME 쪽에서는 Jordan Petridis의 공지대로 GNOME 49(2025년 9월)에서 X11 세션이 기본 비활성화됐고 — 공지가 명시하듯 "Xwayland에는 영향이 없고, X11/Xorg 세션에 관한 것"입니다 — Mutter 50(2026년 3월)은 MR !4505로 X11 백엔드 자체를 삭제했습니다. X11 앱은 Xwayland 위에서 계속 돌지만, 세션과 신기능의 무게중심 이동은 이제 계획이 아니라 릴리스된 사실입니다.

실무 체크리스트

버전 확인이 먼저입니다. 색 관리/HDR을 쓰려면 최소선이 GNOME 48 / Plasma 6.4 / wlroots 0.19 기반이고, 실질적으로는 v2와 렌더링 배관이 갖춰진 GNOME 50 / Plasma 6.6 / wlroots 0.20 세대가 출발선입니다. 배포판의 컴포지터 버전을 이 표에 대조하는 것으로 충분합니다.

하드웨어·드라이버 제약을 기억하세요. 레거시 KMS 경로에서는 HDR이 비활성화됩니다(Mutter 48.1). HDR 토글이 안 보이면 컴포지터 버전보다 드라이버부터 의심하는 게 순서입니다.

앱 개발자라면 — wp_color_management_v1의 버전 협상(v1: 1.41, v2: 1.47, v3: 1.49)을 확인하고, Windows 관례(scRGB, BT.2100)가 필요한 건 Wine 계열 특수 용도라는 점을 구분하세요. 비디오라면 color-representation-v1 지원 여부도 함께 봐야 합니다.

X11 의존 워크플로라면 — 앱 단위 의존(Xwayland로 해결)과 세션 단위 의존(GNOME 50부터 불가)을 구분해서 인벤토리를 만드는 게 급합니다. X 서버 자체는 보안 패치가 계속 나오고 있으므로 당장의 위험은 아니지만, 색 관리·HDR처럼 Wayland 전용으로만 쌓이는 기능의 목록은 앞으로 늘어나기만 할 겁니다.

마치며

정리하면 이렇습니다. Wayland 색 관리는 2020년에 열려 2025년 2월에 병합된 5년짜리 머지 리퀘스트였고, 병합 후 1~4개월 만에 Mutter·KWin·wlroots의 릴리스에 실렸으며, 2026년 상반기에 v2·렌더링 배관·HDR 화면 공유·Windows 호환(v3)까지 붙으면서 "완성형"에 가까워졌습니다. 같은 기간 X 서버는 보안 패치와 소수 인원의 유지보수가 이어지는 한편, 저장소 히스토리를 재구축해야 할 만큼의 거버넌스 비용을 치렀고, 새 릴리스 열차(26.1)는 아직 희망 사항입니다.

"리눅스 HDR 됩니다"는 이제 참입니다 — 단, 컴포지터 버전과 드라이버와 앱이라는 세 조건이 붙은 참이고, 톤 매핑처럼 아직 꺼져 있는 조각도 있습니다. 도입 판단은 헤드라인이 아니라 위의 버전 표와 마찰 기록으로 하시기 바랍니다. 저장소는 발표문보다 정직합니다.