많은 조직이 사이버 보안 프로그램의 핵심 요소로 위험 기반 취약점 관리를 도입하여, CVSS에만 의존하는 초기 분류 단계를 넘어 우선순위 결정 체계를 구축하고, 사이버 위협 인텔리전스 피드, 스캐너, 취약점 수정 워크플로우에 투자하고 있습니다. 그러나 문제 해결 대기열은 여전히 제대로 작동하지 않는 경우가 많고, 위험 점수는 IT 운영팀으로부터 신뢰를 얻기 어려우며, 팀들은 여전히 경영진에게 측정 가능한 위험 감소 효과를 입증하는 데 어려움을 겪고 있다.
이 글에서는 보장 범위 인프라부터 평가 모델, 팀 간 협력에 이르기까지 각 격차를 해소하는 방법을 단계별로 안내하며, 프로그램이 위험을 줄이고 있음을 입증하는 핵심 성과 지표(KPI)도 소개합니다. 이를 통해 귀사의 팀이 조직이 현재 직면한 위협에 발맞춰 대응할 수 있도록 돕습니다.
대부분의 RBVM 프로그램이 규모를 확장하기도 전에 정체되는 이유
기존의 ‘ ’ 방식의 취약점 관리 방식에서 전환하는 조직들은 종종 RBVM이 극복하고자 설계된 바로 그 약점들, 즉 불완전한 자산 가시성, 검증되지 않은 스캐너 분석 결과, 그리고 보안 팀과 IT 운영 팀 간의 불분명한 업무 인계 등을 그대로 이어가곤 합니다. 그러나 대부분의 팀은 위험 기반 우선순위 결정의 원칙을 이해하는 것이 오히려 더 쉬운 부분이라는 것을 깨닫게 됩니다. 기업 환경 전반에 걸쳐 이를 일관되게 적용하는 과정에서 추가적인 어려움이 발생합니다.
이 개념은 간단합니다. 실행 단계에서 프로그램이 오류가 발생합니다.
RBVM 실패의 대부분은 다음 세 가지 인프라상의 격차로 설명됩니다:
- 의 자산 가시성 미비: 부분적인 취약점 데이터를 바탕으로 산출된 위험 점수는 부분적인 보호 수준만을 제공합니다. 엔드포인트가 관리되지 않거나, 스캔되지 않았거나, 오래된 데이터를 반환하는 경우, 위험 대기열에는 어떤 우선순위 지정 모델로도 해결할 수 없는 사각지대가 존재합니다.
- 검증되지 않은 스캐너 결과: 스캐너 출력 결과가 확인된 노출과 동일하지는 않습니다. 스캔 데이터가 오래되었거나 자산 관리 상태가 불량한 환경에서는 오탐률이 상당히 높아져 IT 운영팀이 대기열을 신뢰하지 못하게 되고, 전반적으로 대응 속도가 느려질 수 있습니다.
- 관리되는 핸드오프 모델 없음: 보안 시스템이 위협을 식별하고 우선순위를 지정합니다. IT 운영팀은 문제를 해결합니다. 명확한 책임 소재, 위험 등급별 SLA, 예외 관리가 없다면, 발견된 문제들은 처리되지 못한 채 쌓이기만 할 뿐입니다.
보장 요건
사이버 위험 점수 는 이를 산출하는 데 기초가 되는 자산 목록 및 엔드포인트 상태 데이터만큼만 정확합니다. 보장 범위는 단순히 자산 수만으로 측정되는 것이 아닙니다. 이는 해당 시스템의 최신 구성, 패치 상태 및 노출 여부가 지속적으로 파악되고 있는지에 달려 있습니다. 그렇지 않으면, 우선순위 결정 모델은 불완전한 위험 정보를 바탕으로 작동하게 됩니다.
보장 공백이 발생하는 곳
기업 환경에서는 예상 가능한 부분에서 보안 사각지대가 발생합니다. 관리 대상이 아닌 기기, 계약업체의 노트북, 모바일 기기, 컨테이너, OT 및 ICS 자산, IoT 기기, 섀도우 IT, 그리고 에이전트가 오래되었거나 보고 기능을 수행하지 않는 엔드포인트는 모두 표준 스캔 대상에서 제외됩니다.
OT 및 ICS 자산에는 서로 다른 보호 전략이 필요합니다. 많은 기업이 기존 에이전트를 지원할 수 없으며, 과도한 스캔은 운영 차질을 초래할 위험이 있고, 패치를 적용할 수 없는 구형 소프트웨어가 흔히 사용되고 있습니다. 이러한 자산의 경우, 시정 조치가 아닌 보완적 통제 수단이 주요 위험 완화 수단이 되므로, 범위 계획 수립 시 초기 단계부터 이를 반영해야 합니다.
개발 환경에도 비슷한 사각지대가 존재합니다. DevOps CI/CD 파이프라인 을 통해 유입된 취약점 은 프로덕션 환경에 도달할 때까지 발견되지 않는 경우가 많으며, 이 경우 문제를 해결하는 데 훨씬 더 큰 혼란을 초래합니다.
200 개의 관리 대상 엔드포인트에서 발견된 취약점은, 위험 대기열에 한 번도 등록되지 않은 50 개의 비관리 대상 기기에서도 존재할 수 있습니다. 사진은 완성된 것처럼 보이지만, 실제 노출 범위는 눈에 보이는 것보다 더 넓습니다.
스캔 지연이 득점에 악영향을 미치는 이유
주기적인 스캔은 현재의 공격 표면이 아닌 과거의 상태를 반영하는 평가 결과를 산출합니다. 패치 주기, 배포 및 구성 변경이 지속적으로 발생하는 역동적인 환경에서는, 스캔 지연이 아무리 짧더라도 위험 점수가 실제 노출 상황을 더 이상 반영하지 못하게 될 수 있습니다.
실시간 엔드포인트 가시성을 통해 주기적인 스캔으로 인해 발생하는 지연을 줄임으로써, 위험 점수에 더 정확한 근거를 제공할 수 있습니다. 의 지속적인 모니터링을 위해 설계된 플랫폼 은 자주 업데이트되는 엔드포인트 원격 측정 데이터를 제공하므로, 우선순위 결정이 며칠 전의 순간적인 상황보다는 실제 상황을 반영할 수 있습니다.
자산 가시성 확보는 일회성 프로젝트가 아닙니다. 이는 끊임없이 실천해야 하는 훈련입니다. 그것이 없다면, 아무리 정교한 신용평가 모델이라도 실제 위험 상황을 제대로 반영하지 못하는 순위를 산출하게 된다.
실시간 가시성이 확보되면, 다음으로 제기되는 질문은 ‘팀들이 신뢰할 수 있는 위험 점수를 어떻게 구축할 것인가?’입니다.
리스크 점수가 실제로 어떻게 산정되는가
아무도 신뢰하지 않는 위험 점수는 차라리 점수가 아예 없는 것보다 더 나쁩니다. 효과적인 위험 평가는 보안 팀과 IT 운영 팀 모두가 입력 사항, 가중치 및 점수 산정 논리를 이해할 수 있는 명확하고 투명한 방법론에서 시작됩니다. 신뢰를 쌓기 위해서는 이러한 입력값과 가중치가 어떻게 결합되어 점수가 산출되는지 명확히 밝혀야 합니다.
또한, 팀은 우선순위 결정이 실질적인 조치로 이어질 수 있도록, 기초 데이터가 오래된 스냅샷이 아닌 실시간 시스템 상태를 반영하고 있다는 확신을 가져야 합니다.
RBVM 위험 점수를 산출하는 데 사용되는 네 가지 주요 입력 변수는 무엇인가요?
RBVM 위험 점수는 CVSS 기본 심각도(기술적 결함의 심각도), EPSS 악용 가능성(실제 악용 발생 가능성), CISA KEV 상태(활성 악용 확인 여부), 자산 중요도(비즈니스 기능 및 데이터 민감도)를 종합하여 실제 위험을 우선순위화합니다.
| 입력 | 측정 항목 | 그것이 왜 중요한가 |
|---|---|---|
| CVSS 기본 심각도 | 결함의 기술적 심각도 | 중대도 기준치를 제공하지만, 기본 점수는 실제 상황이나 악용 가능성*을 반영하지 않습니다. |
| EPSS 악용 가능성 | 야생에서 착취당할 가능성 | 현재 위협 행위자의 행동을 반영하며, 새로운 악용 활동이 포착될 때마다 변화하는 동적 신호 |
| CISA KEV 현황 | 해당 취약점이 실제로 악용되고 있는지 여부 | 실제 무기화 여부를 나타내는 이진 지표 |
| 자산 중요도 | 비즈니스 기능, 데이터 민감도, 노출 | 자산이 침해된 경우 폭발 반경을 결정합니다. |
이러한 입력 정보는 새로 공개된 익스플로잇, 새롭게 등장하는 공격 기법, 업데이트된 악용 가능성 점수 등의 최신 취약점 정보를 바탕으로 지속적으로 갱신될 때 가장 효과적입니다. 어떤 산업 분야가 적극적으로 표적이 되고 있는지, 어떤 익스플로잇 키트가 유포되고 있는지 등을 포함한 위협 상황은 특정 환경에 대한 점수 산정 가중치를 더욱 정교하게 조정하는 데 도움이 될 수 있습니다.
횡방향 이동 가능성, 즉 해당 자산의 네트워크 내 위치 및 노출 경로 역시 추가적인 위험 수정 요인으로 작용합니다. 격리된 테스트 서버의 취약점은, 민감한 고객 데이터로 연결되는 네트워크 경로에 위치한 도메인 컨트롤러나 애플리케이션 서버의 동일한 취약점과 비교할 때 다른 위험을 초래합니다.
[취약점 평가가 무엇인지, 침투 테스트와 어떻게 다른지, 그리고 주기적인 스캔보다 지속적인 가시성이 왜 더 중요한지 알아보세요]
위험 기반 접근법의 예로는 무엇이 있나요?
다음 두 가지 취약점을 살펴보겠습니다:
취약점 A: CVSS 9,8 (치명적), EPSS 0,02 (악용 가능성 낮음), CISA KEV에 등재되지 않았으며, 측면 이동 경로가 없는 격리된 테스트 서버에 영향을 미칩니다.
취약점 B: CVSS 7,5 (높음), EPSS 0,85 (악용 가능성 높음), CISA KEV에 등재된 이 취약점은 고객 데이터베이스에 대한 측면 접근 권한을 가진 운영 중인 결제 처리 서버에 영향을 미칩니다.
CVSS만 고려한다면 A가 B보다 우선순위가 높을 것입니다. 하지만 의 위험 기반 모델( )은 B의 우선순위를 올바르게 높입니다. 민감한 데이터로 연결되는 수평 이동 경로가 있는 운영 중인 결제 서버는 랜섬웨어 및 갈취 캠페인이 일상적으로 노리는 것으로 알려진, 가치가 높고 접근 가능한 표적의 유형을 나타내기 때문입니다.
이러한 전환이야말로 위험 기반 프로그램에서 취약점 우선순위 지정의 핵심입니다.
그러나 우선순위 지정만으로는, 이를 통해 시정 조치가 이행되고 검증되지 않는 한 위험을 줄일 수 없다.
[위험 기반 패치 적용, 단계적 배포, 지속적인 규정 준수 추적이 어떻게 기업이 취약점 공개와 악용 사이의 격차를 해소하는 데 도움이 되는지 알아보세요]
구체적인 비중 비율은 조직과 위험 수용 수준에 따라 다르지만, 다음과 같은 일반적인 원칙은 변함없이 적용됩니다. 즉, 동적인 위협 신호와 비즈니스 맥락은 정적인 심각도보다 더 큰 비중을 차지할 수 있으며, 또 그래야 합니다.
점수는 우선순위 결정뿐만 아니라 개선 조치의 실행을 관리하는 데에도 중요한 역할을 합니다. 프로그램이 자동화 단계로 발전함에 따라, 신뢰도 점수 산정은 어떤 조치가 사람의 검토 없이 대규모로 안전하게 적용될 수 있는지, 어떤 조치가 단계적 도입이나 수동 승인이 필요한지를 판단하는 데 도움이 될 수 있습니다.
위험 점수는 높지만 특정 OS 버전에서 패치의 안정성에 대한 불확실성이 있는 취약점의 경우, 즉시 적용하기보다는 단계적으로 배포하는 것이 더 적절할 수 있습니다. 신뢰도 임계값을 문제 해결 워크플로우에 맞추는 것이야말로 조직이 운영 위험을 증가시키지 않으면서 자동화를 확대해 나가는 방법입니다.
하지만 아무리 잘 구성된 분석 결과라 해도, 그 근거가 되는 발견이 사실일 때만 의미가 있다. 바로 그 지점에서 검증의 중요성이 부각됩니다.
조치를 취하기 전에 노출을 검증하기
스캐너 검사 결과만으로는 확진된 노출 사례라고 볼 수 없습니다. 입증되지 않은 조사 결과에 따라 조치를 취하면 시정 역량을 낭비할 뿐만 아니라, RBVM 프로그램의 기반이 되는 팀 간 신뢰를 훼손하게 됩니다. 검증은 그 격차가 커지기 전에 팀이 이를 해소하는 방법입니다.
[취약점 스캔 도구의 작동 원리, 기업 환경에 적합한 도구를 평가하는 방법, 그리고 탐지와 검증된 위험 저감의 차이점을 알아보세요]
‘검증’이란 무엇인가
‘확인된 노출’이란, 현재 엔드포인트 상태 및 구성 데이터를 바탕으로, 해당 엔드포인트에 실제로 존재하며 상쇄 통제 조치에 의해 이미 완화되지 않은 것으로 확인된 결과를 말합니다. 검증은 다음 세 가지 질문에 답합니다:
- 의 취약점이 있는 소프트웨어인 버전이 실제로 설치되어 실행 중인가요?
- 보상 제어만으로도 이미 위험을 완화하고 있습니까? 네트워크 분할, WAF 규칙, 그리고 구성 강화는 모두 악용 가능성을 줄일 수 있습니다.
- 해당 자산은 여전히 활성화되어 있고 접근 가능한가요?
이러한 수준의 확신을 바탕으로, 조직은 해당 과정에서 새로운 위험을 초래하지 않으면서도 수정 단계를 안전하게 자동화할 수 있습니다.
오탐이 신뢰를 훼손하는 이유
기업 환경에서는 스캐너 구성, 자산 상태, 스캔 시점에 따라 오탐률이 크게 달라집니다. 정확한 수치가 어떻든 간에, 대규모 환경에서 오탐지율이 다소 낮더라도, 발견된 문제가 수정 대기열에 들어가기 전에 검증되지 않으면 IT 운영 역량을 압도할 수 있습니다. 구식 취약점 스캔, 고려되지 않은 보완 통제 조치, 그리고 이미 폐기된 자산 등이 모두 원인이 됩니다.
IT 운영팀에 전달되는 오탐지 하나하나마다, 위험 요소를 해결하는 데 사용할 수 있었던 시간이 낭비됩니다. 시간이 지남에 따라 IT 팀은 대기열을 회의적인 시선으로 바라보기 시작한다. 응답 속도가 느려지면 대기열의 신뢰도가 떨어집니다.
예외 처리는 깔끔한 큐와 잡음이 많은 큐를 구분 짓는 요소입니다. 수용된 위험, 보상된 노출 사항 및 해체된 자산에 대한 조사 결과를 배제하는 공식적인 워크플로를 통해, 활성 대기열에는 실제적이고 아직 해결되지 않은 노출 사항만 반영되도록 보장합니다. 이러한 메커니즘이 없다면, 우선순위가 적절히 설정된 대기열이라 할지라도 시간이 지남에 따라 잡음이 누적되어 IT 운영팀의 신뢰도를 저하시킬 수 있습니다.
신뢰를 회복하기 위해서는 조직이 단순히 더 나은 순위 결정 모델만으로는 부족합니다. 그들은 파악된 문제들이 최신 상황을 반영하고 있으며, 시정 조치가 효과적이라는 확신을 가져야 합니다.
즉, 시정 조치가 단순히 티켓 종결이나 상태 업데이트에 그치는 것이 아니라, 시스템 상태에 검증 가능한 변화를 가져오는지 여부를 추적해야 한다는 뜻입니다.
[단순히 자주 스캔만 하는 취약점 관리 프로그램과 진정으로 지속적인 취약점 관리 프로그램을 구분하는 요소가 무엇인지 알아보세요]
Tanium이 위험 기반 취약점 관리를 지원하는 방법
대부분의 조직은 이미 어떤 취약점이 가장 중요한지 알고 있습니다. 더 어려운 과제는 그 지식을 바탕으로 신속하고 일관성 있게, 그리고 대규모로 실행에 옮기는 것입니다. Tanium Exposure Management 는 위험 기반 취약점 관리 프로그램의 진행을 저해하는 실행상의 격차를 해소하며, 실시간 가시성, 우선순위 지정, 수정 조치 및 검증 기능을 단일 플랫폼에서 통합합니다.
실시간 자산 가시성
Tanium은 엔드포인트, 관리되지 않는 기기, 컨테이너 레지스트리 및 쿠버네티스 워크로드를 지속적으로 모니터링하여 취약점과 규정 준수 미비 사항을 파악합니다. Tanium Cloud Workloads는 이미지 레지스트리 가시성 및 취약점 스캔, 런타임 컨테이너 분석, 쿠버네티스 정책 적용 기능을 통해 이러한 보호 범위를 컨테이너화된 환경으로 확장합니다. 이 플랫폼은 다른 도구들이 놓치는 자산들을 파악하기 때문에 보장 공백이 줄어듭니다.
현재 상황을 바탕으로 한 위험도 평가
엔드포인트 수준 및 조직 차원의 위험 점수는 정적 CVSS 점수로는 파악할 수 없는 취약점 심각도, 자산 중요도, 규정 준수 미준수 사항, 수평 이동 위험 등의 요소를 종합하고, 업계 동종 기업과의 비교 분석을 반영하여 산출됩니다. 점수는 주기적으로 찍은 특정 시점의 스냅샷이 아니라, 현재 엔드포인트의 상태를 반영합니다. Tanium Benchmark 는 보안 책임자들이 자사의 위험 현황을 업계 동종 기업들과 비교할 수 있도록 지원하며, 취약점 데이터를 경영진 및 규정 준수 팀이 필요로 하는 성과 중심의 지표로 변환해 줍니다.
통합 정화
팀들은 동일한 플랫폼에서 평가 단계에서 실행 단계로 전환합니다. 패치, 구성 변경 및 기타 제어 조치를 별도의 도구를 번갈아 사용하지 않고도 대규모로 적용할 수 있습니다. Tanium Comply 는 SCAP 및 OVAL 콘텐츠와 매일 업데이트되는 Tanium의 자체 콘텐츠 라이브러리를 활용하여 운영 체제, 애플리케이션, 소프트웨어 공급망 및 보안 구성에 대한 취약점 평가 및 규정 준수 점검을 지원합니다.
통제된 자동화
Tanium Automate 를 통해 팀은 반복 가능한 문제 해결 작업을 자동화하는 노코드 및 로우코드 플레이북을 구축할 수 있습니다. 플레이북은 실행 전에 운영자의 승인을 요구할 수 있어, 대규모 환경에서도 책임 소재를 명확히 할 수 있습니다.
폐루프 검증
수정 조치가 적용된 후 Comply 평가를 실행하면 해당 취약점이 해결되었는지 확인하고, 그에 따라 위험 점수를 업데이트합니다. Tanium은 전체 예약 스캔 주기를 거칠 필요 없이 필요에 따라 이 평가를 실행할 수 있습니다.
통합 IT 및 보안 작업 공간
두 팀 모두 단일 통합 플랫폼 내에서 동일한 위험 점수, 동일한 우선순위 지정 데이터, 동일한 시정 조치 현황을 바탕으로 업무를 수행합니다. 이러한 공유 운영 모델은 보안 및 IT 운영 팀이 서로 다른 도구와 데이터 소스에 의존할 때 발생하는, 문제 해결을 지연시키는 조정 부담을 줄이는 데 도움이 됩니다.
Tanium Guardian
Tanium Guardian은 Tanium 취약점 긴급 대응팀(VERT)의 전문가들이 엄선한 지침과 함께 새로운 위협 을 파악하여, 팀이 제로데이 공격 및 시급한 위험에 자신 있게 대응할 수 있도록 지원합니다. 팀은 Tanium 자율 IT 플랫폼 내에서 직접 문제 해결 조치를 실행할 수 있습니다.
이러한 기능들이 서로 유기적으로 연계되어 문제 발견부터 검증된 해결 조치에 이르기까지의 주기를 단축합니다. Ring Power Corp. 는 Tanium을 활용해 약 30 분 만에 모든 엔드포인트에 걸친 Log4j 건의 취약점을 파악했는데, 팀은 기존 도구를 사용했다면 이 작업에 수개월이 걸렸을 것으로 추정했습니다.
탐지, 우선순위 지정, 수정 조치가 하나의 플랫폼에서 이루어지면, 위험 기반 취약점 관리 프로그램은 위협 환경이 요구하는 속도에 맞춰 대응할 수 있습니다.
[지속적인 위협 노출 관리가 어떻게 작동하는지, 왜 패치 적용보다 검증 과정이 더 중요한지, 그리고 이것이 실제 보안 위험을 줄이는 데 어떻게 도움이 되는지 알아보세요]
위험 기반 취약점 관리에 관한 자주 묻는 질문
잘 알려진 프레임워크라 할지라도 실제 구현 과정에서 의문이 제기되기 마련이며, RBVM도 예외는 아닙니다. 다음 답변들은 팀이 RBVM을 실무에 적용할 때 가장 흔히 겪는 혼란스러운 점 중 일부를 다루고 있습니다.
RBVM은 기존의 취약점 관리와 어떻게 다른가요?
기존의 취약점 관리 방식은 CVSS 심각도 점수만을 기준으로 우선순위를 정하는 반면, RBVM은 악용 가능성과 자산의 중요도를 종합적으로 고려하여 실제 비즈니스 위험을 초래하는 취약점에 집중합니다. 예를 들어, 악용 가능성이 높은 결제 서버의 CVSS 7,5 등급 취약점은 격리된 테스트 시스템의 CVSS 9,8 등급 취약점보다 우선순위가 높을 수 있습니다.
위험 기반 취약점 관리는 사이버 보안 방어 체계를 어떻게 강화하는가?
RBVM은 공격자들이 현재 적극적으로 악용하고 있거나 악용할 가능성이 가장 높은 취약점에 대한 대응 자원을 집중함으로써 방어 체계를 강화합니다. 이를 통해 가장 심각한 보안 취약점에 대한 평균 해결 시간을 단축할 수 있으며, IT 운영 팀이 실질적인 위험을 초래하는 문제점에 집중할 수 있게 됩니다.
[IT 자동화가 어떻게 작동하는지, 왜 운영 위험을 줄여주는지, 그리고 IT 팀이 더 높은 부가가치를 창출하는 업무에 집중할 수 있도록 어떻게 도움을 주는지 알아보세요]
위험 기반 취약점 관리를 구현하는 데 가장 적합한 도구는 무엇인가요?
효과적인 RBVM 프로그램을 운영하려면 일반적으로 다음과 같은 여러 영역에 걸친 역량이 필요합니다. 지속적인 자산 탐지 및 인벤토리 관리, 취약점 스캔 및 정보 보강(EPSS 점수 및 CISA KEV 상태 포함), 수정 조치 할당을 위한 ITSM 도구와의 워크플로 통합, 그리고 배포된 수정 사항이 해당 취약점을 해결했는지 확인하는 기능 등이 그것입니다.
일부 조직은 여러 가지 개별 도구를 활용하여 이러한 기능을 구축합니다. 다른 업체들은 자산 가시성, 위험 점수 산정, 문제 해결을 하나의 워크플로우 플랫폼에 통합합니다. 올바른 접근 방식은 기존 툴스택, 팀 구조, 그리고 엔드포인트 가시성 문제가 이미 해결되었는지 여부에 따라 달라집니다.
Tanium 자율 IT 플랫폼은 실시간 엔드포인트 인텔리전스를 통합 워크플로우 및 문제 해결 기능과 연계하여, 보안 및 IT 팀이 공유되고 정확한 위험 현황을 바탕으로 업무를 수행할 수 있도록 지원합니다.
팀은 수동적인 후속 조치나 오래된 데이터에 의존하지 않고도 더 신속하게 대응하고, 업무 인계 지연을 줄이며, 전체 환경에서 문제 해결 결과를 확인할 수 있습니다.
어떤 취약점이 가장 중요한지 파악하는 것은 문제의 절반에 불과합니다. 이러한 문제를 신속하고 일관되게, 대규모로 해결하는 데서 대부분의 프로그램이 난관에 부딪힙니다.
지금 바로 무료 맞춤형 데모를 예약하세요. Tanium이 단일 플랫폼에서 실시간 가시성, 우선순위 지정, 문제 해결을 어떻게 연계하는지 확인해 보세요.
