MySQL 지원 종료: TuxCare ELS로 보안을 유지하세요

이 블로그 글의 AI 요약으로 바로 가기

MySQL의 지원 종료(EOL)는 기업용 데이터베이스 관리 분야에서 가장 중대한 영향을 미치면서도 가장 오랫동안 미뤄져 온 라이프사이클 이벤트 중 하나입니다. MySQL은 사실상 모든 산업 분야의 전자상거래 플랫폼, SaaS 애플리케이션, 콘텐츠 관리 시스템, 내부 도구 및 데이터 파이프라인을 뒷받침하고 있습니다. 바로 이러한 보편성 때문에 MySQL의 라이프사이클 관리는 그 중요성이 매우 크면서도, 상황이 급박해질 때까지 미루기 쉬운 것입니다.

하지만 MySQL 버전은 저절로 자연스럽게 노후화되지 않습니다. 각 버전에는 정해진 지원 기간이 있으며, 이 기간이 종료되면 오라클은 해당 버전에 대한 보안 패치 제공을 중단합니다. 그 시점 이후에 공개되는 모든 CVE는 사용 중인 버전에 적용되지만, 해당 버전을 위한 수정 패치는 더 이상 제공되지 않습니다. MySQL 5.7을 사용 중이라면, MySQL의 EOL(지원 종료) 시점은 2023년 10월이었습니다. MySQL 8.0을 사용 중이라면 2026년 4월이며, 이 날짜는 대부분의 팀이 생각하는 것보다 훨씬 가까워지고 있습니다.

이 글에서는 MySQL의 릴리스 라이프사이클이 실제로 어떻게 작동하는지, 보안 및 규정 준수 측면에서 MySQL EOL이 무엇을 의미하는지, 그리고 업그레이드를 다음 스프린트 일정에 단순히 포함시킬 수 없는 경우 어떤 선택지가 있는지 살펴보겠습니다.

주요 내용

의존성 요소들은 MySQL의 EOL(지원 종료) 관련 위험 요소를 가중시킵니다: MySQL은 OpenSSL, curl, LZ4, zlib 등 타사 C 라이브러리를 번들로 제공하며, 각 라이브러리는 고유한 CVE 취약점을 내포하고 있어 MySQL 버전이 지원 종료(EOL)에 도달하면 더 이상 패치가 제공되지 않습니다.
서둘러 진행하는 업그레이드는 비용이 많이 듭니다: MySQL의 메이저 버전 업그레이드에는 스키마 호환성 검증, 애플리케이션 쿼리 테스트, 복제 구성 재설정, 그리고 전체 환경에서의 조정된 배포가 수반됩니다. 계획되지 않은 마이그레이션에 드는 엔지니어링 비용은 결코 적지 않습니다.
MySQL의 지원 종료(EOL)가 보안의 종료를 의미하지는 않습니다. TuxCare의 Endless Lifecycle Support(ELS)는 지원이 종료된 MySQL 버전에 대해 지속적인 패치를 제공하며, 모든 종속성을 포괄하므로 고객은 원하는 일정에 맞춰 업그레이드하는 동안에도 데이터베이스 인프라를 안전하게 보호할 수 있습니다.

MySQL의 제품 수명 주기는 무엇인가요?

MySQL의 수명 주기는 오라클의 평생 지원 정책을 따르며, 이 정책은 각 주요 릴리스에 대해 세 가지 명확한 단계를 정의합니다:

프리미어 지원 일반 출시일로부터 5년. 이 기간 동안 오라클은 오라클 크리티컬 패치 업데이트(CPU) 프로그램을 통해 분기별로 정기적으로 새로운 기능, 버그 수정, 보안 경고 및 크리티컬 패치 업데이트를 제공합니다.
확장 지원 프리미어 지원 종료 후 3년간, 추가 비용을 지불하면 이용 가능합니다. 보안 경고 및 중요 패치 업데이트는 계속 제공되지만, 새로운 기능이나 일반적인 버그 수정은 제공되지 않습니다.
지속 지원 확장 지원이 종료된 후, 기간 제한 없이 이용 가능합니다. 중요한 점은 이 단계에서는 새로운 릴리스, 새로운 버그 수정, 새로운 보안 패치가 제공되지 않습니다. 기존에 제공된 수정 사항만 계속 이용할 수 있습니다.

데이터베이스 커뮤니티에서 MySQL 버전의 수명 종료(End of Life)를 언급할 때, 이는 해당 버전이 확장 지원(Extended Support)을 완전히 종료했거나, MySQL 5.7의 경우처럼 오라클이 해당 버전을 유지 관리 지원(Sustaining Support) 단계로 전환했음을 의미합니다. 실질적으로 이는 해당 시점부터 새로운 보안 패치가 더 이상 제공되지 않음을 뜻합니다.

MySQL은 향후 조직들이 라이프사이클을 보다 명확하게 예측할 수 있도록 2023년에 이중 릴리스 모델을 도입했습니다:

장기 지원(LTS) 릴리스 는 운영 환경의 안정성을 위해 설계되었습니다. 각 LTS 버전은 5년간의 프리미어 지원과 3년간의 확장 지원을 받습니다. MySQL 8.4가 현재 LTS 릴리스입니다.
혁신 릴리스 최신 기능을 포함하는 분기별 릴리스입니다. 각 Innovation 릴리스는 다음 릴리스가 출시될 때까지만 지원되므로, 예측 가능한 패치 주기가 필요한 운영 환경에는 적합하지 않습니다.

MySQL 버전	상태	참고 사항
5.7	2023년 10월 지원 종료	지속적인 지원만 제공되며, 새로운 보안 패치는 제공되지 않습니다
8.0	지원 종료: 2026년 4월	확장 지원 종료: 2026년 4월 이후 더 이상 패치가 제공되지 않습니다
8.4 LTS	지원됨	현재 LTS 버전에 대한 프리미어 지원은 2029년경까지 제공됩니다
9.x (혁신)	구르다	각 릴리스는 다음 분기 릴리스로 대체됩니다

실질적인 시사점은 다음과 같습니다. 만약 귀사의 서버 군이 MySQL 5.7을 실행 중이라면, 2023년 10월 이후로 업스트림 보안 패치 없이 운영해 온 셈입니다. MySQL 8.0을 실행 중이라면, 2026년 4월로 예정된 MySQL 지원 종료(EOL) 시한이 이미 다가오고 있습니다.

MySQL의 지원 종료란 무엇을 의미하나요?

보안 패치 더 이상 제공되지 않습니다

MySQL 버전이 지속 지원(Sustaining Support) 단계에 진입하면, 오라클은 해당 버전에 대한 보안 패치 개발을 중단합니다. 즉, 그 시점 이후에 MySQL의 핵심 구성 요소, 쿼리 최적화기, 복제 시스템, 번들 라이브러리에서 발견되는 모든 취약점에 대해 지원 대상 버전에는 패치가 제공되지만, 귀하의 버전에는 아무런 조치도 취해지지 않습니다.

지원 종료된 소프트웨어를 대규모로 운영할 때 직면하게 되는 핵심적인 보안 현실은 다음과 같습니다. 취약점 연구 커뮤니티와 오라클의 보안 팀이 지속적으로 문제를 발견하고 공개하고 있습니다. 과거에는 해당 버전에 대한 수정 사항을 제공하던 분기별 중요 패치 업데이트(CPU) 주기가 더 이상 적용되지 않게 됩니다. 해당 버전이 업데이트 대상에서 제외된 채로 CPU 주기가 지날 때마다 보안 위험은 더욱 커집니다.

MySQL 지원 종료(EOL) 이후의 보안 및 규정 준수 위험

규정 준수 측면에서도 상황은 분명합니다. PCI DSS(요구 사항 6.3.3)는 적용 대상 시스템의 경우 CVSS 점수가 7.0 이상인 중요 및 고위험 취약점에 대해 패치 출시 후 1개월 이내에 패치를 적용하도록 의무화하고 있습니다. HIPAA, FedRAMP 및 SOC 2 역시 각 규정이 적용되는 환경에 대해 유사한 요구 사항을 포함하고 있습니다. 규제 대상 환경에서 지원이 종료된 MySQL 버전을 운영한다는 것은 해당 프레임워크가 요구하는 기한 내에 패치를 적용할 수 없는 데이터베이스를 운영하는 것을 의미하며, 이는 보완 통제 조치로도 부분적으로만 해결할 수 있는 규정 준수 격차를 초래합니다.

MySQL은 고객 기록, 금융 거래 내역, 인증 정보 및 비즈니스 핵심 데이터를 보관하는 애플리케이션 워크로드의 데이터 저장소로서, 지원이 종료된 버전에 패치가 적용되지 않은 환경을 발견한 공격자들에게 주요 표적이 되고 있습니다.

MySQL의 CVE 이력

MySQL의 CVE 기록은 EOL 이후의 보안 취약점이 실제로 어떤 모습인지 잘 보여줍니다.

CVE-2023-21980 CVSS 7.1 고위험. 이 취약점은 버전 5.7.41 및 그 이전 버전, 그리고 8.0.32 및 그 이전 버전의 MySQL Server 클라이언트 프로그램 구성 요소에 영향을 미쳤습니다. 네트워크 액세스 권한을 가진 낮은 권한의 공격자는 이 결함을 악용하여 MySQL Server를 완전히 장악함으로써 기밀성, 무결성 및 가용성을 동시에 침해할 수 있습니다. Oracle은 2023년 4월 중요 패치 업데이트(Critical Patch Update)의 일환으로 지원 대상 버전에 대한 패치를 배포했습니다. 2023년 10월 EOL(지원 종료) 날짜 이후에도 MySQL 5.7을 계속 실행하는 모든 배포 환경은 향후 Oracle로부터 수정 경로를 제공받지 못했습니다. 수정 패치는 존재했으나, 지원 대상 버전에만 제공되었습니다. 이것이 바로 MySQL EOL 노출의 전형적인 패턴입니다. 지원 대상 버전에는 패치가 배포되는 반면, 지원이 종료된 배포 환경에서는 업스트림에서 수정할 수 없는 미해결 CVE가 누적됩니다.

이 현상이 특히 중요한 이유는 그 규모 때문입니다. 오라클의 분기별 보안 업데이트(CPU)에서는 InnoDB, 최적화기(Optimizer), 복제(Replication), DDL, 클라이언트 프로그램 등을 포함한 다양한 구성 요소에서 두 자릿수에 달하는 MySQL 취약점이 정기적으로 해결되고 있습니다. MySQL의 지원 종료(EOL) 이후 지날수록, 배포 환경에 적용되지 않는 수정 사항들이 계속 쌓이게 됩니다. 이러한 누적된 보안 위험은 분기마다 점점 커지고 있습니다.

의존성 표면 문제

MySQL은 독립 실행형 바이너리가 아닙니다. 이는 수많은 타사 C 라이브러리를 묶어 놓은 컴파일된 서버로, 각 라이브러리마다 고유한 취약점이 존재합니다. MySQL이 배포될 때, TLS 암호화를 위한 OpenSSL, HTTP 작업을 위한 curl, 압축을 위한 LZ4, 일반 데이터 압축을 위한 zlib, 네트워크 이벤트 처리를 위한 libevent 등 다양한 라이브러리가 링크되거나 번들로 포함됩니다.

이 번들 라이브러리들은 각각 고유한 CVE 이력과 독립적인 릴리스 주기를 가지고 있습니다. 오라클의 분기별 중요 패치 업데이트(Critical Patch Update)는 이러한 번들 구성 요소의 취약점을 해결하며, 중대한 TLS 취약점이 공개되면 MySQL에 포함된 OpenSSL 버전을 업그레이드하거나, 네트워크 처리 결함이 발견되면 번들로 제공되는 curl에 패치를 적용합니다.

MySQL의 지원 종료(EOL) 이후에는 번들로 제공되던 라이브러리 업데이트도 더 이상 사용자의 버전으로 전달되지 않습니다. 중대한 OpenSSL 취약점, curl의 메모리 손상 결함, LZ4의 버퍼 오버플로 등, 이러한 문제들은 모두 지원되는 MySQL 버전에서는 패치되지만, 사용자의 버전에서는 전혀 패치되지 않습니다. 위험 요소는 MySQL 자체의 쿼리 처리 코드에만 국한되지 않으며, MySQL에 컴파일되어 포함된 모든 라이브러리로까지 확대됩니다.

이는 MySQL 5.7의 지원 기간 동안에도 확인된 바 있습니다. Tenable이 발표한 MySQL 5.7 릴리스에 대한 패치 권고문에는 curl(CVE-2021-22901, 잠재적인 원격 코드 실행(RCE)을 유발할 수 있는 use-after-free 취약점), LZ4(CVE-2019-17543, 힙 오버플로우), OpenSSL(CVE-2021-3711, 서버 장악으로 이어질 수 있는 버퍼 오버플로우)과 같은 번들 구성 요소의 CVE를 MySQL 패치 릴리스를 통해 해결된 취약점으로 꾸준히 나열했으며, 이는 번들 라이브러리의 노출이 MySQL의 공격 표면에 얼마나 깊이 뿌리내리고 있는지를 정확히 보여줍니다. MySQL의 EOL(지원 종료)이 도래하면, 이러한 모든 수정 경로는 차단됩니다.

MySQL 지원 종료(EOL) 이후 보안 및 규정 준수를 유지하기 위한 방안

지원되는 MySQL 버전으로 업그레이드하기

MySQL 5.7을 여전히 사용 중이거나 2026년 4월 MySQL 8.0의 지원 종료 시점을 대비하고 있는 모든 조직에게 MySQL 8.4 LTS로의 마이그레이션은 권장되는 장기적인 방안입니다. MySQL 8.4 LTS는 오라클이 현재 제공하는 생산 환경용 장기 지원 릴리스로, 2029년경까지 프리미어 지원(Premier Support)이 제공됩니다.

이 마이그레이션의 난이도는 사용자의 환경에 따라 크게 달라집니다. MySQL 서버 군은 단일 개발 인스턴스처럼 업그레이드되지 않습니다. 변경 관리와 연계된 조정된 롤아웃, 애플리케이션 팀 간 단계별 배포, ORM 계층 및 애플리케이션 쿼리와의 스키마 호환성 검증, 복제 토폴로지의 재구성, 그리고 프로덕션 환경을 반영하는 스테이징 환경 전반에 걸친 테스트가 필요합니다. MySQL 5.7을 실행 중인 조직이 8.4로 직접 업그레이드하는 경우, 두 개의 메이저 버전 간 격차가 발생하므로 검증해야 할 호환성 범위가 더욱 넓어집니다.

다른 데이터베이스로 마이그레이션하기

일부 조직은 MySQL의 EOL(지원 종료) 시점을 계기로 PostgreSQL, MariaDB 또는 버전 수명 주기 관리를 자동화해 주는 관리형 클라우드 데이터베이스 서비스와 같은 대안을 검토하기도 합니다. 이러한 옵션들은 특정 환경에서는 장기적으로 충분히 타당한 선택지이지만, 이는 패치 마감 기한에 대응하기 위한 조치가 아니라 수 분기에 걸쳐 진행되는 엔지니어링 프로젝트입니다.

지원 종료 시점이 임박한 대부분의 조직에게 있어, 플랫폼 마이그레이션은 당면한 보안 및 규정 준수 격차를 해소하는 현실적인 해결책이 아닙니다.

또한, MariaDB 10.6의 EOL이 해당 방향으로 전환을 고려 중인 팀들에게 어떤 의미를 갖는지, 당사의 심층 가이드에서 자세히 알아보실 수 있습니다.

권장 솔루션: TuxCare의 MySQL 평생 라이프사이클 지원

TuxCare의 MySQL용 Endless Lifecycle Support(ELS)는 즉각적인 메이저 버전 마이그레이션 없이도 MySQL EOL(지원 종료)로 인한 보안 및 규정 준수 문제를 직접 해결합니다. TuxCare는 지원이 종료된 MySQL 버전에 대해 추가 비용 없이 지속적인 보안 패치를 제공하며, 이는 MySQL 자체 구성 요소와 번들로 제공되는 타사 라이브러리 종속성을 모두 포함합니다. 이를 통해 고객은 실제로 원하는 업그레이드 계획을 수립하는 동안에도 데이터베이스 환경을 견고한 보안 상태로 유지할 수 있습니다.

이 서비스의 작동 방식은 실용적입니다. TuxCare는 NVD, 오라클의 보안 권고 사항, 그리고 업스트림 라이브러리 보안 피드를 모니터링하여 MySQL 및 번들 구성 요소에 영향을 미치는 취약점을 파악한 후, SLA를 기반으로 한 프로세스를 통해 지원 종료(EOL) 버전에 대한 수정 사항을 역포트하여 제공합니다. 이를 통해 고객님의 MySQL 버전은 계속 가동되며, 규정 준수 상태도 유지됩니다. 또한 업그레이드 일정은 고객님의 조건에 맞춰 조정할 수 있습니다.

MySQL 업그레이드를 서두를 때의 위험성

MySQL의 지원 종료(EOL) 시기가 다가오면 즉각 대응해야 한다는 압박감이 실감 나지만, 잘못된 대응이 초래하는 대가는 대부분의 팀이 예상하는 것보다 훨씬 큽니다.

MySQL 업그레이드는 실제로 어떤 과정을 거치는가

MySQL의 주요 버전 업그레이드, 특히 운영 환경 전반에 걸쳐 5.7에서 8.4로 업그레이드하는 작업은 롤링 재시작 방식으로 진행될 수 없습니다. 이 작업에는 코드 수정 이 필요합니다. 또한 호환성 검증 이 필요합니다. Django, Rails, Hibernate 등과 같은 프레임워크의 버전 지원 매트릭스를 대상 MySQL 버전과 대조하여 확인해야 하기 때문입니다. 또한 백업 파이프라인, 모니터링 익스포터, MySQL 내부와 직접 통합되는 데이터베이스 마이그레이션 툴을 위한 백업 파이프라인, 모니터링 익스포터, MySQL 내부와 직접 연동되는 데이터베이스 마이그레이션 툴에 대한 조정 작업이 포함됩니다. 또한 테스트 오버헤드 쿼리 실행 계획, 최적화기 버전 간 차이, 인덱스 동작 변화, 그리고 실제 운영 환경과 유사한 부하 조건에서만 나타나는 애플리케이션 쿼리의 극한 사례에 대한 테스트가 포함됩니다.

수백 대에서 수천 대에 이르는 데이터베이스 호스트로 구성된 기업 환경에서는, 서로 다른 애플리케이션 간의 종속 관계, 변경 관리 프로세스에 따라 결정되는 패치 적용 기간, 그리고 조율된 검증이 필요한 서비스 간 종속 관계 등이 존재하기 때문에, 이는 단순한 주말 마이그레이션이 아닌 체계적인 작업 계획이 필요합니다.

업그레이드를 서두르면 어떤 일이 벌어질까

팀이 준비 상태가 아닌 규정 준수 기한 때문에 MySQL 업그레이드를 강행하게 되면, 그 후 나타나는 양상은 항상 비슷합니다. 애플리케이션 팀이 스테이징 환경에서 포착되지 않았던 쿼리 호환성 문제를 발견함에 따라 지원 요청이 급증합니다. 시스템 불안정성은 복제 지연, 예상치 못한 인덱스 동작, 또는 프로덕션 환경의 지연 시간에 영향을 미치는 쿼리 실행 계획의 퇴보 형태로 나타납니다. 마감 기한을 맞추기 위해 임시 방편을 적용함에 따라 기술 부채가 누적되고, 이는 이후 스프린트에서 해결해야 할 재작업으로 이어집니다. 또한 시작 전에 범위가 제대로 설정되지 않은 마이그레이션을 관리하는 데 드는 엔지니어링 시간, 잠재적인 서비스 중단, 운영 오버헤드 등 계획에 없던 비용이 급증합니다.

MySQL의 지원 종료(EOL) 전환을 잘 처리하는 조직들은 이를 준비되지 않은 마감 기한에 대한 긴급 대응이 아니라, 명확한 범위와 충분한 테스트 기간을 두고 전 과정에 걸쳐 안정적인 보안 상태를 유지하는 계획된 마이그레이션으로 간주합니다.

간편한 해결책: MySQL용 TuxCare ELS

TuxCare는 지원 종료된 소프트웨어에 대한 보안 패치를 대규모로 안정적으로 제공할 수 있도록 자동화 시스템, 전문 지식 및 프로세스를 10년 넘게 지속적으로 개선해 왔습니다. 지원 제품 포트폴리오 전반에 걸쳐 22만 개 이상의 패치를 제공해 온 경험을 바탕으로, TuxCare는 신속하면서도 운영 환경에 안전한 패치 적용 워크플로를 구축했습니다.

특히 MySQL의 경우, TuxCare의 ELS는 MySQL의 지원 종료(EOL)로 인해 발생하는 보안 공백을 메워줍니다:

신속하고 SLA가 보장되는 보안 패치. TuxCare는 취약점 공개 정보를 지속적으로 모니터링하고, 정의된 SLA에 따라 고위험 및 치명적 CVE(CVSS 7.0+)에 대한 패치를 제공하여, 귀하의 MySQL 배포 환경이 PCI DSS, HIPAA, FedRAMP 및 기타 규정 준수 프레임워크에서 요구하는 패치 적용 일정을 준수할 수 있도록 지원합니다.
완벽한 종속성 범위 커버리지: TuxCare는 추가 비용 없이 MySQL 자체의 취약점 영역은 물론, 함께 번들로 제공되는 OpenSSL, curl, LZ4 등의 타사 라이브러리까지 모두 커버합니다. MySQL의 컴파일된 종속성 내에 숨겨진 EOL(지원 종료) 위험은 더 이상 귀사의 문제가 되지 않습니다.
기존 워크플로우와의 원활한 통합. 현재 패키지 관리자, 구성 관리 도구 또는 기존 CI/CD 파이프라인을 통해 MySQL 업데이트를 관리하고 계시더라도, 기존 워크플로우를 최소한으로 변경하는 것만으로 업데이트 소스를 TuxCare의 보안 저장소로 전환할 수 있습니다. 현재 사용 중인 툴체인에는 아무런 차질이 없습니다.
서명되고 변조 방지 기능이 적용된 패키지. TuxCare가 제공하는 모든 패치는 사용자의 저장소에 도달하기 전에 무결성, 기능성 및 회귀 테스트를 철저히 거치며, 패키지는 암호학적으로 서명되어 사용자가 정확히 무엇을 배포하는지 알 수 있습니다.
연중무휴 전문가 지원 TuxCare의 보안 팀은 취약점 분류, 패치 요청 및 문제 해결을 위해 연중무휴 24시간 대기하고 있으므로, 전문적인 지원 없이 MySQL EOL 보안 사고를 처리해야 하는 상황이 발생하지 않습니다.

어떤 MySQL CVE가 이미 해결되었는지 확인하려면, TuxCare에서 실시간 CVE 추적기를 운영하고 있습니다. TuxCare의 패치 프로세스 및 검증 기준에 대한 자세한 내용은 기술 백서를 참조하십시오.

MySQL의 지원 종료로 인해 데이터베이스 인프라가 위험에 처하지 않도록 하세요

MySQL의 지원 종료(EOL)가 데이터베이스의 보안이 즉시 침해된다는 뜻은 아닙니다. 하지만 이는 인프라가 의존해 온 보안 지원이 더 이상 제공되지 않는다는 것을 의미하며, 그 시점부터 공개되는 모든 CVE는 상류 수준의 수정 경로 없이 그대로 노출된 상태로 남게 된다는 뜻입니다.

이 문제를 잘 처리하는 팀은 MySQL EOL을 압박감 속에서 대응해야 할 마감일이 아니라, 신중하게 관리해야 할 보안 문제로 여기는 팀입니다. 귀사의 인프라 용량, 애플리케이션 팀의 준비 상태, 그리고 조직의 변경 관리 프로세스에 진정으로 부합할 때 MySQL 8.4 LTS로의 신중한 마이그레이션을 계획할 수 있습니다. 일정을 확정하기 전에 마이그레이션 범위를 적절히 설정할 수 있습니다. 또는 TuxCare ELS를 활용하여 규정 준수 감사의 일정에 쫓기지 않고, 자체적인 조건에 따라 결정을 내리는 동안에도 보안 및 규정 준수 범위를 유지할 수 있습니다.

ELS for MySQL은 단순한 임시 해결책이 아닙니다. 이는 데이터베이스 환경을 안전하게 보호하고, 규정 준수 상태를 유지하며, 엔지니어링 팀이 긴급 마이그레이션 관리에 매달리지 않고 개발 업무에 집중할 수 있도록 해주는 최적의 선택입니다.

현재 MySQL의 지원 종료(EOL)가 보안 관리의 주요 관심사라면, 다음을 방문해 보세요 TuxCare의 오픈소스 소프트웨어 'Endless Lifecycle Support' 를 방문하여, 연장 지원이 필요한 기간 동안 데이터베이스 인프라를 어떻게 보호할 수 있는지 확인해 보십시오.

요약