v2rayN 데스크톱 버전과 WPF 버전의 차이: Avalonia 크로스플랫폼 버전 선택 가이드

Avalonia 데스크톱 버전과 WPF 버전의 핵심 차이

두 버전의 가장 큰 차이는 프록시 프로토콜이 아니라 사용자 인터페이스 기술입니다. Avalonia는 크로스플랫폼 UI 프레임워크이므로 하나의 v2rayN 데스크톱 UI를 Windows, macOS, Linux용으로 빌드할 수 있습니다. WPF는 Windows 데스크톱 UI 기술이어서 WPF 버전은 Windows에서만 사용할 수 있습니다. 두 버전 모두 구독 관리, 노드 선택, 라우팅 설정, 시스템 프록시 제어, 코어 프로세스 관리를 담당합니다. 실제 연결 기능은 창을 어떤 프레임워크로 그렸는지가 아니라 패키지에 포함되거나 사용자가 지정한 Xray 코어에 주로 좌우됩니다.

동일하게 유효한 설정을 사용한다면 Avalonia나 WPF로 바꿔도 VMess, VLESS, Trojan, Shadowsocks, REALITY 및 일반적인 전송 방식이 자동으로 달라지지 않습니다. 노드 주소, 포트, 사용자 식별자, 전송 계층, 보안 매개변수, 라우팅 규칙이 같다면 코어에 전달되는 설정 대상도 같아야 합니다. 따라서 “WPF에서는 작동하지만 Avalonia에서는 작동하지 않는 노드”를 UI 프레임워크 탓으로 단정해서는 안 됩니다. 코어 버전, 설정 이전 상태, 권한, DNS, 시스템 프록시 상태도 함께 확인해야 합니다.

“데스크톱 버전”이라는 명칭은 런타임이 필요한 설치 패키지와 혼동하기 쉽습니다. 다운로드할 때는 파일명에 desktop이 있는지만 보지 말고 플랫폼, 아키텍처, UI 유형, 런타임 포함 여부를 함께 확인해야 합니다. Windows x64를 예로 들면 프레임워크 종속 패키지는 대체로 용량이 작지만, 페이지에 안내된 .NET 런타임이 시스템에 설치되어 있어야 합니다. 자체 포함 패키지는 필요한 실행 구성 요소를 함께 제공하므로 용량이 더 크며, 런타임을 별도로 관리하고 싶지 않은 환경에 적합합니다.

시스템 지원, UI, 트레이 동작 비교 방법

운영체제는 가장 명확한 선택 기준입니다. macOS와 Linux에서는 WPF가 실행되지 않으므로 Avalonia 데스크톱 버전을 선택하면 됩니다. Windows는 두 버전 중에서 고를 수 있습니다. 다른 플랫폼과 비슷한 UI를 원한다면 Avalonia를, Windows 알림 영역, 창 최소화, 시작 프로그램 등록, 네이티브 파일 대화상자를 중시한다면 WPF 버전을 우선 고려하세요.

Avalonia의 장점은 플랫폼 간 구조가 통일된다는 점이지만, “통일”이 세 운영체제의 데스크톱 동작이 완전히 같다는 뜻은 아닙니다. macOS 메뉴 막대, Linux의 데스크톱 환경별 트레이 프로토콜, Windows 알림 영역은 구현 방식이 서로 다릅니다. 기본 창을 닫았을 때 프로그램이 종료되는지 트레이에 남는지도 v2rayN 옵션과 데스크톱 환경 지원 여부의 영향을 받습니다. 처음 실행한 뒤에는 창 닫기, 트레이 아이콘 더블클릭, 트레이 메뉴 우클릭, 프로그램 종료를 직접 테스트하세요.

고해상도 배율도 별도로 확인할 필요가 있습니다. 125%, 150% 배율이나 다중 모니터의 배율이 서로 다른 환경에서 노드 목록 열 너비, QR 코드 창, 로그 창, 메뉴 팝업 위치를 살펴보세요. 글자가 잘리면 먼저 시스템 배율 설정과 현재 v2rayN 버전을 확인한 뒤 클라이언트를 다시 시작해 보세요. 순수한 UI 문제를 해결하려고 노드 설정을 수정해서는 안 됩니다.

Linux 사용자는 사용하는 데스크톱 환경이 트레이를 지원하는지도 확인해야 합니다. 트레이 아이콘이 없다고 해서 코어가 실행되지 않는 것은 아닙니다. 기본 창에서 연결 상태와 로그를 확인하거나 로컬 리스닝 포트를 점검할 수 있습니다. macOS 사용자는 처음 실행할 때 시스템이 표시하는 네트워크 접근 권한을 처리한 뒤, 시스템 프록시를 전환하고 브라우저로 실제 접속해 적용 여부를 확인하세요.

시스템 프록시, 라우팅 규칙, 코어 실행에 차이가 있을까?

v2rayN의 “시스템 프록시”와 “코어 실행”은 서로 다른 계층의 기능입니다. 코어가 시작되면 로컬 주소에서 SOCKS, HTTP 또는 혼합 프록시 포트를 리슨합니다. 시스템 프록시 기능은 Windows, macOS 또는 Linux 데스크톱 환경의 프록시 설정을 해당 포트로 지정합니다. 코어는 정상적으로 실행되지만 시스템 프록시가 설정되지 않았다면 프록시를 수동으로 설정한 앱은 연결되더라도 일반 브라우저는 여전히 직접 연결할 수 있습니다.

WPF 버전은 Windows에서 시스템 프록시 인터페이스를 호출하며, 일반적으로 기본 창이나 트레이 메뉴의 「시스템 프록시」에서 조작합니다. Avalonia 버전에도 해당 기능이 있지만 메뉴 위치와 상태 아이콘은 버전과 플랫폼에 따라 달라질 수 있습니다. 전환한 뒤에는 메뉴의 체크 표시만 보지 말고 시스템 프록시 주소가 127.0.0.1을 가리키는지, 포트가 「설정」→「매개변수 설정」의 로컬 포트와 일치하는지도 확인하세요.

1. 서버 목록에서 이미 작동하는 것으로 확인된 노드를 선택하고 활성 서버로 지정합니다.
2. 「설정」→「매개변수 설정」을 열고 로컬 SOCKS, HTTP 또는 혼합 프록시 포트를 기록합니다.
3. 코어를 시작하고 로그에 리스닝 성공 메시지가 나타나는지 확인합니다. 포트 충돌이나 설정 구문 분석 오류가 없어야 합니다.
4. 기본 창이나 트레이 메뉴에서 시스템 프록시를 열고 필요에 따라 자동 구성 또는 전역 프록시 모드를 선택합니다.
5. 브라우저를 열어 실제로 접속한 다음 직접 연결 모드로 한 번 전환하여 설정에 따라 트래픽 경로가 실제로 바뀌는지 확인합니다.

라우팅 규칙 역시 생성된 코어 설정에 의해 실행됩니다. 도메인 규칙, IP 규칙, geosite, geoip, 직접 연결 출구, 프록시 출구, 차단 출구의 로직은 UI가 Avalonia인지 WPF인지에 따라 달라지지 않습니다. 다만 두 UI의 라우팅 편집기는 표 레이아웃, 버튼 위치, 기본 열 너비가 다를 수 있으므로 이전 후 규칙 순서를 확인해야 합니다. 앞쪽 규칙이 먼저 일치해 최종 출구를 바꿀 수 있습니다.

특정 앱만 프록시를 사용하게 하려면 시스템 프록시는 끈 채 앱 내부에 127.0.0.1과 로컬 포트를 입력하면 됩니다. 이때 프록시 유형을 구분해야 합니다. 앱에 SOCKS5를 입력했다면 SOCKS 리스닝 포트와 연결해야 하고, HTTP를 입력했다면 HTTP 또는 호환되는 혼합 포트와 연결해야 합니다. 10808과 10809를 서로 바꾸는 것은 이전 후 “코어는 시작됐지만 앱이 연결되지 않는” 대표적인 원인 중 하나입니다.

Windows에서 10808 포트 확인:
netstat -ano | findstr :10808

macOS 또는 Linux에서 10808 포트 확인:
lsof -nP -iTCP:10808 -sTCP:LISTEN

운영체제와 사용 습관에 따른 버전 선택

Windows만 사용하는 사용자라면 WPF 버전이 대체로 더 직접적인 출발점입니다. 특히 알림 영역, 트레이 최소화, 시스템 시작 시 자동 실행, Windows 네이티브 창 동작에 익숙한 사용자에게 적합합니다. 기존 WPF 버전의 설정이 안정적이고 크로스플랫폼 이전이 필요하지 않다면 Avalonia가 크로스플랫폼 프레임워크라는 이유만으로 바로 바꿀 필요는 없습니다.

Windows 사용자가 Avalonia를 선택할 만한 경우는 macOS나 Linux 기기와 비슷한 UI를 유지하고 싶거나, 크로스플랫폼 버전의 메뉴 구조에 미리 익숙해지고 싶은 때입니다. 전환하기 전에 구독 주소, 라우팅 규칙, 필요한 사용자 설정을 백업하세요. 이전 프로그램 디렉터리 전체를 새 디렉터리에 덮어쓰는 것은 권장하지 않습니다. 배포 버전에 따라 UI 버전, 런타임 구조, 설정 파일 구성이 달라질 수 있기 때문입니다.

macOS와 Linux 사용자는 두 버전을 반복해서 비교할 필요 없이 해당 플랫폼과 프로세서 아키텍처에 맞는 Avalonia 빌드를 선택하면 됩니다. 다운로드 전에 기기 아키텍처를 확인하여 호환되지 않는 프로세서 환경에 x64 빌드를 사용하지 않도록 하세요. Linux는 배포 패키지 형식에 필요한 실행 권한과 데스크톱 의존성도 확인해야 하며, macOS는 최초 실행에 필요한 시스템 보안 허용과 네트워크 권한을 처리해야 합니다.

업무 환경과 개인 환경에서 결론이 달라질 수도 있습니다. 업무용 기기에서 시스템 프록시 변경, 시스템 시작 시 자동 실행, 백그라운드 프로그램이 일괄적으로 제한된다면 먼저 기기 관리 규정을 따르고 앱 수준 프록시로 테스트하세요. 개인 기기는 사용 빈도에 따라 자동 실행 여부를 정할 수 있지만, 어느 환경에서든 두 개의 v2rayN 인스턴스를 동시에 실행해 같은 리스닝 포트를 경쟁하게 만드는 것은 피해야 합니다.

• Windows만 사용: 크로스플랫폼 UI가 꼭 필요한 경우가 아니라면 WPF 버전을 먼저 선택하세요.
• Windows와 다른 데스크톱 플랫폼을 함께 사용: 메뉴 구조 전환 비용을 줄이려면 Avalonia로 통일할 수 있습니다.
• 트레이 안정성 중시: Windows에서는 WPF를 먼저 테스트하고, Linux에서는 데스크톱 환경의 트레이 프로토콜 지원 여부를 먼저 확인하세요.
• 이미 안정적인 설정이 있음: 현재 정상 작동하는 버전은 유지하고 설정을 내보내 이전 테스트를 진행하세요. 기존 디렉터리를 직접 덮어쓰지는 마세요.
• 런타임 설치가 제한됨: 다운로드 페이지의 안내를 확인하고 현재 시스템과 실행 환경에 맞는 빌드 유형을 선택하세요.

한 버전에서 다른 버전으로 이전하는 절차

이전의 목표는 필요한 설정을 보존하면서 기존 UI의 캐시, 창 상태, 호환되지 않는 설정을 새 버전에 그대로 가져오지 않는 것입니다. 시작하기 전에 v2rayN을 종료하고 작업 관리자나 시스템 프로세스 목록에 v2rayN과 Xray 프로세스가 남아 있지 않은지 확인하세요. 프로그램이 실행 중인 상태에서 설정을 복사하면 파일이 완전히 기록되지 않을 수 있습니다.

구독 사용자는 구독 그룹 이름, 구독 주소, 업데이트 방식, 사용자 메모를 먼저 기록하는 것이 좋습니다. 수동으로 추가한 노드는 클라이언트의 내보내기 기능으로 공유 링크나 설정을 저장하세요. 라우팅에서는 현재 활성화된 규칙 집합, 규칙 순서, 기본 출구, DNS 설정을 기록해야 합니다. 창 크기, 테마, 목록 열 너비보다 이 항목들이 이전할 가치가 높습니다.

1. 기존 버전에서 구독을 한 번 업데이트하고 더 이상 사용하지 않는 중복 노드를 삭제합니다.
2. 필요한 서버 설정을 내보내고 구독 주소와 그룹 설정은 별도로 기록합니다.
3. 「설정」→「매개변수 설정」을 열어 로컬 포트, 로그 수준, 시스템 프록시 모드, 시스템 시작 시 자동 실행 상태를 기록합니다.
4. 기존 버전을 완전히 종료한 뒤 새 버전을 별도의 새 디렉터리에 압축 해제하거나 설치합니다.
5. 새 버전을 처음 실행한 뒤에는 시스템 프록시를 바로 켜지 말고 구독과 노드를 가져온 다음 필드를 확인합니다.
6. 노드 하나를 선택해 코어를 시작하고 로그가 정상인지 확인한 뒤 시스템 프록시를 켜 브라우저로 테스트합니다.
7. 라우팅과 DNS를 확인한 뒤 테스트가 끝나면 기존 디렉터리를 유지할지 결정합니다.

기존 버전이 10808을 사용했는데 새 버전의 첫 실행에서 다른 포트가 생성되면 기존 포트에 의존하는 브라우저 확장 프로그램, 개발 도구, 명령줄 환경은 자동으로 변경되지 않습니다. 새 버전의 포트를 기존 값으로 바꾸거나 호출하는 쪽의 설정을 하나씩 수정할 수 있지만, 두 프로그램이 동시에 127.0.0.1:10808을 리슨하지 않도록 해야 합니다.

이전 후 노드 목록은 정상인데 연결에 실패한다면 먼저 코어 로그를 비교하고 모든 구독을 바로 삭제하지 마세요. 서버 주소 확인, 시스템 시간, 전송 매개변수, REALITY 관련 필드, TLS 서버 이름, 로컬 포트 점유 상태를 중점적으로 확인해야 합니다. 모든 노드가 동시에 실패한다면 코어, 권한, DNS, 시스템 프록시 문제일 가능성이 높고, 특정 노드 하나만 실패할 때는 해당 노드의 매개변수를 먼저 확인하세요.

다운로드 전과 실행 후 확인 목록

다운로드 전에는 운영체제, 프로세서 아키텍처, UI 유형, 런타임 형태 네 가지만 확인하면 됩니다. Windows x64 사용자는 Avalonia와 WPF 중에서 선택할 수 있고, macOS와 Linux 사용자는 해당 Avalonia 빌드를 선택합니다. 프레임워크 종속 빌드와 자체 포함 빌드의 핵심 차이는 실행 구성 요소를 프로그램이 함께 제공하는지 여부이며, 이를 서로 다른 프로토콜 기능으로 오해해서는 안 됩니다.

실행 후에는 “설정, 코어, 포트, 시스템 프록시, 라우팅” 순서로 확인하세요. 이 순서를 따르면 UI 문제와 네트워크 문제를 구분할 수 있습니다. 창이 열린다는 것은 UI 프로세스가 시작됐다는 뜻일 뿐이고, 로그에 코어 리스닝 성공이 표시되어야 로컬 프록시 진입점이 만들어진 것입니다. 브라우저 트래픽이 예상대로 전환되어야 시스템 프록시 설정이 완전히 적용된 것입니다.

• Windows, macOS, Linux 중 해당 운영체제용 빌드를 다운로드했는지, 프로세서 아키텍처가 기기와 일치하는지 확인합니다.
• Windows 사용자는 압축 파일 용량이 아니라 Avalonia 또는 WPF를 명확히 선택해야 합니다.
• 프레임워크 종속 빌드는 먼저 페이지에 명시된 .NET 런타임 요구 사항을 충족해야 합니다.
• 처음 실행한 뒤 「설정」→「매개변수 설정」으로 이동해 실제 로컬 리스닝 포트를 기록합니다.
• 정상 작동하는 노드를 하나 실행하고 코어 로그에 설정 구문 분석 또는 포트 충돌 오류가 없는지 확인합니다.
• 시스템 프록시를 켠 뒤 실제 접속을 테스트하고, 다시 직접 연결로 전환해 상태 변경이 적용되는지 확인합니다.
• 사용자 지정 라우팅을 가져온 뒤 노드 목록만 보지 말고 규칙 순서, 기본 출구, DNS를 확인합니다.
• 창을 닫은 뒤 동작이 예상과 일치하는지 확인하고 트레이 메뉴에서 종료 항목을 찾습니다.

아직 결정하기 어렵다면 현재 안정적인 버전은 유지하고 다른 버전을 별도의 디렉터리에 넣어 짧게 테스트해 보세요. 동일한 구독, 동일한 노드, 동일한 라우팅 조건에서 시작 속도, 트레이 동작, 시스템 프록시 전환, 절전 모드 복귀를 각각 확인하면 됩니다. 이러한 실제 조작을 거치면 UI 스크린샷만 보고 선택하는 것보다 결과의 신뢰도가 높습니다.