코어 비교 2026-05-27 예상 읽기 시간 9분

Clash 오리지널, Meta, mihomo 코어 차이 비교: 프로토콜 지원과 선택 가이드

이름은 비슷하지만 세 코어의 능력 차이는 뚜렷합니다. 이 글은 프로토콜 지원, 규칙 문법, TUN 구현, 유지보수 상태 네 가지 측면에서 항목별로 비교하고, 클라이언트와 사용 시나리오별 코어 선택 결론을 제시합니다.

클라이언트를 다운로드하면 설정 화면에서 "코어 버전" 또는 "코어 유형"이라는 항목을 자주 보게 됩니다. 선택지는 보통 Clash Premium, Clash Meta, mihomo 중 하나이며, 가끔 업데이트가 끊긴 오리지널 Clash도 볼 수 있습니다. 이 이름들은 단순히 버전 번호 차이처럼 보이지만, 실제로는 완전히 다른 코드 브랜치이며 기능 집합, 프로토콜 지원 범위, 업데이트 빈도가 모두 다릅니다. 코어를 잘못 선택하면 가장 직접적으로 나타나는 문제는 특정 규칙 문법의 파싱 실패, 특정 프로토콜 노드 연결 불가, 또는 TUN 모드를 켜도 시스템 트래픽이 제대로 인계되지 않는 현상입니다. 이 글에서는 네 가지 핵심 축을 정리해 현재 사용 중인 클라이언트가 어떤 코어를 쓰는지, 그리고 수동으로 전환해야 하는지 판단할 수 있도록 돕습니다.

코어 계보: 하나의 프로젝트에서 갈라진 세 갈래

차이를 이해하려면 먼저 역사적 흐름을 정리해야 합니다. 최초의 Clash는 Dreamacro가 Go 언어로 작성했으며 오랫동안 사실상의 표준이었고, 규칙 엔진이 간결하고 리소스 사용량이 낮았지만, 작성자가 2023년에 공개 유지보수를 중단하면서 저장소가 보관 처리되어 이후 새로운 프로토콜 지원이 병합되지 않았습니다. 이것이 흔히 말하는 "오리지널 Clash" 또는 Clash Premium입니다(초기에는 유료 코어인 Premium 브랜치가 있어 규칙 속도 측정 등의 강화 기능을 제공했지만, 하위 프로토콜 집합은 오픈소스 버전과 거의 동일했습니다).

오리지널이 업데이트를 멈춘 뒤, 커뮤니티는 이를 기반으로 Clash.Meta 브랜치를 시작해 오리지널에 계속 없었던 프로토콜과 기능을 추가했습니다. 예를 들어 TUN 모드의 완전한 구현, Hysteria, TUIC, WireGuard 아웃바운드 등입니다. 이 브랜치는 이후 정식으로 mihomo로 이름을 바꾸었으며, 현재 커뮤니티 유지보수가 가장 활발하고 업데이트가 가장 빈번한 코어입니다. 대부분의 주류 클라이언트(Clash Verge Rev, FlClash, Clash Meta for Android 등)가 기본으로 내장하는 것도 mihomo이지만, 클라이언트 화면에서는 여전히 관례상 "Meta 코어"라고 부르는 경우가 많아 Meta와 mihomo가 서로 다른 것처럼 오해하기 쉽습니다. 실제로는 mihomo가 곧 Clash.Meta의 이름을 바꾼 후속 버전이며, 둘은 같은 브랜치의 서로 다른 단계일 뿐입니다.

참고: 클라이언트 설정 페이지에 "Meta 코어"라고 쓰여 있고 버전 번호가 v1.18.x 이상이라면, 실제로 실행 중인 것은 mihomo이며 명칭만 옛 이름을 그대로 쓰고 있다고 거의 확신할 수 있습니다.

프로토콜 지원 비교: 차이는 신규 프로토콜에 집중

세 코어는 Shadowsocks, VMess, Trojan 같은 "전통 3종" 프로토콜에서는 실질적인 차이가 없고, 모두 정상적으로 파싱하고 연결할 수 있습니다. 차이는 주로 최근 몇 년 사이 등장한 신규 프로토콜과 전송 방식에서 드러납니다:

프로토콜/기능	오리지널 Clash	Clash Meta	mihomo
Shadowsocks / VMess / Trojan	지원	지원	지원
Hysteria / Hysteria2	미지원	지원	지원
TUIC	미지원	지원	지원(v5 포함)
WireGuard 아웃바운드	미지원	일부 지원	지원
VLESS + XTLS/Vision	미지원	일부 버전 지원	지원
ShadowTLS	미지원	지원	지원
TUN 완전 인계	제한적	지원	지원 및 지속 개선

2021년 이후 등장한 프로토콜은 오리지널 Clash가 거의 예외 없이 지원하지 않는다는 점을 알 수 있으며, 이것이 오리지널이 점차 도태된 직접적인 원인입니다. 과도기 브랜치인 Clash Meta는 대부분의 신규 프로토콜을 다루지만 일부 구현이 초기 버전에 머물러 있어, 프로토콜 규격이 업데이트될 때(예: TUIC가 v4에서 v5로 올라갈 때) 뒤처질 수 있습니다. 현재 활발한 브랜치인 mihomo는 신규 프로토콜 대응 속도가 가장 빠르며, 대체로 프로토콜 표준이 발표된 후 한두 개 마이너 버전 안에 지원이 병합됩니다.

구독 노드 파싱 실패의 흔한 원인

구독에 Hysteria2나 TUIC 노드가 있는데 가져오기 후 "알 수 없는 프로토콜"이라고 표시되거나 그냥 걸러진다면, 클라이언트에 내장된 것이 여전히 오리지널 Clash 코어일 가능성이 큽니다. 이 경우 클라이언트를 다시 다운로드할 필요는 없고, 설정에 "코어 전환" 옵션이 있는지 확인해 Meta 또는 mihomo 코어로 바꾼 뒤 구독을 다시 가져오면 보통 해결됩니다.

규칙 문법 차이: Meta 계열이 추가한 매칭 유형

규칙 세트(Rule Provider)와 규칙 문법 면에서 mihomo/Meta는 오리지널에 비해 오리지널이 인식하지 못하는 매칭 규칙 몇 가지를 추가했으며, 이를 그대로 오리지널 코어의 설정 파일에 넣으면 실행 실패나 규칙이 조용히 무시되는 결과로 이어집니다:

RULE-SET: 외부 규칙 세트 파일을 참조합니다. 오리지널의 초기 버전은 증분 업데이트 방식의 규칙 세트 형식을 지원하지 않습니다.
GEOSITE / GEOIP(mmdb/dat 데이터베이스와 함께 사용): 도메인 또는 IP 소속 지역별로 묶어 분류하며, 오리지널은 새 형식의 데이터베이스와 호환성이 떨어집니다.
SCRIPT: 간단한 스크립트 로직으로 분기 판단을 할 수 있으며, Meta/mihomo만 지원합니다.
SUB-RULE: 하위 규칙 세트를 중첩 참조하는 기능으로, mihomo 후기 버전에서 추가되어 대형 규칙 파일을 간결하게 만드는 데 쓰입니다.
process-name / process-path 프로세스 단위 매칭: 요청을 발생시킨 앱 프로세스 기준으로 분기하며, TUN 모드를 통해 프로세스 정보를 얻어야 하므로 오리지널에는 이런 기능이 없습니다.

rules:
  - RULE-SET,private,DIRECT
  - RULE-SET,reject,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

위의 흔히 보는 규칙 조각에서 RULE-SET과 GEOSITE 모두 코어가 해당 파싱 능력을 갖추고 있어야 합니다. 이런 설정 파일을 오리지널 문법만 지원하는 클라이언트에 넣으면 로그에 보통 "unsupported rule type"이 표시되거나 규칙 전체가 적용되지 않고 기본 정책 그룹으로 돌아가며, 결과적으로 분기 규칙을 설정했는데도 모든 트래픽이 같은 경로로 흐르는 현상이 나타납니다.

TUN 모드 구현: 인계 완성도가 사용 경험을 좌우

TUN 모드란 코어가 시스템 계층에 가상 네트워크 어댑터를 만들어 기기의 모든 앱 트래픽을 강제로 프록시 처리 흐름으로 끌어들이는 방식으로, 개별 앱이 능동적으로 프록시 주소를 설정할 필요가 없습니다. 이 부분이 세 코어의 차이가 가장 직관적으로 드러나는 지점입니다:

오리지널 Clash: TUN 지원은 프로젝트 후반에야 추가되었고 구현이 비교적 기본적인 수준이라 IPv6, DNS 하이재킹 처리가 완전하지 않으며, 실제 사용 시 일부 앱이 프록시를 우회하는 경우가 자주 발생합니다.
Clash Meta: TUN 구현을 새로 작성해 자동 라우팅 테이블 설정, DNS 하이재킹, 프로세스 단위 필터링을 지원하며, UWP 앱이나 시스템 서비스 등 오리지널이 처리하지 못하던 트래픽 유형까지 다룹니다.
mihomo: Meta를 기반으로 지속적으로 다듬어, Android 플랫폼의 VpnService 통합과 iOS 플랫폼의 NetworkExtension 적응을 맞춤 최적화했고, 시스템 버전 업그레이드로 인한 다수의 TUN 호환성 문제도 수정했습니다.

안드로이드 사용자에게는 이 부분이 특히 중요합니다. Clash for Android 계열 클라이언트가 전역 트래픽을 안정적으로 인계할 수 있는지, DNS 요청의 흐름을 올바르게 처리할 수 있는지는 결국 내장된 것이 mihomo 코어인지 여부에 달려 있습니다. 특정 앱(특히 네트워크 격리 메커니즘이 있는 시스템급 앱)이 계속 프록시를 우회한다면, 먼저 클라이언트 코어 버전을 확인한 뒤 해당 앱의 네트워크 설정을 점검하십시오.

유지보수 상태와 업데이트 빈도: 장기 사용 가능성을 결정

프로토콜과 문법 차원의 정적 비교는 현재 상태만 반영할 뿐이며, 실제 선택 시 더 눈여겨봐야 할 것은 유지보수 활발도입니다. 프록시 프로토콜 자체가 계속 진화하고 있어서, 코어가 업데이트를 멈추면 얼마 지나지 않아 서버 측 프로토콜 버전을 따라가지 못하게 됩니다.

항목	오리지널 Clash	Clash Meta	mihomo
저장소 상태	보관 처리됨, 더 이상 업데이트 없음	mihomo에 통합됨, 독립 브랜치는 진행 중단	활발히 유지보수
버전 출시 주기	없음	과거 이력만 존재	몇 주마다 마이너 버전
보안 패치	더 이상 제공되지 않음	더 이상 제공되지 않음	지속적으로 대응
신규 프로토콜 병합 속도	해당 없음	해당 없음	빠름

간단히 말하면, "Clash Meta"라는 이름은 현재로서는 역사적으로 남은 명칭에 가깝고, 실제 코드 발전은 전부 mihomo 저장소로 이전되었습니다. "Clash Meta" 브랜치 명을 계속 유지하는 클라이언트도 본질적으로는 mihomo 빌드 결과물을 사용하고 있으며, 명명만 갱신되지 않았을 뿐입니다. 진짜로 아직 오리지널 Clash 코어를 쓰고 있고 한 번도 업그레이드하지 않은 클라이언트는 이미 드물며, 만나게 된다면 규칙 문법과 프로토콜 지원 모두 눈에 띄게 뒤처져 있을 것입니다.

시나리오별 코어 선택 가이드

위 네 가지 측면을 종합해 몇 가지 대표적인 시나리오의 판단 기준을 제시합니다:

일상 사용, 구독 노드가 비교적 최신인 경우: mihomo 코어를 내장한 클라이언트를 우선 선택하십시오. 신규 프로토콜 호환성과 TUN 안정성이 더 확실하고, 문제가 생겨도 커뮤니티가 더 빠르게 수정합니다.
복잡한 분기 규칙, 대형 규칙 세트에 의존하는 경우: 클라이언트가 RULE-SET과 SUB-RULE 문법을 지원하는지 확인하십시오. 이런 경우에는 오리지널 코어를 거의 배제해야 합니다.
순수 정적 설정, 노드를 장기간 바꾸지 않는 경우: 구독이 Shadowsocks/VMess 같은 기본 프로토콜만 사용하고 TUN 전역 인계가 필요 없다면, 클라이언트가 여전히 "Meta 코어"로 표기되어 있어도 대체로 충분하며 자주 전환할 필요는 없습니다.
안드로이드 기기에서 전역 프록시와 앱별 규칙이 필요한 경우: 클라이언트의 TUN 구현이 mihomo 기반인지 반드시 확인하십시오. 그렇지 않으면 프로세스 단위 분기와 일부 시스템 앱 트래픽 인계가 불완전할 수 있습니다.

현재 클라이언트가 정확히 어떤 코어를 쓰는지 판단하는 가장 직접적인 방법은 설정 페이지의 "정보" 또는 "코어 정보" 항목을 확인하는 것으로, 보통 mihomo v1.18.x 같은 버전 문자열이 표시됩니다. 출처 표기 없이 버전 번호만 적혀 있다면, 설정 파일에 새 문법 규칙(예: RULE-SET)을 하나 추가해 오류가 나는지 테스트해 보는 방식으로 간접적으로 검증할 수도 있습니다.

주의: 코어를 전환한 뒤에는 기존 설정 파일을 다시 한 번 검증하는 것이 좋습니다. 일부 정책 그룹 작성 방식(예: 아웃바운드 그룹의 type 필드 값)이 코어 간에 미세한 차이가 있어, 예전 설정을 그대로 재사용하면 파싱 오류가 발생할 소지가 낮게나마 존재합니다.

코어 문제 진단을 위한 간단한 절차

"규칙이 적용되지 않음", "프로토콜 연결 불가", "TUN을 켜면 일부 앱이 네트워크에 접근하지 못함" 같은 문제를 만나면 아래 순서로 확인하면 대개 몇 분 안에 코어 불일치 여부를 파악할 수 있습니다:

클라이언트 로그를 확인하고 unsupported, unknown rule type, protocol not supported 같은 키워드가 나오는지 검색합니다.
설정에서 현재 코어 버전 번호와 출처를 확인해 오리지널 Clash인지, 지나치게 오래된 Meta 브랜치인지 판단합니다.
클라이언트에 코어 전환 옵션이 있다면 mihomo 브랜치로 바꾼 뒤 설정 파일을 다시 불러옵니다.
규칙과 프로토콜에 여전히 문제가 있다면, 설정 파일 내 해당 필드의 작성 방식이 현재 코어 버전의 문서와 일치하는지 확인하고, 특히 규칙 세트 형식(YAML/텍스트)과 필드명 변화에 주의합니다.

전체적으로 보면 세 코어는 나란히 놓고 고르는 동등한 선택지가 아니라, 하나의 기술 진화 흐름입니다. 오리지널 Clash는 출발점이지만 이미 진행이 멈췄고, Clash Meta는 중간 과도기 단계이며, mihomo는 현재의 연속이자 종착점입니다. 명확한 호환성 이유(예: 일부 오래된 설정 파일이 오리지널의 동작 방식에 엄격히 의존하는 경우)가 없다면, 일상적인 사용에서 옛 코어를 굳이 고집할 필요는 없으며, mihomo를 내장한 클라이언트를 선택하면 프로토콜이나 문법 비호환으로 인한 원인 파악 작업을 대부분 줄일 수 있습니다.