Clash, mihomo, Verge Rev의 관계: 오픈소스 프로젝트 계보 총정리

Clash 생태계를 처음 접하면 혼란스러울 수 있습니다. "Clash 다운로드"를 검색하면 서로 다른 이름을 가진 소프트웨어가 십여 개 나오고, 인터페이스도 제각각이며 GitHub 저장소도 여러 계정에 흩어져 있습니다. 이런 혼란은 우연이 아니라 명확한 역사적 맥락이 있습니다. 원작자가 저장소를 아카이브한 후 커뮤니티가 이어받아 유지보수하면서 지금의 구도가 형성됐습니다. 이 흐름을 이해하면 왜 어떤 클라이언트는 자주 업데이트되고 어떤 클라이언트는 이미 중단됐는지, 그리고 플랫폼별로 어떤 것을 우선 선택해야 하는지 알 수 있습니다.

최초의 Clash 프로젝트는 Dreamacro가 개발했으며 Go 언어로 작성됐습니다. 핵심 아이디어는 "규칙 기반 트래픽 분기"로, 설정 파일에 도메인이나 IP 대역이 어떤 프록시 노드를 거쳐야 하는지 지정하면 커널이 규칙을 순서대로 매칭해 트래픽을 전달합니다. 이 설계는 이후 모든 분기 프로젝트가 완전히 계승했으며, 전체 생태계를 이해하는 기본 토대입니다.

2023년을 전후로 원본 저장소가 여러 외부 요인으로 아카이브되면서 읽기 전용 상태가 됐고 더 이상 새 커밋을 받지 않게 됐습니다. 이는 당시 Clash 커널에 의존하던 모든 GUI 클라이언트에 큰 충격이었습니다. 커널이 더 이상 업데이트되지 않으면 새로운 프로토콜 지원, 새로운 규칙 문법, 보안 수정이 공식 버전에 반영될 수 없다는 뜻이기 때문입니다. 이에 따라 커뮤니티는 두 가지 대응 경로를 취했습니다.

• 기존 커널 유지: 일부 클라이언트는 아카이브 직전 마지막 버전을 그대로 고정해 새 기능을 따라가지 않으며, 장기적으로 사용하면 프로토콜 호환성 문제를 점차 겪게 됩니다.
• 커뮤니티 유지보수 분기 커널로 전환: 현재 활발한 프로젝트들이 대부분 채택한 경로로, 본문에서 중점적으로 다룰 mihomo가 이에 해당합니다.

mihomo는 원래 Clash Meta 프로젝트가 이름을 바꾼 후속 프로젝트로, 커뮤니티 팀이 유지보수하며 현재 가장 활발하고 업데이트가 가장 빈번한 오픈소스 커널입니다. 원조 Clash의 규칙 기반 분기 구조를 기반으로 다음 기능들을 보완하고 강화했습니다.

• TUN 모드: 시스템 네트워크 계층에 가상 네트워크 카드를 만들어 전체 트래픽을 인수합니다. 개별 앱마다 프록시를 수동 설정할 필요가 없고, 시스템 프록시 설정을 지원하지 않는 프로그램에도 동일하게 적용됩니다.
• 더 완전한 프로토콜 지원: VMess, VLESS, Trojan, Hysteria, Hysteria2, TUIC 등 프로토콜이 순차적으로 보완됐으며, 업데이트 속도가 중단 전 원본 커널보다 명확히 빠릅니다.
• 규칙 세트 확장: GEOSITE, GEOIP 등 원격 규칙 세트 형식을 지원해 구독 제공자가 지역과 서비스별로 규칙을 분류 관리하기 쉬우며, 클라이언트가 도메인을 일일이 나열할 필요가 없습니다.
• 스크립트 및 고급 전략: Script 유형 규칙과 더 유연한 정책 그룹 중첩 기능을 제공해 복잡한 분기 시나리오에 대응합니다.

강조할 점은 mihomo 자체는 GUI가 없는 커널 프로그램이라는 것입니다. 일상적으로 사용하는 여러 클라이언트(Verge Rev, FlClash, Nyanpasu 등)는 모두 mihomo 위에 만들어진 GUI 껍데기로, 설정 관리, 노드 표시, 구독 가져오기, 트래픽 통계 등 상호작용 계층 기능을 담당하며, 실제 프록시 및 분기 로직을 실행하는 것은 여전히 커널 자체입니다.

커널이 통일된 이후 GUI 클라이언트들의 차이는 주로 개발 언어, 인터페이스 프레임워크, 대상 플랫폼에서 나타납니다. 아래에서 프로젝트별 특징을 정리해 사용 시나리오에 맞는 선택을 돕습니다.

Verge Rev(clash-verge-rev)

Tauri 프레임워크로 개발됐으며 프런트엔드는 웹 기술 스택 기반, 백엔드는 Rust로 작성돼 기존 Electron 클라이언트보다 용량이 가볍습니다. 현재 Windows, macOS, Linux 세 플랫폼에서 가장 꾸준히 업데이트되는 데스크톱 클라이언트 중 하나이며, 설정 파일은 시각적 편집과 YAML 소스 편집 두 모드를 전환할 수 있어 초보자와 직접 설정 파일을 작성하는 사용자 모두를 만족시킵니다. 정책 그룹, 연결 상세 정보, 로그 패널 등의 정보 표시도 비교적 충실합니다.

FlClash

Flutter 프레임워크 기반으로 개발됐으며 가장 큰 특징은 플랫폼 간 코드 재사용률이 매우 높다는 점입니다. 동일한 인터페이스 코드로 Windows, macOS, Linux, Android 여러 플랫폼용 클라이언트를 빌드할 수 있어 각 플랫폼에서 시각적 스타일이 일관되게 유지됩니다. 여러 다른 시스템의 기기를 오가며 사용하면서도 조작 습관을 통일하고 싶은 사용자라면 이런 클라이언트가 인터페이스 재적응 비용을 줄여줍니다.

Nyanpasu(clash-nyanpasu)

마찬가지로 Tauri 프레임워크 기반이며 인터페이스 디자인에서 애니메이션 효과와 테마 커스터마이징을 더 강조하고, 설정 파일의 시각적 관리와 구독 자동 업데이트를 지원합니다. Verge Rev와 기술 선택은 비슷하지만 인터페이스 스타일과 일부 상호작용 디테일에서 다른 방향을 택해 개성 있는 외관을 선호하는 사용자에게 적합합니다.

모바일 및 기타 플랫폼

Android 플랫폼에서는 FlClash 외에도 mihomo 커널 기반의 독립 클라이언트가 여럿 있으며, 대부분 TUN 모드 하의 전역 프록시와 앱별 분기를 지원합니다. iOS 플랫폼은 선택지가 상대적으로 제한적이며, 대다수 클라이언트가 App Store를 통해 배포되고 인터페이스 스타일이 시스템 네이티브 디자인 규범에 더 가깝고, 설정 관리 방식도 구독 링크의 원클릭 가져오기를 더 강조합니다.

모든 주류 클라이언트가 최종적으로 mihomo 또는 호환 커널을 호출해 설정을 해석하기 때문에, YAML 형식의 설정 파일과 구독 링크는 이들 클라이언트 사이에서 기본적으로 직접 호환됩니다. 표준 설정 파일에는 보통 다음과 같은 핵심 필드가 포함됩니다.

port: 7890
socks-port: 7891
mode: rule
log-level: info
proxies:
  - name: "노드 예시"
    type: vmess
    server: example.com
    port: 443
proxy-groups:
  - name: "자동 선택"
    type: url-test
    proxies: ["노드 예시"]
rules:
  - DOMAIN-SUFFIX,example.com,자동 선택
  - MATCH,DIRECT

즉 한 클라이언트에서 다른 클라이언트로 옮길 때 보통 프록시 노드를 다시 설정할 필요 없이 기존 구독 링크나 로컬 설정 파일을 그대로 가져오면 계속 사용할 수 있습니다. 실제로 주의해야 할 차이는 클라이언트 고유의 인터페이스 설정 항목에 집중돼 있습니다. 예를 들어 시스템 프록시 켜는 방식, TUN 모드 활성화 진입점, 로그 보관 정책 등은 껍데기 계층 기능이라 커널 전환 시 자동으로 이전되지 않습니다.

1. 커버해야 할 플랫폼 확인

   먼저 자신이 사용해야 할 시스템을 명확히 합니다. Windows 단일 플랫폼만인지, 아니면 Windows, macOS, Android를 동시에 사용하는지에 따라 다릅니다. 다중 플랫폼 시나리오라면 같은 프로젝트의 크로스 플랫폼 버전을 우선 고려해 설정 파일을 여러 클라이언트 간 변환하는 수고를 줄일 수 있습니다.

2. 프로젝트 업데이트 빈도 확인

   GitHub 저장소 페이지에서 최근 릴리스(Release) 시점을 확인하세요. 오랫동안 업데이트가 없는 클라이언트는 인터페이스가 정상적으로 열리더라도 커널이 오래돼 새로운 프로토콜이나 규칙 문법을 해석하지 못할 수 있습니다.

3. TUN 모드 지원 확인

   개별 앱 프록시가 아니라 전역 트래픽 인수가 필요하다면 대상 클라이언트가 TUN 모드를 명확히 지원하는지 확인하고, 시스템 차원에서 해당 권한을 부여합니다(Windows의 관리자 권한, macOS의 네트워크 확장 권한 등).

4. 기존 설정 파일 보관

   클라이언트를 바꾸기 전에 기존 구독 링크와 로컬 규칙을 내보내거나 백업해두면 새 클라이언트 설치 후 바로 가져와 노드 정보를 다시 정리하지 않아도 됩니다.

정리하면 명확한 판단 경로가 나옵니다. Clash가 규칙 기반 분기 아키텍처를 확립 → mihomo가 커뮤니티 계승 커널로서 프로토콜과 기능 업데이트를 지속 → Verge Rev, FlClash, Nyanpasu 등 GUI 클라이언트가 mihomo 위에 각자의 인터페이스와 상호작용 경험을 구축. 클라이언트를 선택한다는 것은 본질적으로 하나의 인터페이스 껍데기를 고르는 일이며, 커널이 같고 설정 파일이 호환되는 한 클라이언트 간 이전 비용은 매우 낮습니다. 정말 시간을 들여 비교할 가치가 있는 것은 인터페이스가 자신의 조작 습관에 맞는지, 목표 플랫폼이 안정적으로 지원되는지, 그리고 프로젝트가 여전히 활발히 유지보수되고 있는지입니다.