MyControls는 2001년에 배포한 Classic Mac OS용 컨트롤패널 관리 유틸리티입니다. Mac OS X 등장 후 존재 이유가 사라지면서 2004년 유지보수를 중단했습니다. 지금 돌아보면 짧은 수명이었지만, 그 자체가 Mac 소프트웨어의 세대 전환 시기를 보여주는 사례라고 생각합니다.
Classic Mac OS의 컨트롤패널 시스템
Classic Mac OS의 컨트롤패널은 시스템 설정을 조작하는 별도 파일들이었습니다. 각 컨트롤패널은 시스템 폴더 안에 개별 파일로 존재하고, 시스템 부팅 시 로드되어 메뉴에서 접근 가능해졌습니다.
사용자가 설치할 수 있는 서드파티 컨트롤패널도 많았습니다. 확장 관리자, 프린터 드라이버, 네트워크 설정, 사용자 인터페이스 커스터마이징 등. 시스템 확장(Extensions)과 함께 이런 컨트롤패널은 Classic Mac OS의 확장성을 담당했습니다.
문제는 여러 컨트롤패널이 서로 충돌하는 경우가 흔했다는 점입니다. 특정 조합이 시스템 크래시를 일으키거나, 프린터 컨트롤패널과 네트워크 컨트롤패널이 리소스를 경쟁하거나, 최근 설치한 서드파티 컨트롤패널이 기존 앱을 망가뜨리는 상황.
이런 문제를 진단하려면 시스템 확장 관리자(Extensions Manager)에서 컨트롤패널을 하나씩 켜고 끄면서 원인을 찾아야 했습니다. 시스템 재부팅이 필요해 시간이 많이 걸렸습니다.
MyControls의 아이디어
편집팀 중 한 명이 자기 Mac에서 이 문제를 반복해서 겪은 경험이 MyControls의 시작점이었습니다. 아이디어는 단순했습니다. 사용자 목적별로 컨트롤패널 세트를 저장하고, 상황에 따라 원클릭으로 전환할 수 있게 하자.
기본 세트 예시:
일반 작업. 대부분의 컨트롤패널이 켜진 표준 세트.
인터넷 브라우징. 인터넷 관련 컨트롤패널만 활성. 다른 앱과의 충돌을 최소화.
프레젠테이션. 스크린 보호기, 알림, 스크립트 확장 등을 비활성. 프레젠테이션 중 방해 요소 제거.
네트워크 진단. 네트워크 관련 컨트롤패널만 활성. 네트워크 문제 진단 중 다른 변수 제거.
최소 부팅. 필수 컨트롤패널만 활성. 시스템 부팅 문제 진단용.
기술적 구현
MyControls는 자체적으로는 시스템 폴더를 조작하지 않았습니다. 대신 컨트롤패널 파일들의 활성/비활성 상태를 확장 관리자와 동일한 방식으로 관리했습니다.
Classic Mac OS의 확장 관리자는 컨트롤패널을 비활성화할 때 파일을 “Control Panels (Disabled)” 폴더로 이동시키는 방식을 썼습니다. MyControls도 이 규칙을 따랐고, 확장 관리자와 상태를 공유할 수 있었습니다.
세트 저장은 각 컨트롤패널의 활성 상태를 텍스트 파일로 기록. 사용자가 세트를 적용하면 MyControls가 이 텍스트 파일을 읽어 필요한 컨트롤패널을 활성 폴더로, 나머지를 비활성 폴더로 이동시켰습니다. 이후 시스템 재부팅이 필요했습니다.
UI 결정
MyControls의 메인 창은 컨트롤패널 리스트와 세트 관리 패널로 나뉘어 있었습니다. 사용자가 컨트롤패널을 드래그해 세트에 추가하거나 제거하는 방식.
이 드래그 앤 드롭 UX가 당시 사용자에게 좋은 평가를 받았습니다. Classic Mac OS의 UI 언어를 따르면서도 세트 개념을 직관적으로 표현했습니다.
덜 성공적이었던 결정은 알려진 컨트롤패널 조합에 대한 자동 충돌 감지였습니다. 특정 컨트롤패널이 함께 있으면 문제를 일으킨다는 데이터베이스를 앱에 내장하고, 사용자가 그런 조합을 만들려 하면 경고를 표시하는 기능.
이 데이터베이스를 최신 상태로 유지하는 것이 큰 부담이었습니다. 새 컨트롤패널이 자주 나왔고, 알려진 충돌은 일부에 불과했습니다. 데이터베이스가 오래되면 경고가 부정확해지고 오히려 사용자 신뢰를 잃었습니다.
Mac OS X의 등장과 존재 이유의 소멸
Mac OS X는 컨트롤패널 시스템 자체를 근본적으로 바꿨습니다. 시스템 환경설정(System Preferences, 지금의 System Settings)이 통합된 창으로 등장했고, 개별 컨트롤패널 파일 개념이 사라졌습니다.
사용자는 더 이상 컨트롤패널 파일을 개별적으로 관리하지 않았습니다. Preference Pane이라는 새로운 개념이 도입되었지만, 이것들은 시스템 환경설정 창의 아이콘일 뿐 파일 시스템 차원에서 개별 관리하지 않았습니다.
MyControls의 존재 이유가 사라진 셈입니다. 우리는 2001년 Mac OS X 정식 출시 후 몇 년 동안 Classic 환경에서 실행되는 MyControls를 유지했지만, Classic 자체가 Mac OS X 10.4 Tiger에서 사라지면서 앱의 미래가 끝났습니다.
유지보수 중단 결정
2004년 정식으로 MyControls의 유지보수 중단을 발표했습니다. 이 시점에서 사용자의 반응은 대체로 이해하는 편이었습니다. Classic 사용자가 급격히 줄고 있었고, MyControls의 필요성도 함께 줄었기 때문입니다.
다만 남아있는 Classic 사용자에게는 실질적 불편이 있었습니다. 이들은 대개 오래된 Mac을 유지하는 사용자이거나, 특정 Classic 앱에 의존하는 사용자였습니다. 우리는 이 사용자들에게 앱의 소스 코드 접근을 제한적으로 허용하는 것을 검토했지만, 결국 실현되지는 않았습니다.
지금은 어떻게 해결하는가
Mac OS X 이후 시스템 설정 프로파일 관리라는 개념 자체가 사라진 것은 아닙니다. 다만 개인 사용자 수준에서 이런 필요가 크게 줄었습니다.
기업이나 교육기관에서 여러 Mac을 관리하는 경우는 MDM(Mobile Device Management) 도구가 이 역할을 합니다. Jamf, Mosyle, Kandji 같은 상용 MDM 도구가 시스템 설정 프로파일을 배포하고 관리합니다.
개인 사용자 수준에서는 macOS의 Focus 모드가 유사한 개념을 부분적으로 수행합니다. 특정 상황에서 알림, 앱 접근, 홈 화면 배치를 다르게 하는 기능. MyControls가 다뤘던 문제의 축소판.
이렇게 보면 MyControls는 특정 시대의 문제를 풀었고, 그 시대의 종료와 함께 자연스럽게 사라진 도구입니다. 아쉽지 않다고 말하기는 어렵지만, 기술 전환기의 소프트웨어에게 이런 운명은 예외가 아닙니다.
배운 것
MyControls의 짧은 수명에서 우리가 배운 것은 다음과 같습니다.
플랫폼 전환기의 도구는 위험하다. 특정 OS 세대의 특성에 강하게 의존하는 도구는 그 세대와 함께 사라집니다. 우리가 몰랐던 것은 아니지만, 실제로 경험하는 것과 지식으로 아는 것은 다릅니다.
시스템 아래층에 의존하지 않는 편이 안전하다. MyControls는 시스템 폴더 구조에 직접 의존했고, 이 구조가 바뀌자 앱이 무의미해졌습니다. 시스템의 상위 API에 의존하는 앱이 하위 파일 구조에 의존하는 앱보다 장기적으로 안정적입니다.
필요가 사라지는 방식은 다양하다. 앱이 사용자에게 인기가 없어서 사라지는 경우도 있지만, MyControls처럼 앱이 풀던 문제 자체가 사라지는 경우도 있습니다. 후자는 개발자 관점에서 씁쓸하지만 사용자 관점에서는 좋은 결과입니다.
소프트웨어의 존재 목적은 때로 사용자보다 오래 남는다. Classic Mac OS 사용자 대부분이 Mac OS X로 옮긴 뒤에도, 여전히 Classic을 유지하는 소수의 사용자가 있었습니다. 이 사용자들에게 남긴 부채가 앱 종료 결정을 어렵게 만들었습니다.
기록으로 남기는 이유
지금 이 회고를 남기는 이유는 향수 때문이 아닙니다. Mac 소프트웨어를 오래 관찰해온 사람으로서, 특정 시대의 문제를 풀었던 도구가 그 시대의 종료와 함께 어떻게 사라지는지 기록으로 남기고 싶었습니다.
지금 만들어지는 Mac 소프트웨어도 언젠가 이런 자리에 있게 될 것입니다. 애플의 플랫폼 전환이 계속되고, 특정 시대의 필요를 채웠던 앱들이 그 필요와 함께 저물어갑니다. 이것은 Mac 소프트웨어 생태계의 자연스러운 패턴이고, 이해할 수록 지금의 앱을 어떻게 만들거나 선택할지에 대한 판단이 명확해집니다.