네트워크 프록시 클라이언트를 처음 사용할 때 가장 어려운 부분은 설치보다 화면에 함께 표시되는 구독, 노드, 회선, 프로토콜, 시스템 프록시, TUN, 분할 라우팅, 전체 모드와 규칙 모드입니다. 각각 설정의 출처, 연결 진입점, 전송 방식과 트래픽 처리 전략을 뜻하며 서로 대신할 수 없습니다. 이 계층을 구분하면 노드 선택, 구독 가져오기와 연결 문제 해결이 훨씬 쉬워집니다.
핵심 용어 한눈에 보기: 각각 무엇을 제어할까요?
아래 표는 클라이언트 화면을 해석하는 안내서로 활용할 수 있습니다. 익숙하지 않은 설정을 만났다면 먼저 구성, 진입점, 전송, 라우팅 또는 시스템 제어 계층 중 어디에 속하는지 판단한 뒤 조정 여부를 결정하세요.
| 용어 | 실제 의미 | 흔한 오해 | 초보자가 확인할 점 |
|---|---|---|---|
| 구독 | 서비스 서버에서 관리하는 노드와 매개변수 묶음으로, 클라이언트가 구독 링크를 통해 가져오고 업데이트합니다 | 구독을 하나의 고정 노드로 생각하는 것 | 업데이트 성공 여부와 신뢰할 수 있는 출처인지 여부 |
| 노드 | 클라이언트에서 선택할 수 있는 연결 진입점으로, 일반적으로 서버 주소·포트·프로토콜·인증 정보가 포함됩니다 | 노드 이름이 완전한 네트워크 경로라고 생각하는 것 | 지역, 프로토콜, 회선 설명과 현재 연결 가능 상태 |
| 회선 | 로컬 환경에서 출구까지 데이터가 거치는 네트워크 경로와 전송 기반 | 회선과 프로토콜을 같은 개념으로 보는 것 | 직접 연결, 중계 또는 IEPL 전용 회선이 현재 네트워크에 적합한지 여부 |
| 프로토콜 | 클라이언트와 서버가 데이터를 주고받을 때 사용하는 캡슐화·인증·전송 규칙 | 프로토콜 이름만 보고 속도를 판단하는 것 | 클라이언트 호환성, 전송 계층과 로컬 네트워크 제한 |
| 분할 라우팅 | 도메인·IP·앱 또는 규칙 세트에 따라 요청을 프록시로 보낼지 직접 연결할지 결정하는 방식 | 분할 라우팅이 모든 사용 상황을 자동으로 인식한다고 생각하는 것 | 규칙 적중 여부와 DNS가 규칙과 일치하는지 여부 |
| 전체 모드 | 클라이언트가 제어하는 범위의 트래픽을 우선 선택한 노드에서 처리하는 방식 | 전체 모드가 기기의 모든 트래픽을 제어한다고 생각하는 것 | 시스템 프록시와 TUN의 제어 범위가 서로 다르다는 점 |
| 규칙 모드 | 규칙에 따라 요청마다 다른 출구를 선택하는 방식 | 규칙이 많을수록 반드시 더 정확하다고 생각하는 것 | 규칙 순서, 매칭 결과와 최종 기본 처리 정책 |
| 직접 연결 | 요청이 선택한 프록시 노드를 거치지 않고 현재 로컬 네트워크로 대상에 직접 접속하는 방식 | 직접 연결을 서버 직결 회선으로 이해하는 것 | 클라이언트의 동작과 서버 측 회선 라벨을 구분하기 |
표에서 ‘직접 연결’은 특히 혼동하기 쉽습니다. 클라이언트 규칙에서 직접 연결은 특정 요청이 프록시를 우회한다는 뜻입니다. 반면 노드 상세 정보의 직접 연결 회선은 일반적으로 로컬 네트워크가 해외 서버에 직접 연결되며 서비스 제공업체가 배치한 중계 접속 지점을 거치지 않는다는 의미입니다. 정확한 뜻을 판단하려면 어떤 화면의 어느 설정 계층에 표시되었는지 확인해야 합니다.
구독·노드·회선은 왜 서로 다를까요?
구독은 설정을 가져오는 입구이지 지속적인 전송 통로가 아닙니다
구독 링크는 일반적으로 클라이언트가 해석할 수 있는 설정 모음을 반환합니다. 이 모음에는 여러 노드와 그룹, 규칙 및 업데이트 정보가 포함될 수 있습니다. 클라이언트는 구독을 읽은 뒤 해석 결과를 로컬에 저장하며, 일상적인 접속 트래픽은 보통 ‘구독 링크’를 거치지 않고 선택한 노드에 직접 연결됩니다.
따라서 구독 업데이트 실패와 노드 연결 실패는 서로 다른 문제입니다. 전자는 링크 만료, 설정을 가져오지 못하는 네트워크 상태 또는 클라이언트의 형식 해석 문제와 관련될 수 있습니다. 후자는 노드 상태, 프로토콜 호환성, 시스템 시간, 로컬 UDP 환경 또는 라우팅 경로와 관련될 가능성이 큽니다. 구독을 잠시 새로 고치지 못했다고 해서 아직 사용할 수 있는 로컬 설정을 바로 삭제하지 마세요.
노드는 설정 객체이고 회선은 하위 경로입니다
노드에는 일반적으로 서버 주소, 연결 포트, 프로토콜 유형, 인증 매개변수, 전송 계층과 암호화 관련 설정이 기록됩니다. 클라이언트는 노드를 선택한 뒤 이 매개변수에 따라 연결을 구성합니다. 노드 이름의 지역·용도·회선 라벨은 식별을 돕는 설명일 뿐이며, 실제 연결 방식을 결정하는 것은 설정 필드입니다.
회선은 더 낮은 계층의 경로를 설명합니다. 직접 연결 회선은 로컬 통신사 네트워크에서 원격 진입점까지 바로 연결되므로 구조가 단순하지만 공용 네트워크 라우팅의 영향을 더 많이 받습니다. 중계 회선은 가까운 접속 지점에 먼저 연결한 뒤 서비스 제공업체의 네트워크를 통해 원격 출구로 전달하며, 변동이 큰 공용 네트워크 구간을 피하는 데 사용됩니다. IEPL은 국제 이더넷 전용 회선을 부르는 일반적인 명칭으로, 전송 경로와 네트워크 격리 방식에 초점을 둔 개념이며 프록시 프로토콜은 아닙니다.
구독 가져오기는 다음 순서로 진행하세요
- 서비스 패널에서 전체 구독 링크를 복사하고, 링크에 포함된 인증 매개변수를 직접 삭제하거나 수정하지 마세요.
- 클라이언트에서 ‘URL에서 가져오기’, ‘구독 추가’ 또는 비슷한 메뉴를 선택하세요. 링크를 단일 노드 주소 입력란에 붙여 넣으면 안 됩니다.
- 업데이트를 실행해 노드 목록이 표시되는지 확인한 다음, 대상 서비스가 있는 지역과 가까운 출구를 선택해 연결하세요.
- 클라이언트 로그나 연결 상세 정보에서 핸드셰이크가 완료되었는지 확인한 뒤, 브라우저로 출구 주소와 DNS 조회 결과를 점검하세요.
- 이후 노드 변경 사항을 동기화할 때는 ‘구독 업데이트’를 사용하고, 같은 내용의 구독 항목을 반복해서 만들지 마세요.
- ✅ 구독 이름, 노드 목록과 업데이트 시간이 정상적으로 표시됩니다
- ✅ 노드 프로토콜이 현재 클라이언트에서 지원되며 알 수 없는 필드가 나타나지 않습니다
- ✅ 연결 후 출구 주소가 예상대로 바뀌고 대상 웹사이트가 정상적으로 로드됩니다
- ❌ 구독 링크를 포럼, 스크린샷 또는 온라인 변환 페이지에 공개적으로 붙여 넣기
- ❌ 업데이트에 실패했을 때 같은 링크를 연속으로 가져와 중복 설정을 여러 개 남기기
프로토콜 이름은 어떻게 이해해야 할까요?
프로토콜은 클라이언트와 서버가 데이터를 인증·캡슐화·전송하는 방식을 정하지만, 프로토콜 이름 자체가 속도 순위를 의미하지는 않습니다. 같은 프로토콜도 회선, 로컬 통신사와 클라이언트 구현에 따라 성능이 크게 달라질 수 있습니다. 초보자는 서비스 서버가 제공하고 클라이언트가 완전히 지원하는 설정을 우선 사용하고, 이름만 보고 필드를 직접 바꾸지 않는 것이 좋습니다.
Shadowsocks
Shadowsocks는 가벼운 암호화 프록시 프로토콜로, 일반적인 구현에서는 사전 공유 키와 지정된 암호화 방식을 사용해 클라이언트와 서버 사이의 데이터를 보호합니다. 설정이 비교적 간단하고 호환되는 클라이언트가 많습니다. 다만 Shadowsocks는 프록시 전송을 담당할 뿐, 전통적인 의미에서 시스템 전체 네트워크를 제어하는 VPN과 같지는 않습니다. 모든 앱에 적용되는지는 클라이언트에서 시스템 프록시, VPN 인터페이스 또는 TUN 모드를 활성화했는지에 따라 달라집니다.
VMess와 VLESS
VMess는 V2Ray 생태계에서 비교적 일찍 사용된 인증 및 전송 프로토콜로, 다양한 전송 계층과 함께 구성할 수 있습니다. VLESS는 인증과 데이터 전송을 더 간결하게 설계했으며, 자체적으로 완전한 전송 암호화를 제공하지 않으므로 일반적으로 TLS, REALITY 또는 다른 보안 전송 방식과 함께 배포합니다. VLESS 노드를 볼 때는 서버 주소와 식별 정보만 입력해서는 안 되며, 전송 유형, 서버 이름, 공개 키 또는 경로 등의 필드를 서버 설정과 일치시켜야 합니다.
Trojan
Trojan은 일반적으로 TLS 위에서 실행되며 비밀번호로 인증하고, 연결 형태가 일반적인 TLS 트래픽과 유사합니다. 클라이언트는 인증서와 서버 이름을 올바르게 검증해야 합니다. 기기의 시간이 크게 어긋났거나 도메인 조회에 문제가 있거나 서버 이름이 일치하지 않으면 TLS 핸드셰이크가 실패할 수 있습니다. 인증서 검증을 끄는 것은 연결 검증을 약화시키므로 일반적인 해결 방법으로 사용해서는 안 됩니다.
Hysteria2와 TUIC
Hysteria2와 TUIC는 모두 QUIC 및 UDP 전송을 기반으로 하며, 지연 시간이 길거나 패킷 손실이 발생하거나 대역폭이 변하는 환경에서 전송 효율을 높이는 데 초점을 둡니다. UDP 통신이 정상적으로 허용되는 네트워크에서는 더 유리할 수 있지만, 기업·학교·공용 네트워크 또는 일부 라우터는 UDP를 제한할 수 있습니다. 연결 시간 초과나 반복적인 핸드셰이크 실패가 발생하면 TCP 및 TLS 기반의 사용 가능한 노드로 바꿔 비교해 보세요. 이를 통해 문제가 프로토콜 설정에 있는지 로컬 네트워크 정책에 있는지 판단할 수 있습니다.
| 프로토콜 | 주요 전송 특성 | 설정 시 확인할 점 | 일반적인 점검 방향 |
|---|---|---|---|
| Shadowsocks | 경량 암호화 프록시 | 암호화 방식, 비밀번호, 플러그인 매개변수 | 클라이언트가 해당 암호화 방식을 지원하는지 여부 |
| VMess | 인증 프로토콜, 다양한 전송 계층과 조합 가능 | 식별 정보, 전송 유형, 경로와 서버 이름 | 매개변수가 완전한지, 시스템 시간이 정상인지 여부 |
| VLESS | 간소화된 인증, 일반적으로 보안 전송 계층과 함께 사용 | TLS 또는 REALITY 관련 필드 | 서버 이름, 공개 키와 전송 매개변수 |
| Trojan | TLS 기반 인증 및 전송 | 비밀번호, 인증서 도메인, 서버 이름 | 인증서 검증, DNS와 기기 시간 |
| Hysteria2 | QUIC 및 UDP 기반 | 인증, TLS와 대역폭 관련 설정 | 로컬 네트워크가 UDP를 제한하는지 여부 |
| TUIC | QUIC 및 UDP 기반 | 식별 정보, 비밀번호, TLS와 혼잡 제어 | UDP 연결 가능 여부와 클라이언트 버전 호환성 |
분할 라우팅·전체 모드·규칙 모드 선택 방법
클라이언트가 최종적으로 해결해야 하는 문제는 ‘프록시를 켤지’가 아니라 ‘어떤 트래픽을 어느 출구에서 처리할지’입니다. 전체 모드와 규칙 모드는 클라이언트가 노드에 성공적으로 연결된다는 전제에서 작동하며, 트래픽 결정 방식을 바꿀 뿐 노드 핸드셰이크 실패나 구독 해석 오류를 해결하지는 않습니다.
전체 모드는 일시적인 진단에 적합합니다
전체 모드는 일반적으로 클라이언트가 제어할 수 있는 요청을 현재 노드로 보냅니다. 논리가 단순해 복잡한 규칙을 거치지 않고 특정 웹사이트에 접속할 수 있는지 확인하거나 규칙 오판을 점검하는 데 적합합니다. 반면 로컬 웹사이트, 업데이트 다운로드와 국제 출구가 필요하지 않은 앱도 원격 회선을 거칠 수 있어 우회와 트래픽 사용량이 늘어날 수 있습니다.
‘전체’가 반드시 기기의 모든 데이터를 뜻하는 것은 아닙니다. 클라이언트가 시스템 HTTP 프록시만 설정한 경우 시스템 프록시를 읽지 않는 앱은 계속 직접 연결될 수 있습니다. TUN 또는 시스템 VPN 인터페이스를 활성화하면 보통 제어 범위가 넓어지지만, 제외 라우팅, 로컬 네트워크 트래픽과 앱 자체의 네트워크 구현에 영향을 받을 수 있습니다.
규칙 모드는 일상적인 사용에 적합합니다
규칙 모드는 도메인, IP 주소, 앱 프로세스 또는 규칙 세트를 순서대로 매칭한 뒤 요청을 프록시, 직접 연결, 차단 또는 특정 노드 그룹으로 보냅니다. 규칙에는 일반적으로 순서가 있어 요청이 앞선 규칙에 매칭되면 뒤의 규칙은 처리되지 않을 수 있습니다. 따라서 범위가 넓은 규칙을 추가할 때는 더 구체적인 항목을 먼저 덮어쓰지 않는지 확인해야 합니다.
도메인 규칙과 IP 규칙은 서로 다른 문제를 해결합니다. 도메인 규칙은 도메인 정보가 보이는 시점에 판단에 참여해야 하고, IP 규칙은 조회 결과에 의존합니다. DNS가 클라이언트 외부에서 처리되거나 앱이 자체 암호화 DNS를 사용하면 클라이언트에는 대상 IP만 보일 수 있어 예상한 도메인 규칙이 적중하지 않을 수 있습니다.
직접 연결 모드는 로컬 네트워크 기준을 복원할 때 적합합니다
직접 연결 모드는 요청이 프록시 노드를 거치지 않게 하며, 문제가 클라이언트 설정에서 비롯되었는지 확인할 때 사용합니다. 직접 연결에서도 로컬 서비스에 접속할 수 없다면 로컬 DNS, 라우터, 시스템 방화벽 또는 통신사 네트워크를 우선 점검해야 합니다. 직접 연결은 정상인데 규칙 모드만 이상하다면 규칙 매칭, 노드 연결과 DNS 처리를 확인하는 편이 효과적입니다.
- ✅ 일상적인 웹 이용에는 정상적으로 관리되는 규칙 모드를 우선 사용해 불필요한 원격 우회를 줄이세요
- ✅ 특정 대상에 접속할 수 없을 때 잠시 전체 모드로 전환해 비교하세요
- ✅ 로컬 서비스에 문제가 생기면 직접 연결로 돌아가 기본 네트워크가 정상인지 확인하세요
- ❌ 전체 모드를 노드 대역폭을 높이거나 핸드셰이크 실패를 해결하는 설정으로 생각하기
- ❌ 적중 로그를 확인하지 않고 여러 규칙을 반복해서 수정하기
시스템 프록시·TUN·DNS 누수
시스템 프록시는 프록시 설정을 읽는 앱에만 적용됩니다
시스템 프록시는 운영체제에 HTTP, HTTPS 또는 SOCKS 프록시 주소를 기록하는 방식입니다. 브라우저와 많은 데스크톱 앱은 이 설정을 읽지만, 일부 게임·명령줄 프로그램·자체 네트워크 스택을 사용하는 앱 또는 UDP 요청을 직접 보내는 소프트웨어는 시스템 프록시를 무시할 수 있습니다. 이때 클라이언트에 ‘연결됨’으로 표시되어도 해당 앱의 트래픽이 노드로 들어갔다는 뜻은 아닙니다.
TUN 모드는 가상 네트워크 인터페이스에서 트래픽을 제어합니다
TUN 모드는 가상 네트워크 인터페이스를 만들고 시스템 라우팅을 통해 더 많은 IP 트래픽을 클라이언트가 처리하도록 합니다. 단순한 시스템 프록시보다 적용 범위가 넓어 프록시 설정을 지원하지 않는 앱에 적합합니다. 그만큼 시스템 네트워크 권한이 필요하며 다른 VPN 소프트웨어, 가상 머신 네트워크, 컨테이너 네트워크 또는 보안 소프트웨어와 라우팅 충돌이 발생할 수 있습니다.
TUN을 활성화한 뒤 로컬 기기에 접속할 수 없거나, LAN 서비스가 중단되거나, 특정 앱의 네트워크가 끊기면 먼저 LAN 우회, 사설 주소 직접 연결과 올바른 기본 라우팅이 활성화되어 있는지 확인하세요. 가상 인터페이스를 만들고 기본 라우팅을 수정하는 클라이언트를 동시에 실행하지 마세요.
DNS 누수는 조회 요청이 잘못된 출구로 나가는 현상입니다
DNS 누수는 일반적으로 실제 트래픽은 프록시를 통과하지만 도메인 조회는 로컬 네트워크의 DNS 서버가 직접 처리하는 현상을 뜻합니다. 이로 인해 조회 위치와 출구 위치가 일치하지 않을 수 있고, 로컬 네트워크가 조회한 도메인을 확인할 수도 있습니다. 반드시 인터넷 전체가 끊기는 것은 아니며, 대상이 잘못된 지역의 콘텐츠를 반환하거나 규칙이 적중하지 않거나 일부 도메인이 적절하지 않은 주소로 조회되는 형태로 나타나는 경우가 많습니다.
점검할 때는 클라이언트가 DNS를 제어하는지, 규칙 모드가 어떤 조회 전략을 사용하는지, 브라우저에서 별도의 보안 DNS를 활성화했는지, 시스템에 다른 네트워크 인터페이스의 DNS가 남아 있는지 확인해야 합니다. 연결한 뒤에는 네트워크 진단 페이지를 열어 출구 주소와 DNS 조회 위치를 비교하세요. 두 위치가 크게 다르면 클라이언트로 돌아가 DNS 제어 방식을 조정하세요.
플랫폼별 클라이언트 차이는 어디에서 생길까요?
같은 구독도 플랫폼에 따라 표시되는 옵션이 다를 수 있습니다. 이는 대개 구독 내용이 바뀌어서가 아니라 운영체제가 제공하는 네트워크 인터페이스, 백그라운드 제한과 클라이언트 코어 기능이 다르기 때문입니다. 기기를 옮길 때는 모드와 권한을 다시 확인하고, 가져온 뒤 모든 설정이 자동으로 동일하게 유지된다고 가정하지 마세요.
Windows
Windows 클라이언트는 시스템 프록시와 TUN을 함께 제공하는 경우가 많습니다. 시스템 프록시는 브라우저와 일반 데스크톱 앱에 적합하고, TUN은 명령줄·게임 또는 프록시 설정을 읽지 않는 소프트웨어를 제어하는 데 더 적합합니다. 인터넷에 연결되지 않을 때는 시스템 프록시 설정이 남아 있는지, 가상 네트워크 어댑터가 정상적으로 로드되었는지, 방화벽이 클라이언트 통신을 허용하는지 확인하세요.
macOS
macOS 클라이언트는 시스템 프록시, 네트워크 확장 또는 시스템 VPN 인터페이스를 통해 작동할 수 있습니다. 관련 모드를 처음 활성화하면 시스템에서 네트워크 권한 승인을 요청합니다. 클라이언트가 연결되었는데도 앱이 노드를 거치지 않는다면 네트워크 확장이 활성화되어 있는지, 시스템 설정에 다른 네트워크 필터가 함께 존재하는지 확인하세요. 클라이언트를 종료하기 전에 시스템 프록시를 복원하면 이후 앱이 이미 닫힌 로컬 포트를 계속 가리키는 문제도 피할 수 있습니다.
Android
Android는 일반적으로 시스템 VPN 인터페이스를 이용해 트래픽을 제어하며, 앱별로 터널에 들어갈지 결정할 수 있습니다. 배터리 절약 정책이 백그라운드에서 클라이언트 연결을 유지하지 못하게 할 수 있고, 네트워크를 전환한 뒤 세션을 다시 구성해야 할 수도 있습니다. 특정 앱만 이상하다면 전체 구독을 바로 바꾸기보다 먼저 앱별 분할 라우팅 설정을 확인하세요.
iOS 및 iPadOS
iOS 및 iPadOS 클라이언트는 시스템이 제공하는 VPN 및 네트워크 확장 기능에 의존하며 백그라운드 동작은 시스템이 통합 관리합니다. 구독을 가져온 뒤에도 시스템에서 VPN 구성을 생성하도록 요청합니다. 노드를 바꿔도 즉시 반영되지 않으면 먼저 연결을 끊었다가 다시 연결하고, 현재 활성화된 구성이 실제 사용 중인 클라이언트의 것인지 확인하세요.
| 플랫폼 | 일반적인 트래픽 제어 방식 | 중점 확인 항목 |
|---|---|---|
| Windows | 시스템 프록시, TUN | 남은 프록시 설정, 가상 네트워크 어댑터, 방화벽 |
| macOS | 시스템 프록시, 네트워크 확장 | 네트워크 권한, 필터 충돌, 시스템 프록시 상태 |
| Android | 시스템 VPN 인터페이스, 앱별 분할 라우팅 | 백그라운드 제한, 앱별 우회, 네트워크 전환 |
| iOS 및 iPadOS | 시스템 VPN, 네트워크 확장 | 구성 승인, 현재 활성 구성, 재연결 상태 |
연결 실패부터 규칙 이상까지의 점검 순서
초보자가 자주 겪는 문제는 노드, 프로토콜, DNS, TUN과 규칙을 한꺼번에 바꾼 뒤 어떤 설정이 실제로 효과가 있었는지 확인하지 못하는 것입니다. 더 신뢰할 수 있는 방법은 데이터 흐름을 따라 구독 입력부터 대상 앱의 출구까지 계층별로 점검하는 것입니다.
- 구독이 업데이트되는지, 노드 설정에 프로토콜이나 인증 필드가 누락되지 않았는지 확인하세요.
- 노드 하나를 고정하고 클라이언트 로그에서 연결과 핸드셰이크가 완료되었는지 확인하세요.
- 규칙이 적은 모드로 기본 접속을 테스트해 복잡한 분할 라우팅의 영향을 배제하세요.
- 대상 앱이 시스템 프록시를 읽는지 확인하세요. 읽지 않는다면 TUN 또는 시스템 VPN 인터페이스를 테스트하세요.
- 출구 주소와 DNS 조회 위치를 대조해 조회가 예상한 경로로 들어가는지 판단하세요.
- 일상적인 규칙 모드로 돌아간 뒤 적중 로그에서 대상 도메인이나 IP에 올바른 정책이 적용되었는지 확인하세요.
- 마지막으로 다른 노드와 회선을 비교해 로컬 권한 문제를 회선 문제로 잘못 판단하지 않도록 하세요.
클라이언트에 ‘연결됨’으로 표시되는 것은 특정 연결 과정이 수립되었다는 뜻일 뿐입니다. 구독 업데이트, 앱 제어, DNS 조회, 분할 라우팅 적중과 대상 서비스 접속이 모두 정상이라는 의미는 아닙니다. 문제를 해결할 때는 각 단계를 따로 검증해야 합니다.
이 용어를 이해하면 클라이언트 화면을 명확한 연결 흐름으로 나눌 수 있습니다. 구독은 설정을 제공하고, 노드는 진입점을 제시하며, 프로토콜은 통신을 담당하고, 회선은 데이터를 전달합니다. 시스템 프록시 또는 TUN은 앱 트래픽을 제어하고, 분할 라우팅 규칙은 출구를 결정하며, DNS는 도메인 조회 주소를 제공합니다. 문제가 발생해도 모든 설정을 무작정 바꾸지 말고 해당 계층을 찾아 점검할 수 있습니다.