MySQL 버전 선택 기준: 5.7·8.0 유지 단계와 8.4·9.7 LTS

2022년 토이 프로젝트의 개발 환경을 정하면서 MySQL 5.7과 8.0의 차이를 찾아봤고, 당시에는 8.0을 선택하는 쪽으로 생각했다. 그 판단 자체는 자연스러웠지만 지금 같은 글을 읽는다면 주의해야 한다. database version의 기본 선택지는 시간이 지나며 바뀌기 때문이다.

2026년 8월 2일 기준으로 MySQL은 LTS와 Innovation 릴리스 모델을 운영한다. MySQL 공식 EOL 공지에서는 5.7이 2023년 10월 25일, 8.0이 2026년 4월 21일부터 Sustaining Support 단계라고 안내한다. 새 프로젝트라면 “익숙한 8.0”을 자동으로 고르기보다 현재 사용할 수 있는 LTS인 8.4 또는 9.7을 먼저 검토해야 한다.

최신 숫자가 가장 큰 version과 production에 가장 적합한 version은 같지 않을 수 있다.

먼저 릴리스 종류를 구분한다

MySQL의 현재 릴리스 모델은 크게 LTS와 Innovation으로 나뉜다.

릴리스 종류	목적	선택할 때의 전제
LTS	안정성과 긴 유지 기간을 중시하는 운영 워크로드	변화 폭을 줄이고 계획적으로 업그레이드하고 싶음
Innovation	최신 기능을 빠르게 사용하고 다음 릴리스로 계속 이동	더 짧은 업그레이드 주기를 감당할 수 있음

2026년에는 버전 표기 체계도 바뀌었다. 공식 설명에 따르면 calendar versioning은 YY.M 형태를 사용한다. 따라서 26.7은 2026년 7월 Innovation 릴리스를 뜻한다. 숫자가 9.7보다 커 보여도 “9.7의 다음 장기 지원 버전”이라는 뜻이 아니다.

공식 26.7 발표는 이를 Early Access Innovation 릴리스로 소개한다. 다운로드 화면의 기본값이나 가장 큰 번호만 보고 운영 환경의 기본 버전으로 선택하면 안 되는 이유다.

2026년 8월 기준 선택지를 읽는 법

버전	현재 위치	새 프로젝트에서의 해석
5.7	Sustaining Support 단계	legacy 호환 목적 외에는 새 기본값으로 삼기 어려움
8.0	Sustaining Support 단계	이미 운영 중인 system의 upgrade 출발점으로 볼 수 있음
8.4	LTS	생태계·관리형 서비스 호환성을 확인할 안정적 후보
9.7	LTS	2026년 4월 공개된 더 최근 LTS 후보
26.7	Early Access Innovation	최신 기능 평가와 테스트 목적, 운영 사용은 지원 정책을 별도 확인

Sustaining Support를 “당장 바이너리가 사라진다” 또는 “어떤 도움도 받을 수 없다”로 단순화해서는 안 된다. Oracle의 지원 단계에는 각각 제공 범위가 있다. 중요한 점은 새 프로젝트의 기본값과 장기간 운영 계획을 과거 버전에 계속 묶지 않는 것이다.

새 프로젝트라면 버전 번호보다 환경을 먼저 본다

로컬에서 설치할 수 있다는 사실만으로 운영 버전 선택이 끝나지 않는다. 다음 제약을 먼저 확인한다.

1. managed database가 지원하는가

AWS RDS, Cloud SQL, Azure Database for MySQL 또는 사내 platform이 제공하는 engine version과 patch 정책을 확인한다. MySQL upstream에서 GA·LTS여도 managed service에는 아직 없거나 지원 일정이 다를 수 있다.

2. connector와 framework가 지원하는가

JDBC 드라이버, ORM, 마이그레이션 도구, CDC 커넥터, 백업 에이전트와 모니터링 exporter가 목표 버전에서 검증됐는지 확인한다. 단순 연결 성공만으로 충분하지 않다.

애플리케이션 프레임워크
  ├─ 커넥터·드라이버
  ├─ ORM·쿼리 생성기
  ├─ 스키마 마이그레이션 도구
  ├─ CDC·복제 consumer
  └─ 백업·모니터링 에이전트
        ↓
     목표 MySQL 버전

3. 운영 기간과 upgrade cadence는 어떤가

짧은 실험이라면 Innovation을 평가할 수 있다. 반면 몇 년간 운영할 서비스라면 LTS를 선택하고 마이너 업데이트, 백업 복원, 다음 LTS 마이그레이션을 정기적으로 연습하는 편이 현실적이다.

4. 필요한 기능이 실제로 있는가

“새 버전이 더 빠르다”는 포괄적 문장으로 결정하지 않는다. 워크로드, 스키마, 쿼리, 격리 수준, 연결 패턴이 다르면 결과도 다르다. 특정 기능 때문에 버전을 올린다면 그 기능이 애플리케이션 문제를 해결하는지 벤치마크와 호환성 테스트로 확인해야 한다.

현재 기준의 실용적인 결정 흐름

새 application이라면 다음 순서로 좁힐 수 있다.

1. 운영 플랫폼이 지원하는 LTS 목록을 확인한다.
2. 8.4와 9.7에서 드라이버·ORM·마이그레이션·백업 도구 호환성을 확인한다.
3. 필요한 SQL·replication·security 기능을 목록화한다.
4. 운영 환경과 같은 메이저 버전으로 통합 테스트를 실행한다.
5. 업그레이드와 rollback뿐 아니라 백업 복원과 forward recovery 절차까지 검증한다.

9.7 LTS를 플랫폼과 도구가 모두 지원한다
        └─ 9.7을 우선 검토

9.7 지원이 아직 부족하고 8.4 LTS가 충분히 검증됐다
        └─ 8.4를 선택하고 다음 LTS 이동 계획 기록

새 기능을 빠르게 평가해야 한다
        └─ Innovation·EA를 격리 환경에서 검증

어떤 경우든 latest tag를 고정 버전처럼 운영 환경에 쓰지 않는 편이 좋다. container image와 CI 테스트에는 메이저·마이너 정책을 명시하고 변경을 review 가능한 dependency update로 받는다.

5.7에서 바로 최신 LTS로 갈 수 있을까

MySQL 8.4 공식 업그레이드 경로에 따르면 5.7에서 8.4로 바로 올릴 수 없다. 먼저 최신 8.0으로 이동한 뒤 8.4로 가야 한다.

MySQL 5.7
   ↓
최신 MySQL 8.0
   ↓
MySQL 8.4 LTS

8.0에서 8.4로는 지원되는 직접 경로가 있다. 8.4에서 다음 LTS인 9.7로 이동하는 경로도 공식 문서에서 확인해야 한다. 실제 관리형 서비스는 upstream과 다른 제한·지원 절차를 둘 수 있으므로 서비스 제공자 문서가 최종 기준이다.

업그레이드는 바이너리만 바꾸는 일이 아니다. 다음 항목을 함께 확인한다.

• 사용 중인 인증 플러그인과 클라이언트 호환성
• reserved word와 SQL mode 차이
• removed·deprecated feature
• character set과 collation
• replication topology와 failover
• query plan 변화와 핵심 query latency
• 백업 생성, 복원, point-in-time recovery

MySQL Shell의 Upgrade Checker Utility는 업그레이드 전 호환성 문제를 찾는 도구다. 다만 검사 결과가 운영 안전성을 전부 보증하지는 않는다. 실제 데이터 복제본 또는 snapshot을 이용한 리허설과 애플리케이션 테스트가 필요하다.

performance는 version표만으로 결론 내리지 않는다

과거 버전 비교 글에는 “8.0이 5.7보다 몇 퍼센트 빠르다”는 문장이 흔했다. 하지만 한 벤치마크의 숫자를 모든 워크로드에 적용할 수는 없다.

성능을 비교하려면 최소한 다음 조건을 같게 둬야 한다.

• 동일한 하드웨어 또는 instance type
• 동일한 data volume과 분포
• 동일한 스키마·인덱스·쿼리
• 동일한 buffer pool과 connection 설정
• warm-up과 측정 구간
• p50뿐 아니라 p95·p99 latency와 throughput
• CPU, I/O, lock wait, buffer hit ratio

그리고 버전 업그레이드 전후의 실행 계획을 비교한다.

EXPLAIN ANALYZE
SELECT ...;

version을 올리는 것과 schema·index를 설계하는 것은 별개의 문제다. 복합 index의 동작은 MySQL 복합 인덱스 설계에서 이어서 정리했다.

로컬과 CI를 운영 메이저 버전에 맞춘다

로컬 개발 환경이 8.0인데 운영 환경이 8.4 또는 9.7이면 SQL mode, reserved word, optimizer behavior 차이가 늦게 발견될 수 있다. 가능한 범위에서 운영 환경과 같은 메이저·마이너 계열을 사용한다.

Docker Compose 예시는 tag를 명시적으로 고정한다.

services:
  mysql:
    image: mysql:8.4
    environment:
      MYSQL_DATABASE: app
      MYSQL_USER: app
      MYSQL_PASSWORD: local-only-password
      MYSQL_ROOT_PASSWORD: local-only-root-password
    ports:
      - "3306:3306"

이 예시의 password는 local 개발용 placeholder다. 실제 secret을 repository에 commit하지 않는다. 또한 mysql:8.4가 patch를 따라 움직이는 것이 부담이라면 조직의 patch update 정책에 맞춰 더 구체적인 immutable reference를 사용한다.

CI에서는 마이그레이션과 최소한의 호환성 테스트를 목표 버전에서 실행한다.

스키마 마이그레이션
→ 애플리케이션 통합 테스트
→ 주요 query plan·latency 확인
→ 백업 복원 리허설

2022년의 선택을 지금 다시 내린다면

당시 토이 프로젝트에서 5.7 대신 8.0을 고려한 이유는 오래된 version에 새 project를 시작하지 않으려는 판단이었다. 지금도 판단 원리는 유효하다. 다만 후보가 달라졌다.

2026년 8월 현재라면 다음처럼 결정한다.

• 새 운영 프로젝트: 플랫폼과 생태계가 지원하는 8.4 또는 9.7 LTS 우선
• 기존 8.0 시스템: 지원 상태를 확인하고 LTS 마이그레이션 계획 수립
• 기존 5.7 시스템: 8.0을 거치는 단계적 경로와 애플리케이션 호환성 검증
• 26.7 Innovation·EA: 격리된 평가 환경에서만 먼저 확인

가장 중요한 것은 버전 하나를 고르는 순간이 아니라, 그 버전을 언제 어떻게 갱신할지까지 정하는 일이다.

선택 체크리스트

1. MySQL 공식 릴리스·지원 상태를 확인했는가?
2. managed service가 그 version과 원하는 region·feature를 지원하는가?
3. 커넥터·ORM·CDC·백업·모니터링 도구가 호환되는가?
4. 운영 환경과 같은 버전에서 마이그레이션·통합 테스트를 실행했는가?
5. 핵심 워크로드로 query plan과 latency를 비교했는가?
6. 백업을 실제로 복원해 봤는가?
7. 다음 LTS로 이동할 시점과 책임자를 정했는가?

버전 선택은 기능표 비교가 아니라 애플리케이션과 운영 생태계 전체의 호환성 결정이다. “가장 최신”이나 “가장 익숙한” 하나의 기준보다 LTS, 플랫폼 지원, 검증 가능한 업그레이드 경로를 함께 보는 편이 오래 간다.

참고 자료

• MySQL 8.4 Reference Manual: MySQL Releases
• MySQL Product Support EOL Announcements
• MySQL 8.4 Reference Manual: Upgrade Paths
• MySQL Shell 8.4: Upgrade Checker Utility
• Oracle MySQL Blog: A More Predictable MySQL Release Model
• Oracle MySQL Blog: MySQL Community Server 26.7 Early Access
• Oracle MySQL Blog: MySQL 9.7.0 LTS