MariaDB 10.6, 2026년 7월 6일 지원 종료: 그 의미와 보안 유지 방법

주요 요점

• MariaDB Community Server 10.6은 2026년 7월 6일에 지원 종료됩니다. 해당 날짜 이후, MariaDB 프로젝트는 10.6 버전에 대한 보안 패치 및 버그 수정 사항의 제공을 중단합니다.
• 패치가 적용되지 않은 데이터베이스를 운영 환경에 가동하는 것은 보안 및 규정 준수상의 문제입니다. PCI DSS, HIPAA, SOC 2, FedRAMP 등 모든 규정은 알려진 취약점에 대해 적시에 패치를 적용할 것을 요구합니다.
• 11.4 또는 11.8 LTS로 업그레이드하는 것은 원활하게 진행할 수 있다면 장기적으로 올바른 선택입니다. 일정이 촉박할 때는, MariaDB용 TuxCare Endless Lifecycle Support 는 10.6 버전에 패치를 지속적으로 제공하므로, 고객님의 일정에 맞춰 업그레이드할 수 있습니다.

실제 운영 환경에서 MariaDB Community Server 10.6을 사용 중이라면, 달력에 꼭 표시해 두어야 할 날짜가 있습니다: 2026년 7월 6일입니다. 이 날은 10.6 브랜치의 지원 종료일이며, MariaDB 프로젝트에서 해당 브랜치를 종료하는 날입니다. 그 이후로는 해당 브랜치에 대한 릴리스, 버그 수정 및 보안 패치 제공이 중단됩니다.

7월 6일이 지나면 데이터베이스는 전날과 똑같이 쿼리를 처리할 것입니다. 문제는 그 이후 몇 달 동안 내부에서 벌어지는 상황입니다. 새로운 취약점이 발견되지만 패치되지 않고, 감사관들이 의문을 제기하기 시작하며, 10.6을 둘러싼 생태계는 조용히 다음 단계로 넘어가기 때문입니다.

이 글에서는 10.6 버전의 지원 일정을 비롯해, 지원 종료가 여러분의 환경에 실제로 어떤 변화를 가져오는지, 그리고 현실적으로 고려할 수 있는 선택지들에 대해 다룹니다. 만약 “그냥 업그레이드하면 된다”는 식의 간단한 답변을 원하신다면, 이 글은 그런 내용을 다루지 않습니다. 운영 중인 데이터베이스를 업그레이드하는 일은 겉보기만큼 간단하지 않은 경우가 많으며, 이 글의 목적은 여러분이 자신의 상황에 맞는 해결 방안을 선택할 수 있도록 돕는 데 있습니다.

그림 1. MariaDB LTS 릴리스 및 해당 버전의 커뮤니티 지원 종료일. 10.6 버전이 다음으로 지원이 종료됩니다.

MariaDB 버전 및 수명 주기: 간략히

MariaDB는 두 가지 유형의 릴리스를 제공합니다. 롤링 릴리스는 대략 분기마다 출시되며, 다음 릴리스가 나올 때까지만 지원됩니다. 장기 지원(LTS) 릴리스는 약 1년에 한 번 출시되며, 버그 및 보안 수정 사항이 포함된 더 긴 유지보수 기간을 제공합니다. 실제 운영 환경에서는 LTS 릴리스를 사용해야 합니다.

MariaDB 10.6은 LTS(장기 지원) 릴리스입니다. 이 버전은 2021년 7월 6일에 처음 출시되었으며, 5년의 유지보수 기간이 적용되어 2026년 7월 6일에 지원이 종료됩니다. 이후 MariaDB는 11.8 버전부터 Community Server를 3년의 유지보수 기간이 적용되는 연간 LTS 모델로 전환했습니다(11.4 버전은 여전히 5년 LTS로 유지됩니다). 2026년 6월 현재 최근 LTS 릴리스의 현황은 다음과 같습니다:

두 가지 점이 눈에 띕니다. 첫째, 10.4와 10.5는 이미 지원 종료 시점을 지났고, 10.6이 그 다음 차례이므로 10.x 계열의 대부분은 지원 기간이 끝났습니다. 2028년 2월까지 지원되는 10.11 LTS만이 유일한 예외입니다.  둘째, 지원되는 LTS 버전은 10.11(2028년 2월까지), 11.4(2029년 5월까지), 11.8(2028년 6월까지), 그리고 12.3(최신 LTS, 2029년까지)입니다. 10.6에서 전환하는 팀의 경우, 10.11은 호환성 측면에서 가장 작은 단계이지만 지원 기간이 가장 짧으며, 11.4와 12.3은 가장 긴 지원 기간을 제공하므로 대부분의 업그레이드 논의가 이 두 버전으로 집중됩니다.

MariaDB 10.6의 지원 종료 후에는 어떻게 되나요?

지원 종료는 모든 유지보수 작업이 중단됨을 의미합니다. MariaDB 10.6의 경우, 이로 인해 시간이 지남에 따라 점점 더 심각해지는 세 가지 문제가 발생합니다:

1. 보안 패치 배포 중단

이것이 진짜 문제입니다. 2026년 7월 6일 이후에는 MariaDB Community Server에 영향을 미치는 취약점이 지원되는 커뮤니티 브랜치에서만 수정될 예정이며, 10.6 Community Server는 더 이상 해당 수정 사항을 제공받지 못하게 됩니다. 데이터베이스 엔진은 매우 중요한 대상입니다. 데이터를 보관하고 있으며, 애플리케이션 서버에서 접근할 수 있는 경우가 많기 때문에, 단 하나의 결함만으로도 그 뒤에 있는 모든 것이 노출될 수 있습니다.

지원 종료(EOL) 버전을 대상으로 한 공격 패턴은 이미 잘 알려져 있습니다. 프로젝트에서 지원 중인 버전에 패치를 적용하면 수정 내용이 공개되므로, 공격자는 어떤 코드가 변경되었는지 정확히 파악하고 이를 통해 근본적인 버그를 분석할 수 있습니다. 그런 다음 공격자는 더 이상 패치가 제공되지 않는 EOL 버전에서 동일한 취약점을 찾아냅니다. 자동화 및 AI 기반 분석 기술을 활용하면 이러한 리버스 엔지니어링 과정을 가속화할 수 있어, 공개된 패치와 실제 작동하는 익스플로잇 사이의 시간 차가 급격히 좁혀질 수 있습니다. EOL(지원 종료) 데이터베이스는 바로 이러한 공격 패턴이 효과를 발휘하는 표적입니다. 

2. 규정 준수 및 감사 위험 증가

대부분의 보안 프레임워크는 알려진 문제에 대해 적시에 패치를 적용할 것을 요구합니다. PCI DSS 요구사항 6은 조직이 취약점을 식별하고 위험 등급을 매긴 후 이를 시정할 것을 기대하며, 중대 및 고위험 패치는 출시 후 1개월 이내에 설치해야 합니다(v4.0.1의 6.3.3항). SOC 2 감사인은 지원이 중단된 구성 요소가 해결되지 않은 취약점 관리 또는 변경 관리 위험을 초래할 경우 이를 지적할 수 있습니다. HIPAA 규제 환경의 경우, 지원이 중단된 소프트웨어는 기술적 보호 조치 및 위험 관리 관행이 여전히 합리적인지에 대한 의문을 제기할 수 있습니다. FedRAMP 및 유사한 제도에서는 문서화를 동반한 지속적인 패치 적용을 요구합니다.

가장 답답한 점은, 데이터베이스가 그 외에는 완벽하게 관리된 시스템 환경에서 유일하게 지원 종료(EOL) 상태인 구성 요소일 뿐임에도 불구하고 여전히 감사 지적 사항을 유발할 수 있다는 것입니다. 또한 사이버 보험 심사 과정에서 지원이 중단된 소프트웨어에 대해 면밀히 검토할 수 있으며, 특히 사고 발생이나 갱신 절차 중에 패치 및 취약점 관리에 허점이 드러날 경우 더욱 그러합니다.

3. 생태계가 멀어져 간다

버전이 EOL(지원 종료) 단계에 이르면, 관련 소프트웨어들은 점차 해당 버전에 대한 지원을 중단합니다. 시간이 지남에 따라 리눅스 배포판, 컨테이너 이미지, 타사 저장소 등은 기본 MariaDB 패키지를 지원되는 최신 버전으로 전환하는 경향이 있습니다. 6개월이 지나면 고정된 버전과 임시 해결책이 점점 쌓이게 되고, 미루어 두었던 업그레이드는 쉬워지기는커녕 은연중에 더 어려워지게 됩니다.

그림 2. 데이터베이스의 수명이 다한 후 누적되는 세 가지 위험 영역.

MariaDB 10.6 지원 종료(EOL) 이후에는 어떤 선택지가 있을까요?

최적의 방법은 데이터베이스의 중요도, 감수할 수 있는 운영 부담의 정도, 그리고 현실적인 업그레이드 일정에 따라 달라집니다. 고려해 볼 만한 네 가지 옵션이 있습니다.

그림 3. MariaDB 10.6의 지원 종료 이후의 네 가지 방향과 각 방향의 주요 장단점.

방법 1: 지원되는 LTS 릴리스(10.11, 11.4, 11.8 또는 12.3)로 업그레이드하기

이것은 교과서적인 해법이며, 이를 깔끔하게 실행할 수 있다면 올바른 선택입니다. 지원되는 LTS 릴리스로 전환하면 공식 보안 패치를 다시 적용받을 수 있으며, 대상 버전에 따라 최적화기, JSON 처리, 복제, 운영 도구 등의 분야에서 개선된 기능을 활용할 수 있습니다. MariaDB는 일반적으로 클라이언트-서버 프로토콜 호환성을 유지하지만, 주요 업그레이드 전에는 애플리케이션 동작, SQL 의미론, 복제, 바이너리 로그 형식, 커넥터 버전 및 구성 설정을 반드시 테스트해야 합니다.

문제는 프로덕션 데이터베이스에서 메이저 버전을 업그레이드할 경우 스키마 및 구성 검토, 복제 토폴로지 검증, 새 릴리스에 대한 애플리케이션 동작 테스트, 그리고 다운타임 또는 전환 시간대 계획 수립이 필요하다는 점입니다. MariaDB 11.0에서는 새로운 최적화기 비용 모델이 도입되어 일부 쿼리의 실행 속도가 느려질 수 있으므로, 실제 워크로드를 스테이징 복사본에서 실행하여 실행 계획의 변경 사항을 프로덕션에 반영하기 전에 미리 파악해 두는 것이 좋습니다. 일반적으로 위험이 적은 접근 방식은 실제 트래픽 환경에서 레플리카나 복원된 스테이징 사본을 사용하여 대상 버전을 검증한 후, 정식 배포 전에 전환 및 롤백 경로를 계획하는 것입니다. 정확한 복제 및 배포 전략은 토폴로지와 건너뛰는 메이저 버전 수에 따라 달라지므로, 먼저 지원되는 업그레이드 경로를 확인하십시오. 

옵션 2: MariaDB Enterprise Server로 전환

MariaDB plc는 다음을 통해 지원되는 10.6 버전의 상용 엔터프라이즈 서버 빌드를 판매합니다. 2029년 8월 23일까지까지 지원되며, 이는 커뮤니티 버전의 지원 종료 시점보다 약 3년 더 긴 기간입니다. 여전히 10.6 시리즈를 기반으로 하므로, 이번 조치는 메이저 버전 업그레이드라기보다는 배포판 변경에 가깝고, 엔터프라이즈 기능과 벤더 지원을 추가합니다.

대가로 지불해야 할 비용은 고가의 유료 구독료, 일정 수준의 벤더 종속성, 그리고 커뮤니티 배포판에서 다른 바이너리 배포판으로의 전환입니다. STIG 준수 지원을 제공하는 벤더 지원형 MariaDB Enterprise Server 10.6이 반드시 필요한 팀에게는 합리적인 선택이 될 수 있습니다. 반면, 기존 오픈소스 배포판에 패치를 적용해 유지하는 것이 주된 목표인 팀에게는, 해결해야 할 문제보다 더 큰 변화가 될 수 있습니다.

옵션 3: 자체 유지 관리 또는 포크

원칙적으로 오픈소스 10.6 소스 코드를 가져와 CVE를 직접 추적하고, 수정 사항을 자체 빌드에 백포트할 수 있습니다. 하지만 실제로는 이를 지속적으로 유지하기 어렵습니다. 데이터베이스 보안 백포트를 수행하려면 방대한 C 및 C++ 코드베이스를 정확히 읽고 패치할 수 있으며, 수정 사항을 검증할 수 있는 엔지니어가 필요합니다. 또한, 자신이 원하는 일정이 아니라 새로운 취약점이 발견되는 시점에 맞춰 작업을 수행해야 합니다. 대부분의 팀은 이를 안정적으로 수행할 인력을 확보하기 어렵습니다. 또한, 자원이 절반만 투입된 노력은 오히려 아무런 계획이 없는 것보다 더 나쁠 수 있는데, 이는 보안 범위가 충분히 확보되었다는 잘못된 안도감을 주기 때문입니다.

옵션 4: 무제한 라이프사이클 지원을 통한 강화된 보안

이것이 바로 팀들이 종종 과소평가하는 실용적인 절충안입니다. TuxCare의 MariaDB 무제한 라이프사이클 지원 는 커뮤니티 지원 종료일 이후에도 현재 사용 중인 10.6 배포판에 새로운 취약점에 대한 패치를 지속적으로 제공합니다. TuxCare는 MariaDB의 CVE를 추적하고, 수정 사항을 오픈소스 릴리스에 역포트하여, 사용자가 이미 사용하고 있는 패키지 관리자를 통해 드롭인 패키지 교체 형태로 제공합니다. 애플리케이션을 재작성할 필요가 없으며, 운영 중단을 최소화하면서 기존 복제 및 백업 워크플로를 유지하는 것이 목표입니다.

이 옵션의 핵심은 보안상의 긴급성과 엔지니어링 역량을 분리하는 데 있습니다. 패치는 지속적으로 제공되고 애플리케이션은 계속 가동되며, 팀은 고정된 일정 대신 엔지니어링 현실에 기반한 일정에 따라 업그레이드를 진행합니다. 이 방식은 2026년 7월 6일 이전에 업그레이드를 완료하는 것이 현실적으로 어려울 때, 지속적인 패치 적용을 문서화해야 하는 규정 준수 의무가 있을 때, 또는 배포 환경이 안정적이어서 당장 서둘러 대규모 업그레이드를 진행할 필요가 없을 때 적합합니다.

왜 업그레이드가 항상 즉각적인 해결책은 아닌가

업그레이드는 화이트보드 위에서는 깔끔한 해결책처럼 보입니다. 하지만 현실에서는 몇 가지 이유로 인해 상황이 훨씬 더 복잡해지는데, 이러한 점들은 쉽게 간과되기 쉽습니다.

종종 의존성 및 통합 문제가 진정한 걸림돌이 됩니다. MariaDB 엔진 자체는 업그레이드를 늦추는 경우가 거의 없습니다. 업그레이드를 늦추는 주된 요인은 애플리케이션 코드, 저장 프로시저, 복제 설정, 그리고 주변 도구들인데, 이 모든 요소는 현재 버전의 동작 방식을 전제로 하고 있습니다. 이러한 문제들을 해결하는 데는 시간이 소요되는데, 정해진 EOL(지원 종료) 날짜는 이러한 시간을 고려하지 않습니다.

서둘러 진행하는 업그레이드는 막대한 비용을 초래합니다. 버그가 발생하고, 예외적인 상황을 놓치며, 테스트 과정을 대충 넘기게 됩니다. 그 대가는 다음 분기에 발생하는 사고와 당직 업무량으로 드러나며, 연장 지원 비용을 고려하더라도 느리지만 계획된 업그레이드의 비용보다 더 많이 드는 경우가 많습니다.

일부 시스템의 경우, 당장 그만한 노력을 들일 만한 가치가 없습니다. 교체 예정인 애플리케이션의 백엔드 데이터베이스나, 새로운 기능 추가 계획 없이 고정된 워크로드를 처리하는 데이터베이스의 경우, 올해 대규모 업그레이드를 진행할 필요가 없을 수 있습니다. 이러한 시스템의 경우, 계획된 변경이 이루어질 때까지 현재 버전에 패치를 적용하는 것은 지름길이 아니라 타당한 기술적 판단입니다.

TuxCare를 통해 MariaDB 10.6을 업그레이드 없이 안전하게 관리하세요

MariaDB 10.6의 지원 종료일은 2026년 7월 6일입니다. 이 날짜가 지나면 프로젝트 측에서 더 이상 패치를 제공하지 않으며, 10.6을 계속 실행 중인 모든 호스트에는 새로운 취약점이 누적되기 시작합니다. 지원되는 LTS 릴리스(10.11, 11.4, 11.8 또는 12.3)로 업그레이드하는 것이, 이를 원활하게 그리고 합리적인 기간 내에 수행할 수 있다면 올바른 해결책입니다. 그러나 종속성이 준비되지 않았거나, 기한이 너무 촉박하거나, 배포로 인한 중단이 정당화되지 않아 업그레이드가 불가능한 경우, 확장 지원(Extended Support)을 통해 부적절한 마이그레이션을 강요하지 않으면서도 보안을 유지할 수 있습니다.

MariaDB를 위한 TuxCare의 무한 수명 주기 지원 이 서비스는 EOL(지원 종료)된 MariaDB 릴리스에 대해 지속적인 SLA 기반 보안 패치를 제공함으로써 이러한 격차를 해소하며, 코드 변경 없이 기존 패키지 관리자를 통해 배포됩니다. 귀사의 환경에 어떻게 적용되는지 확인하시려면, TuxCare 전문가와 상담해 보십시오. 목표는 업그레이드 일정을 대체하는 것이 아니라, 귀하가 직접 제어할 수 있도록 돕는 것입니다.

요약

기사 이름

MariaDB 10.6 지원 종료

설명

MariaDB 10.6은 2026년 7월 6일에 지원 종료됩니다. 패치를 적용하지 않고 사용할 경우 발생할 수 있는 위험과 보안을 유지하는 네 가지 방법을 확인해 보세요: TuxCare ELS.

작성자

아르템 카라세프

게시자 이름

TuxCare

게시자 로고