endoflife.date로 서버 EOL 관리하기 — CentOS·Rocky Linux·MariaDB LTS

  • 26th August 2026
  • 7 min read

서버에 접속해 cat /etc/os-release를 쳐본다. Rocky Linux 9.4가 나온다. 그래서 이 서버는 안전한가?

답할 수 없다. 버전 번호는 그 자체로 아무것도 말해주지 않는다. 9.4가 아직 지원되는지, 이미 다음 포인트 릴리스에 밀려났는지, 언제까지 보안 패치가 오는지 — 전부 밖에서 찾아봐야 아는 정보다.

이걸 매번 검색으로 해결하다 보면 결국 한 곳에 정착하게 된다. endoflife.date다.

먼저, 우리가 왜 이 걱정을 하게 됐나

EOL을 신경 쓰는 습관은 대체로 한 번 크게 데인 경험에서 나온다. 서버 쪽에서 그 사건은 CentOS였다.

2020년 12월, Red Hat은 CentOS 8의 지원을 2029년에서 2021년 말로 앞당긴다고 발표했다. 8년이 통째로 사라진 것이다. 개발은 CentOS Stream으로 옮겨간다고 했다 — RHEL의 복제본이 아니라 RHEL의 상류가 되는, 성격이 완전히 다른 물건이다.

2014 2016 2018 2020 2022 2024 2026 2028 2030 예정: 2029년까지 CentOS 8 8년 앞당겨 끊겼다 CentOS 7 — 2024-06 종료 Rocky · AlmaLinux 등장 2020-12 CentOS 8 조기 종료 발표 2023-07 RHEL 소스 접근 제한 → OpenELA CentOS 8은 2029년까지 쓸 수 있는 줄 알고 깔았던 것이다 무료 RHEL 클론이 사실상 표준 서버 OS였기 때문에, 발표 한 번으로 수많은 조직의 이주 계획이 동시에 시작됐다. 그 자리를 메우려고 나온 것이 Rocky Linux 와 AlmaLinux 다.
2029년까지 쓸 수 있는 줄 알고 깔았던 CentOS 8은 2021년 말에 끊겼다.

충격이 컸던 이유는 CentOS가 그냥 배포판 하나가 아니었기 때문이다. 무료로 쓸 수 있는 RHEL 클론이라는 자리는 사실상 표준 서버 OS의 자리였다. 호스팅 업체도, 사내 서버도, 고객사 납품 서버도 기본값이 CentOS였다. 발표 한 번으로 수많은 조직의 이주 계획이 동시에 시작됐다.

그나마 CentOS 7이 2024년 6월 30일까지 살아 있어서 시간을 벌어줬다. 실제로 많은 조직이 그 날짜를 데드라인 삼아 움직였다.

그래서 갈라졌다

빈자리를 메우려는 프로젝트들이 곧바로 나왔다.

  • Rocky Linux — CentOS 공동 창업자인 Gregory Kurtzer가 시작했다. 이름부터 세상을 떠난 공동 창업자를 기린 것이다. "CentOS가 하던 일을 그대로 하겠다"는 선언에 가까웠다.
  • AlmaLinux — CloudLinux가 지원해 시작했고, 재단으로 넘겼다.
  • Oracle Linux, SUSE Liberty 등 기존 상용 진영도 이주 수요를 겨냥했다.

여기서 끝이 아니었다. 2023년 7월, Red Hat이 RHEL 소스 코드의 공개 접근을 제한했다. 그때까지 공개돼 있던 소스를 CentOS Stream으로 일원화하고, RHEL 소스는 고객·파트너에게만 제공하기로 한 것이다. 클론 배포판들이 재료로 쓰던 것을 막은 셈이다.

반응이 둘로 갈렸고, 이 지점이 지금 Rocky와 Alma가 다른 이유다.

  • Rocky는 1:1 바이너리 호환을 고수했다. Oracle·SUSE와 함께 OpenELA(Open Enterprise Linux Association)를 만들어 RHEL 호환 배포판을 만들 수 있는 소스를 공동으로 확보하는 길을 택했다.
  • AlmaLinux는 목표를 ABI 호환으로 바꿨다. RHEL과 한 줄 한 줄 같기를 포기하는 대신, "RHEL용으로 빌드된 프로그램은 그대로 돈다"를 보장하는 쪽이다. 대신 RHEL 릴리스 주기와 무관하게 자체적으로 버그를 고칠 수 있게 됐다.

둘 다 합리적인 선택이고, 어느 쪽이 낫다고 말하기 어렵다. 다만 "CentOS의 대체재"라는 한 덩어리로 보던 시기는 2023년에 끝났다.

요즘은 Rocky로 정착하는 분위기다

체감상 국내 서버 환경에서는 Rocky로 모이는 흐름이 보인다. RHEL과 1:1이라는 점이 기존 CentOS 운영 방식을 그대로 옮기기에 편하고, 검증된 절차와 문서를 재사용할 수 있어서일 것이다.

다만 이건 관찰이지 통계가 아니다. 이 영역은 신뢰할 만한 점유율 데이터가 드물고, 업계나 규모에 따라 그림이 다를 수 있다. 각자 주변을 기준으로 판단하는 편이 낫다.

endoflife.date — EOL을 찾아다니지 않기

이 모든 이야기의 실무적 결론은 하나다. 내가 쓰는 것들의 종료 날짜를 어딘가에서 계속 확인해야 한다.

endoflife.date는 그 정보를 한곳에 모아둔 사이트다. 리눅스 배포판부터 프로그래밍 언어, 데이터베이스, 프레임워크, 브라우저까지 460개가 넘는 제품의 릴리스 날짜와 지원 종료일을 정리해두고 있다.

웹으로 보는 것도 편하지만, 진짜 쓸모는 API에 있다.

# 제품 목록
curl https://endoflife.date/api/v1/products/

# 특정 제품의 릴리스 전체
curl https://endoflife.date/api/v1/products/mariadb/

인증이 필요 없다. 응답의 releases 배열에 릴리스마다 이런 값들이 들어 있다.

{
  "name": "11.4",
  "releaseDate": "2024-05-29",
  "isLts": true,
  "isEol": false,
  "eolFrom": "2029-05-29",
  "isMaintained": true,
  "latest": { "name": "11.4.9", ... }
}

isEol과 eolFrom만 있으면 "내가 쓰는 버전이 아직 살아 있는가"를 코드로 물어볼 수 있다. 사람이 사이트를 방문할 필요가 없어진다는 뜻이다.

#!/usr/bin/env python3
"""내 스택의 EOL 을 한 번에 확인한다."""
import json, urllib.request
from datetime import date

STACK = {"rocky-linux": "9", "mariadb": "11.4", "php": "8.3", "nginx": "1.27"}

for product, mine in STACK.items():
    url = f"https://endoflife.date/api/v1/products/{product}/"
    with urllib.request.urlopen(url, timeout=20) as r:
        releases = json.load(r)["result"]["releases"]

    hit = next((x for x in releases if x["name"] == mine), None)
    if hit is None:
        print(f"{product:12} {mine:8} ← 목록에 없다. 이미 오래된 버전일 수 있다")
        continue

    eol = hit.get("eolFrom") or "?"
    left = (date.fromisoformat(eol) - date.today()).days if eol != "?" else None
    mark = "지원 종료" if hit["isEol"] else (f"{left}일 남음" if left else "")
    print(f"{product:12} {mine:8} EOL {eol}  {mark}")

이걸 크론에 걸어두고 남은 기간이 6개월 아래로 떨어지면 알림을 보내면, EOL은 "생각날 때 확인하는 것"에서 "기한이 다가오면 알려주는 것"으로 바뀐다.

MariaDB의 LTS는 무엇인가

이 도구가 실제로 유용한 예를 하나 보자. MariaDB의 LTS는 생각보다 헷갈린다.

MariaDB는 짧게 살고 지나가는 릴리스와 오래 지원하는 LTS를 섞어 낸다. 예를 들어 12.0·12.1·12.2는 각각 반년 남짓 지원되고 끝났고, 그 계열의 마지막인 12.3이 LTS가 됐다. 그래서 버전 번호만 봐서는 LTS인지 알 수 없다.

2026년 8월 기준 LTS들을 지원 기간으로 늘어놓으면 이렇게 된다.

MariaDB LTS — 나중에 나온 것이 더 오래 가지 않는다 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 10.6 2026-06 지원 종료 10.11 2028-02 11.4 2029-05 11.8 2028-05 12.3 2029-05 오늘 11.8 이 11.4 보다 1년 먼저 끝난다 11.4·10.11·10.6 은 5년, 11.8·12.3 은 3년이다. '최신 LTS' 를 골랐다고 가장 오래 쓰는 것이 아니다.
같은 LTS인데 지원 기간이 다르다. 11.8은 11.4보다 늦게 나와 먼저 끝난다.
버전 출시 지원 종료 기간
10.62021-072026-07 (종료됨)5년
10.112023-022028-025년
11.42024-052029-055년
11.82025-062028-063년
12.32026-052029-063년

표를 보면 이상한 점이 눈에 띈다. 11.8은 11.4보다 1년 늦게 나왔는데 1년 먼저 끝난다.

LTS 지원 기간이 5년에서 3년으로 짧아졌기 때문이다. 그래서 "최신 LTS를 고르면 가장 오래 쓴다"가 성립하지 않는다. 2025년에 11.8로 올렸다면, 그냥 11.4에 있었을 때보다 이주를 1년 일찍 다시 해야 한다.

이런 건 릴리스 노트를 읽어서 알아내기 어렵다. 날짜를 나란히 놓고 봐야 보인다. EOL 데이터를 한곳에서 가져오는 일의 값이 여기에 있다.

포인트 릴리스에 멈춰 있으면 업데이트가 오지 않는다

배포판에는 함정이 하나 더 있다. 포인트 릴리스다.

Rocky Linux는 새 포인트 릴리스가 나오면 이전 포인트 릴리스를 더 이상 지원하지 않는다. 9.x 안에서도 최신에 머물러 있어야 보안 업데이트가 온다는 뜻이다. RHEL이 특정 마이너 버전에 오래 머물 수 있게 해주는 것(EUS)과 다른 지점이다.

그래서 Rocky Linux 9.4라고 적힌 서버는, 그 계열의 최신이 9.8이라면 업데이트를 받지 못하는 상태다. 큰 버전(9)의 지원 종료일은 2032년이지만 그건 9 계열 이야기이고, 9.4에 멈춰 있는 서버의 이야기가 아니다.

# 큰 버전만 보면 안심하게 된다
Rocky Linux 9  → 보안 지원 2032-05-31

# 실제로 확인해야 하는 것
내 서버 9.4  vs  현재 9 계열 최신 9.8   ← 여기가 벌어져 있으면 패치가 오지 않는다

앞의 스크립트에서 latest.name을 함께 보라고 한 이유가 이것이다. 내 버전과 그 계열의 최신을 나란히 놓고 봐야 실제 상태가 나온다.

정리 — EOL을 관리한다는 것

  • 버전 번호는 안전을 말해주지 않는다. 지원 여부와 종료일은 밖에서 확인해야 한다.
  • CentOS 사건이 남긴 교훈은 "무료라서 위험하다"가 아니라, 공급자의 정책이 바뀌면 내 계획도 바뀐다는 것이다.
  • Rocky와 Alma는 2023년 이후 다른 길을 간다. 1:1 바이너리 호환이냐 ABI 호환이냐 — 고를 때 알고 골라야 한다.
  • LTS라고 다 같은 기간이 아니다. MariaDB는 5년에서 3년으로 줄었고, 그 결과 나중에 나온 LTS가 먼저 끝나는 역전이 생겼다.
  • 포인트 릴리스에 멈춰 있으면 큰 버전의 지원 기간은 의미가 없다.
  • 이 모든 걸 사람이 기억할 수는 없다. API로 가져와 기한이 다가오면 알려주게 만든다.

EOL 관리는 재미있는 일이 아니다. 잘 해두면 아무 일도 일어나지 않고, 안 해두면 어느 날 "이 버전은 이제 패치가 안 나옵니다"라는 문장을 급하게 읽게 된다. 날짜를 미리 알고 있는 것과 닥쳐서 아는 것의 차이가 전부다.

이 글의 날짜와 버전은 2026년 8월 기준이며 endoflife.date의 데이터를 인용했다. 정책은 바뀌므로 조치 전에는 각 프로젝트의 공식 공지로 확인하시길 권한다.