왜 지금 토폴로지를 먼저 고르는가

집이나 소규모 작업실에서 Clash·Mihomo를 쓰는 목적은 단순히 “브라우저만 빠르게”가 아니라, 여러 대의 기기가 같은 스플릿 규칙과 DNS 해석 경로를 공유하는 데 가깝습니다. 노트북은 Clash Verge Rev로 잘 돌아가도, 스마트 TV·콘솔·테스트용 서버까지 손이 닿으면 “어느 IP가 게이트웨이인지”가 문제의 중심으로 옮겨 붙습니다. 이때 필요한 것은 노드 속도 경쟁이 아니라 Clash 토폴로지, 즉 프록시 코어를 어디 두고 누가 DHCP로 넘겨받는지에 대한 설계입니다.

대표적인 세 가지는 (1) 단일 PC에서 allow-lan·혼합 포트로 나눠 쓰기, (2) 우회경로 OpenClash 또는 투명 프록시가 올라간 보조 OpenWrt가 전체 기본 경로를 잡기, (3) NAS Docker에서 Mihomo를 상시 띄우고 LAN에서 그 컨테이너로만 모이게 하기입니다. 각각 초기 난이도, 전기 소모, 장애 시 영향 범위, 장비 교체 주기가 다릅니다. 본문은 법령·서비스 약관을 준수하는 개인·가정 내 네트워크 개선을 전제로, 가정 프록시와 소규모 작업실 네트워크에서 자주 보이는 선택지를 나란히 놓고 비교합니다.

세 토폴로지가 맡는 역할을 한 문장으로

단일 PC 방식은 “항상 켜 둘 메인 워크스테이션이 있고, 다른 기기는 그 옆에서 수동 프록시나 간헐적으로만 붙는다”는 가정에 가장 잘 맞습니다. TV나 NAS가 스스로 인터넷에 나가야 한다면 곧바로 한계가 보입니다. 우회경로 OpenClash는 OpenWrt 계열 펌웨어 위에서 Luci로 구독·정책을 묶고, 메인 공유기 뒤나 앞에 두어 DHCP 기본 게이트웨이를 넘겨받는 패턴이 흔합니다. 실무 구성은 OpenClash 구독·노드 전환 튜토리얼과 OpenWrt 우회경로에서 mihomo 투명 게이트웨이 글과 결이 같습니다. NAS Docker Mihomo는 이미 24시간 돌아가는 스토리지 서버가 있다면, 컨테이너 하나와 호스트 네트워크 브리지만 정리하면 된다는 이점이 있습니다. 반대로 NAS 재부팅이 잦거나 디스크 복구 때문에 서비스가 자주 내려간다면 가용성 점수는 떨어집니다.

팁: “어느 게 옳다”보다 “누가 항상 켜져 있고, 누가 DHCP를 말하는가”가 먼저입니다. 전원이 자주 꺼지는 장비를 코어 자리에 두면 규칙이 아무리 완벽해도 가족 전체가 같이 끊깁니다.

토폴로지 A: 단일 PC에서 Clash를 허브로 쓰기

구조는 단순합니다. 한 대의 Windows·macOS·Linux에서 GUI 또는 데몬으로 코어를 띄우고, 다른 기기는 같은 서브넷에서 HTTP·SOCKS 포트로 붙습니다. Allow LAN 점검 가이드에 정리된 것처럼 bind-address·혼합 포트·OS 방화벽·AP 격리를 맞추는 일이 실제 난이도의 대부분을 차지합니다. 장점은 OpenWrt 플래시나 Docker 볼륨 없이도 오늘 당장 시도할 수 있다는 점이고, 데스크톱 사용자가 직접 로그를 보며 디버깅하기도 쉽습니다.

한계도 명확합니다. PC가 절전에 들어가면 LAN 공유 경로가 같이 사라지고, 업데이트 재부팅 때마다 가족 기기가 잠시 끊깁니다. 게임기·스피커처럼 수동 프록시 UI가 없는 기기는 TUN이나 메인 라우터 단의 정책 라우팅 없이는 코어를 거치기 어렵습니다. “내 노트북만”이 아니라 거실 전체를 커버하려는 가정 프록시 요구에 이 단계에서 걸리는 경우가 많습니다. 그때는 토폴로지 B나 C로 옮기는 편이 정신 건강에 이롭습니다.

추가로 TUN 모드를 PC에서 켜 두면 해당 OS 안의 앱 우회는 깔끔해지지만, 이 역시 PC가 꺼지면 함께 사라집니다. TUN은 “한 PC 안의 완전한 가로채기”지, “거실 모든 Wi-Fi 클라이언트 자동화”는 아닙니다.

토폴로지 B: 우회경로·OpenClash가 게이트웨이를 잡는 경우

보조 라우터 한 대를 우회경로로 두고, DHCP에서 기본 라우터·DNS를 그 장비로 넘기면, 스마트폰이든 프린터든 전원만 켜면 같은 정책을 타게 만들 수 있습니다. OpenClash는 구독 동기화·정책 그룹·Geo 데이터를 Luci에서 관리할 수 있어, 콘솔만 붙인 사용자에게도 “공유기 화면만 보면 된다”는 장점이 있습니다. 메인 공유기는 그대로 두고 중간에만 넣는 소규모 작업실 네트워크 확장에도 잘 맞습니다.

비용은 장비와 펌웨어 유지입니다. 트래픽이 몰리면 SoC·RAM·플래시 수명이 병목이 되고, 펌웨어 업그레이드나 패키지 의존이 꼬이면 원격지에서 복구하기 어렵습니다. 장애 범위는 “우회 라우터 뒤의 전 VLAN”이라 넓어서, 반드시 롤백용 DHCP 스냅샷이나 메인 라우터의 예비 프로필을 마련해 두는 것이 좋습니다. 투명 프록시·DNS 리다이렉트를 켤 때는 로컬 NAS 이름·회사 VPN·IPTV 멀티캐스트처럼 DIRECT로 남겨야 할 목적지를 한 번 더 훑어야 합니다.

IPv6나 이중 스택 환경에서는 RA·DHCPv6가 기대와 다르게 동작해 “IPv4만 프록시” 상태가 깨지기도 합니다. 이때는 메인 라우터에서 IPv6 접두사를 잠깐 끄는 등 망 운영자 결정이 필요합니다. 우회 장비 한 대가 전체 정책의 단일 실패점(SPoF)이 된다는 점을 인지하고 UPS·모니터링을 붙이는 편이 안전합니다.

토폴로지 C: NAS 위 Docker Mihomo를 상시 구동

시놀로지·QNAP·자작 NAS 등 이미 항상 켜져 있는 리눅스 호스트가 있다면, Docker로 Mihomo 이미지를 올리고 호스트 브리지 IP의 포트만 열어 주는 방식이 깔끔합니다. 컨테이너는 교체가 쉬워 코어 버전을 올릴 때 볼륨만 유지하면 되고, 설정 파일은 Git이나 스냅샷으로 버전 관리하기도 좋습니다. 작업실에서 개발 서버와 파일 서버를 같은 랙에 두는 경우, NAS가 사실상 “소형 허브 서버” 역할을 이미 하고 있으면 자연스러운 선택입니다.

주의할 점은 NAS 펌웨어 업데이트와 컨테이너 엔진 재시작이 겹칠 때입니다. 제조사가 Docker 패키지를 바꾸면 네트워크 모드가 리셋되어 LAN에서 컨테이너로 향하던 포트가 닫히기도 합니다. 또 NAS 디스크 장애나 RAID 재실드 중에는 CPU가 바빠서 코어 지연이 생길 수 있습니다. 공유기 우회처럼 “모든 Wi-Fi가 자동으로 NAS를 향하게” 만들려면 역시 DHCP 옵션이나 정책 라우팅이 필요하고, NAS 한 대만 DHCP 서버로 삼는 구성은 다른 제약(멀티캐스트·공유기 기능)과 충돌하지 않는지 검토해야 합니다.

이 토폴로지의 강점은 백업과 규칙 파일을 같은 ZFS·Btrfs 풀에 둘 수 있다는 점입니다. 야간 스냅샷에 YAML이 같이 실리면 “어제로 되돌리기”가 수동 복사보다 빠릅니다. 반대로 보안 패치를 게을리하면 침해 시 영향도 함께 커지므로, 관리자 계정·SSH·Docker 소켓 노출은 최소화하는 것이 좋습니다.

같은 기준으로 보는 빠른 비교

표 대신 실무에서 자주 쓰는 질문 네 가지로 압축해 보겠습니다. 첫째, “PC를 끄면 집 전체가 끊겨도 되는가?” 예라면 A가 빠릅니다. 아니라면 B 또는 C입니다. 둘째, “프록시 없는 기기도 같은 규칙을 타야 하는가?” 예라면 단순 Allow LAN만으로는 부족하고 B가 유리합니다. 셋째, “이미 NAS를 365일 돌리고 있는가?” 예라면 C의 운영 비용이 상대적으로 낮습니다. 넷째, “펌웨어·iptables를 손볼 열정이 있는가?” 아니라면 B보다 A+C 조합, 즉 메인은 단순 유지하고 허브만 NAS로 두는 타협을 고려합니다.

운영 측면에서 OpenClash는 UI가 익숙해지면 가족 구성원도 상태를 볼 수 있지만, CLI와 로그 용어에 익숙한 관리자가 한 명은 필요합니다. Docker 쪽은 docker compose나 GUI 래퍼에 익숙하면 재현성이 높고, 그렇지 않다면 학습 곡선이 처음부터 가파릅니다.

참고: 어떤 토폴로지든 구독 URL과 로컬 오버라이드를 분리해 두면 이전이 빨라집니다. 원격 프로필 전체를 그대로 가져오기보다, 가정망용 rules와 DNS만 로컬 파일로 고정해 두는 패턴을 추천합니다.

이전 체크리스트: 한 번에 갈아타기 전에

토폴로지를 바꿀 때 헛발질이 나는 지점은 대부분 “프로필은 옮겼는데 DHCP·DNS는 예전 주소를 가리킨다”는 부분입니다. 아래 순서는 위 HowTo JSON-LD와 동일한 흐름을 글 읽는 순서에 맞게 풀어 쓴 것입니다.

  1. 현재 기본 게이트웨이·DNS·정책 라우팅을 스크린샷 또는 표로 남기고, 프록시 꺼진 상태에서도 인터넷이 나가는 경로를 적어 둡니다.
  2. 사용 중인 YAML 전체와 구독 URL 목록을 분리 백업합니다. 토큰이 URL에 붙어 있다면 비밀 저장소에만 둡니다.
  3. 이동할 단말에서 수동 프록시, PAC, 이전 우회 IP를 모두 끄고, 순수 DHCP만 남긴 채 새 게이트웨이로 ping·DNS 조회가 되는지 확인합니다.
  4. 우회 라우터나 NAS를 기본 게이트웨이로 올릴 때는 한 번에 한 세그먼트만 옮겨 테스트합니다. IoT VLAN은 나중에 붙여도 됩니다.
  5. fake-ip, 스니퍼, 로컬 도메인 예외를 새 파일로 복사합니다. 사내 Git·프린터·NAS 웹 UI 이름이 여기에 걸립니다.
  6. Docker라면 컨테이너 restart 정책과 로그 로테이션을 설정하고, OpenWrt라면 syslog 외부 전송 여부를 결정합니다.
  7. 최종 점검으로 모바일 한 대·유선 PC 한 대·가전 한 종류씩만 골라 트래픽 로그를 비교합니다. 전부 동시에 바꾸면 원인 추적이 불가능해집니다.
  8. 문제가 생기면 메인 공유기 DHCP를 하루 전 값으로 되돌릴 수 있는지 리허설해 둡니다.

A+B, B+C처럼 섞는 현실적인 해법

완전한 단일 선택보다 레이어링이 실제로는 흔합니다. 예를 들어 평소에는 NAS Docker가 코어를 띄우고, 장애 시에만 노트북에서 동일 프로필을 임시로 열어 Allow LAN으로 넘어가는 식입니다. 또는 메인은 OpenClash 우회가 담당하고, 개발자 PC만 TUN으로 이중 확인하는 구조도 있습니다. 중요한 것은 “어느 레이어가 최종 authority인지”를 문서에 한 줄이라도 적어 두는 일입니다. 그렇지 않으면 두 코어가 동시에 DNS를 말하는 이상한 상태로 빠집니다.

자주 묻는 질문

작은 아파트인데 굳이 우회 라우터가 필요할까요? 단말이 둘 셋이면 PC 허브로 충분한 경우가 많습니다. TV·콘솔·스마트 홈 허브까지 포함해 열 대가 넘어가면 DHCP 한 점으로 모으는 편이 규칙 추적이 쉽습니다.

NAS Docker가 더 전력 효율적일까요? 이미 NAS를 24시간 돌리고 있다면 한 컨테이너 추가분은 작습니다. 우회 전용 라우터를 새로 산다면 유휴 전력과 초기 비용을 비교표에 넣으세요.

가족 구성원이 실수로 프록시를 끄면? 토폴로지 B처럼 투명하게 만들면 클라이언트 설정 실수가 줄어듭니다. A에서만 쓸 때는 수동 프록시 프로필을 이름 짓기 규칙을 정해 혼선을 줄입니다.

주의: 프록시·우회 기능은 거주 지역 법령과 통신·스트리밍 서비스 약관을 준수하는 범위에서만 사용해야 합니다. 타인의 구독 자격을 무단으로 공유하지 마세요.

정리

Clash 토폴로지는 노드 품질 이전에 “코어를 어디 두느냐”의 문제입니다. 단일 PC는 시작과 실험에 가장 빠르고, 우회경로 OpenClash는 LAN 전체 자동화에 강하며, NAS Docker Mihomo는 이미 상시 서버가 있는 집과 작업실에서 운영 비용을 줄이는 선택지입니다. 이전할 때는 DHCP·DNS·로컬 예외를 세트로 움직이지 않으면 같은 YAML을 들고 가도 증상만 바뀝니다.

범용 VPN 앱이나 단순 브라우저 확장은 규칙·DNS·구독을 한 파일에서 설계하기 어렵고, 장비마다 따로 깔아야 할 때가 많아 가정 프록시나 소규모 작업실 네트워크처럼 여러 OS가 섞인 환경에서는 유지 부담이 커집니다. 반면 Mihomo·Clash 계열은 동일한 스플릿 개념을 데스크톱·우회 라우터·컨테이너까지 이어 붙일 수 있어 이전 비용을 낮추기 좋습니다. Clash 공식 사이트는 플랫폼별 설치 글과 함께 이런 아키텍처 선택을 한국어로 풀어 적어 두었고, 문서·클라이언트 포인터를 한곳에서 따라가며 다시 찾는 시간을 줄이는 데 초점을 맞추고 있습니다. 지금 환경에 맞는 클라이언트를 바로 깔아 보려면 Clash를 무료로 다운로드한 뒤, 위 토폴로지 중 하나를 골라 단계적으로 옮겨 보시기 바랍니다.