chezmoi vs 심링크 dotfiles — 근본 차이와 언제 무엇을 쓸까

dotfiles를 관리하는 방식을 고를 때 chezmoi를 만나면 “심링크랑 뭐가 다른데?”에서 멈추기 쉽다. 둘은 같은 문제(여러 머신에서 설정 공유)를 풀지만 층위가 다르다. chezmoi는 템플릿을 apply 시점에 그 머신용 실파일로 렌더하는 dotfile 매니저고, 심링크 방식은 원본을 그대로 홈에 링크한 뒤 머신 차이를 셸이 런타임에 분기한다.

이 글은 그 근본 차이를 정리하고, chezmoi가 실제로 값을 하는 경우와 심링크가 더 나은 경우를 가른다. 심링크 방식 자체의 셋업(멱등 링크 헬퍼·bootstrap·시크릿 분리)은 dotfiles를 git 저장소 + 심볼릭 링크로 관리하기에서 다룬다.

근본 차이 — 머신 분기를 ‘언제’ 확정하나

	심링크 방식	chezmoi
머신 차이 처리	런타임 — 셸이 ~/.secrets를 source해 분기	apply 시점 — 렌더 한 번으로 확정
~/.zshrc의 정체	심링크 (조건문이 파일에 내장)	렌더된 실파일 (분기 흔적 없음)
편집→반영	즉시 (같은 inode를 가리킴)	chezmoi apply 필요
drift(원본과 어긋남)	구조적으로 불가 (항상 동기)	복사본이라 발생 가능 → diff/status가 존재하는 이유

한 문장으로 요약하면: chezmoi는 머신 분기를 런타임에서 빌드(apply)타임으로 옮긴다.

심링크 방식에서 ~/.zshrc는 저장소 원본을 가리키는 링크 하나다. 머신마다 다른 값은 파일 안 조건문이나 ~/.secrets source로 실행 시점에 갈린다. 반면 chezmoi의 ~/.zshrc는 템플릿을 렌더해 만든 평범한 실파일이다. 조건 분기는 이미 apply 때 끝나 있어서 파일 자체엔 흔적이 없다.

이 차이가 곧 각 방식의 장단점을 결정한다. 심링크는 편집이 즉시 반영되고 원본과 어긋날 일이 없다(같은 inode니까). chezmoi는 복사본이라 편집 후 apply를 잊으면 원본과 어긋나는 drift가 생길 수 있고, 그래서 chezmoi diff·chezmoi status로 “지금 어긋나 있나”를 확인하는 명령이 따로 있다.

언제 chezmoi가 값을 하나

chezmoi의 이득은 딱 이 세 경우다.

1. 남이 클론해 자기 머신에서 그대로 돌리게 하고 싶을 때 — chezmoi init --apply <repo> 한 줄로 클론·렌더·적용이 끝난다. 심링크 방식으로는 주기 어려운 경험이다.
2. 여러 머신인데 config 내용이 갈릴 때 — 경로 수준을 넘어 이메일·툴셋·호스트별 값처럼 파일 내용 자체가 머신마다 다른 경우. 템플릿이 이 분기를 깔끔하게 흡수한다.
3. 비셸 config에 머신별 값이 필요할 때 — .gitconfig·각종 JSON 설정은 런타임에 source로 분기할 수 없다. 이런 파일은 렌더 시점 분기가 유일하게 깔끔한 길이다.

이 셋에 해당하지 않으면 심링크가 더 낫다. 즉시 반영되고, drift가 구조적으로 불가능하며, 이해할 게 적다. 개인 1머신이거나 머신 차이가 경로 수준(환경변수로 처리 가능)에 그친다면, chezmoi 도입은 일상 편집에 apply 한 단계를 얹어 무겁게만 만든다.

대중성 — 어디쯤 위치한 도구인가

dotfile 매니저 중에서는 1티어다. GNU stow와 양대 축을 이루고, 템플릿·시크릿 기능에서는 chezmoi가 우위다. 다만 짚어둘 것: 전체 dotfiles 사용자 인구로 보면 손수 짠 스크립트나 bare git 방식이 다수다. 매니저를 안 쓴다고 outdated인 것은 아니다 — 도구 없이 링크 스크립트 하나로 충분한 경우가 실제로 많다.

정리하면 선택은 매니저냐 아니냐가 아니라 “내 분기가 런타임으로 충분한가, 렌더가 필요한가”다. 렌더가 필요한 세 경우면 chezmoi, 아니면 심링크(또는 stow)로 충분하다.

관련: chezmoi를 실제로 어떻게 쓰는지(소스 디렉토리·파일명 메타 인코딩·명령 흐름)는 chezmoi 사용법 — 소스 표현과 apply 흐름에서 이어진다. 심링크 방식의 셋업은 dotfiles를 git 저장소 + 심볼릭 링크로 관리하기를 참고.