출장용 VPN추천: 단기해외 접속 업무 네트워크실전 테스트 비교
1~2주 단기 출장에 필요한 호텔 Wi-Fi 연결, 화상회의와 협업 도구 사용성, 종량제·월정액 선택 기준과 테스트 결과를 정리합니다.
출장용 VPN을 고를 때 중요한 것은 노드 목록의 길이가 아니라, 단기해외 접속 업무 중 협업 플랫폼 로그인, 화상회의, 파일 전송을 안정적으로 처리하고 호텔 Wi-Fi 환경이 바뀐 뒤 빠르게 재연결할 수 있는지입니다. 이 출장용 VPN 추천 글은 홍보 문구가 아니라 재현 가능한실전 테스트를 기준으로 직결, 중계, IEPL 전용 회선의 활용 장면을 비교하고 종량제와 월정액이 각각 어떤 업무 방식에 맞는지 설명합니다.
출장지의 네트워크는 집의 고정 광대역과 다릅니다. 호텔에서는 출구를 여러 사람이 공유하거나 일부 UDP 트래픽을 제한할 수 있고, 오피스 방문자 네트워크는 웹 인증을 요구할 수 있습니다. 공항과 전시장에서는 혼잡도 쉽게 발생합니다. 집에서 정상적으로 작동한 서비스라도 출장지에서 적합하다고 단정할 수 없습니다. 따라서 테스트는 로그인, 연결 유지, 네트워크 단절 후 재연결, 회의 음성, 대용량 파일 전송을 포함해야 하며 한 번의 속도 측정만 봐서는 안 됩니다.
단기 출장 전에 확인할 네트워크 업무
먼저 업무를 나눈 뒤 회선과 요금제를 정하세요. 웹 검색과 이메일 동기화는 최초 연결 성공 여부가 중요하고, 코드 저장소·클라우드 드라이브·디자인 자료 전송은 지속 처리량이 더 중요합니다. 화상회의는 지연 시간, 지터, 패킷 손실, 경로 변화의 영향을 함께 받습니다. 다운로드 속도만 기록하면 실제 업무를 좌우하는 요소를 놓치게 됩니다.
| 업무 유형 | 주요 확인 항목 | 자주 발생하는 문제 | 선택 기준 |
|---|---|---|---|
| 웹 및 백오피스 로그인 | 최초 연결, 페이지 응답, 세션 유지 | 출구 변경 후 다시 로그인해야 함 | 같은 지역 출구를 고정해 잦은 회선 전환 줄이기 |
| 화상회의 | 음성 연속성, 화면 안정성, 화면 공유 | 호텔 네트워크 혼잡 시 끊김 또는 재연결 | 경로가 안정적인 중계 또는 전용 회선을 선택하고 예비 프로토콜 준비 |
| 협업 문서 및 채팅 | 메시지 알림, 첨부파일 업로드, 장시간 연결 | 시스템 절전 후 메시지 지연 | 클라이언트가 자동으로 연결을 복구하는지 확인 |
| 클라우드 드라이브 및 코드 저장소 | 지속 전송, 실패한 전송 재개, 업로드 성능 | 대용량 파일 전송이 회선을 모두 사용해 회의에 영향 | 시간을 나눠 전송하거나 분할 라우팅으로 대역폭 경쟁 방지 |
| 기업 내부망 | 라우팅 호환성, DNS 확인, 인증 상태 | 개인 프록시와 회사 VPN의 라우팅 충돌 | 기업 IT 규정을 우선 따르고 필요하면 지정 앱만 프록시 처리 |
기업 내부망은 특히 미리 확인해야 합니다. 일부 회사는 관리되는 기기와 지정 VPN 사용을 요구하며, 개인 해외 접속 회선은 공개 웹사이트와 일반 협업 서비스에만 사용할 수 있습니다. 두 터널이 동시에 기본 라우팅을 맡으면 기업 도메인이 조회되지 않거나 내부망 대역에 접근할 수 없고, 인증 세션이 반복해서 만료될 수 있습니다. 이런 경우 노드를 무작정 바꾸기보다 라우팅 테이블, 시스템 프록시, 회사 클라이언트의 트래픽 처리 범위를 확인해야 합니다.
- ✅ 접속해야 할 웹페이지, 협업 도구, 회의 도구와 파일 서비스를 목록으로 정리합니다.
- ✅ 회사 기기에 타사 클라이언트 설치가 허용되는지와 관리자 권한이 필요한지 확인합니다.
- ✅ 출발 전에 구독 가져오기, 예비 회선 저장, 클라이언트 업데이트를 완료합니다.
- ✅ 호텔 네트워크에서 흔한 웹 인증 절차와 네트워크 단절 후 재연결을 각각 테스트합니다.
- ✅ 서비스 문의 접점과 필요한 설정 안내를 저장해 장애가 난 기기에서만 자료를 찾는 상황을 피합니다.
- ❌ 노드 이름만으로 품질을 판단하지 말고 회의 직전에 전체 설정을 임의로 업데이트하지 않습니다.
직결, 중계, IEPL 해외 접속 회선 선택 기준
직결 회선은 현지 네트워크에서 해외 서버로 직접 연결합니다. 구조가 단순하고 실제 성능은 현지 통신사, 목적지, 당시 국제 라우팅의 영향을 크게 받습니다. 네트워크 조건이 좋다면 웹페이지, 메시지, 가벼운 파일 작업에 충분하지만, 공유 네트워크나 국제 출구가 불안정할 때는 지연 시간과 패킷 손실이 크게 달라질 수 있습니다.
중계 회선은 먼저 가깝거나 연결하기 쉬운 진입점에 접속한 뒤 중계 네트워크를 통해 목표 출구로 전달합니다. 중계의 장점은 단순히 경로를 우회하는 데 있지 않고, 변동이 큰 공용망 경로를 나누어 일부 구간을 최대한 안정적으로 관리하는 데 있습니다. 화상회의, 원격 데스크톱, 지속적인 동기화에서는 순간 최고 속도보다 안정적인 경로가 더 중요할 때가 많습니다. 다만 중계 진입점 자체가 혼잡하면 사용감도 나빠지므로 다른 진입점이나 프로토콜을 예비로 준비해야 합니다.
IEPL 전용 회선은 일반적으로 국제 이더넷 전용 회선 기술을 활용해 서로 다른 지역을 연결한 뒤 현지 출구에서 대상 서비스에 접속하는 방식을 뜻합니다. 국제 공용망 라우팅에 전적으로 의존하는 직결보다 해외 접속 구간을 통제하는 데 중점을 두며, 회의 연속성, 원격 조작, 업로드 안정성이 중요한 업무에 적합합니다. 전용 회선이라도 기기부터 모든 대상 웹사이트까지의 전 구간이 공용망에서 벗어나는 것은 아닙니다. 현지 접속 환경, 출구 이후의 대상 네트워크, 호텔 Wi-Fi가 최종 성능에 계속 영향을 줍니다.
프로토콜은 네트워크 호환성에 맞춰 선택
Shadowsocks는 구조가 가볍고 지원 클라이언트가 많아 일반적인 웹 이용과 앱 분할 라우팅에 적합합니다. VMess와 VLESS는 Xray 생태계를 지원하는 클라이언트에서 흔히 사용됩니다. VLESS 자체는 암호화를 담당하지 않으므로 일반적으로 TLS 같은 전송 보안 계층과 함께 구성해야 합니다. Trojan은 TLS와 유사한 형태로 전송하므로 일반적인 웹 트래픽만 허용하는 네트워크에서 호환성이 더 좋을 수 있지만 인증서, 도메인, 클라이언트 매개변수가 정확해야 합니다.
Hysteria2와 TUIC는 QUIC 또는 UDP를 기반으로 하며 지연 시간이 높고 패킷 손실이 잦은 환경에서 전송 효율을 중시하는 경우가 많습니다. 문제는 일부 호텔, 오피스 방문자 네트워크, 공공 핫스팟이 UDP를 제한한다는 점입니다. 이때 클라이언트 연결이 느려지거나 아예 사용할 수 없게 될 수 있습니다. 신뢰할 수 있는 단기 구성이라면 하나의 프로토콜만 준비하지 마세요. 네트워크가 허용할 때 Hysteria2 또는 TUIC를 사용하되, 호환성 전환을 위해 TCP와 TLS 기반 회선도 남겨 두는 편이 좋습니다.
호텔 Wi-Fi에서 제대로실전 테스트하는 방법
효과적인 테스트는 속도 측정 페이지를 열고 바로 끝내는 것이 아니라 실제 업무 흐름을 최대한 재현해야 합니다. 먼저 회선을 끈 상태에서 호텔 Wi-Fi 웹 인증을 완료한 뒤 클라이언트를 실행하세요. 연결 실패의 원인이 노드가 아니라 인증 페이지에서 아직 네트워크를 허용하지 않았기 때문일 수 있습니다. 페이지가 자동으로 열리지 않으면 프록시를 잠시 끄고 일반 웹페이지에 다시 접속해 인증 화면을 표시하세요.
- 기본 네트워크를 확인합니다. 회선을 끈 상태에서 자주 쓰는 웹사이트를 열어 호텔 네트워크 자체가 도메인을 정상적으로 조회하고 데이터를 전송하는지 확인합니다. 기본 네트워크가 이미 자주 끊긴다면 프로토콜 전환만으로는 일부 문제만 완화할 수 있습니다.
- 최초 연결을 테스트합니다. 준비한 TCP/TLS와 UDP 회선을 각각 시도하고, 클라이언트에 ‘연결됨’이라고 표시되는지만 보지 말고 핸드셰이크가 완료되는지 확인합니다.
- 대상 서비스를 확인합니다. 실제 업무에 필요한 협업 플랫폼, 클라우드 드라이브, 코드 저장소를 열어 로그인 상태, 첨부파일 업로드, 메시지 알림이 정상인지 확인합니다.
- 네트워크 전환을 시뮬레이션합니다. 기기를 절전 모드로 전환했다가 깨우거나 호텔 Wi-Fi와 다른 사용 가능한 네트워크 사이를 바꿔 보면서 클라이언트가 자동으로 재연결되는지, 구독 노드를 계속 선택할 수 있는지 확인합니다.
- 분할 라우팅 결과를 확인합니다. 현지 서비스, 기업 내부망, 국제 웹사이트가 각각 예상한 경로로 연결되는지 확인해 불필요한 트래픽까지 원격 출구로 보내지 않도록 합니다.
- DNS를 확인합니다.도메인 조회가 예상한 경로를 통해 처리되는지 확인하세요. 시스템 DNS와 프록시 출구가 서로 다르면 대상 서비스가 일관되지 않은 지역 정보를 인식할 수 있습니다.
DNS 누수란 앱 트래픽은 프록시나 VPN 출구를 통과하지만 도메인 조회는 현지 네트워크에 맡기는 현상입니다. 이것이 항상 바로 연결 끊김을 일으키는 것은 아니지만, 현지 네트워크가 사용하는 DNS 서비스가 노출될 수 있고 지역 판정, 콘텐츠 전달, 로그인 보안 점검이 서로 어긋날 수 있습니다. 해결 방법은 클라이언트에 따라 다릅니다. 원격 DNS를 지원하거나 프록시 트래픽에 별도 리졸버를 지정할 수 있는 클라이언트가 있고, 가상 네트워크 어댑터로 조회를 일괄 처리하는 클라이언트도 있습니다. 테스트할 때는 브라우저와 시스템 앱을 함께 확인하세요. 서로 다른 DNS 경로를 사용할 수 있습니다.
화상회의 테스트도 화면이 보이는지만 확인해서는 부족합니다. 실제 음성 대화와 화면 공유를 진행하고 파일을 업로드하면서 여러 트래픽이 동시에 발생할 때 음성이 끊기는지 관찰하는 편이 더 유용합니다. 클라우드 드라이브 동기화가 업로드 대역폭을 많이 사용하면 안정적인 회선을 이용해도 회의에 영향을 줄 수 있습니다. 출장 중에는 불필요한 동기화를 일시 중지하고 회의가 끝난 뒤 대용량 파일 전송을 재개하세요.
화상회의·협업 도구와 분할 라우팅 규칙
전체 프록시는 간단하지만 업무에 항상 적합한 것은 아닙니다. 프린터, 호텔 인증 페이지, 현지 온라인 뱅킹, 기업 내부망은 직결을 유지해야 할 수 있고, 국제 협업 플랫폼과 지정 웹페이지는 해외 출구를 거쳐야 할 수 있습니다. 분할 라우팅의 목적은 트래픽마다 적합한 경로를 사용하게 하면서 우회와 라우팅 충돌을 줄이는 것입니다.
일반적인 분할 라우팅 방식에는 도메인, 앱, IP 대역, 규칙 집합에 따른 매칭이 있습니다. 도메인 방식은 협업 플랫폼과 웹 서비스를 관리하기 쉽지만 앱이 사용하는 도메인이 바뀔 수 있습니다. 앱 기준 분할은 직관적이지만 운영체제와 클라이언트가 프로세스를 정확히 식별할 수 있어야 합니다. IP 대역 방식은 고정된 기업 내부망에 적합하지만 주소가 자주 바뀌는 클라우드 서비스에는 적합하지 않습니다. 실제 설정에서는 여러 방식을 조합하고, 매칭되지 않은 트래픽에 명확한 기본 정책을 지정할 수 있습니다.
규칙의 순서도 중요합니다. 일반적으로 먼저 로컬 네트워크와 기업 내부망을 제외한 뒤 프록시가 필요한 업무 도메인을 매칭하고, 나머지 트래픽을 직결할지 프록시로 보낼지 결정합니다. 규칙이 서로 겹치면 클라이언트 문서에 안내된 매칭 순서를 따라야 합니다. 변경 후에는 브라우저에서 페이지가 열리는지만 확인하지 말고 DNS, 웹 인증, 회사 VPN을 다시 테스트하세요.
로컬 네트워크 및 기업 내부망 → 직결
호텔 인증 페이지 → 직결
지정 협업 플랫폼 → 해외 접속 회선
회의 및 원격 업무 앱 → 안정적인 회선
매칭되지 않은 트래픽 → 기업 정책과 실제 필요에 따라 처리업무 계정에는 고정된 출구 지역도 중요합니다. 짧은 시간에 서로 먼 여러 출구 사이를 자주 전환하면 플랫폼의 비정상 로그인 점검이 작동할 수 있습니다. 출장 중에는 주요 업무에 안정적인 한 지역을 지정하고, 연결 실패나 뚜렷한 라우팅 이상이 있을 때만 전환한 뒤 로그인 세션을 다시 확인하세요. 다른 지역의 콘텐츠에 접근해야 한다면 업무 계정과 임시 탐색 작업도 가급적 분리해 처리하는 것이 좋습니다.
종량제와 월정액, 어떻게 선택할까
단기 출장이라고 해서 반드시 월정액이나 종량제가 맞는 것은 아닙니다. 핵심은 데이터 사용량이 집중되는지, 지속적인 예비 연결이 필요한지, 일정이 끝난 뒤 남은 데이터를 어떻게 처리할지입니다. 종량제는 출장 빈도가 일정하지 않고 주로 웹과 문서를 사용하며, 쓰지 않은 데이터를 계속 보관하고 싶은 사람에게 더 적합합니다. 월정액은 출장 중 회의, 자료 동기화, 원격 데스크톱을 지속적으로 사용하거나 전체 일정 동안 예산을 일정하게 관리하고 싶은 사람에게 적합합니다.
| 비교 항목 | 종량제 데이터 패키지 | 월정액 요금제 |
|---|---|---|
| 적합한 일정 | 출장 일정이 불규칙하고 사용 간격이 긴 경우 | 1~2주 동안 지속적으로 업무를 보거나 회의가 많은 경우 |
| 데이터 사용 특성 | 실제 사용량 기준, 데이터 만료 여부가 핵심 | 기간별 초기화 규칙과 해당 기간의 제공량이 핵심 |
| 예산 판단 | 가볍게 사용하면서 남은 데이터를 보관하기에 적합 | 사용량을 비교적 쉽게 예측할 수 있는 집중 사용에 적합 |
| 확인할 사항 | 유효 기간, 충전 방식, 회선 범위 | 갱신 방식, 초기화 날짜, 취소 규정 |
| 대표적인 업무 | 웹, 메시지, 문서 및 소량의 첨부파일 | 회의, 클라우드 드라이브, 자료 전송 및 원격 작업 |
데이터 사용량을 추정할 때는 감으로 판단하지 말고 기기 시스템의 과거 사용량을 확인하세요. 화상회의, 시스템 업데이트, 클라우드 드라이브 동기화, 사진 백업이 백그라운드에서 데이터를 소모할 수 있습니다. 출발 전에 불필요한 자동 업데이트와 미디어 백업을 일시 중지할 수 있지만 중요한 보안 업데이트까지 건너뛰지는 마세요. 업무 파일에 명확한 마감 시간이 있다면 전송 실패 후 재전송할 여유도 남겨야 합니다.
요금제 페이지에서는 데이터 초기화 방식, 환불 규정, 회선이 데이터 한도를 공유하는지, 기기 연결 규칙을 중점적으로 확인해야 합니다. 기기 수에 제한이 없다고 해서 모든 기기가 동시에 전송해도 서로 영향을 주지 않는다는 뜻은 아닙니다. 호텔 출구, 무선 액세스 포인트, 동일 계정의 전체 데이터 사용량은 여전히 실제 제약입니다. 노트북과 태블릿은 미리 설정할 수 있지만 업무가 없을 때 모든 기기를 계속 동기화할 필요는 없습니다.
구독 링크와 플랫폼별 클라이언트 준비
구독 링크는 클라이언트가 노드 이름, 서버 주소, 포트, 프로토콜 및 관련 매개변수를 가져오도록 합니다. 일반적인 홍보 페이지 링크가 아니며 공개해서도 안 됩니다. 가져오기가 끝나면 클라이언트가 원격 설정을 로컬에서 선택할 수 있는 노드로 변환합니다. 서버에서 회선을 조정할 때 사용자는 구독을 업데이트해 변경 사항을 받을 수 있어 항목을 하나씩 직접 입력할 필요가 없습니다.
Windows와 macOS 클라이언트는 일반적으로 시스템 프록시, 가상 네트워크 어댑터, 규칙 모드, 로그 확인 기능을 제공하기 쉬워 DNS와 라우팅 문제를 점검하는 데 적합합니다. iOS와 Android는 시스템 백그라운드 정책의 영향을 더 크게 받습니다. 화면 잠금, 절전, 네트워크 전환으로 연결이 끊길 수 있으므로 필요 시 연결 또는 백그라운드 유지 설정을 확인해야 합니다. 같은 구독을 가져오더라도 클라이언트마다 기본 DNS, 규칙 엔진, 프로토콜 구현이 다를 수 있으므로 결과가 완전히 같다고 가정해서는 안 됩니다.
출발 전 각 업무 기기에서 가져오기와 업데이트를 별도로 완료하고 자주 사용할 프로토콜을 클라이언트가 실제로 지원하는지 확인해야 합니다. 예를 들어 어떤 클라이언트가 Shadowsocks를 인식한다고 해서 Hysteria2나 TUIC까지 지원하는 것은 아닙니다. VLESS를 지원해도 모든 전송 조합을 올바르게 가져온다는 뜻은 아닙니다. 구독에 인식할 수 없는 노드가 나타나면 먼저 클라이언트 버전과 프로토콜 지원 안내를 확인하고, 이해하지 못한 필드를 임의로 수정하지 마세요.
구독 링크가 유출되었다면 로컬 클라이언트에서 삭제하는 데 그치지 말고 사용자 패널에서 재설정해야 합니다. 로컬 설정을 삭제하면 현재 기기의 사본만 제거될 뿐, 이미 복사된 링크는 계속 설정을 업데이트할 수 있습니다. 재설정 후에는 자신의 기기에 새 링크를 다시 가져오고 오래된 설정을 정리해 이미 비활성화된 노드에 잘못 연결하지 않도록 하세요.
- ✅ 출발 전에 패널에 로그인하고 클라이언트 가져오기 경로를 저장합니다.
- ✅ 구독을 업데이트한 뒤 직결, 중계, 전용 회선 노드가 모두 정상적으로 표시되는지 확인합니다.
- ✅ 자주 사용할 회선에 알아보기 쉬운 즐겨찾기 이름을 추가해 현장에서 반복해서 찾지 않도록 합니다.
- ✅ 시스템 프록시, 가상 네트워크 어댑터, 분할 라우팅 모드가 각각 어떤 트래픽을 처리하는지 확인합니다.
- ✅ UDP가 제한된 네트워크에 대비해 TCP/TLS를 지원하는 예비 노드를 하나 남겨 둡니다.
- ❌ 구독 링크를 공개 문서, 공개 코드 저장소, 공유 스크린샷에 넣지 않습니다.
출장 네트워크 장애 점검 순서
새로운 장소에 도착한 뒤 클라이언트가 연결되지 않으면 네트워크 계층을 따라 단계적으로 점검하는 것이 가장 효과적입니다. 먼저 Wi-Fi 인증이 완료되었는지 확인하고, 로컬 DNS와 기본 웹페이지를 점검한 다음, 여러 프로토콜을 테스트하고 마지막에 출구 지역을 바꾸세요. 순서 없이 노드를 계속 바꾸면 호텔 네트워크, 프로토콜, 클라이언트, 대상 서비스 중 무엇이 문제인지 판단할 수 없습니다.
연결됨으로 표시되지만 웹페이지가 열리지 않음
먼저 시스템에 이전 프록시 포트가 남아 있는지 또는 가상 네트워크 어댑터가 기본 라우팅을 맡고 있는지 확인하세요. 이어서 DNS 조회를 점검합니다. 도메인은 조회되지 않지만 알고 있는 서비스에 직접 접속했을 때 응답이 있다면 문제는 대개 DNS에 집중되어 있습니다. 회사 VPN이 동시에 켜져 있다면 회사 규정에 따라 개인 회선을 잠시 끄고 라우팅 충돌 여부를 확인할 수 있습니다.
웹페이지는 되지만 회의가 반복해서 끊김
이 경우에는 회선 지터와 현지 무선 혼잡을 구분해야 합니다. 클라우드 드라이브 동기화와 대용량 파일 업로드를 잠시 멈추고 액세스 포인트 가까이에서 다시 테스트하세요. UDP 기반 프로토콜이 불안정하다면 TCP/TLS 예비 회선으로 전환할 수 있습니다. 모든 프로토콜이 비슷한 시점에 끊긴다면 해외 출구만 바꾸기보다 호텔 Wi-Fi 자체를 점검해야 합니다.
네트워크 전환 후 클라이언트가 복구되지 않음
먼저 현재 연결을 끊고 시스템이 새 네트워크의 주소와 DNS를 가져올 때까지 기다린 뒤 다시 연결하세요. 일부 클라이언트는 네트워크 전환 후에도 이전 인터페이스 상태를 유지할 수 있으므로 노드를 계속 클릭하는 것보다 터널을 새로 만드는 편이 안정적입니다. 문제가 지속되면 클라이언트를 종료했다가 다시 열고, 구독 만료 여부, 시스템 시간의 정확성, 인증서 검증 오류를 함께 확인하세요.
단기해외 접속 업무의 최종추천
단기 출장 네트워크 구성은 복구 가능성을 중심으로 설계해야 합니다. 주 회선은 일상적인 회의와 협업을 담당하고, 예비 회선은 프로토콜 제한이나 라우팅 변동에 대응합니다. 분할 라우팅 규칙은 현지 서비스와 기업 내부망의 불필요한 우회를 막고, 구독 링크는 여러 기기에서 사용할 수 있는 설정을 동기화합니다. 어느 한 요소만으로 전체 일정을 보장할 수는 없지만 이러한 준비를 하면 현장에서 점검해야 할 범위를 크게 줄일 수 있습니다.
업무가 웹, 메시지, 문서 중심이라면 종량제 데이터 패키지와 직결 또는 일반 중계를 먼저 비교하세요. 지속적인 화상회의, 원격 데스크톱, 많은 파일 업로드가 필요하다면 경로가 안정적인 중계나 IEPL 전용 회선을 우선 테스트한 뒤 집중 사용량에 따라 월정액을 선택하는 것이 좋습니다. 어떤 방식을 택하든 TCP/TLS와 UDP 프로토콜을 모두 미리 준비하고 실제 호텔 네트워크에서 로그인, 절전 복귀, DNS, 분할 라우팅을 점검해야 합니다.
VPNHe는 120+개 국가와 180+개 회선을 제공하며 기기 수에 제한이 없고 이메일 주소가 필요하지 않습니다. 출발 전에 자주 사용하는 기기에 구독을 가져오고 업무에 맞춰 위 테스트를 완료한 뒤 적합한 요금제를 선택하세요. 서비스 선택은 준비의 일부일 뿐입니다. 안정적인 출장 업무에는 올바른 클라이언트 설정, 명확한 분할 라우팅 규칙, 기업 네트워크 정책과 현지 규정 준수도 필요합니다.