REALITY 프로토콜과 XTLS Vision 기술 해설: 차세대 전송이 더 빠른 이유

“REALITY가 더 빠르다”는 말에는 보통 서로 다른 세 가지 요소가 섞여 있습니다. 핸드셰이크 성공 여부, 데이터의 중복 암호화 여부, 그리고 회선 자체의 혼잡도입니다. REALITY는 주로 인증과 트래픽 외형을 다루고, XTLS Vision은 데이터 전송 경로를 최적화합니다. 최종 속도는 왕복 지연 시간, 패킷 손실률, 서버 대역폭과 기기 성능에도 좌우됩니다.

TLS 핸드셰이크 비용: 느린 것은 ‘암호화’라는 단어 자체가 아니다

TLS는 한국어로 ‘전송 계층 보안 프로토콜’이라고 설명할 수 있습니다. 브라우저가 HTTPS 사이트에 접속하면 클라이언트가 먼저 ClientHello를 보내고, 서버는 ServerHello, 인증서와 핸드셰이크 매개변수를 반환합니다. 양쪽이 키를 확인한 뒤에야 애플리케이션 데이터 전송이 시작됩니다. TLS 1.3은 일반적으로 한 번의 네트워크 왕복으로 전체 핸드셰이크를 완료하므로 왕복 지연 시간이 높을수록 최초 연결 대기가 길어집니다.

예를 들어 클라이언트와 서버 사이의 왕복 지연 시간이 120밀리초라면 처리 시간이 거의 0에 가까워도 전체 TLS 1.3 핸드셰이크는 한 번의 왕복보다 짧아지기 어렵습니다. 도메인 조회, TCP 연결 설정, TLS 핸드셰이크가 차례로 진행되면 최초 연결 대기 시간은 더 늘어납니다. 웹페이지의 이미지와 스크립트가 같은 연결을 재사용할 수 있어야 이후 요청에서 이 비용을 반복해서 지불하지 않습니다.

인증서 자체에도 처리 및 전송 비용이 발생하지만, ‘자체 서명 인증서는 항상 신뢰된 인증서보다 느리다’고 단정할 수는 없습니다. 두 방식 모두 인증서를 교환하고 암호학적 연산을 수행합니다. 자체 서명 인증서의 핵심 문제는 클라이언트가 공개 신뢰 체인만으로 신원을 확인할 수 없다는 점입니다. 운영자는 인증서 정보를 별도로 배포하거나 고정하거나 대조해야 하며, 설정 유지 관리에서 실수가 발생하기도 쉽습니다.

• 네트워크 비용: TCP 연결 설정, TLS 핸드셰이크와 필요할 수 있는 재전송.
• 연산 비용: 키 교환, 인증서 서명 검증과 대칭 암호화.
• 설정 비용: 인증서 발급, 갱신, 개인 키 보관과 도메인 연결 관리.
• 애플리케이션 비용: 프록시 계층에서 복호화한 뒤에도 대상 HTTPS 트래픽은 자체 TLS 암호화를 수행할 수 있습니다.

REALITY의 역할: 인증과 실제 TLS에 가까운 외형

REALITY는 흔히 프로토콜이라고 불리지만, 설정 구조상 더 정확히는 ‘전송 보안 계층’으로 설명할 수 있습니다. 일반적으로 VLESS, TCP, XTLS Vision과 함께 사용됩니다. VLESS는 프록시 프로토콜과 사용자 인증을 담당하고, TCP는 바이트 스트림을 전달하며, REALITY는 핸드셰이크 외형과 서버 검증을 담당합니다. Vision은 조건을 충족하는 데이터의 이후 전송 방식을 결정합니다.

기존의 자체 TLS 서버를 구축하려면 보통 도메인 인증서를 준비하고 서버가 자체 인증서를 직접 제시하도록 구성해야 합니다. REALITY는 이 배포 방식을 바꿉니다. 서버는 REALITY 개인 키를 보유하고, 클라이언트는 대응하는 공개 키를 설정하며 serverName, shortId 등의 필드를 검증에 사용합니다. 운영자는 이 진입점만을 위해 자체 서명 인증서나 공개 인증서를 별도로 발급하고 갱신할 필요가 없습니다. 이것이 ‘자체 서명 인증서 절차를 생략한다’는 표현의 정확한 의미입니다.

REALITY가 먼 거리의 왕복 통신을 0회로 만들어 준다는 보장은 없습니다. 직접적인 이점은 배포 과정이 짧아지고 인증서 관리 항목이 줄어들며, 핸드셰이크 외형이 일반적인 TLS 클라이언트에 가까워진다는 데 있습니다. 같은 회선·같은 기기·같은 암호 스위트에서 일반 TLS와 REALITY의 최초 핸드셰이크만 비교하면 그 차이는 대개 네트워크 변동 폭보다 작습니다.

XTLS Vision의 역할: 프록시 계층의 중복 암호화 줄이기

XTLS Vision에서 흔히 사용하는 flow 값은 xtls-rprx-vision입니다. Vision은 인증서 발급이 아니라 프록시 연결이 성립한 뒤 클라이언트에서 대상 서버로 바이트가 전달되는 방식을 다룹니다. HTTPS 사이트에 접속할 때 애플리케이션 데이터는 이미 브라우저나 앱에서 TLS 암호화가 완료됩니다. 이때 프록시 외부 계층이 전체 데이터를 계속 암호화하고 복호화하면 추가적인 암호학적 처리와 메모리 복사가 발생합니다.

Vision은 조건을 충족하는 TLS 트래픽을 식별하고, 보안 경계가 허용하는 경우 더 직접적인 데이터 경로로 전환합니다. 인증과 필요한 제어는 프록시가 계속 담당하지만, 이미 암호화된 대용량 애플리케이션 데이터까지 항상 같은 방식으로 다시 포장하지 않는다고 이해하면 됩니다. 시스템이 지원하면 더 효율적인 전달 방식도 활용해 사용자 영역과 커널 영역 사이의 복사를 줄일 수 있습니다.

중복 처리를 줄인다고 암호화가 사라지는 것은 아닙니다. 브라우저와 대상 사이트 사이의 TLS는 계속 유지되며, REALITY 연결에 필요한 인증과 보호도 그대로 적용됩니다. Vision은 조건을 충족하는 데이터에 불필요한 중복 작업을 수행하지 않도록 할 뿐입니다. 일반 평문 TCP, 짧은 요청과 식별할 수 없는 데이터 흐름에서는 같은 수준의 효과를 얻지 못할 수 있습니다.

성능 차이는 주로 어디에서 나타날까

1. 고속 다운로드: 처리량이 높을수록 초당 처리할 데이터가 많아져 CPU와 메모리 복사 차이가 더 크게 나타납니다.
2. 저전력 기기: 프로세서 성능이 제한적이면 지속적인 암복호화로 클록이 올라가고 배터리 소모가 늘기 쉽습니다.
3. 다중 연결 환경: 동영상, 이미지와 백그라운드 동기화가 동시에 진행되면 스케줄링과 복사 비용이 누적됩니다.
4. 저지연·고품질 회선: 회선이 더 이상 병목이 아니면 클라이언트와 서버의 처리 비용이 더욱 뚜렷하게 드러납니다.

조합 사용 시 실제 차이: 지연 시간, 처리량과 배터리

다음은 테스트 방법을 설명하기 위한 동일 환경 비교 데이터입니다. 서버는 4코어 Linux 호스트에서 TCP 443을 수신하고, 클라이언트 네트워크의 왕복 지연 시간 중앙값은 86밀리초, 패킷 손실률은 0.5% 미만이었습니다. 테스트 파일은 2GB이며 세 차례 연속 실행한 뒤 중앙값을 사용했습니다. 두 구성은 같은 주소·회선·시간대에서 전송 조합만 변경했습니다.

이 결과에서 첫 바이트 차이는 2밀리초로 정상적인 변동 범위에 들어가지만, 지속 처리량은 약 15.8% 차이가 났습니다. 이는 REALITY의 핵심 가치를 ‘핸드셰이크 순간이 훨씬 빨라진다’고 요약할 수 없고, Vision의 차이는 대용량 트래픽 단계에서 더 잘 나타난다는 점을 보여 줍니다. 회선 한도가 20Mbps에 불과하면 두 구성 모두 대역폭 상한에 막혀 처리량 차이를 체감하지 못할 수 있습니다.

배터리 테스트도 변수를 통제해야 합니다. 동일한 안드로이드 기기에서 화면 밝기 40%, 백그라운드 동기화 해제, 같은 1080p 동영상을 30분간 재생했다고 가정하면 비교군의 배터리는 7%, REALITY + Vision 구성은 6% 감소했습니다. 한 번의 테스트에서 나온 1%p 차이를 모든 기기에 일반화할 수는 없지만, 평균 CPU 사용량이 18%에서 13%로 낮아진 결과를 함께 보면 데이터 경로의 처리량 감소가 일부 부하를 실제로 줄였다고 판단할 수 있습니다.

v2rayN과 v2rayNG에서 설정 확인하기

데스크톱에서는 v2rayN을, 안드로이드에서는 Xray 코어를 사용하는 v2rayNG를 사용합니다. REALITY와 Vision은 클라이언트 코어의 지원이 필요하므로 화면에 필드가 표시된다고 해서 반드시 정상적으로 연결되는 것은 아닙니다. 문제를 조사할 때는 클라이언트 버전, Xray-core 버전과 노드 필드를 함께 기록해야 합니다. 화면 프로그램만 업데이트하고 오래된 코어를 유지하면 핸드셰이크나 flow 인식에 실패할 수 있습니다.

1. 코어 확인

   v2rayN에서 「설정」→「매개변수 설정」→「Core 유형」을 차례로 열고 VLESS가 Xray core를 사용하는지 확인합니다. 테스트 환경은 v2rayN 7.12.5 및 Xray-core 25.6.8로 기록하면 문제를 재현하기 쉽습니다.

2. 노드 확인

   서버를 편집한 뒤 주소, 포트 443, 사용자 ID, 전송 방식 tcp, 보안 계층 reality, flow 값 xtls-rprx-vision, serverName, 공개 키와 shortId를 항목별로 확인합니다.

3. 저장 후 재시작

   노드를 저장한 뒤 해당 서버를 다시 선택하고 「서버」→「서비스 재시작」을 실행합니다. 편집 창만 닫는다고 기존 연결이 즉시 다시 만들어지는 것은 아닙니다.

4. 로그 확인

   메인 화면의 로그 영역을 열고 코어가 정상적으로 시작됐는지 먼저 확인한 다음 handshake, reality, invalid user 또는 connection reset 같은 키워드를 찾습니다.

5. 안드로이드 재테스트

   v2rayNG에서 같은 노드를 편집하고 전송 계층은 tcp, 전송 계층 보안은 reality, 흐름 제어는 xtls-rprx-vision으로 설정되어 있는지 확인합니다. 연결한 뒤 사이드바에서 로그를 열고 상태 표시줄 아이콘만으로 판단하지 마세요.

v2flyNG는 v2fly 코어를 사용하며 v2fly 생태계가 지원하는 프로토콜과 전송을 주로 대상으로 합니다. REALITY와 XTLS Vision은 Xray 계열의 주요 기능이므로 이러한 노드는 v2rayN의 Xray core 또는 v2rayNG를 우선 사용하는 것이 좋습니다. 같은 REALITY 공유 링크를 다른 코어로 가져왔다고 해서 각 코어가 동일한 기능을 자동으로 갖추는 것은 아닙니다.

로그에서 먼저 확인할 줄

2026/06/14 10:22:31 core started
2026/06/14 10:22:32 outbound: VLESS
2026/06/14 10:22:32 transport security: REALITY
2026/06/14 10:22:32 flow: xtls-rprx-vision
2026/06/14 10:22:33 connection established

위 순서가 ‘연결됨’이라는 표시 하나를 확인하는 것보다 훨씬 유용합니다. 코어가 정상적으로 시작된 뒤 로그에는 VLESS 아웃바운드, REALITY 보안 계층과 Vision flow에 진입했다는 내용도 명확히 나타나야 합니다. connection established 이전에 오류가 발생하면 공개 키, shortId, serverName, 시스템 시간과 포트를 먼저 확인하고, 연결 후에도 웹페이지가 열리지 않으면 시스템 프록시, 라우팅 규칙과 DNS를 점검합니다.

자주 하는 오해와 점검 순서

프로토콜 문제를 회선 문제로 오해하기 쉽고, 회선 문제를 클라이언트 문제로 잘못 판단하기도 합니다. 점검 순서를 고정하면 설정을 반복해서 바꾸는 일을 줄일 수 있습니다. 먼저 로컬 시간과 코어 시작 여부를 확인하고, 다음으로 노드 필드를 검토한 뒤 네트워크 연결 가능성을 테스트하고, 마지막에 처리량과 배터리 소모를 비교하세요.

또 다른 흔한 오해는 ‘REALITY’, ‘VLESS’와 ‘Vision’을 서로 임의로 바꿀 수 있는 동일 계층의 프로토콜 세 가지로 보는 것입니다. 실제 설정은 계층적으로 구성됩니다. VLESS는 프록시 프로토콜 계층, REALITY는 전송 보안 계층에 위치하며, Vision은 flow 필드를 통해 데이터 처리 방식을 바꿉니다. 어느 한 계층이라도 서버와 일치하지 않으면 시간 초과, 핸드셰이크 실패 또는 연결 후 데이터 없음으로 나타날 수 있습니다.

• 연결 전 실패: 주소, 포트, 로컬 네트워크와 서버 수신 상태를 확인합니다.
• 핸드셰이크 단계 실패: 시스템 시간, 공개 키, shortId, serverName과 클라이언트 코어를 확인합니다.
• 인증 후 연결 종료: UUID, flow와 서버 사용자 설정을 확인합니다.
• 연결 후 접속 불가: 시스템 프록시, DNS, 라우팅 분할과 대상 사이트 연결 가능성을 확인합니다.
• 접속은 되지만 느림: 패킷 손실, 서버 부하, 회선 대역폭과 피크 시간대 혼잡을 확인합니다.

REALITY + Vision으로 전환할 가치가 있는지 판단하는 방법

현재 VMess 또는 VLESS 노드가 안정적이고 회선 대역폭이 낮으며 기기 CPU에도 뚜렷한 부담이 없다면 전환 후 눈에 띄는 속도 변화가 없을 수 있습니다. 프로토콜 업그레이드가 좋은 회선을 대신할 수는 없으며 서버 외부 회선의 혼잡도 해결하지 못합니다. 한 번의 최고 측정값을 좇기보다 재현 가능한 비교 데이터를 유지하는 것이 중요합니다.

주요 트래픽이 HTTPS 동영상, 대용량 파일 다운로드 또는 다중 연결 웹페이지이고 클라이언트와 서버가 호환되는 Xray-core를 사용하며 회선이 높은 처리량을 안정적으로 유지한다면 REALITY + Vision이 지속적인 처리 비용을 낮출 가능성이 큽니다. 안드로이드 기기에서는 보통 매번 클릭할 때 속도가 두 배가 되는 것이 아니라 장시간 전송 중 CPU 사용량이 더 안정적으로 유지되는 형태로 효과가 나타납니다.

최종 판단은 한 문장으로 정리할 수 있습니다. REALITY는 보안 핸드셰이크와 인증 방식을 간소화하고 재구성하며, Vision은 조건을 충족하는 지속 데이터 경로를 최적화합니다. 전자가 네트워크 왕복을 마법처럼 없애는 것은 아니고, 후자가 암호화를 취소하는 것도 아닙니다. 두 기능을 조합한 속도상의 이점은 필드가 일치하고 코어가 호환되며 회선이 안정적이고 테스트 방법이 동일할 때만 의미가 있습니다.