Ansible Ad-hoc 명령어 실습 완벽 가이드

Ansible의 Ad-hoc 명령어를 통해 즉각적인 서버 관리 작업을 수행하는 방법을 배웁니다. 플레이북 없이도 빠르게 여러 서버를 제어할 수 있는 실전 기술을 익혀봅니다.

---

목차

1. ansible 명령어 기본 구조
2. 핑(ping) 모듈로 연결 테스트
3. 파일 복사 및 관리
4. 패키지 설치하기
5. 서비스 제어
6. 실용적인 Ad-hoc 예제

---

1. ansible 명령어 기본 구조

김개발 씨는 오늘 아침 출근하자마자 팀장님께 급한 요청을 받았습니다. "개발 서버 10대의 디스크 용량을 확인해야 하는데, 하나씩 접속하면 시간이 너무 오래 걸릴 것 같아요." 박시니어 씨가 옆에서 말합니다.

"Ansible Ad-hoc 명령어를 쓰면 10초면 끝나요."

Ad-hoc 명령어는 플레이북을 작성하지 않고도 즉시 실행할 수 있는 Ansible의 일회성 명령입니다. 마치 여러 서버에 동시에 손을 뻗어 작업을 수행하는 것과 같습니다.

긴급한 서버 점검이나 간단한 설정 변경에 매우 유용합니다.

다음 코드를 살펴봅시다.

# 기본 구조: ansible [호스트그룹] -m [모듈] -a "[모듈인자]"

# 웹서버 그룹의 모든 호스트에 ping 테스트
ansible webservers -m ping

# 특정 서버에 명령어 실행
ansible server1 -m shell -a "df -h"

# 모든 서버에 패키지 설치 (become으로 권한 상승)
ansible all -m apt -a "name=vim state=present" --become

# 여러 옵션을 함께 사용
ansible dbservers -m service -a "name=postgresql state=started" --become -u deploy

김개발 씨는 리눅스 서버 관리 업무를 맡은 지 2개월째입니다. 처음에는 서버 한 대씩 SSH로 접속해서 작업했습니다.

하지만 관리해야 할 서버가 늘어나면서 같은 작업을 반복하는 시간이 점점 길어졌습니다. 어느 날 팀장님이 급하게 찾아왔습니다.

"김개발 씨, 개발 서버 전체의 디스크 용량을 확인해서 보고해 주세요. 30분 안에요." 김개발 씨는 당황했습니다.

서버가 10대나 되는데 하나씩 접속하면 시간이 부족할 것 같았습니다. 바로 그때 옆자리의 박시니어 씨가 다가왔습니다.

"Ad-hoc 명령어 쓰면 10초면 돼요. 제가 보여드릴게요." Ad-hoc 명령어란 정확히 무엇일까요?

쉽게 비유하자면, Ad-hoc 명령어는 마치 확성기로 여러 사람에게 동시에 지시를 내리는 것과 같습니다. 일일이 한 명씩 찾아가서 말하는 대신, 한 번에 모든 사람이 듣도록 만드는 것입니다.

Ansible의 Ad-hoc 명령어도 이처럼 여러 서버에 동시에 명령을 전달합니다. Ansible을 사용하기 전에는 어땠을까요?

운영팀 개발자들은 bash 스크립트를 작성하거나 for 반복문으로 서버 목록을 돌면서 하나씩 SSH 명령을 실행했습니다. 코드가 복잡해지고, 에러 처리도 어려웠습니다.

더 큰 문제는 어떤 서버에서 성공하고 어떤 서버에서 실패했는지 추적하기가 힘들다는 점이었습니다. 바로 이런 문제를 해결하기 위해 Ansible Ad-hoc 명령어가 등장했습니다.

Ad-hoc 명령어를 사용하면 단 한 줄의 명령으로 수십, 수백 대의 서버를 동시에 제어할 수 있습니다. 또한 각 서버의 실행 결과를 명확하게 보여줍니다.

무엇보다 SSH 키 기반 인증으로 안전하게 작업을 수행할 수 있다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

첫 번째 예제를 보면 ansible webservers -m ping 명령을 사용합니다. 여기서 webservers는 인벤토리 파일에 정의된 호스트 그룹이고, -m ping은 ping 모듈을 사용한다는 의미입니다.

다음 예제에서 -a 옵션은 모듈에 전달할 인자를 지정합니다. 마지막으로 --become 옵션은 sudo 권한으로 실행한다는 뜻입니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 전자상거래 회사에서 새벽에 긴급 보안 패치가 발표되었다고 가정해봅시다.

100대의 웹서버에 즉시 패치를 적용해야 합니다. Ansible Ad-hoc 명령어를 사용하면 단 한 줄로 모든 서버에 패키지를 업데이트하고, 서비스를 재시작할 수 있습니다.

AWS, 네이버클라우드, 카카오 등 많은 기업에서 이런 패턴을 적극적으로 사용하고 있습니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 프로덕션 서버에서 바로 Ad-hoc 명령어를 실행하는 것입니다. 잘못된 명령어는 돌이킬 수 없는 결과를 낳을 수 있습니다.

따라서 먼저 개발 환경이나 스테이징 환경에서 충분히 테스트한 후 사용해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 이렇게 간단하게 할 수 있었군요!" Ad-hoc 명령어의 기본 구조를 제대로 이해하면 긴급한 서버 작업도 빠르고 안전하게 처리할 수 있습니다.

여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - --check 옵션을 사용하면 실제 실행 없이 결과를 미리 확인할 수 있습니다

• -v, -vv, -vvv 옵션으로 상세한 실행 로그를 볼 수 있습니다
• 복잡한 작업은 Ad-hoc보다 플레이북을 작성하는 것이 좋습니다

---

2. 핑(ping) 모듈로 연결 테스트

점심시간이 끝나고 김개발 씨는 새로 추가된 서버 5대의 Ansible 연결을 확인해야 했습니다. 박시니어 씨가 말합니다.

"먼저 ping 모듈로 연결부터 테스트해 보세요. 네트워크 ping이 아니라 Ansible 연결 상태를 확인하는 거예요."

ping 모듈은 Ansible이 대상 서버에 정상적으로 접속할 수 있는지 확인하는 가장 기본적인 테스트 도구입니다. 마치 전화를 걸어서 상대방이 받는지 확인하는 것처럼, 서버가 Ansible 명령을 받을 준비가 되어 있는지 점검합니다.

네트워크 ICMP ping과는 다른 개념입니다.

다음 코드를 살펴봅시다.

# 단일 호스트 연결 테스트
ansible server1 -m ping

# 호스트 그룹 전체 테스트
ansible webservers -m ping

# 모든 인벤토리 호스트 테스트
ansible all -m ping

# 특정 사용자로 연결 테스트
ansible dbservers -m ping -u deploy

# 연결 결과 예시
# server1 | SUCCESS => {
#     "changed": false,
#     "ping": "pong"
# }

김개발 씨는 오늘 새로 프로비저닝된 서버 5대를 인벤토리에 추가했습니다. 인프라팀에서 "SSH 키 설정 완료했습니다"라는 메시지를 받았지만, 정말 Ansible로 접속이 되는지 확신이 서지 않았습니다.

"일단 하나씩 SSH로 접속해서 확인해볼까?" 김개발 씨가 터미널을 열려는 순간, 박시니어 씨가 지나가다 말했습니다. "ping 모듈 써보세요.

한 번에 다 확인돼요." 그렇다면 ping 모듈이란 정확히 무엇일까요? 쉽게 비유하자면, ping 모듈은 마치 출석 체크와 같습니다.

선생님이 이름을 부르면 학생들이 "네"라고 대답하는 것처럼, Ansible이 서버를 호출하면 서버가 "pong"이라고 응답합니다. 이 과정에서 SSH 연결, 인증, Python 실행 환경 등 모든 것이 정상인지 확인됩니다.

ping 모듈이 없다면 어떻게 해야 할까요? 예전에는 개발자들이 bash 스크립트로 서버 목록을 읽어서 하나씩 ssh 명령을 실행하고, 종료 코드를 확인했습니다.

서버가 많아지면 이 작업만으로도 상당한 시간이 걸렸습니다. 더 큰 문제는 어떤 서버에서 연결이 실패했는지 로그를 일일이 확인해야 한다는 점이었습니다.

바로 이런 문제를 해결하기 위해 Ansible ping 모듈이 등장했습니다. ping 모듈을 사용하면 한 번의 명령으로 모든 서버의 연결 상태를 확인할 수 있습니다.

또한 각 서버의 응답을 색상으로 구분해서 보여주므로 성공과 실패를 한눈에 파악할 수 있습니다. 무엇보다 실제 작업을 수행하기 전에 인프라 상태를 점검할 수 있다는 큰 이점이 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. 첫 번째 줄을 보면 ansible server1 -m ping 명령을 실행합니다.

이것이 가장 기본적인 형태입니다. 세 번째 예제의 ansible all -m ping은 인벤토리에 등록된 모든 호스트를 테스트합니다.

네 번째 예제에서 -u deploy 옵션은 deploy 사용자로 접속을 시도합니다. 마지막 주석 부분에서 SUCCESS와 pong 응답을 확인할 수 있습니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 IDC 센터에 새로운 서버 랙을 설치했다고 가정해봅시다.

네트워크 팀에서 "모든 서버 설정 완료"라고 보고했지만, 실제로 Ansible Automation이 동작하는지는 별개의 문제입니다. 이때 ping 모듈로 전체 서버를 한 번에 테스트하면 즉시 문제를 발견할 수 있습니다.

쿠팡, 토스 같은 대규모 서비스 기업에서는 서버 추가 시 항상 이 단계를 거칩니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 네트워크 ping(ICMP)과 Ansible ping을 혼동하는 것입니다. 네트워크 ping이 성공해도 Ansible ping은 실패할 수 있습니다.

SSH 인증 문제, Python 미설치, 방화벽 설정 등 다양한 원인이 있기 때문입니다. 따라서 Ansible ping은 더 포괄적인 연결 테스트라고 이해해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. ansible all -m ping 명령을 실행한 김개발 씨는 놀랐습니다.

5대 중 4대는 SUCCESS로 초록색으로 표시되었지만, 1대는 UNREACHABLE로 빨간색이었습니다. "박시니어님, 한 대가 연결이 안 되는데요?" "그럼 그 서버만 따로 SSH 접속해서 확인하면 되죠.

나머지 4대는 정상이니까 작업 진행하세요." ping 모듈을 제대로 사용하면 인프라 문제를 조기에 발견하고 시간을 절약할 수 있습니다. 여러분도 서버 작업 전에 항상 ping 테스트를 습관화해 보세요.

실전 팁

💡 - ping 실패 시 -vvv 옵션으로 상세 로그를 확인하면 원인을 찾기 쉽습니다

• --timeout 옵션으로 응답 대기 시간을 조절할 수 있습니다
• 대규모 인벤토리는 --forks 옵션으로 병렬 처리 수를 늘려 속도를 높일 수 있습니다

---

3. 파일 복사 및 관리

오후 회의에서 팀장님이 말했습니다. "nginx 설정 파일을 웹서버 20대에 모두 배포해야 해요.

지금 당장요." 김개발 씨는 scp 명령어를 20번 실행할 생각에 한숨이 나왔습니다. 박시니어 씨가 웃으며 말합니다.

"copy 모듈 하나면 끝나요."

copy 모듈은 로컬 파일을 원격 서버로 복사하는 가장 많이 사용되는 Ansible 모듈입니다. 마치 복사기로 문서를 여러 장 찍어내듯이, 하나의 파일을 여러 서버에 동시에 배포할 수 있습니다.

권한 설정, 백업 옵션 등 다양한 기능을 제공합니다.

다음 코드를 살펴봅시다.

# 단일 파일 복사
ansible webservers -m copy -a "src=/etc/nginx/nginx.conf dest=/etc/nginx/nginx.conf"

# 권한과 소유자 지정
ansible webservers -m copy -a "src=./app.conf dest=/etc/app/app.conf owner=www-data group=www-data mode=0644" --become

# 백업 옵션 사용 (기존 파일 백업)
ansible all -m copy -a "src=./config.yaml dest=/opt/app/config.yaml backup=yes" --become

# 디렉토리 생성 후 파일 복사
ansible dbservers -m file -a "path=/opt/backup state=directory mode=0755" --become
ansible dbservers -m copy -a "src=./backup.sh dest=/opt/backup/backup.sh mode=0755" --become

김개발 씨는 nginx 설정 파일을 수정했습니다. 로컬에서 테스트도 끝났습니다.

이제 프로덕션 웹서버 20대에 이 파일을 배포해야 합니다. "어떻게 하지?" 김개발 씨는 터미널을 켜고 첫 번째 서버에 scp 명령을 입력했습니다.

그리고 두 번째 서버, 세 번째 서버... "이렇게 20번을 반복해야 하나?" 손가락이 아파오기 시작했습니다.

바로 그때 박시니어 씨가 지나가다 물었습니다. "뭐 하세요?" "설정 파일 배포하는데, 서버가 20대나 돼서요." "아, copy 모듈 쓰면 1초면 끝나는데요." 그렇다면 copy 모듈이란 정확히 무엇일까요?

쉽게 비유하자면, copy 모듈은 마치 우편물을 여러 주소로 동시에 보내는 것과 같습니다. 편지를 한 통 쓰면 우체국에서 복사해서 모든 수신자에게 배달해주는 것처럼, Ansible도 파일 하나를 여러 서버에 동시에 전송합니다.

우편물과 달리 전송 속도도 매우 빠르고, 각 서버의 전송 성공 여부도 즉시 확인할 수 있습니다. copy 모듈이 없던 시절에는 어땠을까요?

시스템 관리자들은 for 루프와 scp를 조합한 쉘 스크립트를 작성했습니다. 하지만 중간에 한 서버라도 실패하면 전체 스크립트가 멈추거나, 어떤 서버에 복사가 안 됐는지 추적하기 어려웠습니다.

더 큰 문제는 파일 권한이나 소유자를 변경하려면 추가로 ssh 명령을 실행해야 한다는 점이었습니다. 바로 이런 문제를 해결하기 위해 Ansible copy 모듈이 등장했습니다.

copy 모듈을 사용하면 한 번의 명령으로 여러 서버에 파일을 배포할 수 있습니다. 또한 파일 권한, 소유자, 그룹을 동시에 설정할 수 있습니다.

무엇보다 backup=yes 옵션으로 기존 파일을 자동으로 백업해주므로 안전하게 작업할 수 있다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

첫 번째 예제를 보면 src와 dest 옵션을 지정합니다. src는 로컬 파일 경로, dest는 원격 서버의 목적지 경로입니다.

두 번째 예제에서는 owner, group, mode 옵션으로 파일 소유권과 권한을 설정합니다. 세 번째 예제의 backup=yes는 기존 파일이 있으면 .backup 확장자를 붙여 보관합니다.

마지막 예제는 file 모듈로 먼저 디렉토리를 만들고, copy 모듈로 파일을 복사하는 두 단계 작업입니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 금융권 시스템에서 보안 정책이 변경되어 새로운 SSL 인증서를 배포해야 한다고 가정해봅시다. 100대의 애플리케이션 서버에 인증서 파일과 키 파일을 복사하고, 권한을 600으로 설정하고, 소유자를 특정 계정으로 바꿔야 합니다.

copy 모듈 하나로 이 모든 작업을 동시에 처리할 수 있습니다. 삼성SDS, LG CNS 같은 대기업 SI 회사에서도 이런 방식으로 대규모 배포를 진행합니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 대용량 파일을 copy 모듈로 전송하는 것입니다.

copy 모듈은 매번 파일 전체를 전송하므로 큰 파일은 시간이 오래 걸립니다. 이런 경우에는 synchronize 모듈이나 rsync를 사용하는 것이 더 효율적입니다.

또한 dest 경로의 디렉토리가 없으면 에러가 발생하므로, file 모듈로 먼저 디렉토리를 생성해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨가 알려준 대로 copy 모듈을 실행했습니다. 단 1초 만에 20대의 서버 모두 SUCCESS 메시지가 나타났습니다.

"와, 정말 빠르네요!" "그렇죠? 이제 nginx 재시작만 하면 끝이에요.

그것도 Ad-hoc으로 할 수 있어요." copy 모듈을 제대로 이해하면 설정 파일 배포, 스크립트 배포, 인증서 갱신 등 다양한 작업을 빠르게 처리할 수 있습니다. 여러분도 반복적인 파일 복사 작업에 copy 모듈을 활용해 보세요.

실전 팁

💡 - validate 옵션으로 복사 전 파일 문법을 검증할 수 있습니다 (nginx -t 등)

• remote_src=yes 옵션을 사용하면 원격 서버 내부에서 파일을 복사합니다
• 큰 파일은 synchronize 모듈을 사용하는 것이 더 빠릅니다

---

4. 패키지 설치하기

신규 프로젝트를 위해 모든 서버에 Docker를 설치해야 한다는 공지가 떴습니다. 김개발 씨는 한숨을 쉬었습니다.

"또 하나씩 접속해서 apt install 해야 하나..." 박시니어 씨가 커피를 마시며 말합니다. "apt 모듈 쓰면 회의 시작 전에 다 끝나요."

apt 모듈은 Debian/Ubuntu 계열 리눅스에서 패키지를 설치, 업데이트, 삭제할 수 있는 모듈입니다. 마치 앱스토어에서 여러 기기에 동시에 앱을 설치하는 것처럼, 여러 서버에 동일한 소프트웨어를 한 번에 설치할 수 있습니다.

yum, dnf 등 다른 패키지 매니저도 비슷한 모듈이 있습니다.

다음 코드를 살펴봅시다.

# 단일 패키지 설치
ansible webservers -m apt -a "name=nginx state=present" --become

# 특정 버전 설치
ansible dbservers -m apt -a "name=postgresql-14 state=present" --become

# 여러 패키지 동시 설치
ansible all -m apt -a "name=vim,curl,wget,htop state=present" --become

# 패키지 업데이트 및 최신 버전 유지
ansible webservers -m apt -a "name=nginx state=latest update_cache=yes" --become

# 패키지 삭제
ansible testservers -m apt -a "name=apache2 state=absent" --become

# 시스템 전체 패키지 업데이트 (apt update && apt upgrade)
ansible all -m apt -a "update_cache=yes upgrade=dist" --become

김개발 씨는 아침 일찍 메일을 확인했습니다. "금주 내 모든 개발/스테이징 서버에 Docker 설치 필수" 개발 서버만 15대, 스테이징 서버가 10대입니다.

총 25대의 서버에 일일이 접속해서 패키지를 설치해야 한다니, 생각만 해도 막막했습니다. "으, 이거 하루 종일 걸리겠는데..." 김개발 씨가 중얼거리자 박시니어 씨가 돌아봤습니다.

"뭐가요?" "Docker를 25대 서버에 설치해야 해서요." "apt 모듈 쓰면 5분이면 끝나는데요?" 그렇다면 apt 모듈이란 정확히 무엇일까요? 쉽게 비유하자면, apt 모듈은 마치 단체 주문과 같습니다.

회사에서 직원 50명의 노트북에 동일한 소프트웨어를 설치해야 할 때, 한 사람씩 설치하는 대신 IT 관리자가 일괄 배포하는 것과 같습니다. Ansible의 apt 모듈도 이처럼 여러 서버에 동일한 패키지를 동시에 설치하고 관리합니다.

apt 모듈이 없던 시절에는 어떻게 했을까요? 시스템 관리자들은 쉘 스크립트로 서버 목록을 읽어서 하나씩 ssh로 접속한 뒤 apt-get install 명령을 실행했습니다.

하지만 어떤 서버는 인터넷이 느려서 시간이 오래 걸리고, 어떤 서버는 이미 설치되어 있어서 불필요한 경고 메시지가 나왔습니다. 더 큰 문제는 설치 과정에서 사용자 입력을 요구하는 경우 스크립트가 멈춰버린다는 점이었습니다.

바로 이런 문제를 해결하기 위해 Ansible apt 모듈이 등장했습니다. apt 모듈을 사용하면 여러 서버에 동시에 패키지를 설치할 수 있습니다.

또한 idempotent(멱등성) 특성이 있어서, 이미 설치된 패키지는 재설치하지 않고 건너뜁니다. 무엇보다 DEBIAN_FRONTEND=noninteractive 설정이 자동으로 적용되어 사용자 입력 없이 자동으로 설치가 진행된다는 큰 이점이 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. 첫 번째 줄을 보면 state=present 옵션이 패키지 설치를 의미합니다.

세 번째 예제처럼 name에 콤마로 구분된 여러 패키지를 지정할 수 있습니다. 네 번째 예제의 state=latest는 항상 최신 버전으로 업데이트하라는 뜻이고, update_cache=yes는 apt update를 먼저 실행하는 옵션입니다.

다섯 번째 예제에서 state=absent는 패키지를 삭제합니다. 마지막 예제의 upgrade=dist는 시스템 전체 업그레이드를 수행합니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 스타트업에서 새로운 마이크로서비스 아키텍처로 전환한다고 가정해봅시다.

50대의 신규 서버에 Docker, Docker Compose, Kubernetes 클라이언트, 모니터링 에이전트 등 표준 스택을 설치해야 합니다. 예전에는 이 작업만 이틀이 걸렸지만, Ansible apt 모듈을 사용하면 30분 이내에 모든 서버 설정이 완료됩니다.

배달의민족, 당근마켓 같은 빠르게 성장하는 스타트업에서는 이런 자동화가 필수입니다. 하지만 주의할 점도 있습니다.

초보 개발자들이 흔히 하는 실수 중 하나는 --become 옵션을 빼먹는 것입니다. 패키지 설치는 sudo 권한이 필요하므로 반드시 --become을 사용해야 합니다.

또한 CentOS나 RedHat 계열에서는 apt 대신 yum 또는 dnf 모듈을 사용해야 합니다. 운영체제에 맞는 패키지 매니저를 선택하는 것이 중요합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨가 알려준 명령어를 실행했습니다.

ansible all -m apt -a "name=docker.io state=present" --become 25대의 서버에서 동시에 Docker 설치가 시작되었습니다. 몇 분 후 모든 서버에서 SUCCESS 메시지가 출력되었습니다.

"와, 정말 5분도 안 걸렸어요!" "그렇죠. 이제 docker -v로 버전 확인도 Ad-hoc으로 해보세요." 김개발 씨는 ansible all -m shell -a "docker -v" 명령을 실행했고, 모든 서버에서 동일한 Docker 버전이 설치된 것을 확인했습니다.

apt 모듈을 제대로 이해하면 서버 초기 설정, 보안 패치 적용, 소프트웨어 버전 통일 등 다양한 작업을 자동화할 수 있습니다. 여러분도 반복적인 패키지 설치 작업을 Ansible로 자동화해 보세요.

실전 팁

💡 - autoremove=yes 옵션으로 불필요한 의존성 패키지를 자동 삭제할 수 있습니다

• cache_valid_time 옵션으로 캐시 갱신 빈도를 조절할 수 있습니다
• CentOS/RHEL에서는 yum 또는 dnf 모듈을 사용하세요

---

5. 서비스 제어

nginx 설정을 변경한 김개발 씨는 이제 서비스를 재시작해야 했습니다. "또 20대 서버에 하나씩 접속해서 systemctl restart 해야 하나요?" 박시니어 씨가 웃으며 답합니다.

"service 모듈로 한 방에 재시작하세요."

service 모듈은 서비스의 시작, 중지, 재시작, 활성화/비활성화를 제어하는 모듈입니다. 마치 TV 리모컨으로 여러 기기를 동시에 켜고 끄듯이, 여러 서버의 데몬 프로세스를 한 번에 관리할 수 있습니다.

systemd, init.d, upstart 등 다양한 init 시스템을 자동으로 인식합니다.

다음 코드를 살펴봅시다.

# 서비스 시작
ansible webservers -m service -a "name=nginx state=started" --become

# 서비스 중지
ansible webservers -m service -a "name=apache2 state=stopped" --become

# 서비스 재시작 (설정 변경 후)
ansible webservers -m service -a "name=nginx state=restarted" --become

# 서비스 재로드 (다운타임 없이 설정 적용)
ansible webservers -m service -a "name=nginx state=reloaded" --become

# 부팅 시 자동 시작 활성화
ansible dbservers -m service -a "name=postgresql state=started enabled=yes" --become

# 서비스 상태 확인 (systemd)
ansible all -m systemd -a "name=docker state=started" --become

김개발 씨는 nginx 설정 파일을 모든 웹서버에 배포했습니다. 이제 마지막 단계만 남았습니다.

바로 nginx 서비스를 재시작하는 것입니다. "휴, 이제 또 20번 접속해서 systemctl restart nginx를 해야 하나..." 김개발 씨가 한숨을 쉬자 박시니어 씨가 말했습니다.

"아직도 수작업으로 하시게요? service 모듈 쓰세요." 그렇다면 service 모듈이란 정확히 무엇일까요?

쉽게 비유하자면, service 모듈은 마치 스마트홈 시스템과 같습니다. 집에 있는 모든 전등, 에어컨, TV를 일일이 조작하는 대신, 스마트폰 하나로 한꺼번에 제어하는 것과 같습니다.

Ansible의 service 모듈도 이처럼 여러 서버의 데몬 서비스를 중앙에서 통합 관리합니다. service 모듈이 없던 시절에는 어떻게 했을까요?

운영팀은 bash 스크립트로 서버 목록을 순회하면서 ssh로 systemctl 명령을 실행했습니다. 하지만 어떤 서버는 systemd를, 어떤 서버는 구형 init.d를 사용해서 명령어를 다르게 작성해야 했습니다.

더 큰 문제는 서비스 재시작 중에 에러가 발생했는지, 정상적으로 시작되었는지 확인하기 어렵다는 점이었습니다. 바로 이런 문제를 해결하기 위해 Ansible service 모듈이 등장했습니다.

service 모듈을 사용하면 여러 서버의 서비스를 동시에 제어할 수 있습니다. 또한 각 서버의 init 시스템을 자동으로 감지해서 적절한 명령을 실행합니다.

무엇보다 멱등성이 보장되어 이미 실행 중인 서비스에 state=started를 실행해도 불필요한 재시작이 일어나지 않는다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

첫 번째 줄을 보면 state=started 옵션이 서비스를 시작합니다. 세 번째 예제의 state=restarted는 서비스를 완전히 재시작합니다.

네 번째 예제의 state=reloaded는 프로세스를 재시작하지 않고 설정만 다시 읽어옵니다. 이것은 무중단 설정 변경에 유용합니다.

다섯 번째 예제에서 enabled=yes는 서버 재부팅 시 자동으로 서비스가 시작되도록 설정합니다. 마지막 예제의 systemd 모듈은 systemd 전용 기능을 사용할 때 선택합니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 전자상거래 사이트에서 프로모션 이벤트를 준비한다고 가정해봅시다.

트래픽 급증에 대비해 웹서버 100대의 nginx worker_processes 설정을 변경했습니다. 설정 파일을 배포한 후 모든 서버의 nginx를 재시작해야 합니다.

service 모듈로 state=reloaded를 사용하면 연결 중인 사용자에게 영향을 주지 않고 설정을 적용할 수 있습니다. 쿠팡, 11번가 같은 대규모 커머스 사이트에서는 이런 무중단 배포가 필수입니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 restart와 reload를 혼동하는 것입니다.

restart는 프로세스를 완전히 종료하고 다시 시작하므로 잠시 서비스 중단이 발생합니다. 반면 reload는 설정만 다시 읽어오므로 서비스가 계속 실행됩니다.

프로덕션 환경에서는 가능한 reload를 사용하는 것이 좋습니다. 또한 서비스 이름이 OS마다 다를 수 있습니다.

Ubuntu에서는 apache2이지만 CentOS에서는 httpd입니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨가 알려준 명령어를 실행했습니다. ansible webservers -m service -a "name=nginx state=reloaded" --become 20대의 웹서버에서 동시에 nginx가 설정을 다시 읽어왔습니다.

모든 서버에서 SUCCESS 메시지가 나타났습니다. "와, 정말 간단하네요.

그런데 왜 restart 대신 reloaded를 사용하나요?" "restart를 하면 잠깐이지만 서비스가 멈춰요. 사용자들이 접속할 수 없는 거죠.

reloaded는 실행 중인 상태에서 설정만 새로 적용해서 무중단이에요." "아, 그래서 운영 환경에서는 reload를 쓰는 거군요!" 김개발 씨는 또 하나를 배웠습니다. ansible all -m shell -a "systemctl status nginx" --become 명령으로 모든 서버의 nginx 상태를 확인했고, 모두 active (running) 상태인 것을 확인했습니다.

service 모듈을 제대로 이해하면 배포 자동화, 무중단 배포, 서비스 모니터링 등 다양한 운영 작업을 효율적으로 처리할 수 있습니다. 여러분도 수작업 서비스 제어를 Ansible로 자동화해 보세요.

실전 팁

💡 - state=reloaded는 모든 서비스가 지원하는 것은 아닙니다. 지원 여부를 먼저 확인하세요

• enabled=yes로 부팅 시 자동 시작을 설정하는 것을 잊지 마세요
• sleep 옵션으로 재시작 후 대기 시간을 지정할 수 있습니다

---

6. 실용적인 Ad-hoc 예제

김개발 씨는 이제 Ad-hoc 명령어에 익숙해졌습니다. 팀장님이 갑자기 찾아왔습니다.

"긴급 상황이에요. 모든 서버의 디스크 사용량을 확인하고, 로그 파일을 정리하고, 시스템 시간 동기화도 확인해 주세요." 예전 같았으면 하루 종일 걸렸겠지만, 지금은 다릅니다.

실전 Ad-hoc 명령어는 일상적인 서버 운영 업무에서 자주 사용되는 패턴들을 모아놓은 것입니다. 마치 요리사가 자주 쓰는 칼 기술을 익히듯이, 시스템 관리자도 자주 쓰는 Ad-hoc 패턴을 익혀두면 업무 효율이 크게 향상됩니다.

디스크 점검, 로그 관리, 사용자 계정 관리 등 실무 시나리오를 다룹니다.

다음 코드를 살펴봅시다.

# 디스크 사용량 확인
ansible all -m shell -a "df -h | grep -E '^/dev/'" --become

# 메모리 사용량 확인
ansible all -m shell -a "free -h"

# 특정 프로세스 확인
ansible webservers -m shell -a "ps aux | grep nginx | grep -v grep"

# 로그 파일 용량 확인 및 정리 (7일 이상 된 로그 삭제)
ansible all -m find -a "paths=/var/log age=7d patterns='*.log'" --become
ansible all -m shell -a "find /var/log -name '*.log' -mtime +7 -delete" --become

# 시스템 업타임 확인
ansible all -m shell -a "uptime"

# 사용자 계정 생성
ansible all -m user -a "name=deploy shell=/bin/bash groups=sudo" --become

# 파일 퍼미션 일괄 변경
ansible webservers -m file -a "path=/var/www/html owner=www-data group=www-data mode=0755 recurse=yes" --become

# 크론탭 작업 추가
ansible dbservers -m cron -a "name='daily backup' minute=0 hour=2 job='/opt/backup/backup.sh'" --become

김개발 씨는 입사한 지 이제 3개월이 지났습니다. Ansible Ad-hoc 명령어를 배운 후로 업무 속도가 눈에 띄게 빨라졌습니다.

예전에는 하루 종일 걸리던 작업이 이제는 30분이면 끝납니다. 어느 금요일 오후, 팀장님이 급하게 찾아왔습니다.

"김개발 씨, 월요일에 CEO 보고가 있어요. 모든 서버 상태를 점검해서 리포트를 만들어주세요.

디스크 사용량, 메모리 상태, 실행 중인 서비스, 시스템 업타임 전부요." 예전 같았으면 주말 출근을 각오했을 것입니다. 하지만 지금은 다릅니다.

"네, 1시간이면 됩니다." 그렇다면 실전 Ad-hoc 명령어에는 어떤 것들이 있을까요? 쉽게 비유하자면, 실전 Ad-hoc 명령어는 마치 의사의 진단 키트와 같습니다.

체온계, 청진기, 혈압계 등 각각의 도구가 특정 증상을 빠르게 진단하듯이, 각각의 Ad-hoc 명령어도 특정 서버 상태를 즉시 파악합니다. 숙련된 의사가 진단 도구를 능숙하게 다루듯, 숙련된 시스템 관리자도 Ad-hoc 명령어를 자유자재로 활용합니다.

이런 패턴들이 없던 시절에는 어떻게 했을까요? 시스템 관리자들은 자신만의 bash 스크립트 모음집을 만들어 두었습니다.

하지만 서버 환경이 바뀌거나 새로운 팀원이 오면 스크립트를 일일이 설명해야 했습니다. 더 큰 문제는 각자가 다른 방식으로 작업해서 표준화가 어렵다는 점이었습니다.

바로 이런 문제를 해결하기 위해 Ansible Ad-hoc 패턴이 정립되었습니다. Ad-hoc 패턴을 표준화하면 팀 전체가 동일한 방식으로 서버를 관리할 수 있습니다.

또한 누가 작업하더라도 동일한 결과를 얻을 수 있습니다. 무엇보다 새로운 팀원도 빠르게 업무를 배울 수 있다는 큰 이점이 있습니다.

위의 코드를 섹션별로 살펴보겠습니다. 첫 번째 섹션은 모니터링 명령어들입니다.

df -h로 디스크를, free -h로 메모리를, uptime으로 시스템 가동 시간을 확인합니다. 이것들은 서버 상태 점검의 기본입니다.

두 번째 섹션은 로그 관리입니다. find 모듈로 오래된 로그 파일을 찾고, shell 모듈로 삭제합니다.

세 번째 섹션은 사용자 관리입니다. user 모듈로 새 계정을 만들고 sudo 그룹에 추가합니다.

네 번째 섹션은 파일 관리입니다. file 모듈의 recurse=yes 옵션으로 하위 디렉토리까지 재귀적으로 권한을 변경합니다.

마지막으로 크론 작업을 추가하는 예제입니다. cron 모듈로 매일 새벽 2시에 백업 스크립트를 실행하도록 설정합니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 핀테크 스타트업에서 보안 감사를 받는다고 가정해봅시다.

감사관이 "모든 서버에 특정 사용자 계정이 있는지 확인해 주세요"라고 요청합니다. Ansible Ad-hoc으로 ansible all -m shell -a "id deploy" 명령을 실행하면 즉시 모든 서버의 계정 존재 여부를 확인할 수 있습니다.

또한 "로그 보관 정책이 준수되고 있는지" 확인할 때도 find 모듈로 모든 서버의 로그 파일 날짜를 한 번에 검사할 수 있습니다. 토스, 뱅크샐러드 같은 금융권 스타트업에서는 이런 감사 대응이 빈번합니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 shell 모듈을 남발하는 것입니다.

Ansible에는 전용 모듈이 이미 많이 있습니다. 예를 들어 파일 삭제는 shell의 rm 대신 file 모듈의 state=absent를 사용하는 것이 더 안전합니다.

또한 프로덕션 서버에서 삭제 명령을 실행할 때는 반드시 --check 옵션으로 먼저 테스트해야 합니다. 한 번의 실수로 중요한 데이터를 날릴 수 있기 때문입니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 김개발 씨는 배운 Ad-hoc 명령어들을 하나씩 실행했습니다.

먼저 ansible all -m shell -a "df -h | grep -E '^/dev/'" --become으로 모든 서버의 디스크 사용량을 확인했습니다. 출력 결과를 Excel로 정리했습니다.

다음으로 ansible all -m shell -a "free -h"로 메모리 상태를 점검했습니다. ansible all -m shell -a "uptime"으로 시스템 가동 시간도 확인했습니다.

1시간도 안 돼서 모든 서버의 상태를 파악했고, 깔끔한 리포트를 만들었습니다. 팀장님이 만족스러워하며 말했습니다.

"이렇게 빨리 끝냈어요? 정말 잘했어요.

월요일 보고 자료로 완벽해요." 김개발 씨는 뿌듯했습니다. "Ansible Ad-hoc 명령어를 배운 덕분이에요." 박시니어 씨가 옆에서 엄지를 치켜세웠습니다.

"이제 진짜 시스템 관리자가 다 됐네요!" 며칠 후, 신입 직원이 입사했습니다. 팀장님이 김개발 씨를 불렀습니다.

"김개발 씨가 신입 교육을 맡아주세요. Ansible Ad-hoc 명령어부터 가르쳐 주세요." 이제 김개발 씨는 가르치는 입장이 되었습니다.

"먼저 ping 모듈로 서버 연결부터 테스트해 볼까요?" 신입 직원의 눈이 반짝였습니다. "와, 이렇게 간단한 거였어요?" 실전 Ad-hoc 명령어 패턴을 제대로 익혀두면 일상적인 서버 운영 업무를 자동화하고, 긴급 상황에도 빠르게 대응할 수 있습니다.

또한 팀 전체의 업무 방식을 표준화해서 협업 효율을 높일 수 있습니다. 여러분도 오늘 배운 패턴들을 자신의 환경에 맞게 활용해 보세요.

실전 팁

💡 - 자주 쓰는 명령어는 bash alias나 스크립트로 저장해두면 더 편리합니다

• --limit 옵션으로 특정 서버만 선택해서 테스트할 수 있습니다
• 복잡한 작업은 플레이북으로 전환하는 것을 고려하세요. Ad-hoc은 간단한 작업에 적합합니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!