Phonebook은 트로픽 소프트웨어가 2000년 여름 처음 배포한 앱입니다. Classic Mac OS용 컴팩트 연락처 데이터베이스로, 2005년까지 유지되었습니다. 20년 넘게 지난 지금 돌아보면서, 그때의 선택이 어떤 것이었고 지금 다시 만든다면 무엇을 다르게 할지 정리합니다.
왜 만들었는가
2000년 당시 Mac 사용자의 연락처 관리 옵션은 제한적이었습니다. Now Contact와 Palm Desktop이 상용 시장의 강자였고, Claris Organizer는 이미 유지보수 중단 상태였습니다. 이 상용 앱들은 기능이 풍부한 대신 무거웠고, 단순한 연락처 관리만 필요한 사용자에게는 과했습니다.
많은 사용자가 그 대안으로 텍스트 파일에 연락처를 관리하거나, FileMaker Pro로 자체 데이터베이스를 만들어 썼습니다. 이 사이의 빈틈이 우리가 노린 자리였습니다. 가볍고, 단순하고, 필요한 필드만 지원하는 연락처 앱.
기술 스택 선택
당시 Classic Mac OS용 앱 개발의 표준 스택은 Metrowerks CodeWarrior와 PowerPlant 프레임워크였습니다. Apple의 MPW (Macintosh Programmer’s Workshop)는 이미 후퇴하고 있었고, CodeWarrior가 사실상 표준이었습니다.
우리는 CodeWarrior + PowerPlant + C++를 선택했습니다. 이유는 단순합니다. 이 조합이 당시 Mac 개발 생태계에서 가장 성숙한 툴체인이었고, 문서와 커뮤니티 지원이 풍부했기 때문입니다.
Carbon과 Cocoa 사이의 선택 문제도 있었지만, Phonebook 첫 배포 시점에는 Carbon만 실용적 선택이었습니다. Cocoa는 Mac OS X의 정식 출시(2001년 3월) 전이었고, Classic Mac OS에서는 실행되지 않았습니다.
데이터 저장 방식
이 부분에서 우리는 몇 가지 잘못된 결정을 했습니다.
Phonebook의 데이터 저장 형식은 자체 이진 포맷이었습니다. 필드별 오프셋과 크기가 하드코딩되어 있고, 버전 업그레이드 시 마이그레이션 코드를 따로 작성해야 했습니다. 표준 SQLite를 쓸 수 있었으면 더 나았을 것 같지만, 당시 Classic Mac OS에서 SQLite의 실용성은 낮았습니다.
대안으로 XML 기반 포맷을 고려했지만, 파일 크기와 파싱 비용 때문에 포기했습니다. 지금 돌아보면 XML을 썼어도 충분했을 것 같지만, 2000년의 하드웨어 성능과 사용자 데이터 규모를 감안하면 그때 판단도 이해할 만합니다.
잘한 선택은 vCard 임포트/익스포트를 첫 버전부터 지원한 것입니다. 사용자가 자신의 데이터를 언제든 표준 포맷으로 뽑아갈 수 있다는 안전감을 제공했고, 나중에 우리 앱이 유지보수 중단됐을 때 사용자가 Apple Address Book으로 옮겨가는 경로가 되었습니다.
UI 결정
Phonebook의 메인 창은 세 개 패널로 나뉘어 있었습니다. 왼쪽에 카테고리 목록, 가운데에 연락처 목록, 오른쪽에 선택된 연락처의 세부 정보. Mail.app이나 Finder의 컬럼 뷰와 유사한 구조입니다.
이 세 패널 구조는 결과적으로 오래 유효한 패턴이었습니다. 지금 Contacts.app도 유사한 구조이고, 대부분의 데이터베이스 관리 앱이 이 패턴을 따릅니다.
덜 성공적이었던 결정은 커스텀 아이콘 세트였습니다. 우리는 사용자가 각 연락처에 아이콘을 지정할 수 있는 기능을 넣었습니다. 지금 생각하면 프로필 사진을 지원했어야 했지만, 당시에는 아이콘이 더 가볍고 스타일리시하다고 판단했습니다. Address Book이 프로필 사진 지원을 표준화한 뒤 우리 앱의 아이콘 시스템은 시대에 뒤처져 보이게 되었습니다.
배포와 라이선싱
StuffIt 형식으로 압축한 .sit 파일을 우리 웹사이트와 Info-Mac, Umich 아카이브에 배포했습니다. Kagi를 통해 결제를 처리했고, 라이선스 키는 이메일과 이름을 조합한 해시 기반 문자열이었습니다.
등록비는 $19.95였습니다. 당시 셰어웨어 시장에서 중간 가격대. 낮으면 개발 비용을 회수하기 어렵고, 높으면 사용자가 대안을 찾아 떠나갔습니다.
이 가격이 정당한 수준이었는지에 대해서는 지금도 판단이 어렵습니다. 앱스토어 이후의 표준화된 가격 구조 안에서는 $19.95는 오히려 비싸 보이지만, 당시 개발 비용과 배포 인프라 비용을 감안하면 적정선이었습니다.
사용자 지원의 실제
사용자 지원은 대부분 이메일이었습니다. 우리는 답장 속도를 자랑스럽게 여겼습니다. 대개 24시간 안에 답장했고, 복잡한 문제는 며칠 안에 해결책과 함께 회신했습니다.
이 부분이 셰어웨어 시장에서 우리 앱의 신뢰를 유지한 핵심이었다고 지금도 생각합니다. 기능 자체는 경쟁 앱과 유사했지만, 개별 사용자 문의에 실제 개발자가 답장한다는 사실이 사용자 커뮤니티에서 언급되었습니다.
가장 자주 온 문의는 마이그레이션 관련이었습니다. Now Contact나 다른 앱에서 Phonebook으로 옮기려는 사용자가 자신의 데이터를 어떻게 변환할지 물었습니다. 우리는 몇 가지 표준 포맷에 대한 변환 유틸리티를 별도로 배포했습니다.
Mac OS X 전환의 어려움
2001년 Mac OS X 정식 출시 후 우리는 Phonebook을 Carbon 앱으로 유지했습니다. Cocoa로 재작성하는 대신 Carbon 브릿지를 사용해 새 OS에서 실행되도록 하는 선택이었습니다.
이 결정은 단기적으로 맞았지만 장기적으로는 부담이 되었습니다. Carbon은 Apple의 로드맵에서 점차 밀려나는 상태였고, 새 macOS 기능(Spotlight 통합, iCloud 동기화 등)을 지원하려면 결국 Cocoa 재작성이 필요했습니다. 우리는 이 전환의 리소스가 없어서 결국 앱을 유지보수 중단하기로 결정했습니다.
지금 생각하면 2003년 시점에서 Cocoa 재작성을 시작했어야 했습니다. 미룰수록 재작성 비용이 커지고, 사용자 경험이 다른 앱에 비해 낡아 보이는 문제가 심해집니다.
2005년 유지보수 중단
2005년 Apple의 Address Book이 iSync를 통해 여러 디바이스와 동기화를 시작하면서, 서드파티 연락처 앱의 실용적 자리가 크게 줄었습니다. 우리는 Phonebook의 유지보수를 정식으로 중단하기로 결정했습니다.
이 결정에 대한 사용자 반응은 대체로 이해하는 편이었습니다. 우리는 마지막 업데이트에서 Address Book으로의 마이그레이션 유틸리티를 포함시켰고, 사용자가 자신의 데이터를 옮길 수 있는 경로를 확보한 뒤 배포를 종료했습니다.
이 종료 방식이 우리가 잘한 몇 가지 중 하나였다고 지금도 생각합니다. 사용자를 갑자기 남겨두지 않고, 다음 단계로 넘어갈 수 있는 경로를 제공한 뒤 문을 닫는 것.
지금 다시 만든다면
2025년 기준으로 Phonebook 같은 앱을 다시 만들 것인가에 대한 답은 “만들지 않는다”입니다. Apple의 Contacts.app이 대부분의 사용자에게 충분한 수준이 되었고, 파워 유저는 이미 Cardhop이나 유사 앱을 사용합니다. 새 진입자의 자리가 없습니다.
다만 우리가 배운 몇 가지 원칙은 지금의 편집 활동에도 반영되어 있습니다.
데이터 이식성을 첫날부터 지원할 것. 사용자가 자신의 데이터를 뽑아갈 수 있는 표준 포맷을 늘 제공.
사용자 지원에 실제 사람이 답장할 것. 자동화된 응답이나 지원 티켓 시스템의 벽 뒤에 숨지 않을 것.
기술 스택 전환을 미루지 말 것. 미룰수록 비용이 커지고 결국 앱의 생명을 단축시킵니다.
종료할 때 사용자를 존중할 것. 마이그레이션 경로 없이 문을 닫지 않을 것.
이 원칙들은 앱을 만들지 않는 지금의 편집 활동에도 그대로 유효합니다. 독자와의 신뢰는 결국 이런 태도에서 축적됩니다.