현대 데스크톱의 문제와 해결책 — tmux를 운영체제로

AI 요약

저자는 Scott Jenson의 데스크톱 UX 강연을 계기로 창 관리 방식을 다시 살펴봅니다. 원하는 방향을 한마디로 줄이면 “tmux가 운영체제인 데스크톱”입니다. 스크롤 가능한 작업 공간, 세션 유지, 분리와 재접속 같은 tmux의 장점을 일반 사용자도 쓸 수 있게 만들고 싶다고 설명합니다.

지금의 창 관리는 달라진 사용 방식에 맞지 않습니다

노트북과 외부 모니터를 하루에도 여러 차례 오가는 사용자는 화면이 바뀔 때마다 창을 다시 정리합니다. 두 대의 모니터를 하나의 넓은 화면처럼 쓰기보다, 한쪽은 작업용으로 두고 다른 쪽은 채팅이나 할 일 목록처럼 곁눈질할 정보에 쓰는 경우도 많습니다. 저자는 2001년 연구에서도 두 번째 모니터를 이런 식으로 활용하는 모습을 확인했지만, 운영체제는 여전히 각 화면의 역할을 파악하지 못한다고 지적합니다.

사용자의 창 배치 방식도 하나로 통일되지 않습니다. 창 하나를 화면에 가득 채우는 사람, 큰 창과 작은 창을 함께 두는 사람, 여러 창의 위치를 직접 조율하는 사람이 있습니다. 여기에 발표 화면에 드러나도 되는 창과 숨겨야 하는 창의 구분도 필요합니다. 저자는 2004년 연구에서도 비슷한 사용자 유형과 공개·비공개 구분이 관찰됐다고 짚습니다.

브라우저도 단순한 앱이 아닙니다. 탭은 문서와 작업 흐름을 담고, 웹 앱은 기존 데스크톱 앱이 맡던 일을 합니다. 하지만 운영체제는 브라우저를 하나의 앱으로 취급합니다. 파일 시스템의 경계도 약해졌습니다. 메모, 메시지, 팀 채팅, PDF가 각 앱 안에 머물고, 사용자가 직접 꺼내지 않으면 운영체제가 일관되게 찾아보기 어렵습니다.

연구와 기존 제품에서 찾은 단서

저자는 Henderson과 Card의 1986년 연구 ‘Rooms’를 살펴봅니다. 연구진은 화면을 메모리처럼 보고, 사용자가 작업 중에는 창 두 개에서 열 개 정도로 이뤄진 작은 집합을 오간다고 설명했습니다. 프로그램 사용 시간의 약 98%는 이런 집합 안에서 보내고, 나머지 약 2%인 작업 전환에 실행 비용의 절반가량이 든다고 분석했습니다. ‘Rooms’는 다음 작업에 필요한 창 집합을 미리 준비해 사용자가 전환 과정에서 겪는 인지 부담, 연구 표현으로는 “사용자의 지식 페이지 폴트”를 줄이려 했습니다.

또 다른 연구는 사람들이 오랫동안 한 가지 일에만 집중하기보다 하루에 여러 작업 영역을 오가며 몇 분 단위로 일한다고 보고했습니다. 저자가 원하는 방향에 가장 가까운 WindowScape는 창을 고정된 그룹에 넣도록 강제하지 않았습니다. 배치가 달라질 때마다 화면 상태를 사진처럼 저장해, 하나의 창을 여러 작업 장면에서 재사용하게 했습니다. 다만 그 사진은 시간이 지나면 사라졌습니다.

타일링 윈도 매니저는 겹치는 창을 정리하는 문제를 줄이지만, 설정 파일을 다뤄야 하는 진입 장벽이 크고 작업 공간을 좌우로 스크롤하는 방식이 부족하다고 저자는 봅니다. Linux용 Niri는 스크롤형 타일링을 이미 제공하지만, 일반 사용자가 쓰기 쉬워져야 한다고 덧붙입니다. 기존 시도도 검토합니다. Windows Timeline은 여러 앱의 활동을 모았고, 취소된 Windows Sets는 앱과 웹 페이지를 작업별 탭 묶음으로 구성하려 했습니다. macOS Stage Manager, KDE Activities, PWA 설치도 각각 작업 공간이나 앱 창을 다루지만, 기본 기능이 아니거나 수동 설정에 기대는 한계가 있다고 분석합니다.

제안하는 데스크톱: 작업 단위 캔버스

저자의 구상은 데스크톱 전체를 무한한 캔버스로 보고, 실제 디스플레이를 그 일부를 비추는 뷰포트로 다루는 방식입니다. 창의 좌우 순서, 스크롤 위치, 입력 포커스, 작업 소속은 유지합니다. 화면 폭이 달라지면 열 너비를 결정론적으로 다시 배치하고, 보이지 않는 창은 스크롤 영역에 남깁니다. 모니터를 분리하면 뷰포트 하나가 사라지고, 다시 연결하면 이전 위치를 비춥니다. 두 모니터를 쓸 때는 하나를 주 작업 화면, 다른 하나를 곁눈질 정보 화면으로 둘 수 있습니다.

최대화 창을 선호하는 사용자, 큰 창과 보조 창을 함께 쓰는 사용자, 여러 창을 조율하는 사용자는 같은 캔버스에서 열 수를 다르게 쓰면 됩니다. 창이나 탭에는 공개·비공개 속성을 붙입니다. 새 디스플레이를 연결하거나 화면 공유를 시작하면 기본 화면은 발표 준비 상태로 둡니다. 사용자가 작업이나 창을 선택하거나 캔버스 확장을 명시하기 전까지 비공개 정보가 드러나지 않게 하자는 제안입니다. 브라우저 탭은 브라우저 안에만 묶어두지 않고 실제 창으로 분리해 관련 작업에 붙입니다.

작업 구성을 돕는 인터페이스로는 로컬 LLM을 제안합니다. 사용자가 자연어로 정리를 요청하면 모델은 제한된 동작만 제공하는 MCP 서버를 조회하고, 바꿀 화면 배치를 미리 보여줍니다. 모델이 윈도 매니저를 직접 조작하지는 않습니다. 사용자가 확인한 뒤 결정론적인 실행기가 변경을 적용합니다. 고정한 창은 실행기가 건드리지 않도록 해 모델의 실수도 막습니다. 반복 작업은 한 번 정리한 구성을 다시 쓰고, 새로운 작업이나 디스플레이처럼 드문 상황에서만 분류와 확인 절차를 거친다는 구상입니다.

실험에서 드러난 한계

저자는 Linux 가상 머신에서 아이디어를 구현하려다 설계의 약점을 발견합니다. 첫째, 화면 포커스와 입력 기록을 분석해 어느 모니터가 주 작업용인지 알아내려는 방식은 사용자를 감시하는 데이터에 기대게 됩니다. 데이터를 로컬에 두고 일시적으로만 쓴다고 해도, 현재 운영체제보다 더 많은 행동 정보를 수집해야 합니다.

둘째, 비공개 창을 화면 왼쪽에 두고 사용자가 자리를 비우면 공개 화면 쪽으로 이동시키려던 아이디어는 실패했습니다. 사용자가 읽느라 입력을 멈춰도 시스템은 이를 유휴 상태로 오인해 화면을 움직입니다. 넓은 모니터에서는 창을 옆으로 옮겨도 주변 사람이 볼 수 있습니다. 보행자가 화면을 보는 상황을 시스템이 감지하지 못하므로, 가림만으로 프라이버시를 지키기 어렵습니다.

셋째, 창을 추가만 하고 옮기거나 지우지 않는 원칙은 공간 기억을 지키지만 작업이 끝난 뒤에도 화면이 계속 커집니다. 무한 캔버스는 결국 무한한 책상이 되고, 저자는 WindowScape의 사진이 사라지는 방식이 사실상 정리 기능, 즉 가비지 컬렉터 역할을 했다고 다시 평가합니다. 창을 움직이지 않은 채 비활성 상태로 만드는 방법도 가능성으로 남지만, 무엇을 비활성화할지는 여전히 해결해야 합니다.

저자는 이 구상이 완성된 설계라고 주장하지 않습니다. 기존 운영체제가 해결하지 못한 문제를 직접 실험하면서, 오래된 연구와 실패한 제품에서 얻은 아이디어를 다시 검토합니다. 제대로 작동하는 시연물을 만들려면 주말을 많이 써야 할 만큼 구현도 어렵다고 밝힙니다.

Lobsters 반응

• @lojikil — 제목만 봤을 때는 “타일링 윈도 매니저나 Scheme Constraints WM과 뭐가 다르지?”라고 생각했는데, 기대보다 훨씬 좋았습니다. 연구를 흥미롭게 정리했네요. 한 가지 빠진 방향으로 ZUI, 즉 줌 가능한 사용자 인터페이스도 있습니다.
  • @raoulmillais — 동의합니다. 조사 범위가 넓어서 제목을 정하기 어려웠습니다. 원래 제목인 “Make tmux the OS”는 내용을 잘못 전달한다고 생각해 조금이라도 설명적인 제목을 붙이려 했습니다. 더 나은 제목 제안도 환영합니다.
• @wwfn — 진전과 막다른 길을 재미있게 살펴봤습니다. Windows Timeline은 흥미로운 개념인데, 있는 줄도 몰라 아쉽네요. 제가 브라우저 콘텐츠를 창 시스템에 넣으려던 복잡한 방식은 Tridactyl의 tabgrab(여러 탭은 Alt-Enter), tabdetach, tabpush로 수동 처리합니다. Sibebery Tree의 도움도 받습니다.
• @alevizio — 끝부분의 “아무것도 사라지지 않는다”는 대목이 가장 좋았습니다. 실제 책상은 물건을 옮기지 않고 쌓아둡니다. 쌓인 깊이로 얼마나 오래됐는지 알 수 있죠. 창도 제자리에서 흐리게 하거나 작게 만드는 식으로 비활성화하면, 공간 기억을 지킬 수 있을 것 같습니다.

원문: matduggan.com / 번역·요약: Trawling