Clash 오리지널, Meta, mihomo 코어 비교: 기능 차이와 선택 기준

코어 계보: Clash 오리지널부터 mihomo까지의 발전 흐름

시중에서 찾을 수 있는 "Clash"는 사실 세 갈래의 서로 다른 코드 라인을 가리킵니다. 이들 사이의 선후 관계를 이해하는 것이 어떤 코어를 써야 할지 판단하는 전제 조건입니다. 최초의 Clash는 원작자가 Go 언어로 작성했고, 배포 방식은 커맨드라인 코어에 서드파티 GUI를 조합하는 형태였으며, 오랫동안 각 플랫폼 클라이언트의 기본 코어 역할을 했습니다. 이 버전은 흔히 "오리지널" 또는 "Clash Premium/Core"로 불리며, 규칙 기반 분기, 프록시 그룹, 구독 링크라는 지금은 업계 표준이 된 인터랙션 모델을 확립했습니다.

2023년을 전후로 원작자의 관련 저장소가 코드 호스팅 플랫폼에서 전체 삭제되었고, 오리지널 코어는 공개적인 소스 업데이트와 버전 배포를 멈췄습니다. 이후 다운로드 가능한 오리지널 바이너리는 대부분 개발 중단 이전에 커뮤니티가 보관해 둔 과거 빌드나 서드파티 미러 저장소의 아카이브이며, 이 코드 라인에 새로운 프로토콜 지원이나 문제 수정이 더 이상 반영되지 않습니다.

오리지널이 아직 활발히 유지되던 시기에 이미 일부 개발자가 해당 코드를 기반으로 분기를 만들어 확장을 진행했는데, 이 분기는 당시 Clash Meta로 명명되었고 오리지널이 따라가지 못했던 신규 프로토콜과 TUN 모드 세부 사항을 중점적으로 보완했습니다. 오리지널이 개발 중단된 후 많은 GUI 클라이언트가 기본 코어를 Meta 분기로 전환했으며, 이것이 "Meta 코어"라는 표현이 튜토리얼과 포럼에서 자주 등장하는 이유입니다. Meta 분기는 이후 정식으로 개명을 거쳐 mihomo라는 이름으로 계속 유지보수되고 있으며, 코드 흐름과 배포 주기는 연속적으로 이어져 왔을 뿐 새로 시작한 것이 아닙니다. 즉 현재 보이는 "mihomo"는 기능적으로 세대 교체된 Meta이며, 둘은 병렬 관계가 아니라 같은 라인의 신구 명칭입니다.

세 세대 코어의 기능 및 프로토콜 지원 비교

세 코드 라인은 프로토콜 커버리지, 실행 모드, 설정 문법에서 모두 차이가 있습니다. 아래 표는 실제 사용에서 영향이 가장 큰 항목들을 정리한 것입니다.

보이는 바와 같이 차이의 핵심은 "누가 더 빠른가"나 "누구 UI가 더 예쁜가"가 아니라 프로토콜 목록과 실행 모드의 세대 차이입니다. 오리지널이 개발을 멈췄을 당시에는 신세대 암호화 프로토콜이 아직 보편화되지 않았으니 당연히 당시 코드에는 반영되지 않았습니다. Meta 분기와 이후의 mihomo가 등장한 가치는 바로 이런 신규 프로토콜과 더 정교한 트래픽 제어 기능을 보완하고, 상위 프록시 소프트웨어 생태계의 변화를 지속적으로 따라가는 데 있습니다.

유지보수 상태와 업데이트 빈도: 안심하고 쓸 수 있는가

코어 선택은 기능 목록만 볼 것이 아니라, 이 코드 라인을 지금 누군가가 계속 수정하고 있는지도 봐야 합니다. 세 코어의 유지보수 상태 차이는 명확합니다.

• 오리지널: 저장소가 더 이상 업데이트되지 않으며, 현재 남아 있는 실행 파일은 과거의 아카이브입니다. 새로운 프로토콜 지원도, 기존 문제에 대한 수정도 받을 수 없습니다. 어떤 구독 제공자가 오리지널이 인식하지 못하는 신규 프로토콜로 전환하면 오리지널은 그대로 연결에 실패하며, 업그레이드 경로도 없습니다.
• Meta(과거 명칭): 전환기의 이름으로서 현재는 더 이상 활성화된 배포 채널이 아니며, 관련 태그와 설명은 새 버전에서 이미 mihomo 프로젝트로 통합되었습니다. "Clash Meta" 최신 버전을 따로 찾으면 대개 mihomo로 안내됩니다.
• mihomo: 현재 실제로 계속 배포되고 있는 코드 라인으로, 버전 번호가 정기적으로 갱신되며 신규 프로토콜, 신규 플랫폼 대응, 문제 수정이 모두 여기서 이루어집니다. 활발히 유지보수되는 대다수 GUI 클라이언트는 하위 코어가 이미 mihomo를 가리키고 있으며, 다만 클라이언트 화면에서는 여전히 "Meta 코어"라는 과거 표현을 쓰고 있을 수 있습니다.

상황별 선택 가이드

프로토콜 호환성과 유지보수 상태를 종합해, 그대로 적용할 수 있는 판단 기준 몇 가지를 제시합니다.

1. 구독이 기본 프로토콜만 사용하고 TUN 모드가 필요 없는 경우

   상위 노드가 전부 Shadowsocks, VMess, Trojan이고 신규 프로토콜이 없으며 시스템 레벨로 트래픽을 처리할 계획도 없다면, 이론적으로는 오리지널 아카이브로도 연결이 가능합니다. 다만 이는 더 이상 문제가 수정되지 않는 과거 버전을 쓰는 것임을 명확히 인지해야 하며, 장기적으로 프로토콜 도태나 클라이언트 대응 단절의 위험이 있으므로 장기 방안으로는 권장하지 않습니다.

2. 구독에 VLESS, Hysteria2, TUIC 등 신규 프로토콜이 포함된 경우

   이런 프로토콜은 오리지널이 전혀 인식하지 못해 연결이 바로 실패합니다. mihomo 코어 기반 클라이언트를 선택해야 하며 우회할 방법이 없습니다.

3. TUN 모드로 전역 트래픽을 처리하거나 프로세스 단위 분기가 필요한 경우

   TUN 모드는 mihomo에서 장기적으로 유지보수되는 안정 기능으로 존재하며, 설정 필드와 동작이 더 완성도 있습니다. 오리지널의 관련 구현은 초기 단계에 머물러 있어 정교한 분기를 이에 의존하는 것은 권장하지 않습니다.

4. 어떤 것을 선택해야 할지 확실하지 않고 문제를 최소화하고 싶은 경우

   현재 주류 GUI 클라이언트가 기본으로 통합한 mihomo 코어를 바로 사용하면 됩니다. 커버하는 프로토콜 범위가 가장 넓고 업데이트 주기가 안정적이며, 문제가 생겨도 지속적으로 수정될 가능성이 있어 코어 출처가 이미 개발 중단되었는지 따로 판단할 필요가 없습니다.

오리지널 설정에서 mihomo로 이전할 때 주의할 점

손에 있는 설정 파일이 예전에 오리지널 규칙으로 작성된 것이라면, mihomo 코어로 이전할 때 기본적으로 그대로 재사용할 수 있지만 몇 가지 필드 차이는 확인해 두는 것이 좋습니다. 규칙 그룹 동작이 예상과 다르게 동작하는 것을 방지하기 위해서입니다.

• proxy-groups 안의 그룹 유형은 mihomo에서 더 많은 정책 옵션으로 확장되었습니다. 오리지널에 없던 필드는 무시되며 설정 오류가 나지는 않지만 적용되지도 않으므로, 하나씩 확인하는 것을 권장합니다.
• rule-providers의 동작 필드는 새 코어에서 더 세분화되었으며, 기존의 단순한 규칙 세트는 그대로 정상적으로 로드됩니다.
• 신규 프로토콜 노드에 해당하는 항목은 오리지널 설정 파일에는 보통 존재하지 않으므로, 이전 후 필요에 따라 추가하면 되며 기존의 다른 노드에는 영향을 주지 않습니다.

간단한 자체 점검 방법은 먼저 새 코어로 기존 설정을 로드해 실행 로그에 인식되지 않은 필드에 대한 안내가 있는지 확인한 뒤, 공식 문서의 필드 설명과 하나씩 대조해 핵심 정책이 빠지지 않았는지 확인하는 것입니다.

mihomo -d ./config -f ./config.yaml

커맨드라인으로 실행하면 로그에 코어 버전, 로드된 규칙 수, 파싱 실패한 항목 여부가 바로 출력됩니다. 이는 코어 버전과 설정 호환성을 확인하는 가장 직접적인 방법이며, 클라이언트 화면에 표시되는 이름만 보는 것보다 훨씬 신뢰할 수 있습니다.

결론: 지금 어떻게 선택해야 하는가

위 내용을 실행 가능한 한 문장으로 정리하면 다음과 같습니다. 오리지널 코어는 이미 유지보수가 종료되어, 자신이 옛 버전을 쓰고 있다는 것을 명확히 알고 있고 구독 프로토콜 범위가 매우 제한적인 경우에만 적합합니다. Meta라는 이름은 현재 이미 mihomo로 통합되었으므로 별도로 찾는 것은 더 이상 의미가 없습니다. 새로 클라이언트를 설치하거나 코어를 교체할 때는 하위 코어가 mihomo인지 먼저 확인하는 것이 우선이며, 이는 프로토콜 커버리지가 가장 넓고 유지보수가 가장 활발한 선택이자 현재 각 플랫폼 GUI 클라이언트의 주류 기본 구성입니다.