Apple 단축어를 프로그래밍 언어로 만든다고? Cherri를 소개합니다

iPhone 단축어, 코드로 짤 수 있다면?

아이폰이나 맥을 쓰는 분이라면 '단축어(Shortcuts)' 앱을 한 번쯤 써보셨을 거예요. 블록을 끌어다 놓으면서 자동화를 만드는 그 앱이요. 예를 들어 "아침에 알람 끄면 자동으로 오늘 날씨를 읽어줘" 같은 걸 만들 수 있는데요. 문제는 조금만 복잡한 걸 만들려고 하면 블록이 수십 개, 수백 개로 늘어나면서 관리가 거의 불가능해진다는 거예요. 스크롤을 내리고 내리고 또 내려야 하고, 디버깅은 사실상 불가능하죠.

바로 이 고통을 해결하려고 나온 프로젝트가 Cherri예요. Cherri는 텍스트 기반 프로그래밍 언어인데, 이 코드를 컴파일하면 Apple 단축어 파일(.shortcut)이 뚝딱 만들어지는 구조거든요. 그러니까 GUI에서 블록을 끌어다 놓는 대신, 코드 에디터에서 타이핑해서 단축어를 만들 수 있는 거예요.

어떻게 동작하나요?

Cherri의 기본 원리는 생각보다 단순해요. Apple 단축어 파일의 내부 구조는 사실 plist라는 형식인데요, 이게 뭐냐면 Apple 생태계에서 설정 데이터를 저장할 때 쓰는 XML 기반 포맷이에요. 단축어 앱에서 블록을 배치하면 내부적으로 이 plist에 액션들이 순서대로 기록되는 거거든요.

Cherri는 자체 문법으로 작성된 소스 코드를 파싱해서, 이 plist 구조로 변환하는 컴파일러예요. Go 언어로 작성되어 있고, macOS와 Linux에서 모두 동작해요. 재밌는 점은 컴파일 결과물이 바이너리가 아니라 .shortcut 파일이라는 거예요. 이 파일을 AirDrop이나 iCloud로 아이폰에 보내면 바로 단축어 앱에서 실행할 수 있어요.

문법을 간단히 살펴보면, 변수 선언, 조건문, 반복문 같은 기본적인 프로그래밍 구조를 지원하고, Apple 단축어의 각종 액션들(알림 보내기, 웹 요청, 파일 조작 등)을 함수처럼 호출할 수 있어요. 예를 들어 사용자에게 입력을 받아서 처리하는 단축어를 만든다면, GUI에서는 블록 5~6개를 배치해야 할 걸 Cherri에서는 몇 줄의 코드로 끝낼 수 있는 거죠.

특히 버전 관리가 가능해진다는 게 큰 장점이에요. 단축어 파일은 바이너리에 가까워서 Git으로 변경 내역을 추적하기 어려운데, Cherri 소스 코드는 일반 텍스트 파일이니까 Git diff로 뭐가 바뀌었는지 한눈에 볼 수 있거든요.

비슷한 프로젝트들과 비교

사실 Apple 단축어를 코드로 작성하려는 시도가 Cherri만 있는 건 아니에요. Jellycuts라는 프로젝트도 비슷한 접근을 했었는데, 현재는 유지보수가 활발하지 않은 상태예요. Cherri가 다른 점은 Go로 작성되어 크로스 플랫폼 빌드가 쉽고, 문법이 좀 더 일반적인 프로그래밍 언어에 가깝다는 거예요.

더 넓게 보면, 이건 로우코드/노코드 도구의 한계를 코드로 극복하려는 흐름의 일부이기도 해요. Zapier, IFTTT, Apple 단축어 같은 도구들이 처음엔 편리하지만, 복잡도가 올라가면 결국 코드가 필요해지는 패턴이 반복되거든요. Terraform이 AWS 콘솔 클릭 대신 인프라를 코드로 관리하게 해준 것처럼, Cherri는 단축어를 코드로 관리하게 해주는 셈이에요.

또한 Apple이 최근 Shortcuts를 macOS에도 확장하고, Siri와의 통합을 강화하면서 단축어의 활용 범위가 넓어지고 있다는 점도 Cherri 같은 도구의 가치를 높여주는 배경이에요.

한국 개발자에게 주는 시사점

솔직히 말하면, Cherri로 당장 프로덕션 수준의 뭔가를 만들 일은 많지 않을 거예요. 하지만 몇 가지 흥미로운 포인트가 있어요.

첫째, 개인 자동화의 수준을 한 단계 올릴 수 있어요. 맥을 메인으로 쓰는 개발자라면, 반복적인 워크플로우를 단축어로 만들어두는 경우가 있을 텐데, Cherri를 쓰면 이걸 훨씬 체계적으로 관리할 수 있어요. dotfiles처럼 자동화 스크립트를 Git 레포로 관리하는 거죠.

둘째, 컴파일러와 언어 설계에 관심 있는 분에게는 좋은 학습 자료예요. Cherri의 소스 코드가 Go로 깔끔하게 작성되어 있어서, "프로그래밍 언어를 만든다는 게 실제로 어떤 과정인지" 궁금한 분이라면 코드를 읽어보는 것만으로도 많은 걸 배울 수 있어요. 렉서, 파서, 코드 생성이라는 컴파일러의 세 단계를 실제 프로젝트에서 확인할 수 있으니까요.

셋째, 이 프로젝트가 보여주는 패턴 자체가 영감을 줄 수 있어요. "기존 플랫폼의 불편한 인터페이스를 더 나은 인터페이스로 감싸기"라는 아이디어는 어디에나 적용할 수 있거든요. 여러분의 업무에서 반복적으로 GUI를 클릭해야 하는 작업이 있다면, 그걸 코드로 자동화하는 도구를 만들어볼 수도 있겠죠.

정리

Cherri는 Apple 단축어의 GUI 한계를 텍스트 기반 코드로 극복하려는 오픈소스 프로젝트예요. 단축어 자동화를 많이 쓰는 Apple 유저 개발자라면 한번 살펴볼 만하고, 컴파일러 설계에 관심 있는 분에게는 훌륭한 학습 자료이기도 해요.

여러분은 자동화 도구를 쓸 때 GUI와 코드 중 어느 쪽을 선호하시나요? 복잡도가 어느 수준을 넘으면 코드로 전환하는 편인가요?