Clash 오픈소스 생태계 정리: 오리지널 코어, mihomo와 각 GUI 클라이언트의 관계 및 선택

A-01계보의 출발점: 오리지널 Clash 코어

오늘날 시중에 나와 있는 다양한 Clash 계열 클라이언트를 제대로 이해하려면 먼저 계보의 출발점으로 돌아가야 합니다. 최초의 Clash는 Go 언어로 작성된 규칙 기반 프록시 코어로, 명령줄 프로그램과 YAML 설정 파일만 제공했으며 구독 파싱, 분기 규칙 매칭, 프록시 노드 관리를 담당하고 별도의 GUI는 없었습니다. 이 코어가 전체 생태계의 기본 문법을 확립했는데, proxies로 노드를 선언하고 proxy-groups로 정책 그룹을 구성하며 rules로 분기 순서를 정의하는 방식입니다. 이후 등장한 거의 모든 분기 프로젝트와 클라이언트가 이 설정 구조를 그대로 이어받았기 때문에, 서로 다른 출처의 구독 링크가 대부분 여러 클라이언트 간에 호환되는 것입니다.

오리지널 코어의 개발은 2023년 중반 이후 정체되었고, 저장소에는 오랫동안 새 버전이 나오지 않았으며 일부 최신 프로토콜 기능이나 규칙 문법도 반영되지 않았습니다. 이는 오리지널 코어를 "쓸 수 없다"는 뜻은 아니며, 기존 설정 파일 대부분은 여전히 정상 작동합니다. 다만 더 이상 커뮤니티가 주력으로 관리하는 버전이 아니라는 의미이며, 신규 기능이나 프로토콜 지원, 보안 패치도 더 이상 이 버전에 반영되지 않습니다.

A-02분기 발전: Clash Meta와 mihomo의 관계

오리지널 코어의 유지보수 속도가 느려진 뒤 커뮤니티에서 여러 분기 프로젝트가 등장했는데, 그중 영향력이 가장 큰 것이 Clash Meta입니다. 이 분기는 오리지널을 기반으로 TUN 모드의 안정적인 구현을 추가하고, 더 완전한 규칙 문법(예: RULE-SET, 프로세스 단위 규칙)을 지원하며, Hysteria, TUIC 등 신형 프로토콜 지원을 늘려 대다수 GUI 클라이언트가 내부적으로 기본 호출하는 코어로 빠르게 자리잡았습니다.

Clash Meta는 이후 정식으로 mihomo로 이름을 바꿨습니다. 이는 완전히 새로운 프로젝트를 처음부터 만든 것이 아니라, 같은 개발 계보가 이어지며 브랜드만 재정립된 것입니다. 현재 주류 GUI 클라이언트가 내부에 탑재하는 것은 대부분 mihomo 코어이며 오리지널 Clash 코어가 아닙니다. 그래서 많은 클라이언트의 설정 화면에서 "코어 버전" 항목에 표시되는 값이 실제로는 mihomo의 버전 번호이지 "Clash"라는 표기가 아닌 경우가 많습니다. 이 관계를 이해하면 클라이언트 업데이트 로그에 나오는 "코어를 mihomo x.x.x로 업그레이드" 같은 문구가 클라이언트 UI 자체의 변경이 아니라 내부 엔진의 버전업을 의미한다는 것을 알 수 있습니다.

다르게 표현하면 mihomo는 이 생태계에서 현재 실제로 뛰고 있는 "심장"에 해당하고, 각 GUI 클라이언트는 그 심장을 감싸는 "껍데기"로서 코어의 기능을 클릭하고 확인할 수 있는 화면으로 변환해주는 역할을 합니다. 이 구조를 먼저 이해하고 뒤에 나오는 클라이언트 비교를 보면 훨씬 쉽게 이해가 됩니다.

A-03GUI 클라이언트 정리: UI는 다르지만 코어는 같다

GUI 클라이언트는 설정 파일을 직접 편집해야 하는 진입 장벽을 낮춰주는 역할을 하며, 구독 가져오기, 노드 전환, 규칙 확인 같은 작업을 시각적인 화면으로 옮겨줍니다. 클라이언트마다 UI 프레임워크, 조작 방식, 부가 기능은 크게 다르지만 내부에서 호출하는 코어는 거의 모두 mihomo 또는 그 초기 형태를 가리킵니다. 아래에서 대표적인 클라이언트 유형별로 위치를 정리했습니다.

특히 주의할 것은 마지막 유형입니다. Clash for Windows는 오랜 기간 Windows 플랫폼을 대표하는 이름이었지만, 이 프로젝트는 유지보수가 중단되어 저장소에 새 커밋이 병합되지 않으며 내부 코어도 비교적 예전 버전에 머물러 있습니다. 계속 사용해도 당장 "멈추는" 것은 아니지만, 신규 프로토콜 노드를 인식하지 못하거나 일부 규칙 문법을 지원하지 않는 문제가 점점 나타나며, 보안 패치가 없다는 점도 장기적인 위험 요소입니다. 현재 Windows 플랫폼에서 활발히 관리되고 커뮤니티 반응이 좋은 대체 선택은 mihomo 코어 기반의 신세대 클라이언트에 집중되어 있습니다.

UI는 다른데 설정 파일이 서로 호환되는 이유

이는 앞서 설명한 계승 관계가 작용한 결과입니다. 대부분의 클라이언트가 동일한 mihomo 코어의 파싱 로직을 호출하며, 설정 파일도 동일한 YAML 문법 규칙을 따르기 때문입니다. 그래서 같은 구독 링크를 Clash Verge Rev, FlClash 등 다른 클라이언트에서도 이론적으로 그대로 사용할 수 있으며, 구독을 새로 생성할 필요 없이 UI 표현 방식과 조절 가능한 옵션 수에만 차이가 있습니다. 그래서 클라이언트를 고를 때는 "설정이 호환되는지"를 과도하게 걱정하기보다는 UI 스타일과 플랫폼 적합성을 중심으로 비교하면 됩니다.

A-04현재 추천 선택: 플랫폼과 필요에 따라 구분

앞서 정리한 계보를 바탕으로 실전에서 참고할 만한 선택 방향을 몇 가지 정리했습니다.

1. Windows와 macOS 데스크톱에서는 mihomo 코어 기반이면서 여전히 활발히 업데이트되는 클라이언트를 우선 고려하세요. UI가 가볍고 설정 항목 노출이 충실한 쪽이 규칙을 수동으로 조정해야 하는 사용자에게 더 적합합니다.
2. 안드로이드 플랫폼에서는 VpnService 지원을 명확히 표기하고 지속적으로 관리되는 클라이언트를 우선 선택하세요. 설치 후에는 시스템 절전 정책이 백그라운드 연결 안정성에 영향을 주는지 확인하는 것이 좋습니다.
3. iOS 플랫폼은 시스템 제약으로 클라이언트 형태가 데스크톱/안드로이드와 다르므로, 공식 채널로 배포되고 업데이트 기록이 명확한 버전을 기준으로 선택하세요.
4. 지금 쓰는 클라이언트 소개 페이지에 여전히 "오리지널 Clash 코어 기반"이라고 표기되어 있고 오랫동안 업데이트가 없었다면, mihomo 기반의 대체 클라이언트로 이전을 검토하는 것이 좋습니다. 이전 과정은 대부분 기존 구독 링크를 다시 등록하는 것만으로 끝납니다.
5. "최신 클라이언트일수록 좋다"는 생각에 집착할 필요는 없습니다. 안정성, 커뮤니티 반응, 업데이트 빈도를 종합적으로 판단하는 쪽이 단순히 버전 번호만 보는 것보다 훨씬 신뢰할 만합니다.

이전 시 주의할 점

한 클라이언트에서 다른 클라이언트로 전환할 때는 대부분 구독 링크를 다시 추가하는 것만으로 이전이 끝나며, 규칙을 수동으로 다시 작성할 필요는 없습니다. 다만 기존 설정에 사용자 정의 정책 그룹, 스크립트 규칙, 특수 파라미터가 포함되어 있다면 이전 후 클라이언트의 설정 확인 화면을 먼저 열어 규칙 수와 정책 그룹 수가 이전 전과 일치하는지 대조해 보세요. 문법 해석 차이로 일부 규칙이 조용히 무시되는 상황을 피할 수 있습니다.

curl -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204 -I

이전이 끝난 뒤에는 위 명령으로 로컬 프록시 포트가 정상적으로 응답하는지 확인할 수 있습니다. HTTP/1.1 204 No Content가 반환되면 새 클라이언트의 프록시 서비스가 정상적으로 트래픽을 넘겨받았다는 뜻이며, 이후 정책 그룹 전환과 규칙 매칭이 예상대로 동작하는지 하나씩 확인하면 됩니다.

A-05자주 나오는 질문