“가장 안정적인 VPN 추천”을 논할 때 한 번의 속도 측정만으로 결론을 내릴 수는 없습니다. 일상적인 사용 경험을 좌우하는 것은 연결이 원활하게 수립되는지, 지속 전송 중 끊기지 않는지, 네트워크 전환 후 복구되는지, 피크 시간대에도 출구 회선 성능을 예측할 수 있는지입니다. 안정성은 특정 노드 이름이나 프로토콜 표기가 아니라 로컬 네트워크, 접속 지점 품질, 국제 연결, 출구 상태, 프로토콜 구현, 클라이언트 설정이 함께 만들어 냅니다.
따라서 이 글에서는 테스트 조건이 빠진 속도 스크린샷을 사용하지 않으며, 우연히 나온 최고 속도를 추천 기준으로 삼지도 않습니다. 더 신뢰할 수 있는 방법은 기기, 접속 네트워크, 클라이언트, 대상 서비스를 고정한 뒤 연결 성공률과 끊김 여부를 각각 관찰하고, 회선 구조와 오류 로그를 함께 살펴 원인을 찾는 것입니다. 이렇게 얻은 결론이 모든 지역에 적용되지는 않더라도 자신의 실제 네트워크 환경에서는 재현할 수 있습니다.
안정적인 VPN은 어떤 지표를 봐야 할까
연결 성공률은 가장 기본적인 지표입니다. 연결을 시작한 뒤 핸드셰이크가 완료되고, 프록시 채널이 구축되며, 도메인이 해석되고, 실제로 대상 페이지나 앱에 접속할 수 있을 때만 성공으로 기록해야 합니다. 클라이언트에 “연결됨”이 표시된다고 해서 실제 트래픽이 정상적으로 흐른다는 뜻은 아닙니다. DNS 조회가 실패했거나, 라우팅이 터널로 들어가지 않았거나, 출구에서 대상 서비스에 접근할 수 없다면 해당 연결은 사용할 수 있는 상태로 볼 수 없습니다.
끊김률은 연속 사용 과정에서 관찰해야 합니다. 클라이언트가 연결 종료를 직접 알리는 명시적인 끊김은 쉽게 확인할 수 있습니다. 반면 페이지가 계속 로딩 중이거나, 스트리밍이 버퍼링되거나, 메신저 메시지가 전송 중 상태에 머문 뒤 클라이언트가 자동으로 복구되는 암묵적인 끊김이 더 흔합니다. 클라이언트 화면만 보면 이런 짧은 중단을 놓치기 쉽습니다.
| 관찰 항목 | 판단 방법 | 흔한 오해 | 연관 가능성이 높은 구간 |
|---|---|---|---|
| 연결 성공률 | 연결 시작부터 대상 서비스에 정상적으로 접속할 때까지 | 클라이언트에 연결됨이 표시되는지만 확인 | 핸드셰이크, 접속 지점, 인증, DNS |
| 끊김 여부 | 연속 세션이 중단되거나 재연결되는지 관찰 | 일시적인 버벅임을 모두 출구 문제로 판단 | 회선 변동, UDP 제한, 클라이언트 절전 |
| 복구 능력 | 네트워크 전환 후 사용할 수 있는 채널을 다시 구축할 수 있는지 | 고정된 유선 네트워크에서만 테스트 | 프로토콜 전환, 시스템 백그라운드 정책 |
| 피크 시간대 성능 | 시간대별 연결과 지속 전송을 비교 | 한산한 시간대의 최고 속도로 장기 성능을 대표 | 접속 지점 혼잡, 국제 연결 조정, 출구 부하 |
| 서비스별 일관성 | 웹, 동영상, 통화, 다운로드를 각각 검증 | 하나의 속도 측정 사이트로 모든 앱을 판단 | 분할 라우팅, 프로토콜 특성, 대상 사이트 라우팅 |
실제로 기록할 때는 두 가지 간단한 공식을 사용할 수 있습니다. 연결 성공률은 사용 가능한 연결을 성공적으로 구축한 횟수를 전체 연결 시도 횟수로 나눈 값이고, 끊김률은 사용자가 직접 끊지 않았는데 중단된 세션 수를 전체 테스트 세션 수로 나눈 값입니다. 여기서 중요한 것은 그럴듯하게 정밀한 백분율을 얻는 것이 아니라 판정 기준을 일관되게 유지하는 것입니다. 어떤 테스트에서는 “페이지가 열림”을 성공으로 기록하고, 다른 테스트에서는 “클라이언트 핸드셰이크 완료”만 요구한다면 결과를 비교할 수 없습니다.
- ✅ 연결 후 출구 IP가 변경되었는지 확인하고 대상 서비스가 실제로 로드되는지 점검합니다.
- ✅ 웹 접속, 지속 다운로드, 실시간 통신을 함께 관찰해 단일 서비스가 문제를 가리지 않도록 합니다.
- ✅ 노드 직접 전환, 기기 절전, 로컬 네트워크 중단은 비정상적인 끊김과 별도로 표시합니다.
- ✅ 클라이언트 로그에 기록된 핸드셰이크 실패, 시간 초과, 라우팅 및 DNS 오류 정보를 보관합니다.
- ❌ 한 번의 최고 속도로 연결 성공률과 지속 세션 테스트를 대신하지 않습니다.
- ❌ 모든 버퍼링을 회선 끊김으로 보지 않습니다. 대상 서비스 자체의 속도 제한이나 혼잡일 수도 있습니다.
IEPL 전용 회선, 중계와 직접 연결의 차이
직접 연결 회선은 클라이언트가 해외 접속 지점이나 출구 노드에 바로 연결하는 방식으로, 경로가 단순하고 추가 전달 단계가 적습니다. 국내 통신사의 국제 출구 품질이 좋다면 오버헤드가 낮을 수 있지만, 국제 상호접속 혼잡, 우회 라우팅, 망 간 품질 변동의 영향을 더 직접적으로 받습니다. 낮에 원활했던 직접 연결 노드도 피크 시간대에는 패킷 손실이 늘거나 핸드셰이크 시간 초과가 발생할 수 있습니다.
중계 회선은 먼저 가까운 접속 지점에 연결한 뒤 서비스 제공자가 관리하는 중간 회선을 통해 출구로 전달합니다. 중계가 모든 네트워크 문제를 없애 주는 것은 아니지만, 사용자가 복잡한 국제 라우팅을 직접 거치는 상황을 줄일 수 있습니다. 안정성은 접속 지점의 분포, 전달 용량, 조정 정책, 중계 구간과 출구 사이의 품질에 달려 있습니다. 접속 지점 자체가 혼잡하거나 조정 과정에서 너무 많은 트래픽이 하나의 출구에 몰리면 중계 회선도 흔들릴 수 있습니다.
IEPL은 일반적으로 기업 간 연결을 위한 국제 이더넷 전용 회선을 의미합니다. 일반 공용망 중계보다 라우팅과 용량 계획을 더 통제하기 쉽고, 공용 인터넷의 예측하기 어려운 우회 경로에도 영향을 덜 받는 편입니다. 그러나 “IEPL”이라는 표기만으로 최종 사용 경험의 안정성이 보장되지는 않습니다. 사용자의 국내 회선에서 전용 회선 접속 지점까지의 품질, 이후 전달 장비, 출구 IP 상태, 서비스 제공자의 용량 관리가 모두 결과에 영향을 줍니다. 판단할 때는 노드 이름보다 장기간 재현되는 성능을 확인해야 합니다.
| 회선 유형 | 주요 경로 | 안정성 특징 | 테스트 우선 항목 |
|---|---|---|---|
| 직접 연결 | 로컬 네트워크에서 해외 노드로 직접 연결 | 구조는 단순하지만 국제 공용망 품질에 더 크게 의존 | 피크 시간대 패킷 손실, 망 간 라우팅 변화 |
| 공용망 중계 | 로컬 네트워크에서 접속 지점으로 연결한 뒤 출구로 전달 | 접속 지점은 가깝지만 중간 회선과 조정 품질에 따라 달라짐 | 접속 지점 혼잡, 출구 전환, 복구 속도 |
| IEPL 전용 회선 | 로컬 접속 지점에서 관리되는 국제 회선으로 연결 | 경로를 더 통제할 수 있지만 접속 지점과 출구 자원의 영향을 받음 | 지속 전송, 접속 네트워크별 일관성 |
프로토콜 안정성은 어떻게 비교할까
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC은 설계의 중점이 서로 다르므로 네트워크 조건을 배제한 “가장 안정적인 프로토콜”은 존재하지 않습니다. 프로토콜이 안정적으로 작동하는지는 먼저 서버 구현과 클라이언트 호환성에 달려 있고, 그다음 현재 네트워크에서 해당 전송 방식이 원활하게 통과할 수 있는지에 좌우됩니다.
Shadowsocks, VMess, Trojan과 VLESS
Shadowsocks는 암호화 프록시 프로토콜로, 클라이언트 생태계가 성숙했고 설정도 비교적 간단합니다. 일반적인 웹 이용, 다운로드, 분할 라우팅에 적합하지만 최종 성능은 하위 전송 방식과 노드 회선에 따라 달라집니다. VMess는 인증 및 전송 설정 기능을 제공하며 초기 프록시 구축에서 자주 사용되었습니다. 설정 항목이 많을수록 클라이언트와 서버의 매개변수가 일치하지 않아 연결에 실패하기 쉽습니다.
Trojan은 일반적으로 TLS 위에서 작동하며, 연결 수립 과정은 인증서, 도메인, 시스템 시간, TLS 매개변수에 의존합니다. 인증서 검증에 실패하거나 도메인 해석에 문제가 있거나 클라이언트 시간이 어긋나면 일반적인 네트워크 시간 초과가 아니라 핸드셰이크 실패가 표시될 수 있습니다. VLESS는 가벼운 인증을 중점으로 하며 완전한 암호화를 자체적으로 제공하지 않습니다. 보통 TLS, REALITY 또는 다른 보안 전송 방식과 함께 사용합니다. VLESS를 평가할 때는 외부 전송 방식까지 함께 테스트해야 하며 프로토콜 이름만 비교해서는 안 됩니다.
Hysteria2와 TUIC
Hysteria2와 TUIC은 QUIC 및 UDP를 기반으로 하며 지연, 패킷 손실, 대역폭 변동이 있는 네트워크에서는 기존 TCP 전송보다 빠르게 복구하고 TCP 중첩으로 인한 문제를 줄일 수 있습니다. 다만 일부 공용 네트워크, 회사 네트워크, 라우터 장비는 UDP를 제한해 연결 자체가 실패하거나 사용 가능한 대역폭이 비정상적으로 줄거나 빈번한 전환이 발생할 수 있습니다. 이런 경우에는 무관한 설정을 반복해서 수정하기보다 TCP 및 TLS 기반 예비 설정으로 전환해야 합니다.
| 프로토콜 | 전송 특성 | 안정성 장점 | 우선 점검 항목 |
|---|---|---|---|
| Shadowsocks | 암호화 프록시, 비교적 직접적인 구축 방식 | 클라이언트 지원 범위가 넓고 분할 라우팅 설정이 성숙함 | 암호화 방식, 포트, 회선 품질 |
| VMess | 인증 및 전송 매개변수 조합이 다양함 | 여러 전송 방식에 적용 가능 | 클라이언트 호환성, 시간 및 매개변수 일치 여부 |
| Trojan | 일반적으로 TLS 위에서 전송 | TCP 사용성이 좋은 네트워크에 적합 | 인증서, 도메인 해석, TLS 핸드셰이크 |
| VLESS | 가벼운 인증, 외부 보안 전송에 의존 | 조합이 유연하고 프로토콜 오버헤드를 조절할 수 있음 | 외부 전송 방식, 서버 및 클라이언트 구현 |
| Hysteria2 | QUIC 및 UDP 기반 | 변동이 있는 회선에 대응 가능 | UDP 도달성, 혼잡, 라우팅 장비 |
| TUIC | QUIC 및 UDP 기반 | 네트워크 변화 시 빠르게 복구 | UDP 제한, 클라이언트 버전 호환성 |
연결 성공률 실측 재현 절차
재현 가능한 테스트의 핵심은 변수를 통제하는 것입니다. 먼저 기기 하나, 접속 네트워크 하나, 동일한 클라이언트 버전, 동일한 대상 서비스를 정하고, 비교하는 동안 프로토콜, 노드, DNS, 분할 라우팅 규칙을 동시에 변경하지 마세요. 한 번에 여러 변수를 바꾸면 사용 경험이 좋아져도 어떤 조정이 효과가 있었는지 알 수 없습니다.
- 기준선 설정. 프록시를 잠시 비활성화하고 로컬 네트워크에 뚜렷한 끊김이 없는지 확인한 뒤 현재 네트워크에서 대상 서비스에 접속 가능한 상태를 기록합니다. 기준선에 문제가 있다면 먼저 라우터, 무선 신호, 통신사 접속 문제를 해결해야 합니다.
- 클라이언트 고정. 동일한 코어와 동일한 권한 모드로 후보 노드를 가져옵니다. 시스템 프록시 모드와 TUN 모드의 결과를 한데 섞지 마세요. 두 모드는 트래픽을 가로채는 범위가 다릅니다.
- 하나씩 연결. 매번 직접 연결을 끊은 뒤 다시 연결을 시작하고 핸드셰이크가 완료될 때까지 기다린 다음 미리 정한 대상 페이지나 앱을 엽니다. 실제 서비스 트래픽이 정상적으로 흐를 때만 성공으로 기록합니다.
- 세션 유지. 웹 로딩, 파일 전송, 실시간 통신을 연속으로 진행하면서 시간 초과, 멈춤, 자동 재연결, 출구 변경이 발생하는지 관찰합니다. 기기를 직접 절전 상태로 전환하기 전에는 해당 상황을 표시해 두어야 합니다.
- 시간대별 재테스트. 평소 사용하는 시간대와 네트워크가 혼잡한 시간대를 모두 포함해야 합니다. 한산한 시간대에만 테스트하면 접속 지점과 국제 회선이 혼잡해진 뒤의 조정 성능을 판단할 수 없습니다.
- 접속 네트워크 변경. 평소 사용하는 유선 네트워크, 무선 네트워크, 모바일 데이터 환경에서 각각 검증합니다. 특정 접속 방식에서만 프로토콜이 실패한다면 보통 로컬 네트워크 정책이나 전송 호환성을 점검해야 합니다.
- 로그 확인. 인증 실패, 핸드셰이크 시간 초과, DNS 오류, 라우팅 실패, 원격 종료를 각각 분류합니다. 오류마다 해결 방향이 다르므로 모두 “노드 불안정”으로 묶어서는 안 됩니다.
테스트 기록
회선 유형: 직접 연결 / 중계 / IEPL
프로토콜 유형: TCP 전송 / UDP 전송
연결 결과: 서비스 사용 가능 / 핸드셰이크 실패 / DNS 실패
세션 상태: 정상 유지 / 일시 중단 / 자동 재연결
접속 환경: 고정 유선 네트워크 / 무선 네트워크 / 모바일 데이터
로그 분류: 인증 / 핸드셰이크 / 라우팅 / DNS / 원격 종료여러 회선을 비교해야 한다면 각 회선에 동일한 필드로 기록을 남기고, 느낌에 따라 “빠름”이나 “느림”이라고 적지 마세요. 장애가 특정 시간대, 특정 프로토콜, 특정 접속 지점, 특정 대상 서비스에 집중되는지 확인하는 것이 중요합니다. 예를 들어 모든 UDP 프로토콜이 실패하고 TCP는 정상이라면 현재 네트워크가 UDP를 제한할 가능성이 큽니다. 특정 도메인만 열리지 않는다면 먼저 DNS와 분할 라우팅 규칙을 점검해야 합니다.
DNS 누출과 분할 라우팅 규칙이 가짜 끊김을 만드는 이유
프록시 채널은 이미 구축되었지만 DNS 조회가 여전히 로컬 네트워크에서 처리되면, 해석 결과와 출구 지역이 일치하지 않거나 도메인이 접근할 수 없는 주소로 해석될 수 있습니다. 또는 대상 서비스가 DNS 위치와 출구 위치의 차이를 바탕으로 추가 확인을 실행할 수도 있습니다. 이런 현상은 노드가 끊긴 것으로 오해하기 쉽습니다. 확인할 때는 웹페이지를 새로 고치는 데 그치지 말고 출구 IP와 DNS 해석 경로를 함께 점검해야 합니다.
시스템 프록시 모드에서는 시스템 프록시 설정을 따르는 앱만 프록시 채널로 들어갑니다. 일부 명령줄 도구, 게임, 백그라운드 업데이트 서비스, 자체 네트워크 스택을 구현한 앱은 직접 연결될 수 있습니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 넓은 범위의 트래픽을 처리하지만 시스템 권한이 필요하며, 보안 소프트웨어, 가상 머신, 다른 VPN, 기존 라우팅 규칙과 충돌하기도 쉽습니다.
분할 라우팅 규칙은 어떤 도메인과 주소가 프록시를 거치고 어떤 항목이 직접 연결될지 결정합니다. 규칙이 오래되면 대상 서비스가 새로 추가한 도메인이 잘못 직접 연결될 수 있습니다. 규칙 순서가 적절하지 않으면 포괄적인 직접 연결 규칙이 먼저 적용되어 메인 사이트는 열리지만 이미지, 로그인 API, 동영상 리소스가 실패할 수 있습니다. 점검할 때 잠시 전체 프록시를 사용해 확인할 수 있습니다. 전체 모드에서는 정상이고 규칙 모드에서만 문제가 발생한다면 원인은 대개 규칙 매칭이나 DNS 정책에 있으며 회선 자체의 문제는 아닙니다.
- ✅ 브라우저에 표시되는 출구 IP가 선택한 노드 지역과 일치하는지 확인합니다.
- ✅ DNS 요청이 로컬 해석, 원격 해석, 클라이언트 내장 해석 중 어떤 방식으로 처리되는지 확인합니다.
- ✅ 로드되지 않는 리소스 도메인에 최종적으로 적용된 분할 라우팅 규칙을 확인합니다.
- ✅ 시스템에서 다른 네트워크 도구가 기본 라우팅이나 DNS를 동시에 변경하고 있지 않은지 확인합니다.
- ❌ 메인 페이지가 열렸다고 모든 하위 리소스가 프록시를 통과했다고 판단하지 마세요.
- ❌ 잘못된 규칙을 전체 모드로 장기간 가리지 말고 구체적인 매칭 항목을 찾아 수정하세요.
구독 링크도 정확히 이해해야 합니다. 일반적으로 노드 설정 모음을 가져오는 주소이며, 서비스 트래픽이 통과하는 터널은 아닙니다. 클라이언트가 구독을 업데이트하면 서버 주소, 포트, 프로토콜, 전송 매개변수가 로컬 설정에 기록됩니다. 구독 업데이트가 성공했다고 모든 노드에 연결할 수 있는 것은 아닙니다. 반대로 구독을 잠시 새로 고칠 수 없어도 클라이언트에 이미 캐시된 노드는 계속 사용할 수 있습니다.
플랫폼별 클라이언트 안정성 차이
Windows에서는 시스템 프록시와 TUN 모드 전환, 가상 네트워크 어댑터 드라이버, 방화벽 규칙, 절전 모드 복귀에서 문제가 자주 발생합니다. 시스템 프록시는 브라우저와 프록시 설정을 따르는 데스크톱 앱에 적합합니다. 더 많은 프로그램을 적용해야 한다면 TUN을 사용할 수 있지만, 가상 인터페이스가 정상적으로 시작되었고 다른 네트워크 소프트웨어가 기본 라우팅을 차지하려 하지 않는지 확인해야 합니다.
macOS도 시스템 프록시와 네트워크 확장 방식의 트래픽 처리를 구분합니다. 시스템 업데이트나 권한 변경 후에는 네트워크 확장에 다시 권한을 부여해야 할 수 있습니다. 클라이언트에는 연결됨으로 표시되지만 앱이 직접 연결된다면 현재 네트워크 서비스에 프록시 설정이 기록되었는지, 대상 앱이 시스템 프록시를 우회하는지 확인하세요. 무선 네트워크를 전환한 뒤 문제가 생겼다면 앱을 반복해서 새로 고치기보다 터널을 다시 구축하는 편이 원인 파악에 도움이 됩니다.
Android의 백그라운드 제한은 지속 연결에 직접 영향을 줍니다. 절전 정책이 클라이언트 프로세스를 일시 중지하면 화면이 꺼진 뒤 메시지가 지연되거나 터널이 다시 구축될 수 있습니다. 서버 측 안정성을 테스트할 때는 먼저 클라이언트가 백그라운드에서 계속 실행되도록 허용해야 합니다. 그렇지 않으면 기기 정책으로 인한 중단이 회선 문제로 잘못 기록됩니다. 항상 연결과 같은 시스템 기능을 켤 때는 앱별 제외 규칙과 클라이언트 분할 라우팅이 충돌하지 않는지도 확인해야 합니다.
iOS는 백그라운드 네트워크 활동을 엄격하게 관리합니다. 앱이 포그라운드와 백그라운드를 오가거나 기기가 잠기거나 무선 네트워크에서 셀룰러 네트워크로 전환될 때 터널이 다시 협상될 수 있습니다. 모바일 프로토콜을 평가할 때는 앱이 전면에 있을 때의 짧은 속도 측정보다 네트워크 전환 후 복구 상태를 특히 관찰해야 합니다. 구독을 가져온 뒤 일부 프로토콜이 보이지 않는다면 클라이언트 코어가 해당 설정 형식을 지원하는지 확인해야 합니다.
Linux는 라우팅, DNS, 서비스 로그를 투명하게 확인할 수 있다는 장점이 있지만, 시스템의 네트워크 관리 방식을 이해해야 합니다. 명령줄 클라이언트를 시스템 서비스로 실행한다면 시작 순서, 기본 라우팅, 리졸버 설정, 방화벽 전달을 확인해야 합니다. 데스크톱 환경, 컨테이너, 가상 머신은 각각 별도의 네트워크 네임스페이스를 사용할 수 있으므로 호스트의 출구가 정상이라고 해서 컨테이너 트래픽까지 프록시로 들어갔다고 볼 수는 없습니다.
피크 시간대 조정과 최종 선택
피크 시간대는 장기적인 안정성을 판단하는 핵심 상황입니다. 이때 로컬 접속, 통신사 백본, 국제 출구, 서비스 제공자의 접속 지점, 대상 사이트가 동시에 부하를 받을 수 있습니다. 신뢰할 수 있는 회선 조정은 모든 노드가 같은 실제 경로에 의존하게 하기보다 접속 지점이나 출구에 문제가 생겼을 때 전환할 수 있어야 합니다. 노드 목록이 많아 보여도 하위 회선이 서로 독립적이라는 뜻은 아니므로, 여러 노드에서 장애가 동시에 발생하는지를 확인해야 합니다.
주 회선을 선택할 때는 반복 가능한 연결 결과, 지속 세션의 적은 중단, 피크 시간대의 허용 가능한 변동을 우선 고려해야 합니다. 예비 회선은 가능한 한 다른 접속 지점, 다른 전송 방식, 다른 회선 유형을 사용해 동일한 장애가 주·예비 설정에 동시에 영향을 미칠 가능성을 낮추는 것이 좋습니다. 실시간 통화와 원격 작업에서는 짧은 순간의 최고 속도보다 안정적인 전송이 중요하며, 대용량 파일 다운로드에서는 지속 처리량과 재전송도 함께 고려해야 합니다.
연결이 자주 실패한다면 먼저 로그를 기준으로 인증, 핸드셰이크, 네트워크 시간 초과를 구분하세요. 인증 오류가 발생하면 구독이 업데이트되었는지와 노드 매개변수가 완전한지 확인해야 합니다. TLS 핸드셰이크 오류는 도메인, 인증서, 시스템 시간, 전송 설정을 점검해야 합니다. 네트워크 시간 초과라면 다른 접속 지점과 다른 프로토콜을 비교하세요. 연결 후 곧바로 끊긴다면 UDP 도달성, 기기 절전, 라우팅 변화, 서버의 직접 종료를 확인해야 합니다.
최종적으로 말하는 “가장 안정적”이라는 평가는 환경과 무관한 브랜드 순위가 아니라, 평소 사용하는 기기·네트워크·서비스에서 계속 재현되는 설정을 뜻합니다. 회선 유형은 경로 통제 가능성을 결정하고, 프로토콜은 패킷 손실과 네트워크 전환에 대응하는 방식을 결정하며, 클라이언트는 트래픽이 실제로 터널에 들어가는지를 좌우합니다. DNS와 분할 라우팅 규칙은 서비스가 완전히 로드될 수 있는지를 결정합니다. 이 요소들을 나누어 테스트하는 편이 노드를 계속 바꾸는 것보다 신뢰할 수 있는 결론을 얻기 쉽습니다.