V2Ray 구성 파일 완벽 가이드

V2Ray와 Xray의 기본 구성은 트래픽 처리 파이프라인을 설명하는 JSON 객체로 이해할 수 있습니다. 인바운드는 연결을 받고, 라우팅은 목적지를 판단하며, 아웃바운드는 연결을 수행합니다. DNS와 정책 객체는 이 파이프라인에 이름 해석과 리소스 제약을 더합니다.

최상위 객체는 실행 단계 목록이 아닙니다

구성 파일의 최외곽은 하나의 JSON 객체로 이루어지며, 일반적으로 log, dns, inbounds, outbounds, routing, policy, stats 키를 포함합니다. JSON 객체는 작성 위치가 아니라 키 이름으로 구조를 표현하므로, 이러한 키의 배치 순서는 대개 실행 순서를 결정하지 않습니다. 실제로 순서가 의미를 갖는 부분은 주로 배열입니다. 예를 들어 routing.rules는 앞에서부터 매칭하며, 먼저 일치한 규칙이 아웃바운드를 결정합니다. 여러 인바운드와 아웃바운드는 각각의 tag를 통해 다른 객체에서 참조됩니다.

구성을 읽을 때는 먼저 모든 태그를 기록한 다음 참조 관계를 따라 확인하는 방법이 안전합니다. 인바운드 태그는 라우팅 규칙의 inboundTag에서 사용될 수 있고, 아웃바운드 태그는 outboundTag가 가리키며, DNS 서버도 tag를 통해 라우팅 규칙과 연결될 수 있습니다. 태그 자체는 구성 내부 식별자일 뿐 자동으로 트래픽 분할을 만들지 않습니다. 존재하지 않는 태그를 규칙에 사용하면 시작 단계에서 오류가 발생하거나, 해당 경로가 실행될 때 트래픽의 목적지를 찾지 못할 수 있습니다. 구체적인 동작은 코어와 필드 위치에 따라 달라집니다.

{
  "log": {
    "loglevel": "warning"
  },
  "dns": {
    "servers": ["1.1.1.1", "localhost"]
  },
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "blocked",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

배열, 객체 및 값의 유형

inbounds, outbounds, routing.rules는 모두 배열이므로 대괄호를 사용합니다. 단일 인바운드, 아웃바운드 또는 규칙은 객체이므로 중괄호를 사용합니다. 포트는 숫자이며 단위가 붙은 문자열로 작성하면 안 됩니다. 불리언 값은 true 또는 false만 사용할 수 있습니다. 필드를 생략하는 것과 값으로 null을 지정하는 것은 같지 않습니다. 생략하면 코어가 기본 동작을 사용하지만, 명시적인 빈 값은 해당 필드 정의에서 허용할 때만 의미가 있습니다. 시작 실패의 상당수는 프로토콜 문제가 아니라 괄호 누락, 객체 사이의 쉼표 누락, 문자열에 중국식 따옴표 사용, 배열이어야 할 필드를 단일 문자열로 작성한 데서 발생합니다.

표준 JSON에서는 주석을 사용할 수 없고 마지막 멤버 뒤에 후행 쉼표를 둘 수도 없습니다. 온라인 예제는 설명을 위해 // 주석을 넣는 경우가 있지만, 클라이언트 코어 구성에 복사하기 전 반드시 삭제해야 합니다. v2rayN, v2rayNG, v2flyNG는 그래픽 인터페이스 외부에서 자체 구성 계층을 관리할 수 있으며, 인터페이스의 노드·구독·라우팅 설정은 변환된 뒤 코어에 전달됩니다. 따라서 직접 편집하기 전에 수정 대상이 클라이언트 관리 파일인지, 생성된 실행 구성인지, 독립 코어가 읽는 구성인지 확인해야 합니다. 파일 이름이 비슷하다는 이유만으로 이 셋을 같은 객체로 보면 안 됩니다.

최소 구성에서 복잡도를 단계적으로 높이기

구성을 점검할 때는 로컬 인바운드 하나, 명확하게 작동하는 아웃바운드 하나, 최소한의 라우팅만 남긴 뒤 DNS, 스니핑, 여러 전송 방식과 통계 정책을 단계적으로 추가해야 합니다. 여러 모듈을 한꺼번에 추가하면 오류 원인이 서로 가려집니다. 예를 들어 연결 실패는 원격 서버 매개변수 때문일 수도 있고, 도메인이 잘못된 DNS 경로로 먼저 해석되었기 때문일 수도 있으며, 선행 규칙이 연결을 blocked로 보냈기 때문일 수도 있습니다. 최소화란 필요한 보안 필드를 삭제하는 것이 아니라 변수의 연결 고리를 줄이는 것입니다. 서버가 요구하는 주소, 포트, 사용자 식별자, 전송 및 보안 매개변수는 유지하고, 연결성에 영향을 주지 않는 부가 규칙만 일시적으로 제거하세요.

저장하기 전 텍스트 인코딩이 UTF-8인지, 파일에 루트 객체가 하나만 있는지, 키 이름의 대소문자가 필드 정의와 일치하는지 확인해야 합니다. outboundTag와 outboundtag는 서로 다른 이름이며, 프로토콜 이름도 인터페이스의 번역명을 보고 추측해서는 안 됩니다. 구조 검사가 끝나면 인바운드, 아웃바운드, 라우팅을 차례로 검증하세요. 대형 구성에서 포트만 반복해서 바꾸는 것보다 원인을 훨씬 명확하게 파악할 수 있습니다.

아웃바운드는 라우팅으로 선택된 연결을 목적지로 보냅니다. 원격 프로토콜 서버에 연결할 수도 있고, 목적지에 직접 연결하거나 연결을 거부하거나 다른 아웃바운드로 넘겨 계속 처리할 수도 있습니다.

프로토콜 필드는 전체 구조로 확인해야 합니다

원격 아웃바운드는 일반적으로 protocol, settings, streamSettings가 함께 정의합니다. VLESS를 예로 들면 서버 주소와 포트는 vnext 항목에, 사용자 식별자는 users에 있습니다. 전송 방식, 보안 계층, 서버 이름은 streamSettings에 지정합니다. 주소, 포트, 사용자 식별자만 확인해서는 구성이 일치한다고 볼 수 없습니다. 클라이언트와 서버의 네트워크 전송, TLS 계열 보안 설정, 경로, 호스트 이름 및 관련 확장 매개변수도 서로 대응해야 합니다.

구성 인터페이스에서는 이러한 필드를 ‘주소’, ‘사용자’, ‘전송’, ‘보안’ 등의 페이지에 나누어 표시하는 경우가 많지만, JSON에서는 인접한 객체에 배치됩니다. 구독 가져오기에 문제가 생기면 노드 표시 이름만 보고 판단하지 말고 클라이언트 상세 페이지에서 항목별로 확인하세요. 노드 이름은 대개 로컬 메모일 뿐 프로토콜 핸드셰이크에 관여하지 않습니다. 실제 연결을 좌우하는 것은 구조화된 필드입니다. 매개변수를 직접 옮길 때는 URI에서 인코딩된 텍스트를 JSON 원문으로 바로 사용하지 말고, 인터페이스에서 ‘기본값’을 의미하는 빈 항목을 임의로 "default" 문자열로 바꾸지도 마세요.

{
  "outbounds": [
    {
      "tag": "remote-vless",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-4111-8111-111111111111",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "tlsSettings": {
          "serverName": "server.example.com"
        },
        "wsSettings": {
          "path": "/example-path",
          "headers": {
            "Host": "server.example.com"
          }
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "blocked",
      "protocol": "blackhole"
    }
  ]
}

direct와 blocked는 명확한 처리 경로입니다

freedom 아웃바운드는 보통 목적지에 직접 연결하는 데 사용하며 direct로 표시합니다. blackhole은 규칙에 선택된 연결을 종료하는 데 사용하며 blocked로 표시하는 경우가 많습니다. 이러한 태그는 관례적인 이름일 뿐 변경할 수 있지만, 라우팅 참조도 함께 수정해야 합니다. freedom을 아웃바운드 배열에 넣는 것만으로 로컬 주소가 자동으로 직접 연결되지는 않습니다. 해당 트래픽을 그 아웃바운드로 보내는 라우팅 규칙이 필요합니다. 마찬가지로 blackhole을 정의해도 아무 도메인이나 자동 차단되지 않으며, 매칭 규칙이 이를 참조해야 적용됩니다.

규칙에 일치하는 항목이 없으면 코어는 일반적으로 기본 아웃바운드를 선택하지만, 구체적인 동작은 구성 구조와 코어 구현에 따라 달라집니다. 구성 독자가 암묵적인 순서에 의존하지 않도록 대형 구성에서는 중요한 트래픽에 명시적인 규칙을 작성하는 편이 좋습니다. 아웃바운드 태그도 읽기 쉬워야 합니다. 원격 연결, 직접 연결, 차단 연결의 이름은 혼동하기 쉬운 연속 숫자보다 용도를 나타내야 합니다. 이름이 명확하면 로그의 아웃바운드 식별자를 구성과 대조하기도 쉽습니다.

아웃바운드 체인, 프록시 설정 및 순환 참조

일부 코어는 proxySettings 또는 다른 방식을 통해 한 아웃바운드가 다른 아웃바운드를 거쳐 연결하도록 허용합니다. 명확하게 설계된 체인형 출구에 적합하지만 DNS, 핸드셰이크 및 장애 분석 단계도 늘어납니다. 체인의 각 구간에는 고유 태그가 있어야 하며 A가 B를 가리키고 B가 다시 A를 가리키는 순환을 만들면 안 됩니다. 원격 서버 도메인을 어떻게 해석할지도 별도로 고려해야 합니다. 첫 번째 연결을 만들기 위한 DNS 조회가 아직 연결되지 않은 아웃바운드에 의존하면 시작 후 계속 시간 초과가 발생하는 순환 구조가 될 수 있습니다.

체인 구성은 실제 연결을 마지막으로 담당하는 단일 아웃바운드부터 독립적으로 작동하게 만든 뒤, 앞쪽 구간을 하나씩 추가하며 점검해야 합니다. 로그에 ‘연결이 종료됨’만 표시된다면 아웃바운드 태그를 함께 확인하여 어느 계층에서 실패했는지 판단하세요. 원격 서버의 거부, 도메인 해석 실패, TLS 서버 이름 불일치, 로컬 라우팅의 잘못된 선행 선택은 모두 앱에서 페이지가 열리지 않는 것처럼 보일 수 있습니다. 모든 프로토콜 매개변수를 동시에 바꾸기보다 계층별로 검증해야 원인을 추적할 증거를 보존할 수 있습니다.

데스크톱에서는 v2rayN으로 노드와 코어 구성을 관리하는 것이 좋고, Android에서는 코어 요구 사항에 따라 v2rayNG 또는 v2flyNG를 선택할 수 있습니다. Xray와 V2Fly의 용도를 비교하려면 Xray와 V2Fly 코어 차이 정리를 참고하세요. 코어 브랜치에 따라 지원되는 필드 범위가 다를 수 있으므로 복잡한 구성을 옮기기 전에 대상 클라이언트에서 실제로 어떤 코어를 활성화했는지 확인해야 합니다.

DNS 구성은 코어가 도메인을 해석해야 할 때 어떤 서버에 조회하고, 특정 도메인을 어느 해석 경로로 우선 보낼지 결정합니다. 운영체제 DNS, 앱 자체 해석, 라우팅 단계의 해석과는 서로 다른 계층입니다.

먼저 누가 조회를 시작했는지 구분하기

앱이 먼저 시스템 계층에서 도메인을 해석한 뒤 프록시에 목적지 IP만 전달할 수 있습니다. 반대로 도메인을 SOCKS 또는 HTTP 인바운드에 그대로 전달할 수도 있으며, 자체 암호화 DNS를 사용하는 앱도 있습니다. 코어로 들어와 코어가 처리하는 조회만 최상위 dns 객체의 직접적인 영향을 받습니다. 따라서 구성을 바꾼 뒤 예상한 변화가 보이지 않으면 인바운드가 도메인을 받았는지 IP를 받았는지, 스니핑으로 도메인을 복원했는지 먼저 확인하세요. dns.servers만 바꾼다고 모든 시스템 프로그램이 자체 해석 경로를 포기하는 것은 아닙니다.

servers에는 단순 주소를 넣을 수도 있고, address, domains, expectIPs, skipFallback 등의 속성을 가진 객체를 넣을 수도 있습니다. 단순 배열은 단일 경로에 적합하고, 객체 형식은 도메인별 서버 선택에 적합합니다. 서버 목록이 항상 ‘첫 번째 서버가 실패하면 두 번째 서버를 사용’하는 전통적인 백업 방식으로 동작하는 것은 아닙니다. 도메인 필터, 폴백 설정 및 코어 구현이 함께 조회 대상을 결정합니다. 복잡한 DNS를 설계하기 전에는 역할이 분명한 서버 두 개로 먼저 검증한 다음 도메인 범위와 폴백 제한을 추가하세요.

{
  "dns": {
    "hosts": {
      "router.example": "192.168.1.1"
    },
    "servers": [
      {
        "address": "localhost",
        "domains": [
          "full:router.example",
          "domain:internal.example"
        ],
        "skipFallback": true
      },
      {
        "address": "1.1.1.1",
        "domains": [
          "domain:public.example"
        ]
      },
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

hosts, domains 및 예상 결과

hosts는 특정 이름에 정적 매핑을 제공하며, 수가 적고 안정적인 로컬 서비스 이름에 적합합니다. 대규모 동적 도메인 목록에는 적합하지 않습니다. 정적 매핑은 우선순위가 높은 편이므로 주소가 바뀐 뒤 갱신하지 않으면 ‘특정 이름 하나만 계속 이전 주소를 가리키는’ 현상이 발생합니다. 문제를 점검할 때는 운영체제 hosts 파일, 클라이언트 인터페이스의 호스트 덮어쓰기 항목, 코어 구성의 dns.hosts를 함께 확인하여 여러 계층의 충돌을 피하세요.

서버 객체의 domains는 해당 서버로 보낼 도메인을 필터링합니다. 문법은 라우팅 도메인 조건과 비슷하지만 용도는 다릅니다. 전자는 해석기를 선택하고 후자는 연결 아웃바운드를 선택합니다. expectIPs는 예상 반환 주소 범위를 제한하여 결과가 사전 설정에 맞는지 판단하는 데 사용합니다. 임의의 응답을 목표 범위로 바꾸는 기능은 아닙니다. 범위를 지나치게 좁히면 정상 응답도 제외되어 폴백으로 넘어갈 수 있습니다. skipFallback은 해당 서버가 폴백에 참여하는 방식을 바꿉니다. 함께 사용하기 전 ‘도메인 선택—서버 조회—결과 검사—연결 라우팅’의 네 단계 관계를 먼저 그려 보세요.

DNS 조회에서 아웃바운드를 선택하는 방식

DNS 서버 주소 자체도 연결을 수립해야 합니다. 서버를 도메인으로 지정하면 먼저 해석기 도메인을 해석해야 하는 문제가 생기고, IP로 지정하면 이 단계는 생략되지만 네트워크 아웃바운드는 여전히 라우팅으로 선택해야 합니다. 복잡한 구성에서는 DNS 트래픽에 태그를 부여한 뒤 라우팅에서 해당 태그나 프로토콜에 따라 특정 아웃바운드로 보낼 수 있습니다. 이때 순환을 피해야 합니다. 원격 아웃바운드가 도메인 해석에 의존하고, 그 도메인 해석이 아직 연결되지 않은 원격 아웃바운드를 요구하는 구조가 대표적인 순환입니다.

설명 가능한 경로를 만들려면 먼저 원격 서버 주소에 안정적인 기본 해석 경로를 마련한 뒤 일반 목적지 도메인의 분할 방식을 결정하세요. 구성에서 domainStrategy와 DNS 규칙을 함께 사용하면 라우팅이 IP 조건을 판단하기 위해 시작한 해석도 DNS 모듈로 들어갑니다. 따라서 겉으로는 라우팅 문제처럼 보여도 실제 원인은 DNS 서버 선택이나 폴백 결과일 수 있습니다. 로그를 점검할 때는 마지막 시간 초과 한 줄만 보지 말고 조회, 주소 획득, 아웃바운드 선택, 연결 대상의 순서를 시간 흐름에 따라 확인하세요.

캐시 및 IPv4·IPv6 선택

queryStrategy는 조회 결과의 주소 계열을 제한하거나 우선시합니다. 지원 범위는 코어마다 다릅니다. 한 주소 계열만 강제하면 로컬 네트워크가 불완전한 문제를 피할 수 있지만, 원래 접근 가능한 목적지까지 제외할 수 있습니다. 먼저 운영체제가 해당 네트워크에 연결할 수 있는지 확인한 뒤 조회 제한 여부를 결정하세요. 클라이언트, 코어, 시스템 해석기가 결과를 각각 캐시할 수 있으므로 DNS를 바꾼 직후 재시도해도 새 조회가 발생하지 않을 수 있습니다. 관련 클라이언트 프로세스를 재시작하고 연결을 다시 만들 수는 있지만, 캐시 삭제를 장기적인 구성 해결책으로 삼아서는 안 됩니다.

‘도메인은 접속할 수 없지만 IP로는 접속되는’ 경우 먼저 조회가 주소를 반환했는지 확인하고, 반환된 주소가 라우팅 규칙에 의해 예상한 아웃바운드로 전달되는지 점검하세요. ‘일부 도메인만 간헐적으로 실패’한다면 실패와 성공 시 선택된 DNS 서버, 주소 계열, 아웃바운드 태그를 비교해야 합니다. 서버를 바꾸는 것은 해석기 경로를 검증하는 방법일 뿐 규칙 조건 점검을 대신할 수 없습니다. 일반적인 클라이언트 연결 흐름과 검증 방법은 입문 가이드에서 단계별로 확인할 수 있습니다.

원격 프로토콜은 신원과 요청 형식을 정의하고, streamSettings는 해당 데이터가 네트워크 연결에 실리는 방식을 정의합니다. 양쪽의 프로토콜 매개변수가 맞더라도 전송 계층이 다르면 연결을 완료할 수 없습니다.

network가 결정하는 후속 설정 객체

streamSettings.network는 전송 유형을 지정하며, 일반적인 구성에는 TCP, WebSocket, gRPC, mKCP 등이 사용될 수 있습니다. 특정 네트워크를 선택한 뒤에는 이에 맞는 설정 객체를 사용해야 합니다. 예를 들어 WebSocket은 wsSettings를, gRPC는 해당 서비스 이름 설정을 사용합니다. 다른 전송의 필드를 구성에 남겨둔다고 두 방식이 자동으로 결합되지는 않으며, 오히려 잘못 읽게 만들 수 있습니다. 노드를 이전할 때는 먼저 인터페이스에 표시된 전송 유형을 확인한 뒤 전용 필드를 항목별로 점검하세요.

전송 유형은 클라이언트가 일방적으로 최적화할 수 있는 옵션이 아닙니다. 서버가 어떤 전송을 수신하고 어떤 경로나 서비스 이름을 사용하는지에 맞춰 클라이언트도 같은 구조로 연결해야 합니다. 오류가 발생했을 때 TCP, WebSocket, gRPC 사이를 계속 바꾸면 대개 변수만 늘어납니다. 원본 구성에 따라 전송 유형을 고정하고, 주소 해석 여부와 포트 접근성을 확인한 다음 경로, 호스트 필드, 보안 계층을 점검하는 편이 안전합니다.

{
  "streamSettings": {
    "network": "grpc",
    "security": "tls",
    "tlsSettings": {
      "serverName": "edge.example.com",
      "allowInsecure": false,
      "alpn": ["h2"]
    },
    "grpcSettings": {
      "serviceName": "example-service",
      "multiMode": false
    },
    "sockopt": {
      "tcpKeepAliveIdle": 100
    }
  }
}

WebSocket 경로, Host 및 TLS 이름

WebSocket 구성의 path는 HTTP 핸드셰이크 경로입니다. 앞에 슬래시가 필요한지, 쿼리 부분을 포함하는지는 서버 진입점과 일치해야 합니다. headers.Host는 WebSocket 핸드셰이크 헤더이고, tlsSettings.serverName은 TLS 서버 이름 검증에 사용됩니다. 둘이 같을 수도 있지만 배포 구조에 따라 다를 수도 있습니다. 두 필드를 하나처럼 취급해 동시에 바꾸면 한 계층은 통과하고 다른 계층은 실패할 수 있습니다.

서버 주소 address는 최초로 연결할 호스트를 결정하고, TLS 이름은 인증서와 핸드셰이크가 대상으로 삼을 이름을 결정하며, WebSocket Host는 HTTP 계층에서 처리됩니다. 문제를 점검할 때는 연결 수립 순서에 따라 이 세 항목을 이해해야 합니다. 주소로 TCP 연결은 되지만 TLS가 실패하면 시스템 시간, 서버 이름, 보안 매개변수를 확인하세요. TLS 성공 후 WebSocket이 거부되면 경로와 Host를 점검해야 합니다. 인증서 검증을 단순히 느슨하게 바꾸는 것은 오류를 숨기므로 일반적인 해결책으로 사용해서는 안 됩니다.

gRPC, mKCP 및 전송 전용 필드

gRPC 구성에는 대개 정확한 serviceName이 필요하며 HTTP/2 관련 협상에 의존합니다. 서비스 이름은 구성값이지 노드 메모가 아니며 URL 형식의 슬래시를 임의로 추가해서도 안 됩니다. 중간 계층이 필요한 연결 방식을 지원하지 않으면 핸드셰이크 직후 연결이 끊길 수 있습니다. mKCP는 UDP 기반 전송이므로 양쪽 매개변수뿐 아니라 현재 네트워크가 UDP를 안정적으로 전달할 수 있는지도 중요합니다. TCP에 연결할 수 있다고 해서 UDP 경로도 연결 가능하다는 뜻은 아닙니다.

전송 전용 매개변수가 많다면 클라이언트가 노드 정보에 따라 생성한 구조를 우선 사용하고, 명확한 요구가 있을 때만 수정하세요. 인터넷의 서로 다른 코어와 시기에 작성된 예제에는 이미 변경된 필드 이름이 포함될 수 있습니다. v2rayN은 일반적으로 데스크톱 코어 관리와 함께 사용되고, v2rayNG는 Xray 코어 경로를, v2flyNG는 V2Fly 코어를 대상으로 합니다. 같은 이름의 전송이라도 기본 개념은 비슷할 수 있지만 확장 필드가 완전히 같지는 않습니다. 지원 범위를 확신할 수 없다면 불필요한 확장을 먼저 제거하고 서버가 요구하는 핵심 필드만 유지하세요.

security, TLS 및 Reality의 계층

security는 사용할 보안 계층을 결정하며, 이에 대응하는 설정 객체도 일치해야 합니다. TLS 매개변수는 tlsSettings에, Reality 매개변수는 코어가 정한 독립 설정 객체에 둡니다. security 문자열만 바꾸고 기존 필드를 전부 재사용해서는 안 됩니다. 서버 이름, 공개 키 계열 매개변수, 짧은 식별자, 지문 선택은 특정 보안 방식의 핸드셰이크 조건이므로 동일한 유효 구성에서 가져와야 합니다.

보안 계층 오류와 사용자 식별자 오류는 인터페이스에서 모두 연결 테스트 실패로 나타날 수 있습니다. 따라서 로그에서 DNS, TCP, TLS, 프로토콜 인증이 각각 어느 단계에서 발생했는지 구분해야 합니다. 서버 포트에 연결조차 되지 않는다면 서버 이름을 계속 바꿔도 의미가 없습니다. TCP는 연결되었지만 보안 핸드셰이크가 실패했다면 먼저 라우팅 규칙을 수정해서는 안 됩니다. 장애가 발생한 계층을 특정한 뒤 매개변수를 바꾸면, 오류 형태만 잠시 바뀌고 근본 원인은 남는 일을 막을 수 있습니다.