2021.07.05

글로벌 칼럼 | M1, 맥OS 몬터레이, 그리고 ‘자동화 진화’가 이끄는 맥 판도 변화

Jason Snell | Macworld
지금의 맥은 그 어느때보다 애플의 강력한 도구다. 오늘날 애플 실리콘을 구동하는 맥들은 맥OS 앱 라이브러리 전체를 사용할 수 있고 iOS 앱 역시 카탈리스트(Catalyst)를 통하거나 직접 앱스토어(App Store)에서 수정되지 않은 상태로 사용할 수 있다. 그리고 내부에는 앱 스크립팅에서부터 유닉스(Unix) 기반의 각종 툴들에 이르는 모든 것이 있다. 

그런데 애플 실리콘으로의 전환, 그리고 다년 간에 걸친 자동화 전환의 일환으로 맥에 단축어가 도입된다는 6월 애플의 발표와 함께 상황이 변하고 있다. 맥이 강력한 도구라는 것에는 변화가 없겠지만, 향후 몇 년 간 맥의 속성이 근본적으로 달라질 것이다.
 

오토메이터를 대체할 단축어

단축어가 오토메이터(Automator)를 대체한다(정말 그렇게 된다)는 소식이 중요한 것은 단지 맥OS에 따끈따끈하게 새로운 사용자 자동화용 툴이 생기기 때문만은 아니다. 애플이 관심을 기울이고 있다는 중요한 징후이기 때문이다. 지난 몇 년간 맥 앱 개발자들은 앱에 자동화 기능을 추가하는 것이 의미 있다고 느끼기가 어려웠다. 그러나 이제는 단축어라는 해결책이 생겼다. 애플은 몇 년에 걸쳐 새로운 세계로 전환해 나갈 것이다.

이번 가을부터 맥 개발자들은 단축어 지원을 추가할 것이다. iOS에서처럼 앱이 단축어 앱에 동작을 “기부”하게 된다. 사용하는 앱의 기능이 단축어에 축적된다. 어떤 경우에는 이런 동작으로 앱이 열리고 작업이 수행되는 반면, 다른 경우에는 앱을 눈에 보이게 열 필요도 없이 앱 기능의 일부분을 해결이 필요한 문제에 적용할 수 있다.
 
단축어는 iOS에서 데뷔해 인기몰이를 했다. ⓒ Apple


유닉스의 지원을 받게 될 단축어

맥의 단축어는 iOS 및 아이패드OS 상에서 이용 가능한 것의 수준을 넘어선다. 유닉스 스크립팅 및 셸 지원에 직접 연결될 수 있기 때문이다. 단, 한 가지 큰 단점이 있다. 애플이 더 이상 일반 유닉스 스크립팅 시스템을 맥OS에 포함시키지 않기로 약속한 것이다. 맥OS 몬터레이(Monterey)에서 PHP는 이미 떠났고 펄(Perl), 파이썬(Python) 등은 곧 제거될 구형 버전이다.

이러한 점은 한편으로는 큰 문제가 되지 않는다. 여전히 PHP, 펄, 파이썬의 최신 버전을 맥OS 상에 설치할 수 있기 때문이다. (필자는 이를 위해 홈브루(Homebrew)를 사용한다.) 다른 한편으로는, 위와 같은 스크립팅 언어 중 하나에 의존하는 자동화를 구축 중이라면 자동화하고자 하는 맥에는 모두 해당 언어를 설치해야 한다.
 

다른 하나의 스크립팅 언어는 어떻게 되는가?

이는 더 큰 문제로 이어진다. 수십 년 동안 맥에서 애플리케이션 간 통신을 살아 있게 해 준 애플 이벤트(Apple Events) 기술과 애플스크립트(AppleScript)는 어떻게 되는가 하는 것이다. iOS에는 애플 이벤트에 상응하는 것이 없다. 믿기 힘들겠지만, URL을 앞뒤로 지나치는 것이 일반적인 통신 방법이 되었다. 그러나 애플은 최근 들어 시리 인텐트(Siri Intents)와 같은 기능들로 현대화를 진행 중이다. 

사실, iOS에서 대부분의 자동화는 서로 다른 앱들의 작은 부분들을 이용해 워크플로를 구축하는 것이 핵심이었다. 그것이 사용자 자동화 이야기의 중요한 부분이지만 또 다른 부분은 스크립팅을 통해 강력한 앱을 깊이 통제하는 능력이다. iOS에서는 이런 수준의 통제 능력이 있는 앱들은 자바스크립트 또는 파이썬에 기반한 자가 구현 매크로 엔진을 사용하는 경향이 있다. 가장 좋은 예라고 할 수 있는 옴니 그룹(Omni Group)의 풍부한 자바스크립트 기반의 자동화는 아이패드, 아이폰 또는 맥에서 옴니의 앱을 스크립트가 통제하게 해 준다.

모든 앱이 자체 스크립팅 또는 매크로 언어를 구현하는 것은 바람직한 길이 아니다. 플랫폼 소유자인 애플이 나서서 개발자와 사용자 모두를 위한 공통의 참조 프레임을 만들어야 한다.
 
애플스크립트의 수명이 얼마 남지 않았다. ⓒ Apple


맥OS에서의 스크립팅의 미래

몇 년이 걸릴 이번 전환이 끝나면 어떻게 될까? 가상 쉽게 예상할 수 있는 것은 1990년대 초반으로 거슬러 올라가는 애플스크립트가 마침내 현역에서 물러날 것이라는 점이다. 

애플스크립트가 무엇으로 대체될 지는 아직 답이 없는 쪽에 가깝다. 단축어가 그 자체만으로 궁극의 모든 것일 수는 없다. 애플리케이션의 정밀한 원격 제어 수준에 맞게 설계된 툴은 아니기 때문이다. 또한, 단축어에 넣는 동작이 많아질 수록 복잡 해진다. 어느 시점을 넘어서면 단순 인터페이스에 모이는 것이 아닌 스크립트로 따로 빼내야 할 것이다. (단축어 만들기용으로 설계된 스크립팅 언어인 젤리컷(Jellycuts)을 보라!)

필자는 스크립터가 쓰고자 하는 언어를 선택하게 해 주는 시스템을 선호한다. (아무도 하지 않는 이야기이지만 애플은 앞서 자바스크립트를 맥에서의 스크립팅에 쓸 애플스크립트의 동료로 추가한 바 있다.) 그러나 애플이 공식 스크립팅 언어를 선택할 가능성이 더 높다. 아마 자바스크립트가 될 것이다. 어디에나 있고 애플도 그 쪽에 경험이 있기 때문이다. 아니면 당연히 스위프트(Swift)의 단순 버전이 될 것이다.

그리고 혹시 가능성이 있을 수도 있는데 애플이 이 자동화 시스템을 한 번 구축한 후에는 맥뿐만 아니라 아이폰과 아이패드에도 배치할 지도 모른다.

이는 어려운 일이다. 그렇기 때문에 애플이 몇 년이 걸리는 전환이라고 분명히 밝혔던 것이다. 맥에서의 단축어는 위대한 첫 걸음이 될 것이지만, 차세대 맥 사용자 자동화가 지난 세대의 부담을 덜어줄 준비가 되려면 할 일이 더 많다. 몇 년이 걸리겠지만 미래는 밝다. editor@itworld.co.kr
 


2021.07.05

글로벌 칼럼 | M1, 맥OS 몬터레이, 그리고 ‘자동화 진화’가 이끄는 맥 판도 변화

Jason Snell | Macworld
지금의 맥은 그 어느때보다 애플의 강력한 도구다. 오늘날 애플 실리콘을 구동하는 맥들은 맥OS 앱 라이브러리 전체를 사용할 수 있고 iOS 앱 역시 카탈리스트(Catalyst)를 통하거나 직접 앱스토어(App Store)에서 수정되지 않은 상태로 사용할 수 있다. 그리고 내부에는 앱 스크립팅에서부터 유닉스(Unix) 기반의 각종 툴들에 이르는 모든 것이 있다. 

그런데 애플 실리콘으로의 전환, 그리고 다년 간에 걸친 자동화 전환의 일환으로 맥에 단축어가 도입된다는 6월 애플의 발표와 함께 상황이 변하고 있다. 맥이 강력한 도구라는 것에는 변화가 없겠지만, 향후 몇 년 간 맥의 속성이 근본적으로 달라질 것이다.
 

오토메이터를 대체할 단축어

단축어가 오토메이터(Automator)를 대체한다(정말 그렇게 된다)는 소식이 중요한 것은 단지 맥OS에 따끈따끈하게 새로운 사용자 자동화용 툴이 생기기 때문만은 아니다. 애플이 관심을 기울이고 있다는 중요한 징후이기 때문이다. 지난 몇 년간 맥 앱 개발자들은 앱에 자동화 기능을 추가하는 것이 의미 있다고 느끼기가 어려웠다. 그러나 이제는 단축어라는 해결책이 생겼다. 애플은 몇 년에 걸쳐 새로운 세계로 전환해 나갈 것이다.

이번 가을부터 맥 개발자들은 단축어 지원을 추가할 것이다. iOS에서처럼 앱이 단축어 앱에 동작을 “기부”하게 된다. 사용하는 앱의 기능이 단축어에 축적된다. 어떤 경우에는 이런 동작으로 앱이 열리고 작업이 수행되는 반면, 다른 경우에는 앱을 눈에 보이게 열 필요도 없이 앱 기능의 일부분을 해결이 필요한 문제에 적용할 수 있다.
 
단축어는 iOS에서 데뷔해 인기몰이를 했다. ⓒ Apple


유닉스의 지원을 받게 될 단축어

맥의 단축어는 iOS 및 아이패드OS 상에서 이용 가능한 것의 수준을 넘어선다. 유닉스 스크립팅 및 셸 지원에 직접 연결될 수 있기 때문이다. 단, 한 가지 큰 단점이 있다. 애플이 더 이상 일반 유닉스 스크립팅 시스템을 맥OS에 포함시키지 않기로 약속한 것이다. 맥OS 몬터레이(Monterey)에서 PHP는 이미 떠났고 펄(Perl), 파이썬(Python) 등은 곧 제거될 구형 버전이다.

이러한 점은 한편으로는 큰 문제가 되지 않는다. 여전히 PHP, 펄, 파이썬의 최신 버전을 맥OS 상에 설치할 수 있기 때문이다. (필자는 이를 위해 홈브루(Homebrew)를 사용한다.) 다른 한편으로는, 위와 같은 스크립팅 언어 중 하나에 의존하는 자동화를 구축 중이라면 자동화하고자 하는 맥에는 모두 해당 언어를 설치해야 한다.
 

다른 하나의 스크립팅 언어는 어떻게 되는가?

이는 더 큰 문제로 이어진다. 수십 년 동안 맥에서 애플리케이션 간 통신을 살아 있게 해 준 애플 이벤트(Apple Events) 기술과 애플스크립트(AppleScript)는 어떻게 되는가 하는 것이다. iOS에는 애플 이벤트에 상응하는 것이 없다. 믿기 힘들겠지만, URL을 앞뒤로 지나치는 것이 일반적인 통신 방법이 되었다. 그러나 애플은 최근 들어 시리 인텐트(Siri Intents)와 같은 기능들로 현대화를 진행 중이다. 

사실, iOS에서 대부분의 자동화는 서로 다른 앱들의 작은 부분들을 이용해 워크플로를 구축하는 것이 핵심이었다. 그것이 사용자 자동화 이야기의 중요한 부분이지만 또 다른 부분은 스크립팅을 통해 강력한 앱을 깊이 통제하는 능력이다. iOS에서는 이런 수준의 통제 능력이 있는 앱들은 자바스크립트 또는 파이썬에 기반한 자가 구현 매크로 엔진을 사용하는 경향이 있다. 가장 좋은 예라고 할 수 있는 옴니 그룹(Omni Group)의 풍부한 자바스크립트 기반의 자동화는 아이패드, 아이폰 또는 맥에서 옴니의 앱을 스크립트가 통제하게 해 준다.

모든 앱이 자체 스크립팅 또는 매크로 언어를 구현하는 것은 바람직한 길이 아니다. 플랫폼 소유자인 애플이 나서서 개발자와 사용자 모두를 위한 공통의 참조 프레임을 만들어야 한다.
 
애플스크립트의 수명이 얼마 남지 않았다. ⓒ Apple


맥OS에서의 스크립팅의 미래

몇 년이 걸릴 이번 전환이 끝나면 어떻게 될까? 가상 쉽게 예상할 수 있는 것은 1990년대 초반으로 거슬러 올라가는 애플스크립트가 마침내 현역에서 물러날 것이라는 점이다. 

애플스크립트가 무엇으로 대체될 지는 아직 답이 없는 쪽에 가깝다. 단축어가 그 자체만으로 궁극의 모든 것일 수는 없다. 애플리케이션의 정밀한 원격 제어 수준에 맞게 설계된 툴은 아니기 때문이다. 또한, 단축어에 넣는 동작이 많아질 수록 복잡 해진다. 어느 시점을 넘어서면 단순 인터페이스에 모이는 것이 아닌 스크립트로 따로 빼내야 할 것이다. (단축어 만들기용으로 설계된 스크립팅 언어인 젤리컷(Jellycuts)을 보라!)

필자는 스크립터가 쓰고자 하는 언어를 선택하게 해 주는 시스템을 선호한다. (아무도 하지 않는 이야기이지만 애플은 앞서 자바스크립트를 맥에서의 스크립팅에 쓸 애플스크립트의 동료로 추가한 바 있다.) 그러나 애플이 공식 스크립팅 언어를 선택할 가능성이 더 높다. 아마 자바스크립트가 될 것이다. 어디에나 있고 애플도 그 쪽에 경험이 있기 때문이다. 아니면 당연히 스위프트(Swift)의 단순 버전이 될 것이다.

그리고 혹시 가능성이 있을 수도 있는데 애플이 이 자동화 시스템을 한 번 구축한 후에는 맥뿐만 아니라 아이폰과 아이패드에도 배치할 지도 모른다.

이는 어려운 일이다. 그렇기 때문에 애플이 몇 년이 걸리는 전환이라고 분명히 밝혔던 것이다. 맥에서의 단축어는 위대한 첫 걸음이 될 것이지만, 차세대 맥 사용자 자동화가 지난 세대의 부담을 덜어줄 준비가 되려면 할 일이 더 많다. 몇 년이 걸리겠지만 미래는 밝다. editor@itworld.co.kr
 


X