SUSE Linux Enterprise Server 16은 2025년 11월에 나온 이 기업용 계열의 세대가 바뀌는 판이다. 설치는 Agama로 옮기고 일상 관리는 Cockpit이 맡고 Ansible은 처음부터 들어가며 이십여 년 쓴 모듈 체계는 걷어 냈다. 16 계열 전체에 16년 지원이 붙어 2038년 고개를 넘는다.

판의 줄기가 한 세대 바뀌었다

목록의 이 항목은 아직 15 SP7에 머물러 있지만 실제는 한 걸음 나아갔다. 16.0이 2025년 11월 4일에 열려 15 계열을 잇는다. 공식 박자는 16.0부터 16.6까지 일곱 번의 다음 판이고 해마다 11월에 하나를 내며 다음 판마다 5년 지원이 따로 붙는다. 정규 지원 2년에 연장 3년이다.

이름도 바뀌었다. 서비스 팩은 다음 판이 되었고 장기 서비스 팩 지원은 그냥 장기 지원이 되었다. 달라진 것은 셈법으로, 전에는 팩의 수명이 큰 판을 따라갔고 지금은 다음 판이 자기 5년을 센다.

YaST는 유지 보수 단계로 물러난다

이 판에서 가장 분명히 짚어야 할 변화다. YaST는 1996년부터 SUSE의 간판이었고 설치, 분할, 네트워크 설정, 서비스 관리가 모두 이를 거쳤다. 16부터 유지 보수 단계로 들어간다. 15 계열은 완전한 지원을 이어가고 16 계열에서는 그 자리를 세 가지가 받는다.

설치는 Agama로 간다. 화면을 바탕으로 한 설치 도구로 흐름 전체가 기기 브라우저에서도 원격에서도 돌아가고, 핵심은 Rust로 쓰였으며 바깥에 완전한 HTTP 연결 지점을 내어 자동화 흐름에 넣기 쉽다. 옛 설정 파일과의 호환을 지켜 이미 있는 자동 설치 설정은 대개 그대로 읽히고, JSON을 바탕으로 한 자체 표기도 함께 제공해 분할안을 전부 쓰지 않고 바꿀 부분만 적을 수 있다.

일상 관리는 Cockpit으로 간다. 화면 제어대에서 상태를 보고 기록을 넘기고 성능을 살피는 일이 브라우저 안에서 끝난다. SUSE가 여기에 전용 응용을 몇 가지 더해 소프트 출처, 패키지 설치, 구독 관리처럼 전에는 YaST만 다루던 일이 화면에서 된다. 자동화는 Ansible로 간다. 이 판은 이것을 시스템 안에 바로 넣고 방화벽, 무리, 보안 정책, 컨테이너 실행 환경 같은 표준 역할을 갖춘다. 전의 Salt는 시스템에 딸리지 않고 여러 Linux를 함께 다루는 제품의 일부로만 이어진다.

모듈 체계는 걷어 냈다

15 계열의 모듈 나눔, 곧 기초 시스템과 서버 응용과 개발 도구가 각각 한 모듈을 차지하고 저마다 소프트 풀과 갱신 통로를 갖던 형태는 16에서 없앴다. 공식 이유는 단순화다. 층이 많은 저장소 구조가 패치 찾기와 올릴지 판단을 어렵게 했고 없앤 뒤 패키지 관리자의 갱신 성능도 올랐다.

값은 습관을 바꾸는 것이다. 먼저 모듈을 더하고 패키지를 넣는 동작은 사라졌고 소프트는 주 저장소에서 바로 온다. 다음 판은 여전히 저마다 저장소를 가져 올리는 길은 다음 판으로 센다. 서비스 몇 개만 돌리는 기계에는 이 단순화가 편하고 모듈로 차이를 만든 환경에서는 옮길 때 무엇을 넣었는지 다시 정리해야 한다.

스냅숏과 되돌리기가 기본이 된다

Btrfs와 Snapper에 바탕을 둔 파일 시스템 스냅숏은 12부터 있었고 이 판은 그것을 클라우드 이미지까지 펼쳤다. 실물 기계에서도 가상 기계에서도 클라우드에서도 행동이 같다. 패키지 관리자나 화면 제어대로 갱신하면 시스템이 스스로 스냅숏을 찍고 정해진 수만 남겨 언제든 되돌릴 수 있다. 스냅숏은 파일 시스템 층에서 찍히므로 어떤 파일이 바뀌었는지까지 보이고 단지 어떤 갱신이 있었다로 끝나지 않는다. 실시간 패치, 이 판은 모든 판에 넣고 따로 팔지 않는다, 와 묶으면 커널 보안 수정을 다시 켜지 않고 넣을 수 있다.

보안 쪽에서 바탕 둘이 바뀌었다

강제 접근 제어가 AppArmor에서 SELinux로 옮기고 사백 개가 넘는 모듈의 정책 묶음이 따른다. 오래 쓴 사람에게는 이것이 실제 이전 작업이다. 전에 AppArmor 설정으로 통과시키던 서비스는 이제 SELinux 정책을 써야 한다. 다른 하나는 재현 가능한 빌드로 같은 소스에서 바이트까지 같은 결과가 나오고 서명과 증명을 더해 배포한 이미지가 도중에 바뀌지 않았음을 보인다. 이것에 공개 거버넌스가 더해져 이 배포판은 디지털 공공재 인정을 받았다.

빼는 목록도 짧지 않다

공격 면을 좁히려고 이 판이 지운 것은 더한 것보다 볼 만하다.

바탕 화면 부분도 함께 줄어 최소한의 GNOME만 싣는다. 브라우저와 파일 관리자, 그림과 문서를 보는 도구가 돌면 충분하고 서버 시스템이 가끔 하는 그래픽 작업 때문에 데스크톱 한 벌을 질 필요는 없다.

지원 기간을 어떻게 세는가

아직 15 계열에 있다면 서두를 일은 없다. 15 SP7은 2025년 6월에 나왔고 정규 지원은 2031년 7월 말까지, 늘린 장기 지원은 2034년 7월 말까지여서 두 세대가 오래 나란히 간다. 올릴 계획을 세울 때는 다음 판의 줄을 본다.

기계의 문턱과 구조

공식 최소 사양은 낮다. CPU 하나, 메모리 2GB, 저장 32GB면 화면이 없는 서버에 충분하다. 구조의 폭은 이 제품의 옛 본령으로 x86-64, ARM, IBM Power, IBM Z가 모두 목록에 있고 구조가 섞인 데이터 센터에는 실제 값어치가 있다.

제품 형태도 설치판 하나가 아니다. 고가용성 확장은 무리와 거점을 넘는 전환을 맡고 고성능 계산판은 큰 무리의 병렬 배치를 맡고 실시간판은 정해진 배치와 낮은 지연을 주며, 컨테이너 형태와 변하지 않는 배치 형태, SAP 응용을 위해 준비한 판도 있다. 이 판은 또 모델 문맥 규약의 호스트 쪽을 들여 대리 방식 AI를 시스템 층에 끌어들였다. 다만 지금은 방향을 보이는 움직임이고 곧바로 쓸 기능은 아니다.

누가 고려해야 하는가

서버를 오래 가는 자산으로 보고 지원 기한과 책임 소재를 분명히 해야 하는 조직에 맞는다. 16년 지원, 재현 가능한 빌드, 디지털 공공재 인정은 모두 조달과 적합성 심사의 자료에 적을 수 있다. IBM Power나 IBM Z 위에서 돌리는 환경에도 맞는다. 그 구조에서 고를 수 있는 상용 배포판은 원래 적다.

반대로 손에 있는 15 계열이 안정적으로 돌면 첫날에 옮길 이유가 없다. YaST는 15에서 완전한 지원이 이어진다. 실제로 손을 대야 하는 것은 모듈 저장소에 기대는 자동 스크립트와 AppArmor 규칙으로 통과시키던 서비스이고, 이 둘이 이전 비용의 큰 몫이라 먼저 파악하고 일정을 짜는 편이 판 번호를 쫓는 것보다 실제적이다.

SLES 16은 도구를 바꾸는 세대 교체다. Agama가 설치를, Cockpit이 관리를 잇고 Ansible이 안에 들어오며 모듈 체계가 사라지고 스냅숏과 실시간 패치가 기본이 된다. 동시에 물건을 지우는 교체이기도 해 X11, Xen, VNC, 낡은 그래픽 라이브러리, 32비트 지원이 모두 물러난다. 16년 지원과 두 세대가 나란히 가는 시간 창이 자기 박자로 옮길 여지를 준다.