맥 없이 macOS 앱이 실행된다? 200여 개 도구 동작시킨 오픈소스 ‘Kakehashi’

“Apple 소프트웨어는 Mac 컴퓨터에서만 작동한다”라는 오랫동안 당연하게 여겨졌던 공식에 균열이 가기 시작했습니다. 2026년 8월 초, 세계 최대 기술 커뮤니티인 Hacker News에 Kakehashi(일본어로 ‘다리 놓기’라는 뜻)라는 이름의 오픈소스 프로젝트가 등장해 156점의 추천과 34개의 댓글을 기록하며 큰 주목을 받았습니다. 이 프로젝트의 핵심은 명확합니다. ARM 기반 Linux PC에서 macOS를 설치하거나 가상머신(VM)을 구동하지 않고, macOS 전용 소프트웨어를 직접 실행하는 것입니다. 현재 200개 이상의 macOS 기본 커맨드라인 도구가 성공적으로 작동했으며, 압축 프로그램인 7-Zip까지 정상 작동하고 있습니다. Apple의 독자적 하드웨어-소프트웨어 통합 장벽에 기술적 접근으로 의미 있는 구멍을 뚫은 셈입니다.

이미지: Hacker News에 공개된 Kakehashi 발표 스레드로, 작성자가 댓글을 통해 진행 상황을 답변하고 있다. 출처: news.ycombinator.com

왜 이것이 불가능하게 느껴졌을까

일반적인 사용자 입장에서 Apple의 소프트웨어와 하드웨어는 하나로 묶여 있습니다. Mac용으로 제작된 프로그램은 다른 PC에서 실행조차 되지 않는데, 이는 우연이 아니라 Apple이 철저하게 설계한 비즈니스 모델 때문입니다.

Apple의 사업 구조는 하드웨어 판매와 소프트웨어 생태계를 강력하게 결합하고 있습니다. macOS 라이선스 이용 약관에는 ‘Apple 브랜드 하드웨어에서만 실행 가능함’이 명시되어 있으며, 타사 장치에 설치하는 것은 약관 위반에 해당합니다. 여기에 App Store 수수료와 클라우드 구독 서비스가 이어지면서 Mac을 구매하는 행위 자체가 생태계에 진입하는 입장권 역할을 합니다. 따라서 지금까지 타 OS에서 macOS 프로그램을 사용하려면 전체 운영체제를 에뮬레이트하는 무겁고 느린 가상머신을 구동하거나, 위험성이 높은 해킨토시(Hackintosh)를 세팅해야만 했습니다.

Kakehashi는 제3의 방식을 선택했습니다. 운영체제 전체를 옮기는 대신 프로그램의 실행 환경만을 변환하는 방식입니다.

어떻게 작동하는가: 시스템 수준의 ‘통역사’

macOS 프로그램을 Linux 환경으로 가져올 때 가장 큰 문제는 두 환경 간의 언어(ABI 및 시스템 콜)가 완전히 다르다는 점입니다. 과거에는 Apple의 독자적 프레임워크와 커넬 구조를 통째로 가져오지 않으면 통신이 불가능했습니다.

Kakehashi의 혁신적인 착상은 Apple Silicon M 시리즈 칩과 Linux를 구동하는 최신 ARM PC가 근본적으로 동일한 명령어(ARM 아키텍처)를 사용한다는 사실에 주목한 것입니다. CPU 레벨의 명령어 세트가 동일하기 때문에 프로그램 바이너리 자체는 에뮬레이션 없이 Linux CPU에서 직접 실행될 수 있습니다. 실제 통역이 필요한 순간은 프로그램이 파일 읽기/쓰기, 네트워크 연결, 메모리 할당 등 운영체제에 처리를 요청하는 시스템 콜 시점뿐입니다. Kakehashi는 이 지점에서 통역사 역할을 수행하여, macOS 전용 요청을 Linux 호환 요청으로 즉시 변환하고 결과값을 다시 프로그램에 전달합니다.

이미지: Apple M 시리즈 칩과 주요 Linux ARM 기기는 동일한 ARM 아키텍처를 공유하므로 프로그램 실행 변환 비용을 크게 줄일 수 있다. 출처: Wikimedia Commons

이러한 구조를 ‘호환 레이어(compatibility layer)‘라고 부르며, 대표적인 선례로는 Windows 프로그램을 Linux에서 실행하게 해주는 Wine이 있습니다.

30년 전에도 비슷한 도전이 있었다

1993년, Wine이라는 오픈소스 프로젝트가 가동되었을 때도 목표는 동일하게 파격적이었습니다. 바로 Linux PC에서 Windows 프로그램을 직접 구동하는 것이었습니다. 당시 대다수의 전문가들은 수만 개에 달하는 Windows API를 일일이 재구현하는 것은 불가능하다고 보았습니다. 그러나 30년에 걸친 지속적인 개발 끝에 Wine은 단순한 호환성 시도를 넘어 필수 기술로 자리 잡았습니다.

오늘날 Wine은 거대한 생태계로 성장했습니다. Valve의 휴대용 게임기인 Steam Deck 역시 Wine 기반의 Proton 기술을 활용하고 있으며, 수십만 명의 게이머가 휴대용 기기에서 Windows 게임을 원활하게 즐기고 있습니다. 한때 불가능해 보였던 프로젝트가 거대 하드웨어 사업의 핵심 기반이 된 것입니다.

macOS 프로그램을 다리 놓으려는 시도가 Kakehashi가 처음은 아닙니다. 이전에도 Darling이라는 프로젝트가 유사한 시도를 진행했으나 개발 속도가 완만했습니다. Kakehashi의 개발자는 Hacker News를 통해 이 프로젝트가 Darling의 포크가 아니며, Rust 언어로 처음부터 다시 작성한 독립적 구현체임을 밝혔습니다. 커넬 영역을 침범하지 않고 사용자 공간(user space)에서만 동작하여 안전성을 높였다고 설명했습니다. 또한 개발 과정에서 AI 보조 도구를 활용했다고 언급하여 커뮤니티 내에서 청정 구현 여부에 대한 토론이 벌어졌으나, 개발자는 모든 코드 소스가 오픈소스로 공개되어 있으므로 검증이 가능하다고 답변했습니다.

5.2배 느린 속도, 과연 치명적인가

현재 공개된 주요 벤치마크 결과에 따르면, 7-Zip 압축 프로그램으로 8,000개 파일(총 240MB)을 압축하는 테스트에서 결과물은 정확히 일치했으나 실행 속도는 Linux 순정 환경보다 5.2배 느린 것으로 나타났습니다(순정 22.5초 대 Kakehashi 118초). 반면 200여 개의 curl 네트워크 명령어가 자동 테스트를 통과했으며, Apple Xcode에 포함된 Git 버전 관리 도구의 기본 기능도 정상 작동했습니다.

5.2배라는 수치가 커 보일 수 있지만, 이는 호환 레이어 초기에 발생하는 자연스러운 손실 비용입니다. 속도 저하의 주요 원인은 시스템 콜이 일어날 때 발생하는 통역 오버헤드입니다. 소형 파일 작업이 빈번할수록 전환 횟수가 늘어나 격차가 벌어지지만, 단일 대용량 파일 작업에서는 속도 차이가 1.1~1.2배 수준으로 크게 줄어듭니다. 초창기 Wine 역시 이보다 훨씬 더 큰 성능 저하를 겪었습니다. 개발자는 로드맵을 통해 Apple Xcode 전체 툴체인(iOS 앱 빌드 포함)과 macOS용 Homebrew 호환을 다음 목표로 제시했으며, 이는 개발자 생태계의 핵심 영역이 될 것으로 전망됩니다.

다만 커뮤니티 일각에서는 Apple이 매년 대규모 OS 업데이트를 통해 내부 인터페이스를 변경하고 있어, 호환 레이어가 이를 계속 추적하는 데 한계가 있을 것이라는 우려도 제기됩니다. 닫힌 문을 굳건히 지키는 기업을 상대로 한 비대칭적인 도전이라는 점은 분명합니다.

이 작은 균열이 가지는 의미

넓은 관점에서 보면 이는 ‘개방성’과 ‘폐쇄성’의 대립이 만들어낸 새로운 장면입니다. 오픈소스 커뮤니티는 소프트웨어가 하드웨어 장벽 없이 자유롭게 작동해야 한다고 믿는 반면, Apple은 통제된 울타리 내부에서 최상의 사용자 경험이 제공된다고 강조해 왔습니다.

만약 macOS 전용 영상 편집, 음악 작업, 디자인 도구가 저렴한 ARM PC에서도 매끄럽게 구동되는 날이 온다면 Apple 하드웨어의 독점적 거함은 어떤 변화를 맞이하게 될까요. 역사가 보여주듯 Wine으로 인해 Windows 생태계가 무너지지 않았으며, 오히려 ‘Windows용 앱을 어디서나 쓸 수 있다’는 환경이 조성되어 전체 소프트웨어의 가치가 높아졌습니다. 장벽에 구멍이 뚫린다고 해서 정원이 무너지는 것은 아니지만, 정원사는 울타리 너머의 세상에 주의를 기울여야 합니다.

Kakehashi의 도전이 최종적으로 어디까지 도달할지는 예측하기 어렵습니다. 5.2배의 성능 격차, 매년 개편되는 OS 인터페이스, 라이선스 이슈 등 넘어야 할 산이 많습니다. 하지만 1993년 Wine이 처음 세상에 나왔을 때 그것이 휴대용 게임기의 시대를 열 것이라고 누구도 예상하지 못했던 점을 기억할 필요가 있습니다. 모든 커다란 변화는 장벽에 생긴 작은 균열 하나에서 시작됩니다.

참고 링크:

• Kakehashi GitHub 저장소 (wie-project): 프로젝트 메인 페이지, README, 아키텍처 문서 및 로드맵
• HN 토론 스레드 (item?id=49145937): 작성자의 7-Zip, curl, Xcode Git 진행 상황 설명 및 Darling과의 차이점
• Wine 공식 역사 문서: WineHQ “Wine Is Not an Emulator” 프로젝트 소개
• Wine 위키백과 항목: 1993년 탄생부터 현재까지의 발전사와 Steam Deck 적용 사례