X Window System은 유닉스 계열 운영체제에서 사용되는 윈도 시스템입니다. 흔히 X.Org, X11 등의 이름으로 불리기도 하는 이 프로그램은 주로 리눅스 계열 운영체제의 윈도 시스템으로 사용됩니다. 네트워크 환경에서 GUI 인터페이스를 제공하기 위한 목적으로 개발되었으며, 네트워크 프로토콜(X 프로토콜)을 사용하여 화면 구성과 출력 연산을 서버에서 관리하기 때문에 원격으로 GUI 프로그램을 실행할 수 있다는 특징이 있습니다.
X 서버, X.Org, X11 등 다양한 이름으로 불리는 이 프로젝트는 1984년, MIT 대학의 아테나 프로젝트에서 출범하였습니다. X의 전신인 W 윈도 시스템은 스탠포드 대학교의 분산 시스템 운영체제인 V에 GUI 구현을 위해 개발되었습니다. 아테나 프로젝트 개발진은 바로 이 W 윈도 시스템의 코드를 복사해 서버의 자원을 GUI 환경에서 사용할 수 있도록 하는 X 윈도 시스템을 개발한 것입니다.
이후 1986년 X 윈도 시스템의 개발자들은 오픈 소스 버전의 X를 공개할 계획을 세웠고 이듬해 X 프로토콜 11버전(X11)이 발표되었습니다. MIT 라이선스로 제공되었기 때문에 다양한 컴퓨터 회사에서 X를 기반으로 하는 GUI 프로그램을 개발할 수 있게 되었습니다.
1988년에는 이들 회사가 조직한 X 컨소시엄이 출범하였고 X11R6 버전을 1996년 발표한 이후 해체하였습니다. 같은 해 유닉스 업계가 조직한 오픈 그룹이 창립되었으나, 이들 그룹이 기존 라이선스를 무시하고 X의 유료화를 선언하였습니다. 이에 개발자들은 X11의 인텔 CPU 버전 구현체인 XFree86으로 모여들었습니다. 오픈 그룹이 뒤늦게 유료화를 포기하였으나 이미 마음이 떠난 개발자들은 XFree86 개발에 집중하였습니다.
하지만 XFree86 역시 이후의 X 버전에서 라이선스를 더 제한된 버전으로 바꾸기 시작했습니다. 2003년 XFree86의 코어 팀 소속인 Keith Packard 가 쫓겨나고, 데비안 등 운영체제에서 라이선스 변경을 이유로 XFree86을 지원하지 않기로 거부하였습니다.
2004년에는 오픈 그룹의 후신으로 X.Org 재단이 출범합니다. 이들과 freedesktop.org의 구성원들이 XFree86의 소스코드를 포크(fork)하며 X 서버의 개발 주도권을 차지하였습니다. 이들 그룹이 현재 대부분의 리눅스 계열 운영체제에서 사용하고 있는 X 프로토콜 구현체인 X.Org의 개발을 담당하고 있습니다.
X 윈도 시스템은 학생들이 GUI 인터페이스를 이용해 원격 서버 자원을 이용할 수 있도록 지원하기 위해 개발되었습니다. 서버-클라이언트 모델로 개발하고 X 프로토콜을 적용한 덕분입니다. 따라서 ssh등을 사용해 원격 접속하여 GUI 프로그램을 사용하는 것이 가능합니다.
X11 프로토콜은 확장(익스텐션) 메커니즘을 정의하고 있어 서버에서 새로운 프로토콜을 정의할 수 있습니다. 이러한 확장성이 2025년까지도 X서버를 사용할 수 있게 지탱하고 있습니다. 예를 들어 X 프로토콜이 개발될 당시에는 키보드와 마우스 외의 입력장치를 사용하는 경우는 드물었습니다. 하지만 오늘날에는 터치 스크린, 타블렛 펜, 조이스틱 등 다양한 입력장치를 사용하고 있습니다. 이들 입력장치를 지원하기 위해 XInput 확장이 개발되었습니다. 현재는 멀티터치(두 손가락 이상을 사용하는 터치 기능)를 지원하는 XInput2가 널리 사용되고 있습니다.
컴퓨터 과학에서 투명성(transparency)이란 세부 사항을 보이지 않게 숨겨서 마치 그런 것이 존재하지 않는 것처럼 보이게 만든다(투명하게 만든다)는 의미입니다. X는 클라이언트가 원격에서 접속하더라도 로컬에서 접속한 것과 아무런 차이 없이 X 서버를 이용할 수 있게 프로토콜을 구현하였습니다. 단, 일부 확장을 사용할 경우 네트워크 투명성이 보장되지 않을 수 있습니다.

위 그림은 X의 서버-클라이언트 및 기타 구조를 나타내고 있습니다. X 윈도 시스템은 여러 프로그램이 하드웨어 자원을 공유할 수 있게 개발되었습니다. 리눅스 커널과 연결된 디바이스 드라이버로부터 전달된 키보드, 마우스 등의 입력 장치와 모니터 등의 출력 장치 이벤트는 모두 X 서버가 중개합니다. 그림 우상단에 표기된 Hardware devices 가 이러한 X 서버의 기능을 나타내고 있습니다.
Hardware devices 아래에는 X 서버의 아키텍처가 표현되어 있습니다. X 서버는 크게 DDX(Device Dependent X) 와 DIX(Device Independent X), Extensions, Acceleration Architecture 라는 네 개 구성요소로 이루어져 있습니다. DDX는 하드웨어와 상호작용하는 부분으로 로드 가능한 모듈 형태로 구현됩니다. Acceleration Architecture 는 2D 렌더링 가속을 지원하는 부분입니다.
DIX는 X 서버의 핵심으로 Event Queue를 통해 입력 이벤트를 X의 클라이언트에게 전달합니다. 사용자와의 상호작용을 마친 X 클라이언트는 그 결과를 다시 서버로 전달합니다. 서버는 그 결과물을 Mesa를 통해 그래픽 드라이버로 내보냅니다.
그 외에 Extensions 가 있습니다. 위에서 소개한 XInput 외에도 GLX(OpenGL과 X11을 연결), RandR(X Resize and Rotate; 화면 회전과 크기 변경) 등의 확장이 존재합니다.
X 윈도 시스템의 마지막 구성 요소는 클라이언트입니다. 클라이언트는 Xlib이나 xcb 라는 라이브러리를 사용해 X 서버와 통신합니다. 그 위에는 Pango, Cairo 등의 라이브러리를 볼 수 있습니다. Pango는 텍스트 렌더링을 위해 사용되며 Cairo는 2D 그래픽을 그리기 위해 사용됩니다. 그림에서는 Cairo에서 곧바로 Mesa로 향하는 선을 볼 수 있는데, 이는 Cairo가 하드웨어 가속을 통해 X를 거치지 않고 직접 렌더링을 한다는 의미입니다.
리눅스에서 GUI 구현을 위해 사용하는 GTK+ 와 Qt는 X 백엔드와의 통신을 구현하고 있습니다. GTK+의 경우 gdk/x11/아래에 X의 프로토콜을 사용하여 서버와 통신하는 코드를 확인할 수 있습니다.
wayland(웨이랜드)는 무겁고 오래된 X 윈도 시스템을 더 가볍고 단순하게 만들기 위해 시작된 프로젝트입니다. 특히 발전한 그래픽 개발 환경 덕분에 X 서버가 기존에 담당하던 기능들을 커널이나 자체 라이브러리에서 담당할 수 있게 되었고 코드가 오래되어 유지보수가 어려워진 X에 대한 성토가 이어지며 wayland 프로젝트가 출범하게 되었습니다.


위 두 개의 이미지는 X 서버와 웨이랜드가 각각 이벤트를 처리하는 방법을 나타낸 그림입니다. Compositor라는 새로운 구성요소가 눈에 띕니다. 기본적으로 X는 윈도우의 그림을 직접 그리지 않습니다. 이로 인해 여러 클라이언트 간 버퍼가 겹쳐질 경우 창이 깜빡이거나 잔상이 남는 등의 문제가 발생합니다. 컴포지터는 윈도우 간 우선순위(누가 앞에 있는지)를 계산하는 역할을 담당합니다. X 서버는 클라이언트의 요청 결과를 컴포지터로 전달, 그 결과를 받아 그래픽 디바이스로 출력 요청을 보내는 과정을 필요로 합니다.
반면 wayland는 그 자체가 서버이자 컴포지터의 기능을 겸비합니다. 불필요한 IPC(Inter-Process Communication)가 없기에 성능이 향상될 수 있습니다. 또한 그래픽 가속 기능이 제공되며, 최신 그래픽 기술과의 연동이 손쉽게 이루어질 수 있다는 장점이 있습니다.
...만, 여전히 많은 어플리케이션이 X를 기반으로 작성되어 있고 이를 웨이랜드로 변경하기 위해서는 상당히 오랜 시간이 걸릴 수 있습니다. 웨이랜드에서는 X 기반 어플리케이션을 웨이랜드에서 실행하기 위한 XWayland 호환 레이어를 제공하고 있으나, 몇몇 확장은 제공하지 않아서 울며 겨자먹기로 X를 사용해야 하는 경우도 있습니다. 또한 일부 개발자들은 변경이 잦은 웨이랜드 프로토콜에 문제를 제기하고 있습니다. 마지막으로 아직 웨이랜드가 X 에 비해 성능이 특별히 좋지 않다는 불만도 제기되고 있습니다. 여기에는 X가 개발되던 시기에 비해서 리눅스 GUI를 개발하기 위한 자원 투자가 많이 줄어들었다는 현실적인 이유도 존재합니다. 하지만 웨이랜드는 느리지만 꾸준히 발전하고 있으므로 언젠가는 X를 대체할 리눅스 데스크탑의 de-pacto standard로 자리매김할 수 있지 않을까 기대해봅니다.