Project V 오픈소스 생태계 총정리: V2Fly, Xray와 v2rayN/v2rayNG의 관계

관계도 먼저 보기: 프로젝트·커널·클라이언트의 3계층

V2Ray 생태계를 이해할 때 가장 흔한 오해는 Project V, V2Ray, V2Fly, Xray와 클라이언트 이름을 같은 종류로 보는 것입니다. 실제로는 서로 다른 계층에 속합니다. Project V는 이 기술 생태계의 역사적 명칭이자 상위 개념이고, V2Fly와 Xray는 계속 발전하는 두 커널 계열입니다. v2rayN, v2rayNG, v2flyNG는 사용자가 조작하는 클라이언트입니다.

Project V와 V2Ray: 도구 이름에서 설정 언어로

Project V는 처음부터 네트워크 프록시 도구, 프로토콜과 조합 가능한 설정을 중심으로 발전했습니다. V2Ray가 가장 널리 알려진 핵심 구현이었기 때문에 오랫동안 ‘V2Ray’는 프로그램, 설정 형식, 노드 유형은 물론 전체 도구 생태계를 가리키는 말로도 사용됐습니다. 지금도 ‘V2Ray 노드’, ‘V2Ray 설정’, ‘V2Ray 클라이언트’라는 표현을 볼 수 있지만, 이 말들이 항상 같은 소프트웨어 패키지를 뜻하는 것은 아닙니다.

엔지니어링 관점에서 V2Ray의 핵심 가치는 단순히 하나의 프로토콜에 있지 않고, 조합 가능한 데이터 흐름 모델에 있습니다. 연결은 inbounds로 들어와 라우팅 판단을 거친 뒤 outbounds로 나갑니다. DNS, 정책, 로그와 전송 계층은 각각 보조 기능을 제공합니다. VMess는 이 생태계 초기에 중요한 프로토콜이었지만 V2Ray 설정이 곧 VMess를 의미하는 것은 아니며, 클라이언트에 ‘V2Ray 설정’이 표시된다고 해서 vmess:// 링크만 가져올 수 있는 것도 아닙니다.

{
  "inbounds": [
    {
      "tag": "local",
      "protocol": "socks",
      "port": 10808
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {}
    }
  ],
  "routing": {
    "rules": []
  }
}

위 구조는 커널 작동의 기본 범위를 보여 줍니다. 로컬 앱이 트래픽을 인바운드로 넘기면 라우팅 모듈이 도메인, 주소 또는 포트에 따라 아웃바운드를 선택하고, 아웃바운드가 노드 프로토콜에 맞춰 연결을 수립합니다. 그래픽 클라이언트는 노드 입력값, 구독 내용과 사용자 설정을 유사한 실행 설정으로 변환한 뒤 커널을 시작합니다. 사용자가 보는 것은 스위치와 목록이지만 실제 연결을 실행하는 것은 백그라운드 커널입니다.

V2Fly와 Xray: 공통 기반에서 갈라진 두 커널 계열

프로젝트가 발전하는 과정에서 V2Ray의 커뮤니티 유지보수는 V2Fly 계열로 이어졌고, Xray는 유사한 코드와 설정 기반에서 별도의 커널 계열로 발전했습니다. 두 계열은 인바운드, 아웃바운드, 라우팅, DNS, VMess, VLESS와 여러 전송 방식 등 역사적으로 공유하는 개념이 많아 기본 설정이 비슷해 보일 때가 많습니다. 그러나 ‘비슷하다’고 해서 모든 필드, 프로토콜 확장과 동작이 완전히 같은 것은 아닙니다.

V2Fly 계열

V2Fly는 V2Ray의 모듈식 구조를 이어 가며, 표준 V2Ray 설정 모델과 VMess 연결, 일반적인 라우팅 기능에 의존하는 환경에 적합합니다. V2Fly는 독립적으로 유지보수되는 프록시 커널이지 그래픽 클라이언트가 아닙니다. 데스크톱이나 Android 화면이 실제 연결을 완료하려면 커널을 시작하고 설정을 생성하며 로그를 읽어야 합니다.

Xray 계열

Xray는 유사한 모델을 바탕으로 프로토콜과 전송 기능을 계속 확장하고 있습니다. 실제 선택에서 가장 뚜렷한 기준은 보통 REALITY입니다. 노드에 security=reality, 공개 키, 짧은 식별자, 서버 이름 등의 매개변수가 명시되어 있다면 해당 기능을 지원하는 Xray 커널을 사용해야 합니다. 이런 링크를 해당 구현이 없는 커널로 가져오기만 하면 시작 실패, 필드 무시 또는 연결 핸드셰이크 실패가 발생할 수 있습니다.

두 계열은 단순히 ‘신형과 구형’으로 나뉘는 관계가 아닙니다. 각자 버전을 관리하고 문제를 수정하며 기능을 조정합니다. 버전 번호도 프로젝트를 넘어 직접 비교할 수 없습니다. 예를 들어 Xray의 특정 버전 숫자가 더 크다고 해서 어떤 V2Fly 버전의 직접적인 업그레이드 패키지라는 뜻은 아닙니다. 신뢰할 수 있는 판단 기준은 노드에 필요한 프로토콜 기능, 현재 클라이언트에 내장된 커널, 그리고 매개변수가 올바르게 로드되었는지를 보여 주는 실행 로그입니다.

클라이언트와 커널: 인터페이스 계층과 실행 계층의 협업

v2rayN, v2rayNG와 v2flyNG는 모두 클라이언트라고 할 수 있지만, 프록시 프로토콜 그 자체는 아닙니다. 클라이언트는 설정 관리 문제를 해결합니다. 공유 링크 수신, 구독 주소 저장, 노드 목록 표시, 실행 설정 생성, 시스템 프록시 전환, 로그 확인과 커널 시작·중지를 담당합니다.

커널은 네트워크 실행을 담당합니다. 로컬 포트 수신, 대상 주소 확인, 라우팅 규칙 적용, 원격 연결 수립, 전송과 보안 매개변수 처리가 여기에 포함됩니다. 두 계층을 구분하면 다음과 같은 현상도 쉽게 설명할 수 있습니다.

• 링크는 정상적으로 가져왔지만 노드에 연결할 수 없음: 클라이언트가 공유 형식을 인식했더라도 커널의 연결 단계에서 프로토콜 매개변수, 네트워크 경로 또는 서버 상태 때문에 실패할 수 있습니다.
• 구독 업데이트는 성공했지만 목록의 노드를 사용할 수 없음: 구독은 설정 목록일 뿐이며, 업데이트 성공이 목록의 모든 원격 진입점이 연결 가능한 상태라는 뜻은 아닙니다.
• 클라이언트를 바꾸자 같은 노드의 결과가 달라짐: 두 클라이언트가 서로 다른 커널 계열이나 버전, 기본 DNS와 라우팅 설정을 사용할 수 있습니다.
• 커널 로그는 정상인데 브라우저가 프록시를 사용하지 않음: 연결 실행 계층은 시작됐지만 시스템 프록시 또는 앱 프록시 진입점이 클라이언트의 수신 포트를 가리키지 않는 상태입니다.

공유 링크 해석은 보통 클라이언트가 담당합니다. 예를 들어 vmess:// 또는 vless://에는 노드에 필요한 프로토콜, 주소, 포트와 전송 정보가 들어 있습니다. 구독 주소는 업데이트 가능한 노드 목록을 반환합니다. 클라이언트는 이러한 외부 형식을 내부 설정으로 변환하지만, 커널이 자동으로 구독 그룹이나 화면의 메모 이름까지 관리해 주지는 않습니다.

v2rayN·v2rayNG·v2flyNG: 대응 관계와 활용 상황

v2rayN: 데스크톱 설정과 시스템 프록시 제어

v2rayN은 데스크톱 환경을 대상으로 하며 서버 목록, 구독 그룹, 라우팅 모드, 시스템 프록시와 커널 프로세스를 통합 관리하는 데 초점을 둡니다. VMess, VLESS 등의 일반적인 노드를 처리할 때는 보통 Xray 계열을 기반으로 연결 기능을 제공합니다. REALITY가 필요한 노드라면 현재 v2rayN 버전과 실제로 호출되는 Xray 커널 버전도 함께 확인해야 합니다.

데스크톱의 장점은 상태를 한눈에 확인할 수 있다는 점입니다. 로컬 수신 포트, 시스템 프록시 모드, 실시간 로그와 라우팅 결과를 점검할 수 있습니다. Windows 사용자는 보통 데스크톱 패키지를 바로 사용하고, macOS와 Linux 사용자는 다운로드 페이지에서 플랫폼에 맞는 파일을 선택한 뒤 프로세서 아키텍처가 일치하는지 확인해야 합니다. 플랫폼이 다른 압축 패키지와 실행 파일은 서로 바꿔 사용할 수 없습니다.

v2rayNG: Android용 Xray 계열

v2rayNG는 Android 클라이언트로, Xray 커널을 사용해 연결을 처리합니다. VMess, VLESS와 REALITY 등 Xray 기능이 필요한 노드에 적합합니다. QR 코드 스캔, 클립보드 가져오기, 구독 그룹, 라우팅 규칙과 앱별 프록시 등 모바일 환경에 맞는 조작 기능을 제공합니다. REALITY가 명시된 VLESS 노드를 받았다면 v2rayNG는 세 클라이언트 중 Android에서 가장 직접적인 선택인 경우가 많습니다.

모바일에서 ‘테스트 지연 시간은 정상인데 앱에 접속할 수 없음’이 발생하면 노드 테스트만 반복해서는 안 됩니다. 현재 설정이 실제로 시작되었는지, 시스템 연결 권한이 적용되었는지, 앱별 목록에서 대상 앱이 제외되지 않았는지, 라우팅 규칙이 대상 도메인을 잘못된 아웃바운드로 보내고 있지 않은지도 확인해야 합니다.

v2flyNG: Android용 V2Fly 계열

v2flyNG는 V2Fly 커널을 사용하려는 Android 환경을 대상으로 합니다. v2rayNG와 화면의 용도는 비슷하지만 기반 커널 계열은 다릅니다. 기존 노드와 설정이 V2Fly 표준 기능을 중심으로 구성되어 있거나 V2Fly 환경의 연결 동작을 재현해야 한다면 v2flyNG를 사용해 커널을 일관되게 유지하기 쉽습니다.

v2flyNG를 선택할 때 ‘링크를 가져오는 데 성공했다’고 해서 모든 확장이 지원된다고 판단해서는 안 됩니다. 특히 설정이 Xray 환경에서 생성된 것이라면 프로토콜, 보안 방식과 전송 필드를 하나씩 확인해야 합니다. 커널이 지원하지 않는 확장을 만났다면 주소, 포트 또는 로컬 프록시 스위치를 반복해서 수정하기보다 호환되는 커널 계열로 바꾸는 것이 올바른 방법입니다.

프로토콜별 커널 선택: VMess, VLESS와 REALITY

클라이언트를 고를 때 가장 실용적인 방법은 소프트웨어 이름을 먼저 비교하는 것이 아니라 노드 매개변수를 먼저 확인하는 것입니다. 프로토콜, 전송 방식과 보안 계층이 연결에 필요한 기능을 결정합니다.

VMess는 Project V 생태계에서 오랜 역사를 가진 프로토콜로, 노드 정보에는 보통 사용자 식별자, 주소, 포트, 전송 유형과 TLS 설정이 포함됩니다. VLESS는 더 간결한 프로토콜 설계를 사용하지만, VLESS가 곧 REALITY를 의미하는 것은 아닙니다. 링크나 설정에 REALITY 보안 방식이 명시된 경우에만 공개 키, 짧은 식별자, 지문과 서버 이름을 REALITY 요구 사항에 맞춰 확인해야 합니다.

WebSocket, gRPC, TCP 등은 전송 계층의 선택이고 TLS 또는 REALITY는 연결 보안과 핸드셰이크 방식에 관여합니다. 프로토콜이 같아도 전송 매개변수가 다르면 한 노드는 작동하고 다른 노드는 실패할 수 있습니다. 예를 들어 서버가 WebSocket으로 설정되어 있는데 클라이언트가 TCP를 잘못 선택하면 주소와 포트가 모두 정확해도 예상한 연결을 수립할 수 없습니다.

설정 호환성과 마이그레이션: 재사용할 수 있는 항목

V2Fly와 Xray는 설정 개념을 많이 공유하므로 단순한 인바운드, 아웃바운드, DNS와 라우팅 규칙은 자주 마이그레이션할 수 있습니다. 다만 마이그레이션 전에 설정을 ‘공통 구조’와 ‘커널 확장’으로 나누어야 합니다. 공통 구조에는 태그, 포트, 도메인 일치, 주소 범위와 기본 프로토콜 매개변수가 포함되고, 커널 확장에는 특정 보안 방식, 흐름 제어 옵션 또는 전송 필드가 포함될 수 있습니다.

1. 먼저 설정 출처를 확인합니다. 어떤 클라이언트나 서버 환경에서 설정이 생성되었는지 확인하고, 원래 사용한 커널 계열을 기록합니다.
2. 그다음 프로토콜 필드를 확인합니다. protocol, network, security와 핸드셰이크 관련 매개변수를 식별합니다.
3. 라우팅을 별도로 검토합니다. 도메인 규칙, 주소 규칙과 아웃바운드 태그가 서로 대응해야 하므로 마이그레이션할 때 노드 부분만 복사해서는 안 됩니다.
4. 로그로 검증합니다. 먼저 설정이 시작되는지 확인한 뒤 도메인 확인, 라우팅 적중과 원격 핸드셰이크를 점검합니다. 모든 실패를 노드 문제로 돌리지 않도록 주의합니다.

공유 링크 마이그레이션은 전체 JSON보다 간단해 보이지만 클라이언트마다 메모, 그룹, 구독 식별자와 추가 필드를 처리하는 방식이 다를 수 있습니다. 단일 링크를 복사하면 보통 노드 자체만 옮겨지고, 원래 클라이언트의 전역 DNS, 로컬 네트워크 우회 규칙, 시스템 프록시 설정 또는 앱별 목록은 함께 옮겨지지 않습니다. 따라서 ‘같은 링크’라고 해서 양쪽의 실행 환경이 완전히 같아지는 것은 아닙니다.

실제 선택: 노드 요구 사항을 클라이언트에 적용하기

실행 가능한 선택 절차만 필요하다면 다음 네 단계를 따르면 됩니다.

1단계: 기기 플랫폼 확인

데스크톱 환경에서는 먼저 v2rayN을 확인하고, Android에서는 v2rayNG와 v2flyNG 중에서 선택합니다. 데스크톱 프로그램 패키지를 Android에 넣거나 모바일 설치 파일을 데스크톱 커널로 사용해서는 안 됩니다.

2단계: 노드 프로토콜 확인

공유 링크가 vmess://로 시작하는지 vless://로 시작하는지 확인합니다. 구독에서 가져온 노드라면 먼저 클라이언트에서 업데이트한 뒤 구체적인 노드 매개변수를 확인합니다. 프로토콜 이름은 첫 번째 확인 항목일 뿐이며 전송 방식과 보안 방식도 이어서 점검해야 합니다.

3단계: 커널 종속 기능 식별

REALITY 등 Xray 계열 기능이 보이면 데스크톱에서는 올바르게 설정한 v2rayN을 사용하고 Android에서는 v2rayNG를 사용합니다. 설정이 V2Fly를 기반으로 하며 Xray 확장에 의존하지 않는다면 Android에서 v2flyNG를 선택해 커널 간 마이그레이션 변수를 줄일 수 있습니다.

4단계: 버전과 로그를 확인할 수 있게 유지

클라이언트 버전과 커널 버전은 별개의 정보입니다. 클라이언트 화면이 정상적으로 열리더라도 커널 버전이 최신 노드 매개변수를 처리할 수 있다는 뜻은 아닙니다. 연결에 실패하면 먼저 로그를 열어 설정 해석 오류, DNS 오류, 연결 시간 초과, 핸드셰이크 실패와 라우팅 오설정을 구분한 뒤 커널 업데이트, 규칙 조정 또는 노드 교체 여부를 결정합니다.

데스크톱과 Android 기기를 함께 관리하는 사용자라면 클라이언트 이름만 기록하기보다 구독 출처, 노드 프로토콜과 커널 요구 사항을 통일해 기록하는 편이 좋습니다. 그러면 기기를 바꿀 때 특정 노드를 v2rayNG와 v2flyNG 중 어디에 넣어야 하는지 빠르게 판단할 수 있고, Xray 전용 설정을 일반적인 V2Ray 설정으로 잘못 이해하는 일도 줄일 수 있습니다.

자주 묻는 질문