macOS에서 국제 네트워크를 처음 설정할 때 중요한 것은 클라이언트를 “응용 프로그램” 폴더에 넣는 것만이 아닙니다. 클라이언트, 구독 형식, 시스템 네트워크 확장, 분할 라우팅 모드가 올바르게 연동되어야 합니다. 클라이언트 선택, 출처 확인, 시스템 권한 허용, 구독 가져오기, 노선 연결과 적용 확인을 순서대로 처리해야 합니다. 메뉴 막대에 “연결됨”이 표시되는 것만으로는 브라우저, 명령줄 도구와 다른 앱이 모두 예상한 출구를 사용하는지 알 수 없습니다.
이 가이드는 실제 작업 순서에 따라 설명합니다. 프록시 프로토콜을 미리 이해할 필요는 없지만, 다음 내용은 알아두어야 합니다. 구독 링크는 노드 매개변수를 클라이언트에 전달하고, 클라이언트는 프로토콜을 해석해 연결을 설정하며, macOS 네트워크 확장은 시스템 트래픽을 클라이언트로 전달합니다. 어느 한 단계라도 맞지 않으면 구독이 비어 있거나, 노선이 시작되지 않거나, 일부 앱이 연결되지 않거나, DNS가 계속 로컬 네트워크를 사용하는 문제가 발생할 수 있습니다.
클라이언트, 프로토콜과 구독 형식은 어떻게 연동될까
macOS용 네트워크 클라이언트는 모든 형식을 지원하는 도구가 아닙니다. 클라이언트마다 지원하는 프로토콜, 구독 형식과 시스템 트래픽을 처리하는 방식이 다를 수 있습니다. 일반적인 구독에는 Shadowsocks, VMess, Trojan, VLESS, Hysteria2 또는 TUIC 노드가 포함될 수 있습니다. 클라이언트가 해당 프로토콜을 구현해야 매개변수를 읽고 연결을 설정할 수 있습니다. 구독은 업데이트되지만 노드 목록이 비어 있거나, 노드는 보이지만 시작되지 않는다면 시스템 권한을 반복해서 삭제하기보다 먼저 호환성을 확인해야 합니다.
| 확인 대상 | 실제 역할 | 일반적인 불일치 현상 | 처리 방향 |
|---|---|---|---|
| 클라이언트 | 구독 해석, 프로토콜 구현, 분할 라우팅 실행 | 가져온 뒤 노드가 없거나 노선을 시작할 수 없음 | 클라이언트가 구독의 프로토콜과 필드를 지원하는지 확인 |
| 구독 링크 | 노드와 규칙 설정을 클라이언트에 제공 | 업데이트 실패, 콘텐츠 만료 또는 형식 오류 반환 | 사용자 패널에서 다시 복사한 뒤 클라이언트에서 업데이트 |
| 네트워크 확장 | 시스템 트래픽을 클라이언트 처리 경로로 전달 | 클라이언트는 실행 중이지만 앱은 기존 네트워크를 사용 | 시스템 설정에서 권한과 연결 상태 확인 |
| 분할 라우팅 모드 | 어떤 도메인과 주소가 노선을 통과할지 결정 | 브라우저는 되지만 터미널이나 특정 앱은 연결되지 않음 | 규칙, 시스템 프록시와 가상 네트워크 모드 점검 |
| DNS 설정 | 도메인을 네트워크 주소로 변환 | 도메인은 열리지 않지만 주소로 직접 접속하면 응답함 | 클라이언트 DNS, 캐시와 분할 라우팅 규칙 확인 |
클라이언트를 선택할 때는 서비스 패널이 제공하는 다운로드 경로와 사용 설명을 우선하세요. VPNLK 클라이언트 입구는 사용자 패널의다운로드 페이지에 있습니다. 파일 이름만 보고 버전을 판단하거나, 재배포 페이지에서 설치 파일을 받지 마세요. 패널에서 그래픽 클라이언트와 범용 구독을 함께 제공한다면 먼저 자신의 목적을 확인하세요. 일상적인 연결만 필요하다면 그래픽 클라이언트가 간편하고, 복잡한 규칙이나 스크립트 또는 여러 구독 소스를 관리해야 한다면 규칙 편집을 지원하는 범용 클라이언트가 더 적합합니다.
프로토콜 이름이 노선 품질을 의미하는 것은 아닙니다. Shadowsocks, VMess, Trojan과 VLESS는 연결 및 전송 설정을 설명하고, Hysteria2와 TUIC는 UDP 기반 전송 특성을 더 강조합니다. IEPL 전용 회선, 중계와 직접 연결은 노선 경로를 설명합니다. 직접 연결은 기기가 해외 입구에 바로 연결되는 방식으로, 로컬 네트워크와 국제 출구의 변동 영향을 더 크게 받을 수 있습니다. 중계는 먼저 중계 노드로 들어간 뒤 목적지 지역으로 이동하며, IEPL 전용 회선은 일반적으로 국제 구간을 관리되는 경로에 둡니다. 프로토콜과 노선은 서로 다른 계층이므로 특정 프로토콜 이름만 보고 반드시 더 빠르다고 판단할 수 없습니다.
클라이언트 설치 및 시스템 권한 허용
패널에서 클라이언트를 받은 뒤에는 먼저 실행 중인 유사 도구를 종료하세요. 여러 클라이언트가 동시에 시스템 프록시, 라우팅이나 DNS를 변경하는 것을 막기 위해서입니다. 디스크 이미지 파일을 받았다면 연 후 앱을 “응용 프로그램” 폴더로 드래그하고 해당 폴더에서 실행하세요. 압축 파일이라면 압축을 푼 뒤 앱을 “응용 프로그램”으로 옮기세요. 앱을 계속 “다운로드” 폴더에서 직접 실행하면 업데이트, 권한 기록과 파일 격리 상태를 확인하기 어려울 수 있습니다.
- 출처와 파일 확인. 사용자 패널의 다운로드 경로로 이동해 앱 이름과 지원 플랫폼을 확인하세요. 시스템이 출처를 확인할 수 없다고 표시하면 보안 검사를 임의로 해제하지 말고 다운로드 경로로 돌아가 파일을 확인하세요.
- 이동 후 최초 실행. 앱을 “응용 프로그램” 폴더에 넣고 실행하세요. 처음 실행할 때 파일 출처 확인 메시지가 나타날 수 있으므로 앱 이름과 출처를 읽은 뒤 진행하세요.
- 연결 시작. 클라이언트가 처음으로 시스템 프록시, 가상 네트워크 인터페이스 또는 VPN 설정을 활성화할 때 권한을 요청하는 경우가 많습니다. 해당 작업을 시작해야 시스템에 관련 팝업이 표시됩니다.
- 네트워크 확장 승인. 시스템 설정에서 해당 클라이언트가 제출한 네트워크 확장 또는 VPN 설정을 확인하세요. 시스템이 관리자 권한을 요구할 수 있으며, 이는 네트워크 설정을 변경할 때의 정상적인 보호 절차입니다.
- 클라이언트로 돌아가 확인. 권한 허용이 끝나면 클라이언트로 돌아가 다시 연결하세요. 시스템 설정 화면에만 머물지 마세요. 클라이언트가 확장을 다시 초기화해야 할 수 있습니다.
시스템 프록시와 가상 네트워크 모드는 적용 범위가 다릅니다. 시스템 프록시는 일반적으로 macOS 프록시 설정을 따르는 앱의 트래픽을 전달하지만, 일부 명령줄 프로그램, 게임이나 자체 네트워크 스택을 사용하는 앱은 이를 무시할 수 있습니다. 가상 네트워크 모드는 네트워크 확장을 통해 더 넓은 트래픽을 처리한 뒤 규칙에 따라 직접 연결 또는 전달을 결정합니다. 따라서 여러 앱에 적용해야 하는 경우에 적합하지만, 권한과 라우팅 및 DNS를 올바르게 설정해야 합니다.
권한 팝업은 필요한 경우에만 나타나며, 실행할 때마다 다시 승인해야 한다는 뜻은 아닙니다. 클라이언트가 계속 권한을 요청한다면 앱이 다운로드 폴더에서 실행 중이거나, 이전 버전의 확장이 남아 있거나, 앱 본체가 이동되었거나, 시스템의 확장 상태가 완료되지 않은 것이 원인일 수 있습니다. 먼저 클라이언트를 종료하고 “응용 프로그램” 폴더에서 다시 실행하세요. 그래도 실패하면 시스템 설정의 네트워크 및 VPN 관련 페이지에서 기존 설정을 확인하고, 이름을 확인한 뒤 작동하지 않는 항목을 제거할 수 있습니다.
- ✅ 클라이언트는 사용자 패널 또는 서비스 안내의 공식 다운로드 경로에서 받았습니다.
- ✅ 앱을 “응용 프로그램” 폴더에 넣고 해당 위치에서 실행했습니다.
- ✅ 시스템 설정에 표시된 확장 이름이 현재 클라이언트와 일치합니다.
- ✅ 같은 시간에 하나의 클라이언트만 시스템 프록시 또는 가상 네트워크 인터페이스를 관리합니다.
- ✅ 권한을 허용한 뒤 클라이언트로 돌아가 다시 연결을 시작했습니다.
구독 가져오기, 노드 업데이트와 노선 선택
설치와 권한 허용이 끝난 뒤 구독을 처리하세요. 사용자 패널에서 구독 링크를 복사하고 클라이언트에서 “URL에서 가져오기”, “원격 설정” 또는 “구독 관리”와 같은 메뉴를 찾습니다. 클라이언트마다 문구는 다를 수 있지만, 핵심 작업은 구독 주소를 저장하고 설정 내용을 요청한 뒤 노드를 해석해 결과를 로컬 설정에 기록하는 것입니다. 구독 링크를 브라우저 검색창에 붙여 넣거나, 브라우저에 표시되는 인코딩된 텍스트를 오류로 판단하지 마세요. 구독 내용은 원래 사람이 직접 읽는 웹페이지가 아닐 수 있습니다.
가져온 뒤 먼저 업데이트를 실행하고 노드 목록을 확인하세요. 클라이언트가 구독 이름을 요구한다면 서비스와 용도를 구분할 수 있는 이름을 사용하면 됩니다. 이름은 연결 매개변수를 바꾸지 않습니다. 노드가 표시된 뒤 여러 노선을 연속해서 클릭하지 마세요. 먼저 목적 서비스 지역에 맞는 노드를 선택하고 한 번 완전히 연결한 뒤, 클라이언트 로그에서 도메인 확인, 핸드셰이크와 라우팅 설정이 끝났는지 확인하세요. 자주 전환하면 이전 연결, DNS 캐시와 앱 세션이 섞여 문제 위치를 판단하기 어려워집니다.
사용자 패널 열기
→ 다운로드 또는 구독 메뉴로 이동
→ 전체 구독 링크 복사
→ 클라이언트에서 원격 구독 추가
→ 구독 수동 업데이트
→ 노선 선택 후 연결
→ 출구, DNS와 실제 앱 확인업데이트할 때 “형식을 지원하지 않음”이라는 메시지가 나오면 웹페이지 주소, 요금제 페이지 주소 또는 잘린 텍스트를 잘못 복사하지 않았는지 먼저 확인하세요. 전체 구독은 일반적으로 끊기지 않은 하나의 URL이며, 복사할 때 마침표, 따옴표나 줄바꿈이 포함되지 않아야 합니다. 업데이트에서 인증 실패가 반환되면 패널로 돌아가 링크를 다시 받으세요. 링크가 공개된 적이 있다면 이전 링크를 계속 공유하지 말고 패널에서 재설정해야 합니다.
노드 목록에 여러 노선 유형이 있다면 용도에 따라 선택하세요. 웹 브라우징과 장시간 연결은 안정성이 중요하고, 다운로드 작업은 지속적인 전송 성능도 확인해야 합니다. 실시간 음성 및 상호작용 앱은 지터와 UDP 지원에 더 민감합니다. IEPL 전용 회선은 국제 구간의 변동을 줄이고 싶은 경우에 적합하며, 중계 노선은 일부 로컬 네트워크에서 해외 입구까지의 경로를 개선할 수 있습니다. 직접 연결은 구조가 단순하지만 현재 통신사의 국제 출구에 더 크게 의존합니다. 클라이언트에 표시되는 짧은 시간의 지연 시간은 초기 선별에만 사용할 수 있으며 실제 앱 테스트를 대신하지 못합니다.
연결 후 실제 적용 여부를 확인하는 방법
확인은 “클라이언트 상태”에서 “시스템 출구”로, 다시 “목적 앱”으로 진행해야 합니다. 클라이언트에 연결됨이 표시된다는 것은 로컬 프로그램이 터널 또는 프록시가 설정되었다고 판단한다는 뜻일 뿐입니다. 모든 트래픽이 예상한 노선을 통과한다는 것을 단독으로 증명하지는 못합니다. 가장 간단한 방법은 연결 해제 상태의 출구 정보를 먼저 기록한 뒤 노선에 연결하고 VPNLK의 IP 확인 페이지에서 비교하는 것입니다. 지역과 네트워크 소속이 예상대로 바뀌어야 현재 브라우저 트래픽이 노선에 진입했다고 볼 수 있습니다.
다음으로 DNS를 확인하세요. DNS 누출은 실제 트래픽은 프록시 노선을 사용하지만 도메인 조회는 여전히 로컬 네트워크의 확인자에게 맡기는 현상입니다. 이로 인해 지역 판단이 일치하지 않거나 도메인 확인이 실패하고 개인정보 경계가 불명확해질 수 있습니다. 확인할 때는 출구 주소만 보지 말고 확인자의 소속이 현재 설정과 일치하는지 살펴보세요. 출구는 바뀌었지만 DNS가 예상과 다르다면 클라이언트가 원격 DNS를 활성화했는지, 규칙이 DNS 요청을 직접 연결로 처리하는지, 시스템의 다른 네트워크 도구가 확인 설정을 변경하고 있지 않은지 확인해야 합니다.
브라우저와 비브라우저 앱도 각각 테스트해야 합니다. 브라우저는 접속되지만 터미널 도구가 실패한다면 시스템 프록시만 활성화되어 터미널 프로그램이 프록시 환경을 읽지 않는 경우가 많습니다. 터미널은 되지만 브라우저가 이상하다면 브라우저 캐시, 확장 프로그램, 암호화 DNS 또는 기존 세션이 원인일 수 있습니다. 가상 네트워크 모드에서도 일부 앱이 연결되지 않는다면 분할 라우팅 규칙이 직접 연결로 처리했거나, 현재 노선이 UDP를 처리하지 못하거나, 목적 앱이 연결 전에 만든 세션을 유지하고 있을 가능성이 있습니다.
- ✅ 연결 해제 및 연결 상태에서 출구 주소와 지역을 비교했습니다.
- ✅ DNS 확인 경로가 현재 클라이언트 설정과 일치하며 비정상 캐시를 계속 사용하지 않습니다.
- ✅ 브라우저, 터미널과 목적 앱에서 각각 실제 접속 테스트를 완료했습니다.
- ✅ 분할 라우팅 모드에서 로컬 서비스는 직접 연결되고 목적 서비스는 예상 노선을 사용합니다.
- ❌ 메뉴 막대 아이콘이나 클라이언트의 녹색 상태만으로 모든 앱에 적용됐다고 판단합니다.
분할 라우팅을 확인할 때는 직접 연결되어야 하는 로컬 사이트와 국제 노선이 필요한 목적 사이트를 각각 테스트하세요. 둘 다 같은 출구를 사용한다면 현재 전체 모드일 수 있습니다. 목적 사이트가 여전히 로컬 출구를 사용한다면 규칙이 적용되지 않았을 가능성이 있습니다. 규칙은 일반적으로 도메인, 주소 범위, 프로세스 또는 규칙 집합에 따라 일치하며 순서도 결과에 영향을 줄 수 있습니다. 규칙을 수정한 뒤에는 연결을 해제했다가 다시 연결하고, 기존 연결이 재사용되지 않도록 새 브라우저 세션을 시작하세요.
일반적인 문제를 현상별로 점검하기
문제를 해결할 때 클라이언트 재설치, 구독 초기화, 노선 변경과 DNS 수정을 동시에 하지 마세요. 한 번에 하나의 변수만 바꿔야 어느 단계가 효과가 있었는지 알 수 있습니다. 먼저 문제가 설치 및 권한, 구독 해석, 노선 연결 또는 앱 분할 라우팅 중 어느 계층에 속하는지 판단한 뒤 해당 단계에서 처리하는 것이 좋습니다.
| 현상 | 가능한 위치 | 우선 확인 |
|---|---|---|
| 앱이 시작되지 않음 | 다운로드 파일 또는 시스템 보안 검사 | 다운로드 출처를 확인하고 앱을 “응용 프로그램”으로 옮긴 뒤 다시 실행 |
| 권한 팝업이 반복해서 나타남 | 네트워크 확장 미완료 또는 이전 설정 잔류 | 확장 이름, 앱 위치와 시스템 네트워크 설정 확인 |
| 구독 업데이트 실패 | 링크 오류, 링크 만료 또는 네트워크 연결 불가 | 패널에서 전체 링크를 다시 복사하고 오류 메시지 확인 |
| 구독은 성공했지만 노드가 없음 | 클라이언트가 구독 형식 또는 프로토콜과 호환되지 않음 | 클라이언트 지원 범위를 확인하고 해석 로그 확인 |
| 노드를 선택했지만 연결할 수 없음 | 노선, 프로토콜 매개변수 또는 로컬 네트워크 | 구독을 업데이트하고 다른 경로의 노선으로 전환한 뒤 핸드셰이크 로그 확인 |
| 브라우저는 되지만 다른 앱은 되지 않음 | 시스템 프록시 적용 범위 | 앱의 프록시 지원을 확인하고 필요하면 가상 네트워크 모드 사용 |
| 주소는 바뀌었지만 도메인이 열리지 않음 | DNS 또는 분할 라우팅 규칙 | 클라이언트 DNS, 규칙 적용 여부와 시스템 캐시 확인 |
| 절전 모드 복귀 후 연결 이상 | 이전 세션, 네트워크 인터페이스 또는 라우팅 상태 | 연결을 해제했다가 다시 연결하고 필요하면 목적 앱을 다시 실행 |
네트워크 확장을 허용했는데 왜 계속 권한이 없다고 표시되나요?
시스템 설정의 스위치 상태와 클라이언트가 현재 불러온 확장 인스턴스가 동기화되지 않았을 수 있습니다. 먼저 클라이언트를 완전히 종료하고 앱이 “응용 프로그램” 폴더에 있는지 확인한 뒤 다시 실행해 연결을 시작하세요. 시스템에 같은 이름의 이전 설정이 남아 있다면 개발자와 앱 이름을 확인한 후 작동하지 않는 항목을 정리하세요. 소속을 확인하지 않은 상태에서 네트워크 설정을 일괄 삭제하지 마세요. 다른 정상 도구도 네트워크 확장에 의존할 수 있습니다.
구독을 가져온 뒤 노드가 일부만 표시되는 이유는 무엇인가요?
클라이언트가 구독에 포함된 일부 프로토콜만 지원하거나, 필터 조건과 그룹 규칙 또는 구독 해석 실패가 원인일 수 있습니다. 먼저 클라이언트의 지역 및 프로토콜 필터를 해제하고 업데이트 로그를 확인하세요. 로그에 특정 노드 필드를 지원하지 않는다고 표시되면 구독 내용을 직접 수정하지 말고 패널이 추천하는 클라이언트를 사용하세요. 직접 수정하면 이후 업데이트에서 로컬 변경 사항이 덮어쓰이고 매개변수 오류가 생기기 쉽습니다.
노선을 바꿨는데 웹사이트 지역이 변하지 않는 이유는 무엇인가요?
브라우저가 전환 전의 장시간 연결을 재사용하고 있거나, 분할 라우팅 규칙이 해당 웹사이트를 직접 연결로 지정했을 수 있습니다. 연결을 해제한 뒤 다시 연결하고 관련 탭을 닫은 다음 새 세션에서 출구를 다시 확인하세요. 그래도 바뀌지 않는다면 현재 모드, 규칙 적용 기록과 시스템에서 다른 클라이언트가 프록시를 동시에 관리하고 있는지 확인하세요.
보안 유지와 일상적인 사용 습관
안정적인 설정을 완료한 뒤에는 불필요한 변경을 줄이는 것이 좋습니다. 검증이 끝난 클라이언트와 구독 설정을 하나 보관하고, 새 규칙을 추가하거나 다른 프로토콜을 테스트할 때 별도로 백업하세요. 클라이언트를 업그레이드하기 전에는 현재 모드, DNS 옵션과 사용자 지정 규칙을 기록할 수 있습니다. 업그레이드 후 구독을 먼저 업데이트하고 기본 연결을 테스트한 뒤 복잡한 설정을 복원하세요. 문제가 생겼을 때 버전 변경, 구독 변경과 사용자 지정 규칙 중 원인을 구분하기 쉬워집니다.
구독 링크를 공개 스크립트, 공유 설정 저장소 또는 다른 사람이 읽을 수 있는 메모에 기록하지 마세요. 다른 macOS 기기에 가져와야 한다면 사용자 패널에서 다시 복사하거나 통제된 방식으로 전달하세요. 링크가 유출된 것을 발견하면 패널에서 구독을 재설정한 뒤 모든 클라이언트가 새 링크로 업데이트하도록 하세요. 채팅 기록만 삭제한다고 이미 복사된 링크가 무효화되지는 않습니다.
분할 라우팅 규칙도 이해하기 쉬운 상태로 유지해야 합니다. 규칙이 많을수록 충돌 원인을 찾기 어렵습니다. 일상적인 사용에서는 “로컬 서비스는 직접 연결, 목적 서비스는 지정 노선 사용, 일치하지 않는 트래픽은 명확한 기본 정책 적용”을 기준으로 구성할 수 있습니다. 로그인, 결제와 업무 시스템처럼 고정된 지역 세션이 있는 서비스는 출구를 바꾸기 전에 이전 세션에서 로그아웃하세요. 같은 세션이 짧은 시간에 서로 다른 지역 사이를 이동하는 것을 피해야 합니다.
클라이언트 옵션의 의미가 확실하지 않다면 시스템 프록시, 가상 네트워크 모드와 여러 DNS 덮어쓰기 기능을 동시에 활성화하지 마세요. 먼저사용 가이드에 따라 기본 설정을 완료한 뒤 필요한 항목을 하나씩 추가하세요. 원인을 찾기 어려운 문제가 발생하면 클라이언트 이름, macOS 시스템 메시지, 구독 업데이트 시간, 선택한 노선 유형과 가린 오류 로그를 남겨 문의 페이지로 제출하세요. “연결되지 않음”이라는 한마디보다 이런 정보가 문제 계층을 판단하는 데 더 도움이 됩니다.
자주 묻는 질문 정리
시스템 프록시와 가상 네트워크 모드 중 무엇을 선택해야 하나요?
macOS 프록시 설정을 따르는 브라우저와 일반 앱에만 적용하면 시스템 프록시가 더 가볍습니다. 터미널 도구, 게임 또는 시스템 프록시를 읽지 않는 앱까지 적용해야 한다면 가상 네트워크 모드가 일반적으로 더 적합합니다. 후자는 더 넓은 트래픽을 처리하므로 분할 라우팅과 DNS를 꼼꼼히 확인해 직접 연결되어야 하는 로컬 서비스가 잘못 전달되지 않도록 해야 합니다.
클라이언트를 열 때마다 구독을 다시 가져와야 하나요?
일반적으로 그럴 필요는 없습니다. 구독을 추가하면 클라이언트 설정에 저장되므로 평소에는 수동 업데이트만 하면 됩니다. 다시 가져오면 그룹과 노드가 중복될 수 있습니다. 설정이 삭제되었거나 구독 링크가 재설정되었거나, 클라이언트를 옮긴 뒤 기존 설정을 읽지 못하는 경우에만 다시 추가하면 됩니다.
노선 테스트는 정상인데 실제 앱이 계속 멈추는 이유는 무엇인가요?
클라이언트의 노선 테스트는 대개 특정 요청만 확인하므로 실제 앱의 장시간 연결, UDP, DNS, 계정 지역과 캐시 상태까지 확인하지 못합니다. 목적 앱을 직접 열어 테스트하고 예상한 규칙이 적용되는지 확인하세요. 앱이 연결 전에 이미 실행 중이었다면 앱을 종료하고 노선에 연결한 뒤 다시 실행하세요.
클라이언트를 삭제하면 모든 네트워크 설정이 자동으로 지워지나요?
그렇지 않을 수 있습니다. 앱 본체, 네트워크 확장, VPN 설정과 구독 데이터가 서로 다른 위치에서 관리될 수 있습니다. 삭제하기 전에 클라이언트에서 연결을 중지하고 안내에 따라 설정을 제거하세요. 이후 시스템 설정에서 관련 네트워크 항목이 남아 있는지 확인하세요. 앱을 휴지통으로 드래그하는 것만으로 모든 설정이 복원되었다고 판단하지 마세요.