1. Shoes의 철학과 초기 성공
Shoes는 기술적인 성취보다 ‘감성적인 통찰’에 기반을 둔 프로젝트였습니다. 개발자 _why는 아이디어가 떠오른 순간부터 프로그램이 실행되기까지의 과정을 방해하는 모든 요소(보일러플레이트, 복잡한 임포트, 빌드 시스템 등)를 제거하고자 했습니다. 단 몇 줄의 루비 코드만으로 버튼이 포함된 윈도우를 띄울 수 있는 Shoes의 간결함은 프로그래밍을 처음 배우는 사람들에게 강력한 동기를 부여했습니다. 특히 배경 그라데이션, 스택 및 플로우 레이아웃 등을 직관적인 문법으로 처리할 수 있었던 점은 당시로서는 매우 혁신적이었습니다.
2. 네이티브 GUI의 기술적 한계와 프로젝트의 위기
초기 Shoes는 리눅스의 GTK, 맥의 Cocoa, 윈도우의 Win32와 같은 네이티브 GUI 툴킷을 기반으로 구축되었습니다. 이는 2008년 당시에는 합리적인 선택이었으나, 결과적으로 프로젝트의 지속 가능성을 저해하는 원인이 되었습니다. 각 플랫폼마다 서로 다른 API와 이벤트 모델, 레이아웃 방식을 가지고 있어 모든 기능을 세 번씩 구현해야 했고, 버그 또한 플랫폼마다 다르게 나타났습니다. _why가 떠난 이후, 커뮤니티는 Shoes3와 Shoes4(JRuby 기반)를 통해 이를 유지하려 노력했으나 네이티브 툴킷의 복잡성을 감당하기에는 역부족이었습니다.
3. Scarpe: 웹 기술을 통한 현대적 접근 방식
Scarpe 프로젝트는 네이티브 GUI와 싸우는 대신, 로컬 웹뷰(Webview)를 통해 HTML로 렌더링하는 방식을 채택했습니다. 이는 현대의 모든 데스크톱 운영체제가 고성능 HTML 렌더러를 내장하고 있다는 점에 착안한 것입니다.
- 렌더링 메커니즘: 루비로 작성된 Shoes 코드는 내부적으로 DOM 조작으로 번역되어 가벼운 브라우저 창에서 실행됩니다.
- 장점: CSS 레이아웃과 자바스크립트 이벤트 처리가 플랫폼 간에 일관되게 작동하므로 유지보수 부담이 획기적으로 줄어듭니다.
- 호환성: Shoes의 독특한 개념들(플로우 레이아웃, 그리기 프리미티브 등)을 HTML로 완벽하게 매핑하는 과제가 남아있지만, 이는 네이티브 API를 해킹하는 것보다 훨씬 해결 가능한 문제입니다.
4. Hackety Hack 호환성과 교육적 가치
Scarpe의 성공 여부를 판단하는 기준은 ‘_why가 만든 루비 교육 환경인 Hackety Hack을 구동할 수 있는가’에 있습니다. 현재 Scarpe는 사이드바 렌더링, 레슨 로딩, 그리고 별, 타원, 사각형과 같은 대부분의 예술적 프리미티브를 지원하는 수준에 도달했습니다. animate나 every 같은 타이머 기능과 배경 그라데이션 기능도 구현되어, 아이들이나 예술가들이 코딩을 통해 시각적인 결과물을 즉각적으로 확인하는 Shoes 특유의 경험을 복원하고 있습니다.
5. 배포 문제의 해결: Traveling Ruby와 패키징
루비 데스크톱 애플리케이션의 고질적인 문제는 사용자 환경에 루비를 설치하고 젬(Gem) 의존성을 관리하는 것이 매우 어렵다는 점이었습니다. Scarpe는 Traveling Ruby를 활용하여 이 문제를 해결했습니다.
- 독립형 패키지: 루비 런타임과 필요한 젬들을 모두 포함하여 약 13MB 크기의 독립형 macOS
.app번들을 생성할 수 있습니다. - 간편한 명령:
scarpe package myapp.rb명령 하나로 시스템에 루비가 설치되지 않은 사용자도 실행할 수 있는 결과물을 만들어냅니다. - 향후 계획: 현재 macOS에서 검증된 이 방식을 윈도우와 리눅스 대상으로 확대하여 개발자 경험을 더욱 개선할 예정입니다.