Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

들어가며 — 9.7 다음 버전은 9.8이 아니다
혁신 릴리스는 다음 혁신 릴리스가 나오면 끝난다
MySQL 9.7 LTS — 2년 만의 정박지
9.7이 커뮤니티 에디션으로 넘긴 것
캘린더 버저닝 — YY.M이 알려주는 것
MariaDB는 5주 뒤 같은 일을 했다
갈라지는 지점 하나 — 지원 기간 8년 대 3년
갈라지는 지점 둘 — 릴리스 노트가 안 짚어준 기본값 변경
그래서 뭘 해야 하나
마치며
참고 자료

들어가며 — 9.7 다음 버전은 9.8이 아니다

2026년 7월 현재, MySQL의 다음 혁신 릴리스 버전 번호는 26.7입니다. 오타가 아닙니다.

Oracle은 2026년 6월 16일 A More Predictable MySQL Release Model 글에서 MySQL 버전 번호를 캘린더 버저닝으로 바꾼다고 발표했습니다. 그리고 MySQL 26.7.0 릴리스 노트의 첫 항목이 이걸 확인해 줍니다.

MySQL Server now uses calendar-based versioning for releases after the 9.7 LTS series. Version values use Year.Month.Patch (YY.M.P) format. MySQL 26.7.0 is the first such calendar-version release.

버전 번호가 9.7에서 26.7로 뛴 건 그 자체로는 그냥 표기법입니다. 흥미로운 건 이 변화가 지난 2년간 MySQL 릴리스 모델이 실제로 굴러간 방식의 결론이라는 점이고, 더 흥미로운 건 MariaDB가 5주 간격을 두고 거의 같은 일을 했다는 점입니다. 이 글은 그 두 흐름을 릴리스 노트와 지원 정책 원문까지 확인해 정리합니다.

이 글은 릴리스 모델과 운영 판단에 집중합니다. MariaDB의 내부 구조(스토리지 엔진, Galera, 파티셔닝)는 MariaDB 모던 아키텍처 편에서 따로 다뤘습니다.

혁신 릴리스는 다음 혁신 릴리스가 나오면 끝난다

먼저 2023년에 도입된 Innovation/LTS 모델을 복습해야 합니다. MySQL 9.7 레퍼런스 매뉴얼 1.3절의 문장이 핵심입니다.

Innovation releases are supported until the next Innovation release.

한 문장이지만 운영 관점에서는 꽤 무거운 조건입니다. 혁신 릴리스를 쓰는 동안 당신의 지원 기간은 "다음 릴리스가 나올 때까지"이고, 그다음 지원을 받으려면 업그레이드하는 것 말고 선택지가 없습니다. 패치 릴리스를 기다리는 선택지가 없다는 뜻입니다.

같은 문서는 LTS를 이렇게 구분합니다.

These releases only contain necessary fixes to reduce the risks associated with changes in the database software's behavior. There are no removals within an LTS release.

반대로 혁신 릴리스에 대해서는 이렇게 씁니다.

Apart from new features in innovation releases, behavior changes are also expected as code is refactored, deprecated functionality is removed, and when MySQL is modified to behave more in line with SQL Standards.

"deprecated functionality is removed"가 추상적인 경고가 아니라는 건 9.0이 바로 보여줬습니다. MySQL 9.0.0 릴리스 노트는 mysql_native_password 인증 플러그인이 서버에서 제거됐다고 적고 있습니다. 8.0에서 deprecated였던 게 다음 메이저에서 사라진 것이고, 오래된 클라이언트·커넥터를 물고 있던 조직은 여기서 걸립니다.

그럼 실제로 각 혁신 릴리스는 얼마나 살았을까요. 아래는 Oracle 릴리스 노트 제목에 적힌 GA 날짜를 그대로 옮긴 것입니다. 지원 종료일은 위 규칙에 따라 곧 다음 줄의 GA 날짜입니다.

릴리스	GA (릴리스 노트 기준)	지원 종료 = 다음 혁신 릴리스 GA	실질 수명
9.0.0	2024-07-01	2024-10-15	약 3.5개월
9.1.0	2024-10-15	2025-01-21	약 3개월
9.2.0	2025-01-21	2025-04-15	약 3개월
9.3.0	2025-04-15	2025-07-22	약 3개월
9.4.0	2025-07-22	2025-10-21	3개월
9.5.0	2025-10-21	2026-01-20	3개월
9.6.0	2026-01-20	2026-04-21	3개월
9.7.0 (LTS)	2026-04-21	Premier 2031-04 / Extended 2034-04	8년

2년 동안 일곱 번, 분기마다 한 번씩입니다. 9.x 라인을 프로덕션에서 굴렸다면 분기마다 메이저 업그레이드를 해야 지원 상태를 유지할 수 있었다는 뜻입니다.

여담이지만 9.0.0은 사족이 하나 더 붙습니다. 릴리스 노트 상단에 이렇게 적혀 있습니다 — "This release is no longer available for download. It was removed due to a critical issue that could stop the server from restarting following the creation of a very large number of tables (8001 or more)." 테이블 8001개 이상을 만들면 서버가 재시작되지 않을 수 있는 문제로 9.0.0은 내려가고 9.0.1로 대체됐습니다. 혁신 릴리스가 어떤 트랙인지 보여주는 사례입니다.

그래서 매뉴얼이 혁신 릴리스를 권하는 대상도 솔직합니다 — "developers and DBAs working in fast-paced development environments with high levels of automated tests and modern continuous integration techniques for faster upgrade cycles." 분기마다 메이저 업그레이드를 테스트하고 넘길 수 있는 조직을 말합니다. 대부분의 조직은 여기 해당하지 않고, 해당하지 않는다는 걸 인정하는 게 이 모델을 제대로 쓰는 첫 단추입니다.

MySQL 9.7 LTS — 2년 만의 정박지

MySQL 9.7.0 릴리스 노트의 GA 날짜는 2026-04-21입니다. 직전 LTS인 8.4.0의 GA는 릴리스 노트 기준 2024-04-30이니, LTS 사이 간격은 2년에서 아흐레 모자랍니다.

지원 기간은 Oracle의 Lifetime Support Policy 문서(Effective Date: May 1, 2026)에 표로 박혀 있습니다. 월 단위까지만 적혀 있지만 이게 1차 출처입니다.

릴리스	GA	Premier 종료	Extended 종료	Sustaining
MySQL 8.0	Apr 2018	Apr 2025	Apr 2026	Indefinite
MySQL 8.4	Apr 2024	Apr 2029	Apr 2032	Indefinite
MySQL 9.7	Apr 2026	Apr 2031	Apr 2034	Indefinite

여기서 눈에 걸리는 줄은 8.0입니다. Premier가 2025년 4월에 끝났고 Extended가 2026년 4월에 끝났습니다. Oracle의 EOL 공지 페이지는 이를 "As of April 21, 2026, MySQL 8.0 is covered under Oracle Sustaining Support."라고 적고 있습니다 — 9.7.0 LTS가 GA된 바로 그날입니다. Sustaining Support는 Oracle 용어로 기한은 무기한이지만 새 수정·보안 알림·신규 인증이 따라오지 않는 단계입니다. 즉 2018년부터 인터넷의 상당 부분을 떠받쳐 온 8.0은 이제 실질적으로 정지 상태입니다.

LTS가 주는 것도 매뉴얼에 분명합니다.

Functionality remains the same and data format does not change in an LTS series, therefore in-place upgrades and downgrades are possible within the LTS series.

같은 LTS 라인 안에서는 다운그레이드까지 가능하다는 것, 이게 실무에서 LTS를 고르는 진짜 이유입니다. 롤백 경로가 있는 업그레이드와 없는 업그레이드는 다른 작업입니다.

9.7이 커뮤니티 에디션으로 넘긴 것

9.7 LTS에서 실제로 주목할 변화는 기능 자체보다 에디션 경계선이 움직였다는 쪽입니다. 릴리스 노트가 나열하는, 이전에는 Enterprise 전용이었다가 커뮤니티로 내려온 컴포넌트는 이렇습니다.

Replication Applier Metrics Component
Group Replication Flow Control Statistics Component
Group Replication Resource Manager Component
Group Replication Primary Election Component
Telemetry Component

여기에 더해 릴리스 노트는 두 가지를 더 적습니다 — "The Hypergraph Optimizer is now available in MySQL Community Edition", 그리고 JSON Duality View에 대한 DML(insert/update/delete) 지원이 커뮤니티 서버로 들어왔다는 것입니다.

Telemetry가 커뮤니티로 온 건 운영 팀에게 꽤 큽니다. OpenTelemetry/OTLP로 로그·메트릭·트레이스를 내보낼 수 있다는 뜻이고, 그동안 커뮤니티 에디션에서 MySQL을 나머지 스택과 같은 관측 파이프라인에 태우려면 익스포터를 따로 붙여야 했습니다. Hypergraph 옵티마이저도 복잡한 조인 플랜 탐색에 쓰이는 물건이라 관심 가질 만합니다.

다만 방향이 한쪽만은 아닙니다. 같은 릴리스에서 Dynamic Data Masking은 Enterprise 쪽에 새로 들어갔습니다. Oracle의 9.7 발표 글은 이를 "server-side protection of sensitive data without requiring application changes"로 설명하며, 마스킹 정책을 베이스 테이블 컬럼에 붙여 실행 유저·롤에 따라 원본 또는 마스킹된 값을 돌려주는 기능이라고 적습니다. 커뮤니티에 준 것과 Enterprise에 넣은 것이 같은 릴리스에 함께 있습니다.

이 흐름에는 배경이 있습니다. Percona는 2026년 2월 17일 An Open Letter to Oracle에서 MySQL 거버넌스를 논의하자고 공개 제안했습니다. 이 글은 Oracle이 2025년 가을 MySQL을 OCI로 옮기고 인력을 감축했다고 주장하며 그 규모를 "roughly 50%"로 적고 있는데, 이건 Percona의 주장이고 Oracle이 확인한 수치가 아니므로 그대로 사실로 받아들일 근거는 없습니다. 다만 같은 글이 9.7에 기대한다고 적은 항목들 — 커뮤니티 에디션의 벡터 함수, 기본 활성화된 Hypergraph 옵티마이저, 완전한 DML을 갖춘 JSON Duality, PGO 빌드 — 은 실제로 9.7 릴리스 노트에서 확인됩니다. 그리고 그 글이 여전히 원한다고 적은 항목에 "vector indexes"가 남아 있다는 점도 같이 봐야 공평합니다. Percona의 표현대로 "verification through action, not words"가 판단 기준일 텐데, 에디션 경계선이 실제로 움직였다는 건 최소한 말만은 아니었다는 근거는 됩니다.

캘린더 버저닝 — YY.M이 알려주는 것

이제 26.7로 돌아옵니다. Oracle의 6월 16일 발표 글은 형식을 이렇게 정의합니다.

YY — 연도의 마지막 두 자리
M — 릴리스 월, 앞자리 0 없이 (1월은 1, 4월은 4, 7월은 7, 10월은 10)

글이 제시한 향후 케이던스 예시는 이렇습니다.

26.7   – July 2026 Innovation release
26.10  – October 2026 Innovation release
27.1   – January 2027 Innovation release
27.4   – April 2027 Innovation release
27.7   – July 2027 Innovation release
27.10  – October 2027 Innovation release
28.1   – January 2028 Innovation release
28.4   – April 2028 LTS release
28.7   – July 2028 Innovation release

LTS의 처리 방식이 이 설계의 핵심입니다. LTS로 지정된 라인은 수명 내내 그 YY.M 접두사를 유지합니다 — 28.4.0 → 28.4.X → 28.4.Y → 28.4.Z 식이라, 2030년에 28.4.10을 보더라도 "2028년 4월에 시작한 LTS 라인"임을 번호만 보고 알 수 있습니다. Oracle의 표현으로는 "This ensures an LTS line retains the identity of exactly when it started."

여기서 실무자가 읽어야 할 진짜 정보는 표기법이 아니라 예시 목록 그 자체입니다. 다음 LTS로 적힌 게 28.4, 즉 2028년 4월입니다. 9.7 LTS가 2026년 4월이니 LTS 간격이 다시 2년이라는 신호입니다. 다만 저 목록의 제목은 "Upcoming Cadence Examples"이고 로드맵 확약이 아니므로, 2028년 4월을 계약처럼 받아들이진 마십시오. 그래도 planning 관점에서 읽을 수 있는 메시지는 분명합니다 — 지금 9.7 LTS에 정박하면 다음 정박지까지 2년쯤 걸립니다.

발표 글은 유지보수 용어도 하나 새로 꺼냅니다. CPU(Critical Patch Update)는 Oracle의 분기 정기 보안 패치 사이클이고, CSPU(Critical Security Patch Update)는 분기 사이에 필요할 때 나가는 표적 보안 업데이트입니다. 글은 CSPU를 "strictly as-needed"라고 못 박으며 매월 의무가 생기는 게 아니라고 명시합니다. 그리고 분기 패키지가 보안 수정만 담는 게 아니라는 점도 짚습니다 — LTS에서는 보안 수정과 버그 수정을, 혁신 릴리스에서는 거기에 새 기능까지 포함합니다.

기존 라인은 어떻게 되나. 발표 글과 표에 따르면 8.4와 9.7 LTS는 영향을 받지 않고 기존 번호 체계를 그대로 유지합니다. 캘린더 버저닝은 9.7 이후의 릴리스부터 적용됩니다.

그리고 26.7.0 자체에 대해 한 가지 정확히 해 둘 게 있습니다. 릴리스 노트 제목은 "Changes in MySQL 26.7.0 (Early Access Release)"입니다. GA가 아니라 Early Access입니다. 새 버전 번호가 붙은 첫 결과물이 프로덕션 릴리스가 아니라는 뜻이니, 26.7이라는 숫자를 봤다고 업그레이드 계획을 세우진 마십시오.

호환성 측면에서 한 가지 배려는 있습니다. 26.7.0은 mysql_version.h에 MYSQL_PREVIOUS_LTS_VERSION("9.7.0")과 MYSQL_PREVIOUS_LTS_VERSION_ID(90700)를 추가했습니다(WL #17310). 버전 번호가 9에서 26으로 뛰면 단순히 숫자를 비교하던 빌드 스크립트와 커넥터가 깨질 수 있는데, 직전 LTS 버전을 헤더에 명시해 계보를 따라갈 수 있게 한 것입니다. 반대로 말하면, 버전 문자열을 파싱하는 코드를 갖고 있다면 지금 한 번 열어볼 이유가 생겼습니다.

MariaDB는 5주 뒤 같은 일을 했다

여기서 재미있는 건 MariaDB가 사실상 같은 구조를 독립적으로 운영하고 있다는 점입니다.

MariaDB Foundation의 12.3 LTS 발표는 2026년 5월 29일자입니다. MySQL 9.7 LTS로부터 5주 뒤입니다. 발표문은 "The first GA of the 12.3 series is 12.3.2"라고 적습니다 — MariaDB에서는 .2가 첫 GA입니다(.0이 preview, .1이 RC).

그 앞의 12.0, 12.1, 12.2는 롤링 릴리스였습니다. MariaDB 릴리스 모델 문서의 문장이 Oracle의 규칙과 거의 판박이입니다.

There are no patch version releases of an innovation release after GA (except for emergency releases), instead users are supposed to upgrade to the next minor innovation release. In other words, innovation releases are rolling releases, one upgrades 11.3.2→11.4.2→11.5.2→11.6.2→11.7.2

같은 문서는 "Approximately every fourth innovation release is a long-term support (LTS) release"라고 적고, MariaDB Foundation의 유지보수 정책은 "A new long-term release (LTS) of MariaDB Server is announced yearly"라고 적습니다. 분기마다 롤링, 연 1회 LTS입니다.

정리하면 두 진영의 구조는 이렇게 겹칩니다.

MySQL    : 분기마다 Innovation  -> 약 2년마다 LTS   (다음 Innovation 나오면 지원 종료)
MariaDB  : 분기마다 Rolling     -> 매년 LTS        (다음 Rolling 나오면 지원 종료)

경쟁하는 두 구현이 같은 결론에 도달했다는 건, 이게 마케팅이 아니라 "메이저 DB를 오픈소스로 유지보수하려면 이 방법밖에 없다"는 공학적 수렴에 가깝다는 뜻입니다. 빠른 트랙과 느린 트랙을 분리하고, 빠른 트랙에는 장기 지원을 약속하지 않는 것입니다.

갈라지는 지점 하나 — 지원 기간 8년 대 3년

구조가 같으니 이제 진짜 차이가 보입니다. LTS를 골랐을 때 몇 년을 버틸 수 있느냐가 완전히 다릅니다.

MySQL 매뉴얼은 이렇게 적습니다.

An LTS series follows the Oracle Lifetime Support Policy, which includes 5 years of premier support and 3 years of extended support.

5 + 3 = 8년입니다. 앞서 본 Lifetime Support 표의 9.7 줄(Premier Apr 2031, Extended Apr 2034)이 정확히 이 계산입니다.

MariaDB Foundation의 유지보수 정책은 다릅니다.

MariaDB Community LTS binaries are released for 3 years after the GA date on mariadb.org/download

각주까지 읽어야 그림이 완성됩니다. 각주 2는 "For releases up to MariaDB 11.4, the binaries are released for 5 years after the GA date"라고 적고 있습니다. 즉 커뮤니티 LTS 바이너리 지원이 11.4까지는 5년이었는데 그 이후로 3년으로 줄었습니다. 각주 1은 완충을 하나 답니다 — "Critical and security fixes will be provided in source code releases for 2 additional years beyond Community LTS binary release period." 바이너리는 3년이지만 치명적·보안 수정은 소스 릴리스로 2년 더 나온다는 뜻입니다. 직접 빌드할 수 있다면 유효 기간이 5년이고, 배포판 패키지에 의존한다면 3년입니다. 이 구분은 실무에서 큽니다.

돈을 내면 달라집니다. 같은 정책 문서는 Enterprise 바이너리에 대해 "an extended release option maintained and supported for 5 and 8 years, respectively, after the GA date"라고 적습니다.

	MySQL 9.7 LTS	MariaDB 12.3 LTS
무료로 받는 지원	Premier 5년 + Extended 3년 = 8년	커뮤니티 바이너리 3년 (+ 소스 한정 치명적/보안 수정 2년)
유료 확장	Sustaining(무기한, 새 수정 없음)	Enterprise 5년 / Extended 8년

한 줄 요약하면, 커뮤니티 에디션만 쓰는 조직에게 MySQL LTS는 8년을 주고 MariaDB LTS는 3년을 줍니다. "둘 다 오픈소스 MySQL 호환 DB"라는 말이 가리는 가장 실무적인 차이가 여기입니다.

공정하게 덧붙이면 MariaDB의 LTS는 매년 나오므로 정박지 자체가 자주 옵니다. 8년마다 한 번 크게 넘느냐, 3년마다 작게 넘느냐의 차이에 가깝습니다. 어느 쪽이 싼지는 조직의 업그레이드 근육에 달렸습니다.

한 가지 주의: MariaDB Foundation의 유지보수 정책 표에서 12.3의 GA 날짜와 EOL은 이 글을 쓰는 시점에 아직 TBC로 비어 있습니다. 그래서 12.3의 정확한 EOL 날짜를 여기 적지 않았습니다. 3년이라는 건 정책 문장이고, 날짜가 확정되면 그 표가 1차 출처입니다.

갈라지는 지점 둘 — 릴리스 노트가 안 짚어준 기본값 변경

12.3 LTS 발표문에는 "Important"로 표시된 항목이 딱 하나 있습니다.

In MariaDB 12.3, innodb_snapshot_isolation defaults to ON

그리고 이렇게 덧붙입니다 — "There probably is no better moment than when we release a new LTS."

이게 무슨 기능인지부터. MariaDB InnoDB 시스템 변수 문서에 따르면 innodb_snapshot_isolation은 InnoDB 안에서 write/write 충돌을 검출하는 스위치입니다. 켜져 있으면 현재 read view에 존재하지 않는 레코드에 락을 잡으려 할 때 ER_CHECKREAD(에러 1020)가 발생하고, 이 에러는 데드락과 같은 방식으로 처리되어 트랜잭션이 롤백됩니다. 기본 격리 수준인 REPEATABLE READ에 영향을 줍니다. 문서의 표현으로는 lost update 같은 이상 현상을 막기 위해, 스냅샷 이후 동시 트랜잭션이 수정한 행에 대한 UPDATE/DELETE를 거부하는 설계입니다.

정확성 면에서는 옳은 방향입니다. 문제는 애플리케이션이 이걸 모른다는 것입니다. 어제까지 조용히 성공하던 UPDATE가 이제 에러 1020으로 롤백되고, 재시도 로직이 없으면 그대로 실패로 올라옵니다. LTS 업그레이드에서 만나고 싶지 않은 종류의 변화입니다.

그런데 여기서 문서와 발표문이 어긋납니다. 같은 시스템 변수 문서는 기본값을 이렇게 적습니다.

Default Value: ON (>= MariaDB 11.6.2), OFF (<= MariaDB 11.6.1)

12.3이 아니라 11.6.2부터 ON이라는 겁니다. 어느 쪽이 맞는지는 소스를 보면 끝납니다. storage/innobase/handler/ha_innodb.cc에서 이 변수의 기본값 인자를 브랜치별로 확인해 보면 이렇습니다.

MariaDB/server 브랜치별 innodb_snapshot_isolation 기본값
  11.4  -> FALSE
  11.5  -> FALSE
  11.6  -> TRUE
  11.7  -> TRUE
  11.8  -> TRUE
  12.2  -> TRUE
  12.3  -> TRUE
  main  -> TRUE

문서 쪽이 맞습니다. 기본값은 11.6에서 뒤집혔고, 12.3에서 바뀐 게 아닙니다.

그래서 LTS만 따라가는 사람 입장에서 실제 그림은 이렇습니다.

11.4 LTS (OFF)  ->  11.8 LTS (ON)  ->  12.3 LTS (ON)
                     ^^^ 여기서 이미 바뀌었음

즉 이 변경은 11.8 LTS에서 이미 적용된 상태로 나갔습니다. 그리고 11.8 LTS 발표문에는 snapshot isolation이 한 번도 언급되지 않습니다. 정리하면 이렇습니다.

11.4 → 11.8로 올라간 조직은 이 동작 변경을 맞았는데 발표문에서 안내받지 못했습니다.
11.4 → 12.3으로 건너뛰는 조직은 이제야 안내받습니다. 다만 "12.3에서 바뀐다"는 설명은 정확하지 않습니다.
11.8 → 12.3으로 올라가는 조직에게 이 항목은 사실 변경 사항이 아닙니다. 이미 ON이었으니까요.

발표문을 탓하려는 게 아닙니다. 오히려 늦게라도 크게 표시한 건 잘한 일이고, 11.4 LTS에서 넘어오는 사람에게는 정확히 필요한 경고입니다. 요점은 다른 데 있습니다 — 릴리스 노트의 "이번에 바뀝니다"는 당신의 업그레이드 경로 기준이 아니라 작성자가 상정한 경로 기준으로 쓰입니다. LTS에서 LTS로 두 칸을 건너뛰면, 그 사이 롤링 릴리스에서 조용히 뒤집힌 기본값들이 한꺼번에 도착합니다. 롤링 릴리스를 건너뛰는 건 합리적인 운영 선택이지만, 건너뛴 구간의 변경 로그까지 건너뛰어도 된다는 뜻은 아닙니다.

실무적으로는 LTS 업그레이드 전에 SHOW GLOBAL VARIABLES를 양쪽 버전에서 떠서 diff하는 게, 발표문을 읽는 것보다 확실합니다. 참고로 이 기능은 아직 다듬어지는 중이기도 합니다. MariaDB Jira에는 innodb_snapshot_isolation이 켜진 상태의 락 대기·데드락 관련 이슈(MDEV-40182, MDEV-40092 등)가 2026년에도 10.11 / 11.4 / 11.8 / 12.3을 fix version으로 달고 올라와 있습니다.

그래서 뭘 해야 하나

정리하면 판단은 단순합니다.

MySQL 8.0을 쓰고 있다면 — 지금이 그 시점입니다. Extended Support가 2026년 4월에 끝났고 지금은 Sustaining Support, 즉 새 보안 수정이 나오지 않는 상태입니다. 목적지는 8.4 LTS(Extended 2032년 4월까지) 또는 9.7 LTS(2034년 4월까지)입니다. 9.0에서 mysql_native_password가 제거됐다는 점 때문에 8.0 → 9.7 점프는 클라이언트·커넥터 인증 방식 점검이 선행돼야 합니다. 그 작업을 지금 감당하기 어렵다면 8.4 LTS가 정직한 중간 기착지입니다.

9.x 혁신 릴리스를 쓰고 있다면 — 9.7로 올리고 멈추십시오. 9.0부터 9.6까지는 전부 지원이 끝났습니다. 9.7은 같은 계보의 LTS이고, LTS 라인 안에서는 in-place 업그레이드와 다운그레이드가 모두 가능합니다.

26.7을 프로덕션에 올리지 마십시오. Early Access입니다. 그리고 캘린더 버저닝 발표가 시사하는 다음 LTS는 2028년 4월(28.4)입니다. 지금 9.7에 정박하는 게 맞습니다.

혁신 트랙을 굳이 타야 하나? 대부분은 아닙니다. 분기마다 메이저 업그레이드를 테스트해 넘길 CI와 인력이 있고, 특정 신기능이 사업적으로 필요할 때만 값을 합니다. 그게 아니라면 LTS에 머무는 게 이 모델이 의도한 정상 경로입니다. Oracle 매뉴얼도 그렇게 적고 있습니다.

MariaDB를 쓰고 있다면 — 12.3 LTS가 현재 정박지입니다. 다만 지원 기간을 착각하지 마십시오. 커뮤니티 바이너리는 3년이고(11.4까지의 5년에서 줄었습니다), 그 뒤 2년은 소스 릴리스로만 치명적·보안 수정이 옵니다. 배포판 패키지에 의존한다면 실질 3년으로 계획하는 게 안전합니다. 그리고 11.4 이하에서 올라온다면 innodb_snapshot_isolation이 ON이 된다는 걸 스테이징에서 반드시 확인하십시오 — 에러 1020 재시도 경로가 없는 애플리케이션이라면 여기서 터집니다.

MySQL과 MariaDB 사이에서 고민 중이라면 — 이 글은 그 답을 주지 않습니다. 다만 지원 기간(커뮤니티 8년 대 3년)과 업그레이드 빈도(2년 대 1년)는 기능 비교표에 잘 안 나오는데 운영 비용에는 그대로 반영되는 항목이니, 벤치마크보다 먼저 계산해 볼 값입니다.

마치며

버전 번호가 9.7에서 26.7로 뛴 건 표기법 변경이지만, 그 배경에 있는 이야기는 표기법이 아닙니다.

2024년부터 2026년까지 MySQL은 분기마다 혁신 릴리스를 냈고, 각 릴리스는 다음 게 나오는 순간 지원이 끝났습니다. 그 2년의 결과물이 2026년 4월 21일 9.7 LTS로 묶였고, 같은 달 8.0이 Sustaining Support로 내려가며 한 시대가 닫혔습니다. MariaDB는 5주 뒤 12.3 LTS로 정확히 같은 동작을 했습니다. 경쟁하는 두 구현이 같은 릴리스 구조에 도달했다는 건 우연이 아니라 수렴입니다.

그리고 그 아래에서 진짜 차이는 여전히 갈라져 있습니다. 커뮤니티 에디션 기준 지원 8년과 3년, 에디션 경계선을 커뮤니티 쪽으로 옮기는 Oracle과 커뮤니티 바이너리 지원을 5년에서 3년으로 줄인 MariaDB, 그리고 LTS 사이를 건너뛸 때 조용히 도착하는 기본값 변경들.

캘린더 버저닝은 "이 릴리스가 언제 시작됐는지"를 번호만 보고 알게 해 줍니다. 유용한 개선입니다. 하지만 번호가 알려주지 않는 것 — 그 사이에 무엇이 제거됐고 어떤 기본값이 뒤집혔는지 — 는 여전히 릴리스 노트를 열어야, 때로는 소스를 열어야 나옵니다. 이 글에서 innodb_snapshot_isolation 하나를 확인하는 데 브랜치 일곱 개를 봐야 했던 것처럼요.