macOS에서 CLI 도구가 설정 파일을 ~/Library/Application Support에서 찾도록 하는 관행은 사용자 기대와 Apple 문서의 취지 모두에 어긋난다. GUI 앱이 사용자를 대신해 설정을 관리하는 경우를 제외하면, CLI 도구는 XDG Base Directory 사양을 따라 기본값 ~/.config($XDG_CONFIG_HOME)에 설정을 두어야 한다.
macOS에서 실행되는 커맨드라인 도구가 사용자 설정 파일을 ~/Library/Application Support에서 찾는 관행은 내가 특히 못마땅하게 여기는 점 중 하나다. 사용자 관점에서의 사용성이 나쁠 뿐 아니라, 이를 정당화하기 위해 인용되는 문서에 비추어 보더라도 이 동작은 잘못되었다고 생각한다. 대신 커맨드라인 도구는 XDG Base Directory Specification을 구현하고, 기본값이 ~/.config인 $XDG_CONFIG_HOME에서 설정 파일을 찾아야 한다.
대개 어떤 프로그램이 설정 파일을 ~/Library/Application Support에서 찾는 이유는 의도적인 설계 결정 때문이 아니다. 보통은 그 결정을 라이브러리에 위임했고, 플랫폼별 설정 디렉터리를 정해 주는 여러 인기 라이브러리가 macOS에서 기본 설정 디렉터리로 ~/Library/Application Support를 사용한다. 예를 들어 Python의 platformdirs 패키지(월 2.42억 다운로드), JavaScript의 env-paths(월 9,500만 다운로드), Rust의 dirs 크레이트(월 480만 다운로드), Go의 adrg/xdg 패키지(913개 패키지에서 사용) 등이 있다. ~/Library/Application Support가 사용자를 대신해 설정 파일을 자동으로 관리하는 GUI 앱 에는 적절한 위치일 수 있지만, 이들 라이브러리를 사용하는 애플리케이션 대부분은 커맨드라인 유틸리티이고, 그 설정은 ~/.config에 있어야 한다.
내가 프로그램이 ~/Library/Application Support에서 도트파일을 찾는 것을 싫어하는 가장 큰 이유는 그것이 예상 밖이기 때문이다. Ashlin Eldridge가 GitHub에서 설명했듯이:
신규 사용자로서,
nu같은 현대적인 도구가 macOS에서 설정 파일을 Application Support 아래에 두는 것은 정말 놀랍습니다. 더 놀라운 점은 일부 사람들이 적극적으로반대한다는 것입니다. XDG 표준 채택을요.XDG의 기원은 이제 중요하지 않습니다. X, D, G가 무엇을 뜻하는지 신경 쓰는 사람은 거의 없습니다. 중요한 사실은 수백 개의 도구가 이를 지원한다는 점(예: Git, Emacs, Neovim, Tmux)이며, 사용자들은 그 지원을 기대하게 되었다는 것입니다. 이는 사용자가 설정 파일의 위치를 제어할 수 있게 해 주는 사실상 유일한 표준(이는 사용자가 파일을 버전 관리하기 쉽게 해 줍니다)이고, 동시에 캐시/데이터 파일처럼 버전 관리에 포함되지 말아야 할 파일도 구분해 줍니다.
사용자가 어떤 프로그램의 동작이 놀랍다고 설명하면, 많은 엔지니어는 그 사용자의 기대가 틀렸다고 응답하곤 한다. 하지만 사용자가 잘못된 정신 모델을 갖게 되는 이유는 대개 프로그램 설계가 더 넓은 맥락에서 이미 자리 잡은 관례를 위반했기 때문이다. 최소 놀람의 원칙에 따라, 나는 사용자가 기대하는 방식으로 프로그램을 바꾸는 편을 선호한다. 사용자 기대를 바꾸려는 시도는 대개 헛수고이기 때문이다.
사용자들이 macOS CLI 도구가 설정 파일을 ~/.config에서 찾기를 기대하는 이유는, 거의 모든 다른 프로그램이 그렇게 하기 때문이다. 설정 파일이 어디에 있어야 하는지에 대해, 당신의 프로그램이 Bash, Vim, Git과 다르게 행동할 이유는 아마도 없을 것이다!
이러한 관례는 시스템의 한 부분에 대한 지식을 다른 부분에 적용할 수 있게 해 주어, 낯선 시스템을 탐색하는 데 도움을 준다. 일관성은 곧 예측 가능성이다. 대부분의 도구가 같은 방식으로 동작하는데 소수만 예외적으로 다르게 동작하면, 사용자는 시간을 낭비하게 만드는 그 예외들에 짜증 내는 것이 정당하다.
많은 엔지니어들이 이러한 설정 파일을 추적하기 위해 일종의 dotfile 매니저를 사용(혹은 유지보수)한다. 만약 설정 파일이 정말 ~/Library/Application Support에 있어야 한다면, macOS에서 실행될 때 dotfile 매니저들도 기본적으로 설정 파일을 그곳에 두도록 할 것이라 기대할 수 있다. 결국 dotfile 매니저의 요지는 여러 머신과 플랫폼에 걸쳐 설정 파일 관리를 단순화하는 것이니까. 그럼 macOS에서 인기 있는 몇 가지 dotfile 매니저가 어떻게 행동하는지 간단히 살펴보자:
~/Library/Application Support로 설정을 연결하려는 시도를 전혀 하지 않는다. 특히 macOS에서 chezmoi를 사용하는 방법을 문서화해 두었음에도 말이다.~/Library/Application Support를 무시한다. 예제에는 macOS 전용 설정 파일이 포함되어 있지만, README에는 macOS에서 완전히 무시될 VS Code 설정이 나온다.~/Library/Application Support 지원을 위해 아무런 시도를 하지 않는다. 예제 설정에 macOS 전용 부분이 있지만 ~/Library/Application Support는 언급하지 않는다.~/Library/Application Support 지원을 위해 아무런 시도를 하지 않는다.~/Library/Application Support를 지원하려는 시도를 하지 않는다.이들 도구 대부분은 요청하면 설정 파일을 ~/Library/Application Support에 연결 할 수 있다(다만 macOS는 심심치 않게 심볼릭 링크를 대상 파일의 복사본으로 바꿔 버리곤 한다). 그러나 기본값으로 그렇게 하지 않는다는 사실 자체가 많은 것을 시사한다. 사용자는 오직 특정한, 문제를 일으키는 소수의 프로그램 때문에만 이런 동작을 원한다.
어쩌면 “일관성”만으로는 다른 프로그램들처럼 당신의 프로그램 설정 파일을 ~/.config에 두어야 할 충분한 이유가 되지 않을 수도 있다. 개발자 기대와 맞지 않더라도, 프로그램은 플랫폼 가이드라인을 따라야 한다고 생각할 수도 있다. @soc는 GitHub에서 이렇게 표현했다:
macOS 개발자에게 드리는 일반적인 조언: 그들의 플랫폼에서 개발한다면, 플랫폼 소유자가 하라는 대로 하십시오. 그들이 영주이고, 당신은 소작농입니다.
또 다른 곳에서, Reilly Wood는 “Application Support를 아예 사용하지 않으면 어떤 단점이 있나요?”라는 사용자 질문에 대해, “[Nushell은] 더 이상 macOS 표준 디렉터리 가이드라인을 따르지 않게 될 것”이라고 반박한다.
곧 해당 가이드라인을 읽어 보겠지만, 애초에 그것들이 관련이 있는지조차 확신할 수 없다. XDG Base Directory Specification은 유닉스를 몇 차례 언급하지만, macOS나 다른 운영체제에 대한 예외 규정은 어디에도 없다. ~/.config가 유닉스 계열 운영체제에서 설정 파일의 표준 위치로 받아들여진다면, BSD 계통의 유닉스인 macOS에서도 당연히 표준 위치여야 하지 않겠는가.
그럼에도 불구하고, XDG 사양이 명시하지도 않았는데 일부 유닉스 운영체제에만 적용된다고 가정해 보자. macOS 표준 디렉터리 문서는 “시스템이 제공하든 앱이 생성하든, 모든 파일은 macOS에서 제자리를 갖는다”고 시작한다. 사실 이 문장에서 독해를 멈춰도 된다. 왜냐하면 커맨드라인 도구는 시스템도, 앱도 아니기 때문이다.
이것이 지나치게 사소한 딴지처럼 보일 수 있지만, 실제로는 이 문서를 올바르게 해석하는 데 결정적 이다! 나는 이 가이드라인을 인용하는 많은 개발자들이 macOS에 대해 잘 모르고, ‘앱’이 단지 실행 파일을 뜻한다고 생각하는 게 아닌가 의심한다. 그러나 그건 사실이 아니다. 몇 스크린 아래 같은 페이지는 /bin이 “핵심적인 커맨드라인 바이너리를 포함한다”고 말한다. 즉, 문서의 작성자들은 앱과 커맨드라인 도구를 혼동하지 않는다. macOS의 앱은 /Applications에 설치되고, 추가적인 여러 요구사항의 적용을 받는다. 번들 ID(예: Preview.app의 com.apple.Preview)부터 앱 아이콘, 런치 스크린, 코드 서명, 공증, 앱 샌드박싱, 런타임 하드닝까지 말이다. 말할 것도 없이, 커맨드라인 유틸리티를 배포하는 개발자들이 이런 가이드라인을 따르는 일은 없다.
다음으로, ~/Library/Application Support에 대한 문서는 다음과 같이 말한다:
앱별 데이터와 지원 파일 전부를 포함합니다. 이는 사용자를 대신하여 앱이 생성하고 관리하는 파일로, 사용자 데이터가 포함된 파일도 여기에 포함될 수 있습니다.
다시 말하지만, 커맨드라인 도구는 앱이 아니므로 앱별 데이터가 전혀 없다. 더 나아가 도트파일은 대개 사용자가 직접 작성하며, 사용자를 대신하여 관리되지 않는다.
다음 문단은 ~/Library/Application Support가 오직 앱을 위한 것임을 아주 명확히 한다:
관례에 따라, 이러한 항목은 모두 앱의 번들 식별자와 이름이 일치하는 하위 디렉터리에 넣어야 합니다. 예를 들어, 앱 이름이
MyApp이고 번들 식별자가com.example.MyApp라면, 사용자별 데이터 파일과 리소스는~/Library/Application Support/com.example.MyApp/디렉터리에 둡니다. 필요한 경우 이 디렉터리를 생성하는 것은 앱의 책임입니다.
커맨드라인 도구는 번들 식별자가 없다. 이는 Apple이 macOS에 기본 제공하는 다수의 커맨드라인 도구(예: ls, vim)도 마찬가지다. 또한 Apple이 다른 현대 유닉스 계열 운영체제의 동등한 도구들과 미묘하게 다르게 동작하는 커맨드라인 도구를 배포하는 데 매우 익숙하다고 하더라도, macOS의 bash, zsh, git, vim은 모두 같은 위치 ~/.config에서 설정 파일을 찾는다. 당신의 도구가 /Applications에 설치되지 않는 한, 그 설정이 ~/Library/Application Support에 있어야 할 이유는 없다.
~/Library/Application Support는 언제 사용해야 할까요위에서 살펴본 가이드라인과 관례를 염두에 두면, 다음 두 가지 조건을 모두 만족하는 경우에만 애플리케이션의 설정 파일을 $XDG_CONFIG_HOME 대신 ~/Library/Application Support에 저장해야 한다:
/Applications 또는 ~/Applications에 설치되어 있다.사용자들은 macOS에서 커맨드라인 도구가 설정 파일을 ~/Library/Application Support에서 찾으리라 기대하지 않는다. dotfile 매니저들도 macOS에서 설정 파일을 ~/Library/Application Support에 두지 않는다. 설정 파일을 ~/Library/Application Support에 두어야 한다는 흔한 근거들은 애초에 커맨드라인 도구에 적용되도록 쓰인 것이 아니다. 심지어 Apple이 배포하는 bash와 git 같은 커맨드라인 도구도 설정 파일을 ~/.config에서 찾는다.
제발, 제발, 제발 XDG Base Directory Specification만 사용하자.