Clash 오리지널, Meta, mihomo 코어 차이 비교: 기능·프로토콜·설정 호환성

하나의 계보: Clash에서 Clash Meta, 다시 mihomo로

세 이름의 관계를 이해하려면 먼저 시간 순서를 봐야 합니다. 가장 초기의 Clash(흔히 "오리지널" 또는 "Clash Premium"이라 부름)는 개인 개발자가 수년간 유지보수하며 규칙 분기, 정책 그룹, Provider 구독이라는 기본 아키텍처를 확립했고, 이후 거의 모든 클라이언트의 설정 문법이 이를 원형으로 삼았습니다. 원작자는 2023년 업데이트를 중단하고 코드 저장소를 삭제했으며, 오리지널 코어는 그 시점에 고정되어 이후 새 프로토콜이나 새 필드를 지원하지 않게 되었습니다.

업데이트가 멈춘 뒤 커뮤니티에서 가장 활발했던 포크 프로젝트가 Clash Meta(Clash.Meta라고도 함)였으며, 오리지널 코드를 기반으로 유지보수를 이어가면서 오리지널에 없던 기능들을 보완했고, 동시에 설정 문법 호환성을 높게 유지해 기존 사용자가 설정을 거의 바꾸지 않고도 전환할 수 있었습니다. Clash Meta는 한동안 운영된 뒤 mihomo로 정식 개명했는데, 이름만 바뀌었을 뿐 저장소와 유지보수 팀, 기술 노선은 연속적이므로 완전히 새로운 프로젝트가 아니라 "Clash Meta의 연속"으로 이해하면 됩니다.

따라서 현재 시장에서 계속 업데이트되는 대부분의 Clash 계열 클라이언트(데스크톱, 라우터 펌웨어 플러그인, 일부 안드로이드 클라이언트)는 내부적으로 거의 다 mihomo 코어를 사용하고 있으며, 겉모습만 서로 다른 그래픽 인터페이스와 브랜드명을 두르고 있을 뿐입니다. 이 계보를 이해하고 나면 아래 기능 비교를 훨씨 쉽게 대응시킬 수 있습니다.

프로토콜 지원 차이: 오리지널 업데이트 종료 이전의 능력 경계

프로토콜 지원은 세 세대 코어 사이에서 가장 직관적인 차이점입니다. 오리지널 코어가 업데이트를 멈췄을 때 지원한 프로토콜은 주로 Shadowsocks, ShadowsocksR, VMess, Trojan, Snell이었고, 당시 대부분의 구독 시나리오를 커버했지만 이후로는 추가된 것이 없습니다. Clash Meta는 바통을 이어받은 뒤 VLESS, Hysteria, Hysteria2, TUIC, WireGuard 등 비교적 최신 프로토콜을 잇달아 추가했고, mihomo도 이 흐름을 이어가며 새 프로토콜 특성과 핸드셰이크 파라미터 지원 속도가 오리지널 코어의 업데이트 종료 전보다 눈에 띄게 빨라졌습니다.

이 표를 다르게 보면: 구독 노드에 VLESS나 Hysteria2 프로토콜이 포함되어 있다면 오리지널 코어는 이런 노드를 전혀 해석할 수 없어 클라이언트가 곧바로 오류를 내거나 해당 노드를 건너뜁니다. 클라이언트를 업그레이드했는데 "노드가 전부 실패"하는 경우가 많은 것도 바로 이 때문입니다—구독이 고장 난 게 아니라 코어가 프로토콜을 따라가지 못하는 것입니다.

TUN 모드와 코어 아키텍처: Meta/mihomo의 핵심 업그레이드

TUN 모드(가상 네트워크 카드 모드)는 클라이언트가 브라우저나 특정 앱의 트래픽만이 아니라 시스템 전체 트래픽을 넘겨받을 수 있는지를 결정합니다. 오리지널 코어도 TUN을 지원하지만 구현이 비교적 기본적이고 프로세스 인식 능력이 제한적이어서, 앱별로 분기해야 하는 상황(예: 특정 게임만 프록시를 태우고 다른 앱은 직결)에서 자주 힘이 부족했습니다.

Clash Meta는 TUN 모드를 체계적으로 재작성해 훨씨 완전한 프로세스 매칭 메커니즘을 도입했고, 프로세스명·경로·패키지명 기준으로 트래픽을 필터링할 수 있게 되었으며, 규칙의 process-name, process-path 필드와 함께 정교한 분기가 가능해졌습니다. mihomo는 이 기반 위에서 성능과 호환성을 계속 최적화하고 있으며, 특히 Windows와 macOS에서의 TUN 안정성, 시스템 방화벽과의 연동, IPv6 트래픽 처리 등에서 오리지널보다 훨씨 성숙합니다.

또 하나 간과하기 쉬운 아키텍처 차이는 멀티코어 병렬 처리와 메모리 사용량 최적화입니다. mihomo는 장시간 실행되고 노드 수가 많은 환경에서 메모리 증가 곡선이 오리지널보다 훨씨 완만하며, 이는 24시간 상시 구동해야 하는 라우터나 NAS 환경에서 특히 중요합니다. 백그라운드에서 상시 실행하고 가끔 정책 그룹만 전환하는 사용 패턴이라면 새 코어를 선택하는 것이 안정성 측면에서 대체로 더 안전합니다.

설정 파일 필드 호환성: 어떤 필드가 그대로 옮겨지는가

좋은 소식은 세 세대 코어의 설정 파일 문법이 매우 동일한 뿌리에서 나왔고, 핵심 구조에 단절적인 변화가 없다는 점입니다. port, socks-port, mode, proxies, proxy-groups, rules 같은 기본 필드는 오리지널, Meta, mihomo 모두 표기 방식이 완전히 같으며, 오리지널용으로 작성한 설정을 mihomo에 그대로 가져가도 대부분 바로 로드되어 정상 작동합니다.

차이는 주로 신규 필드와 신규 프로토콜 전용 파라미터에서 나타납니다. 실제 예시를 몇 가지 들면:

• tun 섹션의 stack(gVisor 또는 System 네트워크 스택 선택), auto-route, dns-hijack 같은 하위 필드는 오리지널에 대응하는 구현이 없어, 오리지널 설정에 적어두면 그냥 무시되거나 오류가 발생합니다.
• proxies 목록의 type: vless, type: hysteria2 같은 노드 선언은 오리지널 코어가 type 필드의 이 값들을 인식하지 못해 해당 노드를 건너뛰거나 해당 구간 전체가 오류로 처리됩니다.
• dns 섹션의 enhanced-mode: fake-ip는 두 세대 모두 지원하지만, mihomo는 fake-ip-filter의 매칭 규칙을 세분화했기 때문에 일부 표기는 오리지널에서 결과가 다르게 나올 수 있습니다.
• 규칙 세트(rule-provider)의 behavior 필드 값은 신규 코어에서 더 많은 유형을 지원하며, 오리지널은 기본적인 domain, ipcidr, classical 세 가지만 호환됩니다.

실무 조언은 다음과 같습니다: 오리지널에서 mihomo로 이전할 때는 설정 파일을 거의 그대로 옮기고 tun 섹션과 신규 프로토콜 노드만 추가하면 됩니다. 반대로 mihomo용 설정을 오리지널 코어에 다운그레이드해 쓰려면 신규 프로토콜 노드와 tun 고급 필드를 먼저 삭제해야 하며, 그렇지 않으면 설정 전체가 로드되지 않습니다.

어떻게 선택할까: 상황별 선택 가이드

위에서 살펴본 프로토콜 지원, TUN 성능, 설정 호환성 차이를 종합해 실용적인 선택 기준을 몇 가지 제시합니다:

1. 구독 노드에 VLESS, Hysteria2, TUIC 등 신규 프로토콜이 포함된 경우: mihomo 코어를 반드시 선택해야 합니다. 오리지널 코어는 이런 노드를 해석할 수 없으며 "그래도 어떻게든 되겠지"의 여지가 없습니다.
2. 앱별 전역 프록시가 필요한 경우(게임만 프록시, 나머지는 직결): 완전한 프로세스 단위 TUN을 지원하는 mihomo를 선택하세요. 오리지널의 프로세스 매칭 능력은 제한적이어서 규칙을 적어도 동작하지 않을 수 있습니다.
3. 라우터나 NAS에 장기간 걸어두고 쓰는 경우: mihomo를 우선 고려하세요. 메모리와 병렬 처리 성능이 더 안정적이며 장시간 실행 신뢰성이 높습니다.
4. 가장 기본적인 Shadowsocks/VMess 노드만 쓰고 설정이 몇 년째 바뀐 적이 없는 경우: 두 세대 모두 작동은 하지만, 오리지널은 업데이트가 멈췄으므로 장기적으로는 지속 유지보수되는 mihomo로 이전해 향후 구독 프로토콜이 업그레이드될 때 호환이 안 되는 상황을 피하는 것을 권장합니다.
5. 남에게 받은 오래된 설정 파일의 호환성이 불확실한 경우: 먼저 텍스트 편집기로 설정에 vless, hysteria, tuic 키워드가 있는지, tun: 섹션이 있는지 검색해보세요. 이런 항목이 있다면 신규 코어용으로 작성된 설정임을 뜻합니다.

현재 주류 Clash 계열 클라이언트는 인터페이스 이름이 무엇이든 관계없이 내부적으로는 대부분 mihomo 코어로 전환되어 있으며, 이는 본 사이트 다운로드 페이지에서도 기본으로 추천하는 코어 노선입니다. 코어를 선택하는 것은 본질적으로 프로토콜 커버리지와 장기 유지보수 보장을 선택하는 일이며, 신규 코어가 두 항목 모두에서 우위에 있고 오리지널은 역사적 참고 대상으로서 존재하는 것에 가깝습니다.