Clash YAML 설정 백업과 멀티 기기 동기화: mixin·워크스페이스·비밀 관리 보안 습관 (2026)

왜 “파일 한 통째” 백업이 위험한가

많은 사용자가 프로필 디렉터리를 통째로 복사해 두거나, 메신저로 config.yaml을 주고받습니다. 짧게는 통하지만, 중장기적으로는 세 가지가 겹칩니다. 첫째, 원격 구독이 주기적으로 덮어쓰는 베이스 YAML 안에 손댄 내용은 다음 갱신에서 사라지거나 머지 지옥이 됩니다. 둘째, 한 번이라도 공유 링크·토큰이 들어간 파일을 공개 채널에 올리면, 회수가 어렵습니다. 셋째, 기기마다 DNS·TUN·포트 요구가 다른데 동일 파일을 강제로 맞추면 한쪽만 되고 다른 쪽은 조용히 깨집니다. 그래서 백업 단위를 “한 장의 최종본”이 아니라 레이어와 비밀 주머니로 쪼개는 편이 안전합니다.

이 관점은 규칙 우선순위나 DNS 누설 방지 같은 튜토리얼과도 연결됩니다. 규칙과 DNS가 어디 파일에서 최종 합쳐졌는지 알아야, 문제가 났을 때 어느 레이어만 되돌릴지 빠르게 고를 수 있습니다.

백업 단위: 베이스·mixin·클라이언트 프로필

실무에서 권장하는 최소 분리는 다음과 같습니다. (A) 구독에서 내려받는 베이스는 읽기 위주로 두고, (B) 내가 유지하고 싶은 rules·rule-providers·추가 proxy-providers·dns 조각은 mixin 파일이나 Merge 스니펫에만 둡니다. (C) profile에 해당하는 선택 상태(마지막으로 고른 노드 등)은 기기별로 달라도 되므로, 동기화 대상에서 빼거나 별도 브랜치로 두는 편이 충돌이 적습니다. mixin 병합 글에서 설명한 것처럼, 베이스를 직접 고치지 않는 습관이 백업 전략의 전제입니다.

구독 URL·토큰은 저장소에서 분리하기

설정 백업을 Git으로 한다면, 가장 흔한 사고는 proxies 목록에 긴 구독 URL을 그대로 커밋하거나, 서비스 제공자가 발급한 개인 경로가 들어 있는 파일을 공개 저장소에 푸시하는 경우입니다. 비공개 저장소라도 협업 초대 범위·토큰 유출을 가정하고, 저장소에는 ${SUB_URL} 같은 플레이스홀더만 두고 실제 값은 OS 환경 변수·비밀 저장소·로컬만 존재하는 secrets.local.yaml(.gitignore)로 두는 패턴이 안전합니다. 팀에서는 템플릿 저장소와 개인 오버레이 저장소를 나누는 방식도 잘 맞습니다.

# Example .gitignore — tune to your repo layout
secrets.local.yaml
*.token
providers/cache/
.verge/
*.dmg
*.exe

클라우드 동기화 도구는 편하지만, 공유 링크나 휴지통 복구 정책까지 고려하면 “실수로 외부에 열린 폴더”가 생기기 쉽습니다. 특히 회사 PC와 개인 NAS를 섞을 때는 동기화 제외 규칙을 명시적으로 두세요.

Clash Verge Rev·Mihomo Party 관점에서의 경로 감각

데스크톱에서는 Clash Verge Rev가 프로필·Merge 스니펫을 GUI에서 다루기 쉽고, Mihomo Party 계열은 플랫폼별 패키징에 따라 데이터 디렉터리가 조금씩 다릅니다. 공통적으로 중요한 것은 “어느 폴더가 사용자 편집본이고, 어느 폴더가 캐시·런타임인지”를 메모해 두는 일입니다. 재설치 후에도 살아야 하는 것은 Merge 스니펫·rule-provider 원본·자작 스크립트이고, 재생성 가능한 캐시는 백업 우선순위에서 내려도 됩니다. 게임·VPN 병행 같은 폭넓은 클라이언트 비교는 Windows 게임 환경 글과 함께 보면 제품별 강점을 빠르게 짚을 수 있습니다.

macOS·Linux 헤드리스에서는 systemd·단일 config 패턴이 많습니다. 이때도 원칙은 같습니다. 서비스 유닛과 엔트리 YAML 경로를 문서화해 두면, 서버 이전 시 한 번에 따라가기 좋습니다.

동기화 방식 선택: Git·드라이브·수동 복사

멀티 기기 동기화에는 각각 장단이 있습니다. Git은 변경 이력·코드 리뷰·태그 릴리스에 강하지만, 바이너리 캐시를 함께 올리면 저장소가 불어납니다. 실시간 클라우드 드라이브는 편하지만 파일 잠금·충돌 복사본이 생기면 YAML이 반쯤 깨진 채로 저장될 수 있어, 민감 파일 제외와 주기적 검증이 필요합니다. 수동 USB 복사는 단순하지만 버전이 안 맞을 때가 많으니, 폴더 이름에 날짜를 붙이는 정도만으로도 사고가 줄어듭니다. 어떤 방식이든 “한 기기에서 검증된 스냅샷”을 기준으로 다른 기기를 맞추는 습관을 추천합니다.

워크스페이스 아카이브와 롤백 습관

대규모로 규칙이나 DNS를 바꿀 때는, 변경 전 폴더를 workspace-20260511-before-dns처럼 아카이브해 두면 멘탈이 편합니다. 문제가 생겼을 때 diff가 아니라 “통째 교체”로 즉시 복구할 수 있습니다. 운영 문서에 “이번에 건드린 레이어가 mixin인지 베이스인지 클라이언트 프로필인지” 한 줄만 적어도, 며칠 뒤의 나 자신에게 큰 도움이 됩니다. 로그 기반 진단은 연결 리셋·로그 글과 연결해 읽으면 좋습니다.

운영 체크리스트

1. 베이스 구독 파일과 mixin·Merge 스니펫의 역할을 문서로 고정했는가.
2. .gitignore 또는 동기화 제외 목록에 토큰·캐시가 들어가 있는가.
3. 각 기기에서 최종 규칙 순서와 DNS가 의도대로인지 샘플 도메인으로 확인했는가.
4. 재설치 시 복사할 최소 파일 목록(스니펫·프로바이더·환경 변수 표)을 만들었는가.
5. 분실 대비로 구독 발급 페이지·고객 지원 경로를 비밀번호 관리자에 따로 적었는가.

자주 묻는 질문

공개 저장소에 구독 YAML을 올려도 될까요?

가능한 한 피하는 것이 좋습니다. URL 자체가 자격 증명 역할을 하는 경우가 많아, 크롤러·스크린샷·실수적인 포크 한 번으로 장기간 노출됩니다. 교육용 예시는 토큰을 가진 채가 아니라 더미 호스트로 바꾼 버전을 사용하세요.

mixin과 Merge 중 무엇을 Git에 넣나요?

둘 다 “내가 책임지는 편집본”에 해당하면 버전 관리 대상입니다. 반대로 클라이언트가 자동 생성하는 캐시·런타임 DB는 제외합니다. 팀 규칙으로 “스니펫만 승인된 경로에 두기”를 정하면 코드 리뷰도 쉬워집니다.

가족·팀과 설정을 공유할 때 주의할 점은?

같은 규칙을 쓰더라도 노드 선택 상태나 TUN 권한은 사람마다 다를 수 있습니다. 공통 레이어와 개인 레이어를 나누고, 구독 계정 약관상 공유 가능 여부도 확인하세요.

정리

Clash 설정 백업은 파일 복사 한 번이 아니라, 갱신되는 베이스와 내 mixin·Merge, 기기별 상태를 나누는 설계입니다. YAML을 여러 대에서 맞추려면 동기화 도구보다 먼저 비밀 경계와 검증 습관을 세우는 편이 오래 갑니다. Clash Verge Rev와 Mihomo Party 사용자는 각각 데이터 디렉터리를 한 번씩 스케치해 두면 재설치 공포가 크게 줄어듭니다. 설정 허브는 문서 페이지에서 이어서 확인할 수 있습니다.

여러 클라이언트를 번갈아 쓰면 프로필 형식과 동기화 방식이 제각각이라, 한번 잘못 맞추면 규칙이 조용히 빗나가기 쉽습니다. 같은 목표를 하나의 앱 안에서 단순하게 묶어 두면 백업 단위도 줄고 실수 여지도 줄어듭니다. 아직 통합 클라이언트를 쓰지 않았다면 Clash를 무료로 내려받아, 본문에서 정리한 레이어 습관대로 프로필을 나눠 두면 멀티 기기 운영이 한결 편해집니다.