코어 발전 흐름: mihomo가 등장한 배경
기존 Clash 코어는 Dreamacro가 주도해 개발했으며, 오랫동안 Clash 생태계의 사실상 표준 구현체로 자리 잡았습니다. Shadowsocks, Vmess, Trojan 등 주요 프로토콜을 지원했고, 규칙 엔진과 설정 형식 역시 이후 수많은 클라이언트의 기준이 됐습니다. 2023년 무렵 원작자 계정과 관련 코드 저장소가 내려가면서 기존 코어의 업데이트는 중단됐습니다.
커뮤니티는 곧 Clash Meta 분기를 통해 개발을 이어갔고, 이후 mihomo로 이름을 바꿨습니다. 이는 단순한 명칭 변경이 아니라, 기존 코드베이스 위에 새 프로토콜과 새 기능을 지속적으로 병합하면서 기존보다 기능 범위가 확연히 넓어진 구현체로 발전한 것입니다. 현재 주류로 쓰이는 Clash 계열 클라이언트, 예를 들어 Clash Verge, Clash for Windows의 후속 대체 클라이언트, 대부분의 모바일 클라이언트는 내부적으로 이미 mihomo 코어로 전환됐으며, 기존 코어는 일부 오래된 클라이언트에만 남아 있는 상태입니다.
이 흐름을 이해하면 실용적인 의미가 하나 생깁니다. 지금 사용 중인 클라이언트가 여전히 "Clash 코어"라고만 표기돼 있고 오랫동안 업데이트가 없었다면, 대부분 기존 코어를 쓰고 있을 가능성이 크며, 프로토콜 지원 범위가 현재 주류 노드 제공업체가 제공하는 프로토콜 종류에 비해 뒤처져 있을 수 있습니다.
프로토콜 지원 범위 비교
프로토콜 지원은 두 코어의 가장 직관적인 차이입니다. 기존 코어가 지원하는 프로토콜 종류는 유지보수가 중단되기 전 상태에 머물러 있고, mihomo는 이 기반 위에 계속 새 프로토콜을 추가해 현재 지원 범위가 눈에 띄게 넓습니다.
| 프로토콜 | 기존 Clash 코어 | mihomo |
|---|---|---|
| Shadowsocks | 지원 | 지원(더 많은 암호화 방식 포함) |
| Vmess | 지원 | 지원 |
| Trojan | 지원 | 지원 |
| VLESS | 미지원 | 지원 |
| Hysteria / Hysteria2 | 미지원 | 지원 |
| TUIC | 미지원 | 지원 |
| WireGuard(아웃바운드) | 미지원 | 지원 |
| SSH(아웃바운드) | 미지원 | 지원 |
이 중 VLESS와 Hysteria2는 최근 몇 년간 노드 제공업체 쪽에서 사용률이 빠르게 늘고 있는 두 프로토콜입니다. VLESS는 보통 XTLS 또는 Reality 전송 계층과 함께 사용해 특징 탐지에 대응하며, Hysteria2는 QUIC 기반으로 약한 네트워크, 높은 지연, 패킷 손실이 있는 환경에서 전통적인 TCP 계열 프로토콜보다 더 안정적인 처리량을 보여줍니다. 구독에 이 두 프로토콜을 사용하는 노드가 포함돼 있다면 기존 코어는 파싱 자체가 실패하거나 노드를 사용할 수 없게 되므로, 반드시 mihomo 코어 기반 클라이언트로 전환해야 정상적으로 연결할 수 있습니다.
사용 중인 클라이언트가 어떤 코어를 쓰는지 확인하려면 클라이언트의 "코어 버전" 또는 "정보" 페이지를 확인하면 됩니다. mihomo 또는 Clash.Meta로 표기돼 있다면 새 코어이고, 순수 숫자 버전 번호만 표기돼 있고 오랫동안 옛 버전에 머물러 있다면 대부분 기존 코어입니다.
TUN 모드: 외부 플러그인에서 내장 기능으로
TUN 모드(가상 네트워크 카드 모드라고도 함)는 코어가 시스템 계층에서 가상 네트워크 인터페이스를 생성해 전체 또는 지정 범위의 시스템 트래픽을 가로채고 프록시 규칙으로 처리하는 방식으로, 애플리케이션 계층의 시스템 프록시 설정에 더 이상 의존하지 않습니다. 이 방식의 장점은 커버 범위가 훨씬 넓다는 점입니다. 시스템 프록시 설정을 지원하지 않는 프로그램, 일부 게임 클라이언트, 시스템 레벨 서비스의 네트워크 요청까지 모두 분기 처리 범위에 포함시킬 수 있습니다.
기존 Clash 코어 자체에는 TUN 기능이 없었습니다. 초기 구현은 별도의 보조 프로그램이나 시스템 계층 드라이버와 함께 작동해야 유사한 효과를 낼 수 있었고, 설정 난이도가 높았을 뿐만 아니라 플랫폼 간 일관성도 떨어져 Windows, macOS, Linux마다 각기 다른 적용 방식이 필요했습니다.
mihomo는 TUN 모드를 코어 자체 네이티브 기능으로 내장했으며, 설정 항목은 핵심 설정 파일의 tun필드 아래 직접 작성하면 되고 별도의 드라이버나 플러그인이 필요하지 않습니다(일부 플랫폼에서는 시스템이 가상 네트워크 카드 생성 권한을 부여해야 하지만, 이는 시스템 차원의 정상적인 권한 부여 절차입니다). 전형적인 mihomo TUN 설정 예시는 다음과 같습니다:
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53stack필드는 system, gvisor등 서로 다른 네트워크 스택 구현을 선택할 수 있으며 각각 호환성과 성능 면에서 트레이드오프가 있습니다. auto-route를 켜면 코어가 시스템 라우팅 테이블을 자동으로 관리해 라우팅 규칙을 수동으로 설정할 필요가 없습니다. 이 부분은 기존 코어에는 전혀 없던 기능으로, 많은 사용자가 기존 코어에서 mihomo로 전환하는 직접적인 이유 중 하나입니다.
규칙 엔진과 규칙 세트 기능 강화
규칙 기반 분기는 Clash 계열 클라이언트의 핵심 메커니즘으로, 도메인, IP 대역, 프로세스 이름 등의 조건을 매칭해 각 연결이 어떤 프록시 노드를 사용할지 또는 직접 연결할지를 결정합니다. 기존 코어의 규칙 유형은 DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR, GEOIP등 기본 유형에 집중돼 있었고, 규칙 세트(Rule Provider) 메커니즘 역시 비교적 단순했습니다.
mihomo는 이를 기반으로 다음과 같이 몇 가지 방향에서 강화했습니다:
- 규칙 세트 형식 확장: 기존 YAML 목록 형식 외에 MRS(mihomo 전용 바이너리 규칙 세트 형식)를 새로 지원해, 용량이 더 작고 로딩이 더 빠르며 규모가 큰 규칙 라이브러리에 적합합니다.
- 논리 규칙:
AND,OR,NOT등 논리 조합 규칙을 지원해 여러 매칭 조건을 하나의 규칙으로 묶을 수 있어 규칙 수를 줄이고 유지보수성을 높입니다. - 프로세스 매칭 규칙:
PROCESS-NAME,PROCESS-PATH등 연결을 시작한 프로세스 이름이나 경로로 분기하는 규칙 유형은 기존 코어에서는 지원 범위가 제한적이었으나, mihomo에서는 더 완전하게 지원되며 특히 데스크톱에서 앱 단위로 분기하는 시나리오에서 유용합니다. - 서브넷 규칙과 스크립트 규칙: 매칭 차원을 더 세밀하게 나눠 복잡한 분기 전략을 처리하기 쉽게 합니다.
이미 규칙 세트를 사용하고 있는(모든 규칙을 메인 설정 파일에 직접 작성하지 않는) 사용자라면 이 변화는 보통 체감하기 어렵습니다. 규칙 세트 주소 자체는 코어 전환의 영향을 받지 않지만, 규칙 세트 작성자가 mihomo 전용 규칙 유형이나 MRS 형식을 사용하기 시작하면 기존 코어에서는 해당 규칙 세트를 파싱할 때 오류가 나거나 규칙이 작동하지 않게 됩니다.
설정 파일 호환성과 마이그레이션 포인트
mihomo는 설계상 기존 Clash 설정 형식에 대해 높은 하위 호환성을 유지하고 있으며, 기본 필드 구조(proxies, proxy-groups, rules등 최상위 필드)는 기본적으로 동일합니다. 즉 대부분의 기존 설정 파일은 mihomo 기반 클라이언트에서도 그대로 정상적으로 로드되고 작동합니다. 다만 기존 코어에서 mihomo로 전환할 때 몇 가지 주의할 점이 있습니다:
- 새 프로토콜 노드는 클라이언트가 지원해야 적용됩니다: 설정 파일에 VLESS, Hysteria2 등 기존 코어가 지원하지 않는 프로토콜 노드가 있으면 기존 코어는 해당 노드를 건너뛰거나 바로 오류를 냅니다. mihomo로 전환해야 해당 노드가 프록시 그룹 목록에 정상적으로 표시됩니다.
- 일부 필드명에 차이가 있습니다: mihomo에는 더 정밀하게 이름을 붙였거나 선택적 파라미터를 추가한 필드가 일부 있습니다. 예를 들어 TUN 관련 설정 전체는 mihomo에서 새로 추가된 필드로, 기존 설정 파일에는 존재하지 않으므로 mihomo 문서를 참고해 추가해야 하며, 옛 설정에서 "복사"해서는 안 됩니다.
- Provider 업데이트 동작이 약간 다릅니다: mihomo는 Proxy Provider, Rule Provider의 헬스 체크와 업데이트 정책을 최적화해 로딩 실패 시 재시도 로직이 더 안정적이지만, 기본 필드(
url,interval,path)는 그대로 유지되므로 변경할 필요가 없습니다. - GEOIP 데이터베이스 형식: mihomo는 기본적으로 mihomo geoip 데이터베이스를 사용하며, 기존에 쓰던 GeoLite2 계열 데이터베이스 형식과 완전히 동일하지 않습니다. 처음 전환할 때는 보통 클라이언트가 자동으로 맞는 데이터베이스 파일을 내려받으며, 네트워크 환경으로 인해 다운로드가 실패하면 GEOIP 관련 규칙이 일시적으로 작동하지 않고 직접 연결/프록시 판단이 다른 규칙에 따라 처리됩니다.
마이그레이션 전에는 기존 설정 파일을 먼저 백업하는 것이 좋습니다. 코어를 전환한 뒤 프록시 그룹이 비어 있거나 규칙이 대량으로 작동하지 않는 경우, 구독 자체가 만료됐다고 의심하기 전에 설정 파일에 mihomo에서만 지원하는 필드나 규칙 세트 형식이 사용됐는지부터 확인하세요.
대부분의 일반 사용자에게는 마이그레이션 경로가 사실 매우 간단합니다. mihomo 코어를 지원하는 클라이언트 설치 파일로 바꾸고, 설정 파일이나 구독 링크를 그대로 가져오면 됩니다. 필드를 직접 수정할 필요는 없습니다. 복잡한 규칙을 직접 작성하거나 논리 규칙 등 mihomo 전용 문법을 사용하는 경우에만 형식 세부사항을 추가로 신경 써야 합니다.
어떻게 선택할까: mihomo 코어로 전환이 필요한 경우
앞선 비교를 바탕으로 판단 기준을 몇 가지 정리하면 다음과 같습니다:
- 구독 노드에 VLESS, Hysteria2, TUIC 등 새 프로토콜이 포함돼 있다면 mihomo 코어를 반드시 사용해야 합니다. 기존 코어는 이런 노드를 파싱할 수 없습니다.
- TUN 모드로 전역 투명 프록시를 구현해야 하는 경우, 특히 게임이나 시스템 레벨 서비스처럼 시스템 프록시를 지원하지 않는 환경까지 커버해야 한다면 mihomo 코어가 유일하게 네이티브로 지원하는 선택입니다.
- Shadowsocks, Vmess, Trojan 등 기본 프로토콜만 쓰고 TUN 모드가 필요 없다면, 기존 설정은 두 코어 모두에서 정상 작동합니다. 다만 기존 코어는 업데이트가 이미 중단됐기 때문에 장기적으로는 계속 관리되고 있는 mihomo로 전환해 보안 업데이트와 안정성 개선을 받는 것이 좋습니다.
- 규칙 세트 작성자가 이미 mihomo 전용 문법이나 MRS 형식으로 마이그레이션했다면, 기존 코어를 계속 사용할 경우 규칙 세트 로딩이 실패하게 되므로 이 경우에는 코어 전환이 유일한 해결책입니다.
현재 주류 Clash 계열 클라이언트는 대부분 기본적으로 mihomo 코어를 통합해 제공하고 있으며, 클라이언트 설정 안에 코어 버전 관리 진입점을 두어 여러 mihomo 버전 사이를 전환할 수 있도록 해 별도로 코어 파일을 내려받을 필요가 없습니다. 신규 사용자라면 현재 유지보수 중인 클라이언트를 바로 설치하면 코어 선택 문제를 거의 겪지 않습니다. 오래된 기존 코어 클라이언트를 계속 쓰고 있는 사용자라면, 노드 프로토콜과 기능 요구사항을 점검한 뒤 가능한 빨리 mihomo 기반 대체 클라이언트로 마이그레이션하는 것을 권장합니다.