한 대의 컴퓨터에 마우스를 여러 개 연결하고, 화면 안에 커서를 여러 개 띄워 여러 사람이 동시에 조작한다는 발상은 오래전부터 있었지만 실제로 쓸 만하게 구현된 적은 드물다. 개발자 blinry는 최근 3주 동안 리눅스와 웨이랜드(Wayland) 환경에서 이 기능이 얼마나 지원되는지를 직접 파고들었고, 그 과정에서 만든 도구와 패치한 라이브러리들을 함께 공개했다. 결론부터 말하면, 아직 빠진 조각이 많지만 웨이랜드의 바탕 구조 자체는 이런 다중 사용자 시나리오를 놀라울 만큼 자연스럽게 받아들이고 있었다.
'시트'라는 개념부터 정리하기
이 주제를 이해하려면 '시트(seat)'라는 용어를 먼저 구분해야 한다. 시트란 한 사람이 함께 쓰는 입력 장치들의 묶음을 뜻한다. 예컨대 마우스 하나와 키보드 하나를 한 시트로 묶으면, 한 컴퓨터 앞에 두 사람이 앉아 각자 자기 시트를 조작하는 구성이 가능하다. 그런데 같은 단어가 두 가지 다른 상황을 가리킨다는 점이 혼란의 원인이다. 하나는 여러 사람이 각자 화면·키보드·마우스를 따로 가지고 서로 간섭 없이 독립적으로 쓰는 '물리적 시트'로, 위키백과가 말하는 멀티시트 구성이 여기에 해당한다. blinry가 다루는 것은 다른 쪽, 즉 여러 사람이 하나의 같은 데스크톱을 공유하면서 화면에 커서가 여러 개 뜨는 '논리적 시트'다. 이 방식에서는 창을 서로 넘겨주거나, 하나의 화이트보드에 함께 그리거나, 같은 프로그램 안에서 직접 협업하는 그림이 가능해진다. 그래서 저자는 제목에 '멀티플레이어'라는 표현을 골랐다.
조사 범위는 리눅스, 그중에서도 웨이랜드로 한정됐다. X11에는 이미 Multi-Pointer X(MPX)라는 다중 포인터 확장이 있지만, 저자는 일상적으로 웨이랜드 컴포지터로 옮겨왔고 웨이랜드 자체의 지원이 훌륭하다는 점을 확인했다. 핵심은 다중 시트 지원이 특정 한 계층이 아니라 프로토콜, 컴포지터, GUI 툴킷, 애플리케이션까지 모든 층위에 갖춰져야 비로소 작동한다는 사실이다. 원격 협업까지 원한다면 VNC 서버 같은 접속 프로그램도 이 개념을 이해해야 한다.
프로토콜과 컴포지터의 지원 현황
가장 밑단인 웨이랜드 코어 프로토콜은 다중 시트를 깊이 있게 내장하고 있다. 모든 입력 이벤트는 wl_pointer나 wl_keyboard에 연결되고, 이들은 다시 wl_seat에 묶인다. 덕분에 어떤 입력이 어느 시트에서 왔는지를 자연스럽게 그룹으로 묶을 수 있고, 시트가 새로 나타나거나 사라질 때 발생하는 이벤트도 정의돼 있다. 문제는 그 위에서 창을 관리하고 그리는 컴포지터들이 이 개념을 얼마나 활용하느냐다. 웨이랜드 참조 구현이었던 Weston은 실제로 여러 커서를 띄우고 각각 독립적으로 창을 옮기게 해주는 첫 사례였으며, 시트별로 창 포커스를 따로 두는 기능까지 갖췄다. 즉 한 시트의 마우스가 어떤 창을 잡으면 그 시트의 키보드 입력이 그 창으로 가고, 다른 시트는 동시에 다른 창을 잡을 수 있다. 다만 설정 과정이 번거로워서, udev 규칙으로 WL_SEAT 속성을 지정해 마우스와 키보드를 같은 시트 이름으로 묶어야 한다.
i3를 웨이랜드로 재구현한 sway 역시 wlroots 0.1(2017년)부터의 지원을 물려받아 시트별 포커스를 포함한 탄탄한 기능을 보인다. swaymsg 명령으로 입력과 시트를 조회하고 배정할 수 있는데, 여기엔 흥미로운 함정이 있다. 장치를 다른 시트로 재배정하면 기존 배정이 교체되는 게 아니라 추가돼, 마우스 하나가 커서 두 개를 동시에 움직이는 상황이 벌어진다. 저자는 이를 고치는 패치와 TUI 기반 설정 도구를 함께 내놓았다. 이 밖에 컴포지터와 창 관리자를 분리하는 River는 자체 입력 관리 프로토콜을 통해 장치·시트를 다루며, 저자가 아끼는 niri는 아직 정식 지원이 없어 두 시트만 되는 임시 패치 수준에 머물러 있다. niri 측은 과거에 애플리케이션 지원 부족을 이유로 도입을 미룬 바 있다.
툴킷과 애플리케이션, 그리고 남은 과제
애플리케이션 계층으로 가면 GTK는 이벤트마다 get_seat 메서드를 제공해 어느 시트의 입력인지 개념적으로 잘 구분한다. 시트 이름을 얻는 방법은 없지만 서로 다른지 비교하는 것만으로도 충분하다. 다만 대부분의 위젯은 여전히 모든 입력을 한 장치에서 온 것처럼 취급하고, 프로그램 실행 후 새로 연결된 장치를 인식하지 못하는 버그도 있다. 게임 쪽에서 자주 쓰이는 SDL은 3.3.4(2025년)부터 이벤트의 which 필드로 시트를 구분하지만, 마우스가 절대 좌표 모드일 때는 이 값이 0으로 고정된다. 상대 모드로 바꾸거나 소스의 특정 라인을 주석 처리해야 실제 장치 ID를 얻을 수 있다. 저자는 SDL 기반 게임 엔진 LÖVE에도 which 값을 콜백으로 전달하는 패치를 만들었다.
현재로선 다중 시트를 실제로 활용하는 완성된 응용 프로그램은 사실상 없다. X11 시절엔 화면 주석 도구 Gromit-MPX가 있었지만 네이티브 웨이랜드는 지원하지 않는다. 그래서 저자는 직접 프로토타입을 만들었는데, 그중 하나가 GTK로 짠 다중 시트 텍스트 위젯이다. 클릭으로 커서를 여러 개 만들고, 각 시트의 입력이 해당 커서 위치에 삽입되는 방식이다. 이 접근의 매력은 CRDT나 운영 변환(OT) 같은 복잡한 동기화 알고리즘 없이도 협업이 자연스럽게 성립한다는 점이다. 물론 유니코드 처리나 텍스트 선택 같은 기본 기능조차 아직 빠져 있어 실용 단계와는 거리가 멀다.
한국 실무자 관점에서 이 조사가 주는 시사점은 두 가지다. 첫째, 웨이랜드는 프로토콜 수준에서 이미 다중 사용자 입력을 전제로 설계돼 있어, 화이트보드나 페어 프로그래밍처럼 한 화면을 여럿이 만지는 협업 도구를 만들 토대가 생각보다 탄탄하다는 점이다. 둘째, 그럼에도 컴포지터마다 지원 편차가 크고 위젯·툴킷의 실제 처리와 완성된 애플리케이션이 비어 있어, 지금 당장 제품에 쓰기보다는 시트 관리자·다중 색상 포커스·시트별 클립보드 같은 세부 UI 문제를 함께 풀어갈 실험 영역에 가깝다는 점이다. 저자가 곳곳에 남긴 '열린 과제' 표시는 이 공백을 함께 메울 사람을 찾는 초대장인 셈이다.