MySQL 수명 종료(EOL): 날짜, 위험 및 업그레이드 체크리스트

1. MySQL 종료 시점(EOL)이란? 지금 확인해야 하는 이유

MySQL EOL이란? 기본 설명

MySQL은 전 세계적으로 널리 사용되는 오픈 소스 관계형 데이터베이스 관리 시스템입니다. 웹 애플리케이션부터 비즈니스 시스템까지 모든 것을 구동하지만, 어떤 버전도 영원히 사용할 수는 없습니다.

MySQL에는 “End of Life (EOL)” 시점도 있습니다. 이는 개발사인 Oracle이 해당 버전에 대한 지원—예를 들어 보안 업데이트와 버그 수정—을 종료하는 날짜를 의미합니다.

예를 들어, MySQL 5.7은 2023년 10월에 지원이 종료되었습니다. 이러한 “EOL 정보”는 프로덕션 시스템의 안전성과 향후 유지 관리에 직접적인 영향을 미치기 때문에 매우 중요합니다.

“우리가 눈치채기 전에 이미 EOL이었습니다”는 매우 위험합니다

많은 개발자와 운영자는 MySQL 업그레이드에 신중을 기하는 경향이 있습니다. “안정적이니 그대로 두자”라고 생각하기 쉽지만, EOL 버전을 계속 사용하면 큰 위험이 따릅니다.

구체적으로, 위험 요소는 다음과 같습니다:

• 보안 취약점이 패치되지 않음
• 운영체제 및 기타 소프트웨어와의 호환성이 상실됨
• 공급업체로부터 지원을 더 이상 받을 수 없음
• 새로운 개발자가 유지 보수가 어려워져 유지 비용이 증가함

이러한 위험을 피하려면, 사용 중인 MySQL 버전의 지원 상태를 정기적으로 확인하는 것이 필수입니다.

지원 상태를 파악하면 “사고”를 예방할 수 있습니다

특히 비즈니스 시스템에서 MySQL을 사용하는 기업의 경우, “우리는 몰래 EOL을 넘겼다”와 같은 상황은 나중에 대규모 서비스 중단이나 보안 사고로 이어질 수 있습니다.

따라서 MySQL 버전의 지원 수명 주기를 이해하고, EOL 이전에 계획된 업그레이드나 마이그레이션을 수행하는 것이 앞으로 안정적인 운영을 위한 핵심입니다.

다음 섹션에서는 어떤 버전이 언제 EOL에 도달했는지 명확한 목록을 정리하여 실용적인 참고 자료로 제공하겠습니다.

2. MySQL 버전별 지원 종료 일정 (EOL 요약)

주요 MySQL 버전과 EOL 날짜 알아보기

MySQL은 수년간 지속적으로 업데이트되어 왔으며, 각 주요 버전마다 명확히 정의된 지원 기간이 있습니다. 아래는 주요 버전에 대해 공식적으로 발표된 EOL(지원 종료 날짜) 요약입니다.

[EOL Table by Version]

*날짜는 Oracle 및 주요 클라우드 제공업체의 공개 정보를 기반으로 합니다.

MySQL 5.5 (지원 종료: 2018년)

MySQL 5.5는 2010년에 출시되어 많은 웹 애플리케이션에서 채택되었습니다. 그러나 지원은 2018년 12월 3일에 종료되었습니다. 더 이상 보안 패치나 버그 수정이 제공되지 않으므로, 아직 이 버전을 사용 중인 시스템은 가능한 빨리 마이그레이션해야 합니다.

MySQL 5.6 (지원 종료: 2021년)

MySQL 5.6은 성능 향상과 새로운 기능으로 인기를 얻었지만, 2021년 2월 5일에 EOL에 도달했습니다. 아직 사용 중인 환경은 이미 지원이 종료되어 상당한 위험에 노출되어 있습니다.

MySQL 5.7 (지원 종료: 2023년 10월)

MySQL 5.7은 수년간 기업 시스템에서 널리 사용되었지만, 2023년 10월 21일에 지원이 종료되었습니다. 여전히 이 버전을 사용하는 시스템이 많으며, 더 많은 조직이 마이그레이션을 서두르고 있습니다. 호환성 검사와 데이터 마이그레이션 작업이 현재 주요 집중 분야입니다.

MySQL 8.0 (프리미엄 지원 예정 종료: 2025년 4월)

MySQL 8.0은 현재 주류 안정 버전이지만, 프리미엄 지원은 2025년 4월에 종료될 예정입니다. 이후에는 연장 지원을 받거나 LTS(Long Term Support) 릴리스로 전환하는 것이 권장됩니다. 2024년에 도입된 MySQL 8.4 LTS에 대한 관심이 높아지고 있으며, 장기적인 안정 운영을 원한다면 고려해볼 가치가 있습니다.

EOL 정보는 향후 계획에 필수적입니다

위와 같이 각 MySQL 버전마다 예정된 EOL이 있으며, 이에 맞춰 마이그레이션 준비가 필요합니다. 시스템이 사용하는 버전을 다시 확인하고 “지금은 괜찮다”가 아니라 “언제 마이그레이션할 것인가?”를 고민하십시오.

3. 지원 종료 후에 무슨 일이 일어날까? EOL 위험 설명

지원 종료 후 계속 사용하는 위험은 막대합니다

MySQL 버전이 EOL(End of Life)에 도달하면, 공식 보안 업데이트, 버그 수정, 개선 사항이 완전히 중단됩니다. 즉, Oracle로부터 더 이상 지원을 받을 수 없습니다.

모든 것이 정상적으로 작동하는 것처럼 보이더라도, 표면 아래에 심각한 위험이 도사리고 있을 수 있습니다. 이는 인터넷에 노출된 웹 서버나 핵심 비즈니스 시스템에서 특히 중요합니다.

패치되지 않은 보안 취약점

가장 심각한 문제는 새로 발견된 취약점이 더 이상 패치되지 않는다는 점입니다. 공격자들은 알려진 취약점 정보를 이용해 EOL 버전을 타겟으로 합니다.

그리고 MySQL이 널리 사용되기 때문에, 매력적인 타겟이 됩니다. EOL 이후에 취약점이 공개되더라도, 수정 패치가 영원히 나오지 않으면 방어 옵션이 극도로 제한됩니다.

🔒 패치가 없음 = 항상 타겟이 됩니다.

법률 및 보안 표준 위반 위험

더 많은 기업과 공공 기관이 ISMS나 PCI DSS 같은 표준을 준수해야 합니다. 이러한 표준은 종종 지원되지 않는 소프트웨어 사용을 명시적으로 금지합니다.

즉, EOL MySQL 버전을 계속 실행하면 감사 결과나 비즈니스 파트너와의 신뢰 손상을 초래할 수 있습니다.

OS나 다른 소프트웨어와의 호환성으로 인한 운영 문제

EOL 버전은 새로운 OS 릴리스나 다른 소프트웨어와의 호환성 테스트가 더 이상 이루어지지 않기 때문에, 예상치 못한 실패나 성능 문제를 일으킬 수 있습니다. 실제 사례로 OS 업데이트 후 MySQL이 시작되지 않거나 성능이 크게 저하되는 경우가 있습니다.

이는 긴급 대응—or 최악의 경우 서비스 다운타임으로 이어질 수 있습니다.

기술 부채로 쌓이는 문제

EOL 버전을 유지하는 것은 기술 부채를 축적합니다. 결국 업그레이드해야 할 때, 마이그레이션 비용이 급증하고 오래된 동작에 의존하는 대량의 코드가 발견될 수 있습니다.

요약하자면, 미루는 기간이 길어질수록 비용과 위험이 시간이 지남에 따라 증가합니다.

운영을 안전하게 유지하는 방법

EOL 위험을 피하기 위해, 반드시 즉시 업그레이드할 필요는 없습니다—하지만 마이그레이션 계획을 세워야 합니다. 현재 버전, EOL까지 남은 시간, 그리고 목적지를 이해함으로써 자신 있게 안정적인 환경을 유지할 수 있습니다.

다음 섹션에서 주요 마이그레이션 옵션과 어떤 경우에 가장 적합한지 소개하겠습니다.

4. 마이그레이션 옵션: 목표에 맞는 최적의 전략 선택

EOL 대응은 “마이그레이션 전략”에 달려 있습니다.

MySQL이 EOL에 가까워질 때 가장 중요한 결정은 “어디로 마이그레이션할지”입니다. 단순히 업그레이드하는 것만으로는 부족하며, 요구 사항과 운영 구조에 맞는 옵션을 선택하는 것이 미래 안정성을 결정합니다.

다음은 세 가지 일반적인 마이그레이션 패턴과 어떤 유형의 사용자에게 가장 적합한지입니다.

MySQL 8.0 또는 8.4 LTS로 업그레이드 (보수적, 안정성 중심)

가장 간단한 옵션은 새로운 MySQL 버전으로 업그레이드하는 것입니다. 현재 MySQL 8.0이 표준이지만, 2024년부터 MySQL 8.4 LTS (Long Term Support)가 주목을 받고 있습니다.

• 장점:
• 기존 MySQL 환경과의 높은 호환성
• 오픈 소스 사용 지속 가능
• MySQL Workbench 같은 기존 도구 계속 사용 가능
• 단점:
• 구문/명세 변경으로 인한 호환성 오류 발생 가능
• 스토리지 설정과 문자셋에 주의해야 함
• 가장 적합한 경우:
• 주요 시스템 변경 없이 안정적인 운영을 원하는 중소 기업 및 개발자

MariaDB나 TiDB 같은 대체 RDBMS로 마이그레이션 (유연성 및 미래 지향성)

MySQL과 호환되는 RDBMS로 전환하는 것도 강력한 후보입니다. 인기 있는 두 옵션은 MariaDB와 TiDB입니다.

• MariaDB:
• MySQL과 유사한 구문 및 관리 방식을 가진 포크
• 커뮤니티가 활발히 개발
• 풍부한 성능 최적화 기능
• TiDB:
• 클라우드 네이티브, 분산 SQL 데이터베이스
• 높은 가용성과 확장성
• OLAP과 OLTP를 모두 잘 처리하며, 분석에도 적합
• Best for:
• 향후 클라우드 마이그레이션이나 대규모 데이터 처리를 고려하는 조직
• 고급 오픈소스 기술을 도입하고자 하는 팀

Managed cloud database services (reduced ops workload, scalable)

온프레미스 운영 부담을 줄이고 싶다면 관리형 클라우드 RDB 서비스를 고려하세요. 일반적인 예시로는:

• Amazon RDS for MySQL
• AWS에서 제공하는 관리형 서비스
• 자동 백업 및 중복성이 기본 제공
• 시간이 지남에 따라 자동 업그레이드가 발생할 수 있음에 유의
• Google Cloud SQL for MySQL
• Google Cloud에서 제공하는 관리형 서비스
• 확장 가능하며 다른 GCP 서비스와 잘 통합
• UI를 통한 관리가 쉬워 초보자에게 친숙
• Pros:
• OS나 하드웨어 유지보수 불필요
• 인프라 전문 지식 요구 감소
• Cons:
• 지속적인 클라우드 비용 발생
• 세밀한 튜닝이 어려울 수 있음
• Best for:
• 소규모에서 중규모 웹 애플리케이션 운영
• 개발/운영 리소스를 효율화하고자 하는 스타트업 및 웹 비즈니스

[Comparison Table] Options and characteristics

다음 섹션에서는 실용적인 마이그레이션 단계와 주요 주의사항을 명확하고 실행 가능한 형태로 나눠 설명합니다. 실수를 방지하기 위해 체크리스트를 함께 살펴보겠습니다.

5. MySQL Migration Steps and Checklist (How to Avoid Failure)

Migration success is “80% preparation”

MySQL EOL(수명 종료)로 인한 마이그레이션은 단순 버전 업그레이드와 다르며—신중한 단계와 철저한 준비가 필요합니다. 특히 프로덕션 시스템에서는 데이터 무결성과 서비스 연속성을 보장하는 것이 최우선입니다.

여기서는 다섯 단계에 걸친 핵심 절차를 설명합니다.

STEP1: Assess and inventory the current environment

먼저 현재 MySQL 버전, 설정, 종속성을 파악합니다.
다음 항목을 확인하세요:

• MySQL 버전 및 빌드 번호
• 사용 중인 문자 집합(예: utf8mb4)
• 스토리지 엔진(InnoDB, MyISAM)
• 사용 중인 SQL 구문 및 함수(버전 의존성이 있을 수 있음)
• 연결된 애플리케이션 및 외부 서비스

✅ Goal: understand all dependencies to prevent post-migration failures
✅ 목표: 모든 종속성을 파악하여 마이그레이션 후 실패를 방지

STEP2: Verify compatibility

현재 환경이 대상 버전과 호환되는지 검증합니다. 대규모 업그레이드 시 특히 다음에 주의하세요:

• 사용 중인 구문/예약어가 제거되었는지
• 기본 설정 변경(예: SQL 모드)
• 시스템 변수 및 파라미터 차이

🔎 You can diagnose compatibility using the mysql_upgrade command or the MySQL Shell Upgrade Checker Utility.
🔎 mysql_upgrade 명령어나 MySQL Shell Upgrade Checker Utility를 사용하여 호환성을 진단할 수 있습니다.

STEP3: Take backups and build a test environment

프로덕션을 직접 업그레이드하는 것은 위험합니다.
먼저 전체 백업을 수행하고 이를 활용해 스테이징(테스트) 환경을 구축합니다.

• mysqldump 또는 mysqlpump 로 백업 덤프
• 파일 기반 백업(예: XtraBackup)
• 스테이징에 복원하고 애플리케이션 동작 테스트

사전에 마이그레이션 후 문제와 SQL 오류를 찾아두면 프로덕션 전환 시 문제를 최소화할 수 있습니다.

STEP4: Migrate data to production

검증이 끝나면 프로덕션으로 마이그레이션합니다. 가능하면 야간이나 트래픽이 적은 시간대에 진행하세요.

• 전환 직전 최종 백업
• 서비스 일시 중지(가능하면 유지보수 페이지 표시)
• 새 데이터베이스 버전으로 데이터 가져오기
• 설정 파일 및 환경 변수 조정

애플리케이션 측에서도 MySQL 엔드포인트 변경 등 조치가 필요하다면 타이밍을 특히 신중히 잡으세요.

STEP5: Validate and optimize

전환이 끝났다고 마이그레이션이 완료된 것은 아닙니다.
새 환경이 안정적인지 확인하기 위해 다음을 점검하세요:

• 애플리케이션과의 연결성
• 쿼리 실행 속도 및 오류
• 로그 모니터링(오류 로그, 슬로우 쿼리 로그)
• 캐시 설정 최적화 및 인덱스 재구축

필요에 따라 ANALYZE TABLE 또는 OPTIMIZE TABLE을 실행하여 마이그레이션으로 인한 성능 저하를 복구합니다.

체크리스트 (최종 검토)

✅ 현재 버전 및 구성 확인
✅ 사전 호환성 검사 실행
✅ 전체 백업 수행
✅ 스테이징 환경에서 테스트
✅ 계획된 프로덕션 전환 실행
✅ 마이그레이션 후 오류 및 성능 모니터링

성공의 핵심은 실행 계획에 있습니다. EOL 기반 마이그레이션의 경우 꾸준한 준비, 테스트, 그리고 신중한 전환이 가장 좋은 위험 감소 전략입니다.

6. 클라우드 서비스에서 EOL 처리 (AWS 및 GCP 사용자 대상)

클라우드에서도 안주해서는 안 됩니다

Amazon RDS나 Google Cloud SQL과 같은 클라우드 플랫폼에서 MySQL을 사용하더라도 EOL(지원 종료)은 여전히 여러분의 문제입니다. 클라우드 제공업체는 지원되지 않는 버전에 대해 자동 업그레이드 또는 서비스 종료를 시행할 수 있으므로 사전 계획이 중요합니다.

아래는 주요 클라우드 서비스별 EOL 처리 개요입니다.

Amazon RDS for MySQL: 자동 업그레이드 주의

Amazon RDS for MySQL을 사용하면 AWS가 지원 종료로 인한 버전 퇴출 및 강제 업그레이드를 여러 차례 수행했습니다.

• MySQL 5.5: 2018년에 종료 → 자동으로 5.6으로 마이그레이션
• MySQL 5.6: 2021년에 종료 → 2022년 이후 자동으로 5.7 업그레이드 적용

그 결과, 의도하지 않은 시점에 MySQL 버전이 전환될 수 있어 애플리케이션 문제나 성능 저하를 초래할 수 있습니다.

✅ 완화 방안: 직접 일정에 맞춰 업그레이드를 계획하고 실행

AWS는 이메일 및 콘솔 알림을 통해 사전 공지를 제공하지만, 이를 무시하면 자동으로 적용될 수 있으니 주의하십시오.

Google Cloud SQL for MySQL: 1세대 퇴출 및 마이그레이션 추진

Cloud SQL for MySQL도 오래된 버전 및 아키텍처의 퇴출을 진행하고 있습니다.

• 1세대 인스턴스는 더 이상 새로 생성할 수 없습니다
• 지원 종료에 가까워지는 버전에 대한 업그레이드 권장 정책이 있습니다

Google은 사용자 유연성을 존중하는 편이지만, 장기적인 “생명 유지”에는 한계가 있어 가능한 한 빨리 업그레이드하거나 재구축하는 것이 좋습니다.

Cloud SQL은 자동 백업 및 장애 조치와 같은 강력한 기능을 제공하지만, 기본 SQL 모드 설정이나 시간대 동작과 같은 차이를 간과하면 문제 발생 가능성이 있습니다.

✅ 클라우드 전용 설정 및 호환성을 사전에 테스트

클라우드 장점과 EOL 함정

클라우드 서비스는 장점이 있지만, EOL 준비가 미흡하면 문제가 발생할 수 있습니다.

클라우드에서도 현실은 동일합니다: 여전히 EOL을 직접 처리해야 합니다.

클라우드 환경을 위한 EOL 체크리스트

✅ 현재 MySQL 버전 및 EOL 일정 확인
✅ 공급업체 알림(이메일 등) 활성화
✅ 자동 업그레이드 적용 여부 확인
✅ 스테이징에서 새 버전 테스트
✅ 필요에 따라 애플리케이션 측 변경 계획

클라우드 편리함을 최대한 활용하려면 “설정 후 방치”하지 마세요. 자신의 측에서 적극적인 관리와 모니터링을 유지해야 합니다. MySQL EOL의 경우, 클라우드 환경에서도 확실한 준비가 필요합니다.

7. 자주 묻는 질문 (FAQ)

Q1: 지원 종료 후에도 MySQL을 계속 사용할 수 있나요?

A: 기술적으로는 가능하지만 권장되지 않습니다.
EOL이 된 MySQL은 보안 패치나 버그 수정이 제공되지 않습니다. 이는 취약점을 이용한 공격 위험을 급격히 높이며 법률이나 보안 정책을 위반할 수도 있습니다.

시스템이 정상적으로 보이더라도 심각한 숨은 위험을 안고 있는 것이므로, 조기에 업그레이드나 마이그레이션을 계획해야 합니다.

Q2: MySQL 8.0과 8.4 LTS의 차이점은 무엇인가요?

A: MySQL 8.4 LTS는 더 긴 기간 동안 지원되는 안정적인 릴리스입니다.
MySQL 8.0은 정기 릴리스 주기를 따르며, 프리미엄 지원은 2025년 4월에 종료될 예정입니다. 반면에 MySQL 8.4 LTS(장기 지원)는 약 5년 정도의 장기 지원을 제공하는 안정적인 릴리스로 도입되었습니다.

비즈니스 시스템에서 장기적인 안정성을 우선시한다면, MySQL 8.4 LTS로 마이그레이션하는 것이 권장됩니다.

Q3: 마이그레이션 비용은 얼마나 듭니까?

A: 규모와 마이그레이션 경로에 크게 좌우됩니다.
예를 들어, 동일 서버에서 버전 업그레이드는 직접적인 비용 없이 가능할 수 있습니다. 그러나 클라우드 서비스로 마이그레이션하거나 제품을 전환(MariaDB/TiDB)하는 경우 설계, 구축, 테스트 및 기술 지원을 위한 노력과 비용이 필요할 수 있습니다.

다운타임 완화와 스테이징 환경 준비에 대한 비용도 고려해야 합니다.

Q4: 프로덕션 시스템 마이그레이션 시 주의할 점은 무엇인가요?

A: 사전 테스트와 단계적 마이그레이션이 핵심입니다.
프로덕션 환경에서는 호환성 검사, 백업, 스테이징 테스트를 수행해야 합니다. 읽기 복제본을 사용하거나 블루-그린 배포(구 환경과 신 환경을 동시에 실행하고 점진적으로 전환) 방식을 활용하면 다운타임을 줄일 수 있습니다.

트래픽이 적은 밤이나 주말에 작업을 수행하는 것이 가장 안전합니다.

Q5: 클라우드에서 자동 업그레이드를 중단할 수 있나요?

A: 일부 부분은 제어할 수 있지만 궁극적으로는 공급업체 정책을 따라야 합니다.
RDS와 Cloud SQL은 자동 업그레이드 일정을 지연하거나 조정하는 등 일부 제어를 허용하지만, EOL 이후에도 강제 업그레이드가 발생할 수 있습니다.

장기적인 회피가 어렵기 때문에 가장 신뢰할 수 있는 방법은 사용자가 주도하는 계획된 업그레이드입니다.

Q6: 대체 데이터베이스를 어떻게 선택해야 하나요?

A: 다음 세 가지 기준을 사용하세요.

1. Compatibility : 기존 애플리케이션 및 SQL이 그대로 얼마나 작동할 수 있는가
2. Scalability / future-proofing : 데이터와 트래픽 증가를 감당할 수 있는지
3. Operational capability : 자체적으로 유지 관리할 수 있는지, 아니면 공급업체 지원이 필요한지

비즈니스 시스템에서는 트렌드보다 실제 운영 역량을 기반으로 선택해야 합니다.

8. 요약: 지원 종료 전에 할 수 있는 최고의 조치

EOL은 “멀리 있지” 않으며—바로 코앞에 있습니다

MySQL EOL(지원 종료)은 IT 직원에게만 해당되는 것이 아닙니다. 보안, 성능, 가용성, 비용 관리 전반에 걸쳐 조직 전체에 영향을 미칩니다.

MySQL 5.7은 이미 2023년 10월에 지원 종료되었으며, MySQL 8.0은 2025년 4월에 프리미엄 지원 종료가 예정되어 있습니다. “아직 동작하니 괜찮다”라고 생각하면, 인식하기 전에 중대한 위험을 안고 운영하게 될 수 있습니다.

계획된 마이그레이션이 최고의 위험 회피 전략입니다

이 문서에서 보여주듯, 단계별로 진행하면 마이그레이션은 어렵지 않습니다:

• 현재 버전 식별
• 호환성 확인 및 마이그레이션 대상 선택
• 스테이징 환경에서 테스트
• 단계적 마이그레이션 및 최종 전환 수행

이 단계들을 따르면 다운타임과 데이터 손실을 방지하면서 마이그레이션을 안전하게 완료할 수 있습니다.

클라우드 서비스를 이용하더라도 모든 것을 공급업체에 맡기지 말고, 상황을 파악하고 능동적으로 업그레이드 계획을 수립하세요.

“몰랐어요”는 더 이상 변명이 될 수 없습니다

현대 시스템 운영에서는 기술 지식뿐만 아니라 지속적인 유지보수 인식도 필요합니다. 지원 종료 시점을 알고, 위험을 평가하며, 최적의 마이그레이션 옵션을 선택하는 것은 모든 운영자와 개발자에게 필수적인 역량입니다.

마지막으로: 지금 바로 취할 세 가지 행동

1. 시스템에서 사용 중인 MySQL 버전 확인
2. EOL 날짜를 확인하고 캘린더에 표시
3. 팀과 마이그레이션 접근 방식(업그레이드 vs. 데이터베이스 전환) 논의

이 세 가지만 해도 다음 단계가 명확해집니다.

MySQL EOL을 처리하는 것은 향후 사고에 대비한 “보험 정책”입니다.
이 기사를 트리거로 사용하여 운영을 검토하고 더 안전하고 지속 가능한 환경을 구축하십시오.