결론부터: 노드 프로토콜에 맞춰 코어 선택

Xray와 V2Fly는 단순히 “신버전”과 “구버전”으로 나뉘지 않습니다. 비슷한 설정 구조를 사용하고 VMess, VLESS, SOCKS, HTTP, 로컬 라우팅, DNS 같은 기본 개념도 공유하지만 유지보수 방향은 이미 달라졌습니다. 선택할 때는 코어 이름만 보거나 지연 시간 숫자만으로 판단하지 마세요. 먼저 노드의 프로토콜, 전송 계층, 보안 계층, flow 값을 확인한 뒤 클라이언트가 실제로 호출하는 코어를 점검해야 합니다.

노드가 VLESS, REALITY, XTLS Vision 조합을 사용한다면 Xray를 선택해야 합니다. REALITY와 xtls-rprx-vision은 Xray 체계의 핵심 기능이므로 V2Fly로 바꾸면 기존 매개변수로 동등한 연결을 만들 수 없습니다. 설정이 VMess, 일반 VLESS, WebSocket, gRPC, TLS, 기존 라우팅 규칙 중심이라면 두 코어 모두 처리할 가능성이 있지만, 구체적인 버전과 필드 지원 여부는 반드시 확인해야 합니다.

Xray와 V2Fly 선택 빠른 확인표
확인 항목 Xray V2Fly
일반 VMess 설정 대체로 지원 대체로 지원
일반 VLESS 전송 지원되며 관련 기능 업데이트가 집중되어 있음 버전에 따라 구체적인 구현 확인 필요
REALITY 사용 가능 Xray 매개변수 그대로 사용할 수 없음
XTLS Vision 사용 가능 동등한 대체로 사용할 수 없음
기존 설정 체계 유지 대체로 호환되며 확장 필드 추가 주요 유지보수 대상 중 하나
선택 기준 노드에 Xray 전용 기능이 포함됨 기존 설정이 명확히 V2Fly를 대상으로 함

두 코어의 관계와 역할

V2Fly는 Project V의 기존 기술 노선을 이어가며, 설정은 일반적으로 인바운드, 아웃바운드, 라우팅, DNS, 정책, 전송 설정을 중심으로 구성됩니다. 자주 쓰이는 JSON 최상위 구조에는 inbounds, outbounds, routing, dns, log가 있습니다. 이러한 구조에 익숙해지면 Xray 설정도 완전히 낯설지는 않습니다.

Xray는 같은 기술 흐름에서 발전했기 때문에 유사한 개념을 많이 유지하면서 VLESS, XTLS, REALITY, 전송 메커니즘, 라우팅 기능을 계속 확장했습니다. 따라서 두 설정 파일에 동일한 내용이 상당 부분 포함될 수 있지만, 특정 보안 계층 필드, flow 값, 전송 매개변수 하나만으로도 서로 바꿔 쓸 수 없게 됩니다.

“설정 파일을 읽을 수 있다”는 사실이 “연결 동작이 완전히 동일하다”는 뜻은 아닙니다. 일부 알 수 없는 필드는 파싱 단계에서 무시될 수 있고, 일부 필드는 시작 오류를 일으키며, 이름이 같은 필드라도 허용 값이나 기본 동작이 코어 버전에 따라 달라질 수 있습니다. 설정을 이전할 때는 실행 로그와 연결 결과를 확인해야 하며, 클라이언트가 시작되는지만 봐서는 안 됩니다.

코어와 클라이언트 인터페이스는 서로 다른 계층

v2rayN은 데스크톱 클라이언트로, 구독 관리, 노드 선택, 시스템 프록시, 라우팅 모드, 코어 프로세스 제어를 담당합니다. 실제 연결을 처리하는 것은 클라이언트가 호출한 코어입니다. 버전이나 설치 패키지에 따라 코어 관리 방식이 다를 수 있으므로 설정 화면이나 로그 첫 부분에서 현재 코어 이름과 버전을 확인해야 합니다. 창 제목만 보고 추측하지 마세요.

Android에서는 구분이 더 명확합니다. v2rayNG는 Xray 코어 노선을 사용하고 v2flyNG는 V2Fly 코어 노선을 사용합니다. 두 앱의 조작 방식은 비슷할 수 있지만 프로토콜 확장, 가져오기 결과, 사용 가능한 매개변수는 코어의 영향을 받습니다. 노드 제공자가 REALITY 또는 Vision 매개변수를 명시했다면 해당 매개변수와 코어를 함께 고려해야 합니다.

프로토콜 지원 차이: VLESS·XTLS·REALITY 중점 확인

VMess: 공통 기반이 모든 조합의 호환성을 보장하지는 않음

VMess는 두 코어 모두에서 흔히 사용되는 프로토콜입니다. 일반적인 VMess 노드는 TCP, WebSocket, HTTP/2, gRPC 같은 전송 방식과 조합되며 외부 계층에 TLS를 사용할 수도 있습니다. “VMess”라는 이름만으로는 호환성을 판단할 수 없고, 전송 유형, TLS serverName, 경로, Host, 포트, 사용자 식별자를 함께 확인해야 합니다.

구조가 비교적 전통적인 VMess 설정이라면 Xray와 V2Fly 모두 대체로 잘 처리합니다. 그래도 실제 이전 과정에서는 오래된 필드, 전송 이름 변경, 구독 변환 결과를 확인해야 합니다. 가져온 뒤 노드는 보이지만 연결에 실패한다면 시스템 프록시를 반복해서 전환하기보다 노드 세부 정보를 열어 항목별로 비교하세요.

VLESS: 프로토콜 이름이 같아도 확장 기능은 다를 수 있음

VLESS는 인증 정보와 전송·보안 계층의 조합을 분리합니다. 노드에는 보통 주소, 포트, 사용자 식별자, 전송 방식, 암호화 및 보안 매개변수가 포함됩니다. 일반 VLESS 설정은 구현이 달라도 어느 정도 호환될 수 있지만, VLESS 관련 확장 기능의 유지보수는 Xray에 더 집중되어 있으며 특히 Vision·REALITY 조합에서 차이가 큽니다.

구독 항목에 vless://만 적혀 있다고 해서 두 코어에서 모두 바로 사용할 수 있는 것은 아닙니다. 쿼리 매개변수의 security, flow, type, sni, fp, pbk, sid도 확인하세요. 이 중 일부는 REALITY 핸드셰이크에 사용되므로 누락되면 핸드셰이크 실패, 연결 직후 종료, 설정 필드 불완전 등의 문제가 흔히 발생합니다.

XTLS Vision: 일반 TLS 스위치로 취급할 수 없음

XTLS Vision은 보통 flow=xtls-rprx-vision으로 표시됩니다. 단순히 “TLS를 XTLS로 바꾸는” 화면 옵션이 아니라 클라이언트, 서버, 프로토콜, 전송 조합이 모두 맞아야 작동합니다. 노드에 Vision이 지정되어 있다면 flow 값을 그대로 유지하고 구독 변환이나 수동 편집 중 삭제하지 마세요.

Vision은 주로 Xray 체계를 대상으로 합니다. 같은 노드를 V2Fly로 전환했을 때 주소, 포트, 사용자 식별자가 모두 같더라도 연결이 성립한다고 단정할 수 없습니다. 서버가 기대하는 핸드셰이크와 흐름 제어 동작이 맞지 않으면 클라이언트에서 시간 초과, 연결 재설정, TLS 계열 오류가 나타날 수 있습니다.

REALITY: 관련 매개변수를 묶어서 확인

REALITY는 Xray에서 널리 사용되는 보안 및 핸드셰이크 방식으로, VLESS·TCP·Vision과 함께 구성되는 경우가 많습니다. 클라이언트에서는 보통 serverName, 공개 키, shortId, 지문 매개변수, flow를 확인해야 합니다. 서버의 개인 키는 클라이언트 구독에 포함되지 않으며, 클라이언트에는 핸드셰이크에 필요한 공개 매개변수가 전달됩니다.

serverName은 서버 설정에서 허용한 이름과 일치해야 하며, 공개 키나 shortId는 문자 하나만 더 많거나 적어도 실패합니다. 지문 매개변수는 클라이언트 핸드셰이크 특성을 나타내므로 코어가 지원하는 값을 사용해야 합니다. REALITY 노드를 사용할 수 없다면 먼저 이 필드들을 대조한 다음 시스템 시간, 네트워크 출구, 서버 상태를 확인하세요.

설정 호환성: 비슷한 JSON에서 가장 쉽게 놓치는 차이

Xray와 V2Fly의 기본 설정은 모두 JSON을 사용하는 경우가 많습니다. 인바운드는 로컬 트래픽을 받고, 아웃바운드는 대상 또는 프록시 서버에 연결하며, 라우팅 규칙은 트래픽을 어느 아웃바운드로 보낼지 결정합니다. 구조가 비슷하기 때문에 전체 설정을 복사한 뒤 실행 코어만 바꾸는 사용자가 많지만, 이 방법은 양쪽이 공통으로 지원하는 필드임이 분명한 설정에만 적합합니다.

첫 번째 차이: 보안 계층과 flow

streamSettings 아래의 보안 유형을 확인하세요. 일반 TLS 설정에는 보통 serverName, ALPN 등이 포함되고 REALITY 설정에는 전용 항목이 나타납니다. VLESS 사용자 또는 노드 정보의 flow도 확인해야 합니다. Xray 전용 값을 남긴 채 V2Fly를 사용하면 설정이 시작되지 않거나 시작 후 연결을 완료하지 못할 수 있습니다.

두 번째 차이: 전송 매개변수와 버전

WebSocket의 경로와 Host, gRPC의 서비스 이름, TCP의 헤더 설정은 설정 형식, 버전 변화, 구독 변환에 따라 달라질 수 있습니다. 두 코어가 특정 전송을 모두 지원하더라도 클라이언트가 생성한 최종 JSON이 완전히 같지는 않을 수 있습니다. 문제를 확인할 때는 구독 원문만 보지 말고 클라이언트가 실제로 기록한 설정을 확인해야 합니다.

서버와 클라이언트의 버전 차이가 너무 크면 새 필드를 인식하지 못하거나, 기존 작성 방식이 변경되거나, 기본값이 달라질 수도 있습니다. 업그레이드 전에는 현재 사용 가능한 노드, 라우팅 모드, 코어 유형을 기록하세요. 업그레이드 후에는 먼저 노드 하나를 테스트한 다음 복잡한 분기 규칙을 복원하면 프로토콜 문제와 라우팅 문제를 분리할 수 있습니다.

세 번째 차이: DNS와 라우팅 분기

라우팅 규칙은 보통 도메인, IP, 포트, 네트워크 유형, 인바운드 태그에 따라 아웃바운드를 선택합니다. 두 코어 모두 관련 기능을 제공하지만 규칙 필드, 매칭 동작, 사용 가능한 확장은 버전에 따라 달라질 수 있습니다. 이전할 때는 domainStrategy, 규칙 순서, 아웃바운드 태그, DNS 조회 경로를 중점적으로 확인하세요.

규칙을 위에서 아래로 매칭하는 경우 앞쪽의 포괄적인 규칙이 트래픽을 먼저 가로채 뒤쪽의 세부 규칙이 실행되지 않을 수 있습니다. “노드는 연결되지만 일부 웹사이트가 예상한 출구를 사용하지 않는” 경우에는 먼저 단순한 전체 프록시 테스트 모드로 전환하세요. 코어와 노드가 정상임을 확인한 뒤 도메인 및 IP 분기를 하나씩 복원합니다.

네 번째 차이: 태그 참조

설정의 tag는 내부 참조 이름입니다. 라우팅 규칙이 가리키는 아웃바운드 태그가 실제로 존재해야 하며, DNS 또는 인바운드 관련 규칙도 올바른 객체를 참조해야 합니다. 설정을 복사하면서 해당 태그가 있는 아웃바운드를 빠뜨리면 코어가 대상을 찾지 못하거나 트래픽이 기본 아웃바운드로 빠질 수 있습니다. 태그 이름 자체가 프로토콜을 결정하지는 않지만 잘못된 참조는 프로토콜 비호환처럼 보일 수 있습니다.

설정 이전 시 필드 확인표
위치 확인 내용 흔한 현상
노드 프로토콜 VMess, VLESS 및 인증 정보 인증 실패 또는 연결 즉시 종료
전송 설정 TCP, WebSocket, gRPC 및 관련 매개변수 시간 초과 또는 서버에 유효한 요청 없음
보안 설정 TLS, REALITY, serverName 및 추가 매개변수 핸드셰이크 실패
flow Vision 값 포함 여부 연결 재설정 또는 실행 불가
라우팅 태그 규칙이 참조하는 아웃바운드의 존재 여부 트래픽이 잘못된 출구로 이동
DNS 조회 경로와 도메인 전략 도메인은 실패하지만 IP는 접속 가능

성능 비교: 한 번의 속도 측정으로 판단하지 않기

Xray나 V2Fly라는 이름만으로 속도를 결정할 수는 없습니다. 실제 처리량과 지연 시간은 서버 회선, 왕복 거리, 혼잡도, 기기 성능, 프로토콜 조합, 전송 계층, 암호화 처리, 분기 규칙, 테스트 대상이 함께 좌우합니다. 서로 다른 노드, 시간대, 네트워크로 측정한 결과는 직접 비교할 수 없습니다.

같은 회선과 비슷한 설정에서는 Xray의 Vision 같은 방식이 특정 조합의 추가 처리 부담을 줄이고 최신 연결 방식에 맞게 최적화될 수 있습니다. 그렇다고 모든 Xray 설정이 모든 V2Fly 설정보다 빠르다는 뜻은 아닙니다. 일반 VMess 또는 VLESS 노드의 병목이 서버 대역폭과 네트워크 경로에 있다면 코어를 바꿔도 차이가 거의 없을 수 있습니다.

올바른 비교 방법

  1. 같은 기기, 같은 로컬 네트워크, 같은 테스트 시간대를 유지하세요.
  2. 같은 서버 회선을 사용하고 포트와 전송 조건이 비교 가능한지 확인하세요.
  3. 먼저 복잡한 라우팅 규칙을 끄고 DNS와 분기로 인한 변수를 제거하세요.
  4. 각 조합을 여러 번 테스트하고 연결 설정 시간, 지연 시간, 다운로드 처리량, 장시간 연결 안정성을 따로 기록하세요.
  5. 클라이언트 로그에서 재연결, 시간 초과, 핸드셰이크 오류를 확인하고 최고 속도만 기록하지 마세요.

메모리와 CPU 사용량도 실제 사용 환경에서 관찰해야 합니다. 동시 연결이 많거나 도메인 규칙이 복잡하고 DNS 조회가 잦으면 리소스 사용량이 증가합니다. 데스크톱과 Android 기기는 백그라운드 정책이 다르므로 두 플랫폼의 수치를 직접 비교할 수 없습니다.

연결이 몇 분마다 끊긴다면 먼저 네트워크 전환, 시스템 절전 제한, 서버 유휴 시간 초과, 클라이언트 백그라운드 상태를 확인하세요. 코어만 바꾸면 증상이 일시적으로 달라질 수 있지만 실제 원인이 해결된다는 보장은 없습니다.

구독 호환성: 가져오기에 성공해도 매개변수가 완전한 것은 아님

구독은 노드 정보를 일괄 전달하지만 구독 형식마다 확장 필드를 표현하는 능력이 다릅니다. 클라이언트에 노드 이름이 표시된다는 것은 항목을 인식했다는 뜻일 뿐, REALITY 공개 키, shortId, serverName, 지문, flow가 최종 설정에 정확히 기록되었다는 의미는 아닙니다.

v2rayN에서 구독을 가져온 뒤 노드 세부 정보를 열어 프로토콜, 전송, 보안 유형, flow를 확인하세요. 구독을 업데이트하기 전에 수동으로 수정한 필드는 다음 업데이트에서 덮어써질 수 있습니다. 장기간 유지해야 하는 매개변수는 매번 다시 입력하지 말고 구독 원본에서 올바르게 제공해야 합니다.

v2rayNG에서 Xray 노선의 노드를 처리할 때는 앱 버전과 노드 매개변수가 맞는지 확인하세요. v2flyNG는 V2Fly를 명확히 대상으로 하는 설정에 더 적합합니다. 동일한 고급 VLESS 링크를 두 클라이언트에 각각 가져와 양쪽 모두 노드가 생성되더라도 하위 계층의 기능이 같다고 볼 수 없습니다.

구독 변환 과정에서 필드 이름이 바뀌거나 인식되지 않은 매개변수가 삭제되거나 전송 유형이 예전 형식으로 매핑될 수도 있습니다. 원본 공유 정보는 작동하지만 구독을 가져온 뒤 작동하지 않는다면 양쪽에서 생성된 노드 세부 정보를 비교하세요. 누락된 필드를 먼저 찾고 포트를 바꾸거나 보안 설정을 함부로 끄지 마세요.

사용 환경에 따라 Xray 또는 V2Fly 선택

상황 1: 노드가 REALITY 또는 Vision을 명시적으로 사용

Xray를 선택하세요. REALITY를 일반 TLS로 바꾸거나 표면적인 호환성을 위해 Vision flow를 삭제하지 마세요. 보안 계층과 흐름 제어는 서버 설정의 일부이므로 클라이언트가 서버 요구 사항에 맞춰 연결해야 합니다. 데스크톱에서는 v2rayN에서 실제로 호출되는 코어를 확인하고, Android에서는 v2rayNG를 사용해 가져온 필드를 점검하세요.

상황 2: 안정적으로 실행 중인 V2Fly 설정이 있음

현재 설정이 일반 VMess, VLESS, WebSocket, gRPC, TLS, DNS, 라우팅 규칙을 사용하고 서버와 클라이언트가 장기간 안정적으로 작동한다면 이름을 바꾸기 위해 이전할 필요는 없습니다. V2Fly를 계속 사용할 경우 현재 버전과 설정 구조를 기록하고 업그레이드 후 노드, DNS, 라우팅 순서로 확인하세요.

상황 3: 하나의 구독에 여러 유형의 노드가 혼합됨

먼저 노드를 기능별로 분류하세요. 일반 VMess와 일반 VLESS는 한 그룹에, REALITY와 Vision 노드는 다른 그룹에 배치합니다. 코어를 바꾼 뒤 그룹별로 테스트해 모든 실패를 구독 문제로 단정하지 마세요. 클라이언트가 노드별로 적합한 코어를 선택할 수 있다면 전환 후 설정을 다시 생성하고 로그도 확인해야 합니다.

상황 4: 복잡한 분기에 의존하는 설정

먼저 노드 프로토콜을 완전히 지원하는 코어를 선택한 다음 분기 규칙을 이전하세요. 노드 계층이 아직 연결되지 않은 상태에서는 복잡한 라우팅이 변수만 늘립니다. 먼저 로컬 프록시 인바운드 하나와 노드 아웃바운드 하나만 남겨 기본 연결을 확인한 뒤 직결 아웃바운드, 도메인 규칙, IP 규칙, DNS 정책을 추가하는 것이 좋습니다.

상황 5: 낮은 지연 시간과 안정적인 연결만 중시

서버 설정과 일치하고 클라이언트 유지보수가 정상이며 로그가 명확한 조합을 우선 선택하세요. 지연 시간 차이가 작다면 한 번의 속도 측정 최고값보다 안정성이 더 중요한 참고 기준입니다. 일정 기간 계속 사용하면서 끊김, 재연결, DNS 실패, 백그라운드 유지 상태를 관찰한 뒤 이전 여부를 결정하세요.

V2Fly에서 Xray로 전환할 때 확인 목록

  1. 현재 환경을 기록합니다. 클라이언트 버전, 코어 이름, 사용 가능한 노드, 수신 포트, 시스템 프록시 모드, 라우팅 모드를 적어 두세요.
  2. 설정 내용을 백업합니다. 구독 주소와 사용자 지정 라우팅 규칙을 저장해 업그레이드나 전환 후 복원할 수 있게 하세요.
  3. 노드 프로토콜을 확인합니다. 노드 이름만으로 분류하지 말고 VMess, VLESS, 전송 방식, 보안 계층, flow를 하나씩 표시하세요.
  4. 로컬 포트를 확인합니다. SOCKS와 HTTP 인바운드 포트를 다른 프로세스가 사용하고 있지 않은지 확인하고, 코어 전환 시 이전 프로세스가 백그라운드에 남아 있지 않게 하세요.
  5. 먼저 노드 하나를 테스트합니다. 복잡한 분기를 끄고 매개변수가 완전한 노드 하나를 선택해 기본 연결을 확인하세요.
  6. 실행 로그를 확인합니다. 설정 파싱, DNS, 핸드셰이크, 인증, 시간 초과, 라우팅 오류를 구분하세요. 오류 유형마다 확인해야 할 방향이 다릅니다.
  7. 라우팅 규칙을 복원합니다. 직결, 프록시, 차단 규칙을 단순한 것부터 복잡한 순서로 추가하고, 수정할 때마다 대표 도메인으로 테스트하세요.
  8. 구독을 업데이트한 뒤 다시 확인합니다. 특히 REALITY와 Vision에 필요한 필드가 업데이트 과정에서 수동 설정과 함께 덮어써지지 않았는지 확인하세요.

반대로 Xray에서 V2Fly로 전환할 때는 코어 파일만 바로 교체하지 말고 먼저 Xray 전용 기능에 대한 의존성을 제거해야 합니다. 노드가 여전히 REALITY 또는 Vision을 요구한다면 V2Fly는 동등한 연결을 제공할 수 없습니다. 기존 노드를 계속 사용해야 한다면 Xray를 유지하고, V2Fly를 사용하려면 서버가 명확히 지원하는 설정 조합을 준비해야 합니다.

자주 묻는 질문

Xray는 모든 V2Fly 설정을 바로 읽을 수 있나요?

“모든 설정”이라고 이해해서는 안 됩니다. 기본 구조가 비슷해 일반적인 인바운드, 아웃바운드, 라우팅 설정은 쉽게 이전될 수 있지만 오래된 필드, 버전 차이, 전송 매개변수, 확장 기능은 항목별 확인이 필요합니다. 읽기에 성공한 뒤에도 DNS, 라우팅, 실제 연결을 테스트해야 합니다.

V2Fly는 일반 VLESS 노드에 연결할 수 있나요?

코어 버전과 노드 조합에 따라 다릅니다. VLESS라는 이름만으로 판단할 수 없습니다. 일반 전송과 기본 매개변수는 지원될 수 있지만 노드에 REALITY 또는 Vision이 포함되어 있다면 Xray를 사용하고 관련 필드를 그대로 유지해야 합니다.

코어를 바꾼 뒤 구독을 다시 가져와야 하나요?

노드 설정을 한 번 다시 생성하거나 업데이트한 뒤 항목별로 확인하는 것이 좋습니다. 클라이언트에 저장된 노드 정보는 같아도 새 코어가 실제로 허용하는 필드와 값은 다를 수 있습니다. 업데이트 후에는 먼저 노드 하나를 테스트하고 일괄 선택과 라우팅 규칙을 복원하세요.

Xray와 V2Fly의 지연 시간 측정 결과가 다른 이유는 무엇인가요?

지연 시간 테스트는 서로 다른 탐색 방식을 사용할 수 있고 DNS, 연결 재사용, 전송 계층, 회선 변동, 테스트 대상의 영향도 받습니다. 네트워크, 노드, 테스트 방식을 고정하고 여러 차례 결과를 기록한 뒤 실제 웹 연결과 장시간 연결 안정성을 함께 평가해야 합니다.

노드를 가져오는 데 성공했지만 REALITY에 연결할 수 없습니다. 무엇부터 확인하나요?

먼저 Xray를 사용 중인지 확인한 다음 VLESS 사용자 식별자, serverName, 공개 키, shortId, 지문, Vision flow를 대조하세요. 이어서 시스템 시간과 클라이언트 로그를 확인합니다. 오류를 피하려고 보안 매개변수를 삭제하지 마세요.

최종 선택 원칙

Xray의 뚜렷한 강점은 XTLS, REALITY, VLESS 중심의 지속적인 확장에 있습니다. V2Fly의 핵심은 기존 설정 체계와 기존 기능 노선을 이어가는 것입니다. 둘 다 적합한 사용 환경이 있으므로 코어 선택의 기준은 브랜드 선호가 아니라 서버 요구 사항, 노드 필드, 클라이언트 지원, 기존 설정을 바꾸는 비용이어야 합니다.

실제로 선택할 때는 세 단계를 따르세요. 첫째, 노드에 REALITY 또는 Vision이 포함되어 있는지 확인합니다. 둘째, 클라이언트에서 실제로 실행 중인 코어를 확인합니다. 셋째, 복잡한 분기를 끈 상태에서 기본 연결을 테스트합니다. 기본 연결이 확인된 뒤 구독 업데이트, DNS, 라우팅 규칙을 복원하세요. 이 순서를 따르면 코어 호환성, 구독 필드 누락, 분기 오류를 서로 뒤섞지 않고 처리할 수 있습니다.