Clash 설정 완벽 가이드

핵심 개념: 연결은 어떤 과정을 거칠까

Clash는 앱의 연결을 받아 설정에 따라 아웃바운드 방식을 선택합니다. 일반적인 사용 환경은 GUI 클라이언트, 프록시 코어, 설정 파일, 원격 프록시 서버로 구성됩니다. 클라이언트를 설치했다고 해서 연결 가능한 원격 노드까지 확보된 것은 아닙니다. 각 구성 요소의 역할을 구분해야 설치, 구독, 규칙, 네트워크 중 어디에서 문제가 생겼는지 파악할 수 있습니다. 모든 연결 실패를 클라이언트 오류로 단정하지 마세요.

클라이언트는 조작을, 코어는 연결을 담당합니다

GUI 클라이언트는 구독 관리, 모드 전환, 로그 확인, 시스템 연동 기능을 제공합니다. 코어는 설정을 해석하고 DNS를 처리하며 규칙을 적용해 연결을 수립합니다. mihomo는 Clash 생태계에서 계속 발전하고 있는 코어이며, Clash Meta라는 이름은 그 발전 과정과 관련이 있습니다. 클라이언트마다 사용하는 코어와 구성 방식이 다를 수 있으므로, 화면의 메뉴 이름이 비슷하다고 해서 같은 설정 항목까지 지원하는 것은 아닙니다. 문제를 해결할 때는 클라이언트 이름과 코어 정보도 함께 기록하세요.

설정 파일에는 로컬 수신 포트, 노드, 프록시 그룹, 규칙, DNS 동작이 정의됩니다. 구독은 보통 설정이나 노드 정보를 가져오는 주소지만, 제공되는 내용은 서비스마다 다릅니다. 완전한 YAML을 제공하는 곳도 있고 노드 목록만 제공하는 곳도 있습니다. 클라이언트가 한 가지 형식을 가져올 수 있다고 해서 모든 형식을 자동으로 인식하는 것은 아닙니다. 파싱 오류가 발생하면 로컬 네트워크 설정을 반복해서 바꾸기보다 구독 제공자가 안내한 대상 형식부터 확인하세요.

앱에서 아웃바운드까지의 처리 과정

브라우저에서 웹페이지를 여는 상황을 예로 들면, 연결은 시스템 프록시 또는 TUN을 통해 코어에 전달됩니다. 코어는 규칙에 따라 직접 연결할지 특정 프록시 그룹으로 보낼지 판단하고, 프록시 그룹은 사용할 노드를 선택합니다. 마지막으로 선택된 노드가 대상 서비스에 연결합니다. DNS는 연결을 가로채는 방식과 설정에 따라 여러 단계에서 작동할 수 있습니다. 이 흐름을 이해하면 로그도 순서대로 확인할 수 있습니다. 연결이 코어에 들어왔는지, 어떤 규칙에 일치했는지, 마지막으로 어떤 아웃바운드가 선택됐는지 살펴보세요.

직접 연결은 현재 기기가 연결된 네트워크를 통해 대상에 접속한다는 뜻이지, 로컬에서 규칙을 확인하지 않는다는 뜻은 아닙니다. 프록시 연결은 지정된 아웃바운드로 연결을 전달한다는 뜻이며, 대상 웹사이트에 반드시 접속할 수 있다는 의미도 아닙니다. 원격 서버 장애, 계정 제한, 대상 서비스의 거부, 로컬 DNS 오류로 인해 프록시 경로에 들어온 연결이 실패할 수 있습니다. 지연 시간 테스트에 성공해도 특정 테스트 요청이 완료됐다는 뜻일 뿐, 실제 앱에서의 연결을 확인한 것은 아닙니다.

최소한의 연결 확인 절차 만들기

학습할 때는 클라이언트 하나, 활성화된 설정 하나, 수동 프록시 그룹 하나만 사용하세요. 프록시를 켜기 전 네트워크 상태를 기록한 다음 시스템 프록시를 켜고, 반복해서 테스트할 수 있는 페이지에 접속해 연결 목록에서 해당 도메인을 찾습니다. 연결과 아웃바운드가 확인되어야 로컬 트래픽이 정상적으로 전달된 것입니다. 여러 프록시 도구를 동시에 켜면 포트, 시스템 프록시 설정 또는 기본 경로를 두고 충돌해 결과를 파악하기 어려워질 수 있습니다.

이후 단계에서도 같은 연결 확인 절차를 사용합니다. 연결이 보이지 않으면 진입 설정을 확인하고, 연결은 보이지만 정책이 잘못 선택됐다면 모드와 규칙을 점검하세요. 정책은 맞는데 요청이 실패하면 노드와 대상 네트워크를 확인합니다. 모든 설정을 하나씩 바꿔 보는 것보다 이 순서대로 확인해야 유효한 단서를 보존하고 정상 설정을 잘못 변경할 가능성을 줄일 수 있습니다.

클라이언트 선택: 플랫폼과 설정 요구 사항부터 확인

처음 사용한다면 Clash Plus로 시작해 설치, 구독, 연결 확인까지 마친 다음 다른 인터페이스나 관리 방식도 살펴보세요. 클라이언트를 고를 때는 이름보다 기기의 운영체제와 프로세서 아키텍처, 설정 형식, 필요한 시스템 연동 기능이 더 중요합니다. 플랫폼별 설치 파일과 선택지는 다운로드 페이지에서 확인하고, 클라이언트별 차이를 비교하려면 클라이언트 비교도 참고하세요.

기기에 따라 선택 범위 좁히기

Windows에서는 Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu를 사용할 수 있으며, 기존 환경에는 Clash for Windows가 남아 있을 수 있습니다. macOS에서는 Clash Plus, Clash Verge Rev, FlClash 또는 아카이브된 ClashX Meta를 선택할 수 있습니다. Android에서는 Clash Plus, Clash Meta for Android, FlClash, Surfboard를 사용할 수 있습니다. iOS는 먼저 Clash Plus의 앱 스토어 링크를 확인하세요. Linux에서는 배포판에 맞는 패키지를 제공하는 Clash Verge Rev 또는 FlClash를 선택하면 됩니다.

Clash for Windows와 ClashX Meta는 더 이상 유지 관리되지 않습니다. 이전 설정을 살펴보거나 기존 환경을 관리하는 용도로는 활용할 수 있지만, 새 기기에 설치할 클라이언트로는 권장하지 않습니다. 아카이브된 클라이언트는 최신 프로토콜이나 시스템 호환성 수정, 설정 확장을 지원하지 않을 수 있습니다. 기존 사용자가 이전할 때는 구독 출처와 사용자 규칙을 먼저 백업하고 새 클라이언트에 별도로 가져와 테스트하세요. 기존 폴더를 바로 덮어쓰지 말고 새 환경에서 연결이 확인된 뒤 이전 프로그램을 제거하세요.

아키텍처와 설치 패키지를 정확히 선택하세요

프로세서 아키텍처에 따라 설치 파일의 실행 가능 여부가 달라집니다. Windows에서는 시스템 정보에서 시스템 종류를 확인하고, macOS에서는 ‘이 Mac에 관하여’에서 칩 또는 프로세서를 확인하세요. Android는 기기가 지원하는 ABI에 맞는 파일을 선택해야 합니다. Linux는 AMD64와 ARM64뿐 아니라 패키지 형식도 확인해야 합니다. 같은 운영체제용으로 여러 패키지가 제공될 수 있으므로 파일 크기만 보고 판단하지 마세요. 다운로드 페이지에 해당 아키텍처용 파일이 없다면 다른 아키텍처의 패키지를 억지로 사용하지 마세요.

Clash 설정을 지원한다고 해서 모든 항목이 호환되는 것은 아닙니다. 규칙 제공자, 일부 DNS 옵션, 프로토콜 매개변수 등은 해당 코어의 지원이 필요하며 GUI가 일부 항목을 다시 쓸 수도 있습니다. Surfboard는 별도의 설정 사용 방식을 따릅니다. 가져오기 전에 지원 형식을 확인하고 완전한 Clash YAML을 그대로 사용할 수 있다고 가정하지 마세요. 클라이언트를 바꾼 뒤 파싱에 실패하면 구독 손상부터 의심하기보다 형식과 기능 지원 여부를 먼저 비교하세요.

같은 조건으로 클라이언트 이전 결과 비교하기

클라이언트 두 개를 비교할 때는 기기, 네트워크, 구독, 노드, 테스트 대상을 동일하게 유지하고 네트워크 트래픽을 가로채는 프로그램은 한 번에 하나만 실행하세요. 먼저 같은 노드로 연결되는지 확인한 뒤 필요한 기능이 작동하는지 살펴봅니다. 한 번 측정한 지연 시간만으로 우열을 판단하지 마세요. 테스트 URL, 시간 제한, 연결 재사용 여부, 당시의 네트워크 상태가 다를 수 있습니다. 실제 사용 경험에는 연결 안정성, 규칙의 이해도, 유지 관리 비용이 더 큰 영향을 줍니다.

서버, 라우터 또는 직접 프로세스를 관리해야 하는 환경에서는 Mihomo 코어를 직접 실행할 수 있습니다. 다만 서비스 관리와 권한 설정, 제어 인터페이스 보호도 직접 맡아야 합니다. 일반 데스크톱 사용자는 상태를 쉽게 확인할 수 있는 GUI 클라이언트부터 사용하는 편이 좋습니다. iOS 사용자는 다운로드 페이지에서 Clash Plus를 확인하고 공식 웹사이트 clashplus.io에서 제품 정보를 살펴보세요. 설치 후에도 설정 가져오기와 연결 권한 승인이 필요합니다.

설치 및 확인: 로컬 연결 경로부터 정상화하기

설치 단계의 목표는 클라이언트가 실행되고 코어가 작동하며 로컬 포트에서 연결을 수신하는 것입니다. 처음부터 모든 네트워크 기능을 켤 필요는 없습니다. 다운로드 페이지에서 운영체제와 아키텍처에 맞는 파일을 선택하고 설치한 뒤 기본 설정을 유지하세요. 다른 프록시 도구는 잠시 꺼 두는 것이 좋습니다. 처음 실행하면 프로그램의 데이터 디렉터리, 현재 혼합 포트, 로그 위치를 기록하세요. 설정 가져오기, 포트 충돌 해결, 백업 이전 과정에서 반복해서 확인하게 됩니다.

데스크톱 플랫폼 설치 순서

Windows에서는 프로그램을 설치하고 실행한 뒤, 메인 화면에 코어 실행 실패 메시지가 없는지 확인하고 구독을 가져오세요. 네트워크 접근 권한을 요청하면 실제 사용 범위에 맞는 네트워크 유형을 선택합니다. 다른 기기와 공유할 필요가 없다면 프록시 접근을 허용하지 않아도 됩니다. 휴대용 디렉터리에 설치하는 경우 현재 계정이 설정과 로그를 저장할 수 있는지 확인하세요. 읽기 전용 디렉터리에 설치하면 설정이 저장되지 않거나, 재시작 후 구독이 사라지거나 업데이트에 실패할 수 있습니다.

macOS에서는 설치 파일 형식에 맞게 앱을 적절한 위치에 넣고 처음 실행하세요. 시스템이 실행을 차단하면 다운로드 출처와 시스템 안내를 먼저 확인하고, 보안 기능을 일괄 해제해 해결하려고 하지 마세요. TUN이나 백그라운드 서비스에 추가 권한이 필요하다면 기본 연결을 확인한 다음 처리하세요. Linux에서는 배포판에 맞는 패키지를 사용하고 설치 중 종속성 오류에 유의하세요. GUI는 실행되지만 코어가 바로 종료된다면 로그에서 권한 문제나 설정 오류를 확인해야 할 수 있습니다.

모바일 플랫폼은 연결 권한부터 확인하세요

Android에서 로컬 VPN 인터페이스를 처음 만들면 시스템 권한 요청이 표시됩니다. 권한을 허용해야 해당 경로로 연결을 가로챌 수 있습니다. 시스템에서 VPN 서비스를 동시에 하나만 사용할 수 있는 경우가 많아 다른 VPN, 방화벽 또는 VPN 기반 필터링 앱과 충돌할 수 있습니다. iOS에 Clash Plus를 설치한 뒤 시스템 안내에 따라 연결 구성을 추가하고 권한을 허용하세요. 두 플랫폼 모두 앱을 열어 둔 상태에서 먼저 연결을 확인한 다음, 화면 잠금과 네트워크 전환, 백그라운드 실행이 연결에 미치는 영향을 살펴보세요.

모바일 기기에 VPN 아이콘이 표시된다고 해서 원격 노드 연결까지 성공한 것은 아닙니다. 이는 시스템의 네트워크 확장 기능이나 인터페이스가 작동 중이라는 뜻일 뿐입니다. 노드에 연결할 수 없거나 구독이 활성화되지 않았거나 규칙 설정이 잘못되어도 아이콘은 표시될 수 있습니다. 실제 요청 결과와 클라이언트 연결 기록을 기준으로 확인하세요. Android에서 화면을 잠근 뒤 연결이 자주 끊기면 처음부터 여러 권한을 동시에 바꾸기보다 배터리 최적화, 백그라운드 활동 제한, 앱 자동 시작 설정을 차례로 확인하세요.

포트 점유와 실행 실패 확인하기

혼합 포트는 일반적으로 HTTP와 SOCKS 프록시 요청을 모두 받습니다. 구체적인 포트 번호는 클라이언트의 현재 설정을 확인하세요. 예시의 7890이 모든 기기에서 고정으로 사용되는 것은 아닙니다. 로그에 수신 주소가 이미 사용 중이라고 나오면 다른 프록시 프로그램을 종료한 뒤 이전 코어 프로세스가 남아 있는지 확인하세요. 사용 중이지 않은 포트로 변경할 수도 있지만, 프록시를 직접 설정한 브라우저, 터미널, 개발 도구의 포트도 함께 바꿔야 합니다. 클라이언트만 변경해서는 안 됩니다.

# Windows PowerShell: 로컬 포트 수신 상태 확인
Get-NetTCPConnection -LocalPort 7890 -State Listen

# macOS / Linux: 해당 TCP 포트를 수신하는 프로세스 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

이 명령은 상태를 확인할 뿐 충돌을 자동으로 해결하지 않습니다. 포트가 수신 대기 중이 아니라면 코어가 실행됐는지, 설정 파싱에 성공했는지 확인하세요. 포트가 수신 대기 중이라면 어떤 프로세스가 사용 중인지 확인해 다른 서비스를 Clash로 오인하지 않도록 합니다. 터미널에서 명령을 사용할 수 없다면 운영체제의 네트워크 또는 프로세스 관리 도구로 같은 내용을 확인할 수 있습니다. 예시를 실행하기 위해 관련 없는 소프트웨어를 설치할 필요는 없습니다.

설치 확인을 마치면 로그 위치를 찾을 수 있고, 코어 상태를 확인하며, 로컬 프록시 포트를 알고 있어야 합니다. 다음은 TUN을 먼저 켜는 대신 구독을 가져오는 단계입니다. Windows 방화벽, 자동 시작, 서비스 모드 설정은 Windows 설치 및 설정 전체 가이드에서, 첫 실행 시 여러 플랫폼에서 확인할 항목은 초기 설정 체크리스트에서 살펴볼 수 있습니다.

구독 가져오기: 다운로드, 파싱, 활성화 구분하기

구독을 제대로 가져오려면 서로 다른 세 단계가 필요합니다. 클라이언트가 콘텐츠를 다운로드하고, 코어가 콘텐츠를 파싱하며, 현재 실행 환경이 해당 설정을 사용해야 합니다. 목록에 구독 이름이 보이는 것만으로는 설정 항목이 추가됐다는 사실만 알 수 있을 뿐, 실제로 활성화됐다는 뜻은 아닙니다. 사용할 수 있는 원본 구독은 따로 보관하고 로컬 오버라이드를 단계적으로 추가하세요. 구독 주소에는 계정 접근 정보가 포함되는 경우가 많으므로 비밀번호처럼 안전하게 보관하고 공개 스크린샷이나 문의 글에 올리지 마세요.

가져오기부터 실제 적용까지

클라이언트에서 구독, 설정 또는 설정 파일 화면을 열고 링크 가져오기를 선택한 다음 전체 주소를 붙여 넣고 저장하세요. 주소 앞뒤의 공백과 줄바꿈, 메신저가 덧붙인 문장 부호 때문에 요청이 실패할 수 있습니다. 가져온 뒤 업데이트를 실행하고 다운로드 결과와 파싱 메시지를 확인하세요. 그런 다음 설정 목록에서 해당 항목을 현재 설정으로 선택합니다. 클라이언트마다 버튼 이름은 ‘활성화’, ‘사용’, ‘적용’ 등으로 다를 수 있습니다. 현재 설정 표시와 노드 목록이 함께 바뀌는지 확인하세요.

로컬 파일 가져오기는 링크 구독과 다릅니다. 파일은 가져온 시점의 콘텐츠 사본이므로 원격 노드 변경 사항을 자동으로 가져오지 않는 경우가 많습니다. 링크 구독은 업데이트할 때 원격 콘텐츠를 다시 가져올 수 있습니다. 압축 파일, 웹페이지 또는 로그인 페이지를 YAML로 바로 가져와서는 안 됩니다. 확장자만 보고 콘텐츠가 올바르다고 판단하지 마세요. 응답 상태가 정상인 웹페이지여도 파서에서 필수 항목이 없거나 예상하지 못한 문자가 있다는 오류가 발생할 수 있습니다.

실패한 단계에 따라 원인 찾기

다운로드 실패 시 오류 유형부터 확인하세요. 시간 초과는 현재 네트워크와 구독 서버 사이의 연결 문제일 수 있습니다. 인증서 오류라면 기기 시간과 요청 경로를 확인하세요. 인증 실패는 구독 주소가 만료됐거나 계정 상태가 바뀌었다는 뜻일 수 있습니다. 파싱에 실패하면 대상 형식, 들여쓰기, 코어 지원 여부를 확인하세요. 콘텐츠를 다운로드해 파싱한 뒤에야 프록시 그룹과 노드를 점검할 수 있습니다. 모든 구독 문제를 노드 연결 불가로 취급하지 마세요.

일부 네트워크에서는 구독 서버에 접속하려면 기존 프록시가 필요한데 새 기기에는 사용할 수 있는 프록시가 없어 시작 단계에서 막힐 수 있습니다. 구독 제공자가 지원하는 접근 경로를 이용하거나 이전에 저장한 유효한 설정을 가져온 뒤 업데이트 요청의 프록시 설정을 검토하세요. 계정 정보가 포함된 주소를 알 수 없는 온라인 변환 서비스에 전달하지 마세요. 서비스 운영자는 원본 링크와 응답 내용을 볼 수 있으므로 설정 형식 변경 외의 위험도 있습니다.

개인 수정 사항을 원격 콘텐츠와 분리해 관리하기

원격 구독을 업데이트하면 설정 파일이 다시 만들어질 수 있어 규칙, 포트, 그룹 이름을 직접 수정하면 덮어써질 수 있습니다. 클라이언트의 오버라이드, 병합 또는 확장 설정 기능을 우선 사용하고 구독 업데이트 이후 적용되는지 확인하세요. 병합 방식은 클라이언트마다 다르므로 목록 항목을 추가하는지 교체하는지 특히 주의해야 합니다. 먼저 명확한 테스트 규칙 하나를 추가해 동작을 확인한 다음 개인 라우팅 설정 전체로 범위를 넓히세요.

구독에 있는 프록시 그룹 이름은 설정에서 일치해야 합니다. 로컬 규칙이 제공자에 의해 삭제되거나 이름이 바뀐 그룹을 가리키면 설정을 불러오지 못할 수 있습니다. 업데이트 후 그룹이 여전히 있는지, 수동 선택이 유지됐는지, 노드 이름이 바뀌었는지 확인하세요. 화면에 남은 이전 캐시만으로 결과를 판단하지 마세요. 필요한 경우 설정을 다시 불러와 코어가 실제로 적용한 내용을 확인하되, 먼저 현재 작동 중인 상태를 저장하세요.

구독이 정상적으로 업데이트되지만 접속이 되지 않는다면 프록시 모드 장으로 넘어가세요. 자주 발생하는 오류는 자주 묻는 질문에서 확인할 수 있습니다. 문의할 때는 오류 유형과 클라이언트 이름, 민감 정보를 제거한 설정 구조만 제공하고 전체 구독 주소는 공개하지 마세요.

프록시 모드: 트래픽 진입 경로와 아웃바운드 선택 구분하기

규칙, 전역, 직접 연결 모드는 코어에 들어온 연결을 어떻게 보낼지 결정합니다. 시스템 프록시와 TUN은 앱의 연결을 코어로 보낼지 결정합니다. 서로 다른 두 가지 설정입니다. 전역 모드를 켜도 시스템 프록시를 무시하는 앱의 연결까지 자동으로 가로채지는 않습니다. 시스템 프록시를 꺼도 TUN이 이미 가로채고 있는 연결은 계속될 수 있습니다. 모드를 바꿨는데 앱 동작이 달라지지 않는다면 노드를 계속 바꾸기 전에 해당 앱이 어떤 진입 경로를 사용하는지 확인하세요.

일상적인 사용에는 규칙 모드가 적합합니다

규칙 모드는 설정에 있는 규칙을 순서대로 적용해 각 연결의 정책을 선택합니다. 연결에 따라 직접 연결할 수도 있고 프록시 그룹을 거칠 수도 있으며, 결과는 도메인, 주소, 프로세스 등의 일치 조건에 따라 달라집니다. 일상적으로 사용하기 좋지만 규칙이 완전하고 그룹 이름이 유효해야 합니다. 처음 테스트할 때는 수동 프록시 그룹에서 연결 가능한 노드를 선택한 뒤 대상 도메인이 어떤 규칙에 일치하는지 확인하세요. 규칙에서 잘못된 아웃바운드를 선택한 문제를 노드 오류로 오해하지 않도록 합니다.

전역 모드는 코어에 들어온 연결을 전역 정책으로 보내지만, 해당 정책에서 사용할 노드나 그룹을 선택해야 합니다. 규칙을 잠시 배제하고 확인할 때 유용합니다. 규칙 모드에서는 실패했지만 전역 모드에서는 같은 대상에 접속할 수 있다면 분기 결과를 집중적으로 확인하세요. 단, 앱의 연결이 실제로 코어에 들어오는지 확인하고 전역 정책이 기존 프록시 정책과 같은 노드를 선택하는지 확인해야 합니다. 두 가지 조건을 동시에 바꾸면 비교 결과를 신뢰하기 어렵습니다.

직접 연결 모드는 코어에 들어온 연결을 직접 아웃바운드로 보냅니다. 기본 네트워크 상태를 확인할 때 유용합니다. 클라이언트를 종료한다는 뜻은 아니며 로컬 수신 포트나 가상 인터페이스가 꺼진다는 뜻도 아닙니다. 클라이언트가 시스템 네트워크에 미치는 영향을 완전히 되돌리려면 TUN을 끄고 시스템 프록시를 해제한 뒤 프로그램을 정상 종료하세요. 직접 연결 모드로만 바꿔서는 시스템 프록시 설정이 완전히 정리됐는지 확인할 수 없습니다.

프록시를 명시해 비교 테스트하기

터미널 도구는 데스크톱의 시스템 프록시를 항상 따르지 않으며, 브라우저 확장 프로그램이 시스템 설정을 덮어쓸 수도 있습니다. 로컬 진입 경로를 확인하려면 단일 명령에서 혼합 포트를 명시적으로 사용하세요. 이렇게 하면 시스템 프록시를 따르는 동작과 코어의 아웃바운드 처리를 분리해 확인할 수 있습니다. 아래 명령은 혼합 포트가 7890이라고 가정합니다. 포트를 변경했다면 명령도 함께 수정하세요. Windows PowerShell에서는 실행 파일 이름을 명시해 명령 별칭과 혼동하지 않도록 합니다.

# Windows PowerShell
curl.exe --proxy http://127.0.0.1:7890 -I https://example.com

# macOS / Linux
curl --proxy http://127.0.0.1:7890 -I https://example.com

응답이 반환되면 이번 요청이 지정한 경로를 통과했다는 뜻이지만 다른 앱도 같은 경로를 사용한다는 뜻은 아닙니다. 테스트 중에는 연결 목록을 열어 요청 도메인, 규칙, 아웃바운드를 확인하세요. 로컬 포트에 연결할 수 없다는 메시지가 바로 나오면 설치 장으로 돌아가 수신 상태를 확인합니다. 로컬 포트에는 연결됐지만 원격 연결이 시간 초과되면 노드를 확인하세요. 테스트 대상 자체에 제한이 있을 수 있으므로 필요하면 정상 작동을 확인한 다른 대상으로 반복하세요.

모드를 바꾼 뒤 연결을 새로 만들어 확인하세요

모드 전환은 보통 새 연결부터 적용되며, 이미 연결된 장시간 연결은 기존 아웃바운드를 계속 사용할 수 있습니다. 설정 적용 여부를 확인할 때는 페이지를 새로고침하거나 해당 연결을 끊거나 테스트 앱을 재시작하세요. 기존 연결을 재사용한 결과를 설정이 적용되지 않은 것으로 오해하지 마세요. 동영상, 메신저, 브라우저의 연결 풀은 변경된 결과가 늦게 나타나기 쉽습니다. 모든 연결을 닫으면 진행 중인 전송이 중단되므로 중단해도 괜찮을 때 실행하세요.

규칙 기반 라우팅: 일치 순서부터 프록시 그룹까지

규칙 기반 라우팅은 위에서 아래로 일치 항목을 찾으며, 일반적으로 먼저 일치한 규칙이 아웃바운드를 결정합니다. 규칙을 작성하기 전에 세 가지를 정리하세요. 어떤 연결을 찾을지, 일치한 연결을 어디로 보낼지, 어떤 규칙보다 먼저 적용해야 할지입니다. 규칙의 개수는 품질을 나타내지 않습니다. 명확한 순서와 안정적인 프록시 그룹 참조가 더 중요합니다. 인라인 규칙부터 익힌 다음 외부 규칙 세트를 사용하세요. 추적하기 어려운 조건을 한 번에 많이 추가하지 않는 편이 좋습니다.

자주 쓰이는 일치 유형 세 가지

DOMAIN은 도메인을 정확히 일치시키고, DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인을 일치시킵니다. IP-CIDR은 주소 범위를 일치시킵니다. MATCH는 마지막에 적용하는 기본 규칙이므로 이후 규칙보다 앞에 두면 안 됩니다. 도메인 규칙이 작동하려면 코어가 대상 도메인을 알아야 합니다. 앱이 IP 주소로 직접 연결하면 일부 도메인 조건이 일치하지 않을 수 있으므로 실제 연결 정보를 확인하세요.

프록시 그룹은 규칙 자체가 아니라 규칙에서 참조하는 아웃바운드 선택기입니다. 수동 선택 그룹은 직접 선택하거나 출구를 고정할 때 적합합니다. 자동 테스트 그룹은 지정한 테스트 대상의 결과를 바탕으로 노드를 선택하며, 페일오버 그룹은 사용 가능 여부와 후보 순서를 중심으로 동작합니다. 제공되는 기능은 코어 지원 여부에 따라 달라집니다. 자동 테스트 결과는 테스트 대상에서의 결과일 뿐이며 모든 웹사이트, 지역 서비스, 장시간 전송에서 같은 성능을 보장하지 않습니다.

# 규칙 예시: 기존 설정에 병합하세요. 완전한 구독 설정이 아닙니다
# DIRECT는 기본 제공되는 직접 연결 아웃바운드입니다
rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.net,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,DIRECT

이 예시는 순서와 문법을 보여 주기 위해 모든 아웃바운드를 기본 제공되는 직접 연결로 설정했습니다. 노드가 없는 환경에서도 규칙 구조를 이해할 수 있습니다. 실제로 프록시를 사용하려면 해당 아웃바운드를 현재 설정에 실제로 존재하는 프록시 그룹 이름으로 바꾸세요. 가이드에 나온 예시 그룹 이름을 그대로 사용하지 마세요. 마지막 기본 연결도 모든 환경에 적합한 것은 아닙니다. 일치하지 않은 연결을 기본적으로 프록시로 보내려면 정상 작동을 확인한 프록시 그룹을 지정하고, 변경 범위에 포함되는 트래픽을 검토하세요.

no-resolve와 DNS의 관계

주소 규칙의 no-resolve는 해당 주소 규칙을 적용하기 위해 도메인을 IP로 변환하지 않도록 하는 옵션입니다. 모든 DNS 요청을 차단한다는 뜻도 아니며 이미 알고 있는 대상 IP에 규칙을 적용하지 않는다는 뜻도 아닙니다. 사설 네트워크 대역 규칙에 사용하면 해당 대역인지 확인하기 위한 추가 DNS 조회를 줄일 수 있습니다. 대상의 조회 결과에 따라 라우팅하려면 DNS 설정을 함께 고려해 해석 과정을 유지할지 판단하세요. 모든 주소 규칙에 같은 옵션을 일괄적으로 추가하지 마세요.

DNS 응답은 주소 규칙과 실제 연결 대상에 영향을 주지만, 도메인 규칙에 대상 주소를 미리 조회하는 과정이 항상 필요한 것은 아닙니다. fake-ip 모드에서는 도메인과 연결의 매핑을 유지하기 위한 가상 IP가 사용됩니다. 이 주소는 원격 서버의 실제 주소가 아니므로 가상 주소가 보인다고 해서 곧바로 DNS 변조라고 판단하지 마세요. 코어가 인식한 도메인과 일치한 규칙, 최종 아웃바운드를 확인한 뒤 DNS를 조정하거나 특정 앱을 제외할지 판단하세요.

규칙을 수정한 뒤 일치 여부 확인하기

현재 설정을 먼저 백업한 뒤 로컬 오버라이드에 대상이 명확한 규칙 하나만 추가하세요. 설정을 다시 불러온 다음 해당 도메인에 접속해 연결 상세 정보에서 실제로 일치한 규칙을 확인합니다. 규칙에 일치하지 않으면 앞에 있는 포괄적인 규칙, 앱의 기존 연결 재사용 여부, 오버라이드가 실행 설정에 적용됐는지 확인하세요. 설정을 불러오지 못하면 들여쓰기와 쉼표, 그룹 이름부터 살펴보세요. 정상 작동하는 이전 설정을 복구한 다음 항목별로 수정합니다.

규칙 세트는 많은 유사 도메인을 한곳에서 관리하는 데 유용하지만 제공자의 형식, 동작 유형, 업데이트 주기, 로컬 캐시 경로를 확인해야 합니다. 다운로드에 실패했을 때 사용할 캐시가 있는지에 따라 설정의 정상 작동 여부가 달라질 수 있습니다. 용도가 겹치거나 출처가 불분명한 여러 규칙 세트를 함께 적용하면 같은 도메인을 서로 다른 조건이 먼저 처리할 수 있습니다. 먼저 분류 기준을 정한 뒤 해당 기준에 맞는 규칙 콘텐츠를 선택하세요.

더 자세한 일치 순서, 도메인 접미사 범위, 기본 규칙 작성법은 Clash 사용자 규칙과 우선순위 상세 가이드를 참고하세요. 개인 규칙을 관리하기 시작할 때 수정 목적과 테스트 대상을 기록해 두면 이후 이전 작업이 쉬워집니다.

TUN 모드: 트래픽 가로채기 범위 확대와 DNS 처리

TUN은 가상 네트워크 인터페이스를 통해 연결을 받아 시스템 프록시를 따르지 않는 앱을 처리할 수 있습니다. 하지만 모든 문제를 해결하는 만능 스위치는 아닙니다. 켜기 전에 기본 시스템 프록시 경로가 정상 작동하는지 확인하세요. 그렇지 않으면 트래픽 가로채기 범위가 넓어져 제한된 설정 오류가 기기 전체의 접속 문제로 번질 수 있습니다. TUN 인터페이스 생성, 경로 가로채기, DNS 가로채기는 서로 다른 상태이며 항상 동시에 작동하는 것은 아닙니다.

권한과 충돌 가능성부터 확인하세요

데스크톱에서는 인터페이스를 만들고 경로를 수정하기 위해 서비스 모드, 보조 서비스 또는 권한 상승이 필요할 수 있습니다. 필요한 방식은 클라이언트마다 다르므로 화면에 표시된 서비스 상태를 읽고 필요한 권한만 승인하세요. 기기에서 회사 VPN, 가상 머신 네트워크, 컨테이너 네트워크 또는 다른 프록시를 사용하고 있다면 현재 상태를 기록하세요. 두 도구가 모두 기본 경로나 DNS를 변경하면 루프, 경로 선점, 일부 네트워크 접속 불가가 발생할 수 있습니다. 테스트할 때는 네트워크 환경을 최대한 단순하게 유지하세요.

모바일 플랫폼에서는 시스템 VPN 또는 네트워크 확장 기능으로 트래픽을 가로채므로 데스크톱과 같은 TUN 설정이 화면에 표시되지 않을 수 있습니다. 데스크톱 YAML의 모든 네트워크 옵션을 휴대폰에 그대로 복사하지 마세요. 시스템 제한, 클라이언트 구현, 설정 오버라이드 방식이 다를 수 있습니다. 같은 구독을 사용하더라도 Wi-Fi, 모바일 네트워크, 화면 잠금, 네트워크 전환 후의 연결을 각각 확인하세요.

자주 쓰는 매개변수의 역할 이해하기

# mihomo TUN 설정 예시: 기존 설정에 병합해야 합니다
# 먼저 클라이언트에서 같은 설정을 이미 생성했는지 확인하세요
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

enable은 인터페이스를 켜고, stack은 네트워크 스택을 선택합니다. auto-route는 코어가 플랫폼 기능에 따라 경로를 설정하도록 하며, auto-detect-interface는 아웃바운드 인터페이스를 자동으로 식별합니다. 이 예시는 완전한 설정이 아니며 모든 환경에 같은 조합이 적합하다는 뜻도 아닙니다. 클라이언트 화면에서 이미 해당 항목을 관리한다면 설정 파일과 화면 설정이 서로 덮어쓰지 않도록 클라이언트의 병합 방식을 따르세요.

dns-hijack는 지정된 DNS 트래픽을 가로채지만 앱에 내장된 모든 암호화 DNS 방식을 자동으로 처리하지는 않습니다. 브라우저의 보안 DNS, 앱 자체 DNS 조회, 하드코딩된 IP, 시스템 캐시가 테스트 결과에 영향을 줄 수 있습니다. 켠 뒤에는 일반 웹페이지뿐 아니라 로컬 네트워크 이름과 필요한 앱도 확인하세요. 웹사이트 하나가 열린다는 이유만으로 모든 DNS 경로가 예상대로 작동한다고 판단하지 마세요.

문제가 생겨도 복구할 수 있는 순서로 켜기

현재 정상 작동하는 설정을 저장하고 클라이언트를 종료하는 방법을 확인한 뒤 화면에서 TUN을 켜세요. 먼저 코어 로그에서 인터페이스 생성이 성공했는지 확인하고 일반 웹사이트와 로컬 네트워크 리소스에 접속한 다음 연결 기록을 살펴봅니다. 로컬 프린터, 라우터 관리 페이지 또는 사내 주소에 문제가 생기면 해당 네트워크 대역의 경로와 직접 연결 규칙을 확인하세요. 경로 제외와 규칙 직접 연결은 서로 다른 단계이므로 도메인 규칙을 추가해 모든 라우팅 문제를 해결할 수는 없습니다.

기기 전체에서 네트워크가 끊기면 먼저 TUN을 끄고 클라이언트는 실행 상태로 둔 채 기본 시스템 프록시 경로가 복구되는지 확인하세요. 연결이 복구되면 두 진입 경로를 비교한 뒤 서비스 상태, 기본 인터페이스, DNS, 다른 VPN을 점검합니다. 연결이 끊긴 상태에서 네트워크 스택, DNS, 규칙, 노드를 동시에 변경하지 마세요. 문제가 해결돼도 원인을 알 수 없게 됩니다. 원격 서버를 관리하는 경우 기본 경로를 바꾼 뒤 접속을 잃지 않도록 별도의 접속 경로를 유지하세요.

UDP를 사용하는 앱은 별도로 확인해야 합니다. 웹페이지 접속은 일부 TCP 요청이 정상이라는 뜻일 뿐 실시간 통신, 게임, 특정 UDP 프로토콜이 작동한다는 뜻은 아닙니다. 노드 지원 여부, 서버 측 정책, 현재 네트워크, 클라이언트 설정을 모두 확인하세요. 네트워크 스택을 바로 바꾸지 말고 해당 연결의 로그와 오류를 먼저 찾은 뒤 아웃바운드나 트래픽 처리 방식을 조정할지 판단하세요.

시스템 시간, 패킷 캡처 도구, DNS 경로로 인해 발생하는 인증서 문제는 Clash를 켠 뒤 웹페이지에서 인증서 오류가 표시될 때 확인할 순서를 참고하세요. 확인을 마친 뒤 실제로 필요한 트래픽 처리 방식만 유지하세요.

유지 관리: 업데이트, 백업, 복원

안정적인 사용의 핵심은 모든 변경 사항을 추적하고 되돌릴 수 있게 관리하는 것입니다. 클라이언트 업데이트, 코어 업데이트, 구독 업데이트, 개인 규칙 수정은 서로 다른 작업이므로 동시에 진행하지 마세요. 현재 정상 작동하는 상태를 기록하고 한 번에 하나씩 변경한 뒤 같은 테스트를 반복하세요. 문제가 생겼을 때 여러 설정과 노드, 트래픽 처리 옵션을 오가며 시도하는 대신 명확한 이전 상태로 돌아갈 수 있습니다.

유용한 백업 항목

최소한 구독 출처, 현재 활성화된 설정, 개인 오버라이드 규칙, 프록시 그룹 선택, 주요 네트워크 설정을 저장하세요. 클라이언트 데이터 디렉터리에 접근 정보나 관리 인터페이스 정보가 들어 있을 수 있으므로 통제 가능한 위치에 백업하고 공개 저장소에 올리지 마세요. 기기를 옮기기 전에 내보낸 파일에 어떤 항목이 포함되는지 확인하세요. 규칙만 내보내는 클라이언트도 있고 실행 디렉터리 전체를 내보내는 클라이언트도 있어 개인정보 노출과 복원 가능성이 다릅니다.

구독 원본과 개인 규칙은 따로 저장하는 것이 좋습니다. 구독 원본은 원격에서 다시 업데이트할 수 있지만 개인 규칙은 현재 기기에만 있을 수 있습니다. 포트, 로컬 네트워크 연결 허용 여부, TUN 상태, 시작 시 자동 실행 설정도 기록하세요. 클라이언트 화면에서 저장한 설정은 내보낸 YAML에 포함되지 않을 수 있습니다. 복원 후 노드 이름만 확인하지 말고 시스템 프록시 주소, 수신 주소, 로컬 오버라이드가 실제로 적용됐는지도 확인하세요.

업데이트 전후에 같은 체크리스트 사용하기

업데이트 전에는 사용하는 플랫폼과 기능에 관련된 변경 사항을 확인하세요. 새 설치 파일이 나왔다는 이유만으로 모든 기기에 바로 설치할 필요는 없습니다. 업데이트 후에는 프로그램 실행, 코어 설정 파싱, 구독 로드, 규칙 일치, TUN 상태를 확인하고 프록시 대상 하나와 직접 연결 대상 하나를 테스트하세요. 새 환경이 불안정하다면 저장해 둔 설정과 옵션으로 복구하세요. 코어마다 캐시나 확장 설정 항목이 달라 이전 버전으로 단순히 되돌려 사용할 수 없을 수도 있습니다.

일상적인 지연 시간 테스트는 연결할 수 없는 노드를 찾는 데 유용하지만 구독 전체를 자주 새로고침해 가장 낮은 수치를 찾으려 해서는 안 됩니다. 동시 테스트가 많으면 네트워크 자원을 소모하고 서버 측 제한을 받을 수도 있습니다. 다운로드 속도, 첫 연결 시간, 장시간 연결 안정성은 서로 다른 지표입니다. 자주 사용하는 프록시 그룹에 검증된 대체 노드를 남겨 두세요. 이상이 생겼을 때 비교 기준으로 사용할 수 있어 테스트 결과에 따라 계속 전환하는 것보다 판단에 도움이 됩니다.

로그를 활용해 문제 해결 기록 남기기

평소에는 기본 로그 수준을 사용하고 문제를 재현하는 짧은 시간 동안만 상세 로그를 켜세요. 문제가 발생한 시각, 앱, 대상 도메인, 트래픽 진입 경로, 모드, 일치한 규칙, 오류 메시지를 기록합니다. 시간 초과, 연결 거부, 파싱 실패, 인증 실패는 서로 다른 단계의 문제입니다. 마지막 줄에 있는 ‘실패’만 잘라 적지 마세요. 로그를 복사하기 전에 구독 정보, 노드 주소, 내부 네트워크 주소, 로컬 경로가 포함됐는지 확인하고 필요한 부분을 익명화하세요.

환경 변화도 기록해야 합니다. 새 Wi-Fi에 연결하거나 회사 네트워크에 접속하고 보안 소프트웨어를 켜거나 가상 머신을 실행한 뒤에만 문제가 발생한다면 기본 경로, DNS, 방화벽 규칙이 바뀌었을 수 있습니다. 먼저 이전 네트워크에서 비교한 다음 클라이언트 설정을 바꿀지 판단하세요. 같은 네트워크에서 여러 기기에 동시에 문제가 발생하면 각 기기의 클라이언트를 다시 설치하기보다 공용 네트워크와 원격 서비스부터 확인하세요.

정상 종료 및 제거 전 확인

종료하기 전에 TUN과 시스템 프록시를 끈 다음 프로그램을 정상 종료하세요. 프로그램이 비정상적으로 종료된 뒤 브라우저에 연결 문제가 생기면 시스템 프록시가 이미 수신을 중단한 로컬 포트를 가리키고 있는지 확인하세요. 포트가 더 이상 작동하지 않는 것을 확인한 뒤 현재 네트워크에 맞게 남은 설정을 해제합니다. 출처를 알 수 없는 네트워크 초기화 스크립트를 바로 실행하지 마세요. 전체 초기화로 회사 프록시, 고정 IP 주소, 정상 작동하던 다른 네트워크 설정까지 지워질 수 있습니다.

고급 활용: 설정 사용에서 주도적인 유지 관리까지

고급 활용은 설정을 더 많이 켜는 것이 아니라, 설정 변경이 어디에 영향을 주는지 예상하고 기록을 통해 결과를 확인하는 것입니다. 앞선 8단계를 마쳤다면 설정 구조, 규칙 제공자, DNS, 실행 관리 순서로 익히는 것이 좋습니다. 한 번에 기능 하나만 추가해 복구 가능한 테스트 설정에서 확인한 뒤 일상 환경에 반영하세요. 분명한 용도가 없는 항목은 그대로 두는 편이 이른바 ‘최적화 설정’을 통째로 복사하는 것보다 안정적입니다.

먼저 설정의 종속 관계 파악하기

설정은 진입 경로, 아웃바운드, 프록시 그룹, 규칙, DNS가 서로 참조하는 구조로 볼 수 있습니다. 규칙은 프록시 그룹을 참조하고, 프록시 그룹은 노드나 다른 그룹을 참조합니다. 제공자는 외부 콘텐츠를 가져오며, 시스템 연동은 앱의 트래픽을 진입 경로로 전달합니다. 이름을 변경할 때는 참조 경로를 함께 확인하고 노드 출처를 삭제하기 전에 프록시 그룹에서 사용 중인지 살펴보세요. 설정 파싱에 성공하는 것은 첫 단계일 뿐입니다. 최종 아웃바운드가 원래 목적에 맞는지도 확인해야 합니다.

규칙 제공자를 익힐 때는 규모가 작고 내용을 알고 있는 규칙 모음부터 만든 뒤 형식과 동작 유형, 업데이트 결과를 확인하세요. 긴 외부 목록을 바로 연결해 설명하기 어려운 조합에 라우팅을 맡기지 마세요. 업데이트 주기도 적절하게 설정해야 합니다. 규칙 콘텐츠를 몇 초마다 다시 가져올 필요는 없으며, 지나치게 자주 새로고침하면 네트워크 의존성만 커집니다. 첫 실행 시 캐시가 없는 경우와 평소 업데이트가 실패했지만 캐시가 남아 있는 경우의 차이도 알아 두세요.

그다음 DNS와 연결 메타데이터 살펴보기

DNS를 공부할 때는 먼저 시스템 DNS 조회, 코어의 DNS 조회, 앱 자체 DNS 조회의 차이를 이해한 뒤 fake-ip 방식과 실제 주소를 반환하는 방식의 처리를 비교하세요. 매번 테스트할 때 요청 도메인, 조회 결과, 일치한 규칙, 아웃바운드 경로를 함께 기록합니다. 한 모드가 특정 앱의 문제를 해결하더라도 로컬 네트워크 검색이나 별도의 DNS 절차를 사용하는 앱에 영향을 줄 수 있습니다. 단일 웹사이트만 확인하지 말고 자주 쓰는 시나리오를 대상으로 회귀 테스트를 유지하세요.

트래픽 스니핑은 조건에 따라 도메인 정보를 보완할 수 있지만 모든 앱의 콘텐츠를 볼 수 있다는 뜻도, 모든 연결의 대상 정보를 올바르게 복원할 수 있다는 뜻도 아닙니다. 효과는 프로토콜, 암호화 방식, 앱 동작에 따라 달라집니다. 먼저 스니핑을 사용하지 않을 때 연결 정보가 어떻게 보이는지 파악한 다음 필요한 경우에만 활성화 여부를 검토하세요. 올바른 DNS 처리나 규칙 설계를 대신하는 기능으로 사용하지 마세요. 민감한 업무에 적용할 때는 해당 네트워크의 관리 정책도 따라야 합니다.

CLI 코어를 사용할 때 접근 경계 보호하기

코어를 직접 실행하는 방식은 서버와 라우터에 적합하지만 설정 경로, 작업 디렉터리, 프로세스 재시작, 로그 보관, 권한을 직접 관리해야 합니다. 먼저 포그라운드에서 설정을 확인한 뒤 시스템 서비스에 등록하세요. 아래 명령은 mihomo 실행 파일이 설치되어 있고 현재 디렉터리에 설정 파일이 있다고 가정합니다. 설정을 테스트하는 명령이며 프로그램을 다운로드하거나 설치하지 않고 모든 원격 노드의 연결 가능 여부도 확인하지 않습니다.

# 현재 설정의 문법과 로드 가능 여부 확인
mihomo -t -f ./config.yaml

# 지정한 설정을 포그라운드에서 실행
mihomo -f ./config.yaml

설정 테스트를 통과한 뒤에도 실제 실행 환경에서 규칙과 연결을 확인해야 합니다. 서비스와 대화형 터미널은 작업 디렉터리, 환경 변수, 사용자 권한이 다를 수 있어 포그라운드에서 실행된다고 서비스에서도 같은 파일을 찾을 수 있는 것은 아닙니다. 절대 경로와 명확한 데이터 디렉터리를 사용하면 혼동을 줄일 수 있습니다. 실제 배포 위치에 맞는 경로를 지정하고 다른 기기의 경로를 그대로 복사하지 마세요.

로컬 네트워크 연결을 허용하면 로컬 프록시 진입 경로에 접근할 수 있는 범위가 넓어지고, 외부 제어 인터페이스는 더 강력한 설정 관리 기능을 제공할 수 있습니다. 둘 다 인터넷에 무분별하게 노출해서는 안 됩니다. 공유나 관리가 꼭 필요한 경우에만 켜고 수신 주소와 네트워크 접근 범위를 제한하며 클라이언트에서 지원하는 인증 방식을 사용하세요. 휴대폰에서 관리 화면을 열기 위해 라우터 포트를 바로 외부에 공개하지 마세요. 먼저 접근 범위와 비활성화 방법을 확인한 뒤 설정하세요.

문제 해결 절차를 개인 가이드로 정리하기

자주 사용하는 환경에서 같은 테스트를 반복할 수 있도록 기본 직접 연결 대상, 프록시가 필요한 서비스, 로컬 네트워크 리소스, 터미널의 명시적 프록시, 필요한 UDP 앱을 정해 두세요. 설정을 변경한 뒤 각 항목을 다시 확인하고 느낌이 아닌 결과를 기록합니다. 문제가 생기면 진입 경로, DNS 조회, 규칙, 아웃바운드, 원격 서버의 다섯 단계로 범위를 좁히세요. 이렇게 쌓은 기록은 이후 기기 이전에 활용할 수 있으며 재현 가능한 문제를 다른 사람에게 설명하기도 쉬워집니다.

각 변경의 목적과 확인 결과, 이전 상태로 되돌리는 방법을 설명할 수 있다면 설정을 독립적으로 유지 관리할 기초를 갖춘 것입니다. 이후 기능을 선택할 때도 같은 원칙을 따르세요. 먼저 문제가 발생한 단계를 찾고 거기에 맞는 기능을 선택하되, 매개변수를 늘리기 위해 불필요한 복잡성을 추가하지 마세요.