v2rayN Avalonia와 WPF 버전 비교: 화면 구성, 지원 OS, 런타임 차이

이 글의 핵심 내용

먼저 운영체제와 CPU 아키텍처에 맞는 패키지를 고른 다음 런타임 요구 사항을 확인하세요. Windows에서는 WPF와 Avalonia 중 선택할 수 있고, macOS와 Linux에서는 해당 플랫폼용 Avalonia 빌드를 사용합니다. 이 글에서는 UI와 프록시 코어의 차이, 패키지 이름 확인법, 실행 오류 점검 순서, 기존 설정을 보존하며 다른 UI 버전을 시험하는 방법을 설명합니다.

UI 프레임워크와 프록시 코어의 차이

WPF는 Windows용 데스크톱 UI 프레임워크이고, Avalonia는 여러 운영체제에서 사용할 수 있는 데스크톱 UI 프레임워크입니다. v2rayN에서는 창, 목록, 메뉴와 데스크톱 조작 방식을 구현하는 데 주로 쓰입니다. 프록시 프로토콜이 아니며 서버에서 별도로 지원해야 하는 연결 방식도 아닙니다. WPF 버전에서 Avalonia 버전으로 바꿔도 VMess를 VLESS로 변경할 필요는 없습니다.

실제 연결은 프록시 코어가 처리합니다. v2rayN UI는 서버 정보를 저장하고 설정 파일을 생성하며 코어 프로세스를 관리합니다. Xray 같은 코어는 프로토콜, 라우팅과 외부 연결을 처리합니다. 따라서 ‘UI가 열리는지’와 ‘프록시로 연결되는지’는 별도로 확인해야 합니다. UI가 정상적으로 실행된 뒤에도 코어 파일, 노드 정보, 시스템 프록시와 라우팅 설정을 점검하세요.

비교 항목	WPF 버전	Avalonia 데스크톱 버전
지원 플랫폼	Windows	Windows 전용
UI 구현	Windows 데스크톱 컨트롤과 조작 방식	크로스 플랫폼 컨트롤과 창 시스템
주요 선택 이유	익숙한 Windows 사용 흐름 유지	여러 데스크톱 OS에서 비슷한 UI 구조 사용
연결 기능 확인	UI 프레임워크 이름만 보지 말고 사용하는 코어, 노드 프로토콜과 설정을 확인
OS 통합 기능 차이	트레이, 시작 프로그램 등록, 시스템 프록시와 권한 처리는 운영체제의 영향을 받음

‘크로스 플랫폼’이라고 해서 압축 파일 하나로 모든 운영체제에서 바로 실행할 수 있는 것은 아닙니다. Avalonia는 UI 기술을 공유하지만 프로그램과 함께 제공되는 코어는 플랫폼과 아키텍처별로 다릅니다. WPF나 Avalonia라는 이름만으로 어느 쪽의 지연 시간이 더 낮다고 판단할 수도 없습니다. 네트워크 성능을 비교하려면 노드, 코어, 라우팅과 테스트 대상을 동일하게 맞추세요.

Windows와 크로스 플랫폼 환경에서 선택하기

현재 WPF 버전이 안정적으로 작동하고 구독 그룹, 서버 목록, 시스템 프록시를 주로 사용한다면 UI 이름만을 이유로 바꿀 필요는 없습니다. Windows와 Linux를 함께 사용하거나 macOS에서도 비슷한 사용 흐름을 원한다면 Avalonia를 먼저 시험해 볼 만합니다. 릴리스에 따라 메뉴 위치가 달라질 수 있으므로 두 UI의 스크린샷을 픽셀 단위로 비교하지 마세요.

사용 환경에 맞는 UI 선택

주로 Windows 사용

WPF에 익숙하고 현재 문제없이 작동한다면 해당 빌드를 계속 사용해도 됩니다.
여러 운영체제에서 같은 방식으로 사용하고 싶다면 별도 폴더에 Avalonia 버전을 설치해 시험해 보세요.
트레이 표시, 화면 배율과 자주 쓰는 단축 동작이 편한지 먼저 확인하세요.

macOS 또는 Linux 사용

Windows 패키지가 아닌 해당 플랫폼용 Avalonia 빌드를 선택하세요.
기기 아키텍처에 따라 x64와 arm64를 구분하세요.
데스크톱 환경의 트레이 지원, 실행 권한과 프록시 설정을 각각 확인하세요.

먼저 플랫폼과 아키텍처가 맞는지 확인한 뒤 조작 방식을 비교하세요. UI 선택이 연결 설정을 대신해 주지는 않습니다.

고해상도 화면에서의 글꼴 크기, 목록 밀도, 마우스 오른쪽 버튼 메뉴와 창 배율은 실제 기기에서 확인하는 것이 좋습니다. Linux의 트레이 표시는 데스크톱 환경과 확장 기능에도 영향을 받습니다. macOS에서는 창을 닫는 동작과 프로세스 종료를 별도로 확인하세요. 창이 사라져도 프로그램이 트레이나 메뉴 막대에서 실행 중일 수 있으니 상태를 먼저 확인한 뒤 다른 버전을 실행하세요.

설치 패키지 이름과 런타임 요구 사항

설치 패키지를 고를 때는 ‘운영체제 → CPU 아키텍처 → UI 종류 → 배포 형식’ 순서로 파일 이름과 릴리스 안내를 확인하세요. 파일 이름의 windows, linux, macos는 대상 운영체제를, x64와 arm64는 대상 아키텍처를 나타냅니다. wpf 표시는 WPF 빌드를 구분하는 데 사용됩니다. 표시가 없더라도 다운로드 페이지의 설명을 함께 확인하세요. 특정 단어가 없다는 이유만으로 빌드 종류를 단정하면 안 됩니다.

Windows: ‘설정’ → ‘시스템’ → ‘정보’를 열고 ‘시스템 종류’를 확인하세요. Windows 버전 번호와 CPU 아키텍처를 혼동하지 마세요.
macOS: Apple 메뉴에서 ‘이 Mac에 관하여’를 열고 칩 또는 프로세서 정보를 확인하세요. Apple 실리콘 기기라면 호환되는 arm64 빌드를 우선 선택하세요.
Linux: 터미널에서 uname -m을 실행하세요. 일반적으로 x86_64는 x64, aarch64는 arm64에 해당합니다. 릴리스 안내에 명시된 시스템 라이브러리 요구 사항도 확인해야 합니다.
배포 형식: 설치 프로그램, 압축 파일과 앱 패키지는 실행 방법이 서로 다릅니다. 압축 파일은 전체 내용을 먼저 풀어야 하며, 압축 미리보기에서 실행 파일만 바로 실행하면 안 됩니다.

두 UI 버전 모두 .NET 기술을 사용하지만 사용자가 런타임을 별도로 설치해야 하는지는 해당 빌드의 배포 방식에 따라 달라집니다. 자체 포함 빌드는 필요한 .NET 런타임 구성 요소를 패키지에 포함하고, 프레임워크 종속 빌드는 시스템에 설치된 호환 런타임을 사용합니다. 자체 포함이라고 해서 운영체제 구성 요소까지 전혀 필요 없는 것은 아닙니다. 특히 Linux에서는 시스템 라이브러리와 그래픽 환경 요구 사항을 확인하세요.

UI 실행에 필요한 런타임과 코어 파일도 따로 확인해야 합니다. 런타임이 없으면 보통 창이 뜨기 전에 문제가 발생합니다. 창은 정상적으로 열리지만 로그에 코어가 없거나 실행 권한이 없다는 내용, 또는 코어를 시작할 수 없다는 내용이 표시된다면 함께 제공된 코어와 경로를 점검하세요. 실행 파일만 복사하면 설정 리소스나 코어 폴더가 누락될 수 있습니다.

설정을 보존하고 다른 UI 버전 시험하기

기존에 사용 중인 폴더를 덮어쓰지 말고 별도 폴더에서 시험하는 것이 좋습니다. 같은 플랫폼의 비슷한 버전끼리는 설정 데이터를 재사용할 수 있지만, 버전 간 데이터 구조와 플랫폼별 경로가 완전히 호환된다고 볼 수는 없습니다. 가장 안전한 순서는 먼저 백업하고 구독으로 노드를 복원한 다음 로컬 설정을 항목별로 확인하는 것입니다.

기존 설정 기록

기존 프로그램에서 ‘설정’ → ‘매개변수 설정’을 열고 로컬 수신 대기 포트, LAN 연결 허용 등의 항목을 기록하세요. 기본 화면의 시스템 프록시 상태, 라우팅 선택과 구독 그룹 주소도 함께 적어 두세요. 종료하기 전에 기존 프로그램의 데이터 폴더를 백업하세요.
기존 인스턴스 종료

트레이 메뉴에서 ‘종료’를 선택하고 기존 프로그램과 코어 프로세스가 모두 중지됐는지 확인하세요. 창만 닫으면 백그라운드 프로세스가 계속 실행될 수 있습니다. 이 상태에서 다른 버전을 실행하면 포트 충돌이 발생할 수 있습니다.
별도 폴더에서 실행

이 사이트의 다운로드 페이지에서 해당 플랫폼용 빌드를 선택한 뒤 배포 형식에 맞게 설치하거나 새 폴더에 전체 압축을 풀어 주세요. 먼저 기본 창이 정상적으로 표시되는지 확인한 다음 노드와 시스템 프록시를 설정하세요.
구독 복원

‘구독 그룹’ → ‘구독 그룹 설정’에서 기존 구독 주소를 추가하고 저장한 다음, ‘구독 그룹’ 메뉴의 업데이트 기능으로 노드를 가져오세요. UI에 따라 그룹 편집 버튼이나 메뉴 위치가 다를 수 있으므로 같은 이름의 기능을 찾아 사용하면 됩니다.
연결 확인

먼저 노드를 선택하고 TUN은 끈 상태로 둔 다음, 기본 화면의 시스템 프록시 메뉴에서 ‘시스템 프록시 자동 설정’을 선택하세요. 일반 브라우저로 접속이 되는지 확인한 뒤 사용자 지정 라우팅, DNS와 기타 트래픽 처리 설정을 복원하세요.

구독은 주로 서버 항목을 복원하며 클라이언트 설정 전체를 되돌리지는 않습니다. 사용자 지정 라우팅, 수신 대기 포트, 단축키, 창 배치와 로컬 파일 경로는 별도로 확인해야 합니다. 운영체제를 바꾸면 기존 폴더의 절대 경로가 특히 쉽게 무효화될 수 있습니다. 구독 주소에는 접근 자격 증명이 포함될 수 있으므로 이전 기록과 스크린샷을 안전하게 보관하고 전체 주소를 공개하지 마세요.

실행과 연결 문제를 단계별로 점검하기

문제가 어느 단계에서 발생하는지 먼저 구분하세요. 더블 클릭해도 창이 뜨지 않으면 플랫폼, 아키텍처와 런타임을 확인합니다. 창은 열리지만 노드 시작에 실패하면 코어 로그를 확인합니다. 노드가 시작됐는데 브라우저가 프록시를 사용하지 않는다면 시스템 프록시와 포트를 점검하세요. 이 순서대로 살펴보면 런타임 문제를 구독 오류로 오해하지 않을 수 있습니다.

UI 구현 방식: WPF와 Avalonia

시험할 때는 클라이언트 인스턴스를 하나만 실행하세요

10808

아래 포트 점검 예시는 설명용이며 기본 포트가 아닙니다

예를 들어 ‘설정’ → ‘매개변수 설정’의 로컬 수신 대기 포트가 10808인데 로그에 address already in use가 표시된다면, 먼저 기존 코어가 해당 포트를 사용 중인지 확인하세요. 아래 명령은 포트 사용 여부만 조회하며 설정을 변경하지 않습니다. 실제 포트가 10808이 아니라면 UI에 표시된 값을 사용하세요. 모든 빌드에 HTTP 포트와 SOCKS 포트가 각각 똑같이 제공된다고 가정하지 마세요.

# Windows: 터미널에서 예시 포트 확인
netstat -ano | findstr :10808

# Linux: 예시 포트를 수신 대기 중인 프로세스 확인
ss -lntp 'sport = :10808'

# macOS: 예시 포트를 수신 대기 중인 프로세스 확인
lsof -nP -iTCP:10808 -sTCP:LISTEN

출력에서 프로세스를 확인한 뒤 종료할 프로그램을 결정하세요. 정체를 모르는 시스템 프로세스를 바로 종료하지 마세요. 클라이언트의 수신 대기 포트를 변경했다면 프록시를 수동으로 설정한 앱에서도 포트를 바꿔야 합니다. 브라우저가 시스템 프록시를 통해 정상 접속된다는 것은 해당 경로가 작동한다는 뜻일 뿐입니다. 모든 명령줄 프로그램이나 시스템 프록시를 사용하지 않는 앱까지 같은 연결을 자동으로 이용한다는 뜻은 아닙니다.

패키지 선택과 설정 이전 FAQ

Windows에서는 반드시 Avalonia로 바꿔야 하나요?

그럴 필요 없습니다. 현재 WPF 버전이 필요한 기능을 제공한다면 계속 사용해도 됩니다. UI를 비교해 보고 싶다면 데이터를 먼저 백업하고 Avalonia를 별도 폴더에서 시험하세요. 트레이, 창 배율, 구독 관리와 시스템 프록시 등 평소 사용하는 기능을 확인하고 기존 폴더를 덮어쓰지 마세요.

UI를 바꾸면 기존 구독을 계속 사용할 수 있나요?

UI 프레임워크를 바꿔도 구독 주소 자체는 달라지지 않습니다. ‘구독 그룹’ → ‘구독 그룹 설정’에서 주소를 다시 추가하고 업데이트하면 확인할 수 있습니다. 파싱에 실패한다면 먼저 구독 형식, 주소 유효성, 코어의 프로토콜 지원 여부를 확인하세요. WPF와 Avalonia에서 노드를 함께 사용할 수 없다고 단정할 필요는 없습니다.

.NET 런타임을 설치했는데도 실행되지 않는 이유는 무엇인가요?

오류 메시지에서 요구하는 프레임워크 이름, 주 버전과 아키텍처를 확인한 뒤 패키지 압축이 제대로 풀렸는지 살펴보세요. WPF에 필요한 Desktop Runtime과 일반 Runtime은 서로 다릅니다. Linux에서는 터미널 실행 로그도 확인해 시스템 라이브러리 누락이나 실행 권한 오류가 없는지 점검하세요.

한 버전은 연결되는데 다른 버전에서는 웹페이지가 열리지 않나요?

포트 충돌을 피하려면 다른 버전을 먼저 종료하세요. 그런 다음 노드, 코어, 라우팅과 DNS를 비교하세요. 기본 화면의 시스템 프록시 메뉴에서 트래픽 처리 설정을 다시 적용하고 앱에 수동으로 지정한 프록시 포트도 확인하세요. 이 조건들이 같아야 연결 결과를 의미 있게 비교할 수 있습니다.

기존 폴더 전체를 그대로 복사해도 되나요?

먼저 기존 폴더의 복사본을 보관하세요. 플랫폼을 바꿀 때는 실행 파일, 코어와 경로가 달라질 수 있으므로 폴더 전체를 덮어쓰지 마세요. 구독을 다시 가져온 뒤 기존 라우팅과 포트를 복원하는 편이 좋습니다. 설정 데이터를 옮겨야 한다면 대상 버전의 호환성 안내를 먼저 확인하세요.

최종 선택은 세 가지를 확인하면 됩니다. 패키지가 기기와 맞는지, 런타임 요구 사항을 충족하는지, 자주 쓰는 조작이 편한지 살펴보세요. Windows 사용자는 익숙한 방식에 따라 두 UI를 비교하면 됩니다. macOS와 Linux 사용자는 해당 플랫폼용 Avalonia 빌드를 선택하세요. 네트워크 문제가 생기면 코어, 노드와 트래픽 처리 설정을 점검하고 UI 이름만으로 연결 성능을 판단하지 마세요.