VPN 추천 2026: 안드로이드 백그라운드 유지와 앱별 프록시 실측 비교

안드로이드 VPN을 추천할 때 노드 수나 첫 화면의 가격만 비교해서는 부족합니다. 실제 사용 경험은 클라이언트에 좌우되는 경우가 많습니다. 화면을 잠근 뒤 시스템이 연결을 종료하지 않는지, 네트워크가 바뀌었을 때 복구되는지, 배터리 관리가 백그라운드 실행을 허용하는지, 앱별 프록시가 로컬 앱을 예상대로 통과시키는지를 확인해야 합니다. 회선이 아무리 빨라도 클라이언트가 백그라운드 실행 권한을 잃으면 메시지 지연, 웹페이지 멈춤, 앱의 반복 재연결로 이어질 수 있습니다.

이 글에서는 재현 가능한 점검 방법을 사용하며, 임의의 지연 시간·부하·성공률을 제시하지 않습니다. 한 번의 속도 측정값보다 동작 자체를 확인하는 데 초점을 둡니다. 구독 가져오기가 안정적인지, 시스템 권한이 모두 부여됐는지, 화면을 잠근 뒤 터널이 유지되는지, Wi‑Fi와 모바일 네트워크 전환 후 복구되는지, 분할 라우팅 규칙이 적용되는지, DNS 요청이 예상한 경로를 따르는지를 살펴봅니다. 끝까지 읽으면 기기 환경과 사용 방식에 맞춰 안드로이드 클라이언트와 서비스를 바로 선별할 수 있습니다.

속도 측정보다 백그라운드 유지부터 확인하세요

안드로이드의 백그라운드 관리는 하나의 스위치로 끝나지 않습니다. 시스템은 배터리 최적화, 백그라운드 활동 권한, 자동 시작 정책, 앱 절전 상태, 메모리 부족 시 프로세스 처리 등을 종합적으로 적용합니다. 시스템별 메뉴 이름은 다르지만 판단 기준은 같습니다. 클라이언트가 VPN 터널을 계속 유지하고 네트워크 환경이 바뀐 뒤 연결을 다시 만들어야 합니다.

짧게 웹페이지를 열어 보는 것만으로는 현재 연결이 성공했다는 사실만 확인할 수 있으며, 백그라운드 유지가 안정적이라는 뜻은 아닙니다. 더 의미 있는 실측 절차는 먼저 연결한 뒤 홈 화면으로 돌아가 화면을 잠그는 것입니다. 다시 사용하기 전에 상태 표시줄의 VPN 아이콘, 클라이언트 연결 상태, 실제 출구 경로를 확인하세요. 이후 네트워크를 전환하고 터널이 자동으로 복구되는지, 가짜 연결 상태에 머무는지, 수동으로 연결을 끊었다가 다시 연결해야 하는지를 살펴봅니다.

구독 가져오기를 완료하고, 클라이언트에 선택 가능한 회선 목록이 생성됐는지 확인하세요. 편집할 수 없는 임시 설정 하나만 표시되어서는 안 됩니다.
처음 연결할 때 안드로이드 시스템이 표시하는 VPN 연결 요청을 허용하세요. 이 권한을 거부하면 클라이언트 화면에서 회선을 선택했더라도 시스템 수준의 터널을 만들 수 없습니다.
시스템 앱 설정에서 백그라운드 활동을 허용하고, 클라이언트를 엄격한 배터리 최적화 대상에서 제외하세요.
연결한 뒤 홈 화면으로 돌아가 화면을 잠그고, 클라이언트를 계속 전면에 띄워 두지 않은 상태에서 일반적인 사용 흐름이 자연스럽게 진행되도록 기다리세요.
기기를 다시 사용하기 전에 VPN 아이콘을 먼저 확인한 다음 네트워크를 사용하는 앱을 열어 요청이 이전 연결에 멈춰 있지 않은지 확인하세요.
네트워크를 전환한 뒤 같은 점검을 반복하세요. 연결됨으로 표시되지만 요청이 통과하지 않는다면 구독을 수동으로 새로 고치고 터널을 다시 만들어 클라이언트 상태 오류와 회선 장애를 구분하세요.

결론: 화면을 자주 잠그고 메시지를 받거나, 백그라운드에서 파일을 동기화하거나, 네트워크 사이를 이동한다면 우선순위는 단일 속도 측정값보다 ‘네트워크 변경 후 자동 복구’여야 합니다. 전면에서만 안정적으로 작동하는 클라이언트는 장기 연결 도구로 적합하지 않습니다.

배터리 최적화 호환성은 어떻게 테스트할까

배터리 최적화 호환성은 ‘배터리를 적게 쓸수록 좋다’는 의미가 아닙니다. 터널은 연결 상태를 유지하고 핸드셰이크를 처리하며 데이터를 전달해야 하므로, 백그라운드 활동을 완전히 금지하면 사용성에 영향을 줍니다. 합리적인 목표는 데이터가 없을 때 필요한 상태를 유지하고, 네트워크가 복구되거나 앱이 요청을 보낼 때 즉시 작동하게 하는 것입니다. 시스템이 프로세스를 계속 종료했다가 다시 시작하게 만들어서는 안 됩니다.

테스트에서는 여러 변수를 한꺼번에 바꾸지 마세요. 먼저 같은 회선과 같은 분할 라우팅 규칙을 고정하고 시스템 백그라운드 권한만 조정합니다. 백그라운드 권한을 허용한 뒤 연결 끊김이 사라진다면 원인은 대체로 시스템의 프로세스 관리에 있습니다. 전면에서도 계속 실패한다면 프로토콜 호환성, 구독 내용, 회선 상태 또는 로컬 네트워크 제한을 추가로 확인해야 합니다.

✅ 시스템 상태 표시줄에 VPN 아이콘이 계속 표시되고 클라이언트와 시스템 상태가 일치합니다.
✅ 화면을 잠갔다가 다시 사용한 뒤 첫 네트워크 요청이 클라이언트를 먼저 열지 않아도 정상적으로 완료됩니다.
✅ 네트워크 전환 후 클라이언트가 다시 핸드셰이크를 수행하며 이전 연결이 상태를 장시간 점유하지 않습니다.
✅ 시스템 재시작 후 동작이 예상과 일치합니다. 상시 실행이 필요할 때는 자동으로 시작되고, 필요하지 않을 때는 임의로 연결하지 않습니다.
❌ 클라이언트에는 연결됨으로 표시되지만 모든 앱에서 데이터가 전달되지 않는다면 가짜 연결이거나 라우팅이 복구되지 않은 상태일 가능성이 큽니다.
❌ 화면을 잠글 때마다 프로세스를 정리한 뒤 다시 연결해야 한다면 백그라운드 권한이나 클라이언트의 복구 로직에 문제가 있을 수 있습니다.
❌ 배터리 절약을 위해 모든 백그라운드 기능을 끄면 백그라운드 유지 테스트 자체가 의미를 잃습니다.

전면에서는 안정적이지만 백그라운드에서 끊긴다면

이 현상은 대개 회선 자체보다 시스템 정책을 먼저 가리킵니다. 배터리 최적화, 백그라운드 활동, 자동 시작, 앱 절전 설정을 순서대로 확인하세요. 조정한 뒤에도 재현된다면 클라이언트가 지원하는 다른 프로토콜을 시도해 보세요. 모든 프로토콜이 같은 상황에서 종료된다면 클라이언트 프로세스 관리나 시스템 제한일 가능성이 높습니다. 특정 프로토콜만 복구되지 않는다면 프로토콜 구현 또는 현재 네트워크와의 호환성 문제에 더 가깝습니다.

네트워크 전환 후 연결됨으로 표시되지만 접속되지 않을 때

Wi‑Fi와 모바일 네트워크를 전환하면 로컬 인터페이스, 기본 라우팅, 사용 가능한 주소가 바뀝니다. 제대로 만들어진 안드로이드 클라이언트는 네트워크 변화를 감지하고 터널을 다시 만들어야 합니다. 클라이언트가 이전 인터페이스의 세션을 계속 유지하면 화면에는 정상 연결로 표시되지만 데이터는 전달되지 않을 수 있습니다. 이때 속도 측정을 반복해서 누르기보다 먼저 연결을 끊었다가 다시 연결하세요. 재연결 직후 복구된다면 이후 서비스 선택에서 ‘네트워크 전환 복구 능력’을 중요한 조건으로 삼아야 합니다.

앱별 프록시가 일상적인 사용성을 좌우합니다

앱별 프록시는 안드로이드에서 가장 실용적이면서도 설정을 반대로 하기 쉬운 기능 중 하나입니다. 일반적으로 두 가지 방식이 있습니다. 선택한 앱만 터널을 통과시키거나, 선택한 앱을 제외한 나머지 앱을 터널로 보내는 방식입니다. 두 모드는 비슷해 보이지만 실제 결과는 정반대입니다. 설정을 저장하기 전에 클라이언트의 ‘포함’과 ‘제외’ 안내를 반드시 확인하세요.

선택한 앱만 프록시를 사용하도록 하는 방식은 용도가 분명한 기기에 적합합니다. 예를 들어 브라우저, 개발 도구 또는 해외 콘텐츠 앱만 원격 회선을 사용하게 하고, 로컬 결제·로컬 네트워크 제어·기타 로컬 서비스는 기존 경로를 유지할 수 있습니다. 특정 앱을 제외하는 방식은 대부분의 트래픽을 터널로 보내고 소수의 로컬 앱만 직접 연결해야 할 때 적합합니다.

점검 항목	선택한 앱만 프록시 사용	선택한 앱 제외	흔한 실수
기본 동작	선택하지 않은 앱은 직접 연결	선택하지 않은 앱은 터널로 연결	포함 목록을 제외 목록으로 착각
적합한 상황	특정 앱만 해외 회선을 사용해야 함	대부분의 앱에 통합 프록시가 필요함	앱 업데이트 후 패키지 이름 변경을 확인하지 않음
로컬 서비스	대체로 기존 경로 유지	제외 규칙에 명시적으로 추가해야 함	로컬 네트워크 접근 필요성을 무시
문제 확인	대상 앱이 선택됐는지 확인	대상 앱이 잘못 제외됐는지 확인	회선만 바꾸고 규칙 적용 여부는 확인하지 않음

앱별 프록시가 적용되는지는 클라이언트의 선택 표시만으로 판단할 수 없습니다. 터널로 들어가는 앱과 직접 연결을 유지하는 앱에서 각각 확인 가능한 네트워크 리소스에 접속해 두 경로가 실제로 다른지 확인하세요. 모든 앱의 동작이 같다면 클라이언트가 시스템 VPN 모드를 활성화했는지, 앱별 설정이 저장됐는지, 시스템에서 다른 VPN 설정이 채널을 점유하고 있지 않은지를 점검해야 합니다.

프로토콜 지원은 이름만 보고 판단할 수 없습니다

일반적인 구독에는 Shadowsocks, VMess, Trojan, VLESS, Hysteria2 또는 TUIC가 포함될 수 있습니다. 프로토콜 이름은 연결 방식의 일부만 보여 줍니다. 실제 사용 가능 여부는 클라이언트 코어 버전, 전송 매개변수, 암호화 설정, TLS 설정, 구독 변환이 완전한지에 따라 달라집니다. 클라이언트가 특정 이름을 지원한다고 해서 서비스가 제공하는 모든 매개변수를 해석할 수 있다는 뜻은 아닙니다.

Shadowsocks, VMess, Trojan 및 VLESS

Shadowsocks는 암호화 프록시 프로토콜로, 설정에는 보통 서버 주소·포트·비밀번호·암호화 방식이 포함됩니다. 구현마다 지원하는 암호화 스위트가 다를 수 있습니다. 가져온 뒤 ‘지원하지 않는 방식’과 같은 오류가 나타나면 구독 내용을 임의로 수정하기보다 클라이언트 코어를 확인하세요.

VMess와 VLESS는 통합 코어를 사용하는 클라이언트에서 자주 쓰입니다. WebSocket, gRPC, TLS 등의 전송 설정과 함께 구성될 수도 있습니다. VMess는 자체 인증 설계를 포함하며, VLESS는 더 가벼운 인증에 가깝고 안전한 전송은 올바르게 설정된 TLS 같은 외부 계층에 의존하는 경우가 많습니다. Trojan은 TLS 연결 위에서 트래픽을 전달하므로 인증서 도메인, 시스템 시간, 서버 이름 일치 여부에 민감합니다.

Hysteria2와 TUIC

Hysteria2와 TUIC는 QUIC 계열 전송을 기반으로 설계되며 일반적으로 UDP를 사용합니다. 패킷 손실이 있는 네트워크에서는 기존 TCP 전송과 다른 복구 특성을 보일 수 있지만, 현재 네트워크가 UDP를 정상적으로 허용해야 합니다. UDP 제한이 엄격한 네트워크에서는 연결이 만들어지지 않거나 네트워크 전환 후 복구가 불안정할 수 있습니다. 이때 TCP와 TLS 기반의 사용 가능한 회선으로 전환하는 것이 더 효과적인 교차 검증 방법입니다.

선택 기준: 안드로이드 클라이언트의 프로토콜 목록은 실제 구독 내용과 맞아야 합니다. 자주 사용하는 회선에 Hysteria2 또는 TUIC가 포함되어 있다면 클라이언트 코어가 이를 명확히 지원하는지 확인하세요. 복잡한 분할 라우팅이 필요하다면 QR 코드가 스캔되는지만 보지 말고 규칙 엔진도 점검해야 합니다.

구독 가져오기와 업데이트는 따로 검증하세요

구독 링크는 단일 노드 링크가 아닙니다. 일반적으로 서버가 여러 회선과 관련 매개변수를 반환하고, 클라이언트가 이를 다운로드·해석해 로컬 설정에 기록합니다. 처음 가져오기에 성공했다는 사실은 그 시점에 링크에 접근할 수 있고 형식을 해석할 수 있었다는 뜻일 뿐입니다. 이후 업데이트가 정상적으로 진행되는지는 구독 주소의 유효성, 클라이언트의 새로 고침 허용 여부, 로컬 네트워크의 구독 주소 접근 가능 여부에도 달려 있습니다.

수동으로 복사할 때는 공백이나 줄바꿈, 메신저가 만든 리디렉션 포장이 함께 들어가지 않도록 주의하세요. 서비스 패널에서 원본 구독 주소를 복사해 신뢰할 수 있는 클라이언트의 ‘클립보드에서 가져오기’ 또는 ‘구독 추가’ 메뉴에 붙여넣은 뒤 업데이트하는 방식이 안전합니다. 전체 구독 링크를 공개 페이지에 게시하지 마세요. 링크에 계정 권한 식별에 사용되는 토큰이 포함될 수 있습니다.

구독 가져오기
→ 업데이트 실행
→ 회선 목록이 완전한지 확인
→ 프로토콜에 맞는 회선 선택
→ 시스템 VPN 연결 만들기
→ 출구 경로, DNS 및 분할 라우팅 확인

업데이트에 실패했지만 기존 회선으로 계속 연결된다면 로컬 캐시가 남아 있을 수 있으며, 문제는 구독을 가져오는 과정에 있을 가능성이 큽니다. 구독은 업데이트되지만 모든 회선에 연결되지 않는다면 프로토콜 지원, 로컬 네트워크, 서비스 상태를 확인하세요. 일부 회선만 실패한다면 프로토콜 유형과 전송 매개변수를 하나씩 대조하고 전체 구독을 바로 삭제하지 마세요.

✅ 구독 이름이 명확해 다른 테스트 설정과 구분할 수 있습니다.
✅ 업데이트 후 회선 목록의 변화가 분명하게 표시되어 추측에 의존하지 않습니다.
✅ 클라이언트가 프로토콜 유형이나 핵심 매개변수를 표시해 호환성 문제를 찾기 쉽습니다.
✅ 클라이언트를 바꾸기 전에 새 클라이언트가 구독에 포함된 프로토콜과 분할 라우팅 형식을 지원하는지 확인합니다.
❌ 전체 구독 주소를 공개 속도 측정 사이트나 출처가 불분명한 변환 페이지에 붙여넣습니다.
❌ 가져오기에 실패한 뒤 링크의 문자를 반복해서 수정해 원본 토큰을 손상시킵니다.

IEPL, 중계 및 직접 연결이 안드로이드 사용 경험에 미치는 영향

직접 연결 회선은 클라이언트가 원격 진입점에 직접 연결하는 방식으로 경로가 단순합니다. 대신 로컬 통신사 네트워크, 국제 라우팅, 시간대별 변동의 영향을 더 크게 받을 수 있습니다. 중계 회선은 가까운 진입점에 먼저 연결한 뒤 중계 네트워크를 통해 대상 지역으로 전달하며, 일부 공용 네트워크 경로의 불확실성을 줄이는 것이 목적입니다. IEPL 전용 회선은 일반적으로 전용 국제 링크로 주요 국제 구간을 전송하는 방식을 뜻하지만, 구체적인 진입점·출구·조정 방식은 서비스 제공업체가 설계합니다. 라벨만으로 전체 품질을 단정할 수는 없습니다.

안드로이드에서는 회선 유형과 백그라운드 유지는 서로 독립된 계층입니다. IEPL이나 중계 방식이 네트워크 경로를 개선할 수는 있어도 시스템이 클라이언트를 종료하는 것을 막지는 못합니다. 반대로 클라이언트의 백그라운드 유지가 안정적이어도 혼잡하거나 장애가 있는 회선을 복구할 수는 없습니다. 테스트할 때는 클라이언트와 시스템 설정을 고정한 채 회선 유형만 바꿔 변화가 네트워크 경로에서 왔는지 앱 상태에서 왔는지 판단하세요.

일상적인 선택에서 가장 먼 지역을 고집할 필요는 없습니다. 현재 용도에 맞고 경로가 짧으며 연결이 안정적인 회선을 우선 사용하세요. 웹페이지는 열리지만 동영상이 버퍼링된다면 바로 프로토콜 문제라고 단정하지 말고, 먼저 같은 지역의 다른 회선을 비교한 뒤 동영상 앱이 예상한 경로를 사용하는지 분할 라우팅을 확인하세요. 기기 전체에서 네트워크가 끊긴다면 콘텐츠 지역을 계속 바꾸기보다 터널과 DNS부터 점검해야 합니다.

DNS 누출 및 분할 라우팅 규칙 확인

VPN 터널을 만든 뒤에도 앱 트래픽과 DNS 조회가 자동으로 같은 경로를 따르는 것은 아닙니다. 클라이언트는 시스템 DNS, 원격 DNS, 암호화 DNS를 사용하거나 도메인 규칙에 따라 나눠 처리할 수 있습니다. 일반적으로 DNS 누출은 터널을 통해 해석되어야 할 조회가 여전히 로컬 네트워크의 리졸버로 전달되어 조회 대상이 노출되거나 출구 지역과 맞지 않는 해석 결과가 발생하는 상황을 뜻합니다.

확인할 때는 출구 주소와 DNS 조회 출처를 함께 살펴봐야 합니다. 출구 주소 변화만으로는 DNS 경로가 올바르다고 증명할 수 없습니다. 클라이언트가 원격 DNS, 직접 연결 DNS, 규칙 매칭을 지원한다면 프록시 도메인은 예상한 원격 리졸버로, 로컬 도메인은 필요에 따라 직접 연결로 처리되는지 확인하세요. 모든 DNS를 원격으로 강제하면 로컬 네트워크 기기 이름이나 로컬 서비스를 해석하지 못할 수도 있습니다.

분할 라우팅 규칙은 보통 도메인, 주소 범위, 앱 또는 규칙 집합에 따라 경로를 결정합니다. 규칙에 순서가 있다면 앞쪽의 포괄적인 규칙이 뒤쪽의 구체적인 규칙을 덮어쓸 수 있습니다. 예를 들어 ‘모두 프록시’를 먼저 실행하면 뒤의 직접 연결 예외가 적용될 기회를 잃을 수 있습니다. 규칙을 조정한 뒤에는 연결을 다시 만들고 프록시 앱, 로컬 앱, 로컬 네트워크 리소스, 자주 사용하는 웹사이트를 각각 확인하세요.

사용 환경별 추천 기준

화면을 자주 잠그고 네트워크를 전환하는 경우

자동 재연결, 네트워크 변화 감지, 안정적인 전면 서비스 알림을 지원하는 클라이언트를 우선 선택하세요. 설치 후 먼저 배터리 최적화 제외를 완료하고 화면 잠금 복구와 네트워크 전환을 테스트합니다. 프로토콜은 현재 네트워크에서 안정적으로 연결되는 방식을 하나 이상 남겨 두어 UDP에만 의존하는 회선만 설정하고 교차 검증 수단이 없는 상황을 피하세요.

소수의 앱만 해외 회선을 사용하는 경우

클라이언트가 앱별 포함 모드를 지원하는지 먼저 확인하고, 설치된 앱을 목록에서 정확히 인식하는지 점검하세요. 설정 후 선택한 앱과 선택하지 않은 앱에서 각각 출구 경로를 확인합니다. 로컬 네트워크 기기에 접근해야 한다면 합리적인 로컬 네트워크 우회 규칙을 활성화해 프린터, 화면 공유, 로컬 제어 트래픽이 원격 터널로 들어가지 않도록 하세요.

스트리밍과 일상적인 웹 브라우징을 함께 사용하는 경우

클라이언트는 앱별 프록시와 도메인 규칙 기능을 모두 지원해야 합니다. 스트리밍은 앱별로 적합한 회선을 사용하게 하고 일상적인 로컬 서비스는 직접 연결로 유지하세요. 회선 라벨은 1차 선별 기준일 뿐이며 최종 판단은 현재 접속 가능 여부를 기준으로 해야 합니다. 콘텐츠 플랫폼은 정책을 조정할 수 있으므로 한 번의 성공을 장기적인 보장으로 해석해서는 안 됩니다.

개발·원격 협업 및 다중 프로토콜 구독

로그, 프로토콜 매개변수, 규칙 적용 정보를 보여 주는 클라이언트를 우선 선택하세요. 연결에 실패했을 때 로그의 DNS, TLS, 시간 초과, 프로토콜 해석 메시지는 단순한 빨간색 상태 아이콘보다 훨씬 유용합니다. 구독에 여러 프로토콜이 포함되어 있다면 클라이언트 코어가 해당 형식을 계속 지원하는지 확인하고 업데이트 후 인식할 수 없는 회선이 생겼는지 점검하세요.

최종 권장 순서: 안드로이드 VPN은 백그라운드 복구 능력, 배터리 최적화 호환성, 앱별 프록시, 프로토콜 일치, 구독 업데이트, 회선 경로 순으로 비교하세요. 재현 가능한 절차로 클라이언트를 먼저 검증한 다음 서비스 요금제를 비교해야 일상적인 실제 사용에 가까운 판단을 내릴 수 있습니다.

연결 이상은 계층별로 점검하세요

안드로이드 문제는 ‘노드가 좋지 않다’고 오해하기 쉽습니다. 시스템 계층, 클라이언트 계층, 구독 계층, 프로토콜 계층, 회선 계층 순서로 확인하는 편이 효율적입니다. 한 번에 하나의 변수만 바꾸세요. 클라이언트·프로토콜·DNS·회선을 동시에 바꾸면 연결이 복구되어도 원인을 알 수 없습니다.

시스템 계층 확인: VPN 권한이 있고 백그라운드 활동이 제한되지 않았으며 다른 앱이 시스템 VPN 채널을 점유하고 있지 않은지 확인하세요.
클라이언트 계층 확인: 연결을 끊었다가 다시 연결하고 상태가 시스템 표시줄과 일치하는지, 명확한 오류 메시지가 나타나는지 살펴보세요.
구독 계층 확인: 구독 업데이트를 실행하고 회선 목록이 정상적으로 해석되는지, 구독 주소가 잘리거나 오염되지 않았는지 확인하세요.
프로토콜 계층 확인: 클라이언트가 명확히 지원하는 다른 프로토콜로 교차 검증해 특정 프로토콜 문제인지 전체 네트워크 문제인지 구분하세요.
회선 계층 확인: 같은 지역의 다른 사용 가능한 회선으로 전환해 단일 경로의 이상을 서비스 전체의 문제로 확대하지 않도록 하세요.
규칙 계층 확인: 먼저 단순한 규칙으로 기본 연결을 확인한 뒤 앱별 라우팅, 도메인 분할 라우팅, 사용자 지정 DNS를 단계적으로 복원하세요.

이 단계를 완료하면 문제 범위를 대체로 명확하게 좁힐 수 있습니다. 시스템이 프로세스를 종료한다면 백그라운드 권한을 처리하고, 구독이 업데이트되지 않는다면 구독 가져오기를 확인하며, 특정 프로토콜만 실패한다면 코어와 네트워크 호환성을 점검하세요. 특정 회선만 이상하다면 같은 용도의 다른 회선으로 전환하면 됩니다. 이런 방식은 재연결 버튼을 계속 누르는 것보다 빠르고 서비스 지원에 유용한 정보를 전달하기도 쉽습니다.