Clash 생태계를 처음 접하는 사람들은 "도대체 뭘 설치해야 하나"라는 질문에 부딕히곤 합니다. Clash, Clash Meta, mihomo, Clash Verge Rev, FlClash 등 이름은 비슷하지만 실제로는 서로 다른 프로젝트를 가리킵니다. 이 글은 커널과 클라이언트의 계승 관계를 시간순으로 정리하고, 누가 누구의 연장선인지, 그리고 한 프로젝트가 여전히 유지보수되고 있는지 판단하는 방법을 설명합니다.
최초의 Clash는 Go 언어로 작성된 규칙 기반 프록시 도구였습니다. 도메인, IP 대역, GeoIP 등의 조건에 따라 트래픽을 서로 다른 출구로 분산시키고, Shadowsocks, VMess, Trojan 등 다양한 프로토콜을 통합 관리할 수 있는 것이 핵심 기능이었습니다. 이 프로젝트의 설계 철학은 "규칙 엔진"과 "프로토콜 구현"을 분리하는 것이었습니다. 설정 파일에 규칙을 작성하면 커널이 매칭과 전달을 처리하며, 사용자는 하단의 핸드셰이크 세부사항을 신경 쓸 필요가 없습니다. 이 구조는 이후 거의 모든 Clash 계열 클라이언트에서 그대로 이어져, 전체 생태계를 이해하는 출발점이 됩니다.
원조 저장소는 수년간 유지보수된 후 개발자에 의해 아카이브되어, 더 이상 새로운 기능 제출을 받지 않고 새로 발생하는 호환성 문제도 수정되지 않습니다. 일반 사용자에게 직접적인 영향은, 이 커널을 기반으로 한 오래된 클라이언트를 계속 사용할 경우 새로운 프로토콜을 지원하지 않거나 새 시스템 버전에 대한 적응 문제가 생겨도 더 이상 공식 업데이트로 해결되지 않는다는 점입니다. 이것이 커뮤니티 포크가 대량으로 등장한 직접적인 원인입니다. 핵심 기능이 사라진 것이 아니라, 새로운 관리자가 이어받아야 하는 상황이 된 것뿐입니다.
원조 프로젝트 발전 중반기에, 개발자는 한때 클로즈드소스 Premium 커널을 출시했습니다. TUN 모드, 더 완전한 규칙 구독, 스크립트 확장 등 고급 기능이 추가되어, 완전히 오픈소스인 기본 버전과 병행 존재했습니다. 이 역사는 이후 커뮤니티 포크의 두 방향을 만들어냈습니다. 일부 프로젝트는 오픈소스 기반 위에 Premium 시대의 기능을 보완하는 데 집중했고(예: 자체적으로 TUN 지원 구현), 다른 일부는 이러한 고급 기능을 통합하거나 재현하는 방향으로 전개되었습니다.
이것이 바로 현재 시장에서 "기능은 거의 같지만 코드 출처가 다른" 여러 클라이언트를 볼 수 있는 이유입니다. 각각 오픈소스 생태계의 서로 다른 분기에서 Premium 시대에 남겨진 기능 요구사항을 다시 구현한 것입니다. 사용자 입장에서는 역사적 세부사항을 파고들 필요 없이, 현재 사용 중인 버전이 TUN 모드, 규칙 구독, 스크립트 정책 등 핵심 기능을 지원하는지만 확인하면 됩니다.
원조 커널이 아카이브된 후, 커뮤니티에서 가장 활발하고 업데이트가 빈번했던 연속 프로젝트가 최종적으로 발전하며 mihomo로 이름을 바꾸었습니다. 기능적으로 기존의 규칙 매칭, 프로토콜 지원을 완전히 커버하며, 새로운 프로토콜(Hysteria2, TUIC 등)과 시스템 레벨 적응(macOS/Windows의 TUN 권한 모델 변화 등)을 계속 따라잡고 있습니다. 현재 여전히 활발히 업데이트되는 대부분의 Clash 계열 GUI 클라이언트는 하단에서 mihomo 커널을 호출하며, 최초의 아카이브된 버전을 사용하지 않습니다.
이 점을 이해하는 것이 중요합니다. 많은 클라이언트가 화면상으로는 여전히 "Clash"라는 이름을 제품 식별자로 사용하지만, 실제로 구동되는 커널은 이미 mihomo로 전환된 지 오래입니다. 클라이언트가 프로토콜 업데이트를 잘 따라가는지 판단하는 본질은, 화면에 표시된 브랜드명이 아니라 해당 클라이언트가 바인딩한 커널 버전의 업데이트 빈도를 확인하는 것입니다.
| 단계 | 주요 프로젝트 | 상태 |
|---|---|---|
| 초기 | 원조 Clash 커널 | 아카이브됨, 더 이상 업데이트 없음 |
| 과도기 | Clash Premium(클로즈드소스) | 과거 버전, 더 이상 이터레이션 없음 |
| 현재 본류 | mihomo 커널 | 활발히 유지보수, 주요 클라이언트의 근간 |
커널 위에는 각종 GUI 클라이언트가 있으며, 이들은 인터페이스, 구독 관리, 시스템 프록시 설정 등 사용자가 직접 접하는 부분을 담당하고, 하단에서는 특정 버전의 커널을 패키징해 호출합니다. 이 관계를 명확히 정리해야 클라이언트가 "최신인지"를 판단할 수 있습니다.
보다시피 이 클라이언트들의 관계는 "누가 누구를 베꼈다"가 아니라, 동일한 커널 기능을 서로 다른 플랫폼과 기술 스택에서 인터페이스로 구현한 것입니다. 어떤 것을 선택할지는 운영체제, 인터페이스 선호도, 업데이트 빈도에 따라 결정되며, "정통성"을 따질 필요는 없습니다.
비슷비슷한 프로젝트 이름들 앞에서, 전체 역사를 추적하기보다는 몇 가지 실용적인 판단법을 익히는 것이 낫습니다.
최근 몇 달 안에 새 버전이 출시되었는지가 가장 직접적인 신호입니다. 오랫동안 업데이트가 없지만 여전히 다운로드 가능한 버전은 대부분 임시로 급한 상황에만 쓰기에 적합합니다.
클라이언트 설정이나 정보 페이지에는 보통 바인딩된 커널 버전 번호가 표시되어 있어, 최신 mihomo 버전인지 대조할 수 있습니다.
새로 등장한 프록시 프로토콜이 클라이언트에서 해당 옵션을 전혀 찾을 수 없다면, 대체로 커널 버전이 오래된 것일 가능성이 큽니다.
운영체제 업그레이드 후(특히 macOS의 네트워크 확장 권한, Windows의 TUN 드라이버 서명 요구사항 등) 클라이언트가 함께 적응했는지도 유지보수 활발도를 나타내는 지표입니다.
일상적인 사용에서는 오픈소스 역사 전문가가 될 필요 없이, 다운로드 페이지에서 현재 활발히 업데이트되는 클라이언트 버전을 선택하고 유효한 구독 링크를 함께 사용하면 규칙 분산, TUN 모드 등 완전한 기능을 얻을 수 있습니다. 기술 선택의 세부사항은 프로젝트 관리자에게 맡기고, 일반 사용자가 실제로 신경 써야 할 것은 "안정적이고 사용하기 편하며 시스템 업데이트를 잘 따라가는가" 이 두 가지뿐입니다.
커널 계보를 이해했다면 다운로드 페이지로 이동해 현재 활발히 유지보수되는 클라이언트 버전을 선택하고 플랫폼에 맞는 설치 파일을 받으시면 됩니다.