이 iPhone VPN 초보자 가이드는 실제 사용 순서에 따라 설명합니다. 먼저 클라이언트 출처와 프로토콜 호환성을 확인한 뒤 구독 링크를 가져오고 시스템 구성을 승인한 다음 출구 주소, DNS 및 분할 라우팅 결과를 점검합니다. 처음 사용하는 분들이 가장 헷갈리는 부분은 버튼이 아니라 ‘구독을 가져온 상태’, ‘시스템 승인이 완료된 상태’, ‘트래픽이 선택한 서버를 통과하는 상태’가 서로 다르다는 점입니다.
전체 연결 과정에는 일반적으로 구독 서비스, 클라이언트, 시스템 네트워크 확장 및 원격 서버가 포함됩니다. 구독 서비스는 서버 정보를 제공하고, 클라이언트는 구성을 읽어 서버를 선택하며, iOS는 제어된 네트워크 채널을 만들고, 원격 서버는 요청을 대상 사이트로 전달합니다. 어느 한 단계라도 맞지 않으면 서버 목록이 비어 있거나 연결 후 접속이 되지 않고, 출구 지역이 다르거나 일부 앱이 프록시를 우회하는 문제가 발생할 수 있습니다.
먼저 클라이언트 출처와 프로토콜 지원 여부를 확인하세요
iPhone에서 구독 서비스를 사용하려면 보통 해당 프로토콜을 지원하는 네트워크 클라이언트가 필요합니다. 클라이언트마다 인터페이스, 분할 라우팅 규칙, 구독 업데이트 방식과 프로토콜 지원 범위가 다르지만 기본 흐름은 비슷합니다. 구독을 읽고 서버 목록을 만든 뒤 시스템에 VPN 구성을 추가하도록 요청하고, 선택한 모드에 따라 네트워크 요청을 처리합니다.
클라이언트를 받을 때는 먼저 서비스 패널의 다운로드 메뉴를 이용한 다음 이동한 페이지의 개발자 이름, 앱 설명과 업데이트 기록을 확인하세요. 앱 스토어에서 이름이 비슷하다고 같은 개발자가 만든 앱이라는 뜻은 아니며, 검색 결과는 계정 지역에 따라 달라질 수 있습니다. 서비스 패널에 권장 클라이언트가 안내되어 있다면 스크린샷이나 이름만 보고 판단하지 말고 패널의 호환성 설명을 기준으로 삼으세요.
| 프로토콜 또는 연결 유형 | 클라이언트에 필요한 기능 | 가져오기 전에 확인할 내용 |
|---|---|---|
| Shadowsocks | 암호화 방식, 서버 주소와 포트를 식별하고 도메인 또는 주소를 기준으로 분할 라우팅을 실행할 수 있어야 합니다 | 구독에 클라이언트가 지원하는 암호화 매개변수가 포함되어 있는지 확인합니다 |
| VMess / VLESS | 전송 계층, TLS, 경로와 서버 이름 등 조합된 매개변수를 올바르게 처리해야 합니다 | 클라이언트 버전이 구독에 사용된 전송 구성을 지원하는지 확인합니다 |
| Trojan | TLS 기반 연결 매개변수를 지원하고 인증서와 서버 이름을 올바르게 검증해야 합니다 | 기기 시간, 서버 이름과 인증서 검증이 정상인지 확인합니다 |
| Hysteria2 / TUIC | 해당 UDP 및 QUIC 구현을 지원하고 현재 네트워크 환경에서 연결을 설정할 수 있어야 합니다 | 현재 네트워크가 UDP를 제한하는지, 클라이언트가 해당 프로토콜을 완전히 지원하는지 확인합니다 |
프로토콜 이름이 같다고 해서 모든 클라이언트에서 바로 사용할 수 있는 것은 아닙니다. VLESS 또는 Trojan을 예로 들면 서버에는 서로 다른 전송 방식, TLS 매개변수와 도메인 설정이 포함될 수 있습니다. 클라이언트가 프로토콜 이름만 인식하고 특정 전송 매개변수를 지원하지 않으면 가져오기는 성공해도 연결에는 실패할 수 있습니다. 가장 안전한 방법은 먼저 구독 서비스가 제공하는 클라이언트 권장 사항을 확인한 다음 현재 클라이언트 버전이 지원하는 프로토콜을 점검하는 것입니다.
- ✅ 서비스 패널 또는 개발자 공식 페이지에서 다운로드 메뉴로 이동하세요
- ✅ 개발자 이름, 앱 설명과 프로토콜 호환 범위를 확인하세요
- ✅ 클라이언트가 단일 서버만 가져오는 것이 아니라 구독을 업데이트할 수 있는지 확인하세요
- ❌ 출처가 불분명한 변환 페이지에 구독 링크를 제출하지 마세요
- ❌ 이름이 비슷하다는 이유만으로 개발자도 같다고 판단하지 마세요
판단 기준: 클라이언트 선택에서 핵심은 인터페이스가 단순한지가 아니라 프로토콜 구현, 구독 업데이트와 분할 라우팅 기능이 서버 구성과 맞는지입니다. 외관보다 신뢰할 수 있는 출처와 매개변수 호환성을 먼저 확인하세요.
구독 링크를 가져오고 서버를 하나씩 복사하지 마세요
구독 링크는 서버에서 생성한 구성 진입점입니다. 클라이언트가 이 링크에 접속하면 사용 가능한 서버, 프로토콜 매개변수와 서버 이름을 읽습니다. 서버를 하나씩 복사하는 것보다 구독 방식이 장기 사용에 적합합니다. 서버 구성이 변경되어도 클라이언트에서 업데이트할 수 있어 각 주소를 다시 입력할 필요가 없기 때문입니다.
일반적인 가져오기 방법으로는 클립보드에서 읽기, 클라이언트 안에 링크 붙여 넣기, 신뢰할 수 있는 패널에서 생성한 QR 코드 스캔, 시스템 공유 메뉴에서 클라이언트로 전달하기 등이 있습니다. 앱마다 버튼 이름은 ‘구독 추가’, ‘URL에서 가져오기’, ‘원격 구성’ 또는 ‘구독 관리’로 다를 수 있지만 핵심 입력값은 동일한 구독 주소입니다.
- 구독 서비스 패널에 로그인한 뒤 iOS 또는 일반 구독 메뉴를 찾습니다.
- 구독 링크를 복사하고 브라우저 주소창에서 직접 열어 장기간 보관하지 않도록 합니다.
- 클라이언트의 구독 관리 화면으로 이동해 링크 또는 클립보드에서 가져오기를 선택합니다.
- 구독을 쉽게 식별할 수 있는 이름을 로컬에서 지정한 뒤 업데이트를 실행합니다.
- 서버 목록이 표시되는지 확인하고 프로토콜 유형을 클라이언트가 인식하는지 점검합니다.
붙여 넣은 뒤 깨진 문자 한 줄, 웹페이지 소스 또는 다운로드 실패 메시지만 나타난다면 반복해서 시도하지 마세요. 링크가 완전히 복사되지 않았거나 구독이 만료되었거나 현재 네트워크가 구독 인터페이스에 접근하지 못하거나 클라이언트가 기대하는 구독 형식이 다를 수 있습니다. 서비스 패널로 돌아가 링크를 다시 복사하고 해당 클라이언트 전용 가져오기 메뉴가 있는지 확인하세요.
QR 코드가 링크보다 본질적으로 안전한 것은 아닙니다. QR 코드는 정보를 그래픽으로 표현한 것일 뿐이므로 공개 스크린샷에 포함되면 다른 사람도 구독 주소를 읽을 수 있습니다. 가져오기가 끝나면 전체 QR 코드가 담긴 임시 이미지를 삭제하고 구독 링크를 신뢰할 수 없는 메모나 채팅 공간에 동기화하지 마세요.
시스템 구성을 승인할 때 실제로 일어나는 일
클라이언트가 처음 연결을 시작하면 iOS에 VPN 구성 추가를 묻는 시스템 안내가 표시됩니다. 일반적인 웹 팝업이 아니라 운영체제가 네트워크 확장 권한을 확인하는 절차입니다. 승인해야 클라이언트가 시스템 인터페이스를 호출해 터널 또는 프록시 채널을 만들 수 있습니다. 기기 설정에 따라 기기 인증으로 확인해야 할 수도 있습니다.
승인이 완료되면 시스템 설정에 해당 구성이 나타납니다. 이 구성은 네트워크 요청을 클라이언트의 네트워크 확장이 처리하도록 전달하지만 서버 주소, 프로토콜 매개변수와 분할 라우팅 규칙은 대개 클라이언트가 관리합니다. 따라서 클라이언트 삭제, 시스템 구성 삭제와 구독 삭제는 서로 다른 계층에 영향을 줍니다. 문제를 해결할 때 이를 같은 작업으로 취급하지 마세요.
| 상태 | 의미 | 추가로 확인할 사항 |
|---|---|---|
| 구독을 가져옴 | 클라이언트가 원격 구성을 읽었습니다 | 서버에 연결할 수 있는지, 매개변수가 호환되는지 |
| 시스템 구성을 승인함 | 클라이언트가 네트워크 채널을 만드는 데 필요한 시스템 권한을 얻었습니다 | 연결이 시작되었는지, 분할 라우팅 모드가 예상과 맞는지 |
| 클라이언트에 연결됨으로 표시됨 | 로컬 네트워크 확장이 연결 상태에 들어갔습니다 | 원격 출구, DNS와 대상 앱의 트래픽이 실제로 서버를 통과하는지 |
| 출구 지역이 변경됨 | 테스트 요청이 선택한 원격 서버를 통해 전달되었습니다 | 다른 앱도 같은 규칙을 따르는지 |
상태 표시줄 아이콘은 보조 정보일 뿐입니다. 시스템 인터페이스와 표시 영역에 따라 VPN 표시 방식이 다를 수 있으므로 아이콘만 보고 모든 요청이 예상대로 전달된다고 판단할 수 없습니다. 클라이언트 연결 로그, 출구 주소 조회와 대상 앱의 실제 접속 결과를 함께 확인하는 것이 더 정확합니다.
실수로 거부를 눌렀다면 보통 연결을 다시 시작해 클라이언트가 권한을 재요청하도록 할 수 있습니다. 시스템 구성은 존재하지만 상태가 이상하다면 먼저 연결을 중지한 뒤 클라이언트에서 다시 설정하세요. 구성이 명백히 손상되었거나 클라이언트 안내에서 재구성을 요구하는 경우에만 기존 구성을 삭제하고 다시 승인하는 것이 좋습니다. 단순한 서버 문제를 전체 구성 초기화로 키우지 마세요.
서버 유형: 직접 연결, 중계와 IEPL의 차이
구독을 가져온 뒤 서버 이름에는 지역과 접속 유형이 포함되는 경우가 많습니다. 지역은 원격 출구의 대략적인 위치를 결정하고 접속 유형은 로컬 네트워크에서 원격 출구까지의 경로에 영향을 줍니다. 초보자는 서버 이름의 ‘고속’이라는 표현만 볼 것이 아니라 직접 연결, 중계와 IEPL의 기본적인 차이를 이해해야 합니다.
직접 연결은 기기에서 원격 서버로 바로 연결하는 방식입니다. 경로는 단순하지만 체감 품질은 로컬 통신사와 대상 지역 사이의 공용 네트워크 경로에 더 크게 좌우됩니다. 네트워크가 혼잡하거나 망 간 연동이 변하거나 국제 경로가 불안정할 때 패킷 손실과 지연이 더 커질 수 있습니다.
중계 연결은 먼저 가까운 입구 또는 더 적합한 경로로 연결한 뒤 중계 네트워크를 통해 원격 출구로 전달합니다. 접속 경로를 개선하는 역할이지만 전체 인터넷 전송 과정이 전용 네트워크에 있다는 뜻은 아닙니다. 중계 품질은 입구, 전달 경로와 출구가 얼마나 잘 조합되는지에 따라 달라집니다.
IEPL 전용 회선은 일반적으로 특정 접속 구간을 국제 이더넷 전용 회선으로 전송하는 방식을 뜻합니다. 일부 공용 네트워크 경로의 불확실성을 줄일 수 있지만 대상 웹사이트 측에서는 여전히 일반적인 인터넷 연결이 필요합니다. IEPL 표시를 모든 앱과 모든 시간대의 고정 속도 보장으로 이해해서는 안 되며, 회선 설계 정보로 보아야 합니다.
- ✅ 지역 제한이 있는 서비스를 이용할 때는 대상 서비스가 지원하는 지역과 일치하는 출구를 우선 선택하세요
- ✅ 일반 웹과 메신저는 경로가 안정적인 가까운 서버부터 선택하세요
- ✅ 현재 서버에 문제가 있으면 같은 지역의 다른 접속 유형으로 비교해 보세요
- ❌ 서버 이름의 형용사를 실제 연결 확인 대신 사용하지 마세요
- ❌ 짧은 시간 안에 출구 지역을 자주 바꾸지 마세요. 대상 서비스의 보안 정책이 작동할 수 있습니다
선택 원칙: 지역 일치는 서비스가 인식하는 출구 위치를 결정하고, 접속 유형은 해당 출구까지의 경로 품질에 영향을 줍니다. 먼저 지역 조건을 충족한 다음 같은 지역 서버의 안정성을 비교하는 편이 한 번의 속도 수치만 좇는 것보다 실용적입니다.
연결 후 실제로 작동하는지 확인하는 방법
클라이언트에 ‘연결됨’이라고 표시되는 것은 로컬 연결 과정에서 즉시 오류가 발생하지 않았다는 뜻일 뿐입니다. 실제 작동 여부는 출구 주소, DNS 확인과 앱 접속 세 가지 측면에서 검증해야 합니다. 테스트 전에 기존 연결을 유지할 수 있는 페이지를 닫고 새 브라우저 탭에서 신뢰할 수 있는 출구 주소 조회 페이지를 열어 표시된 국가 또는 지역이 선택한 서버와 일치하는지 확인하세요.
그다음 DNS를 확인합니다. 도메인에 접속하려면 먼저 DNS 확인이 완료되어야 합니다. 분할 라우팅 규칙이나 클라이언트 DNS 설정이 잘못되면 웹 트래픽은 원격 서버를 통과하면서 DNS 요청은 로컬 네트워크에서 처리될 수 있습니다. 이를 DNS 누출이라고 합니다. 웹페이지가 반드시 열리지 않는 것은 아니지만 로컬 확인 환경이 노출되거나 지역 판단이 서로 충돌할 수 있습니다.
- 연결하지 않았을 때의 출구 지역과 DNS 확인 주체를 기록해 전후 비교에만 사용합니다.
- 대상 서버에 연결하고 클라이언트 상태가 안정될 때까지 기다린 뒤 테스트 페이지를 다시 엽니다.
- 출구 지역이 서버 표기와 일치하는지 확인하고 DNS 결과가 클라이언트 설정에 맞는지 점검합니다.
- 실제로 사용할 앱을 열어 로그인, 이미지 로딩과 지속적인 요청이 정상인지 확인합니다.
- 클라이언트로 돌아가 연결 로그를 확인하고 지속적인 재연결, 핸드셰이크 실패 또는 DNS 오류가 없는지 점검합니다.
브라우저 테스트는 정상인데 특정 앱만 접속되지 않는다면 대개 분할 라우팅 규칙, 앱에 남아 있는 기존 연결 또는 대상 서비스 자체의 정책과 관련이 있습니다. 해당 앱을 완전히 종료한 뒤 다시 열어 네트워크 연결을 새로 만들게 하세요. 클라이언트에 전체, 규칙과 직접 연결 모드가 있다면 현재 모드에서 해당 앱의 도메인이 대상 서버로 지정되어 있는지도 확인해야 합니다.
iCloud 전용 프록시, 브라우저 개인정보 보호 기능과 콘텐츠 필터 확장도 브라우저가 확인하는 출구 결과를 바꿀 수 있습니다. 문제를 해결할 때는 테스트 조건을 동일하게 유지하고 서버를 바꾸면서 여러 시스템 기능을 동시에 수정하지 마세요. 한 번에 하나의 변수만 바꿔야 문제가 서버, 클라이언트 규칙 또는 다른 네트워크 확장 중 어디에서 비롯되었는지 판단할 수 있습니다.
분할 라우팅 규칙이 어떤 요청을 서버로 보낼지 결정합니다
분할 라우팅은 앱을 단순히 ‘연결’과 ‘연결하지 않음’으로 나누는 기능이 아닙니다. 클라이언트가 도메인, 주소, 규칙 집합 또는 프로세스 정보를 기준으로 요청을 프록시, 직접 연결 또는 거부 중 어디로 보낼지 결정하는 방식입니다. iOS 클라이언트는 일반적으로 시스템 네트워크 확장이 제공하는 범위 안에서 작동하므로 클라이언트마다 인식하고 처리할 수 있는 트래픽 범위가 완전히 같지는 않습니다.
규칙 모드는 일상적인 사용에 적합합니다. 로컬 서비스는 직접 연결로 유지하고 국제 경로가 필요한 도메인은 원격 서버로 보냅니다. 전체 모드는 더 넓은 범위의 트래픽을 현재 서버로 보내 규칙 누락을 확인하기 쉽지만 로컬 사이트까지 우회시킬 수 있습니다. 직접 연결 모드는 보통 프록시 규칙을 잠시 중지하거나 로컬 네트워크가 정상인지 확인할 때 사용합니다.
대상 웹사이트의 첫 화면은 열리지만 로그인, 이미지, 동영상 또는 인증 리소스가 로드되지 않는다면 같은 서비스가 사용하는 여러 도메인이 서로 다른 경로로 배정되었을 수 있습니다. 예를 들어 메인 사이트는 원격 서버를 통과하지만 정적 리소스는 직접 연결되면 지역이나 세션이 일치하지 않을 수 있습니다. 이때는 클라이언트 로그에서 도메인이 어떤 규칙에 일치했는지 확인하고 신뢰할 수 있는 규칙을 조정하세요. 클라이언트를 계속 재설치할 필요는 없습니다.
대상 앱 접속 이상
├─ 출구 지역이 다름 → 현재 서버와 모드 확인
├─ 일부 리소스만 실패 → 도메인 분할 라우팅과 DNS 확인
├─ 모든 서버가 시간 초과 → 로컬 네트워크와 구독 업데이트 확인
├─ 단일 서버만 실패 → 같은 지역 서버로 비교
└─ 잦은 연결 끊김과 재연결 → 프로토콜 호환성과 네트워크 제한 확인DNS 설정도 분할 라우팅 로직과 함께 구성해야 합니다. 클라이언트가 원격 확인, 규칙에 따른 확인 서버 선택 또는 DNS 요청의 터널 전송을 지원한다면 클라이언트가 권장하는 설정을 우선 사용하세요. 설명이 불분명한 DNS 구성 파일을 여러 개 임의로 추가하지 마세요. 시스템, 클라이언트와 브라우저 계층에서 동시에 확인 경로를 바꾸면 문제를 오히려 찾기 어려워집니다.
일반적인 오류 해결 순서
문제 해결에서 가장 중요한 것은 범위를 좁히는 일입니다. 문제가 구독 읽기, 시스템 승인, 프로토콜 핸드셰이크, 원격 서버 또는 대상 앱 중 어디에서 발생했는지 먼저 판단하세요. 모든 구성을 한 번에 삭제하고 재설치하면 철저해 보이지만 기존 규칙과 비교 조건을 잃게 되고 실제 원인도 확인할 수 없습니다.
구독을 가져온 후 서버가 표시되지 않음
먼저 서비스 패널로 돌아가 구독 상태를 확인한 다음 전체 링크를 다시 복사해 업데이트하세요. 클라이언트가 형식을 인식하지 못한다고 표시하면 패널에 해당 클라이언트 전용 메뉴가 있는지 확인합니다. 브라우저에서는 패널에 접속되지만 클라이언트가 구독을 가져오지 못한다면 현재 네트워크 또는 기존 분할 라우팅 규칙이 클라이언트를 차단하는지도 점검해야 합니다.
모든 서버의 연결 시간이 초과됨
먼저 로컬 네트워크 환경을 바꿔 비교하고 네트워크를 제어할 수 있는 다른 구성을 일시 중지하세요. Shadowsocks, Trojan 등 TCP 기반 서버는 연결되지만 Hysteria2 또는 TUIC가 계속 실패한다면 현재 네트워크가 UDP 또는 QUIC에 적합하지 않을 수 있습니다. 이때는 알 수 없는 매개변수를 수정하지 말고 클라이언트와 구독이 모두 지원하는 다른 프로토콜을 사용하세요.
특정 서버 하나만 실패함
같은 구독의 다른 서버가 정상이라면 클라이언트 승인과 기본 네트워크 전체에는 문제가 없을 가능성이 높습니다. 같은 지역의 다른 서버를 선택해 확인하고 잠시 후 구독을 업데이트하세요. 서버 주소, 포트, TLS 서버 이름 또는 전송 경로를 임의로 수정하지 마세요. 이러한 매개변수는 서버 측과 일치해야 합니다.
연결됨으로 표시되지만 웹페이지가 열리지 않음
먼저 규칙이 더 단순한 모드로 전환해 확인한 다음 DNS와 클라이언트 로그를 점검하세요. 로그에 인증서 또는 핸드셰이크 관련 오류가 나타나면 기기의 날짜와 시간이 정상인지 확인합니다. Trojan, VMess 또는 VLESS의 TLS 구성은 올바른 서버 이름과 시간 검증에 의존하므로 검증을 임의로 끄는 것은 적절한 해결책이 아닙니다.
화면을 잠그면 연결이 끊김
iOS는 백그라운드 활동을 관리하지만 시스템 네트워크 확장 방식에 맞는 연결은 클라이언트 화면이 계속 전면에 있어야만 유지되어서는 안 됩니다. 클라이언트에서 주문형 연결 또는 자동 재연결 옵션이 활성화되어 있는지 확인하고 시스템 구성이 여전히 존재하는지도 점검하세요. 백그라운드 재연결 방식은 클라이언트마다 다르므로 개발자 안내를 기준으로 하세요.
- ✅ 먼저 구독이 업데이트되는지 확인한 뒤 서버 연결 가능 여부를 판단하세요
- ✅ 같은 지역의 다른 서버로 변수를 하나만 바꿔 비교하세요
- ✅ 핸드셰이크, DNS, 시간 초과와 재연결 관련 로그를 확인하세요
- ✅ 기존 구성을 보존하고 원인을 확인한 뒤 재구성 여부를 결정하세요
- ❌ 인증서 검증을 임의로 끄거나 서버 측 매개변수를 수정하지 마세요
- ❌ 프로토콜, DNS, 분할 라우팅과 시스템 구성을 동시에 변경하지 마세요
최종 확인: 구독이 업데이트되고, 시스템 구성이 승인되며, 대상 서버에 안정적으로 연결되고, 출구 지역이 예상과 일치하고, DNS가 원하지 않는 확인 경로로 돌아가지 않으며, 실제 앱도 같은 분할 라우팅 규칙을 따라야 가져오기부터 적용까지의 검증이 완료됩니다.
일상적인 사용에서 지켜야 할 보안 습관
구독 링크는 자격 증명처럼 관리해야 합니다. 기기를 바꾸거나 특정 클라이언트의 사용을 중단했다면 서비스 패널에서 구독 자격 증명을 갱신한 뒤 계속 사용할 신뢰할 수 있는 기기에서 다시 가져오세요. 링크가 공개 페이지, 공유 스크린샷 또는 신뢰할 수 없는 도구에 노출된 적이 있다면 로컬 채팅 기록만 삭제하지 말고 즉시 변경해야 합니다.
클라이언트와 시스템을 모두 정상적으로 업데이트하세요. 프로토콜 구현, 시스템 네트워크 확장 인터페이스와 대상 사이트의 네트워크 정책은 바뀔 수 있으므로 오래된 버전을 계속 사용하면 구독 분석 실패나 연결 호환성 문제가 생길 수 있습니다. 업데이트 전 개발자 안내를 확인하고 중요한 규칙은 클라이언트의 내보내기 기능으로 안전하게 보관하세요.
국제 경로에 연결한다고 해서 웹사이트 자체의 보안 기능이 대체되는 것은 아닙니다. 접속 도메인이 올바른지 확인하고 웹사이트가 제공하는 계정 보호 방식을 사용하며 신뢰할 수 없는 페이지에 민감한 정보를 입력하지 마세요. VPN은 기기와 원격 출구 사이의 네트워크 경로를 주로 바꿀 뿐, 다운로드 내용이나 웹 스크립트 또는 계정 작업의 신뢰성을 자동으로 판단하지 않습니다.
VPNYQ에서 클라이언트와 구독 메뉴를 제공할 때는 이메일 주소 없이도 가입할 수 있습니다. 가져오기가 끝나면 먼저 대상 지역에 맞는 서버를 선택하고 이 글의 출구, DNS와 앱 접속 절차에 따라 하나씩 확인하세요. 문제가 생기면 로그의 오류 유형과 서버 이름을 기록해 지원팀에 전달하세요. 단순히 ‘연결되지 않는다’고 말하는 것보다 원인을 파악하기 쉽습니다.