Project V, V2Fly, Xray의 관계: 오픈소스 생태계와 클라이언트 코어 정리

이 글의 핵심 내용

Project V는 생태계를 가리키는 개념이고, V2Fly와 Xray는 이후 갈라진 두 가지 코어 유지보수 계열입니다. v2rayN·v2rayNG·v2flyNG는 구독을 가져오고 노드를 선택하며 시스템 프록시를 제어하는 클라이언트입니다. 글을 읽고 나면 어떤 코어가 설정을 실행하는지 판단하고, 클라이언트를 바꾸기 전에 프로토콜·전송 계층·라우팅·로컬 포트의 호환성을 확인할 수 있습니다.

먼저 세 계층으로 나누기: 생태계, 코어, 클라이언트

이 이름들을 이해하는 핵심은 누가 누구를 ‘대체했는지’를 외우는 것이 아니라 소프트웨어 스택을 세 계층으로 나누어 보는 데 있습니다. Project V는 프록시 프로토콜, 코어 구현, 설정 형식과 클라이언트 도구를 아우르는 생태계 이름으로 이해하는 것이 가장 적절합니다. V2Fly와 Xray는 주로 지속적으로 유지보수되는 코어 계열을 뜻하며, v2rayN·v2rayNG·v2flyNG는 사용자가 직접 조작하는 클라이언트 계층에 해당합니다.

코어는 로컬 인바운드 수신, 원격 아웃바운드 연결, DNS 조회 정책 실행, 라우팅 규칙 매칭, VMess 또는 VLESS 트래픽 캡슐화, TCP·WebSocket·gRPC 등의 전송 설정 처리를 담당합니다. 클라이언트는 보통 이러한 프로토콜을 직접 다시 구현하지 않고, 구독 내용을 코어가 읽을 수 있는 설정으로 변환한 뒤 코어 프로세스의 시작·중지·전환을 관리합니다.

Project V: 역사와 생태계 차원에서 사용하는 포괄적인 명칭으로, 프로토콜 설계·핵심 프로그램·설정 체계·주변 도구를 아우릅니다. 이 이름을 특정 설치 파일로 곧바로 이해해서는 안 됩니다.

V2Fly: V2Ray 기술 계열을 이어 가는 커뮤니티 유지보수 체계로, 핵심 프로그램은 보통 v2fly-core 또는 v2ray-core라고 부릅니다. VMess·VLESS·라우팅·DNS와 다양한 전송 조합을 계속 지원합니다.

Xray: 기존 코드 기반에서 발전한 또 다른 코어 계열입니다. 설정 구조는 V2Ray 체계와 공통점이 많지만, 자체적인 프로토콜 및 전송 기능도 확장해 왔습니다.

클라이언트: 그래픽 인터페이스, 구독 업데이트, QR 코드 가져오기, 노드 목록, 시스템 프록시와 로그 확인 기능을 제공합니다. 클라이언트 이름과 현재 실행 중인 코어 이름이 반드시 같은 것은 아닙니다.

판단 방법: 먼저 ‘설정을 실행하는 주체는 누구인가?’를 확인하기

화면에 표시되는 이름은 어떤 클라이언트를 조작 중인지 알려 줄 뿐입니다. VMess·VLESS와 라우팅 규칙을 실제로 어느 코어 계열이 실행하는지는 로그의 코어 버전, 프로세스 이름과 Core 유형으로 확인해야 합니다.

시간순으로 보기: 하나의 생태계에 두 코어 계열이 생긴 이유

Project V 초기에는 V2Ray 핵심 프로그램을 중심으로 비교적 안정적인 JSON 설정 구조가 형성되었습니다. 대표적인 설정에는 inbounds, outbounds, routing, dns, log 등이 포함됩니다. 주변 클라이언트는 이 필드를 생성하고 핵심 프로그램을 호출하는 방식으로 그래픽 환경을 제공할 수 있었습니다.

유지보수 조직, 개발 방향과 기능 우선순위가 달라지면서 기존 생태계에는 서로 다른 유지보수 계열이 생겼습니다. V2Fly는 V2Ray의 커뮤니티 유지보수를 이어 갔고, Xray는 유사한 설정을 기반으로 독립적인 발전을 이루었습니다. 공통된 역사가 있어 기본 개념은 많이 겹치지만, 모든 필드·프로토콜 확장·전송 매개변수를 서로 바로 바꿔 쓸 수 있다고 가정해서는 안 됩니다.

초기 단계: V2Ray 코어, VMess 프로토콜과 JSON 설정 체계가 생태계의 기반이 되었고, 클라이언트는 핵심 프로그램을 중심으로 인터페이스를 제공했습니다.
커뮤니티 계승: V2Fly는 v2ray-core를 계속 유지보수하며 모듈화된 구조와 v5 설정 관련 기능을 단계적으로 추진했습니다.
독립적 발전: Xray-core는 많은 기본 개념을 이어받는 동시에 VLESS, 전송 보안과 흐름 제어 등의 구현을 확장했습니다.
클라이언트 분화: 데스크톱 및 Android 클라이언트는 대상 코어에 따라 서로 다른 구성 요소를 포함하게 되었고, 구독 필드에도 계열별 차이가 나타나기 시작했습니다.

이 관계는 단순한 구버전과 신버전의 관계라기보다 ‘공통 기반 위에서 병렬로 유지보수되는 관계’에 가깝습니다. V2Fly의 4.x 설정 관행과 v5 방향, Xray-core 1.x의 확장 흐름은 각각 별도로 존재합니다. 버전 번호도 서로 직접 비교할 수 없습니다. 예를 들어 Xray-core 1.8.x가 v2fly-core 5.x보다 오래되었다는 뜻은 아니며, 두 버전 체계의 숫자를 환산할 수 없습니다.

V2Fly와 Xray의 공통점과 핵심 차이

두 코어 계열 모두 일반적인 프록시 경로를 처리할 수 있습니다. 로컬 애플리케이션이 SOCKS 또는 HTTP 인바운드 포트에 연결하면 코어가 라우팅 규칙에 따라 프록시 또는 직접 연결 아웃바운드를 선택하고, 노드 설정에 따라 원격 연결을 구성합니다. VMess·VLESS·TCP·WebSocket·gRPC·TLS·DNS 분기와 도메인 규칙은 두 계열을 이해할 때 자주 접하는 공통 용어입니다.

공통 용어가 설정까지 완전히 같다는 뜻은 아닙니다. 노드가 실행되는지는 프로토콜, 전송 방식, 보안 계층, 흐름 제어 필드와 클라이언트 변환 로직을 함께 확인해야 합니다. 일반적인 VMess over WebSocket + TLS 설정은 대체로 호환 범위가 넓지만, Xray 전용 확장이 포함된 VLESS 노드는 해당 필드를 명확히 지원하는 Xray-core에서 처리해야 합니다.

Xray 코어

V2Fly 코어

V2Ray 커뮤니티 계열을 이어 가며, 표준 VMess·VLESS와 일반적인 라우팅 설정에 적합합니다. v2flyNG를 사용하면 클라이언트와 코어의 계열이 명확해 V2Fly 지원 범위에 맞는 설정인지 확인하기 쉽습니다.

적합한 경우: 표준 V2Ray 설정, V2Fly 계열, 이미 호환되는 구독

노드 이름만 보기

‘고속’, ‘전용 회선’, ‘V2Ray 노드’는 기술 필드가 아니므로 어떤 코어가 필요한지 판단할 수 없습니다. 실제로 확인해야 할 정보는 프로토콜, 전송 방식, 보안 계층, 포트와 확장 매개변수입니다.

적합한 경우: 선택 기준으로 삼지 말고 설정 세부 정보에서 필드를 확인해야 함

성능 역시 코어 이름만으로 결론 내리면 안 됩니다. 같은 컴퓨터·노드·라우팅 규칙에서 예시 테스트를 진행했을 때 TCP 실제 연결 지연 시간이 86ms, 91ms, 88ms로 나왔다면 세 번의 변동 폭만 5ms입니다. 저녁 시간대 회선 혼잡으로 인한 변화가 유사한 설정에서 두 코어 사이의 차이보다 훨씬 클 때가 많습니다. 비교할 때는 최소한 노드, 테스트 시간, DNS 방식과 시스템 프록시 모드를 고정해야 합니다.

결론: 버전 숫자보다 호환성이 우선

구독에 Xray 확장 필드가 포함되어 있으면 Xray-core를 우선 사용하고, 설정이 V2Fly 기준으로 생성되었다면 v2fly-core를 사용하세요. 버전 숫자가 더 크다는 이유만으로 다른 계열의 코어로 바꾸지 마세요.

v2rayN·v2rayNG·v2flyNG는 각각 어떤 코어를 사용하는가

v2rayN은 데스크톱 클라이언트로, 구독 그룹 관리·노드 테스트·라우팅 모드·시스템 프록시·코어 관리 등을 담당합니다. 일반적으로 Xray-core를 주력으로 사용하지만, 실제 결과는 클라이언트 버전·다운로드한 코어 구성 요소·사용자 선택에 따라 달라질 수 있습니다. 따라서 ‘v2rayN을 사용한다’는 사실만으로 특정 코어가 실행 중이라고 단정할 수 없으며, 설정과 로그에서 확인해야 합니다.

v2rayNG는 Android 클라이언트로 Xray 코어 계열을 사용하며, Xray가 지원하는 VMess·VLESS 등의 설정을 가져오는 데 적합합니다. v2flyNG 역시 Android에서 실행되지만 V2Fly 코어 계열을 사용합니다. 두 클라이언트의 화면과 기본 조작은 비슷할 수 있어도 코어 계열은 다르므로, 노드를 옮길 때 서버 주소와 포트만 비교해서는 안 됩니다.

클라이언트	플랫폼	주요 코어 계열	확인 위치
v2rayN	Windows、Linux	일반적으로 Xray-core가 기본이며, 클라이언트 버전과 Core 유형 설정에 따라 달라질 수 있음	「설정」→「매개변수 설정」→「Core 유형」에서 확인하고 시작 로그를 확인
v2rayNG	Android	Xray-core	사이드 메뉴에서 설정과 로그로 이동해 코어 시작 정보를 확인
v2flyNG	Android	v2fly-core	설정 페이지에서 버전을 확인한 뒤 실행 로그에서 코어 정보를 대조

v2rayN에서 실제 코어 확인하기

매개변수 설정 열기

v2rayN을 실행한 뒤 「설정」→「매개변수 설정」으로 이동합니다. 창 제목만 봐서는 안 됩니다. 클라이언트 이름이 현재 코어 프로세스를 의미하지 않기 때문입니다.
Core 유형 확인

계속해서 「Core 유형」으로 이동해 VMess·VLESS 등 프로토콜에 연결된 코어 옵션을 확인합니다. 7.x의 세부 버전에 따라 배열이 달라질 수 있지만, 판단 기준은 여전히 프로토콜과 코어의 매핑입니다.
코어 재시작

저장한 뒤 「서비스 재시작」을 실행하거나 노드에 다시 연결해 새 선택을 적용합니다. 드롭다운 옵션만 바꾸고 재시작하지 않으면 이전 코어 프로세스가 계속 실행 중일 수 있습니다.
시작 로그 읽기

로그 창을 열고 코어 이름, 버전과 설정 로드 결과를 찾습니다. 예시 기록에는 ‘Xray 25.3.6’처럼 전체 버전이 포함되어야 하며, 클라이언트 버전만 기록해서는 안 됩니다.
로컬 포트 확인

SOCKS 포트와 HTTP 포트를 다른 프로그램이 사용하고 있지 않은지 확인합니다. 일반적인 설정은 10808과 10809를 사용하지만, 실제 값은 「매개변수 설정」에 표시된 값을 기준으로 해야 합니다.

구독·설정 가져오기·라우팅 분기가 코어의 영향을 받는 이유

구독은 코어 자체가 아니라 일반적으로 여러 노드 정보를 배포하는 방식입니다. 클라이언트는 구독을 가져온 뒤 URI 또는 구조화된 내용을 파싱하고 코어 설정을 생성해야 합니다. 같은 구독이라도 클라이언트에 따라 표시되는 노드 수가 다를 수 있습니다. 특정 클라이언트가 프로토콜 필드를 아직 인식하지 못했거나 구독 그룹의 필터 규칙이 일부 노드를 숨기는 경우가 많습니다.

노드 ‘가져오기 성공’이 곧 ‘코어 시작 가능’을 의미하지는 않습니다. VLESS를 예로 들면 주소·포트·사용자 식별자·전송 방식은 기본 필드일 뿐입니다. 설정에 보안 계층·흐름 제어·서버 이름·핑거프린트·전송 경로가 포함되어 있다면 필수 매개변수 하나만 빠져도 핸드셰이크가 실패할 수 있습니다. VMess 설정에서는 사용자 식별자·전송 방식·TLS 상태와 서버 시간 오차를 확인해야 합니다.

구독 계층: 노드 배포를 담당하며, 업데이트 주기는 6시간·12시간·24시간 등일 수 있습니다. 구체적인 주기는 서버 정책에 따라 결정됩니다.
클라이언트 계층: 구독을 파싱하고 그룹을 저장하며 노드를 선택한 뒤 코어 설정 파일을 생성합니다.
코어 계층: 필드를 검증하고 로컬 포트를 수신하며 DNS와 라우팅 규칙을 실행하고 원격 연결을 구성합니다.
시스템 계층: 애플리케이션은 시스템 프록시·SOCKS 프록시 또는 투명 전달을 통해 트래픽을 로컬 인바운드로 넘깁니다.

라우팅 분기 역시 노드 이름이 아니라 코어가 실행합니다. 클라이언트의 ‘로컬 네트워크 우회’, ‘중국 본토 주소 직접 연결’, ‘전역 프록시’ 같은 옵션은 최종적으로 도메인·IP·포트 또는 프로토콜 매칭 규칙으로 변환됩니다. Xray 계열에서 V2Fly 계열로 전환한다면 규칙 세트 형식과 확장 필드를 확인해야 하며, 클라이언트 데이터베이스만 복사하고 동작이 완전히 같을 것이라고 가정해서는 안 됩니다.

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

위 조각은 계층 관계만 보여 줍니다. 로컬 SOCKS 인바운드는 127.0.0.1:10808에서 수신하고 사설 주소는 직접 연결 아웃바운드로 보냅니다. 실제 설정에는 완전한 아웃바운드·DNS·로그 항목도 필요합니다. 수신 주소를 0.0.0.0으로 바꾸면 같은 네트워크의 기기가 연결할 수 있으므로, 클라이언트의 LAN 연결 허용 옵션·운영체제 방화벽·접근 제어를 함께 확인해야 합니다.

자주 하는 오해와 마이그레이션 점검

가장 흔한 오해는 관련 소프트웨어를 모두 ‘V2Ray’라고 부르는 것입니다. 일상적인 대화에서는 이해하기 쉽지만 문제를 해결할 때는 정보가 부족합니다. 정확한 설명에는 클라이언트·코어·프로토콜·전송 방식·오류 단계가 포함되어야 합니다. 예를 들어 ‘v2rayNG에서 VLESS 노드를 가져오는 데 성공했지만 Xray-core 시작 후 전송 필드가 잘못되었다는 메시지가 표시됨’처럼 말해야 합니다.

두 번째 오해는 같은 구독이 세 클라이언트에서 반드시 완전히 동일하게 표시되어야 한다는 생각입니다. 실제로 구독 파서·필드 매핑·기본 라우팅은 각각 클라이언트 구현에 속하며, 코어는 클라이언트가 최종 생성한 설정만 처리합니다. 노드가 누락되면 먼저 구독을 업데이트하고 그룹 필터를 해제한 뒤 현재 클라이언트 버전이 해당 프로토콜을 인식하는지 확인해야 합니다.

v2rayN은 반드시 V2Fly 코어를 실행하나요?

반드시 그렇지는 않습니다. 「설정」→「매개변수 설정」→「Core 유형」에서 프로토콜에 대응하는 항목을 확인한 다음 서비스를 재시작하고 로그의 코어 이름과 전체 버전을 확인하세요.

v2rayNG와 v2flyNG의 설정을 서로 바로 덮어쓸 수 있나요?

먼저 프로토콜·전송 방식·보안 계층·흐름 제어·라우팅 규칙을 항목별로 확인하세요. 표준 VMess 설정은 대체로 옮기기 쉽지만, 특정 확장 필드가 포함된 VLESS 설정은 대상 코어에 맞게 다시 가져와 테스트해야 합니다.

구독에 노드가 있는데 왜 시작하자마자 중지되나요?

코어 로그를 열고 먼저 설정 파싱 오류를 찾은 다음 10808·10809 같은 로컬 포트가 사용 중인지 확인하세요. 로그에 알 수 없는 필드가 표시되면 해당 설정과 호환되는 코어 계열로 바꿔야 합니다.

코어를 바꾼 뒤 지연 시간이 갑자기 높아지면 어떻게 하나요?

같은 노드에서 실제 연결 지연 시간을 세 번 연속 측정하고 DNS·라우팅 모드·시스템 프록시가 동시에 바뀌지 않았는지 확인하세요. 결과가 82ms, 137ms, 89ms라면 단 한 번의 137ms만으로 코어 성능을 판단하지 말고 네트워크 변동을 계속 점검해야 합니다.

VMess 노드는 특정 계열을 고정해서 선택해야 하나요?

표준 VMess 설정은 두 계열에서 대체로 호환성이 좋지만 전송 방식과 TLS 매개변수는 확인해야 합니다. 기존 설정이 안정적으로 실행 중이라면 버전 숫자가 더 크다는 이유만으로 코어를 바꿀 필요는 없습니다.

마이그레이션 시 남겨야 할 점검 기록

클라이언트 이름과 버전을 기록하세요. 예: v2rayN 7.11.3. ‘데스크톱 버전’이라고만 적지 마세요.
로그에 표시된 코어 이름과 버전을 기록하세요. 예: Xray-core 25.3.6 또는 해당 v2fly-core 버전.
노드 프로토콜·원격 포트·전송 방식·보안 계층과 서버 이름을 기록하세요.
로컬 SOCKS·HTTP 포트와 시스템 프록시 모드를 기록하세요.
구독 업데이트·코어 시작·TCP 실제 연결 지연 시간·웹페이지 접속을 각각 확인해 서로 다른 단계의 문제를 섞지 않도록 하세요.

정리하면 Project V는 역사와 생태계를 이해하는 출발점이고, V2Fly와 Xray는 공통 기반을 가지면서 독립적으로 유지보수되는 두 코어 계열입니다. v2rayN·v2rayNG·v2flyNG는 각 플랫폼에 맞춘 클라이언트입니다. 어떤 이름이 더 ‘정통’인지 논쟁하기보다 클라이언트가 구독을 완전히 파싱하는지, 코어가 노드 필드를 지원하는지, 라우팅 규칙이 예상대로 실행되는지만 확인하면 됩니다.