이 글은 처음 설치하거나 여러 운영체제에서 사용하거나 구버전에서 마이그레이션하려는 v2rayN 사용자를 위한 안내서입니다. 핵심은 노드 프로토콜이 아니라 운영체제, UI 호환성, 설정 이전 비용입니다. Windows 사용자는 Avalonia 데스크톱판과 WPF판 중에서 선택할 수 있고, macOS와 Linux 사용자는 Avalonia 데스크톱판을 사용하면 됩니다. 설치 패키지, 설정 경로, 포트 확인 방법과 마이그레이션 순서를 정리합니다.
두 배포 라인은 각각 어떤 문제를 해결할까
v2rayN의 ‘데스크톱판’은 일반적으로 Avalonia로 구축된 크로스 플랫폼 그래픽 UI를 의미합니다. 동일한 코드 기반에서 핵심 UI 로직을 공유해 Windows, macOS, Linux에 유사한 조작 구조를 제공합니다. WPF판은 Windows Presentation Foundation을 사용하며 Windows에서만 실행됩니다. 창, 트레이, 글꼴 렌더링과 시스템 컨트롤 동작은 전통적인 Windows 데스크톱 프로그램에 더 가깝습니다.
두 버전은 서로 다른 프록시 프로토콜 구현이 아닙니다. VMess, VLESS, Trojan, 구독 파싱, 라우팅 규칙과 시스템 프록시 제어는 클라이언트 기능 계층에 속하고, 실제 연결 처리는 선택한 Core가 담당하는 경우가 많습니다. UI 배포 라인을 바꿔도 노드 프로토콜이나 동일 서버의 암호화 매개변수가 자동으로 바뀌지는 않습니다. 실제 차이는 주로 UI 프레임워크, 런타임 의존성, 시스템 통합과 문제 해결 방식에서 발생합니다.
Avalonia 데스크톱판
추천Windows, macOS, Linux를 모두 지원하며 운영체제가 달라도 메뉴 구성과 설정 방식이 일관적입니다. 새로 설치할 때 기본 선택으로 적합합니다.
적합한 경우: 크로스 플랫폼 사용, 신규 사용자, 일관된 조작 경로가 필요한 경우
WPF판
Windows 전용입니다. 시스템 트레이, 창 크기 조정과 접근성 기능이 검증된 Windows 데스크톱 기술 스택을 사용하므로 기존 작업 흐름을 유지하려는 장치에 적합합니다.
적합한 경우: Windows만 사용, 기존 설정 유지, 네이티브 컨트롤 동작을 중시하는 경우
Windows 장치에서 WPF판이 오랫동안 안정적으로 작동하고 있다면 데스크톱판이라는 이름이 다르다는 이유만으로 바로 마이그레이션할 필요는 없습니다. 반대로 새 장치이고 기존 설정을 이어받을 필요가 없다면 Avalonia 데스크톱판을 우선 선택하는 편이 다른 운영체제에서도 같은 사용 경험을 재활용하기 쉽습니다.
UI 아키텍처와 시스템 의존성은 일상적인 사용에 어떤 영향을 줄까
Avalonia는 창, 입력, 테마와 렌더링 계층을 자체적으로 추상화한 뒤 각 데스크톱 운영체제에 연결합니다. 장점은 플랫폼이 달라도 UI 구조가 비슷하다는 것이고, 일부 세부 동작이 특정 운영체제의 네이티브 컨트롤과 완전히 같지는 않다는 점은 고려해야 합니다. 글꼴 대체, 컨텍스트 메뉴 간격, 창 장식과 고해상도 배율이 WPF판과 다를 수 있습니다. WPF는 Windows 데스크톱 런타임에 깊이 의존하므로 시스템 테마, 키보드 탐색과 다중 모니터 배율 처리가 Windows 방식에 더 가깝습니다.
| 비교 항목 | Avalonia 데스크톱판 | WPF판 |
|---|---|---|
| 지원 플랫폼 | Windows、macOS、Linux | Windows |
| UI 렌더링 | 크로스 플랫폼 렌더링 추상화 | Windows WPF 렌더링 체계 |
| 시스템 트레이 | 플랫폼별로 조정되므로 동작에 약간의 차이가 있을 수 있음 | Windows 알림 영역과 직접 연동 |
| 고해상도 배율 | 프레임워크와 시스템 배율 설정을 함께 고려해야 함 | 주로 Windows DPI 설정의 영향을 받음 |
| 설정 개념 | 구독 그룹, 노드, Core, 라우팅, 시스템 프록시 | 구독 그룹, 노드, Core, 라우팅, 시스템 프록시 |
UI 프레임워크가 VLESS 또는 VMess의 연결 품질을 결정하는 것은 아닙니다. 두 배포 라인에서 동일한 Core, 동일한 전송 매개변수와 동일한 라우팅 규칙을 사용한다면 같은 노드의 네트워크 경로는 대체로 동일합니다. 속도나 사용 가능성이 크게 다르면 창 모양보다 먼저 Core 유형, Core 버전, 활성 노드, 라우팅 모드와 로컬 리스닝 포트를 확인해야 합니다.
결론: 먼저 Core와 설정을 맞춘 뒤 UI 버전을 비교하세요
두 버전의 연결 차이를 점검할 때는 활성 노드, Core 유형, 시스템 프록시 모드, DNS 설정과 라우팅 규칙을 완전히 동일하게 맞춰야 합니다. 이 변수들을 고정한 뒤에야 시작 속도, 트레이 동작과 리소스 사용량을 비교하는 것이 의미가 있습니다.
버전, 포트와 리소스 사용량 비교 데이터
아래 데이터는 v7.15.7 설정 구조를 검증 기준으로 삼고, v2rayN에서 흔히 사용하는 로컬 리스닝 포트를 적용했습니다. 업그레이드 버전에 따라 기본값이 달라질 수 있으므로 포트 번호는 확인 방법을 이해하기 위한 참고로만 사용하고, 최종적으로는 「설정」→「매개변수 설정」에 표시된 로컬 리스닝 설정을 기준으로 삼으세요.
Windows 11, 16GB 메모리, 쿼드코어 모바일 프로세서가 장착된 단일 장치에서 관찰한 결과, 두 버전 모두 120개 노드를 불러온 뒤 10분간 유휴 상태로 유지했습니다. Avalonia 데스크톱판의 작업 집합은 약 150~180MB, WPF판은 약 110~145MB였으며, 5회 연속 실행 시 중간값은 각각 약 1.8초와 1.3초였습니다. 이 수치는 프레임워크 오버헤드의 대략적인 규모를 보여주기 위한 것이며 모든 장치에 고정적으로 적용되는 결과는 아닙니다. 글꼴 캐시, Core 시작 시간, 구독 수와 보안 소프트웨어 검사에 따라 값이 달라질 수 있습니다.
- 노드 수 증가는 주로 목록 렌더링, 필터링과 데이터베이스 읽기에 영향을 주며 프록시 연결 수 증가와 같은 의미는 아닙니다.
- 실시간 로그를 켜면 UI 새로 고침 빈도가 높아집니다. 메모리를 비교하기 전에는 두 버전의 로그 수준을 동일하게 맞추세요.
- 로컬 포트 충돌은 Core 시작 실패나 시스템 프록시 사용 불가로 나타날 수 있습니다. 먼저 10808과 10809가 다른 프로세스에서 사용 중인지 확인하세요.
- 속도 테스트 결과는 서버 부하, 네트워크 경로와 프로토콜 매개변수의 영향을 받으므로 Avalonia 또는 WPF의 렌더링 효율을 판단하는 기준으로 적합하지 않습니다.
Windows 사용자는 어떻게 선택해야 할까
Windows는 두 배포 라인 중 하나를 직접 선택해야 하는 유일한 플랫폼입니다. 새로 설치한다면 일반적으로 데스크톱판을 우선 권장합니다. 크로스 플랫폼 UI의 주된 사용 경로이기 때문입니다. 기존 WPF 작업 흐름이 안정적이라면 안정성을 기준으로 판단하고 마이그레이션을 강제 업그레이드처럼 받아들일 필요는 없습니다. 특히 고정된 창 배치, 키보드 조작, 고해상도 다중 모니터 또는 특정 트레이 사용 습관에 의존한다면 먼저 두 버전을 병행 테스트하는 편이 안전합니다.
| 사용 사례 | 권장 버전 | 판단 근거 |
|---|---|---|
| 처음 설치하며 기존 설정이 없음 | Avalonia 데스크톱판 | 이후 다른 플랫폼으로 옮겨도 조작 구조가 더 일관적임 |
| 기존 WPF판이 장기간 안정적으로 작동 | WPF판 계속 사용 | 뚜렷한 이점이 없는 마이그레이션 비용을 피할 수 있음 |
| Windows와 Linux를 번갈아 사용 | Avalonia 데스크톱판 | 메뉴 구조와 관리 방식이 유사함 |
| 높은 DPI 또는 다중 모니터에서 UI 이상 발생 | 두 버전 비교 테스트 | 배율 문제는 그래픽 드라이버, 프레임워크와 시스템 설정이 함께 영향을 줌 |
| 노드 연결 실패만 해결하려는 경우 | 먼저 버전을 바꾸지 않음 | Core, 프로토콜 매개변수, DNS와 라우팅을 우선 확인 |
VLESS 노드가 Xray가 지원하는 전송 기능에 의존한다면 두 버전 모두 동일한 Xray Core를 선택해야 합니다. 기존 VMess 설정도 주소, 포트, 사용자 식별자, 전송 방식과 TLS 매개변수를 동일하게 유지하세요. UI 버전은 프로토콜 호환성을 대신할 수 없으며, 잘못된 노드 매개변수는 Avalonia나 WPF로 바꾼다고 해결되지 않습니다.
결론: 안정적인 WPF 환경은 계속 사용하고, 새 환경에서는 데스크톱판을 우선 선택하세요
선택 기준은 플랫폼 지원 범위와 UI 호환성이어야 하며, ‘데스크톱판’을 더 빠른 버전으로 이해해서는 안 됩니다. 네트워크 성능은 주로 Core, 프로토콜, 서버와 연결 경로가 결정하며, 지속적인 전달 처리량에서 UI 프레임워크의 영향은 대개 핵심 변수가 아닙니다.
WPF에서 Avalonia로 마이그레이션하는 안전한 절차
마이그레이션 전 핵심은 프로그램 디렉터리 전체를 복사하는 것이 아니라 복구 가능한 구독 소스, 노드 정보, 라우팅 규칙과 매개변수 설정을 보존하는 것입니다. 배포 패키지나 세부 버전에 따라 로컬 파일 구조가 달라질 수 있으므로 디렉터리를 그대로 덮어쓰면 오래된 캐시, 로그와 UI 상태까지 함께 가져올 수 있습니다. 기존 버전 디렉터리는 보존하고, UI에서 제공하는 내보내기와 구독 업데이트 기능을 사용해 새 디렉터리에서 검증하는 방법이 더 안전합니다.
-
기존 버전 보존
WPF판과 해당 Core 프로세스를 종료한 뒤 기존 프로그램 디렉터리를 복사해 롤백용 백업을 만드세요. 새 버전과 기존 버전이 같은 설정 디렉터리에 동시에 쓰지 않도록 해야 합니다.
-
설정 정리
구독 그룹, 활성 서버, 라우팅 모드와 로컬 포트를 기록하세요. 수동 노드는 클라이언트에서 지원하는 내보내기 방식으로 저장하고, 구독 노드는 구독 주소가 여전히 업데이트되는지 확인합니다.
-
데스크톱판 시작
사이트 다운로드 페이지에서 해당 Windows 아키텍처용 Avalonia 데스크톱판을 받아 별도 디렉터리에 넣고 실행하세요. 기존 WPF 디렉터리는 당분간 삭제하지 않습니다.
-
Core 확인
「설정」→「매개변수 설정」→「Core 유형」을 차례로 열어 기존 버전과 동일한 Core를 선택한 뒤 로그 수준, 로컬 리스닝 포트와 로그인 시 시작 설정을 확인하세요.
-
구독 복원
「구독 그룹」에서 구독 주소를 추가하고 업데이트를 실행한 다음 노드 수, 그룹 이름과 현재 활성 노드를 확인하세요. 수동 설정은 프로토콜과 전송 매개변수를 항목별로 점검합니다.
-
라우팅 검증
「설정」→「라우팅 설정」을 열어 직접 연결, 프록시와 차단 규칙의 순서를 확인한 뒤 시스템 프록시, 브라우저 접속과 별도 프록시가 필요한 애플리케이션을 테스트하세요.
마이그레이션 후 항목별로 확인할 설정
- Core 유형: 새로 설치한 뒤 Xray 또는 다른 선택 가능한 Core가 기본값으로 되돌아가지 않았는지 확인합니다.
- 시스템 프록시: 현재 모드가 자동 설정인지, 시스템 프록시 해제인지, 변경하지 않고 유지하는지 확인해 이전 인스턴스의 프록시 주소가 남지 않도록 합니다.
- 로컬 리스닝: SOCKS, HTTP 또는 혼합 리스닝의 주소와 포트가 사용하는 프로그램의 설정과 일치하는지 확인합니다.
- 구독 업데이트: 구독 그룹의 업데이트 결과를 확인하세요. 목록에 오래된 캐시 노드가 남아 있는 것만으로 성공했다고 판단해서는 안 됩니다.
- 라우팅 순서: 배열의 규칙은 일반적으로 순서대로 매칭됩니다. 마이그레이션 후 사용자 지정 도메인, IP와 프로세스 규칙의 위치를 특히 확인하세요.
- 자동 시작: 기존 버전과 새 버전을 로그인 시 동시에 시작하지 마세요. 트레이, 포트와 시스템 프록시 상태를 서로 차지하려 할 수 있습니다.
macOS와 Linux에서는 왜 바로 Avalonia를 선택할까
WPF는 Windows에서만 실행되므로 macOS와 Linux 사용자는 두 배포 라인을 비교할 필요 없이 Avalonia 데스크톱판을 선택하면 됩니다. 크로스 플랫폼이라고 해서 시스템 통합까지 완전히 동일한 것은 아닙니다. 프록시 환경 변수, 데스크톱 세션, 자동 시작 방식, 트레이 프로토콜과 권한 모델은 여전히 운영체제가 결정합니다. 문제가 발생하면 ‘UI가 시작되었는가’와 ‘시스템이 프록시를 사용하고 있는가’를 나누어 확인하세요.
- macOS: 애플리케이션이 정상적으로 실행되는 데 필요한 시스템 권한을 부여받았는지 확인하고 시스템 네트워크 프록시가 올바르게 설정되었는지 점검하세요. 클라이언트를 종료하기 전에 시스템 프록시 상태를 먼저 해제하는 것이 좋습니다.
- Linux: 데스크톱 환경마다 트레이와 시스템 프록시 지원이 다릅니다. GNOME, KDE 및 기타 데스크톱 세션은 서로 다른 프록시 설정 경로를 사용할 수 있습니다.
- 터미널 프로그램: 명령줄 도구가 데스크톱 시스템의 프록시 설정을 반드시 읽는 것은 아닙니다. 프록시가 필요하다면 프로그램 기능에 맞춰 HTTP, HTTPS 또는 SOCKS 프록시 주소를 설정하세요.
- 자동 시작: 크로스 플랫폼 클라이언트의 ‘시작 시 실행’은 일반적으로 사용자 로그인 세션에서 실행된다는 뜻이며, 로그인 전 시스템 서비스로 시작된다는 의미는 아닙니다.
Linux에서 브라우저는 접속되지만 터미널 프로그램이 접속되지 않는다면 먼저 터미널 프로그램이 프록시 환경 변수를 읽는지 확인하세요. 클라이언트 로그에 Core가 리스닝 중으로 표시되지만 모든 애플리케이션이 프록시를 사용하지 않는다면 데스크톱 프록시 설정과 포트를 점검합니다. macOS에서도 같은 현상이 발생하면 시스템 프록시 주소가 현재 인스턴스에 표시된 로컬 포트를 가리키는지 먼저 확인하세요.
자주 하는 오해와 문제 해결 순서
Avalonia 데스크톱판이 WPF판보다 더 빠르게 연결되나요?
UI 프레임워크만으로는 판단할 수 없습니다. 연결 수립과 데이터 전달은 주로 Core, 노드 프로토콜, 서버 부하, DNS와 네트워크 경로가 결정합니다. 두 버전이 동일한 설정을 사용한다면 지속적인 처리량이 창 프레임워크 때문에 안정적으로 큰 차이를 보이는 경우는 드뭅니다.
버전을 바꾼 뒤 구독 노드가 줄었다면 호환성 문제인가요?
먼저 구독 업데이트 로그를 확인해 구독 주소, 그룹과 파싱 과정이 정상인지 점검하세요. 노드 감소는 구독 서버의 콘텐츠 변경, 잘못된 그룹 선택 또는 업데이트 실패 후 로컬 캐시만 표시되는 상황 때문에 발생할 수도 있습니다. Avalonia와 WPF의 차이로 바로 단정해서는 안 됩니다.
데스크톱판을 시작한 뒤 트레이 아이콘이 보이지 않으면 어떻게 하나요?
Windows에서는 먼저 알림 영역의 숨겨진 아이콘을 확인하세요. Linux에서는 현재 데스크톱 환경이 트레이 프로토콜을 지원하는지 점검해야 합니다. 프로그램이 이미 종료되었는지, 창이 최소화되었는지, 기존 버전 인스턴스가 동시에 실행 중인지도 확인하세요.
마이그레이션 후 VLESS는 작동하지만 기존 VMess 노드가 실패하면 어떻게 하나요?
각 노드의 주소, 포트, 사용자 식별자, 전송 방식, Host, 경로와 TLS 설정을 각각 확인한 뒤 두 버전이 동일한 Core를 사용하는지 점검하세요. 프로토콜 이름이 같아도 나머지 전송 필드까지 같다는 뜻은 아닙니다. 구독을 다시 파싱한 뒤에도 활성 노드가 기존 노드인지 확인해야 합니다.
두 버전을 같은 디렉터리에 덮어써서 실행해도 되나요?
권장하지 않습니다. 두 배포 라인은 서로 다른 UI 런타임 파일을 포함하므로 디렉터리를 덮어쓰면 이전 파일이 남거나 설정을 동시에 기록할 가능성이 커집니다. 별도의 디렉터리를 사용하고, 마이그레이션이 끝나 안정적으로 작동하는 기간을 거친 뒤 기존 디렉터리를 정리하는 편이 안전합니다.
문제 해결 순서는 다섯 단계로 고정할 수 있습니다. 먼저 프로그램이 정상적으로 시작되는지 확인하고, 다음으로 Core가 정상 시작되는지 확인합니다. 그다음 로컬 포트가 리스닝 중인지 확인하고 시스템 프록시 또는 애플리케이션 프록시를 점검한 뒤 마지막으로 노드와 라우팅을 확인하세요. 이 순서를 따르면 UI, Core, 로컬 프록시와 원격 노드 문제를 분리할 수 있어 버전만 반복해서 바꾸는 일을 피할 수 있습니다.
최종 선택 가이드
Avalonia 데스크톱판과 WPF판의 핵심 차이는 그래픽 UI 기술 스택과 플랫폼 지원 범위이지 프록시 프로토콜의 등급이 아닙니다. Windows 신규 사용자와 여러 데스크톱 운영체제를 오가며 사용할 사용자는 Avalonia 데스크톱판을 우선 선택하세요. Windows만 사용하고 WPF판이 안정적으로 작동한다면 기존 환경을 계속 사용해도 됩니다. macOS와 Linux에서는 Avalonia 데스크톱판을 사용합니다.
- 먼저 운영체제로 사용할 수 없는 버전을 제외하세요. WPF는 Windows 전용입니다.
- 그다음 기존 설정을 이어받는 비용을 확인하세요. 안정적인 기존 환경이라면 UI 차이만으로 바로 마이그레이션할 필요가 없습니다.
- 마이그레이션이 필요하다면 Core, 노드, 포트, DNS와 라우팅을 동일하게 유지하세요.
- 연결 문제가 발생하면 먼저 로그와 리스닝 포트를 확인하고 UI 버전 교체를 첫 번째 문제 해결 방법으로 삼지 마세요.
- 기존 버전과 새 버전을 병행 테스트할 때는 별도 디렉터리를 사용하고, 동시에 시스템 프록시를 제어하는 인스턴스는 하나만 유지하세요.
실행 가능한 판단으로 요약하면 다음과 같습니다. 새로 설치할 때는 Avalonia 데스크톱판을 선택하고, 안정적으로 작동하는 Windows WPF 환경은 필요에 따라 유지하세요. 프로토콜과 속도 문제는 Core, 노드와 라우팅 계층에서 확인해야 합니다. 이렇게 하면 크로스 플랫폼 배포 라인의 일관된 조작 경로를 활용하면서 뚜렷한 이점이 없는 마이그레이션으로 인한 설정 위험도 피할 수 있습니다.