Rift - macOS용 타일링 윈도우 매니저
(github.com/acsandmann)- macOS에서 사용할 수 있는 오픈소스 타일링 윈도우 매니저로 성능과 사용성에 중점을 두고 개발 중
- 시스템 코드 보안(SIP) 비활성화 없이 동작하며, macOS의 "** Displays have separate Spaces**" 옵션과 호환되는 몇 안 되는 윈도우 매니저
- i3/sway 및 bspwm과 유사한 다양한 레이아웃 스타일을 지원함
- Mission control 스타일의 워크스페이스 탐색 및 트랙패드 제스처 같은 macOS 네이티브 환경과의 자연스러운 연계를 제공
- 애니메이션 성능과 사용자 경험에 중점을 두며, 설정의 핫 리로드와 외부 프로그램과의 연동 기능이 특징
- 기존 macOS용 타일링 윈도우 매니저인 Aerospace의 장점(성능, 유연성 등)을 일부 계승하면서도, 애니메이션 지원과 다중 디스플레이에서 하나의 디스플레이만 전체 화면으로 활용하는 등 추가 기능을 목표로 함
주요 기능
- 여러 레이아웃 스타일: i3나 sway처럼 창을 격자 형태로 배치하거나, bspwm 스타일의 이진 공간 분할 방식을 지원함
- 메뉴바 아이콘: 모든 워크스페이스와 해당 워크스페이스 내 레이아웃 현황을 시각적으로 표시함
- macOS 미션 컨트롤 스타일 탐색: 워크스페이스 간 전환을 시각적으로 쉽게 관리할 수 있음
- 마우스 포커스 자동 전환 및 자동 올리기 기능을 제공함
- 창 드래그 시 위치 교환이 가능하며, 애니메이션이 부드럽게 동작함
- 트랙패드 제스처 이용 시 macOS 네이티브처럼 워크스페이스 전환이 가능함
- 실행 중 설정 변경(핫 리로드) 을 지원하여 실시간 구성이 매우 용이함
- Sketchybar 등 서드파티 프로그램과의 인터페이스 및 CLI 또는 mach port를 통한 연동 지원
- 워크스페이스 변경이나 창 변화 시 신호(Signals) 를 외부로 보낼 수 있으며, 신호는 CLI 또는 mach 연결을 통해 송출할 수 있
- Rust 언어로 100% 개발됨
Hacker News 의견
-
예전에 i3를 정말 많이 사용했음. i3는 엄청 유연하고 설정도 자유로워서 단순히 창을 옮기는 것 그 이상을 할 수 있음. 그런데 Mac으로 넘어오고 나서는, 기능이 많으면서도 안정적인 타일링 창관리자를 못 찾았음. 여러 옵션을 시도해보고 지금은 그냥 Rectangle을 사용하게 됨. Rectangle은 진짜 창관리자가 아니라, 창을 왼쪽/오른쪽/상단/하단이나 3/4/6 분할로 쉽게 움직이도록 단축키만 제공해줌. 내 사용패턴 중 80% 정도를 커버하고, 커스텀 설정도 필요 없고 예기치 못한 행동도 없어서 만족스럽게 사용 중임. 나이 들어서 여러 커스텀 설정에 시간 들이는 게 힘들기도 함. Rectangle 공식 사이트
- Rectangle에서 정말 마음에 드는 기능이 todo 모드임. 실제로 할 일 관리는 안 쓰지만, 어떤 창을 항상 표시하도록 고정하고, 전체 창 단축키가 자동으로 그에 맞게 조정돼서 정말 편함
- Rectangle이 Spectacle 단축키 옵션을 지원해줘서 너무 고마움. 언젠가 기본 단축키도 익힐지 모르겠지만 지금은 이미 손에 익어서 계속 이 방식 유지 중임
- Rectangle과 Apptivate 조합 덕분에 몇 년간 i3 대체제를 찾던 고민이 끝났음. Rectangle로 창 이동, Apptivate로 super+숫자로 창 전환—정말 i3에서 쓰던 움직임 그대로 구현됨
- 비슷한 경험인데 나는 Rectangle 대신 Divvy를 사용함. Divvy 공식 사이트
- Rectangle 추천함. 리눅스에서 Mac으로 넘어올 때 적응이 훨씬 쉬웠음
-
5k/6k 디스플레이에서는 일반적인 타일링은 한계가 있음—창 크기가 너무 커져버림. 그래서 moon 같은 앱이 훨씬 낫다고 생각함. 윈도우에서는 Moom 같은 앱이 없어서 komorebi 같은 타일링 매니저를 씀. 여러 운영체제와 디바이스를 오가는 사람으로서, rift가 범용적인 alt+hjkl 같은 키 바인딩을 지원하지 않는 게 아쉬움. 초고해상도나 울트라와이드 모니터에서는 이런 창 배치가 필수라고 봄 (komorebi에서 지원함)
- 붙여넣은 아스키 도면이 잘 안 보이면, 코드 블록은 공백 네 칸을 들여쓰면 HN에서 코드처럼 보여짐
- komorebi가 곧 macOS에도 나온다고 함 komorebi macOS 소개 영상
-
많은 사람들에겐 부족할 수 있지만, 나처럼 Mac에서 주로 창 하나만 쓰거나, 외장 모니터를 연결할 때만 두 화면 쓰는 경우엔 이 기본 기능MacOS 공식 윈도우 스플릿 가이드면 충분함(나는 헤비한 타일링 유저가 아님)
- 이 기능, Tahoe 맥에서만 쓸 수 있는 거였는지 궁금함. 지금까지 몰랐음
- 이런 기능이 있다는 걸 전혀 몰랐었음—정보 고마움
-
macOS에서 전체 화면과 트랙패드 제스처가 정말 매력적으로 느껴지는 이유는, 대다수의 경우 하나의 창에서만 작업하기 때문임. 하지만 터미널·에디터·브라우저DevTools·로그·문서 같이 여러 창을 동시에 띄워야 할 땐 레이아웃 예측이 정말 중요해짐. 타일링 툴은 단순히 창 두 개 나란히 두는 게 아니라,
- 컨텍스트 스위칭 오버헤드를 크게 줄여줌(키보드만으로 창 전환/재배열)
- 자주 쓰는 작업 레이아웃을 프로젝트별로 복제 가능
- 초고해상도 화면에서 정확한 분할이 훨씬 유용
나는 Mac에서 Rectangle이나 Moom으로 80% 정도는 해결하고, 그 외엔 Aerospace나 Rift 활용 중임. 창 개수나 전환 빈도가 높을 때 타일링 창관리자의 쓸모는 확실해짐
-
한때 나만의 창관리자를 만들려고 했지만, macOS에는 제대로 된 API가 없어서 금방 포기했음. 실질적으로는 접근성 API를 해킹해서 써야 함. 이 프로젝트도 Objective C 바인딩과 접근성 API를 사용하는데, 디버깅이나 기능 구현, 또는 어떤 툴을 주로 썼는지 궁금함
- 접근성 프레임워크는 단순히 "해킹"이라고 부르기엔 굉장히 잘 설계된 도구라고 생각함. 최근 한 달 동안 Rust로 유사 프로젝트를 만들면서 여러 macOS 프레임워크 바인딩을 다뤘는데, 그렇게 무섭지 않음. 개발환경은 Rust와 rust-analyzer, 그리고 애플 문서와 objc2 문서만 켜두면 충분하고, XCode 같은 복잡한 세팅도 필요없음
-
나도 최근 Aerospace를 정말 손에 맞게 세팅하느라 험난한 시간(yak shaving)을 겪었음. 많은 단축키가 겹칠 때 다들 어떻게 해결하는지 궁금함. 나는 hjkl 조합이 손에 익어서 이걸로 대부분 매핑하고 싶어지는데, Aerospace의 모달 기능이 단축키 충돌을 조금은 해결해줌. 다들 궁극적으로 어떻게 세팅하나?
- 보통 별다른 해결책 없이 써버리는 것 같음. 나도 일상적으로 쓰다보면 단축키 충돌이 금방 튀어나옴. Aerospace를 1년 정도 쓰면서 alt+space를 리더키로 해서 모든 걸 숨겨둠. Aerospace의 노멀모드에 alt-shortcut을 몇 개 두고 {hjkl}로 창 이동, 나머진 따로 모드에서 처리함(예: ‘go-to’, ‘move-to’ 모드로 레터/숫자에 맞춰 빠르게 창 이동). 터미널에서 zellij/tmux, leader key 기반 사용성의 확장판처럼 느껴져서 만족 중임. 한 가지 고충은, Aerospace가 화면 전환 후 창을 숨겨놔서, 아래쪽 구석에서 찾느라 헤매는 경우가 많음
- Aerospace 써봤는데, 기본 세팅이 모든 alt+알파벳(26개)을 각기 다른 워크스페이스에 할당해서 각 앱에서 쓸 수 있는 emacs류 단축키들을 다 날려버림. 기본 키맵핑이나 사용법에 대한 튜토리얼조차 없고, 명령어만 잔뜩 나열되어 있음. 최근에 sway, hyprland 같은 리눅스 환경에서도 꽤 많은 고생을 했는데(심지어 리눅스 부트로더/디스크 암호 관련 작업도 했음), 그 정도로 불친절한 소프트웨어는 드물다고 느낌. 그래서 Aerospace는 지우고 Rift를 차기 후보로 고려 중, 아니면 직접 창관리자를 구현할 수도 있을 것 같음—타일링 창관리자 자체가 워낙 "내가 필요한 기능 직접 만들겠다"는 식의 취향 타협이라서
- 나도 비슷한 방식으로 카라비너(Karabiner)로 외장키보드의 오른쪽 Option을 Option+Shift(A1)로, 오른쪽 Control을 Control+Option+Shift(A2)로 바꿨음. Aerospace 설정에서 포커스 이동은 A1+hjkl, 창 이동은 A2+hjkl. 워크스페이스 전환은 A1+ui, 창 워크스페이스 이동은 A2+ui. 화면(모니터) 전환은 A1+m, 창 화면 이동은 A2+m. 실제로 가장 자주 쓰는 단축키 조합이고, 앱들끼리 단축키가 겹치면 해당 앱 단축키를 바꿔서 충돌을 피함. 더 확장해볼 만도 한데, 지금 형태로도 충분히 잘 작동함
- meh(컨트롤+알트+쉬프트)와 hyper(컨트롤+알트+쉬프트+커맨드) 단축키 활용함. caps lock을 길게 누르면 meh, 짧게 두드리면 esc로 매핑함. 덕분에 많은 단축키들을 한 손에 쏙 들어오게 만들었음. 예를 들면 meh+숫자로 space 전환, 터미널 핫윈도우는 meh+스페이스, 창 포커스 역시 meh+hjkl
-
Hammerspoon을 활용하면 직접 창매니저를 만들 수 있음. 나는 Divvy가 제공하는 모달(명령 단일키로 레이아웃 전환) 방식을 좋아하는데, 아쉽게도 더 이상 유지보수가 안 되고 있음. 그래서 OpenAI Codex로 직접 모달 창관리자를 만들어봄 hammerspoon용 윈도우매니저 소스코드. 이런 접근법 공유하면 재미있을 것 같음!
- 나도 divvy를 꾸준히 써왔는데, 유지보수가 끊긴 줄 전혀 몰랐음… 그래도 이미 필요한 기능은 다 있어서 불편함은 없음. 혹시 추가됐으면 하는 기능이 있다면 궁금함
- 나는 MiroWindowsManager(Hammerspoon 플러그인)로 필요 기능을 모두 구현함. 3가지 chord division 방식으로 어떤 창이든 원하는 분할에 핫키만으로 즉시 배치할 수 있음. 정말 몇 초 만에 원하는 대로 창 배치 가능함
-
Swish만큼은 맥북 트랙패드 유저라면 어떤 앱보다 압도적임 Swish 공식 사이트
- 확실히 "highly opinionated"라는 네이밍이 실감남 ;). 그런데, 내가 Divvy를 지속적으로 선호하는 이유는, 내 커스텀 키보드 단축키가 항상 트랙패드든 외장키보드든 똑같이 동작하기 때문임. Divvy 공식 사이트
-
이거(nix flake)로 누가 세팅해본 사람 있음? yabai 이후로 여러 창관리자를 테스트 중인데, Aerospace가 이벤트 처리 문제인지 sketchybar 예쁜 워크스페이스 표시 목적일 때 가끔 렉이 걸림. 다음엔 이걸(rift)도 써볼까 함
- 참고로 여기 있음 rift용 nix flake 레포
-
왜 타일 창관리자가 macOS에서 필요할지 모르겠음. 창을 나란히 둘 필요가 얼마나 자주 있을지. 대부분 앱을 전체화면으로 띄우고 4핑거 스와이프로 창 바꾸면 충분하지 않음? 누가 설득 좀 해주길 바람
- 진짜 자주 씀. Slack을 오른쪽 1/4에, 나머지는 브라우저/터미널/IDE 등 조합에 따라 다양하게 배치. 종종 브라우저+로그 tail, 각 앱 내부에서도 멀티뷰/터미널 등으로 나눔. 브라우저에서도 페이지 나란히 띄워서 보는 경우 잦음
- 꼭 타일링 창관리자가 "필요하다"고 할 생각은 없음. 하지만 "그냥 전체화면 만들고 4핑거 스와이프"가 잘 맞는 건 본인(you you)만 그럴지도. 나는 제스처, 애니메이션, 여러 데스크탑(스페이스) 거의 다 꺼버렸음. 전체화면 앱끼리 넘어가는 속도가 너무 느리고, 필요한 앱에 바로 가려면 여러 번 스와이프를 겹쳐야 함. 앱 순서를 머릿속으로 계산하면서 몇 번 넘어가야 하는지 신경 쓰는 게 싫음. 바로 원하는 앱을 즉시 띄우고 싶음
- MacOS는 아니지만, 리눅스에서 타일링을 쓰는 이유와 비슷할 거라 생각함. 노트북 화면만 쓸 땐 전체화면이 낫지만, 모니터가 커질수록 창을 나란히 써야 할 이유가 많아짐. 문서/메일, 에디터/터미널/VCS, 코드/문서, 템플릿/웹, 회계/은행, 파일관리 등, 서로 다른 앱을 동시에 보며 작업할 일이 많아서 타일링이 훨씬 생산적임
- 확실히 옆에 여러 창이 띄워져 있으면 좋을 때가 있음. 예를 들어 웹브라우저/문서/IDE 같이 여러 작업을 하는 경우, 또는 한 앱에서 다 작업하기엔 화면을 다 쓰지 않을 때. 실제로 대부분의 앱은 풀스크린 사이즈가 필요 없고, 오히려 1/4 타일이 편할 때도 많음. 나는 평소엔 풀스크린+가상 데스크탑을 자주 쓰지만, 작업마다 다름
- 예전에는 스페이스(데스크탑 전환)를 많이 썼는데, 큰 모니터에서는 오히려 한 화면에 다 띄우는 게 더 편함. 난 32인치 모니터 3대를 쓰고(좌우는 세로 배치) IDE를 제외하고 풀스크린 거의 안 씀. 화면 분할은 언제나 작은 화면 여러 개를 동시에 갖는 셈이라서, 굳이 어떤 창이 어느 데스크탑에 있는지 찾지 않아도 되어 단순하고 효율적임. 크롬만 여러 스페이스에서 뜨면 cmd-tab으로 원하는 창이 선택되지 않을 때도 많고, 결국 직접 찾아 들어가야 해서 귀찮음. 반면 랩탑만 쓸 때는 화면이 작으니 가상 스페이스 위주로 창을 관리함. Slack, 여러 개의 chrome, terminal, IDE, postman, datagrip 등 모든 앱을 단축키 한 번에 전환하고, 화면 전체를 바꾸지 않아도 됨. 실제 화면 8개를 항상 띄워놓는 셈이라 생산성이 극대화됨. r-cmd로 각 앱에 집중할 수 있어 전환도 엄청 빠름. 가상 데스크탑 돌아다닐 필요가 없으니 찾기도 쉬움