처음 설치한다면 운영체제와 프로세서 아키텍처에 맞는 Avalonia 데스크톱 버전을 우선 선택하세요. Windows에서 WPF 버전을 안정적으로 사용 중이라면 인터페이스가 달라졌다는 이유만으로 옮길 필요는 없습니다. 이 글에서는 UI 프레임워크, 프록시 코어, 시스템 트래픽 처리 방식을 구분해 두 버전의 사용 범위와 의존성 확인 방법을 살펴보고, 기존 설정을 보존한 채 비교 테스트하는 순서를 안내합니다.
1. Avalonia와 WPF가 바꾸는 부분
Avalonia는 크로스 플랫폼 .NET UI 프레임워크이며, WPF는 Windows용 데스크톱 UI 프레임워크인 Windows Presentation Foundation의 약자입니다. v2rayN에서 두 이름은 창, 목록, 메뉴와 상호작용을 구현하는 방식을 가리킵니다. 서로 다른 프록시 프로토콜이나 서버 요금제가 아닙니다.
v2rayN은 서버 설정, 구독, 라우팅과 코어 프로세스를 관리하며, 실제 프로토콜 연결은 선택한 코어가 처리합니다. VMess, VLESS 등의 프로토콜을 사용할 수 있는지는 노드 설정과 선택한 코어 및 버전의 호환 여부에 달려 있습니다. 이름에 Avalonia가 있다고 노드 연결이 더 빠른 것은 아니며, WPF라고 해서 구형 프로토콜만 연결되는 것도 아닙니다.
| 구분 항목 | 담당 기능 | 확인할 위치 또는 내용 |
|---|---|---|
| UI 프레임워크 | 창, 글꼴, 메뉴, 목록 조작 | 다운로드 페이지의 데스크톱 버전 또는 클래식 WPF 버전 |
| 프록시 코어 | 프로토콜 핸드셰이크, 전송, 라우팅 규칙 적용 | 클라이언트의 코어 선택, 시작 로그, 코어 버전 |
| 노드 설정 | 서버 주소, 포트, 인증 및 전송 매개변수 | 서버 편집 창과 구독 가져오기 결과 |
| 트래픽 처리 | 앱의 요청을 로컬 프록시로 전달 | 시스템 프록시, 앱 내 프록시 또는 TUN 설정 |
예를 들어 브라우저가 로컬 HTTP 프록시를 통해 웹페이지에 접속할 수 있는지는 코어가 실행 중인지뿐 아니라 브라우저가 올바른 포트를 사용하도록 설정됐는지에도 달려 있습니다. 창 모양이 바뀐다고 포트 입력 오류가 저절로 해결되지는 않습니다. 문제를 해결할 때는 인터페이스 버전을 계속 바꾸기보다 먼저 어느 계층에서 문제가 생겼는지 확인하는 편이 효과적입니다.
2. 플랫폼과 사용 방식에 따라 버전 선택하기
다운로드 순서는 ‘운영체제 → 프로세서 아키텍처 → UI 버전’으로 정하세요. Windows에서는 두 UI 버전 중 하나를 선택할 수 있습니다. macOS와 Linux에서는 해당 플랫폼용 Avalonia 데스크톱 버전을 선택해야 하며, Windows용 WPF 프로그램을 복사해 실행할 수는 없습니다.
Avalonia 데스크톱 버전
추천처음 설치할 때 우선 고려할 버전입니다. Windows, macOS, Linux에 맞는 배포 패키지를 선택하면 데스크톱 운영체제가 달라도 비슷한 방식으로 설정을 관리할 수 있습니다. 실제 지원 아키텍처는 다운로드 페이지에 표시된 항목을 확인하세요.
추천 대상: 처음 설치하는 사용자, 여러 운영체제에서 사용하는 사용자, 일관된 조작 방식을 원하는 사용자.
클래식 WPF 버전
Windows용 버전입니다. 기존 노드 목록, 트레이 메뉴와 설정 위치에 익숙하고 현재 설치가 정상 작동한다면 계속 사용해도 됩니다. macOS나 Linux에서 실행하기 위한 호환 버전은 아닙니다.
추천 대상: Windows에서 설정을 안정적으로 사용 중이며 기존 조작 방식을 유지하고 싶은 사용자.
프로세서 아키텍처도 따로 확인해야 합니다. Windows에서는 「설정」→「시스템」→「정보」에서 ‘시스템 종류’를 확인할 수 있습니다. macOS에서는 Apple 메뉴의 「이 Mac에 관하여」에서 칩 정보를 확인하세요. Linux에서는 아래 명령으로 시스템 아키텍처를 확인할 수 있습니다. x86_64는 일반적으로 x64, aarch64는 일반적으로 ARM64에 해당합니다. 아키텍처를 잘못 선택했다면 구독 설정을 바꾸지 말고 설치 패키지를 다시 선택하세요.
uname -m결론: 플랫폼을 먼저 맞춘 뒤 인터페이스를 비교하세요
macOS와 Linux에서는 해당 플랫폼용 Avalonia 패키지를 선택하세요. Windows에 처음 설치한다면 데스크톱 버전을 우선 선택하고, 안정적으로 사용 중인 WPF 환경이 있다면 기존 버전을 유지한 채 별도 폴더에서 테스트한 후 이전 여부를 결정하세요.
3. 인터페이스 차이와 시스템 의존성 확인하기
두 버전은 메뉴 구성, 대화상자 배치, 글꼴 렌더링과 트레이 동작이 다를 수 있습니다. 익숙한 튜토리얼 화면과 다르다고 해서 기능이 없는 것은 아닙니다. 설정을 찾을 때는 버튼 색이나 창 위치에만 의존하지 말고 구독 그룹, 시스템 프록시, 로컬 수신 포트, 라우팅 설정 등 기능 이름을 기준으로 찾아보세요.
설치 전 확인 사항: Windows와 크로스 플랫폼 환경
Windows: 배포 패키지의 의존성 안내 확인
- 설치 파일과 압축 해제 후 실행하는 패키지를 구분하고, 압축 파일은 전체 내용을 풀어야 합니다. 실행 파일만 따로 복사하지 마세요.
- .NET이 없다는 메시지가 표시되면 안내된 런타임 이름, 주 버전과 아키텍처를 확인하세요.
- WPF 프로그램에는 호환되는 .NET Desktop Runtime이 필요할 수 있습니다. 일반 런타임이나 개발 도구가 이를 항상 대신할 수 있는 것은 아닙니다.
- 패키지에 런타임이 포함돼 있다면 다른 버전에 의존성이 필요하다는 이유만으로 관련 없는 런타임을 추가 설치하지 마세요.
macOS·Linux: 시스템 통합 조건 확인
- 패키지가 프로세서 아키텍처와 일치하는지 확인한 뒤, 현재 배포 패키지의 안내에 따라 실행하세요.
- macOS에서 처음 실행할 때 시스템이 차단하면 파일 출처를 먼저 확인한 다음 「시스템 설정」→「개인정보 보호 및 보안」을 살펴보세요.
- Linux에서는 배포판의 그래픽 라이브러리 의존성, 데스크톱 환경과 트레이 지원을 확인하세요. 창이 실행되는 것과 트레이 아이콘이 표시되는 것은 별개의 문제입니다.
- 시스템 프록시와 TUN은 필요한 권한이 서로 다릅니다. 앱 실행에 필요한 조건과 네트워크 트래픽을 처리하는 데 필요한 권한을 혼동하지 마세요.
결론: 필요한 의존성은 현재 패키지의 안내와 실제 오류 메시지로 확인하세요. Avalonia나 WPF라는 이름만으로 추측할 수는 없습니다.
메인 창은 열리지만 코어 실행 직후 오류가 난다면 로그에서 실행 파일 경로, 권한과 포트 사용 여부를 먼저 확인하세요. 반대로 더블클릭해도 창이 뜨지 않는다면 패키지가 제대로 압축 해제됐는지, 런타임이 맞는지부터 살펴보세요. 두 문제는 점검할 지점이 다르므로 구독을 다시 가져와도 앱 실행 문제는 해결되지 않습니다.
4. 기존 설정을 보존하며 이전하는 순서
두 버전 모두 구독을 관리할 수 있다고 해서 모든 버전의 설정 폴더를 그대로 덮어쓸 수 있는 것은 아닙니다. 클라이언트 설정에는 데이터베이스 구조, 코어 경로와 플랫폼별 설정이 포함될 수 있습니다. 새 버전에서 저장한 설정을 구버전이 그대로 읽지 못할 수도 있습니다. 안전하게 이전하려면 먼저 전체 백업을 보관하고, 공통 설정을 옮긴 다음 시스템 트래픽 처리 설정을 확인하세요.
- 기존 환경을 기록하세요. 클라이언트 버전과 코어 이름 및 버전을 저장하고, 현재 서버, 라우팅 모드, 수신 주소와 포트를 기록하세요. 구독 주소는 민감한 정보이므로 공개 스크린샷이나 공유 문서에 포함하지 마세요.
- 먼저 백업한 뒤 테스트하세요. 기존 클라이언트를 종료하고 트레이 프로세스가 완전히 끝났는지 확인한 뒤, 실제 사용 중인 설정 폴더를 백업하세요. 새 패키지는 별도 폴더에 두고 기존 프로그램 파일을 덮어쓰지 마세요.
- 공통 설정부터 가져오세요. 새 버전의 「구독 그룹」→「구독 그룹 설정」에서 그룹과 주소를 확인한 뒤 구독을 업데이트하세요. 메뉴 이름은 버전에 따라 달라질 수 있습니다. 수동으로 추가한 노드는 클라이언트의 내보내기·가져오기 기능을 사용해 인증 매개변수를 하나씩 다시 입력하지 않도록 하세요.
- 포트와 라우팅을 확인하세요. 「설정」→「매개변수 설정」에서 로컬 수신 관련 항목을 확인하고 라우팅, DNS와 코어 선택을 다시 점검하세요. 새로 설치한 버전이 기존 버전의 모든 설정을 자동으로 이어받는다고 가정하지 마세요.
- 네트워크를 처리하는 클라이언트는 하나만 실행하세요. 먼저 앱 내 프록시로 로컬 수신이 되는지 확인한 다음 트레이의 「시스템 프록시」 메뉴에서 「시스템 프록시 자동 설정」을 선택하세요. 테스트가 끝난 뒤 종료할 버전은 계속 꺼 둬야 두 프로세스가 시스템 설정을 번갈아 변경하는 일을 막을 수 있습니다.
이전이 끝나면 같은 목적지 주소로 프록시 경로를 확인하세요. 예를 들어 https://example.com으로 테스트 요청을 보내고 클라이언트 로그에 해당 요청이 나타나는지, 라우팅이 예상대로 선택됐는지 살펴보세요. 웹페이지 하나가 열렸다고 해서 모든 앱의 트래픽이 시스템 프록시나 TUN을 통해 처리된다는 뜻은 아닙니다.
5. 속도·메모리·기능을 공정하게 비교하는 방법
‘Avalonia와 WPF 중 어느 쪽이 더 빠른가?’에는 적어도 두 가지 질문이 들어 있습니다. 창 조작이 원활한지, 프록시 연결이 안정적인지입니다. 전자는 UI 렌더링, 목록 크기와 데스크톱 환경에 영향을 받고, 후자는 주로 서버 경로, 코어 설정, DNS, 라우팅과 네트워크 상태에 좌우됩니다. 웹페이지를 한 번 불러온 결과만으로 UI 프레임워크의 성능을 판단하지 마세요.
- 네트워크 조건을 동일하게 맞추세요: 같은 컴퓨터와 네트워크에서 동일한 노드, 전송 설정, 코어 버전과 라우팅 규칙을 사용하세요. 경로 변화를 버전 차이로 오해하지 않도록 해야 합니다.
- 인터페이스와 네트워크를 따로 기록하세요: UI 테스트에서는 실행 후 조작할 수 있을 때까지 걸린 시간과 노드 필터링 중 멈춤 여부를 기록하세요. 네트워크 테스트에서는 같은 목적지에 연결되는지와 관련 로그를 확인하세요.
- 메모리 측정에는 코어도 포함하세요: 작업 관리 도구에서 UI 프로세스와 UI가 실행한 코어 프로세스를 함께 살펴보세요. 메인 창 프로세스만 확인하면 실제 리소스 사용량을 놓칠 수 있습니다.
- 반복해서 확인하세요: 각 버전을 같은 조건에서 3회 테스트하고 가장 좋은 결과만 고르지 말고 측정 범위를 기록하세요. 3회는 테스트 권장 횟수이며, 이 사이트에서 직접 측정한 성능 결과가 아닙니다.
TUN 모드에서만 실패하고 앱 내 HTTP 프록시는 정상이라면 UI 프레임워크 탓으로 돌리기 전에 권한, 라우팅과 DNS를 확인하세요. 시스템 프록시는 해당 설정을 따르는 앱에 주로 영향을 주며, TUN은 가상 네트워크 인터페이스와 라우팅 처리를 수반합니다. 두 기능은 같은 설정을 다르게 부르는 것이 아닙니다.
6. 버전 선택 FAQ
Windows에서 WPF가 잘 작동하는데 바꿔야 하나요?
인터페이스 이름만 바꾸기 위해 이전할 필요는 없습니다. 여러 운영체제에서 사용해야 하거나 데스크톱 버전에서 특정 작업 흐름이 더 편리한 경우처럼 실제 필요가 있는지 먼저 확인하세요. 테스트해 보려면 기존 폴더를 백업하고 기존 인스턴스를 종료한 뒤 새 버전을 별도 폴더에서 실행하세요. 기존 파일을 바로 덮어쓰면 이전 버전으로 되돌리기 어려울 수 있습니다.
Avalonia로 바꾸면 기존 구독을 계속 사용할 수 있나요?
구독은 대개 다시 추가할 수 있지만 가져오기 결과는 구독 형식과 현재 버전의 지원 여부에 따라 달라집니다. 먼저 「구독 그룹」의 주소를 확인한 뒤 구독을 업데이트하세요. 노드 수나 필드가 다르면 업데이트 로그와 노드 편집 창을 확인하고, 가져오기 문제를 감추기 위해 기존 데이터베이스를 바로 덮어쓰지 마세요.
새 버전은 실행되는데 브라우저가 연결되지 않는 이유는 무엇인가요?
활성 서버를 선택했는지, 코어가 정상적으로 실행됐는지 확인한 다음 로컬 수신 포트를 점검하세요. 예시 포트 10808을 사용하는 경우 앱 내 프록시와 클라이언트 수신 포트가 일치해야 합니다. 마지막으로 트레이의 「시스템 프록시」가 「시스템 프록시 자동 설정」으로 되어 있는지 확인하고, 다른 인스턴스가 여전히 시스템 프록시를 변경하고 있지 않은지도 살펴보세요.
.NET 오류가 뜨면 아무 런타임이나 설치해도 되나요?
오류 메시지에 맞춰 런타임 종류, 주 버전과 아키텍처를 선택해야 합니다. WPF에 필요한 데스크톱 런타임을 일반 런타임과 같은 것으로 볼 수는 없습니다. 현재 패키지의 의존성 안내를 먼저 읽고 런타임을 설치한 다음 클라이언트를 다시 실행해 같은 오류가 사라졌는지 확인하세요.
UI 버전을 바꾸면 VLESS 노드 연결 실패가 해결되나요?
반드시 해결되는 것은 아닙니다. 먼저 양쪽의 코어 버전, 서버 포트, TLS, SNI와 전송 매개변수를 비교하세요. 노드에서 Reality를 사용한다면 관련 인증 매개변수도 확인해야 합니다. 설정이 동일하고 문제가 특정 클라이언트 구현과 관련된다고 확인된 경우에만 버전 차이를 점검 대상으로 삼으세요.
선택 기준은 간단합니다. 플랫폼과 아키텍처가 맞고, 필요한 의존성이 갖춰져 있으며, 자주 쓰는 기능이 정상 작동하고, 기존 설정을 안전하게 보존할 수 있으면 됩니다. UI 버전은 조작 환경을 선택하는 문제입니다. 연결 품질은 코어, 노드와 로컬 네트워크 설정을 하나씩 확인해야 합니다.