Red Hat Certified Engineer (RHCE) #18 시험 팁과 시간 관리

인프라 리눅스 RHEL 레드햇 자격증
11 분 소요

#1부터 #17까지 RHCE의 모든 출제 영역을 정리했습니다. 이 글은 실기 시험에 들어가기 직전 한 번 더 읽고 갈 압축본입니다. 새로운 문법은 없고, 4시간 실기를 어떻게 운영하는지와 시리즈 전체에서 가장 자주 점수를 흘리는 함정만 모았습니다. RHCE는 손으로 명령을 치는 시험이 아니라 빈 제어 노드에서 멱등성 있는 플레이북을 작성해 여러 관리 노드를 구성하는 시험이라, 같은 지식이라도 운영이 합격과 불합격을 가릅니다.

4시간 운영 전략 #

전부 자동화라 환경 세팅이 먼저다 #

RHCE가 CKA,RHCSA와 결정적으로 다른 점은 모든 작업이 한 제어 노드의 플레이북으로 수렴한다는 것입니다. 작업마다 새 클러스터로 전환하거나 다른 노드로 SSH하는 운영이 아니라, 시험 시작 직후 한 번 환경을 세팅해 두면 그 위에 작업을 계속 누적하는 구조입니다. 그래서 첫 10〜15분에 들이는 환경 세팅이 4시간 전체의 속도를 결정합니다.

단계시간행동
환경 세팅약 15분inventory,ansible.cfg,SSH 키,become,작업 디렉터리 구성, 전 호스트 ping 확인
1차 풀이약 3시간손에 익은 작업부터 task/플레이북 누적. 작성할 때마다 --syntax-check,--check
2차 풀이약 20분막혔던 작업 재시도, 멱등성이 깨지는 task 보강
검산약 20분전체 플레이북을 두 번 실행해 changed 0 확인, 영구 적용,재부팅 생존 점검

task 누적 방식으로 운영한다 #

RHCE 환경은 작업이 여러 문항으로 나뉘어도 결국 하나의 작업 디렉터리 안에서 inventory와 ansible.cfg를 공유합니다. 문항마다 별도 플레이북을 만들되, inventory,become,ssh 설정은 시작할 때 한 번 잡아 둔 ansible.cfg가 전부 가져가게 합니다. 같은 설정을 문항마다 다시 잡지 않는 것이 시간을 가장 크게 아낍니다.

환경 세팅 직후 확인 
# 작업 디렉터리에서 ansible.cfg가 인식되는지 먼저 확인
ansible --version | grep "config file"

# inventory의 모든 호스트가 응답하는지 (환경 세팅 직후 1회)
ansible all -m ping

ansible.cfg의 위치는 점수와 직결됩니다. 현재 작업 디렉터리의 ansible.cfg가 가장 먼저 읽히므로, 작업 디렉터리를 벗어나 플레이북을 실행하면 의도한 inventory,become이 적용되지 않습니다. 시작할 때 작업 디렉터리에 ansible.cfg를 두고, 그 안에서만 플레이북을 실행하는 동선을 손에 익힙니다.

ansible.cfg 
# 작업 디렉터리의 ansible.cfg (한 번만 잡아 둠)
[defaults]
inventory = ./inventory
remote_user = devops
become = true
[privilege_escalation]
become = true
become_method = sudo
become_user = root

–syntax-check와 –check를 자주 건다 #

플레이북을 다 쓰고 한 번에 실행하면, YAML 들여쓰기 사고나 모듈 인자 오류를 마지막에야 발견합니다. task를 몇 개 쓸 때마다 --syntax-check로 문법을, --check로 동작을 미리 확인하는 습관이 디버깅 시간을 크게 줄입니다.

--syntax-check와 --check 
# YAML/플레이북 문법만 빠르게 검증 (실행 안 함)
ansible-playbook play.yml --syntax-check

# 실제 변경 없이 무엇이 바뀔지 미리 봄 (dry-run)
ansible-playbook play.yml --check

# 특정 task만 빠르게 돌릴 때 tag 활용
ansible-playbook play.yml --tags web

--check는 일부 모듈에서 정확하지 않을 수 있지만, 대다수 작업에서 “이 플레이북이 무엇을 바꾸려 하는가"를 안전하게 보여 줍니다. 막히는 task는 -vvv로 상세 로그를 켜서 어느 인자에서 실패하는지 바로 짚습니다.

한 작업에 과몰입하지 않는다 #

합격선은 210/300(70%)입니다. 배점에 비해 시간이 오래 걸리는 작업은 일단 가능한 데까지 task를 만들어 두고 다음으로 넘어갑니다. 모듈 하나가 기억나지 않는 작업을 붙들다가 손에 익은 작업 여러 개를 놓치는 것이 가장 흔한 실패입니다. 모르는 모듈은 뒤에서 다룰 ansible-doc으로 푸는 길이 있으므로, 막히면 표시해 두고 진도를 먼저 뺍니다.

ansible-doc을 무기로 쓴다 #

RHCE는 인터넷이 없습니다. 로컬 man page와 ansible-doc만 허용되므로, 모르는 모듈을 푸는 능력은 곧 ansible-doc을 빠르게 읽는 능력입니다.

ansible-doc 활용 
# 모듈을 모를 때 키워드로 검색
ansible-doc -l | grep -i firewall

# 모듈의 옵션과 설명 전체
ansible-doc ansible.posix.firewalld

# 문서 하단의 EXAMPLES만 바로 보기 (가장 빠른 동선)
ansible-doc ansible.posix.firewalld | grep -A 40 EXAMPLES

운영의 핵심은 EXAMPLES를 복사해 변형하는 것입니다. 모듈 옵션을 처음부터 외워 쓰는 것이 아니라, ansible-doc 하단의 EXAMPLES 블록을 플레이북에 붙여 넣고 값만 작업 조건에 맞게 바꿉니다. FQCN(예: ansible.posix.firewalld)도 ansible-doc -l 검색 결과에 그대로 나오므로, 컬렉션 이름을 기억하지 못해도 정확한 모듈명을 찾을 수 있습니다.

설치된 collection 확인 
# 어떤 컬렉션이 설치돼 있는지 (FQCN 확인용)
ansible-galaxy collection list

system roles example 문서를 적극 활용한다 #

rhel-system-roles는 RHCE에서 자주 나오는 고배점 영역이고, 각 role의 예시 플레이북이 로컬에 설치돼 있습니다. 인터넷 없이도 /usr/share/doc 아래의 예시를 그대로 가져다 쓸 수 있어, system roles 작업은 처음부터 작성하기보다 예시를 복사해 변형하는 편이 빠르고 안전합니다.

system roles 예시 위치 확인 
# 설치된 system roles 확인
ls /usr/share/ansible/roles/

# role별 예시 플레이북과 문서 위치
ls /usr/share/doc/rhel-system-roles/

# 예를 들어 timesync(chronyd) role의 예시
ls /usr/share/doc/rhel-system-roles/timesync/

/usr/share/doc/rhel-system-roles/<role>/에는 README와 함께 바로 실행 가능한 예시 플레이북이 들어 있습니다. 작업이 “system roles로 chronyd를 구성하라"라면, 해당 예시를 복사해 NTP 서버 주소 같은 값만 작업 조건에 맞게 바꾸면 됩니다. role 변수 이름을 외울 필요 없이 README의 변수 표를 그대로 참고합니다.

멱등성을 두 번 실행으로 검증한다 #

RHCE 채점의 핵심은 같은 플레이북을 여러 번 돌려도 결과가 같은가입니다. 채점 시스템이 플레이북을 다시 실행해 멱등성을 확인하는 경우가 많으므로, 작성한 플레이북은 반드시 두 번 돌려 두 번째 실행에서 changed가 0이 되는지 확인합니다.

두 번 실행으로 멱등성 검증 
# 첫 실행: 변경이 일어남 (changed 발생)
ansible-playbook play.yml

# 두 번째 실행: 아무것도 바뀌면 안 됨 (changed=0이어야 멱등)
ansible-playbook play.yml

두 번째 실행에서 changed가 남아 있다면 그 task는 멱등하지 않습니다. 가장 흔한 원인은 command,shell 모듈입니다. 이 둘은 매번 실행되므로, 가능하면 전용 모듈로 바꾸고, 불가피하면 creates,removes나 changed_when으로 멱등성을 직접 잡습니다.

command 멱등성 제어 
# command를 쓸 수밖에 없을 때 멱등성 직접 제어
- name: 초기화 스크립트는 한 번만
  ansible.builtin.command: /opt/setup.sh
  args:
    creates: /opt/.setup_done

- name: 출력만 보는 명령은 변경 아님으로 표시
  ansible.builtin.command: cat /etc/redhat-release
  register: rel
  changed_when: false

자주 틀리는 패턴 #

실기에서 점수를 흘리는 단골 패턴입니다. 지식 부족보다 운영 실수로 잃는 점수가 더 많습니다.

1) FQCN 누락 #

최신 RHCE 환경에서는 모듈을 짧은 이름으로 쓰면 컬렉션을 찾지 못해 실패하는 경우가 있습니다. firewalld가 아니라 ansible.posix.firewalld, setup이 아니라 ansible.builtin.setup처럼 FQCN을 그대로 씁니다. 정확한 FQCN은 ansible-doc -l로 확인합니다.

FQCN으로 모듈 지정 
# 짧은 이름 대신 FQCN으로
- name: 패키지 설치
  ansible.builtin.dnf:
    name: httpd
    state: present

2) become 빠뜨림 #

root 권한이 필요한 task(패키지 설치, 서비스 제어, 시스템 파일 수정)에 become이 없으면 권한 오류로 실패합니다. ansible.cfg에 전역으로 잡아 두되, play나 task 단위로 필요한 곳을 다시 확인합니다.

play 전체 권한 상승 
- name: 시스템 구성
  hosts: webservers
  become: true   # play 전체에 권한 상승
  tasks: ...

3) command/shell 멱등성 미처리 #

command,shell은 매 실행마다 changed로 잡혀 멱등성을 깹니다. 전용 모듈로 대체하거나, 불가피하면 creates,removes,changed_when으로 제어합니다(앞 절 예시 참고). 두 번째 실행에서 이 task만 changed로 남아 있다면 채점에서 멱등성 점수를 잃습니다.

4) Vault 비밀번호 파일 누락 #

Vault로 암호화한 변수를 쓰는 플레이북은 실행할 때 비밀번호를 줘야 합니다. --ask-vault-pass를 매번 입력하기보다, 비밀번호 파일을 만들고 ansible.cfg에 경로를 등록해 두면 실수가 줄어듭니다.

ansible.cfg 
# ansible.cfg
[defaults]
vault_password_file = ./vault_pass.txt
변수 파일 암호화와 편집 
# 변수 파일 암호화/편집
ansible-vault encrypt secret.yml
ansible-vault edit secret.yml

5) mount는 state=mounted #

파일시스템 마운트 작업에서 state: present는 /etc/fstab 항목만 추가하고 지금 마운트하지는 않습니다. 시험은 보통 “지금 마운트되고 재부팅 후에도 유지"를 요구하므로 state: mounted를 씁니다. present와 mounted의 차이를 혼동하면 영구 적용 점수를 잃습니다.

state mounted로 영구 마운트 
- name: NFS를 지금 마운트하고 fstab에도 등록
  ansible.posix.mount:
    path: /mnt/data
    src: nfs.example.com:/export
    fstype: nfs
    state: mounted   # present는 fstab만, mounted는 지금+영구

6) handler notify 이름 불일치 #

notify에 적은 이름과 handler의 name이 한 글자라도 다르면 handler가 호출되지 않아 서비스가 재시작되지 않습니다. 설정을 바꿨는데 반영이 안 되는 단골 원인입니다. 둘을 복사해 정확히 일치시킵니다.

notify와 handler 이름 일치 
tasks:
  - name: 설정 배포
    ansible.builtin.template:
      src: httpd.conf.j2
      dest: /etc/httpd/conf/httpd.conf
    notify: restart httpd   # 아래 handler name과 정확히 일치해야 함

handlers:
  - name: restart httpd
    ansible.builtin.service:
      name: httpd
      state: restarted

7) –syntax-check를 안 함 #

플레이북을 작성하고 바로 실행하면 YAML 들여쓰기나 모듈 인자 오류를 실행 중에야 만납니다. task 몇 개마다 --syntax-check로 문법을, --check로 동작을 미리 검증하는 두 단계를 습관으로 묶어 둡니다.

8) ansible.cfg 위치 혼동 #

작업 디렉터리 밖에서 플레이북을 실행하면 의도한 ansible.cfg가 읽히지 않아 inventory,become,remote_user가 빠집니다. 모든 플레이북은 ansible.cfg가 있는 작업 디렉터리 안에서 실행하고, ansible --version의 config file 줄로 어느 설정이 읽히는지 확인합니다.

헷갈리는 개념 쌍 #

작업 중 순간적으로 헷갈리기 쉬운 쌍을 한 줄 차이로 압축합니다.

쌍한 줄 차이
state present vs mountedfstab 항목만 추가(지금 마운트 안 함) vs 지금 마운트하고 fstab에도 등록
import vs include정적: 파싱 시점에 전개(tag,handler가 미리 보임) vs 동적: 실행 시점에 전개(when으로 통째 제어)
copy vs template파일을 그대로 복사 vs Jinja2 변수를 치환해 렌더링 후 배포
become vs remote_usersudo로 권한 상승(주로 root) vs SSH 접속 계정 지정
changed_when vs failed_when변경 여부를 직접 판정 vs 실패 여부를 직접 판정
ansible-playbook vs ansible-navigator전통적 실행기(가벼움) vs execution environment 컨테이너 실행기(run -m stdout)

import_*와 include_*는 전개 시점이 다릅니다. import는 플레이북을 읽는 시점에 정적으로 펼쳐져 task의 tag와 handler가 미리 보이는 반면, include는 실행 도중 동적으로 펼쳐져 when,loop로 블록 전체를 조건부로 제어할 수 있습니다. 변수가 실행 중에 정해지는 동적 상황이면 include, 그 외에는 import가 무난합니다.

copy와 template는 변수 치환 여부가 갈림입니다. 호스트마다 값이 달라야 하는 설정 파일은 template로 Jinja2를 렌더링하고, 내용이 고정인 파일은 copy로 그대로 보냅니다. 시험에서 “호스트별로 다른 값"이라는 조건이 보이면 template입니다.

영역별 응시 직전 체크리스트 #

각 영역에서 손이 바로 나와야 하는 핵심 모듈과 절차입니다.

환경과 inventory, 연결 #

  • inventory: static 호스트,그룹, group_vars,host_vars 분리
  • ansible.cfg: 작업 디렉터리에 두고 inventory,remote_user,become 등록
  • 연결 확인: ansible all -m ping, ansible --version의 config file 줄
  • ad-hoc: ansible <host> -m <module> -a "..."로 즉석 확인

플레이북과 변수, 템플릿 #

  • 멱등성: 모듈 우선, command/shell은 creates,changed_when
  • 변수 우선순위, setup(fact),ansible_facts, custom facts
  • template: Jinja2 필터,when,loop, copy와 구분
  • handler: notify이름과 handler name 정확히 일치

제어 흐름과 오류 처리, 보안 #

  • block/rescue/always, failed_when,ignore_errors
  • when,loop,until, tags로 부분 실행
  • Vault: ansible-vault encrypt/edit, vault_password_file 등록

role과 collection, system roles #

  • role 구조(tasks,handlers,defaults,templates), ansible-galaxy init
  • collection: ansible-galaxy collection list로 FQCN 확인
  • system roles: /usr/share/doc/rhel-system-roles/<role>/ 예시 복사

RHCSA 작업 자동화 (비중 절반) #

  • 사용자,그룹,패키지,repository: user,group,dnf,yum_repository
  • 서비스,chronyd,log: service,timesync role,logrotate
  • 스토리지,파일시스템: lvg,lvol,filesystem,mount(state=mounted)
  • firewall,SELinux,SSH 키: firewalld,seboolean,sefcontext,authorized_key

Remote Exam 응시 직전 점검 #

RHCE는 시험장(Kiosk) 또는 Red Hat Remote Exam으로 응시합니다. 시작 전에 다음을 확인합니다.

신분증 #

  • 영문 표기가 있는 신분증(여권 권장), 이름이 등록 정보와 정확히 일치
  • 감독관 안내에 따라 신분증을 카메라에 제시

응시 환경 #

  • 책상 위 모든 물건 치움, 벽면 메모,포스터 제거
  • 단일 모니터 사용, 보조 화면 분리
  • 외부인 출입 차단, 조용한 단독 공간 확보

시스템과 시작 직후 #

  • 제공되는 라이브 이미지를 USB로 부팅, 안정적인 유선 네트워크
  • 시작 직후 작업 디렉터리,inventory,ansible.cfg,SSH 키,become 세팅
  • 첫 task 전 ansible all -m ping으로 전 호스트 연결 확인

정리 #

이 글에서 잡은 것:

  • 4시간 운영. 전부 자동화라 환경 세팅이 먼저. 한 디렉터리에 task 누적, 작성할 때마다 --syntax-check,--check, 과몰입 금지
  • ansible-doc을 무기로. 인터넷 없음. ansible-doc -l로 모듈 검색, EXAMPLES 복사해 변형, ansible-galaxy collection list로 FQCN 확인
  • system roles 예시. /usr/share/doc/rhel-system-roles/<role>/의 예시 플레이북을 복사해 값만 변경
  • 멱등성. 두 번 실행해 changed 0 확인. command/shell은 creates,changed_when으로 제어
  • 단골 실수. FQCN 누락, become 빠뜨림, command 멱등성, Vault 비밀번호 파일, mount state=mounted, handler 이름 불일치, syntax-check 생략, ansible.cfg 위치
  • 헷갈리는 개념 쌍(present/mounted, import/include, copy/template), 영역별 체크리스트, Remote Exam 점검

다음: 풀스케일 모의고사 #

마지막 글입니다.

#19 풀스케일 모의고사 (Ansible 통합 시나리오 + 해설)에서는 실제 시험과 비슷한 영역 분포로 통합 시나리오를 플레이북으로 풀고 상세 해설을 답니다. 4시간을 재며 풀어 보고, 멱등성과 영구 적용을 점검하며 비중 큰 RHCSA 자동화 영역을 한 번 더 다지는 마지막 단계입니다.

X