[Linux] CentOS 7에서 AlmaLinux 9로: 성공적인 서버 마이그레이션 전략과 실제 경험

CentOS 7 AlmaLinux 9 마이그레이션 이야기가 요즘 정말 많이 나옵니다. 이유는 단순합니다. CentOS 7 EOL(End of Life, 기술지원 종료)이 이미 현실이 됐기 때문이거든요. 기존에 잘 돌아가던 서버라도 보안 업데이트가 끊기면 운영 입장에서는 그냥 두기 어렵습니다. 저도 홈랩과 업무 환경에서 비슷한 상황을 여러 번 겪었는데, 처음엔 “OS만 바꾸면 끝 아닌가?” 싶었다가 생각보다 체크할 게 많아서 삽질 좀 했습니다 ㅎㅎ

특히 이번 글은 CentOS 7에서 AlmaLinux 9로 바로 점프하는 상황을 기준으로 정리했습니다. 결론부터 말씀드리면, 저는 이런 경우 인플레이스 업그레이드(in-place upgrade, 현재 서버를 그대로 올리는 방식)보다 병행 구축 후 이전(side-by-side migration, 새 서버를 만들고 데이터와 서비스를 옮기는 방식)을 훨씬 더 추천합니다. 실제로 써보니까 이 방식이 훨씬 덜 위험하더라고요.

기존 CentOS 7 서버, 신규 AlmaLinux 9 서버, 데이터 동기화, 검증, DNS 또는 로드밸런서 전환 흐름을 한눈에 보여주는 개요 이미지입니다.

1. 왜 CentOS 7 AlmaLinux 9 마이그레이션이 중요한가

쉽게 말해 운영체제는 서버의 바닥입니다. 애플리케이션이 아무리 멀쩡해도 바닥이 낡으면 문제가 생깁니다. CentOS EOL 이후에는 보안 패치, 버그 수정, 생태계 호환성 측면에서 점점 불리해집니다. 지금 당장은 돌아가도, 어느 날 패키지 설치 하나 때문에 막히는 경우가 생겨요. 저도 예전에 오래된 저장소(repository, 패키지 보관소) 의존성 때문에 야간 작업에서 발목 잡힌 적이 있었습니다.

AlmaLinux는 RHEL(Red Hat Enterprise Linux, 레드햇 엔터프라이즈 리눅스) 계열과의 호환성을 바탕으로 운영하기 좋은 선택지입니다. 실무 관점에서는 “얼마나 화려한가”보다 얼마나 예측 가능하게 굴러가느냐가 중요하잖아요. 그런 면에서 AlmaLinux 전환은 꽤 현실적인 선택입니다.

• 보안 측면: 지원 종료 OS를 계속 쓰는 리스크를 줄일 수 있습니다.
• 운영 측면: 최신 패키지와 관리 체계를 받아들이기 쉬워집니다.
• 표준화 측면: 앞으로의 리눅스 서버 이전 작업도 훨씬 수월해집니다.

2. 개념부터 정리: 업그레이드와 마이그레이션은 다릅니다

여기서 중요한 포인트가 하나 있습니다. 많은 분들이 업그레이드와 마이그레이션을 비슷하게 보시는데, 실제 운영에서는 완전히 다르게 접근해야 합니다.

제가 직접 해보니 CentOS 7에서 AlmaLinux 9로는 새 서버를 만들고 옮기는 전략이 가장 안정적이었습니다. 이유는 간단합니다. 메이저 버전 차이가 크면 패키지 체계, 기본 설정, 런타임(runtime, 실행 환경), 보안 정책이 한꺼번에 바뀌거든요. 특히 다음 항목은 꼭 체크해야 합니다.

• yum에서 dnf: 명령 습관은 비슷하지만 운영 방식이 미묘하게 달라집니다.
• Python 2에서 Python 3: 운영 스크립트가 있다면 거의 필수 점검입니다.
• 방화벽 정책: firewalld, nftables 계열 변화에 따라 기존 iptables 습관이 그대로 안 먹히는 경우가 있습니다.
• OpenSSL/OpenSSH/PHP/MariaDB 같은 런타임 차이: 애플리케이션 호환성 검증이 필요합니다.

3. 제가 실제로 잡았던 AlmaLinux 9 마이그레이션 전략

처음엔 저도 “야간 점검 시간에 한 번에 올리면 되지 않을까?” 생각했었습니다. 근데 서비스가 조금이라도 복잡하면 그 접근이 위험하더라고요. 그래서 최종적으로는 아래 순서로 갔습니다.

1. 기존 CentOS 7 서버의 서비스 목록과 의존성 파악
2. 신규 AlmaLinux 9 서버 구축
3. 패키지, 계정, 서비스 설정 재현
4. 데이터 사전 동기화
5. 테스트 도메인 또는 hosts 기반 검증
6. 짧은 점검 시간에 최종 동기화 후 전환
7. 문제 없으면 기존 서버는 일정 기간 읽기 전용 또는 대기 상태로 유지

이 방식의 장점은 명확합니다. 언제든 이전 상태로 돌아갈 수 있다는 거예요. 드디어 됐다 싶어도 사람 일은 모르거든요. 실제 운영은 “성공”보다 “실패했을 때 얼마나 빨리 회복하느냐”가 더 중요합니다.

4. 실전 구현: CentOS 7 AlmaLinux 9 마이그레이션 준비

4-1. 기존 서버 인벤토리 정리

먼저 해야 할 일은 감으로 움직이지 않는 겁니다. 서비스 포트, 패키지, 크론(cron, 주기 실행 작업), 사용자 계정, 마운트 정보를 뽑아두세요. 저는 아래처럼 기본 자료부터 수집했습니다.

hostnamectl
cat /etc/centos-release
ip addr
ss -tulpn
rpm -qa | sort > /root/pkglist-centos7.txt
systemctl list-unit-files --type=service > /root/services-centos7.txt
crontab -l
ls -al /etc/cron.d/
getent passwd > /root/passwd.snapshot
getent group > /root/group.snapshot
df -h
mount

이 단계에서 중요한 건 “무엇이 설치돼 있는가”보다 실제로 무엇이 쓰이고 있는가입니다. 설치만 돼 있고 안 쓰는 패키지는 꽤 많습니다. 이걸 정리해두면 AlmaLinux 전환 후 서버가 훨씬 깔끔해집니다.

4-2. 신규 AlmaLinux 9 서버 기본 세팅

새 서버는 기존 서버를 그대로 복제하려 하지 말고, 필요한 것만 다시 만든다는 느낌으로 가는 게 좋습니다. 저도 처음엔 예전 설정을 몽땅 복붙했다가 SELinux(Security-Enhanced Linux, 보안 강제 정책)와 서비스 경로 차이 때문에 다시 정리했었네요.

dnf update -y
hostnamectl set-hostname new-app01.example.local
timedatectl set-timezone Asia/Seoul
dnf install -y rsync vim tar curl wget firewalld policycoreutils-python-utils
systemctl enable --now firewalld
systemctl enable --now sshd

계정과 SSH 키도 이 시점에 맞춰둡니다.

useradd -m deploy
mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chown -R deploy:deploy /home/deploy/.ssh

AlmaLinux 9 신규 서버에서 기본 패키지 설치, firewalld 활성화, 호스트명 설정이 끝난 초기 구성 단계를 보여주는 이미지입니다.

4-3. 애플리케이션 설정과 데이터 이전

데이터 이전은 보통 rsync(알싱크, 파일 동기화 도구)를 많이 씁니다. 증분 복사(incremental copy, 바뀐 부분만 다시 전송)가 가능해서 정말 편하더라고요. 서비스 종류에 따라 디렉터리만 옮길지, DB를 별도로 덤프(dump, 내보내기)할지는 달라집니다.

rsync -avzH --numeric-ids /etc/nginx/ root@new-app01:/etc/nginx/
rsync -avzH --numeric-ids /var/www/ root@new-app01:/var/www/
rsync -avzH --numeric-ids /data/ root@new-app01:/data/

DB는 파일 복사보다 논리 백업(logical backup, SQL 기반 백업) 쪽이 더 안전한 경우가 많습니다.

mysqldump --all-databases --single-transaction --routines --triggers > all.sql
scp all.sql root@new-app01:/root/
mysql < /root/all.sql

웹 서비스라면 설정 파일을 옮긴 뒤 문법 검사를 먼저 합니다.

nginx -t
apachectl configtest
systemctl daemon-reload
systemctl enable --now nginx

여기서 제가 많이 하는 방식은 운영 DNS를 바로 바꾸지 않고 hosts 파일이나 임시 도메인으로 먼저 붙어보는 것입니다. 이 단계에서 80% 문제를 잡아요.

5. ⚠️ 실제로 자주 막히는 문제와 해결법

이 섹션은 진짜 중요합니다. 문서만 보면 다 쉬워 보이는데, 실전에서는 작은 차이 때문에 시간이 녹습니다.

5-1. SELinux 때문에 서비스는 뜨는데 동작이 이상한 경우

처음엔 이게 뭔가 싶었는데, 프로세스는 살아 있는데 파일 접근이 막혀서 웹이 비정상 동작하는 경우가 있더라고요. 저는 로그부터 확인했습니다.

getenforce
ausearch -m avc -ts recent
journalctl -xe

무작정 비활성화하기보다 컨텍스트(context, 보안 레이블)를 먼저 맞춰보는 게 훨씬 낫더라고요.

restorecon -Rv /var/www
semanage fcontext -a -t httpd_sys_content_t "/data/web(/.*)?" 
restorecon -Rv /data/web

5-2. 예전 스크립트가 Python 2 기준인 경우

CentOS 7 시절에 만든 운영 스크립트가 꽤 오래 살아남는 경우가 많죠. 근데 AlmaLinux 9로 오면서 Python 3 기준으로 정리해야 할 때가 많습니다. 저도 백업 스크립트 하나가 print 문법 때문에 바로 죽어서 순간 멈칫했습니다.

• 쉘 스크립트로 대체 가능한지 먼저 검토
• Python 스크립트라면 shebang과 모듈 의존성 점검
• 가상환경(virtual environment, 독립 실행 환경) 필요 여부 확인

5-3. 방화벽 규칙이 예전과 다르게 느껴지는 경우

서비스는 정상인데 외부에서 접속이 안 되는 상황, 생각보다 흔합니다. 이럴 때는 애플리케이션만 보지 말고 포트 리슨(listen, 대기 상태) 여부, firewalld 규칙, 보안 그룹 또는 상위 네트워크 정책까지 같이 봐야 합니다.

ss -tulpn
firewall-cmd --get-active-zones
firewall-cmd --list-all
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload

5-4. 패키지 이름은 비슷한데 설정 경로가 미묘하게 다른 경우

이거 꽤 귀찮습니다. 특히 예전 블로그 글만 보고 따라 하면 안 맞는 경우가 있어요. 그래서 저는 항상 패키지 설치 후 기본 설정 파일 위치와 systemd(unit, 서비스 정의) 이름부터 확인합니다.

rpm -qc nginx
systemctl status nginx
systemctl cat nginx

마이그레이션 중 흔히 만나는 SELinux, 방화벽, 파일 동기화 문제를 점검하는 실제 운영자 시점의 트러블슈팅 이미지입니다.

6. 검증: 전환 전에 꼭 확인한 체크리스트

제가 실제로 써보니까 AlmaLinux 마이그레이션 성공 여부는 전환 직전보다 전환 전에 얼마나 검증했는가에서 갈리더라고요. 아래 체크리스트는 꼭 추천드립니다.

1. 서비스 프로세스가 정상 기동하는가
2. 기존 포트와 동일하게 리슨 중인가
3. 웹, API, 배치, DB 연결이 모두 정상인가
4. 로그 경로와 로그 로테이션(log rotation, 로그 순환)이 정상인가
5. 백업 스크립트와 크론 작업이 정상 동작하는가
6. 모니터링 대상과 알림 규칙이 새 서버에 반영됐는가
7. TLS/인증서, 권한, SELinux, 방화벽 정책이 검증됐는가

저는 간단한 검증 스크립트도 만들어서 썼습니다.

#!/bin/bash
set -e
curl -I http://127.0.0.1
systemctl is-active nginx
systemctl is-active mariadb
ss -tulpn | grep -E ":80|:443|:3306"
test -f /var/log/messages

그리고 전환 직전에는 한 번 더 최종 동기화를 했습니다.

systemctl stop nginx
rsync -avzH --delete /var/www/ root@new-app01:/var/www/
rsync -avzH --delete /etc/nginx/ root@new-app01:/etc/nginx/

이후 DNS를 바꾸거나, 로드밸런서(load balancer, 트래픽 분산 장비) 백엔드를 교체하는 식으로 컷오버(cutover, 실제 전환)를 진행했습니다.

마이그레이션 완료 후 시스템 서비스 상태, 포트 오픈 현황, 웹 응답, 기본 모니터링 지표가 정상임을 보여주는 검증 이미지입니다.

7. 결과: AlmaLinux 전환 후 체감했던 변화

결과적으로는 꽤 만족스러웠습니다. 물론 마이그레이션 자체가 즐거운 작업은 아니죠. 근데 막상 끝나고 나면 얻는 게 분명합니다.

• 지원 종료에 대한 불안감이 줄어듭니다.
• 새로운 패키지와 운영 표준으로 정리하기 쉬워집니다.
• 불필요한 설정과 레거시(legacy, 오래된 자산)를 털어낼 기회가 됩니다.
• 향후 자동화(Ansible 같은 구성관리 포함) 기반 정리가 쉬워집니다.

특히 CentOS 7 AlmaLinux 9 마이그레이션은 단순히 OS 이름만 바꾸는 일이 아니라, 운영 환경을 한 번 건강하게 정리하는 계기였습니다. 저도 처음엔 귀찮아서 미루고 싶었는데, 정리하고 나니 다음 서버도 훨씬 자신 있게 이전하게 되더라고요.

8. 정리와 FAQ: 리눅스 서버 이전 전에 꼭 기억할 것

CentOS 7 AlmaLinux 9 마이그레이션에서 제가 가장 강조하고 싶은 건 딱 세 가지입니다. 첫째, 무리해서 한 번에 올리지 말 것. 둘째, 새 서버를 만들고 검증한 뒤 전환할 것. 셋째, 롤백 경로를 미리 확보할 것. 이 세 가지만 지켜도 실패 확률이 크게 줄어듭니다.

혹시 이런 경험 있으신가요? 설정은 맞는 것 같은데 전환 후에만 이상하게 꼬이는 상황이요. 대부분은 서비스 자체보다 권한, 경로, 방화벽, 이름 해석 같은 주변 요소에서 터집니다. 그래서 저는 항상 체크리스트와 검증 스크립트를 같이 둡니다. 이거 진짜 편하더라고요.

자주 묻는 질문

• Q. 인플레이스 업그레이드보다 신규 구축이 왜 더 낫나요?
  A. 메이저 버전 차이가 큰 경우 변수도 많아집니다. 신규 구축은 검증과 롤백이 쉬워서 운영 리스크가 낮습니다.
• Q. 모든 설정 파일을 그대로 복사하면 되나요?
  A. 권장하지 않습니다. 필요한 설정만 검토해서 옮기는 편이 안전합니다.
• Q. AlmaLinux 전환 전에 가장 먼저 볼 것은 뭔가요?
  A. 서비스 의존성, 런타임 버전, 백업/복구 절차입니다.

다음 글에서는 AlmaLinux 전환 이후 체크해야 할 보안 하드닝(hardening, 보안 강화) 항목이나 Ansible 기반 자동화 이전 방법도 다뤄볼 예정입니다. 이전 글에서 다뤘던 백업 검증 루틴과 함께 보시면 더 도움이 될 겁니다.

CentOS 7과 AlmaLinux 9의 운영 차이, 추천 마이그레이션 방식, 전환 전후 체크포인트를 요약한 인포그래픽 이미지입니다.