Clash 프로필 백업을 제대로: Git·암호화 패키징·다중 PC 동기화 실무 체크리스트 (2026)

① 이 글이 맞는 검색 의도: 설정 파일이 ‘자산’인 사람

검색어에 Clash 프로필 백업·구독 내보내기·Git·암호화·다중 PC 동기화를 같이 적는 경우는 대개 동일합니다. 단순히 앱을 켠다 끈다가 아니라, 프록시 그룹·분류 규칙·DNS·Mixin 덮어쓰기까지 포함한 ‘작동하는 상태’를 자산으로 보고, 롤백 가능한 변경 이력을 남기고 싶은 경우입니다.

반대로 한 대의 PC에서만 짧게 쓰고 매번 구독 링크만 다시 넣으면 된다면 이 글의 절반은 과합니다. 다만 업무용·개발자·멀티 OS 조합처럼 실패 비용이 큰 환경일수록, 여기서 말하는 백업 범위를 문서로 고정해 두는 편이 장기적으로 시간을 돌려줍니다. 전체 흐름은 Clash 입문 튜토리얼의 규칙·모드 설명과 같이 읽으면 맥락이 이어집니다.

② 백업 범위를 먼저 쪼갠다: 무엇을 유실하면 복구가 길어지나

Clash·Mihomo 계열에서 사실상 ‘깨지기 쉬운’ 것은 크게 네 덩어리입니다. 첫째, 활성 프로필 YAML과 그 안의 proxy-groups·rules 본문입니다. 둘째, 구독에서 내려받은 노드 정보가 합쳐진 결과물이지만, 여기에는 보통 구독 URL 자체가 들어 있으므로 외부 유출에 취약합니다. 셋째, rule-providers로 가져오는 원격 규칙 세트와 로컬 캐시 파일입니다. 넷째, GUI 클라이언트인 Clash Verge Rev 쪽의 Mixin·프로필 덮어쓰기·앱 설정 JSON 등 ‘앱이 얹는 레이어’입니다.

이 중에서 ‘동일한 파일을 여러 PC에 복제해야 하는 것’과 ‘장소마다 달라도 되는 것’을 나누지 않으면, 곧바로 동기화 충돌이 납니다. 예를 들어 한쪽 PC만 TUN 관련 옵션을 손댄 경우, 다른 쪽에서 가져온 YAML을 그대로 덮어쓰면 부팅 직후부터 네트워크가 꼬일 수 있습니다. Windows 11에서 Clash Verge Rev Mixin으로 프로필 덮어쓰기를 이미 쓰고 있다면, 무엇을 Mixin에 두었는지부터 표준 문서에 적어 두세요.

③ 구독 URL·토큰은 ‘버전 관리’와 별도 금고로 분리한다

구독 URL은 곧 계정과 과금 권한이 연결된 비밀입니다. 공개 GitHub에 실수로 올린 사례는 매년 반복되며, 검색 엔진과 미러링봇에 남은 뒤에는 즉시 폐기·재발급이 필요합니다. 안전한 패턴은 다음과 같습니다. (1) 저장소에는 subscription.example.txt처럼 빈 껍데기나 변수명만 둔다. (2) 실제 링크는 OS 자격 증명 저장소, 비공개 1password형 금고, 팀이면 최소 권한만 준 비공개 워크스페이스에 둔다. (3) 민감 파일 이름은 .gitignore에 넣고, 대신 ‘주입 방법’만 README에 쓴다.

구독이 여러 개라면 ‘이름–용도–갱신 주기’ 표를 만들어 두면 다중 PC에서도 동일한 의미로 대화할 수 있습니다. 클래식 클라이언트에서 새 그래픽 클라이언트로 옮기는 흐름은 Clash for Windows에서 Verge Rev로 이전 글과 접점이 있으니, 이전 직후에 백업 절차를 같이 정리해 두면 재이탈 비용이 줄어듭니다.

④ Git으로 프로필을 관리할 때의 현실적인 루틴

Git의 이점은 단순히 ‘백업’이 아니라 되돌리기와 비교에 있습니다. 의미 있는 시점마다 태그를 달아 두면, ‘지난달에 잘 되던 규칙’으로 빠르게 되돌릴 수 있습니다. 브랜치 전략까지 할 필요는 없고, 단일 main에 짧은 커밋 메시지를 붙이는 것만으로도 운영 기록이 남습니다. 예를 들어 rule: add stream domestic, dns: fallback order처럼 한 줄로 어디를 건드렸는지 적어 두면, 며칠 뒤 자신이나 동료가 원인을 찾기 쉽습니다.

사설 저장소를 쓸 수 없다면, 로컬 git만 초기화하고 원격은 비우는 방식도 있습니다. 이 경우에는 암호 ZIP이나 외장 디스크 복제가 반드시 따라와야 합니다. 원격이 없어도 ‘변경 이력’이라는 자산은 로컬에만 있어도 가치가 있습니다.

⑤ 암호화 아카이브: ‘한 통째’ 백업의 최소 조건

암호화 패키징은 휴먼 에러로 구독 링크가 섞였을 때 외부에 열리지 않게 막는 마지막 문지기 역할을 합니다. 운영에서는 보통 7-Zip의 AES, age, GPG 대칭 암호 중 하나를 고릅니다. 중요한 실무 팁은 ‘파일 이름에 서비스명을 직접 쓰지 않는다’는 것입니다. 대신 clash-profile-2026-05-13.bundle.crypt처럼 날짜와 무작위 접미사만 남기고, 내용 목록은 별도 메모에만 적습니다.

백업 파일을 메일로 보내거나 메신저로 전송해야 한다면, 평문 폴더 대신 항상 암호 컨테이너 하나만 던지세요. 팀 단위로 공유할 때는 키 회전 주기를 정하고, 퇴사·장비 반납 시 키 폐기도 함께 문서화합니다.

⑥ 다중 PC·노트북 동기화: 중앙 사본 하나를 믿을지, 양방향일지

여기서 흔한 실패는 ‘클라우드 동기화 폴더에 그대로 두었다가 두 PC가 동시에 써서 파일이 반쯤 섞인다’는 유형입니다. 안전한 패턴은 단일 소스 오브 트루스를 정하는 것입니다. 예를 들어 집 데스크톱에서만 규칙을 편집하고, 다른 PC는 pull만 한다거나, 반대로 노트북만 쓴다면 노트북을 기준으로 맞춥니다. 양방향으로 편집해야 한다면, ‘충돌 났을 때 어느 쪽이 이기나’를 README에 써 두고, 가능하면 텍스트 머지 도구를 쓰세요.

rule-providers의 interval·path·캐시 동작은 PC마다 디스크 경로가 달라질 수 있습니다. 주기와 경로를 맞추는 개념은 Windows 11 기준 rule-providers 간격·캐시 글과 같이 읽으면, ‘무엇을 Git에 넣고 무엇을 재생성에 맡길지’ 판단이 분명해집니다.

⑦ Clash Verge Rev·Mihomo 사용자가 빠지기 쉬운 구멍

Clash Verge Rev는 프로필 외에 앱 레벨 설정이 별도로 존재할 수 있어 ‘프로필만 복사했다고 전부 같은 환경’은 아닙니다. 시스템 프록시·자동 시작·TUN 권한·업데이트 채널 같은 값이 기기마다 다를 수 있습니다. 따라서 운영 문서에는 ‘프로필 Git 커밋 + 앱 설정 스크린샷 또는 내보내기 JSON’을 같이 적는 편이 안전합니다.

Mihomo 코어 자체는 파일 지향이라, 최종적으로는 ‘한 디렉터리에 모아 두고 커밋 후보를 고르는’ 방식이 디버깅에 유리합니다. 개발자가 터미널에서도 같은 프로필을 검증한다면 WSL2·Git·npm과 Clash 글의 프록시 정리와 충돌하지 않게 환경 변수 표를 맞춰 두세요.

⑧ 재해 복구 시나리오: 새 PC에 얼마나 걸리나 쟁여 본다

진짜 재해 복구 준비는 ‘백업 파일이 있다’가 아니라 ‘복원 절차를 한 번이라도 재현했다’로 완료됩니다. 시나리오 예시는 다음과 같습니다. 새 사용자 계정을 만들고 Clash 클라이언트를 깨끗이 설치한 뒤, 암호 아카이브를 풀고 프로필을 넣는다. 그다음 구독 URL 금고에서 링크를 채워 넣고 수동 갱신을 눌러 노드 목록을 재구성한다. 마지막으로 연결 로그에서 의도한 그룹으로 나가는지 확인합니다.

이 과정에서 시간이 걸리는 지점이 곧 문서에 적어 둘 체크리스트 항목입니다. 예를 들어 ‘구독 서버가 짧은 시간에 요청 제한을 건다’거나 ‘특정 DNS만 쓰면 갱신이 느리다’ 같은 발견은 다음 백업 정책을 바꿉니다.

⑨ 운영 체크리스트: 주간·월간에 넣으면 좋은 항목

1. 프로필 해시: 활성 YAML의 체크섬을 메모해 두었다가 의심될 때 비교합니다.
2. 구독 만료일: 과금·토큰 재발급 주기를 캘린더에 넣습니다.
3. rule-providers 태그: 원격 세트 버전이 바뀌었는지 릴리스 노트를 한 번 훑습니다.
4. Mixin 차이: OS별로 다른 덮어쓰기를 표로 남깁니다.
5. 동기화 방향: 어느 PC가 쓰기 권한을 갖나 팀에 공지합니다.
6. 암호 키 보관: 비상 연락망과 키 폐기 절차를 같이 둡니다.

이 리듬은 장비 대수가 늘수록 빛을 발합니다. 한 사람이 관리하는 세 대의 PC라도 표준이 없으면 결국 ‘어느 게 맞는 설정이지’라는 질문만 남습니다.

⑩ 자주 묻는 질문

구독 URL을 Git에 그대로 올려도 되나요?

공개 저장소에는 절대 넣지 마세요. 비공개 저장소라도 토큰이 유출되면 비용·노드가 타인에게 열립니다. 변수 치환이나 별도 시크릿 저장소를 권합니다.

클라우드 드라이브에 폴더만 두면 충분할까요?

편하지만 버전 기록이 약하고 실수로 덮어쓰기 쉽습니다. 최소한 날짜 접두가 붙은 ZIP 백업과 Git 태그 둘 중 하나는 병행하세요.

rule-providers 캐시까지 동기화해야 하나요?

보통은 정의 YAML과 interval만 맞으면 각 PC가 다시 받습니다. 대역을 아껴야 할 때만 선별적으로 캐시를 포함하세요.

⑪ 단순 백업 앱·일회성 내보내기와 비교했을 때 Clash·Mihomo 쪽이 주는 여지

일부 일회성 내보내기나 ‘한 방에 설정 복제’ 도구는 첫 경험은 간단해 보이지만, 규칙·DNS·프록시 그룹이 섞인 환경에서는 ‘어느 레이어가 바뀌어서 고장 났는지’를 나중에 잡기 어렵습니다. 특히 구독 스냅샷과 로컬 규칙이 한 파일에 섞이면 팀 상황에서 더 복잡해집니다.

Clash 생태계는 프로필을 파일과 GUI에서 동시에 다루는 흐름으로 바꾸고, Mihomo 코어는 rule-providers와 Mixin을 통해 변경을 단계적으로 나눌 수 있습니다. 그래서 백업 정책도 ‘무엇을 Git에 두고 무엇을 금고에 두는지’를 분명히 나눌 때 가장 안정적입니다. 지금 정리한 체크리스트를 기준으로 클라이언트를 고르고 싶다면, 배포 페이지에서 검증된 빌드를 고른 뒤 Clash 다운로드 안내에 따라 설치와 첫 프로필 불러오기까지 맞춰 보시길 권합니다.