<aside>
☁️ 클라우드웨이브 · W06 · 2/5 · 예상 읽기 6~8분
</aside>
수동으로 여러 서버를 관리할 때 가장 어려운 점은 작업 자체보다 서버마다 조금씩 달라지는 상태를 기억하는 일이었다. 어떤 호스트에는 패키지가 설치되어 있고, 다른 호스트에는 설정 파일이 오래된 채 남아 있을 수 있다. Ansible을 배우며 이 문제를 관리 대상과 원하는 상태의 언어로 바꿔 적을 수 있다는 점이 인상적이었다.
인벤토리는 호스트의 목록이면서 분류 체계다. 웹, 작업, 데이터처럼 역할별 그룹을 만들면 같은 정책을 특정 집합에 적용할 수 있다. 인벤토리의 책임은 어디에 적용할지를 알려주는 것이고, 작업의 순서를 설명하는 책임은 플레이북에 있다. 이 둘을 섞지 않으면 환경이 바뀌어도 작업 정의를 재사용하기 쉽다.
플레이북은 하나 이상의 플레이로 구성되고, 플레이는 대상과 작업을 연결한다. 작업은 모듈과 옵션을 선택한다. YAML은 읽기 쉽지만 들여쓰기가 구조를 결정하므로 작은 오탈자도 실행 결과를 바꿀 수 있다.
- name: 원하는 상태를 표현하는 예시
hosts: web_group
tasks:
- name: 패키지가 설치된 상태 보장
package:
name: example-service
state: present
절차적 스크립트는 무엇을 어떤 순서로 할지 직접 지시한다. 반면 모듈 기반 작업은 결과 상태를 표현하고, 현재 상태를 확인한 뒤 필요한 변경을 선택한다. 이미 패키지가 설치되어 있으면 다시 설치하지 않고, 파일 내용이 같으면 다시 쓰지 않는 식이다. 이것이 멱등성이다.
멱등성은 무조건 모든 작업이 한 번만 실행된다는 뜻이 아니다. 반복 실행의 결과가 안정적이어야 한다는 뜻이다. 외부 명령을 무심코 호출하면 매번 변경이 발생할 수 있으므로, 가능한 경우 전용 모듈로 상태를 표현하고 변경 여부를 분명히 해야 한다.
인벤토리와 플레이북을 분리하면 테스트 범위도 나누어 생각할 수 있다. 같은 플레이북을 학습용 그룹과 검증용 그룹에 각각 적용해 대상 선택이 맞는지 확인하고, 운영 그룹을 가리키는 순간에는 변경 계획과 승인 절차를 추가한다. 자동화 코드가 어느 범위의 호스트에 영향을 미치는지 항상 읽을 수 있게 만드는 일이 중요하다.
Kubernetes 컨트롤러도 현재 상태와 사용자가 선언한 원하는 상태를 비교하고 차이를 줄인다. Ansible은 보통 실행이 끝나면 제어가 종료되지만, Kubernetes는 컨트롤러가 계속 관찰하며 조정한다는 차이가 있다. 두 시스템을 같은 도구라고 볼 수는 없지만, 상태를 코드로 선언하고 반복 가능한 조정으로 운영 변동을 줄인다는 사고방식은 이어진다.
결국 좋은 자동화는 실행 결과만 빠르게 만드는 것이 아니라, 왜 그 결과가 나왔는지 설명할 수 있게 만든다. 대상 그룹의 의미와 작업의 성공 조건을 코드와 문서에 함께 남기면 새로운 사람이 변경 범위를 검토하기도 쉬워진다.
이 설명 가능성이 반복 운영에서 특히 중요하다.
작업을 작성하기 전에 관리 대상의 경계와 성공 상태를 먼저 적는다. 그 다음 인벤토리, 플레이북, 구성 파일을 분리하고, 반복 실행해도 변경이 불필요한 상태가 되는지 확인한다. 제어 노드와 관리 호스트를 구분하면 자동화 코드, 접근 권한, 실행 로그의 책임도 선명해진다.