Clash 오픈소스 생태계 총정리: 코어·GUI 클라이언트·규칙 프로젝트의 관계

생태계 지도: 네 가지 프로젝트는 어떻게 계층화되어 있나

Clash 관련 자료를 검색하면 Clash, Clash Meta, mihomo, ClashX, Clash Verge, subconverter, geoip 같은 이름이 뒤섞여 등장하는 경우가 많아, 초보자는 이들을 서로 경쟁하는 소프트웨어로 오해하고 비교하기 쉽습니다. 사실 이 프로젝트들은 서로 다른 네 개 계층에 속해 있으며, 각자 다른 역할을 맡아 합쳐졌을 때 하나의 완전한 트래픽 분산 프록시 솔루션이 됩니다.

첫 번째 계층은 코어입니다. 실제로 네트워크 연결을 처리하고 프록시 규칙을 실행하며 연결 풀을 유지하는 백그라운드 프로세스로, 그래픽 인터페이스가 없이 설정 파일과 API 호출만 받습니다. 두 번째 계층은 GUI 클라이언트로, 코어를 사용자가 클릭으로 조작할 수 있는 앱으로 감싸며 구독 가져오기, 노드 전환, 시스템 프록시 설정, TUN 네트워크 어댑터 관리 같은 상호작용 작업을 처리합니다. 세 번째 계층은 규칙 세트와 지리 데이터베이스로, 도메인과 IP 대역을 분류한 목록을 제공해 코어가 트래픽을 분산할 때 매칭에 사용하도록 합니다. 네 번째 계층은 변환 및 패널 도구로, 서로 다른 형식의 구독을 코어가 읽을 수 있는 설정으로 통일해 변환하거나, 웹 기반 연결 모니터링 패널을 제공합니다.

이 네 계층의 의존 관계를 이해하면 왜 같은 컴퓨터에 클라이언트와 코어라는 두 프로세스가 동시에 설치될 수 있는지, 그리고 클라이언트를 교체해도 규칙 세트 파일을 다시 내려받을 필요가 없는 이유도 알 수 있습니다.

코어 발전 계보: 초기 Clash에서 mihomo까지

코어 계열은 생태계 전체에서 변화가 가장 큰 부분으로, 시간 순서를 파악해두면 지금 어떤 버전을 써야 할지 판단하기 쉬워집니다.

1. 초기 Clash

   Dreamacro가 시작한 최초 버전으로, Go 언어로 구현되어 설정 파일 형식, 프록시 그룹, 규칙 기반 트래픽 분산이라는 기본 모델을 정립했습니다. 이 저장소는 현재 보관(archived) 상태로 새 기능이 병합되지 않고 새로 발견되는 호환성 문제도 수정되지 않지만, 여기서 정의된 설정 문법은 이후 모든 파생 프로젝트에서 계속 쓰이고 있습니다.

2. Clash Premium

   초기 버전을 기반으로 일부 비공개 기능과 더 완전한 규칙 문법을 추가했으며, 한동안 가장 기능이 풍부한 브랜치였지만 업데이트 속도 역시 오래전부터 느려져 새로 등장한 전송 방식에 대한 프로토콜 지원이 뒤처져 있습니다.

3. Clash Meta

   초기 버전이 업데이트를 멈춘 뒤 커뮤니티가 유지보수를 이어받아 Vision, Hysteria, TUN 모드 등 새로운 프로토콜과 기능을 지원하도록 보완했으며, 한때 가장 활발히 업데이트되던 브랜치로 많은 GUI 클라이언트가 이 버전으로 코어를 전환했습니다.

4. mihomo

   Clash Meta가 이름을 바꿔 이어지는 프로젝트로, 저장소 이전과 명칭 변경 이후에도 기존 팀과 커뮤니티가 계속 코드를 커밋하고 있으며 신규 프로토콜 추가, 취약점 수정, 새 시스템 버전 대응 작업이 모두 여기서 진행됩니다. 현재 주요 GUI 클라이언트의 코어는 대부분 mihomo로 전환됐거나 전환 중입니다.

다시 말해, 어떤 클라이언트가 "어떤 코어를 쓰는지" 확인하는 일은 본질적으로 그것이 이미 업데이트가 멈춘 오래된 브랜치를 쓰는지, 아니면 여전히 지속적으로 유지보수되는 mihomo를 쓰는지 확인하는 작업입니다. 이는 새로 등장한 프록시 프로토콜을 쓸 수 있는지, 시스템 버전이 올라간 뒤에도 네트워크 확장 권한이 정상적으로 트리거되는지를 직접적으로 결정합니다.

GUI 클라이언트, 누가 유지보수 중이고 누가 멈췄나

GUI 클라이언트 계층의 업데이트 상태는 가장 놓치기 쉬운 부분입니다. 화면은 평소처럼 열리는 것처럼 보여도 내부 코어는 이미 오래전에 업데이트가 멈췄을 수 있기 때문입니다. 아래는 플랫폼별 대표적인 상황이며, 정확한 버전은 각 프로젝트의 릴리스 페이지를 기준으로 확인하세요.

iOS는 특수한 경우입니다. 시스템 정책상 서명되지 않은 실행형 코어를 배포할 수 없기 때문에, iOS 클라이언트는 대부분 비슷한 코어 로직을 독자적으로 구현한 앱으로 App Store에 올라갑니다. 설정 문법은 Clash 계열과 호환되지만 동일한 코어 코드를 그대로 재사용하는 것은 아닙니다. iOS 클라이언트를 고를 때는 "공식인지 아닌지"보다 표준 구독 링크 형식과 규칙 문법을 지원하는지를 중점적으로 확인해야 합니다.

실용적인 자가 점검 방법은 클라이언트의 정보 페이지나 설정 페이지를 열어 "코어 버전" 또는 "core version" 표기를 찾은 뒤, mihomo 릴리스 페이지의 최신 버전 번호와 비교해보는 것입니다. 차이가 너무 크다면 클라이언트 자체도 오랫동안 의존성을 업데이트하지 않았을 가능성이 큽니다.

규칙 세트와 변환 도구: 코어 외에 필요한 나머지 조각

코어는 "규칙대로 실행"만 담당하며, 규칙이 어디서 오는지는 별도의 프로젝트들이 해결합니다. 대표적인 규칙 세트 프로젝트는 전 세계에서 자주 쓰이는 도메인과 IP 대역을 지역별, 서비스 유형별로 분류해 geosite, geoip 형식의 데이터 파일로 묶어 제공합니다. 코어는 이를 불러온 뒤 설정 안에서 분류 이름만 직접 참조하면 되므로, 수천 수만 개의 도메인 항목을 직접 관리할 필요가 없습니다. 이런 프로젝트는 보통 일정한 주기로 데이터를 갱신하며, 업데이트 기록에서 어떤 분류가 추가되거나 조정됐는지 구체적으로 확인할 수 있습니다.

변환 도구는 또 다른 문제를 해결합니다. 서로 다른 프록시 서비스 제공자가 내주는 구독 링크 형식은 통일되어 있지 않으며, 어떤 것은 표준 프로토콜 링크 모음이고 어떤 것은 커스텀 JSON입니다. 변환 서비스는 중간에서 형식을 번역해 원본 구독을 Clash 계열 설정이 바로 읽을 수 있는 YAML 구조로 바꿔주며, 필요에 따라 그룹과 규칙 템플릿을 함께 삽입할 수도 있습니다. 변환 서비스를 사용할 때는 신뢰할 수 있는 출처가 제공하는 변환 인터페이스만 사용하고, 출처가 불분명한 제3자 사이트에 구독 링크를 제출하지 않는 것이 좋습니다.

패널 도구는 코어의 API 인터페이스 위에 웹 화면 한 겹을 씌운 것으로, 현재 연결 상태 확인, 지연 시간 측정, 노드 그룹 전환 등에 사용됩니다. 대부분의 GUI 클라이언트에 내장된 "패널" 화면은 사실상 이런 오픈소스 패널 프로젝트의 프런트엔드 코드를 그대로 삽입한 것입니다.

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies:
      - 노드A
      - 노드B
    url: http://www.gstatic.com/generate_204
    interval: 300

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "규칙 세트 다운로드 주소"
    path: ./rules/reject.yaml
    interval: 86400

위 설정 조각은 규칙 세트가 코어에 어떻게 참조되는지를 보여줍니다. 코어는 규칙 데이터가 구체적으로 어떻게 만들어졌는지에는 관심이 없고, rule-providers에 지정된 주소를 주기적으로 받아와 불러오기만 합니다. 이것이 바로 계층 구조 설계가 주는 이점으로, 규칙 세트 프로젝트는 코어의 새 버전 출시를 기다리지 않고 독립적으로 업데이트될 수 있습니다.

선택 가이드: 의존 관계를 거꾸로 따라가며 무엇을 설치할지 정하기

위의 계층 구조를 이해했다면, 선택 문제는 여러 프로젝트 이름 중에서 감으로 고르는 게 아니라 세 단계로 확인하는 절차로 바뀝니다.

• 먼저 플랫폼을 확인합니다. 운영체제마다 쓸 수 있는 클라이언트 범위가 다릅니다. iOS는 App Store라는 독립된 생태계를 거치고, 데스크톱과 안드로이드는 선택의 폭이 더 넓습니다.
• 그다음 코어를 확인합니다. 내부 코어가 꾸준히 업데이트되는 클라이언트를 우선 선택하고, 설정 페이지나 프로젝트 설명에서 코어 버전 번호와 업데이트 시점을 대조해봅니다.
• 마지막으로 규칙 출처를 확인합니다. 클라이언트에 기본 내장된 규칙 세트가 업데이트가 느리다면, 설정에서 아직 유지보수 중인 규칙 세트 주소로 수동 교체하면 됩니다. 이 단계는 클라이언트 자체를 바꿀 필요가 없습니다.

추가로 짚어둘 점은, 코어가 보관 처리됐다고 해서 소프트웨어를 즉시 쓸 수 없게 되는 것은 아니며 이미 배포된 버전은 여전히 작동합니다. 다만 새로운 프로토콜 지원과 보안 수정은 더 이상 받을 수 없습니다. 일상적인 사용을 기준으로는 내부 코어가 여전히 활발히 유지보수되는 클라이언트를 선택하는 편이 더 안전합니다. 새로운 전송 프로토콜이 등장하거나 시스템 업데이트로 인한 호환성 문제가 생겼을 때 수정 버전을 더 빨리 받을 수 있고, 직접 코어 수준의 문제를 파고들 필요가 없어집니다.