Ansible 성능 최적화와 디버깅 완벽 가이드

Ansible 플레이북의 실행 속도를 극적으로 향상시키고, 문제 발생 시 효과적으로 디버깅하는 방법을 다룹니다. 병렬 실행, 캐싱, SSH 최적화부터 디버그 모드와 프로파일링까지 실무에서 바로 적용할 수 있는 기법들을 소개합니다.

---

목차

1. 병렬_실행_최적화
2. Facts_캐싱_활용
3. SSH_연결_재사용
4. 디버그_모드_사용법
5. verbosity_레벨_조정
6. 성능_프로파일링

---

1. 병렬 실행 최적화

김개발 씨는 100대의 서버에 패치를 배포해야 했습니다. 플레이북을 실행했더니 한 대씩 순차적으로 처리되어 퇴근 시간이 훌쩍 지나버렸습니다.

"이걸 동시에 여러 대씩 처리할 수는 없을까요?" 선배에게 물었더니 돌아온 대답은 "forks 설정을 바꿔봤어?"였습니다.

병렬 실행은 Ansible이 동시에 몇 대의 호스트를 처리할지 결정하는 설정입니다. 마치 식당에서 웨이터 한 명이 테이블 하나씩 주문을 받는 것과 여러 명이 동시에 주문을 받는 것의 차이와 같습니다.

기본값은 5이지만, 서버 사양에 따라 이 값을 높이면 전체 실행 시간을 크게 단축할 수 있습니다.

다음 코드를 살펴봅시다.

# ansible.cfg 설정
[defaults]
forks = 50
# 한 번에 50대의 호스트를 동시에 처리합니다

# 플레이북에서 serial 키워드로 배치 크기 조절
- hosts: webservers
  serial: 10
  # 10대씩 묶어서 순차적으로 처리 (롤링 업데이트)
  tasks:
    - name: 웹 서버 업데이트
      apt:
        name: nginx
        state: latest

# 명령줄에서 forks 지정
# ansible-playbook deploy.yml -f 30

김개발 씨는 입사 6개월 차 DevOps 엔지니어입니다. 오늘 받은 업무는 전체 웹 서버 100대에 보안 패치를 적용하는 것이었습니다.

평소처럼 플레이북을 실행했더니 진행 상황이 너무 느렸습니다. 화면을 보니 서버 한 대가 끝나야 다음 서버로 넘어가고 있었습니다.

단순 계산으로도 서버당 1분씩 걸리면 100분이나 소요되는 상황이었습니다. 옆자리 박시니어 씨가 상황을 보더니 말했습니다.

"forks 설정이 기본값으로 되어 있네요. 우리 컨트롤 노드는 성능이 좋으니까 50 정도로 올려도 괜찮아요." 그렇다면 forks란 정확히 무엇일까요?

쉽게 비유하자면, forks는 마치 마트 계산대의 개수와 같습니다. 계산대가 하나뿐이면 손님들이 긴 줄을 서야 하지만, 여러 개가 열려 있으면 동시에 여러 손님을 처리할 수 있습니다.

Ansible의 forks도 마찬가지로 동시에 작업할 수 있는 호스트의 수를 결정합니다. Ansible의 기본 forks 값은 5입니다.

즉, 아무 설정 없이 실행하면 한 번에 5대의 서버만 동시에 처리합니다. 서버가 10대라면 두 번에 나눠서, 100대라면 스무 번에 나눠서 처리하는 것입니다.

하지만 주의할 점이 있습니다. forks를 무작정 높인다고 좋은 것은 아닙니다.

컨트롤 노드의 CPU와 메모리 사용량이 증가하기 때문입니다. 만약 컨트롤 노드의 성능이 부족한데 forks를 100으로 설정하면, 오히려 시스템이 불안정해질 수 있습니다.

보통 CPU 코어 수의 2~4배 정도가 적당한 값입니다. 또 하나 알아둘 것이 serial 키워드입니다.

이것은 forks와는 조금 다른 개념입니다. serial은 롤링 업데이트를 위한 설정입니다.

예를 들어 로드 밸런서 뒤에 있는 웹 서버 100대를 업데이트한다고 생각해 봅시다. 모든 서버를 동시에 업데이트하면 서비스가 중단될 수 있습니다.

이때 serial을 10으로 설정하면 10대씩 순차적으로 업데이트하여 서비스 연속성을 보장할 수 있습니다. 김개발 씨는 ansible.cfg 파일을 열어 forks를 50으로 수정했습니다.

다시 플레이북을 실행하니 여러 서버가 동시에 처리되기 시작했습니다. 100분 걸릴 작업이 단 10분 만에 완료되었습니다.

김개발 씨의 얼굴에 미소가 번졌습니다. "이렇게 간단한 설정 하나로 이렇게 차이가 나다니요!" 박시니어 씨가 덧붙였습니다.

"운영 환경에서는 serial도 함께 고려해야 해요. 속도와 안정성 사이의 균형을 잘 맞춰야 합니다."

실전 팁

💡 - 컨트롤 노드의 CPU 코어 수 x 2~4 정도로 forks를 설정하세요

• 운영 환경 배포 시에는 serial을 활용한 롤링 업데이트를 고려하세요
• 네트워크 대역폭도 병목이 될 수 있으니 모니터링하면서 조절하세요

---

2. Facts 캐싱 활용

김개발 씨가 플레이북을 실행할 때마다 "Gathering Facts" 단계에서 오랜 시간이 걸리는 것을 발견했습니다. 매번 같은 서버인데 왜 정보를 다시 수집하는 걸까요?

박시니어 씨가 웃으며 말했습니다. "Facts 캐싱을 설정하면 그 시간을 아낄 수 있어요."

Facts는 Ansible이 대상 호스트에서 수집하는 시스템 정보입니다. OS 종류, IP 주소, 메모리 용량 등 다양한 정보가 포함됩니다.

이 정보 수집에는 시간이 걸리는데, Facts 캐싱을 사용하면 한 번 수집한 정보를 저장해두고 재사용할 수 있습니다. 마치 도서관에서 자주 찾는 책을 별도 서가에 보관해두는 것과 같습니다.

다음 코드를 살펴봅시다.

# ansible.cfg에서 Facts 캐싱 설정
[defaults]
gathering = smart
# smart: 캐시가 있으면 사용, 없으면 수집

fact_caching = jsonfile
# 캐시 저장 방식: jsonfile, redis, memcached 등

fact_caching_connection = /tmp/ansible_facts_cache
# 캐시 파일 저장 경로

fact_caching_timeout = 86400
# 캐시 유효 시간: 86400초 = 24시간

# Redis를 사용하는 경우
# fact_caching = redis
# fact_caching_connection = localhost:6379:0

김개발 씨는 하루에도 여러 번 플레이북을 실행합니다. 테스트 환경에서 설정을 바꿔가며 검증하기 때문입니다.

그런데 매번 실행할 때마다 "Gathering Facts"라는 단계가 나타나며 30초 이상 소요되었습니다. 처음에는 당연한 것으로 여겼습니다.

하지만 같은 서버에서 몇 분 간격으로 실행하는데, 매번 OS 정보나 메모리 용량이 바뀔 리가 없었습니다. 박시니어 씨에게 물었더니 명쾌한 답이 돌아왔습니다.

"Facts 캐싱을 설정하면 한 번 수집한 정보를 재사용할 수 있어요." Facts란 무엇일까요? Ansible은 플레이북을 실행하기 전에 대상 호스트의 시스템 정보를 자동으로 수집합니다.

이 정보에는 운영체제 종류, 커널 버전, CPU 개수, 메모리 용량, 네트워크 인터페이스, 마운트된 디스크 등 수백 가지 항목이 포함됩니다. 이 정보를 Facts라고 부릅니다.

Facts는 플레이북 내에서 조건문이나 변수로 활용됩니다. 예를 들어 "Ubuntu 서버에서만 이 태스크를 실행하라"는 조건을 걸 때 Facts를 사용합니다.

문제는 이 수집 과정에 시간이 걸린다는 점입니다. 서버 한 대당 1~2초씩 걸리고, 서버가 많아지면 전체적으로 상당한 시간이 소요됩니다.

Facts 캐싱은 이 문제를 해결합니다. 마치 자주 방문하는 웹사이트의 데이터를 브라우저가 캐시해두는 것처럼, Ansible도 한 번 수집한 Facts를 저장해두었다가 다음에 재사용합니다.

캐싱 방식에는 여러 가지가 있습니다. 가장 간단한 것은 jsonfile입니다.

각 호스트의 Facts를 JSON 파일로 저장합니다. 설정이 간단하고 별도의 인프라가 필요 없어서 소규모 환경에 적합합니다.

대규모 환경에서는 Redis나 memcached 같은 인메모리 캐시를 사용합니다. 여러 컨트롤 노드가 캐시를 공유할 수 있고, 성능도 더 뛰어납니다.

gathering 옵션도 중요합니다. 이 값을 smart로 설정하면 캐시가 유효할 때는 캐시를 사용하고, 캐시가 없거나 만료되었을 때만 새로 수집합니다.

김개발 씨는 ansible.cfg에 캐싱 설정을 추가했습니다. 처음 실행할 때는 여전히 Facts를 수집했지만, 두 번째 실행부터는 그 단계가 순식간에 지나갔습니다.

단, 주의할 점이 있습니다. 서버의 하드웨어나 네트워크 설정이 변경되었을 때는 캐시를 갱신해야 합니다.

fact_caching_timeout을 적절히 설정하거나, 필요할 때 수동으로 캐시를 삭제하면 됩니다.

실전 팁

💡 - 테스트 환경에서는 jsonfile, 운영 환경에서는 Redis 캐싱을 권장합니다

• 서버 변경 작업 후에는 캐시를 갱신하거나 삭제하세요
• gathering = explicit로 설정하면 Facts 수집을 완전히 끌 수 있지만, Facts를 사용하는 태스크가 실패할 수 있습니다

---

3. SSH 연결 재사용

김개발 씨가 네트워크 모니터링 도구를 확인하다가 이상한 점을 발견했습니다. Ansible이 같은 서버에 SSH 연결을 수십 번씩 맺고 끊고 있었습니다.

"왜 이렇게 연결을 반복하는 거죠? 한 번 연결해서 계속 쓰면 안 되나요?" 이 질문이 SSH 연결 최적화를 배우는 시작점이 되었습니다.

Ansible은 기본적으로 각 태스크마다 새로운 SSH 연결을 맺습니다. SSH 멀티플렉싱을 활성화하면 하나의 연결을 여러 태스크가 공유하여 재사용할 수 있습니다.

이는 마치 고속도로 톨게이트를 매번 통과하는 대신 하이패스로 빠르게 지나가는 것과 같습니다. 연결 수립에 드는 오버헤드가 줄어들어 전체 실행 속도가 향상됩니다.

다음 코드를 살펴봅시다.

# ansible.cfg SSH 최적화 설정
[ssh_connection]
ssh_args = -o ControlMaster=auto -o ControlPersist=60s
# ControlMaster: 마스터 연결을 자동으로 관리
# ControlPersist: 연결을 60초간 유지

pipelining = True
# 파이프라이닝 활성화로 SSH 왕복 횟수 감소

control_path = %(directory)s/%%h-%%r
# 소켓 파일 경로 (경로가 너무 길면 에러 발생)

# 호스트 키 체크 비활성화 (보안 주의)
[defaults]
host_key_checking = False

어느 날 김개발 씨는 서버팀으로부터 연락을 받았습니다. "혹시 지금 뭔가 작업 중이세요?

특정 서버에 SSH 연결이 비정상적으로 많이 들어오고 있어요." 확인해보니 Ansible 플레이북이 실행 중이었습니다. 태스크가 30개인 플레이북이었는데, 서버 한 대당 30번의 SSH 연결이 발생하고 있었습니다.

서버가 50대이니 총 1,500번의 SSH 연결이 짧은 시간에 이루어지고 있었던 것입니다. 박시니어 씨가 상황을 파악하고 말했습니다.

"SSH 멀티플렉싱을 설정해야 해요. 그러면 연결 한 번으로 모든 태스크를 처리할 수 있어요." SSH 멀티플렉싱이란 무엇일까요?

일반적으로 SSH 연결을 맺을 때는 여러 단계를 거칩니다. TCP 핸드셰이크, 암호화 협상, 인증 과정 등이 필요합니다.

이 과정이 매번 반복되면 상당한 시간이 소요됩니다. SSH 멀티플렉싱은 하나의 마스터 연결을 맺어두고, 이후의 연결들은 이 마스터 연결을 통해 이루어지도록 합니다.

마치 고속도로에서 첫 번째 차가 톨게이트를 열어두면 뒤따르는 차들이 빠르게 통과하는 것과 같습니다. ControlMaster와 ControlPersist 옵션이 이를 가능하게 합니다.

ControlMaster=auto는 마스터 연결을 자동으로 관리하고, ControlPersist=60s는 마지막 연결이 끝난 후에도 60초간 마스터 연결을 유지합니다. 여기에 pipelining을 추가하면 더 빨라집니다.

Ansible은 기본적으로 원격 서버에 파이썬 스크립트를 전송하고 실행하는 방식으로 동작합니다. 이 과정에서 여러 번의 SSH 왕복이 발생하는데, pipelining을 활성화하면 이를 하나의 SSH 세션으로 처리합니다.

단, pipelining을 사용하려면 대상 서버의 sudoers 설정에서 requiretty 옵션이 비활성화되어 있어야 합니다. 그렇지 않으면 sudo 명령어가 실패합니다.

김개발 씨는 ansible.cfg에 SSH 최적화 설정을 추가했습니다. 다시 플레이북을 실행하니 SSH 연결 수가 현저히 줄었고, 전체 실행 시간도 30% 가량 단축되었습니다.

control_path 설정도 주의가 필요합니다. 소켓 파일 경로가 너무 길면 운영체제의 경로 길이 제한에 걸려 에러가 발생할 수 있습니다.

호스트명이 긴 경우 짧은 해시값을 사용하도록 설정하는 것이 좋습니다.

실전 팁

💡 - pipelining을 사용하려면 원격 서버의 /etc/sudoers에서 requiretty를 비활성화하세요

• control_path가 너무 길면 에러가 발생하므로 짧게 유지하세요
• 보안이 중요한 환경에서는 host_key_checking을 끄지 마세요

---

4. 디버그 모드 사용법

김개발 씨의 플레이북이 에러를 뱉어냈습니다. "FAILED!

=> changed=false, msg='이상한 에러 메시지'"라고만 나올 뿐, 정확히 무엇이 문제인지 알 수 없었습니다. 박시니어 씨가 다가와 물었습니다.

"debug 모듈은 써봤어요? 변수 값을 찍어보면 문제가 보일 거예요."

debug 모듈은 Ansible의 필수 디버깅 도구입니다. 플레이북 실행 중에 변수 값, 조건문 결과, Facts 정보 등을 화면에 출력할 수 있습니다.

마치 프로그래밍에서 print문으로 값을 확인하는 것과 같습니다. 복잡한 플레이북에서 문제의 원인을 찾을 때 가장 먼저 사용하는 도구입니다.

다음 코드를 살펴봅시다.

# debug 모듈 기본 사용법
- name: 변수 값 확인하기
  debug:
    var: my_variable
  # 변수의 값과 타입을 출력합니다

- name: 메시지 출력하기
  debug:
    msg: "현재 호스트: {{ inventory_hostname }}, IP: {{ ansible_host }}"

- name: 조건부 디버그 출력
  debug:
    msg: "경고: 메모리가 부족합니다!"
  when: ansible_memtotal_mb < 1024

# 복잡한 데이터 구조 확인
- name: Facts 전체 출력
  debug:
    var: ansible_facts
    verbosity: 2
  # verbosity: 2 - v 플래그 2개 이상일 때만 출력

김개발 씨는 서버 설정을 자동화하는 플레이북을 작성하고 있었습니다. 조건문을 사용해서 서버 환경에 따라 다른 설정을 적용하는 로직이었습니다.

그런데 이상하게도 모든 서버에 같은 설정이 적용되고 있었습니다. 분명히 when 조건문을 넣었는데 왜 동작하지 않는 걸까요?

코드를 아무리 들여다봐도 문제를 찾을 수 없었습니다. 그때 박시니어 씨가 조언했습니다.

"debug 모듈로 조건문에 사용되는 변수 값을 찍어봐요." debug 모듈은 Ansible에서 가장 기본적이면서도 강력한 디버깅 도구입니다. 가장 간단한 사용법은 var 옵션입니다.

확인하고 싶은 변수 이름을 지정하면 그 값이 화면에 출력됩니다. 중요한 점은 var 옵션에는 변수 이름만 쓰고, 중괄호를 쓰지 않는다는 것입니다.

msg 옵션은 커스텀 메시지를 출력할 때 사용합니다. 여러 변수를 조합하거나 설명을 덧붙이고 싶을 때 유용합니다.

msg에서는 Jinja2 템플릿 문법을 사용할 수 있습니다. 김개발 씨는 조건문에 사용되는 변수를 debug로 출력해보았습니다.

그제야 문제가 보였습니다. 변수 값이 예상했던 문자열이 아니라 리스트로 들어오고 있었던 것입니다.

"아, 인벤토리에서 변수를 잘못 정의했구나!" 문제를 수정하니 플레이북이 정상적으로 동작했습니다. debug 모듈에는 verbosity 옵션도 있습니다.

이 옵션을 사용하면 특정 verbosity 레벨 이상에서만 출력되도록 설정할 수 있습니다. 예를 들어 verbosity: 2로 설정하면 -vv 이상의 플래그를 줬을 때만 출력됩니다.

이 기능은 개발 중에는 상세한 디버그 정보를 보고, 운영 환경에서는 깔끔한 출력을 유지하고 싶을 때 유용합니다. when 조건과 함께 사용하면 특정 상황에서만 디버그 정보를 출력할 수도 있습니다.

예를 들어 메모리가 부족한 서버에서만 경고 메시지를 출력하는 식입니다. 박시니어 씨가 덧붙였습니다.

"debug 모듈은 개발할 때 적극적으로 사용하되, 운영 환경에 배포할 때는 정리하는 것이 좋아요. 불필요한 출력은 로그를 지저분하게 만들거든요."

실전 팁

💡 - var 옵션에는 중괄호 없이 변수 이름만 쓰세요

• verbosity 옵션으로 개발용 디버그 출력과 운영용 출력을 분리하세요
• 복잡한 문제는 ansible_facts 전체를 출력해서 확인해보세요

---

5. verbosity 레벨 조정

"에러 메시지만 봐서는 도저히 모르겠어요." 김개발 씨가 한숨을 쉬었습니다. Ansible이 뱉어낸 에러는 너무 간략해서 원인을 파악하기 어려웠습니다.

박시니어 씨가 물었습니다. "-v 플래그 붙여봤어요?

몇 개까지 붙여봤는데요?"

verbosity 레벨은 Ansible 실행 시 출력되는 정보의 상세도를 조절합니다. -v 플래그를 추가할수록 더 많은 정보가 출력됩니다.

-v는 기본 상세 정보, -vv는 연결 정보, -vvv는 태스크 입력값, -vvvv는 SSH 디버그 정보까지 보여줍니다. 마치 현미경의 배율을 높이듯이 문제의 원인을 점점 더 자세히 들여다볼 수 있습니다.

다음 코드를 살펴봅시다.

# verbosity 레벨별 실행 예시

# 레벨 1 (-v): 태스크 결과 상세 정보
ansible-playbook deploy.yml -v

# 레벨 2 (-vv): 연결 정보 + 태스크 입력값
ansible-playbook deploy.yml -vv

# 레벨 3 (-vvv): 모든 입출력값 + 연결 상세
ansible-playbook deploy.yml -vvv

# 레벨 4 (-vvvv): SSH 디버그 정보까지 전부
ansible-playbook deploy.yml -vvvv

# 특정 호스트만 상세하게 보기
ansible-playbook deploy.yml -vvv --limit webserver01

# 환경변수로 설정하기
# export ANSIBLE_VERBOSITY=2

김개발 씨의 플레이북이 실패했습니다. 에러 메시지는 단 한 줄이었습니다.

"fatal: UNREACHABLE!" 서버에 직접 SSH로 접속해보면 잘 됩니다. 그런데 Ansible만 실패합니다.

도대체 무엇이 문제일까요? 박시니어 씨가 다가왔습니다.

"verbosity 레벨을 높여서 실행해봐요. -vvvv까지 붙여보면 SSH 연결 과정이 전부 보여요." verbosity란 Ansible 출력의 상세도를 의미합니다.

기본적으로 Ansible은 최소한의 정보만 출력합니다. 태스크가 성공했는지 실패했는지, 변경이 있었는지 정도만 알려줍니다.

하지만 문제가 발생했을 때는 이 정보만으로는 부족합니다. -v 플래그 하나를 붙이면 레벨 1이 됩니다.

각 태스크의 결과가 조금 더 상세하게 출력됩니다. 반환값이나 변경된 내용을 확인할 수 있습니다.

-vv는 레벨 2입니다. 연결 정보가 추가됩니다.

어떤 사용자로, 어떤 포트로 연결하는지 알 수 있습니다. 또한 태스크에 전달되는 입력값도 보여줍니다.

-vvv는 레벨 3으로, 모든 입출력 정보가 출력됩니다. 모듈이 어떤 인자를 받았고, 무엇을 반환했는지 상세하게 볼 수 있습니다.

대부분의 문제는 이 레벨에서 원인을 파악할 수 있습니다. -vvvv는 레벨 4입니다.

SSH 연결 과정의 디버그 정보까지 모두 출력합니다. SSH 키 교환, 인증 시도, 채널 설정 등 저수준의 정보가 쏟아져 나옵니다.

김개발 씨가 -vvvv를 붙여 실행하자 원인이 보였습니다. SSH 연결 시 잘못된 키 파일을 참조하고 있었습니다.

인벤토리 파일에서 ansible_ssh_private_key_file 경로가 틀렸던 것입니다. "아, 이 경로가 예전 프로젝트 설정이었네요!" 문제를 수정하니 플레이북이 정상적으로 실행되었습니다.

한 가지 주의할 점이 있습니다. verbosity를 높이면 출력량이 폭발적으로 증가합니다.

서버가 많으면 수천 줄의 로그가 쏟아질 수 있습니다. 따라서 --limit 옵션으로 특정 호스트만 지정해서 디버깅하는 것이 효율적입니다.

또한 비밀번호나 민감한 정보가 출력될 수 있으니, 높은 verbosity 레벨의 로그를 공유할 때는 주의가 필요합니다.

실전 팁

💡 - 일반적인 디버깅은 -vv나 -vvv로 충분합니다

• SSH 연결 문제는 -vvvv로 확인하세요
• 민감한 정보 노출에 주의하고, 로그 공유 시 마스킹하세요

---

6. 성능 프로파일링

플레이북 실행이 왜 이렇게 오래 걸릴까요? 김개발 씨는 막연하게 "느리다"고만 느꼈지, 정확히 어디서 시간이 소요되는지 몰랐습니다.

박시니어 씨가 말했습니다. "프로파일링 콜백 플러그인을 써봐요.

각 태스크별로 얼마나 걸리는지 정확히 알 수 있어요."

프로파일링은 플레이북의 각 태스크가 얼마나 시간을 소요하는지 측정하는 것입니다. Ansible은 callback 플러그인을 통해 이 기능을 제공합니다.

profile_tasks, profile_roles, timer 등의 플러그인을 활성화하면 실행 시간 통계를 확인할 수 있습니다. 마치 달리기 선수가 구간별 랩타임을 측정하듯이 병목 구간을 정확히 파악할 수 있습니다.

다음 코드를 살펴봅시다.

# ansible.cfg에서 프로파일링 콜백 활성화
[defaults]
callbacks_enabled = profile_tasks, profile_roles, timer
# profile_tasks: 각 태스크별 실행 시간
# profile_roles: 각 롤별 실행 시간
# timer: 전체 실행 시간

# 출력 예시:
# PLAY RECAP ******************************
# Wednesday 03 February 2026  10:30:45 +0900
# ==========================================
# nginx : Install nginx package -- 45.23s
# nginx : Configure nginx -- 12.11s
# nginx : Start nginx service -- 3.45s
# ==========================================
# Total: 60.79s

# 명령줄에서 환경변수로 활성화
# ANSIBLE_CALLBACKS_ENABLED=profile_tasks ansible-playbook site.yml

김개발 씨의 배포 플레이북은 총 실행 시간이 15분이었습니다. 팀에서는 이 시간을 절반으로 줄이고 싶었습니다.

하지만 어디서부터 손을 대야 할지 막막했습니다. "일단 뭐가 오래 걸리는지 알아야 최적화를 하죠." 박시니어 씨의 말에 김개발 씨는 고개를 끄덕였습니다.

프로파일링은 프로그램의 각 부분이 얼마나 시간을 소요하는지 측정하는 기법입니다. Ansible에서는 callback 플러그인을 통해 이 기능을 제공합니다.

가장 유용한 플러그인은 profile_tasks입니다. 이 플러그인을 활성화하면 플레이북 실행이 끝난 후 각 태스크별 실행 시간이 정렬되어 출력됩니다.

가장 오래 걸린 태스크가 맨 위에 나옵니다. profile_roles는 롤 단위로 시간을 집계합니다.

플레이북이 여러 롤로 구성되어 있을 때, 어떤 롤이 가장 오래 걸리는지 한눈에 파악할 수 있습니다. timer는 전체 실행 시간을 측정합니다.

이 세 가지를 함께 활성화하면 전체 그림부터 세부 사항까지 모두 볼 수 있습니다. 김개발 씨는 ansible.cfg에 프로파일링 설정을 추가하고 플레이북을 실행했습니다.

결과가 흥미로웠습니다. 전체 15분 중에서 "패키지 설치" 태스크 하나가 8분을 차지하고 있었습니다.

원인을 분석해보니 매번 패키지 캐시를 업데이트하고 있었습니다. cache_valid_time 옵션을 추가하여 캐시가 유효할 때는 업데이트를 건너뛰도록 수정했습니다.

그것만으로 8분이 1분으로 줄었습니다. 다음으로 오래 걸리는 것은 "파일 복사" 태스크였습니다.

수백 개의 작은 파일을 하나씩 복사하고 있었습니다. synchronize 모듈로 변경하니 이 부분도 크게 개선되었습니다.

프로파일링 없이 막연하게 최적화했다면 엉뚱한 곳에 시간을 쏟았을 것입니다. 데이터를 기반으로 결정하니 효과적인 개선이 가능했습니다.

15분이 5분으로 줄었습니다. 팀 목표를 달성한 김개발 씨는 뿌듯한 미소를 지었습니다.

박시니어 씨가 조언을 덧붙였습니다. "최적화는 한 번에 끝나는 게 아니에요.

정기적으로 프로파일링해서 성능 변화를 추적하세요."

실전 팁

💡 - 최적화 전에 반드시 프로파일링으로 병목 구간을 파악하세요

• 가장 오래 걸리는 태스크부터 개선하면 효과가 큽니다
• 프로파일링 결과를 저장해두고 개선 전후를 비교하세요

---

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