tmux를 OS로 만들자

• 다만 두 회사가 전혀 시도하지 않는다기보다 매우 보수적으로 시도한다는 쪽에 가까움
• 오늘날 당연하게 여기는 컴퓨터 사용 방식 중 상당수는 이미 사라진 하드웨어 제약을 우회하던 방법임

• 큰 모니터 하나와 작은 모니터 두 개는 같은 경험이 아님. 주 화면에서는 터미널/tmux/브라우저로 일하고, 보조 화면에는 할 일 목록, 업무 채팅, 이메일처럼 가끔 보는 정보를 두는 식임
• Grudin은 2001년에 이미 주 화면의 집중 작업과 보조 화면의 주변 정보 확인을 관찰했지만, OS는 여전히 화면별 역할을 알지 못함

• 최대화형은 큰 창 사이를 Command + Tab이나 Dock으로 전환함
• 준최대화형은 큰 주 창 옆에 상태나 채팅을 확인할 작은 창을 둠
• 배치형은 여러 창의 위치와 크기를 세심하게 조정함

• 2004년 연구 “Revisiting Display Space Management: Understanding Current Practice to Inform Next-generation Design”에서도 같은 세 가지 사용 유형과 공개/비공개 구분을 확인함

• 터미널의 Vim에서 Terraform 코드를 작성하면서 공급자 문서를 참고하고, 같은 문서 탭을 티켓 업데이트에도 다시 사용함
• 하나의 탭이 여러 작업에 속해야 하는지, 더 단순한 방식이 가능한지는 별도로 풀어야 할 문제임

파일시스템은 사용자 작업 전체를 대표하지 못함

• Apple Notes의 메모, iMessage의 메시지, Teams와 Slack의 콘텐츠는 각 앱 안에 있으며, 밖으로 꺼내면 복사본이 됨
• Firefox에서 보는 PDF도 사용자가 별도 동작을 해야 OS의 파일로 저장됨
• Windows 95와 System 7 시절의 흐름은 파일 생성, 앱으로 열기, 저장, 전달이라는 연쇄였고, 모든 단계가 OS에서 볼 수 있는 파일을 전제로 했음. 현대 앱에서는 이 전제가 무너짐
• 모든 앱에 같은 저장 시스템을 강제하자는 뜻은 아니며, 약해진 파일시스템 추상화 자체에는 장점이 있을 수도 있음
• 2004년 CHI 논문 “Stuff goes into the computer and doesn't come out”도 같은 종류의 문제를 다룸

• 화면은 RAM, 닫힌 창은 디스크로 밀려난 페이지에 해당하며, 사용자는 보통 2~10개의 작은 창 집합 안에서 작업함
• 프로그램이 시간의 약 98%를 한 작업 집합 안에서 보내지만 실행 비용의 약 절반은 나머지 2%의 집합 전환 중 발생한다는 비유를 바탕으로, 다음 집합을 미리 준비하려 함
• 목표는 사용자의 “knowledge faulting”, 즉 필요한 맥락을 다시 불러오는 부담을 줄이는 것이었음

• 동반 논문의 제목 “Constant, constant, multi-tasking craziness”도 참가자의 실제 발언에서 가져옴
• 장시간 한 작업에 집중하는 모델만으로는 실제 업무를 담기 어려움

• 창을 하나의 그룹에만 넣게 하면 새 창이 어디에 속하는지 미리 결정해야 함
• 사진 모델에서는 동일한 창이 여러 사진에 등장할 수 있으므로, 여러 작업에서 같은 창을 쓰는 관계를 자연스럽게 표현할 수 있음
• 처음에는 사진이 사라지는 점을 보완해야 할 결함으로 봤지만, 직접 실험한 뒤에는 그 소멸이 정리 기능을 했다는 쪽으로 생각이 바뀜

• 설정 파일 편집이나 저장소 복제부터 요구하는 사용 방식은 일반 사용자용 기본 환경이 되기 어려움

• macOS Spaces처럼 작업공간을 미리 나누지 않고, 무한한 공간에서 다른 일을 시작할 수 있어야 함
• Niri는 이미 이 핵심 설계를 구현하고 있으며, 더 쉽게 쓸 수 있도록 만드는 과제가 남아 있음

• Arc는 탭을 상단 대신 사이드바로 옮기고 OS의 창 역할까지 상당 부분 흡수함
• 관련 화면과 설계 분석은 Arc 디자인 가이드에서 확인할 수 있음

• 모든 활동을 기록하는 방식은 감시처럼 느껴졌고, 원하지 않는 Edge 기능 노출 때문에 브라우저 홍보처럼 보이기도 했음

• OS가 앱과 웹 콘텐츠를 작업으로 묶었다는 점에서 이번 구상과 가장 가까운 시도임
• 내부 전략과 앱 호환성 혼란 속에서 중단됐으며, 이를 살릴 만큼 강한 사용자 요구도 없었음

• iPad식으로 한 번에 하나를 쓰고 빠르게 전환하는 흐름에 치우친 반면, 데스크톱에서는 두세 가지가 함께 작동해야 함

• 다만 설정과 관리가 지나치게 수동이며, 직접 활성화해야 하는 기능은 정작 가장 필요한 사람이 설정하지 않기 쉬움
• KDE 디자인 문서도 참고할 만함

• 9월 23일 이후 수십 개 문서를 다룬 뒤 9월 28일에 확인해도 기대한 최근 항목을 찾지 못했으며, 오류인지 다른 기준인지도 불명확했음

• 저장 위치가 Slack인지 iCloud인지 신경 쓰지 않아도 되어야 함
• Microsoft의 유사 시도는 호응을 얻지 못했지만, 통합해서 본다는 개념 자체는 유효하다고 봄

• 창의 가로 순서, 스크롤 위치, 입력 포커스, 작업 소속은 바꾸지 않음
• 열 너비만 반응형 레이아웃처럼 결정론적으로 재배치하고, 오른쪽에 들어가지 않는 창은 스크롤 영역으로 남김
• 두 화면은 집중 작업과 주변 정보 영역을 각각 비추며, 도킹 해제 시 두 번째 뷰포트만 사라짐
• 다시 도킹하면 각 뷰포트가 이전에 보던 영역을 복원함

• 키 입력의 약 90%를 받는 화면은 주 화면, 계속 보이지만 거의 포커스를 받지 않는 창은 주변 정보로 판단함
• 시선 추적이나 수동 설정 없이 구분하고, 작은 노트북 화면에서는 주변 정보를 얇은 띠로 축소함

• 최대화형은 전체 너비의 한 열, 준최대화형은 한 열과 주변 정보 띠, 배치형은 여러 열을 사용함
• 특정 사용 습관을 강요하지 않아야 기본 환경으로 채택할 수 있음

• 이미 알려진 화면은 이 절차를 생략함
• 화면 공유도 케이블 없는 외부 화면 연결과 같은 사건으로 취급함

• 로컬 LLM이 제한된 명령 목록을 가진 MCP 서버로 정보를 조회하고 배치 미리보기를 만듦
• 모델은 창 관리자를 직접 조작하지 않으며, 사용자가 y로 승인해야 실행함

• 네트워크 저장소의 파일을 수정해 결과를 채팅에 붙이거나, 티켓 확인부터 Vim 작업, 업데이트, PR 생성과 검토 요청까지 이어지는 흐름을 한 번 정리해 재사용함
• 설정이 복잡한 JSON이어도 주된 독자가 모델이라면, 설정 파일 자체가 사용자 인터페이스일 필요는 없음

• Kirsh와 Maglio의 인식적 행위(epistemic action) 연구%20on%20distinguishing%20epistemic%20from%20pragmatic%20action.pdf)에서 Tetris 플레이어는 생각하기 위해 필요한 횟수보다 더 많이 조각을 회전시킴
• 창 배치 역시 사고의 일부이므로, 도우미가 중간에 최적화하면 작업을 방해할 수 있음

• 한 가지 대응은 모델이 제안만 하고 결정론적 실행기가 고정된 항목의 변경을 거부하도록 하는 것임

• 전역 단축키 드롭다운과 스크롤 타일 같은 일부 요소는 동작하지만 여전히 투박함
• 작동하는 데모만 만들기 위해서도 여러 주말에 걸친 작업이 필요할 것으로 예상함

프라이버시 중심 설계가 감시와 닮은 데이터를 요구함

• 주 화면과 주변 정보 창을 알아내려면 어느 화면에 키 입력이 가고 어떤 창이 포커스를 받는지 시간에 걸쳐 관찰해야 함
• 로컬에 일시적으로만 보관해도 상당한 행동 데이터가 필요하며, 이런 데이터 수집은 과거의 유사 시도를 좌절시킨 요인이기도 함

유휴 상태 기반 숨김은 읽기를 방해하고, 지나가는 사람은 막지 못함

• 초기 구상은 사적인 창을 왼쪽, 공개 창을 오른쪽에 두고 유휴 상태가 되면 공개 영역으로 이동하는 방식이었음
• 읽는 동안에도 입력은 멈추므로, 콘텐츠가 사용자 눈앞에서 사라지는 문제가 발생함
• 넓은 화면에서는 왼쪽에 놓인 사적인 창도 행인에게 그대로 보이며, 그 행인의 존재는 감지할 수 없음

무한 캔버스와 추가 전용 규칙은 정리를 막음

• 공간 기억을 절대적으로 보존하면 작업이 계속 쌓여, 지저분한 책상을 무한히 넓힐 뿐임
• WindowScape에서 사진이 사라지는 동작은 사실상 가비지 컬렉터 역할을 했음
• 항목을 이동하지 않고 휴면 상태로 보내는 기능이 필요하지만, 무엇을 정리할지 결정하는 일은 추가 전용 원칙과 충돌하며 실제 캔버스도 빠르게 부담스러워졌음