mihomo 코어와 오리지널 Clash의 차이점은? Meta 브랜치 기능 총정리

Clash에서 Clash Meta, 그리고 mihomo로: 코어 발전사

오리지널 Clash 코어는 Dreamacro가 시작하여 Go 언어로 구현했으며, config.yaml의 기본 구조, 프록시 그룹 개념, 규칙 매칭 엔진을 확립해 이후 모든 브랜치의 출발점이 되었습니다. Hysteria2, TUIC, WireGuard 같은 프로토콜이 잇따라 등장하고 사용자들이 더 세밀한 제어를 요구하게 되면서, 커뮤니티는 오리지널을 바탕으로 Clash Meta 브랜치를 만들어 새 프로토콜, 새 규칙 타입, 성능 개선을 지속적으로 병합했습니다. 오리지널 저장소는 2022년 이후 업데이트가 둔화된 반면, Clash Meta는 활발한 유지보수 속에서 오리지널의 기능 범위를 점차 앞서갔고, 결국 mihomo로 이름을 바꿔 독립 프로젝트로 계속 발전하고 있습니다.

지금 쓰이는 "mihomo 코어"라는 표현은 사실상 초기의 "Clash Meta 코어"와 거의 같은 의미입니다. 둘은 동일한 개발 흐름의 다른 시점 명칭일 뿐이며, 프로토콜 프리픽스와 설정 필드는 대체로 호환되지만, 패키지 구성·버전 번호·일부 기본 동작은 반복 개발을 거치며 변화했습니다. 이런 흐름을 알아두면 특정 클라이언트가 표시하는 "코어 버전"이 실제로 어떤 기능 집합에 해당하는지 판단하는 데 도움이 됩니다.

출력 프로토콜 지원: mihomo가 추가한 프로토콜

프로토콜 지원은 두 코어의 가장 직관적인 차이입니다. 오리지널 Clash 코어는 Shadowsocks, ShadowsocksR, VMess, Trojan, Snell 등 비교적 초기에 성숙한 프로토콜에 초점을 맞췄고, 설정 필드가 상대적으로 고정되어 있으며 오랫동안 큰 확장이 없었습니다. mihomo는 이를 바탕으로 최근 몇 년간 등장한 출력 유형을 보완했는데, 대표적으로 다음과 같습니다:

• Hysteria / Hysteria2: QUIC 기반 혼잡 제어 프로토콜로, 네트워크 품질이 나쁘거나 패킷 손실이 많은 환경에서 기존 TCP 계열보다 우수한 성능을 보입니다.
• TUIC: 마찬가지로 QUIC 위에 구축되었으며 저지연 상황에 특화되어, 상호작용 지연에 민감한 사용 환경에 적합합니다.
• WireGuard: 출력 프로토콜로 직접 연결되어, 별도의 시스템 수준 WireGuard 클라이언트가 필요하지 않습니다.
• VLESS / VMess의 흐름 제어 확장 및 ShadowTLS 전치 계층으로, 트래픽 특징을 한층 더 위장합니다.
• Snell v4 등 프로토콜의 신규 버전 필드 지원.

즉, 구독 노드가 위와 같은 최신 프로토콜을 사용한다면 mihomo 코어만이 이를 올바르게 해석하고 연결을 맺을 수 있습니다. 오리지널 코어는 알 수 없는 프로토콜 타입을 만나면 대개 해당 노드를 건너뛰거나 오류를 내며, 이로 인해 프록시 그룹에서 "노드 수가 맞지 않는" 현상이 나타납니다.

규칙셋과 GEO 데이터: 갱신 방식의 차이

규칙 기반 분기는 GEOIP, GEOSITE 데이터베이스와 규칙셋(rule-provider)에 의존해 도메인이나 IP의 소속을 판단합니다. 오리지널 코어의 GEO 데이터 형식은 상대적으로 고정되어 있고 갱신 빈도는 코어 자체의 릴리스 주기에 좌우되지만, mihomo는 더 유연한 규칙셋 소스와 형식을 지원합니다:

1. rule-set으로 원격 규칙셋을 참조할 수 있고 behavior(domain / ipcidr / classical)와 갱신 간격을 지정할 수 있어, 규칙 내용이 코어 버전과 분리됩니다. 코어 신규 버전을 기다릴 필요 없이 최신 분기 규칙을 받을 수 있습니다.
2. MRS(mihomo 전용 바이너리 규칙 형식)를 지원해 기존 텍스트 규칙보다 로딩이 빠르며, 규칙 항목이 수만 개 규모에 달할 때 시작 속도와 매칭 성능 차이가 특히 두드러집니다.
3. GEO 데이터베이스 소스를 커스터마이즈할 수 있어, 코어에 내장된 고정 버전 대신 커뮤니티가 유지관리하는 GeoIP2/GeoSite 데이터 저장소를 지정할 수 있습니다.

일반 사용자 입장에서 체감되는 부분은, mihomo 코어를 쓰는 클라이언트는 보통 "규칙 제공자" 설정에서 더 풍부한 동작 옵션과 더 짧은 갱신 주기를 볼 수 있는 반면, 오리지널 코어 기반 클라이언트는 규칙 갱신이 클라이언트 전체 버전 릴리스와 함께 이루어지는 경우가 많다는 점입니다.

TUN 모드와 네트워크 스택: mihomo의 하위 레벨 개선

TUN 모드를 사용하면 Clash가 브라우저 등 프록시 설정을 지원하는 앱뿐 아니라 시스템 수준 트래픽 전체를 처리할 수 있습니다. 오리지널 코어의 TUN 지원은 비교적 기본적인 수준으로 시스템 라우팅 테이블을 수동으로 설정해야 했지만, mihomo는 이 계층에서 다음과 같은 개선을 이뤘습니다:

• 자동 라우팅 관리를 내장해 가상 네트워크 카드를 생성한 뒤 라우팅 테이블 항목을 자동으로 기록하고 종료 시 정리해, 수동 설정 오류 가능성을 줄입니다.
• gVisor 사용자 공간 스택과 시스템 네이티브 스택(system stack) 간 전환을 지원하며, 전자는 호환성이 좋고 후자는 일부 플랫폼에서 성능이 더 우수해 필요에 따라 선택할 수 있습니다.
• DNS 하이재킹과 Fake-IP 풀이 TUN 모드와 맞물리는 부분을 강화해, DNS 해석 경로 불일치로 인한 연결 실패를 줄였습니다.
• Android, macOS 등 플랫폼의 가상 네트워크 카드 권한 처리를 최적화해, 시스템 수준에서 연결이 끊길 가능성을 낮췄습니다.

이것이 "전역 투명 프록시", "시스템 전체 트래픽 인수" 같은 시나리오가 필요한 대부분의 클라이언트가 mihomo 코어를 우선 선택하는 이유입니다. TUN 모드의 안정성은 일상 사용 경험에 직접적인 영향을 미칩니다.

RESTful API 및 설정 기능 강화

두 코어 모두 HTTP 기반 외부 제어 인터페이스(보통 127.0.0.1:9090 같은 주소에서 대기)를 제공해, 클라이언트 UI가 프록시 상태를 조회하고 노드를 전환하고 로그를 확인할 수 있게 합니다. mihomo는 이 API를 다음과 같이 확장했습니다:

• 더 세밀한 인터페이스를 추가해, 그룹별 지연 조회나 규칙 제공자별 개별 갱신 트리거 등을 전체 설정을 다시 로드하지 않고도 수행할 수 있습니다.
• Script 규칙과 Lua 논리 판단 같은 고급 매칭 방식을 지원해, 규칙 파일에 단순 스크립트 로직을 작성할 수 있어 정적 규칙만 나열하는 방식에서 벗어났습니다.
• Provider 오버라이드(override) 기능을 강화해, 구독 자체를 수정하지 않고도 로컬 오버라이드 규칙으로 일부 필드(예: UDP 강제 활성화, 테스트 URL 수정)를 조정할 수 있습니다.

이런 기능은 주로 고급 사용자와 클라이언트 개발자를 대상으로 하며, 일반 사용자가 API를 직접 호출할 필요는 없습니다. 하지만 클라이언트 UI에서 "테스트 방식을 커스터마이즈할 수 있음", "특정 프록시 그룹이 스크립트 선택자를 지원함" 같은 설정 항목은 대개 이런 코어 API 확장에서 비롯됩니다.

주요 클라이언트는 어떤 코어를 내장하고 있나?

클라이언트를 고를 때 코어 버전이 기능의 상한선을 결정합니다. 아래 표는 대표적인 클라이언트와 그에 대응하는 코어 정보를 정리한 것으로, 빠르게 확인할 수 있습니다:

주의할 점은 같은 클라이언트 프로젝트라도 버전이 바뀌면서 코어를 옮기는 경우가 있다는 것입니다. 예를 들어 초기에는 오리지널 코어에 의존했다가 이후 mihomo를 내장하는 방향으로 전환할 수 있습니다. 다운로드 전에 클라이언트 릴리스 노트나 설정 페이지의 "코어 버전" 항목을 확인하는 것이, 클라이언트 이름만 보는 것보다 실제 기능을 파악하는 가장 확실한 방법입니다.

어떻게 선택해야 할까?

구독 노드가 Hysteria2, TUIC, WireGuard 같은 비교적 최신 프로토콜을 사용하거나, 안정적인 전역 TUN 모드와 더 유연한 규칙셋 갱신이 필요하다면 mihomo 코어를 내장한 클라이언트를 선택하는 것이 거의 유일하게 합리적인 선택입니다. Shadowsocks, VMess 같은 전형적인 프로토콜만 사용하고 이미 익숙해진 클라이언트 UI와 사용 습관이 있다면, 오리지널 코어 클라이언트로도 기본적인 분기와 전환 요구를 충족할 수 있으므로 굳이 무리하게 옮길 필요는 없습니다.

두 코어 모두 GPL-3.0 오픈소스 라이선스를 따르며 설정 파일 문법이 상당히 호환되어, 대부분의 config.yaml은 서로 간에 그대로 옮길 수 있습니다. 다만 새 프로토콜이나 새 규칙 문법이 관련된 부분은 오리지널 코어가 인식하지 못할 수 있으므로, 클라이언트를 전환하기 전에 미리 확인해 둘 필요가 있습니다.