chezmoi로 4대의 공통 설정만 관리하기

2026-10-13 · 인프라

컴퓨터 네 대에서 AI 도구를 운영하면 같은 훅을 여러 곳에 등록하게 된다. 훅은 특정 동작 앞뒤에 실행하는 작은 프로그램이다. 공통 훅은 같은 기준을 따라야 하지만, 각 컴퓨터의 모델 설정과 개인 설정까지 같을 필요는 없다.

2026년 10월 12일, chezmoi를 이용해 설정 파일 안의 승인된 훅 하나만 관리하는 방식을 도입했다. Mac 두 대와 Windows의 WSL 환경 두 곳에 적용했다. 복사본 시험부터 기존 관리 도구와의 공존, 주기 검사까지 확인했다.

이 글은 그날 확인한 도입 과정과 판단을 정리한 기록이다. 현재 네 대의 실시간 상태를 보여주는 문서는 아니다.

1. 관리할 범위를 먼저 정했다

설정 파일에는 공통 훅 외에도 기기별 경로, 모델 선택, 개인 설정, 비밀값이 들어갈 수 있다. 파일 전체를 한 벌로 배포하면 공통화할 필요가 없는 값까지 덮어쓸 수 있다.

그래서 기존 승인 목록에 있는 질문 도구용 훅 하나를 선택했다. 그 안에서도 프로그램 종류, 실행 명령, 제한 시간만 관리 대상으로 삼았다.

대상	이번에 정한 관리 방식
선택한 훅의 `type`, `command`, `timeout`	기존 승인 목록을 기준으로 관리
같은 훅에 사용자가 추가한 다른 필드	원래 값 보존
다른 훅, 모델 설정, 기기별 설정	기존 사용자와 관리 도구가 계속 관리
비밀값과 전체 설정 파일	Git에 저장하지 않음

chezmoi는 파일의 일부를 관리하는 modify_ 방식을 제공한다. 기존 내용을 표준 입력으로 받은 스크립트가 원하는 내용을 표준 출력으로 돌려주는 방식이다. 이번에는 JSON을 읽고 선택한 항목만 바꾸는 변환기를 만들었다. 공식 부분 관리 설명

2. 복사본에서 실패 조건부터 확인했다

첫 시험은 비밀값을 시험 문자열로 바꾼 복사본에서 진행했다. 실제 설정과 분리된 디렉터리에 chezmoi의 원본, 적용 대상, 캐시를 뒀다. 공식 릴리스 2.73.1의 체크섬을 확인한 뒤 사용했다.

정상 적용만 확인하면 보존해야 할 값이 사라지는 경우를 놓칠 수 있다. 그래서 일부러 다른 값을 넣거나 잘못된 입력을 줬다.

시험 조건	확인한 결과
대상 훅의 제한 시간을 다르게 설정	불일치를 감지하고 해당 값만 복원
다른 모델 값과 로컬 훅 추가	추가한 값 보존
같은 상태에 다시 적용	파일 내용과 수정 시각 유지
대상 훅 누락	선택한 훅만 추가
깨진 JSON, 중복 키, 중복 훅	쓰기 거부
적용 뒤 다른 편집 없이 원복	적용 전 바이트 복원
적용 뒤 별도 편집을 하고 원복	나중 편집을 덮지 않도록 원복 거부

복사본 시험 25개가 통과했다. 이 결과로 부분 관리 가능성을 확인했다. 다른 컴퓨터의 운영 설정이나 실제 사용자 질문 왕복까지 검증한 것은 아니었다.

3. 기존 등록기와 관리 주체를 나눴다

운영 도입에서 먼저 해결할 문제는 기존 훅 등록기였다. 새 도구와 기존 도구가 같은 훅을 계속 관리하면 한쪽 변경을 다른 쪽이 덮어쓸 수 있다.

선택한 훅의 관리 주체를 기록했다. 기존 등록기는 그 기록을 확인하면 해당 훅을 건너뛰도록 했다. 나머지 훅은 기존 등록기가 계속 맡는다.

설정 파일을 쓰는 도구들은 같은 잠금도 사용한다. 새 도구는 적용 직전에 파일 상태를 다시 비교한다. 그 사이에 편집이 있으면 쓰기를 거부한다. 원복도 적용 후 상태가 유지될 때만 허용한다.

잠금을 따르지 않는 외부 프로그램이 마지막 비교 직후 파일을 쓰는 경쟁까지 완전히 막지는 못한다. 따라서 실제 변경이 필요한 수동 적용은 다른 설정 편집이 없는 때 수행한다.

부분 관리 도구를 도입할 때는 관리 항목과 기존 작성자를 함께 확인해야 한다. 복사본에서 변환이 잘됐다는 사실만으로 운영 파일의 쓰기 충돌이 해결되지는 않는다.

4. 운영 적용에서 무변경도 확인했다

네 대에 설치한 뒤 검사, 적용, 재적용, 훅 실행 시험을 수행했다. 기존 등록기도 실제로 실행해서 선택한 훅을 건너뛰는지 확인했다.

운영 설정은 이미 승인 목록의 목표 상태와 일치했다. 적용 후에도 설정 파일의 내용, 권한, 수정 시각이 유지됐다. 이번 도입을 “네 대의 잘못된 설정을 고쳤다”고 기록하면 사실과 달라진다. 확인한 결과는 정상 설정을 보존하면서 관리 주체를 이전했다는 것이다.

관련 Mac 검사 37개와 Linux의 실제 chezmoi 검사 12개도 통과했다. 이 숫자는 각 검사의 범위별 결과다. 실제 사용자 질문이 전달되고 선택되는 전체 흐름의 성공 횟수는 아니다.

5. 불일치 검사와 수정을 분리했다

chezmoi의 verify는 실행 시점의 대상과 목표 상태를 비교한다. 계속 감시하려면 별도의 실행 주기가 필요하다. 공식 verify 설명

한 대의 Mac에서 60초마다 네 대를 읽기 검사하도록 구성했다. 설정 차이뿐 아니라 접속 실패와 검사 실패도 알림 대상으로 삼았다. 같은 문제의 반복 알림은 6시간 동안 억제한다.

검사기는 불일치를 발견해도 설정을 자동으로 고치지 않는다. 수정은 명시적인 수동 적용에서만 일어난다. 검사 중 사용자가 바꾼 값을 무조건 되돌리는 일을 피하기 위한 선택이다.

도입 때 자연 주기 실행 세 번을 관측했다. 기존 알림 경로로 시험 메시지를 한 번 보냈다. 발송 영수증은 확인했지만, 사용자가 텔레그램 화면에서 읽었다고 주장하지 않았다.

검사를 담당하는 Mac이 꺼져 있거나 잠들면 주기 검사도 중단된다. 이 구성은 상시 가동 서버를 둔 감시 체계와 가용성이 다르다.

6. 도입 과정에서 배운 구분

이번에는 설치 자체보다 완료 기준을 나누는 일이 중요했다.

복사본 시험과 운영 도입: 복사본 통과 뒤에도 기존 등록기와의 소유권 조정이 필요했다.
검사와 자동화: verify 실행 성공 뒤에도 주기 실행과 알림을 별도로 확인해야 했다.
설치와 실제 변경: 운영 설정은 처음부터 정상이었다. 파일을 바꾸지 않은 결과도 검증 대상이었다.
훅 시험과 사용자 왕복: 설치한 훅에 합성 입력을 주는 시험은 통과했다. 실행 중인 AI 세션에 실제 질문을 넣는 시험은 수행하지 않았다.
발송과 사용자 확인: 알림 발송 영수증과 사람이 화면에서 읽은 사실은 따로 기록했다.

기존 세션 시작 관리기의 노드 목록 검사에서는 도입 전후에 같은 실패가 남아 있었다. 그 오래된 배포기는 이번 설치에 사용하지 않았다. 이 실패를 새 도구의 성공 결과에 섞지 않았다.

다른 환경에서 같은 방식을 적용할 때도 먼저 관리할 최소 항목을 정하면 된다. 그 항목을 쓰는 기존 도구를 찾는다. 복사본에서 보존과 원복을 검증한다. 이후 실제 파일의 변경 여부와 감시 실행을 각각 확인한다.

참고 자료

검증 근거는 2026-10-12 복사본 시험과 운영 도입 기록을 기준으로 정리했다. 비밀값, 원본 설정 본문, 개인별 접속 정보는 공개 기록에서 제외했다.