Alpine Linux 지원 종료: 컨테이너 인프라의 보안을 유지하세요

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

주요 내용

컨테이너 이미지에 사용된 Alpine 버전이 지원 종료되면, OS 계층뿐만 아니라 기본 이미지에 포함된 모든 패키지에 대한 업스트림 보안 패치 제공도 중단됩니다.
마감 기한의 압박 속에서 강제로 진행되는 베이스 이미지 마이그레이션은 호환성 문제, 운영 환경의 불안정성, 기술적 부채, 그리고 연장 지원 비용을 훨씬 초과하는 예상치 못한 비용을 초래합니다.
TuxCare ELS는 핵심 Alpine 패키지에 대한 보안 지원 범위를 확장하므로, 조직은 신뢰할 수 있는 기본 이미지를 계속 사용하면서도 새로운 CVE에 대한 수정 패치를 받을 수 있습니다.

컨테이너 인프라를 오랫동안 운영하다 보면, 언젠가는 이런 순간을 마주하게 됩니다. 취약점 스캔에서 기본 이미지에 문제가 발견되거나, 보안 대시보드가 적색 경보를 표시하거나, 규정 준수 검토 과정에서 지원 종료 시점을 조용히 맞이한 Alpine 버전에 대한 질문을 받게 되는 경우 말이죠.

언뜻 보면 평범한 업데이트처럼 보일 수 있습니다. 하지만 컨테이너 베이스 이미지에 사용된 Alpine 버전이 지원 종료(EOL)에 이르면, 그 여파는 운영 체제 계층을 훨씬 넘어 확산됩니다. 보안 패치 제공이 중단되는 것은 Alpine 자체뿐만 아니라 해당 베이스 이미지에 포함된 패키지들까지 포함됩니다. 그 결과, 사소한 유지보수 작업처럼 보였던 일이 갑자기 컨테이너 공급망 전반에 걸친 체계적인 재구축 작업으로 변모하게 됩니다.

Alpine Linux는 현대적인 컨테이너 인프라의 핵심입니다. 최소한의 리소스 사용량, 빠른 시작 속도, 보안 중심의 설계 덕분에 수천 개 기업에 걸쳐 클라우드 및 쿠버네티스 환경에서 실행되는 컨테이너의 기본 베이스 이미지 레이어로 자리 잡았습니다. 하지만 Alpine의 짧은 릴리스 주기로 인해 지원 기간이 빠르게 종료되며, Alpine Linux의 지원 종료(EOL) 시점이 도래하면 운영에 미치는 영향은 대부분의 팀이 예상하는 것보다 훨씬 더 광범위합니다.

이 글에서는 컨테이너 기반 조직에게 Alpine Linux의 EOL(지원 종료)이 실제로 무엇을 의미하는지, 진정한 보안 위험 요소가 어디에 있는지, 관리가 어려운 이유는 무엇인지, 그리고 TuxCare의 Endless Lifecycle Support(ELS)를 통해 컨테이너의 핵심 가치인 배포 속도를 저해하지 않으면서도 완벽한 보안 범위를 유지할 수 있는 방법을 설명합니다.

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

Alpine Linux는 예측 가능하고 정해진 주기에 따라 릴리스를 진행합니다. 이 프로젝트는 롤링 릴리스 방식의 “edge” 채널에서 분기된 새로운 안정화 릴리스 브랜치를 매년 5월과 11월에 공개합니다. 각 릴리스에는 고유한 업데이트 스트림을 갖춘 버전별 브랜치(예: 3.19, 3.20, 3.21)가 부여됩니다.

각 브랜치의 메인 저장소는 출시일로부터 약 2년 동안 지원됩니다. 더 광범위한 패키지 세트를 포함하는 커뮤니티 저장소는 다음 안정화 버전이 출시될 때까지만 적극적인 지원을 받습니다. 표준 지원 기간이 지난 후에도 패치가 있는 경우 요청에 따라 보안 수정 사항이 적용될 수 있지만, 이는 공식적인 약속이 아니므로 운영 환경에서 이를 전적으로 의존해서는 안 됩니다.

그 결과, 간결하면서도 신속하게 진행되는 라이프사이클이 형성되었습니다. 6개월마다 새로운 브랜치가 출시되며, 지원 기간은 5월과 11월에 예측 가능한 일정에 따라 종료됩니다. 이러한 주기에 맞춰 업무를 수행하는 팀에게는 이 방식이 효과적입니다. 하지만 이미지 업데이트 비용이 많이 드는 대규모의 운영에 필수적인 컨테이너 환경을 운영하는 조직의 경우, Alpine Linux의 EOL(지원 종료)은 반복적인 운영상의 과제를 야기합니다.

지점	릴리스 날짜	지원 종료	상태
알파인 3.18	5월 2023	5월 9, 2025	EOL
알파인 3.19	12월 2023	11월 1, 2025	EOL
알파인 3.20	5월 2024	4월 1, 2026	활성 (만료 예정)
알파인 3.21	12월 2024	11월 1, 2026	활성
알파인 3.22	5월 2025	5월 1, 2027	활성
알파인 3.23	12월 2025	11월 1, 2027	활성(최신)

Alpine Linux의 EOL이 컨테이너 환경에 어떤 의미를 갖는가?

기존의 서버/VM 환경의 경우, 지원 종료 시점이 되면 OS에 대한 보안 패치 제공이 중단되므로, 영향을 받는 모든 호스트에 대해 계획된 OS 업그레이드를 수행해야 하며, 이는 대개 단계적인 배포와 애플리케이션 검증을 동반합니다. Alpine을 기본 이미지로 사용하는 컨테이너 기반 조직의 경우, ‘OS 업그레이드’는 이미지 공급망 전반에 걸쳐 적용되어야 합니다. 기본 레이어가 각 이미지에 내장되어 있기 때문에, 지원을 재개하려면 영향을 받는 서비스 전반에 걸쳐 재빌드, 스캔, 검증 및 재배포를 조율하여 수행해야 합니다. AL2 베이스 이미지를 사용하여 ECS 또는 EKS 워크로드를 운영하는 팀들은 곧 다가올 Amazon Linux 2의 지원 종료와 관련하여 동일한 과제에 직면하게 됩니다.

기본 이미지 공급망 문제

컨테이너 이미지는 계층적 구조로 이루어져 있으며, 일반적으로 Alpine 릴리스인 베이스 레이어는 OS 레이어와 그 위에 번들로 포함된 수많은 시스템 패키지의 기반이 됩니다. 해당 베이스 레이어의 지원 기간이 종료되면 Alpine은 해당 릴리스 브랜치에 대한 업스트림 보안 패치 제공을 중단하므로, 지원되는 베이스(또는 확장 지원 소스)로 전환하지 않는 한 OS 레이어와 apk로 설치된 패키지는 더 이상 공식 업데이트를 받을 수 없습니다.

더 중요한 점은, 조직들이 단 하나의 이미지만 운영하는 것이 아니라는 사실입니다. 일반적인 클라우드 네이티브 환경에서는 수십 개에서 수백 개의 컨테이너화된 서비스가 실행되며, 이들 중 상당수는 동일한 Alpine 기본 이미지 버전을 공유합니다. 해당 버전의 지원이 종료되면, 대응 조치는 일상적인 플릿 패치 작업에서 체계적인 이미지 갱신 작업으로 전환됩니다. 즉, 업데이트된 이미지를 재빌드하고, 스캔하고, 테스트한 뒤 영향을 받는 서비스 전반에 배포해야 합니다.

다양한 서비스를 운영하는 조직의 경우, 베이스 이미지의 버전이 한 번 변경되는 것만으로도 여러 팀과 파이프라인 전반에 파급 효과가 발생할 수 있습니다. 이는 광범위한 품질 보증(QA) 작업, 베이스 이미지 위에 구축된 모든 애플리케이션 계층에 대한 호환성 점검, 재빌드된 이미지의 취약점 재검토, 그리고 개발, 스테이징, 프로덕션 환경을 거쳐 신중하게 단계적으로 진행되는 롤아웃을 유발하며, 이는 종종 규정 준수 기한이라는 시간적 압박 속에서 이루어집니다.

Alpine Linux 지원 종료 이후의 보안 및 규정 준수 위험

Alpine 버전이 지원 종료(EOL) 단계에 도달하면, 업스트림 프로젝트는 해당 버전에 대한 보안 수정 사항의 배포를 중단합니다. 그 이후에 발견되는 취약점(musl libc, BusyBox, apk 패키지 관리자 또는 베이스 이미지의 기타 구성 요소에서 발견된 취약점 포함)에 대해서는 공식 패치가 제공되지 않습니다.

PCI DSS(요구사항 6.3.3)는 중요 및 고위험 패치를 패치 출시 후 1개월 이내에 설치할 것을 요구합니다. SOC 2 감사인은 운영 환경에서 지원 종료된 소프트웨어가 있는지 철저히 조사합니다. 패치가 적용되지 않은 지원 종료 컨테이너 이미지를 사용하면 문서화 상의 누락이 발생하게 되며, 이는 보안 설문조사에서 드러나 인증 절차를 지연시키고, 규제 산업에서는 고객 계약 갱신을 가로막는 심각한 장애 요인이 됩니다.

CVE 기록: 취약점 기록이 보여주는 것

알파인(Alpine) 고유의 CVE 노출 범위는 더 복잡한 배포판에 비해 좁은 편입니다. 이러한 최소한의 설계는 진정한 보안상의 이점입니다. 하지만 노출 범위가 작다고 해서 취약점이 전혀 없다는 뜻은 아니며, 지원 종료 시점이 다가옴에 따라 상황은 크게 달라집니다.

Alpine의 역사에서 발견된 두 가지 중대한 취약점이 이를 명확히 보여줍니다:

CVE-2021-36159 (CVSS 3.1: 9.1, 중요): apk-tools의 libfetch 구성 요소에서 FTP 및 HTTP 프로토콜의 숫자 문자열을 잘못 처리하여 발생하는 범위를 벗어난 읽기 취약점입니다. 이 취약점은 패키지 검색 중, 특히 apk 업데이트 중, 또는 apk 설치 작업 중에 악의적인 서버에 의해 유발될 수 있습니다. 이 문제는 여러 Alpine 브랜치에 동시에 영향을 미쳤으며, 해결을 위해 조정된 패치 릴리스가 필요했습니다.

CVE-2019-5021 (CVSS 3.1: 9.8, 중요): 버전 3.3부터 공식 Alpine Docker 이미지에서 루트 사용자의 비밀번호가 null로 노출되는 문제가 발생했습니다. 이는 2015년 12월에 도입된 회귀 오류로, 수년 동안 발견되지 않았습니다. shadow 또는 Linux-PAM 패키지가 설치된 이미지에서는 셸 액세스 권한을 가진 비루트 사용자라면 누구나 컨테이너의 완전한 루트 권한으로 권한을 상승시킬 수 있었으며, 이 권한 상승 경로로 인해 Alpine 기반 컨테이너 배포 환경을 운영하는 NetApp, F5 등의 업체에서 보안 권고문을 발표했습니다.

이는 예외적인 사례가 아닙니다. 이는 바로 기반 구성 요소에 존재하는 ‘중대(critical)’ 등급의 취약점 유형으로, 널리 사용되는 이미지 버전에 영향을 미치며, 해결을 위해 베이스 이미지 업데이트가 필요하지만, Alpine Linux의 지원 종료(EOL) 릴리스에서는 영구적으로 패치되지 않은 상태로 남게 됩니다. 지원 기간이 종료되면 심각도에 관계없이 공식적인 수정 프로그램이 제공되지 않습니다.

보안 유지 및 규정 준수 방안

컨테이너 기반 이미지에서 지원 종료된 Alpine 버전을 운영 중인 조직은 두 가지 선택지를 고려할 수 있습니다. 첫 번째 방법은 상당한 노력과 업무 중단, 운영상의 위험을 수반합니다. 두 번째 방법인 TuxCare의 ‘Endless Lifecycle Support’는 업무 중단 없이 보안 취약점을 즉시 해소해 주는 솔루션입니다.

옵션 1: 최신 Alpine 버전으로 업그레이드

장기적인 해결책은 베이스 이미지의 Alpine 버전을 업데이트하고, 이를 기반으로 영향을 받는 모든 컨테이너 이미지를 다시 빌드하는 것입니다. 현재 적극적으로 지원되는 버전에는 Alpine 3.21부터 3.23까지가 포함되며, 각 버전은 수년에 걸친 지원 기간을 제공하여 조직이 Alpine Linux의 지원 종료로 인한 위험에 노출되는 것을 방지할 수 있도록 돕습니다.

실제로는 단순히 ‘찾기 및 바꾸기’로 해결될 문제가 아닙니다. 새로운 기본 버전을 기반으로 재구축하려면 애플리케이션 계층의 모든 패키지가 새로운 Alpine 릴리스와 호환되는지 확인해야 합니다. 패키지 이름, 버전, 사용 가능 여부는 릴리스마다 달라집니다. 이를 위해서는 모든 이미지를 처음부터 다시 빌드하고, 애플리케이션 계층 전반에 걸쳐 전체 회귀 테스트를 수행하며, 재빌드된 모든 이미지에 대해 취약점 검사를 다시 실시하고, 스테이징 환경에서 동작을 검증한 뒤, 프로덕션 인프라 전반에 걸쳐 조율된 롤아웃을 실행해야 합니다.

수십 개의 서비스를 운영하는 조직의 경우, 이는 수십 번의 재빌드 및 테스트 주기를 의미하며, 공유되는 기본 이미지나 라이브러리로 인해 서비스 간 순서 의존성이 발생하는 제약 조건도 수반됩니다. 이를 잘 관리하는 팀은 사전에 계획을 수립하고 이를 별도의 프로젝트로 취급합니다. 반면, Alpine Linux의 지원 종료(EOL) 시한으로 인해 어쩔 수 없이 이 작업을 수행해야 하는 팀에게는 그런 여유가 없습니다.

옵션 2: TuxCare 확장 라이프사이클 지원: 권장 경로

이것이 바로 모든 것을 바꿔놓을 선택지입니다. Alpine Linux의 단종(EOL) 소프트웨어 보안을 전문으로 하는 기업들이 제공하는 확장 지원 서비스입니다.

TuxCare의 Alpine Linux용 ‘무기한 라이프사이클 지원’은 바로 이러한 상황을 위해 특별히 설계되었습니다. 준비가 되지 않은 상태에서 성급하게 업그레이드를 진행할 필요 없이, 기존 툴체인을 통해 제공되는 핵심 Alpine 패키지에 대한 지속적인 보안 패치 지원을 받으면서도 이미지 재빌드 없이 현재 사용 중인 Alpine 기반 이미지를 프로덕션 환경에서 계속 운영할 수 있습니다.

보안 취약점은 즉시 해소됩니다. 규정 준수 상태는 유지됩니다. 팀은 긴급 대응이 아닌 통제된 프로젝트로서 운영상 타당한 일정에 따라 적절한 업그레이드 계획을 자유롭게 수립할 수 있습니다. 파이프라인 중단도, 마감 기한 압박에 따른 강제 마이그레이션도, 운영 환경에서의 호환성 문제도 발생하지 않습니다.

이는 단순히 시간을 벌기 위한 조치가 아닙니다. 엔터프라이즈급 보안과 규정 준수를 유지하면서 업그레이드 로드맵에 대한 주도권을 확보하는 것입니다.

베이스 이미지 업그레이드를 서두를 때의 위험성

보안 대시보드에 Alpine Linux의 EOL(지원 종료) 알림이 표시되고 규정 준수 팀에서 질문을 시작하면, 즉각적인 조치를 취해야 한다는 압박감이 실감 나게 느껴집니다. 하지만 서둘러 베이스 이미지를 업그레이드하는 것이 실제로 무엇을 의미하는지 파악하는 것은, 보안 취약점 자체를 이해하는 것만큼이나 중요합니다.

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

팀들이 마감 기한의 압박 속에서 이 작업을 서둘러 처리할 때, 그 결과는 뻔합니다:

호환성 문제: 철저한 테스트를 거쳤다면 발견되었을 문제들이 생산 환경으로 유입됩니다. 재빌드 과정에서 업데이트된 패키지가 새로운 문제를 유발하여 재빌드된 이미지가 취약점 검사에서 실패합니다. 배포 속도가 지원 팀이 드러나는 문제를 파악하고 대응할 수 있는 속도를 앞지릅니다.

지원 업무량 증가: 테스트 과정에서 발견되지 않은 버그가 실제 운영 환경에 나타납니다. 지원 대기열은 비정상적인 동작에 대한 보고서로 가득 차게 되며, 그 중 상당수는 이번 업그레이드와 관련이 있습니다.

시스템 불안정성: 베이스 레이어 구성 요소의 미묘한 동작 변화는 디버깅이나 재현이 어려운 간헐적인 오류를 유발할 수 있습니다. 이러한 현상은 사전 운영 환경이 아닌 실제 운영 부하 상황에서 나타납니다.

기술 부채의 누적: 시간적 압박 속에서 적용된 임시 방편이 영구적인 해결책으로 굳어집니다. “나중에 제대로 고치자”는 것이 관행이 되면서, 원래의 수명 종료 문제보다 더 큰 혼란을 초래하게 됩니다.

예상치 못한 비용: 긴급 엔지니어링 업무 시간, 기능 출시 지연, 그리고 시니어 엔지니어들이 새로운 기능을 개발하는 대신 호환성 문제를 해결하는 데 소요되는 기회 비용이 빠르게 누적됩니다.

간편한 해결책: Alpine Linux 단종(EOL)을 위한 TuxCare ELS

바로 이 점에서 TuxCare의 Alpine Linux용 ‘무한 라이프사이클 지원’이 판도를 완전히 바꿔놓습니다.

TuxCare는 지원 종료(EOL)된 Alpine Linux 버전에 대해 ‘무제한 라이프사이클 지원’을 제공합니다. 팀이 아직 준비되지 않은 베이스 이미지 업그레이드를 강제로 진행할 필요 없이, 기존 툴체인을 통해 지속적으로 제공되는 보안 패치를 활용하여 현재 사용 중인 Alpine 기반 컨테이너 이미지를 계속 운영할 수 있습니다.

TuxCare는 지난 10년 넘게 지원이 종료된 운영 체제, 런타임, 라이브러리 및 애플리케이션에 대한 보안 패치를 제공해 왔습니다. 이들은 오픈소스 생태계 전반에 걸쳐 22만 개 이상의 보안 패치를 배포했습니다. 지원이 종료된 소프트웨어를 기업 규모로 안전하게 유지하는 방법을 안다고 말할 때, 이는 단순한 마케팅 수사가 아닙니다. 이들은 실제로 대규모로 이를 실현해 왔습니다.

TuxCare의 접근 방식이 다른 점은 무엇인가요?

정교하고 자동화된 패치 적용 프로세스: TuxCare는 NVD, 벤더 보안 권고 사항, Alpine 자체 보안 트래커, GitHub 보안 피드 등 Alpine Linux EOL 취약점이 공개되는 모든 채널을 모니터링합니다. CVE가 등록되면 알고리즘 기반 도구와 AI 지원 자동화 시스템이 지원되는 버전으로 보안 수정 사항을 백포트하며, 보안 전문가들이 배포 전 모든 패치를 검증합니다. 모든 업데이트는 사용자의 저장소에 도달하기 전에 무결성, 기능 및 회귀 테스트를 거칩니다.

이 과정이 내부적으로 정확히 어떻게 작동하는지 알고 싶다면 다음을 확인해 보세요 TuxCare의 오픈 소스 패치 프로세스에 관한 기술 백서를를 확인해 보세요. 기술 문서치고는 의외로 읽기 쉽습니다.

원활한 통합: TuxCare의 ELS 패키지는 Alpine APK 패키지 생태계와 직접 연동됩니다. 컨테이너 빌드 파이프라인, CI/CD 워크플로우, 팀의 업무 방식에 아무런 변경이 필요하지 않습니다. 현재 컨테이너 빌드 프로세스나 자동 업데이트 흐름을 통해 Alpine 패키지를 사용하고 계시더라도, 기존 워크플로우를 최소한으로만 변경하여 업데이트 소스를 TuxCare의 보안 저장소로 전환할 수 있습니다. 업데이트는 표준 패키지 메커니즘을 통해 제공되며, 기존 도구 및 오케스트레이션과 호환됩니다.

SLA 기반 신속 대응: apk-tools나 musl libc와 같은 핵심 패키지의 중대한 문제를 포함하여 Alpine Linux EOL 구성 요소에서 새로운 취약점이 공개될 경우, TuxCare는 서비스 수준 계약(SLA)에 따라 보장된 일정 내에 패치를 제공합니다. 심각도 높음 및 중대(CVSS 7+) 등급의 취약점은 공개 후 14일 이내에 해결됩니다. 결코 나오지 않을지도 모르는 커뮤니티 백포트를 기다릴 필요가 없습니다. 고객은 취약점 분류 및 문제 해결을 위한 연중무휴 전문가 지원을 통해, 운영 환경에 바로 적용 가능한 업데이트를 받아 계획을 수립할 수 있습니다.

개발 속도 유지: 컨테이너의 핵심 가치는 소프트웨어 배포에 제공하는 속도와 일관성입니다. 관리가 되지 않는 Alpine Linux EOL(지원 종료) 기본 이미지는 배포 속도를 저해하는 긴급 재빌드 주기를 강요하거나, 패치되지 않은 상태로 노출되어 규정 준수 위험을 초래할 수 있습니다. TuxCare ELS는 갑작스러운 업그레이드 단절을 해소하여, 팀이 컨테이너의 가치를 높이는 배포 속도를 유지하면서 주요 기본 이미지 업그레이드를 자체 일정에 따라 계획적이고 위험이 낮은 프로젝트로 진행할 수 있도록 지원합니다.

비용 효율적인 보안 연속성: TuxCare ELS의 비용은 규정 준수 기한으로 인해 어쩔 수 없이 진행해야 하는 긴급 재구축 및 재배포 주기의 비용에 비해 극히 일부에 불과합니다. 컨테이너 워크로드의 기반이 되는 Alpine의 보안을 저해하지 않으면서도 긴급 마이그레이션 횟수를 줄이고, 운영 위험을 최소화하며, 보다 예측 가능한 릴리스 계획을 수립할 수 있습니다.

시작하는 방법

Alpine Linux EOL 버전에서 정확히 어떤 취약점이 해결되었는지 확인하려면, TuxCare에서 실시간 CVE 추적기 이곳에서 특정 버전을 조회하여 어떤 취약점이 패치되었는지 확인할 수 있습니다.

더 자세한 내용을 원하시나요? TuxCare의 ‘Alpine Linux를 위한 무제한 라이프사이클 지원’ 페이지를 방문하시면 지원되는 버전, 가격, 그리고 실제 구현 방식에 대한 정보를 확인하실 수 있습니다.

Alpine Linux의 지원 종료로 인해 컨테이너 워크로드가 위험에 처하지 않도록 하세요

Alpine 기본 이미지의 지원이 종료되면, 문제는 단순히 운영 체제가 구식이 된다는 데 그치지 않습니다. 이는 컨테이너 인프라가 의존하는 보안 지원이 단절된다는 것을 의미합니다. 이 문제를 방치할 경우, 보안 공백은 곧바로 규정 준수 문제로 이어지고, 취약점이 노출되며, 마감 기한 내에 프로덕션 이미지를 재구축해야 하는 압박으로 이어질 수 있습니다.

하지만 Alpine Linux의 지원 종료(EOL)가 반드시 컨테이너 환경 전반에 걸친 긴급 재구축을 유발해야 하는 것은 아닙니다. 이를 잘 관리하는 팀들은 이를 긴급 대응이 아닌 계획적인 결정으로 다룹니다. 이들은 지원 기간이 갑자기 종료될 때가 아니라, 변경 사항이 아키텍처, 테스트 역량, 릴리스 일정에 부합할 때 베이스 이미지를 업그레이드합니다.

TuxCare의 ‘무한 라이프사이클 지원(ELS)’은 이러한 체계적인 접근 방식을 가능하게 합니다. ELS는 지원 종료된 Alpine 버전에 대한 보안 패치를 지속적으로 제공함으로써 컨테이너 기반을 안전하게 보호하는 동시에, 엔지니어링 팀이 업그레이드를 적절히 계획할 수 있는 시간과 안정성을 확보해 줍니다.

위험한 마이그레이션을 서두르거나 컨테이너를 무방비 상태로 방치하는 대신, 보안과 규정 준수, 운영 안정성을 유지하면서 개발 팀이 소프트웨어 출시에만 집중할 수 있도록 합니다.

Alpine Linux의 지원 종료(EOL) 일정이 궁금하시다면 다음을 방문해 보세요 TuxCare의 Alpine Linux용 Endless Lifecycle Support 를 방문하여, 확장된 지원이 필요한 기간 동안 컨테이너 기반을 어떻게 보호해 줄 수 있는지 확인해 보세요.

요약