Ansible Galaxy와 컬렉션 완벽 가이드

Ansible Galaxy를 통해 커뮤니티가 만든 Role과 컬렉션을 검색하고 설치하는 방법을 배웁니다. requirements.yml 작성법부터 자체 컬렉션 생성까지, 인프라 자동화의 생산성을 높이는 핵심 기술을 다룹니다.

---

목차

1. Ansible_Galaxy_소개
2. Role_검색_및_설치
3. requirements.yml_작성
4. 컬렉션_개념과_구조
5. 컬렉션_설치_및_사용
6. 자체_컬렉션_생성하기

---

1. Ansible Galaxy 소개

어느 날 김개발 씨는 새 프로젝트에서 Nginx 서버를 설치하고 설정하는 Playbook을 작성해야 했습니다. 처음부터 모든 것을 직접 작성하려니 막막했습니다.

그때 옆자리 박시니어 씨가 다가와 물었습니다. "혹시 Galaxy 써봤어요?"

Ansible Galaxy는 한마디로 Ansible 역할(Role)과 컬렉션(Collection)을 공유하는 커뮤니티 허브입니다. 마치 스마트폰의 앱스토어처럼, 다른 개발자들이 만들어 둔 자동화 코드를 검색하고 다운로드할 수 있습니다.

이것을 활용하면 바퀴를 다시 발명하지 않고도 검증된 코드로 빠르게 인프라를 구축할 수 있습니다.

다음 코드를 살펴봅시다.

# Galaxy에서 Role 검색하기
ansible-galaxy search nginx --author geerlingguy

# Galaxy에서 Role 정보 확인하기
ansible-galaxy role info geerlingguy.nginx

# Galaxy 웹사이트에서도 검색 가능
# https://galaxy.ansible.com

# 설치된 Role 목록 확인
ansible-galaxy role list

# 설치된 Collection 목록 확인
ansible-galaxy collection list

김개발 씨는 입사 6개월 차 DevOps 엔지니어입니다. 이번 주 미션은 새로운 웹 서버 환경을 자동화하는 것이었습니다.

Nginx 설치, 방화벽 설정, SSL 인증서 적용까지 해야 할 일이 산더미였습니다. "이걸 언제 다 작성하지?" 김개발 씨는 한숨을 내쉬었습니다.

Ansible은 어느 정도 다룰 줄 알았지만, 모든 태스크를 처음부터 작성하려니 막막했습니다. 그때 박시니어 씨가 다가왔습니다.

"김개발 씨, 혹시 Ansible Galaxy 써봤어요? 거기에 이미 다 있는데요." 그렇다면 Ansible Galaxy란 정확히 무엇일까요?

쉽게 비유하자면, Galaxy는 마치 스마트폰의 앱스토어와 같습니다. 우리가 메모 앱이 필요할 때 직접 개발하지 않고 앱스토어에서 다운로드하듯이, 서버 설정 자동화가 필요할 때 Galaxy에서 이미 만들어진 코드를 가져다 쓸 수 있습니다.

Galaxy가 등장하기 전에는 어땠을까요? 개발자들은 Nginx를 설치하는 Playbook을 프로젝트마다 새로 작성했습니다.

A 회사에서도 작성하고, B 회사에서도 작성했습니다. 비슷한 코드가 수천 번 중복으로 만들어졌습니다.

더 큰 문제는 각자 작성한 코드의 품질이 들쑥날쑥했다는 점입니다. 바로 이런 낭비를 줄이기 위해 Ansible Galaxy가 탄생했습니다.

Galaxy에는 전 세계 개발자들이 만든 수만 개의 Role과 컬렉션이 올라와 있습니다. 그중에서도 geerlingguy라는 개발자가 만든 Role들은 특히 유명합니다.

수년간 커뮤니티의 검증을 거친, 믿을 수 있는 코드들입니다. Galaxy는 웹사이트(galaxy.ansible.com)에서 직접 검색할 수도 있고, 터미널에서 ansible-galaxy 명령어로 검색할 수도 있습니다.

둘 다 같은 저장소를 바라보고 있으니 편한 방법을 선택하면 됩니다. 실제로 Galaxy를 사용하면 개발 시간이 획기적으로 줄어듭니다.

Nginx 설정에 보통 하루가 걸리던 작업이 30분 만에 끝나기도 합니다. 이미 검증된 코드를 가져다 쓰니 버그도 적습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 조언을 들은 김개발 씨는 Galaxy에서 nginx Role을 검색해보았습니다.

"와, 이렇게 많은 게 이미 있었네요!" Ansible Galaxy를 제대로 활용하면 인프라 자동화의 생산성이 크게 향상됩니다. 여러분도 새로운 자동화 작업을 시작하기 전에 Galaxy를 먼저 검색해 보세요.

실전 팁

💡 - Galaxy에서 Role을 선택할 때는 다운로드 수와 GitHub 스타 수를 확인하세요

• geerlingguy, ansible-community 등 신뢰할 수 있는 제작자의 Role을 우선 고려하세요

---

2. Role 검색 및 설치

김개발 씨는 Galaxy에서 마음에 드는 Nginx Role을 찾았습니다. 이제 이걸 어떻게 설치해야 할까요?

박시니어 씨가 터미널 앞에 앉아 직접 보여주기 시작했습니다. "설치는 정말 간단해요.

한 줄이면 끝나요."

ansible-galaxy role install 명령어는 Galaxy에서 Role을 다운로드하여 로컬에 설치하는 명령입니다. 마치 npm install이나 pip install처럼, 패키지 이름만 지정하면 의존성까지 알아서 처리해줍니다.

설치된 Role은 기본적으로 ~/.ansible/roles 디렉토리에 저장됩니다.

다음 코드를 살펴봅시다.

# Role 설치하기 (기본 경로: ~/.ansible/roles)
ansible-galaxy role install geerlingguy.nginx

# 특정 버전 설치하기
ansible-galaxy role install geerlingguy.nginx,3.1.0

# 특정 경로에 설치하기
ansible-galaxy role install geerlingguy.nginx -p ./roles

# 설치된 Role 확인하기
ansible-galaxy role list

# Role 삭제하기
ansible-galaxy role remove geerlingguy.nginx

# Playbook에서 Role 사용하기
# site.yml
# - hosts: webservers
#   roles:
#     - geerlingguy.nginx

박시니어 씨는 터미널을 열고 명령어를 입력했습니다. "자, 이렇게 하면 돼요." 김개발 씨는 화면을 집중해서 바라보았습니다.

ansible-galaxy role install geerlingguy.nginx라는 명령어가 실행되자, 무언가가 다운로드되기 시작했습니다. "이게 끝이에요?" 김개발 씨가 놀라서 물었습니다.

"네, 이게 끝이에요." 박시니어 씨가 웃으며 대답했습니다. Role 설치는 마치 온라인 쇼핑과 비슷합니다.

마음에 드는 상품을 클릭하고 주문 버튼만 누르면, 알아서 집 앞까지 배송됩니다. ansible-galaxy role install도 마찬가지입니다.

원하는 Role 이름만 입력하면 알아서 다운로드되어 정해진 위치에 설치됩니다. 설치된 Role은 어디에 저장될까요?

기본적으로 ~/.ansible/roles 디렉토리에 저장됩니다. 하지만 프로젝트별로 Role을 관리하고 싶다면 -p 옵션으로 경로를 지정할 수 있습니다.

많은 팀에서 프로젝트 폴더 내의 roles 디렉토리에 설치하는 방식을 선호합니다. 버전 관리도 중요한 포인트입니다.

Role 이름 뒤에 콤마(,)와 버전을 붙이면 특정 버전을 설치할 수 있습니다. 프로덕션 환경에서는 항상 버전을 명시하는 것이 좋습니다.

그래야 나중에 Role이 업데이트되어도 기존 환경에 영향을 주지 않습니다. 설치가 끝나면 Playbook에서 바로 사용할 수 있습니다.

hosts 파일에 대상 서버를 정의하고, Playbook의 roles 섹션에 설치한 Role 이름을 적어주면 됩니다. Role 내부의 복잡한 태스크들이 자동으로 실행됩니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 Role을 설치만 하고 변수 설정을 잊어버리는 것입니다.

대부분의 Role은 기본값이 있지만, 실제 환경에 맞게 변수를 조정해야 제대로 동작합니다. Role의 README 파일을 꼭 읽어보세요.

김개발 씨는 geerlingguy.nginx Role의 README를 열어보았습니다. nginx_vhosts, nginx_upstreams 같은 변수들이 상세히 설명되어 있었습니다.

"아, 이렇게 커스터마이징하면 되는구나!" ansible-galaxy role install은 Ansible 자동화의 첫걸음입니다. 이 명령어 하나로 수많은 커뮤니티 자산을 활용할 수 있습니다.

실전 팁

💡 - 프로덕션 환경에서는 항상 버전을 명시하여 설치하세요

• Role 설치 후 반드시 README를 읽고 필수 변수를 확인하세요

---

3. requirements.yml 작성

김개발 씨는 프로젝트에 Role이 점점 늘어나면서 고민에 빠졌습니다. Nginx, MySQL, Redis, Certbot...

매번 하나씩 설치하기가 번거로웠습니다. 박시니어 씨가 조언했습니다.

"requirements.yml을 사용해보세요. 한 번에 다 설치할 수 있어요."

requirements.yml은 프로젝트에 필요한 Role과 컬렉션 목록을 정의하는 파일입니다. 마치 Node.js의 package.json이나 Python의 requirements.txt처럼, 의존성을 한 곳에 모아 관리합니다.

이 파일 하나로 팀원 모두가 동일한 환경을 구성할 수 있습니다.

다음 코드를 살펴봅시다.

# requirements.yml
---
roles:
  # Galaxy에서 설치
  - name: geerlingguy.nginx
    version: "3.1.0"

  - name: geerlingguy.mysql
    version: "4.0.0"

  # Git 저장소에서 직접 설치
  - src: https://github.com/company/internal-role.git
    scm: git
    version: main
    name: internal-role

collections:
  - name: community.general
    version: ">=7.0.0"

  - name: amazon.aws
    version: "6.0.0"

# 한 번에 모두 설치
# ansible-galaxy install -r requirements.yml

김개발 씨의 프로젝트는 점점 커지고 있었습니다. 웹 서버, 데이터베이스, 캐시 서버, SSL 인증서 관리까지.

설치해야 할 Role이 벌써 다섯 개를 넘어섰습니다. "새로운 팀원이 들어오면 이걸 어떻게 설명하지?" 김개발 씨는 걱정이 되기 시작했습니다.

박시니어 씨가 해결책을 알려주었습니다. "requirements.yml 파일을 만들어두면 돼요.

거기에 필요한 Role을 전부 적어두는 거예요." requirements.yml은 마치 쇼핑 목록과 같습니다. 장을 보러 가기 전에 필요한 물건을 목록으로 적어두면, 마트에서 헤매지 않고 효율적으로 쇼핑할 수 있습니다.

requirements.yml도 마찬가지입니다. 필요한 Role을 미리 목록으로 만들어두면 한 번에 설치할 수 있습니다.

파일 구조를 살펴보겠습니다. 크게 roles 섹션과 collections 섹션으로 나뉩니다.

roles 섹션에는 설치할 Role들을 나열하고, collections 섹션에는 필요한 컬렉션들을 나열합니다. 각 Role에는 name과 version을 지정합니다.

version을 명시하는 것이 매우 중요합니다. 버전이 없으면 매번 최신 버전이 설치되어 환경이 달라질 수 있습니다.

Galaxy에 없는 내부 Role도 등록할 수 있습니다. 회사 내부에서만 사용하는 Role이 있다면 Git 저장소 주소를 src에 적어주면 됩니다.

scm을 git으로 지정하고, branch나 tag를 version에 적어주세요. 설치는 단 한 줄의 명령어로 끝납니다.

ansible-galaxy install -r requirements.yml 명령을 실행하면, 파일에 정의된 모든 Role과 컬렉션이 자동으로 설치됩니다. 새로운 팀원도 이 명령어 하나로 동일한 환경을 구성할 수 있습니다.

주의할 점이 있습니다. requirements.yml은 반드시 **버전 관리 시스템(Git)**에 포함시켜야 합니다.

이 파일이 없으면 팀원들이 각자 다른 버전의 Role을 사용하게 되어 "내 컴퓨터에서는 되는데..."라는 문제가 발생합니다. 김개발 씨는 requirements.yml을 작성하고 Git에 커밋했습니다.

다음 날 새로 입사한 신입 개발자가 명령어 하나로 환경을 구성하는 것을 보며 뿌듯해했습니다. 의존성 관리는 팀 협업의 기본입니다.

requirements.yml로 모든 팀원이 같은 환경에서 작업할 수 있도록 하세요.

실전 팁

💡 - requirements.yml은 반드시 Git에 포함하여 버전 관리하세요

• version에 부등호(>=, <)를 사용하면 유연한 버전 지정이 가능합니다

---

4. 컬렉션 개념과 구조

김개발 씨는 AWS 인프라를 자동화하는 작업을 맡게 되었습니다. EC2, S3, RDS를 다뤄야 했는데, 각각 별도의 Role을 찾아야 할까요?

박시니어 씨가 알려주었습니다. "컬렉션 하나면 다 해결돼요.

amazon.aws 컬렉션을 설치하세요."

**컬렉션(Collection)**은 Role, 모듈, 플러그인, 플레이북을 하나의 패키지로 묶은 배포 단위입니다. 마치 스위스 아미 나이프처럼, 관련된 도구들을 한 곳에 모아놓았습니다.

Ansible 2.10부터 도입된 컬렉션은 현재 Ansible 생태계의 핵심 배포 방식입니다.

다음 코드를 살펴봅시다.

# 컬렉션 구조 예시
# amazon.aws 컬렉션 내부 구조
amazon/
  aws/
    plugins/
      modules/           # EC2, S3, RDS 등 모듈
        ec2_instance.py
        s3_bucket.py
        rds_instance.py
      inventory/         # 동적 인벤토리 플러그인
        aws_ec2.py
    roles/               # 미리 정의된 Role
      ec2_setup/
    playbooks/           # 예제 Playbook
    docs/                # 문서
    galaxy.yml           # 메타데이터

# 컬렉션의 모듈 사용 예시 (Playbook)
# - name: EC2 인스턴스 생성
#   amazon.aws.ec2_instance:
#     name: "my-instance"
#     instance_type: t3.micro

김개발 씨는 AWS 인프라 자동화라는 새로운 미션을 받았습니다. EC2 인스턴스 생성, S3 버킷 관리, RDS 데이터베이스 설정...

해야 할 일이 많았습니다. "이거 각각 Role을 찾아야 하나?" 김개발 씨는 고민에 빠졌습니다.

박시니어 씨가 다가와 설명해주었습니다. "Role은 특정 작업에 특화된 거고, 컬렉션은 더 큰 개념이에요.

AWS 관련 작업이라면 amazon.aws 컬렉션 하나로 다 해결돼요." 컬렉션은 마치 공구 세트와 같습니다. 드라이버, 망치, 펜치를 따로따로 사는 대신, 공구 세트 하나를 사면 필요한 도구가 다 들어있습니다.

컬렉션도 마찬가지로, 특정 도메인에 필요한 모든 것을 한 패키지에 담고 있습니다. 컬렉션 안에는 무엇이 들어있을까요?

첫째, **모듈(Modules)**이 있습니다. 실제 작업을 수행하는 핵심 코드입니다.

amazon.aws 컬렉션에는 ec2_instance, s3_bucket, rds_instance 같은 모듈이 포함되어 있습니다. 둘째, **플러그인(Plugins)**이 있습니다.

인벤토리 플러그인, 필터 플러그인 등 Ansible의 기능을 확장하는 코드입니다. 셋째, Role도 포함될 수 있습니다.

자주 사용하는 작업 패턴을 Role로 미리 만들어 제공합니다. 넷째, 문서와 예제 Playbook도 들어있습니다.

어떻게 사용하는지 친절하게 안내해줍니다. 컬렉션의 이름은 네임스페이스.컬렉션명 형태입니다.

amazon.aws에서 amazon은 네임스페이스(조직명), aws는 컬렉션명입니다. 이런 명명 규칙 덕분에 같은 이름의 모듈이 충돌하지 않습니다.

Playbook에서 컬렉션의 모듈을 사용할 때는 **전체 경로(FQCN)**를 적어줍니다. amazon.aws.ec2_instance처럼요.

이렇게 하면 어떤 컬렉션의 모듈인지 명확해집니다. 왜 컬렉션이 등장했을까요?

예전에는 모든 모듈이 Ansible 코어에 포함되어 있었습니다. 그러다 보니 Ansible이 너무 무거워졌고, 업데이트도 느려졌습니다.

컬렉션으로 분리하면서 각 도메인별로 독립적인 개발과 배포가 가능해졌습니다. 김개발 씨는 amazon.aws 컬렉션 하나로 EC2, S3, RDS를 모두 다룰 수 있다는 사실에 감탄했습니다.

"이렇게 편리할 줄 몰랐네요!" 컬렉션은 현대 Ansible의 핵심입니다. Role이 단일 작업에 특화되어 있다면, 컬렉션은 전체 도메인을 아우르는 종합 솔루션입니다.

실전 팁

💡 - community.general 컬렉션에는 범용적으로 유용한 모듈이 많이 포함되어 있습니다

• Playbook에서 모듈 사용 시 FQCN(전체 경로)을 사용하는 습관을 들이세요

---

5. 컬렉션 설치 및 사용

김개발 씨는 컬렉션의 개념을 이해했습니다. 이제 실제로 설치하고 사용해볼 차례입니다.

박시니어 씨가 옆에서 지켜보며 한 단계씩 알려주었습니다. "Role 설치랑 비슷해요.

명령어만 조금 달라요."

ansible-galaxy collection install 명령어로 컬렉션을 설치합니다. Role 설치와 거의 동일하지만, 설치 경로가 다르고 네임스페이스가 포함된 이름을 사용합니다.

설치 후에는 Playbook에서 FQCN(Fully Qualified Collection Name)으로 모듈을 호출하여 사용합니다.

다음 코드를 살펴봅시다.

# 컬렉션 설치하기
ansible-galaxy collection install amazon.aws

# 특정 버전 설치
ansible-galaxy collection install amazon.aws:6.0.0

# 특정 경로에 설치
ansible-galaxy collection install amazon.aws -p ./collections

# 설치된 컬렉션 목록 확인
ansible-galaxy collection list

# Playbook에서 컬렉션 사용 예시
---
- name: AWS 인프라 구성
  hosts: localhost
  connection: local
  tasks:
    - name: EC2 인스턴스 생성
      amazon.aws.ec2_instance:
        name: "web-server"
        instance_type: t3.micro
        image_id: ami-0123456789abcdef0
        state: running

박시니어 씨가 터미널에서 명령어를 입력하기 시작했습니다. "자, Role 설치할 때 ansible-galaxy role install 썼죠?

컬렉션은 ansible-galaxy collection install이에요." 김개발 씨는 고개를 끄덕였습니다. 문법이 일관성 있어서 기억하기 쉬웠습니다.

ansible-galaxy collection install amazon.aws 명령을 실행하자, 컬렉션이 다운로드되기 시작했습니다. Role보다 파일 크기가 커서 조금 더 걸렸습니다.

"설치된 컬렉션은 어디에 저장되나요?" 김개발 씨가 물었습니다. 기본 경로는 ~/.ansible/collections입니다.

Role과 비슷하지만 폴더 이름이 다릅니다. 프로젝트별로 관리하고 싶다면 -p 옵션으로 경로를 지정할 수 있습니다.

버전 지정 방식도 알아두어야 합니다. 컬렉션은 Role과 달리 콤마(,)가 아닌 **콜론(:)**으로 버전을 구분합니다.

amazon.aws:6.0.0처럼 작성합니다. 작은 차이지만 헷갈리기 쉬우니 주의하세요.

이제 Playbook에서 사용해봅시다. 컬렉션의 모듈을 사용할 때는 **FQCN(Fully Qualified Collection Name)**을 사용합니다.

amazon.aws.ec2_instance처럼 네임스페이스.컬렉션명.모듈명 형태로 적습니다. 왜 이렇게 길게 써야 할까요?

여러 컬렉션에 같은 이름의 모듈이 있을 수 있기 때문입니다. 예를 들어 amazon.aws.ec2_instance와 다른 컬렉션의 ec2_instance가 충돌하지 않도록 구분해주는 것입니다.

FQCN이 너무 길다고 느껴진다면 collections 키워드를 사용할 수 있습니다. Playbook 상단에 collections: [amazon.aws]를 선언하면, 그 아래에서는 amazon.aws를 생략하고 ec2_instance만 적어도 됩니다.

하지만 명확성을 위해 FQCN을 사용하는 것을 권장합니다. 김개발 씨는 첫 번째 EC2 인스턴스를 Ansible로 생성하는 데 성공했습니다.

Playbook 몇 줄로 인프라가 만들어지는 것을 보며 신기해했습니다. "자동화의 힘이란 게 이런 거군요!" 컬렉션 설치와 사용은 Ansible 자동화의 핵심 기술입니다.

다양한 컬렉션을 활용하여 인프라 자동화의 영역을 넓혀보세요.

실전 팁

💡 - ansible-galaxy collection list로 설치된 컬렉션과 버전을 정기적으로 확인하세요

• 새 프로젝트 시작 시 ansible.cfg에 collections_paths를 설정해두면 편리합니다

---

6. 자체 컬렉션 생성하기

몇 달이 지났습니다. 김개발 씨는 이제 능숙하게 Galaxy의 Role과 컬렉션을 활용하고 있었습니다.

어느 날 팀장님이 찾아왔습니다. "김개발 씨, 우리 회사만의 컬렉션을 만들어볼 수 있겠어요?

자주 쓰는 모듈들을 패키징하고 싶어요."

ansible-galaxy collection init 명령어로 컬렉션의 기본 구조를 생성할 수 있습니다. 생성된 컬렉션에는 모듈, Role, 플러그인을 추가할 수 있으며, ansible-galaxy collection build로 배포 가능한 패키지를 만들 수 있습니다.

사내 Ansible Automation Hub나 프라이빗 Galaxy에 배포하여 팀 전체가 활용할 수 있습니다.

다음 코드를 살펴봅시다.

# 컬렉션 기본 구조 생성
ansible-galaxy collection init mycompany.infra

# 생성된 구조
mycompany/
  infra/
    docs/
    galaxy.yml        # 메타데이터 (버전, 의존성 등)
    plugins/
      modules/        # 커스텀 모듈 추가 위치
      inventory/
    README.md
    roles/            # 커스텀 Role 추가 위치

# galaxy.yml 예시
# namespace: mycompany
# name: infra
# version: 1.0.0
# dependencies:
#   community.general: ">=7.0.0"

# 컬렉션 빌드 (배포용 tar.gz 생성)
cd mycompany/infra
ansible-galaxy collection build

# 로컬 파일에서 설치
ansible-galaxy collection install mycompany-infra-1.0.0.tar.gz

김개발 씨는 팀장님의 제안에 눈이 반짝였습니다. 그동안 팀에서 반복적으로 사용하던 코드들을 컬렉션으로 묶으면 정말 편리해질 것 같았습니다.

박시니어 씨가 다가와 격려해주었습니다. "컬렉션 만드는 거 어렵지 않아요.

한번 해볼까요?" 컬렉션 생성은 마치 새 책을 집필하는 것과 같습니다. 먼저 책의 골격(목차)을 만들고, 그 안에 내용(모듈, Role)을 채워넣습니다.

완성되면 출판(빌드)하여 독자(팀원)에게 배포합니다. 첫 단계는 ansible-galaxy collection init 명령입니다.

mycompany.infra처럼 네임스페이스.컬렉션명 형태로 지정합니다. mycompany는 회사나 팀 이름, infra는 컬렉션의 목적을 나타냅니다.

명령을 실행하면 기본 디렉토리 구조가 자동으로 생성됩니다. 생성된 구조를 살펴보겠습니다.

galaxy.yml은 컬렉션의 신분증입니다. 이름, 버전, 설명, 의존성 등 메타데이터를 담고 있습니다.

plugins/modules 폴더에는 커스텀 모듈을 추가합니다. roles 폴더에는 컬렉션에 포함할 Role을 넣습니다.

김개발 씨는 팀에서 자주 사용하는 로그 수집 모듈을 plugins/modules에 추가했습니다. 그리고 서버 초기 설정 Role을 roles 폴더에 복사했습니다.

galaxy.yml 파일도 수정해야 합니다. version을 1.0.0으로 설정하고, dependencies에 필요한 외부 컬렉션을 명시했습니다.

이 컬렉션이 community.general에 의존한다면 여기에 적어두어야 합니다. 모든 준비가 끝나면 빌드할 차례입니다.

ansible-galaxy collection build 명령을 실행하면 mycompany-infra-1.0.0.tar.gz 파일이 생성됩니다. 이 파일 하나로 컬렉션을 배포할 수 있습니다.

배포 방법은 여러 가지입니다. 가장 간단한 방법은 tar.gz 파일을 직접 공유하는 것입니다.

좀 더 체계적으로 관리하려면 사내 Ansible Automation Hub를 구축하거나, 프라이빗 Git 저장소에 올려두고 requirements.yml에서 참조할 수 있습니다. 주의할 점도 있습니다.

컬렉션 버전 관리를 철저히 해야 합니다. 변경사항이 있을 때마다 버전을 올려야 사용자들이 업데이트 여부를 알 수 있습니다.

**시맨틱 버저닝(Semantic Versioning)**을 따르는 것이 좋습니다. 몇 주 후, 김개발 씨가 만든 mycompany.infra 컬렉션은 팀 전체에서 활용되기 시작했습니다.

반복적인 작업이 줄어들고, 코드 품질도 일관되게 유지되었습니다. 팀장님이 김개발 씨를 칭찬했습니다.

"이제 우리 팀도 자체 자산이 생겼네요. 잘했어요!" 자체 컬렉션은 팀의 노하우를 축적하는 최고의 방법입니다.

반복되는 작업이 있다면 컬렉션으로 만들어 공유해보세요.

실전 팁

💡 - 컬렉션 버전은 시맨틱 버저닝(Major.Minor.Patch)을 따르세요

• README.md에 사용법과 예제를 상세히 작성하면 팀원들이 쉽게 활용할 수 있습니다

---

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