RHEL 실전 #6 트랙 마무리: 레퍼런스 아키텍처
RHEL 실전 트랙을 따라오며 웹 서버, 데이터베이스, 컨테이너, 모니터링, 자동화를 한 조각씩 익혔습니다. 각 글은 하나의 주제를 처음부터 끝까지 다뤘지만, 실제 운영에서는 이 조각들이 따로 놀지 않습니다. 한 대의 서버 위에서 서로 맞물려 돌아갑니다. 트랙의 마지막인 이번 글에서는 지금까지 다룬 모든 조각을 하나의 레퍼런스 아키텍처로 묶어, 작은 웹 서비스 한 대를 RHEL 위에서 어떻게 구성하고 운영하는지 전체 그림을 그리겠습니다.
레퍼런스 아키텍처는 거창한 다이어그램이 아닙니다. 어떤 부품을 어떤 순서로 쌓고, 무엇을 영구로 고정하고, 어디를 잠그고, 무엇을 백업하는지에 대한 한 장짜리 합의입니다. 이 글을 트랙 전체의 요약이자 실무에서 바로 꺼내 쓸 체크리스트로 삼겠습니다.
한 대로 굴리는 작은 웹 서비스 #
이 트랙에서 다룬 부품을 모으면 작은 웹 서비스 한 대가 완성됩니다. 구성은 다음과 같습니다.
- nginx 프런트. 외부 요청을 받는 입구입니다. 정적 콘텐츠를 직접 내려주거나, 뒤에 있는 애플리케이션으로 요청을 전달하는 reverse proxy 역할을 합니다(#1).
- PostgreSQL 데이터 계층. 서비스의 상태를 보관하는 데이터베이스입니다. AppStream module로 설치하고 데이터 디렉터리와 SELinux 컨텍스트를 맞춥니다(#2).
- Podman 컨테이너. 애플리케이션 본체는 컨테이너로 돌립니다. quadlet으로 systemd 서비스처럼 다뤄, 부팅 시 자동으로 뜨게 합니다(#3).
- Cockpit,PCP 모니터링. 웹 콘솔로 서버 상태를 보고, PCP로 성능 지표를 수집합니다(#4).
- Ansible 자동화. 위 모든 구성을 손으로 한 번씩 하는 대신 playbook으로 코드화해, 같은 서버를 언제든 똑같이 재현합니다(#5).
이 다섯 부품이 한 서버 안에서 어떻게 층을 이루는지 그림으로 보면 다음과 같습니다.
[ 외부 사용자 ]
│
HTTPS (443)
│
┌──────────────────────┴───────────────────────┐
│ RHEL 서버 │
│ │
│ firewalld (80,443,22만 개방) │
│ SELinux enforcing (전 계층 강제) │
│ ────────────────────────────────────────── │
│ │
│ [ nginx 프런트 ] ── reverse proxy ──┐ │
│ │ │
│ [ Podman 컨테이너 ] │
│ (앱 본체) │
│ │ │
│ [ PostgreSQL ] │
│ (데이터) │
│ │
│ ────────────────────────────────────────── │
│ [ Cockpit,PCP ] 상태,성능 관측 │
│ [ Ansible ] 전체 구성을 코드로 재현 │
│ │
│ journald 영구 로그 │ chronyd 시간 동기화 │
│ 3-2-1 백업 (DB 덤프 + 설정 + 데이터 볼륨) │
└────────────────────────────────────────────────┘위에서 아래로 요청이 흐르고, 그 흐름 전체를 firewalld와 SELinux가 감싸고, 옆에서 모니터링과 자동화가 받칩니다. 한 대짜리 구성이지만 각 계층의 책임이 분명히 나뉘어 있습니다.
운영 체크리스트 #
레퍼런스 아키텍처의 핵심은 그림보다 운영 규율입니다. 트랙 전체에서 반복해서 강조한 원칙을 한 곳에 모았습니다. 새 서버를 올릴 때마다 이 목록을 위에서 아래로 점검하면 됩니다.
1. 모든 설정을 영구로 고정한다 #
런타임에만 적용된 설정은 재부팅 한 번에 사라집니다. 마운트는 /etc/fstab에, 서비스는 systemctl enable로, 방화벽은 --permanent로, SELinux boolean,포트,컨텍스트는 semanage와 setsebool -P로 영구화합니다.
# 마운트는 fstab에 등록하고 검증
sudo systemctl daemon-reload
sudo mount -a
# 서비스는 enable로 부팅 자동 시작 고정
sudo systemctl enable --now nginx postgresql
# 부팅 시 뜰 서비스 목록 확인
systemctl list-unit-files --state=enabled“지금 되는가"가 아니라 “재부팅 후에도 되는가"를 기준으로 삼습니다. 운영 중 가장 흔한 사고가 임시 설정이 재부팅과 함께 증발하는 경우입니다.
2. SELinux는 enforcing으로 유지한다 #
막힌다고 setenforce 0이나 SELINUX=disabled로 도망가지 않습니다. enforcing을 유지한 채 정책으로 풉니다. 포트는 semanage port, 파일 컨텍스트는 semanage fcontext + restorecon, 동작 허용은 setsebool -P로 처리합니다.
# enforcing 상태 확인 (반드시 Enforcing이어야 함)
getenforce
# 막혔을 때 원인 진단
sudo ausearch -m AVC -ts recentsetenforce 0은 원인이 SELinux인지 가리는 확인용으로만 잠깐 쓰고, 즉시 setenforce 1로 되돌립니다.
3. firewalld는 최소한만 연다 #
열어야 할 포트만 영구로 열고 나머지는 닫아 둡니다. 작은 웹 서비스라면 보통 22(SSH),80(HTTP),443(HTTPS) 세 개면 충분합니다.
# 필요한 서비스만 영구 허용
sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --add-service=https --permanent
sudo firewall-cmd --reload
# 열린 항목 확인
sudo firewall-cmd --list-all“일단 다 열고 나중에 잠그자"는 거의 영원히 열린 채로 남습니다. 처음부터 최소로 시작합니다.
4. 백업은 3-2-1 원칙을 지킨다 #
데이터가 3벌, 서로 다른 매체 2종, 그중 1벌은 다른 장소에 둡니다. 작은 웹 서비스에서 백업 대상은 세 가지입니다. PostgreSQL 데이터(pg_dump), 설정 파일(/etc와 컨테이너 정의), 컨테이너 데이터 볼륨입니다.
# DB 논리 백업
sudo -u postgres pg_dump appdb > /backup/appdb-$(date +%F).sql
# 설정,볼륨은 별도 매체와 원격지로 복제백업은 복원 테스트까지 해야 백업입니다. 정기적으로 복원이 되는지 확인하지 않은 백업은 백업이 아닙니다.
5. 업데이트는 dnf로 정기 적용한다 #
보안 패치를 미루지 않습니다. dnf upgrade로 정기적으로 갱신하고, 필요하면 dnf-automatic으로 보안 업데이트를 자동화합니다.
# 보안 업데이트만 미리 확인
sudo dnf updateinfo list security
# 전체 갱신
sudo dnf upgrade -y6. 로그는 journald 영구 저장으로 남긴다 #
기본 journald는 재부팅 시 로그가 휘발될 수 있습니다. /var/log/journal 디렉터리를 만들어 영구 저장으로 전환하면 부팅 이전 로그까지 추적할 수 있습니다.
# 영구 저장 디렉터리 생성 후 재시작
sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald7. 사용자는 최소 권한으로 운영한다 #
root로 직접 로그인하지 않습니다. 일반 사용자에게 필요한 만큼만 sudo를 주고, SSH는 키 인증만 허용해 비밀번호 로그인을 막습니다.
# SSH 키 등록 후 비밀번호,root 로그인 차단
# /etc/ssh/sshd_config에서
# PasswordAuthentication no
# PermitRootLogin no
sudo systemctl reload sshd권한은 줄 수 있는 최소치에서 시작해 필요할 때 늘립니다. 처음부터 넓게 주면 다시 좁히기 어렵습니다.
8. 시간은 chronyd로 동기화한다 #
로그 시각, 인증서 유효 기간, 데이터베이스 타임스탬프가 모두 시계에 의존합니다. chronyd로 시간을 동기화하고 상태를 확인합니다.
# 동기화 상태 확인
chronyc tracking
chronyc sources보안 기본기 #
위 체크리스트 중 보안에 해당하는 네 가지는 따로 묶어 강조하겠습니다. 작은 서비스라도 이 네 가지는 타협하지 않습니다.
- SELinux enforcing 유지. 애플리케이션이 해를 입어도 그 영향이 정책 경계를 넘지 못하게 막는 마지막 방벽입니다.
- firewalld 최소 개방. 공격 표면을 물리적으로 줄입니다. 닫힌 포트는 뚫릴 수 없습니다.
- SSH 키 인증. 비밀번호 무차별 대입을 원천 차단합니다. 키 인증만 남기고 비밀번호와 root 로그인을 막습니다.
- 최소 권한. 각 사용자와 서비스에 필요한 만큼만 권한을 줍니다. 사고가 나도 피해 범위를 좁힐 수 있습니다.
이 네 가지는 RHEL이 기본값으로 강하게 밀어 주는 영역이기도 합니다. 기본을 끄지 않고 그대로 살려 운영하는 것만으로도 상당한 수준의 보안을 확보합니다.
학습 경로: 실무에서 자격증까지 #
이 트랙으로 RHEL 운영의 한 사이클을 손에 익혔습니다. 다음 단계로 나아가는 길은 두 갈래입니다. 더 깊은 실무로 가거나, 자격증으로 지식을 정리하는 길입니다.
지금까지의 흐름을 정리하면 다음과 같습니다. RHEL 실무 트랙에서 systemd,SELinux,firewalld,스토리지의 기초 기능을 익혔고, 이 RHEL 실전 트랙에서 그 기능들을 엮어 실제 서비스를 운영하는 시나리오를 따라갔습니다. 이 두 단계를 거치면 자격증 준비에 필요한 실무 감각은 이미 상당 부분 갖춰진 셈입니다.
자격증은 이 감각을 체계로 정리하고 객관적으로 증명하는 수단입니다. Red Hat의 대표 자격증은 두 가지입니다.
- RHCSA. 시스템 관리자 자격증입니다. 이 트랙에서 다룬 서비스 관리, 스토리지, SELinux, 사용자,권한, 네트워크 기초가 시험 범위와 그대로 겹칩니다.
- RHCE. 자동화 엔지니어 자격증입니다. #5에서 다룬 Ansible 자동화가 핵심 주제입니다. RHCSA를 먼저 취득한 뒤 진행하는 순서입니다.
두 시험 모두 객관식이 아니라 실제 시스템을 다루는 실기 시험입니다. 이 트랙처럼 손으로 직접 구성해 본 경험이 가장 확실한 준비입니다.
트랙을 마치며 #
여기까지 RHEL 실전 트랙 여섯 글을 완주하셨습니다. 축하드립니다. 패키지 하나 설치로 끝나지 않는 RHEL 운영의 실제를, 웹 서버부터 자동화까지 한 사이클로 통과했습니다. 이제 새 서버를 받았을 때 무엇을 어떤 순서로 쌓고, 무엇을 영구로 고정하고, 어디를 잠가야 하는지에 대한 자신만의 기준이 생겼을 것입니다.
이 글의 운영 체크리스트는 트랙 전체의 압축본입니다. 실무에서 새 서버를 올릴 때마다 한 번씩 꺼내 보며 빠진 곳이 없는지 점검하시기 바랍니다.
다음 단계 #
실무와 실전을 거쳤다면 자격증으로 지식을 정리할 차례입니다. 두 자격증 트랙으로 이어집니다.
- RHCSA 트랙에서 시스템 관리자 자격증의 시험 범위를 항목별로 정리하고 실기 대비 흐름을 다루겠습니다.
- RHCE 트랙에서 Ansible 자동화 중심의 엔지니어 자격증을 RHCSA 이후 단계로 준비하는 길을 안내하겠습니다.