10년 만의 결별: CERN이 RHEL 계열을 떠나 Debian을 택한 진짜 이유

한눈에 보는 핵심 요약

CERN이 입자 가속기 제어용 산업용 컴퓨터와 임베디드 시스템을 CentOS에서 Debian으로 전환합니다.
2026년 말까지 2,200대 이상에 Debian 13을 배포하는 것이 목표입니다.
결정적 계기는 CentOS Stream의 기본 컴파일러 플래그 -march=x86-64-v2가 유발하는 **구형 하드웨어의 강제 노후화(forced obsolescence)**였습니다.
단, 전환 범위는 산업 제어 시스템에 한정되며 데이터센터와 실험용 컴퓨팅 환경은 계속 RHEL/AlmaLinux를 사용합니다.

RHEL 진영의 상징이었던 CERN

CERN은 대형 강입자 충돌기(LHC)로 유명하지만, 리눅스 생태계에서는 오랫동안 RHEL/CentOS 중심 기관으로도 잘 알려져 있었습니다.

과거에는 다른 교육·연구 기관들과 함께 RHEL 파생 배포판인 Scientific Linux를 공동으로 유지보수했습니다.
약 10년간 Scientific Linux를 운영한 뒤, 2015년 CentOS로 이전했습니다.
그리고 다시 약 10년이 흐른 지금, 일부 시스템에 대해 Debian 채택을 결정하고 스위스 빈터투어(Winterthur)에서 열린 MiniDebConf에서 계획을 공개했습니다.

10년 주기로 기반 OS를 한 번씩 갈아온 셈인데, 이번에는 방향 자체가 RHEL 계열 바깥으로 향했다는 점이 다릅니다.

결정을 가른 한 줄, `-march=x86-64-v2`

가장 자연스러운 선택지는 CentOS Stream으로 넘어가는 것이었고, CERN도 실제로 이를 검토했습니다. 그런데 발목을 잡은 것이 기본 컴파일러 플래그였습니다.

-march=x86-64-v2는 SSE4.2, POPCNT 같은 명령어 집합을 전제로 바이너리를 빌드하겠다는 의미입니다. 즉, 이 기준에 못 미치는 오래된 CPU에서는 아예 동작하지 않습니다.

일반적인 서버 환경이라면 큰 문제가 아닐 수 있습니다. 하지만 CERN의 상황은 다릅니다.

가속기 제어용 산업 시스템은 한번 설치하면 수십 년 단위로 운영되는 경우가 많습니다.
물리적으로 접근이 까다로운 위치에 설치된 장비도 존재합니다.
OS 업그레이드 때문에 멀쩡히 동작하는 하드웨어를 통째로 교체해야 한다면, 그 비용과 리스크는 감당하기 어렵습니다.

CERN 엔지니어들이 이 변경을 두고 "강제 노후화"라고 표현하며 RHEL 계열을 포기한 결정적 계기로 꼽은 이유입니다.

장밋빛만은 아니다 — Debian 도입의 과제

전환이 순조롭기만 한 것은 아닙니다. CERN은 온보딩 과정에서 마주한 어려움도 함께 공유했습니다.

패키지 자동 빌드·배포를 위한 표준 도구의 부재: 대규모 조직이 내부 패키지를 CI로 찍어내고 배포하는 흐름을 만들기에는, 공식 도구 체계에 여러 공백이 있습니다.
동일 패키지의 복수 버전 미지원: 일부 도구가 같은 패키지의 여러 버전을 동시에 다루지 못해, 버전별 병행 운영이 필요한 환경에서 걸림돌이 되고 있습니다.

RHEL 생태계가 오랜 기간 다져온 엔터프라이즈 빌드·배포 툴체인의 성숙도를 감안하면, 이 부분은 Debian 진영이 참고할 만한 피드백이라 할 수 있습니다.

전면 이전은 아니다 — 정확한 적용 범위

이 소식을 "CERN이 RHEL을 버렸다"로 읽으면 과장입니다. 실제 범위는 명확히 선을 긋고 있습니다.

| 구분 | 운영체제 | | --- | --- | | 가속기 제어용 산업 컴퓨터·임베디드 시스템 (2,200대 이상) | Debian 13 | | 데이터센터 | RHEL / AlmaLinux 유지 | | 실험용 컴퓨팅 환경 | RHEL / AlmaLinux 유지 |

즉, 워크로드 특성에 맞춰 배포판을 나누는 선택에 가깝습니다. 수명주기가 길고 구형 하드웨어가 섞인 제어계는 Debian으로, 하드웨어 갱신 주기가 정상적으로 도는 데이터센터·연구 컴퓨팅은 기존 RHEL 계열로 가져가는 구조입니다.

우리가 얻을 수 있는 교훈

기본값은 정책이다. 컴파일러 플래그 하나가 수천 대 규모의 OS 전략을 바꿀 수 있습니다. 배포판의 빌드 기본값은 단순한 기술 설정이 아니라 지원 하드웨어의 하한선을 정하는 정책 결정입니다.
하드웨어 수명주기를 먼저 보라. OS 선택은 성능이나 생태계보다 "이 장비를 언제까지 굴릴 것인가"에서 출발해야 하는 경우가 있습니다. 산업·임베디드 영역이 특히 그렇습니다.
전부 아니면 전무가 아니다. CERN처럼 시스템 성격별로 배포판을 분리하는 것도 충분히 합리적인 전략입니다.

자세한 전환 내용은 MiniDebConf에서 공개된 영상 발표에서 확인할 수 있습니다.