▲

Cocoa-Way – macOS에서 Linux 앱을 네이티브로 실행하는 Wayland 컴포지터

 (github.com/J-x-Z)
1P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • macOS에서 Linux 애플리케이션을 가상머신 없이 실행할 수 있게 하는 Wayland 컴포지터로, Metal/OpenGL 기반 렌더링을 사용해 macOS 창 환경과 자연스럽게 통합됨
  • Unix 소켓을 통한 직접 Wayland 프로토콜 통신으로 성능 손실을 최소화하며, HiDPI 디스플레이 최적화와 서버 측 데코레이션을 지원
  • Rust로 작성되어 있으며, 하드웨어 가속 렌더링을 통해 낮은 지연과 높은 효율을 제공
  • SSH와 waypipe-darwin을 이용해 Linux 호스트의 앱을 macOS 창으로 표시할 수 있음
  • GPLv3 라이선스로 공개되어 있으며, Windows와 Android 백엔드 확장을 포함한 로드맵이 진행 중임

개요

  • Cocoa-Way는 macOS에서 Linux 애플리케이션을 네이티브 환경처럼 실행할 수 있게 하는 Wayland 컴포지터
  • Metal/OpenGL 렌더링을 통해 macOS 데스크톱과 자연스럽게 통합되며, 가상머신 없이 소켓을 통한 직접 Wayland 프로토콜 연결을 지원
  • HiDPI 디스플레이 최적화, 서버 측 데코레이션, 하드웨어 가속 렌더링 기능 포함
  • Rust로 작성되었으며, GPLv3 라이선스로 배포

주요 기능

  • 네이티브 macOS 통합: Metal/OpenGL 기반 렌더링으로 macOS 창 관리 및 시각 효과와 완전한 호환성 유지
  • Zero VM Overhead: 가상화 없이 Unix 소켓을 통한 직접 Wayland 프로토콜 통신으로 성능 손실 최소화
  • HiDPI 지원: Retina 디스플레이에 맞춘 스케일링과 픽셀 정밀도 제공
  • UI 완성도 향상: 그림자, 포커스 인디케이터 등 서버 측 데코레이션 기능 포함
  • 하드웨어 가속: 효율적인 OpenGL 렌더링 파이프라인으로 낮은 지연과 높은 성능 구현

설치 방법

  • Homebrew 설치 (권장)

    • brew tap J-x-Z/tap
    • brew install cocoa-way waypipe-darwin

  • 바이너리 다운로드

    • GitHub Releases 페이지에서 .dmg 또는 .zip 파일 다운로드 가능

  • 소스 빌드

빠른 시작

  • 필수 구성요소: waypipe-darwin 설치 필요
    • brew tap J-x-Z/tap && brew install waypipe-darwin
  • 컴포지터 실행 
    cocoa-way
  • Linux 앱 연결 
    ./run_waypipe.sh ssh user@linux-host firefox
  • SSH를 통해 Linux 호스트의 Wayland 앱을 macOS 창으로 표시

아키텍처

  • macOS 측에는 Cocoa-Way 컴포지터와 waypipe 클라이언트 존재
  • Linux VM 또는 컨테이너 측에는 waypipe 서버와 Linux 앱 존재
  • Linux 앱 → Wayland 프로토콜 → waypipe 서버 → SSH/소켓 → waypipe 클라이언트 → Cocoa-Way → Metal/OpenGL → macOS 디스플레이
  • 전체 경로가 가상화 없이 직접 연결되어 낮은 지연과 높은 효율 제공

비교

솔루션 지연 HiDPI 네이티브 통합 설정 복잡도
Cocoa-Way ⚡ 낮음 ✅ 완전 지원 ✅ 네이티브 창 🟢 쉬움
XQuartz 🐢 높음 ⚠️ 부분 지원 ⚠️ X11 특이점 존재 🟡 중간
VNC 🐢 높음 ❌ 미지원 ❌ 전체 화면 전용 🟡 중간
VM GUI 🐢 높음 ⚠️ 부분 지원 ❌ 별도 창 🔴 복잡

로드맵

  • ✅ macOS 백엔드 (Metal/OpenGL)
  • ✅ Waypipe 통합
  • ✅ HiDPI 스케일링
  • 🚧 Windows 백엔드 (win-way)
  • 📱 Android NDK 백엔드 (계획 중)
  • ⏳ 멀티 모니터 지원
  • ⏳ 클립보드 동기화

연구 배경

  • “Turbo-Charged Protocol Virtualization” 연구 프로젝트의 일부로, Rust 트레이트 모노모픽화와 SIMD 기반 픽셀 변환을 활용한 제로 코스트 크로스플랫폼 Wayland 가상화를 탐구

문제 해결

  • SSH 오류 “remote port forwarding failed” 발생 시, 원격 호스트에 남은 소켓 파일이 원인
    • run_waypipe.sh 스크립트는 -o StreamLocalBindUnlink=yes 옵션으로 자동 처리
    • 수동 실행 시: 
      waypipe ssh -o StreamLocalBindUnlink=yes user@host ...

기여

  • 기능 추가나 변경 전 이슈 등록 후 논의 권장
  • Pull Request를 통한 기여 환영

라이선스

  • GPL-3.0
  • 저작권 © 2024–2025 J-x-Z
▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • 솔직히 궁금한 점이 있음. 리눅스 GUI 앱 중에서 macOS용 네이티브 빌드가 없는 게 뭐가 있을까 궁금함. 대부분 Qt나 GTK 기반이라 멀티플랫폼인데, 딱 떠오르는 인기 앱이 없음

    • 핵심은 그게 아님. 이건 원격 리눅스 호스트의 앱을 로컬 창으로 실행하는 용도임. 예를 들어, 맥에서 VS Code를 원격 서버 창으로 띄우거나, 연구실 클러스터의 Matlab GUI를 접근하는 식임. X11에서는 xpra로 비슷하게 할 수 있음
    • 인기 앱은 많지 않지만, 집적회로 설계 분야에는 리눅스 전용 앱이 많음. 맥에서 컨테이너로 돌려봤는데 XQuartz가 너무 별로였음. Wayland로 전환되면 훨씬 나아질 수도 있음. 일부는 ARM 빌드도 생기고 있어서 언젠가 네이티브 맥 GUI도 가능할 듯함
    • 개인적으로 흥미로운 이유가 두 가지 있음. 첫째, Siri용 개발 환경을 타일링 윈도 관리로 쓰고 싶지만, 애플 생태계에 묶여 있어서 이런 방식이 괜찮은 대안일 듯함. 둘째, Iridium의 Niagara Workbench처럼 리눅스만 지원하는 앱들이 있어서 Quartz 지원 종료 이후 불편했음
    • 나는 단순히 KDE Plasma를 쓰고 싶음. 맥OS 인터페이스는 솔직히 별로라고 생각함
    • 단순히 리눅스 앱 실행뿐 아니라, 원격 리눅스 서버의 그래픽 앱을 로컬에서 실행하는 용도로도 쓸 수 있음

  • 완벽함. 이제 컨테이너 안에서 GUI 앱을 돌릴 수 있게 됨. 예전에 X11로 비슷한 걸 해봤지만 마음에 안 들었음. 점점 애플의 데스크톱 입지가 약해지는 느낌임. 결국 모든 사람이 “개발자”가 되는 시대가 올 것 같음

    • 애플이 데스크톱 시장에서 약해진다고 하지만, 사실 예전부터 리눅스보다 점유율이 높았음. 큰 변화는 없을 듯함
    • 나는 프로젝트별로 격리된 컨테이너 환경을 열어 쓰고 싶음. Parallels의 윈도 통합 모드처럼, 보안과 집중을 위해 앱을 그룹화하는 게 목표임

  • 이 프로젝트는 좀 수상함. README는 이모지로 가득하고 구현 설명도 없음. Metal 백엔드가 있다고 하지만 실제로는 없는 듯함. 의존성 리스트도 이상함

    • 전혀 쓸 가치가 없음. 어떤 하이퍼바이저를 쓰는지도 안 밝힘. QEMU인지 Docker인지 알 수 없음. 표도 이상함 — VM이 가장 설정이 쉬운 게 맞는데, 여기선 반대로 써 있음. 코드도 OpenGL 3.3 Core를 쓰고 있어서 너무 구식임. 아마 LLM이 생성한 코드일 가능성이 높음. 요즘 AI 코드가 과대평가된다는 생각이 듦. 겉만 번지르르하고 실속은 없음. 예전에 Anthropic이 Rust로 만든 C 컴파일러 홍보용 프로젝트가 떠오름

  • 이런 게 안드로이드용으로도 필요함. termux-x11이 시작점이긴 하지만, termux가 Wayland를 지원하거나 안드로이드의 리눅스 VM에서 Wayland 소켓을 노출할 수 있다면, 남은 건 부드러운 렌더링을 위한 네이티브 컴포지터뿐임

  • 만약 macOS가 GUI 없이 Darwin 셸 모드로 부팅할 수 있었다면, KDE나 COSMIC 같은 데스크톱 환경에 brew 패키지 매니저를 얹은 멋진 UNIX가 됐을 텐데 하는 아쉬움이 있음

    • 그렇다면 굳이 macOS를 쓸 이유가 있나 싶음. 인터페이스를 뺀다면 Darwin은 FreeBSD나 GNU와 다를 게 없음
    • 맥 커널은 성능도 떨어지고 패키지 관리도 nix보다 열등함
    • 인텔 맥 시절엔 단일 사용자 모드가 있었지만, 그때도 프레임버퍼 제어는 불가능했음

  • 이게 가능하다면, macOS 기반 Wayland 클라이언트가 EGL 서피스를 생성할 수 있는지도 궁금함

  • 혹시 Orbstack 안에서 Waydroid를 이용해 안드로이드 환경을 실행할 수 있을까? 이론상 가능할 것 같음

  • 맥OS를 윈도/리눅스 키보드 단축키로 바꿀 수 있다면 훨씬 덜 답답할 것 같음

    • 그건 잘못된 생각임. macOS 단축키는 터미널 작업에 최적화되어 있음. 시스템 단축키가 다른 키를 써서 control 코드와 충돌하지 않음
    • 설정에서 cmd와 ctrl 키를 바꾸거나, Karabiner-Elements로 완전히 커스터마이징 가능함. 나도 처음엔 헷갈렸지만 일주일이면 적응함. 지금은 오히려 윈도 단축키가 불편함. Command 키의 역사도 흥미로움
    • 터미널에서 ctrl+shift를 써야 하는 건 정말 끔찍함. macOS 단축키 체계가 훨씬 낫다고 생각함
    • 개인적으로 Super 키를 대부분의 단축키에 쓰는 게 더 낫다고 봄. 윈도에서는 시작 메뉴 전용이라 낭비임
    • 실제로 Karabiner-Elements로 cmd, option, control 키를 각각 ctrl, alt, super처럼 매핑해서 쓰고 있음. macOS 기본 설정만으로도 어느 정도 가능하지만, 좌우 키를 다르게 바꾸려면 Karabiner가 필요함. 의외로 애플 제품치고는 꽤 유연한 설정임

  • 이 프로젝트가 GNUstep에 조금이라도 관심을 불러일으킬 수 있을지 궁금함

답변달기