macOS 가상 데스크톱, 왜 다시 격자가 필요하다는 얘기가 나왔나

사라진 건 기능 하나가 아니라 ‘공간 감각’이었음

• 글쓴이는 20년 전의 맥 데스크톱 경험이 지금보다 더 좋았다고 말함

  • 당시에는 지금 기준으로 저해상도 단일 모니터를 쓰고 있었음
  • 그런데도 9개 넘는 화면을 몸으로 기억하며 이동하는 느낌이 있었다고 함

• 핵심은 macOS 10.5 레퍼드의 스페이스(Spaces)였음

  • 레퍼드의 스페이스는 가상 데스크톱을 3x3 같은 격자로 배치할 수 있었음
  • 글쓴이는 가운데에 브라우저, 위쪽에 웹 에디터, 왼쪽 위에 엑스코드, 그 아래에 아이오에스 시뮬레이터를 두는 식으로 썼음
  • 이 구조에서는 화면 전환이 “몇 번째 데스크톱”이 아니라 “위로 한 칸”, “왼쪽 위” 같은 공간 이동이 됨

• macOS 라이언에서 미션 컨트롤(Mission Control)이 나오면서 이 감각이 깨졌다고 봄

  • 애플은 가상 데스크톱을 가로 한 줄로 제한함
  • 단축키로 바로 이동할 수는 있지만, 브라우저가 7번인지 8번인지 기억해야 하는 식이라 공간 기억이 사라짐
  • 글쓴이 표현대로라면 꽤 큰 후퇴였던 셈

그래서 GridLion을 만들었음

• GridLion은 macOS 스페이스를 레퍼드 시절처럼 격자로 쓰게 해주는 앱임

  • 이름은 격자(Grid)와 문제의 시작점이었던 macOS 라이언(Lion)에서 따온 것
  • 글쓴이도 이름이 별로라는 피드백을 받았다고 인정하지만, 이름보다 동작이 중요하다는 쪽임

• 구현 방식은 네이티브 스페이스를 갈아엎는 게 아니라 가볍게 감싸는 래퍼에 가까움

  • macOS는 미션 컨트롤 관련 API 대부분을 잠가두고 있음
  • 문서화된 API로 새 데스크톱을 만들거나, 스페이스를 원하는 위치로 재배치하는 방식은 어렵다는 얘기
  • 대신 애니메이션 없이 즉시 스페이스를 이동하는 방법을 보고, 한 줄짜리 네이티브 스페이스를 내부 모델에서 격자처럼 보여주는 방식으로 풀었음

• 대규모 언어 모델(LLM)의 도움으로 하루 만에 못생겼지만 작동하는 프로토타입을 만들었다고 함

  • 처음 며칠은 “며칠 전이었다면 돈 주고 샀을 앱”이라는 느낌이 들 정도였음
  • 하지만 며칠 써보니 제대로 된 제품으로 다듬고 싶어졌고, 한 달 정도 제한된 자유 시간을 들여 꽤 만족스러운 수준까지 끌어올림

sequenceDiagram
    participant 사용자
    participant 그리드라이언
    participant 미션컨트롤
    participant 네이티브스페이스
    사용자->>그리드라이언: 격자 위치로 이동 단축키 입력
    그리드라이언->>그리드라이언: 격자 좌표를 한 줄 스페이스 번호로 변환
    그리드라이언->>미션컨트롤: 해당 스페이스로 즉시 전환 요청
    미션컨트롤->>네이티브스페이스: 실제 데스크톱 전환 수행
    네이티브스페이스-->>사용자: 원하는 위치의 작업 공간 표시

macOS 권한 UX는 생각보다 빡셈

• 전역 단축키를 잡고 스페이스를 이동하려면 접근성(Accessibility) 권한이 필요함

  • 보안상 이유는 납득 가능함
  • 문제는 macOS의 승인 흐름이 사용자를 설정 앱으로 보내고, 거기서 작은 토글을 찾아 켜게 만드는 식이라는 점
  • 아이오에스처럼 요청, 승인, 끝이 아니라 여러 단계의 안내와 보안 프롬프트를 지나야 함

• 스페이스 미리보기까지 하려면 화면 및 시스템 오디오 녹화 권한도 필요함

  • 화면 미리보기는 대부분 사용자가 원할 만한 기능이라고 봄
  • 그런데 승인하면 또 설정으로 이동하고, 토글을 켜고, 추가 프롬프트를 승인하고, 앱이 종료됐다 다시 열리는 흐름을 거침
  • 보이지 않는 창과 화면의 미리보기까지 만들려 하면 더 무서운 경고창이 뜬다고 함

앱스토어 밖에서 파는 것도 일이었음

• GridLion은 앱스토어에 올리기 어려움

  • 스페이스 정보를 얻기 위해 비공개 API(Private APIs)를 호출하기 때문
  • 애플 앱스토어 심사에서는 이런 사용이 허용되지 않는다고 봐야 함

• 그래서 글쓴이는 앱스토어 밖에서 판매하는 방법을 찾았고, 결제와 세금, 환불을 맡아주는 머천트 오브 레코드(Merchant of Record)를 검토함

  • 후보로 패들, 검로드, 레몬 스퀴지를 언급함
  • 최종적으로 레몬 스퀴지의 라이선스 코드 API에 끌렸다고 함
  • 구매 시 라이선스 키를 발급하고, 앱에서 활성화, 비활성화, 검증을 처리할 수 있기 때문

• 생각보다 가입 즉시 판매 시작은 아니었음

  • 판매자가 평판이 있고 실제 가치 있는 제품을 판다는 걸 증명해야 했음
  • 스크린캐스트와 소셜 계정 증빙이 필요했다고 함
  • 다만 테스트 계정 접근은 가능해서 앱 통합과 검증은 쉽게 진행할 수 있었음

대규모 언어 모델은 빠르지만, UX를 신경 쓰진 않음

• 글쓴이는 업무에서도 대규모 언어 모델을 코딩 어시스턴트로 쓰고, 관련 제품도 만든다고 함

  • 그런데 개인 네이티브 앱 프로젝트에 제대로 써본 건 이번이 처음
  • 결론은 “엄청 빠른 배 같지만, 피드백 루프가 없으면 엉뚱한 곳으로 간다”에 가까움

• API 결과나 대규모 데이터 쿼리처럼 정답이 비교적 명확한 작업에서는 대규모 언어 모델이 잘 맞는다고 봄

  • 계획이 잘 잡혀 있으면 결과가 원하는 모양이 아닌지도 모델이 바로 확인하고 반복할 수 있음
  • 이때 사람의 시간은 주로 리뷰에 들어감

• 반면 사용자 인터페이스는 느낌의 영역이 커서 사람이 계속 개입해야 함

  • 버튼 반응, 전환 감각, 미세한 지연 같은 건 자동 채점이 어려움
  • 글쓴이는 10년 전의 자신이라면 같은 시간 안에 비슷한 앱을 만들었고, 그 과정에서 더 많이 배웠을 수도 있다고 느낌

아직 남은 아쉬움도 있음

• GridLion은 글쓴이가 원하는 대부분을 구현한 상태임

  • 격자형 스페이스를 쉽게 탐색하고 재배치할 수 있음
  • 빠르고 안정적이며, 느려지는 문제가 없도록 신경 썼음
  • 디스플레이별 격자 크기와 단축키 같은 설정도 지원함

• 하지만 macOS API 제한 때문에 못 하는 것도 남아 있음

  • 한 디스플레이의 스페이스를 다른 디스플레이로 옮기는 것
  • 한 스페이스의 창을 다른 스페이스로 안정적으로 이동시키는 것
  • 이런 작업은 여전히 미션 컨트롤을 직접 써야 함

• 원래 스페이스에 있던 “특정 앱을 특정 위치에 항상 띄우기” 기능도 고민 중임

  • 다만 글쓴이는 재시작을 자주 하지 않고, 설정과 재배치가 빠르기 때문에 예전만큼 필요하지 않을 수도 있다고 봄
  • 여러 개의 브이에스코드 창을 동시에 여는 현재 작업 방식에서는 이 기능을 어떻게 처리할지도 애매함

기술 맥락

• GridLion의 선택은 “macOS 스페이스를 새로 만들자”가 아니라 “기존 미션 컨트롤을 격자처럼 해석하자”에 가까워요. macOS가 스페이스 관련 API를 대부분 막아두고 있어서, 공식 API만으로 레퍼드식 격자를 복원하기 어렵거든요.

• 그래서 구현의 핵심은 한 줄짜리 네이티브 스페이스를 내부 모델에서 2차원 좌표로 바꾸는 거예요. 사용자는 위, 아래, 왼쪽, 오른쪽으로 움직인다고 느끼지만, 실제로는 앱이 그 좌표를 미션 컨트롤의 순번으로 변환해 전환하는 구조예요.

• 권한 설계도 이 앱의 중요한 기술적 제약이에요. 전역 단축키는 접근성 권한이 필요하고, 스페이스 미리보기는 화면 녹화 권한이 필요해요. 기능은 생산성 도구에 가깝지만, 운영체제 입장에서는 키 입력과 화면 캡처라는 민감한 영역을 건드리는 셈이라 사용자 승인 흐름이 무거워져요.

• 앱스토어 밖 배포를 고른 이유도 기술 선택의 결과예요. 비공개 API를 쓰면 앱스토어 심사 통과가 어렵기 때문에, 결제와 라이선스 검증을 직접 붙이거나 머천트 오브 레코드 서비스를 써야 해요. 글쓴이가 레몬 스퀴지를 본 건 라이선스 키 발급과 검증 API가 앱 내부 흐름에 바로 맞았기 때문이에요.

• 대규모 언어 모델은 여기서 빠른 프로토타입 도구로는 잘 맞았지만, 완성도 판단까지 맡기긴 어려웠어요. 격자 전환이 “맞게 동작한다”와 “손에 붙는다”는 다르거든요. 이 앱처럼 공간 기억과 반응성이 제품 가치의 핵심이면, 최종 품질은 결국 사람이 계속 써보며 조정해야 해요