2000년대 초 Classic Mac OS 시대의 셰어웨어 배포는 지금의 앱스토어 배포와 여러 지점에서 근본적으로 달랐습니다. 트로픽 소프트웨어가 Phonebook과 MyControls를 배포하던 시기의 실제 흐름을 복기하면서, 그때와 지금의 차이를 정리해봅니다.
배포 채널
당시의 주요 배포 채널은 셋이었습니다. 첫째, 자체 웹사이트에서의 직접 다운로드. 둘째, Info-Mac, Umich Mac Archive 같은 대형 Mac 소프트웨어 아카이브. 셋째, MacUpdate와 VersionTracker 같은 소프트웨어 카탈로그 사이트.
각 채널에 새 버전을 배포하려면 개발자가 직접 파일을 업로드하거나, 카탈로그 사이트에 새 릴리스를 신고해야 했습니다. Info-Mac은 이메일로 압축 파일을 보내면 큐레이터가 검토 후 아카이브에 반영하는 구조였습니다. 지금 기준으로는 상상하기 어려운 수동적인 프로세스지만, 당시에는 그것이 표준이었습니다.
파일 형식
StuffIt 압축 (.sit)이 사실상 표준이었습니다. 나중에 .sit.hqx (BinHex 인코딩된 StuffIt) 형식이 이메일 전송용으로 자주 쓰였습니다. Aladdin Systems의 StuffIt Expander는 사실상 모든 Mac에 기본 설치된 도구였습니다.
Mac OS X가 등장한 뒤 .dmg (디스크 이미지)가 표준이 되었지만, 초기에는 두 형식이 공존했습니다. 트로픽 소프트웨어의 마지막 버전들은 .dmg로 배포되었습니다.
결제와 라이선싱
셰어웨어의 특징은 “먼저 사용해보고 마음에 들면 등록비를 낸다”는 명예 시스템이었습니다. 라이선스 키가 없어도 앱이 동작했고, 대신 실행할 때마다 “등록해주세요” 알림이 뜨거나, 일부 기능이 제한되는 방식이 일반적이었습니다.
결제 처리는 Kagi가 표준적인 대행 서비스였습니다. 개발자는 Kagi 계정을 만들고, 자신의 앱을 등록하고, 사용자는 Kagi 결제 페이지에서 신용카드로 결제한 뒤 이메일로 라이선스 키를 받았습니다. Kagi가 수수료를 떼고 남은 금액을 개발자에게 송금하는 구조였습니다.
Phonebook의 라이선스 키는 사용자 이메일과 이름을 조합한 해시 기반 문자열이었습니다. 앱이 자체적으로 해시를 재계산해 검증했습니다. 지금 기준으로는 리버스 엔지니어링에 쉽게 깨지는 방식이었지만, 셰어웨어 시장은 명예 시스템에 의존했기에 깨진 키가 유포되어도 큰 사업 위협은 아니었습니다.
업데이트 배포
자동 업데이트라는 개념이 표준이 아니었습니다. 개발자가 새 버전을 배포하면 사용자에게 알리는 방법은 다음 몇 가지였습니다.
메일링 리스트. 개발자 사이트에서 이메일을 남긴 사용자에게 새 버전 소식을 보내는 방식. 스팸이라는 개념이 아직 심각하지 않던 시기라 큰 저항 없이 통했습니다.
카탈로그 사이트 업데이트. VersionTracker와 MacUpdate에 새 버전을 등록하면, 사용자들이 그 사이트를 통해 새 버전을 알게 되었습니다. 많은 Mac 사용자가 정기적으로 이런 사이트를 방문했습니다.
앱 내 업데이트 체크. 일부 개발자는 앱 실행 시 자체 서버에 접속해 최신 버전을 확인하는 기능을 넣었습니다. 지금의 Sparkle 프레임워크 같은 표준화된 도구는 없었기에 각자 구현해야 했습니다.
지원과 커뮤니티
사용자 지원은 대체로 이메일로 이루어졌습니다. 개발자가 직접 답장했고, 답장 속도는 개발자에 따라 크게 달랐습니다.
Mac 커뮤니티는 지금보다 훨씬 작았고, MacInTouch, MacFixIt 같은 사이트가 뉴스와 트러블슈팅 중심점이었습니다. Ambrosia Software, Bare Bones Software 같은 독립 개발사가 문화적 리더 역할을 했습니다.
지금과의 차이
지금은 App Store가 대부분의 배포를 대체했습니다. Sparkle을 사용한 앱스토어 외부 배포도 여전히 유효한 채널이지만, 소비자 대상 앱의 상당수는 App Store를 통해 배포됩니다.
결제 처리도 근본적으로 바뀌었습니다. App Store 결제, Stripe, Paddle 같은 성숙한 결제 인프라가 개발자의 결제 처리 부담을 대부분 대체했습니다. Kagi 같은 개별 결제 대행사는 App Store 이후 대부분 사라지거나 축소되었습니다.
라이선스 관리도 서버 기반으로 옮겨갔습니다. 라이선스 키만으로 검증하는 대신, 서버에서 사용자 계정과 결합해 관리하는 방식이 표준이 되었습니다. 사용자가 여러 디바이스에서 로그인해 사용하는 흐름이 일반화되었기 때문입니다.
여전히 유효한 것
변한 것은 많지만 여전히 유효한 원칙도 있습니다.
사용자와 직접 소통하는 것의 가치. 지금도 인디 Mac 개발자들이 사용자 피드백에 개인적으로 답장하는 문화는 남아있습니다. Panic, Bare Bones, Rogue Amoeba 같은 오래된 인디 개발사는 여전히 이런 방식으로 신뢰를 유지합니다.
Mac 커뮤니티의 문화적 성격. 애플 자체가 소수 문화였을 때 형성된 Mac 사용자의 서로 챙기는 태도는 지금도 특정 커뮤니티에 남아있습니다.
도구가 오래 유지될 수 있다는 기대. Bare Bones의 BBEdit는 1993년부터 지금까지 유지되고 있고, 많은 인디 앱이 십 년 넘게 유지보수됩니다. 이런 지속성은 iOS 앱 시장에서는 상대적으로 드문 현상입니다.
기록으로 남기는 이유
이 노트는 향수를 자극하려는 목적이 아닙니다. 지금 Mac 소프트웨어를 만들거나 배포하는 사람에게, 이 생태계가 어디에서 왔는지 이해하는 것이 특정 결정을 내릴 때 도움이 될 수 있다고 생각합니다. 왜 특정 개발사가 App Store 외부 배포를 고집하는지, 왜 어떤 인디 앱은 수십 년 동안 같은 이름과 정체성을 유지하는지, 이런 질문의 답은 대개 이 시기의 문화에서 비롯됩니다.
트로픽 소프트웨어 자체도 이 시기의 문화 안에서 태어났습니다. 지금은 앱을 만들지 않지만, Mac 소프트웨어에 대해 쓰는 방식과 관점은 그 시절의 것에서 크게 달라지지 않았습니다.