--- title: "macOS 가상 데스크톱, 왜 다시 격자가 필요하다는 얘기가 나왔나" published: 2026-06-02T01:28:34.000Z canonical: https://jeff.news/article/3614 --- # macOS 가상 데스크톱, 왜 다시 격자가 필요하다는 얘기가 나왔나 한 개발자가 macOS 레퍼드 시절의 격자형 스페이스 경험을 되살리기 위해 GridLion이라는 앱을 만들었어. 글은 단순 앱 소개가 아니라, 애플이 macOS 라이언에서 스페이스를 한 줄로 바꾼 뒤 사라진 공간 기억, macOS 권한 시스템의 불편함, 앱스토어 밖에서 소프트웨어를 파는 현실, 대규모 언어 모델을 개인 프로젝트에 쓰며 느낀 한계를 꽤 솔직하게 풀어냄. ## 사라진 건 기능 하나가 아니라 ‘공간 감각’이었음 - 글쓴이는 20년 전의 맥 데스크톱 경험이 지금보다 더 좋았다고 말함 - 당시에는 지금 기준으로 저해상도 단일 모니터를 쓰고 있었음 - 그런데도 9개 넘는 화면을 몸으로 기억하며 이동하는 느낌이 있었다고 함 - 핵심은 macOS 10.5 레퍼드의 스페이스(Spaces)였음 - 레퍼드의 스페이스는 가상 데스크톱을 3x3 같은 격자로 배치할 수 있었음 - 글쓴이는 가운데에 브라우저, 위쪽에 웹 에디터, 왼쪽 위에 엑스코드, 그 아래에 아이오에스 시뮬레이터를 두는 식으로 썼음 - 이 구조에서는 화면 전환이 “몇 번째 데스크톱”이 아니라 “위로 한 칸”, “왼쪽 위” 같은 공간 이동이 됨 - macOS 라이언에서 미션 컨트롤(Mission Control)이 나오면서 이 감각이 깨졌다고 봄 - 애플은 가상 데스크톱을 가로 한 줄로 제한함 - 단축키로 바로 이동할 수는 있지만, 브라우저가 7번인지 8번인지 기억해야 하는 식이라 공간 기억이 사라짐 - 글쓴이 표현대로라면 꽤 큰 후퇴였던 셈 > [!NOTE] > 여기서 말하는 불편함은 단순히 “옛날이 좋았다”가 아니라, 가상 데스크톱을 실제 물리 모니터처럼 다루던 작업 방식이 사라졌다는 문제임. ## 그래서 GridLion을 만들었음 - GridLion은 macOS 스페이스를 레퍼드 시절처럼 격자로 쓰게 해주는 앱임 - 이름은 격자(Grid)와 문제의 시작점이었던 macOS 라이언(Lion)에서 따온 것 - 글쓴이도 이름이 별로라는 피드백을 받았다고 인정하지만, 이름보다 동작이 중요하다는 쪽임 - 구현 방식은 네이티브 스페이스를 갈아엎는 게 아니라 가볍게 감싸는 래퍼에 가까움 - macOS는 미션 컨트롤 관련 API 대부분을 잠가두고 있음 - 문서화된 API로 새 데스크톱을 만들거나, 스페이스를 원하는 위치로 재배치하는 방식은 어렵다는 얘기 - 대신 애니메이션 없이 즉시 스페이스를 이동하는 방법을 보고, 한 줄짜리 네이티브 스페이스를 내부 모델에서 격자처럼 보여주는 방식으로 풀었음 - 대규모 언어 모델(LLM)의 도움으로 하루 만에 못생겼지만 작동하는 프로토타입을 만들었다고 함 - 처음 며칠은 “며칠 전이었다면 돈 주고 샀을 앱”이라는 느낌이 들 정도였음 - 하지만 며칠 써보니 제대로 된 제품으로 다듬고 싶어졌고, 한 달 정도 제한된 자유 시간을 들여 꽤 만족스러운 수준까지 끌어올림 ```mermaid sequenceDiagram participant 사용자 participant 그리드라이언 participant 미션컨트롤 participant 네이티브스페이스 사용자->>그리드라이언: 격자 위치로 이동 단축키 입력 그리드라이언->>그리드라이언: 격자 좌표를 한 줄 스페이스 번호로 변환 그리드라이언->>미션컨트롤: 해당 스페이스로 즉시 전환 요청 미션컨트롤->>네이티브스페이스: 실제 데스크톱 전환 수행 네이티브스페이스-->>사용자: 원하는 위치의 작업 공간 표시 ``` ## macOS 권한 UX는 생각보다 빡셈 - 전역 단축키를 잡고 스페이스를 이동하려면 접근성(Accessibility) 권한이 필요함 - 보안상 이유는 납득 가능함 - 문제는 macOS의 승인 흐름이 사용자를 설정 앱으로 보내고, 거기서 작은 토글을 찾아 켜게 만드는 식이라는 점 - 아이오에스처럼 요청, 승인, 끝이 아니라 여러 단계의 안내와 보안 프롬프트를 지나야 함 - 스페이스 미리보기까지 하려면 화면 및 시스템 오디오 녹화 권한도 필요함 - 화면 미리보기는 대부분 사용자가 원할 만한 기능이라고 봄 - 그런데 승인하면 또 설정으로 이동하고, 토글을 켜고, 추가 프롬프트를 승인하고, 앱이 종료됐다 다시 열리는 흐름을 거침 - 보이지 않는 창과 화면의 미리보기까지 만들려 하면 더 무서운 경고창이 뜬다고 함 > [!WARNING] > GridLion 같은 생산성 앱은 실제로는 작은 화면 미리보기를 만들 뿐이어도, macOS 권한 문구상으로는 꽤 위험해 보일 수 있음. 그래서 개발자는 네트워크 접근을 업데이트 확인과 라이선스 검증 정도로 제한해 신뢰를 쌓는 쪽을 택함. ## 앱스토어 밖에서 파는 것도 일이었음 - GridLion은 앱스토어에 올리기 어려움 - 스페이스 정보를 얻기 위해 비공개 API(Private APIs)를 호출하기 때문 - 애플 앱스토어 심사에서는 이런 사용이 허용되지 않는다고 봐야 함 - 그래서 글쓴이는 앱스토어 밖에서 판매하는 방법을 찾았고, 결제와 세금, 환불을 맡아주는 머천트 오브 레코드(Merchant of Record)를 검토함 - 후보로 패들, 검로드, 레몬 스퀴지를 언급함 - 최종적으로 레몬 스퀴지의 라이선스 코드 API에 끌렸다고 함 - 구매 시 라이선스 키를 발급하고, 앱에서 활성화, 비활성화, 검증을 처리할 수 있기 때문 - 생각보다 가입 즉시 판매 시작은 아니었음 - 판매자가 평판이 있고 실제 가치 있는 제품을 판다는 걸 증명해야 했음 - 스크린캐스트와 소셜 계정 증빙이 필요했다고 함 - 다만 테스트 계정 접근은 가능해서 앱 통합과 검증은 쉽게 진행할 수 있었음 ## 대규모 언어 모델은 빠르지만, UX를 신경 쓰진 않음 - 글쓴이는 업무에서도 대규모 언어 모델을 코딩 어시스턴트로 쓰고, 관련 제품도 만든다고 함 - 그런데 개인 네이티브 앱 프로젝트에 제대로 써본 건 이번이 처음 - 결론은 “엄청 빠른 배 같지만, 피드백 루프가 없으면 엉뚱한 곳으로 간다”에 가까움 - API 결과나 대규모 데이터 쿼리처럼 정답이 비교적 명확한 작업에서는 대규모 언어 모델이 잘 맞는다고 봄 - 계획이 잘 잡혀 있으면 결과가 원하는 모양이 아닌지도 모델이 바로 확인하고 반복할 수 있음 - 이때 사람의 시간은 주로 리뷰에 들어감 - 반면 사용자 인터페이스는 느낌의 영역이 커서 사람이 계속 개입해야 함 - 버튼 반응, 전환 감각, 미세한 지연 같은 건 자동 채점이 어려움 - 글쓴이는 10년 전의 자신이라면 같은 시간 안에 비슷한 앱을 만들었고, 그 과정에서 더 많이 배웠을 수도 있다고 느낌 ## 아직 남은 아쉬움도 있음 - GridLion은 글쓴이가 원하는 대부분을 구현한 상태임 - 격자형 스페이스를 쉽게 탐색하고 재배치할 수 있음 - 빠르고 안정적이며, 느려지는 문제가 없도록 신경 썼음 - 디스플레이별 격자 크기와 단축키 같은 설정도 지원함 - 하지만 macOS API 제한 때문에 못 하는 것도 남아 있음 - 한 디스플레이의 스페이스를 다른 디스플레이로 옮기는 것 - 한 스페이스의 창을 다른 스페이스로 안정적으로 이동시키는 것 - 이런 작업은 여전히 미션 컨트롤을 직접 써야 함 - 원래 스페이스에 있던 “특정 앱을 특정 위치에 항상 띄우기” 기능도 고민 중임 - 다만 글쓴이는 재시작을 자주 하지 않고, 설정과 재배치가 빠르기 때문에 예전만큼 필요하지 않을 수도 있다고 봄 - 여러 개의 브이에스코드 창을 동시에 여는 현재 작업 방식에서는 이 기능을 어떻게 처리할지도 애매함 --- ## 기술 맥락 - GridLion의 선택은 “macOS 스페이스를 새로 만들자”가 아니라 “기존 미션 컨트롤을 격자처럼 해석하자”에 가까워요. macOS가 스페이스 관련 API를 대부분 막아두고 있어서, 공식 API만으로 레퍼드식 격자를 복원하기 어렵거든요. - 그래서 구현의 핵심은 한 줄짜리 네이티브 스페이스를 내부 모델에서 2차원 좌표로 바꾸는 거예요. 사용자는 위, 아래, 왼쪽, 오른쪽으로 움직인다고 느끼지만, 실제로는 앱이 그 좌표를 미션 컨트롤의 순번으로 변환해 전환하는 구조예요. - 권한 설계도 이 앱의 중요한 기술적 제약이에요. 전역 단축키는 접근성 권한이 필요하고, 스페이스 미리보기는 화면 녹화 권한이 필요해요. 기능은 생산성 도구에 가깝지만, 운영체제 입장에서는 키 입력과 화면 캡처라는 민감한 영역을 건드리는 셈이라 사용자 승인 흐름이 무거워져요. - 앱스토어 밖 배포를 고른 이유도 기술 선택의 결과예요. 비공개 API를 쓰면 앱스토어 심사 통과가 어렵기 때문에, 결제와 라이선스 검증을 직접 붙이거나 머천트 오브 레코드 서비스를 써야 해요. 글쓴이가 레몬 스퀴지를 본 건 라이선스 키 발급과 검증 API가 앱 내부 흐름에 바로 맞았기 때문이에요. - 대규모 언어 모델은 여기서 빠른 프로토타입 도구로는 잘 맞았지만, 완성도 판단까지 맡기긴 어려웠어요. 격자 전환이 “맞게 동작한다”와 “손에 붙는다”는 다르거든요. 이 앱처럼 공간 기억과 반응성이 제품 가치의 핵심이면, 최종 품질은 결국 사람이 계속 써보며 조정해야 해요 ## 핵심 포인트 - macOS 레퍼드의 스페이스는 3x3 같은 격자형 가상 데스크톱을 지원해 공간 기억 기반 작업이 가능했음 - macOS 라이언의 미션 컨트롤은 스페이스를 가로 한 줄로 제한해 기존 사용자의 탐색 감각을 깨뜨림 - GridLion은 네이티브 스페이스를 직접 대체하지 않고, 한 줄 스페이스를 격자처럼 보여주는 래퍼 방식으로 구현됨 - 전역 단축키와 화면 미리보기를 위해 접근성 권한과 화면 녹화 권한이 필요하지만 macOS 승인 흐름이 꽤 번거로움 - 비공개 API 사용 때문에 앱스토어 배포가 어렵고, 개발자는 레몬 스퀴지를 통해 라이선스와 결제를 처리하려 함 - 개발자는 대규모 언어 모델이 프로토타입에는 빠르지만, 사용자 인터페이스의 ‘느낌’을 다듬는 데는 인간 피드백이 필수라고 봄 ## 인사이트 이 글의 재미는 ‘옛날 기능이 그리워서 앱 만들었다’에서 끝나지 않는다는 데 있음. 데스크톱 생산성 도구는 기능 목록보다 몸에 붙는 공간 감각과 미세한 반응성이 중요하고, 그 지점에서는 대규모 언어 모델도 아직 사람의 집착을 대체하기 어렵다는 얘기로 읽힘.