"내 컴퓨터 화면에 창·커서·글자를 실제로 그려 주고, 키보드·마우스 입력을 프로그램들에게 나눠 주는 중앙 관리자"입니다. 우리가 보는 리눅스 데스크톱에서 크롬·터미널·파일관리자 같은 프로그램들은 사실 화면에 직접 픽셀을 찍지 못합니다. 대신 "여기 이런 창을 그려 줘"라고 디스플레이 서버에게 부탁하고, 서버가 GPU·모니터·입력장치를 실제로 조작합니다. XLibre는 그 디스플레이 서버의 한 종류인 X 서버를 만드는 프로젝트입니다.
이름 'XLibre'는 X(윈도우 시스템) + Libre(자유로운)의 합성어입니다. 토대는 수십 년간 리눅스/유닉스 데스크톱의 사실상 표준이던 X.Org 서버이고, XLibre는 그 소스코드를 그대로 이어받아 정리·개선하는 포크(fork)입니다. 즉 완전히 새로 만든 게 아니라, 검증된 거대 코드베이스(2만 3천 커밋 이상)를 계승해 새 방향으로 끌고 가는 프로젝트입니다.
연극에서 배우들은 "이 장면에선 조명을 붉게, 막을 내려 줘"라고 요청할 뿐, 직접 조명기를 만지지 않습니다. 무대감독 한 명이 모든 장치(조명·막·음향)를 통제하죠. 디스플레이 서버가 바로 이 무대감독입니다.
크롬·터미널은 배우(클라이언트)이고, XLibre는 무대감독(서버)입니다. 배우가 "창을 여기 그려, 이 글자를 써, 이 영역을 지워"라고 프로토콜(대본)로 말하면, 감독이 GPU·모니터·키보드·마우스라는 실제 무대 장치를 조작해 화면을 완성합니다.
XLibre가 트렌딩에 오르는 이유는 기술과 커뮤니티 드라마 두 가지가 겹쳐 있습니다. 기술적으로는 "다들 죽었다고 하는 X11을 계속 발전시킨다"는 역발상이고, 사회적으로는 2025년 6월 X.Org 커뮤니티에서 벌어진 충돌에서 갈라져 나온 사연이 화제가 됐습니다.
저장소의 HISTORY.md에 따르면, 주도자(Enrico Weigelt, 별명 metux)는 X.Org를 계속 개발하려 했으나 방향성·운영을 둘러싼 갈등 끝에 2025년 6월 freedesktop.org의 GitLab 계정·저장소·이슈가 차단됐다고 주장합니다. 그는 이를 "검열"로 규정했고, 그 직후 XLibre 포크를 공개했습니다. 반대편(레드햇/freedesktop.org 측)은 이 서술에 동의하지 않으며, 차단의 경위에 대한 양측 입장이 갈립니다. 이 문서는 어느 한쪽 편을 들지 않습니다 — 다만 "거버넌스 갈등이 대형 포크로 이어진 오픈소스의 전형적 사건"이라는 점, 그리고 README·HISTORY에 정치적 수사가 강하게 담겨 있다는 점을 알아 두면 코드를 읽을 때 맥락이 됩니다.
XLibre의 README/HISTORY에는 특정 기업·정책에 대한 강한 비판과 구호가 섞여 있다. 기술을 배우는 입장에서는 "코드의 품질·구조"와 "창립자의 주장"을 분리해서 보는 게 좋다. 포크의 정당성·인물 평가는 자료를 직접 읽고 스스로 판단할 영역이고, 여기서는 X11 서버의 구조와 학습 가치에 집중한다.
| 특징 | 의미 |
|---|---|
| X.Org의 모든 자산 계승 | 아직 정식 릴리스 안 된 기능까지 포함해 X.Org 코드를 그대로 가져옴 |
| TearFree 모드세팅 기본값 | 화면 찢김(테어링) 없는 출력을 기본 적용, 선택적 atomic modesetting |
| 구형 Nvidia 드라이버 지원 | 340·390·470·570 등 독점 드라이버를 자동 감지·내부 처리 |
| Xnamespace 확장 | X 클라이언트를 서로 격리(컨테이너 비슷한 분리) — X11의 약한 보안을 보완 |
| 멀티플랫폼 CI | 여러 BSD·Linux·macOS·Windows에서 빌드 검증 |
| seatd 지원 | systemd-logind 외에 seatd로도 좌석(seat) 관리 — systemd 비의존 선택지 |
요즘 리눅스 데스크톱은 Wayland로 옮겨 가는 추세입니다. Wayland는 "서버가 곧 컴포지터"인 더 단순하고 안전한 설계입니다. 하지만 X11은 네트워크 투명성(원격에서 GUI 실행), 성숙한 드라이버·앱 호환성, 수많은 레거시 환경에서 여전히 강점이 있습니다. XLibre는 "X11이 필요한 사람은 계속 있다"는 전제 위에, X 서버를 방치하지 않고 손보는 프로젝트입니다. 학습자에게는 디스플레이 서버라는 거대한 시스템 소프트웨어를 통째로 들여다볼 수 있는 흔치 않은 교재라는 점이 진짜 매력입니다.
Wayland가 "새로 지은 스마트 빌딩"이라면, X11은 "수십 년 증축을 거듭한 오래된 대저택"이다. XLibre는 그 대저택을 허물지 말고 계속 수리하며 살자는 프로젝트다. 트렌딩 이유는 포크 드라마 + 역발상이지만, 배울 것은 "디스플레이 서버가 도대체 어떻게 동작하는가"라는 컴퓨터과학의 고전적 주제다.
XLibre는 웹 프로젝트와 전혀 다른, 순수 시스템 프로그래밍 스택입니다. 화려한 프레임워크 대신 C 언어·빌드 도구·저수준 그래픽/입력 라이브러리로 이뤄집니다. 핵심은 "하나의 거대한 C 코드베이스에서 여러 종류의 X 서버 실행파일을 만들어 낸다"는 점입니다.
| 항목 | 내용 |
|---|---|
| 주 언어 | C 94.8% — 저수준 메모리·포인터 제어가 필수인 시스템 소프트웨어 |
| 보조 언어 | Python 1.8%(빌드·테스트 스크립트), Roff 1.1%(man 페이지), Objective-C 1.0%(macOS Xquartz), C++ 0.1% |
| 빌드 시스템 | Meson + Ninja — meson setup → ninja -C build install |
| 빌드 옵션 | meson_options.txt에 수십 개 옵션(서버별·확장별 on/off, auto 감지) |
| 레거시 호환 | xorg-server.pc.in·xorg-server.m4 — 기존 Xorg 빌드 인터페이스 유지 |
| CI | AppVeyor 등으로 BSD·Linux·macOS·Windows 멀티플랫폼 검증 |
| 의존성 | 역할 |
|---|---|
| xorgproto | X11 프로토콜·확장 정의 헤더. "클라이언트와 서버가 주고받는 대화 규약"의 원본 |
| pixman | 픽셀 단위 합성·래스터화 라이브러리. 소프트웨어 렌더링의 엔진 |
| libdrm | 리눅스 DRM(Direct Rendering Manager) 접근 — GPU·모드세팅과 통신 |
| libepoxy / gbm | OpenGL 함수 로딩(epoxy)과 GPU 버퍼 관리(gbm) — Glamor 가속에 사용 |
| libudev | 입력·모니터 장치 핫플러그 감지(연결/분리 자동 인식) |
| seatd / systemd-logind | 좌석(seat)·세션 관리 — 누가 어떤 장치를 쓸 권한이 있는지 |
XLibre의 묘미는 같은 코어를 두고 "어디에 그릴 것인가"만 바꾼 여러 서버 실행파일을 만든다는 점입니다. 이를 DDX(Device Dependent X)라 부릅니다.
| 서버 | "어디에 그리나" | 용도 |
|---|---|---|
| Xorg | 실제 GPU·모니터 | 일반 데스크톱용 메인 서버 |
| Xephyr | 다른 X 서버 안의 창 | 개발·테스트(안전한 격리 실행) |
| Xvfb | 가상 프레임버퍼(화면 없음) | CI·헤드리스 렌더링·자동화 테스트 |
| Xnest | 다른 X 서버 안의 창 | 중첩 실행(Xephyr의 구형 형제) |
| Xquartz | macOS 네이티브 윈도우 | 맥에서 X11 앱 실행 |
| XWin | Microsoft Windows | 윈도우에서 X11 앱 실행 |
| Xfbdev | 리눅스 프레임버퍼(/dev/fb) | GPU 드라이버 없이 단순 출력 |
실제 GPU 드라이버(intel·amdgpu·nouveau…)와 입력 드라이버(libinput·evdev…)는 이 저장소에 들어 있지 않다. xf86-video-*·xf86-input-*라는 독립 저장소로 나뉘어 있고, 런타임에 .so 모듈로 동적 로딩된다. 덕분에 서버 본체는 가볍게 유지되고, 새 하드웨어 지원은 드라이버만 갱신하면 된다. "코어와 플러그인의 분리"라는 고전적 모듈화의 교과서다.
X 서버의 큰 그림은 "아래에서 위로 쌓인 4개 층"입니다. 맨 아래 OS 추상화층이 소켓·입출력을 책임지고, 그 위 코어층(DIX/MI/FB)이 프로토콜을 해석하며, 다시 그 위 확장(Extension)층이 추가 기능을 얹고, 맨 위 DDX층이 실제 하드웨어(또는 가상 화면)에 출력합니다. 아래 도식은 저장소의 CODE_OVERVIEW.md가 제시하는 구조를 옮긴 것으로, 아래에서 위로 읽으면 각 층이 어떻게 쌓이는지 보입니다.
클라이언트(예: 터미널)가 "이 창을 그려"라고 보내면, 다음 순서로 처리됩니다.
# X 프로토콜 요청의 일생 1. 클라이언트 요청 도착 → os/ (소켓·연결관리가 받음) 2. 디스패치(분배) → dix/dispatch.c 가 요청 종류 판별 3. 코어 op? → DIX가 직접 처리 / 확장 op? → 등록된 확장으로 전달 4. 실제 그리기 → mi/(범용) · fb/(프레임버퍼) · render/(가속) 5. 화면 출력 → hw/(DDX: 실제 GPU 또는 가상 화면)
대형 우체국과 같다. OS층은 우편물을 받는 접수창구, DIX는 "이건 일반우편, 저건 등기"로 분류하는 분류기다. 일반(코어 요청)은 바로 처리하고, 특수(확장 요청)는 전담 부서(확장 모듈)로 보낸다. MI/FB/Render는 실제로 물건을 포장하는 작업대, DDX는 최종적으로 트럭(GPU)에 실어 배달하는 단계다.
X 서버 설계의 정수는 "하드웨어에 의존하는 코드"와 "의존하지 않는 코드"를 칼같이 나눈 것입니다. DIX(Device Independent X)는 어떤 하드웨어에서도 똑같이 도는 코어 로직, DDX(Device Dependent X)는 GPU·OS마다 다른 부분, MI(Machine Independent)는 그 사이의 범용 구현입니다. 덕분에 macOS·Windows·가상화면용 서버를 DDX만 바꿔 만들 수 있습니다.
RandR(해상도 변경)·Composite(투명·합성)·XInput(고급 입력)·GLX(OpenGL) 등 거의 모든 기능이 코어가 아니라 확장으로 구현됩니다. 확장은 dix/extension.c에 자신을 등록하고, 새 요청 코드(opcode)를 추가합니다. 이 구조 덕에 X11은 40년간 코어를 갈아엎지 않고도 기능을 계속 늘려 왔습니다. 많은 확장이 render/(렌더 확장)에 의존하는 점도 특징입니다.
그리기는 가능하면 GPU로(glamor/ OpenGL 가속), 안 되면 구형 2D 가속(exa/), 그것도 안 되면 순수 소프트웨어(fb/ + pixman)로 내려갑니다. 하드웨어가 없거나 드라이버가 빈약해도 일단 화면은 뜬다는 견고함이 여기서 나옵니다. Xvfb(가상 프레임버퍼)가 화면 없이도 도는 이유이기도 합니다.
최상위 디렉토리는 X 서버의 계층 구조를 그대로 폴더로 옮긴 모습입니다. 폴더 이름만 알면 "이 기능은 어디 있겠다"가 바로 짐작됩니다.
세 가지가 핵심입니다. 첫째, 최상위 폴더 = 아키텍처 층입니다. os/(맨 아래) → dix/ mi/ fb/(코어) → 각종 확장 폴더 → hw/(맨 위 DDX)가 도식 그대로 놓여 있습니다. 둘째, 확장이 폴더 하나씩을 차지해 "기능 = 디렉토리"가 됩니다 — RandR을 고치려면 randr/만 보면 됩니다. 셋째, hw/ 안에서 서버 변형들이 갈립니다 — 새 플랫폼 지원은 여기에 DDX를 추가하는 일입니다. 진입점은 dix/main.c, 확장 등록은 dix/extension.c 하나만 기억하면 코드 탐색의 출발점이 잡힙니다.
hw/ 하위 폴더에는 README가 없다. 대신 .man 파일(예: hw/kdrive/Xkdrive.man)로 문서화한다 — 유닉스 전통이다. 코드 전체 지도는 루트의 CODE_OVERVIEW.md가 가장 정확하니, 소스를 파기 전에 이 파일부터 읽는 게 지름길이다.
이 레포는 "네트워크 프로토콜로 GUI를 그린다"는 발상을 실물로 보여 줍니다. 클라이언트는 요청(request)을 보내고 서버는 이벤트(event)·응답(reply)·오류(error)를 돌려줍니다. 실습: xtrace로 xeyes가 서버와 주고받는 메시지를 들여다보고, "창 만들기 → 그리기 → 입력 이벤트"의 실제 패킷 흐름을 관찰하기.
하드웨어 독립층과 의존층을 어떻게 가르는지가 시스템 설계의 정석입니다. 실습: dix/main.c의 디스패치 루프와 dix/dispatch.c의 요청 분배를 따라 읽으며, 코어 요청과 확장 요청이 어디서 갈라지는지 코드로 확인하기.
RandR·Composite 같은 확장이 코어를 건드리지 않고 기능을 더하는 구조는 "개방-폐쇄 원칙"의 C 언어 구현입니다. 실습: 가장 단순한 확장(예: record/ 또는 dbe/) 하나를 골라, extension.c 등록 → opcode 추가 → 핸들러 연결의 3단계를 추적하기.
수십 개 옵션으로 거대한 C 프로젝트를 구성하는 현대적 빌드를 배울 수 있습니다. 실습: meson setup 시 -Dxephyr=true -Dxorg=false처럼 옵션을 바꿔 Xephyr만 빌드해 보고, meson_options.txt의 auto 옵션이 의존성 유무에 따라 어떻게 켜지고 꺼지는지 확인하기.
GPU 가속(Glamor/OpenGL) → 구형 가속(EXA) → 소프트웨어(fb+pixman)로 내려가는 폴백 사다리는 그래픽 스택을 통째로 이해하는 좋은 단면입니다. 실습: Xvfb(순수 소프트웨어)와 Xephyr(상위 서버 GPU 경유)에서 같은 앱을 띄워 렌더링 경로 차이를 체감하기.
같은 코어가 Linux·BSD·macOS(Xquartz)·Windows(XWin)에서 도는 비결은 os/와 hw/의 플랫폼 추상화입니다. 실습: os/의 소켓·폴링 코드(ospoll.c)를 읽고, OS별 차이를 어디서 흡수하는지 찾아보기.
| 항목 | 요구사항 |
|---|---|
| 대상 OS | Linux(주력) · 여러 BSD · macOS(Xquartz) · Windows(XWin) |
| 빌드 도구 | Meson + Ninja, C 컴파일러(gcc/clang), pkg-config |
| 핵심 빌드 의존성 | xorgproto · pixman · libdrm · libepoxy · gbm · libudev(리눅스) |
| GPU 드라이버 | 별도 xf86-video-* 모듈(amdgpu·intel·nouveau 등) — ABI 일치 필요 |
| 입력 드라이버 | 별도 xf86-input-* 모듈(libinput·evdev 등) — 없으면 입력 잠김 위험 |
| 세션/좌석 관리 | seatd 또는 systemd-logind |
| 안전한 테스트 | Xephyr(중첩 창) 또는 Xvfb(가상 화면) 권장 — 본 세션 잠김 방지 |
XLibre는 모듈 ABI가 바뀌어서, 드라이버를 반드시 이 서버 버전에 맞춰 재컴파일해야 한다. 입력 드라이버가 버전 불일치로 못 올라오면 키보드·마우스가 모두 잠겨 VT 전환조차 안 될 수 있다. 실기에서 테스트할 땐 다른 PC에서 SSH로 접속하거나, 일정 시간 뒤 chvt 1을 호출하는 타이머를 걸어 두는 식으로 탈출 경로를 미리 확보하자. 입문자는 실기 대신 Xephyr/Xvfb로 시작하는 게 안전하다.
# 소스 빌드 (Xephyr만 켜고 메인 Xorg는 끔) meson setup --prefix="$(pwd)/image" build -Dxephyr=true -Dxorg=false ninja -C build install # 현재 데스크톱 안에 중첩 창으로 X 서버 띄우기 → :2 디스플레이 ./image/bin/Xephyr :2 -screen 1024x768 & DISPLAY=:2 xeyes # 그 안에서 X 클라이언트 실행 (안전, 본 세션과 격리)
배포판 패키지로 Xephyr를 설치해 Xephyr :2 -screen 1024x768로 중첩 서버를 띄우고, DISPLAY=:2로 xeyes·xterm·xclock을 실행한다. "클라이언트가 서버를 골라 붙는다"는 X의 핵심을 체감하기.
xev로 키·마우스 이벤트가 어떻게 들어오는지 보고, xtrace로 클라이언트↔서버 요청/응답을 캡처한다. "CreateWindow → MapWindow → Expose" 흐름을 실제 메시지로 확인하기.
의존성(pixman·libdrm·xorgproto…)을 설치하고 meson setup → ninja로 빌드한다. README의 testx.sh로 "10초간 검은 화면"이 뜨면 성공. 빌드 옵션을 바꿔 가며 어떤 서버·확장이 포함되는지 비교하기.
dix/main.c에서 서버 초기화와 메인 루프를, dix/dispatch.c에서 요청 분배를 따라 읽는다. 코어 요청 핸들러 하나(예: ProcCreateWindow)에 로그를 추가해 빌드하고, 창이 생길 때 호출되는지 확인하기.
xcb 라이브러리로 "창 하나를 띄우고 클릭하면 사각형을 그리는" 50줄짜리 C 프로그램을 작성한다. CreateWindow·Map·이벤트 루프·그리기 요청을 직접 호출하며, XLibre 서버가 이 요청들을 어떻게 처리하는지 소스와 대조하기.
record/나 dbe/ 같은 단순 확장을 골라 등록(extension.c)→opcode→핸들러 경로를 추적하고, 디버그 로그를 심어 특정 확장 요청이 들어올 때 출력되게 만든다. "모든 것이 확장"이라는 구조를 코드로 체득하기.
| 주차 | 학습 주제 | 실천 목표 |
|---|---|---|
| 1주차 | X11 개념·역사 | 클라이언트-서버 모델, X11 vs Wayland 차이, 윈도우 매니저/컴포지터 역할 이해 |
| 2주차 | X 프로토콜 관찰 | xev·xtrace·xwininfo로 요청/이벤트 흐름 캡처·해석 |
| 3주차 | XLibre 빌드·실행 | Meson/Ninja로 소스 빌드, Xephyr/Xvfb로 격리 실행 |
| 4주차 | 서버 아키텍처 | DIX/DDX/MI 분할, dispatch 루프, CODE_OVERVIEW.md 정독 |
| 5주차 | 확장 메커니즘 | extension.c 등록 구조, RandR·Composite 동작 추적 |
| 6주차 | 렌더링 파이프라인 | fb·pixman 소프트웨어 렌더, Glamor/EXA 가속 경로 비교 |
| 7주차 | XCB로 클라이언트 작성 | 창 생성·이벤트 루프·그리기를 직접 구현 |
| 8주차 | Wayland와 비교 | wlroots 등 컴포지터 구조를 보고 X11과 설계 철학 대조 |
xrandr 명령이 이 확장을 사용한다.meson setup으로 설정하고 ninja로 컴파일한다. 수십 개 옵션으로 어떤 서버·확장을 포함할지 고를 수 있다.| 링크 | 설명 |
|---|---|
| GitHub 저장소 | 소스 전체. dix/·hw/·CODE_OVERVIEW.md가 출발점 |
| CODE_OVERVIEW.md | 코드 구조 안내서 — 소스 탐색 전 필독 |
| HISTORY.md | 포크 경위·원본 문서 모음(맥락 자료, 정치적 수사 포함) |
| XLibre Wiki | 빌드·호환성·배포판 적용 현황(Are We XLibre Yet?) |
| xlibre.net | 프로젝트 공식 홈페이지(미션·기능) |
| TrendShift 페이지 | 트렌딩 추이(일간 19위, 2026-06-09) |
| X Window System (위키백과) | X11의 역사·개념 개관 |
| Xorg — ArchWiki | 설정·구성 상세 문서(XLibre에도 대부분 적용) |
| X.Org 프로젝트 | 원본 X.Org 서버·드라이버·프로토콜 자료 |