원격근무 VPN을 고를 때는 다운로드 속도만 봐서는 안 됩니다. Zoom·Teams 같은 화상회의 도구에서는 왕복 지연의 안정성, 패킷의 연속적인 도착, 회의 중 경로 변경 빈도가 실제 사용 경험을 좌우합니다. 파일을 빠르게 내려받는 회선이 양방향 실시간 통화에 적합하다고는 할 수 없습니다. 속도 측정에서 높은 순간 최고치를 기록해도 회의 중 음성이 끊기거나 화면이 멈추고 발언이 늦게 전달될 수 있습니다.
주문형 동영상은 미리 버퍼링할 수 있지만, 회의에서는 음성·화면·화면 공유·제어 신호를 지속적으로 양방향 전송해야 합니다. 패킷 하나가 늦게 도착해도 회의 앱은 대화를 계속 늦추지 않기 위해 무작정 기다리지 않습니다. 오래된 데이터를 버리고 화질이나 프레임률을 낮추거나 잠시 영상을 끄면서 통화를 유지할 수 있습니다. 따라서 해외 원격근무 회선을 고를 때는 짧은 순간에 높은 대역폭을 내는 것보다 데이터를 안정적으로 제때 전달하는 능력을 우선해야 합니다.
화상회의가 동영상 시청보다 회선 품질에 민감한 이유
주문형 동영상은 주로 서버에서 기기로 단방향 전송되며, 플레이어가 이후 콘텐츠를 미리 내려받아 버퍼로 네트워크 변동을 흡수할 수 있습니다. 반면 화상회의는 지속적인 양방향 통신입니다. 카메라와 마이크의 데이터를 보내는 동시에 다른 참가자의 음성과 영상도 받아야 합니다. 화면 공유, 채팅, 손들기 상태, 회의 제어 정보도 같은 세션에서 계속 오갑니다. 업로드 품질이 조금만 떨어져도 본인 화면은 정상으로 보일 수 있지만, 다른 참가자에게는 음성이 이미 끊기기 시작합니다.
회의 품질은 서로 연결된 여러 지표로 결정됩니다. 지연은 데이터 왕복에 걸리는 시간을 뜻하고, 지터는 인접한 패킷의 도착 시간이 일정한지를 나타냅니다. 패킷 손실은 일부 데이터가 목적지에 도달하지 못하는 상태이며, 가용 대역폭은 현재 화질과 공유 콘텐츠를 감당할 수 있는지를 결정합니다. 대역폭이 부족하면 곧바로 혼잡이 발생하지만, 대역폭이 충분하다고 해서 우회 경로·지터·패킷 손실이 자동으로 사라지는 것은 아닙니다.
| 관찰 항목 | 회의에서 나타나는 증상 | 가능한 네트워크 원인 | 우선 조치 |
|---|---|---|---|
| 왕복 지연 | 질문과 답변의 흐름이 느려지고 서로 동시에 말하기 쉬움 | 먼 거리, 해외 우회 경로 또는 출구 혼잡 | 회의 서비스 진입점에 더 가깝고 경로가 짧은 회선 선택 |
| 지터 | 음성이 빨라졌다 느려지고 화면이 간헐적으로 멈춤 | 무선 간섭, 대기열 혼잡 또는 중간 구간 변동 | 유선 네트워크로 전환하고 더 안정적인 중계 또는 전용선 비교 |
| 패킷 손실 | 음절이 잘리고 기계음이 나며 공유 화면에 빈 부분이 생김 | 약한 현지 신호, 출구 혼잡 또는 불안정한 회선 품질 | 먼저 현지 문제를 배제한 뒤 진입점과 회선 유형 변경 |
| 업로드 성능 | 다른 참가자가 내 화면을 선명하게 보지 못하거나 발언을 잘 듣지 못함 | 동기화·백업 또는 다른 기기가 업로드 대역폭을 모두 사용함 | 대용량 작업을 일시 중지하고 회의 트래픽의 우선순위 상향 |
| 연결 지속성 | 회의 재연결 또는 잠시 오프라인으로 표시되는 상태 | 네트워크 전환, 클라이언트 절전 또는 회선 재설정 | 과도한 절전 설정을 끄고 회의 중 노드 전환 방지 |
회의 앱은 보통 WebRTC 또는 플랫폼 자체의 실시간 전송 방식을 사용하며, 대기 시간을 줄이기 위해 UDP를 선호합니다. UDP는 신뢰성 중심 전송 연결처럼 모든 데이터를 하나씩 확인하고 재전송하지 않으므로, 오래된 콘텐츠를 다시 보낼 필요가 없는 실시간 환경에 더 적합합니다. UDP가 제한되면 앱이 다른 전송 방식으로 전환할 수 있습니다. 회의는 계속 연결되더라도 지연과 혼잡 대응 성능은 달라질 수 있습니다.
이 때문에 웹페이지는 정상적으로 열리는데 회의는 불안정할 수 있습니다. 웹 요청은 재시도할 수 있고 파일 다운로드는 기다릴 수 있지만, 실시간 음성은 이미 놓친 문장을 나중에 되돌려 보낼 수 없습니다. 점검할 때 단순히 웹페이지를 열어 회선을 판단하거나, 한 번의 다운로드 속도를 회의 품질의 유일한 근거로 삼지 마세요.
직결·중계·IEPL 전용선 선택 기준
회선 이름만 보면 등급이 높을수록 항상 빠르다고 생각하기 쉽습니다. 더 정확히는 직결·중계·IEPL 전용선이 서로 다른 해외 연결 경로를 사용하며, 각각 적합한 네트워크 환경이 다릅니다. 실제 성능은 사용 지역, 현지 통신사, 회의 플랫폼의 진입점, 이용 시간대에 따라 달라집니다.
직결: 경로는 단순하지만 공용망 상태에 더 크게 좌우됨
직결 회선은 보통 사용 지역의 공용망에서 해외 노드로 직접 연결되며, 중간에 별도의 최적화 진입점을 거치지 않습니다. 현지 국제 출구 품질이 좋고 대상 지역이 가까울 때 자연스럽고 직접적인 경로를 얻을 수 있다는 점이 장점입니다. 반면 공용망 혼잡, 통신사 라우팅, 해외 경로 변경의 영향을 더 쉽게 받습니다. 같은 직결 회선도 한산한 시간에는 원활하다가 업무가 몰리는 시간에는 큰 변동을 보일 수 있습니다.
직결은 가벼운 협업, 이메일, 문서 작업처럼 실시간성이 높지 않은 업무에 적합하며 백업 경로로도 활용할 수 있습니다. 회의 전 과정에서 지연이 안정적이고 지속적인 패킷 손실이 없다면 ‘직결’이라는 이름만으로 제외할 필요는 없습니다. 회선은 명칭이 아니라 실제 측정된 안정성을 기준으로 선택해야 합니다.
중계: 최적화된 진입점으로 불확실한 우회 경로 줄이기
중계 회선은 먼저 가까운 접속 지점에 연결한 뒤 중계 네트워크를 통해 해외 출구로 전달합니다. 장점은 단순히 지리적 거리를 줄이는 데 있지 않고, 변동이 큰 공용망 구간을 더 관리하기 쉬운 전달 경로로 바꾸는 데 있습니다. 현지 국제 출구가 혼잡하거나 해외 경로가 자주 바뀌는 환경에서는 일반 직결보다 일상적인 회의에 더 적합한 경우가 많습니다.
중계가 모든 상황에서 가장 낮은 지연을 보장하는 것은 아닙니다. 접속과 전달 구간이 추가되면 처리 경로도 늘어납니다. 진입점이 사용자와 멀거나 출구가 회의 플랫폼의 실제 접속 지역과 맞지 않으면 경로가 좋은 직결보다 결과가 나쁠 수 있습니다. 따라서 자신의 네트워크 위치에 가까운 진입점을 먼저 고른 뒤, 회의 서비스 진입점과 가까운 출구를 조합하는 것이 좋습니다.
IEPL 전용선: 안정성과 업무 피크 시간대 성능을 우선 고려
IEPL 전용선은 보다 안정적인 국제 연결 경로를 구성해 일반 공용망의 해외 구간에서 발생하는 불확실성을 줄이는 데 사용됩니다. 해외 회의가 잦거나 원격 시연, 클라우드 데스크톱, 지속적인 음성 협업처럼 지터에 민감한 업무에 적합한 경우가 많습니다. 일반 공용망 직결보다 전용선을 선택하는 핵심 이유는 안정성과 경로 제어 가능성이며, 어느 장소에서나 동일한 결과를 기대해서는 안 됩니다.
회의가 고객 커뮤니케이션, 원격 교육 또는 중요한 시연에 사용된다면 IEPL 전용선을 우선 테스트하고, 다른 진입점을 가진 중계 회선을 백업으로 유지하는 것이 좋습니다. 현지 접속 자체에 무선 간섭이나 업로드 혼잡이 있다면 전용선도 기기와 라우터 사이의 문제를 해결할 수 없으므로, 먼저 현지 네트워크를 점검해야 합니다.
회의 플랫폼 진입점에 따른 노드 지역 선택
노드는 무조건 가까울수록 좋은 것도, 참가자에게 가까울수록 좋은 것도 아닙니다. 회의 데이터는 보통 Zoom·Teams 같은 플랫폼의 서비스 노드로 먼저 들어간 뒤 플랫폼에서 다른 참가자에게 분배됩니다. 이상적인 경로는 기기에서 회선 진입점까지와 회선 출구에서 플랫폼 진입점까지를 함께 고려해야 하며, 지도에서 가장 가까운 국가나 지역을 기계적으로 고르는 방식은 적절하지 않습니다.
기업 계정은 관리자가 데이터 리전을 설정할 수 있고, 회의 주최자의 위치가 서비스 진입점에 영향을 줄 수도 있습니다. 회사의 협업 리소스가 특정 지역에 집중되어 있다면 해당 지역과 인접한 네트워크 허브를 먼저 테스트하세요. 팀이 여러 지역에 분산되어 있다면 참가자 위치를 따라 노드를 바꾸기보다 회의 생성자, 기업 테넌트 위치, 실제 라우팅 성능을 기준으로 판단해야 합니다.
노드를 선택할 때는 가까운 곳부터, 안정적인 경로부터 백업 경로까지 순서대로 시험할 수 있습니다. 먼저 현지 네트워크 품질이 좋은 중계 또는 전용선 진입점을 테스트한 다음, 대상 서비스 지역과 가까운 출구를 비교하세요. 재사용 가능한 주 회선과 백업 회선을 마련하면 회의 전에는 연결 상태만 확인하면 되므로 매번 모든 노드를 임시로 탐색할 필요가 없습니다.
- ✅ 회사 회의 계정과 자주 사용하는 클라우드 서비스가 주로 어느 지역에 있는지 먼저 확인하세요.
- ✅ 현지 네트워크에 가까운 접속 진입점을 우선 선택해 기기와 진입점 사이의 변동을 줄이세요.
- ✅ 노드 이름이 아니라 출구에서 회의 플랫폼까지의 실제 성능을 비교하세요.
- ✅ 평소 업무 시간대에 발언·영상·화면 공유를 포함한 전체 통화 테스트를 진행하세요.
- ✅ 중요한 회의를 위해 서로 다른 진입점이나 회선 유형의 백업 연결을 마련하세요.
- ❌ 회의 중 노드를 반복해서 전환하지 마세요. 전환하면 기존 세션이 끊기고 재연결이 발생합니다.
- ❌ 다운로드 속도 측정만으로 판단하지 말고 실시간 음성과 업로드 화면을 반드시 확인하세요.
노드에서 회선 상태를 참고할 수 있다면 지연과 대역폭 추이를 확인해도 좋지만, 이 수치는 해당 시점의 측정값일 뿐입니다. 현지 무선 환경을 완전히 보여주지 못하며 실제 회의 테스트를 대신할 수도 없습니다. 더 실용적인 방법은 같은 기기·네트워크·회의 플랫폼을 고정하고 후보 회선을 차례로 비교해 변수를 줄이는 것입니다.
프로토콜 선택이 실시간 통화에 미치는 영향
Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC은 모두 프록시 트래픽을 전달하는 데 사용할 수 있지만 전송 방식과 클라이언트 지원 범위가 다릅니다. 프로토콜 이름만으로 회선 품질을 판단할 수는 없습니다. 기본 해외 경로가 불안정하다면 프로토콜 변경으로 일부 전송 동작은 개선할 수 있어도, 우회 공용망을 전용선으로 바꿀 수는 없습니다.
Shadowsocks는 구조가 비교적 단순하고 지원 클라이언트가 다양해 일반적인 프록시와 분할 라우팅에 적합합니다. VMess와 VLESS는 유연한 전송 설정을 지원하는 클라이언트에서 흔히 사용됩니다. VLESS는 간결한 인증과 전송 조합에 중점을 두며, 실제 성능은 외부 전송 방식·암호화·서버 설정에 따라 달라집니다. Trojan은 보통 TLS와 함께 사용되며 표준 암호화 전송처럼 보이는 배포 환경에 적합합니다.
Hysteria2와 TUIC은 QUIC 방식에 기반해 전송을 처리하며, 패킷 손실이나 변동이 있는 네트워크에서 처리량과 응답성을 유지하는 데 더 중점을 둡니다. 모바일 네트워크나 품질 변화가 큰 회선에 적합할 수 있지만, 사용한다고 해서 지연이 반드시 줄어드는 것은 아닙니다. 현지 네트워크나 기업 방화벽이 UDP를 제한하면 QUIC 기반 연결이 설정되지 않거나 백업용으로 다른 프로토콜을 사용해야 할 수 있습니다.
원격근무 환경에서는 프로토콜이 안정적인 UDP 전달을 지원하는지, 클라이언트가 분할 라우팅 규칙을 올바르게 적용하는지, 절전이나 네트워크 전환 후 연결을 안정적으로 복구하는지를 확인해야 합니다. 일부 클라이언트의 ‘전역 프록시’는 시스템 프록시에 표시되는 트래픽만 처리하며, 회의 앱의 UDP 데이터는 기존 시스템 프록시를 거치지 않을 수 있습니다. 이 경우 가상 네트워크 어댑터 모드나 UDP를 명확히 지원하는 연결 방식을 사용하고, 연결 후 회의 앱의 실제 출구를 확인해야 합니다.
분할 라우팅 규칙과 DNS가 업무에 영향을 주는 이유
전역 프록시는 기기의 대부분 트래픽을 하나의 회선으로 보내 설정이 간단하지만, 현지 업무 시스템·프린터 서비스·지역 웹사이트까지 해외 출구로 전달할 수 있습니다. 규칙 기반 분할 라우팅을 사용하면 회의 플랫폼, 해외 협업 도구, 지정 클라우드 서비스만 가속 회선을 이용하고 나머지 트래픽은 현지 연결을 유지할 수 있습니다. 원격근무에서는 적절한 분할이 불필요한 회선 부하를 줄이고 현지 업무 시스템의 접속 경로를 유지하는 데 도움이 됩니다.
분할 라우팅 규칙은 회의 웹사이트 도메인만 포함해서는 충분하지 않습니다. 데스크톱 클라이언트는 인증 서비스, 미디어 서버, 콘텐츠 전송 네트워크, 동적으로 할당되는 서비스 주소에도 연결할 수 있습니다. 로그인 페이지에만 프록시를 적용하면 ‘로그인은 되지만 회의에 참가할 수 없음’, ‘회의에는 들어갔지만 소리가 나지 않음’, ‘채팅은 되지만 화면 공유가 실패함’과 같은 문제가 발생할 수 있습니다. 유지 관리되는 규칙 세트를 사용하고 회의 관련 UDP 트래픽과 도메인 해석이 같은 경로를 따르는지 확인하는 편이 안전합니다.
DNS 누수는 조회 요청이 예정된 해석 경로를 거치지 않아 도메인 해석 결과가 여전히 현지 네트워크에서 제공되는 현상을 말합니다. 원격근무에서는 개인정보뿐 아니라 서비스 라우팅에도 영향을 줄 수 있습니다. 회의 도메인이 현지 DNS를 통해 특정 진입점으로 해석되었지만 실제 연결은 다른 지역의 프록시 출구에서 시작되면 경로가 길어질 수 있습니다. 프록시는 연결되었는데 DNS 조회가 현지 네트워크의 간섭을 받으면 클라이언트가 간헐적으로 서비스 주소를 찾지 못하는 경우도 있습니다.
연결 후에는 출구 위치와 DNS 경로를 함께 확인해야 합니다. 클라이언트에 ‘원격 DNS’, ‘프록시를 통한 DNS’ 또는 가상 네트워크 어댑터의 DNS 인계 옵션이 있다면 분할 모드에 맞게 활성화하고, 현지 도메인이 필요한 경우 직접 연결로 해석되는지 확인하세요. 모든 DNS 조회를 하나의 원격 해석기로 무조건 보내면 기업 내부 도메인이나 로컬 네트워크 서비스가 현지 해석에 의존할 때 문제가 생길 수 있습니다.
플랫폼별 클라이언트 설정 핵심
Windows의 회의 도구는 기업 업무 소프트웨어와 함께 실행되는 경우가 많아 시스템 프록시 모드가 모든 실시간 트래픽을 처리하지 못할 수 있습니다. 가상 네트워크 어댑터 모드를 지원하는 클라이언트를 사용한다면 네트워크 어댑터가 정상적으로 생성되었는지 확인하고, 기업 보안 소프트웨어가 관련 드라이버를 제한하는지도 점검하세요. 클라우드 드라이브 동기화·시스템 업데이트·원격 백업을 동시에 실행 중이라면 회의 전에 대역폭을 많이 사용하는 작업을 일시 중지해 업로드 대기열이 가득 차지 않게 하세요.
macOS는 네트워크 확장과 VPN 설정에 대해 명확한 시스템 승인 절차를 요구합니다. 구독을 가져온 뒤 클라이언트가 네트워크 구성을 추가하라고 표시하면 시스템 설정에서 승인해야 합니다. 일부 클라이언트는 창을 닫아도 메뉴 막대에서 계속 실행되지만, 다른 클라이언트는 시스템 절전과 함께 연결을 일시 중지합니다. 장시간 회의 전에는 깊은 절전을 유발할 수 있는 설정을 끄고, 깨어난 뒤 회선이 ‘연결됨’으로 표시되지만 실제로는 사용할 수 없는 상태에 머물지 않는지 확인하세요.
iOS의 회의는 Wi-Fi와 모바일 네트워크 사이를 전환하는 경우가 많습니다. 네트워크가 바뀌면 하위 연결도 변경되므로 회의 앱과 프록시 클라이언트가 세션을 다시 설정해야 합니다. 중요한 회의에 들어가기 전에는 가능한 한 품질이 안정적인 네트워크를 고정해 사용하고 회의 중 직접 전환하지 마세요. 저전력 모드가 켜져 있으면 백그라운드 활동이 더 엄격하게 제한될 수 있으므로 프록시 연결이 계속 유지되는지 미리 확인해야 합니다.
Android 기기의 차이는 주로 제조사별 절전 정책에서 발생합니다. 화면이 꺼진 뒤 시스템이 프록시 클라이언트의 백그라운드 실행을 제한해 회의 중 연결이 끊길 수 있습니다. 사용하는 클라이언트를 백그라운드 활동 허용 목록에 추가하고 ‘항상 켜짐’ 유형의 시스템 VPN 옵션이 현재 사용 방식과 호환되는지 확인하세요. 앱별 프록시에서는 특히 주의해야 합니다. 회의 본 프로그램만 선택하고 인증 또는 보조 구성 요소를 빠뜨리면 로그인과 미디어 연결이 서로 다른 출구를 사용할 수 있습니다.
어떤 플랫폼을 사용하든 구독 링크는 지원되는 클라이언트에서 가져와야 합니다. 구독은 노드와 설정 업데이트를 받기 위한 것이므로 일반 웹페이지처럼 반복해서 열면 안 됩니다. 구독을 업데이트한 뒤 기존 회선 이름과 분할 라우팅 설정이 유지되는지 먼저 확인하고 연결을 테스트하세요. 클라이언트가 연결 로그를 지원한다면 DNS·핸드셰이크·UDP 전달·규칙 매칭이 어느 단계에서 발생하는지 로그로 판단할 수 있습니다. 단, 로그를 공유하기 전에는 구독 주소·인증 정보·기기 식별자를 삭제해야 합니다.
회의 전 점검과 끊김 발생 후 문제 해결 순서
가장 효과적인 점검 방법은 한 번에 하나의 변수만 바꾸는 것입니다. 노드·프로토콜·Wi-Fi·클라이언트를 동시에 변경하면 어떤 조정이 효과가 있었는지 알 수 없습니다. 회의 플랫폼과 기기를 고정한 뒤 현지 네트워크부터 확인하고, 프록시 연결·회선 유형·노드 지역·분할 라우팅 규칙을 차례로 점검하세요.
- 현지 네트워크 확인. 무선 접속 지점에 가까이 가고, 가능하면 유선 연결로 전환하세요. 클라우드 드라이브 동기화·업로드·대용량 파일 전송을 일시 중지한 뒤 프록시에 연결하지 않은 상태에서도 네트워크에 뚜렷한 변동이 있는지 확인합니다.
- 구독을 새로 고치고 주 회선에 연결. 클라이언트에 인증 실패·설정 만료·지속적인 재연결이 표시되지 않는지 확인하세요. 회의가 시작된 뒤 모든 설정을 임시로 업데이트하지 마세요.
- 출구와 DNS 확인. 출구 지역이 선택한 노드와 일치하는지 확인하고, DNS가 회의 서비스를 적절하지 않은 지역으로 잘못 해석하지 않는지 점검하세요.
- 양방향 테스트 진행. 마이크·카메라·화면 공유를 모두 테스트하세요. 다른 사람의 화면만 보는 것으로는 현지 업로드 문제를 확인할 수 없습니다.
- 백업 회선 비교. 직결·중계·IEPL 전용선 후보에서 같은 테스트를 각각 진행하고, 평소 업무 시간대에 어느 회선이 더 안정적인지 기록하세요.
- 복구용 설정 유지. 주 회선에 문제가 생기면 미리 테스트한 백업 항목으로 전환하고, 노드 목록에서 무작위로 시도하지 마세요.
음성만 이상하고 영상은 계속 보인다면 업로드 혼잡, 마이크 장치, UDP 경로를 먼저 확인하세요. 모든 참가자의 화면이 동시에 멈춘다면 현지 네트워크 전체 중단이나 프록시 재연결일 수 있습니다. 회의에는 들어갔지만 계속 연결 중으로 표시되면 분할 라우팅 규칙과 회의 미디어 도메인을 점검하세요. 브라우저 버전은 정상인데 데스크톱 클라이언트만 문제가 있다면 두 환경이 서로 다른 프록시 방식을 사용하는지 비교해야 합니다.
기업 네트워크에는 방화벽·접근 제어·특정 출구 정책이 설정되어 있을 수 있습니다. 회사 기기에서 지속적인 연결 문제가 발생하면 조직의 네트워크 및 보안 요구 사항을 따르고 관리자에게 허용된 연결 방식을 확인받으세요. 잠깐 연결하기 위해 엔드포인트 보호를 임의로 끄면 기존 업무 환경의 보안 경계를 무너뜨릴 수 있습니다.
원격근무 VPN의 최종 판단 기준
원격근무 VPN의 정답은 특정 프로토콜이나 노드 이름이 아니라 안정적으로 재사용할 수 있는 연결 조합입니다. 해외 화상회의에서는 먼저 현지 업로드와 무선 환경을 확인한 뒤 직결·중계·IEPL 전용선을 비교하세요. 노드 지역은 회의 플랫폼 진입점을 중심으로 선택하고, 프로토콜은 현재 네트워크에서 UDP와 지속 연결을 지원해야 합니다. 분할 라우팅과 DNS는 회의 제어 트래픽과 미디어 트래픽이 같은 경로를 사용하도록 구성해야 합니다.
가끔 짧은 회의에 참여하는 정도라면 안정적인 직결 또는 중계 회선 하나로 충분할 수 있습니다. 매일 해외 협업·고객 시연·원격 교육을 진행한다면 IEPL 전용선을 우선 테스트하고 다른 진입점의 백업 회선을 준비하는 편이 좋습니다. 클라이언트에서는 Windows와 macOS의 시스템 프록시·가상 네트워크 어댑터 차이를 확인하고, iOS와 Android에서는 네트워크 전환과 백그라운드 연결 유지를 중점적으로 점검하세요.
마지막으로 ‘끊김 없음’을 변동이 절대 발생하지 않는 상태로 이해해서는 안 됩니다. 인터넷 경로·회의 플랫폼의 라우팅·현지 네트워크는 계속 변합니다. 현실적인 목표는 올바른 회선 선택, 회의 전 검증, 백업 방안을 통해 장애 파악 시간을 줄이고 주 회선에 문제가 생겼을 때 신속하게 업무를 복구하는 것입니다.